Business Agility

Business Agility
Those who master large-scale software delivery will define the economic landscape of the
21st century.
—Mik Kersten, Project to Product
Business Agility is the ability to compete and thrive in the digital age by quickly responding
to market changes and emerging opportunities with innovative business solutions.
Business Agility requires that everyone involved in delivering solutions—business and

technology leaders, development, IT operations, legal, marketing, finance, support,
compliance, security, and others—use Lean and Agile practices to continually deliver
innovative, high-quality products and services faster than the competition.
Competing in the Age of Software

In Technological Revolutions and Financial Capital, [1] Carlota Perez plots the evolution of
society, business, and financial capital based on technological revolutions that have occurred
over the last few hundred years. She opines that these disruptive trends happen every
generation or so. These include technology trends such as the ‘age of steel and heavy
engineering,’ ‘age of oil and mass production,’ and others, as illustrated in Figure 1.
She concludes that these technology revolutions radically alter society, first via a mass
movement in financial (investment) capital, which then results in new production capital
(goods and services). Massive societal change, disruption, and a new economic order sets in.
These are truly ‘world-shaking’ disruptions that occur with three distinct phases:
 Installation Period – New technology and financial capital combine to create a

‘Cambrian explosion’ (a geological term for a relatively short time over which a large
diversity of life forms appeared) of new entrants.
 Turning Point – Existing business either master the new technology or decline and
become relics of the last age
 Deployment Period – Production capital of the new technological giants starts to take
over
Figure 1. Technological revolutions over the past few centuries. [1, 2] As Figure 1 indicates, are we at
the turning point or in the deployment period?
 If we are looking for the explosion of new entrants, we would need to look no further
than the dotcom boom and bust at the start of this century.
 If we were looking for the turning point, where existing business either master the
new technology or decline, Blockbuster, Nokia phones, AOL, and many others come
to mind
 If we were looking for the deployment period, one might look at the market
capitalizations of Google, Apple, Amazon, Baidu, Salesforce, or Tesla—all
companies that didn’t exist just 20-30 years ago
In his analysis of this work and in his book, Project to Product, Kersten [2] notes that with
respect to production capital “The productivity of software delivery at enterprise
organizations falls woefully behind that of the tech giants, and the digital transformations
that should be turning the tide are failing to deliver business results.”
This means that many large and successful enterprises today face an existential crisis, the
distinctive competencies and massive tangible assets that got them there—distribution, real
estate, manufacturing, retail, local banking centers, insurance agents—will not be adequate to
assure survival in the digital age.
How We Got Here

“The problem is not with our organizations realizing that they need to transform; the
problem is that organizations are using managerial frameworks and infrastructure models
from past revolutions to manage their businesses in this one.” — Mik Kersten
Most of the leaders of these traditional organizations are well aware of the threat of digital
disruption, and yet many fail to make the transition to take their place in the next economy.
The question is, why?
As an organizational researcher and author John Kotter illustrates in his recent

book, Accelerate: Building Strategic Agility for a Faster-Moving World [1], successful
enterprises don’t start as large and cumbersome. Rather, they typically began as a fast-
moving, adaptive network of motivated individuals aligned to a common vision and focused
on the needs of their customers. Roles and reporting relationships are fluid, and people
collaborate organically to identify customer needs, explore potential solutions, and deliver
value in any way they can. In other words, it’s an adaptive ‘entrepreneurial network’ of
people working towards a shared, customer-centric purpose (Figure 2).
Figure 2. New enterprises start as a customer-focused network
As the enterprise succeeds, it naturally wants to expand on its success and grow. This means
that individual responsibilities must become clearer to ensure that critical details are carried
out. To add expertise, specialists are hired. Departments are created. Policies and procedures
are established to ensure legality and compliance and to drive repeatable, cost-efficient
operations. The business starts to organize by function. Silos begin to form. Meanwhile,
operating in parallel, the network continues to seek new opportunities to deliver value
(Figure 3).
Figure 3. Growing hierarchical structure running in parallel with an entrepreneurial network
To achieve increasing economies of scale, the hierarchy continues to grow. And grow.
However, by assuming the practices and responsibilities incumbent on large business, it
begins to conflict with the entrepreneurial network. With the authority of current revenue and
profitability needs behind it, the hierarchical organization collides with the faster-moving,
more adaptive network. The result? The network gets crushed in the process. Customer
centricity is one of the casualties. (Figure 4.)
Figure 4. Entrepreneurial network collides with a growing hierarchy
Still, as long as the market remains relatively stable, the economies of scale provide a barrier
against competitors, and the enterprise can enjoy continued success and growth. However,
when customer needs shift dramatically, or when a disruptive technology or competitor
emerges, the organization lacks the agility to respond. Years of market domination and
profitability can vanish, seemingly overnight. The result is an existential crisis; the
company’s very survival is at stake.
The organizational hierarchies that we’ve built over the last fifty years have done a great job
of providing time-tested structures, practices, and policies. They support the recruiting,
retention, and growth of thousands of employees across the globe. Simply put, they are still
needed. But the question becomes, how to organize and reintroduce the entrepreneurial
network? In addressing the dilemma, Kotter points out, “The solution is not to trash what we
know and start over but instead to reintroduce a second system.” This model, which Kotter
calls a ‘dual operating system’ (Figure 5), restores the speed and innovation of the
entrepreneurial network while leveraging the benefits and stability of the hierarchical system.
Figure 5. A ‘dual operating system’ offers efficiency and stability with the speed of innovation
So how do we create such a dual operating system?
SAFe 5.0 – Your Operating System for Business Agility

By organizing the second operating system around value streams instead of departments,
SAFe offers a way for enterprises to focus on customers, products, innovation, and growth
(Figure 6).
Figure 6. SAFe as a second organizational operating system
Moreover, this operating system is flexible. It is built on time tested Lean, Agile, and SAFe
practices, and it can organize and quickly reorganize without completely disrupting the
existing hierarchy. That’s what Business Agility demands.
But to achieve this, the organization requires a significant degree of expertise across seven
core competencies, as illustrated in Figure 7.
Figure 7. The Customer is at the center of the Seven Core Competencies of Business Agility
While each competency can deliver value independently, they are also interdependent in that
true Business Agility can be present only when the enterprise achieves a meaningful state of
mastery of all. It’s a tall order, but the path is clear.
The remainder of this article summarizes each of the seven core competencies
Team and Technical Agility

It all starts with Agile development, the cornerstone of Business Agility. The Team and
Technical Agility competency describe the critical skills and Lean-Agile principles and
practices that high-performing Agile teams and Teams of Agile teams use to create high-
quality solutions for their customers. It consists of three dimensions, as illustrated in Figure
8:
Figure 8. The three dimensions of Team and Technical Agility
 Agile Teams – High-performing, cross-functional teams anchor the competency by

applying effective Agile principles and practices.
 Team of Agile Teams – Agile teams operate within the context of a SAFe Agile
Release Train (ART), a long-lived, team of Agile teams that provides a shared vision
and direction and is ultimately responsible for delivering solution outcomes.
 Built-in Quality – All Agile teams apply defined Agile practices to create high-
quality, well-designed solutions that support current and future business needs.
Agile Product Delivery

Business Agility demands that enterprises rapidly increase their ability to deliver innovative
products and services. To be sure, the enterprise is creating the right solutions for the right
customers at the right time; they must balance their execution focus with a customer focus.
These capabilities are mutually supportive and create opportunities for sustained market and
service leadership. Agile Product Delivery is a customer-centric approach to defining,
building, and releasing a continuous flow of valuable products and services to customers and
users.
There are three dimensions to Agile Product Delivery, as illustrated in Figure 9.

Figure 9: Three Dimensions of Agile Product Delivery
Customer Centricity and Design Thinking – Customer centricity puts the customer at the
center of every decision and uses design thinking to ensure the solution is desirable, feasible,
viable, and sustainable.
Develop on Cadence; Release on Demand – Developing on cadence helps manage the
variability inherent in product development. Decoupling the release of value from that
cadence ensures customers can get what they need when they need it.
DevOps and the Continuous Delivery Pipeline – DevOps and the Continuous Delivery
Pipeline creates the foundation that enables enterprises to release value, in whole or in part,
at any time it’s needed.
Enterprise Solution Delivery

Building and evolving large, enterprise solutions is a monumental effort. Many such systems
require hundreds or thousands of engineers. They demand sophisticated, rigorous practices
for engineering, operations, and support. Moreover, over the decades that these systems are
operational, their purpose and mission evolve. That calls for new capabilities, technology
upgrades, security patches, and other enhancements. As true ‘living systems,’ the activities
above are never really ‘done.’ Instead, they are released earlier and further developed over
time.
The Enterprise Solution Delivery competency describes how to apply Lean-Agile principles

and practices to the specification, development, deployment, operation, and evolution of the
world’s largest and most sophisticated software applications, networks, and cyber-physical
systems. It consists of three dimensions. (Figure 10).
Figure 10. Three dimensions of Enterprise Solution Delivery
Lean System and Solution Engineering applies Lean-Agile practices to align and

coordinate all the activities necessary to specify, architect, design, implement, test, deploy,
evolve, and ultimately decommission these systems.
Coordinating Trains and Suppliers coordinates and aligns the extended set of value
streams to a shared business and technology mission. It uses the coordinated Vision,
Backlogs, and Roadmaps with common Program Increments (PI) and synchronization points.
Continually Evolve Live Systems ensures both the development pipeline and the large
systems themselves support continuous delivery of value, both during and after, release into
the field.
Lean Portfolio Management
The three competencies above provide the technical practices needed to build and deploy
meaningful business solutions. But none of them directly address the more significant issue
of why those solutions are required, how they are funded and governed, and what other
solutions are necessary to deliver complete enterprise value. For that, we need to address
portfolio concerns. However, traditional approaches to portfolio management were not
designed for the impact of digital disruption. These factors put pressure on enterprises to
work under a higher degree of uncertainty, and yet deliver innovative solutions much faster.
Portfolio Management approaches must be modernized to support the new Lean-Agile way
of working. The Lean Portfolio Managementcompetency aligns strategy and execution by
applying Lean and systems thinking. As Figure 11 illustrates, it accomplishes this through
three collaborations for strategy and investment funding, Agile portfolio operations, and
Lean governance.
Figure 11. Lean Portfolio Management responsibilities
Strategy and Investment Funding ensures that the entire portfolio is aligned and funded to
create and maintain the solutions needed to meet business targets. It requires the cooperation
of Business Owners, portfolio stakeholders, technologists, and Enterprise Architects.
Agile Portfolio Operations coordinates and supports decentralized program execution,

enabling operational excellence. It requires the cooperation of the Agile Product
Management Office/Lean-Agile Center of Excellence (APMO/LACE) and Communities of
Practice (CoPs) for Release Train Engineers (RTEs) and Scrum Masters.
Lean Governance manages spending, audit and compliance, forecasting expenses, and

measurement. It requires the engagement of the Agile PMO/LACE, Business Owners, and
Enterprise Architects.
Organizational Agility
Even with the competencies above, the enterprises must be able to change quickly to respond
to the challenges and opportunities that today’s rapidly evolving markets present. This
requires more flexibility and adaptability than the hierarchical operating system is likely to
be able to muster. Again, we turn to the second operating system for help. SAFe helps
businesses address these challenges with Organizational Agility, which is expressed in three
dimensions (Figure 12):
Figure 12. Three dimensions of Organizational Agility
Lean-Thinking People and Agile Teams – This state occurs when everyone involved in
solution delivery is trained in Lean and Agile methods and embraces and embodies the
values, principles, and practices.
Lean Business Operations – Teams apply Lean principles to understand, map, and
continuously improve the business processes that support the business’s products and
services.
Strategy Agility – This state occurs when the enterprise shows the ability and adaptability
needed to sense the market and quickly change strategy when necessary continuously.
Continuous Learning Culture
And even with mastery of the above, there can be no steady-state. Startup companies will
continue to challenge the status quo. Juggernaut companies like Amazon and Google are
entering entirely new markets such as banking and healthcare. Expectations from new
generations of workers, customers, and society as a whole challenges companies to think and
act beyond balance sheets and quarterly earnings reports.
To address the demand for continuous learning, growth of its people, and improvement in
processes, the Continuous Learning Culture competency describes a set of values and
practices that encourage individuals—and the enterprise as a whole—to continually increase
knowledge, competence, performance, and innovation. It is expressed in three dimensions, as
shown in Figure 13.
Figure 13. The three dimensions of a continuous learning culture
The three dimensions are:
Learning Organization – Employees at every level are learning and growing so that the
organization can transform and adapt to an ever-changing world.
Innovation Culture – Employees are encouraged and empowered to explore and implement
creative ideas that enable future value delivery.
Relentless Improvement – Every part of the enterprise focuses on continuously improving

its solutions, products, and processes.
Lean-Agile Leadership
Finally, we recognize that an organization’s managers, executives, and other leaders provide
the foundation ultimately responsible for the adoption and success of Lean-Agile
development and mastery of the competencies that lead to Business Agility. Only they have
the authority to change and continuously improve the systems that govern how work is
performed. Only they can create an environment that encourages high-performing Agile
teams to flourish and produce value. Leaders, therefore, must internalize and model leaner
ways of thinking and operating so that team members will learn from their example,
coaching, and encouragement.
By helping leaders develop along three dimensions, as illustrated in Figure 14, organizations
can establish the core competency of Lean-Agile Leadership.
Figure 14. Three dimensions of Lean-Agile Leadership
Leading by Example – Leaders gain earned authority by modeling the desired behaviors for
others to follow, inspiring them to incorporate the leader’s example into their development
journey.
Mindset and Principles – By embedding the Lean-Agile way of working in their beliefs,
decisions, responses, and actions, leaders model the expected norm throughout the
organization.
Leading Change – Leaders lead (rather than support) the transformation by creating the

environment, preparing the people, and providing the necessary resources to realize the
desired outcomes.
Measure and Grow

The road to real business agility is long and never-ending. The SAFe Business Agility
Assessment helps enterprises understand where they are on their journey and reminds them
to celebrate the small successes along the way. It is built directly around the seven core
competencies; each competency is further split into the three competency dimensions.
Applying the assessment, reasoning about the results, and following the recommendations
will help assure the best possible outcomes for the enterprise. See the Measure and
Growarticle for more details.
Summary
Welcome to the age of software. An era where Business Agility will be the most significant
single factor in deciding the winners and losers in the new economy. Lean-
Agile commercial businesses will create higher profits, increase employee engagement, and
more thoroughly satisfy customer needs. Lean-Agile nonprofits will build resilience,
sustainability, and the alignment needed to fulfill its mission. Lean-Agile governments will
deliver systems that better assure the safety and economy of the general public.
All of these segments depend on the ability to deliver innovative business solutions faster
and more efficiently than ever before. Each will employ a dual operating system: a
hierarchical model intended for efficiency and scale and a second, customer-centric network
operating system that delivers innovative solutions. The seven core competencies of SAFe
for Lean Enterprises instantiates this all-important second operating system. Those who
master these competencies will be those who survive and thrive in the new digital age.
Core Values
Find people who share your values, and you’ll conquer the world together.
—John Ratzenberger
The four Core Values of alignment, built-in quality, transparency, and program
execution represent the fundamental beliefs that are key to SAFe’s effectiveness. These
guiding principles help dictate behavior and action for everyone who participates in a SAFe
portfolio.
Details
SAFe is based on three primary bodies of knowledge: Agile Development, Lean Product
Development, and Systems Thinking. That makes SAFe broad, deep and scaleable. But at its
core, SAFe places the highest value on four things: alignment, built-in
quality, transparency, and program execution. These are illustrated in Figure 1 and
described in the following sections.
Figure 1. SAFe’s four core values
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 is needed to keep pace with fast change, disruptive competitive forces, and
geographically distributed teams. While empowered, Agile Teamsare good (even great), but
the responsibility for strategy and alignment cannot rest with the combined opinions of the
teams, no matter how good they are. Instead, alignment must rely on the Enterprise business
objectives. Here are some of the ways how SAFe supports alignment:
 Alignment starts with the strategy and investment decisions at the Portfolio level and
is reflected in Strategic Themes, Portfolio Vision, and the Portfolio Backlog. In turn,
this informs the Vision, Roadmap, and the backlogs at all levels of SAFe. Continuous
Exploration with Customer Centricity and Design Thinking gathers the inputs and
perspectives from a diverse group of stakeholders and information sources to ensure
that the items in the backlogs contain economically prioritized and refined work,
ready for teams to implement. All work is visible, debated, resolved and transparent.
 Alignment is supported by clear lines of content authority, starting with 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.
 Architectures and user experience guidance and governance help ensure that
the Solution is technologically sound, robust, and scalable.
 Economic prioritization keeps stakeholders engaged in continuous, agreed-to, rolling-
wave prioritization, based on the current context and evolving facts.
Alignment, however, does not imply or encourage top-down command and control.
Alignment occurs when everyone is working toward a common direction. Indeed, Alignment
enables empowerment, autonomy, and Decentralized Decision-making, allowing those who
implement value to make better local decisions.
Built-in Quality
“Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The
quality, good or bad, is already in the product. Quality cannot be inspected into a product or
service; it must be built into it.”
—W. Edwards Deming

Built-in Quality ensures that every element and every increment of the solution reflects
quality standards throughout the development lifecycle. Quality is not “added later.”
Building quality in 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 likely results.
Also the bigger the system, the more important endemic quality is, so there can be no
ambiguity about the importance of built-in quality in large-scale systems. It is mandatory.
Built-in quality is a major foundational element of SAFe, and since it’s impossible to
localize the quality discussion to every specific activity or artifact that affects quality, the
SAFe Built-in Quality article organizes quality thinking around five specific aspects—Flow,
Architecture and Design Quality, Code Quality, System Quality and Release Quality, as
Figure 2 illustrates.
Figure 2. Five primary dimensions of Built-In Quality
In addition, this article is augmented by three Advanced Topic articles, Agile

Testing, Behavior-Driven Development (BDD) and Test-Driven Development. Together, this
set of articles provides a fairly comprehensive starting point for achieving built-in quality in
large systems.
Transparency
Solution development is hard. Things go wrong or do not work out as planned. Without
openness, facts are obscure and decision-making is based on speculative assumptions and
lack of data. No one can fix a secret.
To ensure openness—trust is needed. Trust exists when the business and development can
confidently rely on another to act with integrity, particularly in times of difficulty. Without
trust no one can build high-performance teams and programs, nor build (or rebuild) the
confidence needed to make and meet reasonable commitments. And without trust, working
environments are a lot less fun and motivating.
Building trust takes time. Transparency is an enabler of trust, provided through several SAFe
practices:
 Executives, Lean Portfolio Management, and other stakeholders can see the Portfolio

Kanban and program backlogs, and they have a clear understanding of the PI
Objectives for each Agile Release Train or Solution Train.
 ARTs have visibility into the team’s backlogs, as well as other Program Backlogs.
 Teams and programs commit to short-term, visible commitments that they routinely
meet.
 Inspect and Adapt occurs with all relevant stakeholders and creates backlog
improvement items from lessons learned.
 Teams and Agile Release Trains (ARTs) can see portfolio business and enabler Epics.
They have visibility into new initiatives.
 Progress is based on objective measures of working solutions. (Principle #5)
 Everyone can understand the velocity and WIP of the teams and programs; strategy
and the ability to execute are visibly aligned.
 Programs execute reliably, as noted below.
Lean-Agile Leaders also play a critical role in creating an environment that fosters trust and
transparency.
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 business outcomes.
History shows us that while many enterprises start the transformation with individual Agile
teams, they often become frustrated as even those teams struggle to deliver more substantial
amounts of solution value, reliably and efficiently.
That is the purpose of the ART, and that is why SAFe focuses implementation initially
at Essential SAFe. In turn, the ability of Value Streams to deliver value depends on the
ability of the ARTs and Solution Trains.
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.
Leadership is Required
Successful scaled Lean-Agile development and these four core values require the active
support of Lean-Agile Leadership and a Continuous Learning Culture. Leaders couple these
core values with SAFe Lean-Agile Principles and practices and an orientation toward
creating value for customers. In turn, that creates a persistent and meaningful culture for the
teams and their stakeholders.
This is the way 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] http://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.
Last update: 18 September 2019
The information on this page is © 2010-2020 Scaled Agile, Inc. and is protected by US and
International copyright laws. Neither images nor text can be copied from this site without the
express written permission of the copyright holder. Scaled Agile Framework and SAFe are
registered trademarks of Scaled Agile, Inc. Please visit Permissions FAQs and contact us for
permissions.
Lean-Agile Mindset
“In a growth mindset, people believe that their most basic abilities can be developed
through dedication and hard work—brains and talent are just the starting point. This view
creates a love of learning and a resilience that is essential for great accomplishment.”
— Dr. Carol S. Dweck, Author and Psychology Professor at Stanford University
The Lean-Agile Mindset is the combination of beliefs, assumptions, attitudes, and actions of
SAFe leaders and practitioners who embrace the concepts of the Agile Manifesto and Lean
thinking. It’s the personal, intellectual, and leadership foundation for adopting and applying
SAFe principles and practices.
SAFe is firmly grounded in two bodies of knowledge: Lean and Agile. In fact, the genesis of
SAFe was to develop guidance for enterprises on how to apply the principles and practices of
Lean and Agile in the world’s largest organizations. For leaders, it requires a broader and
deeper Lean-Agile mindset to drive the organizational change required to adopt Lean and
Agile at scale across the entire enterprise.
The Lean-Agile mindset forms the cornerstone of a new management approach and an
enhanced company culture that enables Business Agility. It provides leadership with the
tools needed to drive a successful SAFe transformation, helping individuals and the entire
enterprise achieve their goals.
Details
Mindset Awareness and Openness to Change
A mindset is the mental lens through which we view the world around us. It is how the
human brain simplifies, categorizes, and interprets the vast amount of information it receives
each day. Through a lifetime of structured learning (classes, reading) and unstructured
lessons (life events, work experience), we form our mindsets. They reside in the
subconscious mind and manifest themselves as deeply held beliefs, attitudes, assumptions,
and influences. Consequently, individuals are often unaware of how their mindsets influence
how they carry out their responsibilities and interact with others. For example, many leaders
develop beliefs through business school training and on-the-job experiences that are
grounded in legacy waterfall, stage-gated, and siloed ways of working.
So how can mindsets be changed? It begins with an awareness of how one’s current mindsets
were formed. It’s also vital to cultivate the belief that mindsets can be developed and
improved (a ‘growth’ mindset, as illustrated in Figure 1). Leaders must remain open to the
possibility that existing mindsets based on traditional management practices need to evolve
in order to guide the organizational change required to become a Lean enterprise. [3]
Figure 1. Adopting a new mindset requires a belief that new abilities can be developed with effort
The next two sections describe the key elements of Lean and Agile that form the basis of the
Lean-Agile mindset.
Thinking Lean with the SAFe House of Lean

Initially derived from Lean manufacturing, the principles and practices of Lean thinking as
applied to software, product, and systems development are now deep and extensive [2]. For
example, Ward [3], Reinertsen [4], Poppendieck,[5], Leffingwell [6], and others have
described aspects of Lean thinking, placing many of the core principles and practices in a
product development context. Along with these, the SAFe House of Lean, as illustrated in
Figure 2, was inspired by houses of Lean from Toyota and others.
Figure 2. The SAFe House of Lean
The Goal – Value
The goal of Lean is to deliver the maximum customer value in the shortest sustainable lead-
time while providing the highest possible quality to customers and society as a whole. High
morale, safety, and customer delight are additional goals and benefits.
Pillar 1 – Respect for People and Culture

A Lean-Agile approach doesn’t implement itself or perform any real work—people do.
Respect for people and culture is a basic human need. When treated with respect, people are
empowered to evolve their practices and improve. Management challenges people to change
and may steer them toward better ways of working. However, it’s the teams and individuals
who learn problem-solving and reflection skills and are accountable for making the
appropriate improvements.
The driving force behind this new behavior is a generative culture, which is characterized by
a positive, safe, performance-centric environment [7]. Achieving this culture requires the
enterprise and its leaders to change first. The principle of respect for people and culture also
extends to relationships with Suppliers, partners, customers, and the broader community that
supports the Enterprise.
When there’s an urgency for positive change, transforming culture is possible. First,

understand and implement the SAFe values and principles. Second, deliver winning results.
The culture will change naturally over time.
Pillar 2 – Flow
The key to successfully executing SAFe is to establish a continuous flow of work that
supports incremental value delivery based on constant feedback and adjustment. Continuous
flow enables faster sustainable value delivery, effective Built-In Quality practices, relentless
improvement, and evidence-based governance based on working components of the solution.
The principles of flow are an essential part of the Lean-Agile mindset. These include
understanding the full Value Stream, visualizing and limiting Work in Process (WIP), and
reducing batch sizes and managing queue lengths. Additionally, Lean focus on identifying
and continuously removing delays and waste (non-value-added activities). One critical move
that organizations must address to achieve flow is the shift from a start-stop-start project
management process to an agile product management approach aligned to long-lived value
streams.
Lean-Agile principles provide a better understanding of the system development process by

incorporating new thinking, tools, and techniques. Leaders and teams can use them to move
from a phase-gated approach to a DevOps approach with a Continuous Delivery Pipeline that
extends flow to the entire value delivery process.
Pillar 3 – Innovation
Flow builds a solid foundation for value delivery. But without innovation, both product and
process will steadily decline. To support this critical part of the SAFe House of Lean, Lean-
Agile Leaders engage in the following practices:
 Hire, coach, and mentor innovation and entrepreneurship in the organization’s

