Cross-Functional Team

The team as a whole should embody all the talent necessary to deliver product.

... the Scrum Team is organizing its development effort, and are choosing team members, or are assessing how to grow the team skill set.

✥       ✥       ✥ 

The Scrum Team is not able to operate autonomously because it does not have all the skills required to complete a complex network of tasks. Depending on skills from people outside the team, the team cannot take ownership for finishing their tasks. It reduces the influence on the time it takes to finalize and can impact the quality of the end result. The core Lean principles of consistency and reduced rework depend on short feedback loops. Most features require talents from many different areas including human factors, engineering excellence, and quality assurance. It is rare that one finds all of these talents in any given individual, let alone in all of the members of a single team. Organizations often organize around areas of competence: birds of a feather flock together. This is sometimes called a functional organization. Yet, it is costly to coordinate these functions across team boundaries, because efficient communications take place between those who share the context of the current work — and that is usually the team members.

A complex product might require that the team has mastered numerous skills to develop Done functionality. When a single individual is needed for each skill, the team will become too big to be effective, so one might be tempted to not extend the skill set in the team and to instead introduce external dependencies. On the other hand, one might choose to give the work to the team so that they can develop and learn the required skill, but learning takes time.

Local learning can become local optimization, where a group of specialists develop practices and processes that optimize their work. Specialization, local practices and processes can all be sources of efficiency in an organization, but can also create problems at the boundary of the group. To attack these problems, an organization can define contracts about how to work with each other (e.g. service requests). The contract will specify the nature and detail of the work requests that can be made for the group and expected durations for responses to requests. Anyone needing the group’s specialization will need to use these contracts. However, this can add significant burden to the product development process which, despite creating greater efficiency for the local department, will slow the development of the product. Again there may need to be additional groups within the organization to manage these boundary contracts, to negotiate exceptions or ensure all parties understand what is required, to make sure the department meets their obligations of these contracts.

New products create a new world for their customers and because you cannot know in advance what this new world will be like you must focus on learning and experimentation as you develop your products. Lessons learned need to come from the product the customers are using rather than from a plan you are following, and must be integrated across the product development process. Everyone recognizes the advantages of local flow, autonomy, and control that come from working as an individual within a step of the process or within a functional area. However, such a work structure moves everyone (except the person doing the last step) further from the end user and the broad insights that come from interactions at that boundary. This may result in sub-optimal local functions though with greater optimization across the entire product development process.


Each Scrum Team should comprise all talent necessary to deliver Done functionality.

It’s good to pay attention to skill-set coverage when initially creating the team, but it’s more important that the charter team members share enthusiasm for the Vision and they have a track record for learning new things. Because things change over time, it is unlikely that the team will be able to foresee all of its long-term skill needs from the beginning.

✥       ✥       ✥ 

Instead of changing team membership as the need for new skills emerge, grow the people internally and strive for Small and Stable Teams. Over time, cross-train team members so each member grows their skill set to accommodate more and more competency areas (see Moderate Truck Number). This will increase the ability of the team to operate autonomously. With Cross-Functional Teams it becomes easier to Distribute Work Evenly.

The team members now have all the opportunities to learning secondary skills. They can swarm on PBIs which increase learning and optimizes for flow and getting functionality to Done fast. The development of secondary skills enables the team to react to the work that they have to do with more flexibility and to stand in for one another when a team member is unavailable. The team always makes progress and is autonomous.

These teams naturally act like “feature teams” (see Conway’s Law) because most PBIs are feature-shaped: marketable elements of revenue-generating functional product increment. If Cross-Functional Teams develop the product, it is natural to eliminate handoffs from the Value Stream: the development of any single feature happens within a single team. Involving multiple teams introduces delays in feedback loops, increases the waste (muda) of rework, and creates inconsistency (mura) between development stages in the Value Stream.

A study of two corporations published in the Harvard Business Review [1], one organized functionally and the other by product, suggests that cross-functional teams offer the best features of both organizational structures.

Set-Based Design is a technique that keeps developers engaged in many disciplines and domains that may be relevant to the business, whether or not they ultimately make it through to the any product. Such practice broadens the expertise base of the team and enterprise and reduces the probability that the team will be surprised by the need to master some new discipline.

As the team integrates new lessons there will be new product ideas. Change will proceed quickly (and must be allowed to proceed quickly). Change will be the norm rather than the exception. This requires small organizations where everyone knows what is happening: organizations that can embrace change, work across specializations, regularly deliver value and are, for want of another term: agile.

A Game

Assemble several small team who will compete in a game to make and fly paper airplanes. Each team member may make only one fold at a time, and thereafter must work on another plane. Only 15 folds are allowed per plane. It must be at least 15 centimeters long and 8 centimeters wide. It must have a blunt tip at least 2 centimeters wide. To be accepted as a quality product the plane must fly 3 meters horizontally when the tester tests it. Each plane may be tested only once.

Try the game, and apply Scrum patterns (hint: Swarming) to optimize the number of quality planes produced in a one-minute Sprint.

[1] Arthur H. Walker and Jay W. Lorsch. “Organizational Choice: Product vs. Function.” In Harvard Business Review 46(6), 1968, pp. 129-138. (accessed 8 November 2017).

Picture from