Large-Scale Scrum (LeSS):

Hussien Bassal (180961), Ali issa(180289)

What is LeSS Framework:

LeSS is a framework for scaling scrum to multiple teams who work together on a
single product. It starts with a foundation of one scrum team and applies to
multiple teams who work together on one product.

The LeSS framework seeks to apply the principles and ideals of scrum in a large-
scale enterprise context as simply as possible through defined rules and guides. Its
simplicity has earned LeSS the label of being a “barely sufficient” framework, but
that’s not meant to cast it in a negative light.

LeSS Concepts:
LeSS defines 10 concepts for making use of the value, elements, and standard
cause of scrum throughout an enterprise. They assist create extra accountable
groups with extra purchaser attention and collaboration. Teams attention on
learning, transparency, and turning in purchaser-centric values that product groups
want to stay competitive and responsive. Here’s the whole list:
Large-Scale Scrum is Scrum
Large-scale Scrum, like classic Scrum, is a development framework where the details need to be
compiled by teams and evolved iteration by iteration, team by team. It reflects the pillar of Lean thinking
of continuous improvement. It is a collection of advice for controlling and adapting the product and the
process when there are many teams, at least two teams, and up to groups of 500 or 1000 people.

It is not about "New and Improved Scrum". LeSS is about applying the principles, elements and purpose
of Scrum in a large-scale context. Multi-team Scrum, not multiple Scrum teams.

Empirical process control

Inspection and adaptation of products, processes, organizational design and practices to create an
appropriate situational organization based on Scrum, rather than following a detailed formula. And
empirical control of the process demands and creates transparency.

Transparency
Inspection and adaptation of products, processes, organizational design and practices to create an
appropriate situational organization based on Scrum, rather than following a detailed formula. And
empirical control of the process demands and creates transparency.

More with less

In empirical process control: more learning with less defined processes.

In Lean Thinking: More value with less waste and overhead.

In scaling, more ownership, purpose, and joy with fewer roles, artifacts, and special groups.

Whole product focus

One Product Backlog, One Product Owner, One Product Increment Potentially Shipping, One Sprint,
whether there are 3 or 33 teams. Customers want the product, not a part.

Customer-centric
Identifies value and waste in the eyes of the paying customer.Reduce cycle time from their perspective.
Increase feedback loops with real customers Everyone understands how their work today relates directly
to paying customers.

Continuous improvement towards perfection

 Create and always distribute a product, free from defects, that completely thrills customers, improves the
environment and improves life. Experiment with humble and radical improvement with each Sprint
towards this goal.

Systems thinking
Identifies value and waste in the eyes of the paying customer.Reduce cycle time from their perspective.
Increase feedback loops with real customers Everyone understands how their work today relates directly
to paying customers.

Lean Thinking
Create and always distribute a product, free from defects, that completely thrills customers, improves the
environment and improves life. Experiment with humble and radical improvement with each Sprint
towards this goal.

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.

LeSS is a scaled version of a one-team Scrum, which focuses on directing the attention of all the
teams towards the product. It maintains basic practices of Scrum but has some basic differences
from regular Scrum meetings:

• There is a product backlog, but for the product and not for the team
• There is only one Definition of Done for all the teams
• All teams are in a common sprint to deliver a common shippable product

Each sprint starts with Sprint Planning1 wherein team members along with the product owner
divide their product backlog items. This is followed by Sprint Planning2 wherein the team
discusses their strategies for feature development. Each self-managing team develops the
features that they selected and coordinates with other teams for integrating their potentially
shippable product increment altogether.

In LeSS, coordination amongst the teams is the responsibility of the team itself and there are no
assigned coordinators for it. These teams coordinate through scrum meetings which include
product owners, scrum masters, and rotating representatives from each team.
Once there is an increment by teams, a shared session amongst the teams happens where teams
and customers explore what is done and discuss the next increment to develop. This session is
called the Sprint Review.

After this, each team retrospect its product increment, followed by an overall retrospection
session where teams, scrum masters, product owners, and managers determine any impediments
that affect the delivery of the product.

Depending upon how large the team is, there are two LeSS frameworks available for adoption:

1. LeSS: Up to eight teams (of eight members each)

2. LeSS Huge: Up to a few thousand members on one product

Frameworks:
Basic Less Framework Rules:
The LeSS framework applies to products with 2 to 8 teams.

