SAFe (Scaled Agile Framework): SAFe – Tutorial (about 60 minutes)

The Scaled Agile Framework, almost always shortened to SAFe, is a publicly available body of guidance for running many agile teams as one coordinated system, from the individual team up to the investment decisions of a portfolio. Large companies and government agencies use it when dozens or hundreds of people must build and evolve the same products together, often across software, hardware and business functions. After this tutorial you will be able to explain the problem SAFe tries to solve, describe its values, principles, configurations, roles, events and backlogs, follow an Agile Release Train through a full Planning Interval, and judge whether an implementation is delivering real outcomes or only adding ceremony.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: SAFe is a proprietary framework owned, maintained and published by Scaled Agile, Inc., the company co-founded by its creator Dean Leffingwell. It was first released in 2011 and evolved through a series of numbered versions; the last numbered major version is SAFe 6.0, released in March 2023, and the official site still offers the SAFe 6.0 Big Picture configurations. Since then Scaled Agile has updated the framework continuously and logs changes month by month on its "What's New" page: in early 2025 the competencies were regrouped into five disciplines, and in 2026 guidance was added on AI-empowered agility and on Strategic Investment Planning. In June 2026 Scaled Agile introduced a second operating model, AI-Native SAFe, which it describes as a reinvented operating model that sits alongside, and does not replace, the established model now called Core SAFe. This tutorial teaches Core SAFe, using the vocabulary established in SAFe 6.0, and mentions AI-Native SAFe only for context. SAFe is not an ISO, IEC or national standard, and there is no certification of an organisation as "SAFe compliant"; Scaled Agile certifies individuals. Verified 2026-10-29 against framework.scaledagile.com.

Who it is for: engineers, testers, architects, product owners and product managers, project, programme and delivery managers, quality, security and compliance professionals, and leaders who are joining an organisation that uses SAFe or who are evaluating whether to adopt it. No previous SAFe experience is assumed.

Prerequisites: none formally. A basic understanding of a single-team agile method such as Scrum or Kanban helps, because SAFe builds on team-level agility rather than replacing it. Where team-level ideas matter, this tutorial explains them briefly.

How to use this tutorial: read the seven lessons in order (about 45 minutes), study the five diagrams, then spend the remaining time on the reflection questions before taking the 25-question knowledge check.

Learning objectives:

You will be able to explain why scaling agile is hard and which ideas from Lean, agile development, product development flow and DevOps SAFe draws on.
You will be able to name the four core values and summarise the ten Lean-Agile principles in your own words.
You will be able to describe the four Big Picture configurations, the five disciplines and the backlog hierarchy of epics, capabilities, features and stories.
You will be able to walk an Agile Release Train through a Planning Interval, including PI Planning, iterations, the System Demo and Inspect and Adapt.
You will be able to prioritise work with Weighted Shortest Job First and explain how Lean Portfolio Management funds value streams instead of projects.
You will be able to distinguish individual SAFe certifications from organisational claims and use outcome, flow and competency measures to judge progress.
You will be able to compare SAFe with Scrum, Kanban, LeSS, Nexus, Scrum@Scale, Disciplined Agile and traditional project frameworks.

Lesson 1 – Origins, purpose and scope

The problem SAFe addresses

A single agile team of, say, eight people can plan together, talk every day and show working results every two weeks. The difficulty starts when one product needs fifteen such teams, plus architects, operations staff, security specialists, a hardware group and an external supplier. Each team may be agile on its own, yet the whole system still behaves like a slow, plan-driven organisation: teams wait for each other, integration happens late, priorities conflict, and funding is still decided once a year for projects that were defined before anyone learned anything. Leaders cannot see real progress, and teams cannot see how their work connects to the strategy.

SAFe was created to give such organisations a shared operating model. It answers questions that single-team methods deliberately leave open: how many teams should plan together, how often, and around what; who decides the order of large pieces of work; how architecture and integration are handled when no single team owns the whole system; and how a portfolio funds and governs work without returning to detailed project plans. The framework calls the target state business agility, meaning the ability of an enterprise to sense changes in its market and respond quickly with innovative, digitally enabled solutions.

Where SAFe came from

