Over 60% of Scrum Masters are not fulfilling the accountability of their role.
That’s not a Reddit take. It comes from Scrum Match – a company that connects Scrum Masters with organizations through in-person assessment interviews. Not surveys. In-person reviews.
The number is uncomfortable. What makes it more uncomfortable is that most of the people it describes are trying hard. They show up. They run the ceremonies. They care about their teams.
The problem isn’t effort. It’s the ideas they were taught.
At Agile Tour Vienna 2025, Armin Mandara – Agile Team Coach and former Head of Agile Practice at IBM iX – made the case that the Scrum Master role has been defined in ways that set practitioners up to fail. Three specific antipatterns, baked in from the beginning, that good intentions can’t overcome.
This article covers those three antipatterns, the research and cases behind each one, and what the role actually needs to become.
The Scrum Guide defines the Scrum Master’s accountability in its very first sentence: „accountable for establishing Scrum as defined in the Scrum Guide.“ By definition, a Scrum Master is an advocate and executor for Scrum. Not for outcomes. Not for delivery. For a framework.
The job market reflects this. Capital One eliminated over 1,100 Agile roles in 2023. Their statement was explicit: the Agile roles had been „critical to our earlier transformation phases“ but the organization had matured. The Hacker News thread that followed was blunter. Scrum.org’s response identified the pattern: the Scrum Masters who survived weren’t the ones who facilitated ceremonies most effectively. They were the ones who had expanded their impact beyond the team.
Bertrand Meyer, the French computer scientist, made the same argument in Agile: The Good, the Hype and the Ugly in 2014: „The Scrum idea of a dedicated scrum master is good for Scrum but not appropriate for most projects. Good development requires not just talkers but doers.“ That was over a decade ago. The criticism has been sitting in the literature since then.
From the earliest stages of a Scrum Master career, the role is defined around changing how people think. The underlying logic: if people have the right mindset, the right behavior follows.
The problem isn’t with the logic. It’s with difficulty. Changing someone’s established attitudes – their mindset, in the organizational psychology sense – is something trained therapists and psychologists find genuinely hard. Yet we expect coaches with no psychology training to do it routinely. And when it doesn’t work, the convenient explanation is: „They don’t have an agile mindset.“
That’s where the second problem lives. „Mindset“ becomes an explanation for failed change that locates the failure in other people rather than in the approach. If the team isn’t collaborating the way you want, they don’t value collaboration. If they’re resistant to ceremonies, they’re not agile thinkers. The Scrum Master’s inability to introduce change effectively stays invisible.
Schiphol Airport in the 1990s had a problem with spillage at urinals. The obvious approach: signs, awareness campaigns, a manifesto for respectful restroom use. What they actually did: placed a small fly image inside each urinal. Spillage dropped by an estimated 50–80%. Cleaning costs fell by 8%.
No mindset change required. A behavioral intervention that worked because it changed the environment, not the person.
Jerry Sternin, the activist and social change practitioner, framed the principle clearly: it’s easier to act your way into a new way of thinking than to think your way into a new way of acting. Armin applies this directly to Scrum Master practice. Instead of coaching people toward collaboration as a value, ask: what does collaboration actually look like in this team? What specific behaviors would you observe? And then: what change to the environment or the work would make those behaviors more likely?
The behavioral economics literature on nudging makes the same point at scale. A powerful Scrum Master manages the system, not the mindset of individuals within it.
This is the one that provoked the most pushback in the room.
Earlier in the conference, two speakers had gently suggested that some technical familiarity might be useful for Scrum Masters. The audience Q&A that followed was defensive rather than curious. The objections were variations on a theme: technical knowledge isn’t the role, it might interfere with coaching, it creates bias.
Armin’s response: a Scrum Master with technical understanding will always be more effective than one without. Not because they need to write code – but because without it, they can’t evaluate whether a technical discussion is worth letting run, they lose credibility with engineers who care about their craft, and they default to the only tools they have: process facilitation and mindset coaching. Which brings us back to the antipattern one.
His recommendation: go back to Extreme Programming. Much of what we take for granted in Agile – continuous integration, test-driven development, pair programming, refactoring – came from XP and its emphasis on engineering discipline. Scrum won the adoption war. It didn’t necessarily win on merit.
The Scrum Guide says a Scrum team is self-managing: „they internally decide who does what, when, and how.“ That’s all it says. Self-managing means the team manages its own work.
Somewhere along the way, this became: the team should surface its own problems, the team should ask for help if it needs it, the team should never become dependent on the Scrum Master. And the highest aspiration of the Scrum Master became redundant.
The consequences are what Armin describes as a „defensive crouch.“ The Scrum Master becomes careful about which tasks they take on, anxious about being seen as too involved, unwilling to challenge the team directly because that might make the team need them more. The result: a role that makes you feel like a failure when the team needs you, and an impostor when they don’t.
This was designed from the beginning. The goal of making yourself redundant is not a motivating frame for any role. And it’s not actually what high-functioning teams need.
At IBM iX, Armin’s team eventually renamed the role entirely. Scrum Master became Agile Delivery Lead. Agile – framework-agnostic. Delivery – actual accountability for something. Lead – not a supporter, a leader.
They expanded the required skills: technical concepts, software development lifecycle, product management basics, delivery ownership. The Certified Scrum Master training with Mitch Lacey is worth approaching in exactly this spirit – as a starting point for understanding the principles behind iterative delivery, not as a credential that defines what the role is.
The job description changed to match what the role actually needed to be. That sequencing matters: they didn’t rename the role to signal aspiration. They changed the skills, then changed the name to reflect what the role had become.
Teams struggle – with culture, quality, accountability, honest conversations, the gap between what they ship and what customers need. Organizations struggle with coordinating work across teams, connecting delivery to strategy, getting the right things done rather than just more things done.
There is a version of the Scrum Master role that helps with all of this. It takes ownership rather than facilitating around it. It challenges the team rather than asking the team what it wants. It understands the technical context rather than staying safely above it. The Advanced Certified Scrum Master program goes into exactly this territory – coaching at the organizational level, leadership impact, the kind of accountability that makes the role genuinely hard to eliminate.
The criticism of the Scrum Master role from the engineering community isn’t new, and it isn’t unfair. The practices that created the harmless Scrum Master – the focus on mindset over behavior, the absence of technical depth, the passiveness justified as respect for self-organization – were taught as virtues. They were well-intentioned. They were wrong.
The role has earned its place. It just needs to grow into it.
Armin Mandara spoke at Agile Tour Vienna 2025. Watch the full talk: Scrum Masters, you need to do better! The 2026 edition is live – the full program is available now.
Build your solid foundation through our training and continue developing your leadership and coaching journey.