LeSS Structure:
• Structure the organization using real teams as the basic building block of the organization
• Each team is (1) self-managed, (2) cross-functional, (3) co-located, and (4) long-lived.
• Most teams are customer-focused feature teams.
• Scrum Masters are responsible for making the adoption of LeSS work smoothly. They
focus on the teams, the Product Owner, the organization and the development practices.
A Scrum Master does not focus on a single team but on the entire organizational system.
• A Scrum Master is a dedicated full-time role.
• One Scrum Master can serve 1 to 3 teams.
• In LeSS, managers are optional, but if they exist, their role is subject to change. Their
focus shifts from managing the day-to-day product work to improving the value-
delivering capability of the product development system.
• The role of managers is to improve the product development system by practicing
encouraging Stop and Fix and experiencing compliance.
• For the product group, establish the complete LeSS structure at the start; this is vital for a
LeSS adoption.

Less Product
• There is a Product Owner and a Product Backlog for the entire deliverable product.
 • The Product Owner should not work alone on Product Backlog refinement; it is
supported by multiple teams that work directly with customers / users and other
stakeholders.
• All priorities go through the Product Owner, but clarification is done as much as possible
directly between Teams, customers / users and other stakeholders.
• The definition of the product should be as broad and end-user/customer centric as is
practical. Over time, the definition of the product may expand. Wider definitions are
preferred.
• A definition of Done for the entire product, common to all teams.
• Each team can have their own stronger Definition of Done by expanding the common one.
• The goal of perfection is to improve the Definition of Done so that it results in a product that can be
shipped every Sprint (or even more frequently).

LeSS Sprint
• There is a product-level Sprint, not a different Sprint for each team. Each team starts and ends the
Sprint at the same time. Each Sprint translates into a complete integrated product.
• Sprint planning has two parts: Sprint planning 1 is common to all teams while Sprint planning 2
is usually done separately for each team. Run multi-team Sprint Planning Two in a shared space
for closely related items.
• Sprint Planning One is followed by the Product Owner and the teams or team representatives.
Together, they tentatively select the items each team will work on in this Sprint. Teams identify
opportunities to work together and final questions are clarified.
• Each Team has their own Sprint Backlog.
• Sprint Planning Two allows teams to decide how to execute the selected items. This usually
involves the design and creation of their Sprint Backlogs.
• Each Team has their own Daily Scrum.
• The coordination of the cross-team is decided by the teams. Prefer decentralized and informal
coordination to centralized coordination. Emphasize Just Talk and informal networking through
coded communications, cross-team meetings, component mentors, travelers, scouts, and open
spaces.
• Product Backlog refinement (PBR) is preferably done with multiple teams to increase shared
learning and take advantage of coordination opportunities.
• There is a Sprint Review product; it is common to all the teams. Ensure that the appropriate
stakeholders come together to provide the information necessary for effective inspection and
adaptation.
• Each Team has their own Sprint Retrospective.
• A general retrospective is held after the team retrospectives to discuss cross-team and system-wide
issues and create improvement experiences. Participants include the Product Owner, Scrum Master,
team representatives and managers (if any).
Huge Less 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 the customer's point of view are
grouped into requirement areas.
• Each team specializes in an area of requirements. Teams stay in one area for a long
time. When there is more value in other areas, teams can change. Requirements
Domain
• Each Requirement Area has one Area Product Owner.
• Each Requirement Area has between “4-8” teams. Avoid violating this range.
• LeSS Huge adoptions, including structural changes, are done with an incremental
evolutionary approach.
• Remember every day: huge adoptions take months or years, endless patience and a
sense of humor.

Less Huge Product:

• A Product Owner is responsible for prioritizing a product and deciding which teams work
in which area.
 • Area Product Owners act as Product Owners towards their teams.
• There is a Product Backlog; each element it contains belongs exactly to a domain of
requirements.
• There is one Product Backlog area per requirement area. This backlog is conceptually
a more granular view of the single 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 further enable product-level adaptations.

Reference

• [By Written by Archna Oberoi]https://insights.daffodilsw.com/blog/safe-vs-less-vs-dad-

comparing-the-three-frameworks-to-scale-agile
• [By The LeSS Company B.V. All Rights Reserved] https://less.works/less/framework
• [By THOMAS E. OCONNOR]https://www.atlassian.com/agile/agile-at-scale/less