LeSS: Das Large-Scale-Scrum-Framework erklärt

Jede Organisation, die über ein einzelnes Scrum-Team hinauswächst, stellt irgendwann dieselbe Frage: Wie koordiniert man zehn, dreißig oder achtzig Teams, ohne das zu verlieren, was Scrum ursprünglich funktionieren ließ? SAFe antwortet mit zusätzlicher Struktur: mehr Rollen, mehr Zeremonien, mehr Ebenen, damit alle ausgerichtet bleiben. Large-Scale Scrum (LeSS) antwortet mit dem Gegenteil.

LeSS ist Scrum, angewendet auf viele Teams, die gemeinsam ein Produkt bauen, und es erreicht das, indem es die Organisation entschlackt (Descaling), statt etwas Neues obendrauf zu schichten. Statt zu fragen, wie man agil im großen Maßstab arbeitet, geht es von einer kleineren, härteren Frage aus: Wie einfach kann die Organisation werden und dabei wirklich agil bleiben?

Key Facts

• Large-Scale Scrum wurde von Craig Larman und Bas Vodde geprägt, die seit 2005 gemeinsam am Skalieren von Scrum arbeiten.
• less.works definiert zwei Frameworks: LeSS für 2 bis 8 Teams und LeSS Huge für mehr als 8, wobei die Grenze von acht Teams als „nur eine empirische Beobachtung der Obergrenze" beschrieben wird, nicht als harte Regel.
• less.works nennt zehn LeSS-Prinzipien, nicht neun, eine Zahl, die mehrere Sekundärzusammenfassungen falsch wiedergeben.
• In LeSS Huge umfasst eine Requirement Area von vornherein 4 bis 8 Teams, nie weniger.

Was ist LeSS (Large-Scale Scrum)?

Large-Scale Scrum (LeSS) ist Scrum, angewendet auf mehrere Teams, die gemeinsam ein Produkt bauen, und es erreicht das, indem es die Organisation entschlackt, statt eine Koordinationsebene darüberzulegen. Während viele Skalierungs-Frameworks fragen, wie man agil im großen Maßstab arbeitet, formuliert less.works die LeSS-Frage anders: Wie können wir die Organisation vereinfachen und agil sein, statt nur die Bewegungen davon nachzuahmen?

Craig Larman und Bas Vodde haben das Framework aus Kundenprojekten entwickelt, die 2005 begannen. Jahre des Skalierens von Scrum mit realen Organisationen wurden zu den LeSS-Regeln, die das Framework heute veröffentlicht. Aus dieser Arbeit gingen zwei Frameworks hervor. Das einfache LeSS deckt 2 bis 8 Teams ab. LeSS Huge übernimmt ab da für mehr als 8. less.works stellt offen klar, dass die Grenze von acht Teams keine harte Regel ist, und nennt sie „nur eine empirische Beobachtung der Obergrenze": der Punkt, an dem die kleinere Struktur nach ihrer Erfahrung Unterstützung braucht, keine Zahl, die in der Logik des Frameworks verankert wäre.

Beide Frameworks halten an denselben unverhandelbaren Punkten fest: ein Product Backlog, eine Definition of Done, ein Sprint, ein Product Owner und ein potenziell auslieferbares Product Increment, egal wie viele Teams dazu beitragen.

Die zehn LeSS-Prinzipien

less.works ist bei der Anzahl eindeutig: zehn Prinzipien, nicht neun. Das irritiert viele, weil eine ganze Reihe von Sekundärzusammenfassungen auf neun abrundet und unterwegs eines streicht. Der Unterschied ist weniger als Quizwissen wichtig, sondern weil dies die Ideen sind, aus denen die LeSS-Regeln tatsächlich hervorgehen. less.works sagt, die Prinzipien hätten „uns bei der Entwicklung von LeSS geleitet" und sollten eine Einführung auf dieselbe Weise leiten: Sie sind das, worauf man zurückgreift, wenn eine Situation auftaucht, die die Regeln nicht abdecken.

Über das letzte Prinzip lohnt es sich nachzudenken, wenn Sie Zeit in SAFe oder einem anderen Framework verbracht haben, das auf parallele Arbeitsstränge setzt: Die Warteschlangentheorie besagt, dass mehr Work in Progress alles verlangsamt, selbst wenn es sich anfühlt, als müsse mehr parallele Anstrengung beschleunigen. LeSS wendet diese Logik auf die ganze Organisation an, nicht nur auf das Board eines einzelnen Teams.

