Dave

Inhaltsübersicht

1Einführung in agile Skalierung

2Einführung in Nexus

3Einen Nexus aufsetzen

4Planen in Nexus

5Einen Nexus Sprint durchführen

6Nexus weiterentwickeln

7Nexus im Notfallmodus

8Retrospektive zur Nexus-Reise

Anhang

Glossar

Index

Inhaltsverzeichnis

1Einführung in agile Skalierung

1.1Warum agil?

1.2Warum Scrum?

1.2.1Was ist ein Produkt?

1.2.2Was ist Scrum?

1.3Warum Nexus?

1.4Einfachheit ist der Schlüssel zur Skalierung

2Einführung in Nexus

2.1Was ist Nexus?

2.2Nexus erweitert Scrum

2.3Das Nexus-Integrationsteam

2.4Nexus-Ereignisse

2.4.1Refinement

2.4.2Nexus Sprint Planning

2.4.3Das Nexus Daily Scrum

2.4.4Das Nexus-Sprint-Review

2.4.5Die Nexus-Sprint-Retrospektive

2.4.6Fragen, die in jeder Nexus-Sprint-Retrospektive gestellt werden sollen

2.5Nexus-Artefakte

2.5.1Product Backlog

2.5.2Nexus-Ziel

2.5.3Nexus Sprint Backlog

2.5.4Integriertes Inkrement

2.5.5Transparenz der Artefakte

2.5.6»Definition of Done« im Nexus-Framework

2.6Was brauchen Sie, um mit Nexus zu beginnen?

2.7Fazit

3Einen Nexus aufsetzen

3.1Entwicklung eines cross-funktionalen Teams

3.1.1Praxis: Öffnen der Codebasis

3.1.2Praxis: Teams rund um Teile des Geschäftswerts bilden

3.1.3Praxis: Selbstorganisierte Teams bilden

3.2Einen Nexus wachsen lassen

3.2.1Klein anfangen und dann wachsen

3.2.2Aufbau von Scrum-Teams mit Pairing und »Praktikum«

3.2.3Warum nur drei bis neun Scrum-Teams in einer Nexus-Implementierung?

3.3Bildung des Nexus-Integrationsteams (NIT)

3.3.1Wer ist im Nexus-Integrationsteam?

3.4Wie funktioniert Nexus?

4Planen in Nexus

4.1Konsolidierung und Validierung des Product Backlogs

4.1.1Refinement des Product Backlogs

4.1.2Teamübergreifendes Product Backlog Refinement

4.1.3Abhängigkeiten von Product-Backlog-Elementen

4.1.4Optionale Praxis: Mit Story Mapping Fähigkeiten und Abhängigkeiten verstehen

4.1.5Optionale Praxis: Verwendung eines teamübergreifenden Refinement Board zum Verständnis von Abhängigkeiten

4.2Planung eines Sprints in Nexus

4.2.1Festlegung des Nexus-Ziels

4.2.2Schätzung und Dimensionierung von Product-Backlog-Elementen

4.2.3Optionale Praxis: Verbindung zwischen Product-Backlog-Elementen und Wertbeitrag

4.2.4Aufbau des Nexus Sprint Backlog und der Scrum-Team-Backlogs

Wie lange dauert das Sprint Planning?

4.3Fazit

5Einen Nexus Sprint durchführen

5.1Das Nexus Daily Scrum

5.2Transparenz innerhalb und außerhalb des Nexus schaffen

5.2.1Optionale Praxis: Product Backlog Treemap

5.2.2Optionale Praxis: Visualisierung von Product Backlog Burndown und Umsetzungsgeschwindigkeit

Wie viel Planungssicherheit ist ausreichend?

5.2.3Das Nexus-Sprint-Review

5.2.4Optionale Praxis: Verwendung des Expo-Formats für Nexus-Sprint-Reviews

5.2.5Optionale Praxis: Verwendung von Offline-Review-Techniken für Nexus-Sprint-Reviews

5.3Die Nexus-Sprint-Retrospektive

