LeSS (Large-Scale Scrum)

Large-Scale Scrum (LeSS) Definition

Large-Scale Scrum – abgekürzt LeSS – ist ein Framework für die agile Produkterstellung und hilft Organisationen, im großen Umfang agil zu werden. Dafür bietet das Rahmenwerk

• Prinzipien,
• Regeln,
• Leitlinien und
• Experimente.

Scrum ist eines der am weitesten verbreiteten agilen Frameworks, weil es sich auf selbstorganisierende Teams konzentriert, die empirische Prozesskontrolle (Transparenz, Inspektion und Anpassung) nutzen, um gemeinsam mit Nutzern oder Kunden in kurzen Iterationen Produkte zu entwickeln. Und natürlich, weil es sich darauf konzentriert, die Dinge, die aus Sicht des Kunden am wichtigsten sind, in kurzen Zyklen zu liefern und kontinuierlich zu lernen, wie man das richtige Produkt auf die richtige Weise entwickelt. Large-Scale Scrum versucht, dies in einem Kontext außerhalb eines Teams – einer Organisation – zu replizieren und konzentriert sich darauf, einfachere Organisationen zu schaffen, die auf Anpassungsfähigkeit mit geringen Änderungskosten optimiert sind und den höchsten Kundennutzen liefern.

Mit anderen Worten: LeSS ist ein Framework zur Verringerung organisatorischer Komplexität und hilft Organisationen, agil zu werden und nicht nur agile Praktiken durchzuführen.

LeSS ist kein Skalierungs-Framework

LeSS wird oft zusammen mit skalierenden Frameworks wie SAFe (Scaled Agile Framework) oder Scrum@Scale erwähnt. Skalierende Frameworks geben größeren Organisationen eine Anleitung, wie sie Scrum auf Teamebene einsetzen und den Wertstrom für die Produktlieferung mit vielen Teams verwalten können. Sie führen viele zusätzliche Artefakte und Rollen ein (Agile Release Train, Product Increment Planning, Programme Backlog, Release Train Engineer, Solution Train Engineer, Executive MetaScrum Forum, Executive Action Team usw.), um einen Fokus auf priorisierte Geschäftsziele in einem Netzwerk von mehreren Scrum-Teams zu schaffen. Damit schaffen sie eine zusätzliche Komplexitätsebene, die die durch Scrum geschaffene Agilität zerstört, Übergaben und Engpässe einführt und die Entscheidungslatenz (Zeit für eine Entscheidung) erhöht.

LeSS zielt auf das Gegenteil ab: Es beantwortet die Frage, wie man Scrum mit mehreren Teams durchführen kann, anstatt mehrere Scrum-Teams und eine ganze Schicht von Komplexität um sie herum zu haben, um die Wertschöpfung der Teams zu verwalten.

Gründe für LeSS: Warum ist Scrum auf Organisationsebene nicht ausreichend?

Scrum, wie es ursprünglich im Scrum Guide beschrieben wurde, ist für ein einzelnes Scrum Team konzipiert. Im Scrum Guide gibt es außer diesem Absatz keine Anleitung, wie man mit mehreren Teams arbeitet:

Wenn Scrum Teams zu groß werden, sollten sie in Erwägung ziehen, sich in mehrere zusammengehörende Scrum Teams zu reorganisieren, die sich alle auf dasselbe Produkt konzentrieren. Daher sollten sie sich Produkt‐Ziel, Product Backlog und Product Owner:in teilen – Scrum Guide 2020

Unternehmen, die Scrum einführen, definieren ihre Produkte in der Regel um ihre bestehenden Teams herum und finden einen Product Owner, der ein Product Goal und ein Product Backlog erstellt. Leider führt dies zu Teams, die zwar für einen besseren Output, nicht aber für bessere Ergebnisse optimiert sind, da ihnen Schlüsselelemente von Scrum fehlen (wie z. B. die direkte Interaktion mit dem Kunden/Endbenutzer, die häufige Lieferung von Produktinkrementen, die dem Kunden einen Mehrwert bieten, usw.). Um Scrum in der großen Produktentwicklung mit mehreren Teams anwenden zu können, muss die richtige Organisationsstruktur vorhanden sein (d.h. entsprechend strukturierte Teams und geeignete Richtlinien).

Die LeSS Prinzipien erweitern die Scrum Prinzipien (empirische Prozesskontrolle, Transparenz, Kundenfokus) um zusätzliche Prinzipien, die bei der Anwendung von Scrum in einem Team sehr offensichtlich sind, bei der Produktentwicklung in mehreren Teams jedoch nicht so offensichtlich. Diese Prinzipien sind

• Ganzheitlicher Produktfokus (Whole Product Focus),
• Mehr mit LeSS (More with LeSS),
• Warteschlangentheorie (Queueing Theory)
• und die kontinuierliche Verbesserung in Richtung Perfektion (Continuous Improvement towards Perfection).

