This is an excerpt from the new Illustrated Scrum Myths book by Mary Iqbal, now available on Amazon. Each myth in the book includes a full-color illustration, a description of the myth, and an explanation of the truth behind the myth.
The purpose of this book is to help you use myths to remove impediments to value delivery. Myths can often be signposts pointing to a deeper truth. For example, is your vendor insisting you document items on the Product Backlog with excessive detail? Maybe they don’t understand what you’re asking for. Maybe you have siloed your teams too narrowly. Or maybe they don’t have the expertise to deliver what is being asked of them. It’s your job to figure out the truth behind the myth. Every myth in this book is an invitation to a deeper conversation.
Myth # 39: Technical Debt is the Developer's Problem. They caused it, so they should fix it on their own time.
The reality
The Product Owner should be kept informed of Technical Debt by the Scrum Team and should add fixes for Technical Debt to the Product Backlog and order it along with new features. To reduce the accumulation of new technical debt, teams should consider enhancements to their Definition of Done.
What this myth reveals
This can often be a sign of a disempowered Product Owner—or a newer Product Owner. The Product Owner should be empowered to order fixes for technical debt on the Product Backlog. They should be the ones to decide whether that bug fix, that code refactoring or that new feature will add the most value to the Product.
Here’s why
Technical debt is a common software development term describing coding decisions that might slow future delivery of future value to the customer. For example, delaying necessary upgrades is a common type of technical debt. Poorly organized code or unnecessary code lines are also examples of technical debt.
Not all technical debt is bad. A Product Owner might decide to delay an upgrade to enable them to release new high-value features to the customer sooner. Likewise, the Product Owner might authorize an experiment or a pilot without a robust technical framework to get customer feedback about usage before investing further. There may also be times when Developers make decisions to trade quality for speed in consultation with the Product Owner. For example, the Product Owner may agree that something should be hard coded rather than dynamic in the short term to help release a new feature sooner.
Technical debt needs to be paid back to avoid slowing future value delivery. The team might address technical debt by adding improvements to the Product Backlog. Upgrades, bugs, and new features should be included and ordered on the Product Backlog together, rather than on separate lists. This gives the Product Owner greater visibility, control, and accountability for the product overall. After all, they are the owner of the product as a whole, not just new features.
Conclusion
Developers should inform the Product Owner of any technical debt they may not be aware of, such as poorly documented or organized code, so that the Product Owner can ensure that fixes for Technical Debt are added to the Product Backlog. Additionally, the Scrum Team should consider updates to the Definition of Done which might prevent the accumulation of additional Technical Debt in the future.
Get your full-color copy of Illustrated Scrum Myths on Amazon today. Includes over 100 full-color illustration and years of practical advice.