Zero-bug-policy - Myth, goal or state of the art

Working as a trainer in Scrum- and Kanban-workshops and -trainings, I am often confronted with the question on how to handle bugs. Bugs are mentioned neither in descriptions of planning meetings nor replenishment meetings. Many participants of our trainings come up with two or three ideas how to cope with bugs. And then there is the idea of a zero-bug-policy.

But before I want to write about this idea, I want to have a look on what many teams do to cope with their bugs.

What Teams do

The most popular idea seems to be to handle bugs similar to stories/tickets: every bug discovered of a size bigger than fixing a typo goes directly to the Product Owner or whoever responsible for prioritizing the work, is estimated in complexity or effort, is planned and finally fixed by the team when it's the "right" time.

A second possibility is that the team reserves a certain amount of time (e.g. one day a week or a certain time per day) just for bugfixes.

Another very popular idea relates to reporting the bugs in a tracker system of any flavor and the team pulls the bugs they recon as important any time they think suits their purpose. A variation has people e.g. of the support or management who actually add some pressure by appearing in the team-room and complaining until someone agrees to fix the problem.

A fourth possibility to handle bugs which I already encountered in trainings or coaching is a bug fixing team, which cleans up after the team who implements the functionality. In these cases the teams don't seem to communicate very often.

What may be dysfunctions

There are more ways to handle bugs. Some may be a combination of the given ones. I don't think that one way serves all teams but I think that there are certain no-gos because one way or another promotes dysfunctions which I'd rather not have in my team:

Estimating bugs and actually fixing them when they are the most important functionality at a given time doesn't make me nervous. But don't give the team credit for this in terms of storypoints or accomplished tickets! The team shouldn't be proud of a sprint with many storypoints which actually come from bugs they shouldn't have had in the first place. I actually want the team feeling a certain pain coming from bugs in form of a reduced speed. Some teams otherwise tend to rush through stories/tickets thinking they can fix the bugs later and even get credit for it!

The same problem applies to separate bugfixing teams: If the team doesn't feel the pain of bugs, they have a reason less to motivate good and responsible work!

A problem with fixing bugs in a convenient time or by pressure of other people may be that some teams tend to lose track of what is really important just now (prioritizing) or that unpopular tasks are left undone (avoidance).

Not all the problems apply to all teams. Most of them actually seem to know exactly what is important. Sometimes the pressure on them leads to other than sensible actions.

Zero-bug-policy?

Now back to a zero-bug-policy. Yes, I know that there are no systems without bugs. But if you called it zero-known-bug-policy it doesn't read as smoothly. For many teams this seems impossible. Who doesn't know bugtracking systems stuffed with unresolved bugs? Sometimes the bugs are old. Really old.

When you tell them that others have a zero-bug-policy they sneer at you and tell you that they have a more complex system where that is not possible. If they were to resolve all the bugs in their tracker, they may be weeks or even months out of business.

And I heard about a team which actually did exactly that: They didn't develop anything new for about three months and fixed every single known bug. Although the little company was stuck and it really was expensive, they had serious quality-troubles beforehand and their reputation was at stake. The company survived this trip barely and I won't recommend this strategy to every team. But if you have a reputation for many bugs and there is competition, quality shouldn't be taken easily.

Another team did throw away all the data of their bugtracker. They began from scratch concerning bugs and counted on their testers and users to report any important bug anew. With this strategy, they could concentrate on the actual concerns of their users. I also won't recommend this strategy to every team but if you don't know how to prioritize start from the most recent ones backwards.

Some teams succeed to not having to handle a whole bunch of bugs. Most of them invest a certain amount of time on fixing the bugs and integrate their testers as early in their process as possible: from the very start!

When teams decide for a bugtracking system, I always shiver, because that decision may be the decision for managing bugs, instead of fixing them. Recently I saw two teams (of one company) who said goodbye to their bugtracker. The tester was incorporated to the teams more and more. They could get rid of the bugtracker and replaced it by good communication and a swimlane on their board for any raised bugs. The teams felt responsible for the technical quality more and more and they worked hard for several months to fix more bugs and to produce less. And they succeeded. In a complex system which grew over the last at least 10 years.

What I see

What about the title of this post? Myth, goal or state of the art? The zero-bug-policy is not a myth. At least if you speak of known bugs. There are teams who succeed to keep their (known) bugrate at level very close to zero. And the way may be hard and timeconsuming. There are radical ways to get there and less radical ones. It helps to not have too many dysfunctions and teams who feel responsible.

I don't think that it is state of the art, yet. But I definetely have a zero-bug policy as a goal in every team I work on. Keep on fixing problems. Don't manage them!