I've lost count of how many "Scrum failed us" posts I've read, and the replies are almost always the same. That wasn't real Scrum. Your framework isn't broken, your fundamentals are.1
I don't think Scrum is dead or broken, and I won't bash it. I actually think it's one of the most successful ideas our industry has produced. That's not a niche thing: in VersionOne's 10th State of Agile survey, 58% of respondents ran plain Scrum and another 17% some Scrum hybrid. I just believe it's successful for almost the opposite reason its fans give: hardly anyone implements it the way the Guide describes, and the version companies really run gives them something they want more than high performance.
A theory that can't lose
The Scrum Guide says it right there in its end note: the framework is "immutable", and if you only use parts of it, "the result is not Scrum". The community happily took it from there. If Scrum works, that's Scrum. If it doesn't, it wasn't real Scrum. And if it was, the problem is your company, your team or you. An idea that explains every outcome doesn't explain much.
Ask agile coaches how many teams they've seen doing it by the book and the honest answer is usually: not many. The numbers point the same way. In 2016, Ron Jeffries, one of the Agile Manifesto authors, counted 388,000 Certified ScrumMasters but only 82,000 certified Product Owners. So roughly four out of five teams didn't even have a trained PO. Good luck doing it by the book. If that's true, "they're doing it wrong" stops being an excuse and becomes the main theme. To me, it shows that Scrum is an operating manual for a world that doesn't exist: a world full of people with no fear and giant guts, where every developer thinks like a small business owner and is otherwise a perfectly interchangeable Joe Average.2
"The purpose of a system is what it does." -- Stafford Beer3
Ownership without the upside
For a brief moment put yourself the business hat on and now read the Scrum Guide, it describes something closer to a small company than a team of employees. The team is "self-managing" and decides internally who does what, when and how. The Product Owner is responsible for the value of the product, the developers for quality and for hitting the Sprint Goal.
The pay, though? Exactly the same. Founders get equity, sales people get commission, managers get bonuses tied to results. A Scrum team that supposedly owns the outcome earns the same whether the product takes off or quietly dies. Developers don't lose money when things go wrong, so I wouldn't call it unpaid risk. It's more that Scrum asks people to act like owners while giving them none of the reasons owners have. The Product Owner gets the worst of it: real accountability on an ordinary salary.
Then there's how exposed people are. Scrum runs on transparency, but the transparency goes up the ladder and the consequences come back down. Saying you're stuck in the Daily means saying it in front of the people who'll write your next review. Scrum assumes the safety to do that is already there. Nothing in it creates it. Jeffries himself wrote that Scrum "can be very unsafe for programmers".
If you're a senior engineer who could find a new job next month, that's fine. If you're junior, new, or simply can't afford to lose this job, it's a lot to ask. So people do the sensible thing: talk ownership, avoid ownership.
Where the bending goes
When people explain broken Scrum, they usually blame management. Jeffries calls it "Dark Scrum": the version where the ceremonies turn into a way of controlling developers, and that definitely happens. But it is's only half the story.
Developers bend Scrum too, and in my experience they almost always bend it the same way: towards more safety and less personal responsibility. Estimates get padded until the sprint feels safe4. The Daily slowly turns into a status round where everyone says enough to sound busy and nothing that might start a conversation. Sprint Goals quietly become lists of tickets, so there's no single outcome that could visibly fail. Retros end with "we should communicate better".
Scrum's habit of calling everyone just a "Developer" helps with this. Points and velocity belong to the team, not to people. I don't believe in the 10x developer, but some people bring something to work that others just don't. I once worked on a team of three developers who built a real-time JVM, and no velocity chart would ever have shown what those three brought. That makes the strongest engineers harder to see, and it gives everyone else somewhere to hide. In the end all the meetings are still there, but the risk has gone. We followed the process. The team committed to it.
Is that laziness or a failure? I don't think so. Given everything above, it's the rational thing to do.
The deal
So Scrum is rarely done properly, it doesn't protect people much, it doesn't reward ownership, and teams bend it towards safety. Why is it still everywhere?
I think it's because of all that, not in spite of it.
Scrum can offer companies a deal nobody says out loud: you can call it Scrum without changing anything that matters. You keep the hierarchy, the yearly budget, the fixed-scope contracts and the performance reviews. You add a few meetings, give the project manager a new title and move the tickets onto a board.
And pretty much everyone comes out ahead. Management gets regular cadences, standard reports and a name customers and investors recognise. Developers get shared accountability and a process to point at. Coaches and trainers get a market that never dries up, because "you're not quite there yet" is always true. And the framework itself stays untouchable, since every failure gets blamed on how it was implemented. The surveys even say it out loud: in that same State of Agile report, the most common reason given for failed agile projects (46%) was a company culture at odds with agile values. Translation: the company didn't want to change. Shocking.
A while ago I tried to understand why certain parts of my company kept failing, and why nobody did anything about it. It wasn't incompetence. Everyone was getting something out of the current arrangement, and anyone who tried to change it on their own would have lost their share of the deal first. In game theory, that's a Nash equilibrium: nobody can improve their position by moving alone, so nobody moves. Scrum as practised is exactly that kind of equilibrium.
There's a second reason the deal holds. Organisations don't really want continuous change. They want long stretches of stability where people can get work done, and now and then a real break when the old way stops working. Thomas Kuhn described science like this: normal science, then a paradigm shift. Scrum promises something in between, permanent inspection and adaptation, which is too restless for the stable phases and far too small for a real break. So companies quietly turn it into stability and keep the label.
That's also how the contradiction in this post resolves for me. Judged by what it promises, empowered self-organising teams working at their peak, Scrum doesn't do very well. Judged by what it actually delivers, which is a common interface, predictability, visibility and a fair amount of comfort for everyone involved, it does extremely well. A framework that required real change would have been picked up by a handful of companies. One you can adopt on the surface while it keeps its reputation intact can be picked up by everyone. Strict on paper, flexible in practice. Honestly, that's genius.
What I didn't say
Some will say Scrum only exposes dysfunction rather than causing it. I think this is partly true, but if a tool exposes people without helping them cope, it still has a design problem. Others will say psychological safety is a leadership job, not something a framework can deliver. I'm not so sure. David Marquet, who commanded the submarine USS Santa Fe, describes how small structural changes, like having officers say "I intend to…" instead of asking for permission, pushed responsibility and confidence down the chain of command. Mechanisms can create safety. Scrum just doesn't include any.
So what now?
I don't think Scrum is broken. I just don't think it is what its biggest fans say it is. Scrum is the Facade pattern applied to organisations: a clean interface on top, the same old mess behind it. Every team exposes the same interface (sprints, points, burndowns), while the implementation can be anything at all. That's a big part of why it's everywhere.
It also isn't built for peak performance, and honestly, most companies don't need it to be. They need people they can replace and plans that roughly hold far more than they need a team of stars.
Maybe the more useful question isn't whether we're doing Scrum right5. It's what we actually want out of it. A great team or a predictable one? Who carries the responsibility, and do they get anything for it? Which parts of our process produce something, and which are just there so we can say we followed it?
That applies just as much to SAFe, Kanban or whatever comes next. A framework is a tool, and once you need faith to keep using it, it has probably stopped being one.
So, has anyone out there seen Scrum run exactly by the book and actually turn a team into a high-performing one? Tell me in the comments, especially if you think I'm wrong. I promise I won't call it a fundamentals problem.
Sources and further reading:
- Cover-Image: Da-shika on unsplash
- Ken Schwaber and Jeff Sutherland, The Scrum Guide (2020), especially the end note
- Ron Jeffries, Dark Scrum (2016)
- VersionOne's 10th State of Agile survey, summarised by InfoQ (2016)
- Connie Gersick, "Revolutionary Change Theories: A Multi-Level Exploration of the Punctuated Equilibrium Paradigm", Academy of Management Review 16(1), 1991
- Thomas Kuhn, The Structure of Scientific Revolutions* *(Must Read)
- L. David Marquet, Turn the Ship Around!
- Amy Edmondson, The Fearless Organization
Teamwork: Ideas me
AI: Translation, Research (including Quotes and Numbers)
-
Which makes it a personal and moral failure on your part. Nice! ↩
-
Same logic as "communism works, it's just never been done properly", with much lower stakes. ↩
-
Never disagree with a man with a cool name. ↩
-
Check yourself, is your sprint succes rate near 50%. Congretulations you are doing it honestly. ↩
-
Practicality eats ethics for lunch. ↩
Top comments (2)
the ownership without the upside section is the sharpest part. you're asked to think like an owner about the sprint goal and get paid the same whether it lands or quietly dies, without any of the reasons owners have to care
Thanks. What fascinates me is that hardly anyone seems to notice it, because to me it’s almost painfully obvious and I'm not a PO. The word “ownership” does all the work: companies get owner behaviour at employee prices. It's a nice deal, if you’re on the right side of it.