Summary : As a whole, the team should contain all the talents needed to deliver the product. The Scrum team organizes its development efforts, selects team members, or evaluates how to grow the team's skills.

Scrum Pattern | Cross-Functional Team

Source：cross-functional team

As a whole, the team should contain all the talents needed to deliver the product.

The Scrum team organizes its development efforts, selects team members, or evaluates how to grow the team's skills.

1. Why Does the Scrum Team Needs the Cross-Functional Team

It does not have all the skills needed to complete a complex task network if a Scrum team cannot work autonomously. The team cannot really "master" the work at hand if it relies on the skills of team external personnel. In this way, the team has less control over the work's completion time, and the final result will also be affected. The two core Lean principles of Consistency and Reduced Rework rely on short feedback loops. Most complex development efforts require a wide range of talent from different fields (such as ergonomics, engineering excellence, and quality assurance). It is rare to find all these talents on a team, let alone all of these skills in any person. As the saying goes, birds of a feather flock together. The team is usually organized around competency areas, sometimes called a Functional Organization. However, the cost of coordinating these functions across team boundaries is high because effective communication can only exist between those who share their current work background - which is usually only possible for members of the same team.

A complex product may require a team with many skills to "complete" (one of the Scrum Patterns will introduce in a separate article). If we need to add one person for each required talent, the team will become too large to work effectively. There are usually two options to solve this problem: you may prefer not to expand the team's skillset but to introduce external dependencies, Or you may choose to assign the work to the team to develop and learn the skills they need. But learning takes time.

Local learning can lead to local optimization, meaning that experts will develop practices and processes to optimize their work. Specialization, Local Practices, and Processes can all be sources of efficiency for an organization, but they can also cause problems within the team's boundaries. The organization can define "contracts" that describe working with the other party to address these issues(such as service requests). Such a contract can specify what nature of work the organization is willing to do and the expected response time to the request. Anyone who needs the team's expertise must use these contracts to deal with them. However, this may slow down the development of the whole product, even if it improves the efficiency of local departments. At the same time, it may be necessary to set up additional coordination groups within the organization to manage these boundary contracts, negotiate exceptions or ensure that all parties understand the required content, and ensure that each team performs its obligations to other teams, as well as customers according to the responsibilities of these contracts.

Therefore：
Each scrum team should include all the talent needed to deliver the "done" function.
It's great to focus on skill coverage in the early stage of the team's creation, but it's more important that team members share a passion for the vision and are willing to learn new things. The team cannot foresee all the long-term skill needs from the beginning because things will change over time.

2. How to Cultivate a Cross-Functional Team?

It's better to develop talents internally and strive to establish a small and stable team instead of replacing team members just because they need new skills. Over time, we should conduct cross-training for team members to make their skillset grow continuously to fit an increasing number of competency areas (for further information, please see the Modern Truck Number Model that follows), which will improve the team's ability to work as an autonomous team. With a cross-functional team, it is easier to distribute work evenly(one scrum pattern will be introduced in a separate article).

Team members now have too many opportunities to learn sub-skills. For example, they can use the crowding mode on the Product Backlog (PBI), increasing learning opportunities, optimizing the flow, and helping the function reach the "done" state quickly. Developing sub-skills makes the team more flexible, so anyone else can do their job if someone is not there. In this way, the team can always make progress and be autonomous.

Scrum doesn't mention how to deal with the problem of lack of ability. It believes that these can be solved by common sense: seeking help from other teams or outsourcing considerable work, although outsourcing results are unknown and may surprise the team. It is understandable if the team needs such help occasionally. However, if the team often relies on external support, they should see this as an obstacle and take measures (such as training, reorganization, or recruitment) to remedy the situation.

For example, a team of software programmers may find themselves building a product that does not belong to their professional fields, such as pharmaceutical or aerospace. We want to assign a person in charge of each weaker capability in the team, and maybe we can consult external domain experts. However, the team representative may not know how much they don't know and may not even know what questions to ask domain experts. Conversely, most domain experts treat domain expertise as tacit knowledge (it has become part of the expert's subconscious), so they may not be able to realize what insight software personnel want (because experts won't notice what they take for granted, that is, tacit knowledge). Team members must understand domain factors' impact on implementation and comprehensively understand the business and solution space. In a recent article, Amazon's Jesse Watson pointed out that these two factors must coexist "within one skull." It is better to bring experts into the team and expand their knowledge through cross-training. But remember to keep the team small: adding experts to the team may weaken teamwork to the point where it is almost non-existent.

These teams will naturally work like the "Feature Team" (for further information, please see Conway's law model that follows) because most PBIs exist as Feature-Shped: marketable elements of the revenue-generating functional product increment. If a cross-functional team develops the product, the handover action will naturally disappear from the value stream: the team can develop any feature without external support or intervention. Involving multiple teams can cause delays in feedback loops, rework Muda, and create Mura between different development stages of the value stream.

Harvard Business Review published a study on two companies, one organized by function and the other by-product. Research shows that cross-functional team delivery features are the best in comparison (see Organizational Choice: Product v.s. Function)

Set-Based Design（one of the Scrum Patterns will introduce in a separate article） is a technique that allows developers to participate in many disciplines and fields that may be relevant to the business, even if the current product may not use them in the end. This practice broadens the professional knowledge base of the team and the enterprise and makes the team not surprised by the need to master specific new disciplines.

As the team integrates new experiences, they will have new ideas about products. The change will be rapid (and it must be allowed to be fast). The change will be the norm, not the exception. That requires small-scale organizations where everyone knows what is happening: these organizations can embrace change, work across disciplines, and deliver value regularly. In a word, it is agile.

3. A Game

We set up several small teams to make flying paper planes in the game. Each team member can only do one folding action at a time and then must switch to another plane. No flying paper planes may have more than 15 creases. It must be at least 15 cm long and 8 cm wide. It must have a blunt head at least 2 cm wide. The tester must fly 3 meters horizontally when testing to become a high-quality product. The tester can only test each flying paper plane once.
We can try this game and apply the Scrum Pattern（tip：swarm pattern） to optimize the number of high-quality aircraft produced in a one-minute Sprint.

1. What Are The Complete Scrum Artifacts?

2.【A Brief History of Agile】Ken Schwaber - A Brave Warrior (Part 1)