Large-Scale Scrum: Scrum erfolgreich skalieren mit LeSS

Von Craig Larman und Bas Vodde

Wie können wir agiles Arbeiten in großen, komplexen Organisationen skalieren? Eine Frage, die sich vielen Unternehmen stellt. Mit Large-Scale Scrum (LeSS) liegen nun zwei Frameworks (LeSS und LeSS Huge) vor, mittels derer Scrum konsequent ohne viel Zusatz skaliert werden kann, um als Unternehmen agil und überlebensfähig zu sein.

In diesem Buch haben Craig Larman und Bas Vodde ihre Erkenntnisse aus mehr als einem Jahrzehnt an Erfahrung in der Einführung von LeSS in groß angelegten Umgebungen gebündelt. Es sind konkrete Wegweiser entstanden, die dabei helfen, mehr Flexibilität durch weniger Komplexität, mehr Wert durch weniger Verschwendung und mehr Sinnhaftigkeit durch weniger Vorschriften im Unternehmen zu verankern.

Es werden u.a. folgende Themen adressiert:
- Implementierung von LeSS für die Entwicklung in großen Umgebungen
- Auswahl der richtigen Umsetzungsstrategie und des Organisationsdesigns
- Ausrichtung und Strukturierung einer großen Entwicklungsorganisation hin zum Kundennutzen
- Klärung der Rolle des Managements, des Product Owners und des Scrum Masters
- Skalierung von Produktdefinition, Anforderungen, Planung und Produktmanagement
- Synchrones Arbeiten mit mehreren Feature-Teams
- Koordination und Integration zwischen den Teams
- Integration von Scrum in Multisite- und Offshore-Projekten
- Skalierung von Design und Architektur

• Sprache: Deutsch
• Herausgeber: dpunkt.verlag
• Erscheinungsdatum: 5. Apr. 2017
• ISBN: 9783960881223

Buchvorschau

Inhaltsübersicht

1      More with LeSS

2      LeSS

Teil I      LeSS-Struktur

3      Einführung

4      Organisiere nach Kundennutzen

5      Management

6      Scrum Master

Teil II      LeSS-Produkt

7      Produkt

8      Product Owner

9      Product Backlog

10    Definition of Done

Teil III      LeSS-Sprint

11    Product Backlog Refinement

12    Sprint-Planung

13    Koordination & Integration

14    Review & Retrospektive

Teil IV      More or LeSS

15    Was kommt als Nächstes?

Anhang

A      Literaturempfehlungen

B      Regeln

C      Wegweiser

Index

Inhaltsverzeichnis

1 More with LeSS

Warum LeSS?

2 LeSS

Scrum mit einem Team

LeSS

▀   Vorgeschichte

▀   Experimente, Wegweiser, Regeln und Prinzipien

▀   LeSS-Prinzipien

▀   Zwei Frameworks: LeSS & LeSS Huge

LeSS-Framework

▀   LeSS-Framework – Zusammenfassung

▀   LeSS-Geschichten

▀   LeSS-Geschichte: Der Ablauf von Teams

▀   LeSS-Geschichte: Der Fluss von Einträgen

LeSS-Huge-Framework

▀   Requirement Areas

▀   Area Product Owner

▀   Area-Feature-Teams

▀   LeSS-Huge-Framework – Zusammenfassung

▀   LeSS-Huge-Geschichten

▀   LeSS-Huge-Geschichte: Eine neue Requirement Area

▀   Standortübergreifende Teams: Begriffe und Tipps

▀   LeSS-Huge-Geschichte: Standortübergreifende Teams

Ausblick

Teil I LeSS-Struktur

3 Einführung

Scrum mit einem Team

LeSS-Einführung

▀   LeSS-Regeln

▀   Wegweiser: Drei Einführungsprinzipien

▀   Wegweiser: Erste Schritte

▀   Wegweiser: Kultur folgt Struktur

▀   Wegweiser: Gesicherter Arbeitsplatz, aber keine gesicherte Rolle

▀   Wegweiser: Vision einer perfekten Organisation

▀   Wegweiser: Kontinuierliche Verbesserung

▀   Wegweiser: Skalierung der Einführung

LeSS Huge

▀   LeSS-Huge-Regeln

▀   Wegweiser: Evolutionäre inkrementelle Einführung

▀   Wegweiser: Nur eine Requirement Area gleichzeitig

▀   Wegweiser: Parallele Organisationen

4 Organisiere nach Kundennutzen

Scrum mit einem Team

Organisiere nach Kundennutzen in LeSS

▀   LeSS-Regeln

▀   Wegweiser: Baue teambasierte Organisationen auf

▀   Wegweiser: Feature-Teams verstehen

▀   Wegweiser: Feature-Team Adoption Maps

▀   Wegweiser: Bevorzuge Spezialisierung nach Kundengebiet

▀   Wegweiser: LeSS-Organisationsstruktur

▀   Wegweiser: Mehrere Standorte in LeSS organisieren

LeSS Huge

▀   LeSS-Huge-Regeln

▀   Wegweiser: Requirement Areas

▀   Wegweiser: Dynamiken von Requirement Areas

▀   Wegweiser: Übergang zu Feature-Teams

▀   Wegweiser: LeSS-Huge-Organisation

5 Management

Scrum mit einem Team

LeSS-Management

▀   LeSS-Regeln

▀   Wegweiser: Taylor und Fayol verstehen

▀   Wegweiser: Theorie-Y-Management

▀   Wegweiser: Manager sind optional

▀   Wegweiser: Die LeSS-Organisation

▀   Wegweiser: Go & See

▀   Wegweiser: Manager als Lehrer und Lernende

