Agile has a funny reputation.
On a good day, it’s the way a team stays calm and effective in the middle of change. On a bad day, it’s treated like a system for making change stop happening.
And that’s where things go wrong.
Agile works with uncertainty; when we try to control it out of existence, we end up with certainty theatre and slower delivery.
The itch for control
Most organisations don’t choose control as a philosophy. They drift into it because uncertainty feels expensive.
Uncertainty makes budgets wobbly. It makes timelines embarrassing. It makes stakeholders nervous. It makes leaders feel like they’re failing at their job.
So we reach for certainty. We add process. We add approvals. We add detail. We add more planning meetings about the planning meetings.
The underlying hope is simple: if we can just define everything clearly enough up front, we can eliminate surprises.
It’s a very human instinct.
It’s also exactly how Agile gets quietly sabotaged.
What Agile is actually for
Agile is not a promise that delivery will be predictable.
Agile is what you do when predictability is not available.
If you already know what you’re building, why you’re building it, and how long it will take, you can run a perfectly decent project with a plan and a checklist. (You’ll still hit snags, but they’ll be the ‘normal’ kind.)
Agile becomes valuable when you’re dealing with:
- unclear requirements
- shifting priorities
- emerging risks
- new information arriving mid-flight
- people (always people)
In other words: reality.
So if the goal becomes ‘eliminate uncertainty’, you’re trying to delete the very condition that makes Agile useful.
The control trap that makes Agile ‘fail’
Here’s the pattern I’ve seen over and over:
- A team adopts Agile because things feel chaotic.
- Leadership asks for more certainty to make it feel less risky.
- The organisation adds controls that reduce feedback and slow learning.
- Work becomes less responsive, so outcomes get worse.
- Agile gets blamed for not delivering certainty.
Agile didn’t fail. It got repurposed into a certainty machine. Then it got judged for not being one.
That’s like buying a lifeboat and being annoyed it doesn’t stop storms.
The hidden cost of eliminating uncertainty
Trying to eliminate uncertainty doesn’t just fail. It creates new problems:
- You delay learning – if you insist on exhaustive analysis up front, you often postpone the only thing that clarifies the work: building something real and putting it in front of real users.
- You optimise for reporting, not outcomes – teams start producing artefacts that look like certainty: detailed roadmaps, precise estimates, confidently coloured RAG statuses. They become busy proving control, instead of discovering truth.
- You punish honesty – when an organisation demands certainty, people learn quickly that uncertainty is not safe to mention. So you get certainty theatre instead: optimistic promises, padded estimates, and quiet panic in week six.
- You reduce adaptability – the heavier the governance, the harder it becomes to respond when reality changes (which it will, because it’s reality). So teams stick to the plan, even when the plan is wrong, because changing the plan is harder than failing politely.
What to aim for instead
If control is the wrong goal, what’s the right one?
Responsiveness.
Not ‘we respond to everything instantly’, but ‘we notice change early and adapt without drama’.
Responsiveness comes from a few things that look almost boring on paper:
- short feedback loops
- small slices of delivery
- decisions made close to the work
- transparency that doesn’t punish people
- clear priorities that can change without shame
That’s the trade: less illusion of certainty, more actual ability to steer.
A better question for leaders
Instead of asking, “How do we eliminate uncertainty?”, a healthier question is:
“How quickly can we learn what’s true, and adjust?”
Because uncertainty isn’t a flaw in the system. It is the system. The work is complex. The environment changes. People change their minds. Users surprise you. Competitors exist. Technology does what it does.
The only sustainable advantage is being able to respond faster than your problems can grow legs and run off.
The punchline
Agile fails when we treat it as a way to control uncertainty.
Agile works when we treat it as a way to work with uncertainty.
Trying to eliminate the unknown is a comforting fantasy. Building a team that can navigate the unknown is the actual job.
