1
Lieber SAFe oder LeSS
Vergleich
Scaled Agile Framework (SAFe) und
Large Scale Scrum (LeSS)
agile-scrum.de
Josef Scherer
...
2
ServicesSPC, CSP, CSD, …
About Josef Scherer
 Scrum/Agile Coach since 2007
 Lead Agile Transitions @
Allianz DE, Telek...
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
1919
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
(...
22 22
23
Flow, Cadence & Synchronization
23
2424
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 cu...
30
Release Train Engineer (RTE)
 Facilitates release planning readiness and
the Release Planning Meeting
 Assists progra...
31
System Architect
 Helps to maintain a high level
understanding of system requirements and
NFRs
 Evaluates design alte...
32
System Team Integrates and Evaluates
 Build/supports development infrastructure
and manage environments
 Assist with ...
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 Spri...
39
Release Planning Meeting
 Two days every 8-12 weeks
 Everyone attends in person if at all possible
 Product Manageme...
40
Scrum of Scrums
 The Scrum of Scrums is
a meeting for Scrum
Masters and the
Release Train Engineer
to gain visibility ...
41
Continuous Inter-team Coordination
 Agile team members
may visit other team’s…
 Backlog grooming: to
see what’s comin...
42
Fortnightly System Sprint Demo
 A demonstration of the
integrated software
assets.
 For business owners
and other pro...
43
CoPs Support Continuous Learning
 Typical CoPs:
– Architecture and Design
– Automated Testing
– Continuous Integration...
44
HIP Sprints
 Hardening: Some system test, product and regulatory
validation, and documentation may not be practical
ev...
45
Inspect&Adapt
I&A has three parts:
 Part 1.
The PSI demo of the solution’s current state to program
stakeholders
 Par...
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 be...
52
LeSS Principles & Themes
53
LeSS als Organisations-Design-Framework
 Larman‘s Law: Cuture follows structure
 beginnt damit Standard Scrum zu vers...
54
Die ideale Produktentwicklungs-Organisation
Scrum Feature Teams
Area
Product Owner
Produkt
Manager/Product
Owner
CXO CP...
55
Von Spezialisten Teams zu interdisziplinären
Teams
IT Spezialisten Teams Interdisziplinäre PD Teams
Lead
Designer
Desig...
56
Von Komponenten- zu Feature-Teams
Komponenten Design Fokus
Item 1
Item 2
Item 3
Item 4
...
…
system
comp
C
Team
comp
A
...
57
Von funktionalen Silos zu Communities of Practice
Funktionale Silos Communities of Practice
Leiter
Design
Designer
Team...
58
Von Verträgen zur direkten Zusammenarbeit
„Contract Game“ FB & IT Produkt Manager als PO
Product
Management
R&Dstart en...
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 Spr...
61
SAFe Portfolio Level
6262
Upcoming SlideShare
Loading in...5
×

Lieber SAFe oder LeSS?

707

Published on

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

Published in: Software, Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
707
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Lieber SAFe oder LeSS?

  1. 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. 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. 3. 4 Framework Creator: Dean Leffingwell 4
  4. 4. 5 SAFe Delivers Business Results 5
  5. 5. 6 Roots of the Scaled Agile Framework 6
  6. 6. 7 Lean Thinking
  7. 7. 8 Systems Must be Managed 8
  8. 8. 9 Lean Thinking House 9
  9. 9. 10 Goal: Speed, Value, Quality 10
  10. 10. 14 Product Development Flow 14
  11. 11. 16 16
  12. 12. 18 18
  13. 13. 1919
  14. 14. 20 Agile Teams Produce Higher Quality Code 20
  15. 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. 16. 22 22
  17. 17. 23 Flow, Cadence & Synchronization 23
  18. 18. 2424
  19. 19. 25 Develop on Cadence. Deliver on Demand. 25
  20. 20. 27 Alignment 27
  21. 21. 28 Key Program Level Roles  Product Management  Release Train Engineer (RTE)  System Architect  System Team
  22. 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. 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. 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. 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. 26. 33 Program Level Artifacts  Roadmap  Program Backlog & Features  PSI/Release Objectives  Program Plan
  27. 27. 34 Roadmap The Roadmap guides the delivery of Features over time
  28. 28. 35 Program Backlog & Features
  29. 29. 36 Release Planning Team Deliverables
  30. 30. 37 Program Plan, Milestones & Dependencies
  31. 31. 38 Program Level Events  Release Planning  Scrum of Scrums  System Sprint Demo  Community of Practice (CoP)  HIP Sprints  Inspect & Adapt
  32. 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. 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. 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. 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. 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. 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. 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. 39. 46 Synchronizing Waterfall & Agile Teams  Synch at key (PSI/Release) milestones  Synch frequently (every Sprint)
  40. 40. 47 Low Dependency Teams
  41. 41. 48 High Dependency Teams
  42. 42. 49 Large Scale Scrum  Principles  Organisations Design  Framework I (- 10 Team)  Team Coordination
  43. 43. 50 Larman, Vodde 2008, 2010: LeSS bei Valtech & NSN
  44. 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. 45. 52 LeSS Principles & Themes
  46. 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. 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. 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. 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. 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. 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. 52. 59 LeSS Framework I für bis zu 10 Teams
  53. 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. 54. 61 SAFe Portfolio Level
  55. 55. 6262
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×