The Scrum Master Role in Practice: Far More Than Running Meetings

8 min read5 days ago

Article 1 of 8 in the Scrum Master in Practice series

If you disappeared from your team for two weeks, what would stop happening?

If the first answer that came to mind was “nobody would run the Daily Scrum”, keep reading. Not because you are doing something wrong, but because your team is probably getting very little of what you can do for it.

Almost every Scrum Master has been through this phase. The week slips away between opening the Daily Scrum, passing the word around, writing down impediments, updating the board and sending the Retrospective invite. At the end of the day you are tired, and one question remains: is the team any better than it was last month?

This series is for you, the person doing this work, whatever your badge says: Scrum Master, Agile Master or Agilist. It has eight articles about day-to-day practice, from joining a new team to metrics, pressure from management and AI. This first one asks a simple question: where should your time go?

What the Scrum Guide asks of you

The Scrum Guide, the official definition of Scrum written by Ken Schwaber and Jeff Sutherland, says you are accountable for establishing Scrum as defined, helping everyone understand its theory and practice, both within the team and across the organization. It goes further: you are accountable for the Scrum Team’s effectiveness.

Read that second sentence again, because it changes the yardstick. Effectiveness is not events starting on time. It is the team delivering something valuable, with quality, and getting better at it every cycle. Running meetings is one of the tools to get there, not the measure of your work.

The guide also says whom you serve, on three fronts:

The team: helping people self-manage, work together and remove what blocks their work.
The Product Owner: supporting product goals, backlog management and conversations with the people who use and sponsor the product.
The organization: teaching, supporting Scrum adoption, helping leaders understand empirical work and breaking down barriers between the team and other areas.

Now think about your last week. How much of it went to the third front? For many of us, almost nothing. And that is exactly the front that sets a senior Scrum Master apart, because many of the impediments that come back sprint after sprint are born outside the team.

Going deeper: the 2020 Scrum Guide replaced “roles” with “accountabilities” and stopped calling the Scrum Master a servant leader. The text now describes a true leader who serves the team and the organization. The change sparked debate in the community, because being accountable for a team’s effectiveness requires some influence over the conditions the team works in, not just good will.

What the role is not

Barry Overeem, one of Scrum.org’s best-known trainers, described the most common ways the role gets misunderstood in a free white paper. See if you recognize yourself in any of them:

The secretary: books meetings, reserves rooms, sends invites and reminders.
The scribe: writes everything down and updates the board for the team.
The Scrum police: enforces the rules without asking whether they help.
The team boss: hands out tasks and decides for people.
The superhero: solves everything alone and, without noticing, keeps the team from learning to solve things itself.

If you saw yourself in one or two, you are in good company. Everyone who does this job has fallen into some of them, often because the company itself expects it. Booking a meeting or unblocking something with your own hands is not wrong. The problem starts when that becomes the whole job, and the team starts depending on you for things it could already do on its own.

The stances you switch between

If the role is none of those, what is it? Overeem suggests thinking in stances rather than in a single function. In the most recent version of his work, there are six, and you probably use all of them in the same week:

Facilitator: you create the conditions for the team to talk, decide and reach agreements. Not only in events, but in any difficult conversation.
Teacher: you teach Scrum, practices and concepts to the team, the Product Owner and the organization.
Mentor: you share what you have seen work and help people grow in their own roles.
Coach: you ask questions that help a person or a team reach their own answer, instead of handing it over.
Impediment remover: you clear what the team cannot solve alone, and help the team solve what it can.
Change agent: you work on the organization around the team, because many of the team’s problems are born outside it.

The hard part is not knowing the stances, it is choosing which one to use at each moment. With a team that is just starting to work this way, you will teach more, lead more and propose more. With an experienced team, you will ask more, observe more and step back. A good sign that you are on the right track is becoming less visible in the events over the months, because the team has taken over what used to depend on you.

Scrum Master, Agile Master, Agilist: the title matters less than the work

If you have ever looked for a job, you know the market uses these titles almost as synonyms. And that the description often asks for much more than the title suggests.

Posts titled Scrum Master ask for Kanban experience, working with several squads at once, tracking metrics to make delivery predictable and aligning business and technology. I have seen an Agile Master post asking, among its requirements, for “experience as an Agilist” with Scrum, Kanban and SAFe. Three different titles in the same description.

In practice, this is what I usually see:

None of these titles is above the others. They describe, loosely, a similar set of responsibilities. What changes from one company to the next is the scope: how many teams, which methods, how much contact with management and other areas. So when you look at a job post or talk about your own role, look at the scope, not the title.

Get Bruno Novaes’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

In this series, I use Scrum Master as the name of the role. But everything I discuss applies to you, whatever your badge says.

For recruiters: before choosing the job title, it helps to answer four questions. Is the work with one team or several? Does the team use Scrum, Kanban or both? Will the person be accountable for delivery results, and also for people? Will they work closely with management and other areas? The answers say more about the right profile than the job title, and help candidates understand what the company really expects.

An honest counterpoint

It is not always the market that misunderstands the role. Sometimes we are the ones reinforcing that image.

It happens when we defend an event for its own sake, without being able to explain what problem it solves. When we treat the Scrum Guide as law rather than a starting point. When the team’s routines fill our calendar so much that there is no time left to look at what blocks the flow outside it. And when we keep leading everything for a team that no longer needs it.

It is also fair to say that not every team needs a full-time Scrum Master, and not every context benefits from Scrum. Admitting that does not diminish your work. It shows you are looking at the team’s effectiveness, not at your own calendar.

In practice: where does your week go?

A simple exercise shows which version of the role you are in today. It takes about thirty minutes.

Open last week’s calendar and list what you did, including what was not on the calendar: hallway conversations, messages, board updates, reports.
Put each activity into one of five categories, as in the table below.
Estimate the percentage of time spent on each.
Next to it, write where you believe that time should go, given your team’s current moment.

A few signs to read the result:

If running events and operational work take more than half the week, you are close to the secretary and the scribe. Ask what the team could take over.
If working with the organization is close to zero, impediments that start outside the team are probably coming back sprint after sprint.
If developing the team is the smallest slice, the team may depend on you more than it should.

There is no ideal split. A team that is just starting needs more guidance, and an experienced team needs more work with the organization. The point of the exercise is to turn a feeling into data and to choose, on purpose, one change for next week.

If you want to speed things up, an AI tool can help sort your list of activities into the five categories. Use the list you wrote yourself, without people’s names or internal company information, and review the result: you are the one who knows what each conversation meant.

To wrap up

If you only run meetings, you are not doing it wrong, but you are using only part of the role. It asks you to be accountable for the team’s effectiveness, and that runs through the team, the Product Owner and the organization around them. Your badge may say Scrum Master, Agile Master or Agilist. The work is the same, and it goes far beyond the events.

In the next article of the series, I cover your first 90 days with a new team: how to observe before stepping in, how to read the situation without labeling anyone, and which agreements to make right at the start.

What about you: if you did the weekly exercise today, which category would take up the most space? Tell me in the comments.

Scrum Master in Practice series

The Scrum Master Role in Practice: Far More Than Running Meetings (this article)
The First 90 Days as a Scrum Master on a New Team
Events Worth the Team’s Time: Daily, Planning, Review, and Retrospective
When the Team Sees No Point in the Process
Flow and Metrics: See the Work, Deliver Better
Delivery Pressure Without Cowboy Coding: The Scrum Master Between the Team and Management
Scrum Master for More Than One Team: Focus, Dependencies, and Community of Practice
AI the Professional Way for Scrum Masters

Previous series: Product Owner in Practice