▀   Wegweiser: Sowohl fachliche als auch technische Kompetenz

▀   Wegweiser: LeSS-Metriken mit weniger Zielen

▀   Wegweiser: Literaturliste für das Management

6 Scrum Master

Scrum mit einem Team

LeSS Scrum Master

▀   LeSS-Regeln

▀   Wegweiser: Im Fokus des Scrum Masters

▀   Wegweiser: Fünf Scrum-Master-Werkzeuge

▀   Wegweiser: Großgruppenmoderation

▀   Wegweiser: Fördere Lernbereitschaft & ein breites Fähigkeitenspektrum

▀   Wegweiser: Community-Arbeit

▀   Wegweiser: Überlebenstipps für Scrum Master

▀   Wegweiser: Literaturliste für Scrum Master

▀   Wegweiser: Achte besonders auf ...

LeSS Huge

▀   Wegweiser: Vermeide Requirement-Area-Silos

Teil II LeSS-Produkt

7 Produkt

Scrum mit einem Team

LeSS-Produkt

▀   LeSS-Regeln

▀   Wegweiser: Was ist dein Produkt?

▀   Wegweiser: Definiere dein Produkt

▀   Wegweiser: Ausdehnen der Produktdefinition

▀   Wegweiser: Produkt über Projekt oder Programm

LeSS Huge

8 Product Owner

Scrum mit einem Team

Product Owner in LeSS

▀   LeSS-Regeln

▀   Wegweiser: Wer sollte Product Owner sein?

▀   Wegweiser: Starte früh oder unstrukturiert mit einem fingierten Product Owner

▀   Wegweiser: Wer sind diese Nutzer bzw

▀   Wegweiser: Priorisierung über Klärung

▀   Wegweiser: Tu es nicht

▀   Wegweiser: Helfer für Product Owner

▀   Wegweiser: Fünf Beziehungen

▀   Wegweiser: Zusammenarbeit mit dem Kunden über ...

▀   Wegweiser: Liefere mindestens jeden Sprint

▀   Wegweiser: Sei nicht nett

▀   Wegweiser: Lass los

▀   Wegweiser: Lass dir unerledigte Arbeit nicht zum Verhängnis werden

▀   Wegweiser: LeSS-Meetings

LeSS Huge

▀   LeSS-Huge-Regeln

▀   Wegweiser: LeSS Huge Product Owner

▀   Wegweiser: Area Product Owner

▀   Wegweiser: Product-Owner-Team unterstützt durch Scrum Master

9 Product Backlog

Scrum mit einem Team

Product Backlog in LeSS

▀   LeSS-Regeln

▀   Wegweiser: Nicht »Abhängigkeiten managen«, sondern Einschränkungen minimieren

▀   Wegweiser: Nimm nur ein Stückchen

▀   Wegweiser: Umgang mit Elternelementen

▀   Wegweiser: Umgang mit speziellen Einträgen

▀   Wegweiser: Werkzeuge für große Product Backlogs

▀   Wegweiser: Mehr Ergebnis, weniger Leistung

LeSS Huge

▀   LeSS-Huge-Regeln

▀   Wegweiser: Area Backlogs

▀   Wegweiser: Maximal drei Ebenen

▀   Wegweiser: Eine neue Area für eine gigantische Anforderung

▀   Wegweiser: Umgang mit gigantischen Anforderungen

10 Definition of Done

Scrum mit einem Team

LeSS Done

▀   LeSS-Regeln

▀   Wegweiser: Entwerfen der Definition of Done

▀   Wegweiser: Entwickle die Definition of Done

LeSS Huge

Teil III LeSS-Sprint

11 Product Backlog Refinement

Scrum mit einem Team

LeSS Product Backlog Refinement

▀   LeSS-Regeln

▀   Wegweiser: Arten von Product Backlog Refinement

▀   Wegweiser: Gesamt-PBR

▀   Wegweiser: Multiteam-PBR

▀   Wegweiser: PBR mit verteilten Standorten

▀   Wegweiser: Initiales PBR

▀   Wegweiser: Schneiden

▀   Wegweiser: Schätzung skalieren

LeSS Huge

12 Sprint-Planung

Scrum mit einem Team

LeSS-Sprint-Planung

▀   LeSS-Regeln

▀   Wegweiser: Sprint-Planung 1

▀   Wegweiser: Multiteam-Sprint-Planung 2

▀   Wegweiser: Keine Softwarewerkzeuge für das Sprint Backlog

LeSS Huge

▀   Wegweiser: Product-Owner-Team-Meeting

13 Koordination & Integration

Scrum mit einem Team

Koordination & Integration in LeSS

▀   LeSS-Regeln

▀   Wegweiser: Einfach reden

▀   Wegweiser: Koordinationsfreundliche Umgebung

▀   Wegweiser: Kommuniziere mittels Code

▀   Wegweiser: Integriere kontinuierlich

▀   Wegweiser: Communitys

▀   Wegweiser: Teamübergreifende Meetings

▀   Wegweiser: Multiteam-Design-Workshop

▀   Wegweiser: Workshop zur aktuellen Architektur

▀   Wegweiser: Komponentenmentoren

▀   Wegweiser: Open Space

▀   Wegweiser: Traveler

▀   Wegweiser: Scouts

▀   Wegweiser: Eher kein Scrum of Scrums

▀   Wegweiser: Ein führendes Team

▀   Wegweiser: Mischen und Verbinden von Techniken

LeSS Huge

14 Review & Retrospektive

Scrum mit einem Team

Sprint-Review & Retrospektiven in LeSS

▀   LeSS-Regeln

▀   Wegweiser: Adaptiere das Produkt früh und häufig

