Claude, rewrite Venkatesh Rao’s 2018 Use and Misuse of the OODA Loop essay, but it’s about cargo culting the UK government’s Agile Delivery framework.
\nThe Use and Misuse of Agile Delivery: A Cargo Cult Field Guide
\nThe Agile delivery section of the GOV.UK Service Manual is, I suspect, the most widely cited and least carefully read document of practical importance in British public administration. Everyone in Whitehall digital has a view on it. Very few people have a working relationship with it. What most departments have instead is a cargo cult.
\nIn 1974 Richard Feynman described “cargo cult science”: research with every outward form of science and none of its substance. He took the image from Melanesia, where islanders who had watched wartime airstrips bring supplies built their own, with bamboo control towers and carved wooden headphones. Everything was in place except the aircraft.
\nThe image is a little unfair to the islanders, who were reasoning sensibly from what they could see. That is exactly why it fits Whitehall. Cargo culting is not stupidity. It is what intelligent people do when they can observe the outputs of a practice but not the conditions that produced it.
\nThe manual itself is not the problem. By the standards of government guidance it is unusually good: short pages, plain English, a sensible lifecycle (discovery, alpha, beta, live, retirement), and solid advice on team walls, user stories, roadmaps and governance. The trouble is the genre it gets mistaken for. It was written as a description of how good digital teams already behaved, condensed by people who had watched it work. It is routinely read as a prescription that will make any team behave that way if followed closely enough.
\nThat gap between a field guide and a rulebook is where every cargo cult grows. Early GDS teams had stand-ups, walls of index cards and fortnightly show-and-tells. They also had ministerial cover, hand-picked staff, unusual spending freedom and the licence to say no. Only the first list fitted on a slide, so the first list is what got copied. Stand-ups appeared. Walls appeared. The aircraft did not land, and the usual response was to build a better control tower.
\nDrawing the phases
\nMost people meet the guidance as a single slide: four or five coloured boxes in a row, discovery → alpha → beta → live. There’s an arrow, and perhaps a little loop over each box to signal that iteration happens in here. Sometimes a service assessment is pinned between the boxes like a toll booth.
\nThat slide is the first cargo, and it gets drawn wrong in two opposite ways depending on who holds the pen.
\nThe programme office draws it as a conveyor belt. Every box gets entry criteria, exit criteria, a RAID log and a RAG status. Each arrow becomes a gate, each gate a board, each board a pack. This is the drawing of someone who has seen a waterfall plan and been asked to make it look agile: the PRINCE2 Gantt chart in a hoodie.
\nThe evangelist draws it as a mandala. It is one circle labelled “discover–test–iterate”, with no boxes at all, as if naming the cycle were the same as running it. You are meant to contemplate it until the right behaviour arrives. It rarely does.
\nBoth drawings copy the shape and miss the function. A more useful approach treats the phases as a vocabulary for stating what you don’t yet know:
\nRead that way, a phase is not a place you are in. It is a claim about the shape of your ignorance. Different parts of one service can make different claims at the same time: the payments journey can be firmly live while the appeals journey is, honestly, still in discovery. A cargo cult can’t say that, because it only knows which box the slide says it’s standing in.
\nThree cargo cults
\nThe misreadings come in three main varieties. Each copies a different visible layer of the original.
\nThe cult of artefacts. The first treats the manual as a compliance checklist. Every page becomes a box to tick, every recommendation a deliverable. Did discovery last eight to twelve weeks? Is there a team wall? Photograph it for the pack. Are the user stories written as “As a… I want… so that…”? Then we are agile. The photographed team wall is the bamboo control tower of digital government: accurate in every visible detail, connected to nothing.
\nThis cult is strongest among people who are near delivery but not in it: assurance leads, portfolio offices, commercial teams, consultancies billing by the artefact. It is a natural response to having responsibility without control. If you can’t change what the team builds, you can at least document that they built it correctly. The manual becomes evidence rather than instruction, read the way a barrister reads a statute: for what can be shown to have been complied with.
\nThe cult of words. The second is quieter and more affectionate. It treats the manual, the early GDS blog and a handful of conference talks from 2012 to 2015 as a founding canon. The question stops being “what does this situation need?” and becomes “what would the founders have done?” Slogans like start with user needs, the strategy is delivery and show the thing get used as incantations, recited at a problem until it seems to resolve. This copies not the rituals but the speech of the people who made it work.
\nThe tell is that its members rarely know any other tradition well. They haven’t read operations research, systems engineering, or the public-administration literature on why large programmes fail. So every situation gets diagnosed with the same three slogans. The slogans are good, but they are not enough on their own.
\nThe cult of the calendar. The third copies the rhythm. The lifecycle flattens into a timetable. You are in alpha, so it is the season for prototypes. You are in beta, so research is something you scale down. Sprint boundaries, phase boundaries and spend-control boundaries are all aligned, so that every two weeks the team can report which stage of the ceremony it has reached.
\nThe extreme case is the team that “pivots” at every sprint review because the manual says to learn and adapt, and learning has been redefined as changing direction on schedule. That isn’t agility; it’s a metronome mistaken for a compass. Teams like this usually have a deeper problem than misread guidance: nobody with authority has said what the service is for.
\nThe iteration myth
\nOne cargo belief deserves its own section, because whole programmes get built on it: that iterating faster is the point.
\nThe creed is to ship small, ship often, release every fortnight and deploy daily. The reasoning goes that if the feedback loop is tight enough, everything else follows: policy fit, user satisfaction, value for money. It is a lovely idea, in the way that “if we just digitise the form, the backlog will clear” is a lovely idea.
\nThe myth survives because it is right often enough. Most government services in the 2000s were starved of feedback, so almost any increase in iteration speed was an improvement. If you learned agile in that era, every data point told you to go faster.
\nBut a feedback loop is only as good as what it’s coupled to. Picture a team iterating weekly on a benefits journey whose eligibility rules are fixed in primary legislation and change every few years. That team is not learning faster. It is polishing the same answer to a question it isn’t allowed to change. Meanwhile the decision that matters most, whether the policy intent is achievable through this channel at all, moves at the speed of a Bill.
\nThe skill is not speed. It is matching cadence to whatever you’re coupled to. Interface details can move hourly, and content design weekly. Data models and integrations with HMRC or DWP systems move quarterly, if you’re lucky. Policy moves with parliamentary sessions. A good delivery team runs all these clocks at once and knows which one it is listening to. A cargo team picks the fastest clock, makes it the only clock, and reports velocity to the board. Velocity is the purest cargo metric there is: easy to see, easy to copy, and almost entirely unconnected to whether anything useful arrived.
\nThe manual is wiser than its readers here. Its page on making services in an emergency effectively admits that tempo is situational: some conditions call for going much faster than usual and accepting the cost. The corollary, less often stated, is that some conditions call for going slower.
\nWhat the cult can’t copy
\nHere is the non-obvious part. The agile delivery guidance is not a map of your service. Other things map your service: journey maps, service blueprints, data flows, the legislation, the budget. The guidance maps something else, which is the condition of the organisation doing the delivering. That is why it is so easy to cargo cult. Conditions are invisible; their symptoms are not.
\nRead it again with that lens. “Creating an agile working environment” is about whether information can flow. “Deciding on priorities” is about who is allowed to say no. The governance principles are about how far decisions sit from the work. Even the phase pages are mostly about which questions the organisation may ask at which moment.
\nThose functions don’t live where the org chart says they do. Sometimes the product manager really does decide priorities. Other times it’s the deputy director, the minister’s private office, a clause in a 2014 outsourcing contract, or the one DBA who controls the only test environment. Sometimes user research is genuinely the team’s eyes. Sometimes the eyes are the press office, because complaints arrive there first.
\nOne function is categorically different from the rest: the ability to change the question. Most of a delivery team’s work is a smooth loop of research, decide, build, release. Above that loop sits something that can interrupt it, by saying “we’re solving the wrong problem”, “this shouldn’t be a digital service” or “retire it”. In the manual this function is spread across discovery, service assessments, governance and the retirement page. In practice it is the scarcest capability in any department, and the one most often missing entirely.
\nIt is also the one thing a cargo cult can never copy, because it has no visible ritual. It looks like a senior person, in a meeting nobody photographs, agreeing to stop. A team that has it can survive bad tooling, a poor estate and a thin budget. A team without it can have perfect ceremonies and still deliver, very efficiently, a service nobody should have built.
\nTelling real from cargo
\nIf the guidance describes conditions, you should be able to look at a team and say which condition it is in. Here are six common ones.
\nHere is the cargo cult’s real damage. All six conditions can hold identical stand-ups, identical walls and identical show-and-tells. The rituals look the same. Only the outcomes differ. So a team stuck in discovery can report, with complete sincerity, as though it were healthy, and every artefact in the pack will back it up. Naming the condition honestly is often most of the fix.
\nThere is always a counterparty
\nThe guidance has a mild, collegiate tone. It assumes everyone around the team wants the service to succeed. Experienced delivery people know this is a polite fiction, and the most useful thing to add to the manual mentally is a counterparty.
\nThis doesn’t mean villains. It means non-aligned intentions, which in government are structural rather than personal. HM Treasury’s spending cycle runs on a different clock and optimises for different things. Ministers turn over every eighteen months and each wants a visible announcement. Large suppliers hold the keys to the legacy estate and are paid by the change request. Policy teams are accountable for intent, not implementation, and are understandably wary of a delivery team telling them their intent doesn’t survive contact with users. Parliament asks questions on its own timetable. The National Audit Office arrives afterwards.
\nCargo cults suit several of these parties rather well. A supplier can sell rituals by the day. A minister can announce a “digital transformation” with photos of a team wall. A portfolio office can report green against every artefact. Nobody in that chain is being dishonest, exactly. Each is simply being paid, praised or protected for the visible layer.
\nEach party also has its own loop of watching, deciding and acting, and much of what happens to a service is decided by whose loop gets inside whose. A supplier that controls the only environment where real data lives effectively controls the team’s research. A spending review that lands mid-beta can reset priorities more thoroughly than any user finding. A ministerial announcement dated before the alpha has finished turns discovery into retrospective justification.
\nThe internal version is just as real. One team contains people who want different things: the developer who wants to rebuild properly, the delivery manager who wants to hit the date, the researcher who wants the hard finding heard. They rarely negotiate openly. More often they quietly shape what the others see. Whoever writes the sprint review slides has a lot of power.
\nRead the manual this way and its governance pages look different. Principles like keeping decisions close to the work, going to see for yourself and trusting but verifying are not management hygiene. They are defences against cargo: against reports that look like delivery but aren’t.
\nWhen to use it
\nThe agile delivery guidance works best as a mirror. Use it to see your own team clearly: which phase claims you can honestly make, which functions are missing, whose clock you’re actually on, and who else is inside your loop.
\nIt is much weaker as a lever. It will not turn a poorly governed programme into a well-governed one. Mandating it across a department is the most reliable way to start a cargo cult, because the people who most need the mirror are the least likely to look in it. A good delivery leader can sharpen their judgement with it. A weak one gains a new vocabulary for the same mistakes.
\nShared vocabulary helps only when both people are literate in it. A delivery manager and a deputy director who both understand what “we’re still in discovery on appeals” really claims can have a fast, useful conversation. If only one of them does, drop the jargon and just say it in plain English: “we don’t yet know if this should exist.”
\nA simple test separates use from cargo. Take any practice your team follows and ask what would happen if you stopped it tomorrow. If the honest answer is “we’d lose information we rely on to make decisions”, it’s real. If the answer is “the assessment would ask where it went”, it’s bamboo.
\nUsed like a sacred text or a compliance regime, the manual will build you a beautiful airstrip. Used like a good map, partial, deliberately distorted and honest about what it leaves out, it is one of the better things the British state has written about itself. The aircraft were never attracted by the runway. They came because someone, somewhere, had the authority to send them.
", "content_hash": "sha256:509cb5626947877ff6546a99f80f4fc5748297a7622750e6746b55db7c192324", "media": [], "changelog": [ { "version": 1, "at": "2026-11-06T17:33:43Z", "note": null } ] }