Few movements in software have been as successful as Agile. What began as a reaction against heavyweight process, exhaustive documentation, and centralised planning became the dominant way organisations talk about building software. And somewhere in that success it acquired certifications, prescribed ceremonies, maturity models, governance structures, a consulting industry, and dedicated management hierarchies, which is to say it acquired most of the things it was a reaction against.
The question worth asking is narrow. Not whether Agile succeeded, and not the broad point that institutions reshape ideas, but the specific mechanism. By what steps does a critique of bureaucracy turn into a bureaucracy, when nobody involved wanted that outcome?
Two mechanisms seem to do most of the work, and neither requires anyone to act in bad faith. From the participant’s side they feel like different phenomena: rituals becoming mandatory is not the same experience as numbers becoming targets. But they arise from a single source. Institutions have a structural preference for what they can observe, and there are two things they can observe: behaviours and numbers. Ceremonies are the observable behaviours. Metrics are the observable numbers. The symmetry is the argument.
Ceremony survives
Many organisations adopted the visible features of Agile before, or instead of, the assumptions underneath them. Stand-ups, retrospectives, sprint planning, story points, velocity tracking: these spread quickly and widely.
The trouble is an asymmetry in what can be checked. A ceremony is easy to observe. Judgement is not. A manager can confirm that a stand-up happened, that the retrospective was held, that the board has the right columns. A manager cannot easily confirm whether a team is actually learning from feedback, because learning leaves no attendance record. So the observable thing gets monitored, reported, and eventually required, while the unobservable thing it was meant to produce goes unmeasured.
Over time the ritual detaches from its purpose and keeps going on its own. The stand-up persists after it has stopped surfacing anything. The retrospective produces the same three action items nobody acts on. The form survives because the form is what anyone can see, and what can be seen is what gets defended when someone asks whether the team is doing Agile properly. The question itself, doing it properly, is the tell: it treats a set of observable behaviours as the thing, when the behaviours were only ever proxies for it.
Metrics become targets
If ceremonies are the observable behaviours, numbers are the observables that fit in a spreadsheet, and an institution likes those even better. This second mechanism is older than Agile and was simply inherited by it. Institutions run on measurement, and Agile arrived with a convenient supply of numbers: velocity, capacity, throughput, burn-down. These began as descriptive tools, ways for a team to notice its own rhythm and plan against it.
Once a number is visible to people who manage rather than do the work, it tends to stop describing and start governing. Velocity shifts from something a team observes about itself to something it is expected to hit, and then to increase. The moment a measure becomes a target it stops being a good measure, because behaviour reorganises to optimise the number rather than the thing the number stood for. Story points inflate. Work is sliced to make the chart look right. The metric ends up describing the reporting system more faithfully than it describes the software, and everyone can read the dashboard while no one can read the work.
Quiet part
Left to run long enough, the two mechanisms stop Agile functioning mainly as an engineering approach. It becomes a governance layer. Its value to the organisation is in the reporting structure, the planning cadence, the budget conversations it supports, the portfolio oversight, the executive visibility. None of that necessarily improves what gets shipped. It does answer questions the institution genuinely has, about coordination and accountability and where the money went, and those questions are real even when they are not engineering questions.
This is the quiet part. The institution and the engineering practice end up serving different purposes through the same vocabulary, and because the vocabulary is shared the divergence is hard to name from inside. The team thinks it is doing the thing the words describe. The organisation needs the words to mean something else, and the words oblige.
It also explains why people keep performing rituals that have stopped working, which is otherwise a puzzle. They keep performing them because the artefacts have become evidence. A retrospective is no longer valuable because it improves anything; it is valuable because it demonstrates that retrospective activity occurred. A velocity chart is no longer valuable because it predicts delivery; it is valuable because it satisfies a reporting requirement. Once the artefact is the thing being asked for, producing the artefact is the rational response, and whether the underlying work improved becomes a separate question that nobody with a dashboard is positioned to ask. The participants are not being cynical. They are responding to what is actually being checked.
Agile did not become bureaucratic because its advocates secretly wanted bureaucracy. It became bureaucratic because the observable parts were the parts that could be required, and the descriptive numbers were the numbers that could be targeted, and an institution presented with something observable and something countable will tend to require and target them. A method built to help teams adapt to uncertainty became a system for helping organisations report on it. Those are related goals. They are not the same goal.
The distance between them is where the meetings live.