What is LeSS (Large-Scale Scrum)?

What is Large-Scale Scrum (LeSS)?

Large-Scale Scrum – abbreviated to LeSS – is a framework for agile product creation and helps organisations to become agile on a large scale. To do this, the framework offers

• principles,
• rules,
• guidelines and
• experiments.

Scrum is one of the most widely used agile frameworks because it focuses on self-managing teams using empirical process control (transparency, inspection and adaptation) to co-develop products with users or customers in short iterations. And of course, because it focuses on delivering the things that are most important from the customer’s perspective in short cycles and continuously learning how to build the right product the right way. Large-Scale Scrum tries to replicate this in a context outside of a team – an organisation – and focuses on creating simpler organisations that are optimised for adaptability with low change costs and deliver the highest customer value.

In other words, LeSS is a framework for reducing organisational complexity and being agile rather than doing agile.

LeSS is not a scaling framework

LeSS is often mentioned along with scaling frameworks such as SAFe (Scaled Agile Framework) or Scrum@Scale. Scaling frameworks give guidance to larger organisations on how to deploy Scrum at team level and manage the value stream for product delivery with many teams. They introduce many additional artefacts and roles (Agile Release Train, Product Increment Planning, Programme Backlog, Release Train Engineer, Solution Train Engineer, Executive MetaScrum Forum, Executive Action Team, etc.) to create a focus on prioritised business goals in a network of multiple Scrum teams. In doing so, they create an additional layer of complexity that destroys the agility created by Scrum, introduces handoffs and bottlenecks, and increases decision latency (time to make a decision).

LeSS aims to do the opposite: it answers the question of how to do Scrum with multiple teams, rather than having multiple Scrum teams and a whole layer of complexity around them to manage the teams’ value creation.

Why is Scrum not sufficient at the organisational level?

Scrum, as originally described in the Scrum Guide, is designed for a single Scrum Team and there is no guidance in the Scrum Guide, other than this paragraph, on how to work with multiple teams:

If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner. – Scrum Guide 2020

Companies adopting Scrum usually define their products around their existing teams and find a Product Owner who creates a Product Goal and a Product Backlog. Unfortunately, this leads to teams that are optimised for better output but not for better results because they lack key elements of Scrum (such as direct interaction with the customer/end user, frequent delivery of product increments that add value to the customer, etc.). In order to apply Scrum in large product development with multiple teams, the right organisational structure must be in place (i.e. appropriately structured teams and suitable guidelines).

The LeSS principles extend the Scrum principles (Empirical Process Control, Transparency, Customer Focus) with additional principles that are very obvious when Scrum is applied in one team, but not so obvious in multi-team product development. These principles are

• Whole Product Focus,
• More with LeSS,
• Queueing Theory,
• and Continuous Improvement towards Perfection.

Furthermore, with thinking tools like system thinking, it is possible to see the system dynamics and how local optimisation can lead to sub-optimisation at the system level. Lean thinking, for example, has had a major impact on agile software development because it challenged traditional management and processes in product development and can be used as a guide for creating the right organisational structures, leadership and rules for an agile organisation.

Where does LeSS come from?

LeSS was developed by Craig Larmann and Bas Vodde and first introduced in 2008 in the book “Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum”.¹ Since 2005, Bas and Craig have worked with many clients to apply product development at scale and have distilled their findings into a few rules to get started and use as a foundation, a moderate set of guides to apply the rules effectively, and many experiments that are highly situational and may work or should rather be avoided in a given context. Moreover, the principles mentioned above are at the heart of LeSS and influence the rules, guides and experiments.

A good way to look at LeSS is to visualise it in the LeSS big picture:

Two frameworks: LeSS & LeSS Huge

Large-Scale Scrum distinguishes between two frameworks: LeSS (for 2 to 8 teams) and LeSS Huge (for more than 8 teams). The number 8 is not a magic number and sometimes it is recommend to keep the smaller LeSS framework for more than 8 teams if possible, but there are also situations where LeSS Huge has to be used with less than 8 teams.

The reason for switching from LeSS to LeSS Huge can be one of the following:

1. The single Product Owner can no longer keep track of the whole product.
2. The Product Owner cannot balance an external and internal focus.
3. The Product Backlog is so large that it is difficult for one person to work on it.

Both frameworks have common elements: a Product Owner and a Product Backlog, a common Sprint for all teams, a deliverable product increment.

LeSS Huge introduces some additional rules (which are not needed for small teams), such as Area Product Owner and Area Product Backlog.

The LeSS Framework

The smaller LeSS framework is for one (and only one) Product Owner who owns the product, and who manages one Product Backlog worked on by the teams in one common Sprint, optimising for the whole product.

