Why try a zero bug policy?
One of the hot topics at Redgate right now is the zero bug policy. Some teams are really keen, while others remain more sceptical.
What is a zero bug policy?
We’re not going to claim our software is bug free, nor that we fix all bugs. We realise that’s unrealistic at best. We’re looking to stop managing large numbers of open bug reports.
There’s a lot of information online about zero bug policies, and how different teams have implemented them. My prefered starting point is Fix It Now Or Delete It:
(Image courtesy of www.crisp.se)
Anything more than this seems to be fitting the process into your world and what you need to achieve.
What are we hoping to get from it?
Effective backlogs
Backlogs grow rapidly, filling up with great ideas and actionable feedback (like bugs).
How do we make sure we’re always doing the most important work?
Right now that means hours spent in triage meetings. We discuss the latest issues, often ignoring older problems, and pick the top priority work to do now.
Anything we don’t immediately prioritise gets put on a backlog and rarely, if ever, becomes the most important work. Why maintain a backlog of work you’ll likely never do?
Confidence we’re doing the most important work
Bloated backlogs have a hidden cost. They bring doubt.
When we commit to work we have to ask “but what about that other thing?”, but rarely change our plans because of it.
Why spend our time second-guessing our past decisions when we could be confidently improving our products?
But what if…
We want to fix an issue but it isn’t a blocker?
Should you fix it? Will you choose to prioritize fixing it?
Something is important, but we can’t do it now?
How likely is this to become the most important piece of work in the future? We consistently find that to be a rare occurrence, so accept the risk.
We want to fix it, but don’t understand how?
How can you improve the logging & diagnostics in the tool to make it easier to understand and fix next time it’s reported?
We know an upcoming piece of work will fix it?
Record the issue as part of whatever work package you’re doing later, rather than writing a bug report you’ll likely forget.
Maybe consider a quick fix to keep users happy until that work happens.
We ignore something we should have fixed?
We can already make the wrong choice and not prioritise work.
When this happens, bugs make their way back onto our radar as more reports come in. That’s just as true if we don’t have a record in an issue tracking system.
What’s Next?
At least two of our development teams are looking to experiment with this approach in the early part of 2019, so hopefully we’ll have some stories to share soon!
