Matt Archer's Blog

  • LinkedIn

  • Twitter

  • Twitter Updates

  • New Book

    I'm working on a new book. View the home page for the 'Tips for manual testers working in an agile environment' book
  • Enter your email address to receive notifications of new posts by email.

  • Subscribe

Why agile software teams should fix bugs ASAP

Posted by Matt Archer on February 8, 2012

Recently I’ve been working with Andy Glover (a.k.a. the Cartoon Tester) on an article for the Testing Planet. It’s on a topic that affects us all regardless of the software development process we follow (Waterfall, RUP, XP, Scrum or some other flavour of Agile). That topic is the existence of bugs within the software we are developing and the many consequences brought about by not fixing bugs as soon as they are discovered. 10 consequences are discussed in total, but not wanting to give too much away, I’ll leave you with a brief extract to whet your appetite.

“If a bug is left to fester in the software you are developing, configuring or maintaining it may camouflage other bugs, demotivate the team by suggesting quality isn’t important, become the topic of pointless conversations, cause duplicate effort, lead to incorrect project metrics, distract the project team, hinder short-notice releases, invalidate estimates and lead to unnecessary frustration. And the longer you leave a bug before fixing it, the more likely these things are to occur and to a greater extent.”

The next edition of the Testing Planet is due out in March, but you can pre-order your copy now. Past editions are also available to view online.

[Update: 09-02-2012] I have added the picture below in response to Joe Strazzere’s comment.  His ideas are unlikely to make it into the final version, but he makes a noteworthy comment that is worth expanding on here (see also my comment response below).

3 Responses to “Why agile software teams should fix bugs ASAP”

  1. As you discuss the Pros associated with fixing bugs as soon as possible, I hope you’ll also discuss the Cons.
    And I’m hoping you also discuss what “as soon as possible” means here.

    My basic concerns are around having developers interrupted (perhaps often) while working on developing a feature. Interruptions are never without cost or consequences.

    • Hi Joe,

      I must confess that it is a one-sided look at the problems caused by leaving bugs unfixed, but I appreciate your point of view. If I understand your concern correctly, I agree with you when you suggest that if “ASAP” is taken to mean “Mr/Mrs developer, fix this bug now!” then this has its own set of consequences which need to be considered.

      I say considered rather than avoided because some bugs need to be fixed immediately (not after a cup of coffee, or an hour later, or a day later, but immediately). That said; I see this treatment of bugs as being the exception rather than the rule for most projects. Similarly, I would suggest that leaving a bug unfixed for several days should be the exception rather than the rule too.

      Of course, the upper and lower exceptions I’ve suggested are extremely context dependent. If a team is rapidly sprinting (as in Scrum) then an entire Sprint may only be 5 days in length. Conversely, I have worked with programmes where 5 days is tiny in comparison to the overall schedule. In either case, using several days as an example of an upper exception may not be appropriate. Many other factors (not just the project schedule) will have an affect too.

      When I say things like “fix bugs ASAP” or “fix bugs as soon as you find them”, the caveat (which potentially I should communicate more explicitly) is that this should be done in a way that is amenable to the whole team.

      It’s a bit of a cliché, but I believe that every team needs to agree what “ASAP” means to them – their sweet spot. I’ve attached a picture to the original post above. When I say “ASAP”, I’m thinking about the point where the line in the chart dips to its lowest point. Not too soon that fixing a bug causes problems in its own right, but quickly enough to avoid the majority of problems caused by leaving the bug unfixed for an extended period of time.

      The scale of the chart will vary from team to team, but note that I have deliberately drawn the right-hand tail for a longer period and to a greater magnitude in comparison to the tail on the left. This is because whilst fixing a bug too soon can cause its own set of problems (like those you hinted at above), I believe these can easily be dwarfed by the problems caused by leaving a bug unfixed for an extended period of time.

      In terms of sharing my own experiences of fixing bugs ASAP, I’ll write a separate post in which I’ll describe what I refer to as a “bug lucky dip”. It’s not a complicated idea and arguably it’s more suited to agile teams, but it’s worked well for me in the past and can also be quite fun! I’ll repost as soon as I can.

  2. […] bugs is just putting off work until a later date (and everyone does that, right?), but as my recent article for The Testing Planet highlights, delaying the fixing of bugs has several negative effects of the […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s