SlideShare a Scribd company logo

More with LeSS

Scrum Gathering Florida - More with LeSS -

1 of 4
Download to read offline
Large Scale Scrum(LeSS): More with LeSS
-by Ram Srinivasan
CST and Large Scale Scrum (LeSS) coach at InnovAgility.com
http://linkedin.com/in/ramvasan Twitter: @ramvasan Email: ram@InnovAgility.com
Resources and attributions: The contents of this handout are from http://less.works. Chapter 2 (free) of the new book “Large-
Scale Scrum: More with LeSS” and case studies are available at http://less.works. Also check
https://less.works/less/adoption/index.html for tips and hints on getting started
Key Recommendations: “After working for some years in the domain of large,
multisite and offshore development, we have distilled our experience and
advice down to the following: Don’t do it” - Craig Larman and Bas Vodde -
Scaling Lean and Agile Development (book 1)
Why LeSS?
Scaling Scrum starts with understanding standard one-team Scrum. From that
point, your organization must be able to understand and adopt LeSS, which
requires examining the purpose of one-team Scrum elements and figuring out
how to reach the same purpose while staying within the constraints of the
standard Scrum rules.
Agile development with Scrum requires a deep organizational change to
become agile. Therefore, neither Scrum nor LeSS should be considered
as merely a practice. Rather, they form an organizational design
framework.
Traditional sequential-lifecycle development doesn’t work well. It doesn’t work
well for either small or large product development efforts. Since 2001, Agile
development and Scrum in particular have revolutionized software development, but when asked how to apply Agile
development to large groups many people say “don’t” or “just use a small team” or “do Scrum at the team level.” None of those
answers is particularly useful, and while it is true that it is best to avoid adding people to your development effort, it is also true
that large scale product development isn’t going away so we need to discover ways to do it well.
Craig Larman and Bas Vodde have been involved in software development for a long time in all sorts of roles in traditional
sequential-lifecycle development, Unified Process, CMMI and others. None felt right. Scrum, on the other hand, felt right for
single-team development. So, the question then became “How can we scale Scrum without losing its strength?”
LeSS is Scrum Scaled
What is the strength of Scrum? That is not an easy question to answer. Of course, the concepts and principles behind Scrum,
such as Transparency, Empirical Process Control, Iterative development, and Self-managing teams are critical. Those principles
have been around for quite a while, however, so their inclusion does not explain Scrum’s success. After much discussion, we
have concluded:
Scrum hits the sweet spot between abstract principles and concrete practices. Thus, in order to keep Large-scale Scrum
as Scrum, we’ll need to find a similar balance, so that we will be able to say: For large groups, LeSS hits the sweet spot
between defined concrete elements and empirical process control.
This leads to some decisions:
• LeSS needs to be simple
• When scaling, there is a tendency to add roles, artifacts, processes, etc. This should be avoided so that a process can
empirically be created by the product group. Most other scaling frameworks fall into the trap of providing a defined process.
In LeSS we want to avoid that trap.
• LeSS is Scrum Scaled
• Rather than having Scrum as a building block for a scaled framework, we need to look at Scrum and for each element
ask “Why is it there?” followed by “If we have more than one team, how can we achieve the same purpose on a larger
scale?”
• Scaled up instead of tailored down
LeSS: The Complete Picture
Large Scale Scrum: More with LeSS by Ram Srinivasan - CST and Large Scale Scrum (LeSS) Coach at InnovAgility.com
http://linkedin.com/in/ramvasan http://www.slideshare.net/ramvasan Twitter: @ramvasan Email: ram@InnovAgility.com
• A common concept for process development is
to define a universal, overarching framework
and then contextually tailor it down. Tailoring
frameworks down does not work well
because people often assume everything is
needed in their particular context. This
assumption often leads to the creation of bloated
processes. LeSS should be kept to the
minimum. We acknowledge that scaling will
require “more” but instead of “polluting” LeSS
with optional elements, we have separated out a
different framework LeSS Huge.
LeSS Principles
1. Large-Scale Scrum is Scrum: It is not “new
and improved Scrum.” LeSS is about applying
the principles, elements, and purpose of Scrum
in a large-scale context. Multiple-team Scrum,
not multiple Scrum teams.
2. Empirical process control: Inspection and adaptation of the product, processes, organizational design, and practices to
craft a situational appropriate organization based on Scrum, rather than following a detailed formula. And empirical process
control requires and creates transparency.
3. Transparency: Based on tangible ‘done’ items, short cycles, working together, common definitions, and driving out fear in
the workplace.
4. 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, more ownership, purpose, and joy with less roles, artifacts, and special groups.
5. Whole-product focus: One Product Backlog, one Product Owner, one potentially shippable product increment, one Sprint—
regardless if there are 3 or 33 teams. Customers want the product, not a part.
6. Customer-centric: Identify value and waste in the eyes of the paying customer. Reduce the cycle time from their
perspective. Increase feedback loops with real customers. Everyone understands how their work today directly relates to
paying customers.
7. Continuous improvement towards perfection: Create and deliver a product all the time, without defects, that utterly
delights customers, improves the environment, and makes lives better. Do humble and radical improvement experiments
each Sprint towards that.
8. Systems thinking: See, understand, and optimize the whole system (not parts), and explore system dynamics. Avoid the
local and sub-optimizations of focusing on the ‘efficiency’ or ‘productivity’ of individuals and individual teams. Customers care
about the overall concept-to-cash cycle time and flow, not individual steps.
9. Lean thinking: Create an organizational system whose foundation is managers-as-teachers who apply and teach systems
thinking and lean thinking, manage to improve, and who practice Go See at the gemba. Add the two pillars of respect for
people and continuous improvement. All towards the goal of perfection
10. Queuing theory: Understand how systems with queues behave in the R&D domain, and apply those insights to managing
queue sizes, work-in-progress limits, multitasking, work packages, and variability.
Two Agile Scaling Frameworks
LeSS provides two different large-scale Scrum frameworks. Most of the scaling elements of LeSS are focused on directing the
attention of all of the teams onto the whole product instead of “my part.” Global and “end-to-end” focus are perhaps the dominant
problems to solve in scaling. The two frameworks – which are basically single-team Scrum scaled up – are:
• LeSS (“smaller” LeSS Framework): Up to eight teams (of eight people each).
• LeSS Huge: Up to a few thousand people on one product.
What does it mean to be the same as One-Team Scrum?
LeSS is a scaled up version of one-team Scrum, and it maintains many of the practices and ideas of one-team Scrum. In
LeSS all Teams are in a common Sprint to deliver a common shippable product, every Sprint. In LeSS, you will find:
• A single Product Backlog ( it’s for a product, not a team) • One Product Owner
• Many complete, cross-functional teams (with no single-specialist teams) • One Definition of Done for all teams
• One Product Increment at the end of each Sprint • One Sprint.
Large Scale Scrum: More with LeSS by Ram Srinivasan - CST and Large Scale Scrum (LeSS) Coach at InnovAgility.com
http://linkedin.com/in/ramvasan http://www.slideshare.net/ramvasan Twitter: @ramvasan Email: ram@InnovAgility.com
What’s Different in LeSS?
• Sprint Planning Part 1: In addition to the one Product Owner, it includes people (just representatives, if more than two or
three teams) from all teams. Let team members self-manage to decide their division of Product Backlog Items. Team members
also discuss opportunities to find shared work and cooperate, especially for related items.
• Sprint Planning Part 2: This is held independently (and usually in parallel) by each Team, though sometimes for simple
coordination and learning two or more Teams may hold it in the same room (in different areas).
• Daily Scrum: This is also held independently by each Team, though a member of Team A may observe Team B’s Daily
Scrum, to increase information sharing.
• Coordination: Teams or rotating representatives from each may hold an Open Space, Town Hall Meeting, or Scrum of
Scrums regularly to increase information sharing and coordination. In general, decentralized co-ordination techniques are
preferred over centralized co-ordination techniques. The most effective form of co-ordination technique between teams is
“just talk” and “co-ordinate-in-code”. Scrum-of-Scrums is the least recommended format of co-ordination.
• Overall PBR: There may be an optional and short overall Product Backlog Refinement (PBR) meeting that includes the one
Product Owner and people from all teams. The key purpose is to decide which teams are likely to implement which items and
therefore select those items for later in-depth single-team PBR. It is also a chance to increase alignment with the Product
Owner and all teams.
• Product Backlog Refinement: The only requirement in LeSS is single-team PBR, the same as in one-team Scrum. But a
common and useful variation is multi-team PBR, where two or more Teams are in the same room together, to increase learning
and coordination.
LeSS Rules (April 2016) (2)
The LeSS Rules are the definition of the LeSS Framework. They are things we consider a must. Why? This is explained in the
“Why LeSS?” section.
LeSS Framework Rules (“smaller” or “basic” LeSS Framework)
The (basic) LeSS framework applies to products with 2-“8” teams.
LeSS 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.
• Scrum Masters are responsible for a well-working LeSS adoption. Their focus is towards the Teams, Product Owner,
organization, and development practices. A Scrum Master does not focus on just one team but on the overall
organizational system.
• A Scrum Master is a dedicated full-time role.
• One Scrum Master can serve 1-3 teams.
• In LeSS, managers are optional, but if managers do exist their role is likely to change. Their focus shifts from managing
the day-to-day product work to improving the value-delivering capability of the product development system.
• 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.
LeSS 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.
• The definition of product should be as broad and end-user/customer centric as is practical. Over time, the definition of
product might expand. Broader definitions are preferred.
• One Definition of Done for the whole product common for all teams
• Each team can have their own stronger Definition of Done by expanding the common one.
• The perfection goal is to improve the Definition of Done so that it results in a shippable product each Sprint (or even
more frequently).
Large Scale Scrum: More with LeSS by Ram Srinivasan - CST and Large Scale Scrum (LeSS) Coach at InnovAgility.com
http://linkedin.com/in/ramvasan http://www.slideshare.net/ramvasan Twitter: @ramvasan Email: ram@InnovAgility.com
LeSS 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 One is common for all teams while Sprint Planning Two is usually
done separately for each team. Do multi-team Sprint Planning Two in a shared space for closely related items.
• Sprint Planning One is attended by the Product Owner and Teams or Team representatives. They together tentatively
select the items that each team will work on that Sprint.
The Teams identify opportunities to work together and final
questions are clarified.
• Each Team has their own Sprint Backlog.
• Sprint Planning Two is for Teams to decide how they will do the selected items.
This usually involves design and the
creation of their Sprint Backlogs.
• Each Team has their own Daily Scrum.
• Cross-team coordination is decided by the teams. Prefer decentralized and informal coordination over centralized
coordination. Emphasize Just Talk and informal networks via communicate in code, cross-team meetings, component
mentors, travellers, scouts, and open spaces.
• Product Backlog Refinement (PBR) is done per team for the items they are likely going to do in the future. Do multi-
team PBR and/or overall PBR to increase shared understanding and exploiting coordination opportunities when having
closely related items or a need for broader input/learning
• 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.
• 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, Scrum Masters, Team representatives, and
managers (if any).
LeSS Huge Framework Rules
LeSS Huge applies to products with “8+” teams. Avoid applying LeSS Huge for smaller product groups as it will result in more
overhead and local optimizations. All LeSS rules apply to LeSS Huge, unless otherwise stated. Each Requirement Area acts
like the basic LeSS framework.
LeSS Huge Structure
• Customer requirements that are strongly related from a customer perspective are grouped in Requirement Areas.
• Each Team specializes in one Requirement Area. Teams stay in one area for a long time. When there is more value in
other areas, teams might change Requirement Area
• Each Requirement Area has one Area Product Owner.
• Each Requirement Area has between “4-8” teams. Avoid violating this range.
• LeSS Huge adoptions, including the structural changes, are done with an evolutionary incremental approach.
• Remember each day: LeSS Huge adoptions take months or years, infinite patience, and sense of humor.
LeSS Huge Product
• Each Requirement Area has one Area Product Owner.
• One (overall) Product Owner is responsible for product-wide prioritization and deciding which teams work in which Area.
He works closely with Area Product Owners.
• Area Product Owners act as Product Owners towards their teams.
• There is one Product Backlog; every item in it belongs to exactly one Requirement Area.
• There is one Area Product Backlog per Requirement Area. This backlog is conceptually a more granular view onto the
one Product Backlog.
LeSS Huge Sprint
• There is one product-level Sprint, not a different Sprint for each Requirement Area. It ends in one integrated whole
product.
• The Product Owner and Area Product Owners synchronize frequently. Before Sprint Planning they ensure the Teams
work on the most valuable items.
After the Sprint Review, they enable product-level adaptations.

