Essential SAFe. The essential scaling patterns that we can (probably) all agree on

1© 2017 Scaled Agile, Inc. All Rights Reserved.V4.0.0 V4.0.0© 2017 Scaled Agile, Inc. All Rights Reserved.
Essential SAFe®
4.0 Overview
Ten Essential Scaling Patterns We Can (Probably) All Agree on
Richard Knaster
SAFe Fellow,
Principal SAFe Contributor

2© 2017 Scaled Agile, Inc. All Rights Reserved.
About today’s speaker
SAFe Fellow, Principal Consultant and
author:
– SAFe White paper (author)
– SAFe Distilled (Lead co-author)
– SAFe Reference Guide (co-author)
Over 25 years of industry experience in
software and systems development in roles.
Formerly IBM Chief Agile Methodologist; held
various roles as CIO, CTO, Director of
Development and various practitioner roles

Why focus on the essentials?
Successful rollout, but still struggling.
Root causes:
Not doing Inspect and Adapt
No Innovation and Planning
iteration
Individual Agile teams were not
actually cross-functional
No routine system demo
“SAFe is a flexible framework. We’ve
adopted what we liked, but we don’t
use Agile Release Trains.”
“SAFe is flexible. We’re adopting it, but
we’ve decided not to affect the way
the teams are working. So we didn’t
include the teams in training.”
“Our leaders don’t have time for
training.”
Findings from the field Heard in the field
Because there’s a danger in skipping critical elements

The Essential SAFe Little Big Picture

10 essential elements
Lean-Agile Principles
Agile Teams and Release Trains
Cadence and synchronization
Critical team and program roles
PI Planning
System Demo
Inspect and Adapt
IP iteration
Architectural runway
Lean-Agile leadership
1
2
3
4
5
6
7
8
9
10

Lean-Agile Principles
#1-Take an economic view
#2-Apply systems thinking
#3-Assume variability; preserve options
#4-Build incrementally with fast, integrated learning cycles
#5-Base milestones on objective evaluation of working systems
#6-Visualize and limit WIP, reduce batch sizes, and manage queue lengths
#7-Apply cadence, synchronize with cross-domain planning
#8-Unlock the intrinsic motivation of knowledge workers
#9-Decentralize decision-making
1

Without a shared understanding of principles ...
There is no systematic way to adapt practices to local context
Business outcomes do not significantly improve
Practices and measures that were once beneficial become problematic
Lean-Agile mindset is unachievable; Agile practices deployed on a wrong-
minded “mental platform” produce serious challenges
Conflict and disagreement on processes and practices are impossible
to resolve

Agile Teams and Agile Release Trains
Agile Teams power the train:
Cross-functional teams apply Scrum,
XP and Kanban and built-in quality
practices to produce working system
increments every iteration.
Agile Release Trains (ARTs) are cross functional teams of Agile Teams and other
stakeholders that deliver solutions. They have all the people they need to define and
deliver value every two weeks.
2

Without Agile Teams and ARTs ...
Teams don’t work towards a common mission
Teams locally optimize and can’t deliver end-to-end value
Dependencies rule the day
Individuals are over-specialized; bottlenecks inhibit flow and release of value
There is no architectural and user experience integrity

Cadence and Synchronization
 Transforms unpredictable events into
predictable events
 Makes wait times predictable
 Facilitates planning; provides more
efficient use of resources
 Synchronization causes multiple
events to happen at the same time
 Sync events facilitate cross-functional
tradeoffs of people and scope
3

Without cadence and synchronization ...
No development rhythm
Constantly fight entropy and misalignment
Impossible to schedule planning, retros, demos and key events
Hard to adjust to changing priorities
Impossible to limit Work in Process (WIP), constantly overloaded

Critical Team roles
Scrum Master facilitates team events, drives Agile behavior,
and coaches the team.
Product Owner acts as the customer for team and prioritizes
their work. Defines and accepts requirements.
Development Team is everyone needed to define, build,
and test an increment of value.
4

Critical Program roles
Release Train Engineer acts as the chief Scrum Master for the train.
Business Owners are a small group of stakeholders who have the ultimate
fiduciary, governance, efficacy, and ROI responsibility for ART value.
Product Management is responsible for Customer needs. Owns the
vision and product backlog, prioritizes features for optimum economics.
System Architect/Engineering align ARTs to a common technological
and architectural vision.
Customer consumes the work of an ART. The ultimate arbiters of value.
4

