Essential SAFe® 4.

0
A Scaled Agile, Inc. White Paper
March 2017

PORTFOLIO Va l u e S t r e a m s

Vision Customer
DevOps

AGILE RELEASE TRAIN Solution

Solution

WSJF
Lean-Agile RTE
Leaders

PROGRAM
Business
Owners System Demos Feature
System Product Feature
Arch/Eng Mgmt
PI Planning

PI Planning

PI Planning

NFRs
Backlog PI Objectives Feature Architectural
Feature
Runway

Product XP Stories
Owner
Increment

Program Increment
ProgramIncrement

I I
Backlog

PI
P P
TEAM
Scrum Objectives
Master
Scrum NFRs
Program

I I Built-In Quality
Backlog

PI P P
Objectives
Agile Team NFRs
Kanban
Leffingwell, et al. © 2008–2017 Scaled Agile, Inc.
SAFe
Principles

PROVIDED BY

scaledagileframework.com / scaledagile.com
Table of Contents
Introduction........................................................................................................................ 1
The Ten Essential Elements......................................................................................... 2
SAFe Lean-Agile Principles................................................................................3, 4, 5
Agile Teams and Release Trains............................................................................6, 7
Cadence and Synchronization.............................................................................. 8, 9
Essential Team and Program Roles................................................................... 10, 11
PI Planning..................................................................................................................12, 13
System Demo...................................................................................................................14
Inspect and Adapt....................................................................................................15, 16
IP Iteration.........................................................................................................................17
Architectural Runway....................................................................................................18
Lean-Agile Leadership.......................................................................................... 19, 20

PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

Introduction
The Scaled Agile Framework® (SAFe®) was designed to help enterprises deliver value continuously and
more efficiently on a regular and predictable schedule, making them more Agile in the marketplace and
more competitive in their industry.

Over time, the Framework has grown in size to accommodate the full spectrum of complexity in software
and systems development. From international bond trading and medical devices to memory chips
and fighter aircraft, SAFe has proven to scale to all situations. But, with such a robust framework, the
question becomes: how closely does an organization need to follow various SAFe practices in order to
get the desired result?

In addition, we’ve observed that not every implementation realizes the full business benefits that others
achieve. When diagnosing, we’ve found that the less successful enterprises have skipped some of the
most essential practices. It’s easy to see how that can happen. After all, it’s a big framework, how would
an enterprise know what’s essential?

To that end, Essential SAFe (Figure 1) is a subset that describes the minimal elements necessary to be
successful. If you are incorporating these ten essential elements for each Agile Release Train in your
portfolio, you’re well on your way to realizing the full benefits of SAFe.
PORTFOLIO

Figure 1. Essential SAFe is a subset of SAFe

VALUE STREAM

PORTFOLIO Va l u e S t r e a m s

Vision Customer
DevOps

AGILE RELEASE TRAIN Solution

Solution

WSJF
Lean-Agile RTE
PROGRAM

Leaders
Business PROGRAM
Owners System Demos Feature
System Product Feature
Arch/Eng Mgmt
PI Planning

PI Planning

PI Planning

NFRs
Backlog PI Objectives Feature Architectural
Feature
Runway

Product XP Stories
Owner
Increment

Program Increment
ProgramIncrement

I I
Backlog

PI
TEAM

P P
TEAM

Scrum Objectives
Master
Scrum NFRs
Program

I I Built-In Quality
Backlog

PI P P
Objectives
Agile Team NFRs
Kanban
Leffingwell, et al. © 2008–2017 Scaled Agile, Inc.
SAFe
Principles

1
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

The Ten Essential Elements
As can be seen in Figure 2, Essential SAFe identifies the ten major elements proven to be critical for a
successful implementation. Each is the topic of a section that follows.

System Demo
PI Planning
An integtated demo of a full solution
increment to the stakeholders every There is no SAFe
iteration ensures that the entire without PI planning that
system is iterating as a whole and not involves the entire train
just individual teams. and achieves alignment
to a common mission.

Essential Team and Program Roles

Product Management, System
Arch/Eng, and Release Train
Engineer—provide content and
technical authority, and an effective Inspect and Adapt
development process. Product
Owners and Scrum Masters help the Inspect & Adapt provides the
teams meet their objectives. The venue for comprehensive
Customer is part review of the PI outcomes and
of the value stream and is integrally systematic improvements.
engaged throughout development.

Essential SAFe® 4.0

Lean-Agile Leadership PORTFOLIO Va l u e S t r e a m s

Successful transformations
are based on educating Architectural Runway
management first to
Vision Customer
DevOps

AGILE RELEASE TRAIN Solution

Solution
Architectural runway
become lean-thinking
provides “just enough”
manager-teachers, who
W SJF
Lean-Agile RTE

technical enablement
Leaders
PROGRAM

Business
Owners System Demos

lead, rather than follow, the

Feature
System Product Feature

to keep program
Arch/Eng Mgmt
PI Planning

PI Planning

PI Planning

NFRs
PI Objectives

transformation
Backlog Feature Architectural
Feature
Runway

Product
Owner
XP Stories velocities high, and
Increment

Program Increment
ProgramIncrement

avoid excessive rede-

I I
Backlog

PI
P P
TEAM

Scrum Objectives
Master
Scrum NFRs

sign.
Program

I I Built-In Quality
Backlog

PI P P
Objectives
Agile Team NFRs
Kanban
Leffingwell, et al. © 2008–2017 Scaled Agile, Inc.
SAFe
Principles

Agile Teams and Release IP Iteration

Trains The Innovation and
The Agile Release Train is a key Planning iteration is like
building block of a SAFe enteprise. extra oxygen in the
Trains are organized around tank: Without it, the
value streams, and consist of train may start straining
Agile teams. Teams use Scrum, under the pressure of
Kanban, and built-in quality the tyranny of the
practices to frequently produce urgent, a plan that
integrated increments of value. forgives no mistakes,
DevOps practices close the loop nor provides dedicated
on customer value delivery. time for innovation.

SAFe Lean-Agile Principles Cadence and Synchronization

Lean-Agile principles provide A synchronized program increment and
the basis for every successful iteration cadence is the heartbeat of every
transformation and guide ART. Periodic synchronization of all aspects
decision-making as the process limits variance to a single time interval.
evolves and adapts.

Figure 2. The ten elements of Essential SAFe

2
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

SAFe Lean-Agile Principles
To appreciate what SAFe is and how it helps the enterprise accomplish what it does, an understanding
of the nine fundamental Lean-Agile principles is necessary. The SAFe website describes the principles
in detail, but they are summarized here briefly.

#1 - Take an economic view

The over-arching goal is simple: to deliver the best value and quality to people and society in the
shortest sustainable lead time. Doing so requires a fundamental understanding of the eco-
nomics of the system builder’s mission. Lean system builders endeavor to make sure that
everyday decisions are made in a proper economic context. The primary aspects include de-
veloping and communicating the strategy for incremental value delivery and the creation of
the economic framework. This helps define the trade-offs between risk, Cost of Delay (CoD),
and operational and development costs, while supporting decentralized decision-making.

#2- Apply systems thinking

W. Edwards Deming, one of the world’s foremost systems thinkers, constantly focused on
the larger view of problems and challenges faced by people building and deploying all types
of systems: manufacturing, social, management, and even government. One central con-
clusion was the understanding that the problems faced in the workplace were a result of a
series of complex interactions that occurred within the systems the workers used to accom-
plish their tasks. In SAFe, systems thinking addresses this and is applied to the organization
that builds the system, as well as the system under development.

#3 - Assume variability; preserve options

Traditional design and life cycle practices drive picking a single requirements and design
option early in the development process (early in the “cone of uncertainty”). However, if the
starting point is wrong, then future adjustments take too long and can lead to a suboptimal
long-term design. Alternatively, Lean system developers maintain multiple requirements and
design options for a longer period in the development cycle. Empirical data is then used to
narrow focus, resulting in a design that creates better economic outcomes.

#4 - Build incrementally with fast, integrated learning cycles

Lean system builders develop solutions incrementally in a series of short iterations. Each
results in an integrated increment of a working system. Subsequent iterations build upon
the previous ones. Increments provide the opportunity for fast customer feedback and risk
mitigation, and also serve as minimum viable solutions or prototypes for market testing and
validation. In addition, these early, fast feedback points allow the system builder to “pivot”
when necessary to an alternate course of action.

3
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

#5 - Base milestones on objective evaluation of working systems

System builders and customers have a shared responsibility to assure that investment in
new solutions will deliver economic benefit. The sequential, phase-gate development model
was designed to meet this challenge. But experience has shown that it does not mitigate
risk as intended. In Lean-Agile development, each integration point provides an objective
milestone in which to evaluate the solution frequently and throughout the development life
cycle. This objective evaluation provides the financial, technical, and fitness-for-purpose gov-
ernance needed to assure that continued investment will produce commensurate return.

#6 – Visualize and limit work in process, reduce batch sizes, and manage queue lengths

Lean system builders strive to achieve a state of continuous flow, allowing new capabilities to
move quickly and visibly from concept to cash. Three keys to ensure flow are: 1) Visualize and
limit the amount of Work in Process (WIP) to restrict demand to actual capacity, 2) Reduce
the batch sizes of work items to facilitate reliable flow through the system, and 3) Manage
queue lengths to reduce the wait times for new capabilities.

#7 – Apply cadence, synchronize with cross-domain planning

Cadence transforms unpredictable events into predictable ones, and provides a rhythm for
development. Synchronization causes multiple perspectives to be understood, resolved, and
integrated at the same time. Applying development cadence and synchronization, coupled
with periodic cross-domain planning, offers Lean system builders the tools they need to
operate effectively in the presence of product development uncertainty.

#8 - Unlock the intrinsic motivation of knowledge workers

Lean-Agile leaders understand that knowledge workers generally aren’t motivated by incen-
tive compensation approaches. Such individual MBOs (Management by Objectives) cause
internal competition and destruction of the cooperation necessary to achieve the larger
system aim. Providing autonomy, mission and purpose while minimizing constraints leads
to higher levels of employee engagement, and results in better outcomes for customers and
the enterprise.

#9 - Decentralize decision-making

Achieving fast value delivery requires fast, decentralized decision-making, as any decision
escalated introduces delay. In addition, escalation can lead to lower quality decisions due to
the lack of local context, and changes in fact patterns that occur during the wait time. Decen-
tralized decision-making reduces delays, improves product development flow, and enables
faster feedback and more innovative solutions. Some decisions, however, are strategic global
choices that have economies of scale warranting centralized decision-making. Since both
types of decisions occur, creating an established decision-making framework is a critical step
in ensuring the fast flow of value.

4
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

Without a shared understanding of principles:

• There is no systematic way to adapt practices to local context.

• Business outcomes do not significantly improve.

• Practices and measures that were once beneficial become problematic.

• A Lean-Agile mindset is unachievable; Agile practices deployed on a “wrong-minded” platform

produce serious challenges.

• Conflict and disagreement on processes and practices are impossible to resolve.

5
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

Agile Teams and
Release Trains
Agile Release Trains (ARTs) are virtual organizations that have all the people they need to define and deliver
value. Each ART is a long-lived, self-organizing team of Agile teams, a virtual organization (50-125 people)
that plans, commits, and executes together. ARTs are organized around the enterprise’s significant value
streams, and exist solely to realize the promise of that value by building solutions that deliver benefit
to the end user. The ART aligns teams to a common mission via a single vision and program backlog.

In functional organizations, developers work with developers; testers work with other testers; architects
and systems engineers work with each other. While there are reasons why organizations have evolved
that way, value doesn’t flow easily, as it must cross ALL the silos. Daily involvement of managers and
project managers is necessary to move the work across the silos. As a result, progress is slow, and
handoffs and delays rule the day.

Instead, the ART takes a systems view and builds a cross-functional organization that includes all people
needed to continuously define, build, test, and deploy valuable features. This means each train must
include real, cross-functional Agile teams, as well as people from various other disciplines, as can be
seen in Figure 3.

Figure 3. ARTs are cross-functional

6
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

To support this, Agile Teams are necessarily cross-functional too, as shown in Figure 4.

Figure 4. Agile teams are cross-functional

Each Agile team has the skills and people needed (designers, developers, testers, etc.) to effectively
deliver a feature or component with a minimum number of dependencies on others.

Together, this fully cross-functional organization—whether physical (direct organizational reporting) or

virtual (line of reporting is unchanged)—has everyone and everything necessary to define and deliver
value. It is self-organizing and self-managing at the team and program levels. This creates a far leaner
organization, one where traditional daily task management is no longer required. Value flows more
quickly, with a minimum of overhead. That’s the purpose of the ART.

Without Agile Teams and ARTs:

• Teams don’t work towards a common mission.

• Teams locally optimize and can’t deliver end to end value.

• Dependencies rule the day.

• Individuals are over-specialized; bottlenecks inhibit flow and release of value.

• There is no architectural and user experience integrity.

7
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

Cadence and synchronization
Cadence provides a rhythmic pattern, the dependable heartbeat of the development process. It makes
routine that which can be routine. This frees the intellectual capacity of the system builders to focus on
managing the variability inherent in solution development.

Synchronization causes multiple perspectives to be understood and resolved at the same time. For
example, synchronization is used to pull the disparate assets of a system together to assess solution-level
viability. It’s also used to align development teams and the business to a common mission at Program
Increment (PI) planning.

Together, cadence and synchronization are the primary tools used to manage the inherent variability of R&D.

The first cadence of SAFe is the iteration cycle, each a Plan-Do-Check-Adjust (PDCA) empirical cycle.
During this short period, the team plans, builds, integrates, and demonstrates the result, followed by a
short retrospective. As illustrated in Figure 5, each iteration is followed by another, providing the basic
steady cadence tempo of team development.

Figure 5. The basic iteration cadence, each a plan-do-check-act cycle

However, because significant solutions require integration across multiple teams, it is critical for the
teams to work on a common cadence. Otherwise, the teams may be iterating, but integration is difficult,
and the slowest cycle delays problem discovery. The net result is that the teams may be iterating, but
the system isn’t incrementing, as can be seen in Figure 6.

Figure 6. Cadence without synchronization is not enough

8
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

To address this, SAFe provides a nesting of synchronized feedback loops for the ART. The inner iteration
PDCA loops are synchronized across teams. Moreover, the inner loop acts in the context of a larger,
outer Program Increment (PI) loop, as Figure 7 illustrates.

Figure 7. Iterations and Program Increments provide nested learning cycles

The nested inner PDCA cycle fast-paces.

the build of the solution
The larger PDCA cycle provides a more strategic timebox in which to accumulate and assess system-level
performance. It also provides the cadence for the entire train to perform cross-domain planning,
integration, demo, and Inspect and Adapt (I&A).

Develop on Cadence, but Release Any Time

We’ve described how cadence and synchronization are the primary tools in managing the inherent
variability of R&D. But it’s important to note that the development cycle is distinct from the release
cycle; these are separate concerns. While in some situations the PI and release cadence are the same,
other programs may need to release less or more frequently than the PI cadence. Still others will have
multiple, independent release cycles for the various subsystems of the solution.

Without cadence and synchronization:

• There’s no development rhythm.

• You constantly fight entropy and misalignment.

• It’s impossible to schedule planning, retrospectives, demos and key events.

• It’s hard to adjust to changing priorities.

• You can’t limit Work in Process (WIP) and are constantly overloaded.

9
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

Essential Team
and Program Roles
Effective programs require the right people in the right roles, fulfilling the right set of responsibilities.

Essential Team Roles

Scrum Master

Scrum Masters coach a high-performing and self-managing team. They do that by facilitating
team meetings, driving Agile behavior, removing impediments, helping maintain the team’s
focus by managing input demand, and attending ART sync meetings.

Product Owner

The Product Owner maintains the team backlog, acts as the customer for team questions,
prioritizes the work, and collaborates with Product Management to plan PIs.

Development Team

Developers, testers, and various specialists create and refine user stories and acceptance
criteria. They define, build, test, and deliver software, hardware, and other system
components or features.

Essential Program Roles

The Release Train Engineer (RTE)

The RTE acts as the chief Scrum Master for the train. RTEs facilitate ART-level events and
meetings, and help drive Agile behavior with the teams, the ART, and other stakeholders.
They help manage risk, coordinate dependencies, and coach the ART to relentless
improvement.

Product Management

Product management is responsible for identifying customer needs. They own the vision and
product backlog, and sequence features for optimal ROI. They drive PI objectives and release
content via prioritized features and acceptance criteria.

System Architect-Engineering

System Architect-Engineering align ARTs with a common technological and architectural

vision. They participate in defining the system and subsystems and their interfaces,
validate technological assumptions, and evaluate alternatives. They support robust system
development by providing, communicating, and evolving the larger technological and
architectural view of the solution.

10
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

 Business Owners

Business Owners are a small group of stakeholders who have the ultimate fiduciary,
governance, efficacy, and ROI responsibility for the value delivered by a specific release train.
Business Owners typically have management responsibility for customer relationships,
development, solution quality, deployment, operations, Product Management, and
architecture. They work with the ART continuously to define the business value of plans and
working systems.

Customer

The customer is whoever consumes the work of an ART. They are the ultimate arbiters of
value delivered. Whether internal or external to the development organization, they are an
integral part of the value stream, and thereby participate in ART events.

Without these critical roles …

• Responsibilities for most everything is unclear. Decision-making is fractured, late,

and uncertain.

• Deliverables do not meet stakeholder expectations.

• Solution features and components evolve incompatibly.

• Vision and requirements are unclear and hard to prioritize.

• Improvements are virtually impossible to achieve.

11
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

PI Planning
No event is more powerful in SAFe than PI planning. It’s the cornerstone of the Program Increment (PI),
which provides the cadence, or rhythm for the ART.

When 100 or so people are work together toward a common mission, vision, and purpose, it’s amazing
how much alignment and energy it creates. Gaining that alignment in just two days can save weeks if
not months of delays of waiting on decisions, tracking down the right people, and seeking agreement
via a flurry of emails.

More importantly, this event represents a critical and cultural milestone for the implementation of SAFe:

• Here’s where the teams come together periodically to better define and design the system that
fulfills the vision, and to commit to near-term PI objectives.

• The ART uses this event to create, foster and sustain a sense of shared mission, responsibility,
and collaboration.

• The responsibility for planning moves from central authority to the teams who do the work.
This signals true change from management that the teams are now empowered.

• This event builds the social network that the ART depends on. After all, building large scale,
complex solutions is a social endeavor.

Whenever possible, attendees should include all members of the ART. In the end, they’re the ones doing
the work. So they are the only ones who can design the system, plan, and then commit to their plan.
As shown in Figure 8, there are teams in the U.S. planning at the same time with remote teams in India,
using video conferencing. Leads from teams in Eastern Europe are attending the U.S. event in person,
and are collaborating with their teams remotely. U.S.-based Business Owners are sitting at the table in
the middle, accessible to everyone. Product Owners are with their teams in India.

Figure 8. Large-scale, face-to-face PI planning. Remote teams in

India and Slovakia are planning simultaneously with teams in the U.S.

12
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

Without PI Planning …

• Stakeholders, teams, and management are misaligned.

• Demand doesn't match capacity, eliminating predictability and creating excess WIP.

• Lack of trust between stakeholders and teams develops.

• Dependencies are discovered by “running into them.”

• The result is low commitment, ownership, and enthusiasm.

13
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

System Demo
The primary measure of ART progress is the objective evidence provided by a working solution in the
system demo. Every two weeks, the full system—the integrated work of all teams on the train for that
iteration—is demoed to the train’s stakeholders. (This is in addition to each team’s iteration demo.)
Stakeholders provide the feedback the train needs to stay on course and take corrective action, as can
be seen in Figure 9.

Figure 9. Teams integrate every iteration to demo the full system

At the end of each PI, a final system demo is held. That demo is a significant and somewhat more
structured affair, as it demonstrates the accumulation of all the features from all teams on the train that
have been developed over the course of the PI.

Without the System Demo:

• PIs are “waterfalled”; problems and risks are discovered too late.

• Teams are sprinting, but the system is not.

• Chronic lack of trust develops between stakeholders and teams.

• There’s no feedback about the right solution.

• False progress leads to poor quality.

14
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

Inspect and Adapt
The Inspect and Adapt (I&A) workshop is a significant event held at the end of each PI, and serves as a
highpoint in the process.

A regular time to reflect, collect data and solve problems, the I&A workshop assembles teams and
stakeholders to assess the solution, and define and take action on the improvements needed to increase
the velocity, quality, and reliability of the next PI.

All program stakeholders participate, resulting in a full understanding of the current context. They also
generate a set of improvement features that can be added to the backlog for the upcoming PI planning.
As a result, every ART improves every PI. Continuous improvement is assured with implementation of
the identified backlog improvement items.

The I&A has three parts:

• PI system demo. This is a demo of all features completed by the ART during the previous PI.

• Quantitative measurement. This is a review of the quantitative metrics teams has agreed to
collect and discuss.

• Problem-solving workshop. This short retrospective for the PI, along with a structured prob-
lem-solving workshop (as can be seen in Figure 10), focuses on identifying the root causes of
the challenges faced by the ART. Most importantly, it pinpoints a small number of improvement
items that can be added to the backlog for the upcoming PI.

Figure 10. Problem-solving workshop format

15
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

Without Inspect and Adapt:

• Problems perpetuate without systemic improvement.

• There is no way to measure or establish delivery predictability.

• Improvement attempts address symptoms, not root causes.

• Those who could change the system are not engaged.

• Morale deteriorates.

16
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

IP Iteration
Every PI delivers value. During the PI, teams are busy working on the PI objectives that they had committed
to in PI planning. Every iteration counts, and the teams are mostly “heads down,” focused on near-term
delivery. There is a sense of urgency about every iteration and every PI. Given this urgency, there’s a
risk that if time is not put aside for innovation, improvement and planning, the “tyranny of the urgent”
will outweigh all other activities.

To address this, the IP iteration provides a regular, cadence-based opportunity, for teams to work on
activities that are difficult to fit into a continuous delivery model. These can include time for innovation
and exploration, a dedicated time for the scheduled PI system demo, the I&A workshop, PI planning
events, backlog refinement for the next PI, and even time for continuing education.

The IP iterations fulfill another critical role: They provide an estimating buffer for meeting PI objectives
and enhancing release predictability. Lean teaches us that operating at near 100% utilization drives
unpredictable results. Put simply, if everyone is planned to full capacity, there is no one available to flex
when problems inevitably occur. The result is unpredictability and delays in value delivery.

For this reason the IP iteration is also treated as a “guard band” or estimating buffer. During PI planning,
no features or stories are planned for development in this iteration. This buffer gives the teams extra
time to respond to unforeseen events, delays in dependencies, and other issues, which increases their
ability to meet PI objectives. This substantially improves the predictability of the program’s outcomes,
an attribute that’s extremely important to Business Owners.

Routinely using that time for completing the work, however, is a failure pattern. Teams must also take
care that the IP iteration does not simply become a crutch for poor planning, or worse, a time for the
quality activities that must occur during the iterations themselves. It defeats the primary purpose of
the IP iteration; innovation will surely suffer.

Without the IP iteration:

• Lack of delivery capacity buffer impacts predictability.

• Tyranny of the urgent overrules innovation.

• Technical debt grows uncontrollably.

• People burn out.

• There’s no time for teams to plan, demo, and improve together.

17
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

Architectural Runway
The Architectural Runway exists when the enterprise’s platforms have enough technological infrastructure
to support implementing the highest-priority near-term features without excessive delay-inducing redesign.
Constantly building and extending the Architectural Runway is the way the enterprise assures that it
keeps evolving the systems architecture, and not just focusing on the business features that consume it.

In order to support upcoming functionality, the enterprise must continually invest in extending the
runway by implementing new architectural and infrastructure enablers. Some of these enablers fix
existing problems with the solution—for example, the need to enhance performance—while others
might implement foundational capabilities that will be used by future features. This process of creation
and consumption can be seen in Figure 11.

Figure 11. Enablers build the Architectural Runway. Features consume it

For this reason, teams need some intentional architecture—a set of planned architectural initiatives
that enhance solution design, performance, and usability, and provide guidance for cross-team design
and implementation synchronization.

Without enough investment in the architectural runway, the train will experience slow value delivery,
needing to redesign for the delivery of each feature. Too much runway, however, will create architecture
“inventory” that might never be used, and can even clog the system. A sense of balance is required.

Without an Architectural Runway:

• Architecture deteriorates quickly under the pressure of ”now.”

• Velocity peaks for a while, then falls off.

