Agile maintenance in a devops world

"What is an agile way of doing maintenance projects?", is a common question. An answer like the following is par for the course:
"It isn't very different from development projects. Write tests to reproduce bugs before you fix them. Treat enhancements as one or more stories. Keep the CI server running. Make sure that changes are occasionally merged from the maintenance branch into trunk. Pairing is probably not as important."

In the context of this post, a 'maintenance' project is one where a client outsources ongoing bug-fixes and enhancements for a live application to an IT vendor (often offshore). Conventional wisdom has it that development is investment (capex) and maintenance is cost (opex). Hence, clients look for much lower billing rates when it comes to maintenance. This results in separate contracts/teams/vendors for development and maintenance. Some clients go a step further and outsource even IT operations to a different team/vendor under a separate contract. The rationale is to stick to core 'business competency' and outsource everything else (let them vendors compete with each other for our slice of IT).

Depending on how critical the said application is for revenue generation, this strategy of 'divide-and-conquer-IT' can be frustrating at best and suicidal at worst. The best of the businesses that make most of their money off their websites outsource little to none of their IT. This is simply because you cannot go to market fast enough if you have to orchestrate between three teams/vendors for every new feature. Equally importantly, the feedback loop gets badly constricted at contractual boundaries. Designing formal, SLA driven protocols of communication between business, development, operations and maintenance is a recipe for bureaucracy and indifference.

Not everyone can afford not to outsource. It is very difficult to put a good IT team in place. A lot of outsourcing has been a reaction to uncooperative in-house IT. But the solution has gone overboard in trying to compartmentalize development, operations and maintenance. You don't want to be overly reliant on a single vendor? Fair enough, consider outsourcing product A to vendor X, B to vendor Y and C to vendor Z. This is better than outsourcing the development of A, B, C to vendor X, operations to vendor Y and maintenance to vendor Z. The latter model requires well defined, stable interfaces between different constituencies. Not suitable where business is changing every week. It is a repeat of the layered-team anti-pattern at a higher level.

What if we want to deliver a grand SOA? Once the team of architects have specified every service, surely it should be possible to outsource a bunch of services to different vendors and the consuming applications to yet others. Splitting up integration work is extremely risky, in my opinion. Service contracts are rarely cast in stone. On the contrary, if you like the idea of evolutionary, guerrilla SOA, you no longer plan to have stable interfaces - the service evolves in tandem with the needs of its consumers. So, try to give all integration work and important applications to your primary vendor. Better yet, don't do big bang top down integration. Evolve bottom up.

On the other hand, it may be that your business doesn't change that often or your application doesn't generate revenue. If so, it is useful to ask "Why build? Why not buy?" every once in a while. SaaS is growing fast. It is likely that someone is offering your bespoke application as a service. At the cost of some tweaks to your business process, you might end up with a better application at lower cost. The SaaS vendor in turn is likely running a full in-house IT.

The world has changed yet again. Devops is gaining currency. These days, a common way of testing the uptake of new features is to divert, say 5% of your traffic to a new deployment and see how it goes. A separate maintenance team is a dinosaur in an age of frequent deployment (blue-green or otherwise) and continuous delivery.

Q. What is an agile way of doing maintenance projects?
A. Don't do maintenance as a separate project.

There is one situation where a maintenance project might make sense. End-of-life support. Basically, you pay for a team to keep an old app running while a new replacement gets built. Other than that, it is all about breaking down silos.

Of course, you will never hear Indian IT majors singing this tune. Their recruitment and business model is based on economies of scale. 'Changing businesses' are anathema to their ossified processes. However, in response to changing realities of the marketplace, some of them have begun to sing an agile tune. Some of them even claim to have proprietary, hybrid, high-performance methodologies that "synergize best of breed practices from CMMi, ISO, Six Sigma and Scrum". I'll explore a certain aspect of this 'synergy' in my next post.