The Agile Island: Why High-Performing Teams Cannot Move an Un-Agile Organisation
You cannot coach a team into having authority it was never given.
The Team That Could Not Win
There is a scene that repeats across organisations attempting to adopt agile methods, and once you have watched it play out a few times you stop mistaking it for bad luck. A team is assembled, given a coach, taught to work in two-week iterations, and within a few months it is genuinely capable. It produces working software at the end of every sprint. It understands its own velocity. It holds a backlog it can actually reason about. And yet the programme surrounding it moves no faster than before. The sprint reviews are impressive. The delivered outcome — the thing the business is actually waiting for — arrives on much the same timescale it always did.
The reflexive explanation, offered in steering meetings across the industry, is that the team is not mature yet, or that the framework has been implemented incorrectly, or that a further round of coaching is required. I want to argue the opposite. In my experience the team is very often the healthiest part of the system. The failure is not inside the team at all. It sits in the organisation that surrounds it — the funding model, the governance calendar, the resourcing mechanics, the reporting expectations — none of which have changed, and none of which the team has any authority to change.
An agile team inside an un-agile organisation is not a transformation. It is an island. And islands do not move the continents they sit in.
Why the Organisation Wins
The uncomfortable truth is that when a fast team meets a slow organisation, the organisation wins. It wins not through malice but through gravity — the accumulated weight of systems that were designed, entirely rationally, for a different way of working.
Consider what actually governs the pace of delivery in most large organisations today:
- The funding cycle. Money is allocated annually, against a business case written eighteen months earlier, with a fixed scope and a fixed date. A team that has learned to inspect and adapt every fortnight is reporting into a machine that can only inspect and adapt once a year.
- The governance calendar. Progress is assessed at stage gates and monthly programme boards. The gate asks whether the plan has been followed; the team has learned that following the plan to the letter is precisely the wrong thing to optimise for. The two are speaking different languages about the same work.
- Resource allocation. People are assigned from functional silos and shared across three initiatives at once. The team’s capacity — the one thing its velocity depends on — is set by a matrix it does not control.
- The contract. Where delivery is outsourced, the commercial agreement fixes scope and price in advance. Agility inside the delivery team is commercially irrelevant if the contract it operates under forbids change.
Each of these is a control that predates the team and outranks it. The team can run a flawless retrospective and still be unable to touch a single one of them. This is why maturity is the wrong lens. You cannot coach a team into having authority it was never given.
The Comfortable Misdiagnosis
Leadership tends to reach for one of two explanations, and both are comfortable precisely because both locate the problem somewhere cheap to fix.
The first is that the team has failed — it needs more discipline, better estimates, a stricter definition of done. The second is that the method has failed — agile doesn’t work here, we are too regulated, too large, too complex. Both conclusions share a hidden convenience: they leave the funding model, the governance structure, and the operating model untouched. They protect the organisation from having to look at itself.
It is easier to declare that agile does not scale than to admit that the organisation was never asked to change.
What actually tends to happen, once the mismatch becomes chronic, is one of three quiet outcomes — none of which appears on any dashboard.
- The team performs theatre. It keeps the ceremonies and abandons the substance. Stand-ups become status meetings, the backlog becomes a disguised Gantt chart, and the vocabulary of agility is used to describe an entirely conventional way of working. Everyone is satisfied and nothing has changed.
- The team burns out. The people who understand what good looks like spend their energy fighting the surrounding system rather than building the product. This is expensive and it is invisible, because the cost is paid in the departure of exactly the people you most wanted to keep.
- A translation layer forms. A project manager, or the team lead, quietly absorbs the impedance mismatch — converting sprints into stage-gate language upwards and shielding the team downwards. This can work, and I have seen it work well, but it depends entirely on one or two individuals, and it is a symptom of the problem, not a cure for it.
The Reframe That Actually Helps
If there is a single idea worth taking from the last few years of adoption, it is this: agility is a property of the organisation, not a practice of the team. A team can be agile in its methods while the organisation remains entirely incapable of responding to change. The two are not the same thing, and conflating them is the root of most of the disappointment.
This is not an argument for a grand enterprise-wide programme to become agile — those tend to manufacture the very bureaucracy they set out to remove. It is an argument for honesty about where the constraints actually live, and for spending scarce leadership attention on the constraints rather than on the team. In practice, that points to a small number of unglamorous moves:
- Fund the team, not the project. Allocate money to a persistent team and a problem to solve, reviewed quarterly, rather than to a fixed scope fixed a year in advance. This unlocks the most, and organisations resist it most strongly, because it moves control away from the annual planning ritual.
- Let governance ask a different question. A board that asks what have we learned, and what will we now do differently? is compatible with an agile team. A board that only asks are you on plan? is not. The ceremony can stay; the question must change.
- Give the team stable membership. Agility assumes a team whose capacity is known. Shared, fractional, constantly reshuffled members make velocity meaningless. Protecting team composition is dull, structural work — and it matters more than any coaching intervention.
- Fix the contract before the method. Where the work is outsourced, no amount of internal agility survives a fixed-scope contract. The commercial model is part of the operating model, and it has to change with it.
None of this is fast, and none of it is the kind of thing that shows well in a launch announcement. But it is the actual work. The alternative — standing up an agile team and hoping its energy will somehow diffuse outward into the organisation — is a hope I have watched fail too many times to recommend.
What the Island Teaches
There is real value in the island, even when it fails to move the continent. A well-functioning agile team is a working demonstration of what good looks like, running inside your own walls, in your own context, with your own people. It is proof that the capability exists. The mistake is to treat that demonstration as the transformation itself, rather than as the first and easiest step of one.
The organisations that will get the most from these methods in the years ahead are not the ones with the best-drilled teams. They are the ones willing to look honestly at the systems above the team — the money, the governance, the resourcing, the contracts — and to change those in step with the way their teams have already learned to work. Until that happens, we should be honest with ourselves about what we have built. We have not made the organisation agile. We have built an island, and then wondered why the tide keeps coming in.