LeSS (Large-Scale Scrum)

Get Started. It's Free
or sign up with your email address
LeSS (Large-Scale Scrum) by Mind Map: LeSS (Large-Scale Scrum)

1. Systems thinking

1.1. Master complexity of dynamics instead of static details

1.2. Casual loop diagrams

1.2.1. Define variables such as # of defects, and link them them

1.2.2. Casual links

1.2.3. Delays

1.2.4. Quick fix reactions

1.2.5. Extreme effects

1.2.6. Constraints

1.2.7. Positive feedback loops

1.2.8. Opposite effect

1.3. Root cause tools

1.3.1. Ishikawa (Fishbone)

1.3.2. Five whys

1.3.3. Watch the baton, not the runners

1.4. Measurement dysfunction

1.5. Secret developer toolbox

2. Organisation redesign

2.1. How to transition into cross-functional?

2.1.1. Embed first: analysis, coding, soft.arch., testing

2.1.2. Gradually expand team responsibility

2.2. Cross-component, not component teams

2.2.1. Big, slow organisation will build big and slow systems

2.3. Self-management

2.3.1. Teams & individuals evolve their own practices and improvements

2.3.2. Need right environment first

2.3.3. Autonomous

2.3.4. Cross-functional / see the whole

2.3.5. Challenged

2.3.6. Manages the work & the work process

2.3.7. Yokoten - spread knowledge laterally

2.4. Avoid...projects in product development

2.5. Communities of Practice

2.5.1. Functional learning

2.5.2. Volountary

2.5.3. OpenSpace

2.6. Top-down and Bottom-up approach

2.7. Seeing the whole

2.7.1. Whole product Product components as seen by the customer

2.7.2. Feature team co-creates product with users

2.7.3. Team specialisation in customer domain over technical

3. Lean

3.1. Reducing lean thinking to kanban, queue management and other tools is like reducing a working democracy to voting.

3.2. Toyota’s real advantage was its ability to harness the intellect of ‘ordinary’ employees.

3.3. Principles

3.3.1. Kaizen Culture of continuous improvement Challenge status quo / everything Why are we doing this? Toyota "Global Goal" "See the whole" Genchi Genbutsu - Go and See Stop and fix right Improve for improvement's sake, endlessly My work is to do my work and to improve my work Yokoten - spread knowledge laterally Waste

3.3.2. Respect Management Management commitment to continuously invest in its people The responsibility lies, not with black belt specialists, but with the leadership hierarchy that runs the operation and they are teachers and coaches. Act as teachers of thinking skills Long term philosophy "Transparency is the new control system" Person at the next workstation is also your customer

3.4. Queueing Theory

3.4.1. Benefits Reduced overall release-cycle-time Freedom for business to ship a smaller product earlier Ineffective practices are exposed

3.4.2. WIP queue

3.4.3. Shared resource queue

3.4.4. Invisible queue

3.4.5. Serial vs parallel development Point kaizen (kanban system) System kaizen Eradicate a queue

3.4.6. Scrum: queue of feature requests in PBL

3.4.7. Suggestions in Scrum Similar-sized user stories in release backlog Product Backlog Refinement workshop - 5% Stable feature teams Spike - timeboxed effort-boxed learning goal

3.4.8. Theory of Constrains (TOC) One bottleneck that limits throughput

4. Re-use info and knowledge

4.1. Wiki

4.2. Design Patterns

5. Team

5.1. Advantages

5.1.1. Deliver what customer values most

5.1.2. Intensified learning

5.1.3. Planning is easier

5.1.4. Handoff reduced

5.1.5. Less waiting waste

5.1.6. Cost reduction, efficiency, less management

5.2. Team as org. building block

5.2.1. Accountability

5.2.2. Leadership changes in team

5.2.3. Across all disciplines

5.2.4. 7 +- 2 people

5.2.5. Cross-component

5.2.6. Balance

5.2.7. Long-lived

5.2.8. Identity

5.2.9. Empowerment

5.2.10. Generalising specialists

5.2.11. Consensus

5.2.12. Working agreements

5.2.13. Cross-functional

5.2.14. Co-located

5.2.15. Could work on multiple products

5.2.16. Shared responsibility

6. Architecture and design

6.1. Set-based design (exploring several alternatives)

6.2. Design workshop

6.3. Agile Modelling

7. Writing code

7.1. No locking in version control

7.2. Continuous Integration

7.3. Trunk based development

7.3.1. Avoid...Staircase branching

7.4. TDD

7.5. Evolutionary Design

7.6. Shared code ownership

7.6.1. Component guardians

7.6.2. Architecture code police

7.6.3. Community of practice

7.6.4. Part-time architectural community of practice

7.6.5. Temporary infrastructure team

8. Multiple teams

8.1. Working agreements

8.1.1. Definition of Done

8.2. Requirements area

8.2.1. Customer centric

8.2.2. Set of strongly related features

8.2.3. Independently managed area backlog

9. Tools

9.1. Avoid traditional requirement management tools

9.2. Avoid tools optimized for reporting

9.2.1. Prevents Genchi Genbutsu

10. Scrum Scaled Up

10.1. LeSS basic

10.1.1. Up to 8 teams

10.1.2. Domain experts can help PO

10.1.3. Refinement can be done by teams

10.1.4. PO not involved in low level details

10.1.5. Sprint planning part 1 All teams in one room or 2 representatives from each team Teams volunteer backlog items

10.1.6. Daily Scrum members from other teams observe as chickens

10.1.7. Joint retrospective

10.2. LeSS huge

10.2.1. Requirement areas (if more than 8 teams) Area backlog Area Product Owner Dedicated Scrum Feature teams

10.2.2. Product Owner team PO and all APOs

10.3. LeSS ScrumMaster

10.3.1. Deals with large-scale problems

10.3.2. Focus in later stage Change organisation Development practices

10.3.3. Focus in beginning Product Owner Team

10.3.4. Colocate with teams

10.4. Product Owner in LeSS

10.4.1. Candidates Product manager Someone from user group with authority From company receiving the system, close to user

10.5. Timeboxing

10.5.1. Takt time

10.5.2. Enforces cadence

10.5.3. Increases focus

10.5.4. Limits scope creep

10.5.5. Limits gold-plating

10.5.6. Reduces Student Syndrome

11. Multisite

11.1. Colocate entire requirement area? Yes and No!

12. Type of development

12.1. Product (external customer)

12.2. Internal (IT department)

12.3. Project (outsourcer)