• Releases are late and spasmodic; quality varies dramatically.

• Solution robustness, maintainability and quality decay rapidly.

• The development pace is unsustainable.

18
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

Lean-Agile Leadership
SAFe is based on a number of modern systems and software engineering disciplines, including systems
thinking, Lean product development, and Agile development. Agile provides the tools needed to empower
and engage teams to achieve unprecedented levels of productivity, quality, and engagement. But a
broader and deeper mindset is needed to support Lean and Agile development at scale across the
entire enterprise.

For SAFe to be effective, the enterprise’s leaders and managers must take responsibility for Lean-Agile
adoption and success. Executives must become leaders who are trained—and become trainers in—these
leaner ways of thinking and operating. Without such a change, and without leadership taking responsibility
for the implementation, the transformation will fail to achieve the intended benefits. That’s why SAFe
focuses first and foremost on a Lean-Agile leadership mindset, which includes:

Thinking Lean
Lean thinking is represented in the SAFe “House of Lean” icon, organized around six key
constructs. The “roof” represents the goal of delivering Value. The “pillars” support that goal
through Respect for People and Culture, Flow, Innovation, and Relentless Improvement. Lean
leadership provides the foundation on which everything else stands.

Embracing Agility
In addition, SAFe is built entirely on the skills, aptitude, and capabilities of Agile teams and
their leaders. And while there is no one definition of what an Agile method is, the Agile
Manifesto provides a unified value system that has helped inaugurate Agile methods into
mainstream development.

However, thinking Lean and embracing Agile aren’t enough. Leading is what’s required. To this end,
SAfe’s Lean-Agile Leaders:

#1 - Lead the change

Steering an organization toward Lean and Agile behaviors, habits, and results cannot be
delegated. Leaders must exhibit and communicate the urgency for change, collaboratively
build a plan, understand and manage the change process, and quickly solve problems. They
must have knowledge of organizational change management, and take a systems view for
implementing the transformation.

#2 - Know the way; emphasize lifelong learning

Create an environment that promotes continuous learning, and fosters formal and informal
groups for learning and improvement. Strive to learn and understand new developments in
Lean, Agile, and contemporary management practices.

19
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

 #3 - Develop people

Focus on developing people’s knowledge and skills rather than on being the go-to expert or
coordinator of tasks. Create a team that is jointly responsible for success.

#4 - Inspire and align with mission

Minimize constraints. Provide an inspirational mission and vision; and eliminate demotivating
rules, policies, and procedures. Build Agile teams and trains organized around value.

Understand the power of self-organizing, self-managing teams. Create a safe, failure-tolerant

environment for learning, growth, and mutual influence.

#5 - Decentralize decision-making

Establish a decision-making framework. Empower others by setting the mission, developing

people, and teaching them to problem-solve.

#6 - Unlock the intrinsic motivation of knowledge workers

Understand the role that compensation plays in motivating knowledge work. Change from
individual to shared rewards. Create an environment of mutual influence. Eliminate any and
all management processes and objectives that cause internal competition.

Without Lean-Agile Leadership:

• The teams learn from others instead of their leaders.

• The transformation is fatally flawed.

• “Agile” development with non-Agile governance is, “Agile in name only. They don’t get it.”

• While decisions are escalated lead time is slow.

• People are not allowed to experiment, fail, innovate, and learn.

20
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

Learn More
If you would like to learn more about SAFe, visit these websites:

• Learn about real world implementations at scaledagileframework.com/case-studies

• Browse the Framework at scaledagileframework.com

• Find role-based SAFe training and certification at scaledagile.com

• View SAFe presentations and videos at scaledagileframework.com/videos-and-presentations

• Read Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the
Enterprise – bit.ly/AgileSWReq

• Experience a SAFe transformation in The Rollout by Alex Yakyma at therolloutbook.com

21
PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

About Scaled Agile, Inc.
Based in Boulder, Colorado, Scaled Agile’s mission is to help
system and software-dependent enterprises achieve better
outcomes, increase employee engagement, and improve
business economics through adoption of Lean-Agile principles
and practices based on the Scaled Agile Framework® (SAFe®).
Scaled Agile supports tens of thousands of practitioners of the
Framework through training, certification, consulting services,
and a global partner network that reaches over 35 countries
and 350 cities.

