"When Scrum Masters Become Secretaries"

February 2026 9 min read Case Study

Role erosion in organisations is rarely dramatic. Nobody calls a meeting to announce that the Scrum Master will now function as an administrative coordinator. It happens incrementally – one small task added here, one genuine accountability quietly dropped there – until the person who started as a coach and change agent is spending 80% of their time scheduling meetings and updating Jira boards. And because the erosion is gradual, nobody notices until the damage is done.

---

The Hook: How a Leadership Role Becomes a Support Function

The Scrum Master role, as defined in the Scrum Guide, is one of the most demanding in any software organisation. It requires coaching expertise, political skill, systems thinking, and the courage to challenge structures and behaviours that obstruct effective Agile practice. It is, fundamentally, a leadership role.

In most organisations, it functions as something closer to a team coordinator with Agile vocabulary. The leadership accountability has been quietly removed. The administrative tasks have accumulated in its place. The Scrum Master who was hired to be a change agent has become the person who makes sure everyone has updated their tickets before the daily standup.

This article is about how that happens, why it is so difficult to prevent, and what it costs.

---

The Reality: The Erosion Pattern

Role erosion follows a consistent pattern. Understanding the pattern is the first step to interrupting it.

Stage 1: The Reasonable Request

It starts with something that seems entirely reasonable. The team needs someone to set up the sprint board. The Product Owner asks the Scrum Master to take notes in the sprint review because they are busy facilitating. A stakeholder emails the Scrum Master asking for a status update because they are not sure who else to ask. The Scrum Master says yes. Of course they say yes. These are small things. Helpful things. Why would anyone refuse?

Stage 2: The Expectation

The reasonable request becomes an expectation. The Scrum Master always sets up the sprint board. They always take notes in the sprint review. They always respond to stakeholder status requests. Nobody decided this would be their responsibility. It simply calcified into habit. When the Scrum Master does not do these things, someone notices and mentions it. When they do, nobody notices at all.

Stage 3: The Accumulation

More reasonable requests arrive. Can you manage the team’s Confluence page? Can you prepare the velocity report for the quarterly review? Can you chase the dependency with Team B because you have a good relationship with their Scrum Master? Can you coordinate the cross-team planning session? Each request is reasonable in isolation. The accumulation is not.

Stage 4: The Displacement

The administrative load has grown to the point where the Scrum Master’s actual accountabilities – coaching the team, removing impediments, challenging organisational dysfunction, developing team self-management – are being displaced. There are not enough hours. The visible, immediate tasks get done. The less visible, more important ones do not.

The displacement test: Track a Scrum Master’s actual time allocation for two weeks. Categorise every activity as either “coaching and change work” or “coordination and administration.” In my experience, the typical result for an eroded Scrum Master role is 20-30% coaching, 70-80% administration. The role description says coaching. The time allocation says coordinator. One of them is accurate.

Stage 5: The Normalisation

The final and most damaging stage. The eroded role becomes the expected role. New Scrum Masters are hired into it. Job descriptions are written around the administrative tasks. The question “what does a Scrum Master do?” is answered with “manages the ceremonies, maintains the board, coordinates dependencies, produces reports.” The leadership accountability has been written out of the role entirely – not by intention, but by accumulated precedent.

---

The Checksum: What Drives the Erosion

Role erosion does not happen randomly. It follows predictable organisational logic.

Administrative Work Is Visible. Coaching Is Not.

A sprint board that is not updated is immediately visible. A retrospective that was not facilitated skillfully is much harder to detect. A team that is not developing its self-management capability looks indistinguishable, in the short term, from a team that is. The invisible work gets deprioritised because nobody notices when it is not done. The visible work gets done because somebody notices immediately when it is not.

Organisations are not deliberately choosing administration over coaching. They are responding to the incentives their visibility structures create. Scrum Masters who understand this dynamic can partially compensate by making their coaching work visible – through explicit conversations with leadership about what they are working on and why, through regular reporting on team development indicators rather than just process metrics.

The Coordination Vacuum

Every team creates coordination work. Dependencies need managing. Stakeholders need information. Planning needs organising. In a well-functioning Agile organisation, much of this coordination is handled by the team itself, by the Product Owner, or by explicit coordination roles. In most organisations, these responsibilities are distributed ambiguously, and the Scrum Master – present in every team ceremony, connected to every stakeholder – becomes the path of least resistance for coordination requests.

The Scrum Master fills the coordination vacuum because they are there and because they are capable. The filling of the vacuum prevents the organisation from noticing that the vacuum exists and needs to be addressed structurally.

The Scrum Master’s Own Trap

Many Scrum Masters collude in their own role erosion. Administrative work is satisfying in a way that coaching work often is not. A sprint board configured correctly, a set of meeting notes published promptly, a dependency resolved through a well-timed phone call – these produce immediate, visible results. Coaching a team toward self-management is slow, non-linear, and produces results that are difficult to attribute directly to the coach’s efforts.

There is also a psychological safety element. Administrative work is low-risk. Nobody challenges you for updating a Jira board. Challenging a senior stakeholder’s interference in a team’s work, having a difficult conversation with a Product Owner about backlog quality, pushing back on a management request that undermines team autonomy – these carry interpersonal risk. The path of least resistance is administration. Many Scrum Masters take it, not from laziness, but from an entirely human preference for the comfortable over the uncomfortable.

“A Scrum Master who has become a secretary is not a failure of the person. It is a failure of the organisation to protect the role – and often, a failure of the Scrum Master to protect it themselves.” Markus – agile-checksum.com

---

Real-World Case Studies

The Note-Taker