The LeSS framework elements are about the same as one-team Scrum:

• Roles² – One Product Owner, two to eight Teams, a Scrum Master for one to three Teams. The Teams are feature teams – true cross-functional and cross-component full-stack teams that work together in a shared code environment, each team doing everything to create a product increment.
• Artefacts – One potentially shippable product increment, one Product Backlog (for all teams), and a separate Sprint Backlog for each team.
• Events – One common Sprint for the whole product that includes all teams and ends in one potentially shippable product increment.

The LeSS Huge Framework

When working with more than 100 people on one product, divide-and-conquer seems unavoidable because of the complexity of so many requirements and people. Traditional large-scale development groups are usually divided by single-functional groups (analysis team, test team, etc.) or by technical component groups (frontend team, backend team, etc.). This organisational design yields slow inflexible development with

1. high level of waste (inventory, work-in-progress, handoff, information scatter, etc.),
2. long-delayed return-of-investment,
3. complex planning and coordination,
4. overhead management, and
5. week feedback and learning.

And it is organised inward around single skills, architecture, and management, rather than outward around customer value.

In LeSS Huge, the division is around major areas of customer concerns called Requirement Areas. The requirement areas consist of 4 to 8 teams, which are dynamic, i.e. they grow or shrink over time, with teams joining or leaving – most likely to or from another existing area.

Each Requirement Area works as a (smaller) LeSS implementation, each working in parallel in one overall Sprint.

As mentioned before, LeSS Huge extends the LeSS elements:

• Roles – Same as LeSS, plus two or more Area Product Owners, and four to eight Teams in each Requirement Areas. The one Product Owner (who focuses on overall product optimisation) and the several Area Product Owners form the Product Owner Team.
• Artefacts – Same as LeSS, plus a Requirement Area attribute in the one Product Backlog and thus an Area Product Backlog view for each area.
• Events – There is still only one common Sprint for the whole product that includes all teams and ends in one potentially shippable product increment.

What are the LeSS guides and experiments?

The LeSS principles should guide every decision and provide guidance to create an organisation that optimises its adaptability and works on the most important things from the customer’s perspective. The LeSS Framework and the LeSS Huge Framework provide the LeSS rules. In addition, there is a set of guides on how to apply these rules effectively as well as a huge list of experiments (over 600) that are usually very situational and may or may not be worth trying. The guides contain tips that have been identified based on years of experience with LeSS and are worth trying, such as the

• “Three Adoption Principles” or
• “Getting Started [with LeSS]”.

Examples of experiments are

• “Try… Joint Sprint Review bazaar”,
• “Avoid… Separate analysis or specialist groups”
• or “Avoid… Agile/lean transformations or change projects”.

Who can benefit from adopting LeSS and who should not bother?

Adopting LeSS is difficult, and as with any other framework or even tool, it is useful to first understand its purpose, features and benefits before making a decision on whether it will be helpful or not.

Here are some scenarios where LeSS (and LeSS Huge) will most likely not bring (much) benefit or cannot be adopted:

• Your main optimisation goal is speed to delivery, time to market, team-level efficiency gains, lead time improvements, or something similar.
• You are not able or willing to change organisational structures or policies.
• You are working on a contract basis, delivering a project with fixed scope, time and resources (e.g. a system upgrade project).
• You need accurate predictability of development forecasts.
• The majority of your product development team is located outside your organisation (e.g. third parties).

And here are some scenarios where LeSS (and LeSS Huge) could actually prove extremely helpful:

• Your optimisation goal is adaptability with low change costs and working on the most important issues from a business and customer perspective.
• You are developing a product in a complex environment that requires multiple teams.
• You want your team members to continuously develop the skills needed to create the elements that are most important from the customer’s perspective.

Impulse to discuss:

What additional differences do you see comparing LeSS and Scrum?

Notes:

[1] Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
[2] The Scrum Guide 2020 defines accountabilities instead of roles and thus emphasises the participants’ responsibility for results. Of course, in lived corporate practice, there are still roles.

Here you can learn more about Large-Scale Scrum.

Here you can find a nice video expaining LESS and the differences to Scrum.

LeSS coach wanted? Our recommendation: Robert Briese from Lean Sherpas.

Robert Briese is a coach, consultant and trainer in agile and lean product development and the founder and CEO of Lean Sherpas GmbH. As one of only 22 certified Large-Scale Scrum (LeSS) Trainers in the world he works with individuals, teams and organisations on adopting practices for agile and lean development as well as improving organisational agility through cultural change.

Here you will find additional information from our blog:

What does t2informatik actually do? One click and you'll know.