A zero bug policy (1/n)

A critical decision to make when developing software is how to handle bugs.

Yet, many teams struggle to cope with bugs effectively and focus mostly on releasing new features quickly. By following a zero bug policy -where bugs take priority over new features- you build in quality. And you avoid a lot of frustration for your users, team members, and management.

I write this blog as the first in a series about a zero bug policy to share my experiences. I hope this experience might give you inspiration on how to handle bugs on your team.

The next blogpost in the same series is about how you can introduce a zero bug policy.

Why?

“Problems breed problems, and the lack of a disciplined method of openly attacking them breeds more problems.” ~ Phil Crosby

It is impossible to produce bug-free code continuously. Bugs will always exist¹.

With this in mind, a crucial factor for fewer bugs is how you handle them. Handling them as fast as possible is vital for the following reasons.

Users hate it when your software does not do what it promises. You are losing them faster than you think. Even if they have no choice, they will resent your software fast.
The longer you wait to fix a bug, the longer it takes. You often have to understand the requirements, the code, and the technical context before you find a solution, and the longer you wait, the more information has been forgotten.
On top of this, bugs often hide or interact with other bugs, complicating the effort and time it takes to solve these issues.
When you have lots of open bugs, you need to prioritize. Prioritization often leads to a lot of wasted energy in long and tedious meetings, managing unhappy customers, and handling negative customer reviews. Fixing bugs is a more useful way of spending that energy.
Existing bugs often lead to a broken window syndrome. How can you be proud of what you do if it is full of small issues? The motivation, focus, and perseverance required for making high-quality software will be a lot less if the software is already full of bugs.
Fixing bugs in a software system is by the nature of the work very unpredictable, as the largest part of fixing a bug is understanding what is going on.
False sense of speed. People wrongly assume that the work is fully finished and how much work teams can handle with decent quality.

In summary, the longer you ignore bugs because you want to focus on features, the more unpredictable it becomes to fix them, leading to unhappy users, unpredictable delivery, and a lot of wasted energy.

What is a zero bug policy

“In a true zero-defects approach, there are no unimportant items.” ~ Phil Crosby

A zero bug policy means that all bugs take priority over all new feature development.

The zero bug policy is not a means to prevent all bugs; it means striving to remove all known bugs as soon as possible. It is a software version of the Andon cord in Lean.

A zero bug policy typically needs a bit more clarification before you can start applying it in a team. Below describe our policy (with minimal redaction to remove references to the company and improve readability) from a context with a product where we have three subteams working on the same codebase in a Scrum kind of way.

Our policy

The default is that we handle bugs before new stories.

We handle high priority bugs immediately; we do not wait until we finish a story.

We assign the bug to the subteam responsible for the component in which we found the bug. If it is not clear, we give the bug to a random team to do the first analysis.

Exceptionally, a pair working on a feature on the business’s critical path (critical pair) can ignore 1 and 2. In this case, the other pair of the same subteam needs to cover for the critical pair. We agree on the exception during planning or the standup.

The following guidelines help to determine if a bug is a high priority

Something that is in production (not hidden behind a feature toggle) and impacts multiple users

Something that would prevent us from releasing

Something that would block more team members to do their job

Something with high impact

Some clarifications on our policy

Handled could mean the fixed, closed without resolution because we decided it was not significant enough, or converted to a story on the backlog if it was a feature request packed as a bug.
A typical story takes a few days to finish. As we have multiple pairs working on the same product, a pair typically starts analyzing any bug within a day or so.
Any team member can recategorize a bug as a feature or identify a bug as a high priority. Only in case of discussion or doubt within the team, the product owner is involved.
As we have several subteams and several (functional) components, we assigned a responsible subteam for each component (called component guardians). This subteam typically investigates and solves all the issues in that component.
As you might notice, there is a compromise in our policy to allow exceptions for a pair to focus on a very critical feature. I could have left it out, as any of these explanations sounds better in a pure form. But I left it on purpose to illustrate that compromises are a reality, and it is better to have the truth in your policy and do it than describe some dream that everyone ignores.

Next up?

In the next post I discuss the turmoil of introducing a zero bug policy: steps, concerns, questions, and how long it takes to reach a good place.

And as always, let me know what you think on Twitter. And remember

“Quality is everyone’s responsibility.” ~ W. Edwards Deming

Some references

Following good technical practices reduces your bugs. But because of the large number of OS versions, hardware, and specific circumstances, it is very hard to prevent all possible bugs. The key characteristic is to prevent as many as possible, and handle all of the issues that appear ASAP. The practices you can follow will be the subject of a future article. ↩︎