Cross-functional teams: all the skills inside one team

Many teams call themselves cross-functional because they have a developer, a tester and a designer on the same chat channel. The Guide asks for something stricter. It is less about the mix of job titles and more about one question: can this team, on its own, take an idea to a finished and verified piece of the product within a Sprint?

What the Guide says

The Guide defines the term in a clause. Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. Elsewhere it describes Scrum as engaging groups of people who collectively have all the skills and expertise to do the work and share or acquire such skills as needed.

Three points follow. The test is collective: no one person needs every skill. The test is per Sprint, so the skills must be present in the team during that period, not available somewhere in the building. And the Guide expects people to share or acquire skills, so the team's range can grow.

The Guide also widens the scope of the team's responsibility. The Scrum Team is responsible for all product-related activities, from stakeholder collaboration, verification, maintenance and operation to experimentation, research and development, and anything else that may be required. That is a long list, and it explains why a team that only writes code is rarely cross-functional in this sense.

The word "Developers" is also deliberately broad. The Guide says it uses the word not to exclude but to simplify, and that developers, researchers, analysts, scientists and other specialists do the work. A team's skills are whatever the product needs. A vendor article on Scrum roles makes the same point: a team building a web insurance application needs very different skills from one making a game, so the structure follows the problem.

The SBOK view

The SBOK® Guide asks the Scrum Team to possess all the essential skills to carry out the work, with enough collaboration that minimal coordination is needed to get things done. It gives an optimum size of six to ten members, large enough to hold the skill sets and small enough to collaborate. The Guide's typical figure is ten or fewer. The SBOK also lists a cross-functional outlook among the desirable traits of team members, and suggests members develop expertise outside their own role where possible, and that back-up people be identified, because small teams suffer from the loss of one person.

A worked example: the missing tester

This is an illustrative case. A team of four is building a customer account page. It has three developers and a designer. Testing is done by a separate quality group that takes work in batches every other Friday.

In Sprint two the team finishes the account page on Wednesday. It goes to the quality group, which has a queue. On Friday of the following week the group returns six defects. The Sprint has ended and the story is not Done.

The team is not cross-functional in the Guide's sense, because verification is among the skills it needs and it does not own them. There are several honest ways to fix it. The team can take the testing in-house by adding a person or by having developers learn it, supported by automated tests. It can ask the quality group to place a tester in the team for the duration of the product. Or it can reduce what it commits to, so that stories fit the quality group's schedule, and accept this as a limit. The first two address the cause. The third manages the symptom and should be seen as a temporary measure.

Ways to test your own team

A few direct questions work well.

1. List the last ten Sprint Backlog items. For each, who did the design, the build, the test and the release? If any step regularly goes outside the team, that step is a dependency.
2. Count the waits. How many times did a Developer say "I'm blocked until someone outside the team does X"? A cross-functional team has few such waits.
3. Check the single points. Is there one person whose absence would stop a type of work? The SBOK recommends back-ups for the same reason.
4. Look at what the team does not touch. Releasing, monitoring and fixing are product work. A team that hands them over is giving away part of its accountability.

What to do about a missing skill

There are four moves, and teams usually need more than one.

Learn it. The Guide expects people to acquire skills as needed. Pair a person who has the skill with one who wants it, and plan for the slower first few Sprints.

Add it. If the skill is needed every Sprint, a team member is the right answer, and this is a staffing request the Scrum Master can raise.

Borrow it, briefly. For a rare skill, such as a specialist security review, a short loan is reasonable. Plan it into the Sprint ahead of time, and include it in the Definition of Done if it is mandatory.

Change the slice. Sometimes the item is shaped so that it needs the skill. A thinner slice that avoids the dependency might still deliver value.

Why it matters more than it seems

A missing skill is rarely visible as a missing skill. It shows up as a story that is "waiting for review", a release that depends on a hand-off, or a Sprint Goal that was met in everything except the last mile. Over several Sprints the pattern becomes a belief that the team is slow, when the real cause is that part of the work lives somewhere else. This is also why the Guide gives the whole Scrum Team the accountability for creating a valuable, useful Increment every Sprint: the accountability is empty if the skills sit outside the team.

The effect on planning is direct. The Developers use their past performance, capacity and Definition of Done to decide how much to select, and a hidden dependency makes all three unreliable. A team that fixes its dependencies often finds that its forecasts improve before anything else does.

Misreadings

• Everyone does everything. The Guide does not ask for it. It asks for collective coverage. See T-shaped skills for how depth and breadth combine.
• Cross-functional means full-stack. A team may be cross-functional with specialists who each go deep.
• A matrix organisation can supply skills on demand. Loans from a pool do not make a team cross-functional if the Sprint depends on the pool's queue.
• Cross-functional means big. The Guide keeps the team small, typically ten or fewer, and says that if teams get too large they should reorganise into several cohesive teams sharing one Product Goal, Product Backlog and Product Owner.

How to practise it

Take a recent piece of work and trace where it waited. Each wait outside the team is a skill gap or a rule that should change. In the simulator the Developers you work with each bring a different strength, and you see what happens to a Sprint when the plan ignores who can do what.