LeSS vs. LeSS Huge: Was sich ab acht Teams tatsächlich ändert

Zwei bis acht Teams sind der Bereich des einfachen LeSS, und innerhalb dieses Bereichs ändert sich an der Koordination strukturell nichts: ein Product Backlog, ein Product Owner, der direkt mit jedem Team arbeitet, ein Sprint. Ab acht Teams ergänzt LeSS Huge die Mechanik, die nötig ist, um die Sicht auf das Gesamtprodukt zu behalten, wenn kein einzelner Product Owner mehr plausibel die tägliche Arbeit jedes Teams allein verfolgen kann.

Area Product Owner spezialisieren sich auf ihre Area und agieren gegenüber den Teams darin wie Product Owner, doch der übergreifende Product Owner behält das letzte Wort über das produktweite Backlog und die Vision. Beide stimmen sich laufend ab, besonders vor dem Sprint Planning, damit die lokalen Prioritäten eines Area PO nie weit von dem abdriften, was der übergreifende Product Owner tatsächlich als am wichtigsten festgelegt hat. An diesem Koordinationspunkt verdient LeSS Huge seine zusätzliche Komplexität: Es soll den Fokus auf das Gesamtprodukt schützen, sobald die Teamanzahl über das hinauswächst, was eine Person allein überblicken kann.

Der LeSS-Sprint: ein Sprint, viele Teams

Konzeptionell fährt LeSS einen Sprint auf Produktebene für das gesamte Produkt, nicht einen Sprint pro Team im eigenen Takt. Alle Teams starten und enden gemeinsam, und das Ergebnis ist ein integriertes, potenziell auslieferbares Product Increment, kein Haufen von Team-Increments, die jemand hinterher abgleichen muss. Das Sprint Planning für alle Teams findet zur selben Zeit statt, ebenso Sprint Review und Retrospective. Was nicht übereinstimmen muss, ist das Backlog Refinement: Teams können nach eigenem Zeitplan verfeinern, solange die Einträge bereit sind, wenn das Sprint Planning beginnt.

Das Sprint Planning selbst teilt sich in zwei Teile, genau wie auf Einzelteam-Ebene, nur mit mehr Personen im Raum in der ersten Hälfte.

Beim Refinement verlangt LeSS die meiste Disziplin, denn es lässt sich leicht schleifen, wenn nichts es wie das Sprint Planning in den Kalender zwingt. less.works nennt die Multi-Team-Variante „wohl das wichtigste Event in LeSS", und Teams verwenden dafür typischerweise etwa ein Zehntel ihrer Sprint-Kapazität. Wird es übersprungen, verwandelt sich Sprint Planning One in ein Meeting, das mit Klären statt mit Auswählen verbracht wird, das Gegenteil seines Zwecks.

Das Sprint Review verdient eine eigene Erwähnung, weil man es leicht wie eine Einzelteam-Demo betreibt, die nur auf mehr Personen gestreckt ist. LeSS behandelt es als echten Inspect-and-Adapt-Punkt für das gesamte Produkt, nicht als Freigabe-Schranke des Product Owners, was eine feinere Unterscheidung ist, als sie klingt. Eine Demo, die in Wahrheit ein Abnahmepunkt ist, erzieht Teams dazu, für den PO zu performen. Ein Basar, auf dem Stakeholder umherwandern, Fragen stellen und das Weitere mitgestalten, erzieht die Organisation dazu, das gebaute Produkt tatsächlich anzusehen.

Ein Product Owner für das ganze Produkt (der Teil, den alle bezweifeln)

Dieses Detail lässt die meisten beim ersten Hören erstarren: ein Product Owner für das gesamte Produkt, über alle Teams hinweg, egal wie viele Teams das sind. Es klingt nach einem Flaschenhals, der nur darauf wartet, aufzutreten. In der Praxis geht die Rechnung in LeSS auf, weil präzise festgelegt ist, was der Product Owner tatsächlich tun muss.