Dean Leffingwell had worked for years on software requirements and on agile adoption in large companies. His books on scaling agile practices, especially Scaling Software Agility (2007) and Agile Software Requirements (2011), described patterns that he and colleagues had seen work in big organisations. In 2011 these patterns were published as the first version of the Scaled Agile Framework, presented as a single large diagram called the Big Picture, with each icon linked to an article on a public website. Scaled Agile, Inc. was founded to maintain the framework and to run a training, certification and partner programme around it.

SAFe deliberately combines several bodies of knowledge rather than inventing a new theory. From agile development it takes short iterations, cross-functional teams and the values of the Agile Manifesto. From Lean thinking, rooted in the Toyota Production System, it takes the focus on value, flow, eliminating waste and respect for people. From product development flow, especially the work of Donald Reinertsen, it takes economic decision-making, the idea of cost of delay, small batch sizes and limiting work in process. From systems thinking it takes the view that the organisation and the solution are both systems that must be optimised as a whole. From DevOps it takes automation, continuous delivery and shared responsibility for running what is built.

Scope and use

SAFe is not limited to software. Its guidance covers cyber-physical systems that combine hardware, firmware and software, regulated environments such as medical devices, finance and defence, and business functions such as marketing that adopt agile ways of working. Because the framework is a knowledge base rather than a rulebook, the guidance states that organisations should start with the minimal elements they need and add more only when a real problem calls for it.

SAFe is also widely debated. Some agile practitioners argue that it is too prescriptive or that it can preserve old hierarchies under new names; supporters answer that it is meant to be tailored and that such problems come from poor implementations. Either way, you should learn to tell a healthy implementation from an unhealthy one.

Lesson 2 – Key concepts and vocabulary

SAFe has a large vocabulary. Many terms were renamed in SAFe 6.0, so you will still meet older names in organisations that adopted earlier versions; where that matters, the older name is given in brackets. The terms below are the minimum you need to follow the rest of the tutorial.

Agile Release Train (ART) – a long-lived team of agile teams, usually between about 50 and 125 people, that plans, builds, delivers and often operates one or more solutions together on a shared cadence.
Planning Interval (PI) – a fixed timebox, typically 8 to 12 weeks, in which an ART plans together and then delivers value in a series of iterations (called a Program Increment before SAFe 6.0).
Iteration – the team-level timebox inside a PI, usually two weeks, in which each agile team plans, builds, tests and reviews a small increment.
Innovation and Planning (IP) iteration – the last iteration of each PI, reserved for innovation, learning, final integration work, Inspect and Adapt and preparation for the next PI Planning; it also acts as an estimating buffer.
Value stream – the sequence of steps that delivers value to a customer. An operational value stream delivers a product or service to customers; a development value stream builds and evolves the solutions that the operational one uses.
Solution – the product, service or system that a train delivers to its customers, whether internal or external.
Epic – a significant initiative, large enough to need a lightweight business case and an approval decision by portfolio leaders before implementation.
Capability – a large piece of solution behaviour that spans several ARTs in a large solution and is sized to be finished within one PI.
Feature – a service or behaviour that delivers business value, sized so that one ART can deliver it within one PI; features are described with a benefit hypothesis and acceptance criteria.
Story – a small piece of desired functionality, usually written from a user's point of view, that one team can complete within one iteration.
Enabler – work that does not deliver user value directly but makes future value possible, such as architecture, infrastructure, exploration or compliance activities. Enablers can exist at every backlog level.
Architectural runway – the existing code, components and technical infrastructure needed to implement upcoming features without excessive redesign or delay.
PI objectives – a summary, in business language, of what each team and the ART intend to achieve in the PI; each is marked as committed or uncommitted.
Weighted Shortest Job First (WSJF) – SAFe's prioritisation model, which orders work by dividing its cost of delay by its job size or duration.
Cost of delay – the economic value lost by postponing a piece of work, the numerator of WSJF.
Lean Portfolio Management (LPM) – the function, and the discipline, that aligns strategy with execution by funding value streams, managing the flow of epics and applying lightweight governance.
Lean-Agile Center of Excellence (LACE) – a small, dedicated team that drives and supports the SAFe transformation.
SAFe Practice Consultant (SPC) – a certified change agent qualified to train others in SAFe and to guide an implementation.

Two further ideas recur throughout. Cadence is a predictable rhythm of events that makes planning and integration routine, and built-in quality means quality practices such as test automation and continuous integration are part of daily work, not a final phase.

Lesson 3 – Structure of the framework

Values, mindset and principles