Darüber hinaus ist es mit Denkwerkzeugen wie dem Systemdenken (System Thinking) möglich, die Systemdynamik zu erkennen und zu sehen, wie lokale Optimierung zu einer Suboptimierung auf Systemebene führen kann. Lean Thinking hatte bspw. einen großen Einfluss auf die agile Softwareentwicklung, weil es das traditionelle Management und die Prozesse in der Produktentwicklung in Frage stellte und als Leitfaden für die Schaffung der richtigen Organisationsstrukturen, Führung und Regeln für eine agile Organisation verwendet werden kann.

Der Ursprung von LeSS

LeSS wurde von Craig Larmann und Bas Vodde entwickelt und erstmals 2008 in dem Buch “Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum” vorgestellt.¹ Seit 2005 haben Bas und Craig mit vielen Kunden zusammengearbeitet, um die Produktentwicklung in großem Maßstab anzuwenden, und ihre Erkenntnisse in ein paar Regeln für den Einstieg und als Grundlage, eine Reihe von moderaten Leitfäden für die effektive Anwendung der Regeln und viele Experimente, die sehr situationsabhängig sind und in einem bestimmten Kontext funktionieren oder eher vermieden werden sollten, destilliert. Darüber hinaus sind die oben genannten Prinzipien das Herzstück von LeSS und beeinflussen die Regeln (Rules), Leitlinien (Guides) und Experimente.

Eine gute Möglichkeit, LeSS zu betrachten, ist die Visualisierung im LeSS-Gesamtbild:

Die Unterscheidung in zwei Frameworks: LeSS & LeSS Huge

Large-Scale Scrum unterscheidet zwischen zwei Frameworks: LeSS (für 2 bis 8 Teams) und LeSS Huge (für mehr als 8 Teams). Die Zahl 8 ist keine magische Zahl und manchmal ist es empfehlenswert, das kleinere LeSS-Framework für mehr als 8 Teams beizubehalten, aber es gibt auch Situationen, in denen LeSS Huge mit weniger als 8 Teams verwendet werden muss.

Der Grund für den Wechsel von LeSS zu LeSS Huge kann einer der folgenden sein:

• Der Product Owner verliert den Überblick über das gesamte Produkt.
• Der Product Owner hat Schwierigkeiten, den externen und internen Fokus in Balance zu halten.
• Das Product Backlog ist so groß, dass es für eine Person schwierig ist, es zu bearbeiten.
• Beide Frameworks haben gemeinsame Elemente: einen Product Owner und ein Product Backlog, einen gemeinsamen Sprint für alle Teams, ein lieferbares Produktinkrement.

LeSS Huge führt einige zusätzliche Regeln ein (die für kleine Teams nicht erforderlich sind), wie z. B. Area Product Owner und Area Product Backlog.

Das LeSS Framework

Die Elemente des LeSS Frameworks sind in etwa die gleichen wie bei Scrum mit einem Team:

• Rollen² – ein Product Owner, zwei bis acht Teams, ein Scrum Master für ein bis drei Teams. Die Teams sind Feature-Teams – wahre funktions- und komponentenübergreifende Full-Stack-Teams, die in einer gemeinsamen Code-Umgebung zusammenarbeiten, wobei jedes Team alles tut, um ein Produktinkrement zu erstellen.
• Artefakte – Ein potenziell auslieferungsfähiges Produktinkrement, ein Product Backlog (für alle Teams) und ein separates Sprint Backlog für jedes Team.
• Events – Ein gemeinsamer Sprint für das gesamte Produkt, der alle Teams einschließt und in einem potenziell auslieferbaren Produktinkrement endet.

Das LeSS Huge Framework

• einem hohen Maß an Verschwendung (Inventar, unfertige Arbeiten, Übergabe, Informationsstreuung usw.),
• verzögerter Return of Investment,
• komplexe Planung und Koordinierung,
• Verwaltung von Gemeinkosten und
• schwaches Feedback und Lernen.

Und sie ist nach innen auf einzelne Fähigkeiten, Architektur und Management ausgerichtet und nicht nach außen auf den Kundennutzen.

In LeSS Huge erfolgt die Einteilung in Hauptbereiche von Kundenanliegen, die als Anforderungsbereiche (Requirement Areas) bezeichnet werden. Die Anforderungsbereiche bestehen aus 4 bis 8 Teams, die dynamisch sind, d. h. sie wachsen oder schrumpfen im Laufe der Zeit, wobei Teams hinzukommen oder weggehen – höchstwahrscheinlich zu oder von einem anderen bestehenden Bereich.

Jeder Anforderungsbereich arbeitet als eine (kleinere) LeSS-Implementierung, die jeweils parallel in einem Gesamtsprint bearbeitet wird.

Wie bereits erwähnt, erweitert LeSS Huge die LeSS-Elemente:

