Home > Articles > Software Development & Management > Agile

  • Print
  • + Share This
This chapter is from the book

5.8 Maintenance Teams

Cross-functional product teams own their product—they shape it, build it, maintain it, and run it. However, many organizations retain separate teams for maintenance (bug fixes and minor enhancements) and IT operations.

Figure 5-4 shows a traditional cycle. Maintenance and IT operations work on what is released while development works on the next release. To cater to users who cannot upgrade to newer releases promptly, there is usually a support window of current minus N releases (N 5 1 in Figure 5-4).

Figure 5-4

Figure 5-4 Typical software release cycle

There is common but flawed notion in enterprise IT circles that maintenance work requires less skill than full-scale development. As a result, project sponsors looking to reduce cost opt for a different team of lower-cost people for maintenance work. This is false economy. It hurts the larger business outcome and reduces IT agility. When the same product team does development and maintenance, there is no handoff at release time. It is easier to merge bug fixes from release branch to trunk because the team is familiar with the ongoing changes in trunk. What’s more, trunk-based development22—a branchless technique that is gaining adoption—is nearly impossible with separate development and maintenance teams.

End-of-life support is one situation where a maintenance team might make sense. This team keeps an old app/product running while a new replacement is built. Other than that, it is all about tearing down potential silos such as separate maintenance teams. Even in case of end-of-life support, a capability-oriented IT organization may choose to have the old and new coexist in a single capability team (Section 8.2). A separate maintenance team is a dinosaur in an age of continuous delivery and DevOps.

  • + Share This
  • 🔖 Save To Your Account