At the foundation of SAFe sit four core values. Alignment means everyone understands the strategy and how their work contributes to it. Transparency means that plans, progress, problems and data are visible, so that trust can grow and decisions are based on facts. Respect for people means valuing the people who do the work, as well as customers and suppliers, and giving them the conditions to succeed. Relentless improvement means a constant sense of urgency to learn and get better, at every level.

On top of the values, SAFe describes a Lean-Agile mindset, the combination of Lean thinking and the agile values, and ten Lean-Agile principles that guide decisions where no practice gives a direct answer. In paraphrase:

Take an economic view – make decisions on the basis of value, cost, risk and delay, and deliver early and often.
Apply systems thinking – optimise the whole solution and the whole organisation, not individual teams or departments.
Assume variability; preserve options – keep several design options open while uncertainty is high instead of committing early to one.
Build incrementally with fast, integrated learning cycles – build in small integrated steps and use each step to test assumptions.
Base milestones on objective evaluation of working systems – measure progress by demonstrating working solutions, not by completed documents.
Make value flow without interruptions – manage queues, batch sizes and work in process, and remove blockers to flow.
Apply cadence, synchronise with cross-domain planning – use a regular rhythm and plan together across teams and disciplines.
Unlock the intrinsic motivation of knowledge workers – provide autonomy, purpose and mastery rather than relying on individual incentives.
Decentralise decision-making – keep strategic, infrequent decisions central and push frequent, time-critical decisions to those closest to the work.
Organise around value – structure teams and trains around the flow of value to customers rather than around functions or projects.

The principles matter because SAFe cannot list a practice for every situation; when people disagree, they provide the reasoning a good answer should respect.

The five disciplines and their competencies

SAFe 6.0 originally described seven core competencies of business agility. Since early 2025 the framework organises its guidance into five disciplines, each made up of competencies that are framed around the business problems they solve:

Leadership and Culture – how leaders lead change, develop people, run management teams in an agile way and build an organisation that learns, including how to adopt AI responsibly.
Team and Technical Agility – how effective agile teams and trains are formed, how they build quality software and systems, deliver continuously and maintain the architectural runway.
Product Development Flow – how to organise teams and trains around value, discover and validate what customers need, create responsive roadmaps, scale requirements and accelerate flow.
Large Solution Integration and Delivery – how multiple trains and suppliers coordinate to build very large or cyber-physical systems, including Lean systems engineering.
Lean Portfolio Management – how a portfolio sets strategy, validates investments, funds value streams, balances its work and governs it with lightweight practices.

The four configurations

The Big Picture has long been published in four configurations, which are views of the framework sized for different situations. They nest rather than compete: every configuration contains the essential elements, and the larger ones add layers.

Figure 1 – The four SAFe configurations nest: Essential is the base, Large Solution and Portfolio each add a layer, and Full SAFe combines both.

Essential SAFe is the starting point and the minimum needed to work the SAFe way: agile teams, one or more ARTs, the core roles, PI Planning and the other train events, the Lean-Agile principles and values. Large Solution SAFe adds a Solution Train to coordinate several ARTs and suppliers that build one very large solution, such as an aircraft system or a national payments platform, without a portfolio layer. Portfolio SAFe adds Lean Portfolio Management: strategic themes, lean budgets and guardrails, the portfolio backlog and portfolio Kanban, and the portfolio roles. Full SAFe combines all of these for the largest enterprises. On the current official site, the Core SAFe Big Picture is organised around the five disciplines, with the mindset, values and principles at its base.

Backlog levels

Work in SAFe is captured in a hierarchy of backlogs, each owned by a different role and sized for a different horizon. Large items at the top are split into smaller items further down, so that strategy can be traced to the stories that teams build each iteration.

Figure 2 – The backlog hierarchy: epics are split into capabilities (in a large solution) or directly into features, and features into stories that one team can finish in an iteration.

The Portfolio Backlog holds approved epics. The Solution Backlog, used only with a Solution Train, holds capabilities. The ART Backlog (formerly the Program Backlog) holds features and is managed by Product Management. Each Team Backlog holds stories and enablers and is managed by the team's Product Owner. Enablers appear at every level alongside the business items, so that technical work competes for capacity openly instead of being hidden.

Lesson 4 – How it works in practice

Agile teams

