LeSS-Intro - Scrum Meetup Berlin
0 likes1,274 views
1. The document introduces the Large Scale Scrum (LeSS) framework for scaling agile development with multiple teams. 2. Key aspects of LeSS include having a single Product Owner prioritize work for all teams, representatives from each team participate in events like planning and retrospectives, and defining "Done" to mean work that is potentially shippable. 3. Feature teams are adopted, where multidisciplinary teams work on end-to-end features rather than individual components. This allows for greater autonomy, motivation, and learning among teams.
LeSS-Intro - Scrum Meetup Berlin
- 1. LeSS – Large Scale Scrum 15 min Intro to LeSS on 12th August 2015
- 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 Why all this?
- 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 3 Item 5 Item 8 Team 1 Sprint Backlog 2 Item 1 Item 2 Item 3 Item 4 Item 5Team 2 Sprint Backlog 3 Item 1 Item 2 Item 3 Item 4 Item 5Team 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 Item 1 Item 2 Item 3 Item 4 Item 5 Item 6 Item 7 Item 8 Item 9 … Network PO Monitoring PO Network Backlog Item 1 Item 2 Item 3 Item 4 Item 5 Item 6 Item 7 Item 8 Item 9 … Monitoring Backl. Item 1 Item 2 Item 3 Item 4 Item 5 Item 6 Item 7 Item 8 Item 9 … … Up to 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. It’s still a framework, applicable to different contexts 2. Real decision authority becomes possible for the product owner 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 anton@skornyakov.de www.skornyakov.de
- 18. BackUp
- 19. Principles QUEUEING THEORY SYSTEMS THINKING LEAN THINKING CONTINUOUS IMPROVEMENT TOWARDS PERFECTION EMPIRICAL PROCESS CONTROL LARGE-‐SCALE SCRUM IS SCRUM WHOLE PRODUCT FOCUS CUSTOMER CENTRIC MORE WITH LESS TRANSPARENCY
- 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)