Mit dem Nexus™ Framework Scrum skalieren: Kontinuierliche Bereitstellung eines integrierten Produkts mit mehreren Scrum-Teams
By Kurt Bittner, Patricia Kong and Dave West
()
About this ebook
Die Autoren beschreiben, wie Teams mit Nexus™ unter Beibehaltung der Scrum-Kernprinzipien ein komplexes, plattformübergreifendes, softwarebasiertes Produkt in kurzen, häufigen Zyklen ohne Einbußen bei der Konsistenz oder Qualität und ohne unnötige zusätzliche Komplexität liefern können. Anhand einer ausführlichen Fallstudie wird dargestellt, wie das Framework beim Umgang mit typischen Herausforderungen der Skalierung, wie der Reduzierung von teamübergreifenden Abhängigkeiten oder dem Erhalt von Selbstorganisation und Transparenz unter den Teams, unterstützt. Im Einzelnen werden behandelt:
- Herausforderungen bei der Bereitstellung funktionierender, integrierter Produktinkremente mit mehreren Teams
- Entwicklung eines neuen oder Weiterentwicklung eines existierenden Produkts mit Nexus™
- Arbeiten mit dem Nexus Sprint Backlog, Ausführen des Nexus Daily Scrum sowie die Durchführung von effektiven Nexus-Sprint-Reviews und Nexus-Sprint-Retrospektiven zur kontinuierlichen Verbesserung
- Managen eines Nexus™, einschließlich Transparenz des Fortschritts, Verbesserung der Leistungsfähigkeit und des Durchsatzes sowie Beseitigung von EngpässenJeder, der Scrum nutzt, wird von diesem Buch profitieren!
Related to Mit dem Nexus™ Framework Scrum skalieren
Related ebooks
Nexus - Scrum für mehrere Teams (Aktualisiert für Scrum Guide V. 2020): Das Nexus-Framework verstehen und anwenden - Erfolgsfaktor im Einsatz von skaliertem Scrum - eine Vorbereitung auf die NexusTM - (SPS)-Zertifizierung Rating: 0 out of 5 stars0 ratingsRetrospektiven in der Praxis: Veränderungsprozesse in IT-Unternehmen effektiv begleiten Rating: 0 out of 5 stars0 ratingsScrum Master: Vorbereitung auf die PSM I Prüfung Rating: 0 out of 5 stars0 ratingsLeadership im Produktmanagement: Wie Sie Stakeholder und Entwicklungsteams effektiv führen Rating: 0 out of 5 stars0 ratingsNeue Geschichten vom Scrum: Von Führung, Lernen und Selbstorganisation in fortschrittlichen Unternehmen Rating: 0 out of 5 stars0 ratingsThe People's Scrum: Revolutionäre Ideen für den agilen Wandel Rating: 0 out of 5 stars0 ratingsAgiles Projektmanagement und Scrum: Praxishandbuch Agiles Arbeiten Rating: 0 out of 5 stars0 ratingsScrum. Schnelleinstieg (3. Aufl.) Rating: 0 out of 5 stars0 ratingsAgiles Produktmanagement mit Scrum: Erfolgreich als Product Owner arbeiten Rating: 3 out of 5 stars3/5Choose your WoW - Second Edition (GERMAN): A Disciplined Agile Approach to Optimizing Your Way of Working Rating: 0 out of 5 stars0 ratingsModellbasiertes Requirements Engineering: Von der Anforderung zum ausführbaren Testfall Rating: 0 out of 5 stars0 ratingsAgile Softwareentwicklung: Werte, Konzepte und Methoden Rating: 0 out of 5 stars0 ratingsMicroservices: Der Hype im Realitätscheck Rating: 0 out of 5 stars0 ratingsGeschichten vom Scrum: Von Sprints, Retrospektiven und agilen Werten Rating: 4 out of 5 stars4/5Scrum-Training: Der Praxisleitfaden für Agile Coaches Rating: 0 out of 5 stars0 ratingsAgil im ganzen Unternehmen: Wie Sie eine dynamische, flexible und kundenorientierte Organisation gestalten Rating: 0 out of 5 stars0 ratingsAgile Softwareentwicklung: Ein Leitfaden für Manager Rating: 0 out of 5 stars0 ratingsAgiles Projektmanagement: Scrum für Einsteiger Rating: 0 out of 5 stars0 ratingsSAFe® 4.6: Eine Anleitung zur lean agilen Revolution? Rating: 0 out of 5 stars0 ratingsSQL Server: Performanceprobleme analysieren und beheben Rating: 0 out of 5 stars0 ratingsScrum: Schnelleinstieg Rating: 0 out of 5 stars0 ratingsAgilität neu denken: Mit Flight Levels zu echter Business-Agilität Rating: 0 out of 5 stars0 ratingsKnigge für Softwarearchitekten Rating: 0 out of 5 stars0 ratingsScrum: Agiles Projektmanagement und Scrum erfolgreich anwenden Rating: 0 out of 5 stars0 ratingsCloud-Services testen: Von der Risikobetrachtung zu wirksamen Testmaßnahmen Rating: 0 out of 5 stars0 ratingsKanban: Der agile Klassiker einfach erklärt Rating: 0 out of 5 stars0 ratings
Software Development & Engineering For You
Programmieren lernen mit Python 3: Schnelleinstieg für Beginner Rating: 0 out of 5 stars0 ratingsDesign Thinking für Anfänger: Innovation als Faktor für unternehmerischen Erfolg Rating: 0 out of 5 stars0 ratingsProjektmanagement für Anfänger: Grundlagen, -begriffe und Tools Rating: 0 out of 5 stars0 ratingsLean Production - Grundlagen: Das Prinzip der schlanken Produktion verstehen und in der Praxis anwenden. Schlank zur Wertschöpfung! Rating: 0 out of 5 stars0 ratingsProjekt Unicorn: Der Roman. Über Entwickler, Digital Disruption und das Überleben im Datenzeitalter Rating: 0 out of 5 stars0 ratingsAutomatisiertes Testen: Testautomatisierung mit Geb und ScalaTest Rating: 0 out of 5 stars0 ratingsDas große Python3 Workbook: Mit vielen Beispielen und Übungen - Programmieren leicht gemacht! Rating: 4 out of 5 stars4/5Weniger schlecht Projekte managen: Ohne Krise zum Projekterfolg Rating: 0 out of 5 stars0 ratingsAgiles Projektmanagement: Scrum für Einsteiger Rating: 0 out of 5 stars0 ratingsAgiles Requirements Engineering und Testen Rating: 0 out of 5 stars0 ratingsSketchnotes in der IT: Abstrakte Themen mit Leichtigkeit visualisieren Rating: 0 out of 5 stars0 ratingsBessere Softwareentwicklung mit DevOps Rating: 0 out of 5 stars0 ratings3D-Drucken für Einsteiger: Ohne Frust 3D-Drucker selbst nutzen Rating: 0 out of 5 stars0 ratingsEinfach Python: Gleich richtig programmieren lernen Rating: 0 out of 5 stars0 ratingsModellbasiertes Requirements Engineering: Von der Anforderung zum ausführbaren Testfall Rating: 0 out of 5 stars0 ratingsAgiles Coaching als Erfolgsfaktor: Grundlagen des Coachings, um Agile Teams erfolgreich zu managen Rating: 0 out of 5 stars0 ratingsLean Management für Einsteiger: Erfolgsfaktoren für Lean Management – Lean Leadership & Co. als langfristige Erfolgsgaranten Rating: 0 out of 5 stars0 ratingsSoftwareentwicklungsprozess: Von der ersten Idee bis zur Installation Rating: 0 out of 5 stars0 ratingsDigital Painting Workbook Rating: 0 out of 5 stars0 ratingsAgile Spiele – kurz & gut: Für Agile Coaches und Scrum Master Rating: 0 out of 5 stars0 ratingsKompaktes Managementwissen: Die Grunstruktur agiler Prozesse Rating: 0 out of 5 stars0 ratingsEinfach Java: Gleich richtig programmieren lernen Rating: 0 out of 5 stars0 ratingsKanban für Anfänger: Grundlegendes über den Einsatz von Kanban in der Industrie und der Softwareentwicklung Rating: 0 out of 5 stars0 ratingsIT Wissensmanagement: Theorie und Praxis Rating: 0 out of 5 stars0 ratingsEbenen in Adobe Photoshop CC und Photoshop Elements - Gewusst wie Rating: 0 out of 5 stars0 ratingsZertifizierung für Softwarearchitekten: Ihr Weg zur iSAQB-CPSA-F-Prüfung Rating: 0 out of 5 stars0 ratingsKOMA-Script: Eine Sammlung von Klassen und Paketen für LaTeX 2e Rating: 0 out of 5 stars0 ratingsUML @ Classroom: Eine Einführung in die objektorientierte Modellierung Rating: 0 out of 5 stars0 ratings
Reviews for Mit dem Nexus™ Framework Scrum skalieren
0 ratings0 reviews
Book preview
Mit dem Nexus™ Framework Scrum skalieren - Kurt Bittner
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 Nexus-Framework