Recommended

Large Scale Scrum: More with LeSS
Large Scale Scrum: More with LeSSLarge Scale Scrum: More with LeSS
Large Scale Scrum: More with LeSSRam Srinivasan, CST
 
Self-Organization and Empowerment in Agile
Self-Organization and Empowerment in AgileSelf-Organization and Empowerment in Agile
Self-Organization and Empowerment in AgilebeLithe
 
System Thinking - Making sense before acting
System Thinking - Making sense before actingSystem Thinking - Making sense before acting
System Thinking - Making sense before actingAndre Jankowitz
 
Scrum: Leading a Self-Organizing Team
Scrum: Leading a Self-Organizing TeamScrum: Leading a Self-Organizing Team
Scrum: Leading a Self-Organizing TeamMike Cohn
 
Introduction to Systems Thinking
Introduction to Systems ThinkingIntroduction to Systems Thinking
Introduction to Systems ThinkingAcquate
 

More Related Content

What's hot

Leading Self Organizing Teams - NDC 2014
Leading Self Organizing Teams - NDC 2014Leading Self Organizing Teams - NDC 2014
Leading Self Organizing Teams - NDC 2014Mike Cohn
 
The lean thinking organization final
The lean thinking organization finalThe lean thinking organization final
The lean thinking organization finalLawell Kiing
 
