OK so you’ve seen the Google Ken Schwaber videos on http://video.google.com/videoplay?docid=-7230144396191025011 and you’ve sent your program managers and dev managers off to scrum training. And your whole team is full of enthusiasm for the new processes.

And they make a lot of sense. Taking a chunk of functionality and getting it to the point where it could actually go out the door is a good idea. Adding lots of half baked features just to show progress and then bug fixing in a death march for months or years is no-ones idea of fun.

So you vow that from now on features will not be released until they’re done, done and done. Technical debt will be a thing of the past.

But, there’s always a ‘but’. What about all that code you already have in your enterprise application. You’ve got –lets say– ten million lines of code developed over ten years. The quality of that code will likely be highly variable, depending on which developers coded it, who QA’d it, and what management pressure the team were under at the time.

You will in all likelihood have a bug list as long as your arm. There will also be customer and management escalations to deal with, if you haven’t got a good solid sustained engineering team covering your back (as I was). In fact if you’re strapped for resources your ability to get new functionality to market is probably groaning under the weight of just supporting what you have already.

The thing is, dealing with bugs is not something I’ve seen addressed in Agile/Scrum. Possibly because training and books seem to focus on small new development projects that don’t have this problem.

The first thing you need to do is get agreement from the product owners how much new development, vs technical dept, vs bug fixing you need to do. These will not be easy conversations. But if you focus on the customer benefits you should be able to come to an agreement on what percentage of your teams should be fixing bugs.

Second you should add bug fix items to the backlog, giving each one enough story points to be consumed by one team for one sprint. It’s important that these items are visible to everyone.

Thirdly you should schedule each of your sprint teams for a bug fix sprint on as fair a rotational basis as your critical path analysis will let you. Spread them out over your whole release cycle and if you have enough teams you should aim to always have one team on this duty at all times.

What you get from this approach:

• You’ve always got a go to team for escalations that you can hit up without frustrating them, or having them lose momentum on a feature.
• Having teams do nothing but bug fixing for two or three weeks give you good data on their fix rates.
• Once you have data you can predict ahead of time how many bugs your team will fix for a given level of resourcing. This will be invaluable when it comes to producing service packs. You will be able to use hard numbers when having conversations planning releases and how many bugs the business gets for what level of resourcing.
• Your teams are going to be a lot happier to do a bug fix sprint if it’s only every three or four sprints.

Things to watch out for:

• Don’t let your teams fall back into old habits. They should be fixing bugs that come up in sprints within that sprint, they should not be knowingly contributing to a net increase in bugs as features are implemented. Make one of your ““Done, Done and Done”” criteria a metric based off your bug tracking system and use that same system to track all sprint bugs.
• The bug fix sprints in the backlog will be the first in the firing line when a new feature has to be added to a release. You will just have to fight for these if you think it’s warranted. One thing that may help is putting a focus on the bug fix sprints e.g. performance or reliability. Choose areas that are known customer pain points for your sprints and you’ll get better buy in.
• Resist the urge to pick up a couple of extra ““bits and pieces”” in a bug fix sprint. It will dirty your metrics, and they team will work better if they’re all working on bugs together.
• Don’t over plan the bug fix sprints, and don’t make the team’s commit to a specific number of bugs. Make the team’s total (not individuals) part of the handover and openly discuss the count and how they compare to your other teams. That will generally be enough to spur them on to doing their best especially when they know that they (the team) is being compared against their peer teams.

Bug fixing is not one of the most pleasant aspects of software development. But when I implemented the above approach it became less of a thorn in my side. Sure, the teams didn’t love it when they were doing it, but once they’d got a couple of completely interruption free feature sprints they understood the value of it. And they loved the ten minutes planning meeting for those sprints.

It was good to have a team I could hit hit up for any escalations without the guilt of pulling them off a task. Plus, giving each dev in your org the opportunity to help their director out personally at some point, and getting the opportunity to personally and genuinely thank them for it has a value to morale that is incalculable.