Agile for maintenance projects

Posted on March 14th, 2008 in Agile, Methodology by siddharta || 7 Comments

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.

Doing Distributed Agile?

Share and collaborate with distributed teams with our electronic agile board tools. Get all the benefits of electronic tools without sacrificing the benefits of physical boards. Supports Scrum taskboards, Kanban boards and user story maps. Check it out!

7 Responses to “Agile for maintenance projects”

  1. C Greer Says:

    Cood high-level article! Not a lot of info around on how to tackle maintenance projects using Agile. This is a good start! I’d be interested in a deeper dive, as well.

  2. Agile Advice on maintenance projects, Yahoo India tries out Kanban » Blog Archive Says:

    […] on from my previous post on agile for maintenance projects, I came across this post on Mishkin’s Agile Advice (do subscribe to Agile Advice, it’s […]

  3. Franck Says:

    In addition to the problems you mention, there is another issue with agile maintenance. I think that one of the condition for iteration is knowing the “velocity”, that is the productivity rate of programmer. It is more difficult to determine how long it could take to solve a maintenance/bug on a system that sometimes you didn’t develop.

  4. siddharta Says:

    @Greer: Thanks!

    @Franck: Right, in a maintenance project, the concept of “Yesterday’s Weather” type of estimation doesn’t work very well. This is another area where a queue based process scores over an iteration based one.

  5. kapypant Says:

    very true that when you are dealing with maintanance project with very bad design and coding its a nightmare to dont know impact of fix.

  6. Joe Says:

    The selection of a methodology should be based on business risk as well as business needs.

    Agile may or may not be appropriate for some maintenance projects.

    From what I have seen written on the Internet, there is a push to force the fit into various efforts just because it is Agile and the adherents are “true believers.”

  7. Phu Says:

    Hi, my team has a probleme with bugs of closed project during the period of new project.
    We dont really divide a projet team or maintenance team. What should we do if there are these bugs of an closed project when we’re in a Sprint of a present project.

Leave a Reply