DevOps: The Future is Already Here — It’s Just Unevenly Distributed
DevOps: The Future is Already Here — It’s Just Unevenly DistributedDevOps: The Future is Already Here — It’s Just Unevenly Distributed
DevOps: The Future is Already Here — It’s Just Unevenly Distributeddev2ops
 
Leading a Self-Organizing Team
 Leading a Self-Organizing Team Leading a Self-Organizing Team
Leading a Self-Organizing TeamMike Cohn
 
Self-Organization & Subtle Control: Friends or Enemies?
Self-Organization & Subtle Control: Friends or Enemies?Self-Organization & Subtle Control: Friends or Enemies?
Self-Organization & Subtle Control: Friends or Enemies?Mike Cohn
 
IMPLEMENTATION OF SCALED AGILE AND DEVOPS
IMPLEMENTATION OF SCALED AGILE AND DEVOPSIMPLEMENTATION OF SCALED AGILE AND DEVOPS
IMPLEMENTATION OF SCALED AGILE AND DEVOPSSQLI DIGITAL EXPERIENCE
 
Destroying DevOps Culture Anti-Patterns
Destroying DevOps Culture Anti-PatternsDestroying DevOps Culture Anti-Patterns
Destroying DevOps Culture Anti-PatternsTom Cudd
 
Stephanie Ryan
Stephanie RyanStephanie Ryan
Stephanie RyanMike Flynn
 
Incorporating Learning and Expected Cost of Change
Incorporating Learning and Expected Cost of ChangeIncorporating Learning and Expected Cost of Change
Incorporating Learning and Expected Cost of ChangeMike Cohn
 
DevOps Paradox: Going Faster Brings Higher Quality, Lower Costs, & Better Out...
DevOps Paradox: Going Faster Brings Higher Quality, Lower Costs, & Better Out...DevOps Paradox: Going Faster Brings Higher Quality, Lower Costs, & Better Out...
DevOps Paradox: Going Faster Brings Higher Quality, Lower Costs, & Better Out...dev2ops
 
