"Why Most Scrum Masters Don't Understand Their Job"

September 2025 9 min read Opinion from Experience

The Scrum Master is the most misunderstood role in software development. Not because it is complicated. Because it is inconvenient. And inconvenient things, in large organisations, tend to get quietly redefined until they are no longer inconvenient.

---

The Hook: A Role Designed to Be Uncomfortable

I have hired Scrum Masters. I have coached Scrum Masters. I have worked alongside Scrum Masters who were genuinely exceptional and Scrum Masters who were actively making their teams worse. After twenty years in enterprise IT, I have a reasonably clear picture of what separates the two groups.

It is not certification. It is not years of experience. It is not even technical knowledge.

It is whether they understand what their job actually is.

And in most organisations, most Scrum Masters do not. Not because they are incompetent. Because the organisation has never allowed them to find out.

---

The Reality: What Most Scrum Masters Actually Do

Let me describe a typical day for a Scrum Master in a mid-to-large enterprise. See if it sounds familiar.

They start the morning by checking whether everyone has updated their Jira tickets. They send reminders to the two developers who have not. They update the sprint burndown chart because the tool does not do it automatically. They schedule next week’s retrospective and send calendar invites. They attend a meeting about the quarterly planning process. They write up the notes from yesterday’s daily standup. They chase a dependency with another team because the Product Owner asked them to. They spend forty minutes in a discussion about story point estimation for a ticket that will probably not be worked on for three sprints. They end the day by updating the team’s velocity chart for the weekly report.

None of this is in the Scrum Guide.

The hard question: If you removed the Scrum Master from that description and replaced them with a well-organised project coordinator, would anything of substance change? If the answer is no – that is a problem. Not with the person. With how the role has been defined.

The Three Things Most Scrum Masters Get Wrong

1. They Manage the Process Instead of Coaching the Team

The most common failure mode. The Scrum Master becomes the guardian of the process – making sure ceremonies happen on time, making sure the board is updated, making sure the Definition of Done is being followed. These things matter. But they are not the job.

The job is to help the team get better at doing the job. That means asking uncomfortable questions in retrospectives rather than just facilitating a safe discussion. It means challenging estimation that is clearly driven by fear rather than genuine assessment. It means having difficult conversations with the Product Owner when the backlog is a mess and nobody wants to say so.

Process management is visible and measurable. Coaching is neither. Organisations reward what they can measure. So Scrum Masters manage the process.

2. They Protect the Team From Discomfort Instead of From Dysfunction

There is a version of servant leadership that tips over into something less useful – call it protective leadership, or in less charitable moments, helicopter Scrum Mastering. The Scrum Master who shields the team from every difficult stakeholder conversation. Who buffers every piece of negative feedback. Who smooths over every conflict before it has a chance to surface something important.

Discomfort, in a healthy team, is often diagnostic. A team that is consistently uncomfortable with its sprint commitments is telling you something about the planning process. A team where the same interpersonal tension surfaces in every retrospective is telling you something about a relationship that needs to be addressed rather than managed around.

The Scrum Master’s job is not to make the team comfortable. It is to make the team effective. Sometimes those are the same thing. Often they are not.

3. They Report Up Instead of Serving Across

In many organisations, the Scrum Master has become a de facto reporting channel. They collect status from the team, translate it into management-friendly language, and present it upward. They are the person who explains to the steering committee why the sprint goal was not met. They are the person who defends the team’s velocity in the quarterly review.

This is not inherently wrong. Communication between teams and leadership matters. But when the Scrum Master’s primary relationship is with management rather than with the team – when they are spending more time preparing reports than sitting in team conversations – something has inverted. The role was designed to serve the team first. In practice, it often serves the reporting structure first.

“A Scrum Master who makes their manager happy at the expense of their team’s autonomy is not doing their job. They are doing someone else’s job, badly.” Markus – agile-checksum.com

---

The Checksum: What the Role Was Actually Designed For

The 2020 Scrum Guide describes the Scrum Master’s accountability in three directions: serving the Scrum Team, serving the Product Owner, and serving the organisation. Let us look at what each of those actually means.

Serving the Scrum Team

The Scrum Guide is specific. The Scrum Master serves the team by coaching team members in self-management and cross-functionality, helping the team focus on creating high-value increments, removing impediments, and ensuring that all Scrum events take place and are positive, productive, and kept within the time-box.

Notice what is not on that list: updating Jira, scheduling meetings, writing status reports, managing dependencies, or translating team output into management dashboards.

Serving the Product Owner

The Scrum Master helps the Product Owner find techniques for effective goal definition and backlog management, helps establish empirical product planning, and facilitates stakeholder collaboration as requested. They are a coach and a facilitator – not an assistant and not a proxy.

Serving the Organisation

This is the accountability most Scrum Masters never get to exercise. The Scrum Guide says the Scrum Master serves the organisation by leading, training, and coaching in Scrum adoption, planning and advising Scrum implementations, and helping employees and stakeholders understand and enact an empirical approach.

In plain language: the Scrum Master is supposed to be an agent of organisational change. They are supposed to challenge structures, processes, and behaviours that obstruct Scrum – not just within their team, but across the organisation. That is a fundamentally different remit from scheduling retrospectives.

