I’ve seen this argument many times—“Scrum Masters are the most useless role in tech [1, 2].”
It usually comes from two places: a team that’s already reached full Agile maturity (which is rare) or an organization that never really understood what the Scrum framework was designed to do.
While personal experiences vary, it’s important not to confuse the tasks of a role with the purpose of a framework. Scrum isn’t just a collection of meetings or ceremonies; it’s a deliberate system built to help teams deliver value consistently and sustainably. Each role—Product Owner, Developer, and Scrum Master—is intentionally defined to keep that system balanced.
1. The Scrum Master Is Not a Process Administrator
The idea that “anyone can volunteer to manage the process” misses the point.
A Scrum Master isn’t there to schedule meetings or enforce rules. Their primary role is to coach the team and maintain the framework.
If an engineer “volunteers” to take on that responsibility, their attention will always remain split—and rightly so. Their priority is coding and building. But a dedicated Scrum Master focuses entirely on how the work gets done: removing impediments, improving flow, and safeguarding the team from distractions.
Without that focus, the system degrades over time. The team becomes reactive instead of adaptive.
2. Self-Organization Doesn’t Just Happen
Another common point is that “self-organized teams don’t need Scrum Masters.”
That’s true—once they’re there.
But self-organization is the destination, not the starting point.
Teams don’t automatically evolve into high-performing, self-managing units. They get there through intentional coaching, trust-building, and continuous reflection—all core parts of the Scrum Master’s work.
The irony is that when you see a team thriving without a Scrum Master, it’s often because they were guided by one in the past. Their habits, discipline, and mindset didn’t appear out of thin air.
3. It’s Not a Question of Headcount
The claim that “it’s better to hire one more engineer than a Scrum Master” is a false comparison.
Hiring one more engineer increases your team’s capacity—the amount of work you can produce.
Hiring one skilled Scrum Master improves your effectiveness—the quality, speed, and clarity with which the whole team delivers that work.
A good Scrum Master doesn’t write code. They make sure your engineers can.
They remove friction, clarify goals, and nurture a system that scales performance across multiple people and roles.
The Bigger Picture
Agile frameworks were designed to sustain high performance, not just enable it.
The Scrum Master’s purpose is to maintain the health of that system—to ensure that collaboration, focus, and continuous improvement don’t fade when deadlines, politics, or fatigue set in.
When the system works, the Scrum Master becomes almost invisible.
That’s not uselessness. That’s mastery.
References
[1] https://www.reddit.com/r/agile/comments/1gso2fp/scrum_master_is_a_useless_role/
[2] https://medium.com/@daxx5/scrum-masters-are-the-most-useless-role-in-tech-dbc10bdd433a
