Warum man LeSS nicht mit einem Skalierungsrahmen wie SAFe vergleichen kann

Der wichtige Unterschied zwischen einem skalierenden und einem de-skalierenden Framework

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.

‍

Wie unterscheidet sich LeSS von gängigen Skalierungs-Frameworks?

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.

‍

Warum nicht nur Scrum? Warum brauchen Sie etwas anderes?

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.

‍

Wie man mit LeSS die Komplexität reduziert

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.