Scaling Agile and Working with a Distributed Team
Scaling Agile and Working with a Distributed TeamScaling Agile and Working with a Distributed Team
Scaling Agile and Working with a Distributed TeamMike Cohn
 
Overcoming Waterfallacies & Agilephobias
Overcoming Waterfallacies & AgilephobiasOvercoming Waterfallacies & Agilephobias
Overcoming Waterfallacies & AgilephobiasMike Cohn
 
Salesforce Enterprise Agile - Agile Turkey Summit
Salesforce Enterprise Agile - Agile Turkey SummitSalesforce Enterprise Agile - Agile Turkey Summit
Salesforce Enterprise Agile - Agile Turkey SummitNicola Dourambeis
 
Lean sw development il tech-talks
Lean sw development   il tech-talksLean sw development   il tech-talks
Lean sw development il tech-talksElad Sofer
 

What's hot (20)

Leading Self Organizing Teams - NDC 2014
Leading Self Organizing Teams - NDC 2014Leading Self Organizing Teams - NDC 2014
Leading Self Organizing Teams - NDC 2014
 
The lean thinking organization final
The lean thinking organization finalThe lean thinking organization final
The lean thinking organization final
 
DevOps: The Future is Already Here — It’s Just Unevenly Distributed
DevOps: The Future is Already Here — It’s Just Unevenly DistributedDevOps: The Future is Already Here — It’s Just Unevenly Distributed
DevOps: The Future is Already Here — It’s Just Unevenly Distributed
 
Leading a Self-Organizing Team
 Leading a Self-Organizing Team Leading a Self-Organizing Team
Leading a Self-Organizing Team
 
Self-Organization & Subtle Control: Friends or Enemies?
Self-Organization & Subtle Control: Friends or Enemies?Self-Organization & Subtle Control: Friends or Enemies?
Self-Organization & Subtle Control: Friends or Enemies?
 
Overcoming More Impediments to Agile Transformation - Distributed Teams, Scal...
Overcoming More Impediments to Agile Transformation - Distributed Teams, Scal...Overcoming More Impediments to Agile Transformation - Distributed Teams, Scal...
Overcoming More Impediments to Agile Transformation - Distributed Teams, Scal...
 
IMPLEMENTATION OF SCALED AGILE AND DEVOPS
IMPLEMENTATION OF SCALED AGILE AND DEVOPSIMPLEMENTATION OF SCALED AGILE AND DEVOPS
IMPLEMENTATION OF SCALED AGILE AND DEVOPS
 
Lec 19
Lec 19Lec 19
Lec 19
 
Webinar: What You Can Do with Kanban
Webinar: What You Can Do with KanbanWebinar: What You Can Do with Kanban
Webinar: What You Can Do with Kanban
 
Destroying DevOps Culture Anti-Patterns
Destroying DevOps Culture Anti-PatternsDestroying DevOps Culture Anti-Patterns
Destroying DevOps Culture Anti-Patterns
 
Overcoming Impediments to Agile Transformation
Overcoming Impediments to Agile TransformationOvercoming Impediments to Agile Transformation
Overcoming Impediments to Agile Transformation
 
Overcoming Impediment to Agile Transformation
Overcoming Impediment to Agile TransformationOvercoming Impediment to Agile Transformation
Overcoming Impediment to Agile Transformation
 
Agile Retrospective & review
Agile Retrospective & review Agile Retrospective & review
Agile Retrospective & review
 
Stephanie Ryan
Stephanie RyanStephanie Ryan
Stephanie Ryan
 
Incorporating Learning and Expected Cost of Change
Incorporating Learning and Expected Cost of ChangeIncorporating Learning and Expected Cost of Change
Incorporating Learning and Expected Cost of Change
 
DevOps Paradox: Going Faster Brings Higher Quality, Lower Costs, & Better Out...
DevOps Paradox: Going Faster Brings Higher Quality, Lower Costs, & Better Out...DevOps Paradox: Going Faster Brings Higher Quality, Lower Costs, & Better Out...
DevOps Paradox: Going Faster Brings Higher Quality, Lower Costs, & Better Out...
 
Scaling Agile and Working with a Distributed Team
Scaling Agile and Working with a Distributed TeamScaling Agile and Working with a Distributed Team
Scaling Agile and Working with a Distributed Team
 
Overcoming Waterfallacies & Agilephobias
Overcoming Waterfallacies & AgilephobiasOvercoming Waterfallacies & Agilephobias
Overcoming Waterfallacies & Agilephobias
 
Salesforce Enterprise Agile - Agile Turkey Summit
Salesforce Enterprise Agile - Agile Turkey SummitSalesforce Enterprise Agile - Agile Turkey Summit
Salesforce Enterprise Agile - Agile Turkey Summit
 
Lean sw development il tech-talks
Lean sw development   il tech-talksLean sw development   il tech-talks
Lean sw development il tech-talks
 

Similar to More with LeSS

Enterprise agile Framework
Enterprise agile FrameworkEnterprise agile Framework
Enterprise agile FrameworkAgile Club
 
"Scrum master or Agile Master" - by Saikat Das @ Scaling Agile Institute
"Scrum master or Agile Master" - by Saikat Das @ Scaling Agile Institute"Scrum master or Agile Master" - by Saikat Das @ Scaling Agile Institute
"Scrum master or Agile Master" - by Saikat Das @ Scaling Agile InstituteInnovation Roots
 
