Every Scrum team should have a Scrum Master. Scrum Masters are important to the success of Scrum within the organization and impact the Scrum team's ability to deliver value and improve customer outcomes. The Scrum Master is often called upon to coach and mentor the Scrum team and its stakeholders - even leadership.
But Scrum Masters are human. And sometimes - even when they are trying to help - they can unintentionally overstep their authority. In this article, we will discuss the most common ways that Scrum Masters overstep themselves, and why.
"No one can speak to the Scrum team except for me"
When the Scrum Master makes themselves into a communications roadblock, it's a clear overstep and misunderstanding of their responsibility. In fact, becoming a roadblock is the opposite of what the Scrum Master should be doing. According to the Scrum Guide, part of the Scrum Master's service to the Product Owner is to facilitate stakeholder collaboration when needed.
Why does it happen?
There are many reasons why a Scrum Master might try this approach:
Are stakeholders going around the Product Owner?
It could be that stakeholders are going around the Product Owner and requesting - or even pressuring - Developers to do work that is not in the Product Backlog. For example, I once worked with a Scrum team struggling to deliver against the roadmap. Upon investigation, it turned out that 90% of the work completed during the Sprint was random work requested by the stakeholders directly from Developers. The stakeholders bypassed the Product Owner because they were frustrated with the slowness of delivery. But they didn't realize that they were actually causing much of the delay by going around the Product Owner!
Is the Scrum Master trying to help streamline the Requirements process?
This could be an attempt to reduce the amount of time documenting items in the Product Backlog.
Misunderstanding of the Scrum Master accountability
This could be a simple misunderstanding. They may mistakenly believe their role is to act as a gatekeeper for the team, protecting them from distractions, rather than fostering transparency and collaboration.
What to do instead:
Rather than taking such a hard line and demanding that no one talk to the Scrum team, the Scrum Master should coach the Scrum team to have more positive interactions. For example, if stakeholders are trying to go around the Product Owner, discuss it at the retrospective. Perhaps Developers can redirect stakeholders to the Product Owner to submit their requests.
Assigning work to individual developers
Scrum Masters should not be assigning work to the developers. Instead, the Scrum Master should be facilitating conversations which allow Developers to decide who will do which work. Scrum teams are self-managing, which doesn't mean that there's not manager and it doesn't mean that the Scrum Master is the boss of the team. What it means is that those closest to the work - the Developers - should collaborate together to figure out how to deliver it.
Why does it happen?
The Scrum Master is trying to help
When I have seen this happen on a Scrum team, it's usually because the Scrum Master is genuinely trying to help. Newer Scrum Masters often see themselves as taking an administrative burden from the Scrum Team.
Misunderstanding of the Scrum Master accountability
The Scrum Master may see themselves more as a technical Project Manager than as a Scrum Master. They may not understand that the true power of Scrum comes from self-management. When a Scrum Master takes that away from the team, what they are really doing is disempowering developers.
What to do instead:
The Scrum Master should take a step back from assigning work and use the Sprint Planning event and the Daily Scrum as a place for Developers to decide upon or update the plan for delivering the Sprint Goal. The Scrum Master should help the Scrum team to use the Sprint Backlog to visualize and update their plan continuously throughout the Sprint. Trust them to be able to do this, and you will see morale improve as Developers become accountable for their own work.
Prioritizing team morale over delivery
Team morale is undeniably important. High morale can lead to increased collaboration, creativity, and productivity. However, prioritizing morale at the expense of delivery can backfire. A common misconception is that boosting morale requires organizing after-work activities, like happy hours or team-building exercises. While these activities can be fun, they often fail to address the underlying factors that impact morale during the workday.
In my experience, morale improves most when teams work together effectively to deliver value. People want to feel they’re part of a team that achieves meaningful results. A sense of accomplishment and contribution to a shared goal is one of the most powerful motivators for any Scrum team.
Why does it happen?
There are several reasons why a Scrum Master might prioritize morale over delivery: