What Is the Scaled Agile Framework (SAFe®)?

Introduction to SAFe®

The Scaled Agile Framework®, also known as SAFe®, is a set of guidelines for implementing agile and lean principles at scale.

SAFe® is one of several frameworks available for adopting agile approaches 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 and reports that the framework now supports tens of thousands of practitioners — including at more than 60 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 these can give organizations tested approaches for successfully scaling agile across teams and complex environments.

According to documented case studies, users have experienced the following measurable improvements after implementing SAFe®:

20 to 50 percent increases in productivity

30+ percent faster time to market

50 percent reduction in defects

Higher employee engagement

Principles

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

The principles are:

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 you 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 that they cannot possibly know everything upfront, and therefore they can better accommodate change by maintaining responsiveness in their 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 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 products and provides objective measures for gauging progress toward your goals.

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 to 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 can speed decision-making, mitigate risk, and set realistic development scope.

Unlock the intrinsic motivation of knowledge workers.

If you have watched Daniel 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 de-centralize decisions that are frequent, local, or time-critical.

Levels and roles

People need to know how to act on a concept. SAFe® offers guidance for action across three main levels of an organization: team, program, and portfolio. An optional fourth level addresses organizations working with value streams.

Team-level

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

The systems engineer and team provide architectural guidance and enablement

DevOps engineers build the deployment pipeline

Program-level

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

SAFe® advises users to shape a vision for each PI, to help teams understand the larger business context and feel invested in what they will be building. 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.

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. The development teams break down those features into user stories and provide estimates. Once teams have added their capacity and estimated user stories for their first few iterations, they 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.

Once 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 them 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. These themes should be developed 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. They must communicate a strong mission and vision, along with a culture of learning and respect, which will motivate people to do their best work.