␡
- 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
This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter is from the book
5.11 Summary of Insights
- Collaboration within teams tends to be unscripted—on demand, just in time, and continuous. Collaboration across teams tends to be discontinuous and discrete (e.g., via meetings). This can be factored into team design by locating all roles that require continuous collaboration within a single team.
- Handoffs are mostly a result of specialization. Organization design cannot reduce these handoffs, but it can make them faster and cheaper by making them occur inside a single team.
- The biggest promise of continuous delivery is a reduction in IT delivery cycle time. It requires the delivery value stream to process work in small batches, which ultimately calls for a single team (or as few as possible) responsible for the whole value stream.
- A cross-functional team consists of people with different primary skills working toward a common goal. They are an example of valuing responsiveness over cost-efficiency.
- Cross-functional teams aren’t anti-specialization. Specialization isn’t the problem; organizing along lines of specialization is.
- It is okay to have activity-oriented teams for activities that aren’t an integral part of a business outcome’s core value stream.
- Release interval is not the same as cycle time. Monthly releases imply a minimum cycle time of a month, very likely much higher.
- Given that IT is itself a “function,” an IT-matrix represents a functional organization within a functional organization—a near guarantee of pain.