Meetup#2 SAFe Patrick & Maxence

SAFe – Scaled Agile Framework
groupe-sii.com | October 2018 | Confidential
Patrick Pouchot
Agile Project Manager SII
ppouchot@sii.fr
Maxence VAN HOVE
Schneider Digital Service Platform Manager
maxence.vanhove@se.com

Agenda
Part 4 – Program level
Part 1 – Quizz
Part2 – SAFe Introduction
Part3 – Team level (//Scrum)
Part 8 – So Safe agile or not + Q & A
Part 5 – Alternate Scaled agile models
Part 6 – Solution of the Quizz
Part 7 – Schneider Electric testimony

groupe-sii.com | January 2018
Figures
5-12
2 W
(6)8 – 12 W
50 – 125

Agenda
Part 1 – Quizz

1.7
© Scaled Agile, Inc.
Dean Leffingwell
Creator of SAFe
“Every business is a software business now.
Agility isn't an option, or a thing just for teams, it is a
business imperative. But we struggle building big
systems … “

Nothing beats an Agile Team…
Cross-functional, self-organized —
deliver Value every 2 weeks
Applied Agile Software Engineering
practices with XP, Scrum,
and Kanban

…Except a team of Agile Teams
2/ Program
1/ Project/team
3/ Portfolio
Align 50 - 125 practitioners to a
common mission
Apply cadence and synchronization,
Program Increments every 6 - 12
weeks
Provide Vision, Roadmap,
architectural guidance

Embrace Lean-Agiles Values
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
That is, while there is value in the items on
the right, we value the items on the left
more.
We are uncovering better ways of developing software
by doing it and helping others do it. Through this work
we have come to value:
House of Lean
Value in the shortest
sustainable lead time

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

Scaled Agile Framework

Full SAFe (with large solutions level)
The Full SaFe configuration is the most
comprehensive version of the
Framework.
Its supports enterprises that build and
maintain large integrated solutions,
witch require hundreds of people or
more
In the largest enterprises, multiple
instances of various SaFe
configurations may be required

Stat with Essential SAFe

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

Critical ART roles
Release Train Engineer acts as the chief Scrum Master for the train
Product Management is responsible for customer needs. Owns the
vision and product backlog, prioritizes features for the best economic
outcome
System Architect/Engineering provides architectural guidance and technical
enablement to the teams on the train.
System Team provides processes and tools to help integrate and evaluate
assets early and often.
Business Owners are a small group of stakeholders who have financial,
governance, fitness for purpose and ROI responsibility

Synchronizing with PI planning
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
All stakeholders face-to-face (but typically multiple locations)
Management sets the mission, with minimum possible constraints
Requirements and design emerge
Important stakeholder decisions are accelerated
Teams create—and take responsibility for—plans
For a short video PI planning example, see: https://youtu.be/ZZAtl7nAB1M

Demonstrating the full system every two weeks
Full system
System
Team
An integrated solution demo – new
features work together and with existing
functionality
Objective milestone
Demo from the staging environment, or
the nearest proxy

Scaled planning

Agenda
Part 1 – Quizz

SAFe TEAM events
Iteration Planning (Iteration = Sprint in scrum)
Daily Stand-Up
Backlog Refinement
Iteration Review
Iteration Retrospective

Sprint Planning
Purpose: Identify, refine, and commit to stories for the Iteration
• Product Owner defines what
• The team defines how and how much
• First day of Iteration, four hours max
Output: Iteration Goals and backlog of the team’s commitment
Business commits to leaving priorities unchanged during
the Iteration
Basic format
1.Confirm team velocity
2.Clarify stories & acceptance criteria
(negotiate if needed)
3.Estimate (split stories if needed)
4.Add stories until reach velocity
5.Create Iteration goals & commit!
Reminder to Include
1.Test automation time
2.Investigation/design time

Daily stand-up
Purpose : It is used to:
• Share information about progress
• Coordinate activities (team synchronization)
• Raise blocking issues
Meeting time is whenever is most convenient
for the team (every day in front of team board)
Timebox of 15 minutes
It is not:
• status meeting for management
• a problem-solving session
Basic format
Each person answers:
1.What did I do yesterday?
2.What will I do today?
3.Anything blocking the Iteration
Goals?
Meet-After agenda
1.Review topics the Scrum Master
wrote on the meet-after board
2.Involved parties discuss, uninvolved
people leave

Backlog refinement / Groming
Allows team to preview (“sleep” on) upcoming stories prior to the next
Iteration Planning
Opportunity to:
• Identify and resolve dependencies and issues that could impact the next Iteration
• Improve user stories (who, what, why)
• Add acceptance criteria (estimates may change)
• Point out missing information to the Product Owner
Focus is on the next Iteration, but if time allows, discuss future Iterations and
even Features for the next PI
Occurs prior to upcoming iteration planning; 2 hours per iteration

Sprint review / demo
Provides the true measure of progress by showing working
software functionality, hardware components, etc.
Preparation for the review begins during planning (how will
we demo?)
Teams demonstrate every Story, Spike, Refactor, and NFR
(and gathers feedback)
Attendees are the Team and its stakeholders (PO will follow
up if needed)
Timebox: 1 – 2 hours
Limit preparation to 1 – 2 hours. Minimize PowerPoint.
Basic format
1.Review Iteration Goals
2.Demo each Story, spike, refactor,
and NFR (meet DoD? See next slide)
3.Discussion of Stories not completed
and why
4.Review of risks and impediments
5.Any changes? Revise team backlog
and Team PI Objectives as needed
Two Views
1. How did we do on our Iteration
Goals?
2. Are we on track with our PI
Objectives?

Sprint review / retrospective
Team reflects on how to become more effective and
adjusts accordingly. Continuous improvement!
30 – 60 minutes
Excuse non-team members from this meeting
Pick 1 – 2 things that can be done better,
target for next Iteration
Enter improvement items into the Team Backlog
***Important!
Basic format
Part 1: Quantitative
1.Review the improvement backlog item
from the last Iteration. Have we taken
action?
2.See sample metrics on next page…Did
the team meet the goals (yes/no)?
Part 2: Qualitative
1.What went well?
2.What didn’t?
3.What we can do better next time?

SAFe PROGRAM events
PI (Program Increment) Planning
Scrum of Scrums
PO/PM Sync
Backlog Refinement
System Demo
Inspect & Adapt

PI planning (pacemaker of the Agile Entreprise)
Align teams around a common mission with a clear set of prioritized
objectives
Cadence is two days every 8 – 12 weeks
Everyone attends in person if at all possible
Product Management owns Feature priorities (vision/what)
Product Owner has authority to make decisions at user story level
Development teams own story-planning, high-level estimates (how), and
working out interdependencies with other teams
Architects and UX work as intermediaries for governance, interfaces,
and dependencies
Facilitator is Release Train Engineer

Day 1 agenda

Day 2 agenda

ART Sync
Programs coordinate dependencies through sync meetings
Visibility into progress and impediments
Facilitated by RTE
Participants: Scrum Masters, other select team
members, SMEs if necessary
Weekly or more frequently, 30 – 60 minutes
Timeboxed, and followed by a “meet after”
Visibility into progress, scope, and priority
adjustments
Facilitated by RTE or PM
Participants: PMs, POs, other stakeholders,
and SMEs as necessary
Weekly or more frequently, 30 – 60 minutes
Timeboxed, and followed by a “meet after”

Program Backlog refinement / grooming
Owned by Product Management
Actively managed to prepare for the next PI planning
Typically Includes:
•Prioritization items using WSJF (weighted shortest job first)
•Reviewing/updating backlog item definition, acceptance criteria and benefit hypothesis
•Working with PO/teams/SME to establish technical feasibility and scope estimates
•Splitting backlog items into smaller chunks of incremental value (to fit within PI)
•Working with architects to identify enablers required to support new features and
capabilities, and establishing their capacity allocation %
Final backlog preparation done 1 or 2 weeks before PI planning
Works with Product Owners to refine/groom the backlog before PI planning
event

Integrated System Demo
Demonstrate the full System increment to stakeholders every Iteration.
Full system
System
Team
Check point to gather fast feedback and ensure you
are on the right track
Happens after the iteration review (may lag by as
much as one Iteration, maximum)
Demo from the staging environment, or the nearest
proxy

Inspect & Adapt
Includes:
1. The PI System Demo
2. Quantitative measurement
3. The problem-solving workshop
Timebox: 3 – 4 hours per PI
When: day prior to PI planning
PI System Demo:
Demonstrate the current state of the Solution
Typically led by Product Management, POs, and the System Team
Attended by all - Business Owners, program stakeholders, Product
Management, RTE, Scrum Masters, and teams

Alternative Scaled Agile models
1. Nexus (Scrum.org + Ken Schwaber, former « Scrum of Scrum »)
2. LeSS (Large Scale Scrum by Craig Larman)
3. DAD (Disciplined Agile Delivery by Scott Ambler)
4. Spotify model
5. Henrik Kniberg’s approach

Nexus Framework
A Nexus consists of 3-9 Scrum Teams working on a single Product Backlog to build an Integrated Increment
that meets a goal.
The framework is especially beneficial for organizations who have had positive results using Scrum with one or
two teams working on a single product and who want to scale more broadly.
The Nexus framework introduces one new role, the Nexus Integration Team (NIT).

LeSS Framework
Applied to many teams – cross functional, cross-component, full-stack features teams of 3-9 learning(focused people that do
it all – from UX to code to video – to create done items and shippable product
Working together…– because they have a common goal to deliver one common shippable product at the end of a common
Sprint, and each team cares about this because they are a feature team responsible for the whol, not a part
…on one product – a broad complete end-to-end customer-centric solution that real customers use. It’s not a component,
platform, layer or library

DAD Framework
Disciplined Agile Delivery (DAD) is a people-first, learning-oriented hybrid agile approach to IT solution delivery.
It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and is scalable.

Scale Agile @Spotify
Benefits of the method :
Autonomy and trust. Enhanced velocity
Processes are reduced to a minimum
Addresses short term challenges
Minimized dependencies
Lack of a firm structure makes problem solving
easier
Minimum control/Promotes clarity and
transparency
Works best for what suits your working
environment

Henrik Kniberg’s approach

Figures
5-12
2 W
(6)8 – 12
50 – 125

Figures
5-12
2 W
(6)8 – 12
W
50 – 125
Average sprint time (team/project level)
Total number of team members(people)
(for tex PI planning)
Nbr of Agile teams in ART
PI Duration/program increments
cadence of PI planning 2 days every (6)8-12 W
4 to 6 sprints of 2 W

Part of Schneider Digital under IoT & Digital Offers
Create and operate a mutualized IoT platform to accelerate digitization of
Schneider Electric offers
Scope from hardware design reference up to Big Data for Analytics
R&D teams split across 3 locations: Kolding, Grenoble and Andover, MA
EcoStruxure Technology Platforms at a glance

Answer to required visibility and commitment to our internal customers
Necessary to control time-to-market
Initiated in 2017 with help of a consultant
Switched from Essential SAFe to Large Solution SAFe in 2018
Four teams in 2017
Nine teams in 2019
Eleventh PI planning in February
Adoption of SAFe

So SAFE …. Agile or Not?
To put customer first and to tailor agility to context.
https://agnosticagile.org/

Requires strong foundations in SCRUM
SAFe is a framework which needs adaptation to your own context
Huge preparation work
Refinement and architectural during Innovation & planning sprint
Important role of transversal functions such as System Team and
DevOps
Permanent dialog needed between Product Management and Architects
Experience Take Aways

SAFe – Scaled Agile Framework Q &
A
groupe-sii.com | October 2018 | Confidential
Patrick POUCHOT
Agile Project Manager SII
ppouchot@sii.fr
Maxence VAN HOVE
Manager Schneider Digital Service Platform
maxence.vanhove@se.com

www.groupe-sii.com | 2017
Thank you ! Merci!

Meetup#2 SAFe Patrick & Maxence

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Meetup#2 SAFe Patrick & Maxence

Similar to Meetup#2 SAFe Patrick & Maxence (20)

More from Alexandre Boutin

More from Alexandre Boutin (11)

Recently uploaded

Recently uploaded (20)

Meetup#2 SAFe Patrick & Maxence

Editor's Notes