What is the Scaled Agile Framework (SAFe®)?

The Scaled Agile Framework®, also known as SAFe®, is a set of guidelines for implementing agile and lean principles at scale. It is one of several frameworks used at the enterprise level. Others include Disciplined Agile Delivery (DaD), Large Scale Scrum (LeSS), and Nexus.

Scaled Agile, Inc. developed and launched SAFe® in 2011. Today the framework supports tens of thousands of practitioners and is used by more than 70 of the 100 companies at the top of the Fortune 500 list.

Though agile adoption is often organic (beginning with a single development team doing standups and sprints), many organizations struggle to extend agile adoption across teams — much less across departments. Frameworks like SAFe® give organizations tested approaches for successfully scaling agile across complex product teams and environments.

According to documented case studies, organizations can gain the following from implementing SAFe®:

20 to 50 percent increases in productivity
30+ percent faster time to market
50 percent reduction in defects
Higher employee engagement

Descriptions of SAFe® can feel fairly rigid or authoritarian — especially if you do not have any experience using the framework. Before deciding whether or not to implement SAFe®, it is important to understand what the framework is and how it works. Then you can figure out where it makes sense to adopt (or adapt) SAFe® practices to fit your own team.

Principles of SAFe®

Just as the Agile Manifesto principles inspired the creation of common agile practices, SAFe® guidelines are based on a set of core principles. These include:

Take an economic view.
Delivering the best products in the shortest time is not only good for customers, it ultimately benefits an organization’s bottom line. When product and development teams adopt agile approaches like incremental delivery, you should also see faster return on value to the organization.
Apply systems thinking.
SAFe® borrows heavily from the views of W. Edwards Deming, an American business management expert and engineer, who advised that organizations are systems, and systems are themselves a series of complex interactions. Optimizing your system means looking at the whole rather than just its components, and actively managing it rather than hoping it will manage itself.
Assume variability; preserve options.
Users are advised to remember: you cannot possibly know everything upfront, and therefore you can better accommodate change by maintaining responsiveness in your design, requirements, and development plans.
Build incrementally with fast, integrated learning cycles.
The best way to learn and improve what you are doing is to get to the learning point faster. An iterative, agile approach to product development sets up cycles of value delivery, fast feedback, and the ability to adjust course based on that feedback.
Base milestones on objective evaluation of working systems.
Where the phase-gate milestones of traditional waterfall processes leave little opportunity to respond to new information, iterative development sets frequent milestones for delivering working software and provides objective measures for gauging progress toward your goals.
Visualize and limit “work in progress,” reduce batch sizes, and manage queue lengths.
Lean and agile approaches borrow manufacturing concepts such as smaller batch sizes, limiting (and seeing) “work in process” (WiP), and leaving slack in the system to reduce the wait time for new features. Applying these concepts can help you cut time to market and reduce costs.
Apply cadence; synchronize with cross-domain planning.
When organizations plan and deliver on a regular cadence, they become more predictable. Synchronizing those cadences across functional groups such as product, engineering, marketing, and sales can speed decision-making, mitigate risk, and set realistic development scope.
Unlock the intrinsic motivation of knowledge workers.
If you have watched Dan Pink’s TED talk, then you know that employees perform better in creative, complex jobs when they are intrinsically motivated. Giving workers autonomy, mastery, and purpose yields better outcomes for both your organization and your customers.
Decentralize decision-making.
The gist of this principle is that people closest to the data should make decisions about the data. When decisions move far away from their source, they are more likely to cause delays or problems. SAFe® guidance is to centralize strategic decisions that have long-lasting impact or employ an economy of scale, and decentralize decisions that are frequent, local, or time-critical.
Organize around value.
This principle is a new addition as part of SAFe® 5.0 and places emphasis on end-to-end value delivery. When you understand, measure, and organize around the value you provide to customers, it becomes a competitive advantage — enabling your organization to respond to changing customer and market needs with greater speed and impact.

Levels and roles

People need to know how to act on a concept. SAFe® offers guidance for action across the different levels of an enterprise: team, program, and portfolio. Previously separate, the team and program levels have been combined into one "essential" level in SAFe® 5.0. This change aligns people and processes more closely, giving organizations a more comprehensive view of how to get started with SAFe® — before growing to portfolio-level adoption. An optional extra level addresses organizations working with value streams.

Essential level: team

Agile teams are the essential building block of SAFe®. An agile team consists of 7 ± 2 self-organized, cross-functional members — such as software developers, QA, and systems engineers — as well as a scrum master and a product owner. Most teams are organized around building either features or components, and follow scrum, kanban, or XP practices.

The agile release train (ART)

