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.
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.
Do you want to write for Serious Scrum or seriously discuss Scrum?