Damit bleibt der Product Owner komplett aus Sprint Planning Two, Daily Scrums und Retrospectives auf Teamebene heraus. Diese Meetings gehören den Teams, nicht dem PO. LeSS gelingt das, indem es zwei Aufgaben trennt, die viele Organisationen in einer Rolle bündeln: Priorisierung und Klärung. Der Product Owner verantwortet die Priorisierung, also zu entscheiden, was am wichtigsten ist und warum. Die Klärung, das Hin und Her darüber, wie sich ein Eintrag genau verhalten soll, findet direkt zwischen Team und Kunde oder Stakeholder statt, wobei der PO verfügbar, aber nicht als Zwischenstation erforderlich ist. less.works beschreibt die vorgesehene Rolle als „Verbinder, nicht Vermittler", eine spürbar andere Aufgabe, als der einzige zugelassene Kanal für jede Frage eines Teams zu sein.

Es ist außerdem eine andere Form, als viele Leser beim Einstieg annehmen. Das ist kein Product Manager, der über mehreren Product Ownern sitzt und ein Team von Koordinatoren koordiniert. Es ist eine Person, die die Scrum-Product-Owner-Aufgabe im Produktmaßstab ausübt, wobei die Teile der Aufgabe, die sich nicht skalieren lassen, an die Teams abgegeben werden.

Diese Trennung schützt zudem die Autonomie der Teams auf eine leicht zu übersehende Weise. Müsste jede Klärungsfrage über eine einzige Person laufen, würde LeSS genau den Flaschenhals neu erschaffen, den Kritiker vermuten. Stattdessen kommen Teams, die direkt mit Kunden sprechen können, bei den Details schneller voran, und der Product Owner nutzt die gewonnene Zeit für das, was nur eine Person für das gesamte Produkt tun kann: entscheiden, was als Nächstes gebaut wird. Wenn Sie diese Rolle gegen die Koordinationsaufgabe abwägen, die ein Scrum Master auf Teamebene übernimmt, ist die Aufteilung dieselbe, die schon im Ein-Team-Scrum besteht, nur auf mehr Teams angewendet statt innerhalb eines einzigen.

LeSS vs. SAFe: Descaling vs. zusätzliche Struktur

Leser landen auf dieser Seite meist, nachdem sie bereits über SAFe gelesen haben, und der faire Weg des Vergleichs besteht darin zu sagen, worauf jedes der beiden tatsächlich optimiert. SAFe lässt Teams im Wesentlichen, wie sie sind, und fügt Ebenen, Rollen und einen skalierten Planungsrhythmus hinzu, um sie zu koordinieren. LeSS geht in die andere Richtung: Es verlangt von der Organisation, sich um Feature-Teams herum neu zu ordnen, zusätzliche Rollen zu streichen und über einen Sprint und ein Backlog zu koordinieren statt über einen Stapel von Planungs-Events.

Keine Seite dieser Tabelle ist falsch, und keines der Frameworks ist nach irgendeinem objektiven Maß agiler als das andere. Sie lösen dasselbe Koordinationsproblem mit entgegengesetzten Instinkten: SAFe geht davon aus, dass Koordination mehr Gerüst braucht, und LeSS geht davon aus, dass der Großteil dieses Gerüsts das Problem ist, das es zu lösen versucht. Wo SAFe PI Planning als Synchronisations-Event nutzt, nutzt LeSS Sprint Planning One, dasselbe Event, das ein einzelnes Team bereits fährt, nur mit allen Teams im Raum. Das ist die philosophische Lücke in einem Vergleich: Ein Framework hat ein neues Event gebaut, um mit Größe umzugehen, das andere hat das Event skaliert, das es schon hatte.

LeSS vs. Spotify-Modell vs. einfaches Multi-Team-Scrum

Zwei weitere Vergleiche kommen oft genug vor, um sie kurz abzudecken. Keiner ist wirklich ein Konkurrent von LeSS wie SAFe, da sie leicht andere Probleme lösen.

