Agile in Regulated Industries: What Actually Works

In defence, aerospace, banking and insurance, "going agile" has a poor reputation among the people who actually carry the risk. Not because the teams are cynical, but because they have seen the pattern before: a transformation arrives, the walls fill with sticky notes, everyone learns the ceremonies, certificates are handed out — and eighteen months later the organisation is delivering at roughly the same pace, only now with more meetings and a new vocabulary. Meanwhile the regulator still wants the same evidence, the safety case still has to hold, and the regulator has not relaxed a single requirement.

The problem is rarely agile itself. The problem is treating agile as the goal.

The goal was never "to be agile"

Agile, whatever you take that word to mean this week, is a means. The goal in a regulated business is the consistent delivery of world-class software and systems — delivery that is fast and holds up when it is inspected. When teams lose sight of that and optimise for the ritual instead, they get the worst of both worlds: they adopt the overhead of agile ceremonies without the engineering discipline that makes speed safe, and they treat assurance as an obstacle to route around rather than something to build in.

That is why so many transformations in audited environments stall. They change the surface — the stand-ups, the board, the job titles — without changing the operating model underneath. The funding is still project-shaped, the teams still disband the moment a milestone is signed off, and the compliance work still happens in a long, painful phase at the end. Rename all of that "agile" and you have simply added cost.

Why regulated is genuinely different

It is worth being honest about this, because a lot of generic agile advice quietly assumes you can ship, learn and correct in the open. In a regulated context you often cannot, and pretending otherwise is how transformations lose credibility with the engineers and risk people whose support they need.

In these industries, output is audited. An airborne system carries design-assurance obligations. A change to a trading or lending platform has to be traceable, reviewable and reversible, with evidence that controls were applied. A safety-critical system needs a safety case that remains valid as the software changes. None of that is bureaucracy for its own sake — it is the reason the public trusts an aircraft, a bank or a defence capability to work. Any approach to delivery that treats those obligations as friction to be minimised is not going to survive contact with the environment, and it should not.

So the real question is not "how do we do less of the compliance work so we can go faster?" It is "how do we generate the assurance continuously, as a by-product of good engineering, rather than as a phase bolted on at the end?"

The false choice between speed and control

Most organisations experience speed and control as a trade-off. Want to move faster? Loosen the gates. Want tighter control? Add more review, more sign-off, more documentation, more delay. Under that model, every improvement on one axis is a loss on the other, and the two sides — delivery and assurance — end up in a slow, adversarial stand-off.

That trade-off is real only when control is applied as a series of manual gates at the end of the process. When the controls are moved into the way the work is done, the relationship inverts. Small, frequent, well-tested changes are easier to review, easier to trace and easier to reverse than large, infrequent ones. Automated pipelines produce the evidence trail — who changed what, which tests passed, which checks ran — as an artefact of the work itself, not as a documentation exercise performed from memory weeks later. Done well, going faster and being more auditable become the same activity, because both are served by smaller batches and stronger engineering discipline.

This is the point most "agile transformations" miss, and it is the point that matters most in regulated industries.

What actually works

Across complex, regulated organisations, the changes that move the needle are consistent, and almost none of them are about ceremonies.

Change the operating model, not just the process. A project model funds a burst of activity, assembles a team, hits a milestone and disperses — taking the hard-won knowledge with it. In systems that live for years or decades, that is enormously wasteful and quietly dangerous. A product operating model keeps a persistent, accountable team around a product or capability, with stable funding and clear ownership. Continuity of people is continuity of understanding, and in an audited environment understanding is what keeps you safe.

Build assurance in, continuously. Treat traceability, testing and evidence as things the pipeline produces automatically, not as a phase. Compliance expressed as code and automated checks is faster, more reliable and more credible to an auditor than a folder of documents assembled at the end. The aim is that at any moment you can show the state of the system and how it got there.

Put the assurance people inside the team. Risk, safety and compliance specialists should be part of delivery from the first day, shaping how the work is done, rather than a downstream gate that discovers problems when they are most expensive to fix. When those perspectives are in the room continuously, controls stop being a surprise and start being a design input.

Work in small batches and integrate often. Reducing the size of each change is the single most effective way to reduce risk — and, not coincidentally, the thing that lets cadence go from a release every few weeks to several a day. Small changes fail smally, are understood easily and are reversed cleanly. Auditors, once they see the evidence trail that comes with them, tend to prefer this to occasional large releases.

Insist on senior people doing the actual work. In hard environments the gap between advice and delivery is where transformations die. The people designing the change should be the people delivering it, close enough to the real constraints to adapt when the plan meets reality — not a strategy deck handed to a more junior team to implement.

What it looks like when it works

None of this is theoretical. When the operating model changes and assurance is built in rather than bolted on, regulated organisations move from a release every few weeks to several a day, and cut delivery times by half — across multiple products, multiple countries and multiple regulatory regimes — without weakening the controls that let them operate at all. The teams are not going faster by cutting corners. They are going faster because the way they now work produces better evidence, smaller risks and fewer expensive surprises.

That is the outcome worth aiming at. Not a more agile-looking organisation, but a consistently delivering one whose speed and whose auditability come from the same source.

Where to start       

The mistake is to begin by rolling out a framework. Begin instead by understanding where your delivery actually loses time and where risk actually concentrates — which is rarely where the org chart suggests. A short, focused review of how work really flows, where it waits, and where assurance is applied late will tell you more than any maturity model. From there the sequence is almost always the same: fix the operating model and the engineering foundations first, and let the practices follow the outcomes rather than leading with them.

Agile was never the goal. Consistent delivery of world-class software and systems, in industries where that delivery is audited, always was.

Hiisi Consulting builds product operating models in complex, regulated businesses — defence, aerospace, satellite, financial services and insurance. If you want to know where your delivery is actually losing time, our Rapid Review is a focused, low-commitment place to start.