Without these critical roles ...
Responsibilities for most everything is unclear.
Decision-making is fractured, late, uncertain
Deliverables do not meet stakeholder expectations
Solution features and components evolve incompatibly
Vision and requirements are not clear; hard to prioritize
Virtually impossible to improve

PI Planning
 Important stakeholder decisions
are accelerated
 Teams create—and take
responsibility for—plans
 Result: Alignment!
 All stakeholders face-to-face (but
typically multiple locations)
 Management sets the mission,
minimum possible constraints
 Requirements and design emerge
“Future product development tasks can’t be pre-determined. Distribute planning
and control to those who can understand and react to the end results.”
— Michael Kennedy, Product Development for the Lean Enterprise
For a See the short video PI planning example https://www.youtube.com/watch?v=ZZAtl7nAB1M
5

Without PI Planning ...
Stakeholders, teams, and management are misaligned
Demand doesn't match capacity; no predictability; excess WIP
Lack of trust between stakeholders and teams
Dependencies are discovered by “running into them”
Low commitment, low ownership, low enthusiasm

System Demo
Demonstrate the full Solution increment to stakeholders every Iteration.
An integrated Solution demo
Happens after the team’s demo (but may lag
by as much as one Iteration, maximum)
Demo from the staging environment, or the
nearest proxy
6

Producing a System Demo requires Built-in Quality
Building quality in:
Ensures that every increment of the solution reflects quality standards
Is required for high, sustainable development velocity
Software quality practices include continuous integration, test-first,
refactoring, pair-work, collective ownership and more
Hardware quality is supported by exploratory, early iterations, frequent
system level integration, design verification, MBSE and set-based
design
“You can’t scale crappy code” (or hardware, or anything else)
Built-in
Quality

Without the System Demo ...
PIs are “waterfalled”; problems and risks discovered too late
Teams are sprinting, but the system is not
Chronic lack of trust between stakeholders and teams
No feedback to the right solution
False progress, poor quality

Inspect & Adapt
Inspect & Adapt provides a venue for comprehensive review of the PI
outcomes and systematic improvements.
Three parts:
1. The PI System Demo
2. Quantitative
measurement
3. The problem-solving
workshop
7

Without Inspect & Adapt ...
No systemic improvement; problems persist
No means to measure or establish delivery predictability
Improvement attempts address symptoms, not root causes
Those who could change the system are not engaged
Morale deteriorates

IP Iteration
The IP Iteration is extra fuel in the tank. Without it the train will start sputtering under the
pressure of a plan that forgives no mistakes, nor provides time for innovation.
8

Without the IP Iteration ...
Lack of delivery capacity buffer impacts predictability
Little innovation, tyranny of the urgent
Technical debt grows uncontrollably
People burn out
No time for teams to plan together, demo together, and improve together

The Architectural Runway
Architectural runway provides “just enough” technical enablement to keep
program velocities high and avoid excessive redesign.
… to support
future features
Implemented now …
Feature
Feature
Feature
Enabler
9

Without Architectural Runway ...
Architecture deteriorates quickly under the pressure of ”now”
Velocity peaks for a while, then falls off
Releases are late and spasmodic; quality varies dramatically
Solution robustness, maintainability, and quality decay rapidly
Development pace is unsustainable

Lean-Agile Leadership
Successful transformations are based on educating leadership first.
“Lean-thinking manager-teachers” lead, rather than follow, the
transformation.
“It is not enough that management commit
themselves to quality and productivity …
They must know what it is they must do.
Such a responsibility cannot be delegated.”
—W. Edwards Deming
10

Without Lean-Agile Leadership ...
The teams learn from others, not their leaders
The transformation is fatally impaired
“Agile” development with non-Agile governance; “Agile in name only.
They don’t get it.”
Lead time is slow while decisions are escalated
People not allowed to experiment, fail, innovate, and learn

Without Lean-Agile Leadership ...
SAFe will not work!

© 2016 Scaled Agile, Inc. All Rights Reserved.
© 2017 Scaled Agile, Inc. All Rights Reserved. 29
Exercise: Create your own SAFe Essentials assessment
Fill out the assessment on the next page.
Start with 5 points per category. Subtract one point for every symptom you
checked on that category. Shade in the result.
Be prepared to share your results, if you have courage!
10
min

Create your own SAFe Essentials assessment here

Essential SAFe. The essential scaling patterns that we can (probably) all agree on

More Related Content

What's hot (18)

Similar to Essential SAFe. The essential scaling patterns that we can (probably) all agree on (20)

Recently uploaded (20)

Essential SAFe. The essential scaling patterns that we can (probably) all agree on