Do Agile Teams Need Maintenance Organizations?
I’ve been helping some clients grapple with the role of the maintenance team in Agile-IID. I’m finding it a very fascinating topic, because it is allowing me to challenge many of my deeply held beliefs about creating effective software. To help me consider this topic better I thought I’d blog about it.
My experience with maintenance teams started in the early 90’s when I was asked to turn-around a pretty dysfunctional development organization at EDS. One of the problems was that there was no organizational distinction between the different kinds of development. Each developer was given the (dreaded) pager: when it went off, it meant that a problem was being escalated from support into development. Developers were expected to stop working on their task and solve the problem. If they didn’t get it done both the pager and the problem were given to the next sucker (er, I mean, developer) the next week.
Pretty easy to imagine what happened. Ignore the pager for as long as possible. Miss your schedule commitments because you can’t project how much time you have dedicated for the new code. Ignore the problem and make the fastest patch possible so that you can get back to your new code. If you can’t fix it, wait—the next sucker will have to fix it.
To resolve the problem I reorganized the team into a group of new code developers and maintenance developers. Now, don’t tell me that I had created different classes of programmers, or that really great programmers don’t want to do maintenance. That’s bunk. Some of the best developers I had volunteered for the team, because they knew that maintenance wasn’t about lesser work—it was about different work.
Indeed, for me, maintenance is central to realizing agility in dealing with customers. Instead of framing the problem in terms of the kind of work, I think of maintenance as the kind of response I want to provide to customers. Typically, major product releases enterprise software occur every 9 – 15 months (for customer hosted models—SaaS changes the game, as I’ll explain later). Customers, however, often need genuine modifications sooner than this. A maintenance team allows an organization to be more responsive—more agile—to the legitimate requests that customers make (bug fix requests, enhancement requests, and so forth).
Perhaps more importantly, the maintenance team “shields” the new development team so that they can focus on new development. This allows the new development team to make more accurate scheduling predictions and to tackle those tasks that can’t be done in a single iteration (e.g., like a major architectural change).
There are other reasons why a maintenance team helps an organization be more agile. Sales, legal, marketing, support, QA, professional services, and operations are engaged very diffently for a “patch” release than a full release. If every release is a full release, the product organization will become burdened with far too much busy work. Patch releases created by the maintenance team are usually distributed to customers with far less overhead. This is by design, and the design works.
These are among reasons I continue to believe that a separate maintenance team is an essential part of the mature software organization. That said, there are several things that are challenging this assumption.
The first is the rise of continued rise of agile methods. My own perspective is that the backlog is the sum total of work that needs to be done for a product. From features to bugs that you want fixed, the backlog contains everything. You could argue that in a well functioning agile team
SaaS models. In these models, it is easier to collapse maintenance and new development activities into one organization,
August 19th, 2009 at 19 Aug 2009
The answer depends on the size of the body of accumulated work compared to the size of the development organization. Our company has a fairly unique and long-standing “SaaS before ‘SaaS’” structure. We built software, it worked, we built more software, it also worked. We had the “engineers rotate pager duty” method of operational support for many years. That ended abruptly after a significant incident a few years back. Many people burned much midnight oil to get critical systems back online.
ITIL was implemented as a result to establish order in the operational space and ensure stability of our services. (And that precious focus was returned to our development teams.) We also realized that we had more “products” and software items than we have Product Owners or Software Architects. And of course, documentation was rare. A “maintenance”/lifecycle/firefighting group of engineers was formed to address bugs, breakdowns and backlogs that were not part of a prepared “project” or were not planned for. (An MS patch to IE breaks critical functionality in a web-based product that does not have active development or a Product Owner… “firefighter developers” to the rescue!)
One point of uneasiness now is with the agile manifesto’s de-emphisis of documentation. Documentation is a lifeline for knowledge transfer between development and “maintenance” groups, a key component of ITIL’s Service Transition book. For businesses that operate and host SaaS that are critical to customers, the question is not “Are maintenance teams needed?” but “How can Agile engage with and support the mission of operational teams?” Specifically for me, that challenge is in reconciling and integrating Agile development principles with ITIL operational best practices.