▀   Wegweiser: Review-Basar

▀   Wegweiser: Gesamtretrospektive

▀   Wegweiser: Verbessere das System

LeSS Huge

▀   LeSS-Huge-Regeln

▀   Wegweiser: Multi-Area-Reviews & -Retrospektiven

Teil IV More or LeSS

15 Was kommt als Nächstes?

Anhang

A Literaturempfehlungen

B Regeln

LeSS-Framework-Regeln

▀   LeSS-Struktur

▀   LeSS-Produkt

▀   LeSS-Sprint

LeSS-Huge-Framework-Regeln

▀   LeSS-Huge-Struktur

▀   LeSS-Huge-Produkt

▀   LeSS-Huge-Sprint

C Wegweiser

Index

1 More with LeSS

Die billigsten, schnellsten und verlässlichsten Komponenten sind die, die gar nicht da sind.

Gordon Bell

Warum LeSS?

Warum ist die Zahl von Scrum-Einführungen in den letzten zehn Jahren förmlich explodiert? Das war die Frage, mit der wir uns bei einem Bier in einer der großen Garküchen in Singapur beschäftigt haben.

Einige meinen, dass der Grund dafür in seinem einfachen Zertifizierungsmodell liegt. Mag sein. Aber eine andere agile Methode – DSDM (Dynamic Systems Development Method) – hat Zertifizierungen bereits vor Scrum angeboten und nie eine solche Verbreitung erfahren.

Andere wiederum sagen, dass das Angebot an Scrum-Master-Trainings den Unterschied gemacht hat. Ken Schwabers ursprüngliches Scrum-Master-Training hat sicher einen starken Einfluss gehabt, doch auch in diesem Kontext war eine andere agile Methode schneller: Extreme Programming hat das XP-Vertiefungstraining (»XP Immersion«) angeboten, was sich aber auch nicht so durchgesetzt hat.

Vielleicht ist es ja die Einfachheit von Scrum, die den Unterschied macht? Verglichen mit XP stellt Scrum ein deutlich einfacheres Framework zur Verfügung. Doch auch noch einfachere agile Methoden wie beispielsweise Crystal sind nicht wirklich durchgestartet.

Nach einigen weiteren Diskussionen und Gedanken schlug Craig vor:

Scrum trifft eine ideale Balance zwischen abstrakten Prinzipien und konkreten Praktiken.

Damit schlossen wir die Diskussion ab und tranken noch ein Bier. Diese konkreten Praktiken betonen die empirische Prozesskontrolle – ein elementares Scrum-Prinzip. Durch die empirische Prozesskontrolle unterscheidet sich Scrum von anderen agilen Frameworks. Der Scrum Guide bringt es auf den Punkt:

Scrum ist weder ein Prozess noch eine Technik zur Erstellung von Produkten, sondern ist vielmehr als Rahmenwerk zu verstehen, innerhalb dessen verschiedene Prozesse und Techniken zum Einsatz gebracht werden können. Scrum macht die relative Wirksamkeit Ihres Produktmanagements und Entwicklungsvorgehens sichtbar, so dass Sie sich verbessern können.

¹

Was bedeutet das? Mit empirischer Prozesskontrolle legen wir weder den Umfang des Produkts noch den Prozess, wie es herzustellen ist, fest. Stattdessen bauen wir in kurzen Zyklen kleine, auslieferbare Teile des Produkts. Wir inspizieren, was wir haben und wie es erstellt wurde. Dann überarbeiten wir das Produkt und die Art, wie es erstellt wurde – basierend auf dem, was wir in der Inspektion erkannt haben. Diese klare Inspektion wird durch die eingebauten Mechanismen zur Erzeugung von Transparenz ermöglicht.

Prinzipien klingen gut, sind aber offenbar nicht immer so leicht umsetzbar. Es ist diese kleine, einfache Menge an konkreten Praktiken, die es so einfach machen, mit Scrum zu starten: die klaren Rollen, Artefakte und Events.

Diese Praktiken erleichtern den Einstieg, sind aber bewusst »unvollständig«, sodass Gruppen genug Raum und Freiheiten innerhalb des Scrum-Frameworks haben, um kontinuierlich zu lernen und zu verbessern. Dies geschieht immer in dem vollen Bewusstsein, dass wir in Domänen von sehr hoher Komplexität arbeiten, für die festgelegte Prozessrezepte eine zu starke Vereinfachung sind.

Die konkreten Praktiken aus Scrum bilden den Ausgangspunkt für die Einführung seiner tieferen Prinzipien. Eine perfekte Balance.

Large-Scale Scrum (LeSS) erreicht die gleiche Balance für größere Produktgruppen. Es fügt ein bisschen mehr konkrete Struktur zu Scrum hinzu, deren Zweck es ist, Transparenz aufrechtzuerhalten und die »Inspect & Adapt«-Zyklen zu betonen, sodass Gruppen kontinuierlich ihre eigenen Arbeitsweisen verbessern können.

Genau wie Scrum ist LeSS bewusst unvollständig. Es lässt genug Raum für sehr viel situatives Lernen. Es bietet nicht viele endgültige Antworten. Wer nach schablonenhaften Antworten oder scheinbar sicheren, disziplinierten Ansätzen sucht, die die tröstliche Illusion von vorhersehbarer Kontrolle wie bei den definierten Prozessen bieten, wird mit LeSS wohl nicht glücklich werden. Diese Ansätze zerstören die Prinzipien von empirischer Prozesskontrolle und das Gefühl, Hoheit über die Prozesse und Praktiken zu haben.

Ein weniger definierter Prozess führt zu mehr Lernen. More with less (mehr durch weniger).