workforce
 Go see…get out of the office and into the actual workplace where the value is
produced, and products are created and used (known as gemba). As Taiichi Ohno put
it, “No useful improvement was ever invented at a desk.”
 Provide time and space for people to be creative to enable purposeful innovation. This
can rarely occur in the presence of 100 percent utilization and daily firefighting.
SAFe’s Innovation and Planning Iteration is one such opportunity.
 Apply Continuous Exploration, the process of constantly exploring the market and
user needs, getting fast feedback on experiments, and defining a Vision, Roadmap,
and set of Features that bring the most promising innovations to market.
 Validate the innovation with customers, then pivot without mercy or guilt when the
hypothesis needs to change.
 Engage both top-down strategic thinking with organic team-based innovations to
create a synergistic ‘innovation riptide’ that powers a tidal wave of new products,
services, and capabilities.
Pillar 4 – Relentless Improvement

The fourth pillar, relentless improvement, encourages learning and growth through
continuous reflection and process enhancements. A constant sense of competitive danger
drives the company to pursue improvement opportunities aggressively. Leaders and teams do
the following:
 Optimize the whole, not the parts, of both the organization and the development
process
 Reinforce the problem-solving mindset throughout the organization, where all are
empowered to engage in daily improvements to the work
 Reflect at key milestones to openly identify and address the shortcomings of the
process at all levels
 Apply Lean tools and techniques to determine the fact-based root cause of
inefficiencies and apply effective countermeasures rapidly
Additional guidance on the importance of innovation and relentless improvement in
achieving business agility can be found in the Continuous Learning Culture competency
article.
Foundation – Leadership
The foundation of Lean is leadership, a key enabler for team success. Leaders are ultimately
responsible for the successful adoption of the Lean-Agile approach. According to
management consultant and efficiency expert W. Edwards Deming, “Such a responsibility
cannot be delegated” [8] to direct reports, Lean-Agile champions, working groups, a
Program Management Office (PMO), process teams, outside consultants, or any other party.
Therefore, leaders must be trained in these new and innovative ways of thinking and exhibit
the principles and behaviors of Lean-Agile leadership.
From a leadership perspective, Lean is different than Agile. Agile was developed as a team-
based process for a small group of cross-functional, dedicated individuals who were
empowered, skilled, and needed to build working functionality in a short time box.
Management was not part of this definition. But excluding management from the way of
working doesn’t scale in an enterprise. By contrast, in Lean, managers are leaders who
embrace the values of Lean, are competent in the basic practices, and teach these practices to
others. They proactively eliminate impediments and take an active role in driving
organizational change and facilitating relentless improvement.
Additional guidance on leadership as the foundation of Lean-Agile transformation using

SAFe can be found in the Lean-Agile Leadershipcompetency article.
Embracing Agility with the Agile Manifesto

In the 1990s, responding to the many challenges of waterfall processes, some lighter-weight
and more iterative development methods emerged. In 2001, many leaders of these
frameworks 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 shared values
and beliefs dwarfed the differences. The result was a Manifesto for Agile Software
Development—a turning point that clarified the new approach and started to bring the
benefits of these innovative methods to the whole development industry. [9] In the years
since the Manifesto was first published, Agile has been adopted by domains outside of
software development, including hardware systems, infrastructure, operations, and support.
More recently, business teams outside of technology have also embraced Agile principles for
planning and executing their work.
The Values of the Agile Manifesto
The Manifesto consists of the value statement shown in Figure 3:

Figure 3. Values of the Agile Manifesto
We Are Uncovering Better Ways
The first phrase of the manifesto deserves emphasis: “We are uncovering better ways of
developing software by doing it and helping others do it.”
We interpret this as describing an ongoing journey of discovery to increasingly embrace
Agile behaviors, a journey with no end. SAFe is not a fixed, frozen-in-time framework. As
soon as we uncover better ways of working, we adapt the framework, as evidenced by more
than six major releases as of the current version (SAFe 5.0).
Where We Find Value
We’ll discuss the four values of the Agile Manifesto shortly, but the final phrase is also
important and sometimes overlooked: “That is, while there is value in the items on the right,
we value the items on the left more.”
Some people may misinterpret the value statements as a binary decision between two choices
(e.g., working software versus comprehensive documentation), but that’s not the intended
meaning. Both items have value; however, the item on the left has more value (i.e., working
software). The Agile Manifesto is not rigid or dogmatic. Instead, it embraces the need to
balance the values based on the context.
Individuals and Interactions over Processes and Tools
Deming notes, “If you can’t describe what you are doing as a process, then you don’t know
what you are doing.” So, agile processes in frameworks like Scrum, Kanban, and SAFe do
matter. However, a process is only a means to an end. When we’re captive to a process that
isn’t working, it creates waste and delays. So, favor individuals and interactions, then modify
processes accordingly.
In a distributed environment, tools are critically important to assist with communication and
collaboration (e.g., video conferencing, text messaging, ALM tools, and wikis). This is
especially true at scale. However, tools should supplement, rather than replace, face-to-face
communication.
Working Software over Comprehensive Documentation
Documentation is important and has value. But creating documents for the sake of
complying with potentially outdated corporate governance models has no value. As part of a
change program, governance, often captured by documentation standards, needs to be
updated to reflect the Lean-Agile way of working. Rather than create detailed documentation
too early—especially the wrong kind—it’s more valuable to show customers working
software to get their feedback. Therefore, favor working software. And document only
what’s truly needed.
Customer Collaboration over Contract Negotiation
Customers are the ultimate deciders of value, so their close collaboration is essential in the
development process. To convey the rights, responsibilities, and economic concerns of each
party, contracts are often necessary—but recognize that contracts can over-regulate what to
do and how to do it. No matter how well they’re written, they don’t replace regular
communication, collaboration, and trust. Instead, contracts should be win–win propositions.
Win–lose contracts usually result in poor economic outcomes and distrust, creating
contentious short-term relationships instead of long-term business partnerships. Instead,
favor customer collaboration.
Responding to Change over Following a Plan
Change is a reality that the development process must reflect. The strength of Lean-Agile
development is in how it embraces change. As the system evolves, so does the understanding
of the problem and the solution domain. Business stakeholder knowledge also improves over
time, and customer needs evolve as well. Indeed, those changes in understanding add value
to our system.
Of course, the manifesto phrase “over following a plan” indicates that there is, in fact, a plan!
Planning is an important part of Agile development. Indeed, Agile teams and programs plan
more often and more continuously than their counterparts using a waterfall process.
However, plans must adapt as new learning occurs, new information becomes visible, and
the situation changes. Worse, evaluating success by measuring conformance to a plan drives
the wrong behaviors (e.g., following a plan in the face of evidence that the plan is not
working).
Agile Manifesto Principles
The Agile Manifesto shown in Figure 4 has 12 principles that support its values. These
principles take those values a step further and specifically describe what it means to be
Agile.
Figure 4. Principles of the Agile Manifesto
Most of these principles are self-explanatory. They need no elaboration, except for a
discussion of applying the Agile Manifesto at scale, which is covered next.
The combination of values and principles in the manifesto creates a framework for what the
Snowbird attendees believed was the essence of Agile. There is mounting evidence from
success stories in all industries across every geography demonstrating the extraordinary
business and personal benefits conferred by this new way of thinking and working. We are
grateful for it.
Applying the Agile Manifesto at Scale
The brief document that launched this massive movement is more than 19 years old. Since
then, not one word has changed. So, it’s fair to ask, given all the advancements in the last 19
years: Is the Agile Manifesto still relevant? Or should it be treated like a historical document
that has long since served its purpose?
What’s more, Agile was defined for small, potentially fast-moving software-only teams. And
that raises another valid question: Does the Agile Manifesto scale? Does it meet the needs of
enterprises developing the biggest and most complex software and systems? Does it serve the
needs of systems that require hundreds of people to build them and have unacceptably high
costs of failure? What about non-technical teams throughout the enterprise who are
beginning to adopt many of the values and principles of the manifesto? Feedback from the
20,000+ organizations using the Agile guidance in SAFe indicates that the Agile
Manifesto does indeed scale. However, many principles require increased emphasis at scale,
while others require a more expanded perspective. The Agile Manifesto remains as relevant
today as ever, perhaps even more so. We’re fortunate to have it, and it plays a vital role in
SAFe.
SAFe integrates the values and principles of the Agile Manifesto throughout the framework.
For example, Principles 1 and 3 describe the frequent delivery of value to the customer.
SAFe practices promote delivery as frequently as possible (as often as multiple times daily)
to benefit the customer and to provide the validated learning that improves future
development. SAFe’s System Demo at the end of every iteration and the PI System Demo
and Solution Demo at each PI boundary evaluate progress based on working products and
components. SAFe integrates business and product owners and product and solution
managers into backlog refinement, demos, PI planning, Inspect & Adapt, and more, which
illustrates its commitment to Principle 4. Team Retrospectives, as well as the Inspect &
Adapt events for ARTs and Solution Trains, support Principle 12 of the Manifesto. From top
to bottom, SAFe embraces Agile and incorporates its best practices throughout the
enterprise.
Lean-Agile leaders advance the adoption of Agile by first gaining in-depth knowledge of
Agile principles and then leading by example through incorporating Agile practices into how
they perform their responsibilities. They do this through training, self-study, applying what
they learn, and discussing breakthroughs and challenges with their peers. Leaders also
support their teams as they embrace the Lean-Agile mindset by providing training, by
providing coaching, and by being a model for others to follow.
Learn More
[1] Dweck, Carol S. Mindset: The New Psychology of Success. Random House Publishing.
Kindle Edition.
[2] 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.
[3] Ward, Allen and Durward Sobeck. Lean Product and Process Development. Lean
Enterprise Institute, 2014.
[4] Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation
Lean Product Development. Celeritas, 2009.
[5] Poppendieck, Mary and Tom Poppendieck. Implementing Lean Software Development:
From Concept to Cash. Addison-Wesley, 2006.
[6] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for
Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
[7] Accelerate: The 2018 State of DevOps Report.
http://services.google.com/fh/files/misc/state-of-devops-2018.pdf
[8] Deming, W. Edwards. Out of the Crisis. MIT Center for Advanced Educational Services,
1982.
[9] Manifesto for Agile Software Development. http://agilemanifesto.org/.
Last update: 3 February 2020
permissions.
SAFe Lean-Agile 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.
SAFe is based on ten immutable, underlying Lean-Agile principles. These tenets and
economic concepts inspire and inform the roles and practices of SAFe.
Figure 1. SAFe Lean-Agile Principles

Why the Focus on Principles?
Building enterprise-class software and cyber-physical systems is one of the most complex
challenges our industry faces today. And, of course, the enterprises that build these systems
are also increasingly sophisticated. They are bigger and more distributed than ever. Mergers
and acquisitions, distributed multinational (and multilingual) development, offshoring, and
rapid growth are all part of the solution. But they’re also part of the problem.
Fortunately, we have an amazing and growing body of knowledge that can help. It includes
Agile principles and methods, Lean and systems thinking, product development flow
practices, and Lean processes. Thought leaders have traveled this path before us and left a
trail in hundreds of books and references to draw on.
The goal of SAFe is to synthesize this body of knowledge, along with the lessons learned
from hundreds of deployments. This creates a system of integrated, proven practices that
have improved employee engagement, time-to-market, solution quality, and team
productivity. Given the complexities, however, there’s no off-the-shelf solution for the
unique challenges each enterprise faces. Not every SAFe recommended practice will apply
equally in every circumstance. This is why we work hard to ensure that SAFe practices are
grounded in fundamentally stable principles. That way we can be confident the practices
apply in most situations.
And if those practices do fall short, the underlying principles will guide the teams to make
sure that they are moving continuously on the path to the goal of the House of Lean:
“shortest sustainable lead time, with best quality and value to people and society.” There is
value in that, too.
SAFe is based on ten fundamental concepts that have evolved from Agile principles and
methods, Lean product development, systems thinking, and observation of successful
enterprises. Each is described in detail in an article by that principle’s name. In addition, the
embodiment of the principles appears throughout the Framework. They are summarized in
the following sections, and each has a full article behind the link.
#1 – Take an economic view

Delivering the ‘best value and quality for people and society in the shortest sustainable lead
time’ requires a fundamental understanding of the economics of building systems. Everyday
decisions must be made in a proper economic context. This includes the strategy for
incremental value delivery and the broader economic economic framework for each value
stream. This framework highlights the trade-offs between risk, Cost of Delay (CoD),
manufacturing, operational, and development costs. In addition, every value stream must
operate within the context of an approved budget, and be compliant to the guardrails which
support decentralized decision-making.
#2 – Apply systems thinking
Deming observed that addressing the challenges in the workplace and the marketplace
requires an understanding of the systems within which workers and users operate. Such
systems are complex, and they consist of many interrelated components. But optimizing a
component does not optimize the system. To improve, everyone must understand the larger
aim of the system. In SAFe, systems thinking is applied to the system under development, as
well as to the organization that builds the system.
#3 – Assume variability; preserve options

Traditional design and life cycle practices encourage choosing a single design-and-
requirements option early in the development process. Unfortunately, if that starting point
proves to be the wrong choice, then future adjustments take too long and can lead to a
suboptimal design. A better approach is to maintain multiple requirements and design
options for a longer period in the development cycle. Empirical data is then used to narrow
the focus, resulting in a design that creates optimum economic outcomes.
#4 – Build incrementally with fast, integrated learning cycles

Developing solutions incrementally in a series of short iterations allows for faster customer
feedback and mitigates risk. Subsequent increments build on the previous ones. Since the
‘system always runs’, some increments may serve as prototypes for market testing and
validation; others become minimum viable products (MVPs). Still others extend the system
to with new and valuable functionality. In addition, these early, fast feedback points help
determine when to ‘pivot,’ where necessary to an alternate course of action.
#5 – Base milestones on objective evaluation of working systems

Business owners, developers, and customers have a shared responsibility to ensure that
investment in new solutions will deliver economic benefit. The sequential, phase-gate
development model was designed to meet this challenge, but experience shows that it does
not mitigate risk as intended. In Lean-Agile development, integration points provide
objective milestones at which to evaluate the solution throughout the development life cycle.
This regular evaluation provides the financial, technical, and fitness-for-purpose governance
needed to assure that a continuing investment will produce a commensurate return.
#6 – Visualize and limit WIP, reduce batch sizes, and manage queue
lengths
Lean enterprises strive to achieve a state of continuous flow, where new system capabilities
move quickly and visibly from concept to cash. Keys to implementing flow are:
1. Visualize and limit the amount of work in process (WIP). This increases throughout and
limits demand to actual capacity.
2. Reduce the batch sizes of work to facilitate fast and more reliable flow.
3. Manage queue lengths to reduce the wait times for new functionality.
#7 – Apply cadence, synchronize with cross-domain planning

Cadence creates predictability and provides a rhythm for development. Synchronization
causes multiple perspectives to be understood, resolved, and integrated at the same time.
Applying development cadence and synchronization, coupled with periodic cross-domain
planning, provides the mechanisms needed to operate effectively in the presence of the
inherent development uncertainty.
#8 – Unlock the intrinsic motivation of knowledge workers

Lean-Agile leaders understand that ideation, innovation, and employee engagement are not
generally motivated by individual incentive compensation. Such individual incentives can
create internal competition and destroy the cooperation necessary to achieve the larger aim of
the system. Providing autonomy and purpose, minimizing constraints, creating an
environment of mutual influence, and better understanding the role of compensation are keys
to higher levels of employee engagement. This approach yields better outcomes for
individuals, customers, and the enterprise.
#9 – Decentralize decision-making
Achieving fast value delivery requires decentralized decision-making. This reduces delays,
improves product development flow, enables faster feedback, and creates more innovative
solutions designed by those closest to the local knowledge. However, some decisions are
strategic, global, and have economies of scale that justify centralized decision-making. Since
both types of decisions occur, creating a reliable decision-making framework is a critical step
in empowering employees and ensuring a fast flow of value.
#10 – Organize around value

Many enterprises today are organized around principles developed during the last century. In
the name of intended efficiency, most are organized around functional expertise. But in the
digital age, the only sustainable competitive advantage is the speed with which an
organization can respond to the needs of its customers with new and innovative solutions.
These solutions require cooperation amongst all the functional areas, with their incumbent
dependencies, handoffs, waste and delays. Instead, Business Agility demands that enterprises
organize around value to deliver more quickly. And when market and customer demands
change, the enterprise must quickly and seamlessly reorganize around that new value flow.
Last update: 30 August 2019
permissions.
Customer Centricity
The most important single thing is to focus obsessively on the customer. Our goal is to be
earth’s most customer-centric company.
—Jeff Bezos
Customers are the ultimate beneficiaries of the value of the business solutions created and
maintained by the portfolio value streams.
Customer centricity is a mindset and a way of doing business that focuses on creating
positive experiences for the customer through the full set of products and services that the
enterprise offers.
Customer-centric businesses generate greater profits, increased employee engagement, and

more satisfied customers. Customer-centric governmentsand nonprofits create the resiliency,
sustainability, and alignment needed to fulfill their mission. All customer-centric enterprises
deliver whole-product solutions that are designed with a deep understanding of customer
needs.
Note: This article focuses on the mindset and impact of customer centricity. It should be
read with the Design Thinking article, which focuses on the tools and practices of
implementing design thinking in support of customer centricity.
Details
Customer centricity is a mindset: Whenever a customer-centric enterprise makes a decision,
it deeply considers the effect it will have on its end users. This motivates us to:
 Focus on the customer – Customer-centric enterprises use segmentation to align and

focus the enterprise on specific, targeted user segments
 Understand the customer’s needs – Customer-centric enterprises move beyond
merely listening to customers who ask for features. Instead, they invest the time to
identify underlying and ongoing customer needs
 Think and feel like the customer – Customer-centric enterprises try to see the world
from their customer’s point of view
 Build whole product solutions – Customer-centric enterprises design a complete
solution for the user’s needs, ensuring that the initial and long-term experience of the
customer is always ideal and evolving as needed
 Know customer lifetime value – Customer-centric enterprises move beyond a
transactional mentality and instead focus on creating longer term relationships based
on a clear and accurate understanding of how the customer derives value from the
solution
Research Driven
The foundation of the customer-centric enterprise is market and user research that creates
actionable insights into the problems customers face, the solution requirements, and the
solution context. Market research tends to drive strategy; user research tends to drive design,
as highlighted in Figure 1 below.
Figure 1. Market and User Research explore different aspects of the problem and solution space
Research activities occur continuously and are directly supported through Continuous

Exploration in the Continuous Delivery Pipeline, product telemetry data, and the feedback
loops that exist between the solution and the Solution Context.
Design with Empathy

Customer-centric enterprises apply empathic design throughout the design process. Empathic
design refers to our ability to put aside our preconceived ideas and develop solutions from
the perspective of our customers. [1]
Empathic design motivates teams to understand and experience the world from the
customer’s perspective, learning and appreciating the difficulties they face, their roles, and
their work context. It emphasizes user research, including activities such as Gemba walks
(visiting the place where the customer work is done). Gemba builds empathy by helping
agile teams to gain a deeper understanding of the user’s emotional and physical needs—the
way they see, understand and interact with the world around them.
Empathic design guides the development of solutions that move beyond functional needs,
also addressing:
 Aesthetic and emotional needs
 Ergonomic needs, such as the placement of physical features
 Product attributes that may not be explicitly requested by users, such as performance,
security and compliance, but which are essential for viability
 An understanding of how the solution may impact the solution context
 The impact of the solution on related or affected groups
 That the architecture of the solution ensures that operations, maintenance, and support
account for the needs of the customer
Degrees of Customer Engagement

Market research helps us determine the nature of the relationship we create with our
customers. This is largely determined by whether the solution is a:
 General solution – intended to be used by a significant number of customers

 Custom-built solution – built and designed for an individual customer
Figure 2 illustrates the relative level of indirect or direct customer engagement in each case
Figure 2. Customer engagement models in general and custom-built solutions

General Solutions
General solutions must address the needs of a broader market or segment in which no single
customer adequately represents the whole market. In this case, Product and Solution
Management become the indirect customer proxy; they have authority over solution content.
It’s their responsibility to facilitate external interaction and make sure that the “voice of the
customer” will be heard, and that the organization will continuously validate new ideas.
Scope, schedule, and budget for development are generally at the discretion of the
internal Business Owners.
Since it’s unlikely that any customer will participate regularly in planning and system demo
sessions, customer interaction is typically based on requirements workshops, focus groups,
usability testing, and limited beta releases. To validate various hypotheses, the solution
evolves through feedback from user behavior analysis, metrics, and business intelligence.
Custom-Built Solutions
For custom-built solutions, external customers collaborate with Product and Solution
Management in joint design efforts. While the customer is leading the effort, deliverables,
sequencing, and timing are negotiated. This promotes incremental learning and creates
opportunities to adjust plans based on the best available data.
SAFe’s focus on cadence-based development directly supports the collaborations that create
the best outcomes in custom-built solutions. For example, PI Planning provides the time and
space to align all stakeholders around the next set of deliverables. The successful completion
of the Program Increment establishes a high degree of trust in the joint development process
and generates data that improves forecasting and economic modeling.
Deep and Narrow Solutions
In the zone between general solutions and custom solutions are deep andnarrow solutions. A
deep and narrow solution has a small number of customers that will often pay a significant
amount of money for these products and services. For example, a solution to manage
logistics for stadiums of more than 50,000 seats will serve a total potential market of less
than 400 total customers.
While maintaining the discipline of creating a single solution that answers a target’s market
needs, these Product and Solution Managers must leverage their familiarity with the small
number of customers they’re serving.
Multi-Segment Solutions
Some solutions serve disparate market segments in which each segment uses the solution in
slightly different ways. In this situation, customer centricity means understanding the unique
needs of each segment even if the solution serves multiple segments.
For example, a B2C software company serving hundreds of thousands to millions of indirect
customers via a website may also offer a set of developer APIs to partners. Members of this
B2B partner segment may act more like customers of custom-built solutions, each making
specific requests of the software provider to adjust, extend, or improve the API to better meet
their unique needs. The goals of customer-centricity in kind of solution is to understand the
needs of both the B2C and B2B segments and establish a roadmap that continues to serve
each.
Whole Product Thinking

Customers never purchase a “generic” solution like a dishwasher or hotel room. Rather, they
buy a specific product from a specific vendor. It’s the design of this solution that determines
the degree of perceived and actual value; i.e., how effectively this solution meets the
customer’s total needs.
Whole Product Thinking [4] helps ensure that the products and solutions being created for
customers to fulfill their needs (Figure 3):
 The generic product is often considered the “minimal offering” of a product. For a

dishwasher, that would be the ability to wash dishes and nothing more. For a hotel, it
might be a clean room and little else.
 The expected product represents the customer’s minimal purchase conditions as
informed by alternative or competing products. For example, a dishwasher without
different cycles or a timed delay start may not meet current market expectations.
 The augmented product goes beyond what is expected and enables competitors to
differentiate their offerings. A dishwasher that provides a mobile phone app to signal
when the washing cycle has completed may qualify.
 The potential product represents everything that might be done to attract and keep
customers. Informed by research, it fuels longer-term strategic planning and creates
opportunities for sustainable product advantages.
Figure 3. Whole Product Model
Leveraging Market Rhythms and Events

The Lean-Agile Mindset that drives the continuous and sustainable flow of value to
customers motivates the customer-centric organization to understand how timing of specific
releases influences their perceived value. Simply put, the value of a release can vary
significantly based on when it is released.
To create the highest value for all stakeholders, customer-centric organizations leverage
market rhythms and market events: [3]
 A market rhythm is a set of events that occur repeatedly on a predictable cadence. For
example, retailers routinely prepare for the holiday shopping season by upgrading
their systems to gain a competitive edge to support significantly higher transaction
volumes.
 A market event is a one-time future event, which has a high probability of materially
affecting one or more solutions. They can be external, such as the launch of
government regulations, or they can be internally created, such as a company’s annual
user conference.
Understanding Market Rhythms
Market rhythms help companies recognize and capitalize on opportunities that are
predictable and require longer-term planning.
Figure 4 illustrates an example of the market rhythms of three different companies. The
vertical axis shows the value delivered to a market, while the horizontal axis depicts the
value over time, usually a calendar or fiscal year. The green line in Figure 1 represents a
social media company where the value over time is relatively constant, which suggests it is
less affected by market rhythms [3].
The next two examples in Figure 4 show more typical market rhythms for companies that
must get their products ready for release responding to a well-known rhythm. A B2B
software provider who markets real-time pricing software updates must issue important alerts
well in advance of the shopping season. (Imagine updating every point of sale terminal in
400 different stores – and training all employees on the new capabilities!) Similarly, the “hot
new toy” of the Holiday shopping season won’t seem so hot or new in January!
Figure 4. An example of market rhythms for different types of companies
Capturing Market Events
Armed with the understanding of market rhythms, customer-centric road-mapping activities

typically focus on the impact of market events. In Figure 4, we show three common events:
the release of new regulations, expected moves of a competitor, and technology changes and
upgrades.
Figure 5. An example of market events
Market events are typically represented as milestones, and they strongly impact the timing
for releasing solutions. They may also inform the content and timing of features or solution
development activities identified during Program Increment (PI) planning.
Understanding the Solution Context

