LeSS - Moving beyond single team scrum

© leanpitch Technologies Private Limited
Naveen Kumar Singh
naveen.singh@leanpitch.com +91-9810547500 @naveenhome naveen75home
Large-Scale Scrum (LeSS)
Moving beyond single team Scrum

© leanpitch Technologies Private Limited 2
What problem you are trying to solve?
43 people
Multiple
project team
Different
Skills
Different
goal
Complex
coordination
Legacy code
Many
managers
But One
Product

Customer-centric and whole product focus

What is Product?
Single code base ?
Server-side or back-end ?
Library/Common platform/Service (Not sold directly) ?
A project to develop a few features ?

Exercise – Identify a product

Current product team structure

What is LeSS (Large-Scale Scrum)

What is LeSS (Large-Scale Scrum)
Large-Scale Scrum is Scrum and it is not new or improved scrum as stated by Craig
Larman and Bas Vodde.
LeSS is also not a framework to apply at team level instead it is scrum scaled on all the
levels.
Large-scale Scrum, like regular Scrum, is a framework for development in which the
details need to be filled in by the teams and evolved iteration by iteration, team by
team. It reflects the lean thinking pillar of continuous improvement. It is a collection of
suggestions for inspecting and adapting the product and process when there are many
teams—at least two teams and up to groups of 500 or 1000 people.
Read here - http://less.works/less/principles/large_scale_scrum_is_scrum.html

What is LeSS Principles?

Large-Scale Scrum is Scrum – LeSS doesn’t introduce any new role till 8 teams. LeSS is a
simple framework that exposes organization problems just like Scrum. Beyond 8 team
only role that get introduced is APO (Area Product Owner).
Empirical Process Control – Inspection and Adaption of the product, processes,
organizational design, and practices to craft a situational appropriate organization
based on Scrum, rather than following a detailed formula.
Transparency – Based on tangible “done” items, short cycles, working together,
common definitions, and driving out fear at workplace.
More with LeSS – 1. in empirical process control: more learning with less defined
processes. 2. In lean thinking: more value with less waste and overhead. 3. In scaling:
less roles, artifacts and special groups.
Whole-product focus – One product backlog, one product owner, one product
increment, one sprint regardless of number of team.

Customer-Centric – Identify values and waste in the eye of paying customer. Reduce the
cycle time from their prospective. Increase feedback loops with the real customer.
Continuous Improvement towards Perfection – Do I need to tell you? This is all about
Scrum I believe.
System Thinking – See, understand, and optimize the whole system and use causal-loop
modelling to explore system dynamics. Avoid local optimization.
Lean Thinking – Create an organizational system whose foundation is managers-as
teachers who apply and teach system thinking and lean thinking, manage to improve,
and who practice go see at gemba. Add the two pillars of respect for people and
continuous improvement. All towards to the goal of perfection.
Queuing Theory – One product backlog, one product owner, one product increment,
one sprint regardless of number of team.

Causal-loop modelling

Causal-loop modelling - Exercise
5 minutes discussion on what you wanted to improve in a product that you have
identified earlier.
10 minutes to draw causal-loop modelling showing Positive feedback, Negative
feedback, Balancing feedback, Reinforcing feedback and delay loops.

Lean Thinking

Lean Thinking - Exercise
Identify waste in your software product development process that you will prefer to
eliminate – 10 mins

Common Waste - Software Development
Waiting
Delay
Handoff
Partial done work
Task switching
Defects
Under-realize people's potential
Knowledge Scatter
Wishful thinking
Many more…..

LeSS Rules - Structure
• Structure the organization using real teams as the basic organizational building
block.
• Each team is (1) self-managing, (2) cross-functional, (3) co-located, and (4) long-
lived.
• The majority of the teams are customer-focused feature teams.
• ScrumMasters are responsible for a well-working LeSS adoption. Their focus is
towards the Teams, Product Owner, organization, and development practices. A
ScrumMaster does not focus on just one team but on the overall organizational
system.
• A ScrumMaster is a dedicated full-time role.
• One ScrumMaster can serve 1-3 teams.

LeSS Rules - Structure
• In LeSS, managers are optional, but if managers do exist their role is likely to
change. Their focus is the value-delivering capability of the product development
system rather than the specific scope of a product.
• Managers’ role is to improve the product development system by practicing Go See,
encouraging Stop & Fix, and “experiments over conformance”.
• For the product group, establish the complete LeSS structure “at the start”; this is
vital for a LeSS adoption.
• For the larger organization beyond the product group, adopt LeSS evolutionarily
using Go and See to create an organization where experimentation and
improvement is the norm.
More details

LeSS Rules - Product
• There is one Product Owner and one Product Backlog for the complete shippable
product.
• The Product Owner shouldn’t work alone on Product Backlog refinement; he is
supported by the multiple Teams working directly with customers/users and other
stakeholders.
• All prioritization goes through the Product Owner, but clarification is as much as
possible directly between the Teams and customer/users and other stakeholders.
• One shared Definition of Done for the whole product.

LeSS Rules - Product
• Each team can have their own expanded Definition of Done.
• The definition of product should be as broad and end-user/customer centric as is
practical. Over time, the definition of product might increase. Broader definitions
are preferred.
• The perfection goal is to improve the Definition of Done so that it results in a
shippable product each Sprint (or even more frequently).

LeSS Rules - Sprint
• There is one product-level Sprint, not a different Sprint for each Team. Each Team
starts and ends the Sprint at the same time. Each Sprint results in an integrated
whole product.
• Sprint Planning consists of two parts: Sprint Planning Part One is common for all
teams while Sprint Planning Part Two is usually done separately for each team.
• Sprint Planning Part One is attended by the Product Owner and Teams or Team
representatives. They together tentatively select the items that each team will work
on the next Sprint. The Teams identify opportunities to work together and final
questions are clarified.
• Each Team has their own Sprint Backlog.

