Don't Manage Backlogs of Bugs

Don't manage failure, create customer value instead: embracing a Zero Bug Backlog Policy for Operational Excellence.

In the fast-paced world of software development, operational excellence is often hindered by accumulating technical debt, excessive operational load on teams, slowed feature delivery, and dissatisfied customers. A common scenario unfolds where a backlog of issues—ranging from minor bugs to critical incidents—continues to swell, making it increasingly difficult for engineering teams to maintain a high level of performance and customer satisfaction. This article explores the benefits of adopting a zero bug backlog policy, emphasizing the importance of fixing bugs promptly to create a quality-first mindset and drive continuous improvement.

The Problem

Imagine a software engineering team grappling with escalating technical debt. The operational burden on engineers intensifies, slowing down feature delivery. Customers become unhappy as they encounter delays and unresolved issues. Meanwhile, the backlog of problems grows, adding to the challenges the team faces. This scenario highlights the common practice of managing a bug backlog, which involves delaying decisions, learning, and fixing issues for "sometime later." This approach often leads to prolonged periods of low-quality service for customers and establishes the counterproductive habit of managing a bug backlog.

Solution: The Zero Bug Backlog Approach

To counter these challenges, a software development team can adopt a zero bug backlog policy. This means agreeing to always triage and prioritize any bug over existing or new feature work, ensuring the bug backlog will not increase but can only shrink. The solution is quite simple, yet usually not intuitive:

1. Is it a bug? If not make it a Task or delete it.

2. Should we fix it at all? If not delete it, if yes fix it now, regardless of severity.

The concept is nicely depicted at

Why Adopt a Zero Bug Backlog Policy?

1. Faster Issue Resolution: Fixing bugs promptly means customers experience fewer issues, enhancing their satisfaction and trust in the product.

2. Cost-Efficiency: Addressing bugs closer to the initial commit reduces the cost of fixes, as the context of the feature is still fresh in the team's mind.

3. Quality-First Mindset: Prioritizing bug fixes reinforces a commitment to quality and continuous improvement, ultimately leading to better products and improved lead times.

4. Preventing Cascading Issues: Immediate bug fixes help in understanding the system better and prevent cascading issues that could complicate future developments.

5. Eliminating Waste: By not having to update, revisit, and re-prioritize a backlog of bugs repeatedly, teams can avoid significant waste.

Underlying Principles

• A Bug is a Broken Promise: A feature is not complete until it works as expected. Delaying bug fixes means breaking promises to customers and it is not customer centric.
• Wasteful Delay: Delaying bug fixes and the associated learning processes is wasteful and detrimental to the team's effectiveness and quality ambition.

Implementation: From Principles to Practice

To implement a zero bug backlog policy effectively, the complete product engineering team and at least the direct management chain has to buy in. Common strategies are to start with one team or a limited timeframe for an experiment. The usual misunderstandings should be clarified (see FAQs). Furthermore teams need a clear definition of quality and an understanding of what constitutes a bug in their specific context. Tools like user stories, service level objectives (SLOs), error budgets, and a solid definition of done are essential. For instance, a quickly built prototype with "throw-away code" will have different SLOs compared to a core platform component or an established, heavily used product. Recognizing and adapting to these differences is crucial for maintaining quality across diverse projects.

Frequently Asked Questions

Then there will be no bugs anymore? No. Bugs will always exist. The focus is on minimizing their presence and learning from them to prevent future occurrences.

Should teams be measured by the number of bugs? No. Teams should be encouraged to raise potential bugs or incidents. Not raising issues as a result would be bad.

Should all bugs in the backlog be fixed first? No. New bugs should be either prioritized or closed as "Won't do." Reducing the existing backlog is a goal, but it may not be feasible to fix all issues at once.

What if some bugs can't be fixed quickly due to external or systemic issues? It is essential to address and understand the root cause of these issues, even if it means stalling feature delivery temporarily.

What if we deleted a bug and it turned out to be a bigger issue? No problem, reopen the issue, add more context why it has been not considered a big enough problem and fix it now.

OMG my boss / product management / sales ... freaks out, we have to deliver features! Good timing (like not in the middle of a big release rollout) and framing it as experiment and of course explaining the benefits might help. At the end we are all interested in better quality for our customers, aren't we?

Conclusion

Adopting a zero bug backlog policy is more than just a strategy; it's a commitment to operational excellence and a quality-first mindset. By prioritizing bug fixes, teams can create value, improve customer satisfaction, and foster a culture of continuous improvement. This approach not only enhances the quality of the software but also contributes to the long-term success and agility of the organization.

Links

• https://www.fixitnowordeleteit.com/
• Roland Flemm, Zero bug policy. A fast way for paying back technical debt. https://www.scrum.org/resources/blog/zero-bug-policy-fast-way-paying-back-technical-debt, "Creating a list of bugs delivers a well organized inventory of technical debt. Spending time on evaluating and administering bugs with the goal of putting them on a list is wasteful. I recommend to stop doing this."
• Peter Hilton, Implement a zero-bug policy: https://hilton.org.uk/blog/zero-bug-policy, "Avoiding managing bugs and having meetings about unpredictable development schedules gives you more time for product development."
• Jan Peratt, How a zero-bug policy doubled our development velocity: https://www.dhirubhai.net/pulse/how-zero-bug-policy-doubled-our-development-velocity-jan-peratt, "Fixing bugs increases velocity"
• James Shore, The Art of Agile Development, Second Edition: https://www.jamesshore.com/v2/books/aoad2/no_bugs#:~:text=A%20culture%20of%20%E2%80%9Cno%20bugs,do%20achieve%20nearly%20zero%20bugs. "Ultimately, “no bugs” is about establishing a culture of excellence. When you learn about a bug, fix it right away, then figure out how to prevent that type of bug from happening again."
• Joel Spolsky, The Joel Test: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ "5. Do you fix bugs before writing new code?"
• Sam Hatoum, Zero-Bug Software Development: https://medium.xolv.io/the-zero-bug-policy-b0bd987be684 "… the Zero-Bug policy. It slows your team down just enough and _in just the right places__. The speed increase may not be visible in the day-to-day, but it will be apparent in the throughput over time."_
• Agile Manifesto principles, https://agilemanifesto.org/principles.htm "Working software is the primary measure of progress.", "Continuous attention to technical excellence and good design enhances agility."
• Porsche AG, Zero Bug Policy: Experience from My Porsche and How to Start https://medium.com/next-level-german-engineering/zero-bug-policy-experience-3121b3046326
• Simone Colosimo, Dashlane, A journey through an adapted zero-bug policy: https://agiletestingdays.com/2021/session/a-journey-through-an-adapted-zero-bug-policy/
• Gal Zellermayer, 0 Bugs Policy: https://www.infoq.com/articles/0-bugs-policy/