Agile promised faster delivery, empowered teams, happier customers and organisations better able to adapt.

The promise was compelling. The ideas were often valuable. But there is a crucial difference between adopting agile and becoming agile.

After years of frameworks, certifications, transformation programmes and agile job titles, one question deserves greater attention:

Have organisations developed the ability to adapt, or merely learned how to perform agility?

This is not an argument that agile has failed. It is a challenge to a more dangerous assumption, that implementing agile practices automatically creates business agility.

It doesn’t. And the difference between the two could determine whether an organisation thrives on change or gets caught out by it.

Infographic summarising the article: “The Treat” — what agile got right — versus “The Trick” — what often happens instead.

The Treat: A Better Way to Work

Agile challenged the belief that work could be fully planned in advance, controlled through detailed processes and delivered successfully simply by following the plan.

It encouraged shorter feedback loops, iterative delivery, closer customer involvement and decisions informed by evidence rather than assumption.

These ideas remain powerful.

When teams can test ideas early, learn from customers and change direction without excessive delay, they can avoid expensive mistakes and identify opportunities sooner.

The real prize, however, was never the sprint, the stand-up or the backlog.

It was the ability to learn faster than circumstances change.

It does happen. When the UK Government Digital Service built the prototype for GOV.UK, a small team released a public alpha in twelve weeks for £261,000, invited feedback from real users and changed direction based on what they learned (Government Digital Service, 2011; Greenway et al., 2018). The achievement was not flawless adherence to a method. It was a team free to respond to evidence.

That was the promise. So where did things go wrong?

The Trick: Mistaking the Method for the Outcome

Agile became something organisations could implement, standardise and measure.

Teams adopted Scrum. Boards appeared. Retrospectives became routine. New roles and governance structures followed.

But the visible adoption of practices is not evidence of improved adaptability.

Consider three familiar situations.

A team holds daily stand-ups but cannot resolve a dependency without waiting two weeks for another department.

A product team delivers every sprint but cannot change priorities without multiple levels of approval.

A retrospective identifies the same obstacles month after month because nobody has the authority to remove them.

The practices are in place. The organisation remains stuck.

The numbers tell the same story. Digital.ai’s 17th State of Agile report found that while 71% of organisations use agile in their software development lifecycle, just 11% are very satisfied with the outcome — and the biggest barriers to scaling are organisational resistance to change and a lack of leadership understanding, not the practices themselves (Digital.ai, 2024). McKinsey’s research reaches a similar conclusion: around 70% of large-scale change programmes fall short of their goals, with inadequate management support and poor cross-functional collaboration among the most common causes (McKinsey & Company, 2021).

This is the central trick: confusing evidence of agile activity with evidence of business agility.

The framework may be working exactly as designed. The wider system may still be preventing the organisation from responding effectively.

The result is agile in form, traditional in behaviour.

Busy Being Agile, Too Slow to Adapt

The problem becomes more serious when organisations confuse speed with progress.

A team can deliver more frequently without delivering greater value. A programme can meet its milestones while customer needs move on. Departments can optimise their own performance while making the end-to-end process slower.

Activity becomes the measure of success. Outcomes become an afterthought.

As management thinker Russell Ackoff’s work on systems thinking reminds us, improving the performance of individual parts does not necessarily improve the whole system (Ackoff, 1999).

The business equivalent is painfully familiar — every team meets its targets, yet the customer still waits.

Real agility requires a different set of questions. Are we solving the right problem? What have we learned? Has the opportunity changed? Should we continue, redirect or stop?

Sometimes the best decision is to deliver faster. Sometimes it is to abandon work that no longer makes sense.

Agility is not doing the wrong thing faster. It is recognising sooner when something else needs to be done.

The Leadership Trick: Demanding Agility Without Enabling it

This is where accountability must move beyond the team.

Leaders frequently demand faster delivery, greater innovation and more ownership while retaining the structures that make those things difficult.