Everything in SAFe rests on cross-functional agile teams of roughly ten or fewer people who can define, build and test what they deliver. Teams may use Scrum-based practices, Kanban or a mix, and they work in iterations that are synchronised across the train. Each team has a Product Owner, who owns the Team Backlog and works with customers and Product Management, and a Scrum Master/Team Coach, who facilitates the team's events, coaches it and helps remove impediments. The team-level events are iteration planning, a short daily team sync, backlog refinement, the iteration review and the iteration retrospective. Most teams are stream-aligned, meaning they deliver directly along the flow of value; SAFe also uses the Team Topologies ideas of complicated-subsystem, platform and enabling teams.

The Agile Release Train and its roles

An ART is a team of teams. It is long-lived, so people build relationships and knowledge instead of being reshuffled with every project, and it is organised around a development value stream so that it can deliver end-to-end value with few hand-offs to other parts of the organisation. Beyond the teams, three roles provide train-level leadership:

The Release Train Engineer (RTE) is a servant leader and coach for the train. The RTE facilitates the train's events, helps manage risks and dependencies, escalates impediments and drives improvement. The RTE does not assign work to people.
Product Management owns the ART Backlog: it understands customer needs, defines and prioritises features, and maintains the vision and roadmap.
The System Architect provides the shared technical vision for the train's solutions and guides the architectural runway, working with teams rather than handing down finished designs.

Business Owners are a small group of senior stakeholders with primary business and technical responsibility for the outcomes, governance and return on investment of the train's work. They take part in PI Planning and assign business value to objectives. Trains may also include a System Team that helps build the integration and test environment, Shared Services such as specialist security or data experts who support several teams, and customers who take part in reviews.

The Planning Interval cadence

The heartbeat of an ART is the Planning Interval. A common pattern is a ten-week PI made of four two-week development iterations followed by one two-week IP iteration, although the exact length is chosen by the organisation within the typical range of eight to twelve weeks.

PI Planning

PI Planning is the most recognisable SAFe event. Everyone on the train, ideally including Business Owners and key stakeholders, plans together for about two days, in person where possible or remotely with good tooling. The inputs are the business context presented by leadership, the vision and the top features of the ART Backlog presented by Product Management, and the architectural vision and any changes to development practices presented by the System Architect.

On the first day, after these briefings, teams hold their first breakout: they estimate their capacity for each iteration, pull features into iterations, split them into stories, and identify risks and dependencies on other teams. The day ends with a review of the draft plans and a management review in which leaders resolve scope, capacity and priority problems that teams cannot solve alone. On the second day leaders present the adjustments, teams hold a second breakout to finalise their plans, and Business Owners visit each team to discuss its PI objectives and assign each one a business value on a scale from 1 to 10.

The event produces several outputs. Each team has a set of committed PI objectives and may add uncommitted ones: work it plans to do but cannot fully promise because of uncertainty. The ART planning board (formerly the program board) shows when features are expected to be delivered, along with the dependencies between teams and with external groups and the important milestones. Risks that threaten the plan are reviewed openly and sorted into four ROAM categories: resolved (no longer a concern), owned (someone takes responsibility for it), accepted (it cannot be resolved and is acknowledged) or mitigated (a plan reduces its impact or likelihood). Finally, the whole train takes a confidence vote, commonly by showing one to five fingers. A low result triggers rework of the plan rather than pressure to accept it, because a plan that the people doing the work do not believe in is not a real commitment. A short retrospective on the planning event closes the two days.

Executing the PI

During the PI, teams run their iterations. To keep the train aligned, the RTE facilitates the ART Sync, which combines a Coach Sync (Scrum Masters/Team Coaches discussing progress, impediments and dependencies) and a PO Sync (Product Owners and Product Management discussing scope and priorities). At the end of each iteration the train holds a System Demo, an integrated demonstration of the new features from all teams working together in a production-like environment. The System Demo is the objective evidence the fifth principle asks for: it shows whether the system works, not whether each team claims its part is done.

The PI ends with Inspect and Adapt (I&A), a significant event held during the IP iteration. It has three parts. First, a PI System Demo shows everything the train achieved in the PI. Second, the train reviews quantitative and qualitative measures, including the business value actually achieved against what was planned. Third, a retrospective and a structured problem-solving workshop pick the most important systemic problems, find their root causes and agree improvement items, which then become backlog items for the next PI Planning.

Continuous delivery and DevOps

