Zero Bug Tolerance: Improve software quality with one simple practice

zero bug tolerance

Did you ever work on a software project full of bugs? It’s a nightmare to go to current build of an app and see that many features just don’t work.

Or even worst: To see the things that used to work, but don’t work anymore?

How about a team that finds bugs and fixes them right away? One might not be that far from the other.

How to get to Zero Bug Tolerance

It’s an easy Kanban practice we use at EL Passion. Visualize your bugs on your Kanban board. Put them as a notes in different color (red or yellow to make them more visible). Always focus on fixing bugs before doing the tickets.

Zero Bug Tolerance: Improve software quality with one simple practice

Do this, don’t do that

  • Don’t store backlogs of bugs – they are the waste.
  • When will you fix the bug? Now or never! There is no later. Can you live with this bug forever? If not just fix it.
  • Don’t estimate the bugs. Use Planning Poker to estimate tickets, but not the bugs. Fixing bugs does not deliver value to the project. It is just fixing what the team did wrong in the past. Estimated bugs might disrupt your team velocity, creating an impression that team is delivering value.
  • Once you start, don’t stop. There might be a temptation to postpone bug fixing, cause there is  this super important feature to finish or release is coming. Don’t do that. Once you stop, bugs will stuck up and easy beautiful mechanism will stop working.

Why it works

  • Visualization: If you have a lot of bugs everyone can see them. You know something is wrong and you should take a closer look at the project to fix it. Making it visible makes it hard to deny the problem.
  • It helps to build a quality culture in the team. In introducing Zero bug tolerance you say NO to bugs and low quality software.

Zero bugs, Happy people

  • The team is happy to work on a project where quality is ranks high.
  • Customers are happy to use a working software. They know that if a bug is found – it will be fixed right away.

 

As most Kanban techniques this one is simple. Yet you might be surprised how it can increase quality and speed of work of your team.

More ideas about Zero Bug Tolerance? Let me know it the comments below.