Insights gained from the Gemba walks and other research activities define the functional and
operational requirements of the solution’s operating environment. In SAFe, this is known as
the Solution Context, which captures environmental, installation, operation, and support
requirements.
Understanding Solution Context is crucial to value delivery. It identifies constraints outside

the organization’s control. As examples, consider the icy roads that a self-driving vehicle
must navigate, or the regulations with which it must comply. Solution Context also describes
the negotiated constraints, such as when the organization uses principles of set-based design
and collaborates with one or more Suppliers to optimize the total system’s space, power
requirements, and weight.
Accordingly, some aspects of Solution Context are fixed, and some are negotiable; this
creates a level of coupling between the Solution, Suppliers, and the Solution Context. The
mandate of Business Agility motivates Product and Solution Managers to seek optimal
solutions, including changing the Solution Context to encourage innovation.
Understanding Customer Value

Creating viable and sustainable offerings requires a deep understanding of the customer’s
perception of value. Consider a for-profit enterprise that has identified a customer problem
that will cost them $800K to solve. If the customer perceives less than $800K in value from
the solution, the organization will be unable to sell it a price that creates a viable offering.
And even if the customer perceives more than $800K in value, suggesting the enterprise can
make a profit, the solution may not be sustainable if the revenue is insufficient to fund new
and ongoing work.
There are two primary means by which a customer derives value from products and
solutions, 1) reducing their costs and 2) increasing their revenue (Table 1).
Cost Reduction Revenue Enhancement

Is less expensive to purchase Accelerates their time-to-market
Lowers operational costs Creates access to new markets
Streamlines workflows Creates new product offerings
Reduces labor costs Creates opportunities for service revenue
Reduces compliance costs
Table 1: Elements of customer value
There are a number of other aspects of value as well. Secondary aspects of value derivation
include such things as brand value, and the alignment of values between the customer and
the enterprise [3].
Learn More
[1] Leonard, Dorothy, and Jeffrey F. Rayport. Spark Innovation Through Empathic Design.
Harvard Business Review, December, 1997.
[2] Moore, Geoffrey. Escape Velocity: Free Your Company’s Future from the Pull of the
Past. HarperBusiness, 2011.
[3] Hohmann, Luke. Beyond Software Architecture: Creating and Sustaining Winning
Solutions. Addison-Wesley Professional, 2003.
[4] Levitt, Theodore. Marketing Success Through Differentiation—of Anything.Harvard
Business Review, January, 1980.
Last update 28 October 2019
permissions.
Design Thinking
Good design is actually a lot harder to notice than poor design, in part because good
designs fit our needs so well that the design is invisible, serving us without drawing attention
to itself. Bad design, on the other hand, screams out its inadequacies, making itself very
noticeable.
—Don Norman, The Design of Everyday Things
Design Thinking is a customer-centric development process that creates desirable products

that are profitable and sustainable over their lifecycle.
It goes beyond the traditional focus on the features and functions of a proposed product.
Instead, it emphasizes understanding the problem to be solved, the context in which the
solution will be used, and the evolution of that solution.
Note: This article focuses on the tools and practices associated with implementing design
thinking. It should be read along with the Customer Centricity article, which focuses on the
mindset and impact of customer centricity.
Details
Traditional waterfall approaches to product development are sequential: requirements are
defined; then, solutions are designed, built, and delivered to the market. The focus tends to
be on the most apparent problems. Often, success is determined by implementing a solution
that meets the requirementsinstead of the needs of the user, resulting in products and services
with unusable or ignored features that frustrate users and fail to meet the business goals of
the enterprise.
Design thinking (Figure 1) represents a profoundly different approach to product and
solution development, in which divergent and convergent techniques are applied to
understand a problem, design a solution, and deliver that solution to the market.
Figure 1. Design thinking activities
Design thinking also inspires new ways to measure the success of our efforts:
 Desirable – Do customers and users want the solution?

 Feasible – Can we deliver the right solution through a combination of build, buy,
partner, or acquire endeavors/activities?
 Viable – Is the way we build and offer the solution creating more value than cost? For
example, in a for-profit enterprise, are we profitable?
 Sustainable – Are we proactively managing our solution to account for its expected
product-market lifecycle?
Successive applications of design thinking advance the solution over its natural market
lifecycle, as shown in Figure 2.
Figure 2. Advancing the solution over the solution lifecycle through design thinking
The Problem Space and the Solution Space
In Figure 1, the core processes of design thinking appear visually as a ‘double diamond’.
This represents the focus on thoroughly exploring the problem space before creating
solutions. The activities associated with exploring the problem are elaborated as follows:
 Discover – The discover phase seeks to understand the problem by engaging in

market and user research to identify unmet needs. This creates fresh perspectives that
drive innovation. Unlike research that confirms or refutes a hypothesis, the inquiries
associated with the discovery phase occur without preconceived notions about how
users should work. Instead, it focuses on how users do work. An essential research
technique is Gemba, also known as, “going to the place where the work is done.”
 Define – The define phase focuses on the information gathered during the discover
phase, using convergent techniques to generate insights into the specific problems
and/or unmet needs. These create opportunities for the enterprise and new product
development. Results of this phase typically include personas and empathy maps
(described further below) that focus the product team on the kinds of solutions the
customer would view as desirable. Epics and Features capture the perceived changes
needed for existing products and solutions.
With a clear understanding of the target market and the problems it’s facing, the enterprise
can move towards designing a solution, the second diamond of design thinking. These are:
 Develop – The develop phase uses journey mapping, story mapping, and prototyping
to design potential solutions to problems quickly and cost-effectively. Each of these
techniques is discussed more thoroughly later in this article. The develop phase also
embraces SAFe Principle #3 – Assume variability; preserve options, using design
techniques to preserve options in a responsible manner.
 Deliver – The deliver phase produces artifacts that are suitable for creating the
solution and vary based on context. They often start as prototypes that are expressed
as a validated set of Features in the Program Backlog for ongoing delivery through
the Continuous Delivery Pipeline.
Note that each diamond focuses on divergent thinking (understanding, exploring options)
followed by convergent thinking (evaluating options and making choices).
Using Personas to Focus Design

Bespoke solutions offer designers the advantage of speaking directly and frequently with a
few targeted users, permitting them to participate in design meetings, PI Planning, System
Demos, and other SAFe events. In several organizations, these people are considered part of
the team, so creating a Persona to represent them isn’t typically needed, but may be helpful
when the organization is highly distributed.
In contrast, in an indirect customer market, which is common in B2C solutions, product
teams need a way to maintain a connection with their target customer. So, they develop
‘personas’, fictional consumers and/or users derived from customer research. [2] They depict
the different people who might use a product or solution in a similar way, providing insights
into how real users would engage with a solution. User personas also support market
segmentation strategy by offering a concrete design tool to reinforce that products and
solutions are created for people. Personas drive product development and several SAFe
practices, as shown in Figure 3.
Figure 3. How Personas can drive key activities in SAFe
In addition to user personas, buyer personas extend design thinking to include the individuals

and organizations that authorize purchasing decisions. They help ensure that the design
encompasses the whole product purchase experience, including after-sales service, support,
and operations.
Establish Empathy Through Empathy Maps
Customer-centric enterprises use empathy throughout the design process. Broadly speaking,
empathetic design dismisses preconceived ideas and uses the customer’s perspective to
inform solution development.
Empathy maps[1] are a design thinking tool that promote customer identification by helping
teams develop deep, shared understanding for others (Figure 4). They help teams imagine
what a specific persona is thinking, feeling, hearing, and seeing as they use the product. The
greater the degree of empathy that a team has for their customer, the more likely the team
will be able to design a desirable solution.
Figure 4. Empathy Map Canvas
Designing the Customer Experience through Journey Maps

A customer journey map illustrates the experience as a user engages with a company’s
operational value stream, products, and services. As shown in Figure 5, journey maps are
powerful design thinking tools for operational Value Streams. They allow teams to identify
ways in which the specific deliverables of one or more Development Value Streams can be
improved to create a better end-to-end experience.
Figure 5. Operational Value Streams and Customer Journey Maps
Delivering Benefits Through Features

While a journey map captures the high-level experience of the customer through the
operational value stream, product Features manage the specific deliverables that fulfill a
stakeholder need. Features are commonly described through a features and benefit matrix
using short phrases that provide context and a hypothesis of the benefits that the user
experiences.
Design thinking practices promote changing the order in which we consider elements of the
Feature-Benefit Hypothesis. They help Agile teams explore better and faster ways to deliver
the desired benefits (Figure 6).
Figure 6. The traditional ‘features and benefits’ matrix becomes a ‘benefits and features’ matrix
Designing User Workflows through Story Maps

Features are implemented through one or more Stories. There are two types of stories in
SAFe:
 User Stories are the primary means of expressing needed functionality. They can be
written in a role format or a persona format:
Role: As a <user role> I want <activity/goal> so that <some reason, such as creating
business value or personal value>
Persona: Frank wants to <activity/goal> so that Frank gets <value>
 Enabler Stories capture system, architecture, or infrastructure requirements, such as

building improvements to support the continuous delivery pipeline.
The Team Backlog contains user and enabler Stories that originate from the Program
Backlog, as well as stories that arise from the team’s local context. Like all backlogs, the
Team Backlog is prioritized, and stories are implemented in priority order.
Features that capture a workflow present a unique challenge to Agile teams: A workflow is a
sequence of steps that must be completed to accomplish a higher-level user goal. The linear
order of a backlog can make it hard for Agile Teams to understand the relationships between
the steps. Frequently a given step can be improved, and teams must also balance
completeness (all of the steps must be supported) before improving a specific set of steps.
Potential conflicts arise when the divergent phase of developing a solution envisions
improvement opportunities, while the convergent phase of design thinking focuses on what’s
essential for the next release.
Solutions contain both large and small workflows. Consider the small workflow of a
businessperson importing a credit card statement into an expense reporting system for
processing. The user must:
 Download the credit statement from the bank

 Upload the credit card statement into the expense reporting system
 Match transactions from the credit card statement with expense receipts stored in the
expense reporting system
 Remove any non-reimbursable transactions
As described earlier, each of these stories can be captured in a workflow. Moreover, each can
be improved over time: We could, for example, imagine a direct connection between the
bank and the expense reporting system, or an automated AI agent that managed the task of
matching transactions.
Features that represent a workflow are captured through story maps [3], which organize a
sequence of stories according to the tasks a user needs to accomplish their goal (Figure 7).
Figure 7. Sample Story Map
Story maps enable teams to understand how the stories in the team backlog support user
objectives (Figure 8).
Figure 8. Relationship between Story Maps and Team Backlogs
Story maps also clarify the relationships between quality and value:
 Quality – Each Story in the backlog must be completed with quality

 Value – All the selected Stories in the Story Map must be completed to create value,
because if a Story is missed, the user cannot complete their workflow
Increasing Design Feedback Through Prototypes

A prototype is a functional model of the Feature or Product we wish to build. It helps the
design team clarify their understanding of the problem and reduces risk in developing a
solution. Prototypes provide a myriad of benefits to product teams:
 Fast feedback. By definition, a prototype is cheaper and faster to produce than a full
solution. This enables faster feedback from users and customers, increased
understanding of solution requirements, and greater confidence in the final designs.
 Risk reduction. Prototypes can reduce technical risk by enabling development teams
to focus initial efforts on the aspects of the solution associated with the highest risk.
 Intellectual property / patent filing. Prototypes can be used to satisfy strategic
requirements for managing intellectual property as early as possible in the
development process.
 Models for requirements. Prototypes can provide more clarity in the requirements of
the desired feature or solution than pages of documentation.
There are many kinds of prototypes, each optimized to provide different types of insights:
 Paper prototypes are typically hand-drawn sketches of the intended solution. They

can be automated to illustrate workflows as complements to user story maps.
 Mid-Fi prototypes are visually-complete representations of software-centric
solutions but are not typically functionally integrated.
 Hi-Fi prototypes are visually-complete and interactive models which users and
customers can directly explore.
 Hardware prototypes provide critical feedback to the development team on such
things as form factors, sizes, and operational requirements. For example, when
exploring form factors to see how a new tablet might fit into existing backpacks,
briefcases and cars, one Silicon Valley company simply cut a multitude of plastic
models from a single sheet plastic. Later in this design process, this same team found
they needed to redesign the power supply so that it would not unduly interfere with
the WIFI signal.
To help them gain actionable feedback, product teams should strive to leverage the lowest-
cost, fastest form of prototyping. Often, paper prototyping is the best choice. [4][5]
Learn More
[1] https://medium.com/the-xplane-collection/updated-empathy-map-canvas-46df22df3c8a.
[2] Cooper, Alan, Robert Reimann, David Cronin, and Christopher Noessel. About Face:
The Essentials of Interaction Design 4th Edition. Wiley, 2014.
[3] Patton, Jeff and Peter Economy. User Story Mapping: Discover the Whole Story, Build
the Right Product 1st Edition. O’Reilly Media, 2014.
[4] Snyder, Carolyn. Paper Prototyping: The Fast and Easy Way to Design and Refine User
Interfaces. Morgan Kaufmann, 2003.
[5] Gothelf, Jeff and Josh Seiden. Lean UX: Designing Great Products with Agile Teams.
O’Reilly Media. 2016.
Last updated: 27 September 2019

permissions.
PI Planning
Future product development tasks can’t be predetermined. Distribute planning and control
to those who can understand and react to the end results.
—Michael Kennedy, Product Development for the Lean Enterprise
There is no magic in SAFe . . . except maybe for PI Planning.
—Authors
Introduction to PI Planning: A Quick Overview
Program Increment (PI) Planning is a cadence-based, face-to-face event that serves as the

heartbeat of the Agile Release Train (ART), aligning all the teams on the ART to a shared
mission and Vision.
For geographically distributed ARTs, the event may occur at multiple locations
simultaneously by maintaining constant audio and video communication between the sites.
Details
Find a Course:
The Agile Manifesto states, “The most efficient and effective method of conveying
information to and within a development team is a face-to-face conversation.”
SAFe takes this to the next level with PI planning, a routine, face-to-face event, with a
standard agenda that includes a presentation of business context and vision, followed by
team planning breakouts—where the teams create their Iteration plans and objectives for the
upcoming Program Increment (PI).
Facilitated by the Release Train Engineer (RTE), this event includes all members of the
ART, whenever possible. It takes place over two days and occurs within the Innovation and
Planning (IP) Iteration. Holding the event during the IP iteration avoids affecting the
scheduling, or capacity of other iterations in the PI.
PI planning is essential to SAFe: If you are not doing it, you are not doing SAFe. This is
quite a significant occasion, as Figure 1 implies.
Figure 1. Face-to-face PI planning. Remote teams are planning at the same time using video
conferencing.
Business Benefits of PI Planning

PI planning delivers many business benefits, including:
 Establishing face-to-face communication across all team members and stakeholders
 Building the social network the ART depends upon
 Aligning development to business goals with the business context, vision, and Team
and Program PI objectives
 Identifying dependencies and fostering cross-team and cross-ART collaboration
 Providing the opportunity for ‘just the right amount’ of architecture and Lean User
Experience (UX) guidance
 Matching demand to capacity and eliminating excess Work in Process (WIP)
 Fast decision-making
Inputs and Outputs of PI Planning

Inputs to PI planning include:
 Business context (see ‘content readiness’ below)

 Roadmap and vision
 Top 10 Features of the Program Backlog
A successful PI planning event delivers two primary outputs:
 Committed PI objectives – A set of SMART objectives that are created by each

team with the business value assigned by the Business Owners.
 Program board – Highlighting the new feature delivery dates, feature dependencies
among teams and relevant Milestones.
Preparation
PI planning is a significant event that requires preparation, coordination, and communication.
It is facilitated by the RTE and event attendees include Business Owners, Product
Management, Agile Teams, System and Solution Architect/Engineering, the System Team,
and other stakeholders, all of whom must be notified in advance to be well prepared. The
active participation of Business Owners in this event provides an important Guardrail on
budgetary spend.
For the event to be successful, preparation is required in three major areas:
 Organizational readiness – Strategic alignment and teams and trains setup

 Content readiness – Management and development preparedness
 Facility readiness – The actual space and logistics for the event
Below are highlights of the ART Readiness Checklist. (The full checklist is provided in
the SAFe PI Planning Toolkit, available to SPCs).
Organizational Readiness
Before PI planning, there must be strategy alignment among participants, stakeholders, and
Business Owners. Critical roles are assigned. To address this in advance, however, event
organizers must consider the following:
 Planning scope and context – Is the scope (product, system, technology domain) of
the planning process understood? Do we know which teams need to plan together?
 Business alignment – Is there reasonable agreement on priorities among the Business
Owners?
 Agile teams – Do we have Agile teams? Are there dedicated team members and an
identified Scrum Master and Product Owner for each team?
Content Readiness
It’s equally important to ensure that there is a clear vision and context and that the right
stakeholders can participate. Therefore, the PI planning must include:
 Executive briefing – A briefing that defines the current business context

 Product vision briefing(s) – Briefings prepared by Product Management, including
the top 10 features in the Program Backlog
 Architecture vision briefing – A presentation made by the CTO, Enterprise
Architect, or System Architect to communicate new Enablers, features,
and Nonfunctional Requirements (NFRs)
Facility Readiness
Securing the physical space and technical infrastructure necessary to support a large number
of attendees isn’t trivial either—especially if there are remote participants. Considerations
include:
 Facility – This must be roomy enough for all attendees, with breakout rooms if
necessary
 Facilities/tech support – These people need to be identified in advance and reachable
during setup and testing, and the event itself
 Communication channels – For distributed planning meetings, primary and
secondary audio, video, and presentation channels must be available
Standard Agenda
The event follows an agenda similar to Figure 2. Descriptions of each item follow.
Figure 2. Standard two-day PI planning agenda
Day 1 Agenda
 Business context – A Business Owner or senior executive describes the current state
of the business, shares the Portfolio Vision, and presents a perspective on how
effectively existing solutions are addressing current customer needs.
 Product/solution vision – Product Management presents the current vision (typically
represented by the next top 10 upcoming features) and highlights any changes from
the previous PI planning meeting, as well as any forthcoming Milestones.
 Architecture vision and development practices – System Architect/Engineering
presents the architecture vision. Also, a senior development manager may introduce
Agile-supportive changes to development practices, such as test
automation, DevOps, Continuous Integration, and Continuous Deployment, which are
being advanced in the upcoming PI.
 Planning context and lunch – The RTE presents the planning process and expected
outcomes of the meeting.
 Team breakouts #1 – In the breakout, teams estimate their capacity for
each Iteration and identify the backlog items they will likely need to realize the
features. Each team creates their draft plans, visible to all, iteration by iteration.
During this process, teams identify risks and dependencies and draft their initial team PI
objectives. The PI objectives typically include ‘uncommitted objectives,’ which are goals
built into the plan (e.g., stories that have been defined and included for these objectives), but
are not committed to by the team because of too many unknowns or risks. Uncommitted
objectives are not extra things to do in case there is time. Instead, they increase the reliability
of the plan and give management an early warning of goals that the ART may not be able to
deliver. The teams also add the features and associated dependencies to the program board,
as shown in Figure 3.
Figure 3. Program board showing features and dependencies
 Draft plan review – During the tightly timeboxed draft plan review, teams present
key planning outputs, which include capacity and load, draft PI objectives, potential
risks, and dependencies. Business Owners, Product Management, and other teams and
stakeholders review and provide input.
 Management review and problem-solving – It’s likely that the draft plans present
challenges such as scope, people and resource constraints, and dependencies. During
the problem-solving meeting, management may negotiate scope changes and resolve
other problems by agreeing to various planning adjustments. The RTE facilitates and
keeps the primary stakeholders together for as long as necessary to make the
decisions needed to reach achievable objectives.
In multi-ART Solution Trains, a similar meeting may be held after the first day of planning
to resolve cross-ART issues that have come up. Alternatively, the RTEs of the involved
trains may talk with each other to raise issues that are then resolved in each ART’s specific
management review and problem-solving meeting. The Solution Train Engineer (STE) helps
facilitate and resolve issues across the ARTs.
Day 2 Agenda
 Planning adjustments – The next day, the event begins with management presenting
any changes to planning scope, people, and resources.
 Team breakouts #2 – Teams continue planning based on their agenda from the
previous day, making the appropriate adjustments. They finalize their objectives for
the PI, to which the Business Owners assign business value, as shown in Figure 4.
Figure 4. A team’s PI objectives sheet with assigned business value

 Final plan review and lunch – During this session, all teams present their plans to
the group. At the end of each team’s time slot, the team states their risks and
impediments and provides the risks to the RTE for use later in the ROAMing
exercise. The team then asks the Business Owners if the plan is acceptable. If the plan
is accepted the team brings their team PI objective sheet to the front of the room so
everyone can see the aggregate objectives unfold in real-time. If the Business Owners
have concerns, teams are given the opportunity to adjust the plan as needed to address
the issues identified. The team then presents their revised plan.
 Program risks – During planning, teams have identified program risks and
impediments that could impact their ability to meet their objectives. These are
resolved in a broader management context in front of the whole train. One by one, the
risks are discussed and addressed with honesty and transparency, and then categorized
into one of the following categories:
o Resolved – The teams agree that the risk is no longer a concern.
o Owned – Someone on the train takes ownership of the risk since it cannot be
resolved during PI planning.
o Accepted – Some risks are just facts or potential problems that must be
understood and accepted.
o Mitigated – Teams identify a plan to reduce the impact of the risk.
 Confidence vote – Once program risks have been addressed, teams vote on their
confidence in meeting their team PI objectives.
Each team conducts a ‘fist of five’ vote. If the average is three fingers or above, then
management should accept the commitment. If it’s less than three, the team reworks the plan.
Any person voting two fingers or fewer should be given an opportunity to voice their
concerns. This might add to the list of risks, require some re-planning, or simply be
informative. Once each team has voted the process is repeated for the entire ART with
everyone expressing their confidence in the collective plan, as illustrated in Figure 5.
Figure 5. Confidence vote for an ART
 Plan rework – If necessary, teams rework their plans until a high confidence level
can be reached. This is one occasion where alignment and commitment are valued
more highly than adhering to a timebox.
 Planning retrospective and moving forward – Finally, the RTE leads a brief
retrospective for the PI planning event to capture what went well, what didn’t, and
what can be done better next time, as shown in Figure 6.
Figure 6. PI planning retrospective
 Typically a discussion about the next steps, along with final instructions to the teams,
follows. This might include:
o Cleaning up the rooms used for planning.
o Capturing the team PI objectives and stories in an Agile project management
tool.
o Reviewing team and ART events calendars.
o Determining Iteration Planning and daily stand-up (DSU) locations and
timings.
After the planning event is done, the RTE and other ART stakeholders summarize the
individual team PI objectives into a set of program PI objectives (Figure 7) and use this to
communicate externally and to track progress toward the goals.
Product Management uses the program PI objectives to update the roadmap and will improve
the forecast for the next two PIs, based on what was just learned.
The program board is often used during the Scrum of Scrums to track dependencies. It may,
or may not, be maintained (manually) after planning is complete. This depends upon the
Agile project management tooling in place and the needs of the ART.
Teams leave the PI planning event with a prepopulated iteration backlog for the upcoming
PI. They take their team’s PI objectives, iteration plans, and risks back to their regular work
area. Program risks remain with the RTE, who ensures that the people responsible for
owning or mitigating a risk have captured the information and are actively managing the risk.
Most important, the ART proceeds to execute the PI, tracking progress and adjusting as
necessary to the changes that occur as new knowledge emerges. Execution of the PI begins
with all the teams conducting planning for the first iteration, using their PI plans as a starting
point. This is fresh input for the iteration planning processes that follow. Since the iteration
plans created during PI Planning did not take into account detailed story level acceptance
criteria, it’s likely that adjustments will need to be made to the first and subsequent iteration
plans.
Figure 7. Program PI objectives
Solution Train PI Planning

This article focuses on the planning activities of a single ART. However, large Value
Streams may contain multiple ARTs and suppliers. In this case, the Solution Train provides
coordination using a Pre-PI Planning event, which sets the context and provides the inputs
for the individual ART PI planning events. A Post-PI Planning event follows ART PI
planning and is used to integrate the planning results of the ARTs that contribute to the
solution.
Figure 8. Pre and Post-PI Planning
The Innovation and Planning Iteration article provides an example calendar for

accommodating Pre- and Post-PI planning events.
Learn More
[2] Kennedy, Michael. Product Development for the Lean Enterprise. Oaklea Press, 2003.
Last update: 30 December 2019
permissions.
Invitation-based SAFe Implementation
by Yuval Yeret, CTO, AgileSparkses
Introduction
Implementing any kind of organizational change, such as adopting SAFe, is hard and raises
several key concerns:
 How do we convince people to adopt the new ways of working?

 How do we get the organization moving in the new direction?
 How do we make decisions about how to implement SAFe in the enterprise?
