Safe For Teams

4.
SAFe
REFERENCE GUIDE
®
SCALED AGILE FRAMEWORK® FOR LEAN

SOFTWARE AND SYSTEMS ENGINEERING
Dean Leffingwell
with Alex Yakyma, Richard Knaster,
Drew Jemilo, and Inbar Oren
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as
trademarks. Where those designations appear in this book, and the publisher was aware of a trademark
claim, the designations have been printed with initial capital letters or in all capitals.
The author and publisher have taken care in the preparation of this book, but make no expressed or
implied warranty of any kind and assume no responsibility for errors or omissions. No liability is
assumed for incidental or consequential damages in connection with or arising out of the use of the
information or programs contained herein.
For information about buying this title in bulk quantities, or for special sales opportunities (which may
include electronic versions; custom cover designs; and content particular to your business, training
goals, marketing focus, or branding interests), please contact our corporate sales department at
[email protected] or (800) 382-3419.
For government sales inquiries, please contact [email protected].
For questions about sales outside the U.S., please contact [email protected].
Visit us on the Web: informit.com/aw
Library of Congress Control Number: 2016943742
Copyright © 2017 Scaled Agile, Inc.
All rights reserved. Printed in the United States of America. This publication is protected by copyright,
and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a
retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying,
recording, or likewise. For information regarding permissions, request forms and the appropriate
contacts within the Pearson Education Global Rights & Permissions Department, please visit www.
pearsoned.com/permissions/.
ISBN-13: 978-0-13-451054-5
ISBN-10: 0-13-451054-2
Text printed in the United States on recycled paper at RR Donnelley in Crawfordsville, Indiana.
First printing, August 2016

Contents
Preface............................................................................................................................................................. vii
Acknowledgments........................................................................................................................................ ix
Scaled Agile Framework Contributors................................................................................................. ix
SAFe Community Contributors.............................................................................................................. x
Additional Acknowledgments................................................................................................................. x
Introduction to the Scaled Agile Framework (SAFe).........................................................................1
Part 1: The SAFe Foundation......................................................................................................................9

Lean-Agile Leaders................................................................................................................................. 11
Communities of Practice...................................................................................................................... 17
SAFe Core Values................................................................................................................................... 21
Lean-Agile Mindset................................................................................................................................. 27
SAFe Principles........................................................................................................................................ 35
Implementing 1-2-3............................................................................................................................... 37
Part 2: The SAFe Principles...................................................................................................................... 43

#1 – Take an economic view................................................................................................................ 45
#2 – Apply systems thinking................................................................................................................ 51
#3 – Assume variability; preserve options....................................................................................... 55
#4 – Build incrementally with fast, integrated learning cycles.................................................... 57
#5 – Base milestones on objective evaluation of working systems........................................... 59
#6 – Visualize and limit WIP, reduce batch sizes, and manage queue lengths...................... 61
#7 – Apply cadence, synchronize with cross-domain planning.................................................. 63
#8 – Unlock the intrinsic motivation of knowledge workers....................................................... 67
#9 – Decentralize decision-making.................................................................................................... 71
Contents iii
Part 3: The Team Level.............................................................................................................................. 73
Introduction to the Team Level.......................................................................................................... 75
Agile Teams.............................................................................................................................................. 77
Product Owner........................................................................................................................................ 83
Scrum Master.......................................................................................................................................... 89
ScrumXP................................................................................................................................................... 93
Team Kanban.......................................................................................................................................... 99
Team Backlog........................................................................................................................................105
Iterations................................................................................................................................................109
Iteration Planning.................................................................................................................................113
Iteration Execution...............................................................................................................................119
Team Demo...........................................................................................................................................125
Iteration Retrospective........................................................................................................................129
Stories.....................................................................................................................................................133
Iteration Goals.......................................................................................................................................143
Built-In Quality.......................................................................................................................................147
Part 4: The Program Level.....................................................................................................................153

Introduction to the Program Level...................................................................................................155
Agile Release Train...............................................................................................................................159
Release Train Engineer and Value Stream Engineer...................................................................167
System and Solution Architect/Engineering..................................................................................171
Product and Solution Management................................................................................................177
WSJF (Weighted Shortest Job First)...................................................................................................183
Program and Value Stream Kanban................................................................................................187
Program and Value Stream Backlogs..............................................................................................193
Nonfunctional Requirements............................................................................................................199
Program Increment.............................................................................................................................207
PI Planning.............................................................................................................................................213
Business Owners..................................................................................................................................221
PI Objectives..........................................................................................................................................225
System Demo........................................................................................................................................233
iv Contents
Features and Capabilities...................................................................................................................237
Enablers..................................................................................................................................................243
Innovation and Planning Iteration....................................................................................................249
Inspect and Adapt................................................................................................................................253
Develop on Cadence, Release Any Time........................................................................................259
Architectural Runway...........................................................................................................................265
Part 5: The Spanning Palette................................................................................................................271

DevOps...................................................................................................................................................273
System Team.........................................................................................................................................279
Release Management..........................................................................................................................283
Shared Services....................................................................................................................................287
User Experience (UX)...........................................................................................................................291
Vision.......................................................................................................................................................295
Roadmap................................................................................................................................................301
Metrics....................................................................................................................................................307
Milestones..............................................................................................................................................323
Releases..................................................................................................................................................331
Part 6: The Value Stream Level............................................................................................................337

Introduction to the Value Stream Level..........................................................................................339
Value Stream Coordination...............................................................................................................343
Economic Framework..........................................................................................................................347
Solution Intent.......................................................................................................................................351
Model-Based Systems Engineering.................................................................................................359
Set-Based Design.................................................................................................................................365
Agile Architecture.................................................................................................................................371
Solution Demo......................................................................................................................................379
Pre- and Post-PI Planning...................................................................................................................383
Supplier...................................................................................................................................................389
Customer................................................................................................................................................395
Solution...................................................................................................................................................401
Solution Context...................................................................................................................................405
Contents v
Part 7: The Portfolio Level.....................................................................................................................411
Introduction to the Portfolio Level...................................................................................................413
Enterprise...............................................................................................................................................417
Strategic Themes..................................................................................................................................423
Program Portfolio Management.......................................................................................................429
Epic Owners...........................................................................................................................................435
Enterprise Architect.............................................................................................................................439
Portfolio Kanban...................................................................................................................................443
Portfolio Backlog...................................................................................................................................449
Budgets...................................................................................................................................................453
CapEx and OpEx...................................................................................................................................463
Value Streams.......................................................................................................................................473
Epics.........................................................................................................................................................483
Part 8: Guidance........................................................................................................................................489
Continuous Integration.......................................................................................................................491
Test-First.................................................................................................................................................497
Agile Contracts......................................................................................................................................503
Glossary of SAFe Terms......................................................................................................................511
Bibliography................................................................................................................................................523
Index..............................................................................................................................................................529
vi Contents
Preface
On behalf of the entire Scaled Agile, Inc., team and the SAFe contributors, it is my personal pleasure
to introduce the SAFe 4.0 Reference Guide.
SAFe is an online, freely revealed knowledge base of proven success patterns for implementing Lean-
Agile software and systems development at enterprise scale. It provides comprehensive guidance for
work at the enterprise Portfolio, Value Stream, Program, and Team levels.
Why SAFe?
The world’s economy, and the health and welfare of society as a whole, is increasingly dependent on
software and systems. In support of this need, systems builders are creating increasingly complex soft-
ware and cyber-physical systems of unprecedented scope and complexity with requirements for utility
and robustness exceeding those that have come before them.
The methods that systems builders use to create these systems must keep pace with this larger mandate.
However, the assumptive, one-pass, stage-gated, waterfall methods of the past are not scaling to the
new challenge. New development methods are needed. Agile shows the greatest promise, but it was
developed for small teams and, by itself, does not scale to the needs of larger enterprises and the systems
they create. What’s needed is a new way of working, one that applies the power of Agile but leverages
the more extensive knowledge pools of systems thinking and Lean product development. The Scaled
Agile Framework (SAFe) is one such approach.
SAFe is provided by Scaled Agile, Inc., where our core belief is simple: Better systems and software make
the world a better place. Our mission is to assist those who build these systems through development
and publication of the SAFe framework, as well as accompanying certification, training, and course-
ware. As case studies on the Scaled Agile Framework website (www.scaledagileframework.com) show,
many enterprises—large and small—are getting outstanding business benefits from applying SAFe.
These typically include:
• 20 – 50% increase in productivity
• 50%+ increases in quality
• 30 – 75% faster time to market
• Measurable increases in employee engagement and job satisfaction
Preface vii
As you can imagine, with results like those, SAFe is spreading rapidly around the world. The majority of
Fortune 100 U.S. companies have certified SAFe practitioners and consultants already on site, as do an
increasing percentage of the Global 1000 enterprises. SAI also has an extensive network of more than 80
global partners providing consulting and implementation services in almost every region of the world.
And while every business situation is unique, we have found that the straightforward Implementation
1-2-3 strategy always delivers results.
Our commitment is to continuously evolve SAFe to provide value to the industry—better systems,
better business outcomes, better daily lives for the people who build the world’s most important new
systems—but only you, the adopters and practitioners, can tell us whether or not we have accomplished
that. As we are fond of saying, “without you, SAFe is just a website.”
Why a Reference Guide?

The SAFe website is quite comprehensive, containing hundreds of pages of guidance for the various
roles, responsibilities, activities, and artifacts that constitute SAFe, along with the foundational elements
of values, Lean-Agile mindset, principles, and practices. This Reference Guide is intended to provide a
hard-copy or e-copy companion to help you understand and apply SAFe, with the goal of helping you
accomplish your mission of building better systems.
More on SAFe
For more on SAFe, please browse the site, read the blog, watch the “updates” field, and follow us
on Twitter (@ScaledAgile), where we will notify you of new developments. Also, click on the site’s
“Presentations & Downloads” tab to find free posters for the Big Picture, the House of Lean, and SAFe
Lean-Agile Principles. You’ll also find SAFe videos and recorded webinars, free presentations, and more.
Finally, be sure to check out our corporate site www.ScaledAgile.com. Even better, attend a Training
and Certification course (www.scaledagile.com/which-course); perhaps I will see you there. Stay SAFe!
—Dean Leffingwell and the Scaled Agile Team
viii Preface
Acknowledgments
Scaled Agile Framework Contributors
Alex Yakyma, SAFe Fellow and Principal Consultant
Alex is a SAFe methodologist, trainer, and principal consultant who has been involved
with the development and field implementations of the Scaled Agile Framework since
its inception. Alex’s broad prior experience as an engineer, development manager,
and program manager in highly distributed multicultural environments provides the
experience needed to assist enterprises with improving their system development
capabilities at the Program, multi-program, and Portfolio levels. Alex has published
a number of articles and white papers on Agile and Lean and is the author of Pacific
Express, a novella about launching an Agile Release Train.
Drew Jemilo, SAFe Fellow and Principal Consultant

Drew is a principal contributor to the Scaled Agile Framework, a consultant, and an
instructor. Drew met Dean Leffingwell in early 2009 when he was developing a scaled
Agile methodology for a management consulting company to bridge their strategic
business framework with Agile. Since then, they have worked together with global
clients to synchronize distributed teams using Agile Release Trains in the United
States, Europe, and India.
Richard Knaster, SAFe Fellow and Principal Consultant

Richard has more than 25 years’ experience in software development in roles rang-
ing from developer to executive and has been involved in Agile for more than a
decade. Prior to joining Scaled Agile, Inc., Richard worked at IBM, where his career
spanned from product line management (PPM domain) and professional services
to chief methodologist, Agile and Lean. Richard is a certified IBM Thought Leader
and an Open Group Distinguished IT Specialist. He is also a certified SPC, PSM,
Agile Certified Practitioner, PMP, and a contributor to the Disciplined Agile Delivery
framework and PMI Portfolio/Program Management standards.
Inbar Oren, SAFe Fellow and Principal Consultant

Inbar has more than 20 years’ experience in the high-tech market. For more than
a decade, he has been helping development organizations—in both software and
integrated systems—improve results by adopting Lean-Agile best practices. Previous
clients include Cisco, Woolworth, Amdocs, Intel, and NCR. Inbar’s current focus is
on working with leaders at the Program, Value Stream, and Portfolio levels to help
them bring the most out of their organizations and build new processes and culture.
Acknowledgments ix
SAFe Community Contributors
We are also indebted to those SAFe Program Consultant Trainers (SPCTs) and SAFe Program
Consultants (SPCs) who are doing the hard work of applying the framework in various enterprises every
day. Many have contributed indirectly in discussions, certification workshops, LinkedIn forums, and
more. More specifically, the following individuals have directly provided content that is included either
here or in Guidance articles on the Scaled Agile Framework website (www.scaledagileframework.com).
• Harry Koehnemann, SPCT – Special contributor to SAFe for Lean Systems Engineering
and 4.0 systems engineering content
• Ken France, SPCT – Guidance article: “Mixing Agile and Waterfall Development in the
Scaled Agile Framework”
• Scott Prugh, SPC – Guidance article: “Continuous Delivery”
• Eric Willeke, SPCT – Guidance articles: “Role of PI Objectives,” “A Lean Perspective on
SAFe Portfolio WIP Limit”
• Jennifer Fawcett, SAFe Fellow and Principal Consultant – Product Manager and
Product Owner contribution and focus
• Colin O’Neill, SPCT – SAFe 1.0 – 2.5 contributor
• Gareth Evans, SPCT – Guidance article: “Lean Software Development in SAFe”
• Gillian Clark, SPCT – Guidance article: “Lean Software Development in SAFe”
• Maarit Laanti, SPC – “Lean-Agile Budgeting” guidance and white paper
• Steven Mather, SPC – SAFe 2.0 glossary draft
• Al Shalloway, SPCT – Concept development and community support
Additional Acknowledgments
The Contributors to Agile Software Requirements
The initial concepts behind the framework were first documented in the 2007 text Scaling Software
Agility: Best Practices for Large Enterprises, by Dean Leffingwell. But the framework itself was first doc-
umented in Dean’s 2011 book Agile Software Requirements: Lean Requirements for Teams, Programs,
and the Enterprise (ASR), so it’s appropriate to repeat and update the book acknowledgments here.
Thanks to the ASR reviewers, Gabor Gunyho, Robert Bogetti, Sarah Edrie, and Brad Jackson. Don
Reinertsen provided permission to use elements of his book, The Principles of Product Development Flow.
Thanks to my Finnish collaborators: Juha-Markus Aalto, Maarit Laanti, Santeri Kangas, Gabor Gunyho,
and Kuan Eeik Tan. Alistair Cockburn, Don Widrig, Mauricio Zamora, Pete Behrens, Jennifer Fawcett,
and Alexander Yakyma contributed directly to book content. Even that list is not exhaustive; many
others—Mike Cottmeyer, Ryan Shriver, Drew Jemilo, Chad Holdorf, Keith Black, John Bartholomew,
Chris Chapman, Mike Cohn, Ryan Martens, Matthew Balchin, and Richard Lawrence—contributed
words, thoughts, or encouragement.
x Acknowledgments
A Special Acknowledgment to the Agile Thought Leaders
Of course, SAFe stands on the shoulders of many who came before us, particularly the Agile thought
leaders who created the industry movement. It starts with the signers of the Agile Manifesto and
continues with those outspoken thought leaders who have helped move the industry toward the new
paradigm. The following have contributed most directly to our understanding of Agile development:
Kent Beck, Alistair Cockburn, Ron Jeffries, Mike Cohn, David Anderson, Jeff Sutherland, Martin
Fowler, Craig Larman, Ken Schwaber, Scott Ambler, and Mary and Tom Poppendieck. Still others are
acknowledged in the Bibliography.
A Special Acknowledgment to the Lean Leaders

In extending Agile to the enterprise and developing the broader Lean-Agile paradigm, we are fortunate
to stand on the shoulders of Lean thought leaders as well, including Don Reinertsen, Jeffrey Liker, Taichi
Ohno, Eli Goldratt, Dr. Alan Ward, Jim Sutton, Michael Kennedy, Dantar Oosterwal, Steve Womack,
and Daniel Jones. Still others are acknowledged in the Bibliography.
And to W. Edwards Deming

Finally, where would we be without the seminal works of W. Edwards Deming, to whom we perhaps
owe the deepest gratitude of all? He was a visionary and systems thinker, whose tireless quest for the
underlying truths and unwavering belief in people and continuous improvement led to a set of trans-
formational theories and teachings that changed the way we think about quality, management, and
leadership.
Acknowledgments xi
This page intentionally left blank
Introduction to the Scaled Agile Framework
(SAFe)
The Scaled Agile Framework (SAFe) is a freely revealed knowledge base of proven, integrated patterns
for enterprise-scale Lean-Agile development. It is scalable and modular, allowing each organization to
apply it in a way that provides better business outcomes and happier, more engaged employees.
SAFe synchronizes alignment, collaboration, and delivery for large numbers of Agile Teams. It sup-
ports both software solutions and complex cyber-physical systems that require thousands of people
to create and maintain. SAFe was developed in the field, based on helping Customers solve their most
challenging scaling problems. SAFe leverages three primary bodies of knowledge: Agile development,
Lean product development and flow, and systems thinking.
Overview
The SAFe website (www.scaledagileframework.com) provides comprehensive guidance for scaling
development work across all levels of an enterprise. SAFe’s interactive “Big Picture” (Figure 1) pro-
vides a visual overview of the framework. Each icon on the website is selectable, navigating the user
to an article that provides extensive guidance on the topic area, along with links to related articles and
further information.
The Big Picture has two views. The default “3-level view” (below left) is well suited for solutions that
require a modest number of Agile Teams. The “4-level view” (below right) supports those building large
solutions that typically require hundreds or more practitioners to construct and maintain.
SAFe 4.0 for Lean Software and Systems Engineering

®
Kanban
Enterprise Epic Epic

Enabler Enabler
PORTFOLIO
PORTFOLIO
Epic Owners
NFRs
Program Portfolio Backlog Va l u e S t r e a m s
Strategic Mgmt
Themes Enterprise
Architect
CapEx & OpEx
Bud
Coordination ge
ts
Expand
• DevOps • Release Mgmt Vision Roadmap Metrics • Milestones
one level
• Sys Team • Shared Services • Releases Customer
• User Experience
VALUE STREAM
AGILE RELEASE TRAIN Solution
Epics Release Any Time