Inhalt Kapitel 2

»LeSS«

Scrum mit einem Team

LeSS

  Vorgeschichte

  Experimente, Wegweiser, Regeln und Prinzipien

  LeSS-Prinzipien

  Zwei Frameworks: LeSS & LeSS Huge

LeSS-Framework

  LeSS-Framework – Zusammenfassung

  LeSS-Geschichten

  LeSS-Geschichte: Der Ablauf von Teams

  LeSS-Geschichte: Der Fluss von Einträgen

LeSS-Huge-Framework

  Requirement Areas

  Area Product Owner

  Area-Feature-Teams

  LeSS-Huge-Framework – Zusammenfassung

  LeSS-Huge-Geschichten

  LeSS-Huge-Geschichte: Eine neue Requirement Area

  Standortübergreifende Teams: Begriffe und Tipps

  LeSS-Huge-Geschichte: Standortübergreifende Teams

Ausblick

Eine große Story Map während des initialen Product Backlog Refinement in LeSS

2 LeSS

Es gibt zwei Möglichkeiten für die Umsetzung eines [Designs]: Eine Möglichkeit ist es, die Umsetzung so einfach zu gestalten, dass es offensichtlich keine Mängel gibt, die andere Möglichkeit besteht darin, es so kompliziert zu machen, dass es keine offensichtlichen Mängel gibt.

C.A.R. Hoare

Scrum mit einem Team

Scrum ist ein Framework zur Entwicklung mittels empirischer Prozesskontrolle, in dem ein cross-funktionales, selbstgeführtes Team ein Produkt iterativ-inkrementell entwickelt.¹ In jedem zeitlich begrenzten (Timebox) Sprint wird ein potenziell auslieferbares Produktinkrement erstellt und idealerweise ausgeliefert. Ein Product Owner (ein einziger!) ist verantwortlich dafür, den Wert des Produkts zu maximieren, die Einträge im Product Backlog zu priorisieren und basierend auf konstantem Feedback und Lernen adaptiv zu entscheiden, was das Ziel eines jeden Sprints ist. Ein kleines Team ist gemeinsam dafür verantwortlich, das Sprint-Ziel zu liefern; es gibt hier keine limitierenden einzelnen Spezialistenrollen. Ein Scrum Master vermittelt, warum Scrum eingesetzt wird und wie man wertvolle Arbeit damit erzielen kann. Er coacht den Product Owner, das Team und die Organisation, wie man Scrum anwenden kann, und agiert als Spiegel. Es gibt keinen Projektleiter oder Teamleiter.

Empirische Prozesskontrolle braucht möglichst vollständige Transparenz, die durch die kurzen Entwicklungszyklen entsteht und die Begutachtung der auslieferbaren Produktinkremente. Es wird Wert gelegt auf kontinuierliches Lernen, Inspektion und Adaption hinsichtlich des Produkts und der Art und Weise, wie es erstellt worden ist. Scrum basiert auf dem Verständnis, dass die Entwicklung zu komplex und dynamisch ist für detaillierte, schablonenhafte Prozesskochrezepte, die eher dem Infragestellen, dem Engagement und der Verbesserung im Weg stehen.

Im Scrum Guide und dem Scrum Primer liegt die Betonung auf einem Team; der Fokus liegt nicht auf vielen Teams, die zusammen an einem Produkt arbeiten. Und das führt natürlich dazu, dass man über Large-Scale Scrum, also Scrum im Großen, nachdenkt.

LeSS

LeSS ist Scrum, angewandt auf viele Teams, die gemeinsam an einem Produkt arbeiten.

Siehe Kapitel

Einführung, S. 61

LeSS ist Scrum – Large Scale Scrum (LeSS)² ist kein neues und verbessertes Scrum. Und es ist nicht Scrum auf unterer Ebene für jedes Team mit etwas anderem oben draufgepackt. Es geht eher darum, herauszufinden, wie man die Prinzipien, den Zweck, die Elemente und die Eleganz von Scrum in einem skalierten Kontext anwendet, und das so einfach wie möglich. Genau wie Scrum und andere, wirklich agile Frameworks ist LeSS bewusst eine »eher unvollständige Methode«, um große Auswirkungen zu erzielen.

Skaliertes Scrum ist kein spezielles Skalierungsframework, das zufälligerweise Scrum nur auf Teamebene enthält. Echtes skaliertes Scrum ist Scrum skaliert.

Siehe Kapitel

Organisiere nach Kundennutzen, S. 87

... angewandt auf viele Teams

Cross-funktionale, komponentenübergreifende, »Full-Stack«-Feature-Teams von drei bis neun Personen, die auf Lernen fokussiert sind und alles machen – von UX über Code bis hin zu Videos –, um Einträge komplett fertigzustellen und ein auslieferbares Produkt zu erzeugen.

Siehe Kapitel

Koordination & Integration, S. 309

... die zusammenarbeiten

Die Teams arbeiten zusammen, da sie ein gemeinsames Ziel haben: ein gemeinsames, auslieferbares Produkt am Ende eines gemeinsamen Sprints auszuliefern. Und jedes Team kümmert sich darum, da sie Feature-Teams sind, die verantwortlich für das Ganze sind, nicht nur für einen Teil.

Siehe Kapitel

Produkt, S. 169

... an einem Produkt

Was für ein Produkt? Eine umfassende, komplette, von Anfang bis Ende gedachte kundenzentrierte Lösung, die von echten Kunden benutzt wird. Ein Produkt ist keine Komponente, Plattform, Schicht oder Bibliothek.

Vorgeschichte