Introduction to LeSS - Large Scale Scrum
Introduction to LeSS - Large Scale ScrumIntroduction to LeSS - Large Scale Scrum
Introduction to LeSS - Large Scale ScrumSrikanth Ramanujam
 
Changes Between Different Versions Scrum Guides
Changes Between Different Versions Scrum GuidesChanges Between Different Versions Scrum Guides
Changes Between Different Versions Scrum GuidesSoumya De
 
Susan Clarke - The practicalities of adopting scaled agile methodologies
Susan Clarke - The practicalities of adopting scaled agile methodologiesSusan Clarke - The practicalities of adopting scaled agile methodologies
Susan Clarke - The practicalities of adopting scaled agile methodologiesAssociation for Project Management
 
Scrum Guide & SAFe Agile booklet
Scrum Guide & SAFe Agile bookletScrum Guide & SAFe Agile booklet
Scrum Guide & SAFe Agile bookletSoumya De
 
10 differences between SAFe and LeSS
10 differences between SAFe and LeSS10 differences between SAFe and LeSS
10 differences between SAFe and LeSSStanislaw Matczak
 
The Large Scale Scrum Framework (LeSS) in a glance
The Large Scale Scrum Framework (LeSS) in a glanceThe Large Scale Scrum Framework (LeSS) in a glance
The Large Scale Scrum Framework (LeSS) in a glanceKendis.io
 
Scrum in IT Industry Part 2
Scrum in IT Industry Part 2Scrum in IT Industry Part 2
Scrum in IT Industry Part 2JayeshPatil149
 
202004-Scrum-Master-Certification-Training-Manual.pdf
202004-Scrum-Master-Certification-Training-Manual.pdf202004-Scrum-Master-Certification-Training-Manual.pdf
202004-Scrum-Master-Certification-Training-Manual.pdfDngoTrung1
 
Scrumprimer20
Scrumprimer20Scrumprimer20
Scrumprimer20msdn70
 
SDEC15: Help the Scrum Master *IS* the Impediment
SDEC15:  Help the Scrum Master *IS* the ImpedimentSDEC15:  Help the Scrum Master *IS* the Impediment
SDEC15: Help the Scrum Master *IS* the ImpedimentRyan Ripley
 
Scaled and Distributed Scrum: Key Considerations for Success
Scaled and Distributed Scrum: Key Considerations for SuccessScaled and Distributed Scrum: Key Considerations for Success
Scaled and Distributed Scrum: Key Considerations for SuccessCognizant
 

Similar to More with LeSS (20)

Enterprise agile Framework
Enterprise agile FrameworkEnterprise agile Framework
Enterprise agile Framework
 
Scaling scrum agile2010
Scaling scrum agile2010Scaling scrum agile2010
Scaling scrum agile2010
 
Agile at Scale
Agile at ScaleAgile at Scale
Agile at Scale
 
"Scrum master or Agile Master" - by Saikat Das @ Scaling Agile Institute
"Scrum master or Agile Master" - by Saikat Das @ Scaling Agile Institute"Scrum master or Agile Master" - by Saikat Das @ Scaling Agile Institute
"Scrum master or Agile Master" - by Saikat Das @ Scaling Agile Institute
 
Scrum master & agile master
Scrum master & agile masterScrum master & agile master
Scrum master & agile master
 
Introduction to LeSS - Large Scale Scrum
Introduction to LeSS - Large Scale ScrumIntroduction to LeSS - Large Scale Scrum
Introduction to LeSS - Large Scale Scrum
 
Changes Between Different Versions Scrum Guides
Changes Between Different Versions Scrum GuidesChanges Between Different Versions Scrum Guides
Changes Between Different Versions Scrum Guides
 
Susan Clarke - The practicalities of adopting scaled agile methodologies
Susan Clarke - The practicalities of adopting scaled agile methodologiesSusan Clarke - The practicalities of adopting scaled agile methodologies
Susan Clarke - The practicalities of adopting scaled agile methodologies
 
Scrum Guide & SAFe Agile booklet
Scrum Guide & SAFe Agile bookletScrum Guide & SAFe Agile booklet
Scrum Guide & SAFe Agile booklet
 
10 differences between SAFe and LeSS
10 differences between SAFe and LeSS10 differences between SAFe and LeSS
10 differences between SAFe and LeSS
 
The Large Scale Scrum Framework (LeSS) in a glance
The Large Scale Scrum Framework (LeSS) in a glanceThe Large Scale Scrum Framework (LeSS) in a glance
The Large Scale Scrum Framework (LeSS) in a glance
 
More with LeSS
More with LeSSMore with LeSS
More with LeSS
 
Approaches to scaling agile
Approaches to scaling agileApproaches to scaling agile
Approaches to scaling agile
 
Scrum in IT Industry Part 2
Scrum in IT Industry Part 2Scrum in IT Industry Part 2
Scrum in IT Industry Part 2
 
202004-Scrum-Master-Certification-Training-Manual.pdf
202004-Scrum-Master-Certification-Training-Manual.pdf202004-Scrum-Master-Certification-Training-Manual.pdf
202004-Scrum-Master-Certification-Training-Manual.pdf
 
Scrum Framework
Scrum FrameworkScrum Framework
Scrum Framework
 
Scrumprimer20
Scrumprimer20Scrumprimer20
Scrumprimer20
 
Scrumprimer20
Scrumprimer20Scrumprimer20
Scrumprimer20
 
