What's the difference between a scrum master and an agile leader?

The Setup: A Quick Joke and a Real Question

What is the difference between a scrum master and an agile leader? Before I answer that question, here's a related one: what's the difference between a scrum master and an agile coach? About $200 a day.

Jokes aside, a scrum master should be working at all levels of the organization, collaborating with other teams of teams, helping people understand how scrum and agile work, and acting as a change agent to carefully expand the footprint of agility. But let's get back to the main question.

What a Scrum Master Should Be Doing

A scrum master should be observing through whatever senses they have — seeing, sensing, picking up on body language, noticing what's going on around them. Crucially, this means observing without judgment.

The work involves:

Helping people, but not inflicting help. Helping when help is requested.
Coaching people professionally, asking Socratic open questions when there's permission from the coachee to do so.
Giving advice when advice is requested.
Teaching when people are open to hearing other options for how they can do their work.
Acting as a change agent for the rest of the organization.
Removing impediments that are beyond the control and influence of the teams or teams of teams.
Working with leadership to help cultivate the environment where agility can grow.

A scrum master also helps make sure scrum is being done well. If they observe negative chaos starting to take hold — perhaps unconstructive or unhealthy conflict — a scrum master needs to step in.

We want teams to be self-managing, but when negative chaos kicks in, intervention becomes necessary. The goal is to reestablish healthy conflict, get back into positive chaos, complexity, complicatedness, or even clear work — anything to nudge teams out of the negative chaos zone.

What an Agile Leader Adds

A leader does much of the same, but with some important additions.

Walking the Gemba of Value Creation

One of the biggest is walking to the source of value creation. Where is the work actually being created? If it's software development, you might even be looking at the source code alongside the team doing mob programming. For non-software work, you're visiting where the product is being produced or where the service is being delivered, and you're seeing what's going on.

This is less about a royal tour — where people know you're coming, it's prearranged, and they stick posters on the wall because you're so important. It's about unexpected, informal visits where people are much more likely to be open about what's frustrating them, what's slowing them down, and how you can help them.

It also helps to be technical — not so technical that you understand every single detail, but enough to grasp the technical risks the team is sitting on top of. This matters especially when people's health or lives are at risk, or when organizational health is on the line. The Japanese call this walking the gemba.

Walking the Gemba of Value Consumption

You can also walk the gemba of value consumption — where value is being received. Visit customers and end users. Don't make one-off visits and assume those one or two customers represent everyone. Build a habit of meeting customers across the regions you operate in, both face to face and online. Understand their perspective and the jobs they're trying to perform.

Inspiring Teams

Not everybody is a visionary, but leaders need to inspire teams through a direction of travel. Often, you'll co-create that direction with the teams or teams of teams, so everyone feels inspired — and inspiring. This is about lighting up the place and helping people get better.

Cultivating the Environment

Your job is to cultivate the environment where agility can grow. That might look like:

Building a horizontal growth path so people can advance without needing a vertical promotion to earn more pay or recognition.
Implementing more frequent funding cycles so the organization can adapt as it learns. Maybe at the start of the year you thought all the value would be created in one area, but you've since learned it's actually somewhere else. You need a funding cycle regular enough to support that pivot.
Decluttering workflows and processes that impede team agility.
Helping teams demonstrate compliance without falling back on waterfall approaches. There are more agile ways of demonstrating compliance — what matters is understanding what you're trying to control and what risks you're managing, then finding alternative ways to show you're on top of them.

So What's Actually Stopping the Overlap?

These are the key differences — but they raise an obvious question: what's stopping a scrum master from being a leader, or a leader from being a scrum master?

Nothing.

In fact, leaders make great scrum masters, as long as they act as leaders and not as controlling managers. There are good managers — not all managers are controlling — so this can absolutely work. But you do need to be careful.

If your manager is also your scrum master, that can impede the self-management of the team. Better that they serve as a scrum master on a different team. If they're not your line manager and don't handle your pay reviews, the dynamic is healthier. And we should definitely leverage these skills — managers and leaders often have more power to fix problems and remove impediments than scrum masters do.

The Bottom Line

That's my summary of the difference between a scrum master and an agile leader: not much. There's a lot of overlap — and that's a feature, not a bug.