LeSS ist ein leichtgewichtiges, agiles Framework zum Skalieren von Scrum für mehr als ein Team. Ab 2005 entwickelten Bas Vodde und Craig Larman das LeSS-Framework, nachdem sie Scrum-Prinzipien und -Regeln in Großprojekten angewendet hatten. Ihr Ziel war es, große Projekte erfolgreich zu entwickeln und dabei innerhalb der Grenzen von Scrum zu bleiben.
LeSS baut auf den Scrum-Prinzipien wie Empirie , funktionsübergreifende selbstverwaltende Teams auf und bietet einen Rahmen, um dies in großem Maßstab anzuwenden. Es bietet einfache Strukturregeln, Leitfäden und Experimente zur Einführung von Scrum in der groß angelegten Produktentwicklungsumgebung. LeSS hat nur wenige Regeln und zwei Frameworks: LeSS und LeSS Huge.
- LeSS Basic: 2–8 Teams
- Weniger riesig: 8+ Teams
Der Unterschied liegt in der Größe der insgesamt beteiligten Teams. Basic LeSS besteht aus zwei bis acht Teams mit jeweils acht Personen, die an derselben Produktentwicklung arbeiten. LeSS Huge umfasst bis zu 2.000 und mehr Personen, die an derselben Produktentwicklung arbeiten. Mit anderen Worten, wie groß möchten Sie groß sein? LeSS kann Scrum nach oben oder unten skalieren, um in vielen Umgebungen zu funktionieren.
LeSS-Framework
Die folgende Abbildung veranschaulicht das Grundgerüst von LeSS. Die Anzahl der Entwicklungsteams variiert zwischen zwei und acht. Ein Product Owner deckt bis zu acht Teams ab und jeder Scrum Master betreut bis zu drei Teams.
Im LeSS-Framework gibt es einen Product Owner und ein Product Backlog für das komplette auslieferbare Produkt. Der Product Owner sollte nicht alleine an der Verfeinerung des Product Backlogs arbeiten; Sie wird von den zahlreichen Entwicklungsteams unterstützt, die direkt mit Kunden/Benutzern und anderen Beteiligten zusammenarbeiten. Die gesamte Priorisierung erfolgt durch den Product Owner, aber die Klärung kann direkt zwischen den Teams und Kunden/Benutzern und anderen Beteiligten erfolgen.
Während ein Großteil von LeSS dem Ein-Team-Scrum-Framework treu bleibt, sind die Unterschiede wichtig:
- Die Sprintplanung ist in zwei Teile aufgeteilt: Teil 1 gilt für alle Teams und Teil 2 für jedes Team.
- Die Sprintplanung (Teil 1) ist auf eine Stunde pro Woche Sprintlänge begrenzt. Obwohl nicht alle Entwickler zur Teilnahme verpflichtet sind, werden sie nicht entmutigt, und mindestens zwei Mitglieder pro Sprint-Team nehmen zusammen mit dem Product Owner teil. Die repräsentativen Teammitglieder gehen dann zurück und teilen ihre Informationen mit ihren jeweiligen Teams.
- Unabhängige Sprint-Planung (Teil 2) und Daily Scrums finden statt, und Mitglieder aus verschiedenen Teams können an Meetings der anderen teilnehmen, um den Informationsaustausch zu erleichtern.
- Teamübergreifende Koordination wird von den Teams entschieden, wobei dezentralisierte und informelle Koordination gegenüber zentralisierter Koordination bevorzugt wird. Der Schwerpunkt liegt auf informellen Netzwerken, die teamübergreifende Gespräche, Komponenten-Mentoren, Reisende, Scouts und offene Räume beinhalten.
- Die Backlog-Verfeinerung wird für das gesamte Produkt-Backlog mit Vertretern aus jedem Entwicklungsteam und dem Product Owner durchgeführt. Die individuelle Team-Backlog-Verfeinerung findet auch auf der individuellen Teamebene statt, aber die Multi-Team-Backlog-Verfeinerung findet in jedem Sprint statt und ist die Schlüsselpraxis in LeSS.
- Sprint Reviews werden mit Vertretern jedes Teams und dem Product Owner durchgeführt.
Scrum vs. LeSS-Framework
Basic LeSS ist einem Ein-Team-Scrum sehr ähnlich, nur erweitert. In LeSS gibt es ein Product Backlog, einen Product Owner, eine Definition of Done, einen gemeinsamen Sprint und ein PSP-Inkrement (Potentially Shippable Product) am Ende des Sprints. Da alle Teams an der Implementierung desselben Produkts arbeiten, sind alle Teams funktionsübergreifend mit wenigen, wenn überhaupt, Spezialteams. Zusammenfassend arbeiten alle Teams daran, in jedem Sprint ein gemeinsames, auslieferbares Produkt zu liefern.
Es gibt Unterschiede zwischen regulärem Scrum und LeSS. In LeSS erfolgt die Sprintplanung separat in zwei Meetings. In einem Meeting trifft sich der Product Owner mit Vertretern aller Teams, die untereinander verwalten, um zu entscheiden, welche Product Backlog Items sie im nächsten Sprint erledigen werden. Einige der gleichen Arbeiten können mit zwei oder mehr Teams geteilt werden. Das zweite Treffen, das parallel oder kurz nach dem ersten stattfindet, ist ein Treffen aller Mitglieder jedes Teams. Zu Koordinierungszwecken können die Teamsitzungen in verschiedenen Abschnitten desselben Bereichs, aber separat abgehalten werden. Diese Anordnung ist hilfreich, wenn zwei Teams, die während des nächsten Sprints an denselben Aufgaben arbeiten, möglicherweise Fragen haben oder eine Klärung durch das andere Team benötigen.
LeSS Riesiges Framework
LeSS Huge baut auf dem LeSS-Framework auf, indem es für acht oder mehr Teams optimiert wird. Mit LeSS Huge sind der Größe des Projektteams keine Grenzen gesetzt. Ein paar tausend Menschen könnten an einem Projekt arbeiten. LeSS Huge führt mehrere neue Konzepte und Herausforderungen für die Verwaltung umfangreicher Backlogs ein. Dies sind Anforderungsbereiche, Bereichsproduktrückstände und Bereichsproduktbesitzer.
Die Scrum-Teams sind in große Kundenanforderungsbereiche unterteilt. Jeder Bereich hat einen Area Product Owner und vier bis acht Scrum-Teams. (Mindestens vier Teams in jedem Anforderungsbereich verhindern zu viel lokale Optimierung und Komplexität.) Ein Gesamt-Product-Owner und mehrere Area-Product-Owner bilden das Product-Owner-Team. Die folgende Abbildung veranschaulicht das LeSS Huge-Framework.
Wie in Scrum und kleineren LeSS haben Sie ein Produkt, eine Definition of Done, einen (Bereichs-)Product Owner und einen Sprint. LeSS Huge ist ein Stack von LeSS für jeden Anforderungsbereich. Jeder Anforderungsbereich verwendet LeSS, und die Menge aller Anforderungsbereiche befindet sich in LeSS Huge. Einige der Unterschiede sind
- Vor dem Sprint-Planungsmeeting findet ein Product-Owner-Planungsmeeting statt.
- Meetings auf Gebietsebene werden hinzugefügt. Sprint-Planung, Review und Retrospektive-Meetings werden auf Bereichsebene durchgeführt, und die Verfeinerung des Produkt-Backlogs auf Bereichsebene findet statt.
- Es werden allgemeine Sprint-Reviews und Retrospektiven durchgeführt, an denen alle Teams beteiligt sind. Diese Überprüfung koordiniert die Gesamtarbeit und den Prozess im gesamten Produktprogrammbereich.
LeSS ermöglicht die Implementierung von Scrum und Skalierung auf eine Weise, die größtenteils den agilen Prinzipien entspricht. Einige Elemente des Scrum-Frameworks werden durch empirisches Lernen, kurze Feedbackschleifen, Selbstorganisation und effektive Zusammenarbeit und Koordination aufrechterhalten.
In LeSS gibt es auch Führungsinstrumente für gute Entscheidungen, die den ROI maximieren; Wert für Kunden liefern; und schaffen Sie glückliche, nachhaltige Teams.
LeSS Basic vs. LeSS Huge
LeSS Huge ähnelt Basic LeSS, außer dass es aufgrund der Größe zwei oder mehr Area Product Owner gibt. Die Area Product Owner und der eine Gesamt-Product Owner bilden das Product-Owner-Team. Je nach Größe kann es auch zusätzliche Produktmanager geben.
Jeder Anforderungsbereich hat idealerweise vier bis acht Teams. Da die Arbeit unter Less Huge normalerweise aus mehreren Gebietsteams mit vier bis acht Teams besteht und Basic LeSS aus zwei bis acht Teams besteht, ist die grundlegende Funktionsweise der Teams unter Basic LeSS und LeSS Huge dieselbe.
Verwalten Sie Scrum mit Large-Scrum Canvas
Ihr Team kann ein agiles Tool verwenden, um die gesamte agile Projektmanagementsoftware mit Visual Paradigm zu automatisieren, um die Scrum-Projekteffizienz mit einem visuellen Prozess-Canvas zu maximieren, das für große Projekte entwickelt wurde.
Machen Sie eine kurze Tour für Large Scrum Canvas – Verwalten Sie Ihr gesamtes LeSS-Framework auf einer einzigen Seite.
Ressourcen:
English
简体中文
繁體中文
Deutsch
Español
Français
العربية
Italiano
Português
日本語
Nederlands
Русский