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 that 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:
A desire to shield the team from pressure
Scrum Masters may feel protective of their teams, especially if external stakeholders are overly focused on deadlines or delivery metrics. While this protection comes from a good place, it can inadvertently shift the focus away from achieving the Sprint Goal.
Misunderstanding of what drives morale
Some Scrum Masters may assume that creating a “fun” environment or planning non-work activities is the best way to boost morale. In reality, morale often suffers when teams struggle with unclear goals, misaligned priorities, or frequent interruptions.
Trying to address symptoms instead of root causes
If the team seems disengaged or frustrated, the Scrum Master might look for quick fixes, like organizing social events, rather than digging into the root causes of dissatisfaction.
What to do instead:
The Scrum Master should focus on fostering an environment where the team can thrive by delivering value. Here are some steps to consider:
Leverage the Sprint Retrospective
Use this event to identify challenges that are hindering morale. For example, are team members facing unclear expectations, constant interruptions, or an unmanageable workload? By addressing these systemic issues, you’ll often see morale improve naturally.
Help the team connect with the purpose of their work
Developers are more likely to feel engaged and motivated when they understand how their work contributes to the organization’s goals or improves customer outcomes. Scrum Masters can facilitate this connection by encouraging the Product Owner to share the “why” behind the work in the Product Backlog.
Promote ownership and autonomy
When teams are empowered to self-manage and make decisions about how to accomplish their goals, they develop a sense of pride and accountability. This ownership is a powerful driver of morale.
Celebrate successes
Acknowledge the team’s accomplishments, big or small. Celebrating the completion of a challenging Sprint Goal or reflecting on how far the team has come can reinforce a sense of achievement and camaraderie.
By focusing on the factors that genuinely influence morale—clear goals, collaboration, and empowerment—the Scrum Master can create a more sustainable and productive environment for the team.
Conclusion
Great Scrum Masters are invaluable. They help the Scrum team by improving the adoption of Scrum and helping people collaborate together. Scrum Masters promote clarity of responsibilities, which prevents tension within the team. But Scrum Masters themselves often need time to grow into their role. Signup for Rebel Scrum's Professional Scrum Master course to learn more about the Scrum Master accountability in Scrum.