SAFe recommends decentralizing control while providing vision and gaining alignment. It is
also about respecting people and culture and maintaining effective flow. In this guidance
article, we will discuss ways we can “Walk that talk” in the way we run a SAFe
implementation.
The default approach for implementing organizational change is the “mandate” or “push”
approach. This may appear to be the fast and easy way, where a central group of change
agents decide when people will “board” the Agile Release Train (ART), as well as how the
train should operate.
It may seem easy because the change is mandated and there is little or no discussion about
whether the change should occur. It also appears to reduce the risk of a shallow SAFe
adoption that doesn’t even cover SAFe’s 10 critical success factors, due to bad
implementation decisions, by people who have limited or no experience. The problem with
this classic approach is mainly that people don’t like to be changed. They like to be involved
in making the decision to change as well as designing the change.
The Vision – Implementing SAFe using Invitations

Martin Fowler, one of the Agile Manifesto signatories, wrote an article in 2006 called “The
Agile Imposition.” In the article, Fowler says, “Imposing an agile process from the outside,
strips the team of the self-determination, which is at the heart of agile thinking.” But what if
we can’t wait for people to self-determine that they should go agile? Should the organization
wait? Even if it kills the business?
SAFe’s 9th principle – “Decentralize Decision Making” provides some guidance here. The
decision whether to go agile and what approach to take is infrequent, long
lasting, and provides a significant economy of scale. So it is a classic strategic decision to
centralize.
But once that central decision to go SAFe has been made, The Agile Manifesto says, “Build
projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.” And “The best architectures, requirements, and designs
emerge from self-organizing teams.” If we apply these two principles to SAFe
implementation this would mean the best plans for implementing SAFe will emerge from
self-organizing teams (or teams of teams) of the people adopting SAFe. Implementing SAFe
using a leaner and more agile approach will send a message about the strength of
management’s commitment to the Lean-Agile mindset described in SAFe. Can you think of
a better way to signal “respect for people and culture”?
In PI planning Business Owners and Product Management present the business context, the
vision. The planning context and structure of PI Planning is a “container” in which the Agile
Release Train self-organizes to figure out how and how much they can do to further the
vision.
Similarly, Invitation-based SAFe implementation needs to set the context and provide the
right structure for the group to figure out how much of SAFe they can achieve in their first
implementation PI. A flow of an invitation-based implementation can be seen in figure 1,
with the blue boxes showing the potential places to involve an invitation to leaders and
practitioners.
Figure 1. Invitation-based SAFe implementation flow
Using the SAFe Implementation Workshop to invite the Enterprise

to consider SAFe
“Leadership is charged with making these types of [strategic] decisions, supported by the
input of those impacted by the decisions.” (SAFe Principle #9, Decentralize decision
making)
One approach that my company, AgileSparks, has discovered works well when teaching
Leading SAFe is to accompany pure training-mode with a “SAFe Implementation
Workshop.” In this workshop, whose agenda you can see in figure 2, a group of leaders
discuss:
 The reasons for considering SAFe

 How good of a fit SAFe seems to be
 Identifying value streams and designing ARTs
 Guidelines for determining how roles in SAFe are chosen or assigned to people
 Implementation risks and organizational impediments
Figure 2. Implementation workshop sample agenda
Through this interactive, collaborative process members of this group will become the initial
“guiding coalition,” a term popularized by Kotter. They consider options, make decisions,
and commit to working together towards the shared vision.
As you can see in the “SAFe Invitations Implementation Approach Roadmap” above, this
workshop format is useful when considering SAFe with a group of leaders across an
enterprise/division as well as later on when preparing to launch a specific Value Stream or
Agile Release Train. Another way to look at is as a different variant of how to run the SAFe
Value Stream workshop that is frequently used following up an Implementing SAFe/Leading
SAFe class to help identify Value Streams/Agile Release Trains for an actual implementation
of SAFe in the organization.
Spreading SAFe through an invitation to Leaders

The outcome of the enterprise-level implementation workshop is an invitation to potential
value streams and/or ARTs to consider what SAFe would mean in their context and figure
out when/how to start their SAFe journey.
In most cases, the potential ART/VS leaders (think VP level leaders) participated in the
initial Leading SAFe + Implementation workshop and are now ready to consider bringing
SAFe to their group.
In larger enterprises, there might be a need for further Leading SAFe+Implementation

Workshops to expose more potential ART/VS leaders. In the “Invitations” spirit you can
invite leaders to participate in such a class or bring SAFe into their organization, not
force/mandate them. The first leaders to accept the invitation are ideal “prospects”
(innovators or early adopters) for starting the SAFe journey and should be where SPCs
should initially spend most of their time.
Using the SAFe Implementation Workshop to launch a

Program/Value Stream
Once a leader decides that the timing is right to consider SAFe in their area, they should
again repeat the same pattern – Leading SAFe combined with a SAFe Implementation
Workshop to figure out how to go SAFe. This time the audience is Lean/Agile leaders for the
ART/VS as well as ART/VS roles such as RTE, Product Management, System Architect.
Typically the Product Owners and Scrum Masters don’t participate in this workshop—in
many cases, it is in this workshop where the leadership team figures out what is the mapping
between the PO/SM/PM roles and the roles and people in the group.
As the POs, SMs, PMs, are identified they get trained in PO/PM and SAFe Scrum Master
workshops. When using the “SAFe Invitations” implementation approach these workshops
should include vignettes from the implementation workshop such as starting with a
pains/why session and gauging confidence level and ROAMing implementation risks
towards the end of the training.
This will help SMs/POs/PMs connect to the vision and feeling more involved in designing
the implementation approach. This will rally them to join the “guiding coalition” of the
group.
Invitation-based ART Launch

Once leaders of a certain area are on board and have identified an Agile Release Train/Value
Stream to focus on and the ART stakeholders/roles have been trained and brought on board
as well, it is time get the team-of-teams rolling.
The combination of training everybody using “SAFe for Teams” at the same time with
planning the initial PI and getting a real feel for how SAFe will look like works better than
just sticking to theory, training exercises, and games.
Bringing an invitation approach into the ART Launch means decentralizing some decisions
around how to operate SAFe to the people on the ART themselves. Aspects like program
board structure, Definition of Done (DoD) policies, ready policies, engineering practices,
agile testing strategies, and some other aspects are great candidates for having the breakout
and integrate discussions as part of the SAFe for Teams training. Additionally, you may want
to allow teams to make other local decisions about how they use SAFe, as long as they’re
aligned with the SAFe principles and it does not cause problems for the other teams on the
train, or the ART as a whole, as can be seen in figure 3.
Figure 3. Invitation-based ART Quick Start

As a blueprint for how the ART will work starts to emerge, it’s time to gauge people’s level
of confidence for how the implementation of SAFe will work and surface risks. You can use
a “fist of five” confidence vote, similar to what we do in PI planning to gather this feedback,
as well as proactively inviting people to share their concerns.
Follow up with questions like, ‘Based upon what we just learned so far, are there any
significant concerns that would prevent us from starting to use SAFe?’ The responses from
the teams can be used to seed topics for a brief problem-solving workshop or ‘open space’
session, where people can raise their concerns, and then join or lead a breakout session to
identify solutions.
Another approach is to ROAM each risk/issue like we do in PI Planning. The use of the
facilitation techniques, like ROAMing risks, confidence vote, and open space all demonstrate
a “servant leadership” style. As leaders, we are not just telling people what to do, we are
involving them in figuring out the ‘how’ and serving them by owning a resolution of key
systemic risks to the change. This same technique can be applied during PI Planning
confidence vote and “ROAMing” of the risks.
Another interesting practice that invites people on the ART to participate in figuring out
implementation details is team self-selection. In this practice, the ART leaders provide
guidelines/constraints and let the people on the ART figure out what at the actual teams
should look like. [8] [9] [10]
Caution: Be careful when allowing customization at this point. There’s a two-fold risk,
either removing too much from the SAFe model, as well as adding too much overhead with
additional process. There’s tremendous value to trying out the SAFe framework, more or less
“as is,” or with careful configuration/customization with the help of a seasoned SAFe
program consultant, and only then continuing to remove/add/change practices. For a view on
the critical elements that shouldn’t be changed, please see SAFe’s 10 critical success factors.
Summary – Evolving SAFe’s Implementation Approach with

SAFe’s Lean-Agile Principles
In essence, the approach described above uses Lean-Agile practices and principles to drive
the adoption of SAFe. Using SAFe to adopt SAFe. We’re asking leaders to set the
vision/direction for implementing SAFe and inviting their people to come on board and
participate in designing this change that will have so much positive impact on how work will
be performed in the future.
Decentralizing control and engaging as many people as possible in figuring out how to use
SAFe tends to improve the quality of SAFe implementation because of ‘Wisdom of the
Crowds’ and the higher motivation people have when they’re invited to be involved. This
applies to leaders at various levels using the SAFe Implementation Workshop that
complements Leading SAFe training and to teams and ART stakeholders using vignettes like
pains/vision mapping, implementation confidence votes, and risk ROAMing in each and
every SAFe training used to prepare and launch SAFe in ARTs/VSs.
Learn More
http://www.agilesparks.com/safe-implementation-strategy-leadership-focusing-workshop/
[1] https://www.linkedin.com/pulse/openspace-agility-right-you-daniel-sloan
[2] John Kotter. Leading Change. Harvard Business Press, Dec 30, 2013
[3] http://openspaceagility.com/big-picture/
[4] http://yuvalyeret.com
[5] http://www.infoq.com/news/2014/10/kickstart-agile-kanban
[6] http://www.infoq.com/interviews/lkfr14-yeret-kanban-agile
[7] https://management30.com/practice/delegation-board/
[8] https://www.linkedin.com/pulse/large-scale-self-selection-australia-post-interview-andy-
sandy-mamoli
[9] https://www.amazon.com/Creating-Great-Teams-Self-Selection-People-
ebook/dp/B019EKWG6M/
[10] https://www.scrumalliance.org/community/articles/2013/2013-april/how-to-form-teams-
in-large-scale-scrum-a-story-of
permissions.
Innovation and Planning Iteration

Inertia is the residue of past innovation efforts. Left unmanaged, it consumes the resources
required to fund next-generation innovation.
—Geoffrey Moore
100% utilization drives unpredictability.
—Don Reinertsen
The Innovation and Planning (IP) Iteration occurs every Program Increment (PI)and serves

multiple purposes. It acts as an estimating buffer for meeting PI Objectives and provides
dedicated time for innovation, continuing education, PI Planning, and Inspect and Adapt
(I&A) events.
SAFe has an intense focus on continuous customer value delivery, and people are busy
working on the Features they committed to during PI planning. Every Iteration counts and
the teams are mostly heads down, delivering near-term value. One iteration after another,
the Solution marches closer to market. The attention to solution delivery is intense and
unrelenting.
Of course, a focus on one thing—delivery—can lead to a lack of focus on another—

innovation. Given the constant urgency for delivery, there’s a risk that the tyranny of the
urgent [1] will override any opportunity to innovate. To address this, SAFe provides
dedicated innovation and planning iterations which are a key aspect of the Lean Enterprise’s
broader innovation culture.
Details
Understand the IP Iteration Activities
Innovation and planning iterations provide a regular, cadence-based opportunity, every PI,
for teams to work on activities that are difficult to fit into a continuous, incremental value
delivery pattern. These may include:
 Time for innovation and exploration, beyond the iterations dedicated to delivery
 Work on technical infrastructure, tooling, and other impediments to delivery
 Education to support continuous learning and improvement
 Cross training to develop skills in new domains, development languages, and systems
 Dedicated time for the I&A event, backlog refinement, including final prioritization
of Features using Weighted Shortest Job First (WSJF), and PI planning
 Final integration of the solution, including verification and validation, if releasing on
the PI boundary
 Final user acceptance testing and documentation, and any other readiness activities
that are not feasible or economical to perform every iteration
IP iterations fulfill another critical role by providing an estimating buffer for meeting PI
objectives and enhancing the predictability of PI performance.
Agile Release Trains (ARTs) typically report that their overall efficiency, velocity, and job
satisfaction are enhanced by regular opportunities to ‘recharge their batteries and sharpen
their tools.’
Allow Time for Innovation

One of the pillars of the SAFe Lean-Agile Mindset is innovation, but finding time for
ideation and change in the midst of delivery deadlines can be difficult. To this end, many
enterprises use IP iterations for research and design activities such as hackathons. There are
two simple rules for hackathons:
 People can work on whatever they want, with whomever they want, so long as the
work reflects the mission of the company
 The teams demo their work to others at the end of the hackathon
The learnings from hackathons routinely make their way into Program Backlogsand often
help drive innovation. They’re fun, too!
Dedicate Time to PI Events

Performing the I&A and PI planning during the IP iteration avoids a reduction in velocity of
the regular iterations. More importantly, since these events are held on a regular cadence and
can be scheduled well in advance, their occurrence is better guaranteed.
Also, it’s likely that some just-in-time, last-responsible-moment program and solution
backlog refinement and feature and capability elaboration during this period can significantly
increase the productivity of the upcoming planning session.
Integrate the Complete Solution

The PI System Demo occurs at the end of each PI. It is the integrated presentation of the
work of all teams on the train, done in a staging environment which emulates production as
closely as possible. For ARTs that are part of a Solution Train, the PI system demo feeds into
the aggregate Solution Demo, which also takes place for during the IP Iteration. It’s a more
structured and formal affair, as it demonstrates the accumulation of all the features and
capabilities developed over the course of the entire PI for a Solution Train.
When a solution includes hardware (and other components), it’s harder to integrate end-to-
end continuously and full integration may be feasible only during the IP iteration. In these
cases, it’s just common sense to plan for that.
However, the IP iteration should not be the only attempt to integrate the assets into the
system. Full or partial integration happens over the course of the PI, with a total solution
integration occurring at least once per PI. This approach validates the assumptions early
enough to be able to respond to significant problems and risks within the PI.
Advance Development Infrastructure

Lean delivery puts increased pressure on the development infrastructure: new continuous
integration environments require provisioning, new test automation frameworks must be
implemented and maintained, Agile project management tooling adopted, upgrading or
enhancing cross-team and train communications systems, and the list goes on. Many times,
the improvement stories are from the team’s Iteration Retrospective or Enablers.
We all understand that we have to sharpen our tools from time to time; Agile teams are no
different. Indeed, they have an even higher dependency on their working environments, so
time must be spent continuously improving them. It’s often more efficient to improve
infrastructure or perform a migration at a time when the teams aren’t in the midst of critical
work.
Enable Continuous Learning

Employees at every level are lifelong learners. Changes in technology, as well as changes to
method and practice, are routine; opportunities for continuing education, however, are far
less frequent. Also, the initial move to Lean-Agile requires many new techniques and skills,
including:
 Feature and Story writing
 Building in quality
 Automated testing
 Collective ownership
 Agile Architecture
 Continuous Integration
 Pair work
 Mastering Product Owner and Scrum Master roles
 Team building
Practitioners are also challenged to keep their technical skills current. New technologies are
being introduced more frequently than ever before. Investing in people who can work across
multiple systems, domains, and languages creates a ‘T-shaped’ (deep skill in one area,
working knowledge in multiple other areas) and even ‘E-shaped’ (deep skill in more than
one area) workforce. This provides the organization with maximum agility and flexibility to
deliver the most important backlog items. However, it is difficult to find time for this type of
growth alongside the drive to constantly deliver new features. IP iterations are a perfect time
for this investment.
Making time for continuing education gives teams and leaders a welcome opportunity to
learn and master these new techniques. It can also be used to launch and
support Communities of Practice devoted to these and other topics. The net results benefit
both the individual and the enterprise: employee mastery and job satisfaction increase,
velocity goes up, and time-to-market goes down.
Leverage the Built-In Estimation Buffer

Lean flow teaches us that operating at “100 percent utilization drives unpredictable results
[2].” Simply put, planning everyone to full capacity, does not allow people the ability to flex
when problems inevitably occur. The result is unpredictability and delays in value delivery.
As a countermeasure, the IP iteration offers a ‘guard band’ (or buffer) to prevent unfinished
work from the current PI from carrying over to the next PI.
During PI planning, the ART does not plan features or stories for the IP iteration, providing a
buffer (extra time) to the teams for responding to unforeseen events, delays resulting from
dependencies, and other issues, increasing their ability to meet Team and Program PI
Objectives. This buffer substantially increases the predictability of the program’s outcomes,
which is extremely important to the business. However, routinely using that time for
completing work is a failure pattern. Doing so defeats the primary purpose of the IP
iteration, and innovation will likely suffer. Teams must take care that this estimating guard
band does not merely become a crutch.
A Sample IP Iteration Calendar

IP iterations take on a somewhat standard schedule and format. Figure 1 provides an example
IP iteration calendar. The items in orange represent Solution Train events, while the blue
ones are for a single ART.
Figure 1. Example calendar for an IP iteration
Learn More
[1] Hummell, Charles E. Tyranny of the Urgent. IPV Booklets, 2013.
[2] Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation
Lean Product Development. Celeritas Publishing, 2009.
Last update: 27 December 2019
permissions.
Introduction
It’s 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.
The Lean-Agile Leadership competency describes how Lean-Agile Leaders drive and sustain
organizational change and operational excellence by empowering individuals and teams to
reach their highest potential.
They do this through leading by example; learning and modeling SAFe’s Lean-Agile
mindset, values, principles, and practices; and leading the change to a new way of working.
It is one of the seven core competencies of the Lean Enterprise, each of which is essential to
achieving Business Agility.
Why Lean-Agile Leaders?

An organization’s managers, executives, and other leaders are responsible for the adoption,
success, and ongoing improvement of Lean-Agile development and the competencies that
lead to business agility. Only they have the authority to change and continuously improve the
systems that govern how work is performed. Moreover, only these leaders can create an
environment that encourages high-performing Agile teams to flourish and produce value.
Leaders, therefore, must internalize and model leaner ways of thinking and operating so that
team members will learn from their example, coaching, and encouragement.
Becoming a Lean enterprise is neither simple nor easy. As described below, business agility
requires a new approach to leadership. It starts with leaders exemplifying behaviors that will
inspire and motivate the organization to pursue a better way of working. They set the
example by coaching, empowering, and engaging individuals and teams to reach their
highest potential through Lean and Agile principles and practices.
In short, knowledge alone won’t be enough. Lean-Agile leaders must do more than simply
support the transformation: they must actively lead the change, participating in and guiding
the activities necessary to understand and continuously optimize the flow of value through
the enterprise. Lean-Agile leaders:
 Organize and reorganize around value

 Identify queues and excess Work in Process (WIP)
 Continually focus on eliminating waste and delays
 Eliminate demotivating policies and procedures
 Inspire and motivate others
 Create a culture of relentless improvement
 Provide the space for teams to innovate
By helping leaders develop along three distinct dimensions as illustrated in Figure 1,

organizations can establish lean-agile leadership as a core competency:
Figure 1. The dimensions of lean-agile leadership
These dimensions are:

1. Leading by Example – Leaders gain earned authority by modeling the desired
behaviors for others to follow, inspiring them to incorporate the leader’s example into
their own personal development journey.
2. Mindset and Principles – By embedding the Lean-Agile way of working in their
beliefs, decisions, responses, and actions, leaders model the expected norm
throughout the organization.
3. Leading Change – Leaders lead (rather than simply support) the transformation by
creating the environment, preparing the people, and providing the necessary resources
to realize the desired outcomes.
The sections that follow explore each of these dimensions of lean-agile leadership in greater
detail.
Leading by Example
Setting an example is not the main means of influencing others, it is the only means.
—Albert Einstein
Through their words and actions, leaders provide the organization with patterns of expected
behaviors. The aggregation of those patterns determines the organization’s culture, whether
good or bad. The most important and effective technique for driving the cultural change
needed to transform into a Lean enterprise is for leaders to internalize and model the
behaviors and mindsets of business agility so that others can learn and grow by example.
Author Simon Sinek underscores the importance of leading by example in his book Leaders
Eat Last [1] with the following:
The leaders of companies set the tone and direction for the people. Hypocrites, liars, and
self-interested leaders create cultures filled with hypocrites, liars, and self-interested
employees. The leaders of companies who tell the truth, in contrast, will create a culture of
people who tell the truth. It is not rocket science. We follow the leader.
By modeling the right behaviors, leaders can transform organizational cultures from the
pathological (negative, power-oriented) and bureaucratic (negative, rule-oriented) patterns of
the past to the generative (positive, performance-oriented) culture that is required for the
Lean-Agile mindset to flourish (Figure 2 provides a comparison of the attributes of
Westrum’s organizational culture model [2]). These same behaviors also build earned
authority—power gained through trust, respect, expertise, or action—which engenders
greater engagement and commitment to organizational aims than positional authority. Such
leaders inspire others to follow their direction and to incorporate the leader’s example into
their own personal development journey.
Figure 2. Westrum’s organizational cultures model (adapted)
What, then, are the behaviors that leaders should embrace to set the right example and build a
generative culture? While the potential list of attributes could be quite long, the aspects
below form a solid foundation for this dimension of leadership.
Authenticity requires leaders to model desired professional and ethical behaviors. Acting

with honesty, integrity, and transparency, they are true to themselves and their beliefs.
Emotional intelligence describes how leaders identify and manage their emotions and those
of others through self-awareness, self-regulation, motivation, empathy, and social skills.
Life-long learning depicts how leaders engage in ongoing, voluntary, and self-motivated

pursuit of knowledge and growth, and they encourage and support the same in others.
Growing others encourages leaders to provide the personal, professional, and technical

guidance and resources each employee needs to assume increasing levels of responsibility
and decision-making.
Decentralized decision-making moves the authority for decisions to where the information

is; prepares teams to make decentralized decisions by investing in their technical competence
and by providing organizational clarity with decision guardrails. [3].
Mindset and Principles

“The basic tenets of Lean challenge many of the aspects of traditional management theory
and calls for a mindset that is foreign to most executives.”
— Jacob Stoller, author of The Lean CEO: Leading the Way to World-Class Excellence
Stoller’s quote is a reminder that traditional management practices are insufficient for the
changes needed to achieve business agility. Instead, the Lean enterprise depends on what
Toyota calls Lean-thinking manager-teachers.These leaders understand Lean thinking and
principles and, as part of their everyday work activities, teach them to others. This is integral
to who they areand what they do. It informs every aspect of their approach to helping teams
throughout the organization work in a Lean and Agile manner as the expected norm.
But what if leaders don’t have that mindset yet? What exactly is a ‘mindset,’ and how can a
mindset be changed?
Mindset Awareness and Openness to Change
A mindset is simply the mental lens through which we view the world around us. It is how
the human brain simplifies, categorizes, and interprets the vast amounts of information it
receives each day. Through a lifetime of structured learning (classes, reading) and
unstructured lessons (life events, work experience), we form our mindsets. They reside in the
subconscious mind and manifest themselves as deeply held beliefs, attitudes, assumptions,
and influences. Consequently, individuals are often unaware of how their mindsets influence
how they carry out their responsibilities and interact with others. For example, many leaders
develop beliefs through business school training and on-the-job experience that are grounded
in legacy waterfall, stage-gate, and siloed ways of working.
So how can mindsets be changed? It begins with the awareness of how one’s current
mindsets were formed. It’s also vital to cultivate the belief that mindsets can be developed
and improved (a ‘growth’ mindset, as illustrated in Figure 3). Leaders must remain open to
the possibility that existing mindsets based on traditional management practices need to
evolve in order to guide the organizational change required to become a Lean enterprise. [4]
Figure 3. Adopting a new mindset requires a belief that new abilities can be developed with effort
Developing a New Mindset
With an increased awareness of current mindsets and an openness to doing the work required
to change them, the question then becomes, “Change them to what?” To lead the
organization through the transformation needed to achieve business agility requires a mindset
that reflects the core values and principles of Lean, Agile, and SAFe. This is developed by
gaining intimate knowledge and application of these values and principles. It is reflected in
how leaders routinely reference Lean-Agile principles and practices as part of carrying out
their responsibilities, how they coach and mentor these behaviors in others, and how they
promote Lean-Agile practices as the default way of working throughout the organization.
Let’s take a closer look at the three key elements that form the foundation of this new
mindset: SAFe Core Values, the Lean-Agile Mindset, and SAFe Principles.
SAFe Core Values
The four core values that define SAFe’s essential ideals and beliefs are alignment,
transparency, built-in quality, and program execution. Leader behaviors play a critical role in
communicating, exhibiting, and emphasizing these values and how they guide the
organization in its journey to embracing agility.
Here are some suggestions for reinforcing these values:

Alignment – Communicate the mission by establishing and expressing the portfolio strategy
and solution vision. Help organize the value stream and coordinate dependencies. Provide
relevant briefings and participate in Program Increment (PI) Planning. Help with backlog
visibility, review, and preparation; regularly check for understanding.
Built-in quality – By refusing to accept or ship low-quality work, Lean-Agile leaders

demonstrate their commitment to quality. They support investments in capacity planning for
maintenance and to reduce technical debt, ensuring that the concerns of the entire
organization—including design thinking, UX, architecture, operations, security, and
compliance—are part of the regular flow of work.
Transparency – Visualize all relevant work. Take ownership and responsibility for errors
and mistakes. Admit missteps while supporting others who acknowledge and learn from
theirs. Never punish the messenger. Instead, celebrate learning. Create an environment where
the facts are always friendly and transparent.
Program execution – Participate as Business Owners in PI execution and establish business

