Create your own awesome maps

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
Scrum)
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

Delays

Quick fix reactions

Extreme effects

Constraints

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

Self-management

Teams & individuals evolve their own practices and improvements

Need right environment first

Autonomous

Cross-functional / see the whole

Challenged

Manages the work & the work process

Yokoten - spread knowledge laterally

Avoid...projects in product development

Communities of Practice

Functional learning

Volountary

OpenSpace

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

Lean

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.

Principles

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

Wiki

Design Patterns

Team

Advantages

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

Accountability

Leadership changes in team

Across all disciplines

7 +- 2 people

Cross-component

Balance

Long-lived

Identity

Empowerment

Generalising specialists

Consensus

Working agreements

Cross-functional

Co-located

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

TDD

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

Tools

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

Timeboxing

Takt time

Enforces cadence

Increases focus

Limits scope creep

Limits gold-plating

Reduces Student Syndrome

Multisite

Colocate entire requirement area? Yes and No!

Type of development

Product (external customer)

Internal (IT department)

Project (outsourcer)