Re-Read Saturday, Fixing Your Scrum, Week 13, Chapter 13: Deconstructing The Done Product Increment

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 Matter – https://bit.ly/3mgz9P6

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

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

Week 4: The Product Owner – https://bit.ly/3qpKvSn

Week 5: The Product Backlog – http://bit.ly/3cAEk9c

Week 6: The Development Team – http://bit.ly/2OLVAAs

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

Week 8: Management – https://bit.ly/31Kv39l

Week 9: Thinking In Sprints – https://bit.ly/321wXTg

Week 10: Sprint Planning – https://bit.ly/3stWOhx