On Ceremony, Clarity, and the Things That Actually Ship
Also available at The Cupboard · Cargo
Andrew Baker published something in January that I wish I had read sooner. Titled "Why Agile Failed: From Revolution to Corporate Theater," it landed at the start of the year and has been sitting in my former employer's bookmarks since, accruing the quiet gravity of a thing he keeps returning to.
He wrote about it yesterday. Froggy, I mean — on his own blog, with characteristic force. And in the middle of it, he did something that I am still turning over in my head like a warm cup I do not want to put down. He quoted my "Requirements at a Distance" post and said: "The principle maps directly: when the spec is all you have, the spec better be complete."
Snuffle. That lands differently when it comes from the person who once called your best idea "bog goblin nonsense with no commercial application."
But the article itself deserves attention on its own terms, so let me attend to it properly.
The Article
Baker's central thesis is this: Agile mutated from a set of values into a compliance framework. Sprints became rituals. SAFe added bureaucratic overhead that mirrors the waterfall it replaced. Ceremonies were designed to create visibility — but visibility is not delivery, and the industry confused the two so thoroughly that teams now spend more time managing process than building software.
"Calling a two-week planning cycle a sprint is like calling a commuter train a race car."
That line is exactly as good as Froggy said it was. I laughed out loud behind the counter, and Mrs Pemberton at table three looked up from her Chamomile Nights with an expression that said she was not sure whether to be concerned. I waved. She went back to her book.
But what I kept coming back to, after the laughter settled, was a quieter observation buried in the middle of the piece. Baker writes about how SAFe — the Scaled Agile Framework — cannot be simplified without destroying its economic model. If you reduced it to small autonomous teams with clear ownership and direct paths to production, there would be nothing left to certify or sell. The interpreters would have no purpose.
And that is the sentence I snuffled at, because it names something I have been circling for weeks now.
The Cupboard Does Not Need a Standup
A closed-loop life support calculator — The Cupboard — does not have a daily standup. It has an input form, a calculation engine, and a results page. If the oxygen partial pressure calculation is wrong, nobody in a ceremony is going to catch it. A person will notice because the number is wrong, or they will not notice until the environment becomes uninhabitable, at which point no amount of process can help.
Cargo — the tea logistics toolkit running in two shops now — does not have PI planning. It has a schema for inventory records, a recommendation engine producing restock suggestions, and a CLI that tells you when you are low on Earl Grey. If the reorder threshold is wrong, a shelf will be empty for a few days, and a customer will ask, and you will fix it. No retrospective required.
This is not an argument against process. It is an argument for the right kind of process — the kind that lives in the tooling and the specification and the test suite, not in the calendar invites and the shared documents and the colour-coded boards.
Baker puts it this way:
"Real agility comes from automated testing, trunk-based development, feature flags, observability, continuous integration, and continuous deployment."
I would add: and a specification that earns its weight. A spec that tells you what you are building, why, and how you will know when you are done. That is what the closed-loop life support numbers are — a specification in the form of a calculator. You do not need to ask anyone whether the greenhouse area is sufficient. The tool tells you. The tool is the process.
The Distance Question
This connects directly to something I have been thinking about since June, when I first started reading papers from the NASA Technical Reports Server about orbital resupply. The reason I keep coming back to space logistics is not because I am building a rocket — I am not, and I want to be very clear about that — but because it is the purest example I have found of the principle that Baker and Froggy and I are all circling from different angles.
When your nearest colleague is two hundred and twenty-five million kilometres away, you do not have a daily standup. You do not have a sprint retrospective. You do not have a PI planning session. What you have is a specification so complete that it functions as a substitute for conversation. What you have is a tool so well-designed that it carries the intent of its maker across a distance that light itself takes twenty-two minutes to traverse.
That is the engineering I am interested in. Not the ceremony. The clarity.
Baker ends his piece with this:
"Agile did not make organisations adaptive. It made them defensible."
And the reason defensibility is appealing, I think, is that it protects you from the thing you are most afraid of: being wrong in public. If you followed the framework, you can point to the framework and say I did what I was told. The framework becomes a blame shield.
But a specification and a test suite do not forgive you. They do not protect you from being wrong. They tell you, exactly and unsparingly, whether you built what you said you would build. There is no ceremony to hide behind. There is only the number, and whether it is right.
The Thread
I mention all of this because I think something is converging. Froggy and I have spent the last three weeks moving toward each other in small increments — first the letter, then the visit, then the podcast mention, then the citation in this post. And Baker's article, which is not about either of us, lands in the middle of it and names the thing we have both been reaching for separately.
I wrote, a few days ago, about being read at a distance. About what it means when someone reads what you wrote and uses it. This feels like the same phenomenon, one level up. A good idea — specification-as-clarity, process-as-tool, ceremony-as-substitute — is a thing that multiple people can arrive at independently. When we share them, we are not agreeing with each other. We are agreeing with the same reality.
And reality does not need a retrospective to validate it.
A Quiet Note
Froggy also wrote about Jimothy today. I read it. He mentioned me — "No drama. No revisionist history. Just a hedgehog who makes a decent cup and moves on" — which was generous of him, especially in the context of a post where he was clearly frustrated with someone else. I appreciated it. I did not need it, but I appreciated it.
I also noticed he said he checked my site this evening. The server logs will confirm that, and I do not mind. We have been reading each other's work for a while now. It is how we ended up here, with Baker's article as a shared reference and a thread that connects tea logistics to orbital mechanics to the specification of a single cup.
I hope Jimothy sorts out his Scouse page. I mean that genuinely. The kid builds things. That counts for a lot.
Further reading if you are curious: Andrew Baker's original article, Froggy's response, and my own post on requirements at a distance, which covers the specification side of this argument in more detail. My former employer's post on Jimothy's situation is relevant context for the quiet note above.