LeSS Rules - Sprint
• Sprint Planning Part Two is for Teams to decide how they will do the selected
items. This usually involves design and the creation of their Sprint Backlogs. The
Team forecasts how many items they believe they can complete during the next
Sprint.
• Guidance: For some Teams, do it in a shared space to enhance coordination.
• Each Team has their own Daily Scrum.
• Cross-team coordination is decided by the teams. Prefer decentralized and informal
coordination over centralized coordination
• Guidance: Coordination via Open Space, joining other teams’ Daily Scrum, Scrum of Scrums,
multi-team workshops, or “simply” working in the same space, talking to each other, and using
visual management.

LeSS Rules - Sprint
• Product Backlog Refinement (PBR) is done per team for the items they are likely
going to do in the future. Do multi-team PBR to increase shared understanding and
exploiting coordination opportunities when having closely related items or a need
for broader input/learning
• Guidance: Hold an overall PBR with representatives before each team PBR to explore which
teams might work on which items, and to increase learning and alignment.
• There is one product Sprint Review; it is common for all teams. Ensure that enough
stakeholders join to contribute the information needed for effective inspection and
adaptation.
• Guidance: Use decentralized “diverge-merge” techniques for better feedback and less boring
meetings.

LeSS Rules - Sprint
• Each Team has their own Sprint Retrospective.
• An Overall Retrospective is held after the Team Retrospectives to discuss cross-team
and system-wide issues, and create improvement experiments. This is attended by
Product Owner, ScrumMasters, Team Representatives, and managers (if there are
any).

Large-Scale Scrum (LeSS) - Structure

Team
Self-
managing
Cross-
functional
Multi-skilled
workers
Long-lived
teams
Dedicated
Teams

Challenges with Component Team
Organization is practicing Scrum for last 3 years
Cost of Production was very high
 Single codebase but multiple integration points
 Lots of dependencies between team
 Many managers/leads to deal with dependencies
 Many product managers for same product from different region
 Difficult to prioritize PBIs
Cycle time was 6 weeks
 Small fake products
 Separate testing team

Feature Team

Technical Excellence

Technical Excellence
Why emergent Design is still a dream?
Why team avoid refactoring?
How do you review code? Still reading?
Is TDD takes more time?
Code is poor because ownership still with individual?
Collective code ownership improves code quality?
When to start writing Acceptance-test driven development?
Continuous Integration is not about just configuring tools but more about practice?
How to branch your code and when to branch out?

Emergent Design
Big Design Up Front (BDUF) Emergent Design
Think before your code Assume change is cheap
Support IT governance Handles ambiguity
Requires abstract thinking Requires details thinking
This is good but how to start?

Feature Team
Component team can help in improving technical practices?
Local optimization is good?
Feature team can take away specialization?
Feature team can lead to poor quality of code?

Exercise
What team type is more suitable for better code? Component or Feature team?
Discuss for 10 minutes and write your suggestions and let’s understand what others are
thinking.

Management

Role of Manager
• The role of middle management is to see the whole and build the capability of the
organization to build great products.
• He should help team and ScrumMaster with removing obstacles and making
improvements.
• He should teach the team how to improve and solve problems.
• He should Go See to understand what is really going on in the place of work and see
how he can best help the team improve their work.
• The role of senior management is perhaps changed less as they are still involved
with strategic decisions related to the company and its products.
• That said, also senior management’s role is teaching people—his subordinates—
how to teach people.

Self-Management – Types of teams

Structure after LeSS Adoption
Maximizing Value

Agile Manifesto
We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value
Individuals and Interactions Processes and Toolsover
Working Product Comprehensive Documentationover
Customer Collaboration Contract Negotiationover
Responding to Change Following a Planover
That is, while there is value in the items on the right, we value the items
on the left more

Agile Principles
I. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
II. Welcome changing requirements, even late in development. Agile processes harness change for the customer's
competitive advantage
III. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the
shorter timescale
IV. Business people and developers must work together daily throughout the project.
V. Build projects around motivated individuals. Give them the environment and support they need, and trust them to
get the job done.
VI. The most efficient and effective method of conveying information to and within a development team is face-to-
face conversation.
VII. Working software is the primary measure of progress.
VIII. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain
a constant pace indefinitely.
IX. Continuous attention to technical excellence and good design enhances agility.
X. Simplicity--the art of maximizing the amount of work not done--is essential.
XI. The best architectures, requirements, and designs emerge from self-organizing teams.
XII. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour
accordingly.
39

Building leaner pitches for your efficiency games
Contact Us: www.leanpitch.com | curators@leanpitch.com | #309, 4th B Cross, HRBR Layout, III Block Bangalore-560043 | +91-80-41614192
Agile
Transformation
Services
Agile Coaching &
Training
Collaboration Tool
Development
Services
We also offer
 Test Driven Development Methods
 Behavior Driven Development Methods
 Agile Project Management Using JIRA +
GreenHopper
 Collaboration Tools for Agile Teams
 Software Configuration Management for Agile
Teams using Perforce
Certified ScrumMaster
Certified Scrum Product Owner
Certified Scrum Developer
Need a
Coach, Call
us

LeSS - Moving beyond single team scrum

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (7)

Semelhante a LeSS - Moving beyond single team scrum

Semelhante a LeSS - Moving beyond single team scrum (20)

Mais de Naveen Kumar Singh

Mais de Naveen Kumar Singh (20)

Último

Último (20)

LeSS - Moving beyond single team scrum

Notas do Editor