␡
- 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
< Back
Page 12 of 12
This chapter is from the book
5.12 Summary of Actions
- Shift from activity-oriented organization to outcome-oriented cross-functional teams. They tend to be self-sufficient (autonomy) and business goal–directed (purpose).
- Communities of practice complement outcome-oriented organization. In the absence of a functional organization, they provide the necessary umbrella to nurture specialist competencies.
- If needed, divide work among multiple teams by splitting the outcome into suboutcomes (e.g., modules of an application or different applications) rather than activities (development, testing, etc.). The same applies for geographic distribution and outsourcing.
- Don’t encourage creation of shared services that service critical value streams. They tend to lose the sense of business purpose and this hurts responsiveness.
- Don’t commission separate teams for maintenance. It is an example of unnecessary handoff created by team design. Besides, rarely is anything in a pure maintenance mode. It always coexists with forward-looking development. A separate maintenance team is adinosaur in an age of continuous delivery and DevOps.
- Move away from an IT-B matrix to outcome-oriented teams aligned with business verticals.
< Back
Page 12 of 12