What Is a Scrum Master? The Servant Leader, Not the Boss

Scrum Master is probably the most misunderstood role in Agile — and it's usually described in such fluffy terms that nobody can picture the actual job. "Servant leader." "Process coach." "Impediment remover." Great, but what does that person do on a Tuesday? Let me get concrete.

First, what they're NOT

This is the part everyone gets wrong, so let's start here. A Scrum Master is not a project manager, and not the team's boss. They don't:

• Assign tasks to people. (The team self-organises and pulls work.)
• Decide what gets built. (That's the Product Owner.)
• Fire, hire, or do performance reviews.
• Whip the team to work faster.

If someone calls themselves a Scrum Master and they're bossing people around, they're doing it wrong. The role has no authority in the traditional sense — and that's deliberate.

The servant leader idea

Scrum calls the Scrum Master a "servant leader." Corny phrase, real meaning: the leader serves the team so the team can do its best work. Their job is to make everyone else more effective — clearing obstacles, smoothing the process, protecting the team from chaos — rather than being the one who gives orders.

The power comes from influence and trust, not position. A good Scrum Master is the person the team goes to with problems because they actually get things unstuck.

What they actually do on a Tuesday

Concretely, the day-to-day looks like:

• Removing blockers. Someone's waiting on access for three days? The Scrum Master chases it. An API is down and nobody's got the right permissions? They escalate. This is the highest-leverage work — unblocking one person can save the whole sprint.
• Running the ceremonies. They facilitate planning, standup, review, and retro — keeping them short, focused, and actually useful. Not by talking the whole time, but by keeping the meeting on track.
• Coaching the team. Teaching the team to self-organise and improve, rather than fixing every problem for them. A Scrum Master who does all the work creates a team that depends on them — a bad outcome in disguise.
• Protecting the sprint. Shielding the team from the "can you just squeeze this in?" requests that would quietly destroy the sprint goal. They say no so the team doesn't have to.
• Improving the process. Taking the retro's "let's try this next sprint" and making sure it actually happens — following up, not just nodding.

A real example

Our best Scrum Master ever spent a whole morning tracking down why the team couldn't deploy — turned out it was an expired credential on a shared account nobody owned. She fixed it, wrote a note about it, and the team's deployment went from a weekly ordeal to a non-event. Nobody clapped, nobody thanked her loudly, the sprint just... worked. That's the job. When it's done well, it's invisible.

Scrum Master vs Agile Coach

They overlap, but roughly: a Scrum Master works with one team on the Scrum process. An Agile Coach works with a whole organisation on Agile practices and culture. Many Scrum Masters grow into coaches over time. If you're starting out, focus on the one team first — the role is already plenty.

Quick answers

Does the Scrum Master report to anyone? Yes, they have a manager like everyone — but their day-to-day is serving the team, not managing it.

Can the Scrum Master also be a developer? Sometimes, in small teams — but it's hard to coach a ceremony while you're mid-code in the same ceremony. Most teams prefer a dedicated SM.

Is the Scrum Master the Product Owner? No. The Product Owner owns the "what" (priorities and backlog); the Scrum Master owns the "how" (the process working smoothly). Keeping those separate matters.

Tip: A good Scrum Master keeps the team's rhythm — including that ceremony timezone problem. If your team is distributed, be the one who checks everyone's local time in ClockHive before locking the recurring standup. Your teammates will quietly love you for it.