Agile

SAFe and scaling agile: when and how to move from Scrum to the Scaled Agile Framework

By Codevista InnovationsPublished 12 October 2026Updated 15 October 202610 min read

SAFe (Scaled Agile Framework) earns its place when several agile teams deliver a single solution together and dependencies, competing priorities and late integration wipe out what each team gains from Scrum. It adds a structure, the Agile Release Train, a shared planning event, PI Planning, and Lean portfolio management, at the price of extra roles and events. Before adopting it, make sure your problem really lies in coordination between teams, and that senior leadership is ready to get involved in person.

How do you know Scrum is no longer enough?

Scrum is designed for a small team that can deliver a usable increment on its own. As long as a product fits within one or two teams, applying Scrum better or switching to Kanban usually solves most problems (see our Scrum vs Kanban comparison). The difficulties change in nature once several teams work on the same solution:

• Cascading dependencies: one team waits for an API, an environment or a sign-off from another, and the sprint ends without a usable increment.
• Misaligned priorities: each Product Owner optimises their own backlog, nobody arbitrates between teams, and the business receives fragments of features that are useless on their own.
• Painful integration: each team declares itself "done" on its side, then assembling everything at the end of the quarter looks exactly like the old integration phase of the V-model.
• No visibility for leadership, which ends up demanding detailed six-month plans that contradict the sprints.

A simple test: reread the impediments raised in your last retrospectives. If they are mostly about how each team works internally, scale is not the problem. If they consistently point to another team, a missing decision or late integration, the question of scaling agile becomes a legitimate one.

What SAFe adds: Agile Release Train, PI Planning and portfolio

The Scaled Agile Framework does not replace Scrum or Kanban at team level: it organises them around a shared value stream. The official reference, which is authoritative on terminology and changes from one version to the next, is published at scaledagileframework.com.

The Agile Release Train (ART)

An ART is a long-lived team of agile teams that shares the same mission, the same ART Backlog and the same cadence. It is deliberately kept to a limited size, roughly 50 to 125 people according to the framework, so that everyone can plan in the same room. The Release Train Engineer (RTE) facilitates it, Product Management prioritises the features, the System Architect holds the technical vision, and the Business Owners represent business interests and approve the objectives.

PI Planning

A PI (Planning Interval, formerly Program Increment) groups several iterations, followed by an Innovation and Planning (IP) Iteration. At the start of each PI, all the teams on the train come together for PI Planning, usually over two days: they break down the features, make dependencies visible on the ART Planning Board and commit to PI Objectives. During the PI, the System Demo shows the integrated increment of the whole train; the PI closes with an Inspect & Adapt.

The portfolio level

In the Portfolio SAFe configuration, Lean Portfolio Management funds value streams rather than individual projects, and Epics go through a Portfolio Kanban before being approved. This is often where the real change happens for an executive team, because it touches budgets and governance, not just the way teams work.

What does SAFe cost in ceremonies and organisation?

The cost of SAFe is not just a training invoice. It is measured above all in time and attention:

• New roles (RTE, Product Management, System Architect), held by people who are genuinely available, not added on top of an already full job.
• Extra events: PI Planning, System Demo, Inspect & Adapt, regular synchronisation between teams, feature refinement ahead of time.
• A shared vocabulary that the whole organisation has to adopt, which means training for teams, managers and executives.
• A proprietary framework: SAFe is a trademark of Scaled Agile, Inc., which issues the official certifications; this weighs on the training and certification budget.
• A risk of bureaucracy if the framework is applied mechanically, artefact by artefact, without asking what each one contributes.

That cost is justified when it replaces informal coordination that is already expensive: crisis meetings, decisions made by escalation, weeks lost to integration. It is not justified for two teams that could simply share a backlog and a review.

SAFe, LeSS, Scrum@Scale or Kanban: what are the alternatives?

SAFe is the most fully equipped and the most prescriptive framework, but it is not the only one. The alternatives are neither better nor worse in principle; they make different bets:

• LeSS (Large-Scale Scrum): a single Product Owner and a single Product Backlog for several teams, with very few added roles. Demanding in terms of technical maturity and organisational redesign.
• Scrum@Scale: a modular extension of Scrum that grows the organisation through linked networks of teams.
• Nexus: the Scrum.org framework for a handful of Scrum teams working on the same product, with a dedicated integration team.
• A well-run portfolio Kanban: make every initiative in progress visible, limit work in progress at leadership level and make trade-offs at regular intervals. It is often the cheapest first step, and it prepares the ground for any framework you adopt later.

SAFe suits large organisations above all, those that need explicit roles, portfolio governance and a common language with senior leadership. For a product carried by three or four teams, a lighter framework is generally more proportionate.

Why do SAFe implementations fail?

The failures look alike from one organisation to the next:

• Trains organised by department rather than by value stream: they recreate the silos under a new name.
• Teams that have not mastered Scrum: without stable iterations or a shared Definition of Done, scaling amplifies the disorder.
• An imposed PI Planning: leadership turns up with a fixed scope and date, ignoring the capacity the teams have stated.
• Priorities changed mid-PI without going through Product Management, which empties the PI Objectives of meaning.
• Weak engineering practices: without continuous integration or automated tests, the System Demo shows screens, not an integrated system.
• A framework adopted for appearances, with no measurement of flow or business outcomes.

None of these causes lies in the framework itself: they are organisational. That is why preparation matters more than the choice between SAFe and its competitors.

How do you prepare a first PI Planning?

A first PI Planning takes several weeks to prepare. The essential steps:

1. Identify the value stream and the teams that contribute to it, including the essential support functions (security, operations, compliance).
2. Appoint and train the key roles: RTE, Product Management, System Architect, Business Owners, as well as the teams' Scrum Masters and Product Owners.
3. Build the ART Backlog: prioritised features with acceptance criteria and a business value hypothesis. Regulatory requirements, such as personal data protection under Morocco's data protection law (loi 09-08), belong there from the outset, not at the end of the PI.
4. Prepare the vision that leadership will present at the opening: business context, objectives, constraints, known milestones.
5. Work out each team's capacity, allowing for leave, public holidays and the share set aside for maintenance.
6. Organise the logistics: a room or collaborative tool, the ART Planning Board, a timed agenda, and decision-makers present from start to finish.

During the event

The typical agenda alternates plenary sessions with team breakouts: a presentation of the business context, the product vision and the architecture vision, followed by workshops in which each team builds its iteration plan. A review of the draft plans and a problem-solving session with leadership allow the scope to be adjusted. On the second day, the teams present their final plans, risks are handled using the ROAM method (Resolved, Owned, Accepted, Mitigated) and a confidence vote closes the exercise. A low vote is not a failure: it is the signal to replan before committing.

When teams are spread across several sites, in Casablanca, elsewhere in Morocco or abroad, a well-equipped hybrid format works, provided the Business Owners remain reachable to make decisions throughout the two days.

What leadership must commit to for SAFe to succeed

SAFe cannot be delegated to the IT department. Senior leadership has to:

• Take part: Business Owners attend PI Planning, the System Demo and Inspect & Adapt, and assign business value to the PI Objectives.
• Fund value streams rather than projects, which means revisiting the budget cycle.
• Protect the PI: no urgent requests slipped back in without a decision, and few initiatives running in parallel.
• Own the transformation: appoint a steering team, which the framework calls the Lean-Agile Center of Excellence (LACE), and give it time and authority.
• Get trained in agile leadership and accept that several PIs will be needed before a train finds its rhythm.

HR, finance and marketing are affected as soon as value streams run through them (see agile beyond IT). For an SME, a lighter approach often fits better within a step-by-step digital transformation.

Codevista Innovations offers SAFe training for organisations that have outgrown a single team, and Scrum training to consolidate the fundamentals, on-site anywhere in Morocco, hybrid or remote. Our qualification application with the OFPPT, Morocco's vocational training office, is in progress, so these programmes cannot yet be funded through its Contrats Spéciaux de Formation (CSF, special training contracts). To assess whether SAFe fits your situation, contact our team.

Frequently asked questions

How many teams do you need to justify SAFe?

There is no magic threshold. An Agile Release Train brings together several agile teams delivering the same solution, roughly 50 to 125 people according to the framework. With two or three teams, a shared backlog, joint reviews or a lightweight framework such as Nexus or LeSS is often enough. The deciding factor is how dependent the teams are on one another and whether you need shared planning that leadership can see.

What is the difference between PI Planning and Sprint Planning?

Sprint Planning involves a single team and a single iteration. PI Planning brings together all the teams on an Agile Release Train, along with Product Management, architecture and the Business Owners, to plan a Planning Interval of several iterations together. It makes dependencies visible and results in PI Objectives. Each team then keeps its own iteration planning within the PI.

Do you need to master Scrum before moving to SAFe?

Yes, it is strongly recommended. SAFe relies on teams that can deliver a working increment every iteration, with clear roles and a shared Definition of Done. If teams are already struggling with the fundamentals, scaling amplifies the problems instead of solving them. Consolidating Scrum or Kanban at team level is therefore often the first step.

Can SAFe training be funded by OFPPT in Morocco?

The scheme exists: the Contrats Spéciaux de Formation (CSF) of OFPPT, Morocco's vocational training office, allow a company to recover part of its training costs. Codevista Innovations' qualification application is in progress; until then, its programmes, including SAFe training, cannot be funded this way. Eligibility conditions and the procedure are set by OFPPT: check them directly with the organisation before starting the process. Our article on CSF funding explains how it works.