Cadence governs planning, but release does not have to wait for the end of a PI. SAFe describes a Continuous Delivery Pipeline with four aspects: continuous exploration, which discovers and defines what to build; continuous integration, which builds and tests the work; continuous deployment, which moves changes to production safely, often behind feature toggles; and release on demand, which makes value available to customers when the business wants it. SAFe's DevOps guidance uses the acronym CALMR: Culture, Automation, Lean flow, Measurement and Recovery. The phrase "develop on cadence, release on demand" summarises the idea.

Prioritising with WSJF

Because capacity is always limited, the order of work matters economically. SAFe estimates cost of delay as the sum of three relative scores: user-business value (how much users or the business gain), time criticality (how quickly value decays if the work waits, for instance because of a deadline or a competitor) and risk reduction or opportunity enablement (how much the work reduces future risk or opens new opportunities). Each is scored relative to the other items, usually on a modified Fibonacci scale such as 1, 2, 3, 5, 8, 13 and 20. Job size is used as a proxy for duration. WSJF is cost of delay divided by job size, and the items with the highest result go first.

Consider three features. Feature A has a cost of delay of 21 and a size of 3, so its WSJF is 7. Feature B has a cost of delay of 34 and a size of 13, giving about 2.6. Feature C has a cost of delay of 13 and a size of 2, giving 6.5. Although Feature B is the most valuable in absolute terms, doing A and C first delivers more value sooner. WSJF is a tool for a conversation, not an automatic calculator: the scores are relative estimates, so they should be produced together by the people who understand value and effort, and revisited as conditions change.

Lean Portfolio Management

At the portfolio level, SAFe replaces project-based funding with funding for long-lived value streams. Portfolio leaders define strategic themes, the few business objectives that connect the enterprise strategy to the portfolio, and summarise the current and intended future state on a portfolio canvas. They fund each value stream through lean budgets, and they control spending through guardrails: agreed policies such as how capacity is balanced between new business features and enablers, which decisions need approval, and how Business Owners stay engaged. Since 2026 the framework describes a practice called Strategic Investment Planning, which succeeds the earlier Participatory Budgeting guidance by keeping its collaborative character while adding financial accountability for portfolio leaders.

Large initiatives flow through a Portfolio Kanban system. An Epic Owner takes an epic through the states shown in Figure 4, writing an epic hypothesis statement and a lean business case that defines a minimum viable product (MVP) to test the hypothesis. Enterprise Architects help with technical epics and long-range architecture.

Figure 4 – The Portfolio Kanban: epics move from Funnel through Reviewing and Analyzing to a go or no-go decision, and implementation starts with an MVP that tests the epic hypothesis.

Work-in-process limits on the Reviewing and Analyzing states prevent the portfolio from starting more analysis than it can finish. In Implementing, the ARTs first build the MVP. If the evidence supports the hypothesis, the portfolio perseveres and further features are prioritised through normal WSJF; if not, it pivots or stops, and the epic moves to Done without consuming more funding. This is how SAFe applies Lean Startup thinking to large investments.

Lesson 5 – Assessment, certification and compliance

No organisational certification

SAFe is a framework, not a requirements standard, and there is no accredited audit that certifies an organisation as SAFe compliant. An organisation can say it "uses SAFe", but such a statement says nothing about how well. Contracts that ask for SAFe usually mean suppliers must work on the customer's cadence, join PI Planning or provide certified people.

Certifications for individuals

Scaled Agile, Inc. runs a role-based certification programme for individuals, delivered through its licensed training partners and certified instructors. Introductory certifications include SAFe Agilist, usually earned through the Leading SAFe course, and SAFe Practitioner, earned through the SAFe for Teams course. Role certifications cover, among others, SAFe Scrum Master, SAFe Advanced Scrum Master, SAFe Product Owner/Product Manager, SAFe Release Train Engineer, SAFe Architect, SAFe Lean Portfolio Manager, SAFe DevOps Practitioner and SAFe Agile Product Manager. At the top sits the SAFe Practice Consultant (SPC), the qualification for people who teach SAFe courses and lead implementations. Candidates normally attend the course and then pass an online exam.

Certifications are valid for one year. Holders keep them current by renewing, by upgrading to a newer version of the course, or by completing professional development activities on Scaled Agile's learning platform, SAFe Studio. In 2026 Scaled Agile folded AI-empowered material into its courses, and AI-Native SAFe is now the upgrade path offered to holders of active certifications. Course names, prices and exam details change often, so always check the current information on the official site before planning training.