SDEC15: Help the Scrum Master *IS* the Impediment
SDEC15:  Help the Scrum Master *IS* the ImpedimentSDEC15:  Help the Scrum Master *IS* the Impediment
SDEC15: Help the Scrum Master *IS* the Impediment
 
Scaled and Distributed Scrum: Key Considerations for Success
Scaled and Distributed Scrum: Key Considerations for SuccessScaled and Distributed Scrum: Key Considerations for Success
Scaled and Distributed Scrum: Key Considerations for Success
 

Recently uploaded

persdonal brand exploration- Karina Maurovich
persdonal brand exploration- Karina Maurovichpersdonal brand exploration- Karina Maurovich
persdonal brand exploration- Karina Maurovichkarinamaurovich05
 
Exploring the Dynamics of Leadership vs. Management.pdf
Exploring the Dynamics of Leadership vs. Management.pdfExploring the Dynamics of Leadership vs. Management.pdf
Exploring the Dynamics of Leadership vs. Management.pdfJasper Colin
 
Redefining Cost Innovation For Growth and Sustainablity
Redefining Cost Innovation For Growth and SustainablityRedefining Cost Innovation For Growth and Sustainablity
Redefining Cost Innovation For Growth and SustainablityInnomantra
 
A Comprehensive Guide To Relationship Mapping
A Comprehensive Guide To Relationship MappingA Comprehensive Guide To Relationship Mapping
A Comprehensive Guide To Relationship MappingCIToolkit
 
Building a Resilient Workforce - Career Conversations
Building a Resilient Workforce - Career ConversationsBuilding a Resilient Workforce - Career Conversations
Building a Resilient Workforce - Career Conversationsleonielam2
 
"Scaling Product Leadership with AI" by Ravi Padaki
"Scaling Product Leadership with AI" by Ravi Padaki"Scaling Product Leadership with AI" by Ravi Padaki
"Scaling Product Leadership with AI" by Ravi PadakiISPMAIndia
 
Unlocking optimal outcomes:Fostering Healthy Debate and Collaboration
Unlocking optimal outcomes:Fostering Healthy Debate and CollaborationUnlocking optimal outcomes:Fostering Healthy Debate and Collaboration
Unlocking optimal outcomes:Fostering Healthy Debate and CollaborationKim Antelo
 

Recently uploaded (7)

persdonal brand exploration- Karina Maurovich
persdonal brand exploration- Karina Maurovichpersdonal brand exploration- Karina Maurovich
persdonal brand exploration- Karina Maurovich
 
Exploring the Dynamics of Leadership vs. Management.pdf
Exploring the Dynamics of Leadership vs. Management.pdfExploring the Dynamics of Leadership vs. Management.pdf
Exploring the Dynamics of Leadership vs. Management.pdf
 
Redefining Cost Innovation For Growth and Sustainablity
Redefining Cost Innovation For Growth and SustainablityRedefining Cost Innovation For Growth and Sustainablity
Redefining Cost Innovation For Growth and Sustainablity
 
A Comprehensive Guide To Relationship Mapping
A Comprehensive Guide To Relationship MappingA Comprehensive Guide To Relationship Mapping
A Comprehensive Guide To Relationship Mapping
 
Building a Resilient Workforce - Career Conversations
Building a Resilient Workforce - Career ConversationsBuilding a Resilient Workforce - Career Conversations
Building a Resilient Workforce - Career Conversations
 
"Scaling Product Leadership with AI" by Ravi Padaki
"Scaling Product Leadership with AI" by Ravi Padaki"Scaling Product Leadership with AI" by Ravi Padaki
"Scaling Product Leadership with AI" by Ravi Padaki
 
Unlocking optimal outcomes:Fostering Healthy Debate and Collaboration
Unlocking optimal outcomes:Fostering Healthy Debate and CollaborationUnlocking optimal outcomes:Fostering Healthy Debate and Collaboration
Unlocking optimal outcomes:Fostering Healthy Debate and Collaboration
 