2002, als Craig Agile & Iterative Development geschrieben hat, haben viele geglaubt, dass agile Entwicklung nur für kleine Teams gedacht war. Wie auch immer, wir beide (Craig und Bas) haben angefangen, uns dafür zu interessieren, wie Scrum in großen, verteilten und Offshore-Entwicklungen angewandt werden kann – und wir erhielten auch immer mehr Anfragen hierzu. So kam es, dass wir uns 2005 zusammengetan haben, um mit Kunden daran zu arbeiten, Scrum zu skalieren. Heute sind beide LeSS-Frameworks (LeSS und LeSS Huge) in großen Gruppen weltweit in unterschiedlichen Domänen eingeführt worden:

Telekommunikationsequipment – Ericsson & Nokia Networks³

Investment- und Handelsbanken – UBS

Handelssysteme – ION Trading

Marketingplattformen und Markenanalyse – Vendasta

Videokonferenzsysteme – Cisco

Onlinespiele (Wetten) – bwin.party

Offshore Outsourcing – Valtech India⁴

Was ist in Bezug auf groß ein typischer Fall einer LeSS-Einführung? Vielleicht fünf Teams an einem oder zwei Standorten. Wir waren in Einführungen von solcher Größenordnung involviert, in solche mit ein paar Hundert Leuten bis hin zu einem LeSS-Huge-Fall von weit über tausend Personen, viel zu vielen Entwicklungsstandorten, vieler Zehnmillionen Zeilen C++-Code mit kundenspezifischer Hardware.

Weitere Informationen zu LeSS

Um Menschen bei ihrer Weiterentwicklung zu unterstützen, haben wir, basierend auf unseren Erfahrungen mit Kunden, 2008 und 2010 zwei Bücher über die Skalierung von agiler Entwicklung mit dem LeSS-Framework veröffentlicht:

Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum – erklärt das Denken, die Führung und Veränderungen am organisatorischen Design.

Practices for Scaling Lean & Agile Development: Large, Multi-site & Offshore Product Development with Large-Scale Scrum – lässt teilhaben an Hunderten konkreten Experimenten für LeSS, basie-rend auf unserer Erfahrung mit Kunden; Experimente im Produkt-management, Architektur, Planung, verteilte Umgebungen, Offshore, Verträge und mehr.

Dieses Buch – Large-Scale Scrum: Scrum erfolgreich skalieren mit LeSS⁵ – ist das dritte in der LeSS-Serie, ein Vorgänger und Grundlagenbuch. Dieses Buch fasst zusammen, erklärt und hebt hervor, was am wichtigsten ist.

Neben diesem Buch findet man online auf http://less.works weitere Quellen zum Lernen (inklusive Buchkapitel, Artikel und Videos), Kurse und Coaching.

Experimente, Wegweiser, Regeln und Prinzipien

In den ersten beiden LeSS-Büchern wurde bereits hervorgehoben, dass es Dinge wie »Best Practices« in der Produktentwicklung nicht gibt. Es gibt nur Praktiken, die in einem bestimmten Kontext passend sind.

Praktiken sind situativ. Fröhlich zu behaupten, sie seien das »Beste«, trennt sie von der Motivation und dem Kontext, die sie jedoch erst zu dem machen, was sie sind. Ohne das werden sie zu Ritualen. Und sogenannte »Best Practices« hervorzuheben, tötet eine Kultur des Lernens, des Infragestellens, des Engagements und der kontinuierlichen Verbesserung. Warum würden Menschen das Beste anfechten?

Daher haben die früheren LeSS-Bücher die Leser an Experimenten teilhaben lassen, die wir und unsere Kunden ausprobiert haben. Wir bestärkten – und bestärken nach wir vor – diese Geisteshaltung. Allerdings beobachteten wir mit der Zeit auch zwei Probleme der Nur-Experimente-Geisteshaltung:

Unerfahrene Gruppen treffen ungeschickte Entscheidungen zu ihrem Nachteil und führen LeSS in einer Art und Weise ein, für die LeSS nicht gedacht war, mit offensichtlichen Problemen. Zum Beispiel gibt es Gruppen, die Requirement Areas mit nur einem Team erstellt haben. Autsch!

Unerfahrene Gruppen fragen: »Wo fangen wir an? Was ist das Wichtigste?« Verständlicherweise können sie die wesentlichen Grundlagen nicht sehen.

Aufgrund dieses Feedbacks haben wir nachgedacht und sind noch mal zum Shu-Ha-Ri-Modell des Lernens zurückgekommen: Shu – folge den Regeln, um die Grundlagen zu erlernen. Ha – breche die Regeln, um den Kontext zu erkunden. Ri – meisterhaftes Können und finde deinen eigenen Weg. In einer LeSS-Einführung auf Shu-Ebene sind nur wenige Regeln nötig für ein gerade mal ausreichendes Framework, um empirische Prozesskontrolle und einen ganzheitlichen Produktfokus anzukurbeln.⁶ Diese Regeln definieren die beiden LeSS-Frameworks, die schon bald vorgestellt werden.

Um später darauf aufzubauen und um es einmal zusammenzufassen, sind nachfolgend die Bestandteile von LeSS aufgeführt:

Regeln

Ein paar wenige Regeln genügen, um loszulegen und um das Fundament zu schaffen. Sie definieren die wesentlichen Elemente des LeSS-Frameworks, die vorhanden sein sollten, um empirische Prozesskontrolle und einen ganzheitlichen Produktfokus zu unterstützen, beispielsweise führe in jedem Sprint eine Gesamtretrospektive durch.

Wegweiser

