<-- back to learn page

July 22, 2021

 - published by 

Robert Briese

Why you can’t compare LeSS to any scaling Framework like SAFe

Warum man LeSS nicht mit einem Skalierungsrahmen wie SAFe vergleichen kann

The important difference between a scaling and de-scaling framework

Willem-Jan Ageling recently published an excellent article titled "The Disastrous Impact Of Framing Scrum As An Incomplete Framework" in which he explains the negative impact of scaling frameworks on the agility introduced by Scrum:

"A scaling framework may seem like a solution to your problems, but it adds complexity and ends up making Scrum less effective." - W.J. Ageling

Unfortunately, he lists LeSS (Large-Scale Scrum) as one of the existing scaling frameworks, along with SAFe, Scrum@Scale, Nexus, and Scrum of Scrums. Unlike the others, he correctly explains Scrum of Scrum as an approach rather than a framework.

In this article, I want to clarify why LeSS should not be considered a scaling framework and why it cannot be compared to other scaling frameworks like the ones mentioned above.

How is LeSS different from common scaling frameworks?

Scaling frameworks, like SAFe or Scrum@Scale, guide organizations in applying concepts from Scrum, Lean, DevOps, or Design Thinking when working with multiple teams on one product. As correctly pointed out by Willem-Jan in his article, these frameworks introduce additional complexity to an already complex environment. LeSS has a fundamentally different approach. Instead of adding complexity, it aims to remove it, while still considering the organizational context around the Scrum Team.

Most scaling frameworks, like SAFe or Scrum@Scale, answer the question “How can we apply agile at scale in our big complex organization?” or like Bas Vodde (creator LeSS) once said, “How can we do what the organization already does in an agile way?’”.

Craig (Larmann — the other creator of LeSS) and Bas believe that traditional large groups are complicated not out of a real necessity, but because their organizational designs create an illusion that complex problems require complex solutions. They created LeSS to encourage organizations to answer another question instead: “How can we simplify an unnecessarily big and complex organization to be agile rather than to do agile?”. Precisely because LeSS promotes combatting complexity by reducing it, LeSS can be seen as a descaling framework rather than a scaling framework.

Like Scrum, LeSS is a lightweight framework for building products in complex environments. It provides a minimal set of rules that defines an organizational design aimed to maximize customer focus and lowering the cost of change (adaptability).

Why not just Scrum? Why do you need something else?

That’s right. Ideally, you don’t!

One of the most significant pieces of advice from the creators of Large-Scale Scrum is not to scale. The preferred setup of LeSS is one-team LeSS, which is Scrum. By now, fortunately, people understand that building products in complex environments is knowledge work, and you can’t fulfill twice as many requirements or cut the development effort in half by adding twice as many developers. However, there are still situations where products can’t be built by just one team. Contrary to popular belief, this is not necessary but often attempted all the same. Building a self-driving car including software and hardware could be a good example where it might be necessary that several hundred people band together.
As Willem-Jan mentioned in his article, Scrum provides a solution for that:

“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

While one might argue that this is enough guidance to do Scrum with multiple teams, it leaves many things open to interpretation (or experimentation). Are we doing one Sprint Review for all Scrum Teams or each Scrum Team individually? How about the Sprint Retrospectives, a pivotal part of enabling empirical process control? Is it better to have a Retrospective with all teams, or could each Scrum Team do their own separately? Here, LeSS provides guidance by offering strict rules: One Sprint Review for all Teams, Team Retrospectives, and an Overall Retrospective with team representatives from the different teams.

But besides mere process questions, there is an even more critical reason why Scrum alone will most likely not prosper in a large organization. Unless you are dealing with a 7–9 people startup, there is usually an organizational context around cross-functional, self-managing teams, and this context has complexity built-in. There are policies and structures like hiring, salaries, skills development, and team composition. All of these factors impact the culture and the way the team(s) work together.

Not understanding these effects can have a substantial negative impact on maximizing the value created by the product group, in complex environments.

In other words, introducing Scrum without taking environmental effects on the team(s) into account is just as ineffective as having a manager command a team to self-organize while not providing an enabling structure.

Photo by José Martín Ramírez Carrasco on Unsplash

But here comes the most problematic part. The Scrum Guide states:

“Scrum Teams are [self-managing and] cross-functional, meaning the members have all the skills necessary to create value each Sprint”. — Scrum Guide 2020

