A team gets a Scrum Master. The Scrum Master runs the standups, keeps an eye on the board, shows up to the retro with a stack of sticky notes. Six months later, nothing about how the team actually works has changed. The standups happen. The retros happen. The team is still stuck.
Dave and I got into why that keeps happening on a recent episode of Definitely Maybe Agile. And the answer isn't really about the Scrum Master. It's about what happens when an organization mistakes a role for a culture.
The Role Got Popular, Then It Got Diluted
Between the two of us, we've spent close to four decades mentoring people into coaching roles. Scrum Master, team coach, agile coach. Dave will tell you the good ones had real impact, and I agree. But as the role spread across the industry, something got lost in the scaling.
We've written before about the risk of forcing one framework everywhere, and the Scrum Master role ended up as a version of the same problem, just applied to a role instead of a methodology.
We both remember spending a lot of time pushing back on a question nobody had a good answer for. What value does an agile coach actually create? Not in theory. In dollars, in outcomes, in something you could point to. That question never got answered consistently. It got arm-waved away instead.
We've tried to answer that question more directly elsewhere, laying out what a Scrum Master's value actually looks like when the role is done well.
The Real Product Was the Culture, Not the Role
Dave argues the value organizations were actually after was never the role itself. It was a culture of continuous improvement. And once you have that culture, a dedicated role for it stops making much sense.
That's a real shift in how to think about the problem. If continuous improvement lives in one person's job description, it's fragile. It disappears the moment that person leaves, gets reassigned, or gets cut in a reorg, which is exactly what's been happening to a lot of these roles lately. If continuous improvement is something every team member carries into how they solve problems, it survives the org chart changing around it.
Think of continuous improvement as like a lumberjack sharpening their axe. Organizations working flat out don't have time to sharpen the axe that would let them work better. So they don't, until the axe is so dull that someone has to bring in an outside expert to sharpen it once and leave again. It stays sharp for a while. Then it goes dull, because the sharpening was never built into how the team operates day to day. It was episodic. A one-off fix, not a habit.
What the Andon Cord Actually Teaches
I brought up Toyota's andon cord on the episode, the mechanism on the production line that lets any worker flag a problem. I got the number wrong when I said it live (I threw out something like 10,000 times an hour, which, on reflection, was way off). The number I should have used is this: a widely cited 2007 BBC report found workers at Toyota's Georgetown, Kentucky plant pulling the cord roughly 2,000 times a week. At a comparable Ford plant in Dearborn, Michigan, workers were pulling it about twice a week.
Same country. Similar equipment. Wildly different numbers. Nobody seriously believes Ford's line had a thousand times fewer problems. The gap was about whether workers believed it was safe, and expected, to flag something the moment they saw it.
We've written before about how psychological safety is the real engine behind continuous improvement, and the andon cord is that idea made physical.
That's the point Dave and I were circling during the episode, translated into organizational terms. A cord that never gets pulled doesn't mean nothing is wrong. Often it means the opposite. People have learned that raising a problem gets treated as a disruption rather than useful information, so they stop raising it. In a lot of organizations, the response to a flagged problem isn't "what can we learn here." It's "how fast can we get the line moving again." That's a different mindset, and it produces a very different culture over time.
Where AI Fits, and Where It Doesn't Answer Everything
We got into AI near the end of the episode. Agile, at its best, accelerated experimentation and learning. Could AI do something similar? And if it can, does that mean the dedicated coach role becomes less necessary?
Whether it's Agile, a Scrum Master, or AI, none of these were ever meant to be permanent fixtures. They're steps toward something else: an organization that has absorbed the habit of experimenting, learning, and adjusting into how it actually works, instead of outsourcing that habit to a role, a framework, or a tool.
The thing I keep coming back to isn't really about AI at all. It's recognizing the moment when continuous improvement stops being something a role is responsible for and becomes something the culture just does, the same way a good team eventually stops needing someone to remind them to talk to each other.
Most organizations never get there. They keep hiring the role, watching the axe go dull, and bringing in someone new to sharpen it. So here's the question I'd ask you right now: would your team notice if that person left tomorrow? Or has the habit they were supposed to build actually become the team's own?
This post draws from a recent episode of Definitely Maybe Agile with hosts Peter Maddison and Dave Sharrock. You can listen at definitelymaybeagile.com.