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 KnasterSAFe 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

Available March 31st


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

https://www.youtube.com/watch?v=ZZAtl7nAB1M

https://www.youtube.com/watch?v=ZZAtl7nAB1M


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

measurement3. 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 …

FeatureFeature

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!

10min


Create your own SAFe Essentials assessment here

essential safe. the essential scaling patterns that we can (probably) all agree on

Technology