A single Scrum Team building a single product is implicitly a feature team, a team that delivers value in the eye of the paying customer each Sprint. In this context, the word “value” doesn’t have to be explicitly defined. For two teams working on the same product, a design choice occurs though: should they specialize in the business domain or in the technical domain?

The latter case could result in “value” being interpreted as an enhanced technical component. As a matter of fact, many teams in large development groups are specialized in the technology domain to the extent that they only work on specific technical components, becoming so-called component teams. This naturally leads to dependencies between the teams that need to be managed before a new product increment can be released.

In LeSS, there is no need to manage internal dependencies [, dependencies between the teams within a product group] — Large-Scale Scrum (More with LeSS), C. Larman, B. Vodde, Page 199

What LeSS does as a descaling framework is to slightly extend the Scrum rules in order to eliminate prominent “first-order” anti-adaptive elements like “component teams” from the example above. In LeSS, teams are not only cross-functional and self-managing, they are also cross-component feature teams which means that they can work on all parts of the product to create customer-centric features. In addition to this, LeSS provides principles, many guides, and hundreds(!) of experiments. The guides and experiments are non-prescriptive suggestions you can try when making decisions about how to build products in a complex environment. The principles, on the other hand, guide you in strengthening the foundations of an agile mindset in your organization.

How to reduce complexity with LeSS

While I completely agree with Willem-Jan that scaling frameworks add unnecessary complexity to the product development environment and should be avoided whenever possible, LeSS, when correctly understood, helps navigate complex environments, and challenges you to simplify and reduce complexity.

For example, LeSS recommends only one Product Backlog for the whole product, no matter how many teams work on it. It’s only when this single Product Backlog becomes unclear and unmanageable — this could happen if you are working with more than 30 teams — that there is the recommendation to create customer-centric views on this one Product Backlog (for example, with filters).

In doing so, you reduce complexity without requiring additional coordination between teams. In other words, the Area Product Backlogs are only filtered views of the one Product Backlog for all teams, not additional artifacts!

Thus, Area Product Owners are only needed when the product is so huge that to reduce complexity, it’s better to divide it into smaller products that can be viewed almost independently of each other. To be clear here, you will never have Area Product Owners in LeSS (Huge) if you don’t have more than eight teams, and even then LeSS advises against adopting LeSS Huge if the PO and the teams are not overwhelmed by the backlog.

I hope this article provides a better understanding of “Why LeSS?” and why, in some situations, you might need more than Scrum — but not a scaling framework — to build products in complex environments. In the article that will follow, I will explore in more detail what exactly you need besides Scrum to have an organization optimized for improved adaptability and customer value.

Robert Briese

Robert is one of 23 certified LeSS Trainers globally and one of the few with hands-on experience in LeSS and LeSS Huge. As a change agent for 15+ years, consulting and coaching, he has worked with over 30 companies, including DAX-listed global brands such as Adidas, BMW, BP, Dr. Oetker, Henkel, Hilti, Hugo Boss, SAP, Volkswagen, and ZF.

From 2015 to 2016 he led a LeSS adoption at a Global Player in the Software Industry, scaling development from 3 to 7 teams and coaching the development and the management team on how to lead a scaled agile organization. In 2018 he contributed to significant improvements in product delivery at one of the biggest LeSS Huge adoptions in the world at BMW AG. Working with over 30 teams, including large groups of over 400 employees, he led them to deliver bi-weekly product increments consisting of hardware and software.

Robert Briese - LeSS Trainer LinkedIn profile.
MockUp of the Lean Sherpas Newsletter on a Galaxy S21.

Join the LeSSons learned Newsletter!

Early access to new content, real-world examples, and funny stories!

More content you might like

Published on 
February 21, 2022
Post by 
Konstantin Ribel

Watch Konstantin Ribel discuss organizational behavior and performance and how LeSS can help manage organizational complexity. The orginal Video is viewable on the TC LeSS YouTube Channel. The original video can be seen on the TC LeSS YouTube Channel.

Published on 
February 21, 2022
Post by 
Konstantin Ribel

SummaryKonstantin Ribel and Craig Larman discuss how BMW's driverless driving team was built based on LeSS Huge, and the successes and problems encountered along the way.‍About the conferenceLeSS attempts to define what is just necessary for large-scale development. It avoids adding additional roles