value. Help adjust the scope to ensure demand matches capacity. Celebrate high-quality
Program Increments while aggressively removing impediments and demotivators.
Lean-Agile Mindset
SAFe is firmly grounded in two established bodies of knowledge: Lean and Agile. In fact,
the genesis of SAFe was to develop guidance for enterprises on how to apply the principles
and practices of Lean and Agile in the world’s largest organizations. A Lean-Agile
Mindset requires leaders to learn, embrace, and model both Lean and Agile in their behaviors
and support adoption by the enterprise. Figure 4 illustrates the key concepts of each
discipline.
Figure 4. The SAFe House of Lean and the values of the Agile Manifesto
Lean – Lean is a set of principles and practices for efficient manufacturing and operations
that grew out of the Toyota Production System developed in post-WWII Japan. It focuses on
problem-solving and continuous improvement to increase quality and eliminate waste.
Adapted to product development by Leffingwell [5], Poppendieck [6], and others, the SAFe
House of Lean illustrates the goal of delivering value through the pillars of respect for people
and culture, flow, innovation, and relentless improvement. Leadership provides the
foundation on which everything else stands.
Agile – Agile was born from a collaboration of 17 thought leaders in software development
who met in 2001 to seek alternatives to the documentation-driven, heavyweight software
development processes that were common at the time. It includes four values (shown in
Figure 4) and twelve principles as reflected in the Agile Manifesto. Agile is known for
delivering iterative and incremental value in the form of working software by promoting
face-to-face interaction frequently between developers, customers, and cross-functional, self-
organizing teams. Agile has since been adapted and embraced in many non-software
development contexts.
The Lean-Agile Mindset article describes how Lean and Agile are at the heart of SAFe and
are supported by many of the articles in the Framework that explain how to implement Lean-
Agile practices at scale. There are also many great courses, books, websites, and videos that
form a rich set of resources that Lean-Agile leaders should explore to deepen their
understanding.
SAFe Principles
SAFe is based on ten immutable, underlying principles for applying Lean and Agile at scale.
These tenets and economic concepts inspire and inform the roles and practices of SAFe,
influencing leader behaviors and decision-making.
The principles are:

Figure 5. The SAFe Lean-Agile Principles
Each is necessary to experience the personal, business, and economic benefits of applying
SAFe. Moreover, these principles work together as a system; each informs the others, and the
whole is far greater than the sum of them individually. Lean-Agile leaders embrace these
principles and routinely demonstrate and apply them as they carry out their organizational
responsibilities. Review the SAFe Principles article for a more in-depth discussion of each
principle.
Leading Change
Being a Lean-thinking manager-teacher provides leaders with the thought processes and
practical tools they’ll need to start building the Lean enterprise and achieving business
agility. The benefits of delivering value in the shortest sustainable lead time, creating flow,
and producing customer delight—all with happy, engaged employees—are clear. It’s also
clear that for many organizations, the new way of working represents a quantum shift in
culture and practice from the traditional paradigms of the past. In other words, the
transformation to Lean-Agile and DevOps with SAFe inevitably leads to significant
organizational change.
Here again, the role of the Lean-Agile leader is critical. Successful organizational change
requires leaders who will lead the transformation (rather than simply ‘support’ it) by creating
the environment, preparing the people, and providing the necessary resources to realize
desired outcomes. In fact, research shows clear correlations between the leader behaviors
described in the “Leading by Example” section of this article and the success of
organizational change driven by Agile and DevOps initiatives. Other researchers found that
these leader behaviors have a greater influence on employees’ commitment to supporting the
change than simply following a prescriptive change model [7, 8].
Lean-Agile leaders drive the change process by developing and applying the following skills
and techniques:
Change vision occurs when leaders communicate why change is needed and do so in ways

that inspire, motivate, and engage people.
Change leadership is the ability to positively influence and motivate others to engage in the
organizational change through the leader’s own personal advocacy and drive.
A powerful coalition for change is formed when individuals from multiple levels and
across silos are empowered and have the influence necessary to effectively lead the change.
Psychological safety occurs when leaders create an environment for risk-taking that supports
change without fear of negative consequences to self-image, status, or career.
Training the new way of working ensures that everyone is trained in the values, principles,
and practices of Lean and Agile, including a commitment by leaders to their own training so
they can lead by example.
Sound organizational change management (OCM) practices are still important and highly
recommended in a SAFe transformation. One of the most respected voices in OCM, Dr. John
Kotter, described the eight steps in implementing successful change as [9]:
1. Establish a sense of urgency

2. Create the guiding coalition
3. Develop the vision and strategy for change
4. Communicate the change vision
5. Empower employees for broad-based action
6. Generate short-term wins
7. Consolidate gains and produce more change
8. Anchor new approaches in the culture
Clearly, these steps require the active participation of the leaders driving the change. But
even this is not enough. As Heath and Heath note in their book on change [10], leaders “need
to script the critical moves” that are essential to accomplish the change.
The SAFe Implementation Roadmap
Based on these insights from the field of organizational change management, the SAFe
Implementation Roadmap article series guides leaders on this particular journey, as
summarized in the Implementation Roadmap article and Figure 6 below.
Figure 6. The SAFe Implementation Roadmap
The SAFe implementation roadmap is described in a series of 12 articles that aligns with
Kotter’s blueprint. For example, the sense of urgency is often established in the many
conversations that lead up to an organization ‘reaching the tipping point’ and deciding to ‘go
SAFe.’ The next recommended action is to train a core group of Lean-Agile change agents
and leaders who will form the powerful guiding coalition. The pattern continues throughout
the roadmap, which is designed to incorporate the lessons of successful organizational
change into the model for a SAFe transformation. This roadmap helps leaders ‘know the
way’ as they drive for successful change.
Role of the SAFe Program Consultant
Even with Lean-Agile leaders and sound organizational change strategies in place,
observations from many SAFe implementations indicate that a significant cadre of change
agents and experienced coaches is also needed. While every leader plays a part in producing
the change, SAFe Program Consultants (SPCs) are trained and equipped specially for this
task. SPCs’ training, tools, courseware, and intrinsic motivation play a critical role in
successfully implementing and sustaining a SAFe transformation.
Measure and Grow

The Measure and Grow article describes how enterprises can assess where they are on their
journey to Business Agility and provides a downloadable self-assessment for that purpose.
That assessment is a high-level view that measures the seven competencies and briefly
touches on each dimension of Business Agility.
In order to provide further insights, each competency has an individual assessment that can
be used to provide additional specificity as to prowess in that competency and implications
as to how to improve. The specific, more detailed assessment for Lean-Agile Leadership can
be downloaded below.
Download Lean-Agile Leadership Assessment
Summary
It’s no surprise that effective leadership is necessary for achieving any significant
organizational change. And implementing SAFe is not just any change: it’s a shift to a
persistent and relentlessly improving Lean enterprise and to business agility, all based on the
fundamentals of Agile and Lean.
This requires leaders with the right mindset who:
 Know what they are trying to do

 Know how they are going to do it
 Lead by example
 Foster the trust that inspires others to join them in the journey
In other words, authentic Lean-thinking manager-teachers are needed who understand how

to lead and sustain the change.
Learn More
[1] Sinek, Simon. Leaders Eat Last. Penguin Random House LLC. Kindle Edition.
[2] Westrum, Ron. (2004) A topology of organizational cultures. Quality and Safety in
Health Care, 13(Suppl II):ii22–ii27. doi: 10.1136/qshc.2003.009522
[3] Marquet, David. Turn the Ship Around. Penguin Group. Kindle Edition.
[4] Dweck, Carol S. Mindset: The New Psychology of Success. Random House Publishing.
Kindle Edition.
[5] Leffingwell, Dean. Agile Software Requirements. Addison-Wesley. Kindle Edition.
[6] Poppendieck, Mary; and Poppendieck, Tom. Implementing Lean Software Development:
Concept to Cash. Addison-Wesley. Kindle Edition.
[7] Mayner, Stephen. 2017. Transformational leadership and organizational change during
agile and devops initiatives. ProQuest.
[8] Herold, Fedor, Caldwell, & Liu. 2008. The effects of transformational and change
leadership on employees’ commitment to change: a multi-level study. Journal of Applied
Psychology, Volume 93, pp. 346-357.
[9] Kotter, John P. Leading Change, With a New Preface by the Author. Harvard Business
Review Press. Kindle Edition.
[10] Heath, Chip; Heath, Dan. Switch: How to Change Things When Change Is Hard. The
Crown Publishing Group. Kindle Edition.
permissions.
Reaching the Tipping Point

The success of any kind of social epidemic is heavily dependent on the involvement of people
with a particular and rare set of social skills.
—Malcolm Gladwell, The Tipping Point

This is article one in the SAFe® Implementation Roadmap series. Click here to view the
entire roadmap.
Changing the way of working in a large organization, including its habits and culture, is
hard. Many enterprises report that implementing SAFe was one of the toughest and yet most
rewarding change initiatives that they have ever done.
People naturally resist change, and it is common to hear phrases like, “That’s the way we’ve
always done it around here,” or “That won’t work here.” Accepting change means accepting
the possibility that individuals and organizations are not currently doing things the best way,
or it may even challenge a person’s long-held beliefs or values.
In the same way, people will naturally keep their old behaviors unless there is an
exceptionally good reason to make a change. This reason must be so compelling that the
status quo becomes simply unacceptable. The motivation must be so strong that change
becomes the only reasonable way forward to success.
In other words, the enterprise must reach its ‘tipping point’—the point at which the
overriding organizational imperative is to achieve the change, rather than resist it [1].
Details
The Need for Change
Organizations arrive at the need for change from a wide range of starting points. The current
context may be a highly regimented waterfall environment marked by strict phase gate
reviews and quality checks, separation of concerns, and sophisticated resource management
procedures. Or perhaps the organization has developed an ad hoc approach, mixing a variety
of team-level Agile methods with more traditional project and portfolio management
techniques. Regardless, before a successful change effort can begin, there must be a clear
and compelling impetus for change: a general acknowledgment that the current ways of
working are inadequate to deliver the performance needed either now or in the future.
Organizations who are able to establish such a shared awareness typically meet one of two
conditions:
 A burning platform – Sometimes the need to change a product or service is obvious.

The company is failing to compete, and the existing way of doing business is
obviously inadequate to achieve a new solution within a survivable time frame. Jobs
are at stake. This is the easier case for change. While there will always be those who
are resistant, they are likely to be overcome by the wave of energy that drives a sense
of urgency for mandatory change through the organization.
 Visionary leadership – In the absence of a burning platform, leadership must drive
change proactively by taking a stand for a better future state. Lean-Agile
Leaders must exhibit what Toyota [2] would call “a constant sense of danger”—a
never-ending sense of potential crisis that fuels continuous improvement. This is often
the less obvious reason to drive change, as the people in the organization may not see
or feel the urgency to do the additional hard work that comes with change. After all,
they are successful now. Why should they assume that they won’t continue to be
successful in the future? Isn’t change risky? In this case, leaders must create a clear
and compelling vision for change that answers why change is needed [3]. They must
constantly communicate and impress the need for change on all, making it clear that
maintaining the status quo is simply unacceptable.
In rare instances, organizations have both a burning platform and visionary leadership with

the courage to lead the change. With SAFe as the blueprint for scripting the change, such
organizations can experience a rapid and dramatic turnaround from a bleak crisis to strong,
positive business results and a bright future with strong, positive business results.
Establish the Vision for Change

While necessary, a compelling and well-understood reason to change is insufficient for an
organization to reach the tipping point. A clear vision for the future is also critical. Kotter
notes that establishing a vision for change is a primary responsibility of leadership [4]. The
vision for change provides three key benefits:
 Purpose – It clarifies the purpose and direction for the change and sets the mission
for all to follow. It avoids the potentially confusing details and focuses everyone on
the why, not the how, of the change.
 Motivation – It starts to move people in the right direction. After all, change is hard,
and pain is inevitable, especially in the early stages. People’s jobs will change. The
vision helps motivate people by giving them a compelling reason to make the change.
Perhaps most importantly, it underlines the fact there is really no job security in the
status quo.
 Alignment – It helps to start the coordinated action necessary to assure that hundreds,
perhaps even thousands, of people work together toward a new and more personally
rewarding goal. With a clarity of vision, people are empowered to take the actions
necessary to achieve the vision without the constant need for management supervision
or check-ins.
In the case of a SAFe transformation, the vision for change must be rooted in an
understanding of the Lean-Agile Mindset and SAFe Principles. It is also critical that leaders
understand that how they lead has a direct correlation to whether or not employees buy into
the change and contribute to its success. The Lean-Agile Leadership competency article
describes the leader behaviors that create a positive environment for change.
Take an Economic View

Whether reactive or proactive, the primary reason to drive change in an organization is to
realize the business and personal benefits that the change is intended to deliver. SAFe
Principle #1 reminds us to always ‘Take an economic view.’ In this context, leaders should
articulate the goal of the change in terms everyone can understand. Dozens of case
studies show that enterprises can expect to see benefits in four major areas, as Figure 1
illustrates.
Figure 1. SAFe business benefits: improved time-to-market, quality, productivity, and employee
engagement
Change leaders should communicate these intended benefits as part of the vision for the
change. In addition, leaders should describe any other specific, tangible objectives they hope
to accomplish. This should include baseline metrics that illustrate the current state, why the
current state is unsustainable, the target future state for the same metrics, and the strategy for
how the change will achieve those targets. Measurable improvement on these key
performance indicators will provide the fuel necessary to escape the inertia of the status quo.
Getting There – Leading SAFe

Too many change initiatives die before they begin by getting ahead of themselves. While
training people and forming Agile Release Trains (ARTs) may feel like progress, these
efforts inevitably stall in the face of organizational inertia unless supported by a senior
leadership team with a shared reason and vision for change that has reached the tipping
point.
The most consistently effective way for organizations to reach the tipping point is the shared
experience of leaders and key influencers attending Leading SAFe.
While it can be challenging for senior leaders to commit two days of dedicated time,
evidence from hundreds of implementations demonstrates that this course is critical to
establishing a truly shared reason and vision for change. Leaders must take the time, as a
group, to collaboratively explore, analyze, and validate for themselves the challenges facing
the organization. They must evaluate how the current system contributes to those challenges
and learn the mindset, principles, and practices they will need to adopt to achieve the
transformative results they envision.
Addressing SAFe Implementation in Government

A growing list of published case studies and experience reports (such as the ones for Centers
for Medicare and Medicaid and Pole emplôi) show that the principles and practices of SAFe
work just as well in a government context as they do in a commercial setting. However, the
challenges of organizational context, culture, and governance in public-sector programs are
truly unique. Government acquisition processes and laws are intended to create a fair playing
field among potential providers, but they can also create bureaucracy and delay. In addition,
government agencies do not have the competitive market dynamic and profit motive that
drives rapid change and innovation in a commercial environment. Instead, funding is
typically provided by legislative bodies in politically-charged annual appropriations
processes that move slowly. Even the concept of value in a government technology program
is often difficult to conceptualize and measure.
To help government agencies get past the tipping point and make the decision to adopt
SAFe, there is specific guidance in the framework that directly addresses the most frequent
impediments to embracing Lean-Agile in government and provides practical solutions for
overcoming these challenges. Read more about these recommendations in the SAFe for
Government article series. In addition, the SAFe for Government course orients learners to
the best practices for implementing SAFe in a government context. Like Leading SAFe, this
course can be used to help decision-makers ‘go SAFe.’ It can also help orient other agency
and industry partner leaders to the recommended patterns for aligning budgeting, forecasting,
contracting, governance, compliance, and much more to Lean-Agile principles and practices.
Moving Forward
A clear vision and compelling reason for change are wasted if not accompanied by a
powerful guiding coalition to carry the vision forward [4]. The tipping pointis just the start
of forming that guiding coalition. SAFe is a proven framework that has delivered
transformative results for hundreds of organizations in every industry across the globe.
Given a compelling reason to change, the next step is a commitment from leadership to build
a transformation team to gain knowledge and explore possible pathways to launching the
SAFe implementation.
Therefore, the next critical move is to Train Lean-Agile Change Agents.
Next
Learn More
[1] Gladwell, Malcolm. The Tipping Point: How Little Things Can Make a Big Difference.
Little, Brown and Company, Kindle Edition.
[2] Cho, Fujio. Chairman of Toyota, 2006-2013.
[3] Sinek, Simon. Start with Why. Penguin Group, Kindle Edition.
[4] Kotter, John P. Leading Change. Harvard Business Review Press, Kindle Edition.
Additional Resources
SAFe Executive Workshop Toolkit
permissions.
Certified SAFe® Program Consultant

…the people who are crazy enough to think they can change the world are the ones who do.
—Apple’s 1997 Think Differently Campaign
Find a Course:
Certified SAFe® Program Consultants (SPCs) are change agents who combine their technical
knowledge of SAFe with an intrinsic motivation to improve the company’s software and
systems development processes. They play a critical role in successfully implementing
SAFe. SPCs come from numerous internal or external roles, including business and
technology leaders, portfolio/program/project managers, process leads, architects, analysts,
and consultants.
Details
A Critical Role for a Critical Need
As outlined in the Implementation Roadmap series, changing the development practices and
behavior of an enterprise is a significant challenge. To achieve meaningful and lasting
change, author John P. Kotter notes that a “sufficiently powerful guiding coalition” of
stakeholders is needed [1]. Such a coalition requires:
 Leaders who can set the vision, show the way, and remove impediments
 Practitioners, managers, and change agents who can implement specific process
changes
 Sufficient organizational credibility to be taken seriously
 The expertise needed to make fast, intelligent decisions
In enterprises new to SAFe, many of these attributes rest with experienced and trained SPCs.
Responsibilities
As knowledgeable change agents, SPCs participate in many of the activities identified in the
12 critical moves described in the SAFe Implementation Roadmap. Specifically, they assist
with:
 Reaching the tipping point – They communicate the business need, urgency, and
vision for change.
 Training executives, managers, and leaders – They socialize the new concepts and
provide orientation and overview training. SPCs teach Leading SAFe to leaders,
managers, and stakeholders.
 Establishing a Lean-Agile Center of Excellence (LACE) – SPCs assist the LACE
with building and executing the transformation backlog.
 Identifying Value Streams and Agile Release Trains (ARTs) – Working with
stakeholders to understand the flow of value, SPCs identify value streams and ARTs
to find those that are the most opportunistic for launch.
 Creating the implementation plan – SPCs participate in creating a plan for the
rollout, communicate upcoming changes, and establish metrics.
 Preparing for the ART launch – SPCs help the LACE plan and prepare for the ART
launch. They coach leadership and help facilitate the creation of new Agile Teams.
They also train or source training of executives, leaders, development teams, and
specialty roles—such as Product Owner, Product Manager, Scrum Master,
and Release Train Engineer (RTE). They also assess and evolve launch and backlog
readiness.
 Training teams and launching the ART – SPCs often directly plan and execute
‘quickstart’ or other rollout strategies. They train or source training for teams and
participate in initial, critical events like Program Increment (PI) Planning and Inspect
and Adapt (I&A). SPCs help establish the ART launch date and calendar for ART and
Team events.
 Coaching ART execution – The SPCs coach leaders and stakeholders to build and
maintain the Vision, Roadmap, and Program Backlogs. They coach teams, Product
Owners, Product Managers, Architects, and RTEs. They guide the shift from project-
to-product with a focus on Customer Centricity and Design Thinking as part of Agile
Product Delivery. They also participate in Scrum of Scrums and System Demo,
facilitate I&A and follow-up on improvement items. Finally, they help teams
establish a DevOps culture and mindset, the Continuous Delivery Pipeline,
infrastructure, and associated Agile technical practices.
 Launching more ARTs and value streams – SPCs work to enable new change
agents to increase organizational capacity to support new value streams, start more
ARTs, and expand the reach of the LACE. They communicate progress and highlight
early accomplishments.
 Extending to the portfolio – Once Lean-Agile practices gain momentum, SPCs can
socialize and drive those practices to the portfolio level, including Portfolio
Vision, Lean Budgets and Guardrails, Lean Portfolio Management, leaner approaches
to CapEx and OpEx, and Agile Contracts. They also communicate the value
of Strategic Themes. (Note that some organizations may opt to implement LPM much
earlier in their SAFe transformation.)
 Accelerating – An enterprise’s SAFe journey doesn’t end with the launching of trains
and the adoption of Lean Portfolio Management. SPCs have expert mastery of the
seven competencies of the Lean Enterprise and how they contribute to
achieving Business Agility. They are proficient in using the assessments described
in Measure & Grow to help organizations understand where they are on the path to
business agility. SPCs can also help develop the action plans that will enable the
enterprise to advance through the sit-crawl-walk-run-fly journey in each of the 21
dimensions across the SAFe competencies.
How Many SPCs Do You Need?

At first glance, the list above seems daunting. No single SPC could accomplish all this alone.
Viewed broadly, however, the knowledge and skills of an SPC can’t be limited to a few
select people. Instead, many leaders across the emerging Lean-Agile business must master
these distinctive new competencies. This means most companies will need to have many
SPCs (perhaps as many as 3 – 5 per 100 development practitioners) to drive and sustain the
implementation.
Training SPCs
SPCs must be trained for their new role, acquiring the skills
and tools needed to execute their responsibilities, as well as to coach and teach others to
implement and support the change. The best way to achieve this is to take the Implementing
SAFe with SAFe® Program Consultant (SPC) certification class. This four-day course
prepares SPCs to become the change agents who lead the transformation. Attendees learn
how to effectively apply the principles and practices of SAFe and organize, train, and coach
Agile teams. They also learn how to identify value streams, identify and launch ARTs, and
help build and manage an Agile portfolio.
Scaling Lean-Agile across the enterprise also requires training all the people who do the
work. To make this practical and cost-effective, Scaled Agile, Inc.supports a train the trainer,
fan-out model, licensing SPCs to teach SAFe courses that support the other key roles in the
implementation. This provides an affordable training strategy and supplies the trainers
needed to achieve the mission of company-wide change.
I’m an SPC, Now What?
After passing an exam, attendees become certified SPCs, gaining access to a variety of
helpful SPC resources to facilitate SAFe adoption. They will also be licensed to teach the
courses listed here.
Learn More
[1] John P. Kotter. Leading Change. Harvard Business Review Press, 1996.
permissions.
Identify Value Streams and ARTs

Break down barriers between departments.
This is article five in the SAFe® Implementation Roadmap series. Click here to view the

entire roadmap.
The first four ‘critical moves’ of the Implementation Roadmap establish the urgency for
change, and the critical mass of informed and dedicated people needed to implement
SAFe effectively:
 Reaching the Tipping Point

 Train Lean-Agile Change Agents
 Train Executives, Managers, and Leaders
 Create a Lean-Agile Center of Excellence (LACE)
With a sense of urgency and a powerful coalition in place, it’s now time to implement SAFe.
This article describes the next critical move—Identify Value Streams and Agile Release
Trains (ARTs). Value streams and ARTs are the organizational backbone of a SAFe
initiative and are critically important to this journey. Attempting to shortcut or breeze
through this step would be the same as putting your foot on the brake at the same time you
are trying to accelerate. But get this one right, and the organization will be well on its way to
a successful transformation.
Details
Identifying Value Streams and Agile Release Trains (ARTs) requires an understanding of a
new organizational model, one that is optimized to facilitate the flow of
value across functional silos, activities, and boundaries, and includes the following steps:
 Identifying the operational value streams

 Identifying the systems that support the operational value stream
 Identifying the people who develop and maintain those systems
 Defining the development value streams that contain the systems and people
 Identifying the ARTs that realize the development value streams
The sections below describe each of these activities.
A Value Stream Refresher

A value stream is a primary construct for understanding, organizing, and delivering value in
SAFe. As illustrated in Figure 1, each value stream is a long-lived series of steps used to
create value—from concept to the delivery of a tangible result for the customer. Like any
well-constructed narrative, the Value Stream identifies a chronological flow of activities:
Figure 1. The anatomy of a Value Stream

 Trigger – Some important event triggers the flow of value, perhaps a customer
purchase order or new feature request. It ends when some value—a shipment,
customer purchase, or solution deployment—has been delivered.
 Steps – The chevrons in the middle are the steps the enterprise uses to accomplish
this feat [1]. For example, Figure 2 describes the steps needed to publish the article
you’re reading now on this website.
Figure 2. Steps in the Value Stream that created this article
 Value – The customer receives value when the value stream executes all of its steps.
In Figure 2, the user gets value when she can read the article and increase her
knowledge of SAFe.
 People and systems – A value stream also contains the people who do the work, the
systems they operate, and the flow of information and materials. For example, in
Figure 2, the people who write the articles, those who maintain the website, the
WordPress application that makes the site functional, and Amazon’s Web Service
hosting systems are all part of the value stream.
 Lead time – The time from the trigger to the delivery of value is the lead time.
Shortening the lead time reduces the time to market. The easiest way to shorten lead
time is to identify and reduce (or remove) non-value added activities and wasteful
delays. That’s the primary focus of Lean thinking.
Types of Value Streams

Note that there are two types of value streams [1] as illustrated in Figure 3.
Figure 3. Operational and development value streams
 Operational value streams – These are the people and steps used to provide goods
or services to a customer. Examples might include manufacturing a medical
instrument, or ordering and receiving a part from a supplier.
 Development value streams – These are the people and steps used to develop new
products, systems, solutions, and services sold by the enterprise, or that support
internal operational value streams. These are the value streams that constitute a SAFe
portfolio.
SAFe concerns itself primarily with development value streams. After all, delivering new
solutions in the shortest sustainable lead time is the focus of SAFe, and value streams help
organizations understand how to get there. However, the enterprise’s operational value
streams must be identified to determine the development value streams that support them.
Identify Operational Value Streams

