Agile is not one size fits all, so why do we keep treating it that way?

Most IT organisations are already agile. The real question is not whether to adopt it, but which model fits your industry. Applying the same framework across different industries like a bank, a hospital and a startup is not agile thinking. It is a recipe for failure.

Yet transformation failure rates remain high. Organisations invest in certifications, hire agile coaches, rename teams and call meetings standups, yet still miss deadlines, overspend and underdeliver. The problem is rarely the framework itself; it is the mismatch between the model and the environment.

A bank conducting two-week sprints with daily deployments in a compliance-heavy environment is not demonstrating agility. It is taking unnecessary risks. Similarly, a defence programme that abandons phase gates solely because a consultant deems waterfall outdated is not modernising, but rather misinterpreting its objectives.

The question is not whether to adopt agile, but which model is appropriate for each context.

The three environments

Industries operate under different conditions and three broad environments determine how agile should be applied.

The first environment is highly regulated: Banking, financial services, healthcare and defence face strict compliance obligations, safety requirements and audit trails. Change is possible, but it must be controlled, documented and defensible.
The second is product and speed driven: Technology companies and retail organisations depend on rapid responses to customer needs. Requirements change frequently, and release frequency is a key competitive advantage.
The third is asset and infrastructure intensive: Manufacturing and utilities manage physical systems and long-lived infrastructure, where errors can have significant consequences. In these settings, agile and plan-driven delivery must coexist.

Programme leaders should first identify the operating environment before considering any framework.

What this looks like in practice

Consider banking. Development teams work in scrum, with short iterations, evolving requirements and tight feedback loops. But releases are planned events, preceded by governance checkpoints, with extensive regression, compliance sign-off and change advisory board approvals at each stage. SAFe coordinates across teams. Waterfall governs the release. Neither alone is sufficient.

In technology and software, the picture looks entirely different. Large platform businesses run SAFe at the portfolio level while individual teams use Scrum or Kanban to deliver continuously, with high release frequency driven by low regulatory ceilings and constant customer demand.

Utilities present perhaps the most instructive example. One major US energy company faced a large-scale customer platform modernisation requiring integration across more than 50 legacy systems. The solution was not to go fully agile or remain fully waterfall. Software delivery adopted SAFe with iterative sprints and Kanban for operational flow. Capital infrastructure and grid operations remained plan-driven with tightly controlled change windows. Two delivery models, one programme, one coherent outcome.

The pattern across all three environments is consistent. Successful organisations are not those that choose the most popular framework, but those that understand their constraints, assess their risk tolerance and build a delivery model that aligns with both.

The leadership decision

This is where programme leadership becomes the deciding factor. A framework does not assess the environment. A tool does not evaluate regulatory burden, safety criticality, or organisational maturity. A methodology does not decide whether your release cadence should be continuous or controlled. A programme leader does.

The most common failure pattern is not a poor framework, but a good framework applied without judgement. An organisation mandates SAFe enterprise-wide because a competitor adopted it. A team is told to run two-week sprints in an environment where no release can go to production without six weeks of compliance testing. The mismatch goes unquestioned because the framework came with a consultant and a certification programme.

Mature programme leadership starts by asking the right questions, before any framework enters the conversation:

What is our regulatory environment?
What is our actual risk tolerance, not our aspirational one?
How often can we genuinely release?
How dependent are we on legacy systems and third parties?
How ready is our organisation, not just our technology teams?

The answers to these questions should drive the framework choice, not the other way around. This is what mission-led delivery looks like in practice. Not agile for its own sake, but the right model in the right hands for the right environment.

The real question

Organisations that navigate complexity and uncertainty best are rarely those with the most sophisticated frameworks. They are those with the most contextually aware leadership.

Agile is not a religion. SAFe is not a silver bullet. Waterfall is not the enemy. Scrum and Kanban are not universal defaults. These are tools, and like any tool, their value depends entirely on whether the person using them understands the job at hand.

The next time someone asks which agile framework your programme should adopt, the right answer is not a framework name. It is a question back: what environment are we actually operating in?