Online Mind Mapping and Brainstorming

Create your own awesome maps

Online Mind Mapping and Brainstorming

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account? Log In

LeSS (Large-Scale Scrum) by Mind Map: LeSS (Large-Scale
0.0 stars - reviews range from 0 to 5

LeSS (Large-Scale Scrum)

Systems thinking

Master complexity of dynamics instead of static details

Casual loop diagrams

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

Casual links


Quick fix reactions

Extreme effects


Positive feedback loops

Opposite effect

Root cause tools

Ishikawa (Fishbone)

Five whys

Watch the baton, not the runners

Measurement dysfunction

Secret developer toolbox

Organisation redesign

How to transition into cross-functional?

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

Gradually expand team responsibility

Cross-component, not component teams

Big, slow organisation will build big and slow systems


Teams & individuals evolve their own practices and improvements

Need right environment first


Cross-functional / see the whole


Manages the work & the work process

Yokoten - spread knowledge laterally

Avoid...projects in product development

Communities of Practice

Functional learning



Top-down and Bottom-up approach

Seeing the whole

Whole product, Product components as seen by the customer

Feature team co-creates product with users

Team specialisation in customer domain over technical


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

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


Kaizen, Culture of continuous improvement, Challenge status quo / everything, Why are we doing this?, Toyota "Global Goal", Development - out-learn competition, Production - out-improve competition, "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, Temporarily necessary waste, Future battle, Pure waste, Batch size, It is not always bad (temporary necessary waste), Cycle time, Delay, WIP

Respect, Management, Management commitment to continuously invest in its people, Building people, then building products, 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

Queueing Theory

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

WIP queue

Shared resource queue

Invisible queue

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

Scrum: queue of feature requests in PBL

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

Theory of Constrains (TOC), One bottleneck that limits throughput

Re-use info and knowledge


Design Patterns



Deliver what customer values most

Intensified learning

Planning is easier

Handoff reduced

Less waiting waste

Cost reduction, efficiency, less management

Team as org. building block


Leadership changes in team

Across all disciplines

7 +- 2 people






Generalising specialists


Working agreements



Could work on multiple products

Shared responsibility

Architecture and design

Set-based design (exploring several alternatives)

Design workshop

Agile Modelling

Writing code

No locking in version control

Continuous Integration

Trunk based development

Avoid...Staircase branching


Evolutionary Design

Shared code ownership

Component guardians

Architecture code police

Community of practice

Part-time architectural community of practice

Temporary infrastructure team

Multiple teams

Working agreements

Definition of Done

Requirements area

Customer centric

Set of strongly related features

Independently managed area backlog


Avoid traditional requirement management tools

Avoid tools optimized for reporting

Prevents Genchi Genbutsu

Scrum Scaled Up

LeSS basic

Up to 8 teams

Domain experts can help PO

Refinement can be done by teams

PO not involved in low level details

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

Daily Scrum, members from other teams observe as chickens

Joint retrospective

LeSS huge

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

Product Owner team, PO and all APOs

LeSS ScrumMaster

Deals with large-scale problems

Focus in later stage, Change organisation, Development practices

Focus in beginning, Product Owner, Team

Colocate with teams

Product Owner in LeSS

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


Takt time

Enforces cadence

Increases focus

Limits scope creep

Limits gold-plating

Reduces Student Syndrome


Colocate entire requirement area? Yes and No!

Type of development

Product (external customer)

Internal (IT department)

Project (outsourcer)