A Scrum Master at a logistics company had been in the role for two years. When I first met her, she was spending approximately four hours per day on documentation: sprint meeting notes, retrospective summaries, dependency logs, stakeholder update emails, velocity reports. Her Confluence pages were impeccable. Her documentation was the best-maintained in the organisation.

When I asked her what she was coaching the team on, she paused for a long time before answering. She eventually said: “I’m not sure I’m really coaching them on anything right now.” When I asked what the team’s biggest development challenge was, she could not answer confidently. She had been so occupied with documentation that she had lost her observation of the team itself.

The documentation had not been assigned to her formally. It had accumulated over two years of reasonable requests. Nobody had explicitly told her this was her job. Nobody had explicitly told her it was not. The role had filled with what was asked of her rather than what was required of her.

The Dependency Manager

A Scrum Master at a financial services organisation had developed a reputation as the best dependency manager in the department. When his team had a dependency on another team, he resolved it faster than anyone else could. When cross-team planning was needed, he organised it. When two teams had conflicting priorities, he brokered the conversation.

He was excellent at this. He was also, inadvertently, preventing the teams from developing their own cross-team coordination capability. Every dependency that he resolved was a dependency the teams had not learned to resolve themselves. Every coordination conversation he brokered was a conversation the teams had not learned to have directly.

When he left the organisation for a new role, the teams were incapable of managing inter-team coordination without a dedicated coordinator. They had not developed the capability because he had always provided it. He had served the teams’ immediate needs so effectively that he had prevented their long-term development. This is the most subtle and the most damaging form of role erosion – when the Scrum Master becomes indispensable by solving problems instead of building the capability to solve them.

The Reset

A new Scrum Master joined a team that had been operating with an eroded role for eighteen months. Her predecessor had been a highly effective administrator. The board was immaculate. The ceremonies ran on schedule. The team was entirely dependent on the Scrum Master for coordination, documentation, and stakeholder management.

She spent the first two weeks observing and mapping what she had inherited. She then had an honest conversation with the team: “Over the next three months, I’m going to gradually hand back to you the things that should be yours. The board maintenance. The dependency management. The stakeholder communication. My job is to help you do those things well, not to do them for you. It will feel uncomfortable at first. That’s expected.”

The transition was not smooth. The team resisted. Things were occasionally dropped. Some stakeholders complained that responses were slower. But six months later, the team was genuinely more self-managing than any team in the organisation. And the new Scrum Master had time – for the first time in the role’s history in that team – to do actual coaching work.

---

How to Prevent and Reverse Role Erosion

For Scrum Masters: Protect the Role Actively

• Track your time for two weeks. The data will tell you what has happened to the role more accurately than your intuition will. If administration exceeds 40% of your time, the erosion has begun.
• Apply the “whose job is this actually?” test to every task. Updating the team’s Jira board – is that the team’s job or yours? Taking notes in the sprint review – is that the Product Owner’s accountability or yours? Managing a dependency with another team – is that a team-to-team conversation that the teams should be having directly?
• Make the handback explicit and gradual. Do not suddenly stop doing things that the team has come to expect. Have the conversation first. Explain why. Transfer the capability, not just the task.
• Say no to reasonable requests – selectively. Not every reasonable request should be accommodated. When a request will create a dependency rather than build a capability, the most useful response is often to help the person develop their own ability to address the need rather than addressing it yourself.

For Organisations: Protect the Role Structurally

• Define explicitly what the Scrum Master role does not do. Job descriptions for Scrum Masters rarely list what is out of scope. They should. “Does not produce management reports, does not manage dependencies on behalf of teams, does not take meeting notes” – explicit scope exclusions prevent the reasonable request accumulation.
• Measure the right things. If Scrum Masters are evaluated on ceremony completion rates and board maintenance quality, you will get Scrum Masters who optimise for those metrics. If they are evaluated on team self-management development and impediment resolution rates, you will get different behaviour.
• Create the coordination roles that are actually needed. If your organisation has a genuine coordination need that is currently being filled by Scrum Masters, acknowledge it and address it structurally. A programme coordinator, a dependency manager, a planning facilitator – these are legitimate roles. Fill them explicitly rather than letting them colonise the Scrum Master role.

---

The Takeaway: The Role Is Worth Protecting

The Scrum Master role, when it functions as intended, is one of the most valuable investments an organisation can make in its Agile capability. A Scrum Master who is genuinely coaching teams toward self-management, genuinely removing organisational impediments, and genuinely developing the organisation’s Agile maturity creates compounding returns. The team that learns to self-organise does not need a coordinator. The impediment that is resolved structurally does not recur. The capability built through coaching stays with the team after the coach moves on.

A Scrum Master who is scheduling meetings and updating boards creates no compounding returns. The work has to be done again next sprint. And the sprint after that. Indefinitely.

Run the checksum on your Scrum Master role:

1. What percentage of your Scrum Master’s time last week was spent on work that built team capability versus work that substituted for it?
2. Name three things the team does independently now that it needed the Scrum Master’s involvement with six months ago.
3. If your Scrum Master left tomorrow, what would the team be unable to do – and should they actually be able to do those things themselves?

The answers will tell you whether you have a Scrum Master or a very capable team coordinator. Both have value. Only one of them is what you hired.

---

Glossary Terms Used in This Article

• Scrum Master – The Scrum accountability responsible for establishing Scrum and serving the team and organisation.
• Servant Leader – A leadership philosophy focused on serving the team’s growth rather than directing them.
• Psychological Safety – The shared belief that it is safe to take interpersonal risks within a team.
• Retrospective – A Scrum ceremony for inspecting the sprint and identifying improvements.
• Agile Transformation – The process by which an organisation attempts to adopt Agile values and practices at scale.