SAFe® coordinates agile teams into an Agile Release Train (ART). The ideal number of people for an ART is roughly Dunbar’s number (between 50 and 150 people, or 5 to 12 teams). Every ART should have a synchronized planning and iteration cadence, a shared program backlog, and a stable composition.

Several additional roles support the ART:

The release train engineer acts as the head scrum master for the train
Product management owns, defines, and prioritizes the feature backlog
Business owners act as the key stakeholders for the train
The systems engineer and team provide architectural guidance and enablement
DevOps engineers build the deployment pipeline

Essential-level: program

SAFe® stresses cadence and synchronization. Coordinating agile teams to plan and iterate at the same frequency may enhance organizational alignment, predictability, and collaboration. At the program increment (PI) level, these coordinated, cross-functional ARTs organize around the planning and execution of work. Each ART shares a common vision, roadmap, features backlog, milestones, and commitment to delivering value in each release.

Vision, roadmap, and backlog prioritization

According to SAFe® recommendations, you should shape a vision for each PI. This helps teams understand the larger business context and feel invested in what you will be building. For example, with the strategic intent expressed through the product vision, product management can begin to build out a program backlog and roadmap.

The framework also provides guidance for prioritizing features in your program backlog. Lean principles recommend asking this question to prioritize features: What is the cost of delay to deliver value? Cost of delay is a function of user or business value (customer preference or impact on revenue), plus time importance (is there a fixed deadline or time window after which value decreases?), plus risk reduction or opportunity enablement; measured against the job’s duration, or effort.

SAFe® expresses this in a simple mathematical calculation, using what it calls “weighted shortest job first” (WSJF):

WSJF = cost of delay / job duration

Jobs with the highest WSJF provide the highest economic returns. Applied to your program backlog, this means you should prioritize features that will deliver the most business value for the least amount of effort.

PI planning, releases, and iterations

PI planning aligns and commits teams around planned and prioritized work. SAFe® advises organizations complete PI planning on a quarterly basis, or roughly every eight to 12 weeks.

Planning should include the ART’s development and product management teams, as well as key leaders and others who provide guidance around the business vision, technology stack, and objectives. For example, UX will provide relevant context about design and usability, while architecture teams will need to provide input on systems and deployment.

During the planning process, product management owns the definition and prioritization of features. As a member of the development team, you then break down those features into user stories and provide estimates. Once you have added your capacity and estimated user stories for your first few iterations, you communicate with the other teams to identify risks and dependencies.

Then, the release train engineer and scrum masters huddle to resolve them. Management reviews the estimated plan and adjusts the scope and objectives if necessary. Once all teams agree on a final plan, with risks and dependencies mitigated, everyone commits to that plan with a vote of confidence.

When the PI is planned, the teams in the ART follow agile principles and rituals to execute on it — planning and committing to work in each iteration, delivering quality with acceptance criteria, inspecting and adapting with demos and retrospectives, and escalating and resolving risks and changes in a scrum of scrums.

Teams are advised to develop on a synchronized cadence throughout the PI. The implication is that teams on the same sprint schedule will become more predictable, which will allow you to respond more easily to change when it invariably arises. But it also recognizes that organizations will want to release at the time that works best for them — whether that is continuous delivery, when the PI is completed, or at a later date.

Portfolio-level

Portfolio-level SAFe® uses lean and agile budgeting principles to prioritize, fund, and plan development. The portfolio provides funding and governance for the products, services, and solutions required to fulfill business strategy.

Building a portfolio

Portfolio themes should connect company strategy to the prioritized and funded work. You should develop these themes from a disciplined strategy process, as they will influence the portfolio backlog, the program roadmap and vision, and the funding of ARTs. Portfolios often include epics — large initiatives that may cut across value streams and span multiple releases. Given the scope of epics, organizations should create them using ROI analysis and a light business case. The framework recommends a portfolio kanban approach for managing the flow of epics, as it lends transparency to the decision-making process and provides WiP limits.

Budgeting

To apply lean and agile principles at the portfolio level, SAFe® recommends funding “value streams” — all the people and processes responsible for delivering value to customers — rather than projects, which can be slowed by approval processes from multiple cost centers and assignments of people to the work.

With lean and agile budgeting, those managing the value stream retain control over their budgets, while portfolio and program managers hold responsibility for total spending over time. This approach provides product managers and ART engineers in the value stream the necessary flexibility to adjust what gets built and how. At the same time, it provides portfolio managers with financial insight and value stream performance data they can use to dynamically manage their initiatives.

Forecasting

Forecasting with agile scenario planning and roadmapping helps large companies respond to changing markets while planning for the future with reasonable accuracy. Portfolio and program managers can forecast (in collaboration with ART members) by estimating epics — breaking them down into potential features and including these estimates in the epic’s business case. You can then apply the epic sizes and your ART velocities to various “what if…” scenarios. Then, you can develop a roughly-right roadmap that forecasts several program increments or business quarters.

