- 5.1 Framing the Problem
- 5.2 Activity-oriented Teams
- 5.3 Shared Services
- 5.4 Cross-functional Teams
- 5.5 Cross-functionality in Other Domains
- 5.6 Migrating to Cross-functional Teams
- 5.7 Communities of Practice
- 5.8 Maintenance Teams
- 5.9 Outsourcing
- 5.10 The Matrix: Solve It or Dissolve It
- 5.11 Summary of Insights
- 5.12 Summary of Actions
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 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.