Newsletter #50: Is it time to ditch Definition of Ready ?

Welcome to newsletter 50.       Past 3 newsletters:  Empirical Coach weekly newsletter #49: “Special Forces” Innovation: How DARPA Attacks Problems Empirical Coach weekly newsletter #48: List of some popular books  Empirical Coach weekly newsletter #47: Toyota Production System is emergent         Interesting Articles   “It's time to ditch Definition of Ready ?" It is a bit of a controversial article and I have my own views. However, the author seems to share his vows through this article around Definition of Ready.  As a Product Owner, I needed help from another team. My request was quite simple: to send a file they were already producing over SFTP to a third-party. I added an item to their Product Backlog with all the bells and whistles: title, description, business value and acceptance criteria. The ticket was refined and planned for the next Sprint. The team contacted me and told me everything was clear. They asked if I could provide the SFTP credentials of the third-party. I immediately asked the third-party to provide us credentials to the different environments. Unfortunately, the third-party did not respond before the Sprint started. When I was checking my e-mail in the office on Monday morning, I found out my Backlog Item was removed from the Sprint. I would need to wait another two weeks. When I asked why they removed it, they answered the ticket did not meet their Definition of Ready and was removed from the Sprint as a result. Two main arguments are commonly used to support the use of a Definition of Ready: Making clear to stakeholders what we need from them in order to make Backlog Items clear. Preventing Backlog Items from being unclear before the team starts working on them. 1. Scrum already prescribes what makes a Backlog Item “Ready” for Sprint Planning Willem-Jan Ageling pointed out to me that Scrum already prescribes what makes a Backlog Item “Ready”. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. — Scrum Guide In the Scrum Guide it is explicitly stated what makes a Product Backlog Item “Ready”. If the Development Team believes it fits in a Sprint, then it’s ready to be worked on. 2. Product Backlog Items in Scrum already contain enough information to get started A Product Backlog Item should possess the following information according to the Scrum Guide: Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”. — Scrum Guide 3. Sometimes just a title may be enough to start working on something Imagine your Sprint has started and someone from the Development Team notices a big production issue. She discusses it with the team and quickly adds a Backlog Item to the Sprint with just a title. She starts working on it immediately and clarifies the description as more information becomes available about the underlying problem. 4. It’s already up to the Development Team to change the Sprint Backlog during a Sprint You don’t need a Definition of Ready to stop messy and unclear Backlog Items from being added to the Sprint. Imagine a Sprint has started and somebody wants your team to work on something during the Sprint that is too vague. You don’t need a Definition of Ready to prevent this from happening. The relevant passage from the Scrum Guide: Only the Development Team can change its Sprint Backlog during a Sprint. — Scrum Guide 5. Definition of Ready conflicts with Agile way of working Let’s take a look at the Agile Manifesto: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan With these sentences in mind that capture the essence of Agile, how does a Definition of Ready fit in? Read the rest of the article here     "What comes after Scrum? - Ken Schwaber" Scrum is not the be-all and end-all process for software and product development. As many of you have noticed, it is barely a process, only a framework. You have to provide all the development, management, product management, and people practices. So, what does Scrum provide? It provides a labeled- environment within which complex development can be successfully managed (where the unknown is greater than the known). Scrum provides containers that allow teams to focus on one aspect of a complex problem  at a time. The containers are short-time boxes so that risk can be managed. Scrum can be replaced or superseded by anything that also supports its underlying principles: 1. Self-organization – people doing complex work are much more effective organizing themselves and the work than someone who isn’t doing the work. 2. Bottom-up intelligence – figuring out how to do work is a management activity best performed by the people doing the work, since the work is unpredictable, with many twists and turns. 3. Empiricism – it is hard to plan what you don’t know, so we instead see what has been accomplished, and then figure out what to do next. We do this frequently to control risk and determine the best path to our goal. 4. Transparency – we periodically have to know what is actually happening to make effective empirical decisions. As stated in bible of process control (“Process Dynamics, Modeling, and Control”, Ogunnaike and Ray, Oxford University Press, 1994) , there is no bad process. However, sometimes processes are applied to inappropriate situations. Scrum is an empirical process built on lean principles. It is most appropriate for optimizing complex work. I welcome anyone who comes up with the next great process, one that does all of the above even better than Scrum. I’m still waiting. Read the original article here     Large-Scale Scrum(LeSS) My recent webinar about  5 unique Things about Large-Scale Scrum  Check out this  youtube link     HOW TO AVOID WRITING NEW LEGACY CODE (Excerpts from Practices of Scaling Lean and Agile  By Larman and Vodde)   “We promised this release to our key customer, and the only acceptable commitment from R&D is the first of February,” said an angry email sent by a director to the management of the product group we were coaching. We read it in disbelief and wondered about the only acceptable commitment. We decided to ignore the email—for now— and get back to normal work—coaching a developer in refactoring a legacy component that was hacked together last release to meet that deadline. Many companies are stuck in a vicious cycle of forced promises and See unrealistic commitments. In today’s time-to-market era, customers force’ them to promise too much. “If you cannot deliver by the end of the year, we will buy from your competitor who will make that promise.” Sales people or executives could respond by being transparent and by working toward a mutual beneficial long-term relationship (customer collaboration), but instead they check whether the contractual penalty for being late is tolerable (contract negotiation) and reply, “Yes, no problem, we can do it!” After which the same cycle starts within the organization. The executive orders the head of R&D to “do it” and “make it happen” because “it is a customer promise.” The promise travels through the organizational hierarchy to the developer, who cannot pass it on any further. How does the developer react? Charles Lecht [Lecht67] already warned us over 40 years ago: The developer will “feel the obligation to respond out of respect, fear or misguided loyalty” and reluctantly commit to the deadline. The developer opens his secret toolbox and does everything possible to make the short-term deadline by using tools such as hardcoding, copy-paste-modify programming, skipping testing, working overtime, and other quality-destroying shortcuts [Schwaber07a]. Nobody notices the use of these ‘tools,’ and so the deadline is made. Management rewards developers for their hard work and applauds their “great teamwork” and “fighting spirit.” These quality-destroying shortcuts result in bad legacy code, which slows down the development and the organization falls behind its competition. A predictable scenario unfolds. They need to reclaim the market and therefore make new promises, starting the vicious cycle all over again. The technical debt—the legacy code—makes development go slower. The learning debt—lack of renewal in developer skills—compounds this slowdown.     If you like this newsletter, please share it with your friends. You can subscribe to the newsletter here     Upcoming Events   Look forward to public courses in Brisbane, Melbourne, Sydney, Perth and India in 2020.  Possibly expanding to other countries. I have started online training for Certified LeSS Basics.  I recently completed a few and would be announcing a few more soon. Keep an eye on this newsletter. Many might not know that I also offer Certified LeSS Executive training. This is specifically for senior leaders who might be interested in learning the intricacies of management and structure to influence the culture.  Please reach out:  venky at agileworld.com.au for further details.   About Empirical Coach If you are interested in Agile coaching, mentoring and training services, please reach out to me (venky@agileworld.com.au). We have a team of passionate coaches collaboratively working together and could help. Our team has deep expertise in Agile, Lean, Systems Thinking and Complexity science. We look at challenges from different angles and apply tools from various schools of thoughts. This is different from the cookie-cutter approaches you see around.  We are proud to be different. I have been deeply involved in many of the initial experiments that lead to the birth of LeSS, one of the countable number of people globally.   Blog | LinkedIn | Twitter

