- 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.6 Migrating to Cross-functional Teams
It is quite disruptive to move from an IT-B matrix organization (or other functional organization) to self-sufficient, cross-functional teams. Here is one method of doing it gradually:
- Identify products/capabilities that differentiate the business. You will need as many cross-functional teams as the number of differentiating business products/capabilities.
- Identify a product/capability for piloting the transition. Ideally, the candidate won’t have too many dependencies with other products/capabilities. Make sure there is a full-time outcome owner (Section 4.1.2) available.
- Have the product owner come up with an initial product roadmap and backlog.
- Identify people from existing activity teams that will make up the pilot team. Explain to them the rationale for the pilot. Use the penny game19 to drive home how small batches and inexpensive handoffs help reduce cycle time.
- Make sure the pilot team has all the skills required to be self-sufficient.
- Let the new team start working through the backlog.
- See how it goes for about three months before deciding to spin up another cross-functional team.
This only addresses the structural aspects of migration. Operational, cultural, and political aspects are addressed in the following chapters.
5.6.1 Separation of Duties
Sometimes, IT governance people say that cross-functional teams are not permitted by accounting and investor protection regulations such as SOX and payment regulations such as Payment Card Industry Data Security Standard (PCI-DSS). In particular, they speak of a control called separation of duties.20 In effect, it aims to separate authorization for making changes to an application/system from authorization to release those changes into production. Traditionally, this hasn’t been a problem because the production deployment team was different from the development team. However, even if separation of duties requires that the same person not have both authorizations, it does not prohibit two people with the combination of authorizations from working together on the same team.21