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:
Things to watch out for:
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.