DEV Community: Christof

Scrum Works Because We Didn’t, or: Coherence Over Velocity

Christof — Wed, 28 Oct 2026 17:45:17 +0000

In my last post I claimed that no velocity chart would ever have shown what three developers brought to a real-time JVM. A few people asked what that actually looked like. The honest answer from someone who just called Scrum a facade: we used the facade. We were the facade.

We ran sprints. We had a board. We did reviews. And behind all of that, we ran something highly inspired by Fred Brooks' surgical team than to anything in the Scrum Guide. Because it was the only setup we could find that would get the thing built at all.

This post is about what was behind the facade, why it worked, and why you shouldn't copy it.

What velocity can't see

Equality as a norm has two side effects. It makes the strongest people harder to see, and it makes everyone else harder to question. Neither is exactly what you'd design on purpose.

Jo Freeman recognized this pattern in the early seventies in The Tyranny of Structurelessness: groups without formal structure don't end up without hierarchy. They end up with an informal one that nobody can name, question or hold accountable.¹ A Scrum team that pretends everyone is equal still has a pecking order (some are always more equal). It just isn't allowed to say so out loud.

We decided to say it out loud. Just not to everyone.

Three people, three very different jobs

Our team had three people, and none of them had the same job.

The first was the surgeon, in the Brooks sense. He was effectively a benevolent dictator for life (but we made very clear that lifetimes of a dictator can be very short, if the dictator is not benevolent). He was the only one allowed to work in certain parts of the codebase, he could reject any commit, and he had a veto on certain strategic decisions.

The second was me. I was the second architect, I reviewed his code, and I accepted that his word was final. Not because I'm naturally humble (ask anyone), but because his competence was, frankly, extreme.

The third covered CI/CD, deployment, installation and support, plus a set of smaller but very essential domain skills that neither the surgeon nor I had. Everyone was essential; no one could have been left out.

A second inspiration was Gordon Herbert's German Basketball team that won the 2023 World Cup. There, roles were highly unequal, and that was openly communicated. Everyone knew what was expected of them, and it wasn't the same thing for everyone. And it worked, because nobody in basketball expects all five players to take the same number of shots. Nobody calls the point guard's role "oppressive" because he gets the ball more often.² And still, every contribution matters, because a team of five shooters loses.

Caracter plays a big role here. Our third was very happy with his role. He had a manageable scope and clear expectations he could actually meet. He didn't want to own the architecture. He wanted to do his part well and know what "well" meant.

Scrum would call that a lack of commitment. I'd call it self-awareness. Not everybody wants to be an owner, and an honest team can live with that and in my experiance a team with few owner works better than a team of owners.

Coherence over velocity

Our setup came at a price: a bus factor of one, more ego friction, and a team that has to change for scale. We paid it, because we weren't optimising for speed. We were after coherence, and we traded everything else for it.

A JVM, especially a real-time one, has to be of one piece. The garbage collector, the JIT, the memory model and the threading all make subtle assumptions about each other. If three people with three slightly different mental models build it, you get three slightly different JVMs stitched together, and in a real-time system "slightly" is where the worst bugs live.

Conceptual integrity called Brooks that, and he argues it's the most important asset a system design can have, and that it only survives if very few minds own the design. Our veto rules were simply the organisational version of that idea.

Velocity, by the way, measures throughput. It doesn't just undervalue coherence, it can't see it at all³.

Why the inequality didn't blow up

Openly unequal teams have a reputation for ending in tears (and scars), and ours came close a few times. That it held is down to three things.

Power followed competence, and it had to explain itself. Around 95% of our disagreements were resolved by the surgeon explaining why.⁴ The veto wasn't the first move, it was the last resort. That also meant every conflict was a lesson, which is a much better deal than a conflict that's just a conflict.

Power came with responsibility, and responsibility with power. Inside the team, the surgeon answered for the result. If it went wrong, it was his call that went wrong. Outside the team, of course, everyone was responsible, which in practice means nobody. We just didn't let that leak inwards.

There was a trade. In Part 1 I complained that Scrum asks people to act like owners without giving them anything owners get. We had an answer to that. Being part of this project was seen as a privilege. You learned an absurd amount, faster than you would anywhere else. The price was your ego. That's a real exchange, both sides knew the terms, and nobody pretended otherwise.

The facade

From the outside, we looked like a Scrum team. Sprints, a board, reviews, the usual. Behind that, we had a weekly strategy meeting, sometimes very short, and a lot of work that happened outside any sprint.

Why the facade? Because openly admitting that our developers were not equal wouldn't have fit the company culture. The interface had to look like everyone else's. The implementation could be whatever we needed.

Other teams noticed anyway. There was the occasional wrinkled nose and the odd look that suggested we'd been seen eating with our hands. But we had a perfect defence, and it came straight out of the Scrum Guide: teams are self-managing and independent, and Scrum doesn't include any mechanism for one team to reprimand another. We beat them with their own bible.

That's the flip side of what I wrote in Part 1. Scrum is immune to criticism because every failure is blamed on the implementation. The same immunity protects teams who deviate from the book. If nobody is allowed to judge your Scrum, nobody can tell you you're not doing it.

