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.
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).
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.
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.
Willem-Jan Ageling hat kürzlich einen ausgezeichneten Artikel mit dem Titel "The Disastrous Impact Of Framing Scrum As An Incomplete Framework" veröffentlicht, der die negativen Auswirkungen von skalierenden Frameworks auf die von Scrum eingeführte Agilität erläutert:
"Ein Skalierungs-Framework mag wie eine Lösung für Ihre Probleme erscheinen, aber sie erhöhen die Komplexität und machen Scrum am Ende weniger effektiv." - W.J. Ageling
Leider führt er LeSS (Large-Scale Scrum) als eines der bestehenden Skalierungs-Frameworks auf, neben SAFe, Scrum@Scale, Nexus und Scrum of Scrums. Scrum of Scrum bezeichnet er im Gegensatz zu den anderen richtigerweise als einen Ansatz und nicht als ein Framework.
In diesem Artikel möchte ich verdeutlichen, warum LeSS nicht als Skalierungsframework gesehen werden sollte und warum es nicht mit anderen Skalierungsframeworks wie den oben genannten verglichen werden kann.
Skalierungs-Frameworks wie SAFe oder Scrum@Scale leiten Organisationen bei der Anwendung von Konzepten aus Scrum, Lean, DevOps oder Design Thinking an, wenn sie mit mehreren Teams an einem Produkt arbeiten. Wie Willem-Jan in seinem Artikel richtig bemerkt, führen diese Frameworks zusätzliche Komplexität in eine bereits komplexe Umgebung ein. LeSS hat einen grundlegend anderen Ansatz. Anstatt Komplexität hinzuzufügen, zielt es darauf ab, sie zu beseitigen, wobei der organisatorische Kontext um das Scrum-Team herum weiterhin berücksichtigt wird.
Die meisten Skalierungs-Frameworks, wie SAFe oder Scrum@Scale, beantworten die Frage "Wie können wir Agile in unserer großen, komplexen Organisation in großem Maßstab anwenden?" oder wie Bas Vodde (Schöpfer von LeSS) einmal sagte: "Wie können wir das, was die Organisation bereits tut, auf agile Weise tun?".
Craig (Larmann - der andere Schöpfer von LeSS) und Bas sind der Meinung, dass herkömmliche große Gruppen nicht aus einer wirklichen Notwendigkeit heraus kompliziert sind, sondern weil ihr Organisationsdesign die Illusion erzeugt, dass komplexe Probleme komplexe Lösungen erfordern. Sie schufen LeSS, um Organisationen zu ermutigen, stattdessen eine andere Frage zu beantworten: "Wie können wir eine unnötig große und komplexe Organisation vereinfachen, um agil zu sein und nicht, um agil zu arbeiten?". Gerade weil LeSS die Bekämpfung von Komplexität durch deren Reduktion fördert, kann LeSS eher als ein Descaling- denn als ein Scaling-Framework betrachtet werden.
Wie Scrum ist LeSS ein leichtgewichtiges Framework für die Entwicklung von Produkten in komplexen Umgebungen. Es bietet ein minimales Regelwerk, das ein Organisationsdesign definiert, das darauf abzielt, die Kundenorientierung zu maximieren und die Kosten für Veränderungen (Anpassungsfähigkeit) zu senken.
Das ist richtig. Idealerweise braucht man das nicht!
Einer der wichtigsten Ratschläge der Erfinder von Large-Scale Scrum ist, nicht zu skalieren. Der bevorzugte Aufbau von LeSS ist LeSS mit einem Team, also Scrum. Glücklicherweise haben die Menschen inzwischen verstanden, dass die Entwicklung von Produkten in komplexen Umgebungen Wissensarbeit ist, und man kann nicht doppelt so viele Anforderungen erfüllen oder den Entwicklungsaufwand halbieren, indem man doppelt so viele Entwickler hinzufügt. Es gibt jedoch immer noch Situationen, in denen Produkte nicht von nur einem Team entwickelt werden können. Entgegen der landläufigen Meinung ist dies zwar nicht notwendig, wird aber dennoch oft versucht. Der Bau eines selbstfahrenden Autos, einschließlich Software und Hardware, könnte ein gutes Beispiel dafür sein, dass es notwendig sein könnte, dass sich mehrere hundert Menschen zusammenschließen.
Wie Willem-Jan in seinem Artikel erwähnt, bietet Scrum dafür eine Lösung:
"Wenn Scrum-Teams zu groß werden, sollten sie sich in mehrere zusammenhängende Scrum-Teams umorganisieren, die sich alle auf dasselbe Produkt konzentrieren. Daher sollten sie das gleiche Produktziel, das gleiche Product Backlog und den gleichen Product Owner haben." - Scrum Guide 2020
Man könnte zwar argumentieren, dass dies eine ausreichende Anleitung für die Durchführung von Scrum mit mehreren Teams ist, aber es lässt viele Dinge für die Interpretation (oder das Experimentieren) offen. Führen wir ein Sprint Review für alle Scrum Teams oder für jedes Scrum Team einzeln durch? Wie sieht es mit den Sprint-Retrospektiven aus, die ein zentraler Bestandteil der empirischen Prozesskontrolle sind? Ist es besser, eine Retrospektive mit allen Teams durchzuführen, oder kann jedes Scrum Team seine eigene Retrospektive separat durchführen? Hier bietet LeSS eine Orientierung, indem es strenge Regeln vorgibt: Ein Sprint-Review für alle Teams, Team-Retrospektiven und eine Gesamt-Retrospektive mit Vertretern aus den verschiedenen Teams.
Doch neben den reinen Prozessfragen gibt es einen noch wichtigeren Grund, warum Scrum allein in einer großen Organisation höchstwahrscheinlich nicht erfolgreich sein wird. Sofern es sich nicht um ein Startup mit 7-9 Mitarbeitern handelt, gibt es in der Regel einen organisatorischen Kontext um funktionsübergreifende, selbstverwaltende Teams, und dieser Kontext hat Komplexität eingebaut. Es gibt Richtlinien und Strukturen wie Einstellung, Gehälter, Kompetenzentwicklung und Teamzusammensetzung. All diese Faktoren wirken sich auf die Kultur und die Art und Weise aus, wie die Teams zusammenarbeiten.
Mit anderen Worten: Scrum einzuführen, ohne die Auswirkungen der Umgebung auf das Team zu berücksichtigen, ist genauso ineffektiv, wie wenn ein Manager einem Team befiehlt, sich selbst zu organisieren, ohne eine entsprechende Struktur zu schaffen.
Aber jetzt kommt der problematischste Teil. Im Scrum-Leitfaden heißt es:
"Scrum-Teams sind [selbstverwaltend und] funktionsübergreifend, d.h. die Mitglieder haben alle Fähigkeiten, die notwendig sind, um in jedem Sprint Wert zu schaffen". - Scrum-Leitfaden 2020
Ein einzelnes Scrum Team, das ein einzelnes Produkt entwickelt, ist implizit ein Feature Team, ein Team, das in jedem Sprint Wert im Sinne des zahlenden Kunden liefert. In diesem Zusammenhang muss das Wort "Wert" nicht explizit definiert werden. Bei zwei Teams, die an demselben Produkt arbeiten, stellt sich jedoch eine Design-Entscheidung: Sollen sie sich auf den geschäftlichen oder den technischen Bereich spezialisieren?
Im letzteren Fall könnte der "Wert" als eine erweiterte technische Komponente interpretiert werden. Tatsächlich sind viele Teams in großen Entwicklungskonzernen so weit auf den Technologiebereich spezialisiert, dass sie nur an bestimmten technischen Komponenten arbeiten und zu so genannten Komponententeams werden. Dies führt natürlich zu Abhängigkeiten zwischen den Teams, die verwaltet werden müssen, bevor ein neues Produktinkrement freigegeben werden kann.
In LeSS müssen keine internen Abhängigkeiten verwaltet werden [, Abhängigkeiten zwischen den Teams innerhalb einer Produktgruppe] - Large-Scale Scrum (More with LeSS), C. Larman, B. Vodde, Seite 199
LeSS erweitert die Scrum-Regeln geringfügig, um prominente anti-adaptive Elemente "erster Ordnung" wie "Komponententeams" aus dem obigen Beispiel zu eliminieren. In LeSS sind die Teams nicht nur funktionsübergreifend und selbstverwaltend, sondern auch komponentenübergreifende Feature-Teams, was bedeutet, dass sie an allen Teilen des Produkts arbeiten können, um kundenorientierte Features zu erstellen. Darüber hinaus bietet LeSS Prinzipien, viele Leitfäden und Hunderte(!) von Experimenten. Bei den Leitfäden und Experimenten handelt es sich um nicht präskriptive Vorschläge, die Sie ausprobieren können, wenn Sie Entscheidungen darüber treffen müssen, wie Sie Produkte in einer komplexen Umgebung entwickeln. Die Prinzipien hingegen helfen Ihnen, die Grundlagen einer agilen Denkweise in Ihrer Organisation zu stärken.
Ich stimme Willem-Jan zwar vollkommen zu, dass Skalierungsframeworks die Produktentwicklungsumgebung unnötig komplex machen und wann immer möglich vermieden werden sollten, aber LeSS hilft, wenn es richtig verstanden wird, sich in komplexen Umgebungen zurechtzufinden, und fordert Sie auf, die Komplexität zu vereinfachen und zu reduzieren.
LeSS empfiehlt zum Beispiel nur ein Product Backlog für das gesamte Produkt, egal wie viele Teams daran arbeiten. Erst wenn dieses eine Product Backlog unübersichtlich und unüberschaubar wird - das kann passieren, wenn Sie mit mehr als 30 Teams arbeiten - wird empfohlen, kundenorientierte Sichten auf dieses eine Product Backlog zu erstellen (z. B. mit Filtern).
Auf diese Weise reduzieren Sie die Komplexität, ohne dass eine zusätzliche Koordination zwischen den Teams erforderlich ist. Mit anderen Worten: Die Area Product Backlogs sind nur gefilterte Sichten auf das eine Product Backlog für alle Teams, keine zusätzlichen Artefakte!
Area Product Owner werden also nur benötigt, wenn das Produkt so groß ist, dass es zur Reduzierung der Komplexität besser ist, es in kleinere Produkte aufzuteilen, die fast unabhängig voneinander betrachtet werden können. Um das klarzustellen: Sie werden in LeSS (Huge) niemals Area Product Owner haben, wenn Sie nicht mehr als acht Teams haben, und selbst dann rät LeSS davon ab, LeSS Huge einzuführen, wenn der PO und die Teams nicht vom Backlog überwältigt werden.
Ich hoffe, dass dieser Artikel zu einem besseren Verständnis der Frage "Warum LeSS?" beiträgt und warum man in manchen Situationen mehr als Scrum - aber kein Skalierungs-Framework - braucht, um Produkte in komplexen Umgebungen zu entwickeln. In dem folgenden Artikel werde ich näher darauf eingehen, was genau Sie neben Scrum benötigen, um eine Organisation zu haben, die für eine verbesserte Anpassungsfähigkeit und einen höheren Kundennutzen optimiert ist.
Robert is the CEO of Lean Sherpas and one of 25 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 ist der CEO von Lean Sherpas und einer von weltweit 25 zertifizierten LeSS-Trainern und hat praktische Erfahrung sowohl mit LeSS als auch mit LeSS Huge. Als agiler Berater und Coach hat er in den letzten 20 Jahren mit über 30 Unternehmen zusammengearbeitet, darunter DAX-notierte Weltmarken wie Adidas, BMW, BP, Dr. Oetker, Henkel, Hilti, Hugo Boss, SAP, Volkswagen und ZF.
Von 2015 bis 2016 leitete er eine LeSS-Einführung bei einem Global Player in der Softwarebranche, skalierte dabei die Entwicklung von 3 auf 7 Teams und coachte das Entwicklungs- und Managementteam bei der Führung einer skalierten agilen Organisation. Im Jahr 2018 trug er bei einer der weltweit größten LeSS-Huge-Implementierungen bei der BMW AG zu signifikanten Verbesserungen in der Produktentwicklung und -auslieferung bei. In Zusammenarbeit mit über 30 Teams und mehr als 400 Mitarbeitern führte er sie dazu, alle zwei Wochen Produktinkremente, bestehend aus Hardware und Software, zu liefern.
Konstantin 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
Konstantin Ribel und Craig Larman erörtern, wie das BMW-Team für fahrerloses Fahren auf der Grundlage von LeSS Huge aufgebaut wurde und welche Erfolge und Probleme auf dem Weg dorthin aufgetreten sind.Über die KonferenzLeSS versucht, das für eine groß angelegte Entwicklung gerade noch Notwendige zu definieren. Es vermeidet das Hinzufügen von zusätzlichen Rollen, Artefakten oder Prozessen, da es die Nachteile dieser Zusätze erkennt.Sehen Sie das Original hier -> www.infoq.com
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.
Sehen Sie, wie Konstantin Ribel über organisatorisches Verhalten und Leistung spricht und wie LeSS helfen kann, die organisatorische Komplexität zu bewältigen. Das Originalvideo ist auf dem TC LeSS YouTube Channel zu sehen.