Ein angemessener Satz an Wegweisern hilft dabei, die Regeln effektiv einzuführen, und gilt für eine Untermenge von Experimenten, die es wert sind, ausprobiert zu werden, da sie auf jahrelanger Erfahrung mit LeSS basieren. Wegweiser enthalten Tipps. In der Regel sind sie hilfreich und ein Bereich für kontinuierliche Verbesserung, beispielsweise die Drei Einführungsprinzipien.

Experimente

Viele Experimente sind sehr situativ und sind es nicht unbedingt wert, ausprobiert zu werden, beispielsweise der Versuch, bei der Entwicklung von multilingualen Anwendungen den Übersetzer im Scrum-Team zu verorten. Dieser Versuch könnte sich im Verhältnis Kosten zu Nutzen als eher nicht praktikabel herausstellen. Doch es gilt: Probieren geht über Studieren!

Prinzipien

Im Mittelpunkt steht ein Satz von Prinzipien – herausgezogen aus der Erfahrung mit LeSS-Einführungen –, die die Regeln, Wegweiser und Experimente prägen, beispielsweise ganzheitlicher Produktfokus.

Die LeSS-Wegweiser und Experimente sind optional. Die Wegweiser werden vermutlich hilfreich sein und wir empfehlen, diese auszuprobieren. Solche, die nicht passen oder die weitere Verbesserung eher einschränken, können Sie übergehen oder weglassen.

Ein guter Weg, LeSS zu betrachten, ist im LeSS-Gesamtbild visualisiert:

Das LeSS-Gesamtbild gibt den Weg vor, wie wir LeSS einführen:

LeSS-Prinzipien – kommen als Nächstes

LeSS-Frameworks (definiert durch die Regeln) – im Rest des Kapitels

LeSS-Wegweiser – in den nachfolgenden Kapiteln dieses Buches

LeSS-Experimente – stehen schon mit den ersten beiden LeSS-Büchern zur Verfügung

LeSS-Prinzipien

Die LeSS-Regeln definieren das LeSS-Framework. Diese Regeln sind jedoch minimalistisch und beantworten nicht die Frage, wie LeSS in einem spezifischen Kontext angewendet wird. Die LeSS-Prinzipien lie-fern die Basis für solche Entscheidungen.

Large-Scale Scrum ist Scrum

Es ist kein neues und verbessertes Scrum. Viel eher geht es in LeSS darum, herauszufinden, wie die Prinzipien, Regeln, Elemente und der Zweck von Scrum in einem großen, skalierten Kontext angewendet werden können, und zwar so einfach wie möglich.

Transparenz

Basiert auf greifbaren »fertigen« Einträgen, kurzen Zyklen, Zusammenarbeit, gemeinsamen Definitionen und dem Vertreiben von Angst am Arbeitsplatz.

More with less (mehr durch weniger)

Wir wollen nicht noch mehr Regeln aufstellen, da mehr Rollen zu weniger Verantwortlichkeit der Teams führen. Wir wollen nicht noch mehr Artefakte, da mehr Artefakte zu einer größeren Distanz zwischen Teams und Kunden führen. Wir wollen nicht noch mehr Prozess, da dies zu weniger Lernen und Teamhoheit über den Prozess führt. Statt dessen wollen wir mehr verantwortliche Teams durch weniger (LeSS-) Regeln. Wir wollen mehr kundenorientierte Teams, die sinnvolle Produkte bauen, indem sie weniger Artefakte haben. Wir wollen mehr Hoheit der Teams über den Prozess und mehr sinnhafte Arbeit durch einen weniger definierten Prozess. Wir wollen mehr durch weniger – »More with LeSS«.

Ganzheitlicher Produktfokus

Ein Product Backlog, ein Product Owner, ein auslieferbares Produkt, ein Sprint – egal, ob drei Teams oder 33 Teams. Kunden wollen wertvolle Funktionalität in einem zusammenhängenden Produkt, keine technischen Komponenten in einzelnen Teilen.

Kundenzentriert

Die Konzentration liegt darauf, die wirklichen Kundenprobleme zu verstehen und zu lösen. Identifizieren Sie Wert und Nutzlosigkeit aus Sicht des bezahlenden Kunden. Reduzieren Sie die Wartezeit aus seiner Perspektive. Erhöhen und verstärken Sie Feedbackschleifen mit echten Kunden. Jeder muss verstehen, wie sich seine tägliche Arbeit direkt auf den zahlenden Kunden auswirkt und wie dieser davon profitiert.

Kontinuierliche Verbesserung in Richtung Perfektion

Hier ist ein Perfektionsziel: Erstellen und liefern Sie ein Produkt möglichst jederzeit ohne zusätzliche Kosten und Fehler, das Kunden erfreut, zur Verbesserung der Umwelt beiträgt und das Leben lebenswerter macht. Seien Sie immer bescheiden und führen Sie radikale Verbesserungsexperimente durch, bis dieses Ziel erreicht ist.

Lean Thinking

Bauen Sie ein organisatorisches System auf, dessen Fundament aus Managern als Lehrer besteht, die Lean Thinking anwenden und vermitteln, die führen, um zu verbessern, die »Stop & Fix« fördern und die »Go & See«⁷ praktizieren. Fügen Sie die beiden Säulen, Respekt für den Menschen und Geisteshaltung hin zu einer Verbesserung durch kontinuierliches Infragestellen des Status quo, hinzu – alles zur Erreichung der Perfektion.

Systemisches Denken

Betrachten, verstehen und optimieren Sie das gesamte System⁸ (und nicht einzelne Teile davon) und verwenden Sie die Systemmodellie-rung, um Systemdynamiken zu erforschen. Vermeiden Sie lokale Teiloptimierungen durch Konzentration auf die Effizienz oder Produktivität von einzelnen Individuen oder Teams. Kunden interessieren sich für die Dauer und den Fluss des gesamten Zyklus »vom Konzept zu Cash«, nicht für individuelle Schritte, und lokale Optimierungen führen meist zur einer Verschlechterung des Gesamten.