They announce empowerment but reserve important decisions for themselves. They encourage experimentation but penalise failure. They demand collaboration while maintaining departmental targets that reward competing priorities.

They ask teams to adapt, then make changing direction a bureaucratic exercise.

These are not primarily team-level failures. They are leadership and organisational design failures.

Mary Parker Follett, the pioneering management thinker, distinguished between power-over and power-with: control imposed on people versus the capacity developed through working together (Follett, 1942). Her ideas remain relevant to the question of whether leaders genuinely empower teams or simply delegate responsibility without authority.

Delegating delivery while retaining every meaningful decision is not empowerment. It is accountability without control.

Leaders cannot reasonably hold teams responsible for outcomes while denying them the authority, information, resources or organisational support needed to influence those outcomes.

Nor can they blame a framework when their own governance, funding and incentive systems obstruct adaptation.

If leaders want an agile organisation, they must take responsibility for the conditions that make agility possible.

That means examining some uncomfortable questions:

  • Decision-making: Which decisions can teams make without seeking permission, and why are the others retained centrally?
  • Funding and priorities: Can resources move when evidence changes, or are teams locked into plans long after their assumptions have failed?
  • Incentives: Are people rewarded for customer and business outcomes, or for local targets, utilisation and predictable delivery?
  • Failure and learning: Can teams expose bad news early without being punished for it?
  • Governance: Does oversight help the organisation make better decisions, or simply add time between recognising a problem and acting on it?

These are leadership responsibilities, not problems a new agile coach can solve.

The real test of leadership is not whether executives endorse agility in presentations. It is whether they are prepared to change the management system that constrains it.

The Practical Test: Can You Change When it Matters?

Forget, for a moment, how many teams use agile methods. Look instead at what happens when reality challenges the plan.

A competitor introduces a disruptive offer. A customer need changes. A technology creates a new opportunity. A product assumption proves wrong.

What happens next?

Does the organisation recognise the signal early? Can the right people make a decision? Can funding and effort be redirected? Can an unsuccessful initiative be stopped without a prolonged battle to protect the original business case?

Or does the organisation continue with its existing plan because changing it is too difficult?

Mike Tyson’s often-quoted observation, made in a 1987 interview, captures the problem neatly: “Everyone has a plan until they get punched in the mouth.”

Business plans are essential. But their value depends on an organisation’s willingness and ability to revise them when circumstances demand it.

A genuinely agile organisation does not abandon planning. It combines direction with the capacity to respond when the evidence changes.

That is the difference between executing a plan and adapting intelligently.

Beyond Agile: Make Adaptability the Objective

The answer is not to discard agile methods or replace them with another fashionable framework.

It is to put methods back in their proper place as tools for achieving better outcomes.

Use Scrum where iterative product development benefits from it. Use Kanban where visualising and improving flow helps. Use other approaches where they better fit the work.

Do not force every problem into the same process.

Measure whether decisions are improving, feedback is changing what happens next, obstacles are being removed and customers are receiving greater value. Examine how quickly the organisation can respond to new information, not simply how consistently it follows a prescribed method.

Above all, connect team-level improvement to the wider operating model. Local agility cannot compensate indefinitely for organisational rigidity.

The objective is not to make everyone look agile.

It is to make the business more capable of changing direction without losing its purpose.

So, Treat or Trick?

Agile has delivered genuine benefits. But adopting its practices is not the same as developing the capability those practices were intended to support.

The Treat is an organisation that learns quickly, makes timely decisions and redirects effort towards changing needs and emerging opportunities.

The Trick is an organisation that measures ceremonies, celebrates activity and declares transformation while its fundamental behaviour remains unchanged.

The distinction is simple, but consequential.

One organisation uses agile to become more adaptable. The other uses agile to reassure itself that it already is.

This Halloween, perhaps the most revealing question for any leadership team is not “Are we agile?”

It is “When circumstances change, can we?”

Because the scariest business risk is not change itself. It is discovering that your organisation has spent years practising agility without ever mastering it.

References