5.4Fazit

6Nexus weiterentwickeln

Warum Komponententeams zum Problem werden können

Entwicklungsteams in Scrum bestehen aus mehr als »Entwicklern«

6.1Optionale Praxis: Scrum-Teams um Features herum organisieren

6.2Optionale Praxis: Code wie in einem Open-Source-Projekt verwalten

6.3Optionale Praxis: Teams um Personas herum organisieren

6.4Erweiterung des Nexus-Integrationsteams

6.5Aktualisierung und Verfeinerung des Product Backlogs

6.6Nexus Sprint Planning, Teil zwei

6.7Das Nexus Daily Scrum, Teil zwei

6.8Das Nexus-Sprint-Review, Teil zwei

6.9Die Nexus-Sprint-Retrospektive, Teil zwei

6.9.1Zu viel Arbeit, nicht genug Fortschritt

6.9.2Wachsende technische Schulden

6.9.3Nicht verfügbarer Product Owner

6.9.4Unzureichende Build- und Testautomatisierung

6.9.5Einen Plan zur Verbesserung erstellen

6.9.6Die Herausforderungen bei der Skalierung von Scrum

6.10Fazit

7Nexus im Notfallmodus

7.1Product Backlog Refinement, Teil drei

7.2Das Nexus Sprint Planning, Teil drei

7.2.1Gestaltung und Moderation von weit verteilten Sprint-Planning-Terminen

7.2.2Nexus mit gemischter Hardware-/Softwareentwicklung

7.2.3Zusammenarbeit von Teams mit verschiedenen Sprint-Längen

7.2.4Mischen von Scrum- und Wasserfall-Ansätzen in Nexus

7.3Das Nexus Daily Scrum, Teil drei

7.3.1Das Nexus Daily Scrum mit verteilten Teams

7.4Was tun, wenn jeder im Nexus mit Schwierigkeiten zu kämpfen hat?

Verantwortlichkeit des NIT

7.4.1Das Nexus-Integrationsteam im Notfallmodus

7.4.2Rückskalierung

7.4.3Mit einem Gesundheitscheck die Gefühlslage des Teams erkennen

7.4.4Scrumbling

7.5Das Nexus-(Pseudo-)Sprint-Review und die Retrospektive

7.6Fazit

8Retrospektive zur Nexus-Reise

8.1Was gut funktioniert hat

8.1.1Das Nexus Daily Scrum

8.1.2Das Nexus-Integrationsteam (NIT)

8.1.3Releasehäufigkeit

8.1.4Produktivität

8.1.5Selbstorganisation

8.2Bereiche für Verbesserungen

8.2.1Umgang mit technischen Schulden

8.2.2Skalierung der Product-Owner-Rolle

8.2.3Entwicklung persönlicher Fähigkeiten

8.2.4Transparenz und Vertrauen

Scrum-Werte

8.3Wie geht’s weiter?

8.4Fazit

Anhang

Glossar

Index

1Einführung in agile Skalierung

Agile Softwareentwicklung hat, um den von Geoffrey Moore populär gemachten Begriff zu verwenden, »die Schlucht überwunden«.¹ Niemand spricht heute mehr darüber, ob agile Softwareentwicklung relevant ist. Die heutigen Diskussionen konzentrieren sich darauf, wann und wo sie eingesetzt werden sollte. In großen Organisationen führen diese Diskussionen häufig zu Fragen über Skalierung. Niemand stellt die Frage, ob agile Ansätze für einzelne, kleine und am selben Standort arbeitende Teams gut funktionieren, sondern die Diskussion dreht sich direkt um die Frage, ob der Ansatz auch für eine große Produktentwicklung mit vielen Teams verwendet werden kann.

In diesem Buch geht es um die Skalierung von Scrum mit dem Nexus-Framework, das von einem der Miterfinder von Scrum entwickelt wurde. Im Laufe des Buches werden wir diskutieren, warum Skalierung schwierig ist und wie man diese Herausforderungen bewältigen kann. In diesem kurzen Kapitel wird erklärt, warum agiles Vorgehen wichtig ist, warum Scrum wichtig ist und warum Nexus der einfachste und unserer Meinung nach der beste Weg ist, Scrum zu skalieren.