Empirische Prozesskontrolle

Das bedeutet kontinuierliches Inspizieren und Adaptieren des Produkts, der Prozesse, der Verhaltensweisen, des organisatorischen Designs und der Praktiken, sich in situativ angemessenen Wegen zu entwickeln. Tun Sie dies, statt einem vorgeschriebenen Satz sogenannter Best Practices zu folgen, die den Kontext ignorieren, zu einem ritualisierten Befolgen führen, Veränderungen und Lernen behindern und den Sinn der Menschen für Engagement und Eigentum zermalmen.

Warteschlangentheorie

Verstehen Sie, wie Systeme mit Warteschlagen sich in einem Forschungs& Entwicklungsumfeld verhalten, und setzen Sie diese Erkenntnisse ein, um die Größen von Warteschlangen, Work-in-Progress(WIP)-Limitierungen, Multitasking, Arbeitspakete und Varianz zu managen.

Zwei Frameworks: LeSS & LeSS Huge

Large-Scale Scrum hat zwei Frameworks:

LeSS

zwei bis acht Teams

LeSS Huge

mehr als acht Teams

Das Wort LeSS bedeutet zweierlei: Es meint sowohl Large-Scale Scrum im Allgemeinen als auch das kleinere LeSS-Framework.

Die magische Zahl Acht

Eigentlich ist die Acht keine magische Zahl, und wenn Ihre Gruppe das kleinere LeSS-Framework mit mehr als acht Teams erfolgreich anwenden kann, wunderbar! Aber das haben wir nicht erlebt ... noch nicht. Diese Obergrenze hat sich einfach nur durch empirische Beobachtung ergeben. Und in einigen Fällen, z.B. unterschiedlich komplexen Zielen in verteilten Umgebungen mit unerfahrenen Teams, die jeweils nur ihre eigene Sprache sprechen, könnte es sein, dass diese Grenze bei weniger als acht liegt.

Es gibt auf jeden Fall einen Zeitpunkt,

an dem ein einziger Product Owner nicht mehr länger den Überblick über das gesamte Produkt erfassen kann,

der Product Owner nicht mehr den Ausgleich zwischen externem und internem Fokus schaffen kann und

das Product Backlog so groß ist, dass es für eine Person schwierig wird, damit zu arbeiten.

Trifft die Gruppe auf diesen Wendepunkt, könnte es Zeit werden für den Wechsel vom kleineren LeSS-Framework zum LeSS-Huge-Framework. Auf der anderen Seite schlagen wir vor, erst einmal zu versu-chen, besser, kleiner und einfacher zu werden, bevor man größer wird.

Gemeinsamkeiten beider Frameworks

Das LeSS- und das LeSS-Huge-Framework weisen gemeinsame Elemente auf:

Ein Product Owner und ein Product Backlog

Ein gemeinsamer Sprint über alle Teams

Ein auslieferbares Produktinkrement

Die folgenden zwei Abschnitte dieses Kapitels gehen mehr ins Detail der beiden Frameworks. Zunächst wird das kleinere LeSS-Framework erläutert, anschließend folgt LeSS Huge auf Seite 39.

LeSS-Framework

LeSS-Framework – Zusammenfassung

Das kleinere LeSS-Framework ist ausgelegt für einen (und nur für einen) Product Owner, dem das Produkt gehört und der ein Product Backlog verwaltet, an dem Teams in gemeinsamen Sprints daran arbeiten, das Gesamtprodukt zu verbessern. Die Elemente des LeSS-Frameworks sind ungefähr 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. Es ist entscheidend, dass diese Teams Feature-Teams sind – echte cross-funktionale, komponentenübergreifende »Full-Stack«-Teams, die zusammen an einer gemeinsamen Codebasis arbeiten, wo jedes Team alles macht, um fertige Einträge zu erstellen.

Artefakte

Ein potenziell auslieferbares Produktinkrement, ein Product Backlog und ein eigenes Sprint Backlog für jedes Team.

Events

Ein gemeinsamer Sprint für das gesamte Produkt. Dieser inkludiert alle Teams und endet in einem potenziell auslieferbaren Produktinkrement. Details hierzu kommen in den anstehenden Geschichten und in eigenen Kapiteln zur Sprache.

Regeln & Wegweiser

Regeln für ein gerade mal ausreichendes Skalierungsframework für empirische Prozesskontrolle und ganzheitlichen Produktfokus. Wegweiser könnten helfen.

LeSS-Geschichten

LeSS lernen

Ein Weg, etwas zu lernen, besteht darin, tiefgehende Erklärungen zu lesen, und Leser, die das bevorzugen, können problemlos alles bis zur Vorstellung des LeSS-Huge-Frameworks (S. 39) überspringen und von dort aus weiterlesen. Andere, die Geschichten mögen, können hier weitermachen.

Einfache Geschichten

Diese Geschichten handeln nicht von den Komplexitäten großer, skalierter Entwicklungen – von der Politik bis zur Priorisierung –, die wir durch Beratung erfahren. Wir widmen uns in späteren Kapiteln diesen Dingen. An dieser Stelle haben wir bewusst klare und einfache Geschichten ausgewählt, um nur die Grundlagen eines LeSS-Sprints vorzustellen. Wer auf der Suche nach einem aufregenden Dialog oder einem Drama ist, der sollte ein Lean-Buch lesen.

Regeln & Wegweiser

