Applying a Zero-Bug Policy at Redgate
A zero-bug policy is a simple yet effective bug management system that can help you avoid being buried deep in months or sometimes even years-old bugs. Any bugs you agree are serious enough for you to fix, you fix right away, and any other bug will not be fixed and closed.
Tom Walsh, software engineer at Redgate Software, spoke about how they applied the zero-bug policy at Lean Agile Exchange 2020.
Walsh explained the thinking behind the zero-bug policy:
Let’s be honest – if it isn’t important enough to fix now, it isn’t likely to ever be important enough! If it’s really that important, it’ll come up again and you can respond accordingly.
Walsh’s team at Redgate implemented their zero-bug policy by running it as a short one-month experiment, just to see if it was something they wanted to pursue long-term. Walsh mentioned that they re-triaged their existing backlog of 100 bugs and closed around 90 of them, which they deemed not important enough to fix. They then committed an entire sprint to fixing the remaining bugs, leaving them with as clean a slate as possible to begin with.
Walsh mentioned that the benefit that the zero-bug policy has brought is that the team has fewer meetings and experiences less disruption because bugs are dealt with as they arrive. This also has the advantage of allowing the entire process to be fully asynchronous, which is great when they’re all working flexibly from home, he said.
Another benefit Walsh mentioned is that it is much easier for them to prioritise and solve bugs:
We generally never have more than five or six open bugs at any one time. In fact, it’s often fewer! We’re also fixing bugs much quicker because of this, which is great for us and our customers!
InfoQ interviewed Tom Walsh about how Redgate applies the zero-bug policy.
InfoQ: You busted several myths on zero bugs in your presentation at Lean Agile Exchange. Can you share some of them?
Tom Walsh: The first myth is that a zero-bug policy is absolutely not about writing software with zero bugs in it. We all live in the real world and we know that outside of critical applications, this just isn’t realistic.
Secondly, contrary to popular belief, if you start closing bugs you have no intention of ever fixing, you won’t end up with an angry mob. In my experience, if you’re honest and transparent with your users, they’ll almost always be understanding and reasonable.
InfoQ: How do you decide if a bug should be solved or not?
Walsh: We needed a new way of deciding which bugs we felt we should fix and which should be closed, rather than relying on the fairly heavyweight weekly triage meeting we’d been using previously. To this end, we developed a process we called triage by emoji. This involved the team member currently handling our support escalations posting any new bugs into our dedicated triage channel on Slack. The other team members could inspect the bug and use one of three emoji reactions to convey their opinion:
• This bug is important and we should fix it
• This bug is not important and we should close it
• I’m not sure on this one; we should discuss and investigate further as a team
Once the team came to a consensus on each bug, their respective ticket was updated accordingly.
InfoQ: What challenges did you face and how did you deal with them?
Walsh: The biggest challenge I faced was getting buy-in from the team in the first place. The zero-bug policy is such a radical departure from traditional software support methods that there were definitely some sceptics! To combat this, I positioned it as an experiment that the team could try for a month while monitoring metrics such as "bug fix time" and customer satisfaction. If it didn’t work well, we could always fall back to our previous approach. This definitely helped get people on board with the idea.
Thankfully, once we eventually started the experiment, we saw so many positive results so quickly that the whole team were soon firm supporters of the zero-bug policy and it quickly graduated from an experiment and became part of our regular team process. We’ve continued to adapt and refine the process since then. For instance, we changed from Scrum to Kanban quite soon after the process rolled out, which required us to change how incoming bugs were dealt with. We also later tweaked the process to ensure we achieved a good balance of feature development, operational maintenance and bug fixing.
InfoQ: What if you decide to not fix a bug; how would you communicate that to your customer?
Walsh: During the triage process, we’d ensure every team member who voted on a particular bug explained why in a comment. This meant that we had a detailed explanation for why the team had declined to fix a bug. The person on the support rota would then add this to the support ticket, and the responsible support agent would communicate it to the customer.
InfoQ: What have you learned?
Walsh: There are two main lessons we’ve learned. The first is if you’re honest and transparent with your customers, 99 times out of 100 they’ll be understanding and reasonable with you, even if you don’t fix their bug.
Secondly, don’t be scared to be brutal! We found we had a tendency to be too lenient on which bugs we deemed important enough to fix. This was especially true if we didn’t currently have many bugs open, as we would sometimes take bugs on simply because we felt we could, rather than we should. This led to us doing potentially less valuable work, and meant that whether a bug got fixed or not could be heavily dependent on when it was reported, rather than the actual severity of the bug itself. Following this advice can be quite tricky. It’s a strange feeling to decline fixing a bug when you have no other open bugs, but like anything, my team found it gets easier with time and experience.