There’s a specific moment I started recognising in agile transformations. Usually around month four or five. The teams are running sprints. The retrospectives are happening. Someone’s bought a Jira licence. And the organisation, structurally, is completely unchanged.
Unclear priorities still cascade down from above. Decisions that need cross-functional sign-off still take three weeks because nobody’s sorted out who can actually say yes. The engineering backlog is a negotiation between twelve different people who all believe their thing is the most important thing. All of this shows up in the retrospectives. It gets written on sticky notes, organised into themes, and left there.
Because fixing it requires authority that doesn’t sit in the team.
I watched this play out at enough organisations that I stopped being surprised by it. The transformation language changed — velocity, ceremonies, iterative delivery — but the underlying system didn’t. Leadership had new words for things. The problems didn’t go anywhere.
That was agile. Now I’m watching the same pattern with AI, except it’s faster and the numbers are bigger.
What’s actually repeating
The surface features are different. Nobody’s running AI standups (yet). But the structural move is identical: adopt the practice, skip the system change underneath it.
AI initiatives land inside organisations where decision rights are unresolved, data is fragmented across functions with no real incentive to share it, and governance exists on paper and nowhere else. The model gets procured. Pilots run. Some of them produce interesting demos. Then the initiative stalls, or fails quietly, or produces results nobody can measure because the definition of success wasn’t written down before they started.
The post-mortem, if there is one, usually focuses on the technology. Wrong model, not enough data, integration problems. These things are sometimes true. They’re rarely the whole story. The bit that’s harder to write in a report is that the organisation running the AI initiative was the same organisation that couldn’t get cross-functional alignment on a sprint goal.
Why it’s worse this time
Agile transformations failed expensively. AI initiatives fail more expensively, faster, and with higher visibility. When a sprint doesn’t deliver, you lose a fortnight. When an AI initiative fails after eighteen months of procurement, implementation, and change management, you’ve lost something considerably harder to recover from — including, sometimes, the internal appetite to try again.
There’s also a diagnostic gap that didn’t exist in the same way with agile. Most organisations running agile transformations had some sense of what they were trying to fix: slow delivery, poor quality, disconnected teams. The problem was legible, even when the solution was badly implemented.
With AI, the problem statement is often less clear. Organisations are adopting AI because it seems necessary, because competitors are doing it, because the board has asked about it. The specific thing AI is supposed to fix is sometimes genuinely undefined. That’s not a technology problem. It’s an organisational clarity problem, and no model resolves it.
What actually needs to happen first
The organisations I’ve seen get something real from AI had a few things in common. They knew which decisions AI was supposed to improve. They had data that was actually trustworthy enough to feed into a model. They’d sorted out who owned the output when the model was wrong.
None of this is glamorous. None of it gets written up in case studies. It’s the foundation that makes the interesting stuff possible.
The pattern from agile teaches one thing clearly: the technology is not the constraint. The system underneath it is. That was true in 2015. It’s still true now.