Blog

Stell dir vor, du hast 3 agile Teams die nach Scrum arbeiten und möchtest jetzt skalieren – Scrum reicht nicht mehr. Wie geht es weiter? Dafür gibt es verschiedene Frameworks, unter anderem SAFe, Nexus, und viele weitere. Heute beschäftigen wir uns näher mit LeSS.

LeSS ist SCRUM (Definition)

Das LeSS-Framework versucht, die Prinzipien und Ideale von Scrum in einem großen Unternehmenskontext so einfach wie möglich durch definierte Regeln und Richtlinien anzuwenden. Aufgrund seiner Einfachheit hat LeSS die Definition bzw. das Label eines „kaum ausreichenden“ Frameworks erhalten – aber das soll es nicht in ein negatives Licht rücken.

7 Vorteile des LeSS-Frameworks

Der grundlegende Fokus von LeSS liegt nicht darauf, ein anderes, neues Framework zu erstellen. Stattdessen werden die Scrum-Prinzipien auf viele Teams angewendet.

Einige der Vorteile, die mit LeSS erzielt werden können, sind:

1. Niedrigere Implementierungskosten durch die Implementierung von Praktiken, die Teams bereits in Scrum anwenden
2. Ein Product Owner, der die Rahmenbedingungen und Prinzipien versteht und dann die Lücke zwischen dem Unternehmen und den technischen Teams schließt
3. Für die Lieferung eines Produkts werden weniger Personen benötigt. LeSS fügt nicht exponentiell mehr Rollen und Overhead hinzu
4. Es bietet eine vollständige Produktansicht im Fokusbereich
5. Die Teams stehen in direktem Kontakt mit dem Kunden und weiteren Stakeholdern 
6. Kontinuierliche Verbesserungen werden durch regelmäßige Retros und andere Meetings ermöglicht, die grundlegende Prozesse des Agilen Manifests sind
7. Für viele Unternehmen ist der LeSS-Ansatz zur Skalierung von Scrum-Teams möglicherweise der nächste logische Schritt auf ihrem Weg zur agilen Skalierung.

Wie ist LeSS strukturiert? Eine Definition

Per Definition baut Large Scale Scrum auf Prinzipien, Rahmenbedingungen, Leitfäden und Experimenten auf. Die Abbildung (Quelle: LeSS Website) zeigt es. Erklären wir das an einem Beispiel: 

Prinzipien: Team X entwickelt ein Handy. Ihnen ist das Prinzip wichtig, transparent zu handeln. Deshalb arbeiten sie einerseits transparent und machen regelmäßige Dailys. Außerdem möchten Sie herauszufinden, woher genau die Materialien stammen, die für die Handyproduktion wichtig sind – um dies später transparent den Kunden mitteilen zu können. Transparenz durch und durch also.

Rahmenbedingungen: Gleichzeitig arbeiten sie kontinuierlich daran, die Rahmenbedingungen zu schaffen, die das SCRUM-Framework als Ideal mit den agilen Werten vorgibt: Offenheit, Mut, Respekt, Fokus & Commitment.

Leitfäden: Leitfäden für die Entwicklung sind die Produktvision, die fachlichen Anforderungen an das Produkt, aber auch die Art und Weise der Zusammenarbeit im Team.

Experimente: Wenn Unsicherheiten auftreten, befindet man sich im Experiment-Bereich, wo es ums Testen und Ausprobieren geht. Beispielsweise wenn wir ein neues Feature entwickeln oder eine neue völlig neue Zielgruppe erschließen möchten. (Quelle: LeSS Website)

Die 10 LeSS-Prinzipien

LeSS definiert 10 Prinzipien. Sie helfen dabei – wenn wir bei unserem Beispiel bleiben – ein Handy zu entwickeln, das den Werten und Vorstellungen des Kunden am ehesten entspricht. Anbei nun die Liste der 10 Prinzipien auf einen Blick:

