Agile leadership
Why most agility programmes stall, and what leaders can do instead
I have worked with dozens of organisations on agile transformation. Some made it through to genuine change. Most did not, at least not in the way they intended. And almost every stalled programme had the same story underneath it: people adopted the vocabulary without doing the thinking.
The practice adoption trap
When organisations start an agile transformation, they typically focus on practices first: the ceremonies, the artefacts, the tools. Two-week sprints. Daily standups. Story points. Backlogs. These are visible and measurable, which makes them feel like progress. They are also easy to introduce without changing anything that actually matters.
The result is a kind of agile theatre. Teams hold retrospectives where nothing is ever genuinely raised. Reviews happen without real feedback. Velocity metrics climb while customer outcomes stay flat. Leaders congratulate themselves on the number of teams trained. Meanwhile, the work is still being done the same way it was before, only with more meetings.
Practices without judgment are a costume. They look the part, but when pressure arrives, the organisation reverts to whatever it was before the transformation began.
Practices without judgment are a costume. They look the part, but when pressure arrives, the organisation reverts.
The sponsorship vacuum
The most common single cause of agility programmes stalling is a sponsorship vacuum. A senior leader champions the transformation, delegates it to a change team or an external consultancy, and then quietly disengages. They attend the launch event. They do not attend the retrospectives six months later.
This matters for one simple reason: people in organisations are exquisitely sensitive to where attention actually goes. When senior leaders talk about agility but continue to reward individual heroics, punish failure, and make decisions in private, teams read the signal clearly. The transformation is not real. The safest response is surface compliance.
Genuine sponsorship is not announcing the programme. It is modelling the behaviours the programme is asking of everyone else, including being visibly uncertain, asking questions instead of providing answers, and treating setbacks as information rather than failures.
The speed trap
There is another, subtler failure mode that is especially common in organisations under commercial pressure: prioritising velocity over learning.
Agile methods are designed to accelerate learning: to surface information quickly so that teams can adapt. But when organisations are under pressure, they tend to use the cadence of agile to ship faster, not to learn better. Two-week sprints become two-week micro-waterfalls. The retrospective is cut short or cancelled. The inspection and adaptation cycle, which is the whole point, gets treated as overhead.
Speed and learning are not in conflict in a mature agile team. But they are in direct conflict when a team is still building the trust and psychological safety that genuine learning requires. Rushing through the early stages of a transformation to demonstrate progress is often how organisations destroy the conditions for sustainable change.
Agile methods are designed to accelerate learning. But under pressure, organisations use the cadence to ship faster, not to learn better.
Three things leaders can do instead
Protect experimentation time explicitly. Continuous improvement does not happen automatically; it requires space that is not filled with delivery pressure. Leaders who want genuine agility create and defend that space, even when it is uncomfortable to do so.
Model vulnerability deliberately. The most powerful signal a leader can send in a transformation is publicly changing their mind based on evidence. This is not weakness. It is exactly the behavior the organisation needs to see from the top if it is going to take learning seriously at every level.
Measure outcomes, not ceremonies. Track what changes for customers and for teams, not how many standups are happening or how many teams are 'certified'. The question is never 'are we doing agile?' The question is always 'are we getting better at the things that matter?'