Enterprise Agile is not a certification programme. It is an operating model change: how work flows across business units, shared services, and countries; who owns scaling decisions; and how delivery capability is enabled at leadership level, not just coached at team level.
This guide sets out the step-by-step approach I use when building and rolling out Agile in federated, regulated enterprises. It ends with a practical answer to a question I hear constantly: when do you use Scrum, SAFe, and Flight Levels together, and for what goal?
"Frameworks are tools. Enterprise Agile is the operating model, the enablement system, and the rollout plan that makes those tools work under board scrutiny."
Step 1: Diagnose the enterprise context
Timeline: Weeks 1 to 4 · Owner: Transformation lead + CoE sponsor
Before selecting SAFe, Scrum@Scale, or anything else, map where Agile must land. In federated organisations this means understanding decentralised business units, group-wide shared services, country entities, and onshore-offshore delivery structures as one system, not separate programmes.
- Map the federation: who decides capacity, funding, architecture, and compliance in each entity
- Identify value streams versus project silos and hidden dependency chains
- Assess maturity honestly: observe ceremonies and backlogs, do not rely on surveys alone
- Surface real blockers: politics, audit gates, architecture forums, parallel compliance tracks
Outputs: current-state map, pain points by BU/country, sponsor agreement on what success looks like (flow, predictability, regulatory response, cost of delay).
Step 2: Define the target operating model
Timeline: Weeks 4 to 8 · Owner: CoE + enterprise architecture + portfolio office
This is where end-to-end scaling ownership begins. Decide how Agile works at enterprise level: decision rights, governance cadence, artefact standards, and role design (RTE, ART, PO, internal coaches, chapter leads).
Sketch operating model options before you commit
The most expensive mistake at this stage is picking one framework and calling it the operating model. In federated enterprises, the operating model is a set of choices about who decides, who enables, who delivers, and how work flows across entities. The right way to do this is to sketch two or three viable options, score them against named needs, and choose with sponsors before rollout spend begins.
Each sketch should answer the same questions on one page:
- Scope: which BUs, countries, and shared services are in wave 1 vs. later waves
- Decision rights: what the CoE mandates centrally vs. what local entities adapt
- Scaling unit: ART, cluster, product group, or chapter-based model
- Planning rhythm: PI, quarterly planning, or continuous flow with checkpoint gates
- Enablement model: central CoE, federated coach network, or hybrid coach-the-coach
- Governance hooks: SteerCo, architecture forum, risk/compliance cadence
Four operating model sketches I use frequently in regulated, federated environments:
Operating model selection canvas
Use this canvas in a half-day workshop: score each sketch against your six priority needs, then select a primary model (often Sketch A for group-wide Delivery Enablement chapters), a secondary layer (often Sketch C for sub-chapters and lifecycle), and add Sketch D only where regulatory capacity must be explicit.
Match the sketch to enterprise needs
Do not ask "Are we a SAFe shop?" Ask which needs must be fulfilled in the next 12 to 18 months, then pick the sketch that serves them with the least organisational friction.
Present three sketched operating models to sponsors and BU leads. Score each against six needs: speed, autonomy, compliance, enablement, transparency, and cost of change. Choose one target model and one fallback. Document what is mandated vs. optional. That decision record becomes the scaling blueprint input for Step 4 pilot design.
- Choose scaling backbone pragmatically once the sketch is selected (see framework mix section below)
- Define federated governance: what the CoE owns centrally vs. what BUs/countries adapt locally
- Align SteerCo / PI / portfolio rhythms to regulatory and audit calendars
- Standardise artefacts: backlogs, risks, dependencies, compliance evidence
Outputs: operating model option sketches, needs-fit decision record, target operating model, scaling blueprint, federated governance charter.
Step 3: Stand up enterprise delivery enablement
Timeline: Weeks 6 to 12 · Owner: Agile CoE
Scaling fails when enablement stops at team training. Enterprise delivery enablement means building the engine that makes rollout repeatable: CoE mandate, coach-the-coach models, RTE/ART enablement, and leadership coaching tied to real decisions.
- Establish or strengthen the Agile CoE with written authority, not sponsorship alone
- Build internal coach capacity and reduce dependency on rotating external trainers
- Enable leaders, RTEs, and POs at cluster and country level
- Align HR, funding, and architecture forums to the new delivery model
Outputs: CoE operating model, enablement curriculum, internal coach network, leadership playbook.
Step 4: Pilot in one federated slice
Timeline: Months 3 to 6 · Owner: Programme lead + CoE
Prove the model in one bounded but real slice before enterprise rollout. The pilot should cross functions and test federated handoffs: BU plus shared service, or onshore-offshore, or two countries on one value stream.
- Launch first ART, cluster, or equivalent scaling unit
- Run first PI or quarterly planning cycle with real dependencies
- Embed compliance and risk into backlog flow, not a parallel track
- Measure flow, dependency health, and delivery confidence
Outputs: reference model, baseline metrics, rollout playbook v1, executive narrative for expansion.
Step 5: Roll out in waves across the federation
Timeline: Months 6 to 18 · Owner: Transformation lead + CoE + BU sponsors
Scale without creating Agile theatre. Sequence waves by readiness, dependency, and business priority. Replicate the operating model with local adaptation, not local reinvention.
Step 6: Embed governance in flow
In regulated enterprises, governance must live inside delivery. Map regulatory obligations to Agile artefacts. Align architecture, risk, and compliance forums to PI cadence. Reserve capacity for regulatory work honestly (typically 20 to 35% in banking), sized and visible in the backlog.
Do not treat compliance as an unplanned interrupt that breaks the sprint. Treat it as a first-class backlog with joint ownership between Legal, Compliance, and delivery teams.
Step 7: Measure enterprise adoption, not ceremony compliance
Report at three levels. Team/flow: cycle time, throughput, dependency resolution. Programme/cluster: PI predictability, cross-team coordination, release readiness. Enterprise: adoption by BU/country, CoE enablement coverage, regulatory response speed, cost of delay.
Step 8: Institutionalise and exit
Transition from external lead to internal CoE ownership. Certify internal coaches and RTEs. Refresh the operating model annually. Kill anti-patterns: fake Agile, waterfall in sprint clothing, compliance parallel tracks that bypass flow.
Outputs: self-sustaining CoE, internal enablement factory, continuous improvement loop.
Using Scrum, SAFe, and Flight Levels together
Non-religious enterprise Agile means assigning each framework to the problem it solves best. They are complementary, not competing denominations.
Which framework for which enterprise goal?
- Goal: Stand up team delivery capability → Start with Scrum (or Kanban where flow is continuous). Add engineering standards and Definition of Done tied to audit needs.
- Goal: Scale to multi-team programme with dependencies → Add SAFe (or Scrum@Scale) for ART structure, PI planning, and RTE enablement. Keep Scrum inside teams.
- Goal: Fix portfolio bottlenecks and leadership misalignment → Add Flight Levels to make work visible at strategy, initiative, and team layers. Use it in SteerCo and CoE forums.
- Goal: Federated rollout across countries → SAFe for common ART/PI backbone; local Scrum practice; Flight Levels to compare flow and capacity across entities without forcing identical team structures.
- Goal: Regulatory programme under hard deadline → SAFe for programme governance and dependency tracking; Scrum for squad execution; explicit regulatory capacity allocation in every PI.
If a framework choice cannot be linked to a named enterprise goal (faster flow, clearer dependencies, better enablement, safer rollout), it is probably theatre. Pick the minimum mix that solves the next constraint, then expand in the next rollout wave.
Closing thought
I do not start with frameworks. I start with the federated operating model, stand up enterprise delivery enablement through a CoE, pilot in one real slice, then roll out in waves with governance embedded in flow. Scrum, SAFe, and Flight Levels are applied where each earns its place.
That is how Agile becomes an enterprise capability instead of a training programme that fades after the consultants leave.