Lieber SAFe oder LeSS?
7 likes3,190 views
This document provides an overview comparison of the Scaled Agile Framework (SAFe) and Large Scale Scrum (LeSS) frameworks for scaling agile development. It describes some of the key aspects of each framework including their origins, principles, roles, events, and how they approach scaling agile practices to the portfolio/program and large team levels. The document aims to help readers understand the different approaches taken by SAFe and LeSS for enabling agility at an enterprise scale.
Lieber SAFe oder 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
- 7. 8 Systems Must be Managed 8
- 9. 10 Goal: Speed, Value, Quality 10
- 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)
- 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 – …
- 55. 6262