1. Large-Scale Scrum ist Scrum: Das Handy kann nicht nur von einem, sondern mehreren Teams entwickelt werden, damit der Kunde zufrieden und die Entwicklungszeit angemessen ist
2. Empirische Prozesskontrolle: Aus kurzfristigen Erfahrungen heraus werden einzelne Funktionen des Handy kontinuierlich angepasst und stetig überarbeitet
3. Transparenz: Unser Team X entscheidet sich, ab jetzt offen die wöchentlichen Teamziele transparent in ihrer internen Plattform zu teilen. Das hilft enorm dabei zu verstehen, woran eigentlich jeder arbeitet.
4. Mehr mit weniger: Grundsätzlich sollte man mit neuen Ideen experimentieren und von diesen lernen, bevor man träge Regeln etabliert und so “Ballast” hinzufügt.
5. Ganzer Produktfokus: Teams haben noch stärker die Tendenz, ihre Ziele zu suboptimieren, als es Individuen tun. Daher ist die größte Herausforderung für die Teams, ihre Arbeit zu einem Produkt zu integrieren. Der “Purpose” des gesamten Produktes sollte deshalb so klar wie möglich sein. Die Teams und Individuen werden so befähigt, passende Subziele bei Bedarf selbst zu definieren.
6. Kundenzentrierung: Nur Teams, welche direkt mit dem Kunden arbeiten, können den tatsächlichen Wert des Produktes maximieren. Leider haben Organisationen die Tendenz, Teams vom Kunden zu entkoppeln, sobald sie anfangen zu wachsen. Um dem entgegenzuwirken, werden Kunden z.B. regelmäßig in Team Meetings eingeladen, um Feedback zu geben.
7. Kontinuierliche Verbesserung in Richtung Perfektion: LeSS ist eine tiefgreifende Veränderung für viele Organisationen. Beachte, dass dies nicht automatisch eine Verbesserung bedeutet. LeSS befähigt die Organisation damit zu starten, besser zu werden – und ab dann sollte man kontinuierlich weiter optimieren. LeSS ist ein Prozess!
8. Lean Thinking: LeSS betont vor allem den Ort des Geschehens selbst zu sehen (Gemba), das dreistufige Lernkonzept ShuHaRi (Shu = nachahmen, Ha = variieren, Ri = eigene Regeln definieren) und den Respekt gegenüber Menschen.
9. Systemdenken: Alle Handlungen, Veränderungen und Verbesserungen sollen immer auch systemisch bzw. systemkonform gedacht werden, um die Ziele zu erreichen. Beispiel: Wenn ich in einem Team theoretisch finanzielle Boni anbiete – was bedeutet das für andere Teams (sprich, für den Rest des organisationalen Systems)?
10. Warteschlangentheorie: Der Grundgedanke ist, dass wir in der Softwarewelt sehr viele unsichtbare Warteschlangen aufbauen (z. B. Anforderungsdokumente, ungetestete Software) und uns kaum um die optimale Behandlung dieser Warteschlangen kümmern. Wusstest du beispielsweise, dass bei der Steigerung der Auslastung einer Ressource von 50% auf 90% die Wartezeit für neue Aufgaben sich nicht ungefähr verdoppelt, sondern vervielfacht? Definiere also WIP-Limits (Work-in-Progress), vermeide Multitasking und große Arbeitspakete. 

Die LeSS-Rahmenwerke

LeSS bietet zwei Konfigurationen: Basic LeSS für zwei bis acht Teams (10 bis 50 Personen) und LeSS Huge für mehr als acht Teams (50 bis 6.000 Personen und mehr).

Quelle: Less.works

Es wird empfohlen, mit Basic LeSS zu beginnen, um zu experimentieren, Erfahrungen zu sammeln und Feedback zu erhalten, bevor man direkt zu LeSS Huge wechselt. Es gibt zwei vorgeschlagene Ansätze für die Einführung von LeSS Huge:

• Starte mit jeweils einem Anforderungsbereich innerhalb des größeren Produkts und konzentriere dich zuerst nur auf diesen
• Oder erweitere allmählich den Arbeitsumfangs des Teams, der Definition of Done und der Produktdefinition

Auf diese Weise kann ein Unternehmen Teamerfahrung mit LeSS aufbauen, in einem Produktbereich expandieren, erste Erfolge erzielen – und so Managementunterstützung erhalten, bevor LeSS im gesamten Unternehmen skaliert wird.

Rollen und Planung in LeSS

Basic LeSS konzentriert sich auf das Team und die wichtigsten Scrum-Rollen:

1. den Scrum-Product Owner, der für die Produktvision und -richtung verantwortlich ist
2. die Scrum-Entwicklungsteams, die für die Produkterstellung und -lieferung verantwortlich sind
3. den Scrum-Master, der das Team bei der kontinuierlichen Verbesserung unterstützt
4. die Rolle des Managers und wie er das Team dabei unterstützt, Hindernisse bzw. “Impediments” für kontinuierliche Verbesserung und Autonomie zu beseitigen (Erweiterung zu SCRUM)

Huge LeSS ergänzt Basic LeSS um die folgenden Rollen:

1. Der regionale Product Owner von LeSS Huge unterstützt Product Owner und ist von entscheidender Bedeutung, um die geschäftliche Anforderungen (Finanzen etc.) mit den Entwicklungsteams zu verbinden.
2. Der Area Product Owner ist auf kundenorientierte Aufgaben spezialisiert und fungiert als Product Owner für produktorientierte Feature-Teams.

Meetings in LeSS

Das Product Backlog Refinement (PBR) Meeting

PBR-Meetings erweitern die Sprintplanung über die Schwerpunktbereiche hinweg durch eine Reihe paralleler LeSS-Sprintausführungen. Die fortlaufende Trittfrequenz dieser Meetings ist in jedem Sprint erforderlich, um Elemente zu verstehen, zu diskutieren und zu verfeinern und sich auf zukünftige Sprints vorzubereiten. Die Hauptaktivitäten von PBR-Meetings sind: 

1. Erstellung von Epics – also Clusterung großer zusammenpassender Themenbereiche; in unserem Beispiel wäre das die Zusammenlegung der Sprints vom Design & Usability Team
2. Klärung und Beantwortung der offenen Fragen: Alle sollten ein gleiches Verständnis zum Produkt und den Vorstellungen des Kunden und der Kollegen haben
3. Schätzung der Größe der User Story, der Risiken, Abhängigkeiten: Quasi die Ableitung und Detailplanung der einzelnen Themenbereiche

Das Sprint-Review

Äquivalent zu Scrum: Das Sprint Review ist ein Treffen am Ende eines Sprints zur Begutachtung der erledigten Arbeit in Bezug auf das gesteckte Sprint-Ziel. Hier geht es um das Produkt an sich. Fortschritte werden sichtbar und neue Handlungsfelder identifiziert. Es macht den Fortschritt im Hinblick auf das Produkt und das Ziel transparent.

Die Retrospektive 

Ähnlich wie bei Scrum: Die Retrospektive ist ein Treffen, das sich mit der Zusammenarbeit des Teams befasst. Die Verbesserung der Zusammenarbeit im Team und somit um die Verbesserung von Abläufen und Inhalten. Es geht auch um das Zusammenspiel zwischen einzelnen Entwicklern, um das Wirken des Scrum Masters und die Kommunikation mit dem Product Owner. Damit ist die Retrospektive wichtiger Teil eines kontinuierlichen Verbesserungsprozesses (KVP).

Bei Large Scale Scrum wird teilweise empfohlen, eine “Retro of Retros” durchzuführen – also übergeordnet über viele Teams hinweg.

Large Scale Scrum – Scrum Master Ratio

Wie viele Teams sollte ein Scrum Master haben? Man kann argumentieren, dass pro Team ein Scrum Master am besten ist – obwohl dies auch Nachteile hat. In der Regel liegt die Large Scale Scrum Master Ratio bei 1:1 bis 1:3 – ein Scrum Master hat ein bis maximal drei Teams.

Wann ist Large Scale Scrum LeSS die richtige Agile Methode?

Large Scale Scrum kann angewendet werden, wenn bereits mit SCRUM gearbeitet wird und du Scrum skalieren willst. Aber auch um die Balance zwischen Selbstorganisation und Regeln zu finden. 

Bas Vodde hat einmal gesagt, dass er und Craig Larman glauben, dass LeSS ein sehr guter Ansatz ist, weil er genau den “Sweet Spot” trifft zwischen so vielen Vorgaben wie nötig und so wenigen wie möglich. 

Ähnlich wie Scrum selbst stellt es nur einen Prozessrahmen dar, der von den Teams, die ihn verwenden, noch sehr individuell und vielfältig ausgestaltet werden kann. Dieses Argument scheint plausibel und hebt Large Scale Scrum (LeSS) tatsächlich von manch anderem Skalierungs-Framework ab.

Abbildung: Sweet Spot 

Im Vergleich: Large Scale Scrum versus Scrum

LeSS baut auf Scrum auf, um seine Verwendung in einem größeren Kontext zu unterstützen und es über größere Organisationen und über das eine Team hinaus zu skalieren. Eine entweder oder Frage stellt sich also nicht. LeSS ist die Erweiterung von SCRUM. Um LeSS einzuführen, benötigt man also immer SCRUM. Es bietet sich an, zuerst SCRUM einzuführen und dann auf LeSS umzustellen.

Im Vergleich: Large Scale Scrum versus Scaled Agile Framework SAFe®

Obwohl LeSS in Unternehmen mit großen Softwareentwicklungsteams immer beliebter wird, haben auch andere skalierte agile Frameworks wie Scrum of Scrums oder Scrum @ Scale an Bedeutung gewonnen. Eines der führenden Frameworks ist das Scaled Agile Framework® (SAFe).

