Einführung in das Scaled Agile Framework (SAFe) und Vergleich mit Larman's Large Scale Scrum (LeSS).

1. 1
Lieber SAFe oder LeSS
Vergleich
Scaled Agile Framework (SAFe) und
Large Scale Scrum (LeSS)
agile-scrum.de
Josef Scherer
josef.scherer@gmail.com

2. 2
ServicesSPC, 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
 josef.scherer@gmail.com
 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

3. 4
Framework Creator: Dean Leffingwell
4

4. 5
SAFe Delivers Business Results
5

5. 6
Roots of the Scaled Agile Framework
6

6. 7
Lean Thinking

7. 8
Systems Must be Managed
8

8. 9
Lean Thinking House
9

9. 10
Goal: Speed, Value, Quality
10

10. 14
Product Development Flow
14

11. 16 16

12. 18 18

13. 1919

14. 20
Agile Teams Produce Higher Quality Code
20

15. 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)

16. 22 22

17. 23
Flow, Cadence & Synchronization
23

18. 2424

19. 25
Develop on Cadence. Deliver on Demand.
25

20. 27
Alignment
27

21. 28
Key Program Level Roles
 Product Management
 Release Train Engineer (RTE)
 System Architect
 System Team

22. 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

23. 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

24. 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

25. 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

26. 33
Program Level Artifacts
 Roadmap
 Program Backlog & Features
 PSI/Release Objectives
 Program Plan

27. 34
Roadmap
The Roadmap guides the delivery of Features over time

28. 35
Program Backlog & Features

29. 36
Release Planning Team Deliverables

30. 37
Program Plan, Milestones & Dependencies

31. 38
Program Level Events
 Release Planning
 Scrum of Scrums
 System Sprint Demo
 Community of Practice (CoP)
 HIP Sprints
 Inspect & Adapt

32. 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

33. 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

34. 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

35. 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

36. 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)

37. 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

38. 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

39. 46
Synchronizing
Waterfall & Agile Teams
 Synch at key (PSI/Release)
milestones
 Synch frequently (every Sprint)

40. 47
Low Dependency Teams

41. 48
High Dependency Teams

42. 49
Large Scale Scrum
 Principles
 Organisations Design
 Framework I (- 10 Team)
 Team Coordination

43. 50
Larman, Vodde 2008, 2010: LeSS bei Valtech & NSN

44. 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

45. 52
LeSS Principles & Themes

46. 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.

47. 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
...

48. 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

49. 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.
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
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.
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
Component teams Feature teams
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
All rights reserved.

50. 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

51. 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. Vodde
All rights reserved.

52. 59
LeSS Framework I für bis zu 10 Teams

53. 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
– …

54. 61
SAFe Portfolio Level

55. 6262