• Rollen – dieselben wie bei LeSS, plus zwei oder mehr Area Product Owner und vier bis acht Teams in jedem Anforderungsbereich. Der eine Product Owner (der sich auf die Gesamtoptimierung des Produkts konzentriert) und die verschiedenen Area Product Owner bilden das Product Owner Team.
• Artefakte – Wie bei LeSS, plus ein Attribut für den Anforderungsbereich in dem einen Product Backlog und somit eine Area Product Backlog-Ansicht für jeden Bereich.
• Events – Es gibt nach wie vor nur einen gemeinsamen Sprint für das gesamte Produkt, der alle Teams einschließt und in einem potenziell auslieferbaren Produktinkrement endet.

Was sind die LeSS Leitlinien und Experimente?

Die LeSS Prinzipien sollten jede Entscheidung leiten und eine Orientierung bieten, um eine Organisation zu schaffen, die ihre Anpassungsfähigkeit optimiert und an den wichtigsten Dingen aus der Sicht des Kunden arbeitet. Das LeSS Framework und das LeSS Huge Framework liefern die LeSS-Regeln. Darüber hinaus gibt es eine Reihe von Leitlinien (Guides) für die wirksame Anwendung dieser Regeln sowie eine riesige Liste von Experimenten (über 600), die in der Regel sehr situationsabhängig sind und sich möglicherweise lohnen. Die Leitfäden enthalten Tipps, die auf der Grundlage jahrelanger Erfahrung mit LeSS ermittelt wurden und einen Versuch wert sind, wie z. B. die

• “Drei Grundsätze für die Einführung” oder
• “Erste Schritte [mit LeSS]”.

Beispiele für Experimente sind

• “Versuchen Sie… gemeinsamen Sprint-Review-Basar”,
• “Vermeiden Sie… getrennte Analyse- oder Spezialistengruppen”
• oder “Vermeiden Sie… Agile/Lean-Transformationen oder Änderungsprojekte”.

Wer kann von der Einführung von LeSS profitieren und wer sollte sich nicht darum kümmern?

Die Einführung von LeSS ist schwierig, und wie bei jedem anderen Framework oder sogar Tool ist es sinnvoll, zunächst seinen Zweck, seine Funktionen und Vorteile zu verstehen, bevor man eine Entscheidung darüber trifft, ob es hilfreich ist oder nicht.

Hier sind einige Szenarien, in denen LeSS (und LeSS Huge) höchstwahrscheinlich keinen (großen) Nutzen bringt oder nicht eingesetzt werden kann:

• Ihr Hauptziel bei der Optimierung ist eine schnellere Lieferung, eine schnellere Markteinführung, Effizienzsteigerungen auf Teamebene, eine Verbesserung der Durchlaufzeit oder etwas Ähnliches.
• Sie sind nicht in der Lage oder bereit, organisatorische Strukturen oder Richtlinien zu ändern.
• Sie arbeiten auf Vertragsbasis und führen ein Projekt mit festem Umfang, fester Zeit und festen Ressourcen durch (z. B. ein System-Upgrade-Projekt).
• Sie brauchen eine genaue Vorhersagbarkeit der Entwicklungsprognosen.
• Der Großteil Ihres Produktentwicklungsteams befindet sich außerhalb Ihres Unternehmens (z. B. bei Dritten).

Und hier sind einige Szenarien, in denen sich LeSS (und LeSS Huge) tatsächlich als äußerst hilfreich erweisen könnte:

• Ihr Optimierungsziel ist Anpassungsfähigkeit mit geringen Änderungskosten und die Arbeit an den wichtigsten Themen aus Geschäfts- und Kundensicht.
• Sie entwickeln ein Produkt in einer komplexen Umgebung, für das mehrere Teams erforderlich sind.
• Sie möchten, dass Ihre Teammitglieder kontinuierlich die Fähigkeiten entwickeln, die sie benötigen, um die Elemente zu entwickeln, die aus Sicht des Kunden am wichtigsten sind.

Impuls zum Diskutieren:

Welche weiteren Unterschiede sehen Sie zwischen LeSS und Scrum?

Hinweise:

Haben Sie Lust auf einen neuen Lieblings-Newsletter?

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

[1] Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
[2] Der Scrum Guide 2020 definiert Verantwortlichkeiten (Accountabilitys) anstelle von Rollen und betont damit die Ergebnisverantwortung der Teilnehmer. In der gelebten Unternehmenspraxis gibt es natürlich weiterhin Rollen.

Hier finden Sie weitere Informationen zu Large-Scale Scrum.

Hier finden Sie ein schönes Video, das LESS und die Unterschiede zu Scrum erläutert.

LeSS Coach gesucht? Unsere Empfehlung: Robert Briese von Lean Sherpas.

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 Entwicklung sowie an der Verbesserung der organisatorischen Agilität durch kulturellen Wandel.

Hier finden Sie ergänzende Informationen aus unserem t2informatik Blog:

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.