The document introduces Large Scale Scrum (LeSS), emphasizing the importance of team-based organizations with a focus on collaboration and stability over traditional structures. It outlines key roles, including the Product Owner, who manages the product backlog and ensures the team delivers high ROI items, as well as the Scrum Master's facilitative role. The document highlights benefits such as enhanced efficiency, real product quality ownership, and a shift towards self-managing teams, which necessitates a change in managerial responsibilities.

1. LeSS – Large Scale
Scrum
A short intro to LeSS

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
What it is actually about…

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 4
Item 5
Item 8
Team 1
Sprint Backlog 2
Item 2
Item 7
Item 9
Item 10
Team 2
Sprint Backlog 3
Item 3
Item 6
Item 11
Team 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
Epic 1
Epic 2
Epic 3
Epic 4
Epic 5
Epic 6
…
Activation
PO
Retention PO
Activation Backl.
Epic 1, Item 1
Epic 1, Item 2
Epic 3, Item 1
Epic 3, Item 2
Epic 3, Item 3
Epic 1, Item 3
Epic 1, Item 4
Epic 1, Item 5
Epic 1, Item 6
…
Retention Backl.
Epic 2, Item 1
Epic 2, Item 2
Epic 4, Item 1
Epic 4, Item 2
Epic 4, Item 3
Epic 2, Item 3
Epic 2, Item 4
Epic 2, Item 5
Epic 2, Item 6
…
…
4-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?

12. Definition of Done

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. The minimal rules to kick-off learning in larger org.
2. Real decision authority, that I’ve rarely experienced
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
www.agile.coach

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)