Bei den Geschichten wird Ihnen auffallen, dass die Randnotizen auf die dazugehörigen LeSS-Regeln und Wegweiser referenzieren, um für mehr Klarheit zu sorgen und Verbindungen herzustellen.

Zwei Perspektiven

Nachfolgend sind zwei zusammenhängende Geschichten mit zwei grundlegenden Perspektiven aufgeführt, um einige Abläufe einfacher vorzustellen:

Der Ablauf von Teams innerhalb eines LeSS-Sprints

Der Fluss von kundenzentrierten Einträgen (Features)

LeSS-Geschichte: Der Ablauf von Teams

Diese Geschichte konzentriert sich auf den Ablauf von Teams in einem Sprint und weniger auf den Fluss von Arbeitspaketen. In der Realität verbringt man den größten Teil der Zeit in einem Sprint mit entwicklungsbezogenen Aufgaben und weniger in Meetings. Wie auch immer, diese Geschichte betont die Meetings und die Interaktionen, da es das Ziel dieser Geschichte ist, zu verstehen, wie mehrere Teams in den LeSS-Events zusammenarbeiten und wie sie sich tagtäglich koordinieren.

Tipp

Wechsle die Stellvertreter in jedem Sprint.

Mark betritt den Raum, in dem sein Team (»Handel«) arbeitet, und sieht Mira⁹. »Guten Morgen!«, sagt sie, »nur zur Erinnerung: Wir sind die Stellvertreter unseres Teams in diesem Sprint und Sprint-Planung 1 beginnt in 10 Minuten.« »Richtig«, antwortet Mark, »Ich treffe dich gleich im großen Raum.«

Sprint-Planung 1

(Wegweiser: Sprint-Planung 1, S. 298)

Regel

Es gibt einen produktübergreifenden Sprint und nicht verschiedene Sprints für jedes Team.

Es ist Zeit für die gemeinsame Sprint-Planung 1. In einem großen Raum haben sich die zehn Stellvertreter von den fünf Teams aus dieser Produktgruppe verteilt. Alle arbeiten am Flagschiffprodukt zum Handel mit Anleihen und Derivaten. Sam, der Scrum Master der Teams »Handel« und »Marge«, ist ebenfalls anwesend. Er plant, das Event zu beobachten und ggf. zu coachen, sollte das nötig werden.

Früher, vor vielen Sprints war jedes Teammitglied aus allen Teams bei der Sprint-Planung 1 dabei. Das war zu dem damaligen Zeitpunkt auch wesentlich nützlicher, da die Gruppe nicht sehr gut darin gewesen war, Arbeitspakete aus dem Product Backlog klar und »fertig« zu bekommen oder überhaupt ein tieferes Wissen in den verschiedenen Teams entstehen zu lassen. In jenen Tagen wurde die Sprint-Planung 1 dazu verwendet, Antworten auf viele der wesentlichen Fragen zu lie-fern, die auch jeder hören musste. Die Sprint-Planung 1 wurde immer weiter verbessert, und verglichen mit damals wurde bis heute eine deutliche Verbesserung erzielt. Die Gruppen experimentieren mit dem Entsenden von wechselnden Stellvertretern, was dazu führte, dass die Sprint-Planung 1 ein einfaches und kurzes Meeting wurde, in dem nur ein paar unwesentliche Fragen geklärt werden, die immer mal wieder auftauchen. Sollte dieser neue Ansatz nicht so gut funktionieren, wird das mit Sicherheit in einer der Gesamtretrospektiven thematisiert werden, woraufhin dann ein neues Experiment zur Verbesserung der Sprint-Planung angegangen wird.

Regel

Die Sprint-Planung besteht aus zwei Teilen: Sprint-Planung 1 ist für alle Teams gemeinsam, wohingegen Sprint-Planung 2 typischerweise jedes Team für sich macht. Wenn man mehrere Teams hat, die an eng zusammenhängenden Dingen arbeiten, führt man mit diesen Teams eine gemeinsame Sprint-Planung 2 in einem gemeinsamen Raum durch.

Regel

An der Sprint-Planung 1 nehmen der Product Owner, die Teams oder deren Stellvertreter teil. Gemeinsam werden sie probeweise die Dinge auswählen, an denen jedes Team im kommenden Sprint arbeiten wird.

Paolo betritt den Raum und begrüßt alle mit einem »Hi!«. Er ist der Product Owner und der leitende Produktmanager.¹⁰ Paolo verteilt 22 Karten auf einem Tisch und sagt: »Hier sind die großen Themen: der Deutsche Markt, Auftragsverwaltung und ein paar regulatorische Berichte. Ich habe sie entsprechend meiner Priorisierung geordnet und ausgelegt. Ich denke, jeder hier versteht, warum die Prioritäten so sind, da wir das häufig genug in den Product Backlog Refinements diskutiert haben. Sollte jedoch etwas unklar sein, fragt bitte noch mal.«

Tipp

Teams wählen ihre Arbeitspakete selbst aus.

Mira und Mark gehen gemeinsam mit den anderen Stellvertretern um den Tisch herum und nehmen sich zwei Karten heraus, die mit Dingen zu tun haben, die den deutschen Anleihenmarkt betreffen. In den letzten beiden Sprints hat ihr Team diese Dinge durch Workshops zu Product Backlog Refinement (PBR) in Einzelteams im Detail geklärt.

Wegweiser

Multiteam-PBR, S. 273

Sie nehmen auch noch zwei weitere Karten, die mit der Auftragsverwaltung zu tun haben und die sowohl das Team »Handel« als auch das Team »Marge« relativ gut verstehen. Beide Teams haben in Multi-team-PBR-Workshops