More with LeSS

  • 1. Large Scale Scrum(LeSS): More with LeSS -by Ram Srinivasan CST and Large Scale Scrum (LeSS) coach at InnovAgility.com http://linkedin.com/in/ramvasan Twitter: @ramvasan Email: ram@InnovAgility.com Resources and attributions: The contents of this handout are from http://less.works. Chapter 2 (free) of the new book “Large- Scale Scrum: More with LeSS” and case studies are available at http://less.works. Also check https://less.works/less/adoption/index.html for tips and hints on getting started Key Recommendations: “After working for some years in the domain of large, multisite and offshore development, we have distilled our experience and advice down to the following: Don’t do it” - Craig Larman and Bas Vodde - Scaling Lean and Agile Development (book 1) Why LeSS? Scaling Scrum starts with understanding standard one-team Scrum. From that point, your organization must be able to understand and adopt LeSS, which requires examining the purpose of one-team Scrum elements and figuring out how to reach the same purpose while staying within the constraints of the standard Scrum rules. Agile development with Scrum requires a deep organizational change to become agile. Therefore, neither Scrum nor LeSS should be considered as merely a practice. Rather, they form an organizational design framework. Traditional sequential-lifecycle development doesn’t work well. It doesn’t work well for either small or large product development efforts. Since 2001, Agile development and Scrum in particular have revolutionized software development, but when asked how to apply Agile development to large groups many people say “don’t” or “just use a small team” or “do Scrum at the team level.” None of those answers is particularly useful, and while it is true that it is best to avoid adding people to your development effort, it is also true that large scale product development isn’t going away so we need to discover ways to do it well. Craig Larman and Bas Vodde have been involved in software development for a long time in all sorts of roles in traditional sequential-lifecycle development, Unified Process, CMMI and others. None felt right. Scrum, on the other hand, felt right for single-team development. So, the question then became “How can we scale Scrum without losing its strength?” LeSS is Scrum Scaled What is the strength of Scrum? That is not an easy question to answer. Of course, the concepts and principles behind Scrum, such as Transparency, Empirical Process Control, Iterative development, and Self-managing teams are critical. Those principles have been around for quite a while, however, so their inclusion does not explain Scrum’s success. After much discussion, we have concluded: Scrum hits the sweet spot between abstract principles and concrete practices. Thus, in order to keep Large-scale Scrum as Scrum, we’ll need to find a similar balance, so that we will be able to say: For large groups, LeSS hits the sweet spot between defined concrete elements and empirical process control. This leads to some decisions: • LeSS needs to be simple • When scaling, there is a tendency to add roles, artifacts, processes, etc. This should be avoided so that a process can empirically be created by the product group. Most other scaling frameworks fall into the trap of providing a defined process. In LeSS we want to avoid that trap. • LeSS is Scrum Scaled • Rather than having Scrum as a building block for a scaled framework, we need to look at Scrum and for each element ask “Why is it there?” followed by “If we have more than one team, how can we achieve the same purpose on a larger scale?” • Scaled up instead of tailored down LeSS: The Complete Picture
  • 2. Large Scale Scrum: More with LeSS by Ram Srinivasan - CST and Large Scale Scrum (LeSS) Coach at InnovAgility.com http://linkedin.com/in/ramvasan http://www.slideshare.net/ramvasan Twitter: @ramvasan Email: ram@InnovAgility.com • A common concept for process development is to define a universal, overarching framework and then contextually tailor it down. Tailoring frameworks down does not work well because people often assume everything is needed in their particular context. This assumption often leads to the creation of bloated processes. LeSS should be kept to the minimum. We acknowledge that scaling will require “more” but instead of “polluting” LeSS with optional elements, we have separated out a different framework LeSS Huge. LeSS Principles 1. Large-Scale Scrum is Scrum: It is not “new and improved Scrum.” LeSS is about applying the principles, elements, and purpose of Scrum in a large-scale context. Multiple-team Scrum, not multiple Scrum teams. 2. Empirical process control: Inspection and adaptation of the product, processes, organizational design, and practices to craft a situational appropriate organization based on Scrum, rather than following a detailed formula. And empirical process control requires and creates transparency. 3. Transparency: Based on tangible ‘done’ items, short cycles, working together, common definitions, and driving out fear in the workplace. 4. 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, more ownership, purpose, and joy with less roles, artifacts, and special groups. 5. Whole-product focus: One Product Backlog, one Product Owner, one potentially shippable product increment, one Sprint— regardless if there are 3 or 33 teams. Customers want the product, not a part. 6. Customer-centric: Identify value and waste in the eyes of the paying customer. Reduce the cycle time from their perspective. Increase feedback loops with real customers. Everyone understands how their work today directly relates to paying customers. 7. Continuous improvement towards perfection: Create and deliver a product all the time, without defects, that utterly delights customers, improves the environment, and makes lives better. Do humble and radical improvement experiments each Sprint towards that. 8. Systems thinking: See, understand, and optimize the whole system (not parts), and explore system dynamics. Avoid the local and sub-optimizations of focusing on the ‘efficiency’ or ‘productivity’ of individuals and individual teams. Customers care about the overall concept-to-cash cycle time and flow, not individual steps. 9. Lean thinking: Create an organizational system whose foundation is managers-as-teachers who apply and teach systems thinking and lean thinking, manage to improve, and who practice Go See at the gemba. Add the two pillars of respect for people and continuous improvement. All towards the goal of perfection 10. Queuing theory: Understand how systems with queues behave in the R&D domain, and apply those insights to managing queue sizes, work-in-progress limits, multitasking, work packages, and variability. Two Agile Scaling Frameworks LeSS provides two different large-scale Scrum frameworks. Most of the scaling elements of LeSS are focused on directing the attention of all of the teams onto the whole product instead of “my part.” Global and “end-to-end” focus are perhaps the dominant problems to solve in scaling. The two frameworks – which are basically single-team Scrum scaled up – are: • LeSS (“smaller” LeSS Framework): Up to eight teams (of eight people each). • LeSS Huge: Up to a few thousand people on one product. What does it mean to be the same as One-Team Scrum? LeSS is a scaled up version of one-team Scrum, and it maintains many of the practices and ideas of one-team Scrum. In LeSS all Teams are in a common Sprint to deliver a common shippable product, every Sprint. In LeSS, you will find: • A single Product Backlog ( it’s for a product, not a team) • One Product Owner • Many complete, cross-functional teams (with no single-specialist teams) • One Definition of Done for all teams • One Product Increment at the end of each Sprint • One Sprint.
  • 3. Large Scale Scrum: More with LeSS by Ram Srinivasan - CST and Large Scale Scrum (LeSS) Coach at InnovAgility.com http://linkedin.com/in/ramvasan http://www.slideshare.net/ramvasan Twitter: @ramvasan Email: ram@InnovAgility.com What’s Different in LeSS? • Sprint Planning Part 1: In addition to the one Product Owner, it includes people (just representatives, if more than two or three teams) from all teams. Let team members self-manage to decide their division of Product Backlog Items. Team members also discuss opportunities to find shared work and cooperate, especially for related items. • Sprint Planning Part 2: This is held independently (and usually in parallel) by each Team, though sometimes for simple coordination and learning two or more Teams may hold it in the same room (in different areas). • Daily Scrum: This is also held independently by each Team, though a member of Team A may observe Team B’s Daily Scrum, to increase information sharing. • Coordination: Teams or rotating representatives from each may hold an Open Space, Town Hall Meeting, or Scrum of Scrums regularly to increase information sharing and coordination. In general, decentralized co-ordination techniques are preferred over centralized co-ordination techniques. The most effective form of co-ordination technique between teams is “just talk” and “co-ordinate-in-code”. Scrum-of-Scrums is the least recommended format of co-ordination. • Overall PBR: There may be an optional and short overall Product Backlog Refinement (PBR) meeting that includes the one Product Owner and people from all teams. The key purpose is to decide which teams are likely to implement which items and therefore select those items for later in-depth single-team PBR. It is also a chance to increase alignment with the Product Owner and all teams. • Product Backlog Refinement: The only requirement in LeSS is single-team PBR, the same as in one-team Scrum. But a common and useful variation is multi-team PBR, where two or more Teams are in the same room together, to increase learning and coordination. LeSS Rules (April 2016) (2) The LeSS Rules are the definition of the LeSS Framework. They are things we consider a must. Why? This is explained in the “Why LeSS?” section. LeSS Framework Rules (“smaller” or “basic” LeSS Framework) The (basic) LeSS framework applies to products with 2-“8” teams. LeSS 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. • Scrum Masters are responsible for a well-working LeSS adoption. Their focus is towards the Teams, Product Owner, organization, and development practices. A Scrum Master does not focus on just one team but on the overall organizational system. • A Scrum Master is a dedicated full-time role. • One Scrum Master can serve 1-3 teams. • In LeSS, managers are optional, but if managers do exist their role is likely to change. Their focus shifts from managing the day-to-day product work to improving the value-delivering capability of the product development system. • 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. LeSS 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. • The definition of product should be as broad and end-user/customer centric as is practical. Over time, the definition of product might expand. Broader definitions are preferred. • One Definition of Done for the whole product common for all teams • Each team can have their own stronger Definition of Done by expanding the common one. • The perfection goal is to improve the Definition of Done so that it results in a shippable product each Sprint (or even more frequently).
  • 4. Large Scale Scrum: More with LeSS by Ram Srinivasan - CST and Large Scale Scrum (LeSS) Coach at InnovAgility.com http://linkedin.com/in/ramvasan http://www.slideshare.net/ramvasan Twitter: @ramvasan Email: ram@InnovAgility.com LeSS 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 One is common for all teams while Sprint Planning Two is usually done separately for each team. Do multi-team Sprint Planning Two in a shared space for closely related items. • Sprint Planning One is attended by the Product Owner and Teams or Team representatives. They together tentatively select the items that each team will work on that Sprint.
