Scrum Master vs team lead: two jobs, one common mix-up

Promote a good engineer to team lead, adopt Scrum, and the new Scrum Master is often the same person with an extra title. Nothing has changed except the name on the calendar invitation. The team still takes its assignments from the same person, and the Sprint events are run like the old status meetings. The Scrum Master role exists to be different from this, and the differences are worth spelling out.

What a team lead usually does

"Team lead" is not defined by the Guide, and its meaning varies. The common core is a person who sets direction for a group, assigns tasks, makes the final technical decisions, handles escalations and, often, writes or contributes to performance reviews. Some team leads are also the best programmer in the group. A vendor article on Scrum roles makes the useful reminder that Scrum roles are accountabilities and not job titles, and that existing titles can stay. Which means a team lead can hold a Scrum role, and what matters is which role they are acting in at a given moment.

What the Guide says about the Scrum Master

The Scrum Master is accountable for establishing Scrum as defined in the Guide, by helping everyone understand Scrum theory and practice. They are accountable for the Scrum Team's effectiveness, by enabling the team to improve its practices within the framework. They are true leaders who serve the team and the organisation.

Equally important is what the Guide leaves out. There is no line saying the Scrum Master assigns tasks, approves designs or evaluates individuals. The Guide's account of the Developers says the opposite: they plan the Sprint, adapt their plan each day and hold each other accountable as professionals, and no one else tells them how to turn Product Backlog items into Increments. The SBOK® Guide says the same in its own style: no core role has authority over the others, and the Scrum Master is a facilitator at the same hierarchical level as anyone else in the Scrum Team.

Where the two differ

The line "who reviews performance" matters the most in practice. If the Scrum Master also writes the reviews, Developers have a reason to hide problems from them, and the Guide's relationship of openness gets harder. Some organisations separate the two on purpose.

A worked example: the same morning

This is an illustrative scene. It is nine in the morning and the Daily Scrum is about to start. The team's Sprint Goal is at risk because an external API behaves differently from its documentation.

As team lead, the person decides: "You two take the API issue, the rest carry on with the screens, and I will chase the vendor." The team nods. The problem is handled. It is also the lead's decision, and the next time something is unclear, the team will wait to be told.

As Scrum Master, the same person asks at the Daily Scrum: "What does the API problem mean for the Sprint Goal? What options do we have?" The Developers discuss and a pair volunteers to build a thin wrapper that isolates the unstable behaviour, while a third checks the vendor. The Scrum Master notes the impediment, asks who needs to know outside the team and leaves.

The outcomes may be similar on a given day. Over a quarter they differ: the second team gets better at deciding, and the first gets better at waiting.

When one person holds both

Sometimes there is no choice, particularly in small organisations. If you hold both hats, a few practices reduce the damage.

1. Say which hat you are wearing. "As Scrum Master, I would like to hear how you plan to solve this" is different from "as team lead, I need this done by Friday". Saying it aloud keeps the roles distinct.
2. Hand over assignment. Let the Developers pick their work from the Sprint Backlog. If you must assign something, do it as an explicit exception.
3. Hold your technical opinions until the team has spoken. A senior person's view tends to end discussion.
4. Keep performance out of Scrum events. Do not use what you hear at the Daily Scrum or Retrospective in reviews, or people will stop being open.
5. Review it every few Sprints. Ask the team whether the arrangement helps or hinders, and be ready to split the jobs.

The SBOK allows the Scrum Master role to rotate: it says any person from the Scrum Team who learns how to facilitate can become the Scrum Master for a project or even for a Sprint. That is one way to avoid a permanent boss.

What the team gains from the split

Separating the jobs gives each side something. The team lead can concentrate on technical direction and on people, and does not have to carry facilitation as well. The Scrum Master can concentrate on the working system of the team, including the relationship with the Product Owner and the wider organisation. Where there is only one person for both, the loud job usually wins: delivery pressure crowds out coaching, and the Retrospective shrinks.

If your organisation cannot split the jobs, it is better to say so than to pretend. A team that knows its lead is also its Scrum Master can ask for the behaviour it needs and call out slips. A team that is told the Scrum Master is a neutral facilitator and then sees them assigning tasks learns to distrust the label.

Common mistakes

• Treating the Scrum Master as the escalation point for people problems. That is a management role.
• Giving the Scrum Master the final word on design. That sits with the Developers.
• Measuring the Scrum Master by delivery dates. The accountability is Scrum and effectiveness, and delivery is a team outcome.
• Having no Scrum Master because the team lead "does it". The Guide's accountabilities do not disappear when no one holds them.

How to practise it

Ask your team to write down, anonymously, one decision that the team lead or Scrum Master makes that the team could make instead. The answers will tell you where to start. In the simulator, the Scrum Master role is all influence and no authority, which shows how much of the job is not deciding.