Zero Defect Culture is a term I came up with just over a year ago to describe an approach that focuses on keeping your in-development defects at or around zero.
It can be applied to any team developing a software application in phased iterations to help minimise disruption created during feedback cycles between releases.
How do you adopt a Zero Defect Culture?
There is only one step involved in putting this in place:
agree as a team that you do not expect or tolerate defects in your work
That’s it. You’re done. Get out of here and crack on.
Not satisfied? Sound like airy-fairy nonsense? Ok, there are some practical steps that go along with this that can help you make it work, but realistically, the power of a self organising team getting together to make a commitment to each other is the most important part of it all.
Feel free to follow the practical steps that follow, but by understanding the concept and having made a commitment to do this, you’ll figure out a way to apply this that is a better fit in your own particular context than any I could suggest.
Doesn’t everyone treat defects with urgency?
It’s nice to think that in general people take defects seriously, but i’ve witnessed teams take a very informal agreement about how to prioritise them and this can break down if people are distracted by the lure of shiny new work. The same people can end up being the ones who always take responsibility for clearing down defects. Zero Defect Culture gives you a framework to share that responsibility.
For those of you who have a bug database with hundreds of open issues that will never get looked at (let alone resolved), imagine trimming down to a lean approach where you could consider not needing a bug database at all.
What is a defect?
Firstly, let’s put issues in your production applications to one side. What i’m talking about here is specifically defects that occur during development of your next software release.
We need to be clear about exactly what is meant by a defect. My definition is:
A regression in done functionality
Something missing that you would reasonably expect to have been done in a completed piece of work
Anything that falls outside this definition is something else. They could be new requirements or perhaps raised in error. There will also be issues raised that are not important enough to matter. For what follows, we do not class any of these as defects.
So what do we do with the defects?
Let’s take the first part of the definition, regressions. If I am building feature A and I do something that breaks feature B, I need to fix that. I don’t need someone to prioritise that work item, it is part of the task i’m already doing, which to give it its full name is implement feature A without breaking anything else. Associate these defects with the original work item that introduced them.
Even if it isn’t clear which item of development work broke feature B, if it worked before our recent changes and doesn’t work today, we should assume it has been broken by our ongoing development. Put these in a pile who’s origin is unclear, but which need addressing immediately (when we come to work on them, we may later understand their cause and associate them with a work item at that point if it makes sense to do so).
The second part of the definition –Something missing that you would reasonably expect to have been done in a completed piece of work – applies to work that we thought was complete, but clearly isn’t. This isn’t to encourage scope creep, but more about the story not making any sense without the missing element, or of the implementation being to a lower standard than usual if it is not included. Use your Definition of Done and your common sense to identify these. Haul that work item back to a state of in-progress and associate the defect with it.
Triage defects aggressively into these three categories and throw everything else out either completely or to a backlog. Delete them from your bug tracking system.
Hopefully by now, you can see a pattern. All we are doing here is highlighting incomplete work that is already or has recently been in-play. This means we can take the question of prioritisation out of the equation. This work has already been prioritised, we’ve just identified that it is not yet complete.
When do we fix them?
So we have identified and allocated some defects, but now what? The answer is, fix them ASAP. What is meant by as soon as possible, is up to the individual. It might be when you complete your current piece of work, or find a suitable stopping point. It is definitely before you start on a new work item.
What are the benefits?
Broken Window Theory describes the negative feedback cycle that occurs when something isn’t given the care it needs. In our industry it can be seen as neglect of a codebase or project leading to software rot or the acceptance of poor standards. By taking a stance that defects aren’t acceptable and need to be addressed quickly, we keep as much of the application release ready as possible and establish a sense of pride and responsibility in the quality of the product.
At first it might feel like this approach leads to too much context switching and a lot of stop/start noise as you jump between stories and defects. But as you start to get into a rhythm of doing this, you’ll hopefully see that this in fact reduces the noise around story development. It’s the usual agile paradox of how going slow gives you the opportunity to learn how to go fast.
Root cause analysis
Once you’ve started to put this in place and are beginning to feel the benefits, you can turn your attention to reducing the number of defects raised.
Make the job of fixing a defect include understanding what caused it in the first place. Some examples of causes could be missing regression tests, poor story definition, agreed process not being followed, an overly complex area of code or lack of developer understanding for example.
Take steps to stop this happening again without unduly bloating your process or abandoning lean principles. Then you’ll really start to feel the benefits of continuous improvement.
Will it work?
There are some fairly obvious ways in which this can fail. If your team are close-knit enough to make a strong commitment to each other and ‘call each other out’ when they pick up new work instead of fixing defects you stand a really good chance of this working for you. Otherwise you’ll end up with some people doing it and not others. And eventually no-one.
Also, if you are not triaging aggressively enough, you’ll end up spending all of your time fixing things that just don’t matter and the value of your output will plummet.
I’ve assumed that you already have a process for dealing with defects that escape into production in a timely manner and so this isn’t covered here.
What is a defect?
- A regression in done functionality
- Something missing that you would reasonably expect to have been done in a completed piece of work
What is Zero Defect Culture?
- Agreeing as a team that you don’t accept or tolerate defects in your work
Keeping your in-development defects at or around zero
What does it mean in practice?
- Aggressive triage of defects to ensure they meet the above definition
- Being thorough in completing work
- Dropping story work to jump on defects when they are raised
- Doing root cause analysis to understand how a defect occurred
‘How dare you, I am a professional!’ attitude.
What are the benefits?
- Less noise, less stop/start disruption
- Always release-ready
- Huge scope for improvement and learning through investigating root causes
An all-round more professional feel to your daily work and the end product
Give it a try and let me know if it works for you with the hashtag #0defects.