Different rules in LeSS and LeSS Huge

"We have 5 teams. We are doing LeSS, and we have 3 APOs (Area Product Owners)." Wait, this is NOT LeSS!

Motivated by this kind of common misunderstanding, I am writing this article to describes the different rules in LeSS and LeSS Huge, and why they are different.

LeSS vs. LeSS Huge

First, what is LeSS? I have to admit that the word LeSS is an overloaded term. It means several things. Let me try to clarify.

• LeSS as a system

I can't actually find a proper word to describe LeSS in general, including experiments, guides, rules and principles, as shown in the LeSS complete picture. I will just call it a system.

• LeSS as a framework

When we say that "LeSS is Scrum applied to many teams working together on one product", it probably refers to LeSS also as a framework, as Scrum is a framework. Then, LeSS framework is only part of LeSS system - the rules. What makes it more confusing is that when we say LeSS framework, it can again mean two different things.

1. LeSS framework as a whole, including both smaller LeSS and larger LeSS Huge frameworks
2. Only the smaller LeSS framework

These different meanings behind the word LeSS unnecessarily add the cognitive load for people learning about LeSS. I agree that we need to fix it, and will work on it further.

With the above clarification, we are in a better position to explain LeSS vs. LeSS Huge.

LeSS and LeSS Huge are smaller and larger frameworks respectively inside the LeSS system. The creation of LeSS frameworks was a response to novice practitioners in large-scale product development in need of something more specific than experiments to start their journey. This something became the rules in LeSS system and they form the two frameworks.

When we say that "this is or is NOT LeSS" or "we are or are NOT doing LeSS", we usually refer to the fact that we are or are NOT following the rules in the LeSS and LeSS Huge frameworks.

The larger LeSS Huge framework differs from the smaller LeSS framework in two significant ways. One is the introduction of RA (Requirement Area), and the other is using the evolutionary incremental approach in adoption. We will elaborate both.

1. Requirement Area

What are RAs? RAs are foremost area backlogs, which are subsets of the whole product backlog. Then, there is one APO and a few (usually 4-8) feature teams associated with a RA. You may learn more about RA from the following articles.

• Follow value in defining RAs
• Decouple Line Organization from Requirement Area

Why RAs in LeSS Huge? The introduction of RA is a response to those limits to one product backlog, especially the ones from PO. Please find more analysis from the following articles.

• Limits to one Product Backlog - 3
• Limits to one Product Backlog - 4

What is or is NOT LeSS?

On one hand,

• in the smaller large-scale context with 2-"8" teams, there is no RA, and all teams share one product backlog. This is LeSS!
• in the larger large-scale context with "8"+ teams, there are RAs - area backlogs, and a few teams share one area backlog. This is LeSS!

On the other hand,

• in the smaller large-scale context with 2-"8" teams, there are RAs - area backlogs, i.e. not all teams share one product backlog. This is NOT LeSS!
• in the larger large-scale context with "8"+ teams, there is no RA, i.e. all teams share one product backlog. This is NOT LeSS!

Objection! Isn't it great if all teams can share one product backlog even in the larger large-scale context with "8"+ teams? Yes, indeed. However, this is not following the rules in the LeSS Huge framework, thus NOT LeSS. Certainly, we can and should experiment on it!

2. Evolutionary incremental approach

What is evolutionary incremental approach in the larger LeSS Huge framework? This is in contrast to the all-at-once approach in the smaller LeSS framework.

LeSS rule: For the product group, establish the complete LeSS structure "at the start"; this is vital for a LeSS adoption.
LeSS Huge rule: LeSS Huge adoptions, including the structural changes, are done with an evolutionary incremental approach.

Why evolutionary incremental approach? LeSS adoption is not simply process change, but deep organizational change. Thus, the change could be overwhelming in the larger large-scale context. Therefore, an evolutionary incremental approach is prescribed for LeSS Huge adoption. Please find more analysis from the following articles.

• Parallel organizations
• Seeing system dynamics in organizational change: 6) the scope of structural change
• Seeing system dynamics in organizational change: 7) incremental structural change

What is or is NOT LeSS?

On one hand,

• in the smaller large-scale context with 2-"8" teams, we change the structure all at once. This is LeSS!
• in the larger large-scale context with "8"+ teams, we change the structure with an evolutionary incremental approach. This is LeSS!

On the other hand,

• in the smaller large-scale context with 2-"8" teams, we change the structure with an evolutionary incremental approach. This is NOT LeSS!
• in the larger large-scale context with "8"+ teams, we change the structure all at once. This is NOT LeSS!

Again, NOT LeSS simply means that we don't follow the rules in the LeSS and LeSS Huge frameworks. It is encouraged to experiment on different approaches than what is prescribed.

Should we care?

Should we care whether this is or is NOT LeSS? Yes and no.

Yes. We should learn about the rules and their differences, more importantly, the reasoning behind them. Breaking rules with proper understanding is experimental, while breaking rules without proper understanding is simply ignorant.

No. Rules are for novice practitioners, while experiments are at the heart of LeSS. We can turn those "NOT LeSS" cases into meaningful experiments.

1. In the smaller large-scale context, these are NOT LeSS: 1) RA, and 2) Evolutionary incremental approach. We can run the below experiments:

• gradually increase the number of feature teams, thus change the structure with evolutionary incremental approach.
• gradually decrease the number of backlogs, thus, still have multiple product backlogs (essentially RAs - area backlogs), until it is reduced to one product backlog eventually.

1. In the larger large-scale context, these are NOT LeSS: 1) No RA, and 2) all-at-once approach. We can run the below experiments:

• break the limits to one product backlog, and keep one (no RA) for 10-15 teams.
• change the structure all at once to avoid parallel organizations in a 150-person organization.

These are both NOT LeSS (about following rules) and LeSS (about running experiments). We understand rules by adopting frameworks, then, break rules by running experiments!