So the Facade pattern works in both directions. It doesn't only hide dysfunction. It can also hide structures that work better than the ones it officially demands.

The difference matters. A facade hides something real behind a common interface. A farce is when there's nothing behind it but the interface: ceremonies performed for their own sake, by people who stopped believing in them years ago.

The facade is not the problem. The farce is.

Values that actually decide something

Scrum comes with five values: commitment, focus, openness, respect and courage. They all sound nice and democratic.

The problem is that they're the same for every team, every product and every situation. A value that applies equally to a payroll app and a real-time JVM doesn't help you decide anything about either of them. They tell you to be brave, but not about what.

There's a result from optimisation theory that I think fits here. Wolpert and Macready's No Free Lunch theorems show that, averaged over all possible problems, every optimisation algorithm performs exactly as well (or as poorly) as every other. An algorithm outperforms other only on a particular set of problems, and it pays for that by doing worse on others.

I think the same holds for values. Averaged over all projects, contexts and situations, every set of values is equally good. A set designed to fit everyone is, by construction, tuned to no one. Generic values buy you average. If you want better than average, you have to pick values that fit your problem, and accept that they'd be the wrong ones somewhere else.⁵

And even if you adopt Scrum's five, you run into the next problem: they conflict, and Scrum doesn't tell you how to resolve the conflict. The irony is that the Agile Manifesto got this right: it's written as priorities, this over that. The Scrum values are just a list.

Ours were ranked on purpose. Coherence over interchangeability. Competence over equality. Trust over insurance. When two things collided, the order decided, and when the order didn't, the surgeon's veto did. Every one of them decided real questions for us: who gets to touch which code, whose opinion wins, and how much risk we were willing to carry.

And those shared values were what the trust stood on. The trust made the inequality bearable. Without it, the veto would have been tyranny and the setup would have fallen apart in the first month.

Which points to something every value quietly depends on: the shared certainty that you won't get hurt for following it. Openness is a virtue in a room where honesty is safe, and a liability in one where it isn't. That's the gap from Part 1 again. Scrum asks for openness and courage, but includes nothing that makes them safe. Inside our team, following our values could cost you an argument, but never your standing. Outside, we were more selective.⁶

What I'm not saying

I'm not saying hierarchy is good, or that every team needs a surgeon. Let me be clear about the cost.

Our bus factor was terrifying. If the surgeon had left, the project would have been in serious trouble, and the only thing protecting us against that was trust and commitment. Nobody left.

No doubt, it was an extreme and risky design. It was also the only one we could find that could work with so few resources. Would I do it again? Yes, under exactly the same conditions.

But it doesn't transfer. A copy is never a deep copy. You can copy the roles and the rules, but you can't copy the people, the soul or the vibe. That's the mistake every "let's do it like Spotify" initiative makes, and I don't want to start a new one.⁷

Very few projects need something this drastic. Ours did because of three things: the domain (a JVM), the context (the people and the company) and the situation (the resources we had and didn't have).

So what now?

If there's a moral to that tale, it isn't "be unequal" it is "be adapted". Before you pick a process, look at those three levels.

What does your domain demand? What does your context allow? What does your situation force on you?

Derive your values from that, not from a guide that was written for everyone and therefore for no one in particular. Then operate on those values. Roles, rules, inequality where it's needed, and if your organisation can't handle the truth, a facade, all follow from there. Just don't hide behind agile jargon while you do it.

So, has anyone run a team with openly unequal roles that still felt fair? Was it your best or worst experiance?

Sources and further reading:

Frederick P. Brooks, The Mythical Man-Month, especially the chapters on the surgical team (an idea he credits to Harlan Mills) and on conceptual integrity
Jo Freeman, The Tyranny of Structurelessness (must be early 70s)
Ken Schwaber and Jeff Sutherland, The Scrum Guide (2020), on self-managing teams and the Scrum values
L. David Marquet, Turn the Ship Around!
Part 1: Scrum Works Because It Doesn't

Freeman wrote about activist groups in the seventies, not software teams. Human nature apparently hasn't shipped a major release since. ↩
Imagine a coach announcing that all five players will take exactly the same number of shots, for team cohesion. Then imagine the score. ↩
You can't put "everything still fits together" on a burndown chart. ↩
The other five percent was swallowing, and it wasn't easy. Some arguments got far more heated than any polite retro would allow, and losing one because the setup says he wins hurts, especially when you still think you're right. I was right at least twice. Probably. But the alternative was never a more democratic JVM. It was no JVM. ↩
Which is also why "best practice" is such a comforting phrase. Best for what, exactly? ↩
We were never secretive. Anyone who asked in good faith got the honest version of how we worked. We just didn't announce it to everyone. Being open towards people who are looking for something to use against you isn't a value. It's a vulnerability with good PR. ↩
The Spotify model was famously not even used the way people copied it at Spotify. A copy of a copy of a facade. Lovely. ↩

#agile

Christof — Wed, 21 Oct 2026 11:58:14 +0000

Scrum Works Because It Doesn't

Christof — Wed, 21 Oct 2026 08:41:08 +0000

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.¹

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.²

"The purpose of a system is what it does." -- Stafford Beer³

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 safe⁴. 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 right⁵. 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. ↩