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.1 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.2 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 all3.
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.4 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.5
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.6
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.7
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. ↩
Top comments (0)