The Teams identify opportunities to work together and final questions are clarified. • Each Team has their own Sprint Backlog. • Sprint Planning Two is for Teams to decide how they will do the selected items.
This usually involves design and the creation of their Sprint Backlogs. • Each Team has their own Daily Scrum. • Cross-team coordination is decided by the teams. Prefer decentralized and informal coordination over centralized coordination. Emphasize Just Talk and informal networks via communicate in code, cross-team meetings, component mentors, travellers, scouts, and open spaces. • Product Backlog Refinement (PBR) is done per team for the items they are likely going to do in the future. Do multi- team PBR and/or overall PBR to increase shared understanding and exploiting coordination opportunities when having closely related items or a need for broader input/learning • 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. • 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, Scrum Masters, Team representatives, and managers (if any). LeSS Huge Framework Rules LeSS Huge applies to products with “8+” teams. Avoid applying LeSS Huge for smaller product groups as it will result in more overhead and local optimizations. All LeSS rules apply to LeSS Huge, unless otherwise stated. Each Requirement Area acts like the basic LeSS framework. LeSS Huge Structure • Customer requirements that are strongly related from a customer perspective are grouped in Requirement Areas. • Each Team specializes in one Requirement Area. Teams stay in one area for a long time. When there is more value in other areas, teams might change Requirement Area • Each Requirement Area has one Area Product Owner. • Each Requirement Area has between “4-8” teams. Avoid violating this range. • LeSS Huge adoptions, including the structural changes, are done with an evolutionary incremental approach. • Remember each day: LeSS Huge adoptions take months or years, infinite patience, and sense of humor. LeSS Huge Product • Each Requirement Area has one Area Product Owner. • One (overall) Product Owner is responsible for product-wide prioritization and deciding which teams work in which Area. He works closely with Area Product Owners. • Area Product Owners act as Product Owners towards their teams. • There is one Product Backlog; every item in it belongs to exactly one Requirement Area. • There is one Area Product Backlog per Requirement Area. This backlog is conceptually a more granular view onto the one Product Backlog. LeSS Huge Sprint • There is one product-level Sprint, not a different Sprint for each Requirement Area. It ends in one integrated whole product. • The Product Owner and Area Product Owners synchronize frequently. Before Sprint Planning they ensure the Teams work on the most valuable items.
After the Sprint Review, they enable product-level adaptations.