1.1Warum agil?

Agile Softwareentwicklungspraktiken sind nicht neu. Scrum ist jetzt schon mehr als 20 Jahre alt² und das Agile Manifest wurde vor mehr als 15 Jahren unterzeichnet³. Neu ist, dass Software in jeder Branche eine disruptive Kraft geworden ist und Unternehmen zu agilen Ansätzen übergegangen sind, um innovative softwarebasierte Lösungen anbieten zu können.⁴

Agile Softwareentwicklungspraktiken ermöglichen es Teams, schneller einen höheren Geschäftswert zu erzielen, indem sie die Zusammenarbeit verbessern und einen empirischen Prozess nutzen, um Geschäftsergebnisse zu überprüfen, anzupassen und zu optimieren. Im heutigen wettbewerbsintensiven Geschäftsumfeld sind langfristige Planungen und mehrjährige Projekte häufigen Releases gewichen. Der agile »Überprüfen und Anpassen«-Ansatz (Inspect & Adapt) passt hierfür sehr gut.

1.2Warum Scrum?

Laut einer Studie von Forrester Research verwenden 90% der agilen Teams Scrum.⁵ Der Schlüssel zu dieser Popularität liegt in der Tatsache, dass Scrum nichts vorschreibt, sondern ein Framework ist, das auf einer Reihe von Prinzipien und Werten basiert. Es besteht aus drei Rollen (Product Owner, Scrum Master und Entwicklungsteam), fünf Ereignissen (Sprint, Sprint Planning, Daily Scrum, Sprint-Review und Sprint-Retrospektive) und drei Artefakten (Product Backlog, Sprint Backlog und Produktinkrement). Dadurch lässt sich das Framework sehr gut an verschiedene Situationen anpassen.⁶

Die Stärke von Scrum liegt in der Einfachheit. Das Framework konzentriert sich auf ein einzelnes Team, das ein einzelnes Produkt erstellt. Es besteht nur aus drei Rollen: einen Product Owner, der sich auf die Geschäftsziele konzentriert, ein Entwicklungsteam, das das Produkt entwickelt, und einen Scrum Master, der dem Product Owner und dem Entwicklungsteam unter anderem durch Training, Coaching und Moderation hilft, diese Ziele zu erreichen. Obwohl Scrum leicht verständlich ist, erfordert die Beherrschung von Scrum den Willen und die Einsatzbereitschaft, mit alten Gewohnheiten zu brechen und neue zu etablieren.

1.2.1Was ist ein Produkt?

Viele Organisationen sind es noch immer gewohnt, in Projekten zu denken. Ein Projekt ist ein Vorhaben mit einer endlichen Länge, einem klar definierten Beginn, einem bestimmten Leistungsumfang und in der Regel einem definierten Enddatum.

Im Gegensatz dazu ist ein Produkt langlebig und oft ohne definiertes Ende. Die Nutzung von Projekten zur Lieferung und Unterstützung von Produkten führt zu vielen Problemen, nicht zuletzt auch zu einer Tendenz der Stakeholder, möglichst viele Anforderungen einzubringen, da nicht sicher ist, ob es eine »nächste« Version geben wird.

In den meisten Organisationen werden Projekte als Kostenquellen betrachtet, während Produkte als Quellen des Geschäftswerts angesehen werden. Der Wechsel von der Projektentwicklung zu einer Produktentwicklung verändert häufig auch die Auffassung darüber, was Entwicklungsteams tun. Aus reinen Unterstützern werden aktive Treiber und Gestalter des Wertschöpfungsprozesses.

