Maintenance victims - Handling maintenance the Agile way

May 2, 2008 by Artem Marchenko

Bugs used to be something very distracting and unpleasant for the software developers. For management they can be even worth - the effort and time bugs need to be fixed is poorly estimatable. Sometimes these number are complete question marks. This predictability drop is one of the reasons why agile methods advocate striving for bug-free development as possible

Scrum teams don't like bugs just as any other teams. There are multiple approaches to handle bugs from entering into the product backlog and making them wait until the end of the sprint to allocating some "maintenance slots" in the sprint to a more-or-less expected amount of maintenance. The sad truth is in that amount of bugs discovered and amount of time needed to fix them is often not predictable even roughly. Especially for teams that are not yet used to deliver the tested features.

Maintenance victim

One approach that some teams find useful is to allocate a maintenance sub-team or a single maintenance person also known as a maintenance victim. This role is typically rotating every sprint and is usually taken on a voluntary basis. When such a team exists, bugs usually don't clutter the product backlog and are maintained in a separate list. During sprint a maintenance sub-team is responsible for doing all the bug fixing so that it wouldn't distract the other team members and would allow them to concentrate on creating new features. The maintenance people are not isolated. They still come to the daily standups, tell about their impediments and can get help from the other team members. At times of unusually high error rates the maintenance team can grow up to the whole Scrum team size.

Pros and Cons

Pros

• Team does not get distracted whenever a new urgent bug comes in.
• There is no or little conflict with the Product Owner or customers not wanting to wait until the end of the sprint for fixing that critical issue.
• Most of the team members periodically get chance to experience the full maintenance pain. It helps them to understand what is difficult to maintain in the code and refresh the maintainability coding guidelines.
• Some teams like the variety provided by the possibility for doing maintenance "sometimes". See also the summary below.

Cons

• For the teams of the highly specialized individuals it might be so that most of the bugs have to be fixed by a concrete person. If this person is not on the maintenance team this time, it might be difficult to cope with the issue even if this person does provide some help.
• Since bugs are handled out of the sprint, possibly even out of the product backlog without the estimations, it might be not too easy to see how much effort is actually going to the bug fixing.

Summary

I know several teams, where people originally didn't like this practice, but then started lining up to the maintenance role. The reason is that in their situation maintenance started looking as a way to sometimes take a rest from the routine of sprint cycles.

Did you ever try such an approach? Can it work for your team? Are there any arguments missing?

Photo courtesy of Ange Soleli @ Flickr

Permalink