Short Introduction to Large Scale Scrum LeSS
1 like760 views
The document introduces Large Scale Scrum (LeSS), emphasizing the importance of team-based organizations with a focus on collaboration and stability over traditional structures. It outlines key roles, including the Product Owner, who manages the product backlog and ensures the team delivers high ROI items, as well as the Scrum Master's facilitative role. The document highlights benefits such as enhanced efficiency, real product quality ownership, and a shift towards self-managing teams, which necessitates a change in managerial responsibilities.
Short Introduction to Large Scale Scrum LeSS
- 1. LeSS – Large Scale Scrum A short intro to LeSS
- 2. “There is no question that the cost of production is lowered by separating the work of planning and the brain work as much as possible from the manual labor“ Frederick Taylor What it is actually about…
- 3. Source: http://less.works/ “BuildYour Method Up - Don’tTailor It Down”
- 4. Roles
- 5. Team-based Organizations Learning humans over “one-skill resources” Teams over individuals as unit of ‘resourcing’ Give work to creative teams over Creating teams around work Stable organizations over dynamic matrixed structures Guidelines Specialisation intechnology Specialisation in customer domain Most Traditional Teams Probably more preferable Team = Development-Team
- 6. Product Owner Single Team Scrum Large Scale Scrum PO is the single person responsible for the team working on items with the highest ROI PO is the single person responsible for the team working on items with the highest ROI PO clarifies PBIs with the team PO connects team with users / stakeholders needed for clarification PO accepts / rejects the work PO typically accepts anything that fulfils the DoD
- 7. Roles & Backlogs PO Product Backlog Item 1 Item 2 Item 3 Item 4 Item 5 Item 6 Item 7 Item 8 Item 9 … Sprint Backlog 1 Item 1 Item 4 Item 5 Item 8 Team 1 Sprint Backlog 2 Item 2 Item 7 Item 9 Item 10 Team 2 Sprint Backlog 3 Item 3 Item 6 Item 11 Team 3 1 Product Backlog Sprint backlog per team SM SM Up to 8 dev. teams 1 Scrum Master per 1-3 teams
- 8. Huge-LeSS PO Product Backlog Epic 1 Epic 2 Epic 3 Epic 4 Epic 5 Epic 6 … Activation PO Retention PO Activation Backl. Epic 1, Item 1 Epic 1, Item 2 Epic 3, Item 1 Epic 3, Item 2 Epic 3, Item 3 Epic 1, Item 3 Epic 1, Item 4 Epic 1, Item 5 Epic 1, Item 6 … Retention Backl. Epic 2, Item 1 Epic 2, Item 2 Epic 4, Item 1 Epic 4, Item 2 Epic 4, Item 3 Epic 2, Item 3 Epic 2, Item 4 Epic 2, Item 5 Epic 2, Item 6 … … 4-8 feature teams
- 9. Five relationships of the PO PO Customers Team SM Higher Management Clarification of PBIs
- 10. Events
- 11. Events with Representatives Meeting Planning One Overall Product Backlog Refinement Overall Retrospective Participants PO + Team Representatives + SM PO + Team Representatives + SM PO + SM + Team Representatives + (Managers) Activities/Focus - Teams apportion items - clear open questions - discuss coordination for upcoming sprint - Split big items - lightweight analysis for basic understanding - estimate - identify strongly related items and apportion items to teams - issues common to all teams: closeness to customer, CoP, coordination, systematic organisational issues - Is PO doing well?
- 13. Extending “Done” to cover potentially shippable Implement Code Implement Integration Tests Implement Unit Tests Today 2 years 5 years 10 years analysis & design customer tests customer doc performance tests marketing material production Needed to be potentially shippable
- 14. Feature Team Adoption 1 Source: http://less.works/
- 15. Feature Team Adoption 2 Source: http://less.works/
- 16. Why I like it 1. The minimal rules to kick-off learning in larger org. 2. Real decision authority, that I’ve rarely experienced 1. Very important efficiency gain is possible (Pareto rule) 3. Real product quality ownership of the teams 1. Enables real motivation 2. Enables real learning 3. Allows to tap into the cognitive potential of all employees 4. Honesty about feature teams | DoD vs. potentially shippable
- 17. Anton Skornyakov Coach for Agile Product Development @antonskornyakov www.agile.coach
- 18. BackUp
- 20. Coordination (= Integration) Nr. 1: Just Talk Communicate in Code - social coding tools: github/gitlab - Have a CI & highly visible build results Scrum of Scrum - SoS only means of last resort Communities of Practice Travelers Component Guardians (mentors not quality gate keepers) Leading Team Approach, when needed to sync with externals
- 21. Scrum Master 1. Question 2. Educate 3. Facilitate 4. Actively do nothing (observe) 5. Interrupt DO’s 1. Remove impediments (thats for the team to do) 2. Never suggest one thing (if you must suggest, suggest a lot of things DONT’s
- 22. Team vs. manager responsibility setting overall direction designing the team and its organisational context Monitoring and managing work and progress Execute team tasks Manager-led teams Self-Managing teams Self- Designing team Self- Governing teams Management responsibility Team’s own responsibility Changing from manager-lead teams to self-managing teams has huge implications on the role of managers. It means that: • the team checks whether they are on track (monitor the progress) • the team takes action when not on track (manage the progress) • the team decides how to work (managing the process) • the team resolves team conflict and fixes problems in the team (monitor and manage the process)