Es gibt viele Ähnlichkeiten zwischen Large Scale Scrum und dem Scaled Agile Framework SAFe®. Zum Beispiel beginnen beide mit der Skalierung eines Scrum-Teams und der Einbeziehung von Prinzipien wie Lean Thinking, kontinuierliche Verbesserung und Kundenorientierung. 

3 Kernunterschiede zwischen Large Scale Scrum und Scaled Agile Framework SAFe®

1. Organisation: LeSS konzentriert sich die Vereinfachung der Organisationsstruktur, indem es flexibel und anpassungsfähig bleibt.
2. Rollen: SAFe hat zusätzliche Rollen (manche sagen auch deshalb mehr “Overhead”), einschließlich des Release Train Engineer (RTE), des Solution Train Engineer (STE) und der Epic Owners.
3. Umsetzung: Das Scaled Agile Framework SAFe® enthält Prozesse, Artefakte und organisatorische Änderungen, die einige Organisationen möglicherweise nicht übernehmen können. Du musst also immer schauen, welches Framework zu dir und deinem Unternehmen passt.

Für eine erfolgreiche Einführung von Large Scale Scrum

Die erfolgreiche Einführung von Large Scale Scrum erfordert das Brechen mit altgedienten Annahmen und das Ändern der Unternehmensstruktur – mit all dem explosiven Potenzial auf “Chefebene” und dem „Gesichtsverlust“, die eine entsprechende Veränderung mit sich bringt. 

Die Grundlage ist deshalb, dass sich alle bereit erklären für diese Veränderung – siehe dazu auch das Change Management Modell nach Kotter oder unseren Artikel zur Agile Transformation Roadmap.

Erstelle eine attraktive Vision, auf die man hinarbeitet – und starte viele Veränderungsprojekte auf einmal, im Sinne des Experimentierens. 

Wenn das ursprüngliche Ziel erreicht ist, dann ist die Änderung erledigt und die Organisation stellt sich auf einen neuen Status quo ein, bis die nächste Änderung bevorsteht. 

Dieser klassische Ansatz ähnelt dem sequentiellen und „Big-Batch“ -Ansatz (siehe Abbildung) der Softwareentwicklung, bei dem Änderungen eine Ausnahme darstellen, die von Kontrollgremien streng verwaltet werden.

Bei LeSS-Adoptionen gibt es keine Change-Initiative, also keine Changemanager. In LeSS ist der Wandel durch Experimentieren und Verbessern kontinuierlich – der Wandel ist der Status Quo.

Was sind die Schritte für eine erfolgreiche Implementierung?

1. Verschiebung, Anpassung oder Änderung der Teamkultur

Wir empfehlen, erst einmal mit einem Scrum Team zu starten, bis das Team und die Organisation ausreichend Erfahrungen über die neue, agile Kultur gesammelt haben und die verantwortlichen Entscheider den nächsten Schritt einleiten. Dies reduziert auch das Risiko einer Fehlentwicklung.

2. Verbesserung der Zusammenarbeit in den Teams

Das skalierte Arbeiten von mehreren Teams an einem Produkt erfordert die Einführung von agilen Praktiken. Besonders hohes Gewicht haben die Praktiken, welche den Teams die Abstimmung untereinander erleichtern. Die ersten Teams müssen als Vorreiter für die restliche Organisation noch sehr viel experimentieren. 

Sind die Teams tatsächlich entkoppelt von dem Rest der Organisation, können sie entsprechend schnell Fortschritte darin machen. Das lässt sich in einem überschaubaren Rahmen schneller und mit weniger Risiko bewerkstelligen.

3. Veränderungen der Unternehmensstruktur

Weiteres Wachstum der agilen Organisation bedeutet eine Umstrukturierung über alle Ebenen. Spätestens jetzt muss der Initiator der Veränderung das Management involvieren. Alle Ebenen zwischen Teams und Unternehmensspitze werden in Frage gestellt – und die Organisationsstruktur wird sehr schlank. Dies ist wohl der “schmerzhafteste” Teil des Prozesses, insbesondere für das Management.

4. Verschiebung der Unternehmenskultur

Durch Anwendung der Scrum und LeSS Rahmenwerke und passenden agilen Praktiken in allen Bereichen der Unternehmung ergibt sich ein organisationsweites Erlernen der agilen Kultur. Der Prozess kommt niemals zum Stillstand, da es keine optimale agile Organisation gibt.

Eine Agile Transition mit Scrum, LeSS und LeSS Huge bedarf einer weitsichtigen Strategie. Sie sollte daher mit entsprechender Beratung und Ausbildung begleitet werden.