Die Erfinder von LeSS, Craig Larman und Bas Vodde, erkannten rasch, dass es natürliche Grenzen für Skalierungsansätze gibt. Will man einem einzigen Product Owner die Verantwortung für ein umfangreiches Produkt übertragen, so stößt man auf die kognitive Grenze der Übersicht. Das bedeutet, je größer ein Produkt ist und je komplexer die Teile davon sind, desto schwieriger wird es für eine einzelne Person, die Übersicht zu behalten. Somit wird es auch schwieriger, die Sortierung wertoptimiert durchzuführen.

LeSS Huge

LeSS soll das Minimum an Prozess darstellen. Die Koordination von mehr als acht Teams benötigt jedoch auch mehr Prozess. Statt LeSS mit optionalen Elementen zu "verunreinigen", entstand mit LeSS Huge ein zweites Framework für noch größere Vorhaben. LeSS Huge baut auf LeSS auf und definiert weitere Regeln, um sehr große Produktentwicklungsvorhaben agil umsetzen zu können. LeSS Huge wird als passend für Vorhaben mit mehr als acht Teams erachtet, wobei acht keine magische Zahl ist, sondern ein aus vielen Jahren Beobachtung resultierender Erfahrungswert der Autoren von LeSS.

Ebenfalls stößt man bei sehr umfangreichen Produkten an die Grenzen der effektiven Kommunikation. Wird ein Produkt z.B. von 120 Teams gleichzeitig entwickelt, sind gemeinsame Meetings aller Teams kaum mehr möglich und auch logistisch schwer durchführbar.

In der Praxis kommt es aber sehr selten vor, dass Produkte von mehr als 20 bis 30 Teams entwickelt werden. Ist das der Fall, kann über eine Gliederung des Produkts in mehrere Teilprodukte oder Produktlinien nachgedacht werden. Grundsätzlich geht LeSS bei der Produktdefinition von "je breiter desto besser" aus, allerdings muss Rücksicht auf die organisatorische Machbarkeit genommen werden.

Regeln in LeSS Huge

Regeln für Strukturen in LeSS Huge

1. Kundenanforderungen, die aus der Sicht des Kunden eine starke Gemeinsamkeit aufweisen, werden zu Anforderungsbereichen (Requirements Areas) zusammengefasst. Dadurch können Synergien und Fokus entstehen und bei sehr großen Produktentwicklungen die Area Product Owners dem Product Owner dabei helfen, den Überblick zu behalten. Ein Nachteil von Areas ist die lokale Optimierung, die automatisch durch die eingeschränkte Fokussierung eines Area Product Owners und den Feature Teams in der Area basieren.
2. Jedes Team spezialisiert sich in einem Anforderungsbereich. Teams bleiben in diesem Anforderungsbereich für eine lange Zeit. Wenn ein anderer Anforderungsbereich wichtiger wird, können Teams dorthin wechseln.
3. Jeder Anforderungsbereich hat einen Area Product Owner.
4. Jeder Anforderungsbereich hat vier bis acht Teams. Weniger bedeutet zu viel lokale Optimierung, mehr bedeutet möglicherweise einen Verlust des Überblicks durch den Area Product Owner. Vermeide es diese Größenangabe zu verletzen (Ausnahmen sind die Anfangsphasen eines neuen Anforderungsbereichs, wenn sich erst nach und nach Teams dafür bilden oder diese dorthin wandern oder wenn ein Anforderungsbereich das Ende seiner Sinnhaftigkeit erreicht hat und die Teams in andere Areas wandern).
5. LeSS-Huge-Einführungen, inklusive der strukturellen Veränderungen, werden mit einem evolutionären und inkrementellen Ansatz durchgeführt. Inkrementell bedeutet in diesem Fall auf den Erkenntnissen der vorigen Teams aufbauend und nach dem Eintreten von Stabilität in der umgestellten Gruppe.
6. Bedenke: LeSS-Huge-Einführungen benötigen Monate oder Jahre, unendliche Geduld und eine Menge Humor.

Regeln für Produkte in LeSS Huge

1. Jeder Anforderungsbereich hat einen Area Product Owner.
2. Ein (overall) Product Owner ist für die produktweite Priorisierung und die Zuteilung der Teams zu den Anforderungsbereichen verantwortlich. Er arbeitet intensiv mit den Area Product Ownern zusammen.
3. Die Area Product Owner agieren als Product Owner gegenüber ihren Teams.
4. Es gibt nur einen Product Backlog und jedes Product Backlog Element (Eintrag im Product Backlog) gehört zu genau einem Anforderungsbereich.
5. Es gibt einen Area Product Backlog pro Anforderungsbereich. Dieser Backlog ist nur eine detailliertere (gefilterte) Ansicht auf den Product Backlog.

Regeln für Sprints in LeSS Huge

1. Es gibt einen produktweiten Sprint, nicht einen unterschiedlichen Sprint für jeden Anforderungsbereich. Er resultiert in ein integriertes Gesamt-Produktinkrement.
2. Der Product Owner und die Area Product Owner stimmen sich regelmäßig ab. Vor jedem Sprint Planning stellen sie sicher, dass die Teams an den wertvollsten Product Backlog Elementen arbeiten. Nach dem Sprint Review ermöglichen sie weitere Adaptierungen auf Produktebene.

Die Regeln von LeSS Huge ergänzen die Regeln von LeSS. LeSS Huge stellt somit eine Erweiterung von LeSS dar.

Drei Ansätze für eine erfolgreiche Einführung

Um LeSS erfolgreich einzuführen, ist es wichtig, drei Ansätze zu berücksichtigen:

1. Deep and Narrow over Broad and Shallow
2. Top Down und Bottom Up
3. Use Volunteering

Deep and Narrow over Broad and Shallow

Bei diesem Ansatz geht es um die Selektion der Organisationseinheiten und Teams, die für die Adoption vorgesehen sind. LeSS Huge empfiehlt den Schritt-für-Schritt Ansatz im Gegensatz zum "Big Bang", bei dem das gesamte Unternehmen nach einer langen Vorbereitung umgestellt wird. Die Einführung von LeSS mit bis zu acht Teams sollte auf einmal durchgeführt werden, da die Anzahl der beteiligten Personen überschaubar ist.

LeSS Huge Adoptions beginnen mit etwa 50 Personen in der Produktentwicklung. Vorteilhaft ist, dass dabei die Umstellung trotz der Größe des Gesamtvorhabens überschaubar bleibt. Es können Erfahrungswerte für die weiteren Organisationseinheiten genutzt werden. Mögliche Schwierigkeiten können so vor dem nächsten Schritt bereits eliminiert werden.