Newsletter #49: “Special Forces” Innovation: How DARPA Attacks Problems

Interesting Articles

“Special Forces” Innovation: How DARPA Attacks Problems

Over the past 50 years, the Pentagon’s Defense Advanced Research Projects Agency (DARPA) has produced an unparalleled number of breakthroughs. Arguably, it has the longest-standing, most consistent track record of radical invention in history.

Its innovations include the internet; RISC computing; global positioning satellites; stealth technology; unmanned aerial vehicles, or “drones”; and micro-electro-mechanical systems (MEMS), which are now used in everything from air bags to ink-jet printers to video games like the Wii.

Though the U.S. military was the original customer for DARPA’s applications, the agency’s advances have played a central role in creating a host of multibillion-dollar industries.

The DARPA model has three elements:

Ambitious goals.

The agency’s projects are designed to harness science and engineering advances to solve real-world problems or create new opportunities. At Defense, GPS was an example of the former and stealth technology of the latter. The problems must be sufficiently challenging that they cannot be solved without pushing or catalyzing the science. The presence of an urgent need for an application creates focus and inspires greater genius.

Temporary project teams.

DARPA brings together world-class experts from industry and academia to work on projects of relatively short duration. Team members are organized and led by fixed-term technical managers, who themselves are accomplished in their fields and possess exceptional leadership skills. These projects are not open-ended research programs. Their intensity, sharp focus, and finite time frame make them attractive to the highest-caliber talent, and the nature of the challenge inspires unusual levels of collaboration. In other words, the projects get great people to tackle great problems with other great people.

Independence.

By charter, DARPA has autonomy in selecting and running projects. Such independence allows the organization to move fast and take bold risks and helps it persuade the best and brightest to join.

The work in Pasteur’s Quadrant doesn’t exist on road maps. It results in discoveries that upset the current trajectory and can destroy an existing business. Expecting the research organization executing against the road map to simultaneously deliver breakthrough innovations that challenge the road map is unrealistic. Instead, companies should create a small, dedicated independent organization to work in Pasteur’s Quadrant. They should take to heart the lesson that the U.S. government learned from the launch of Sputnik: The best way to prevent surprise is to create it. And if you don’t create the surprise, someone else will.

It is a pretty lengthy article filled with a lot of good info.. 

Read the rest of the article here

---

"THE CLOTHESLINE PARADOX"

TIM O'REILLY is the founder and CEO of O'Reilly Media, Inc., a leading computer book publisher. O'Reilly Media also hosts conferences on technology topics, including the O'Reilly Open Source Convention, the Strata series of conferences on big data, and Tools of Change for Publishing. O'Reilly Media's Maker Media unit publishes Make Magazine and operates Maker Faire, the world's largest gathering of DIY hardware enthusiasts and entrepreneurs. O'Reilly AlphaTech Ventures is a leading early-stage venture capital firm.

I've been thinking a lot lately about a piece I read in Stuart Brand's, CoEvolution Quarterly back in 1975. It's called the "Clothesline Paradox." The author, Steve Baer, was talking about alternative energy.


The thesis is simple: You put your clothes in the dryer, and the energy you use gets measured and counted. You hang your clothes on the clothesline, and it "disappears" from the economy. It struck me that there are a lot of things that we're dealing with on the Internet that are subject to the Clothesline Paradox. Value is created, but it's not measured and counted. It's captured somewhere else in the economy.