Damit es sich lohnt, ein Produkt zu entwickeln, muss es anders finanziert und verwaltet werden. Produkte erfordern regelmäßige Releases, um den sich ständig ändernden Bedürfnissen der Nutzer gerecht zu werden. Produkte benötigen ein dediziertes Team, das das Produkt über eine Reihe von Releases hinweg entwickelt und unterstützt, und sie erfordern, dass es aus Sicht des Produktteams keinen Unterschied zwischen Wartung, Neuentwicklung und Verbesserungen gibt.

1.2.2Was ist Scrum?

Scrum ist ein Framework, das Teams dabei unterstützt, mit komplexen und sich verändernden Problemen umzugehen, um ein Produkt mit dem höchstmöglichen Wert zu liefern. Viele Unternehmen setzen Scrum bereits seit Anfang der 90er-Jahre erfolgreich ein.

Scrum basiert auf der Theorie der empirischen Prozesskontrolle, auch Empirie genannt. In der Empirie wird davon ausgegangen, dass Wissen aus Erfahrung und aus Entscheidungen entsteht, die auf der Grundlage von etwas Bekanntem getroffen werden.

Scrum verwendet einen iterativen, inkrementellen Ansatz, um durch kontinuierliches Lernen die Vorhersagbarkeit zu verbessern und Risiken zu beherrschen. Drei Säulen tragen jede Implementierung der empirischen Prozesskontrolle: Transparenz (Transparency), Überprüfung (Inspection) und Anpassung (Adaptation). Es gibt mehr als 12 Millionen Menschen, die Scrum aktiv anwenden, und die Zahl der Anwender wächst täglich.⁷

Obwohl es möglich ist, einige Scrum-Techniken für die Projektarbeit einzusetzen, konzentriert sich Scrum grundsätzlich auf die Produktentwicklung.

Die Kernelemente des Scrum-Frameworks sind in Abbildung 1–1 dargestellt.⁸

Abb. 1–1Das Scrum-Framework

Es gibt jedoch realistische Grenzen für das, was ein einzelnes Scrum-Team erreichen kann. Organisationen mögen versucht sein, einfach mehr Leute zum Team oder mehr Teams zum Produkt hinzuzufügen, um eine höhere Geschwindigkeit zu erzielen, aber die jahrzehntelange praktische Erfahrung hat gezeigt, dass dies kontraproduktiv ist.⁹

1.3Warum Nexus?

Einige Produkte – manche würden argumentieren die meisten Produkte – sind zu komplex, um von einem einzigen Scrum-Team geliefert zu werden. Beispiele hierfür sind Autos oder andere physische Produkte mit Kombinationen aus Hard- und Software oder sehr komplexe Softwareprodukte, die die koordinierte Arbeit vieler Scrum-Teams erfordern. Andere Produktentwicklungen stehen unter Zeitdruck, was bedeutet, dass mehr Funktionen in kurzer Zeit bereitgestellt werden müssen, als ein Team liefern kann.

Angesichts dieser Herausforderungen benötigen Unternehmen mehr als ein Scrum-Team, um an einem Produkt zu arbeiten. Mehrere Scrum-Teams, die gemeinsam ein einzelnes Produkt entwickeln, haben oft Schwierigkeiten, in jedem Sprint ein »fertig« (»done«) integriertes Ergebnis zu erstellen, da die Komplexität der Abhängigkeiten in der Größenordnung ansteigt. Anzeichen dafür, dass die Komplexität so groß ist, dass sie einer effektiven Produktentwicklung im Wege steht, sind zum Beispiel einzelne Teams, die ihre individuellen Ergebnisse anstelle eines integrierten Produkts im Sprint-Review präsentieren, Teams, die eine Reihe von sogenannten »Sicherungs-«Sprints benötigen, um mit den aufgebauten technischen Schulden fertig zu werden, oder die Notwendigkeit eines Integrationsteams, um die Arbeit anderer Teams zusammenzuführen.

Das Nexus-Framework unterstützt dabei, diese Probleme zu lösen, indem es Unternehmen in die Lage versetzt, größere Produktentwicklungsinitiativen (insbesondere solche, die eine umfangreiche Softwareentwicklung erfordern) mit Scrum zu planen, zu starten, zu skalieren und zu verwalten. Nexus ermöglicht es mehreren Scrum-Teams, die an einem einzelnen Produkt arbeiten, sich zu einer einzigen größeren Einheit, dem Nexus¹⁰, zusammenzuschließen.