A personal certificate shows that someone completed a course and passed an exam; it is evidence of shared vocabulary, not of proven skill in leading a train.

Measuring progress: Measure and Grow

SAFe asks organisations to measure their own progress with a practice called Measure and Grow. It looks at three measurement domains. Outcomes ask whether the solutions deliver the intended business and customer results, using measures such as customer satisfaction, revenue, adoption or cost, often organised as key performance indicators or objectives and key results. Flow asks how efficiently value moves through the system. Competency asks how proficient teams, trains and the portfolio are in the practices of the five disciplines, using self-assessments.

SAFe defines six flow metrics:

Flow distribution – the share of each type of work, for example features, enablers, defects and risk reduction, completed in a period.
Flow velocity – how many items are completed in a period.
Flow time – how long items take from start to finish.
Flow load – how many items are in progress or waiting at a time.
Flow efficiency – the share of total flow time in which value-adding work is actually happening, rather than waiting.
Flow predictability – how reliably teams and trains deliver what they planned.

Flow predictability at the train level is commonly measured with the business value assigned during PI Planning. For each team, the actual business value achieved at the end of the PI is compared with the planned business value of its committed objectives. Because uncommitted objectives count towards the actual value but not the planned value, a team can score above 100 percent. SAFe guidance has long treated a range of roughly 80 to 100 percent as a sign of a reliable train: lower values suggest the train cannot plan reliably, while consistently higher values may mean the team is planning too cautiously.

Two cautions apply. First, these measures exist to help the train improve, not to compare teams or reward individuals; when they are used as targets, people learn to game them. Second, flow and predictability are means to an end. A train can be perfectly predictable while delivering features no customer uses, which is why the outcomes domain comes first.

Assessments in regulated work

In regulated sectors, SAFe's compliance guidance suggests treating compliance as part of the work: building compliance activities into the Definition of Done, capturing evidence continuously through automated pipelines, keeping design and compliance information in a living solution intent, and involving quality staff in System Demos. The external standard still defines what must be shown; SAFe offers a way to produce the evidence incrementally.

Lesson 6 – Worked example

To see how the pieces fit together, follow a fictional company through its first year with SAFe. The numbers are illustrative.

The starting point

Harbourline Insurance has about 140 people working on its digital claims experience: a customer mobile app, a claims-handling system used by agents, an integration layer with partner garages and a data group. Work is organised as projects, each funded once a year and staffed by borrowing people from functional departments. Releases happen four times a year after long test phases, and teams regularly discover at integration that they have built incompatible interfaces. Customer complaints about slow claims are rising, and a competitor has launched photo-based claims in minutes.

Figure 5 – A simplified view of the 13-step SAFe Implementation Roadmap, the sequence of steps Harbourline follows from deciding to change to extending SAFe to the portfolio.

Deciding and preparing to change

The tipping point is the competitor's launch: the executive team agrees that the current model cannot respond fast enough. Harbourline hires an external SPC and sends four internal change agents to become SPCs themselves. Together they form a small LACE that reports to the Chief Operating Officer. The executives and department heads attend Leading SAFe, not to learn ceremonies, but to understand what will change in their own roles: funding, decision-making and how they will measure progress.

Organising around value

In a value stream identification workshop, leaders and practitioners map the operational value stream of a customer claim, from first notification to payment. They then identify the development value stream that builds and evolves the systems supporting it. Rather than creating one train per department, they design one ART of about 95 people around the claims value stream, with nine teams: four stream-aligned teams for the customer journey, two for agent tools, one for garage integration, one platform team for the shared claims engine, and a System Team for the integration and test environment.

Planning and preparing the launch

The LACE chooses the launch date for the first PI and fills the train roles: an experienced delivery manager becomes the RTE after training, the claims product lead and two colleagues form Product Management, a senior architect becomes System Architect, and the Head of Claims, the Chief Technology Officer and the Head of Customer Service act as Business Owners. Each team gets a Product Owner and a Scrum Master/Team Coach. In the weeks before the launch, Product Management refines the top ten features of the ART Backlog with benefit hypotheses and acceptance criteria, and ranks them with WSJF. A photo-based damage assessment feature scores highest on time criticality because of the competitor, while an enabler to replace a fragile message queue scores high on risk reduction.

Training teams and the first PI Planning