Contact
Scaled Agile, Inc.

5480 Valmont Rd, Suite 100

Boulder CO 80301 USA

+1.303.554.4367

[email protected]

scaledagile.com

PROVIDED BY

© 2017 Scaled Agile, Inc. All Rights Reserved.

 ROLE-BASED SAFe® CERTIFICATIONS
There’s a certification for everyone on the SAFe Learning Path

PMPO
® ® ® SAFe®

Implementing Leading SAFe® 4.0 SAFe® 4.0 For Teams SAFe® 4.0 Product
SAFe® 4.0 with SAFe with SAFe Agilist with SAFe Practitioner Manager/Product
Certification
Program Consultant 4.0 Certification Owner with SAFe
Certification Product Manager/Product
This two-day course In this two-day course,
Owner Certification
This four-day course teaches the Lean-Agile teams learn how to work
prepares you to lead principles and practices of in an Agile environment Learn how the roles of
an enterprise Agile SAFe. You’ll learn how to using Scrum, Kanban, Product Manager, Product
transformation by execute and release value and XP. They learn how Owner, Solution Manager,
leveraging SAFe. You will through Agile Release to become Agile teams, and Epic Owner drive the
learn how to effectively Trains, how to build an build their backlog, and delivery of value in the
apply SAFe principles and Agile Portfolio, and how to run a Program Increment SAFe enterprise; get an
practices, coach teams, lead a Lean-Agile (PI), including all meetings in-depth understanding
launch Agile Release transformation at at the Team and Program of the activities, tools,
Trains, and build and enterprise scale. level. and mechanics used to
manage an Agile portfolio. effectively deliver value.

SAFe® Scrum Master Curriculum

CORE ADVANCED

SAFe® 4.0 Scrum Master SAFe® 4.0 Advanced Scrum Master

with SAFe 4.0 Scrum Master Certification with SAFe 4.0 Advanced Scrum Master Certification

In this two-day course, you’ll gain an understanding This two-day course prepares current Scrum Masters for
of the role of Scrum Master in a SAFe enterprise. You’ll their leadership role in facilitating Agile team, program,
learn how to plan and execute the Program Increment and enterprise success in a SAFe implementation. It
(PI), and how to build high performing Agile teams by covers facilitation of cross-team interactions in support
becoming a servant leader and coach. of the program execution.

Find out which SAFe training and certification is right for you at:
scaledagile.com/which-course
 SAFe® KEY RESOURCES

Release Train
Engineer with Release SAFe is a freely revealed knowledge base used to
Train Engineer Certification scale Lean-Agile software and systems development
This three-day course scaledagileframework.com
prepares you to perform scaledagileframework.com/introduction-to-safe
the role of a Release scaledagileframework.com/case-studies
Train Engineer in a SAFe scaledagileframework.com/books
enterprise. You’ll learn scaledagileframework.com/blog
how to facilitate delivery
of end-to-end value in an
Agile Release Train (ART)
and within a large and
complex value stream. Scaled Agile supports over 100,000 SAFe practitioners
through role-based training and certification
scaledagile.com
scaledagile.com/find-training
scaledagile.com/partner-directory
scaledagile.com/leading-safe-video
scaledagile.com/insider

L IO
O
TF
R
PO

M
EA
R
ST
E
LU
VA

AM
R
G
O
PR

AM
TE
 PORTFOLIO Va l u e S t r e a m s

Vision Customer
DevOps

AGILE RELEASE TRAIN Solution

Solution

W SJF
Lean-Agile RTE
Leaders
Business
Owners System Demos Feature
System Product Feature
Arch/Eng Mgmt NFRs
PROGRAM

Backlog PI Objectives Feature Architectural

Feature
Runway

PI Planning
PI Planning
PI Planning

Product XP Stories
Owner
PI I I
Scrum Objectives P P
Backlog

Master

PROVIDED BY
Scrum NFRs
Increment
TEAM

I I Built-In Quality
PI P P
ProgramIncrement
Program Increment

Program

Backlog

Objectives
Agile Team NFRs
Kanban
Leffingwell, et al. © 2008–2017 Scaled Agile, Inc.
SAFe
Principles

scaledagileframework.com / scaledagile.com