Nexus kann als eine Art »Exoskelett« betrachtet werden, durch dessen Struktur die Scrum-Teams geschützt und gestärkt werden, indem es die Verbindungen und Abhängigkeiten zwischen den Teams vereinfacht und managt sowie transparente Einblicke in die Zusammenarbeit der Teams bietet. Transparenz und Kommunikation zu fördern, um die Skalierung so einheitlich wie möglich zu halten, bildet die Grundlage des Nexus-Frameworks. Mit Nexus die Skalierung von Scrum auf größere, komplexere Produkte immer noch Scrum.

1.4Einfachheit ist der Schlüssel zur Skalierung

Der Schlüssel zur Skalierung von Agilität für die Arbeit in vielen Teams liegt darin, Abhängigkeiten zwischen diesen Teams zu reduzieren oder zu beseitigen. Nexus bietet einige einfache Erweiterungen für Scrum, um Teams dabei zu unterstützen, genau das zu tun. In den weiteren Kapiteln dieses Buches werden wir diese Erweiterungen detaillierter behandeln. Ergänzend beschreiben wir Praktiken, die Unternehmen dabei helfen, bessere Produkte effektiver zu liefern. Nach einer kurzen Beschreibung von Nexus im nächsten Kapitel wird sich der Rest des Buches auf die Erörterung verschiedener Aspekte von Nexus anhand einer Fallstudie konzentrieren. Und nun wollen wir ohne weitere Einführung in Nexus einsteigen.

2Einführung in Nexus

In diesem Kapitel beschreiben wir das Nexus-Framework in seiner Gesamtheit. Wie Sie sehen werden, handelt es sich bei Nexus um eine relativ kleine und einfache Erweiterung von Scrum. Wie gesagt: »Skaliertes Scrum ist immer noch Scrum.« Scrum selbst ist recht einfach, zumindest einfach zu verstehen. Bei der Skalierung ist diese Einfachheit ein großer Vorteil, denn Komplexität ist der Gegenspieler zur Skalierung. Die Einfachheit von Nexus macht das Framework auch sehr anpassungsfähig, wie wir in den folgenden Kapiteln sehen werden.

2.1Was ist Nexus?

Nexus ist ein Framework, das es mehreren Scrum-Teams ermöglicht, ausgehend von einem einzigen Product Backlog, gemeinsam zu arbeiten und mindestens ein »fertiges« integriertes Inkrement pro Sprint zu liefern. »Mehrere« bedeutet typischerweise drei bis neun Scrum-Teams. Warum nicht zwei? Zwei Teams können sich in der Regel ohne zusätzliche Struktur untereinander abstimmen. Warum neun? So wie Scrum empfiehlt, Teams auf maximal neun Mitglieder zu beschränken, um den Zusammenhalt zu verbessern und die Komplexität zu reduzieren, empfiehlt Nexus dasselbe für die Anzahl der Teams. Genau wie bei Scrum ist diese Obergrenze jedoch nicht absolut und es kann, abhängig von den Rahmenbedingungen, auch noch mit einer größeren Anzahl funktionieren. Bei der Arbeit mit Nexus haben wir festgestellt, dass die Komplexität der Zusammenarbeit und die Koordination zwischen den Teams deutlich ansteigen, wenn die Zahl der Teams über neun hinausgeht. In solchen Fällen kommen verschiedene andere Techniken zum Einsatz.¹

Da Nexus auf Scrum aufbaut, werden seine Bestandteile denjenigen vertraut sein, die Scrum bereits verwendet haben. Der Unterschied besteht darin, dass den Abhängigkeiten und der Kommunikation zwischen den Scrum-Teams mehr Aufmerksamkeit geschenkt wird (siehe Abb. 2–1).

Abb. 2–1Das