For some organizations, identifying operational value streams is easy. Many are just the
products, services, or solutions that the company develops and sells.
In the larger enterprise, however, the task is more complicated. Value flows through various
applications, systems, and services—across many parts of the distributed organization—to
both internal and external customers.
In these cases, identifying operational value streams is an essential analytical activity. Figure
4 provides a set of questions that help stakeholders through that process of identification.
Figure 4. Questions to help identify operational value streams
Identifying operational value streams in the large enterprise is not a trivial undertaking. It
requires an awareness of the organization’s broader purpose and an explicit understanding of
how specific elements of value flow to the customer. To assist you, two examples are
provided in the sections below—one from healthcare, and one from financial services.
Value Stream Definition Template
The value stream definition template can be used to further elaborate and understand the
characteristics of the identified value stream. Figure 5 provides an example.
Figure 5. Value stream definition template with an operational value stream example
Healthcare Provider Operational Value Stream Example
The first operational value stream example is a healthcare network provider, as illustrated in
Figure 6 [2]:
Figure 6. A healthcare network provider’s operational value streams
For illustration, this example focuses on the hospital, specifically the value stream that
represents the processes and information systems that support patient treatment—from intake
through treatment and billing.
The trigger for this value stream is the arrival of a patient at the hospital. The hospital
receives the full value after the patient is treated and payments are made for the services
provided, as shown in Figure 7.
Figure 7. Steps in the patient billing value stream
The people indicated above the chevrons (major activities of value delivery) are the people
who execute the various steps in the value stream.
Financial Services Value Stream Example
The second operational value stream example is a banking institution. Figure 8 illustrates the
variety of value streams that might exist in a large financial institution.
Figure 8. A bank and its operational value streams
The red rectangle highlights the ‘consumer banking loan’ value stream used for further
illustration below. The flow of value is triggered by the customer searching for and finding
the bank’s loan offerings and rates and is fulfilled when the customer repays the loan with
interest. The steps and the people who perform them are highlighted in Figure 9.
Figure 9. The consumer loan value stream
(Note: The customer is also a direct participant in this value stream.)
Identify the Systems that Support the Operational Value Stream

Once the operational value stream steps are identified, the next activity is to identify the
systems that are developed to support it. For larger value streams, it’s important to map the
connections from the systems to the various steps in the value stream. This creates a deeper
understanding of how it all works, as the consumer loan example illustrates in Figure 10.
Figure 10. Identifying the systems that support the steps
Identify the People Who Develop the Systems

Once the systems that support the operational value stream have been identified, the next
activity is to estimate the number and locations of the people that build and maintain those
systems, as Figure 11 illustrates.
Figure 11. Identifying the people who develop the systems
Define the Development Value Streams

The next step is to identify the development value streams, which represent the steps needed
to develop those systems as well as the people who develop them. Since these are different
value streams from the operational ones, organizations need to consider what the trigger and
value are. The systems support and enable better operation through the operational value
streams and as such the value is new or amended features in the systems. The triggers, then,
are the requirements and ideas which drive these features.
Figure 12. Defining the development value streams
These triggers can be used to identify the number of development value streams. If most
requirements necessitate touching all systems to enable the new functionality, there is likely
only one development value stream. If, however, the systems are decoupled, there might be a
few of them. In any case, development value streams should be mostly or wholly
independent, and able to develop and release by themselves, without too many intra-value
stream dependencies. In the example in Figure 12, most requirements touch the first three
systems or the last two, but rarely all, and so there are two development value streams, each
capable of developing, integrating, deploying, and releasing independently of the other.
Development Value Streams Cross Boundaries
Once the development value streams are identified, the next step is to start to understand how
to form Agile Release Trains to realize them. The ARTs contain all the people and other
assets needed to enhance the flow of value. The first step is to understand where in the
organization that value is created because that is where the people, processes, and
systems are. When doing so, it becomes obvious that development value streams cross many
boundaries. Enterprises are organized the way they are for many reasons: history, functional
convenience, the efficiency of centralization, acquisitions, geography, and more. As a result,
it’s entirely possible that no one understands the complete series of events necessary to
continually develop and enhance the systems that help deliver the value. Furthermore,
attempts to improve tend to focus on functional, local improvements, which may result in the
optimization of one function or step but sub-optimization of the end-to-end flow.
It is the long-lived nature of value streams that triggers different thinking in the Lean
organization. To address this, enterprises apply systems thinking (Principle #2, Apply
systems thinking) and come to understand how various parts of the system need to work
together to accomplish improved flow. Typically, larger enterprises are organized
functionally. In addition, people are distributed across multiple geographies and multiple
countries. But value moves acrossthese boundaries, as Figure 13 illustrates.
Figure 13. Value flows across functional, organizational, and geographic boundaries
Identify the ARTs

The final activity is to define the ARTs that realize the value. Experience has shown that the
most effective ARTs have the following attributes:
 50 – 125 people
 Focused on a holistic system or related set of products or services
 Long-lived, stable teams that consistently deliver value
 Minimize dependencies with other ARTs
 Can release independent of other ARTs
Depending on how many people do the work, there are three possible scenarios for the ART
design, as Figure 14 illustrates.
Figure 14. Three possible scenarios for ART design

 Multiple development value streams can fit within a single ART – When several
related products or solutions can be produced with a relatively small number of
people, a single ART may deliver multiple value streams. In this case, the ART is
roughly the same as the value stream. Everyone is in that ART!
 A single development value stream can fit within an ART – Often, a Value Stream
can be realized with 100 or fewer practitioners. Many development groups are already
organized into units of about that size, so this is a common case. Again, everyone is
on the ART.
 Multiple ARTs are required for large development value streams – When a lot of
people are involved, the development value must be split into multiple ARTs, as
described in the next section, and form a Solution Train.
Splitting Large Value Streams into Multiple ARTs
Large development value streams are very common in large enterprises and often some
additional analysis is required. When possible, trains should be focused on a single, primary
system, or a set of closely related products or services in that value stream. This is a fairly
simple design—one ART delivering a well-defined set of valuable things.
However, in the case where many people are needed to deliver a single system, it works best
when teams work together while developing features and components that have high degrees
of interdependence. This leads to the relatively common pattern of organizing ARTs around
‘feature areas’ or subsystems.
 Feature area ARTs are optimized for flow and speed. In this case, individual teams
on the train, and the entire train itself can deliver end-to-end features. The benefit is
obvious, and that’s why they’re preferred. But pay attention to subsystem governance,
or else the system architecture will decay, ultimately reducing velocity. Often, a
system architect (one or more individuals, or even a small team) is dedicated to
maintaining platform integrity.
 Subsystem ARTs applications, components, platforms, and so on, are optimized for
architectural robustness and reuse of subsystems and services. Again, the benefit is
obvious, as this can increase development and reuse efficiencies. (Service-oriented
architectures leverage this.) However, depending on the separation of concerns in the
system architecture, the flow of value in this scenario can create more dependencies,
and require coordination among the ARTs.
There’s no one right solution, and large systems typically require both types of ARTs. A
typical example is when multiple ARTs provide services or solutions based on a common
platform. In that case, there may be one or more platform ARTs supporting the feature
ARTs, as Figure 15 illustrates.
Figure 15. A common feature area
ART and platform ART pattern
There is another common pattern, where ARTs realize specific segments in a larger Value
Stream. That may not seem fully end-to-end, but in reality, the ‘beginning and end’ of a
Value Stream are relative notions. The types of input, value, and systems may be very
different in these segments, creating a logical dividing line.
And of course, combinations of these models often appear in the larger value streams, as our
final example in Figure 16 illustrates.
Figure 16. Combinations of ART patterns in the consumer bank loan example
Finally, there are other ART design and optimization factors based on concerns such as
geography, spoken language, and cost centers—all of which may influence the ART design.
But these are far less desirable.
The SAFe Value Stream and ART identification Workshop

As demonstrated, there’s critical thinking and analysis involved in
this process. To help identify value streams, Scaled Agile, Inc. provides a Value Stream and
ART identification workshop toolkit, consisting of a workshop and other artifacts that SAFe
Program Consultants (SPCs) can use to guide stakeholders. The workshop provides a
structured approach to identifying value streams and to defining ARTs, which can realize the
flow of value in the enterprise. This toolkit offers a proven, systematic approach to optimize
the design by considering the dependencies, coordination, and constraints.
The Value Stream and ART identification workshop is often run directly following
a Leading SAFe class with key stakeholders. The objective is to take them through the
process of identifying the value streams, designing the ARTs, and perhaps even picking the
date for the first ART launch after they have a fundamental understanding of Lean-Agile
development enabled by SAFe.
Because no design is perfect, enterprises sometimes repeat this workshop after learning
more, as part of the Accelerate roadmap step. Doing this allows enterprises to refine their
understanding of value streams and ARTs and incorporate new learnings into the
organizational design.
Moving Forward
This article described how teams do the work to identify the value streams and design the
ARTs that form the basic organizational structure for the transformation.
Now it’s time for the next step, Create the Implementation Plan, which is the next article in
the SAFe Implementation Roadmap.
Next
Learn More
[1] Allen Ward, Lean Product and Process Development. (video) Lean Enterprise Institute,
2004
[2] Contributed by SPCT candidates Jane Tudor, Justine Johnston, Matt Aaron, Steve
Mayner, and Thorsten Janning.
[3] Contributed by SPCT candidates Darren Wilmshurst, Murray Ford, Per-Magnus Skoogh,
Phillip Manketo, Sam Bunting, and Virpi Rowe.
[4] Knaster, Richard and Leffingwell, Dean. SAFe Distilled, Applying the Scaled Agile
Framework for Lean Software and Systems Engineering. Addison-Wesley, 2017.
Value Stream and ART Identification Workshop Toolkit for SPCs.
permissions.
Invitation-based SAFe Implementation
by Yuval Yeret, CTO, AgileSparkses
Introduction
Implementing any kind of organizational change, such as adopting SAFe, is hard and raises
several key concerns:
 How do we convince people to adopt the new ways of working?

 How do we get the organization moving in the new direction?
 How do we make decisions about how to implement SAFe in the enterprise?
SAFe recommends decentralizing control while providing vision and gaining alignment. It is
also about respecting people and culture and maintaining effective flow. In this guidance
article, we will discuss ways we can “Walk that talk” in the way we run a SAFe
implementation.
The default approach for implementing organizational change is the “mandate” or “push”
approach. This may appear to be the fast and easy way, where a central group of change
agents decide when people will “board” the Agile Release Train (ART), as well as how the
train should operate.
It may seem easy because the change is mandated and there is little or no discussion about
whether the change should occur. It also appears to reduce the risk of a shallow SAFe
adoption that doesn’t even cover SAFe’s 10 critical success factors, due to bad
implementation decisions, by people who have limited or no experience. The problem with
this classic approach is mainly that people don’t like to be changed. They like to be involved
in making the decision to change as well as designing the change.
The Vision – Implementing SAFe using Invitations

Martin Fowler, one of the Agile Manifesto signatories, wrote an article in 2006 called “The
Agile Imposition.” In the article, Fowler says, “Imposing an agile process from the outside,
strips the team of the self-determination, which is at the heart of agile thinking.” But what if
we can’t wait for people to self-determine that they should go agile? Should the organization
wait? Even if it kills the business?
SAFe’s 9th principle – “Decentralize Decision Making” provides some guidance here. The
decision whether to go agile and what approach to take is infrequent, long
lasting, and provides a significant economy of scale. So it is a classic strategic decision to
centralize.
But once that central decision to go SAFe has been made, The Agile Manifesto says, “Build
projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.” And “The best architectures, requirements, and designs
emerge from self-organizing teams.” If we apply these two principles to SAFe
implementation this would mean the best plans for implementing SAFe will emerge from
self-organizing teams (or teams of teams) of the people adopting SAFe. Implementing SAFe
using a leaner and more agile approach will send a message about the strength of
management’s commitment to the Lean-Agile mindset described in SAFe. Can you think of
a better way to signal “respect for people and culture”?
In PI planning Business Owners and Product Management present the business context, the
vision. The planning context and structure of PI Planning is a “container” in which the Agile
Release Train self-organizes to figure out how and how much they can do to further the
vision.
Similarly, Invitation-based SAFe implementation needs to set the context and provide the
right structure for the group to figure out how much of SAFe they can achieve in their first
implementation PI. A flow of an invitation-based implementation can be seen in figure 1,
with the blue boxes showing the potential places to involve an invitation to leaders and
practitioners.
Figure 1. Invitation-based SAFe implementation flow
Using the SAFe Implementation Workshop to invite the Enterprise

to consider SAFe
“Leadership is charged with making these types of [strategic] decisions, supported by the
input of those impacted by the decisions.” (SAFe Principle #9, Decentralize decision
making)
One approach that my company, AgileSparks, has discovered works well when teaching
Leading SAFe is to accompany pure training-mode with a “SAFe Implementation
Workshop.” In this workshop, whose agenda you can see in figure 2, a group of leaders
discuss:
 The reasons for considering SAFe

 How good of a fit SAFe seems to be
 Identifying value streams and designing ARTs
 Guidelines for determining how roles in SAFe are chosen or assigned to people
 Implementation risks and organizational impediments
Figure 2. Implementation workshop sample agenda
Through this interactive, collaborative process members of this group will become the initial
“guiding coalition,” a term popularized by Kotter. They consider options, make decisions,
and commit to working together towards the shared vision.
As you can see in the “SAFe Invitations Implementation Approach Roadmap” above, this
workshop format is useful when considering SAFe with a group of leaders across an
enterprise/division as well as later on when preparing to launch a specific Value Stream or
Agile Release Train. Another way to look at is as a different variant of how to run the SAFe
Value Stream workshop that is frequently used following up an Implementing SAFe/Leading
SAFe class to help identify Value Streams/Agile Release Trains for an actual implementation
of SAFe in the organization.
Spreading SAFe through an invitation to Leaders

The outcome of the enterprise-level implementation workshop is an invitation to potential
value streams and/or ARTs to consider what SAFe would mean in their context and figure
out when/how to start their SAFe journey.
In most cases, the potential ART/VS leaders (think VP level leaders) participated in the
initial Leading SAFe + Implementation workshop and are now ready to consider bringing
SAFe to their group.
In larger enterprises, there might be a need for further Leading SAFe+Implementation

Workshops to expose more potential ART/VS leaders. In the “Invitations” spirit you can
invite leaders to participate in such a class or bring SAFe into their organization, not
force/mandate them. The first leaders to accept the invitation are ideal “prospects”
(innovators or early adopters) for starting the SAFe journey and should be where SPCs
should initially spend most of their time.
Using the SAFe Implementation Workshop to launch a

Program/Value Stream
Once a leader decides that the timing is right to consider SAFe in their area, they should
again repeat the same pattern – Leading SAFe combined with a SAFe Implementation
Workshop to figure out how to go SAFe. This time the audience is Lean/Agile leaders for the
ART/VS as well as ART/VS roles such as RTE, Product Management, System Architect.
Typically the Product Owners and Scrum Masters don’t participate in this workshop—in
many cases, it is in this workshop where the leadership team figures out what is the mapping
between the PO/SM/PM roles and the roles and people in the group.
As the POs, SMs, PMs, are identified they get trained in PO/PM and SAFe Scrum Master
workshops. When using the “SAFe Invitations” implementation approach these workshops
should include vignettes from the implementation workshop such as starting with a
pains/why session and gauging confidence level and ROAMing implementation risks
towards the end of the training.
This will help SMs/POs/PMs connect to the vision and feeling more involved in designing
the implementation approach. This will rally them to join the “guiding coalition” of the
group.
Invitation-based ART Launch

Once leaders of a certain area are on board and have identified an Agile Release Train/Value
Stream to focus on and the ART stakeholders/roles have been trained and brought on board
as well, it is time get the team-of-teams rolling.
The combination of training everybody using “SAFe for Teams” at the same time with
planning the initial PI and getting a real feel for how SAFe will look like works better than
just sticking to theory, training exercises, and games.
Bringing an invitation approach into the ART Launch means decentralizing some decisions
around how to operate SAFe to the people on the ART themselves. Aspects like program
board structure, Definition of Done (DoD) policies, ready policies, engineering practices,
agile testing strategies, and some other aspects are great candidates for having the breakout
and integrate discussions as part of the SAFe for Teams training. Additionally, you may want
to allow teams to make other local decisions about how they use SAFe, as long as they’re
aligned with the SAFe principles and it does not cause problems for the other teams on the
train, or the ART as a whole, as can be seen in figure 3.
Figure 3. Invitation-based ART Quick Start

As a blueprint for how the ART will work starts to emerge, it’s time to gauge people’s level
of confidence for how the implementation of SAFe will work and surface risks. You can use
a “fist of five” confidence vote, similar to what we do in PI planning to gather this feedback,
as well as proactively inviting people to share their concerns.
Follow up with questions like, ‘Based upon what we just learned so far, are there any
significant concerns that would prevent us from starting to use SAFe?’ The responses from
the teams can be used to seed topics for a brief problem-solving workshop or ‘open space’
session, where people can raise their concerns, and then join or lead a breakout session to
identify solutions.
Another approach is to ROAM each risk/issue like we do in PI Planning. The use of the
facilitation techniques, like ROAMing risks, confidence vote, and open space all demonstrate
a “servant leadership” style. As leaders, we are not just telling people what to do, we are
involving them in figuring out the ‘how’ and serving them by owning a resolution of key
systemic risks to the change. This same technique can be applied during PI Planning
confidence vote and “ROAMing” of the risks.
Another interesting practice that invites people on the ART to participate in figuring out
implementation details is team self-selection. In this practice, the ART leaders provide
guidelines/constraints and let the people on the ART figure out what at the actual teams
should look like. [8] [9] [10]
Caution: Be careful when allowing customization at this point. There’s a two-fold risk,
either removing too much from the SAFe model, as well as adding too much overhead with
additional process. There’s tremendous value to trying out the SAFe framework, more or less
“as is,” or with careful configuration/customization with the help of a seasoned SAFe
program consultant, and only then continuing to remove/add/change practices. For a view on
the critical elements that shouldn’t be changed, please see SAFe’s 10 critical success factors.
Summary – Evolving SAFe’s Implementation Approach with

SAFe’s Lean-Agile Principles
In essence, the approach described above uses Lean-Agile practices and principles to drive
the adoption of SAFe. Using SAFe to adopt SAFe. We’re asking leaders to set the
vision/direction for implementing SAFe and inviting their people to come on board and
participate in designing this change that will have so much positive impact on how work will
be performed in the future.
Decentralizing control and engaging as many people as possible in figuring out how to use
SAFe tends to improve the quality of SAFe implementation because of ‘Wisdom of the
Crowds’ and the higher motivation people have when they’re invited to be involved. This
applies to leaders at various levels using the SAFe Implementation Workshop that
complements Leading SAFe training and to teams and ART stakeholders using vignettes like
pains/vision mapping, implementation confidence votes, and risk ROAMing in each and
every SAFe training used to prepare and launch SAFe in ARTs/VSs.
Learn More
http://www.agilesparks.com/safe-implementation-strategy-leadership-focusing-workshop/
[1] https://www.linkedin.com/pulse/openspace-agility-right-you-daniel-sloan
[2] John Kotter. Leading Change. Harvard Business Press, Dec 30, 2013
[3] http://openspaceagility.com/big-picture/
[4] http://yuvalyeret.com
[5] http://www.infoq.com/news/2014/10/kickstart-agile-kanban
[6] http://www.infoq.com/interviews/lkfr14-yeret-kanban-agile
[7] https://management30.com/practice/delegation-board/
[8] https://www.linkedin.com/pulse/large-scale-self-selection-australia-post-interview-andy-
sandy-mamoli
[9] https://www.amazon.com/Creating-Great-Teams-Self-Selection-People-
ebook/dp/B019EKWG6M/
[10] https://www.scrumalliance.org/community/articles/2013/2013-april/how-to-form-teams-
in-large-scale-scrum-a-story-of
permissions.
Prepare for ART Launch

Short-term wins help build necessary momentum.
—Kotter
This is article seven in the SAFe® Implementation Roadmap series. Click here to view the
entire roadmap.
Previous articles in the SAFe Implementation Roadmap series discussed the first six ‘critical
moves’ in an implementation:

 Identify Value Streams and Agile Release Trains (ARTs)
 Create the Implementation Plan
By now, the enterprise has identified their value streams and established an implementation
plan. It will also have loosely defined the first ART. This is a pivotal moment, as plans are
now moving toward implementation. From a change-management perspective, the first ART
is very important, with potentially far-reaching implications. This will be the first material
change to the way of working and will generate the initial short-term wins that help the
enterprise build momentum. This article describes the activities necessary to prepare for the
ART launch.
Details
Now is the time to execute the activities necessary for a successful ART launch. SPCs often
lead the implementation of the initial ARTs, supported by SAFe-trained program
stakeholders and members of the Lean-Agile Center of Excellence (LACE).
No matter who leads, the larger activities in preparing the launch include:
 Define the ART

 Set the launch date and cadence for the program calendar
 Train ART leaders and stakeholders
 Establish the Agile teams
 Train Product Managers and Product Owners (POs)
 Train Scrum Masters
 Train System Architects/Engineers
 Assess and evolve launch readiness
 Prepare the program backlog
Each of these activities is described in the sections below.

Define the ART
In Create the Implementation Plan, the process stakeholders used to identify the first value
stream and ART were defined. At that stage of planning, the ART is defined with just
enough detail to determine that it’s a potential ART. However, the parameters and
boundaries of the ART are left to those who better understand the local context, as shown in
Figure 1 [1].
Figure 1. Agile Release Train Canvas
A key benefit of the canvas is to help teams identify the principal ART roles. ARTs work
only when the right people are given the right responsibilities. After all, the ART
organization is a system. All the necessary responsibilities of solution definition, building,
validation, and deployment have to be realized for the system to function properly. Filling in
the key roles on the canvas fosters these discussions and highlights the new responsibilities.
To understand who the Business Owners are, special care must be taken. Clearly, they
include internal and external customers and/or their Product Management proxies. “Applying
a systems view,” however, means that others should often be included as well—for example,
VPs of development/technology, data center managers, enterprise and security architects, and
marketing and sales executives. Only the right set of Business Owners can collectively align
differing organizational responsibilities and perspectives.
Set the Launch Date and Program Calendar

With the ART definition in hand, the next step is to set the date for the first Program
Increment (PI) Planning event. This creates a forcing function, a ‘date-certain’ deadline for
the launch, which will create a starting point and define the planning timeline.
The first step is to establish the cadence for the program, including both the PI and iteration
lengths. The SAFe Big Picture shows a 10-week PI, which consists of four regular iterations
and one Innovation and Planning (IP) iteration. There is no fixed rule for the PI cadence, nor
for how much time should be reserved for the IP iteration. The recommended duration of a
PI is between 8 to 12 weeks, with a bias toward the shorter duration (10 weeks, for example).
Once the cadence is chosen, it should remain stable and not arbitrarily change from one PI to
another. This allows the ART to have a predictable rhythm and velocity. The fixed cadence
also allows a full year of program events to be scheduled on people’s calendars. The PI
calendar usually includes the following activities:
 PI planning
 System Demos
 ART Sync, or individual Scrum of Scrum and PO Sync meetings
 Inspect and Adapt (I&A) workshop
This advance notice reduces travel and facility costs and helps assure that most of the
stakeholders will be able to participate. Once the program calendar is set, team events can
also be scheduled, with each team defining the time and place for their daily meetings,
iteration planning, demos, and retrospectives. All teams on the train should use the same
iteration start and end dates, which facilitates synchronization across the ART.
Train the ART Leaders and Stakeholders

Depending on the scope and timing of the rollout, there may be a number of ART leaders
(Release Train Engineer, Product Managers, System Architects) and stakeholders (Business
Owners, managers, internal suppliers, operations, etc.) who have not attended a Leading
SAFe training session. They will likely be unfamiliar with SAFe, unclear on expectations,
and may not understand the need and benefits of their participation. It’s important that they
understand and support the model, as well as the responsibilities of their role. In that case,
SPCs will often arrange a Leading SAFe class to educate these stakeholders and motivate
participation. This is often followed by a one-day implementation workshop, where newly
trained stakeholders and SPCs can create the specifics of the launch plan. After all, it’s their
ART; only they can plan for the best outcomes. Essentially, this is the handoff of primary
responsibility for the change from the change agents to the stakeholders of the newly formed
ART.
Organizing Agile Teams

During the implementation workshop, questions will arise as to how to organize the Agile
teams with respect to the system architecture and solution purpose. Similar to organizing the
ARTs themselves (see Create the Implementation Plan), there are two primary patterns for
organizing Agile teams:
 Feature teams are focused on user functionality and are optimized for fast value
delivery. This is the preferred approach, as each is capable of delivering end-to-end
user value. They also facilitate the growth of “T-shaped” [2] individual skills.
 Component teams are optimized for system robustness, component reuse, and
architectural integrity. It is recommended that their use is limited to when there are
significant component reuse opportunities, high technical specialization, and critical
Nonfunctional Requirements (NFRs). After a component has matured, the feature
teams, with some lightweight governance, can take on the future development of the
component. The original component team can then be reorganized for other feature or
component work.
Most ARTs have a mix of feature and component teams (see the Guidance article). However,
ARTs should generally avoid organizing teams around a technical system infrastructure
(architectural layer, programming language, middleware, user interface), as this creates many
dependencies, impedes the flow of new features, and leads to brittle designs.
Forming the Agile Teams