All team members attend a SAFe for Teams course during the launch week, and the train then holds its first PI Planning. In the first breakout, the garage-integration team realises it depends on the platform team for a new claims-status interface in iteration 2, and records the dependency on the ART planning board. The draft plan review shows that the photo-assessment feature cannot be finished without the message-queue enabler, and that the plan is overloaded by about 20 percent. In the management review, Business Owners agree to defer a reporting feature to the next PI and to keep the enabler.

On the second day, teams finalise their objectives. The Business Owners give the photo-assessment objective a business value of 10 and an internal dashboard objective a 4. Risks are ROAMed: a dependency on a cloud vendor contract is owned by the CTO, the risk that photo-recognition accuracy is too low is mitigated by an early spike, and the absence of a production-like test environment for the garages is accepted for this PI. The confidence vote averages a little under four fingers, which the RTE accepts after discussing the two people who voted two.

Coaching execution

During the PI, the SPCs and the RTE coach the train. The first System Demo is embarrassing: three teams show work on their own laptops, and integration fails. The train treats this as information, not failure. The System Team prioritises an automated integration environment, and by the third iteration the System Demo runs in a shared staging environment.

At Inspect and Adapt, the train reviews its results. Planned business value for committed objectives was 70 points across the teams, and the actual achieved was 56, a predictability of 80 percent, at the lower edge of the usual range. Flow time for features averaged far longer than expected. The problem-solving workshop chooses "features wait too long for manual regression testing" as the most important problem. A root-cause analysis points to the lack of test automation in the agent tools, and the train adds enablers for test automation to the next PI, protected by a guardrail that reserves a share of capacity for enablers.

Growing and extending

After three PIs the claims app supports photo assessment, customer complaints about delays fall, and the train releases small changes every week through its pipeline instead of four times a year. Harbourline launches a second ART for policy sales and then introduces Lean Portfolio Management: it defines two strategic themes, replaces annual project budgets with lean budgets for the two value streams, and sets up a Portfolio Kanban. The first epic to enter the Funnel, a partner marketplace, is analysed with a lean business case whose MVP is a pilot with ten garages. When the pilot shows weak demand, the portfolio pivots before committing the full budget, which would have been very hard under the old project model.

What the example teaches

Harbourline did not start by renaming roles. It started with a business reason, trained leaders first, built the train around a value stream, used PI Planning to expose overload, treated the System Demo as honest evidence and used Inspect and Adapt to fix a systemic problem.

Lesson 7 – Relationship to other standards and frameworks

SAFe is one of several approaches to scaling agile, and it borrows heavily from others. Knowing the neighbours helps you decide what SAFe adds and where another approach may fit better.

Framework	Owner / origin	Focus	Relationship to SAFe
Scrum	Ken Schwaber and Jeff Sutherland; Scrum Guide (2020)	A single small team delivering in Sprints	Many SAFe teams use Scrum practices; SAFe adds train, solution and portfolio layers on top and adapts some terms, such as iteration for Sprint.
Kanban	David J. Anderson and the Kanban community	Visualising work, limiting work in process, managing flow	SAFe teams can use Team Kanban, and the framework uses Kanban systems at the ART and portfolio levels.
Large-Scale Scrum (LeSS)	Craig Larman and Bas Vodde	Scaling Scrum with minimal extra roles: one Product Owner and one backlog for several teams	Much lighter than SAFe; LeSS removes structure where SAFe adds roles, events and portfolio guidance.
Nexus	Scrum.org (Ken Schwaber)	Roughly three to nine Scrum teams working on one product	Covers a similar size to one ART but stays within Scrum and has no portfolio layer.
Scrum@Scale	Jeff Sutherland, Scrum Inc.	Scaling through networks of teams with scaled Scrum Master and Product Owner cycles	Minimal, modular scaling; SAFe is more detailed and prescriptive about cadence and roles.
Disciplined Agile (DA)	Scott Ambler and Mark Lines; owned by PMI since 2019	A toolkit of choices for selecting a way of working in context	DA helps teams choose practices rather than prescribing one system; it can be used alongside or instead of SAFe.
PMBOK Guide and PRINCE2	PMI; PeopleCert (Axelos)	Project management principles, processes and governance	SAFe funds value streams rather than projects, but organisations often keep project-governance standards for some work and must map between the two.
ITIL 4 and DevOps practice	PeopleCert (Axelos); DevOps community	Service management and fast, reliable delivery and operation	SAFe's continuous delivery pipeline and CALMR draw on DevOps; ITIL 4 covers the operational service management that trains depend on.

