Agile Delivery in Large Organisations: What Actually Works

Agile methodologies were designed for small, co-located, autonomous teams. Most of my project work happens in considerably more complex environments: large enterprises with multiple stakeholder groups, regulatory constraints, legacy systems, and cross-functional teams that include people who don't report to each other.

The ESB RTV Platform — developed within a large, complex energy utility with significant regulatory oversight — was one of the most instructive experiences I've had in Agile delivery at enterprise scale.

What 'Agile' Actually Means in Practice

In my experience, 'Agile' in a large organisation means: short, focused delivery cycles with clear acceptance criteria; regular stakeholder checkpoints that surface misalignment before it becomes expensive; and a process for incorporating new information and changing requirements without derailing the overall delivery.

It does not mean: no planning, no documentation, or 'we'll figure it out as we go.' The organisations that use Agile as cover for insufficient planning produce the worst of both worlds — the overhead of a process without the discipline that makes it work.

Cross-Functional Alignment

On the Workvivo project — particularly through the post-Zoom acquisition period — one of the most challenging delivery aspects was aligning design, engineering, product, and commercial teams that now sat within a significantly larger organisational structure.

The approach that worked was a clear, shared product roadmap that everyone could see — a document that translated the high-level product vision into specific, sequenced delivery commitments. This didn't eliminate disagreement about priorities, but it gave every team a shared reference point for those conversations.

The Research and Design Phase Is Not Optional

One of the most persistent pressures in enterprise Agile is to start development as quickly as possible. The logic is understandable — development teams are expensive and stakeholders want to see progress. The consequence is often a first sprint that produces technically correct but wrong things, because the research and design phase was compressed or skipped.

On every project I've led, the investment in a proper discovery and design phase — even in a constrained timeline — has paid back significantly in reduced rework downstream.

• Define 'done' clearly before you start. Ambiguous acceptance criteria are the most common cause of sprint failure.
• Reserve 20% of each sprint capacity for technical debt and design debt. Teams that don't do this accumulate debt that eventually makes them non-functional.
• Stakeholder checkpoints should be decision points, not show-and-tell sessions. Come with options, not presentations.

‍