In the previous post I wrote that Sanjiv Augustine was giving a talk in Chennai. After the talk we had a discussion about implementing Agile in maintenance projects. This is one of those topics that is not discussed very often, but it’s a topic that crops up very often in an Indian context where many teams are working on offshore maintenance projects.
There are two types of maintenance projects that are commonly encountered. One is when you have a bunch of feature enhancements to an existing project. The second is when you get bug reports from the field that are fixed as they arrive.
The first type is quite straightforward to handle — just prioritize your feature request list and handle like a normal agile project.
The second type is a lot more tricky because you are fixing bugs as they arrive. This means that there is no backlog as such. Rather, bugs are worked on as they arrive in a first-come first-served manner. Sometimes you might have a few bug reports come in simultaneously in which case some basic prioritisation is done, but on the whole it is mostly first-come first-served. What is more, there is no specific “release,” but bugs are fixed and then immediately pushed into production.
It is this second type of project that I want to discuss in this post, because my experience has been that iterations are really ill-suited for this sort of development. The problem with iterations is that you need a definite start date and end date, but it doesn’t make sense to wait and collect bug reports, then plan it out and release them all at once at the end of the iteration. It would be much better if you could work on bug reports as they come in, using some sort of queue.
Naturally, the first thing that comes to mind is David Anderson’s Kanban based method which is based on queues and flow rather than iterations. This seems to be ideally suited to the variable input rate that occurs in bug fixing. One caution is that applying this method requires a good understanding of lean and a mature team and is definitely on the “Ri” end of the “Shu-Ha-Ri” scale. If you are interested, Sajiv has links to a talk that David gave at Yahoo! a few months ago.
Another option that Sanjiv mentioned was doing extremely short iterations. By extremely short, I don’t mean 1 week iterations, but more like 1 day iterations(!). The basic idea is that each day you look at the bug reports available, select some to implement that day, then code, test, integrate within the same day. Repeat every day. Some teams do 2 day iterations instead of 1 day iterations, but the idea is the same - plan, implement and integrate over a very short time frame. This may be easier to implement for those who are familiar with Scrum because the basic principles still apply, though over a very, very short time frame. Given the huge popularity of Certified Scrum Master courses and the subsequent familiarity with Scrum, it might be easier for a new ScrumMaster to go this route.
Another challenge with maintenance projects is that you are often not dealing with your own code. You might be working with some messy legacy code with bad design, no unit tests and so on. What do you do then? All I can say at the moment is to check out Michael Feather’s excellent book, “Working Effectively With Legacy Code“. It’s a must read book for anyone doing agile, maintenance or otherwise.
