T-shaped skills on a Scrum team

Cross-functional is a property of the team. T-shaped is a property of its people, and it is how the team gets there. A group of five specialists who each know only their own field is cross-functional on paper and brittle in practice. A group of five people who each have a deep strength and a working knowledge of two or three neighbouring areas can absorb illness, a change of plan and an awkward dependency.

The idea

The T-shape is a picture. The vertical bar stands for depth of skill and expertise in one field. The horizontal bar stands for the ability to collaborate across other disciplines and to apply knowledge outside one's own specialty. The term is widely used in software development to describe the cross-skilled developers and testers an agile team needs. It is a practitioner idea and is not in the Scrum Guide or the SBOK® Guide under that name.

What the Guide does say is close in spirit. Scrum engages groups of people who collectively have all the skills and expertise to do the work and share or acquire such skills as needed. Scrum Teams are cross-functional, with all the skills necessary to create value each Sprint. And the Developers are the people committed to creating any aspect of a usable Increment, with skills that are often broad and vary with the domain. The words "share or acquire" describe the horizontal bar being built over time.

The SBOK makes a related point about team resilience. It notes that smaller teams are more affected by the loss of a member, even briefly, and that this can be addressed by members having expert knowledge and skills outside their own specific role, though it cautions that this may be difficult and depends on the project, industry and organisation size. It recommends back-up people as well. It also lists a cross-functional outlook among the desirable traits of team members.

Why it helps a Sprint

Three benefits show up quickly.

Flow. When any of three people can pick up a test task, the work does not wait for the one person who usually does it. Queues at specialist stages shrink.

Resilience. One illness, one resignation or one holiday no longer leaves a hole. The bus factor, a blunt measure of how many people would have to leave before a type of work stops, rises from one to two or three.

Better conversations. People who understand a little of each other's work make fewer impossible requests and spot problems earlier. A designer who understands the build constraints suggests a simpler layout.

What it is not

It is not an expectation that everyone does everything. The Guide does not ask for it, and it would destroy the depth that makes specialists valuable. It is not a licence to replace specialists with generalists to save money. And it is not a reason to move people around at random: breadth built without intent is slow and uneven.

A worked example: the skills matrix

This is an illustrative team of five building a booking product. The team makes a simple table. The rows are skills the product needs. The columns are team members. In each cell they mark a level: 0 for none, 1 for can follow along, 2 for can do with support, 3 for can do and teach.

The matrix makes three things visible. Payments integration depends on one person (D), and so does the deployment pipeline (C). Nobody except D can write automated tests at the top level. These are the single points of failure.

The team takes two actions. For the next two Sprints, a pairing plan assigns payments tasks to D together with B, and pipeline tasks to C with A. No one is forced; each pair agrees the work together. And in Sprint Planning the team limits how many payments tasks are allowed at once, because D's capacity is the real limit.

After six Sprints they update the matrix. Payments now has two people at level 2 or above. The deployment pipeline has three. The team's forecasts become steadier, because no single absence changes the picture.

Building the horizontal bar on purpose

Several habits work, and they combine.

Pair on the unfamiliar. The pairing of a person strong in an area with a person who wants to learn it is the fastest way to build skill, and it produces the work at the same time.

Rotate small, not big. A short rotation, such as taking the testing role for a week, is more likely to stick than a wholesale move.

Share reviews. Having people review work outside their specialty spreads knowledge as a by-product.

Learn in the open. A short demonstration of something a team member has learned at the end of a Retrospective keeps learning visible and normal.

Protect time to learn. The Guide notes that working at a sustainable pace improves a team's focus and consistency, and learning is part of a sustainable pace. A team that is always at full utilisation will not cross-train.

The Scrum Master's role, in the Guide's words, includes coaching in cross-functionality. A skills matrix and a pairing plan are two practical tools for doing it. See coaching a Scrum Team.

Cautions

• Using the matrix to rank people. It is a tool for the team to see gaps. If it feeds into performance reviews, scores will be inflated or hidden.
• Letting the strongest specialist be the only teacher. That loads one person and slows their own work. Spread teaching.
• Overdoing it. A level 3 in everything for everybody is not the goal. A team needs depth where the product needs it.
• Ignoring the product. The skills that matter are those the Product Backlog calls for. Look ahead at the next few Sprints and train for those.

How to practise it

Build a matrix for your own team in thirty minutes, and pick the one skill with a single owner. Plan a pairing for it in the next Sprint. In the simulator the Developers on your team have different strengths, and noticing who is best placed for a task is part of the Developer role.