A few relationships deserve emphasis. First, SAFe does not replace team-level agile methods; it depends on them, and a train made of teams that are not really agile cannot succeed. Second, SAFe is compatible with external standards that set requirements, such as ISO quality, safety or security standards, because those define what must be achieved and evidenced while SAFe describes how work is organised.

Finally, AI-Native SAFe deserves a brief note because you will hear about it. Scaled Agile introduced it in June 2026 as a second operating model for organisations where AI changes how work is done. Its themes include putting outcomes first, integrating AI into Lean and agile practices, and governance that checks that what is built faster is also safe, secure and valuable. Core SAFe remains supported and continues to evolve. Because AI-Native SAFe is very new, details may still change; if your organisation adopts it, read the current official guidance rather than relying on summaries.

Common pitfalls and best practices

Pitfalls

Renaming without changing – calling project managers RTEs and projects ARTs, while funding, approvals and hand-offs stay the same, produces the cost of SAFe without its benefits.
Organising trains around departments – an ART built around a function, such as all testers or one technical layer, still depends on other trains for every customer-facing change, so value cannot flow.
Treating PI Planning as a top-down plan – if leaders arrive with fixed scope and dates and pressure teams to accept them, the confidence vote becomes theatre and the plan is fiction.
Filling the PI to 100 percent – planning every hour of capacity, or using the IP iteration as a normal development iteration, removes the buffer for uncertainty and the time for innovation and improvement.
Weaponising metrics – comparing velocity or predictability between teams, or tying them to bonuses, encourages inflated estimates and hidden problems.
Skipping integration until late – teams that only demonstrate their own parts, or integrate once per PI, recreate the late-integration surprises SAFe is meant to remove.
Adopting every element at once – rolling out Full SAFe in an organisation that needs only one or two trains overwhelms people with roles and events that solve no current problem.

Best practices

Start with a business reason – define the outcomes you want, such as faster response to customers or fewer production incidents, before choosing practices, and measure them.
Train leaders first and involve them – executives and managers who understand the principles change funding and decision-making; those who do not quietly undo the change.
Identify value streams before forming trains – design each ART so that it can deliver end-to-end value with as few external dependencies as possible.
Protect the IP iteration and enabler capacity – use guardrails to keep time for architecture, automation and learning, so speed is sustainable.
Make the System Demo honest – demonstrate integrated, working solutions in a production-like environment, and invite real customers or users.
Act on Inspect and Adapt – choose one or two systemic problems each PI, fix their root causes and track the improvement items like any other work.
Tailor deliberately – start with Essential SAFe and add elements from the larger configurations only when a real problem calls for them, documenting why.

Summary and key takeaways

SAFe is a proprietary framework from Scaled Agile, Inc. for coordinating many agile teams; the current established model is Core SAFe, built on the SAFe 6.0 vocabulary, with AI-Native SAFe offered alongside it since 2026.
It rests on four core values, a Lean-Agile mindset and ten Lean-Agile principles that guide decisions where no practice applies.
Guidance is organised into five disciplines, and the Big Picture comes in four nested configurations: Essential, Large Solution, Portfolio and Full.
The Agile Release Train, a long-lived team of agile teams organised around a value stream, is the central construct, led by the RTE, Product Management, the System Architect and Business Owners.
Each Planning Interval starts with PI Planning, runs synchronised iterations with System Demos and ends with the IP iteration and Inspect and Adapt.
WSJF orders work by cost of delay divided by job size, and Lean Portfolio Management funds value streams with lean budgets, guardrails and a Portfolio Kanban that tests epics with MVPs.
No organisation can be certified as SAFe compliant; individuals hold role-based certifications that must be renewed each year.
Progress should be judged by outcomes first, then flow and competency, with metrics used for improvement rather than control.

Reflection questions

Think of a product in your organisation that needs several teams. What would its development value stream look like, and how would you shape one or more trains around it?
Which of the ten Lean-Agile principles is most at odds with how your organisation currently makes decisions, and what would change if it were applied?
Imagine your next PI Planning ends with a confidence vote averaging two fingers. What would you do in the following hour, and who would need to be involved?
Which three measures would convince you, after one year, that a SAFe implementation had really improved outcomes rather than only added meetings?
Your team works under a regulatory standard that requires documented evidence of verification. How would you produce that evidence incrementally within SAFe's cadence?