At the end of every sprint, a team should have a deployable product increment. There are a ton of ideas packed into that single phrase. In this chapter, Mr. Ripley and Miller focus on the concepts of deployable and done. Anyone that has more than an academic knowledge of Scrum knows all the reasons and rationalizations for why having a deployable product increment doesn’t always happen. What is worse, many practitioners believe having something deployable is beyond the realm of possibility in their environment. This is almost always a fallacy.

Being able to deliver a deployable product increment requires having a definition of done. This definition must be understood by every person on the team, from product owner to developer. Without a definition of done that is known upfront, it’s very difficult to know when any piece of work is deployable. Without an understandable definition of done the whole idea of deployable becomes subject to common human biases such as the tyranny of urgency. The outcomes are several of the antipatterns addressed in this chapter all of which yield technical debt, quality problems, and incentives for judgment. One form of poor judgment is releasing an increment with undone work. Todd and Ryan state “releasing an increment with undone work isn’t just technical debt but lays the foundation for significant customer damage and credibility damage for the team.” Sticking in “things” that don’t work isn’t a technical debt strategy.

One of the quotes from the book I have found useful is “is the distance between done and released to the customers is a measure of agility.” As I have noted teams and organizations have many reasons why product increments are not releasable at the end of a sprint. When explored, almost can be addressed with imagination or the political will to re-tool or reorganize the organization. There is no reason to sacrifice flow for quality or security; you will have to engineer the organization to achieve all three. Hardening and testing sprints (along with design, coding, architecture, and others) are still a thing (please tell me the school that teaches this madness). Early last year I had a long discussion with a testing lead that argued that since he was the only tester in a shop that required independent testing that he only would address work after the sprint was “done”.  Work was only implementable when it was “done – done – done.” Bad organizational design is at the crux of this example. That design flaw creates a scenario where the people that fill the roles self-select based on the flaw creating a self-reinforcing cycle. The conversation ended with shrugged shoulders and the statement “it works for me.” The organization complained that the development teams could not respond to change; I am not convinced that the setup was working for anyone.

There are two more chapters in Fixing Your Scrum and a week for a  follow-on discussion.  We will complete our re-read of the book in three weeks. My intent is to reread Project to Product next unless there are other suggestions. Ideas?

If you have not bought your copy — what are you waiting for? Fixing Your Scrum: Practical Solutions to Common Scrum Problems 

Previous Installments

Week 1: Re-read Logistics and Front Matterhttps://bit.ly/3mgz9P6 

Week 2: A Brief Introduction To Scrum, and Why Scrum Goes Badhttps://bit.ly/37w4Dv9 

Week 3: Breaking Bad Scrum with a Value-Driven Approachhttp://bit.ly/3stGc9Q 

Week 4: The Product Ownerhttps://bit.ly/3qpKvSn 

Week 5: The Product Backloghttp://bit.ly/3cAEk9c 

Week 6: The Development Teamhttp://bit.ly/2OLVAAs 

Week 7: Embracing The Scrum Master Role –  https://bit.ly/3m0HB5D 

Week 8: Managementhttps://bit.ly/31Kv39l 

Week 9:  Thinking In Sprintshttps://bit.ly/321wXTg 

Week 10: Sprint Planninghttps://bit.ly/3stWOhx 

Week 11: Sprint Backloghttps://bit.ly/3njezit Week 12 – Reclaiming The Daily Scrumhttps://bit.ly/3eNzMgz