Agile Methods for the Support Teqam

Disclaimer: I was working with a team that did much of a maintenance, but never was on the team that was fully focused on the maintenance. Therefore things below are less of y personal experience and more of what I've heard from other people and read in articles and books.

The major point of agile [from the management level] is the ability to develop things in a relatively short increments of software that is fully DONE, so that every iteration there was a possibility to ship product (or at least say that it is releasable within a month) and/or adjust the product course in the direction market requirements are moving to. It requires freezing the requirements for the direction though.

When you are fully focused on maintenance such a requirements freeze might not be possible even for a couple of weeks. Things that people find useful in such circumstances are:
- Extremely short iterations.
E.g. in a circumstance when business leaders had big problems with the temporary requirement freeze Industrial Logic was successfully utilizing as short iterations as 3 day long ones.
- Ticket/issue oriented development.
If your support requests are flying in an unpredictable and random manner and with the unpredictable priority, you might like to go without iterations and focus on issue-by-issue development
- High emphasis on the built-in quality, continues integration and ubiquitous automation.
Agile methods in general advocate continuous and automated verification of everything. If you decide to go for extremely short iterations or iterationless development, you'd better place even higher emphasis on building the quality in. When fixing yet another support requests, it has to be easy to run the extensive test suite and make sure that nothing has been broken accidentally
- Retrospectives. With iterationless development it might be tempting to forget about the dedicated process improvement points. You might indeed not want to spend half a day retrospecting after every 3-day iteration, but it might be possible to still have major discussions every 2 or 4 weeks.

I guess in the end it all boils down to encouraging the team to think about the *whole* cycle and optimize not for the speed of the current request processing, but for the speed of an average ticket processing and even for decreasing the average number of tickets per month.