<-- back to learn page<-- zurück zur Contentseite

July 22, 2021

 - veröffentlicht von 

 - published by 

Robert Briese

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

The important difference between a scaling and de-scaling framework

Willem-Jan Ageling recently posted an excellent article called “The Disastrous Impact Of Framing Scrum As An Incomplete Framework” that 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 they add to the complexity and make Scrum less effective in the end.” — W.J. Ageling

Unfortunately, he listed LeSS (Large-Scale Scrum) as one of the existing scaling frameworks, next to SAFe, Scrum@Scale, Nexus, and Scrum of Scrums. Scrum of Scrum, in contrast to the others, he correctly explains it as an approach rather than a framework.

In this article, I would like to clarify why LeSS shouldn’t be seen as a scaling framework and why it can’t be compared to other scaling frameworks like those 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.

About Robert

Über Robert

Robert is one of 22 certified LeSS Trainers who are officially allowed to give a Certified Less Practitioner Course.

Robert Briese is a coach, consultant and trainer for agile and lean product development as well as the founder and managing director of Lean Sherpas GmbH. As one of only 22 certified Large-Scale Scrum (LeSS) trainers worldwide, he works with individuals, teams and organizations on the introduction of practices for agile and lean developments as well as the improvement of organizational agility through cultural change.

Robert Briese has worked with (real) startups (Penta), corporate start-ups (Ringier, Yello) and also large organizations (SAP, BMW, adidas) to create an organizational design and introduce practices that facilitate faster customer feedback, learning and a enable greater adaptability to change. He is a frequent speaker at conferences and regularly gives training in Large-Scale Scrum (LeSS).

Robert Briese ist Coach, Berater und Trainer für agile und schlanke Produktentwicklung sowie Gründer und Geschäftsführer der Lean Sherpas GmbH. Als einer von nur 22 zertifizierten Large-Scale Scrum (LeSS) Trainern weltweit arbeitet er mit Einzelpersonen, Teams und Organisationen an der Einführung von Praktiken für agile und schlanke Entwicklungen sowie der Verbesserung der organisatorischen Agilität durch Kulturwandel.

Robert Briese hat mit (echten) Startups (Penta), Corporate Start-ups (Ringier, Yello) und auch großen Organisationen (SAP, BMW, adidas) zusammengearbeitet, um ein Organisationsdesign zu erstellen und Praktiken einzuführen, die ein schnelleres Kundenfeedback, Lernen und a eine größere Anpassungsfähigkeit an Veränderungen ermöglichen. Er ist regelmäßiger Referent auf Konferenzen und gibt regelmäßig Schulungen zu Large-Scale Scrum (LeSS).

Robert Briese - LeSS Trainer LinkedIn profile.

Subscribe for fresh, free, future content 🌱

Contact Data
(* Mandatory fields)
Data protection declaration
Confirmation *
Thank you for subscribing!
You will hear from us shortly. If you have any additional questions in the meantime feel free to contact us at info@leansherpas.com
Oops! Something went wrong while submitting the form. Have you checked if you have filled in all the fields?

Mehr Beiträge die dir gefallen könnten

More content you might like

Published on 
September 21, 2021
Veröffentlicht von 
Daniel Räder & Robert Briese
UA056 - Scrum skalieren mit Large-Scale Scrum Unboxing Agile

Enjoy this great podcast by Robert Briese and Daniel Räder from Unboxing Agile! 🎶 You can listen to it anywhere you can find podcasts. 🌐 Click on here to find it on our website and go from beginner to winner and get one step closer to becoming "scaled agile" pro

Published on 
October 4, 2021
Veröffentlicht von 
Robert Briese
Remote Sprint Review in Large-Scale Scrum (LeSS)

In diesem Artikel bekommst du einen Überblick über den Zweck des Sprint Reviews in Scrum und erfährst mehr über ein reales Beispiel, wie ein modifiziertes Sprint Review in Large-Scale Scrum (LeSS) mit mehreren verteilten Teams gestaltet werden kann.

Published on 
July 22, 2021
Published by 
Robert Briese
Why you can’t compare LeSS to any scaling Framework like SAFe

In this article, Robert clarify's why LeSS shouldn’t be seen as a scaling framework and why it can’t be compared to any other scaling framework. LeSS has a fundamentally different approach. Instead of adding complexity, it aims to remove it.

Published on 
October 4, 2021
Published by 
Robert Briese
Remote Sprint Review in Large-Scale Scrum (LeSS)

In this article you will get an overview of the purpose of sprint reviews in Scrum and learn more about a real example of how a modified sprint review in Large-Scale Scrum (LeSS) can be designed with several distributed teams.

Published on 
July 22, 2021
Published by 
Robert Briese
Scaling Agility by Descaling Organizational Complexity

In this talk Robert will make the case that to achieve true agility an organization needs to descale the complexity of processes and roles. He will discuss the organizational design implications that Scrum (as an agile framework) creates both regarding structure and policies.