Are Scrum Masters Too Much Overhead?
The Unfortunate Tendency of Scrum Masters to Make Scrum Overimportant
I have a surprising confession to make: when I was working at start-ups or scale-ups, I never wanted to hire a separate Scrum Master.
Yes, you’re reading that correctly: never.
I wanted to do Scrum without separate Scrum Masters. I thought the risk of hiring someone and them just becoming overhead and slowing things down was way too high. Even in the Netherlands, the country with the highest number of Scrum Masters per capita in the world. I didn’t want Scrum to become the thing we focused on above everything else.
I wanted our Scrum to be very much in the background, which I believe is infinitely easier without a Scrum Master who constantly tries to bring it to the forefront.
My thinking on this matter was shaped by a team sport I played during university: Ultimate Frisbee. I will use my experience of playing Ultimate Frisbee to explain why I believe that Scrum Masters often represent way too much overhead, especially for start-ups and scale-ups.
Ultimate Frisbee: A Team Sport without Referees
At university, I used to play Ultimate Frisbee. Ultimate Frisbee is a fast-paced game with a frisbee with lots of diving and long-distance throws. The founders of WhatsApp, Koum and Acton, met each other while playing Ultimate Frisbee together.
What’s unique about Ultimate Frisbee, is that every player serves as their own referee. Ultimate Frisbee has a ‘Spirit of the Game’, which means that the responsibility for fair play, sportsmanship and adhering to the rules is placed on every player.
There are upsides and downsides to this system, but two key characteristics stand out:
Every player has to intimately understand the rules of the game.
Almost no player foul will ever be missed, because any player can call a foul on any player.
Point 2 is especially important. You might have seen sports games where a foul is missed by the referee, which completely changes the course of the game. A good example is Diego Maradona's Hand of God goal at the 1986 World Cup.
Argentina was facing England in the quarter-final when someone made a pass to Maradona that he wasn’t able to reach with his head. In an instant, he decided to use his hand to hit the ball towards the goal. He scored a goal that should have been disallowed, yet Argentina ultimately won.
This would never happen in Ultimate Frisbee. Someone would have seen the hands and called it. Period. This is one of the advantages of having players as referees. Everybody has to understand the rules, and everyone can call a violation of the rules.
There are also disadvantages to no referees due to players having skin in the game. Because players really want to win, they aren’t objective, and their judgment becomes clouded. That’s why higher-level Ultimate Frisbee games sometimes also have observers who can help if players can’t reach an agreement over what happened.
How does all of this Ultimate Frisbee talk relate to the realm of Scrum?
You Don’t Need a Scrum Master to Do Scrum
My experience with Ultimate Frisbee shapes my perspective on Scrum: I believe you don’t need a separate Scrum Master to do Scrum, just like you don’t need a referee in Ultimate Frisbee.
I will try to argue this point by considering two very different perspectives people may have on how Scrum Teams should be doing Scrum:
Understanding Scrum is crucial and should be at the forefront of everything the Scrum Team does.
Scrum is unimportant and should move to the background as quickly as possible.
Let’s argue from these two different vantage points what this ultimately means for the Scrum Master accountability.
Scrum at the Forefront
If understanding Scrum is crucial, and should be at the forefront of everything the team does, then the inevitable conclusion is that, just like with Ultimate Frisbee, everyone on the Scrum Team has to have an intimate understanding of Scrum.
If this is the case, then having a Scrum Master is an anti-pattern or something temporary until the whole team understands Scrum really well. In Ultimate Frisbee, we don’t have a referee who teaches players the rules of the game or what Spirit of the Game means.
Having a separate Scrum Master will be a lot of overhead, especially at start-ups and scale-ups. There usually aren’t that many organizational impediments to Scrum to begin with, besides maybe a lack of knowledge or experience with Scrum, but since Scrum is a few decades old, this should become increasingly rare.
Now let’s argue the opposite point, which I actually support, that Scrum should be in the background.
Scrum in the Background
Scrum is a purposefully incomplete framework, which should support the Scrum Team in discovering their own way of working on top of Scrum. This means that ideally Scrum should very quickly move to the background, and rarely be a topic of discussion.
It’s like when you’re playing a game of Ultimate Frisbee or any other sport that has clear rules. If you’re constantly discussing the rules of the game, what they mean, and how to interpret them, then the game will be shit. You should be playing the game of Scrum, and the rules are there to serve the game.
Unfortunately, Scrum is rarely in the background and this is a big problem in the Scrum community. It’s absolutely insane how many questions are being asked from the perspective of Scrum, which is completely irrelevant.
This is why I stopped responding to many questions on Reddit. I get incredibly sad from the Scrum tunnel vision questions that are often asked. It’s the same Scrum noise over and over again. Repeatedly answering the same Scrum delusional nonsense questions feels like a complete waste of my time.
Scrum is purposefully incomplete, it’s not supposed to give you the answers. At best it may show you some of your problems, and then you have to figure out how to solve those problems on your own.
Don’t go looking for the Scrum Guide for answers, which is the opposite of what many Scrum practitioners do. The begin asking silly questions like how do we do X in Scrum, instead of asking what would be the best for our situation?
In short, both when Scrum is at the forefront or in the background, it’s a really bad sign that you need a separate Scrum expert to keep things running.
Should the Scrum Master Make Themselves Redundant?
There is a popular saying in the Scrum community that the Scrum Master should work to make themselves redundant.
I never really liked the sentiment that Scrum Masters should work to make themselves redundant. This statement implies that the default assumption is to start with a separate Scrum Master who will disappear and dissolve in the Scrum Team over time.
If you want to begin with Scrum, ask yourself the following question: Do we need a separate Scrum Master? If the answer is yes, then why do you believe you will need one?
In this article, I argued that needing a Scrum Master is an anti-pattern and potentially introduces unnecessary overhead.
There are cases when a separate Scrum Master may make sense. Especially at bigger companies, with lots of organizational dysfunctions and struggles that limit the ability to do Scrum effectively. You definitely need someone to help resolve these impediments and obstacles.
However, how effective are Scrum Masters at resolving these obstacles and challenges? In my experience, Scrum Masters usually fail to change the company, which means you’ve got overhead that’s not pulling their weight.
What happens most frequently is that the company changes Scrum to fit its context, and Scrum doesn’t change the team's working conditions. If that's the case, then your Scrum Master is just overhead, as you’re not doing Scrum, but you’re paying a Scrum Master to pretend you’re doing Scrum.
The biggest thing that worries me is that after multiple decades of doing Scrum, there are still so many Scrum misunderstandings and misconceptions. After all the certifications and workshops courtesy of the Agile Industrial Complex, I don’t think we made any huge strides. We’re still bumping in the same problems and discussions.
Maybe the biggest flaw of Scrum is that it’s designed with the Scrum Master in mind. If you need a separate person to explain the game's rules, maybe the rules aren’t all that great.
Unfortunately, this reflection will immediately be silenced because whenever someone doesn’t follow Scrum and it fails, someone will utter the cultish words “Of course it didn’t work. You weren’t doing Scrum.”
The point of Scrum isn’t to do Scrum. It should support you in discovering your own way of working that helps to maximize the delivery of value. Does that ever happen? This is rare because often, Scrum Masters don’t place Scrum in this supporting role but at the forefront.
Scrum doesn’t matter all that much for building great products. It’s everything else you do outside the realm of Scrum that makes the biggest difference.
When Scrum adherence remains at the forefront of your discussions, you can forget about ever succeeding with Scrum.
The idea that everyone knows Scrum’s rules is often wrong. Many stakeholders and leaders only understand the basics. But professional Scrum is hard and disruptive because it forces organizations to face uncomfortable truths. That’s where the Scrum Master steps in—as an agent of change, guiding teams to self management.
Scrum’s iterative process is much harder than waterfall. Every iteration requires addressing complex tasks, demanding stronger discipline. Without the Scrum Master driving real change, Scrum becomes mechanical, just checking boxes. Their real value isn’t in running events but in helping teams evolve and adapt.
I enjoyed reading the article and the ultimate frisbee analogy fits well.
As a founder, I would consider hiring a Scrum Master at the point that:
> we've reached the size that someone needs to facilitate events - both for the team and the rest of the company. Groups don't naturally do a great job in meetings without someone neutral facilitating.
> we need someone to help find alternative practices, techniques and frameworks. Yes, "find what fits your team" is good guidance, however the team may have no idea about what to try.
> we need someone to look across the company to spot inefficiencies. 20 years ago our startup had many dysfunctional processes beyond the team. Our Scrum Master did a great job cleaning them up one by one.
I could go on. Net - the "overhead" can be valuably leveraged for organizational success.