Das Spotify-Modell war nie dazu gedacht, 1:1 kopiert zu werden, und Spotify selbst ist längst über die ursprüngliche Struktur hinausgegangen. Es taugt gut als Vokabular (Squads, Chapters, Guilds), aber schlecht als Regelwerk, weil nie eines veröffentlicht wurde. Einfaches Multi-Team-Scrum, also mehrere Teams, die jeweils Standard-Scrum fahren, ohne ein gemeinsames Framework darüber, ist das, was die meisten Organisationen standardmäßig tun, bevor sie etwas anderes einführen, und es ist meist das, was zuerst bricht: Nichts hindert die Product Owner zweier Teams daran, in entgegengesetzte Richtungen zu priorisieren, weil ihre Backlogs von vornherein nichts verbindet. LeSS ist im Grunde das, was man bekommt, wenn man dieses Standard-Setup nimmt und genau das repariert, was es zum Scheitern bringt: ein Backlog, ein Owner, ein Sprint. Es gibt eine ältere Antwort auf dieselbe Frage, die man kennen sollte: Crystal skaliert, indem mit wachsendem Team ein schwereres Mitglied einer Methodikfamilie eingesetzt wird, statt ein Framework beizubehalten und die Organisation darum herum umzugestalten.

Die Adoptions-Realität: Was eine LeSS-Einführung tatsächlich verlangt

SAFe verkauft sich leichter, und es lohnt sich, klar zu sagen, warum. Ein SAFe-Rollout fügt Dinge hinzu: neue Rollen, ein Schulungscurriculum, Zertifizierungen, ein benanntes Event im Kalender. Auf einem Organigramm sieht es nach Fortschritt aus, noch bevor irgendetwas geliefert wurde. Eine LeSS-Einführung entfernt Dinge, und Entfernen ist eine viel schwerere Geschichte für einen Raum voller Manager, deren aktuelle Stelle zu den Dingen gehören könnte, die wegfallen.

Nichts davon ist subtil. Die Neuordnung um Feature-Teams herum bedeutet meist, dass sich der Zuschnitt mancher Stellen ändert, und die Bündelung der Product Ownership in einer Rolle bedeutet meist, dass andere Titel verschwinden oder neu definiert werden. Das ist eine grundlegend andere Anforderung als bei SAFe, das Menschen überwiegend in neue Rollen einschult, statt bestehende Rollen zu entfernen. Es ist auch ein Teil des Grundes, warum LeSS-Einführungen tendenziell kleiner sind und sich langsamer verbreiten als SAFe-Rollouts. Weniger Organisationen sind bereit, dieses Gespräch über die eigene Managementstruktur zu führen, selbst wenn das zugrunde liegende Argument für das Descaling stichhaltig ist.

LeSS passt tendenziell zu Organisationen, die bereits Ein-Team-Scrum gut fahren und ein echtes Backlog vorweisen können, nicht zu solchen, die noch lernen, was ein Sprint oder eine Definition of Done im Alltag bedeutet. Es passt außerdem zu Organisationen, die bereit sind, einen Product Owner mit echter Autorität über das ganze Produkt zu benennen und sich um Feature-Teams herum neu zu ordnen, statt die bestehende Komponententeam-Struktur zu verteidigen. Es passt nicht zu Organisationen, die die Berichts- und Rollenstruktur eines regulierten oder stark vertraglich geprägten Umfelds brauchen, oder zu solchen, die mehrere wirklich getrennte Produkte verantworten, die von vornherein kein gemeinsames Backlog haben. Diese Fälle passen meist besser unter die Portfolio-Ebene von SAFe oder ein ganz anderes Modell.

Wann Sie LeSS nicht einsetzen sollten

Nichts davon sind Gründe, warum LeSS ein schlechtes Framework wäre. Es sind Gründe, warum eine bestimmte Organisation zu einem bestimmten Zeitpunkt für das, was es verlangt, vielleicht noch nicht bereit ist. Die ehrliche Fassung dieses Satzes gilt auch für SAFe oder jeden Skalierungsansatz: Das Framework ist nicht der schwere Teil. Die tatsächliche Struktur einer Organisation zu verändern ist es, und das gilt unabhängig davon, ob das Framework Gerüst hinzufügt oder wegnimmt.

LeSS ist nicht der leichtere Verkauf, und es hat nie versucht, es zu sein. Wenn Ihre Organisation bereits Ein-Team-Scrum gut fährt und bereit ist, sich um Feature-Teams und einen einzigen Product Owner herum neu zu ordnen, ist Descaling eine echte Option, nicht nur eine philosophische Haltung. Wenn sie dazu noch nicht bereit ist, kommen SAFe oder ein leichterer Ansatz wahrscheinlich weiter und schneller, und das ist ebenfalls eine legitime Antwort. Die Wahl betrifft nicht die Frage, welches Framework agiler ist. Es geht darum, in welche Richtung Ihre Organisation Veränderung tatsächlich leisten kann.