The accountability that gets ignored: When did your Scrum Master last challenge a management decision that was obstructing the team? When did they last push back on a process imposed from outside that was adding no value? When did they last tell a senior stakeholder something they did not want to hear? If the answer is never – ask why.

---

Real-World Examples: The Gap in Practice

The Secretary

A Scrum Master I coached at a large insurance company had been in the role for three years. She was organised, reliable, and well-liked. She scheduled every ceremony, kept impeccable notes, maintained the board, and had never missed a standup in three years.

When I asked her what the biggest impediment to her team’s effectiveness was, she said: “The approval process for production deployments. It takes two weeks minimum and requires sign-off from four different departments.”

I asked what she had done about it. She said she had raised it in a retrospective. Once. Eighteen months ago. The team had agreed it was a problem. Nothing had changed.

I asked why she had not escalated it, challenged it, or made it her mission to fix it. She looked genuinely surprised. “Is that my job?” she asked.

Yes. That is exactly your job.

The Buffer

A Scrum Master at a fintech startup had developed a reputation for being extremely protective of his team. No stakeholder could approach a developer directly – all requests went through him. No feedback reached the team unfiltered – he translated everything into what he considered constructive language. No conflict surfaced in the open – he resolved everything in private conversations before it could become visible.

The team loved him. They were also, quietly, one of the least effective teams in the organisation. They had no direct relationship with their stakeholders. They had no practice handling difficult feedback. They had no experience navigating conflict. When he left the company, the team struggled for months with challenges that should have been routine.

He had protected them from discomfort so consistently that he had prevented them from developing the resilience they needed.

The Metric Collector

A Scrum Master at an automotive supplier spent approximately 40% of his time producing metrics. Velocity charts, burndown charts, capacity utilisation, sprint goal achievement rates, cumulative flow diagrams. He was meticulous, the data was accurate, and the management team reviewed it every week.

The team’s actual problems – a toxic dynamic between two senior developers, a Product Owner who changed priorities mid-sprint without discussion, and a Definition of Done that nobody enforced – appeared nowhere in the metrics. They appeared every week in the retrospective, where they were discussed earnestly and then left unresolved.

He was measuring everything except what mattered.

---

What a Good Scrum Master Actually Looks Like

In twenty years, I have worked with perhaps a dozen Scrum Masters who I would describe as genuinely excellent. They shared a set of characteristics that had nothing to do with their certification level or their years of experience.

What They Did	What Most Scrum Masters Do Instead
Asked uncomfortable questions in retrospectives	Facilitated comfortable discussions that reached safe conclusions
Challenged management decisions that obstructed the team	Translated management decisions into team-friendly language
Made impediments visible at the organisational level	Worked around impediments to keep the sprint moving
Coached the team to self-organise	Organised the team themselves
Made themselves progressively less necessary	Made themselves indispensable

That last point is worth dwelling on. A genuinely effective Scrum Master is working toward their own redundancy. The goal is a team that self-organises, self-improves, and handles its own impediments. A Scrum Master who is still essential after two years has either an exceptionally complex situation or a dependency problem of their own creation.

---

The Takeaway: The Role Is Harder Than It Looks

The Scrum Master role is frequently underestimated – by the organisations that hire for it, by the managers who define it, and sometimes by the people who hold it. It is not a coordination role. It is not a facilitation role. It is not a project management role with a different title.

It is a leadership role without formal authority. And leadership without formal authority is one of the hardest things to do well in organisational life.

It requires the courage to challenge people more senior than you. The judgment to know when a team needs support and when it needs to struggle through something on its own. The patience to coach rather than direct. The political skill to navigate organisational structures that were not designed with Scrum in mind. And the self-awareness to recognise when you are solving your own need to be needed rather than serving the team’s actual needs.

Most Scrum Masters do not get the chance to develop those capabilities because their organisations have never asked them to. They have been given a Jira licence and a calendar and told to make the process run smoothly.

“The Scrum Master role is not about making Scrum work. It is about making the organisation safe for Scrum to work. That is a much bigger job.” Markus – agile-checksum.com

Run the checksum on your Scrum Master – or on yourself if that is your role. Ask three questions:

1. What is the most significant organisational impediment your team faces, and what concrete steps have been taken in the last month to address it?
2. When did the Scrum Master last have a conversation that made a senior stakeholder uncomfortable – and what was the outcome?
3. Is the team more self-sufficient than it was six months ago, or more dependent on the Scrum Master to function?

The answers will tell you whether you have a Scrum Master or a very organised meeting scheduler.

---

Glossary Terms Used in This Article

• Scrum Master – The Scrum accountability responsible for establishing Scrum and serving the team and organisation.
• Scrum – A lightweight framework for developing and delivering complex products.
• Product Owner – The Scrum accountability responsible for maximising product value and managing the Product Backlog.
• Servant Leader – A leadership philosophy focused on serving the team rather than directing it.
• Velocity – A measure of work completed per sprint, expressed in story points.
• Burndown Chart – A graphical representation of work remaining versus time within a sprint.
• Definition of Done – The shared agreement on what “complete” means for a product increment.