Value stream-level

The optional value stream level, added to SAFe® in 2016, supports the development of large and complex solutions across multiple ARTs. A value stream is every step of the process by which a company delivers value to customers, from “concept to cash.” Most value streams cut across functional silos, as they comprise all necessary systems, people doing the work, and resources or materials needed to produce value. A single ART may serve multiple value streams, and a large value stream may require multiple ARTs.

Value stream-level SAFe® may be particularly useful for companies that integrate “systems of systems” (common in hardware environments with suppliers), operate in high-compliance environments, or deliver solutions (a combination of products or services). As at the program level, the value stream level demands coordinated PI planning sessions, solution demos, and inspect and adapt rituals. It also includes the additional roles of value stream engineer, solution architect, and solution manager.

Leading a SAFe® organization

Management consultant and prominent author Peter Drucker — who is said to have coined the term “knowledge worker” — also reportedly suggested that “culture eats strategy for breakfast.” In other words, all the best practices and innovative strategies in the world will fail if companies do not build a strong and inspirational company culture.

Successful agile adoption requires a willingness among all participants to evolve company culture and habits. Leading this evolution is vital and cannot be delegated. Agile leaders must collaborate and communicate daily while taking a holistic “systems view” to managing change across the organization. You must communicate a strong mission and vision, along with a culture of learning and respect, which will motivate people to do their best work.

The Scaled Agile Framework is available here. Scaled Agile Inc. also offers a network of more than 75 partners who provide SAFe® role-based training, certification, and implementation services.

Frequently asked questions about SAFe®

Why do some organizations adopt SAFe®?

Companies typically adopt SAFe® in order to achieve business goals and scale agile across the organization. The aim is to have a framework in place that will result in increased productivity and faster time to market. By implementing SAFe® across product, development, and other teams, companies may also experience better cross-functional collaboration and more predictable release schedules.

What type of companies should use SAFe®?

SAFe® is useful for large organizations that want to incorporate agile and lean principles across teams in a coordinated, structured way. SAFe® lends itself to companies working to build complex or sophisticated solutions that require coordination between multiple agile teams. For example, you might find SAFe® at an organization building a platform or portfolio of products. The focus on structure and planning gives companies that follow SAFe® an orderly and standardized way to tackle large efforts, so that everyone in the organization is aligned on each step of the work.

What are the downsides of SAFe®?

Although SAFe® is an agile framework, it is more prescriptive and less flexible than most other agile methodologies. As a result, some teams adopting SAFe® struggle with the high level of upfront planning, reliance on process, and rigid roles. It can also be difficult to move quickly and adapt when there are multiple layers or levels of management, each making decisions and overseeing their own projects.

What is the difference between SAFe® and scrum?

SAFe® and scrum are both agile frameworks. Scrum is suited for small development teams taking an incremental and iterative approach to delivering software. Development teams that use scrum work in time-boxed sprints and engage in scrum ceremonies such as planning, daily meetings, reviews, and retrospections. SAFe®, on the other hand, is better suited to larger companies with multiple products or complex efforts. The goal is to scale agile across the entire organization.

What is the difference between SAFe® and other frameworks for scaling agile?

A handful of other frameworks like Disciplined Agile (DAD), Large Scale Scrum (LeSS), Nexus, and Scrum@Scale offer similar approaches to scaling agile practices. The main differences between these frameworks and SAFe® are popularity and complexity. SAFe® is by far the most widely practiced large-scale agile framework. It is also the most sophisticated, with many explicit guidelines and processes. Smaller, early-stage organizations may prefer the more flexible, less-prescriptive approaches of alternate frameworks — but for major enterprises coordinating full-scale business agility, SAFe® provides the steadiest foundation to build upon.

What is new in SAFe® 5.0?

SAFe® is always evolving. SAFe® 5.0 is the latest iteration of the framework and was announced in 2019. Overall, SAFe® 5.0 provides more guidance for business agility — the process of expanding adoption of agile principles across the organization and beyond technical product development teams. The most notable changes are the combination of team and program levels into one essential level and the addition of a tenth principle ("Organize around value").

What are SAFe® certifications?

SAFe® offers a variety of certification programs for learning, leading, and implementing the framework. You can train to become a SAFe® certified product owner, scrum master, product manager, software engineer, and more with dedicated courses. Many SAFe® practitioners pursue certifications to cement their knowledge of the framework and expand career opportunities. Getting SAFe® certified as a team can also set you up to be more successful in your agile transformation.

Streamline your agile development process with Aha! Develop — try it for free for 30 days.

Aha! Develop — A fully extendable agile development tool