- 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
5.4 Cross-functional Teams
A cross-functional team (also called multifunctional, poly-skilled, or interdisciplinary) is one whose members belong to different specializations and work together toward a common outcome. They are a necessary consequence of organizing for business outcomes rather than activities. The realization of any outcome is bound to involve many different activities. This calls for people with widely different skills to be part of the same team. For example, a cross--functional product team may consist of people with all the skills listed in Section 5.2.
The top half of Figure 5-2 shows a conventional stratified IT organization. The product owner is quite removed from daily development. The term development team is only applied to a minimally cross-functional team of developers, testers, database, and UX people. Sometimes it is worse—development team just refers to developers. In either case, the team is not equipped to own a business outcome.
)
Figure 5-2 Moving from a stratified setup to a cross-functional setup
The lower half of the figure depicts what it would take to own an outcome. The inner box represents a well-equipped cross-functional product development team. Architects, business analysts, deployment engineers, and product owners join the team. Some parts of IT operations, marketing, and sales are also folded in. For example, Operations-A provide a virtualized platform that Operations-B uses for test and production deployments. Field sales and inside sales (Sales-A) may sit outside, but sales engineers (pre-sales) could very well be part of the team. Similarly advertising, SEO, promotions, and pricing (Marketing-A) may sit outside, but social media and content (Marketing-B) would do well to be part of the team.
Cross-functional teams aren’t a new idea. Only the proposed extent of cross-functionality is new. Agile software development teams have always been cross-functional with respect to architects, analysts, developers, and testers. With DevOps, cross-functionality expands to include deployment and some IT operations people. At this point, the cross-functional team is capable of agility in delivery. For full IT and business agility, the circle needs to expand further to include dedicated product owners, UX people, sales, marketing, and support.
5.4.1 DevOps = Cross-functional Dev + IT Ops Team
The DevOps movement advocates a merger of development and related IT operations. It makes a team cross-functional with respect to development and IT operations. Unfortunately, this aspect is often ignored in comparison with the technical aspects of DevOps. From an IT point of view, we broadly have three departments in a typical setup—business, development, and IT operations. There may be many more subdepartments, but this picture is enough to understand what DevOps is not.
In a typical case, once the VP of IT operations is convinced about DevOps, she decides that her team should now acquire so called DevOps capability. Accordingly, they evaluate and buy some product claiming to be a DevOps enabler, do a bit of research on virtualization and infrastructure automation tools, start version controlling their deployment scripts, and then rename their department to DevOps. Is it really DevOps? Well, it isn’t DevOps if you don’t have IT operations people as part of your development organization. The whole point of DevOps is to locate development and operations skills within a single team. The VP of IT operations is not to blame though. Effecting a DevOps reorg is usually beyond her pay grade and fraught with implications for her future role.
5.4.2 Organizing for Responsiveness
Cross-functional teams fold the entire software delivery value stream into a single team rather than let it span across multiple activity-oriented teams. This reduces the cost of handoffs, allows reduction in batch size, and thereby decreases cycle time (improving responsiveness). Cross-functional teams aligned to outcomes can get meaningful things done within the bounds of the team. In this respect, they are much more autonomous units than activity-oriented teams. They are also more fun to be since autonomy is an intrinsic motivator.
Cross-functional teams aren’t anti-specialization. These teams still consist of specialists. Specialization isn’t the problem; organizing along the lines of specialization is. Functional organization makes for slower and more expensive handoffs.
5.4.3 Utilization
Will specialists dedicated to product teams be underutilized? Probably yes. This is where the rubber meets the road in terms of trading off cost-efficiency for the sake of responsiveness. Beyond a certain threshold of utilization, responsiveness decreases as utilization increases. This is a well-known effect from queuing theory. Without some slack, we can’t have responsiveness. A fully utilized highway is a parking lot.11
Besides, as a side effect of being part of a cross-functional team, specialists usually start to acquire adjacent skills. So developers pick up infrastructure skills while product analysts pick up testing skills. This lets them contribute to adjacent areas during lean intervals and jump back to core areas as soon as something comes up. Pure specialists start morphing into generalizing specialists.12 Their skill profile changes shape from the letter I (all depth) to the letter T (some breadth).
5.4.4 T-shaped People
Pure specialists are all depth and very little breadth. Although they may be brought together in a cross-functional team, they might face challenges in interacting with their team members from other specializations. For effective cross-functional collaboration, we need some breadth as well as good depth. Breadth provides perspective and empathy. Hard-core specialists are susceptible to caring only about their part of the work. T-shaped people13 can relate to and build upon ideas coming from outside their domain with greater ease.
5.4.5 Team Size
Common recommendations for development team size range from three to nine.14,15 Another idea called the two-pizza team (number of people that two pizzas will suffice for) comes from Amazon. As long as the architecture is modular (via services or otherwise), these are reasonable heuristics for team size of a single module or service. However, highly cross-functional, outcome-oriented teams, as in Figure 5-2, are likely to be much bigger if the outcome (or suboutcome) requires it. It doesn’t mean humungous standup meetings or that everyone communicates regularly with each other. The cause of responsiveness is served by having a single, dedicated outcome owner for the whole team of teams. The cause of autonomy and purpose is served by having a team big and capable enough to own a business outcome (or suboutcome).