Lean-Agile WSJF
Leaders RTE
PROGRAM
Kanban
Business Enablers
Owners System Demos • Exploration
Feature • Architecture
Communities System
of Practice
Product Feature • Infrastructure
Arch/Eng Mgmt Enabler
PI Planning
PI Planning
PI Planning
NFRs Enabler
Backlog PI Objectives Feature Architectural
Feature Runway
Product XP Stories Goals

Retro
Owner
Increment
Program Increment
ProgramIncrement
I I
Demo
Backlog
PI
Plan
P P
TEAM
Scrum Objectives
Master EXE
SW Scrum
PROGRAM
NFRs
FW
Program
HW Retro
I I
Demo
Built-In Quality
Plan
Backlog
PI P P
Objectives EXE
Agile Team Develop on Cadence
Kanban NFRs Iterations
Provided by Scaled Agile, Inc. Core Lean-Agile SAFe Implementing
Leffingwell, et al. © 2008–2016 Scaled Agile, Inc. v 4.0
Values Mindset Principles 1 23

TEAM
Figure 1. Big Picture: 3-level and 4-level SAFe
Introduction to the Scaled Agile Framework (SAFe) 1

SAFe provides three, and optionally four, organization levels, as well as a foundation, as follows:
• Team Level – SAFe is based on Agile Teams, each of which is responsible for defining,
building, and testing stories from their backlog. Teams employ Scrum or Kanban
methods, augmented by quality practices, to deliver value in a series of synchronized,
fixed-length iterations.
• Program Level – SAFe teams are organized into a virtual program structure called the
“Agile Release Train” (ART). Each ART is a long-lived, self-organizing team of 5 to 12
Agile Teams—along with other stakeholders—that plan, commit, execute, inspect and
adapt, and deliver solutions together.
• Value Stream Level – The optional value stream level supports the development of
large and complex solutions. These solutions require multiple, synchronized ARTs, as
well as stronger focus on solution intent and solution context. Suppliers and additional
stakeholders contribute as well.
• Portfolio Level – The portfolio level organizes and funds a set of value streams. The
portfolio provides solution development funding via Lean-Agile budgeting and provides
necessary governance and value stream coordination.
• Foundation Layer – The foundation layer holds various additional elements that support
development. Elements include guidance for Lean-Agile Leaders, communities of
practice, core values, the Lean-Agile mindset, the nine Lean-Agile principles that guide
SAFe, and an overview of implementation strategy.
Foundation Layer
The foundation layer of SAFe (the shadow backdrop on the big picture) contains the aspects of SAFe
that are critical, necessary, and supportive of value delivery, but are not specific practices. This layer
contains the following:
• Lean Agile Leaders – The ultimate responsibility for the success of the enterprise,
and thereby any significant change to the way of working, lies with management.
To this end, SAFe describes a new style of leadership, one that is exhibited by SAFe’s
Lean-Agile Leaders.
• Communities of Practice – The Lean approach to aligning around Value Streams
typically causes the Lean enterprise to pivot from a functional organization to a more
flexible and adaptive line-of-business approach. In response, SAFe also supports
communities of practice, informal groups of team members and other experts who share
practical, functional knowledge in one or more relevant domains.
• Core Values – There are four primary core values that help make SAFe effective:
Alignment, Built-in Quality, Transparency, and Program Execution.
2 Introduction to the Scaled Agile Framework (SAFe)

• Lean-Agile Mindset – SAFe Lean-Agile Leaders are lifelong learners and teachers who
understand and embrace Lean and Agile principles and practices, and teach them to
others. To achieve that effectively, leaders must first be trained in, and then become
trainers of, these leaner ways of thinking and operating. This mindset is exhibited in part
by the House of Lean and the Agile Manifesto.
• Lean-Agile Principles – SAFe’s practices are grounded on nine fundamental principles
that have evolved from Agile principles and methods, Lean product development,
systems thinking, and observation of successful enterprises. These are:
#1 – Take an economic view
#2 – Apply systems thinking
#3 – Assume variability; preserve options
#4 – Build incrementally with fast, integrated learning cycles
#5 – Base milestones on objective evaluation of working systems
#6 – Visualize and limit WIP, reduce batch sizes, and manage queue lengths
#7 – Apply cadence, synchronize with cross-domain planning
#8 – Unlock the intrinsic motivation of knowledge workers
#9 – Decentralize decision-making
• Implementing 1-2-3 – Based on the learnings from hundreds of SAFe implementations,

a basic “Implementing SAFe 1-2-3” pattern for successfully adopting SAFe has emerged.
The pattern is, first, train implementers and Lean-Agile change agents (SPCs). In turn,
these external or internal consultants can then train all executives, managers, and leaders.
After this, SPCs can train teams and launch Agile Release Trains.
Team Level
The team level provides an organization, artifact, role, and process model for the activities of Agile
Teams, as illustrated in Figure 2.
TEAM
Figure 2. SAFe team level

All SAFe teams are part of one Agile Release Train (ART)—the central construct of the program level.
Each Agile Team is responsible for defining, building, and testing stories from their team backlog in
a series of fixed-length iterations, using common iteration cadence and synchronization to align with
other teams, so that the entire system is iterating.
Teams use Scrum or Team Kanban, along with the Built-in Quality practices, to deliver working soft-
ware every two weeks. The system demo creates a routine “pull event,” which pulls the effort of the
different teams together, bringing forward the hard work of integration and testing that phase-gated
models often leave until too late in the life cycle.
Each team has five to nine members and includes all the roles necessary to build a quality increment
of value in each iteration. Roles include the Scrum Master, Product Owner, dedicated individual con-
tributors, and any specialty resources the team needs to deliver value.
A summary of this level is provided in the “Introduction to the Team Level” overview article.
Program Level
The heart of SAFe is the program level, illustrated in Figure 3, which revolves around the organization
called the “Agile Release Train,” and which incorporates the team level by reference.
• DevOps • Release Mgmt Vision Roadmap Metrics • Milestones

• Sys Team • Shared Services • Releases Customer
• User Experience
AGILE RELEASE TRAIN Solution

Lean-Agile WS JF
Leaders RTE
PROGRAM
Kanban
Business Enablers
Communities System
of Practice
PI Planning
PI Planning
PI Planning
NFRs Enabler
Feature Runway

Retro
Owner
Increment
Program Increment
ProgramIncrement
I I
Demo
Backlog
PI
Plan
Scrum Objectives P P TEAM

Master EXE
SW Scrum NFRs
FW
Program
HW Retro
I I
Demo
Built-In Quality
Plan
Backlog
PI P P
Objectives EXE
Provided by Scaled Agile, Inc. Leffingwell, et al. © 2008–2016 Scaled Agile, Inc. v 4.0
Core Lean-Agile SAFe Implementing
Figure 3. Program level
SAFe program level teams, roles, and activities are organized around the ART metaphor, a team of
Agile Teams that delivers a continuous flow of incremental releases of value.

ARTs are virtual organizations formed to span functional boundaries, eliminate unnecessary handoffs
and steps, and accelerate the delivery of value via implementation of SAFe Lean-Agile principles and
practices.
While it is called the “program level,” ARTs are generally very long-lived and therefore have a more
persistent self-organization, structure, and mission than a traditional “program,” which more classically
has a start and an end date, as well as temporarily assigned resources. It is the long-lived, knowledge
acquiring, flow-based, and self-organizing nature of the ART that powers the SAFe portfolio.
Value in SAFe is delivered by Agile Release Trains, each of which realizes a portion of a value stream
(or, in some cases, the entire value stream). They deliver value incrementally in program increments
(PIs) of 8 to 12 weeks in duration; each PI is a multiple-iteration timebox during which a significant,
valuable increment of the system is developed. Each ART is composed of 5 to 12 Agile Teams (50 – 125+
people) and includes the roles and infrastructure necessary to deliver fully tested, working, system-level
solutions. Many release trains are virtual, spanning organizational and geographic boundaries; others
follow a line of business or product line management reporting structure.
A summary of this level is provided in the “Introduction to the Program Level” overview article.
The Spanning Palette

There are a number of additional icons indicated on this level; they are located at the conjunction
of the value stream and program level on the Big Picture. This is called the “spanning palette” and is
illustrated in Figure 4.
Figure 4. The spanning palette
Each of these artifacts and roles contributes to the ART and program level, as described in the “Vision,”
“Roadmap,” “Metrics,” “Milestones,” “Releases,” “DevOps,” “System Team,” “Release Management,”
“Shared Services,” and “User Experience” articles. However, these elements also “span” the levels because
many of them are also useful at the other levels.

Value Stream Level
The value stream level is optional in SAFe. Enterprises that build systems that are largely independent,
or that can be built with a few hundred practitioners, may not need these constructs, and in that case
the portfolio can operate with the 3-level view. Even then, however, those are far from trivial systems,
and the constructs at the value stream level can be used in 3-level SAFe as needed.
The value stream level helps enterprises that face the largest systems challenges: those building large-
scale, multidisciplinary software and cyber-physical systems. Building such solutions in a Lean-Agile
manner requires additional constructs, artifacts, and coordination. The constructs of the value stream
level are illustrated in Figure 5.
VALUE STREAM
Figure 5. Value stream level
This level contains an economic framework, intended to provide financial boundaries for value stream
and ART decision-making; solution intent as a repository for intended and actual solution behavior;
solution context, which describes the way the solution fits in the deployment environment; and capa-
bilities, describing the larger behaviors of the solution.
Like the program level, the value stream level is organized around program increments, which are
synchronized across all the ARTs in the value stream. It provides for cadence and synchronization of
multiple ARTs and Suppliers, including pre- and post-PI planning meetings and the solution demo.
It also provides additional roles, specifically Solution Management, Solution Architect/Engineering,
and the Value Stream Engineer.
A summary of this level may be found in the “Introduction to the Value Stream Level” overview article.
Portfolio Level
The SAFe portfolio is the highest level of concern in SAFe. As illustrated in Figure 6, each SAFe port-
folio has the value streams, people, and processes necessary to provide funding and governance for the
products, services, and solutions required to fulfill the overall business strategy.

PORTFOLIO
Figure 6. SAFe portfolio level
It provides the basic constructs for organizing the Lean-Agile Enterprise around the flow of value via
one or more value streams, each of which develops the systems and solutions necessary to meet the
strategic intent. The portfolio level encapsulates these elements and also provides the basic budgeting
and other governance mechanisms that are necessary to ensure that the investment in the value streams
provides the returns necessary for the enterprise to meet its strategic objectives.
The portfolio has a bidirectional connection to the business. One direction provides the strategic themes
that guide the portfolio to the larger, and changing, business objectives. The other direction indicates
a constant flow of portfolio context back to the enterprise.
The primary elements of the portfolio are value streams (one or more), each of which provides funding
for the people and other resources necessary to build the solutions that deliver the value. Each value
stream is a long-lived series of system definition, development, and deployment steps used to build and
deploy systems that provide a continuous flow of value to the business or Customer. Program Portfolio
Management represents the stakeholders who are accountable to deliver the business results.
A summary of this level may be found in the “Introduction to the Portfolio Level” overview article.

Lean-Agile Leaders
A leader is one who knows the way, goes the way, and shows the way.
—John C. Maxwell
Abstract
The philosophy of SAFe is simple: As the enabler for the teams, the ultimate responsibility for adop-
tion, success, and ongoing improvement of Lean-Agile development lies with the Enterprise’s existing
managers, leaders, and executives. Only they can change and continuously improve the systems in
which everyone operates. To achieve this, leaders must be trained, and become trainers, in these leaner
ways of thinking and operating. Many need to offer a new style of leadership, one that truly teaches,
empowers, and engages individuals and teams to reach their highest potential.
While some of these management roles and titles do not appear specifically on the Big Picture, they
serve a critical function nonetheless by providing the personnel, resources, management, direction,
and support necessary to help the enterprise achieve its mission. This article describes the principles
of these Lean-Agile Leaders.
Details
SAFe Lean-Agile Leaders are lifelong learners and teachers who help teams build better systems
through understanding and exhibiting the Lean-Agile Mindset, SAFe Principles, and systems thinking.
Such leaders exhibit the behaviors below.
#1 – Lead the Change

The work of steering an organization toward Lean and Agile behaviors, habits, and results cannot be
delegated. Rather, Lean-Agile Leaders exhibit urgency for change, communicate the need for the change,
build a plan for successful change, understand and manage the change process, and address problems
as they come up. They have knowledge of organizational change management and take a systems view
with respect to implementing the transformation.
Lean-Agile Leaders 11
#2 – Know the Way; Emphasize Lifelong Learning
Create an environment that promotes learning. Encourage team members to build relationships with
Customers and Suppliers and expose them to other world views. Strive to learn and understand new
developments in Lean, Agile, and contemporary management practices. Create and foster formal and
informal groups for learning and improvement. Read voraciously from the recommended reading list
and on other topics. Share selected readings with others and sponsor book club events for the most
relevant texts.
Allow people to solve their own problems. Help them identify a given problem, understand the root
causes, and build solutions that will be embraced by the organization. Support individuals and teams
when they make mistakes, otherwise learning is not possible.
#3 – Develop People
Employ a Lean leadership style, one that focuses on developing skills and career paths for team members
rather than on being a technical expert or coordinator of tasks. Create a team jointly responsible for
success. Learn how to solve problems together in a way that develops people’s capabilities and increases
their engagement and commitment. Respect people and culture.
#4 – Inspire and Align with Mission; Minimize Constraints

Provide mission and vision, with minimum specific work requirements. Eliminate demotivating pol-
icies and procedures. Build Agile Teams and trains organized around value. Understand the power
of self-organizing, self-managing teams. Create a safe environment for learning, growth, and mutual
influence. Build an Economic Framework for each Value Stream and teach it to everyone.
#5 – Decentralize Decision-Making
(See “SAFe Principle #9” for further discussion.)
Establish a decison-making framework. Empower others by setting the mission, developing people,
and teaching them to problem-solve. Take responsibility for making and communicating strategic
decisions—those that are infrequent, long lasting, and have significant economies of scale. Decentralize
all other decisions.
#6 – Unlock the Intrinsic Motivation of Knowledge Workers

(See “SAFe Principle #8” for further discussion.)
Understand the role that compensation plays in motivating knowledge workers. Create an environment
of mutual influence. Eliminate any and all management by objectives (MBOs) that cause internal com-
petition. Revamp personnel evaluations to support Lean-Agile principles and values. Provide purpose
and autonomy; help workers achieve mastery of new and increasing skills.
12 PART 1 | THE SAFe FOUNDATION

Role of the Development Manager
As an instantiation of the principles of Lean and Agile development, SAFe emphasizes the values of
nearly autonomous, self-organizing, cross-functional teams and Agile Release Trains. This supports
a leaner management infrastructure, with more empowered individuals and teams and faster, local
decision-making. Traditional, day-to-day employee instruction and activity direction is no longer
required.
However, all employees still need someone to assist them with career development; set and manage
expectations and compensation; and provide the active coaching they need to advance their technical,
functional, individual, and team skills and career goals. They also have a right to serve as an integral
member of a high-performing team.
In addition, self-organizing ARTs do not fund themselves or define their own mission. That remains a
management responsibility, as it is an element of implementation of strategy.
Much of this responsibility traditionally falls to the traditional role of the development manager, and
the adoption of Lean-Agile development does not abrogate their responsibilities. However, in SAFe
these responsibilities fall to those who can adapt, thrive, and grow in this new environment.
Responsibilities
The development manager (or engineering manager for system development) is a manager who exhib-
its the principles and practices of Lean-Agile leadership as described above. Further, the manager has
personal responsibility for the coaching and career development of direct reports, takes responsibility
for eliminating impediments, and actively evolves the systems in which all knowledge workers oper-
ate. They have final accountability for effective value delivery as well. A summary of responsibilities is
highlighted below.
Personnel and Team Development

• Attract, recruit, and retain capable individuals
• Build high-performing teams; establish mission and purpose for individuals and teams
• Perform career counseling and personal development
• Listen and support teams in problem identification, root cause analysis, and
decision-making
• Participate in defining and administering compensation, benefits, and promotions
• Eliminate impediments and evolve systems and practices in support of Lean-Agile
development
• Take subtle control in assignment of individuals to teams; address issues that teams
cannot unblock; make personnel changes where necessary
• Evaluate performance, including team input; provide input, guidance, and corrective
actions
• Serve as Agile coach and advisor to Agile Teams
• Remain close enough to the team to add value and to be a competent manager; stay far
enough away to let them problem-solve on their own
Program Execution
• Help in building Agile Milestones and Roadmaps, as well as the building plans that
enable them
• Help develop, implement, and communicate the economic framework
• Participate in Inspect and Adapt workshops
• Protect teams from distractions and unrelated or unnecessary work
• Assist the Release Train and Value Stream Engineers with PI Planning readiness and Pre-
and Post-PI Planning activities
• Participate in PI planning, System Demo, and Solution Demo
• Build partnerships with Suppliers, subcontractors, consultants, partners, and internal and
external stakeholders
• Provide other resources as necessary for teams and ARTs to successfully execute their
Vision and roadmap
Alignment
• Work with Release Train and Value Stream Engineers and system stakeholders to help
ensure alignment and effective execution of Strategic Themes
• Work with the System Architect/Engineer, Product Managers, and Product Owners to
establish clear content authority
• Continuously assist in aligning teams to the system mission and vision
• Help ensure the engagement of Business Owners, Shared Services, and other stakeholders
Transparency
• Create an environment where the facts are always friendly
• Provide freedom and safety so individuals and teams are free to innovate, experiment,
and even fail on occasion
• Communicate openly and honestly with all stakeholders
• Keep backlogs and information radiators fully visible to all
• Value productivity, quality, transparency, and openness over internal politics

Built-in Quality
• Understand, teach, or sponsor technical skills development in support of high-quality
code, components, systems, and Solutions
• Foster Communities of Practice
• Understand, support, and apply Agile Architecture
LEARN MORE
[1] Manifesto for Agile Software Development. http://agilemanifesto.org/.
[2] Reinertsen, Donald. The Principles of Product Development Flow: Second Generation Lean Product
Development. Celeritas Publishing, 2009.
[3] Rother, Mike. Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results.
McGraw-Hill, 2009.
[4] Liker, Jeffrey and Gary L. Convis. The Toyota Way to Lean Leadership: Achieving and Sustaining
Excellence Through Leadership Development. McGraw-Hill, 2011.
Communities of Practice
It’s said that a wise person learns from his mistakes. A wiser one learns
from others’ mistakes. But the wisest person of all learns from others’
successes.
—Zen proverb adapted by John C. Maxwell
Abstract
A Community of Practice (CoP) is an informal group of team members and other experts, acting within
the context of a program or enterprise, that has a mission of sharing practical knowledge in one or
more relevant domains. CoPs are not new, nor are they mandated by Agile development. However, the
Lean approach to aligning around Value Streams optimizes for delivery of value, which is a good thing.
Over time, this typically causes the Lean Enterprise to pivot from a vertical, functional organization to
a more flexible, horizontal line-of-business organization that can deliver value more rapidly. Further,
within value streams, SAFe promotes long-lived Agile Release Trains (ARTs), which are built of people
allocated to them for an extended period. What happens when practitioners of a discipline (whether
or not their organization has become horizontal), who are from different programs but often have the
same reporting structure, meet regularly, are led by managers and experts from their domain, and
advance their specialist skills? Enter the SAFe CoP (Guild, in Spotify terminology [1]).
Details
Lean-Agile promotes cross-functional teams and programs that facilitate value delivery in the Enterprise.
Similarly, Lean thinking emphasizes organizing people with different skills around a Value Stream.
However, developers need to talk with other developers within or outside of the team context, testers
need to talk with other testers, Product Owners need to communicate with their peers from other Agile
Teams, and so on. This is critical for leveraging the multiple experiences and different types of practical
knowledge available from different people at scale. That is what drives craftsmanship and persistent
knowledge acquisition and facilitates the adoption of new methods and techniques.
Such inter-team communication is often supported by Communities of Practice (CoP)—informal

working groups designed specifically for efficient knowledge-sharing and exploration across teams
and groups of professionals, as shown in Figure 1.
Communities of Practice 17
Figure 1. Community of practice: Members normally work in their
Agile Teams but also regularly share best practices
Organizing a Community of Practice

A Lean enterprise has the ability to identify the relevant domains where communities of practice would
be beneficial and then to foster and support such communities once they are in place.
CoPs can be ad hoc and need driven. They may or may not be permanent; they may form and disband
based on current need and context. For example, an automated testing CoP could be composed of
test engineers and developers who are interested in advancing these skills. An architecture and design
CoP would foster the adoption of practices such as emergent design, intentional system architecture,
Continuous Integration, and refactoring. It could also support the effort put into building and main-
taining the Architectural Runway, foster designing for testability and deployability, deprecate old
platforms, and more. Still others may be formed around Agile coaching, continuous integration, con-
tinuous delivery, coding standards, and other new practices and processes. Similarly, Scrum Masters
from different Agile Teams may form a CoP to exchange facilitation best practices and experiences in
building highly productive Agile Teams.
Operating a Community of Practice

A CoP is defined by the knowledge specialization of its members. Each typically has a specific learning
objective, Roadmap, and backlog. Membership is fluid and changes as members take on different roles,
as new needs arise, or as individual members gain the knowledge they need. CoPs may be fostered or
initiated spontaneously. They are largely self-organizing, although a leader or Scrum Master equiva-
lent (the Guild Coordinator in Spotify terminology) may organize the initiative and help maintain its
momentum. CoPs meet regularly for knowledge-exchange sessions and maintain and evolve internal
community websites and wikis to institutionalize their knowledge. The CoP exists only for so long as
the members believe they have something to learn or contribute.
However, CoPs are created for the purpose of learning and exchanging experiences, not for coordinating
dependencies or current tasks.

For instance, the Scrum Master CoP would foster learning new facilitation techniques, while actual
coordination and dependency management for current work in process would happen among the same
people during the Scrum of Scrums.
The Innovation and Planning Iteration presents a great time for CoPs to hold learning sessions, formal
or informal, as well as other activities such as coding dojos, coaching clinics, and the like.
It is the role of Lean-Agile Leaders to encourage and support people’s desire to improve as this both
helps the enterprise and builds the intrinsic motivation of knowledge workers, as is evident in SAFe
Principle #9–Decentralize decision-making.
LEARN MORE
[1] Scaling Agility @ Spotify with Tribes, Squads, Chapters, and Guilds. https://dl.dropboxusercontent.
com/u/1018963/Articles/SpotifyScaling.pdf.
Communities of Practice 19
SAFe Core Values
Find people who share your values, and you’ll conquer the world together.
—John Ratzenberger
Abstract
Core Values are the fundamental beliefs of a person or organization. The core values are the guiding
principles that dictate behavior and action. Core values can help people to know what is right from
wrong; where to put their focus and help companies to determine if they are on the right path and
fulfilling their business goals; and they create an unwavering and unchanging guide.
A Lean-Agile Mindset, Lean-Agile Leaders, SAFe Principles, and the extensive benefits that Lean-Agile
development provides all play important roles in defining what makes SAFe safe. But in synthesis,
there are four Core Values that SAFe honors, supports, and helps deliver: Alignment, Built-in Quality,
Transparency, and Program Execution. If an Enterprise does those four things well, a lot of goodness
will surely follow.
Details
SAFe is broad and deep and is based on both Lean and Agile principles. That’s what it’s built on, but what
does SAFe itself stand for? SAFe upholds four Core Values: Alignment, Built-in Quality, Transparency,
and Program Execution.
These are illustrated in Figure 1, and each is discussed in the paragraphs that follow.
SAFe Core Values 21

Built-in Quality
SAFe 4.0 for Lean Software and Systems Engineering

®
Kanban
Enterprise Epic Epic
Enabler Enabler
PORTFOLIO
Epic Owners
NFRs
Program Portfolio Backlog Va l u e S t r e a m s
Strategic Mgmt
Themes Enterprise
Architect
CapEx & OpEx
Bud
Coordination ge
ts
Economic
Framework Epics
Transparency
WSJF Solution Demo
VSE
MBSE
Alignment
Kanban
Enabler
VALUE STREAM
Variable
Set Capability
Pre
Pre
Fixed Based Solution
Post
Post
Solution
Agile Arch/Eng Mgmt NFRs PI Objectives Capability
Architecture Backlog Customer
AGILE RELEASE TRAIN
Solution
AGILE RELEASE TRAIN
• DevOps • Release Mgmt Vision Roadmap Metrics • Milestones SUPPLIER

• Sys Team • Shared Services • Releases Solution Context
• User Experience
AGILE RELEASE TRAIN

Lean-Agile WSJF
Leaders RTE
PROGRAM
Kanban
Business Enablers
Communities System
of Practice
PI Planning
PI Planning
PI Planning
NFRs Enabler
Feature Runway

Retro
Owner
Increment
Program Increment
ProgramIncrement
I I
Demo
Backlog
PI
Plan
P P
TEAM
Scrum Objectives
Master EXE
SW Scrum NFRs
FW
Program
HW Retro
I I
Demo
Built-In Quality
Plan
Backlog
PI P P
Objectives EXE
Provided by Scaled Agile, Inc. Core Lean-Agile SAFe Implementing
Leffingwell, et al. © 2008–2016 Scaled Agile, Inc. v 4.0
Program Execution
Figure 1. SAFe core values: alignment,

built-in quality, transparency, program execution
Alignment
Like cars out of alignment, misaligned companies can develop serious problems. They are hard to steer
and they don’t respond well to changes in direction [1]. Even if it’s clear where everyone thinks they’re
headed, the vehicle is unlikely to get them there.
Alignment scales. It is a necessary condition to be able to address the business reality of fast-paced
change, turbulent competitive forces, and geographically distributed teams. While empowered Agile
Teams are good (even great), the responsibility for strategy and alignment cannot rest with the accu-
mulated opinions of the teams, no matter how good they are. Rather, alignment must be based on the
Enterprise business objectives. Here are some of the ways in which SAFe supports alignment:
• It starts at the strategy level of the portfolio, is reflected in Strategic Themes and the
Portfolio Backlog, and then moves down through the Vision, Roadmap, and Program
Backlogs to the Team Backlogs. All is visible. All is debated. All is resolved. All is known.
• It is supported by clear lines of content authority, starting at the portfolio and then
resting primarily with the Product and Solution Management roles, and extending to the
Product Owner role
• PI Objectives and Iteration Goals are used to communicate expectations and
commitments
• Cadence and synchronization are applied to ensure that things stay in alignment, or that
they drift only within reasonable economic and time boundaries

• Program architecture, User Experience guidance, and governance help ensure that the
Solution is technologically sound, robust, and scalable
• Lean prioritization keeps the stakeholders engaged in continuous, agreed-to, rolling-
wave prioritization, based on the then-current context and changing fact patterns
Alignment, however, does not imply or encourage command and control. Instead, it provides a foundation
for the enterprise where business objectives and outcomes are the continued focus. It also encourages
decentralized technical and economic decision-making, thereby enabling those who implement value
to make better local decisions.
Built-in Quality
Built-in Quality ensures that every increment of the solution reflects quality standards. Quality is not
“added later.” Built-in quality is a prerequisite of Lean and flow; without it, the organization will likely
operate with large batches of unverified, unvalidated work. Excessive rework and slower velocities are
the likely outcome. There can be no ambiguity about the importance of built-in quality in large-scale
systems. It is mandatory.
Software
In complex solutions, software functionality often represents a fast-changing and increasingly high-
investment area. In addition, given the high levels of complexity and the manual nature of much of the
work, it is often the source of many solution defects. The relatively lower cost of change encourages
rapid adaptation, which is good. But if attention is not paid, the software design may quickly erode,
negatively affecting quality and velocity.
Put simply, you can’t scale crappy code. The Agile Manifesto certainly focused on quality: “Continuous
attention to technical excellence and good design enhances agility” [2]. To address software quality
in the face of rapid change, software practitioners have developed and evolved a number of effective
practices, many of which are largely inspired by eXtreme Programming. These include:
• Test-First: Test-Driven Development (TDD), Acceptance Test-Driven Development
(ATDD), and Behavior-Driven Development (BDD)
• Continuous Integration
• Refactoring
• Pair work
• Collective ownership
SAFe Core Values 23

Hardware
But coding aside, no one can scale crappy components or systems, either. Hardware elements—
electronics, electrical, fluidics, optics, mechanical, packaging, thermal, and many more—are a lot less
“soft.” Errors here can introduce a much higher cost of change and rework. Tips to avoid this include:
• Frequent design cycles and integration [3]
• Collaborative design practices
• Model-Based Systems Engineering
• Set-Based Design
• Investment in development and test infrastructure
System Integration
Eventually, different components and subsystems—software, firmware, hardware, and everything
else—must collaborate to provide effective solution-level behaviors. Practices that support solution-level
quality include:
• Frequent system and solution-level integration
• Solution-level testing of functional and Nonfunctional Requirements
• System and Solution Demos
Transparency
Solution development is hard. Things go wrong or do not work out as planned. Without transparency,
facts are obscure and hard to come by. This results in decisions based on speculative assumptions and
lack of data. No one can fix a secret.
For that trust is needed, because without trust no one can build high-performing teams and programs,
or build (or rebuild) the confidence needed to make and meet reasonable commitments. Trust exists
when one party can confidently rely on another to act with integrity, particularly in times of difficulty.
And without trust, working environments are a lot less fun and motivating.
Building trust takes time. Transparency is the enabler for trust. SAFe helps an enterprise achieve
transparency:
• Executives, Portfolio Managers, and other stakeholders are able to see into the Portfolio
Kanbans and program backlogs, and they have a clear understanding of the PI goals for
each train
• Programs have visibility into the team’s backlogs, as well other program backlogs
• Teams and programs commit to short-term, clear, and visible commitments. They
routinely meet them.

• Programs Inspect and Adapt with all relevant stakeholders; lessons learned are
incorporated.
• Teams and programs have visibility into business and architecture Epic Kanban systems.
They can see what might be headed their way.
• Status reporting is based on objective measures of working systems
• Everyone can understand the velocity and WIP of the teams and programs; strategy and
the ability to execute are aligned
Program Execution
Of course, none of the rest of SAFe matters if teams can’t execute and continuously deliver value.
Therefore, SAFe places an intense focus on working systems and resultant business outcomes. This isn’t
only for the obvious reasons. History shows us that while many enterprises start the transformation
with Agile Teams, they often become frustrated as even those teams struggle to deliver larger amounts
of solution value reliably and efficiently.
That is the purpose of the Agile Release Train, and that is why SAFe focuses implementation initially
at the Program Level. In turn, the ability of Value Streams to deliver value depends on the ability of
the ARTs.
But with alignment, transparency, and built-in quality on the team’s side, they have a little “wind at their
back.” That enables a focus on execution. And if they struggle—and they will, because complex solution
development is hard—they have the cornerstone of the inspect and adapt workshops. In that way, they
close the loop and execute better and better during each Program Increment.
But program execution can’t just be a team-based, bottom-up thing. Successful Lean-Agile execution
at scale requires not just the teams but the active support of their Lean-Agile Leaders, who couple their
internal leadership with an orientation toward system and Customer outcomes. That creates a persistent
and meaningful context for the teams and their stakeholders.
That’s the way the successful teams and programs are doing it, and that’s why they are getting the many
benefits—employee engagement, productivity, quality, and time to market—that Lean-Agile enterprises
so enjoy.
LEARN MORE
[1] Labovitz, George H. and Victor Rosansky. The Power of Alignment: How Great Companies Stay Centered and
Accomplish Extraordinary Things. Wiley, 1997.
[2] AgileManifesto.org.
[3] Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with
Revolutionary Lean Product Development. Amacom, 2010.
SAFe Core Values 25

Lean-Agile Mindset
It all starts with a Lean-Agile Mindset.

—SAFe Authors
Abstract
SAFe is based on a number of newer paradigms in modern systems and software engineering, includ-
ing Lean and systems thinking, product development flow, and Agile development. As reflected at the
Team Level, Agile provides the tools needed to empower and engage teams to achieve unprecedented
levels of productivity, quality, and engagement. But a broader and deeper Lean-Agile Mindset is needed
to support Lean and Agile development at scale across the entire Enterprise.
Thinking Lean
Much of the thinking in Lean is represented in the SAFe “House of Lean” icon. It is organized around
six key constructs. The “roof ” represents the goal of delivering Value, the “pillars” support that goal via
Respect for People and Culture, Flow, Innovation, and Relentless Improvement. Lean-Agile 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.
Together, these create the Lean-Agile Mindset, part of a new management approach and an enhanced
culture, one that provides the leadership needed to drive a successful transformation, and one that
helps both individuals and businesses achieve their goals.
Details
The SAFe House of Lean
While initially derived from Lean manufacturing [1], the principles and practices of Lean thinking as
applied to software, product, and systems development are now deep and extensive.
Lean-Agile Mindset 27
For example, Ward [2], Reinertsen [3], Poppendieck [4], Leffingwell [5], and others have described
aspects of Lean thinking that put many of the core principles and practices into a product development
context. In combination of these factors, we present the SAFe House of Lean, as illustrated in Figure 1,
which is inspired by “houses” of Lean from Toyota and others.
Figure 1. The SAFe House of Lean
The Goal – Value

The goal of Lean is inarguable: to deliver the maximum Customer value in the sustainably shortest lead
time, while providing the highest possible quality to Customers and society as a whole. High morale,
safety, and Customer delight are further tangible targets and benefits.
Pillar 1 – Respect for People and Culture

SAFe is a systematic framework for implementing Lean-Agile development at scale, but it does not
instantiate itself, nor does it perform any real work. People do all the work. Respect for people and
culture is a fundamental value of the SAFe House of Lean. People are empowered to evolve their own
practices and improvements.

Management challenges people to change and may even indicate what to improve, but the teams and
individuals learn problem-solving and reflection skills, and they make the appropriate improvements.
Culture is the driving force behind this behavior. To evolve a truly Lean organization, the culture will
need to change. In order for that to happen, the organization and its leaders must change first. And
culture and people are not solely an internal construct. The culture of the organization extends to long-
term relationships with Suppliers, partners, Customers, and the broader community that supports the
Enterprise.
Where there is urgency for positive change, improvements in culture can be achieved gradually by, first,
understanding SAFe values and principles; second, implementing SAFe practices; and third, delivering
positive results. Changes to culture will follow naturally.
Pillar 2 – Flow
The key to successful execution in SAFe is establishing a continuous flow of work that supports incre-
mental value delivery, based on continuous feedback and adjustment. Establishing continuous flow
is critical to fast value delivery; effective quality practices; continuous improvement; and effective,
evidence-based governance. The principles of flow, reflected in this pillar of the House of Lean, con-
stitute an important subset of the SAFe Lean-Agile Principles and are instantiated in various practices
throughout. These include understanding the full Value Stream, visualizing and limiting WIP, reducing
batch sizes and managing queue lengths, and prioritizing work based on the cost of delay. Lean also
has a primary focus on Built-in Quality, fast feedback, and the identification and constant reduction
of delays and non-value-added activities.
These constructs provide a pivotal change to a better understanding of the system development pro-
cess and provide new thinking, tools, and techniques that leaders and teams can use to move from
phase-gated processes to more continuous value delivery.
Pillar 3 – Innovation
Flow builds a solid foundation for the delivery of value, but without innovation, both product and
process will stagnate. Innovation is a critical part of the SAFe House of Lean. In support of innovation,
Lean-Agile Leaders:
• “Get out of the office” and into the actual workplace where value is produced and
products are created and used (gemba). As Taiichi Ohno put it, “No useful improvement
was ever invented at a desk.”
• Provide time and space for people to be creative. Time for innovation must be
purposeful. Innovations can rarely occur in the presence of 100% utilization and
continuous firefighting. SAFe’s Innovation and Planning Iteration is one such
opportunity.
• Apply innovation accounting [6]. Establish non-financial, non-vanity Metrics that
provide fast feedback on the important elements of the new innovation.
• Validate the innovation with Customers, then pivot without mercy or guilt when the
hypothesis needs to change
Pillar 4 – Relentless Improvement

The fourth pillar is relentless improvement. With this pillar, the organization is guided to become a
learning organization through continuous reflection and relentless improvement. A constant sense of
competitive danger drives the learning organization to aggressively pursue improvement opportunities.
Leaders and teams do the following systematically:
• Optimize the whole, not the parts, of both the organization and the development process
• Consider facts carefully, then act quickly
• Apply Lean tools and techniques to determine the root cause of inefficiencies and apply
effective countermeasures quickly
• Reflect at key Milestones to openly identify and address the shortcomings of the process
at all levels
Foundation – Leadership
The foundation of Lean is leadership, which is the ultimate enabling force for team success. Here, SAFe’s
philosophy is simple: The ultimate responsibility for adoption and success of the Lean-Agile paradigm lies
with the enterprise’s existing managers, leaders, and executives. “Such a responsibility cannot be delegated”
(Deming [7]) to Lean/Agile champions, Lean/Agile working groups, development teams, a PMO, pro-
cess teams, outside consultants, or any other party. To achieve success, leaders must be trained in these
new and innovative ways of thinking and exhibit the principles and behaviors of Lean-Agile leadership.
Lean thinking deviates from common experience with Agile, which was often introduced as a team-
based process that tended to exclude management. That does not scale. Here is a key differentiator
between traditional Agile and one of the key drivers for SAFe:
In traditional Agile, the expectation has been that management simply supports the teams and
helps eliminate impediments as they arise. In Lean-Agile development, the expectation is that
management leads the teams, embraces the values of Lean, is competent in the basic practices,
proactively eliminates impediments, and takes an active role in driving organizational change and
facilitating relentless improvement.

The Agile Manifesto
In the 1990s, in response to the many challenges of waterfall development methods, a number of
lighter-weight and more iterative development methods arose. In 2001, many of the leaders of these
methods came together in Snowbird, Utah. While there were differences of opinion on the specific
merits of one method over another, the attendees agreed that their common values and beliefs dwarfed
the differences in approach. The result was a Manifesto for Agile Software Development [8], which was
a turning point that helped unify the approach and started to bring the benefits of these innovative
methods to the industry at large. The Manifesto consists of a value statement, as exhibited in Figure 2,
and a set of principles, as exhibited in Figure 3.
The Values of the Agile Manifesto
We are uncovering better ways of developing

software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right,

we value the items on the left more.
agilemanifesto.org
Figure 2. Values of the Agile Manifesto
The Principles of the Agile Manifesto
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference for the shorter timescale.
4. Business people and developers must work together daily throughout
the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done.
6. The most efficient and effective method of conveying information to
and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence and good design
enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—
is essential.
11. The best architectures, requirements, and designs emerge from
self-organizing teams.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.
agilemanifesto.org
Figure 3. Principles of the Agile Manifesto
Along with the various Agile methods, the Manifesto provides the Agile foundation for effective,
empowered, self-organizing teams. SAFe extends this foundation to the level of teams of teams and
applies Lean thinking to understand and relentlessly improve the systems that support the teams in
their critical work.

LEARN MORE
[1] Womack, James P., Daniel T. Jones, and Daniel Roos. The Machine That Changed the World: The Story of Lean
Production—Toyota’s Secret Weapon in the Global Car Wars That Is Revolutionizing World Industry. Free Press,
2007.
[2] Ward, Allen and Durward Sobeck. Lean Product and Process Development. Lean Enterprise Institute, 2014.
[3] Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product
Development. Celeritas, 2009.
[4] Poppendieck, Mary and Tom Poppendieck. Implementing Lean Software Development: From Concept to Cash.
Addison-Wesley, 2006.
[5] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the
Enterprise. Addison-Wesley, 2011.
[6] Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically
Successful Businesses. Crown Business, 2011.
[7] Deming, W. Edwards. Out of the Crisis. MIT Center for Advanced Educational Services, 1982.
[8] Manifesto for Agile Software Development. http://agilemanifesto.org/.
SAFe Principles
The impression that “our problems are different” is a common disease that
afflicts management the world over. They are different, to be sure, but the
principles that will help to improve the quality of product and service are
universal in nature.
—W. Edwards Deming
SAFe is based on a number of immutable, underlying Lean and Agile principles. These are the fun-
damental tenets, the basic truths and economic underpinnings that drive the roles and practices that
make SAFe effective. The nine principles are:
#1-Take an economic view
#2-Apply systems thinking
#3-Assume variability; preserve options
#4-Build incrementally with fast, integrated learning cycles
#5-Base milestones on objective evaluation of working systems
#6-Visualize and limit WIP, reduce batch sizes, and manage queue lengths
#7-Apply cadence, synchronize with cross-domain planning
#8-Unlock the intrinsic motivation of knowledge workers
#9-Decentralize decision-making
SAFe Principles 35
Why the Focus on Principles?
Building enterprise-class software and cyber-physical systems is one of the most complex challenges
the industry faces today. Millions of lines of software, complex hardware and software interactions,
multiple concurrent platforms, demanding and unforgiving nonfunctional requirements—these are
just a few of the challenges systems builders face.
Of course, the enterprises that build these systems are increasingly complex, too. They are bigger and
more distributed than ever. Mergers and acquisitions, distributed multinational (and multilingual)
development, offshoring, and the rapid growth that success requires are all part of the solution—but
also part of the problem as well.
Fortunately, we have an amazing and growing body of knowledge to help us address this challenge.
These include Agile principles and methods, Lean and Systems thinking, product development flow,
Lean process and product development, and more. Many thought leaders have gone down this path
before us and left a trail to follow in the hundreds of books and references we can draw on.
SAFe’s goal is to synthesize some of this body of knowledge and the lessons learned from hundreds of
deployments into a single framework—a system of integrated, proven practices that has been demon-
strated to bring substantial improvements in employee engagement, time to market, solution quality,
and team productivity. However, given the complexity of the industry challenges already discussed,
there is truly no off-the-shelf solution to the unique challenges every enterprise faces. This means that
some tailoring and customization may be required, as not every SAFe-recommended practice will apply
equally well in every circumstance. Therefore, we always endeavor to make certain that SAFe practices
are grounded in fundamental, and reasonably immutable, principles. In that way, we can be confident
that they apply well in the general case. And when and if they don’t, the underlying principles can guide
those doing the implementation to make sure that they are moving on a continuous path to the “short-
est sustainable lead time, with best quality and value to people and society.” There is value in that too.
The nine SAFe Principles are discussed in greater detail in the next chapter.

Implementing 1-2-3
It is not enough that management commit themselves to quality and

productivity, they must know what it is they must do. Such a responsibility
cannot be delegated.
—W. Edwards Deming
Abstract
Implementing the changes necessary to become a Lean-Agile technology enterprise is a substantial
change for most organizations. Embracing a Lean-Agile Mindset, understanding and applying the
Lean-Agile principles, and effectively implementing the SAFe practices all come before the business
benefits. And, of course, the culture must evolve, too.
While SAFe is a freely revealed body of knowledge, available to all, it does not implement itself, nor
does it prescribe the organizational change management process that is typically required for successful
implementation. We leave that to the enterprise, because only they know their specific context, and
they—typically assisted by their partners—must own the transformation.
But many enterprises have gone down this path already (see the “Case Studies” articles online at www.
scaledagileframework.com), and the lessons learned are now becoming more widely accessible. Based
on the learnings from hundreds of SAFe implementations, Scaled Agile, Inc., the owner of SAFe, has
developed a basic Implementing SAFe 1-2-3 pattern for successful SAFe adoption. It provides a simple
roadmap that helps gets everyone aligned to a common implementation strategy.
This article describes an overview of this successful pattern for SAFe implementation, along with point-
ers to the growing community of service providers who are ready and willing to help your enterprise
make this critical transformation.
Details
Figure 1 on the next page provides a high-level summary of the Implementing SAFe 1-2-3 approach.
Each of the numbered items in this strategy is described in the paragraphs that follow.
Implementing 1-2-3 37
PORTFOLIO
VALUE STREAM
PROGRAM
TEAM
Figure 1. Implementing SAFe 1-2-3
1. Train Implementers and Lean-Agile Change Agents

Given the scope, challenge, and impact of rollouts, successful adoption of SAFe requires most enterprises
to use a combination of internal and external change agents, leaders, mentors, and coaches. These peo-
ple need to be skilled in teaching and delivering SAFe. To achieve this, Scaled Agile, Inc. provides an
Implementing SAFe 4.0 with SPC Certification program. After taking this class, attendees will be able to:
• Lead an enterprise Agile transformation with SAFe
• Implement SAFe
• Launch Agile Release Trains and proctor and continuously improve the trains via Inspect
and Adapt workshops
Those who take and pass the optional SPC Certification exam (included) will be licensed to:
• Train managers and executives in Leading SAFe and act as a SAFe Agilist (SA)
certifying agent
• Train practitioners in SAFe 4.0 for Teams and act as a SAFe Practitioner (SP)
certifying agent

The Implementing SAFe 4.0 with SAFe Program Consultant (SPC4) Certification course is delivered
by certified SPC Trainers (SPCT) in open enrollment or on-site settings worldwide. Service providers
who specialize in SAFe and Scaled Agile Partners can be found online at www.scaledagile.com. There
are many independent SPCs as well; these can be found at the Scaled Agile SPC membership site at
www.scaledagileacademy.com.
2. Train all Executives, Managers, and Leaders

It is critical that executives, managers, and leaders understand what is required to lead a Lean-Agile
transformation, including how and why SAFe works. To help achieve this, Scaled Agile, Inc., provides
a two-day course, Leading SAFe 4.0, Leading the Lean-Agile Enterprise with the Scaled Agile Framework.
After attending, participants will be able to:
• Adopt a Lean-Agile mindset
• Apply Lean and Agile principles; base daily decisions on this long-term philosophy;
understand, exhibit, and teach these principles
• Understand the practices, roles, activities, and artifacts of the Scaled Agile Framework
• Unlock the intrinsic motivation of knowledge workers
• Learn the practices and tools of relentless improvement and teach employees problem-
solving and corrective-action skills
• Become hands-on in the new process adoption, eliminate impediments, and facilitate
organizational change management
• Take responsibility for Lean-Agile implementation success
The audience for this class is executives, managers, and change agents responsible for leading a Lean-
Agile change initiative, whereby they gain the knowledge necessary to lead the SAFe adoption.
A certification exam is optional for this course. Those who pass the optional exam will be certified as
SAFe Agilist (SA), and will receive one year’s membership to that community and its benefits.
The Leading SAFe 4.0 course is delivered by certified SPC consultant/trainers in open enrollment or
on-site settings worldwide. Service providers include Scaled Agile, Inc.; Scaled Agile Partners; and
independent SPCs.
3. Train Teams and Launch Agile Release Trains

The primary value delivery mechanism in the enterprise is the Agile Release Train, but starting these
trains is not a trivial task. One proven starting mechanism is an Agile Release Train Quickstart.
Suitable after some significant up-front preparation, the QuickStart is a one-week training and immer-
sion program that:
• Organizes 50 – 100 team members into Agile Teams, training them simultaneously in the
principles of Lean, Agile, and SAFe
• Aligns the teams on the train to a common mission and spends two days in face-to-face
support of planning the next Program Increment
• Introduces prospective Product Owners and Scrum Masters to the skills and activities
unique to their roles in the new Agile enterprise
• Builds context and a cadence-based, rolling-wave planning and delivery model that
continuously incorporates business objective setting and program commitments,
effective and reliable program execution, and adaptive feedback
SPCs can provide these services and download and use the SAFe ART Launch Pack (member login
required) to prepare for a successful launch. It contains the tools to prepare the organization, programs,
teams, and individuals for success and continuous improvement. You may also want to consider licens-
ing the ART Training and Launch Pack Bundle. This bundle provides both the courseware and tools
needed to quickly and effectively launch Agile Release Trains.
Supporting Consulting Activities

Once the enterprise has a critical mass of in-house Lean-Agile Leaders, and a few Agile Release Trains
rolling, a variety of consulting activities may be applicable and beneficial. These could include coaching
the train, training specialist roles, and continuous improvement.
Coaching the Train

By sharing their knowledge and experience, coaches can help teams and individuals improve their
newfound skills by:
• Providing program consulting and team coaching to build the organization’s Lean-Agile
capabilities
• Facilitating Agile Release Train readiness, including Program Backlog refinement and
more
• Facilitating inspect and adapt workshops
• Facilitating Portfolio planning workshops
• Implementing relevant Metrics and governance
• Mentoring executives, managers, and other program stakeholders in SAFe adoption
• Shadowing and mentoring Release Train Engineers

Many of the these activities are supported by various Scaled Agile workshop kits, which are available
to SPCs in good standing.
Training Specialist Roles

It is important to train specialists—including prospective Product Owners and Scrum Masters—in the
principles and practices unique to their roles. Training courses for this purpose include:
• SAFe 4.0 Scrum Master Orientation – Half- to 1-day orientation to the role of a SAFe
Scrum Master
• SAFe 4.0 Product Manager / Product Owner with PMPO certification – This 2-day
certification course is for Product Managers, Business Owners, and Product Owners
who will learn how to manage and prioritize backlogs, participate in SAFe events, define
and support epics, capabilities, features, and user stories, and manage stakeholders at the
various levels of the enterprise.
• SAFe 4.0 Advanced Scrum Master with ASM Certification – This 2-day advanced,
certification course prepares current Scrum Masters for their leadership role in
facilitating Agile team, program, and enterprise success. It enhances the Scrum paradigm
with an introduction to scalable engineering and DevOps practices; the application of
Kanban to facilitate flow; supporting interactions with architects, product management,
and other critical stakeholders; and tips and techniques for building high-performing
Agile teams.
Note: The courseware offerings are always advancing, so be sure and check ScaledAgile.com for the
latest updates.
Continuous Improvement
Once the transformation is under way, there are a variety of opportunities for sustaining and enhancing
improvements in speed and quality that can be best facilitated by the extensive community of skilled
professionals. These activities can include Agile Release Train health checks; Portfolio, Value Stream,
Agile Release Train, and Team agility self-assessments; and facilitated Inspect and Adapt sessions. For
help, we again refer you to your in-house SPCs, Scaled Agile Partners, and other independent SPCs.
Guidance and Governance with Enterprise SAFe

For those who would benefit from being able to modify a custom version of the Scaled Agile Framework
website, all SAFe content is available for enterprise licensing. Organizations that are scaling Lean-Agile
best practices leverage Enterprise SAFe so they can have access to the most up-to-date content for their
teams and the thought leaders at Scaled Agile, Inc.
Enterprise SAFe allows organizations to align around common process objectives while providing the
ability to adapt SAFe to their unique needs and culture. Enterprise SAFe allows organizations to create
a custom version of the Scaled Agile Framework website while maintaining automated updates as the
methodology advances.
Fully Adaptable to Your Organization’s Context
Provisioned by Scaled Agile, Inc., and built on WordPress, Enterprise SAFe supports adaptation that
enables organizations to revise the graphical representation of the SAFe Big Picture as well as the entire
SAFe content offering. Content is controlled locally by the enterprise via a set of tools that support
accepting or rejecting framework updates from Scaled Agile, Inc., as well as adding custom content,
such as articles, icons, labels, and graphics.
Enterprise SAFe features include:

• A WordPress publishing platform that allows you to start capturing the specifics of your
custom SAFe implementation in a matter of minutes
• A customizable Big Picture in Adobe Illustrator that allows you to capture key
modifications to the framework at the front end of the website
• A PowerPoint version of all SAFe artwork that allows you to change the graphics that are
integral to the story
• Provisions to modify or extend SAFe with your custom process content
• Local control of custom content via a set of tools that allow reviewing differences
between local pages and content updates, and accepting or rejecting updates
• Administration utility for easy management of large numbers of user accounts
Enterprise SAFe is provisioned by Scaled Agile, Inc., via a private and secure cloud-based website.

Index
3Cs: Card, Conversation, Confirmation, 136–137 collaborative approach, 505–506
details, 503–509
3-level SAFe, Big Picture, 1
firm fixed-price, 503–505
4-level SAFe, Big Picture, 1 SAFe Managed-Investment Contracts, 506–509
with suppliers, 393
80/20 rule, 256–257
time and materials, 503–505
versus traditional approaches, 503–505
A
Agile Development in High-Assurance and Regulated
Acceptance Test-Driven Development (ATDD). See ATDD Environments, 352
(Acceptance Test-Driven Development).
Agile Manifesto, 31–32. See also Lean-Agile mindset; SAFe
Acceptance tests principles.
automated, 502
system-level, 498–499 Agile Release Trains (ARTs). See ARTs (Agile Release
template/checklist, 502 Trains).
Adaptive planning, 368 Agile Software Requirements, 497
Agenda for Agile Teams

iteration planning meeting, 116 abstract, 77
iteration retrospective, 131 in the Big Picture, 77–81
PI planning event, 216–218 choosing Agile practices, 79
solution demo, 381 collaborative demos, 80
SoS (Scrum of Scrums), 210 collaborative learning, 81
system demo, 235 definition, 511
team demo, 127 details, 77–78
estimating work, 80
Agile architecture integration with other teams, 80
abstract, 371 intense collaboration, 78–79
architectural runway, 371 PI planning, 80
in the Big Picture, 371–378 relentless improvement, 81
definition, 511 roles and responsibilities, 78
details, 371–378 skill requirements, 77–78
emergent design, 371 team level, 77–81
implementers, training, 38
intentional architecture, 371 Agile Testing, 497
recording models in solution intent, 376 Agile Testing Matrix, 497–499
tool for solution intent, 203
value stream level, 371–378 Alignment
core value of SAFe, 22–23
Agile architecture, basic principles definition, 22–23
architectural collaboration, 372, 373–374 development manager, 14
coding alternative approaches, 375–376 scaling, 22
emergent design, 372–373
fostering a culture of innovation, 377 All-at-once approach to NFRs, 204
implementing architectural flow, 377 Analysis stage, portfolio Kanban, 445, 446
intentional architecture, 373
keeping it simple, 375 Architectural collaboration, principle of Agile architecture,
modeling alternative approaches, 375–376 372, 373–374
responsibility for testing, 376–377 Architectural flow, implementing, 377
system size versus runway length, 374–375
Architectural runway
Agile contracts abstract, 265
abstract, 503 Agile architecture, 371
in the Big Picture, 503–509 in the Big Picture, 265–270
INDEX 529
creating, 267–269 Assuming variability (SAFe Principle #3)
definition, 511 in the Big Picture, 55–56
destruction over time, 269 overview, 55–56
details, 265–270 solution intent, 353
emergent design, 265–266
ATDD (Acceptance Test-Driven Development). See also
extending, 266–267, 270
Test-first methods.
intentional architecture, 266
in the Agile Testing Matrix, 500
potential problems, 266
definition, 149
program level, 265–270
PO (Product Owner) support for, 84
source of the metaphor, 270
test-first methods, 500
system size versus runway length, 374–375
Autonomy, motivating knowledge workers
Architecture enablers, 245, 246
(SAFe Principle #8), 68
ARTs (Agile Release Trains)
Average lead time, Kanban, 101–102
abstract, 159
in the Big Picture, 159–165
Business Owners, 161 B
CI (continuous integration), 492 Backlog refinement. See also Team backlog.
coaching, 40 PO (Product Owner), 84
component teams, 164–165 program backlogs, 194
definition, 2, 511 role of PO (Product Owner), 84
details, 159–165 team backlog, 107–108
DevOps, 161 value stream backlogs, 194
feature teams, 164–165 value stream Kanban, 191
key concepts, 160
key roles, 161 Backlogs
launching, 39–40 creating improvement backlog items, 257–258
local versus global optimization, 160 Little’s Law, 197
mixing with traditional methods, 158 NFRs as backlog constraints, 201–202
operating principles, 160–161 portfolio level, 449–452
PM (Product Management), 161 team level, 105–108
program level, 159–165 Backlogs, portfolio level
RTE (Release Train Engineer), 161 in the Big Picture, 449–452
Self Assessment, 318–319 definition, 516
self-managing, 433
Shared Services, 161 Backlogs, program level
steering. See RTE (Release Train Engineer); VSE abstract, 193
(Value Stream Engineer). in the Big Picture, 193–197
System Architects/Engineers, 161 capacity allocation, 195–196
System Team, 161 definition, 516
teams on the train, 164–165 details, 193–197
UX designers, 161 Little’s Law, 197
PI planning, 195
ARTs (Agile Release Trains), for value streams prioritizing, 194
coordinating, 481 program backlogs, 193–197
multi-ART value streams, 480 queues, 197
multiple value stream ARTs, 478–479 refining, 194
single value stream ARTs, 479–480 solution integrity, optimizing, 195–196
ARTs (Agile Release Trains), organizing value, optimizing, 195–196
around capabilities, 163–164 value stream backlogs, 193–197
around subsystems, 163–164 wait times, 197
effective train size, 162 Backlogs, team level
factors to consider, 162–165 abstract, 105
teams on the train, 164–165 in the Big Picture, 105–108
value stream size, 162–163 capacity allocation, 107
value streams, splitting, 163–165 definition, 520
Assigning business value, Business Owners, 223 details, 105–108
refinement, 107–108
530 INDEX
specification workshops, 108 innovation and planning iteration, 249–252
system health, optimizing, 107 introduction, 155–158
value delivery, optimizing, 107 NFRs (nonfunctional requirements), 199–206
PI (Program Increment), 207–212
Backlogs, value stream level
PI objectives, 225–231
abstract, 193
PI planning, 213–220
Product Management, 177–181
capacity allocation, 195–196
program backlogs, 193–197
definition, 516, 521
program Kanban, 187–191
details, 193–197
RTE (Release Train Engineer), 167–170
Little’s Law, 197
Solution Architect/Engineering, 171–175
PI planning, 195
Solution Management, 177–181
pre- and post-PI planning meetings, 386
System Architect/Engineering, 171–175
prioritizing, 194
system demo, 233–236
queues, 197
value stream backlogs, 193–197
refining, 194
value stream Kanban, 187–191
solution integrity, optimizing, 195–196
VSE (Value Stream Engineer), 167–170
value, optimizing, 195–196
web address, 153
wait times, 197
WSJF (Weighted Shortest Job First), 183–186
Batch sizes, reducing. See Reduce batch sizes
Big Picture, SAFe foundation
(SAFe Principle #6).
3-level SAFe, 1
Beck, Kent, 375 4-level SAFe, 1
CoPs (Communities of Practice), 17–19
Beyond Entrepreneurship, 420
core values, 21–25
Beyond project cost accounting, 454–461 definition, 1
House of Lean, 27, 28–30
Big Picture, guidance
Implementing 1-2-3, 37–42
Agile contracts, 503–509
Lean-Agile Leaders, 11–15
CI (continuous integration), 491–496
Lean-Agile mindset, 27–32
test-first methods, 497–502
portfolio level, 7
web address, 489
program level, 4
Big Picture, portfolio level spanning palette, 5
budgets, 453–461 team level, 3
CapEx (capital expense), 463–471 web address, 1
enterprise, 417–422
Big Picture, SAFe principles
Enterprise Architect, 439–442
assuming variability (Principle #3), 55–56
Epic Owners, 435–437
cadence (Principle #7), 63–65
epics, 483–488
cross-domain planning (Principle #7), 63–65
illustration, 7
decentralizing decision-making (Principle #9), 71–72
introduction, 413–415
economic view (Principle #1), 45–49
OpEx (operational expense), 463–471
incremental build (Principle #4), 57–58
portfolio backlog, 449–452
integrated learning cycles (Principle #4), 57–58
portfolio Kanban, 443–447
managing queue lengths (Principle #6), 61–62
PPM (Program Portfolio Management), 429–434
motivating knowledge workers (Principle #8), 67–69
strategic themes, 423–427
objective milestones (Principle #5), 59–60
value streams, 473–482
preserving options (Principle #3), 55–56
web address, 411
reduce batch sizes (Principle #6), 61–62
Big Picture, program level synchronization (Principle #7), 63–65
architectural runway, 265–270 systems thinking (Principle #2), 51–53
ART (Agile Release Train), 159–165 visualize and limit WIP (Principle #6), 61–62
Business Owners, 221–224 web address, 43
capabilities, 237–242
Big Picture, spanning palette
develop on cadence, release any time, 259–264
DevOps, 273–278
enablers, 243–247
illustration, 5
features, 237–242
metrics, 307–321
I&A (inspect and adapt), 253–258
milestones, 323–329
illustration, 4
Release Management, 283–285
INDEX 531
releases, 331–336 The Lean Startup, 420
roadmaps, 301–306 “Mixing Agile and Waterfall Development,” 158, 391
Shared Services, 287–289 The Principle of Continuous Economic Trade-Offs, 49
System Team, 279–282 The Principle of Optimum Decision Making, 49
UX (User Experience), 291–294 The Principle of Quantified Cost of Delay, 49
Vision, 295–300 Release Planning Readiness Checklist, 215
web address, 271 The Sunk Cost Principle, 49
Technical Strategies for Agile and Waterfall
Big Picture, team level
Interoperability at Scale,” 391
Agile Teams, 77–81
built-in quality, 147–152 Bounded NFRs, 203
demos, 125–127
Box, George E. P., 359
illustration, 3
introduction, 75–76 Brainstorming, I&A (inspect and adapt) workshop, 257
iteration execution, 119–124
Budgets
iteration goals, 143–145
definition, 511
iteration planning, 113–117
enterprise, 418, 421
iteration retrospective, 129–131
Lean-Agile budgeting, 348, 432
iterations, 109–111
portfolio level, 453–461
Product Owners, 83–87
PPM (Program Portfolio Management), 432
Scrum Master, 89–91
for value streams, portfolio level, 477–478
ScrumXP teams, 93–97
solution demo, 125 Budgets, portfolio level
stories, 133–141 abstract, 453
system demo, 125 approving epic level initiatives, 460
team backlog, 105–108 beyond project cost accounting, 454–461
team demo, 125–127 in the Big Picture, 453–461
team Kanban, 99–104 cost-center budgeting, problems with, 455–456
web address, 73 details, 453–461
effects of delays, 457
Big Picture, value stream level
empowering value stream content authority, 459–460
abstract, 339
fiscal governance with dynamic budgeting, 461
Agile architecture, 371–378
funding value streams, not projects, 458–459
Customers, 395–399
Lean-Agile Budgeting: Beyond Project Cost Accounting,
details, 339–343
454–455
economic framework, 347–349
problems of traditional cost accounting, 455–457
illustration, 6
project-based constraints, 456–457
introduction, 339–343
providing objective evidence of fitness for purpose, 460.
MBSE (Model-Based Systems Engineering), 359–364
See also Objective milestones (SAFe Principle #5).
pre- and post-PI planning, 383–388
Set-Based Design, 365–369 Built-in quality, core value of SAFe
solution context, 405–409 abstract, 147
solution demo, 379–382 in the Big Picture, 147–152
solution intent, 351–358 business benefits, 148
solutions, 401–404 CI (continuous integration), 148–149, 152
suppliers, 389–394 collective ownership, 150–151
value stream coordination, 343–346 definition, 23, 511
web address, 337 design verification, 152
details, 147–152
Big visual information radiators (BVIRs), 95
development manager, 14
Books and publications firmware, 151–152
Agile Development in High-Assurance and Regulated hardware, 24, 151–152
Environments, 352 iteration execution, 122
Agile Software Requirements, 497 MBSE (Model-Based Systems Engineering), 362
Agile Testing, 497 pair programming, 150
Beyond Entrepreneurship, 420 pair work, 150
Beyond Project Cost Accounting, 414 refactoring, 150
The First Decision Rule Principle, 49. See also scaling crappy code/components, 23–24
Decentralizing decision-making (SAFe Principle #9). software, 23, 148–151
532 INDEX
system integration, 24 CapEx (capital expense), portfolio level
team level, 147–152 abstract, 463–464
Agile development capitalization strategies, 467–468
Business benefits, pre- and post-PI planning meetings, 384
allowable labor efforts, 470–471
Business context, pre- and post-PI planning meetings, 385 applying stories, 468–470
Business drivers, enterprise, 421
capitalization triggers in waterfall development,
Business epics. See Epics. 466–467
capitalization versus expense criteria, 465–466
Business objectives. See Strategic themes.
capturing labor effort, 469
Business Owners categorization of features, 468
abstract, 221 details, 463–471
ART (Agile Release Train), 161 FASB (Financial Accounting Standards Board), 465
assigning business value, 223 FASB 86 guidelines, 465
in the Big Picture, 221–224 portfolio level, 463–471
definition, 512 software classification, 465
details, 221–224 software development costs, 465
at I&A (inspect and adapt) workshop, 223–224 by story count, 470
importance of, 224 by story hours, 469
during PI execution, 223–224 by story points, 469–470
during PI planning, 222
Capitalization. See also CapEx (capital expense), portfolio
prior to PI planning, 222
level.
roles and responsibilities, 221–224
versus expense criteria, 465–466
Business value, assigning triggers in waterfall development, 466–467
to PI objectives, 229–230
Card aspect of stories, 136
role of Business Owners, 223
Case Studies articles, website, 37
BVIRs (big visual information radiators), 95
Categorization of features for CapEx, 468
C CFD (cumulative flow diagram), 101–102, 318
Cadence (SAFe Principle #7) CI (continuous integration)
in the Big Picture, 63–65 abstract, 491
objective milestones (SAFe Principle #5), 60 ART integration, 492
overview, 63 in the Big Picture, 491–496
value stream coordination, 344–345 built-in quality, 148–149, 152
Cadence-based integration points, 58 challenges, 494–495
common cadence, 495
Calendars, sample IP iteration calendar, 251–252 component level, 491–492
Capabilities definition, 512
abstract, 237 deprecated tests, 494
in the Big Picture, 237–242 designing for testability, 496
definition, 237, 512 details, 491–496
details, 237–242 emulated environments, 495
enablers, 244 enabling, 495–496
program level, 237–242 feature level, 491–492
splitting into features, 241–242 implementing a culture of, 496
value stream, 240–241 infrastructure, 495
integration frequency, 494
Capacity allocation mocks, 495
program backlogs, 195–196 regression tests, 494
team backlog, 107 solution context synchronization, 493–494
value stream backlogs, 195–196 solution integration, 492–494
Capacity ARTs, 163–164 stubs, 495
supplier synchronization, 493–494
CapEx (capital expense), definition, 512 supporting the System Team, 496
trade-offs, 494–495
INDEX 533
Classes of service, 102–103 CoPs (Communities of Practice)
abstract, 17
Coaching the ART (Agile Release Train), 40
Big Picture, 17–19
Coding alternative approaches, principle of Agile decentralizing decision-making (SAFe Principle #9), 19
architecture, 375–376 definition, 2, 512
details, 17–19
Collaborating on solution intent, 354–355
Guild Coordinator. See SM (Scrum Master).
Collaborating with suppliers, 392–393 horizontal line-of-business organization, 17
operating, 18–19
Collaboration, in solution context, 408–409
organizing, 18
Collaborative demos, Agile Teams, 80 Scrum Master, 18–19
Collaborative learning, Agile Teams, 81 Core values, enterprise, 421
Collective ownership, built-in quality, 150–151 Core values of SAFe
abstract, 21
Collins, James, 420
alignment, 22–23
Communities of Practice (CoPs). See CoPs (Communities in the Big Picture, 22
of Practice). definition, 21
details, 21–25
Compensation, motivating knowledge workers (SAFe
list of, 2, 21. See also specific values.
Principle #8), 67
program execution, 25
Competitive environment, 421 transparency, enabling trust, 24–25
Compliance, MBSE (Model-Based Systems Engineering), Core values of SAFe, built-in quality
360–361, 362 abstract, 147
Component level, CI (continuous integration), 491–492
business benefits, 148
Component tests, 498, 500 CI (continuous integration), 148–149, 152
collective ownership, 150–151
Confidence vote, pre- and post-PI planning meetings, 387 definition, 23, 511
Confirmation aspect of stories, 137 design verification, 152
details, 147–152
Constant communication, iteration execution, 121 development manager, 14
Consulting activities, 40–41 firmware, 151–152
hardware, 24, 151–152
Content authority, PO (Product Owner), 85–86 iteration execution, 122
Content management pair programming, 150
a Lean-Agile approach, 177–178 pair work, 150
at the program level, 156 refactoring, 150
value stream coordination, 345–346 scaling crappy code/components, 23–24
software, 23, 148–151
Content readiness, PI planning event, 215 system integration, 24
Continuous delivery, 46–47, 262 Cost accounting, traditional problems of, 455–457.
Continuous improvement. See Kanban; Relentless See also Budgets.
improvement. Cost of delay
Continuous integration (CI). See CI (continuous calculating, 184–185
integration). primary elements of, 184
risk reduction-opportunity enablement value, 184
Continuous learning, innovation and planning iteration, time criticality, 184
251 user-business value, 184
Continuous management information, iteration goals, 146 Cost-center budgeting. problems with, 455–456
Continuous value flow, PPM (Program Portfolio Cross-ART enablers, 246–247
Management), 432
Cross-domain planning, synchronization, 63–65
Contracts, Agile. See Agile contracts.
Cross-value stream enablers, 246–247
Conversation aspect of stories, 136–137
Culture of CI (continuous integration), implementing, 496
Coordination. See Value stream coordination.
534 INDEX
Culture of innovation, principle of Agile architecture, 377 Designing for testability, CI (continuous integration), 496
Cumulative flow diagram (CFD), 101–102, 318 Designs, solution intent, 352–353
Customer context for solutions, 403 Develop on cadence, definition, 512
Customers Develop on cadence, release any time
abstract, 395 abstract, 259–264
custom solutions, 398–399 continuous delivery, 262
definition, 512 details, 259–264
details, 395–399 PI (Program Increment), 208
engagement, 397–399 program level, 259–264
general solutions, 398 releases, 263–264, 332
internal versus external, 396–397 separating development concerns from release, 262–263
responsibilities, 396 synchronization, 259–261
value stream level, 395–399
Developing, solution intent, 354–355
D Development environments, DevOps, 276
Decentralized, rolling-wave planning, 433 Development infrastructure, building, 280
Decentralizing decision-making (SAFe Principle #9) Development infrastructure strategy, Enterprise

in the Big Picture, 71–72 Architects, 441
CoPs (Communities of Practice), 19 Development manager
economic framework, 348, 349 alignment, 14
suppliers, 391–392 built-in quality, 14
System Architect/Engineering, 174 overview, 13
Decision-making personnel and team development, 13–14
decentralizing. See Decentralizing decision-making program execution, 14
(SAFe Principle #9). responsibilities, 13
strategic decisions, 71 transparency, 14
Decision-making framework, 71–72 Development value streams, 474–475, 477, 478–480
Delays, effects on budgets, 457 DevOps. See also Deployment.
Delivering early and often, economic view (SAFe Principle abstract, 273
#1), 46–47 ART (Agile Release Train), 161
automatically building environments, 277
Demand management, PPM (Program Portfolio automating the deployment process, 277
Management), 432 in the Big Picture, 273–278
Deming, W. Edwards, 51, 393–394 definition, 513
deployability, 276, 277–278
Demos. See also Solution demos; System demos. deployment frequency, 276
in the Big Picture, 125–127 deployment readiness, 276
of solutions, 403 details, 273–278
team level, 125–127 development and test environments, 276
Dependencies, managing, 145 importance to the value stream, 273–274
Internet of Things, 274
Deployability, 276, 408–409 Murphy’s Law, 275
Deployment. See also DevOps. in a production-equivalent staging environment,
automating, 277 275–276
frequency, 276 recommended practices, 275–278
readiness, 276 solution architecture, 277–278
value stream coordination, 346 spanning palette, 273–278
on the train, 274
Deployment infrastructure strategy, Enterprise Architects, typical team members, 274
441 version control, 277
Deprecated tests, CI (continuous integration), 494 Distinctive competence, 421–422
Design verification, built-in quality, 152 Distributed, governed UX development, 294
INDEX 535
Documentation Enabler work, scope of, 85
MBSE (Model-Based Systems Engineering), 362, 364
Enablers
solution intent, 357–358
abstract, 243
Done stage, portfolio Kanban, 445, 447 for architecture, 245, 246
Drive, motivating knowledge workers
capabilities, 244, 513
(SAFe Principle #8), 68
creating and managing, 244
Drucker, Peter F., 67–68 cross-ART, 246–247
cross-value stream, 246–247
DSU (daily stand-up) meeting, 95, 121
definition, 513
details, 243–247
E epics, 244, 513
Early and continuous delivery, economic view for exploration, 245
(SAFe Principle #1), 46–47 extending the architectural runway, 266–267
features, 244, 513
Ease of use. See UX (User Experience) design. for infrastructure, 245–246
Economic decisions, principles for, 49, 195 program level, 243–247
of solutions, 402
Economic efficiency, Set-Based Design, 366–368 stories, 135–136, 244, 513. See also Stories.
Economic framework. See also Economic view (SAFe types of, 244
Principle #1). uses for, 245–246
abstract, 347 Enterprise
in the Big Picture, 347–349 abstract, 417–418
decentralized decision-making, 348, 349 in the Big Picture, 417–422
definition, 513 budget, 418, 421
details, 347–349 business drivers, 421
epic funding and governance, 348 competitive environment, 421
job sequencing based on cost of delay, 348, 349 connecting to a portfolio, 418
Lean-Agile budgeting, 348 core values, 421
strategic themes, 425 decentralizing execution, 422. See also Decentralizing
value stream level, 347–349 decision-making (SAFe Principle #9).
Economic trade-off parameters, economic view definition, 513
(SAFe Principle #1), 47–49 details, 417–422
distinctive competence, 421–422
Economic trade-offs, Set-Based Design, 368–369 financial goals, 421
Economic view (SAFe Principle #1). See also Economic KPIs (key performance indicators), 420
framework. mission, 421
abstract, 45 multiple SAFe instances, 419–420
in the Big Picture, 45–49 portfolio context, 418, 420–422
delivering early and often, 46–47 portfolio level, 417–422
details, 45–49 portfolio strategy, 420–421
early and continuous delivery, 46–47 qualitative data, 420
economic trade-off parameters, 47–49 sample portfolio, 418–419
optimizing life cycle profits, 48–49 strategic themes, 418
waterfall method, 47 as a system, 52
80/20 rule, 256–257 vision, 421
Emergent design Enterprise Architect, portfolio level, 439–442

Agile architecture, 371 Enterprise Architects
architectural runway, 265–266 abstract, 439
principle of Agile architecture, 372–373 architectural strategy, 440–442
Empirical approach to System Architect/Engineering, in the Big Picture, 439–442
174–175 choice of technology, 441
definition, 513
Emulated environments, 495 deployment infrastructure strategy, 441
details, 439–442
536 INDEX
development infrastructure strategy, 441 Estimating poker, 138–140
gemba, 442
Estimating workload
implementation strategy, 442
Agile Teams, 80
interprogram collaboration, 441–442
common starting point for estimation, 104
establishing velocity, 114
Kanban teams, 103–104
working with System/Solution Architects, 441
relative estimating, 116–117
Enterprise architecture, value stream coordination, stories. See Stories, estimating.
345–346
Evolving solution context, 406
Enterprise Balanced Scorecard, 311–312
Executable MBSE models, 363
Enterprise SAFe, 41–42
Executives, training, 39
Environment of mutual interest, motivating knowledge
Expedite service class, 102–103
workers (SAFe Principle #8), 68–69
Exploration enablers, 245
Epic Burn-up Chart, 309
Extending architectural runways, 266–267, 270
Epic Owners
abstract, 435
in the Big Picture, 435–437 F
collaborative nature of, 437 FAB (features and benefits) matrix, 238–239
definition, 514
details, 435–437 Fan-out model for PO, PM, and Agile Teams, 86
portfolio level, 435–437 FASB (Financial Accounting Standards Board), 465
FASB 86 guidelines, 465
Epic Progress Measure, 310
Feature enablers, 244
Epic specification workshop, 191
Feature level CI (continuous integration), 491–492
Epic Success Criteria, 310–311
Feature Progress Report, 314–315
Epic Value Statement Template, 484
Feature section, program Kanban, 190
Epics
abstract, 483 Feature selection, program Kanban, 190
analysis, 484–485 Features
approving investment in, 488 abstract, 237
in the Big Picture, 483–488 accepting, 240
definition, 514 in the Big Picture, 237–242
details, 483–488 creating and managing, 239
enablers, 244, 513 definition, 237, 514
Epic Value Statement Template, 484 details, 237–242
funding and governance, economic framework, 348 estimating, 240
measuring progress, 486 FAB (features and benefits) matrix, 238–239
metrics for, 309–311 versus objectives, PI objectives, 227–228
portfolio Kanban, 444–445 prioritizing, 239
portfolio level, 483–488 program level, 237–242
PPM (Program Portfolio Management), 432 splitting capabilities into, 241–242
program, 488, 516
splitting, 486–487 Feedback, balancing with integration effort, 235
success criteria, 486 Feedback, eliciting, 130
value stream, 488, 521
Financial Accounting Standards Board (FASB), 465
Estimating
Agile method, 433 Financial goals, enterprise, 421
features, 240 Firm fixed-price contracts, 503–505
leveraging the estimation buffer, 251–252
portfolio backlog, 451–452 Firmware, built-in quality, 151–152
PPM (Program Portfolio Management), 433 The First Decision Rule Principle, 49
relative, 116–117
INDEX 537
Fishbone diagrams, 256 House of Lean, 27, 28–30
Fitness for purpose, providing objective evidence for, 460. Human factors. See UX (User Experience) design.
See also Objective milestones (SAFe Principle #5).
Five Whys technique, 256 I
Fixed date service class, 102–103 I&A (inspect and adapt) workshop. See also Relentless
improvement.
Fixed solution context, 406 abstract, 253
Fixed solution intent, 354, 355–356 agreeing on problems, 255–256
Fixed-date milestones, 327–328 brainstorming, 257
Fixed-schedule programs, Set-Based Design, 366 Business Owners, 223–224
creating improvement backlog items, 257–258
Flow definition, 514
architectural, implementing, 377 details, 253–258
CFD (cumulative flow diagram), 101–102, 318 PI (Program Increment), 211
continuous value, PPM (Program Portfolio PI system demo, 254
Management), 432 problem-solving workshop, 255
improving, iteration execution, 121–122 program level, 253–258
improving with Kanban, 102–103 Program Predictability Measure, 254
measuring with Kanban, 101–102 quantitative measurement, 254
primary keys to, 61. See also specific keys. restating problems, 257
Principles of Product Development Flow, 259–261 retrospective, 255
visualizing with Kanban, 100–101 root cause analysis, 256–257
workflow management, program level, 156 at the value stream level, 258
Forecasting workshop, 85
portfolio backlog, 451–452 Impact analysis, MBSE (Model-Based Systems
with roadmaps, 303 Engineering), 360–361
Foundation layer, 2–3. See also Big Picture, SAFe Implementation stage, portfolio Kanban, 445, 446–447
foundation.
Implementation strategy, Enterprise Architects, 442
4-level SAFe, Big Picture, 1
Implementing 1-2-3. See also Training.
Frequency of releases, 331–332 abstract, 37–38
Frequent integration points, Set-Based Design, 367 in the Big Picture, 37–42
continuous improvement, 41
Functional tests, test-first methods, 498, 501 definition, 514
Funnel stage, portfolio Kanban, 444, 445 details, 37–42
Enterprise SAFe, 41–42
pattern description, 3
G
training, 3
Gemba (visiting the workplace), 29, 392, 442
Implementing architectural flow, principle of Agile
Genchi genbutsu, 392 architecture, 377
Go and see. See Gemba (visiting the workplace). Implementing SAFe 4.0 with SPC Certification, 38
Goals, for sprints. See Iteration goals. In the Big Picture, web address, 271
Governance, PPM (Program Portfolio Management), Incremental build (SAFe Principle #4)
433–434 in the Big Picture, 57–58
cadence-based integration points, 58
Greenleaf, Robert, 169
integration points, creating, 57–58
overview, 57–58
H
Independent, Negotiable, Valuable, Estimable, Small,
Hardware, built-in quality, 24, 151–152 Testable (INVEST), 137
Honda, collaborating with suppliers, 392 Independent NFRs, 203
Horizontal line-of-business organization, 17 Infrastructure, CI (continuous integration), 495
538 INDEX
Infrastructure enablers, 245–246 DSU (daily stand-up) meeting, 121
improving flow, 121–122
Innovation and planning iteration
intra-iteration waterfalls, 122–123
abstract, 249
key elements of, 120
advance development infrastructure, 251
managing WIP, 121–122
PO (Product Owner), 84–85
definition, 514
program execution, 124
details, 249–252
purpose of, 119–120
enabling continuous learning, 251
team level, 119–124
integrating a complete solution, 250–251
test automation, 122
leveraging the estimation buffer, 251–252
tracking progress, 120–121
visualizing progress, 120–121
sample IP iteration calendar, 251–252
time for innovation, 250 Iteration goals
time for PI events, 250 abstract, 143
aligning program teams to common PI objectives, 145
Inspect and adapt (I&A) workshop. See I&A (inspect
aligning team members to a common purpose, 145
and adapt) workshop.
Integrated learning cycles (SAFe Principle #4) continuous management information, 146
in the Big Picture, 57–58 definition, 514
faster learning through faster cycles, 58 details, 143–146
integrated learning cycles, 60 importance of, 144–145
PDCA (Plan-Do-Check-Adjust) cycle, 58 managing dependencies, 145
slipping integration points, 58 outputs of, 143–144
Integration, solutions, 403
Iteration Metrics, 319
Integration frequency, CI (continuous integration), 494
Iteration planning
Integration points
abstract, 113
cadence-based, 58
attendees, 115
creating, 57–58
indication of a troubled project, 58
commitment, 115
slipping, 58
definition, 514–515
Integration with other teams, Agile Teams, 80 details, 113–117
establishing velocity, 114
Intense collaboration, Agile Teams, 78–79
guidelines, 116
Intentional architecture, 266, 371, 373 innovation and planning iteration, 514
inputs to, 114
Interactive view of SAFe. See Big Picture.
iteration goals, 115
Interfaces, specifying, 367 normalizing story point estimating, 116–117
PO (Product Owner), 84
Internet of Things, DevOps, 274
purpose of, 113–114
Interprogram collaboration, Enterprise Architects, relative estimating, 116–117
441–442 sample agenda, 116
story analysis and estimation, 115
INVEST (Independent, Negotiable, Valuable, Estimable,
task analysis, 115
Small, Testable), 137
Ishikawa diagrams, 256
Iteration retrospective
IT deployment environments, solution context, 407–408 abstract, 129
agenda, 131
Iteration execution. See also Program execution. in the Big Picture, 129–131
abstract, 119 definition, 515
in the Big Picture, 119–124 details, 129–131
building stories, serially and incrementally, 122–124 eliciting feedback, 130
built-in quality, 122 guidelines, 131
constant communication, 121 PO (Product Owner), 85
continuous story acceptance, 122 qualitative review, 130
definition, 514 quantitative review, 129–130
details, 119–124
INDEX 539
team level, 129–131 Leading SAFe 4.0, Leading the Lean-Agile Enterprise with
the Scaled Agile Framework, 39
Iterations. See also PDCA cycles.
abstract, 109 Lean Portfolio Metrics, 307–308
adjusting, 111
The Lean Startup, 420
checking, 111 Lean-Agile approach to System Architect/Engineering,
definition, 515 173–175
details, 109–111
Lean-Agile budgeting, economic framework, 348
executing, 110
PDCA cycle, 109–111 Lean-Agile Budgeting: Beyond Project Cost Accounting,
planning, 110 454–455
Lean-Agile change agents, training, 38, 39
J Lean-Agile Leaders. See also specific leaders.

abstract, 11
Jeffries, Ron, 136 in the Big Picture, 11–15
Job duration, WSJF (Weighted Shortest Job First), 185–186 definition, 2, 515
details, 11–15
Job sequencing based on cost of delay, economic frame- philosophy of SAFe, 11
work, 348, 349 in System Architect/Engineering, 174
Job size as a proxy for duration, WSJF (Weighted Shortest traits of, 174
Job First), 186 Lean-Agile Leaders, desirable behaviors
Just-in-time story elaboration, PO (Product Owner), 84 decentralized decision-making, 12
developing people, 12
emphasizing lifelong learning, 12
K leading change, 11
Kanban. See also Team Kanban. minimizing constraints, 12
average lead time, 101–102 motivating knowledge workers, 12
CFDs (Cumulative Flow Diagrams), 101–102 Lean-Agile mindset. See also Agile Manifesto.
classes of service, 102–103 abstract, 27
description, 100 Big Picture, 27–32
improving flow, 102–103 definition, 515
measuring flow, 101–102 details, 27–33
Portfolio Kanban Board, 308–309 foundation of, 30
program, 517 leadership philosophy, 30
Program Kanban Board, 315 training leaders in, 3
as a pull system, 99
swim lanes, 102–103 Lean-Agile mindset, House of Lean
Team Kanban Board, 320 definition, 27
throughput, 101–102 flow, 29
Value Stream Kanban Board, 313 four pillars, 28–30
visualizing flow, 100–101 goal, 28
WIP limits, 100–101 innovation, 29–30
relentless improvement, 30, 81
Kettering, Charles, 255 respect for people and culture, 28–29
KPIs (key performance indicators) Lean-Agile practices, suppliers, 390
enterprise, 420
PPM (Program Portfolio Management), 433 Learning cycles, MBSE models, 360
Learning milestones, 326–327
L
Licensing, 38
Labor efforts, as CapEx (capital expense), 469–471
Life-cycle governance, PPM (Program Portfolio
Lazier, William, 420 Management), 433–434
Leaders, training, 39 Lightweight business cases, PPM (Program Portfolio
Management), 432
540 INDEX
Little’s Law Portfolio Metrics, 307–308
program backlogs, 197 for portfolios, 307–312
queue length, 62 Program Kanban Board, 315
value stream backlogs, 197 Program Performance Metrics, 316–317
Program Predictability Measure, 316
M for programs, 314–319
SAFe Team Self-Assessment, 321
Management, role in changing systems, 52–53 spanning palette, 307–321
Managers, training, 39 Team Kanban Board, 320
Team PI Performance Report, 320–321
Managing queue lengths (SAFe Principle #6) for teams, 319–321
in the Big Picture, 61–62 Value Stream Kanban Board, 313
flow limit, 62 Value Stream Performance Metrics, 314
Little’s Law, 62 Value Stream Predictability Measure, 313–314
queue length versus wait time, 62 for value streams, 313–314
Man-machine interface. See UX (User Experience) design. Milestones. See also Metrics.
Marick, Brian, 497 abstract, 323
MBSE (Model-Based Systems Engineering) definition, 515
in the Big Picture, 359–364 fixed-date, 327–328
built-in quality, 362 learning, 326–327
compliance, 360–361, 362 measuring success, 328–329
definition, 515 object measurement. See Objective milestones (SAFe
details, 359–364 Principle #5).
documentation, 362, 364 phase-gate (waterfall), 59–60, 324
executable models, 363 PI (Program Increment), 325–326
impact analysis, 360–361 planning and executing, 328
model standards, 362–363 spanning palette, 323–329
models and learning cycles, 360
recording models in solution intent, 361–362 Minimal constraints, motivating knowledge workers
testable models, 363 (SAFe Principle #8), 68
tool for solution intent, 203 Mission
traceability, 360–361 enterprise, 421
value stream level, 359–364 motivating knowledge workers (SAFe Principle #8), 68
Measurements. See Metrics; Milestones. “Mixing Agile and Waterfall Development,” 158, 391
Metrics. See also Milestones. Mocks, 495
abstract, 307
ART Self-Assessment, 318–319 Model-Based Systems Engineering (MBSE). See MBSE
in the Big Picture, 307–321 (Model-Based Systems Engineering).
CFD (cumulative flow diagram), 318 Modeling, Set-Based Design, 367
definition, 515
details, 307–321 Modeling alternative approaches, principle of Agile archi-
Enterprise Balanced Scorecard, 311–312 tecture, 375–376
Epic Burn-up Chart, 309 Models, MBSE
Epic Progress Measure, 310 and learning cycles, 360
Epic Success Criteria, 310–311 recording in solution intent, 361–362
for epics, 309–311 standards, 362–363
Feature Progress Report, 314–315 testable, 363
Iteration Metrics, 319 traceability, 360–361
Lean Portfolio Metrics, 307–308
measuring epic progress, 486 Moore, Geoffrey, 420
measuring progress against strategic themes, 426–427 Motivating knowledge workers (SAFe Principle #8)
objective milestones (SAFe Principle #5), 60 autonomy, 68
PI Burn-down Chart, 317–318 in the Big Picture, 67–69
Portfolio Kanban Board, 308–309
INDEX 541
decision-making framework. See Decentralizing Objectives versus features, PI objectives, 227–228
decision-making (SAFe Principle #9).
Ohno, Taiichi, 29
drive, 68
Drucker on, 67 Online resources. See Web addresses; Websites.
environment of mutual interest, 68–69
Oosterwal, Dantar P., 324
leveraging the systems view, 67
minimal constraints, 68 Operating CoPs (Communities of Practice), 18–19
mission, 68
Operational value streams, 474–475
purpose, 68
the role of compensation, 67 OpEx (operational expense), definition, 512
Multi-ART value streams, 211, 219–220, 480 OpEx (operational expense), portfolio level, 463–471
abstract, 463–464
Multiple value stream ARTs, 478–479
Murphy’s Law, DevOps, 275 allowable labor efforts, 470–471
applying stories, 468–470
N in the Big Picture, 463–471
capitalization triggers in waterfall development,
Negotiable NFRs, 203 466–467
NFRs (nonfunctional requirements) capitalization versus expense criteria, 465–466
abstract, 199 capturing labor effort, 469
all-at-once approach, 204 categorization of features, 468
as backlog constraints, 201–202 details, 463–471
in the Big Picture, 199–206 FASB (Financial Accounting Standards Board), 465
bounded, 203 FASB 86 guidelines, 465
criteria for, 203 portfolio level, 463–471
definition, 515 software classification, 465
details, 199–206 software development costs, 465
economic impacts of, 202 by story count, 470
fitness for use, 199–200 by story hours, 469
FURPS (Functionality, Usability, Reliability, by story points, 469–470
Performance, Supportability), 199–200 Optimizing life cycle profits, economic view (SAFe
implementation approaches, 203–204 Principle #1), 48–49
independent, 203
negotiable, 203 Organizing CoPs (Communities of Practice), 18
program level, 199–206 Overview of SAFe, interactive. See Big Picture.
at SAFe levels, 200–201
solution intent, 202–203
P
and solutions, 402
specifying, 203 Pair programming, built-in quality, 150
story-by-story approach, 204
Pair work, built-in quality, 150
system qualities tests, 499
systemic impacts of, 202 Pareto Analysis, 256–257
testable, 203
PDCA (Plan-Do-Check-Adjust) cycles. See also PI
testing, 204–206, 499
(Program Increment).
tools for solution intent, 203
adjusting the next iteration, 111
checking iterations, 111
O executing iterations, 110
Objective milestones (SAFe Principle #5) factor in faster learning, 58
in the Big Picture, 59–60 in iterations, 109–111
cadence (SAFe Principle #7), 60 planning iterations, 110. See also Innovation and plan-
incremental build, integrated learning cycles (SAFe ning iteration.
Principle #4), 60 Personnel and team development, development manager,
measurement frequency, 60 13–14
metrics, 60
versus phase-gate milestones, 59–60, 324 Phase-gate (waterfall) milestones, 59–60, 324
Objectives, business. See Strategic themes.
542 INDEX
PI (Program Increment). See also PDCA (Plan-Do-Check- PO (Product Owner), 84
Adjust) cycle. post-event activities, 219
abstract, 207 preparation for, 214–218
in the Big Picture, 207–212 program backlogs, 195
definition, 517 program level, 213–220
develop on cadence, release any time, 208 Release (PI) Planning event, 64–65
executing, 208–212 Release Planning Readiness Checklist, 215
I&A (inspect and adapt) workshop, 211 responsibilities of Business Owners, 222
milestones, 325–326 sample program board, 218–219
multi-ART value streams, 211 value stream backlogs, 195
PI planning, 209, 211 value stream Kanban, 191
PO Sync meeting, 210
PI planning report, 386–387
pre- and post-PI planning, 211
program level, 207–212 PI summary reports, 385
solution demo, 211–212
PI system demo, I&A (inspect and adapt) workshop, 254
SoS (Scrum of Scrums) meetings, 210
system demo, 211 Pillars of the House of Lean, 28–30. See also specific pillars.
value stream increment, 211–212
Pink, Daniel, 67–68
PI Burn-down Chart, 317–318
Plan review, pre- and post-PI planning meetings, 387
PI cadence, portfolio Kanban, 447
Plan-Do-Check-Adjust (PDCA) cycles. See PDCA (Plan-
PI execution, responsibilities of Business Owners, 223–224 Do-Check-Adjust) cycles.
PI objectives Planning. See also Iteration planning; PI planning event;
aligning program teams, iteration goals to, 145 Pre- and post-PI planning meetings.
program level, 225–231 innovation and planning iteration, 514
team level, definition, 520 milestones, 328
value stream level, definition, 521 PPM (Program Portfolio Management), 433
PI objectives, program level PM (Product Management)
abstract, 225 abstract, 177
assigning business values to objectives, 229–230 ART (Agile Release Train), 161
committing to, 230 definition, 516
details, 225–231 program level, 177–181
features versus objectives, 227–228 responsibilities, 179–181
program objectives, creating, 230–231
PO (Product Owner). See also ScrumXP teams; SM
shedding excess WIP, 231
(Scrum Master).
SMART objectives, 229
abstract, 83
stretch objectives, 228–229
accepting stories, 84
team PI objectives, finalizing, 230
ATDD support, 84
team PI objectives, setting, 227
backlog refinement, 84
value stream objectives, creating, 230–231
PI planning event. See also Pre- and post-PI planning. content authority, 85–86
abstract, 213 definition, 516
agenda, 216–218 details, 83–86
Agile Teams, 80 fan-out model for Product Management and Agile
in the Big Picture, 213–220 Teams, 86
business benefits, 214 inspect and adapt workshop, 85
content readiness, 215 iteration execution, 84–85
definition, 516 iteration planning, 84
details, 213–220 iteration retrospective, 85
facility readiness, 215 just-in-time story elaboration, 84
inputs to, 214 in PI planning, 84
in multi-ART value streams, 219–220 program execution, 85
outputs, 218–219 responsibilities, 83–86
PI (Program Increment), 209, 211 scope of enabler work, 85
INDEX 543
team demos, 85 Portfolio Metrics, 307–308
training, 41
Portfolio strategy, enterprise, 420–421
PO Sync meeting, 210
Portfolio Vision
Point-Based Design, versus Set-Based Design, 365–366 capturing in solution intent, 298–299
characteristics of, 296–297
Portfolio business epics, definition, 516
definition, 296
Portfolio context solution vision, 297–298
enterprise, 418, 420–422
Portfolio-level concerns, solution context, 408
PPM (Program Portfolio Management), 430–431
Portfolios
Portfolio Kanban
connecting to an enterprise, 418
abstract, 443
connection to program level, 157
analysis stage, 445, 446
enterprise, sample, 418–419
metrics for, 307–312
definition, 516
new portfolio work levels, 345
details, 443–447
roadmaps, 346
done stage, 445, 447
for epics, 444–445 Portfolios, backlog
funnel stage, 444, 445 abstract, 449
implementation stage, 445, 446–447 in the Big Picture, 449–452
PI cadence, 447 definition, 516
portfolio backlog stage, 445, 446 details, 449–452
portfolio level, 443–447 estimating, 451–452
purpose of, 444 forecasting, 451–452
review stage, 445, 446 input, 450
managing, 450–451
Portfolio Kanban Board, 308–309
moving to implementation, 452
Portfolio level portfolio Kanban, 445, 446
abstract, 413 portfolio level, 449–452
in the Big Picture. See Big Picture, portfolio level. strategic themes, 426
budgets, 453–461
Post-PI planning. See Pre- and post-PI planning.
CapEx (capital expense). See CapEx (capital expense),
portfolio level. PPM (Program Portfolio Management)
connection to the enterprise, 414 abstract, 429
definition, 2, 516 Agile estimating and planning, 433
description, 6–7 in the Big Picture, 429–434
details, 413–415, 423–427 continuous value flow, 432
enterprise, 417–422 decentralized, rolling-wave planning, 433
Enterprise Architect, 439–442 definition, 517
Enterprise Architect, duties of, 415 delegated functions, 433
Epic Owners, 435–437 demand management, 432
epics, 483–488 details, 429–434
introduction, 413–415 epics, 432
key concepts, 414–415 governance, 433–434
managing epic workflow, 414–415 KPIs (key performance indicators), 433
OpEx (operational expense). See OpEx (operational Lean-Agile budgeting, 432
expense), portfolio. Lean-Agile portfolio management, 431–432
portfolio backlog, 449–452 life-cycle governance, 433–434. See also Integrated
portfolio Kanban, 443–447 learning cycles (SAFe Principle #4); Objective mile-
PPM (Program Portfolio Management), 414, 429–434 stones (SAFe Principle #5).
strategic themes, 423–427 lightweight business cases, 432
value streams, 473–482 portfolio context, 430–431
web address, 411 portfolio level, 429–434
program management, 432–433
Portfolio management. See PPM (Program Portfolio
qualitative data, 433
Management).
responsibilities of, 430–431
self-managing ARTs, 433
strategy and investment funding, 432
544 INDEX
Pre- and post-PI planning meetings Program backlogs
business benefits, 384 capacity allocation, 195–196
business context, 385 definition, 516
confidence vote, 387 details, 193–197
definition, 516 Little’s Law, 197
details, 383–388 PI planning, 195
inputs to, 384 prioritizing, 194
next PI features, 386 program level, 193–197
output, 387–388 queues, 197
PI planning report, 386–387 refining, 194
PI summary reports, 385 solution integrity, optimizing, 195–196
plan review, 387 value, optimizing, 195–196
preparing for, 211, 385 wait times, 197
retrospective, planning, 387
Program board, sample, 218–219
rework, planning, 387
risk analysis, 387 Program epic section, program Kanban, 189
setting planning context, 385–386
Program epics
solution context, 385
definition, 516
solution demos, 384
exploring and approving with program Kanban, 189
stakeholder participation, 386
summarizing results, 386–387 Program execution. See also Iteration execution.
value stream backlog, 386 core value of SAFe, 25
value stream level, 383–388 development manager, 14
iteration execution, 124
Preserving options (SAFe Principle #3)
at the program level, 156
creating integration points, 57–58
overview, 55–56 Program Increment (PI). See PI (Program Increment).
The Principle of Continuous Economic Trade-Offs, 49 Program Kanban
abstract, 187
The Principle of Optimum Decision Making, 49
The Principle of Quantified Cost of Delay, 49 definition, 517
details, 187–191
Principles
exploring and approving program epics, 189
Agile architecture. See Agile architecture, basic
feature section, 190
principles.
feature selection, 190
Agile Manifesto, 32
program epic section, 189
Lean. See SAFe principles.
for making economic decisions, 49, 195
SAFe. See SAFe principles. Program Kanban Board, 315
Principles of Product Development Flow, 259–261 Program level
abstract, 155
Priorities, strategic themes, 426
architectural runway, 265–270
Prioritizing ART (Agile Release Train), 159–165
features, 239 in the Big Picture. See Big Picture, program level.
jobs, 183–186 Business Owners, 221–224
program backlogs, 194 capabilities, 237–242
value stream backlogs, 194 definition, 2, 517
description, 4–5, 155–158
Problem-solving workshop, 255. See also I&A (inspect and
details, 155–158
adapt) workshop.
develop on cadence, release any time, 259–264
Product Management (PM). See PM (Product enablers, 243–247
Management). features, 237–242
I&A (inspect and adapt), 253–258
Product Owner (PO). See PO (Product Owner).
innovation and planning iteration, 249–252
Product Owners, team level, 83–87 introduction, 155–158
INDEX 545
key roles, 156–157 Qualitative review, iteration retrospective, 130
managing workflow, 156
Quantitative measurement, I&A (inspect and adapt)
NFRs (nonfunctional requirements), 199–206
workshop, 254
PI objectives, 225–231 Quantitative review, iteration retrospective, 129–130
PI planning, 213–220
Queues
portfolio, connection to, 157
avoiding excessive length, 305–306
Product Management, 177–181
managing. See Managing queue lengths (SAFe Principle
program backlogs, 193–197
#6).
program Kanban, 187–191
program backlogs, 197
RTE (Release Train Engineer), 167–170
value stream backlogs, 197
Solution Architect/Engineering, 171–175
versus wait time, 62
Solution Management, 177–181
System Architect/Engineering, 171–175
system demo, 233–236 R
value stream, connection to, 157 The real place. See Gemba (visiting the workplace).
value stream backlogs, 193–197
value stream Kanban, 187–191 Recording models in solution intent, Agile architecture,
VSE (Value Stream Engineer), 167–170 376
web address, 153 Reduce batch sizes (SAFe Principle #6), 61–62
WSJF (Weighted Shortest Job First), 183–186
Refactoring, built-in quality, 150
Program level epics, 488
Refining backlogs, 107–108, 194
Program management, 345–346. See also PPM (Program
Portfolio Management). Regression tests, 494
Program Performance Metrics, 316–317 Reinertsen, Donald
on decision-making, 49
Program PI objectives, definition, 517 Principles of Product Development Flow, 259–261
Program Portfolio Management (PPM). See PPM sunk cost principle, 195
(Program Portfolio Management). Release any time. See also Develop on cadence, release any
Program Predictability Measure, 254, 316 time.
Program teams, aligning to common PI objectives, 145 definition, 517
Program Vision, 299 Release Management
Programs, metrics for, 314–319 abstract, 283
Program/value stream backlog refinement, value stream components of, 283
Kanban, 191 definition, 517
Progress details, 283–285
tracking. See Tracking progress. membership of, 283–284
visualizing. See Visualizing progress. responsibilities for, 283–284
spanning palette, 283–285
Project-based constraints, effects on, 456–457 weekly meetings, 285
Promise for a conversation, 136 Release (PI) Planning event, 64–65. See also PI planning.
Prototyping, Set-Based Design, 367 Release Planning Readiness Checklist, 215
Pugh, Ken, 500 Release Train. See ARTs (Agile Release Trains).
Pull systems, Kanban, 99 Release Train Engineer (RTE). See RTE (Release Train
Purpose, motivating knowledge workers (SAFe Engineer).
Principle #8), 68 Releases
abstract, 331
Q in the Big Picture, 331–336
definition, 517
Qualitative data
definition of done, 335–336
enterprise, 420
details, 331–336
PPM (Program Portfolio Management), 433
546 INDEX
develop on cadence, release any time, 332 SM (Scrum Master), 89–91
frequency, 331–332 Solution Architect/Engineering, 172–173
spanning palette, 331–336 Solution Management, 181
System Team roles and responsibilities, 281 System Architect/Engineering, 172–173
value stream coordination, 346 UX (User Experience), 291–292
VSE (Value Stream Engineer), 167–168
Releases, building
actual release, 334–335 Roles and responsibilities, System Team
preventing release issues, 335 details, 279–282
solution increment, 334 release, 281
system increment, 333–334 solution demos, 281
team increment, 333 solution performance testing, 281
system demos, 281
Releasing any time, developing on cadence, 263–264
system integration, 280
Relentless improvement. See also I&A (inspect and adapt)
Root cause analysis
workshop.
80/20 rule, 256–257
Agile Teams, 81
fishbone diagrams, 256
backlog items, creating, 257–258
Five Whys technique, 256
Implementing 1-2-3, 41
I&A (inspect and adapt) workshop, 256–257
Lean-Agile mindset, House of Lean, 30, 81
Ishikawa diagrams, 256
Requirements, specifying, 367 Pareto Analysis, 256–257
Responding to change over following a plan, roadmaps, RTE (Release Train Engineer)
301–302 abstract, 167
ART (Agile Release Train), 161
Responsibilities. See Roles and responsibilities.
Retrospective definition, 517
I&A (inspect and adapt) workshop, 255 details, 167–170
planning, pre- and post-PI planning meetings, 387 program level, 167–170
reporting structure, 169
Review stage, portfolio Kanban, 445, 446
responsibilities, 167–168
Rework, planning, 387 as servant leaders, 169
value stream Kanban, 191
Risk analysis, pre- and post-PI planning meetings, 387
Runway. See Architectural runway.
Risk reduction-opportunity enablement value, 184
Roadmaps S
abstract, 301
avoiding long queues, 305–306 SAFe (Scaled Agile Framework)
in the Big Picture, 301–306 interactive view of. See Big Picture.
building, 302–303 organization levels, 2. See also Spanning palette; specific
definition, 518 levels.
details, 301–306 websites. See Websites, SAFe (Scaled Agile Framework).
estimating longer-term initiatives, 304–305 SAFe 4.0 Advanced Scrum Master with ASM certification,
example, 302 41
Little’s Law, 306
long-term forecasting, 303 SAFe 4.0 Product Manager / Product Owner with PMPO
responding to change over following a plan, 301–302 certification, 41
spanning palette, 301–306 SAFe 4.0 Scrum Master Orientation, 41
view of Vision, 299–300
SAFe 4.0 with SAFe Program Consultant (SPC4)
Roles and responsibilities Certification, 39
Agile Teams, 78
Business Owners, 221–224 SAFe foundation, 2–3. See also Big Picture, SAFe founda-
development manager, 13 tion.
Enterprise Architects, 439–440 SAFe Managed-Investment Contracts, 506–509
Epic Owners, 435–437
PM (Product Management), 179–181 SAFe principles
RTE (Release Train Engineer), 167–168 in the Big Picture. See Big Picture, SAFe principles.
Shared Services, 288–289 definition, 518
INDEX 547
importance of, 36 abstract, 287
list of, 3, 35, 43. See also specific principles. ART (Agile Release Train), 161
SAFe Team Self-Assessment, 321
definition, 518
Scaled Agile Framework (SAFe). See SAFe (Scaled Agile details, 287–289
Framework). embedded in Agile teams, 289
Scaled Agile SPC membership site, 39
skills required, 288
Scaling spanning palette, 287–289
alignment, 22 specialized training, 288
crappy code/components, 23–24
Simplicity, principle of Agile architecture, 375
Scrum Master (SM). See SM (Scrum Master).
Simulation, Set-Based Design, 367
Scrum of Scrums (SoS), 210
Single value stream ARTs, 479–480
Scrum process
Skill requirements, Agile Teams, 77–78
DSU (daily stand-up) meeting, 95 Slipping integration points, 58
iteration planning, 94–95
SM (Scrum Master)
iteration retrospective, 96
abstract, 89
iterations versus sprints, 94
stories, dividing into tasks, 94–95
CoPs (Communities of Practice), 18–19
story boards, 95
definition, 518
team demo, 96
details, 89–91
tracking progress, 95
visualizing work, 95
sourcing the role, 91
ScrumXP teams team level, 89–91
abstract, 93 time requirements, 91
on the ART train, 96–97 training, 41
SMART objectives, 229
definition, 518
details, 93–97 Software, built-in quality, 23, 148–151
leadership, 97
Software classification, CapEx (capital expense), 465
SM (Scrum Master), 94 Software development costs, CapEx (capital expense), 465
team level, 93–97
Solution Architect/Engineering
Set-Based Design abstract, 171
abstract, 365 in the Big Picture, 171–175
adaptive planning, 368 definition, 518
in the Big Picture, 365–369 details, 171–175
definition, 518 origin of SAFe roles, 173
details, 365–369 program level, 171–175
economic efficiency, 366–368 responsibilities, 172–173
economic trade-offs, 368–369
Solution context
fixed-schedule programs, 366
abstract, 405
frequent integration points, 367
modeling, 367
continuous collaboration, 408–409
versus Point-Based Design, 365–366
definition, 518
prototyping, 367
deployability, 408–409
recommended practices, 367–368
details, 405–409
simulation, 367
driving solution intent, 406
specifying interfaces and requirements, 367
fixed versus evolving, 406
tool for solution intent, 203
for IT deployment environments, 407–408
portfolio-level concerns, 408
Shared Services
548 INDEX
synchronization with CI (continuous integration), value stream level, 351–358
493–494 variable, 354, 355–356
for a system of systems, 407
Solution Management
types of, 407
abstract, 177
Solution demos definition, 519
agenda, 381 program level, 177–181
attendees, 380 responsibilities, 181
in the Big Picture, 125, 379–382
Solution performance testing, System Team roles and
definition, 519
responsibilities, 281
demonstrating the solution, 381
details, 379–382 Solution vision, 297–298
guidelines, 381
Solutions
investment, 382
abstract, 401
capabilities, 402
preparation for, 380
context, 403
as a pull event, 380
customer context, 403
strategy, 382
definition, 518
System Team roles and responsibilities, 281
demos, 403
team level, 125
details, 401–404
timing, 382
development overview, 401–402
economic viability, 403
Solution increment, 334 enablers, 402
integration, 403
Solution integration
multiple, managing, 403–404
CI (continuous integration), 492–494
NFRs, 402
versus testing effort, 281–282
solution intent, 403
Solution integrity, optimizing, 195–196 as systems, 51–52
systems thinking, 402–403
Solution intent
testing, 403
abstract, 351
Agile Development in High-Assurance and Regulated
Environments, 352 Solution/system demo, value stream Kanban, 191
assuming variability, 353
SoS (Scrum of Scrums), 210
capturing portfolio Vision, 298–299 Spanning palette
collaborating on, 354–355 in the Big Picture. See Big Picture, spanning palette.
current and future state, 352–353 definition, 519
definition, 519 description, 5
designs, 352–353 DevOps, 273–278
details, 351–358 metrics, 307–321
developing, 354–355 milestones, 323–329
documentation, 357–358 at the program level, 157
driven by solution context, 406 Release Management, 283–285
dynamic nature of, 353 releases, 331–336
fixed, 354, 355–356 roadmaps, 301–306
introduction, 352–353 Shared Services, 287–289
and NFRs (nonfunctional requirements), 202–203 System Team, 279–282
recording MBSE models, 361–362 UX (User Experience), 291–294
recording models in, Agile architecture, 376 Vision, 295–300
and solutions, 403 web address, 271
specifications, 352–353
Specialist roles, training, 41
system level, 356–357
tests, 352–353 Specification workshops, team backlog, 108
INDEX 549
Specifications, solution intent, 352–353 Story points
CapEx (capital expense), 469–470
Splitting
estimating stories, 138
capabilities into features, 241–242
epics, 486–487 Story-by-story approach to NFRs, 204
stories, 140
Strategic themes
abstract, 423
Sprint goals. See Iteration goals. in the Big Picture, 423–427
connecting enterprise to portfolio, 418
Sprints. See Iterations.
definition, 519
Stakeholder participation, pre- and post-PI planning economic framework, 425
meetings, 386 examples, 424
formulating, 424–425
Standard service class, 102–103
input to portfolio vision, 425–426
Statement of intent, 136 measuring progress against, 426–427
portfolio backlog, 426
Stories
3Cs: Card, Conversation, Confirmation, 136–137
priorities, 426
abstract, 133
acceptance criteria, 137
vision, 426
accepting, 84
analysis of, 115 Stretch objectives, 228–229
applying to CapEx, 468–470
Stubs, 495
building serially and incrementally, 122–124 Subsystem ARTs, 163–164
Card aspect, 136
Success criteria for epics, 486
Confirmation aspect, 137
continuous acceptance, 122 The Sunk Cost Principle, 49
Conversation aspect, 136–137
Suppliers
definition, 519
abstract, 389
details, 133–141
Agile contracts, 393
enabler, 135–136, 513
guidelines for writing, 136–137
collaborating with, 392–393
hierarchy of artifacts, 133–134
decentralizing decision-making, 391–392
INVEST (Independent, Negotiable, Valuable, Estimable,
definition, 519
Small, Testable), 137
details, 389–394
promise for a conversation, 136
improving, 393
in the SAFe Requirements Model, 141
Lean-Agile practices, 390
sources of, 134
selecting, 393
splitting, 140
synchronization with CI (continuous integration),
statement of intent, 136
493–494
task analysis, 115
systems thinking, 391–392
traditional methods, 391
user, 134
value centric, 134
Swim lanes, 102–103
Stories, estimating
common starting baseline, 139–140 Synchronization
estimating poker, 138–140 with cross-domain planning, 63–65
iteration planning, 115 develop on cadence, release any time, 259–261
normalizing story point estimating, 116–117 value stream coordination, 344–345
story points, 138
System architect, origin of SAFe roles, 173
velocity, 139
System Architect/Engineering
Story boards, 95
abstract, 171
Story count, CapEx (capital expense), 470 ART (Agile Release Train), 161
Story enablers, 244
decentralized decision-making, 174
Story hours, CapEx (capital expense), 469 definition, 519
550 INDEX
details, 171–175 the solution is a system, 51–52
empirical approach, 174–175 solutions, 402–403
Lean-Agile approach, 173–175 suppliers, 391–392
origin of SAFe roles, 173
program level, 171–175 T
at the program level, 157
responsibilities, 172–173 TDD (Test-Driven Development), 149. See also Test-first
traits of Lean-Agile Leaders, 174 methods.
System demos. See also Team demos. Team backlogs. See also Backlogs.
agenda, 235 in the Big Picture, 105–108
attendees, 236 capacity allocation, 107
balancing integration effort and feedback, 235 definition, 520
in the Big Picture, 125, 233–236 details, 105–108
definition, 520 refinement, 107–108
details, 233–236 specification workshops, 108
PI (Program Increment), 211 system health, optimizing, 107
program level, 233–236 team level, 105–108
System Team roles and responsibilities, 281 value delivery, optimizing, 107
team level, 125 Team demos
timing of, 234–235 abstract, 125
System health, optimizing, 107 agenda, 127
attendees, 127
System increment of releases, 333–334 in the Big Picture, 125–127
System integration definition, 520
built-in quality, 24 details, 125–127
System Team roles and responsibilities, 280 functions of, 125
guidelines, 127
System Kanban, details, 187–191 PO (Product Owner), 85
System level, solution intent, 356–357 process, 126
purpose of, 126
System of systems, solution context, 407 team level, 125–127
System qualities. See NFRs (nonfunctional requirements). Team increment of releases, 333
System qualities tests, 499 Team Kanban. See also Kanban.
System Team abstract, 99
abstract, 279 on the ART train, 103
ART (Agile Release Train), 161 in the Big Picture, 99–104
in the Big Picture, 279–282 calculating derived velocity, 104
building development infrastructure, 280 common starting point for estimation, 104
CI (continuous integration) in support of, 496 definition, 520
details, 279–282 estimating work, 103–104
in larger value streams, 280 team level, 99–104
release, 281 Team Kanban Board, 320
solution integrations versus testing effort, 281–282 Team level
solution performance testing, 281 Agile Teams, 77–81
spanning palette, 279–282 in the Big Picture. See Big Picture, team level.
system and solution demos, 281 built-in quality, 147–152
system integration, 280 definition, 2, 520
demos, 125–127
Systems engineer, origin of SAFe roles, 173 description, 3–4
Systems thinking (SAFe Principle #2) iteration execution, 119–124
in the Big Picture, 51–53 iteration goals, 143–145
the Enterprise is a system, 52 iteration planning, 113–117
management role in changing systems, 52–53 iteration retrospective, 129–131
INDEX 551
iterations, 109–111 UX design, 293
Product Owners, 83–87
Testing effort versus solution integrations, 281–282
purpose of, 3
Scrum Master, 89–91 Tests, solution intent, 352–353
ScrumXP teams, 93–97
3Cs: Card, Conversation, Confirmation, 136–137
solution demo, 125
stories, 133–141 3-level SAFe, Big Picture, 1
system demo, 125
Throughput, Kanban, 101–102
team backlog, 105–108
team demo, 125–127 Time and materials contracts, 503–505
team Kanban, 99–104
Time criticality, cost of delay factor, 184
Team members, DevOps, 274
Time to market, reducing, 481–482
Team PI objectives, definition, 520
Tools, for solution intent, 203
Team PI Performance Report, 320–321
Toyota, 392
Teams. See also specific teams.
Traceability, MBSE models, 360–361
on the train, 164–165 Tracking progress. See also Kanban.
“Technical Strategies for Agile and Waterfall
DSU (daily stand-up) meeting, 95, 121
iteration execution, 120–121
Test automation, iteration execution, 122 story boards, 95
Test environments, DevOps, 276 Training
Agile implementers, 38
Testable MBSE models, 363
coaching the ART (Agile Release Train), 40
Testable NFRs, 203 consulting activities, 40–41
executives, 39
Test-Driven Development (TDD), 149. See also Test-first
Implementing 1-2-3 pattern, 3
methods.
Implementing SAFe 4.0 with SPC Certification, 38
Test-first methods. See also ATDD (Acceptance Test- leaders, 39
Driven Development); TDD (test-driven development). Leading SAFe 4.0, Leading the Lean-Agile Enterprise with
abstract, 497 the Scaled Agile Framework, 39
acceptance test template/checklist, 502 Lean-Agile change agents, 38, 39
Agile Testing Matrix, 497–499 licensing, 38
ATDD (Acceptance Test-Driven Development), 149, managers, 39
500 Product Owners, 41
automated acceptance testing, 502 SAFe 4.0 Advanced Scrum Master with ASM
in the Big Picture, 497–502 Certification, 41
built-in quality, 149 SAFe 4.0 Product Manager / Product Owner with PMPO
component tests, 498, 500 certification, 41
definition, 520 SAFe 4.0 Scrum Master Orientation, 41
details, 497–502 SAFe 4.0 with SAFe Program Consultant (SPC4)
functional tests, 498, 501 Certification, 39
recommended practices, 499–502 Scrum Masters, 41
system qualities tests, 499 specialist roles, 41
system-level acceptance tests, 498–499
Transparency
TDD (Test-Driven Development), 149
core value of SAFe, 24–25
unit tests, 498, 500
development manager, 14
Testing enabling trust, 24–25
deprecated tests, 494
designing for testability, 496 U
NFRs (nonfunctional requirements), 204–206
partial, 205 Uniform Resource Locators (URLs). See Web addresses;
regression tests, 494 Websites.
responsibility for, 376–377 Unit tests, test-first methods, 498, 500
solutions, 403
552 INDEX
URLs (Uniform Resource Locators). See Web addresses; enterprise architecture, 345–346
Websites. new portfolio work levels, 345
portfolio roadmap, 346
Usability. See UX (User Experience) design.
program management, 345–346
User Experience (UX) design. See UX (User Experience) release, 346
design. synchronization, 344–345
User stories, 134
Value Stream Engineer (VSE). See VSE (Value Stream
User-business value, cost of delay factor, 184
Engineer).
UX (User Experience) design
Value stream epics, definition, 521
abstract, 291
in the Big Picture, 291–294 Value stream increment, PI (Program Increment), 211–212
centralized guidance and implementation, 293–294
Value stream Kanban
characteristics of, 292
definition, 520
definition, 521
design criteria, 293
epic specification workshop, 191
designers on the ART, 161, 293–294
PI planning, 191
details, 291–294
distributed, governed development, 294
program/value stream backlog refinement, 191
interfaces, specifying, 367
solution/system demo, 191
as potential bottleneck, 294
supporting ceremonies, 191
spanning palette, 291–294 Value Stream Kanban Board, 313
testing criteria, 293
Value stream level
Agile architecture, 371–378
V in the Big Picture. See Big Picture, value stream level.
Value, optimizing, 195–196 coordination of dependencies, 343–346
Customers, 395–399
Value centric stories, 134 definition, 2, 521
Value delivery, optimizing, 107 description, 6
economic framework, 347–349
Value stream, importance of DevOps, 273–274 MBSE (Model-Based Systems Engineering), 359–364
Value stream backlogs pre- and post-PI planning, 383–388
abstract, 193 Set-Based Design, 365–369
in the Big Picture, 193–197 solution context, 405–409
capacity allocation, 195–196 solution demo, 379–382
definition, 516, 521 solution intent, 351–358
details, 193–197 solutions, 401–404
Little’s Law, 197 suppliers, 389–394
PI planning, 195 value stream coordination, 343–346
pre- and post-PI planning meetings, 386 web address, 337
prioritizing, 194 Value stream level backlogs
program level, 193–197 abstract, 193
queues, 197 in the Big Picture, 193–197
refining, 194 capacity allocation, 195–196
solution integrity, optimizing, 195–196 definition, 516, 521
value, optimizing, 195–196 details, 193–197
wait times, 197 Little’s Law, 197
Value stream coordination PI planning, 195
abstract, 343 pre- and post-PI planning meetings, 386
in the Big Picture, 343–346 prioritizing, 194
cadence, 344–345 queues, 197
content management, 345–346 refining, 194
definition, 521 solution integrity, optimizing, 195–196
deployment, 346 value, optimizing, 195–196
details, 343–346 wait times, 197
INDEX 553
Value stream level epics, 488 spanning palette, 295–300
strategic themes, 426
Value stream objectives, creating, 230–231
Vision, portfolio
Value Stream Performance Metrics, 314
capturing in solution intent, 298–299
Value stream PI objectives, definition, 521 characteristics of, 296–297
definition, 296
Value Stream Predictability Measure, 313–314
solution vision, 297–298
Value streams
Visualize and limit WIP (SAFe Principle #6). See WIP
abstract, 473
(work in progress), visualizing and limiting.
budgeting for, 477–478 Visualizing progress. See also Kanban.
coordinating, 481 BVIRs (big visual information radiators), 95
crossing boundaries, 477 DSU (daily stand-up) meeting, 95, 121
definition template, 476 iteration execution, 120–121
details, 473–482 story boards, 95
development, 474–475, 477, 478–480
VSE (Value Stream Engineer)
identifying, 475–478
abstract, 167
operational, 474–475
definition, 521
reducing time to market, 481–482
details, 167–170
triggering value flow, 474
types of, 474–475
reporting structure, 169
value stream mapping, 481–482
Value streams, ARTs as servant leaders, 169
coordinating, 481 value stream Kanban, 191
multi-ART value streams, 480
multiple value stream ARTs, 478–479 W
single value stream ARTs, 479–480
Wait time
Value streams, portfolio level program backlogs, 197
connection to program level, 157 versus queue length, 62
definition, 521 value stream backlogs, 197
multi-ART, 211 Wake, Bill, 137
size, organizing the ART, 162–163 Waterfall development
splitting, 163–165 intra-iteration waterfalls, 122–123
strategic themes, 425–426 mixing with ART (Agile Release Train), 158
Variability, assuming. See Assuming variability (SAFe phase-gate milestones, 59–60, 324
Principle #3). “Technical Strategies for Agile and Waterfall
Variable solution intent, 354, 355–356
Web addresses, Big Picture
Velocity guidance, 489
derived, calculating, 104 portfolio level, 411
stories, estimating, 139 program level, 153
workload, estimating, 114 SAFe foundation, 1
Version control, DevOps, 277 SAFe principles, 43
spanning palette, 271
Vision team level, 73
abstract, 295 value stream level, 337
definition, 521 Websites, SAFe (Scaled Agile Framework)
details, 295–300 Case Studies articles, 37
enterprise, 421 interactive guide to SAFe. See Big Picture.
program, 299 “Mixing Agile and Waterfall Development,” 158
roadmap view, 299–300 overview, 1
Scaled Agile SPC membership site, 39
554 INDEX
Weighted Shortest Job First (WSJF). See WSJF (Weighted abstract, 183
Shortest Job First). in the Big Picture, 183–186
cost of delay, calculating, 184–185
WIP (work in progress)
definition, 522
limits, Kanban, 100–101
details, 183–186
managing iteration execution, 121–122
job duration, 185–186
shedding excess, 231
job size as a proxy for duration, 186
WIP (work in progress), visualizing and limiting (SAFe prioritizing jobs, 183–186
Principle #6). See also Kanban. program level, 183–186
in the Big Picture, 61–62 WSJF, calculating, 183–184
flow limit, 61
Wishful thinking, 492
Workflow management, program level, 156
WSJF (Weighted Shortest Job First)
INDEX 555

Safe For Teams

Uploaded by

Copyright:

Available Formats

Safe For Teams

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Safe For Teams

Uploaded by

Copyright:

Available Formats

4.

SCALED AGILE FRAMEWORK® FOR LEAN

For government sales inquiries, please contact [email protected].

Visit us on the Web: informit.com/aw

Library of Congress Control Number: 2016943742

Copyright © 2017 Scaled Agile, Inc.

First printing, August 2016

Introduction to the Scaled Agile Framework (SAFe).........................................................................1

Part 1: The SAFe Foundation......................................................................................................................9

Part 2: The SAFe Principles...................................................................................................................... 43

Part 4: The Program Level.....................................................................................................................153

Part 5: The Spanning Palette................................................................................................................271

Part 6: The Value Stream Level............................................................................................................337

Why a Reference Guide?

—Dean Leffingwell and the Scaled Agile Team

Drew Jemilo, SAFe Fellow and Principal Consultant

Richard Knaster, SAFe Fellow and Principal Consultant

Inbar Oren, SAFe Fellow and Principal Consultant

A Special Acknowledgment to the Lean Leaders

And to W. Edwards Deming

SAFe 4.0 for Lean Software and Systems Engineering

Enterprise Epic Epic

AGILE RELEASE TRAIN Solution

Epics Release Any Time

Product XP Stories Goals

Values Mindset Principles 1 23

Figure 1. Big Picture: 3-level and 4-level SAFe

Introduction to the Scaled Agile Framework (SAFe) 1

2 Introduction to the Scaled Agile Framework (SAFe)

• Implementing 1-2-3 – Based on the learnings from hundreds of SAFe implementations,

Figure 2. SAFe team level

Introduction to the Scaled Agile Framework (SAFe) 3

• DevOps • Release Mgmt Vision Roadmap Metrics • Milestones

Epics Release Any Time

Product XP Stories Goals

Scrum Objectives P P TEAM

Figure 3. Program level

4 Introduction to the Scaled Agile Framework (SAFe)

The Spanning Palette

Figure 4. The spanning palette

Introduction to the Scaled Agile Framework (SAFe) 5

6 Introduction to the Scaled Agile Framework (SAFe)

Introduction to the Scaled Agile Framework (SAFe) 7

#1 – Lead the Change

#4 – Inspire and Align with Mission; Minimize Constraints

#6 – Unlock the Intrinsic Motivation of Knowledge Workers

12 PART 1 | THE SAFe FOUNDATION

Personnel and Team Development

14 PART 1 | THE SAFe FOUNDATION

[1] Manifesto for Agile Software Development. http://agilemanifesto.org/.

Such inter-team communication is often supported by Communities of Practice (CoP)—informal

Organizing a Community of Practice

Operating a Community of Practice

18 PART 1 | THE SAFe FOUNDATION

SAFe Core Values 21

SAFe 4.0 for Lean Software and Systems Engineering

• DevOps • Release Mgmt Vision Roadmap Metrics • Milestones SUPPLIER

AGILE RELEASE TRAIN

Epics Release Any Time