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. Re-use info and knowledge

2.1. Wiki

2.2. Design Patterns

3. Team

3.1. Advantages

3.1.1. Deliver what customer values most

3.1.2. Intensified learning

3.1.3. Planning is easier

3.1.4. Handoff reduced

3.1.5. Less waiting waste

3.1.6. Cost reduction, efficiency, less management

3.2. Team as org. building block

3.2.1. Accountability

3.2.2. Leadership changes in team

3.2.3. Across all disciplines

3.2.4. 7 +- 2 people

3.2.5. Cross-component

3.2.6. Balance

3.2.7. Long-lived

3.2.8. Identity

3.2.9. Empowerment

3.2.10. Generalising specialists

3.2.11. Consensus

3.2.12. Working agreements

3.2.13. Cross-functional

3.2.14. Co-located

3.2.15. Could work on multiple products

3.2.16. Shared responsibility

4. Architecture and design

4.1. Set-based design (exploring several alternatives)

4.2. Design workshop

4.3. Agile Modelling

5. Writing code

5.1. No locking in version control

5.2. Continuous Integration

5.3. Trunk based development

5.3.1. Avoid...Staircase branching

5.4. TDD

5.5. Evolutionary Design

5.6. Shared code ownership

5.6.1. Component guardians

5.6.2. Architecture code police

5.6.3. Community of practice

5.6.4. Part-time architectural community of practice

5.6.5. Temporary infrastructure team

6. Multiple teams

6.1. Working agreements

6.1.1. Definition of Done

6.2. Requirements area

6.2.1. Customer centric

6.2.2. Set of strongly related features

6.2.3. Independently managed area backlog

7. Tools

7.1. Avoid traditional requirement management tools

7.2. Avoid tools optimized for reporting

7.2.1. Prevents Genchi Genbutsu

8. Multisite

8.1. Colocate entire requirement area? Yes and No!

9. Type of development

9.1. Product (external customer)

9.2. Internal (IT department)

9.3. Project (outsourcer)

10. Organisation redesign

10.1. How to transition into cross-functional?

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

10.1.2. Gradually expand team responsibility

10.2. Cross-component, not component teams

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

10.3. Self-management

10.3.1. Teams & individuals evolve their own practices and improvements

10.3.2. Need right environment first

10.3.3. Autonomous

10.3.4. Cross-functional / see the whole

10.3.5. Challenged

10.3.6. Manages the work & the work process

10.3.7. Yokoten - spread knowledge laterally

10.4. Avoid...projects in product development

10.5. Communities of Practice

10.5.1. Functional learning

10.5.2. Volountary

10.5.3. OpenSpace

10.6. Top-down and Bottom-up approach

10.7. Seeing the whole

10.7.1. Whole product Product components as seen by the customer

10.7.2. Feature team co-creates product with users

10.7.3. Team specialisation in customer domain over technical

11. Lean

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

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

11.3. Principles

11.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

11.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

11.4. Queueing Theory

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

11.4.2. WIP queue

11.4.3. Shared resource queue

11.4.4. Invisible queue

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

11.4.6. Scrum: queue of feature requests in PBL

11.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

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

12. Scrum Scaled Up

12.1. LeSS basic

12.1.1. Up to 8 teams

12.1.2. Domain experts can help PO

12.1.3. Refinement can be done by teams

12.1.4. PO not involved in low level details

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

12.1.6. Daily Scrum members from other teams observe as chickens

12.1.7. Joint retrospective

12.2. LeSS huge

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

12.2.2. Product Owner team PO and all APOs

12.3. LeSS ScrumMaster

12.3.1. Deals with large-scale problems

12.3.2. Focus in later stage Change organisation Development practices

12.3.3. Focus in beginning Product Owner Team

12.3.4. Colocate with teams

12.4. Product Owner in LeSS

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

12.5. Timeboxing

12.5.1. Takt time

12.5.2. Enforces cadence

12.5.3. Increases focus

12.5.4. Limits scope creep

12.5.5. Limits gold-plating

12.5.6. Reduces Student Syndrome