lieber safe oder less?
TRANSCRIPT
1
Lieber SAFe oder LeSS Vergleich
Scaled Agile Framework (SAFe) und
Large Scale Scrum (LeSS)
agile-scrum.de
Josef Scherer
2
Services SPC, CSP, CSD, …
About Josef Scherer
Scrum/Agile Coach since 2007
Lead Agile Transitions @
Allianz DE, Telekom P&I, …
BMW: Senior Agile Coach @
IAP 2, BMWi USP
Coderetreats@BMW with Martin
Klose
Leading SAFe training
SAFe Agilist (SA) certification
SAFe ScrumXP training
SAFe Practitioner (SP)
certification
Agile Release Train Quickstarts
Agile/Scrum Coaching
Solution Focused Coaching
Retrospectives & Innovation
Games Facilitator
I am a certified SAFe Program Consultant (SPC) , SAFe Trainer &
Scrum/Agile Coach
4
Framework Creator: Dean Leffingwell
4
5
SAFe Delivers Business Results
5
6
Roots of the Scaled Agile Framework
6
7
Lean Thinking
8
Systems Must be Managed
8
9
Lean Thinking House
9
10
Goal: Speed, Value, Quality
10
14
Product Development Flow
14
16 16
18 18
19 19
20
Agile Teams Produce Higher Quality Code
20
21
PSI / Release
timebox of 5 Sprints to synchronize release planning, inspection and adaption of an Agile Release Train
(50-125 people, 5-12 ScrumXP Teams)
22 22
23
Flow, Cadence & Synchronization
23
24 24
25
Develop on Cadence. Deliver on Demand.
25
27
Alignment
27
28
Key Program Level Roles
Product Management
Release Train Engineer (RTE)
System Architect
System Team
29
Product Management
Product Management is the „content authority“ for the Release Train
Continuously interacts with customers and
stakeholders for solution definition and
feedback
Owns the Vision
– Works with stakeholders to establish and
articulation Vision
– Defines statement, positioning, and solution
economic model
Drives the PSI/Release
– Defines and prioritizes Program Backlog
– Participates in Release Planning and I&A
Communicates the Roadmap
30
Release Train Engineer (RTE)
Facilitates release planning readiness and
the Release Planning Meeting
Assists program execution and tracking
Facilitates Scrum of Scrums
Ensures collaboration within and across
trains
Escalates impediments and helps manage
risk
Helps drives program-level continuous
improvement
The RTE is the „Chief Scrum Master“ for the Agile Release Train
31
System Architect
Helps to maintain a high level
understanding of system requirements and
NFRs
Evaluates design alternatives and performs
cost benefit Analysis
Presents the technological Vision during
Release Planning
Helps the teams make appropriate design
decisions during implementation
Establishes test automation strategies
Works with Enterprise Architects to
establish Architectural Runway
The System Architect plays a unique role in helping teams
efficiently implement stakeholder needs
32
System Team Integrates and Evaluates
Build/supports development infrastructure
and manage environments
Assist with test automation strategies and
adoption
Provide/support full system integration
Perform end-to-end system and system
quality (NFRs) testing
Stage and support System Sprint Demo
The System Team provides process and tools to integrate and
evaluate assets early and often
33
Program Level Artifacts
Roadmap
Program Backlog & Features
PSI/Release Objectives
Program Plan
34
Roadmap
The Roadmap guides the delivery of Features over time
35
Program Backlog & Features
36
Release Planning Team Deliverables
37
Program Plan, Milestones & Dependencies
38
Program Level Events
Release Planning
Scrum of Scrums
System Sprint Demo
Community of Practice (CoP)
HIP Sprints
Inspect & Adapt
39
Release Planning Meeting
Two days every 8-12 weeks
Everyone attends in person if at all possible
Product Management owns feature priorities
Development team owns story planning and high-level
estimates
Architects, UX folks work as intermediaries for
governance, interfaces and dependencies
Result: A committed set of program objectives for the
next PSI
40
Scrum of Scrums
The Scrum of Scrums is
a meeting for Scrum
Masters and the
Release Train Engineer
to gain visibility into
team progress and
program impediments
It is typically held twice
per week
It is timeboxed but is
followed by a “Meet
After” for problem-
solving
Programs continuously coordinate dependencies through
Scrum of Scrums
41
Continuous Inter-team Coordination
Agile team members
may visit other team’s…
Backlog grooming: to
see what’s coming next
sprint, request
adjustments
Sprint planning: request
adjustments
Daily standups: follow
up on execution
Team Demo: summarize
current stage
Agile Teams self-manage dependencies and resolve risks
42
Fortnightly System Sprint Demo
A demonstration of the
integrated software
assets.
For business owners
and other program
stakeholders (many of
whom could not attend
every team demo)
Happens after the team
sprint demos (may lag
by as much as a sprint,
maximum!)
Every sprint, the System Team/Product Management demonstrates
the solution increment to the program stakeholders
43
CoPs Support Continuous Learning
Typical CoPs:
– Architecture and Design
– Automated Testing
– Continuous Integration
– Etc. …
May meet multiple times per PSI/Release
Session example:
developer from ‘Transformers’ Team shows others how
to use mock objects in real examples
Agile Teams share new expertise and experience
via Communities of Practice (CoPs)
44
HIP Sprints
Hardening: Some system test, product and regulatory
validation, and documentation may not be practical
every sprint.
– BUT not an excuse to build up technical debt!
Innovation/Improvement:
– Opportunity for innovation spikes, heckathons, and
continuous education
– infrastructure improvements
– Inspect&Adapt Workshop
Planning: Readiness, Release Planning
Hardening/Innovation/Planning (HIP) sprints
enable cadence and delivery reliability
45
Inspect&Adapt
I&A has three parts:
Part 1.
The PSI demo of the solution’s current state to program
stakeholders
Part 2.
Quantitative measurement (Rel. Obj., Velocity, Quality)
Part 3.
The problem solving workshop
Attendees:
teams and stakeholders
Timebox:
3-4 hours per PSI
Inspect and Adapt (I&A) is to a Release Train what
the sprint demo and retrospective are to a team
46
Synchronizing
Waterfall & Agile Teams
Synch at key (PSI/Release)
milestones
Synch frequently (every Sprint)
47
Low Dependency Teams
48
High Dependency Teams
49
Large Scale Scrum
Principles
Organisations Design
Framework I (- 10 Team)
Team Coordination
50
Larman, Vodde 2008, 2010: LeSS bei Valtech & NSN
51
Komplexität, Einfachheit & Selbstorganisation
Simple, clear purpose and principles give rise to
complex, intelligent behavior.
Complex rules and regulations give rise to
simple, stupid behavior.
Dee Hock, Gründer und CEO VISA
Dee Hock.The Birth of the Chaordic Age
52
LeSS Principles & Themes
53
LeSS als Organisations-Design-Framework
Larman‘s Law: Cuture follows structure
beginnt damit Standard Scrum zu verstehen und
in einzelnen Teams anwenden zu können,
führt beim Skalieren zu tiefgreifenden
organisatorischen Veränderungen und
benötigt daher das volle Verständnis und die
Unterstützung des Senior Managements.
54
Die ideale Produktentwicklungs-Organisation
Scrum Feature Teams
Area Product Owner
Produkt Manager/Product
Owner
CXO CPMO
Produkt A
Area x Area y
Feature Team 1
Feature Team n
Feature Team 10
Service & Support
Produkt B
...
55
Von Spezialisten Teams zu interdisziplinären
Teams
IT Spezialisten Teams Interdisziplinäre PD Teams
Lead Designer
Designer
Designer
Lead Arch.
Architekt
Architekt
Lead Dev
Developer
Developer
Developer
Developer
Developer
Developer
Test Lead
Tester
Tester
Tester
56
Von Komponenten- zu Feature-Teams
Komponenten Design Fokus
Item 1
Item 2
Item 3
Item 4
...
…
system
comp
C
Team
comp
A
Work from multiple teams is required to finish a customer-centric feature. These dependencies cause waste such as additional planning and coordination work, hand-offs between teams, and delivery oflow-value items. Work scope is narrow.
Product
Owner
comp
B
Team
comp
A
Team
comp
B
comp
C
Item 1
Item 2
Item 3
Item 4
...
…Team
Wu
Product
Owner
Team
Shu
Team
Wei
system
comp
A
comp
B
comp
C
Every team completes customer-centric items. The dependencies between teams are related to shared code. This simplifies planning but causes a need for frequent integration, modern engineering practices, and additional learning.Work scope is broad.
Component teams Feature teams
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
All rights reserved.
Customer Feature Fokus
Item 1
Item 2
Item 3
Item 4
...
…
system
comp
C
Team
comp
A
Work from multiple teams is required to finish a customer-centric feature. These dependencies cause waste such as additional planning and coordination work, hand-offs between teams, and delivery oflow-value items. Work scope is narrow.
Product
Owner
comp
B
Team
comp
A
Team
comp
B
comp
C
Item 1
Item 2
Item 3
Item 4
...
…Team
Wu
Product
Owner
Team
Shu
Team
Wei
system
comp
A
comp
B
comp
C
Every team completes customer-centric items. The dependencies between teams are related to shared code. This simplifies planning but causes a need for frequent integration, modern engineering practices, and additional learning.Work scope is broad.
Component teams Feature teams
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
All rights reserved.
57
Von funktionalen Silos zu Communities of Practice
Funktionale Silos Communities of Practice
Leiter Design
Designer Team
Designer Team
Leiter Arch.
Architekten Team
Architekten Team
Leiter SWE
Developer Team
Developer Team
Developer Team
Developer Team
Developer Team
Developer Team
Leiter QS
QS Team
QS Team
QS Team
58
Von Verträgen zur direkten Zusammenarbeit
„Contract Game“ FB & IT Produkt Manager als PO
Product
Management
R&Dstart end
(release)content freeze
(release contract agreed)
The Milestone point
is arbitrary
more,
more,
more!
less,
less,
less!
1 2
The Contract
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. V odde
All rights reserved.
59
LeSS Framework I für bis zu 10 Teams
60
Team Koordination
Durch gemeinsame Sprint Meetings mit Team
Vertretern
– Joint Product Backlog Refinement
– Joint Sprint Planning I
– Joint Retrospective
Interne Open Source, collective code ownership
Continuous Integration
Teamübergreifende Communities of Practice
(CoPs) z.B. für"
– Architektur
– User Experience
– …
61
SAFe Portfolio Level
62 62