The next step is to form the Agile teams that will be on the train. One innovative solution is
to enable the people on the ART to organize themselves into Agile teams with minimal
constraints (see Em-Campbell Pretty’s blog on self-organization [3]). In other cases,
management makes initial selections based on their objectives, knowledge of individual
talents and aspirations, timing, and other factors. In most cases, a bit of back and forth
between management and the teams will be needed. Teams have a better understanding of
their local context and know how they like to work. Managers add perspective based on
current individual, organizational, and product development strategies.
Prior to PI planning, all practitioners must be part of a cross-functional Agile team, and the
initial roles of Scrum Master and Product Owner must also be established.
The team roster template shown in Figure 2 is a simple tool that can help bring clarity and
visibility to the organization of each team.
Figure 2. An Agile team roster template
The simple act of filling out the roster can be quite informative, as it starts to make the more
abstract concepts of Agile development concrete. After all, the structure of an Agile team is
fairly well defined; the question of who is on the team, and the nature of the specialty roles,
can lead to interesting discussions. Even the seemingly simple act of dedicating an individual
to one Agile team can be an eye-opening experience. But there’s no going back. The proven
success patterns of Agile, including ‘one person–one team’ are fairly clear.
The geographic location column is also interesting, as it defines the level of collocation and
distribution for each team. Collocation is better, of course. But there may be cases where one
or more individuals cannot be physically collocated with the others. That may evolve over
time, but at least everyone understands where the current team members reside, so they can
start thinking about Daily Stand-up (DSU) times and other team events. Many transformation
teams also include the name and contact information of the direct supervisors for each
member of the ART to ensure proactive communication and coordination takes place with
these managers before changes are announced (they should also be invited to attend Leading
SAFe!).
Train Product Owners and Product Managers
Product Managers and Product Owners steer the train

together. They have content authority over features and stories, respectively. These two roles
are critical to the success of the ART, and the people fulfilling these roles must be well
trained to ensure optimal collaboration, learn the new way of working, and understand how
to best fulfill their specific responsibilities. In addition, these roles will be largely responsible
for building the initial program backlog, which is a key artifact for PI planning.
Scaled Agile, Inc.’s two-day SAFe Product Owner/Product Manager course is designed

specifically for this purpose. The course teaches Product Owners and Product (and Solution)
Managers how to drive the delivery of value in the SAFe enterprise. Attendees get an
overview of SAFe’s Lean-Agile Mindset and principles, as well as an in-depth exploration of
role-specific practices. Attendees learn how to write Epics, Features, and User Stories, how
to establish the Team and Program Kanban systems to manage the flow of work, and how to
manage and prioritize backlogs using Weighted Shortest Job First (WSJF).
Train the Scrum Masters

Effective ARTs, in large part, rely on the servant leadership
of the Scrum Master and their ability to coach Agile Team members and improve the
performance of the team. It’s a specialty role that includes traditional Scrum leadership
duties, as well as responsibilities to the larger team-of-Agile-teams that constitute the ART.
In SAFe, Scrum Masters also play a critical role in PI planning and help coordinate value
delivery through Scrum of Scrums meetings. Obviously, it’s incredibly helpful if they
receive appropriate training prior to the start of the first PI.
Scaled Agile, Inc.’s two-day SAFe Scrum Master course teaches Scrum fundamentals and
also explores the role of Scrum in the context of SAFe. It prepares Scrum Masters for how to
facilitate team iterations, how to successfully plan and execute the PI, how to participate in
ART events, and how to measure and improve the flow of work through the system using
Kanban. This course is beneficial for both new and experienced Scrum Masters.
Train the System Architects/Engineers
System Architects/Engineers support solution development

by providing, communicating and evolving the broader technology and architectural view of
the solution. In so doing, they enable Agile teams to make effective, decentralized decisions
that accelerate the creation of business value, while ensuring that the solution’s architecture
remains robust and sustainable. Individuals fulfilling these roles must not only be
experienced technical experts but must be effective Lean-Agile Leaders skilled at engaging
across the organization. Partnering with Product Management, this role takes on, defines and
owns enabler features in the backlog designed to maintain the architectural runway necessary
to sustain business value creation.
Scaled Agile, Inc.’s three-day SAFe System and Solution Architect courseteaches senior
technical contributors the role of architecture in a Lean-Agile enterprise. Attendees will
explore the principles underlying Lean-Agile architecture and Release on Demand, learn to
lead and support Solution Trains and Agile Release Trains, extend the principles driving
continuous flow to large systems of systems, and discover how to enable an improved flow
of value across an entire portfolio.
Assess and Evolve Launch Readiness

Training people in their new roles and responsibilities is a key part of ART readiness, but it’s
only one element of a successful ART launch. Additional activities are required. However,
since SAFe is based on the empirical Plan-Do-Check-Adjust (PDCA) model, there is no such
thing as perfect readiness for a launch. Even attempting to achieve such a state is a fool’s
errand, as the experience of the first PI will inform future activities. What’s more, trying to
be too perfect up-front will delay learning, postponing the transformation and realization of
its benefits.
That said, a certain degree of readiness will help assure a more successful planning event the
first time. Figures 3 and 4 provide a checklist for some of the ART readiness assessment and
activities.
Figure 3. ART readiness checklist: needed items
Figure 4. ART readiness checklist—helpful items
Most would agree that the majority of the items in Figure 3 are required for a successful
launch. The items in Figure 4 are certainly desirable, but depending upon your
circumstances, they can also be addressed easily over the first few PIs.
Prepare the Program Backlog

As previously mentioned, using the launch date as a forcing function increases the urgency
of determining the scope and Vision for the PI. After all, no one wants to show up at PI
planning without a solid sense of the mission. While it’s tempting to assume that should be
the case prior to the event, experience often shows otherwise. It’s more likely that there will
be multiple opinions about what the new system is supposed to do, and it might take some
time to converge those points of view prior to the launch date.
The scope of the PI, or ‘what gets built,’ is largely defined by the Program Backlog, which
contains the set of upcoming features, NFRs, and architectural work that define the future
behavior of the system. To that end, SPCs and LACE stakeholders often facilitate bringing
the ART stakeholders together to prepare a common backlog. This is typically done in a
series of backlog refinement workshops and other activities, as illustrated in Figure 5.
Figure 5. Preparing the program backlog and related activities
It’s easy to over-invest in backlog readiness, so don’t let that bog the process down, as the
act of planning with the teams will sort out many issues. They typically know what’s best
anyway. Experience shows that a list of well-written features with initial acceptance criteria
is sufficient. Many tend to over-plan and create user stories ahead of time. But that tends to
create waste and disappointment when the vision changes. It’s also a sure way to demotivate
the teams, as creating stories is a significant aspect of their contribution to PI planning.
Moving Forward
So far, it’s been quite a journey. Here’s what has been accomplished so far:
 Reached the tipping point

 Trained Lean-Agile change agents
 Trained executives, managers, and leaders
 Identified value streams and ARTs
 Created the implementation plan
 Prepared for the first ART launch
It’s finally time to leave the station and launch this train! For more on the launch events, read
the next article in this series, Train Teams and Launch the ART.
Next
Learn More
[1] Thanks to SPCT Mark Richards for the ART Canvas inspiration.
[2] https://en.wikipedia.org/wiki/T-shaped_skill
[3] http://www.prettyagile.com/2017/01/facilitating-team-self-selection-safe-art.html
 Leading SAFe
 SAFe POPM
 SAFe Scrum Master

permissions.
Release Train Engineer and Solution Train

Engineer
It is a misuse of our power to take responsibility for solving problems that belong to others.
—Peter Block
The Release Train Engineer (RTE) is a servant leader and coach for the Agile Release Train
(ART). The RTE’s major responsibilities are to facilitate the ART events and processes and
assist the teams in delivering value. RTEs communicate with stakeholders, escalate
impediments, help manage risk, and drive relentless improvement.
The Solution Train Engineer (STE) is a servant leader and coach for the Solution Train,
facilitating and guiding the work of all ARTs and Suppliers in the Value Stream.
Although ARTs and Solution Trains are composed of self-organizing and self-managing
teams, trains don’t drive or steer themselves on autopilot. That responsibility falls to the RTE
or STE, who operate most effectively as servant leaders. They have a solid grasp of how to
scale Lean and Agile practices and understand the unique opportunities and challenges
associated with facilitating and continuously aligning a large development program.
Details
Find a Course:
The RTE and the STE facilitate ART and Solution Train processes and execution,
respectively. They escalate impediments, manage risk, help ensure value delivery, and help
drive relentless improvement. Many also participate in the Lean-Agile transformation,
coaching leaders, teams, and Scrum Masters in the new processes and mindsets. They help
configure SAFe to the organization’s needs, standardizing and documenting practices.
Responsibilities
RTEs and STEs typically fulfill the following responsibilities:
 Manage and optimize the flow of value through the ART and Solution Train using
various tools, such as the Program and Solution Kanbans and other information
radiators
 Establish and communicate the annual calendars for Iterations and Program
Increments (PIs)
 Facilitate PI Planning readiness by fostering a Continuous Exploration process which
drives the synthesis of a Vision, a Roadmap, and Backlogs, and through Pre- and
Post-PI Planning meetings
 Facilitate the PI planning event
 Summarize Team PI Objectives into Program PI Objectives (the RTE) and publish
them for visibility and transparency
 Summarize program PI objectives into Solution PI Objectives (the STE) and publish
them for visibility and transparency
 Assist tracking the execution of features and capabilities (see Metrics)
 Facilitate periodic synchronization meetings, including the ART sync at the Essential
Level and the value stream sync for Solution Trains
 Assist with economic decision-making by facilitating feature and capability
estimation by teams and the roll-up to Epics, where necessary
 Coach leaders, teams, and Scrum Masters in Lean-Agile practices and mindsets
 Help manage risks and dependencies
 Escalate and track impediments
 Provide input on resourcing to address critical bottlenecks
 Encourage collaboration between teams and System and Solution
Architects/Engineering
 Work with Product and Solution Management, Product Owners, and
other stakeholders to help ensure strategy and execution alignment
 Improve the flow of value through value streams by improving and assessing the
practices associated with DevOps and Release on Demand in the Continuous Delivery
Pipeline
 Help drive the Lean User Experience (UX) innovation cycle
 Work with the Agile Program Management Office (APMO) on program execution
and operational excellence (see Lean Portfolio Management)
 Understand and operate within Lean Budgets and ensure adherence to Guardrails
 Facilitate System Demos and Solution Demos
 Drive relentless improvement via Inspect and Adapt workshops; assess the agility
level of the ART and Solution Train and help them improve
 Foster Communities of Practice and the use of engineering and Built-In
Quality practices
Reporting Structure
SAFe doesn’t prescribe a reporting structure, but the RTE and STE typically report to the
development organization or an APMO, which, in SAFe, is considered a part of Lean
Portfolio Management. For enterprises with existing PMO organizations, a program manager
often plays this role.
RTEs and STEs Are Servant Leaders

While new RTEs and STEs typically have the organizational skills to perform their roles,
they may need to learn and adopt Lean-Agile Mindsets. They may need to transition from
directing and managing activities to acting as a servant leader. Servant leadership is a
philosophy that implies a comprehensive view of the quality of people, work, and
community spirit [1]. The focus is on providing the support needed by the teams, ARTs, and
Solution Trains to be self-organizing and self-managing. Characteristic servant leader actions
include:
 Listen and support teams in problem identification and decision-making

 Create an environment of mutual influence
 Understand and empathize with others
 Encourage and support the personal development of each individual and the
development of teams
 Coach people with powerful questions rather than use authority
 Think beyond day-to-day activities; apply systems thinking
 Support the teams’ commitments
 Be open and appreciate openness in others
As Robert Greenleaf, the father of servant leadership, said, “Good leaders must first become
good servants.” Just as there are Lean-Agile transformational patterns for the LPM function,
there are also transformational patterns for a traditional manager moving to a servant leader.
The ‘from’ and ‘to’ states are:
 From coordinating team activities and contributions to coaching the teams to

collaborate
 From deadlines to objectives
 From driving toward specific outcomes to being invested in the program’s overall
performance
 From knowing the answer to asking the teams for the answer
 From directing to letting the teams self-organize and hit their stride
 From fixing problems to helping others fix them
Learn More
[1] See Servant Leadership at http://en.wikipedia.org/wiki/Servant_leadership.
[3] Trompenaars, Fons and Ed Voerman. Servant-Leadership Across Cultures: Harnessing
the Strengths of the World’s Most Powerful Management Philosophy. McGraw-Hill, 2009.
Last update: 12 November 2019
permissions.

Real learning gets to the heart of what it means to be human. Through learning, we recreate
ourselves. Through learning, we become able to do something we never were able to do.
Through learning, we re-perceive the world and our relationship to it. Through learning, we
extend our capacity to create, to be part of the generative process of life. There is within
each of us a deep hunger for this type of learning.
—Peter M. Senge, The Fifth Discipline
The Continuous Learning Culture competency describes a set of values and practices that
encourage individuals—and the enterprise as a whole—to continually increase knowledge,
competence, performance, and innovation.
This is achieved by becoming a learning organization, committing to relentless improvement,

and promoting a culture of innovation.
It is one of the seven core competencies of the Lean Enterprise, each of which is essential to
achieving Business Agility.
Why Continuous Learning Culture?

Organizations today face an onslaught of forces that create both uncertainty and opportunity.
The pace of technology innovation is beyond exponential. Startup companies challenge the
status quo by transforming, disrupting, and in some cases eliminating entire markets.
Juggernaut companies like Amazon and Google are entering entirely new markets such as
banking and healthcare. At any moment, political, economic, and environmental turmoil
threaten to change the rules. Expectations from new generations of workers, customers, and
society as a whole challenges companies to think and act beyond balance sheets and
quarterly earnings reports. Due to all of these factors and more, one thing is certain:
organizations in the digital age must be able to adapt rapidly and continuously or face decline
—and ultimately extinction.
What’s the solution? In order to thrive in the current climate, organizations must evolve into
adaptive engines of change, powered by a culture of fast and effective learning at all levels.
Learning organizations leverage the collective knowledge, experience, and creativity of their
workforce, customers, supply chain, and the broader ecosystem. They harness the forces of
change to their advantage. In these enterprises, curiosity, exploration, invention,
entrepreneurship, and informed risk-taking replace commitment to the status quo while
providing stability and predictability. Rigid, siloed top-down structures give way to fluid
organizational constructs that can shift as needed to optimize the flow of value.
Decentralized decision-making becomes the norm as leaders focus on vision and strategy
along with enabling organization members to achieve their fullest potential.
Any organization can begin the journey to a continuous learning culture by focusing their
transformation along three critical dimensions, as shown in Figure 1.
Figure 1. The three dimensions of a continuous learning culture
The three dimensions are:
1. Learning Organization – Employees at every level are learning and growing so that
the organization can transform and adapt to an ever-changing world.
2. Innovation Culture – Employees are encouraged and empowered to explore and
implement creative ideas that enable future value delivery.
3. Relentless Improvement – Every part of the enterprise focuses on continuously
improving its solutions, products, and processes.
Each is described in the sections below.
Learning Organization
Learning organizations invest in and facilitate the ongoing growth of their employees. When
everyone in the organization is continuously learning, it fuels the enterprise’s ability to
dynamically transform itself as needed to anticipate and exploit opportunities that create a
competitive advantage. Learning organizations excel at creating, acquiring, and transferring
knowledge while modifying practices to integrate the new insights [1,2]. These organizations
understand and foster the intrinsic nature of people to learn and gain mastery, harnessing that
impulse for the benefit of the enterprise [3].
Learning organizations are distinguished from those using the scientific management
methods promoted by Frederick Taylor. In Taylor’s model, learning is limited to those at the
top while everyone else simply follows the policies and practices they create. Becoming a
learning organization is not an altruistic exercise. It’s an antidote to the status-quo thinking
that drove many former market leaders to bankruptcy. Learning drives innovation, leads to
greater sharing of information, enhances problem-solving, increases the sense of community,
and surfaces opportunities for more efficiency. [4]
The transformation into a learning organization requires five distinct disciplines, as described
by Senge. The best practices for developing these disciplines include:
Personal Mastery – Employees develop as ‘T-shaped people’. They build a breadth of

knowledge in multiple disciplines for efficient collaboration and deep expertise aligned with
their interests and skills. T-shaped employees are a critical foundation of Agile teams.
Shared Vision – Forward-looking leaders envision, align with, and articulate exciting
possibilities. Then, they invite others to share in and contribute to a common view of the
future. The vision is compelling and motivates employees to contribute to achieving it.
Team Learning – Teams work collectively to achieve common objectives by sharing

knowledge, suspending assumptions, and ‘thinking together’. They complement each other’s
skills for group problem solving and learning.
Mental Models – Teams surface their existing assumptions and generalizations while
working with an open mind to create new models based on a shared understanding of the
Lean-Agile way of working and their customer domains. These models make complex
concepts easy to understand and apply.
Systems Thinking – The organization sees the larger picture and recognizes that optimizing
individual components does not optimize the system. Instead, the business takes a holistic
approach to learning, problem-solving, and solution development. This optimization extends
to business practices such as Lean Portfolio Management (LPM), which ensures that the
enterprise is making investments in experimentation and learning to drive the system
forward.
Many of SAFe’s principles and practices directly support these efforts, as illustrated in
Figure 2.
Figure 2. SAFe includes principles and practices that support the learning organization.
Here are some of the ways SAFe promotes a learning organization:

 Lean-Agile leaders promote, support, and exhibit personal mastery.
 A shared vision is iteratively refined during each PI Planning period. This influences
Business Owners, the teams on each Agile Release Train (ART), and the entire
organization.
 Teams learn continuously through daily collaboration and problem solving, supported
by events such as team retrospectives and Inspect & Adapt.
 The Scaled Agile Framework provides a set of powerful guidelines for teams to use as
they apply Lean and Agile principles and practices.
 Systems Thinking is a cornerstone of Lean-Agile and one of the ten SAFe principles.
 SAFe also provides regular dedicated time and space for learning through the
Innovation and Planning (IP) iteration that occurs every Program Increment.
Innovation Culture
Innovation is one of the four pillars of the SAFe House of Lean. But the kind of innovation
needed to compete in the digital age cannot be infrequent or random. It requires
an innovation culture. An innovation culture exists when leaders create an environment that
supports creative thinking, curiosity, and challenging the status quo. When an organization
has an innovation culture, employees are encouraged and enabled to:
 Explore ideas for enhancements to existing products

 Experiment with ideas for new products
 Pursue fixes to chronic defects
 Create improvements to processes that reduce waste
 Remove impediments to productivity
Some organizations support innovation with paid time for exploring and experimenting,
intrapreneurship programs, and innovation labs. SAFe goes further by providing consistent
time each PI for all members of the Agile Release Train (ART) to pursue innovation
activities during the Innovation and Planning iteration. Innovation is also integral to Agile
Product Delivery and the Continuous Delivery Pipeline.
The following sections provide practical guidance for initiating and continuously improving
an innovation culture.
Innovative People
The foundation of an innovation culture is the recognition that systems and cultures don’t
innovate: people innovate. Instilling innovation as a core organizational capability requires a
commitment to cultivating the courage and aptitude for innovation and encouraging risk-
taking among employees. For existing organization members, this may necessitate coaching,
mentoring, and formal training in the skills and behaviors of entrepreneurship and
innovation. Individual goals and learning plans should include language that enables and
empowers growth as an innovator. Rewards and recognition that balance intrinsic and
extrinsic motivation reinforce the importance of everyone as an innovator. Criteria for hiring
new employees should include evaluating how candidates will fit in an innovation culture.
Opportunities and paths for advancement should be clear and available for people who
demonstrate exceptional talent and performance as innovation agents and champions [5].
Time and Space for Innovation
Building time and space for innovation includes providing work areas conducive to creative
activities, as well as setting aside dedicated time from routine work to explore and
experiment. Innovation space can also include:
 Broad cross-domain interactions involving customers, the supply chain, and even the
physical or professional communities connected to the organization
 Temporary and limited suspension of norms, policies, and systems (within legal,
ethical, and safety boundaries) to challenge existing assumptions and explore what’s
possible
 Systematic activities (IP iteration, hackathons, dojos, etc.) and opportunistic
innovation activities (continuous, accidental, unplanned)
 Perpetual innovation forums on collaboration platforms and Communities of Practice
(CoPs) that create the opportunity for ongoing conversations across the organization
Go See
Often, the best innovation ideas are sparked by seeing the problems to be solved first-hand—
witnessing how customers interact with products or the challenges they face using existing
processes and systems. Gemba is a Lean term and practice from Japan meaning ‘the real
place,’ as in where the customers’ work is actually performed. SAFe explicitly supports this
concept through Continuous Exploration. Making first-hand observations and hypotheses
visible channels the creative energy of the entire organization toward conceiving innovative
solutions. Leaders should also openly share their views on the opportunities and challenges
the organization faces to focus innovation efforts on the things that have the highest potential
to benefit the enterprise.
Experimentation and Feedback
Innovation cultures embrace the idea that conducting experiments designed to progress
iteratively towards a goal is the most effective path to learning that creates successful
breakthroughs. Regarding his many unsuccessful experiments to create an incandescent light
bulb, Thomas Edison famously said, “I have not failed. I’ve just found 10,000 ways that
won’t work.” In the scientific method, experiments don’t fail; they simply produce the data
needed to accept or reject a hypothesis. Many companies don’t innovate sufficiently due to a
culture that includes fear of failure. Such fear cripples innovation.
In contrast, innovation cultures depend on learning from experiments and incorporating those
insights into future exploration. When leaders create the psychological safety described in
the Lean-Agile leaders article, people are encouraged to experiment (within guardrails). They
feel permission to solve big problems, to seize opportunities, and to do so without fear of
blame, even when the results of the experiments suggest moving in a different direction.
Pivot Without Mercy or Guilt
Every innovation begins as a hypothesis – a set of assumptions and beliefs regarding how a
new or improved product will delight customers and help the organization achieve its
business objectives. However, hypotheses are just informed guesses until they are supported
by validated feedback from real customers. As Eric Ries promotes in The Startup Way, the
fastest way to accept or reject a product development hypothesis is to experiment by building
a Minimum Viable Product or MVP [6]. An MVP is the simplest thing that can possibly
work to test the proposed innovation to see if it leads to the desired results. MVPs must be
tested by customers in the target market or by intended users of the system for fast feedback.
In many cases, the feedback is positive and further investment to bring the innovation to
market or into production is warranted. In other instances, the feedback dictates a change in
direction. This could be as simple as a set of modifications to the product followed by
additional experiments for feedback, or it could prompt a ‘pivot’ to an entirely different
product or strategy. When the fact-based evidence indicates that a pivot is required, the shift
in direction should occur as quickly as possible without blame, and without consideration of
sunk costs in the initial experiments.
Innovation Riptides
To create an innovation culture, organizations have to go beyond catchy slogans, ‘innovation

