Your SlideShare is downloading. ×
Lieber SAFe oder LeSS?
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Lieber SAFe oder LeSS?

596
views

Published on

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

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
596
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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