The translation problem.

Most agile frameworks were written for single-product, single-team, co-located environments. Banks are none of those things. They're multi-product, multi-team, multi-jurisdiction, and the product they're "shipping" is often a regulatory change whose design is partially dictated by an external authority.

That doesn't make agile inapplicable. It does mean that agile in a bank has to do three things the original texts didn't contemplate.

Three things agile has to do that it usually doesn't.

1. Operate under an externally-imposed end date.

Most iterations of Scrum assume you can flex scope, cost or time. In a regulatory uplift program, time is fixed (by the regulator), cost is usually fixed (by the business case), and only scope can move. The job of agile in this environment is to make the scope trade-off visible and conscious, sprint by sprint.

Practically: prioritise by regulatory obligation, not by product manager preference. Re-order the backlog only when the obligation changes, not because the team had a good demo.

2. Survive audit six months later.

A sprint decision made in February will be audited in August. If your retrospective notes are a photo of a whiteboard, you will lose that audit — not because the decision was wrong, but because you can't reconstruct the reasoning.

In regulated agile, every material decision needs a written artefact: a design note, a risk-accepted memo, a variance record. This isn't bureaucracy — it's the difference between "we made a judgement call" and "we have nothing to show the auditor".

3. Coexist with waterfall dependencies.

Most bank programs depend on upstream or downstream systems that don't work in sprints. A trade-surveillance uplift shipping fortnightly is blocked by a market-data migration that releases twice a year.

Agile in this environment means explicit dependency management at the program level — not wishful thinking about "agile at scale". I've yet to see a program that tried to pretend the waterfall didn't exist that delivered well.

The healthiest agile programs in banking I've seen don't pretend to be "pure" anything. They're deliberately hybrid, and they're honest about it.

Ceremonies worth keeping, ceremonies worth cutting.

A practical list, from programs I've run or reviewed:

  • Keep: sprint planning, daily stand-up, sprint review. These are the load-bearing ceremonies.
  • Keep, but re-shape: retrospectives — capture the written output, not just the Miro board.
  • Often cut: scaled big-room planning events that turn into two-day decks. Effective for the first PI, diminishing returns after.
  • Often over-done: backlog refinement. One hour per sprint is usually enough; three is a symptom of an unclear product owner.
  • Almost always cut: scrum of scrums of scrums. If you're three levels deep, replace it with a weekly written program stand-up.

Working with risk, audit and compliance.

The best delivery leads I've seen in banking treat risk, audit and compliance as customers of the program, not obstacles to it. That shift is almost always the unlock.

Practical moves:

  • Invite a named representative from risk and from compliance to sprint reviews. Not always, but at material checkpoints.
  • Ask them to help define the "definition of done" for regulatory stories. They know what audit will ask.
  • Circulate sprint goals to them 48 hours in advance, not at the review itself. Surprises in a sprint review are how relationships break.
  • Agree a written variance process for risk-accepted items. Document it once, apply it repeatedly.

A closing note on scale.

SAFe, LeSS and the various scaled-agile frameworks are fine starting points, but I've never seen any of them applied verbatim in a Tier-1 bank without significant local adaptation. The frameworks are starting kits — they're not operating models.

The real operating model is the one your program writes for itself, based on the specific regulatory, vendor, and internal-audit constraints you're operating under. That document — usually about 15 pages — is the single most important artefact in the first ninety days of any regulated agile program I've run.

Write it, agree it, and revisit it every quarter. Everything else follows.