CTO at EL Passion. Agile, Ruby on Rails, Bitcoins. Get in touch with Marek.

  • Krzysztof Niewiński

    Hi Marek,

    When you have to work on a “project full of bugs”, how do you deal with it using Scrum?
    Will you use Scrum in this situation actually?

    Let me explain:
    When you have many bugs to work on, you are not able to say how many Story Points will you take on the next sprint. If you decide to work on Bugs first and those bugs are not estimated, you are not able to predict when will you start working on a next Story. You just can’t say when will you fix those bugs, and how many Sprint will it take.
    So, you are forced to say to your PO (also stakeholders) that you will not deliver any new Story for some time. But for how long? Your answer is: “Until we fix the product”.

    What is the reason to use Scrum then? I see here some dysfunctions:
    – You can’t forecast what will you deliver on the next Sprint.
    – There’s a big chance, that even if you commit on something, you will not be able to fulfill this.
    – If you can’t take any new Story, what do you actually do on a Planning Meeting / Grooming / Review? There is nothing to show to your Stakeholders.
    – There is no Sprint plan (to deliver business value). Your plan is to finish your Bugs ASAP.
    – Working on a Bugs only seems to look as a product maintenance – not a product development.
    – These unpredictable work (Bugs!) may force you to abandon the Sprint
    – It also force you to collaborate more, re-planning often, be more flexible (ready to work on something outside of a Sprint Backlog like critical Bugs)

    Will you use Scrum to deal with it? I bet someone gonna say: “No, I will use Kanban instead”.

    So, where is the line to stop (or start) using Scrum?


    Cheers! ;)

    • Marek Kirejczyk

      1) Would I use Scrum [in such a project]?

      In general – yes. Of course everything depends on the context. But again in general – I perceive Scrum to be superior framework to not-a-framework Kanban. It encourages more [again in my humble opinion] to improve continuously, gives you better predictability, covers more of standard problems and has a bigger set of good practices to try out.

      2) Introduce the bugs to “project full of bugs”
      I believe a backlog of bugs is an indicator of what I call “management debt” (which is similar to technical debt, but not necessary a purely technical problem). Dealing with technical/management dept means a lot of work over time. Rather then adding more theory I would jump to example solution.

      What I would do:
      Split board horizontally in half. At the bottom I would have maintenance Kanban, at the top product scrum. In every sprint I would divide team differently (into maintenance and product team). I would spit bugs into two categories: “to fix soon” and “to fix never”. Fix soon I would prioritise to Kanban board. Fix never – I would forgot about them (forever or till it will be reported again). Iterate till bug amount is low enough to remove maintenance Kanban and put it on the Scrum board.

      Keep in mind:
      If you have technical debt, the stream of bugs might never stop. You have to work with your technical debt too.

    • http://fluidcircle.net/ Michał Parkoła

      Scrum is designed to solve complex problems. If you have *that* many bugs then you might think of the quality improvement as a complex problem in itself and make that the main focus.

      You can consider:

      * make sure fixing it has business value

      * decompose the whole mess into a backlog grouped by a) valueable functionality affected b) type of technical issue; just as you would new stuff,

      * have a PO to prioritise improvement efforts,

      * have a goal for each sprint, that will make *something* better in a customer-visible way,

      * have a Definition of Done that makes it more likely that when you’re “done” the bugs you just fixed will not multiply again the minute you turn your eyes away,

      * don’t dig in so deep that you forget what you are trying to accomplish beyond “fix the bugs”

      and last but not least:

      Don’t let it turn into a death march. At the end of each sprint stop, put away your tools, sweep the floor and go out to celebrate your progress ;-)

  • Bob Paige

    While I agree we should fix bugs, I have to disagree with you on a couple points.

    1. Who defines a bug?
    Bugs need to be defined by the process (acceptance criteria for a story fail) or the Product Owner. You can’t leave it up to the engineers.

    I’ve seen engineers who can *always* find fault with something (be it a bug or technical debt) and others who think *everything* is fine. It is like asking the fox to define security for the hen-house. Someone *outside* has to make the decision.

    2. When to fix a bug?
    I can identify 10’s of bugs in one of our products, misbehaviors that I feels should be fixed. But if fixing those bugs would take a significant amount of time *and* they would not impact users in the short term, why fix them now?

    That said, if it is convenient to fix a bug as part of some other development, or if fixing a bug becomes mandatory to implement/release some other work, it should be done.

    3. What is the cost?
    Not pointing bug fixes? Seriously? That opens you up to all kinds of ‘hidden’ work (work not reflected in your velocity) and will affect the predictability of the team.

    Sure, the bugs shouldn’t be there in the first place, but stuff happens and we should track the effort required.

    This leads me to one thing that has bothered me about Agile in my limited exposure to it: tracking actual effort vs. complexity. Suppose you assign 5 points to a story, but as you start work you realize it is more effort that expected. How do you account for that?
    – Dump this story and create another one? That disrupts the sprint.
    – Work on it anyway without changing the points? Overall velocity goes down because you can’t finish other stories
    – Change the story points? Maybe, if you drop other stories from the sprint to make up for it, but changing points on a story is not only against the rules, you may not know the actual cost until the work is completed.

    Is there some way to track actual effort compared to predicted effort (story points) so a team can improve *that* performance? I’d love to hear other people’s experience.

    • Marek Kirejczyk

      Ad 1.
      It is less important who is defining a bug, as long as there is no doubt whether “the thing” is the bug or not.

      Ad 2.
      When to fix: now or never. If you have a team of 3 developers and a backlog of 10 bugs, how long will it take to fix it? A day, two days? Not a big investment. If you thing it is not worth it – then the backlog will grow and you will most probably never fix the bugs anyway.

      Ad 3.
      What is the cost of producing a buggy software? Unhappy customers, high maintenance cost, low motivation of the team. The question should not be if you can afford zero bug tolerance – it should be “Can you afford not to have it?”

      About estimation and tracking:
      Never change estimations once the ticket is in progress (or in sprint backlog)! The whole idea is that you can predict velocity based on story point, because it accounts for hidden requirements, unexpected blockers, etc…
      Use retrospection to discover why ticket took, so long and figure out how to improve in the future.