I keep seeing the same thing, everywhere. I bet you do too.
An organisation adopted agile some years ago. They have certified scrum masters, two-week sprints, a backlog, stand-ups, retros, the works. Delivery is still slow. The team is still tired. Nobody can quite say what they got for the investment. The question, delivered with varying levels of frustration, is some version of: did agile fail us?
No. What failed was the assumption that installing the ceremonies was the same as adopting the disposition behind them. The ceremonies are downstream artefacts. The disposition is the thing. Skip to the artefacts and you get the costume without the character underneath, and the costume on its own does not deliver software, or anything else.
I am writing this because the conversation does not seem to be improving. Twenty years on, we are still mistaking the costume for the character, and the cost of that mistake compounds every year an organisation runs a method it does not believe in.
What the originals actually said
Kent Beck codified Extreme Programming in the late nineties. I’m old enough to remember when XP was new, and "agile" was still a word used to describe athletic prowess. Beck was clear that the practices were instrumental. They existed to support a small number of underlying values — communication, simplicity, feedback, courage, and later respect. The practices were a means. The values were the thing.
The Manifesto authors a few years later wrote four short value statements and twelve principles. Almost nothing about how to run a meeting. That was deliberate. They knew that codifying method would invite the very thing they were trying to escape: ritual without discernment..
Read XP carefully and what you find is not a process. It is a list of demands on the humans involved. Pair programming demands you can tolerate working alongside another person all day. Test-first demands you can think clearly about behaviour before writing the code that delivers it. Collective code ownership demands you let go of the parts you wrote. Continuous integration demands you finish things to a standard often enough that integration is predictable and boring. None of that is something you can instil with a training course.
What got built on top of those ideas is something else. SAFe, LeSS, scaled-Scrum-flavoured-things — these are packaged guidance. They exist because organisations needed something they could roll out, certify against, and audit, and the market obliged. They are commercial products as much as intellectual ones, and they were never the thing the originals were pointing at.
Frameworks externalise responsibility
The packaging does real work for the buyer. It provides defensibility. If a programme falters under SAFe, the executive sponsor can point at the framework and say we followed the playbook. If a programme falters under a principles-first approach, the sponsor has to defend the judgement calls.
This is why frameworks sell. They externalise responsibility. That is a feature for the buyer and a bug for the outcome. Responsibility is the thing you cannot outsource if you want delivery to work.
There is a related manoeuvre that needs to be talked about. Most large agile transformations are not really transformations of how work happens. They are transformations of how work is described. The backlog replaces the requirements document. The sprint replaces the phase gate. The product owner replaces the project sponsor. The labels change, the underlying behaviour does not, and a year in everyone notices that the team is still working the way it always did, just with new vocabulary and a new ceremony cost on top.
I have walked into rooms where this exact thing has happened, and the most damaging part is not the wasted investment. It is that the diagnostics get disabled. A formally-run waterfall programme that ships late and over budget is a known failure mode. The audit trail is there. The variance reports are there. You can govern it.
A nominally agile programme that has been drifting for two years while telling itself a story about empowerment is a much harder thing to fix. You can't find the failure because the artefacts that would have surfaced it were thrown out as bureaucratic overhead. The team has been told their judgement is the control, and their judgement has quietly atrophied because nobody has been checking it.
People first, always
The principle that holds the rest together is that capable, motivated people doing direct, honest work outperform any process you can wrap around them. This sounds obvious until you watch what organisations actually do. They hire reluctantly. They invest in capability slowly. They tolerate poor management and low standards for years. Then they try to compensate by adding ceremony.
The ceremony is cheaper than the people work, in the short term. In the long term it is much more expensive, because it gradually selects for people who are good at performing the ceremony and against people who are good at the actual work. A retrospective is a useful thing. A retrospective performed by people who do not trust each other to say what they actually think is theatre, and theatre is more expensive than silence because it consumes hours and produces nothing.
A team that genuinely understands its problem, talks to its users, finishes one thing before starting the next, and tells the truth in retrospectives will outperform a more formally-run team almost every time. Not because the formal team is incompetent. Because the informal team is solving the actual problem rather than the surrogate problem of complying with a method.
Where formal method earns its keep
I want to be careful not to pretend the answer is to throw out structure. Formal method exists for a reason, and the reason is mostly that not every team is capable of self-direction. Capability is uneven. Some teams have the experience, judgement, and personal accountability to operate on principles - they will create their own guardrails where necessary. Many do not have these traits, and pretending otherwise is its own kind of negligence.
Where capability is limited, structure is a substitute. Templates, gates, checklists, defined ceremonies, named artefacts — these give people who would otherwise drift a set of guardrails to stay between. The cost is real. The structure consumes effort, slows decisions, and produces work that exists to satisfy the process rather than the customer.
It is a lesser cost than the drift and ill-discipline of agile-in-name-only, which produces a worse outcome at similar expense while pretending to be lightweight.
This is the call I make most often with new clients, and it is rarely the answer they want to hear. If you do not have the team to run on principles, do not run on principles. Adopt the formal structure your capability supports, run it well, and invest patiently in the capability that would let you let go of some of it later. The path back to lighter governance runs through earning it as a team, not declaring it as a manager.
Accountability is the hinge
The reason capability matters so much is that the two approaches handle accountability completely differently.
Under formal method, accountability is bureaucratic. It runs through documents, sign-offs, RACI charts, change control boards, and stage gates. It is slow, expensive, and largely unavoidable once installed. It has a real virtue, though: it does not depend on the character of the people involved. A reasonably diligent team executing a reasonable process will produce a defensible audit trail and a delivery you can govern. The accountability is in the structure.
Under a principles-based approach, accountability is social and personal. You are accountable to the colleague you committed to in stand-up. You are accountable to the user whose problem you said you would solve. You are accountable to the team whose trust you would lose if you cut corners. You are accountable to your own professional standards. This accountability is enormously cheaper than the bureaucratic kind. There is almost no overhead. But it only works where people care about their standing with each other, and where the team is small and stable enough for that standing to mean something.
Once those conditions break down, social accountability evaporates. Unless something replaces it, the work falls apart quickly, and usually quietly.
This is why scaling agile is so consistently disappointing. The original method assumed conditions — small teams, direct contact with users, stable membership, mutual respect — that almost no large organisation reliably provides. The frameworks that promise to scale agile are essentially trying to reintroduce bureaucratic accountability without admitting that is what they are doing. They are reinventing the very governance overhead that agile was meant to escape, and doing it worse, because the resulting hybrid satisfies neither model cleanly.
What this means in practice
For executives, the practical takeaway is to be honest about what you are buying. If you have a team that genuinely operates on principles, protect it. Do not impose process on it because the rest of the organisation is process-heavy. If you do not have that team, do not pretend that you do. Adopt the formal structure your capability supports. Run it properly. Invest in the capability that would let you let go of some of it later.
For delivery practitioners, the takeaway is that fluency with both modes is the actual competence. Knowing when to lean on the team's judgement and when to lean on the artefact. Knowing which conversations need to happen face-to-face and which need a written decision record. Knowing when a retrospective is real and when it has become theatre. A consultant or PM who can only operate in one mode is half-equipped for the work.
Agile was always a claim about people first. The frameworks that proliferated around it are a useful fallback when the people conditions can't be met. They are a fallback, not the thing itself, and confusing the two is the most expensive mistake in modern delivery.
