How do you apply Scrum to maintenance and legacy code improvements? [closed]

Question

As the title suggest... How can I apply a scrum process to anything that doesn't work on new code and can be estimated to some degree?

How can I apply a scrum process to maintenance and emergency fixes (which can take from 5 minutes to 2 weeks to fix) type of environment when I still would like to plan to do things?

Basically, how do I overcome unplanned tasks and tasks that are very difficult to estimate with the scrum process? or am I simply applying the wrong process for this enviroment?

Answer 1

Basically, how do I overcome unplanned tasks and tasks that are very difficult to estimate with the scrum process? or am I simply applying the wrong process for this enviroment?

You're using the wrong process for this environment. What you need is a stack/queue management process which is separate to your planned/estimated SCRUM development process.

The reason for this is simple and twofold:

1. As you mention in your post, it is often very difficult to estimate maintenance tasks, especially where legacy systems are involved. Maintenance tasks in general and legacy systems specifically have a tendency to involve 'curly' problems, or have a long 'tail', where one seemingly simple fix requires a slightly more difficult change to another component, which in turn requires an overhaul of the operation of some subsystem, which in turn... you get the point.

2. Quite often when dealing with maintenance tasks, by the time you have finished estimating, you have also finished solving the problem. This makes the process of estimation redundant as a planning tool. Those who insist on dividing estimation from solving the problem for maintenance tasks are simply adding unnecessary overhead.

Put simply, you need a queueing system. It will have these components:

• A 'pool' of tasks which have been identified as requiring attention. Newly raised items should always go into the pool, never the queue.
• A process of moving these tasks out of the pool and onto the queue. Usually a combination of business/technical knowledge is required.
• A queue of tasks which are clearly ordered such that developers responsible for servicing the queue can simply pick from the front of it.
• A method for moving items around in the queue (re-prioritising). To allow 'jumping the queue' for critical/emergency items.
• A method for delivering the completed items which does not interrupt servicing the queue. This is important because the overhead of delivering maintenance items is usually significantly lower than development work. You don't want your maintenance team sitting around for a day waiting for the build and test teams to give them the ok each time they deliver a bugfix.

There are other nuances to queue management, but getting these in place should set you on the right path.

Answer 2

If you have that much churn in your environment, then your key is going to be shorter iterations. I've heard of teams doing daily iterations. You can also move towards a Kanban type style where you have a queue which has a fixed limit (usually very low, like 2 or 3 items) and no more items can be added until those are done.

What I'd do is try out one week iterations with the daily stand-ups, backlog prioritization, and "done, done". Then reevaluate after 5 or 6 weeks to see what could be improved. Don't be afraid to try the process as is - and don't be afraid to tweak it to your environment once you've tried it.

There was also a PDF called Agile for Support and Operations in 5 minutes that was recently posted to the Scrum Development list on Yahoo!