Tips for Team Design in Agile IT Organizations
- 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
The first four chapters were short and introductory. The water gets deeper from here on. This chapter describes how various multiteam configurations, including the matrix organization, reduce organizational agility and how having fewer outcome-oriented, cross-functional teams can help. It explains why activity-oriented teams cannot work with small batch sizes required for lower cycle time. It covers why testing and maintenance are not separate activities and how certain configurations of outsourcing work better than others do. In terms of the key themes laid out in Chapter 3, the discussion in this chapter expands on organizing for responsiveness over cost-efficiency.
5.1 Framing the Problem
Why do business-IT organizations end up in situations where multiple teams are collectively responsible for a single business outcome? Here are some typical reasons:
- The scale of the problem is such that a single team would be unwieldy.
- Organizational boundaries
- Functional (activity-oriented teams)
- Regional (distributed teams)
- Business (product teams)
- Contractual (e.g., outsourcing)
- Shared support services (e.g., IT helpdesk, product support)
Whatever the reason for multiple teams serving a single outcome, once they are in place; it reduces the effectiveness with which the larger outcome may be realized. Why? Because collaboration within a team can be continuous, but collaboration between teams is always discontinuous (discrete). Meetings, for instance, are a great indicator of discontinuous collaboration. Continuous delivery needs continuous (and unscripted) collaboration. Effective collaboration on any given task between two individuals X and Y on two different teams depends on the following:
- Their individual dispositions to collaborate
- Their history of working together (relationship)
- The prevailing interteam communication protocol
- Whether the task has the same level of importance and urgency for both teams
The last two points can be affected by organization design. Can two individuals, X and Y, simply meet with each other, agree on what is required, and go back and do the work? Do they have to involve their respective managers in the process? Do the managers have to sanction the time for it? Does it all have to be via some system of record? The more process and indirection there is, the greater the friction for effective collaboration.
By contrast, people within a team don’t have to schedule meetings to collaborate with each other. They collaborate continuously and get into huddles (informal, ad hoc meetings—virtual or face to face) on demand. But given that multiple teams are unavoidable and that it reduces effectiveness, how can we design teams so that the most important outcomes are affected the least? This is the basis for the rest of our discussion in this chapter.