teams,’ and popular techniques like hackathons and dojos. A fundamental rewiring of the
enterprise’s DNA is needed to fully leverage the innovation mindset and create the processes
and systems that promote sustained innovation. As shown in Figure 3, SAFe provides these
needed structures.
Figure 3. SAFe includes critical elements to support a consistent, continuous flow of innovation
The continuous flow of innovation is built on the foundation of SAFe principle #9 which
promotes decentralized decision-making. Some innovation starts as strategic portfolio
concerns that are realized through Epics and Lean Budgets applied to value streams. In the
course of building the solution to realize Epics, teams, suppliers, customers and
business leaders all identify opportunities for improving the solution. The potential
innovations that result can be considered an ‘innovation riptide’ that flows back into the
structures that SAFe provides for building solutions. Smaller, less expensive innovations
flow into the Program Kanban as Features while larger, more expensive innovations result in
the creation of an Epic and Lean Business Case and flow into the Portfolio Kanban.
Relentless Improvement
Since its inception in the Toyota Production System, kaizen, or the relentless pursuit of
perfection, has been one of the core tenets of Lean. It is illustrated in various ‘house of Lean’
models including the SAFe House of Lean.
While unattainable, the act of striving for perfection leads to continuous improvements to
products and services. In the process, companies have created more and better products for
less money and with happier customers, all leading to higher revenues and greater
profitability. Taiichi Ohno, the creator of Lean, emphasized that the only way to achieve
kaizen is for every employee at all times to have a mindset of continuous improvement. The
entire enterprise as a system—executives, product development, accounting, finance, and
sales—is continuously being challenged to improve [7].
But improvement requires learning. Rarely are the causes and solutions for problems that
organizations face clear and easily identified. The Lean model for continuous improvement
is based on a series of small iterative and incremental improvements and experiments that
enable the organization to learn its way to the most promising answer to a problem.
The sections that follow further illustrate how a continuous learning culture is a critical
component of relentless improvement.
Constant Sense of Danger
SAFe uses the term relentless improvement in its House of Lean to convey that improvement
activities are essential to the survival of an organization and should be given priority,
visibility, and resources. This closely aligns with another core tenet of Lean, which is an
intense focus on delivering value to customers by providing products and services that solve
their problems in a way that’s preferred over the organization’s competitors. SAFe promotes
both ongoing and planned improvement efforts through team retrospectives, the problem-
solving workshop during Inspect & Adapt (I&A), as well as the use of the Innovation &
Planning (IP) iteration to conduct improvement work. Improvement Features and Stories that
emerge from the I&A are also incorporated into team plans and integrated into the work
planned for the following Program Increment.
Optimize the Whole
“Optimize the whole” suggests that improvements should be designed to increase the
effectiveness of the entire system that produces the sustainable flow of value, as opposed to
optimizing individual teams, silos, or subsystems. Everyone at all levels should embrace
improvement thinking, but improvements in one area, team, or domain should not be made to
the detriment of the overall system. Organizing around value in ARTs, Solution Trains, and
value streams create opportunities for people in all domains to have regular and holistic
conversations about how to enhance overall quality, the flow of value, and customer
satisfaction.
Problem Solving Culture
In Lean, problem-solving is the driver for continuous improvement. It recognizes that a gap
exists between the current state and the desired state, requiring an iterative process to achieve
the target state. The steps of problem-solving are both fractal and scalable. They apply to
teams trying to optimize response time in a software system and to enterprises trying to
reverse a steady decline in market share. Iterative Plan-Do-Check-Adjust (PDCA) cycles, as
shown in Figure 4, provide the process for iterative problem solving on small adjustments as
well as breakthrough innovations. The entire process is repeated until the target state is
achieved. This model treats problems as opportunities for improvement in a blameless
process, and employees at all levels are empowered and equipped with the time and
resources to identify and solve problems. As part of the ART and Solution Train Inspect &
Adapt events, SAFe builds problem-solving into Agile team retrospectives, and into the
problem-solving workshop.
Figure 4. The PDCA problem-solving cycle scales from individual teams to entire organizations
Reflect at Key Milestones
Improvement activities are often deferred in favor of ‘more urgent’ work such as new feature
development, fixing defects, and responding to the latest outage. Relentless improvement
requires a disciplined structure to avoid neglecting this critical activity. For individual teams,
SAFe encourages retrospectives at iteration boundaries at a minimum and in real-time when
possible. ARTs and Solution Trains reflect every Program Increment as part of the Inspect &
Adapt event. This cadence based milestone provides predictability, consistency, and rigor to
the process of relentless improvement in large product development efforts.
Fact-based Improvement
Fact-based improvement leads to changes guided by the data surrounding the problem and
informed solutions, not by opinions and conjecture. Improvement results are objectively
measured, focusing on empirical evidence. This helps an organization concentrate more on
the work needed to solve problems and less on assigning blame.
Measure and Grow

The Measure and Grow article describes how enterprises can assess where they are on their
journey to Business Agility and provides a downloadable self-assessment for that purpose.
That assessment is a high-level view that measures the seven competencies and briefly
touches on each dimension of Business Agility.
In order to provide further insights, each competency has an individual assessment that can
be used to provide additional specificity as to prowess in that competency and implications
as to how to improve. The specific, more detailed assessment for Continuous Learning
Culture can be downloaded below.
Download Continuous Learning Culture Assessment
Summary
Too often, organizations fall into the trap of assuming that the culture, processes, and
products that led to today’s success will also guarantee future results. That mindset increases
the risk of decline and failure. As Albert Einstein said (paraphrased), “we can’t solve
problems by using the same kind of thinking we used when we created them.” The
enterprises that will dominate their respective markets going forward will be those that are
adaptive learning organizations with the ability to learn, innovate, and relentlessly improve
more effectively than their competition.
Learn More
[1] Garvin, David A. Building a Learning Organization. Harvard Business Review, July-
August 1993. https://hbr.org/1993/07/building-a-learning-organization
[2] Senge, Peter. The Fifth Discipline: The Art and Practice of the Learning
Organization. Penguin Random House LLC. Kindle Edition.
[3] Pink, Daniel H. Drive: The Surprising Truth About What Motivates Us.Penguin Group.
Kindle Edition.
[4] Marquardt, Michael. Building the Learning Organization. Nicholas Brealey Publishing.
Kindle Edition.
[5] Beswick, Cris; Bishop, Derek; & Geraghty, Jo. Building a Culture of
Innovation. KoganPage Publishing. Kindle Edition.
[6] Ries, Eric. The Startup Way. Currency. Kindle Edition.
[7] Liker, Jeffery K. Developing Lean Leaders at All Levels. Lean Leadership Institute
Publications. Kindle Edition.
permissions.
Accelerate
Excellent firms don’t believe in excellence—only in constant improvement and constant
change.
—Tom Peters
This is article 12, the final article in the SAFe®Implementation Roadmap

series. Click here to view the entire roadmap.
The previous articles in the SAFe Implementation Roadmap series described the first 11
steps:

 Identify Value Streams and Agile Release Trains (ARTs)
 Create the Implementation Plan
 Prepare for ART Launch
 Train Teams and Launch the ART
 Coach ART Execution
 Launch More ARTs and Value Streams
 Extend to the Portfolio
Organizations that have followed the steps above are to be congratulated! No doubt
substantial progress has been made on this portion of the Lean-Agile transformation journey.
A sufficiently powerful coalition of change agents is in place. The majority of stakeholders
are trained. The portfolio has been transformed into value streams supported by Agile release
trains continuously delivering value. The new way of working is becoming the norm all the
way from individual teams to those responsible for managing portfolio concerns. Most
importantly, substantial business benefits are accumulating every day as evidenced by
outcome-centric portfolio KPIs. Improvements in quality, productivity, time-to-market, and
employee engagement are meeting or exceeding expectations, and the first results
of Business Agility are becoming apparent. The temptation for many enterprises who have
made it to this point is to fall into the trap of thinking that the work of transformation and
SAFe adoption is done, since most of the steps in the implementation roadmap have been
followed.
However, this is not the end of the journey. It’s just the start of a new beginning! Now the
aim is to accelerate the enterprise towards business agility!
To reinforce and accelerate the SAFe transformation, leaders must now expand their view of
the implementation. They will need to maintain the energy and enthusiasm they are devoting
to the short cycles of Iterations and Program Increments (PIs) while setting their sights on the
larger goals of true business agility. Across all seven competencies of the Lean Enterprise,
improvements must progress to an advanced state until the culture of the organization
transforms.
This final article in the SAFe Implementation Roadmap series suggests some key activities
that build on the previous steps in the roadmap and can accelerate the organization to
business agility.
Details
Getting to this last step of the Implementation Roadmap is the beginning of another journey,
one based on the foundation of relentless improvement. By now, the emerging Lean
Enterprise will have started to build a new operating model and culture, one in which the
principles and practices of Lean and Agile are beginning to be the norm. While most
competencies have started to take root in the previous steps in the roadmap, others,
like Organizational Agility and a Continuous Learning Culture are likely to be at the early
stages in this step.
Building on the benefits gained allows the enterprise to accelerate its journey towards
business agility. It requires dedication to basic and advanced practices, self-reflection, and
retrospection. Here are some activities the enterprise can use to ensure relentless
improvement:
 Measure the performance of the portfolio

 Reinforce the basics
 Progress toward mastery
 Anchor new behaviors in the culture
 Apply learnings across the enterprise
Each of these is described in the sections below.
Measure the Performance of the Portfolio

One of the most important steps to accelerate progress toward business agility is to assess
how far the portfolio has come, leverage its strengths, and to focus improvement efforts on
any areas of weakness. If the organization followed the guidance in Measure and Grow to
conduct baseline business agility assessments at the start of the SAFe implementation, then a
re-assessment using the same 21 dimensions of business agility can quickly shine the
spotlight on the most critical areas of focus for relentless improvement activities.
As an example, the assessment in Figure 1 shows that the portfolio has reached a high degree
of mastery in some dimensions like Agile Teams, while others, such as the three dimensions
of Lean Portfolio Management, remain not started.
Figure 1. Example Business Agility assessment showing low LPM proficiency
Achieving business agility requires similar proficiency across all seven competencies and 21
dimensions. These results provide a clear visible indicator that the organization should revisit
the ‘extend to portfolio’ step of the implementation roadmap, understand the gaps, and build
a tangible action plan to increase proficiency in that area. One obvious action that could be
taken in the Figure 1 scenario (if it hasn’t been done already) would be for the portfolio
participants to attend the SAFe Lean Portfolio Management course, followed immediately
with a facilitated session to build a plan for launching (or re-launching) Lean Portfolio
Management.
The questions in the Business Agility assessment download (see Measure and Grow) also
imply the recommended actions to take for advancing in each of the 21 dimensions of
business agility. Organizations with low scores in any dimension should look closely at the
corresponding questions for that dimension and work to implement what the questions
suggest. For example, if the question “Leaders use the Implementation Roadmap to guide the
adoption of SAFe” is answered with ‘disagree’ or ‘strongly disagree’ then the recommended
action would be to review and retrain the leadership team on the steps in Implementation
Roadmap, and adjust the rollout plan to follow the recommended steps more closely. Note
that the success pattern is to fill any low scoring gaps (as illustrated by the LPM dimensions
in Figure 1 for example) and ensure the portfolio is making similar progress across all
competencies over just focusing on mastery in one dimension.
Reinforce the Basics

In virtually every team sport, when teams start to falter during a season, coaches will refocus
their players on the basic fundamentals of their positions as the first step to getting back on
the path to winning. The same is often true for organizations adopting SAFe. At the
beginning of the transformation journey, great focus was placed on the basics of Lean-
Agile and SAFe principles, Team and Technical Agility, and Agile Product Delivery.
Everyone was trained, and much of the initial emphasis was on learning the basics of SAFe.
As more trains are launched and the organization’s attention moves to new challenges, steps
in the implementation roadmap may be skipped along the way. Practices that were closely
followed in the beginning may have been altered or discontinued. Whether it’s due to lack of
understanding, a desire to shortcut the path to agility, or the natural ebb and flow of a large
company, the end result is that one (or several) of the ten critical ART success factors of
SAFe described in the Essential SAFe article are not being followed. Experience from
thousands of SAFe implementations has shown that skipping any of these ten factors will
inevitably lead to the inability of the portfolio to achieve optimal results from implementing
SAFe to achieve business agility.
Figure 2. The 10 critical success factors of Essential SAFe
SAFe Program Consultants (SPCs) can use the Essential SAFe Toolkit to guide a self-
assessment by the organization of these ten critical success factors. The toolkit uses common
anti-patterns that emerge when one or more critical practices are not being followed, and
helps focus relentless improvement efforts on the basic elements that need to be revisited and
potentially retrained.
Progress Towards Mastery

Once the recommendations of the SAFe business agility assessment have been followed and
the critical success factors are consistently practiced by every ART, the portfolio should see
significant improvement in all competencies and dimensions. By this time, value is being
delivered frequently, customers and business owners are happy, and everyone in the portfolio
is energized. At this stage the question may become “now what?” While the positive
improvements to the culture and the better business results should be celebrated, there’s
more work to do. It’s time to take the next steps toward mastery, to maximize the
performance in every dimension, and permanently engrain the new way of working into the
culture of the organization.
The following is a list of ‘pro tips’ and advanced concepts in each of the seven competencies
that will help enterprises realize the greatest benefits of SAFe and optimize the environment
for business agility.
Team and Technical Agility
 Double down on the principles that drive Agile Teams and Agile Release Trains.
 Train all teams in built-in practices, with development teams getting trained in Agile
Software Engineering
 Ensure all teams apply and improve built-in quality practices
Agile Product Delivery
 Focus on Customer Centricity and Design Thinking to help drive better solutions.
 Train Product Management in Agile Product and Solutions Management to better
understand the practices and apply the tools
 Map the delivery pipeline to identify the delays to flow, guide investments in
automation, and achieve the goal of release on demand.
Enterprise Solution Delivery
 Ensure specification and roadmaps build and validate the solution and its Continuous
Delivery Pipeline together
 Include continuous delivery concerns and the cost of delayed value in system
architecture decisions
 Measure and improve ‘continuish’ integration practices across the entire supply chain
Lean Portfolio Management
 Apply participatory budgeting

 Eliminate projects and timesheets
 Master Lean Startup practices
 Make an explicit Enterprise Architecture roadmap
 Evolve the focus from developing individual Lean-Agile leaders to building high-
performing leadership teams
 Form Communities of Practice specifically for leaders interested in connecting with
peers who are also developing as Lean-Agile leaders
 Contact Scaled Agile for information on becoming an early adopter of new Lean-
Agile Leadership programs (under development)
Organizational Agility
 Reinforce the principles with book club readings

 Share best practices and learnings from optimizing value streams
 Incorporate Gemba in everyone’s work activities
 Share strategy agility success stories
 Develop and visualize both quantitative and qualitative metrics to assess the tangible
results of relentless improvement
 Expand Gemba visits to customers, partner organizations, and enterprises in unrelated
markets to gain new insights that can spark fresh innovation initiatives
 Invest in advanced digital systems for knowledge sharing, collaboration, and rapid
access to accurate information
Anchor New Behaviors in the Culture

The work to implement SAFe and achieve mastery of the seven competencies will inevitably
shift the culture of the organization. Anchoring this shift so that it becomes permanent is
critical to ensuring the organization keeps progressing and doesn’t slip back into old patterns
of behavior. As portfolios advance toward higher degrees of mastery there will be a natural
tendency to assume that the new way of working is understood and to shift the focus of the
organization to ‘the next big thing.’ The reality is that until all of the new principles and
practices have permeated the entire portfolio and have simply become the default way work
gets done, there will be an ongoing risk that all of the organization’s hard-fought gains will
be lost, and the portfolio will revert back to legacy mindsets and practices. This can be
caused by changes in leadership, new threats in the market that create a crisis response
environment, or by the organization simply not having enough time exercising all of the new
habits to the point that they transform the culture.
How can this pitfall be avoided?
Once again the wisdom of W. Edwards Deming points the way. “Transformation is not
automatic. It must be learned; it must be led.” Leaders must do more than ‘change the
system.’ Leaders must also understand the principles and practices of change leadership and
organizational change management. This means leaders must be curators, caretakers, and
defenders of the new way of working. When the heat is on and the pressure to revert back to
old habits escalates, everyone will look to leaders from the top of the organization down to
see how they respond. Have the leaders transformed how they think? How they act? How
they make decisions? How they get things done in moments of crisis? When leaders
demonstrate that true change has occurred, and going backward is not an option no matter the
circumstances, the changes become galvanized into the organization’s DNA, and the new
way of working is likely to withstand similar challenges in the future.
Apply Learnings Across the Enterprise

It is common for the world’s largest organizations to have many portfolios. Success in one
portfolio does not ensure success in other portfolios. As the initial portfolio adopting SAFe
makes headway on its progress towards business agility, the final stage of Accelerate is to
leverage the learnings and successes of the pioneering organization to transform the
remaining portfolios. The recommended pattern is to provide change agents from the initial
portfolio with the opportunity to transplant into subsequent portfolios, bringing with them all
of the experience and insights of implementing SAFe. To keep this pattern from crippling the
first portfolio, organizations should aggressively invest in cultivating the next generation of
leaders in every role so they are prepared to step in when their counterparts move on to
launch the transformation in other portfolios. Planned well, these transitions can be smooth
and can also create great opportunity and upward mobility for these leaders.
Learn More
[1] Perez, Carlota. Project to Product: Technological Revolutions and Financial Capital:
The Dynamics of Bubbles and Golden Ages [2] Kersten, Mik. Project to Product. IT
Revolution Press. Kindle Edition.
Last updated: 28 September 2019

permissions.
Response Summary
Question
Which core competency of the Lean Enterprise addresses the Enterprise Solution Delivery
integration across Agile Release Trains (ARTs)?
Question
What is a key business benefit of SAFe? To adapt quickly to changing technologies and economic condi
Question
Which core competency of the Lean Enterprise focuses on Team and Technical Agility
building quality in?
Question
What is Business Agility? A customer-centric approach to defining, building, and releasin

users.
Question
A leader that admits his own mistakes exhibits which SAFe Transparency
Core Value?
Question
Response Summary
The House of Lean is a classic metaphor describing the Innovation

mindset essential for Lean thinking. Which one of the four
pillars advocates a 'Go See' mindset?
Question
Which statement fits with the SAFe Core Value of Built-in You cannot scale crappy code
Quality?
Question
Flow is one of the four pillars of the SAFe House of Lean. Respect for people and culture;Relentless improvement;Innova
What are the three other pillars? (Choose three.)
Question
When basing decisions on economics, how are lead time, To identify different parameters of the economic framework
product cost, value, and development expense used?
Question
Which is an aspect of systems thinking? Optimizing a component does not optimize the system
Question
If small batches go through the system faster with lower Large batches can cause projects to miss targets
variability, then which statement is true about batch size?
Question
Response Summary
What is an example of applying cadence-based Teams align their Iterations to the same schedule to support com
synchronization in SAFe?
Question
According to SAFe Lean-Agile Principle #10, what should Reorganize the network around the new value flow
the Enterprise do when markets and Customers demand
change?
Question
Who facilitates team-level events? The Scrum Master
Question
Who is the content authority for an Agile Release Train Product Management
(ART)?
Question
Design Thinking identifies at least four new ways to measure Marketability;Desirability;

success. What are two of those ways? (Choose two.)
Question
The benefit hypothesis justifies the Feature implementation It provides business perspective when making scope decisions
cost, and what else?
Question
During Program Increment (PI) Planning, what is the To highlight challenges that management must address in the m
primary objective of the draft plan review?
Response Summary
Question
What is the final activity on day one of Program Increment Management review and problem-solving
(PI) Planning?
Question
In Program Increment (PI) Planning, the final plan review is Teams and Business Owners
done by who?
Question
During Program Increment (PI) Planning, which statement is At team breakout #2, teams work to create their final plans
true about the activities of team breakouts?
Question
What are three essential program events that keep the Agile Inspect and Adapt (I&A) event;System Demo;Program Increme
Release Train (ART) on the tracks? (Choose three.)
Question
An Innovation and Planning (IP) Iteration allows time for For continuing education;For innovation;
which two activities? (Choose two.)
Question
What are two benefits of funding Value Streams rather than To eliminate the delays of project approvals and funding;To eli
projects? (Choose two.) progress;
Question
Response Summary
Which two SAFe Program Consultant (SPC) resources are The Introducing SAFe workshop;The SAFe Executive Worksh
intended to aid in arriving at the SAFe tipping point?
(Choose two.)
Question
What are two aspects of leading by example? (Choose two.) Psychological safety;Transparency;
Question
According to John Kotter, what is the first step to successful Establishing a sense of urgency
change?
Question
A compelling Vision for change achieves which two It clarifies the purpose and direction of the change;It motivates
objectives? (Choose two.)
Question
What is one key reason an organization starts a SAFe A 'burning platform'; there is an obvious need to change a prod
transformation?
Question
A sufficiently powerful guiding coalition consists of which Trained Lean-Agile leaders;Executives with high credibility;Ch
three elements? (Choose three.)
Question
What are two responsibilities of a Lean-Agile Center of To help establish relentless improvement;To foster SAFe comm
Excellence (LACE)? (Choose two.)
Response Summary
Question
What are three benefits of organizing around Value Streams? Optimize the system as a whole;Built-in alignment between the
(Choose three.)
Question
What are two types of Value Streams? (Choose two.) Development;Operational;
Question
What is the SAFe-recommended size of an effective Agile 50–125 people

Release Train (ART)?
Question
Why might an organization choose to create a platform Agile To accelerate value delivery
Release Train (ART)?
Question
What is one benefit of an invitation-based implementation It centralizes the decision to launch Agile Release Train (ARTs
approach to SAFe?
Question
Which statement is true about multiple Agile Release Train ART rollouts should be incremental; one ART should start whe
(ART) rollouts?
Question
There are multiple Agile Release Trains (ART) identified Leadership support, collaborating teams, clear products or Solu
Response Summary
from the Value Stream and ART Identification Workshop.

The ideal ART to launch first is found at the intersection of
which converging factors?
Question
What is the benefit of timeboxing the preparation for the first To minimize the expansion of work during preparation
Program Increment (PI) Planning event?
Question
The design of an Agile Release Train (ART) should remove Silos that inhibit flow
what?
Question
What are three things an Agile Release Train (ART) needs The portfolio canvas;Program roster;Facilities;
for its launch readiness? (Choose three.)
Question
What are the elements of the Agile Release Train (ART) SAFe for Teams training, Program Increment (PI) Planning, wo
quickstart approach?
Question
When are the teams formed for the Agile Release Train Before the ART is launched but can be changed or adjusted if n
(ART)?
Question
What are two benefits of 'big room training'? (Choose two.) Accelerated learning;Overall cost efficiency;
Response Summary
Question
Why is Program Increment (PI) Planning itself considered a It creates a clear commitment to goals
short-term win?
Question
Why is the first Program Increment (PI) the most crucial to There is no Lean-Agile Center of Excellence (LACE) at this sta
facilitate?
Question
Why does a SAFe Program Consultant (SPC) provide To build the organization's Lean-Agile capabilities
ongoing program consulting and team coaching?
Question
Why is it important the SAFe Program Consultant (SPC) To give the Agile Release Train (ART) the tools it needs to imp
supports the Release Train Engineer (RTE) in the first
problem-solving workshop?
Question
A new Agile Release Train (ART) is formed and Lee is the Attend the Iteration Retrospectives as this will give her the mos
new coach. All members of the train are new to Agile. After
three Iterations Lee is hearing that many of the teams are
having problems running their team events. What can she do
to assist the teams?
Question
What are three parts to the Inspect and Adapt (I&A) event? Program Increment (PI) System Demo;Problem-solving worksh
(Choose three.)
Response Summary
Question
What is an example of traditional mindset for Lean Portfolio Centralized annual planning
Management?
Question
When calculating and assessing team Program Increment It includes uncommitted objectives
(PI) performance for the PI predictability measure, which
statement is true about the actual total?
Question
A problem-solving workshop focuses the Agile Release To identify the root causes of the problems
Train (ART) to take what action?
Question
When is the right time to create the role of the Solution Train When a large Value Stream has enough Agile Release Trains (A
Engineer (STE)?
Question
When should a Lean portfolio be established? When the lack of communication between strategy and executio
Question
What are two benefits of communities of practice? (Choose They provide access to expertise;They enable visibility into the
two.)
Question
Response Summary
How can Essential SAFe be used to evaluate a Full SAFe Verify that the Full SAFe implementation performs the elemen
implementation?
Question
Which SAFe core competency includes fostering an Continuous Learning Culture

innovative culture?
Question
Which statement is true about the accelerate step of the Remaining portfolios can leverage the learnings and successes
SAFe Implementation Roadmap?
Question
What is the last step in Kotter's eight step model to Anchor new approaches in the culture
implementing successful change?

Business Agility

Uploaded by

Document Information

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

Business Agility

Uploaded by

Copyright:

Available Formats

Business Agility

—Mik Kersten, Project to Product

Business Agility requires that everyone involved in delivering solutions—business and

Competing in the Age of Software

 Installation Period – New technology and financial capital combine to create a

How We Got Here

As an organizational researcher and author John Kotter illustrates in his recent

So how do we create such a dual operating system?

SAFe 5.0 – Your Operating System for Business Agility

Team and Technical Agility

 Agile Teams – High-performing, cross-functional teams anchor the competency by

Agile Product Delivery

There are three dimensions to Agile Product Delivery, as illustrated in Figure 9.

Enterprise Solution Delivery

The Enterprise Solution Delivery competency describes how to apply Lean-Agile principles

Lean System and Solution Engineering applies Lean-Agile practices to align and

Agile Portfolio Operations coordinates and supports decentralized program execution,

Lean Governance manages spending, audit and compliance, forecasting expenses, and

The three dimensions are:

Relentless Improvement – Every part of the enterprise focuses on continuously improving

Leading Change – Leaders lead (rather than support) the transformation by creating the

Measure and Grow

—W. Edwards Deming

Figure 2. Five primary dimensions of Built-In Quality

In addition, this article is augmented by three Advanced Topic articles, Agile

 Executives, Lean Portfolio Management, and other stakeholders can see the Portfolio

Last update: 18 September 2019

Thinking Lean with the SAFe House of Lean

Pillar 1 – Respect for People and Culture

When there’s an urgency for positive change, transforming culture is possible. First,

Lean-Agile principles provide a better understanding of the system development process by

 Hire, coach, and mentor innovation and entrepreneurship in the organization’s

Pillar 4 – Relentless Improvement

Additional guidance on leadership as the foundation of Lean-Agile transformation using

Embracing Agility with the Agile Manifesto

The Values of the Agile Manifesto

The Manifesto consists of the value statement shown in Figure 3:

Where We Find 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

Agile Manifesto Principles

Applying the Agile Manifesto at Scale

Last update: 3 February 2020

SAFe Lean-Agile Principles

Figure 1. SAFe Lean-Agile Principles

#1 – Take an economic view

#3 – Assume variability; preserve options

#4 – Build incrementally with fast, integrated learning cycles

#5 – Base milestones on objective evaluation of working systems

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

#8 – Unlock the intrinsic motivation of knowledge workers

#10 – Organize around value

Customer-centric businesses generate greater profits, increased employee engagement, and

 Focus on the customer – Customer-centric enterprises use segmentation to align and

Research activities occur continuously and are directly supported through Continuous

Design with Empathy

Degrees of Customer Engagement

 General solution – intended to be used by a significant number of customers

Figure 2. Customer engagement models in general and custom-built solutions

Deep and Narrow Solutions

Whole Product Thinking

 The generic product is often considered the “minimal offering” of a product. For a