Why we don't use the word "agile"

We have a small internal policy: we don't use the word "agile" in project discussions. Not because the underlying ideas are wrong — some of them aren't — but because the word has accumulated so much contradictory meaning that it has ceased to mean anything at all.

When a word can simultaneously describe a fourteen-person ceremony on a Tuesday morning, a philosophical stance about uncertainty, and a billable consulting framework, it has become noise. We prefer to be specific.

What the word replaced

There was a period, before the methodology industrialised, when the core insight was genuinely useful: that software development benefits from short feedback loops, that requirements change, and that a planning process that pretends otherwise will produce worse outcomes than one that doesn't.

This was not a revolutionary insight. It was an obvious one. The reason it needed to be stated was that the dominant alternative — exhaustive upfront specification followed by serial execution — had become so institutionalised that its failure modes were invisible to practitioners inside the system.

The insight got wrapped in ceremonies. The ceremonies got sold. The sales required certifications. The certifications required trainers. And somewhere in this process, the original insight — tight feedback loops help — became buried under a scaffolding of standups and story points and velocity metrics.

We are not opposed to standups. We are opposed to standups that exist because a framework requires them rather than because the team finds them useful.

What flexibility actually requires

Operational flexibility — the ability to change direction when circumstances change — is not produced by ceremonies. It is produced by structural choices made at the beginning of a project that create optionality later.

Specifically, it requires:

Loose coupling between components. If your components are tightly coupled — if changing one requires changing many others — you will be slow regardless of your planning cadence. You will be slow because the cost of change is high, and no amount of ritual will reduce that cost.

Clear interfaces. Systems that can be understood independently of their implementation are systems that can be changed independently. Interfaces that are poorly defined or frequently violated create a hidden cost that accumulates until it is prohibitive.

Explicit dependency management. Knowing what depends on what, and in what direction, is the prerequisite for safe change. This sounds obvious. It is consistently underinvested in.

A culture of reversibility. The question "how would we undo this if we're wrong?" is not a sign of timidity. It is a sign of structural thinking. Systems that are easy to reverse are systems that can afford to take risks.

None of these require any particular planning cadence. They require careful design decisions made before the first line of code is written.

The sprint as a unit of premature optimisation

Sprint-based planning tends to optimise for predictable, estimable units of work — the kind of work that can be described clearly enough to be pointed and committed to within a two-week window. This is fine for a certain class of work. It is catastrophically mismatched to work that involves genuine uncertainty: exploratory research, novel architecture, problems where the shape of the solution is unknown at the outset.

The problem is not the sprint. The problem is applying sprints indiscriminately — using a planning tool designed for repetitive, well-understood work as if it were universal.

The teams we have seen produce the best work on genuinely hard problems share certain characteristics. They plan longer horizons, with explicit uncertainty bands. They allocate time for exploration that is not expected to produce demonstrable output. They measure progress by structural improvement — reduced coupling, better-defined interfaces, clearer understanding of the problem — rather than by feature completion.

They are, in the original sense, adaptive. They are not, in any meaningful sense, "agile."

A note on terminology

We are aware that this critique is not original. It has been made, in various forms, by people who were present at the creation of the frameworks we're criticising. The word has been reclaimed and redefined so many times that the original intent is now irrecoverable.

We prefer to describe what we actually do. We build systems with short feedback loops where feedback is valuable, and longer planning horizons where it isn't. We design for reversibility. We measure structural health alongside feature completion.

We don't have a name for this. We find that useful.