Agile

Many critiques of Agile assume something went wrong. The story is usually told as a fall from grace: a practical response to software uncertainty that then disappeared beneath ceremonies, certifications, frameworks, and consultants. There is another way to read the same history. Perhaps Agile did not fail. Perhaps it succeeded, and what happened next is simply what institutions do to successful ideas. On that reading the interesting question is not why Agile became institutionalised. It is why successful ideas so reliably do. ...

Most engineering disciplines accept that method follows from context. Nobody expects a bridge engineer, a documentary director, and a trauma surgeon to share a planning model, and nobody finds the difference remarkable. Software is one of the few fields where people go looking for a single methodology and then try to apply it to everything in sight. Agile is the most successful instance of that search, which makes it an awkward thing to argue about. The useful question is not whether it is good or bad. It is what kind of work it was meant for, and that turns out to depend on two things that have nothing to do with how much anyone likes the method. ...

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