Originally published in GoRetro
Scrum is by far the most used agile framework in the world. It’s pretty simple to understand, though challenging to implement properly. Over the last years, I’ve worked for many companies and participated in several interviews, but one thing was clear:
Companies often transform Scrum into something slightly different from its original intent.
Executives have a hard time understanding what Scrum is about. Many people perceive Scrum as a set of roles, events, and artifacts. They miss the mindset behind doing Scrum. If organizations do Scrum with the traditional waterfall mindset, Scrum will be nothing more than a flawed process.
One pattern I identified was working with Scrum without a dedicated Scrum Master. Although it may seem odd at first glance, it might make sense depending on your scenario and team seniority.
In this post, I will share my learnings on when it makes sense to have a dedicated Scrum Master and when it doesn’t.
Does it make sense to have a dedicated Scrum Master?
Before we can understand if it makes sense to have a dedicated Scrum Master or not, we should clarify what a Scrum Master is.
Now and then, I read wanted ads for the position of Scrum Master, and they often have nothing to do with the role itself; this strikes me as odd. Even companies willing to hire a Scrum Master don’t comprehend the meaning of the role. A couple of days ago, I stumbled upon this ad for the Scrum Master position at a major German company:
In your role as a Scrum Master, you organize a Scrum Team with a strong focus on customer success, you will continuously develop your skills and increase your knowledge regarding business processes and technology.
You represent the scrum team and organize scrum related sessions.
You support a holistic testing approach including automated and manual tests.
You ensure quality with appropriate KPIs and follow-up activities like root cause analysis.
You contribute as a Single Point of Contact in cross-functional teams for Release Management, Test Management, and other teams like cutover or hyper care.
You plan, manage, and maintain the scope, timelines, and respective progress for the increments in your role.
When I read this ad, I wondered: is the Scrum Master now responsible for the scope and timeline? Is the Scrum Master accountable for quality? Should the Scrum Master also set KPIs? From my understanding, these are not the responsibilities of a Scrum Master.
Until companies understand what Scrum is about, they will not succeed with Scrum.
To better understand the Scrum Master role, let’s look at what the Scrum Guide says about the role of the Scrum Master. In bold is the essential part.
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.
The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.
As you can see, the Scrum Master is accountable for helping the team and organization understand and benefit from Scrum. However, the Scrum Master is a role, and it doesn’t mean a dedicated person must play it. That’s why the organization can decide which strategy to follow.
Immature teams and organizations
Many teams believe they don’t need a Scrum Master because they perceive themselves as a self-organizing team. Such teams think they have already reached their highest potential. Therefore, a Scrum Master seems incapable of adding value to them.
I’ve heard harsh statements from Product Owners and developers during my journey. Some examples are:
Scrum Master is the most useless role ever.
We don’t need a babysitter to take care of us.
Our Scrum Master only slows us down.
Such claims come from immature teams; they over evaluate themselves and become arrogant. From my experience, when Scrum Teams have such an attitude, they potentially need a dedicated Scrum Master. Allow me to share with you what I’ve experienced with such teams.
Executives define unrealistic roadmaps. As a result, business stakeholders pressure developers to deliver more features. Without proper arguments, developers bow to the pressure and rush to provide those features. Given the pressure, developers cut corners and then got surprised with bugs. Suddenly they become firefighters; every day is a new fire to take care of.
The Scrum Team is now trapped; they look like a dog chasing its tail.
Sprint after Sprint, the Scrum Team does not become a better version of itself. They have no time to stop and reflect because they have a lot on their plate. They feel like they are in a vicious circle. Scrum’s pillars slowly drift away; at some point in time, nobody remembers what inspection, adaption, and transparency mean. Still, the team believes they are doing Scrum.
Stakeholders are disappointed because they don’t get what they need. Executives are annoyed because business goals seem unachievable. They are clueless as to what is happening within the team. Yet, these people do not put any effort into collaborating with the developers. They don’t go to the Sprint Review. They don’t provide feedback. But they still think they are doing Scrum.
Such teams need a dedicated Scrum Master. The reasons are simple: the team lacks the maturity to function autonomously. Also, stakeholders misunderstand how to benefit from Scrum. Instead of collaborating, they treat the team as a service provider. In such situations, the person wearing the Scrum Master hat would have a massive challenge ahead of them. From my experience, overcoming such challenges is a full-time job, and I, therefore, cannot see a shared Scrum Master working well. With low maturity, the focus is critical to identify the necessary measures to evolve with Agile.
Mature teams and organizations
Imagine a situation where the organization was born with an Agile mindset. The CEO had a clear vision and then hired people to go on a mission. The Scrum Team has worked together for years now; they have a profitable product on the market. Sprint after Sprint, the team reaches their Sprint Goal and creates value for their users and business.
My question for you is, would this team need a dedicated Scrum Master?
In a scenario where both the organization and team are mature, a dedicated Scrum Master becomes optional. Remember that Scrum Master isn’t strictly a person but a role, and someone else from the team could take this responsibility. Believe it or not, I’ve seen that play out quite well. Here are some examples:
Rotative Scrum Master: Every second Sprint, a new team member plays the role of Scrum Master. This person has to live the Scrum Master accountabilities entirely in combination with their other responsibilities, e.g., development or product ownership.
Product Owner and Scrum Master together: This is a challenging combination, and it requires substantial maturity from the person. In general, there’s a conflict of interest from both roles: Product Owners long for more outcomes, while Scrum Masters focus on balance. Yet, this combination can work if the person is senior enough to separate both worlds.
Developer and Scrum Master together: An experienced developer can be a great Scrum Master. This combination tends to work well because the conflict of interests is negligible compared to the Product Owner.
I want to emphasize that when a person takes on combined roles, it requires a high level of seniority. Also, the environment needs to contribute to agility. Otherwise, that person will quickly become overwhelmed, and Scrum will plunge.
Wrap up
In my opinion, it’s optional to have a dedicated Scrum Master. However, this decision needs to be mindfully done. A poor decision will lead to a suboptimal version of Scrum.
It requires tremendous effort, time, and mindset changing to reach what Scrum promises. That’s why an honest maturity evaluation will help you understand whether you need a dedicated Scrum Master or not.
Scrum isn’t about following the rules, it’s about creating value sooner. High-performing teams use Scrum to help them evolve as a team and create value. They don’t get obsessed with rules and dogmas; they get obsessed with making progress.