Über die Autoren:
Kurt Bittner ist Vizepräsident des Bereichs »Unternehmenslösungen« bei Scrum.org. Er verfügt über mehr als 35 Jahre Erfahrung in der Unterstützung von Teams bei der Bereitstellung von Software in kurzen Feedbackzyklen, als Entwickler, Produktmanager und Product Owner sowie als Branchenanalyst und organisatorischer Veränderungsagent. Er ist Autor von Büchern zu Software Engineering, vielen Blogs und Artikeln und hält regelmäßig Vorträge auf Konferenzen.
Patricia Kong ist Product Owner des Scrum.org-Programms für Unternehmenslösungen, einschließlich des Nexus-Frameworks. Sie leistet einen wesentlichen Beitrag zum Nexus-Framework und zum Evidence-Based Management-Framework. Sie leitete die Produktentwicklung, das Produktmanagement und das Marketing für verschiedene Unternehmen in USA und Europa und arbeitete im Bereich Business Development und Engagement Management für Forrester Research.
Dave West ist CEO und Product Owner bei Scrum.org. Er hält regelmäßig Vorträge auf großen Industriekonferenzen und ist ein viel gelesener Autor von Büchern, Blogs, Artikeln und Forschungsberichten. Er hat sowohl Produktentwicklungs- als auch Beratungsprojekte für multinationale Organisationen geleitet.
Übersetzer:
Stefan Zumbrägel ist Berater bei der it-agile GmbH in Hamburg. Er beschäftigt sich seit 2012 mit agilen Entwicklungsmethoden und ist Certified Scrum Professional (CSP). Seit 2013 hat er in verschiedenen Projekten mit unterschiedlichen Skalierungsansätzen gearbeitet. Seine Vision ist es, die agile Idee auch über die Softwareentwicklung hinaus (z.B. in die Schule oder die ehrenamtliche Gruppenarbeit) zu verbreiten.
|
Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+: www.dpunkt.plus |
Kontinuierliche Bereitstellung eines
integrierten Produkts mit mehreren Scrum-Teams
Mit einem Geleitwort von Ken Schwaber
Übersetzung aus dem Englischen von Stefan Zumbrägel
Übersetzung: Stefan Zumbrägel · stefan.zumbraegel@it-agile.de
Lektorat: Christa Preisendanz
Copy-Editing: Ursula Zimpfer, Herrenberg
Satz: Birgit Bäuerlein
Herstellung: Stefanie Weidner
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN: |
|
978-3-86490-576-6 |
|
978-3-96088-684-6 |
|
ePub |
978-3-96088-685-3 |
mobi |
978-3-96088-686-0 |
Copyright © der deutschen Ausgabe 2019
dpunkt.verlag GmbH
Wieblinger Weg 17 · 69123 Heidelberg
Authorized translation from the English language edition, entitled NEXUS FRAMEWORK FOR SCALING SCRUM, THE. CONTINUOUSLY DELIVERING AN INTEGRATED PRODUCT WITH MULTIPLE SCRUM TEAMS, 1st Edition by KURT BITTNER, PATRICIA KONG, DAVE WEST, published by Pearson Education, Inc, publishing as Addison-Wesley Professional, Copyright © 2018 Scrum.org
ISBN 9780134682662
Nexus™ diagram and derivative images copyright © Scrum.org and used with permission.
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc.
German language edition published by DPUNKT.VERLAG GMBH, Copyright © 2018
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.
5 4 3 2 1 0
Für die Mitglieder der Community professioneller Scrum-Trainer, von denen wir jeden Tag lernen.
Dieses Buch ist großartig. Es beginnt mit einer einfachen Anwendung des Nexus-Frameworks und beschreibt dann den Einsatz in immer komplexeren Situationen. Die Autoren erläutern die Komplexität, die Probleme, die daraus entstehen, und wie man das Nexus-Framework anwenden kann, um ihnen zu entgegnen. Die Ideen dazu führen sie in einer Fallstudie zusammen. Dabei unterstützt sie der Nexus Guide, der ultimative Wissensschatz.
Aber warum gibt es Nexus überhaupt?
Scrum ist ein Framework, das einem Team den Rahmen bietet, ein komplexes Problem anzugehen, um in kurzer Zeit ein wertvolles Produktinkrement zu schaffen. Seit über 27 Jahren hat sich Scrum in vielen Anwendungen bewährt.
Scrum ist nur für ein einzelnes Team konzipiert. Situationen erfordern es jedoch oft, dass mehrere Teams mit unterschiedlichen Fähigkeiten zusammenarbeiten, um Wert zu schaffen. Die Organisationen wollen dabei auf dem ursprünglichen Scrum-Framework aufbauen.
Im Laufe der Jahre habe ich mit Hunderten von Organisationen zusammengearbeitet, die sich an den Rahmen und die Werte von Scrum gehalten haben, während ich den Einsatz auf Dutzende, Hunderte und sogar Tausende von Menschen skaliert habe, die zusammenarbeiten, um ein einzelnes Ergebnis zu erstellen.
Viele andere Anwender von Scrum haben dies ebenfalls getan. Dadurch, dass wir unsere Vorkenntnisse eingebracht haben, wurde ein Großteil der Produktivität und des Werts von Scrum beibehalten.
Basierend auf meinen Erfahrungen und denen anderer, mit denen ich bei Scrum.org zusammenarbeite, habe ich ein definiertes Framework für die Arbeit vieler Scrum-Teams an einem einzelnen Produkt oder Problem entwickelt. Das Ergebnis ist Nexus, ein Exoskelett, das auf vielen Scrum-Teams beruht. Nexus stellt Informationen und Managementwissen zur Verfügung, um die Zusammenarbeit der Teams zu begleiten. Dabei wird möglichst viel Produktivität beibehalten, Methoden zur Produktivitätssteigerung werden beschrieben und auch Lösungsansätze zur Fehlerbehebung aufgezeigt.
Lesen und erfahren Sie mehr. Scrum on.
Ken Schwaber
Unser Ziel beim Schreiben dieses Buches war simpel: Menschen, die bereits mit Scrum vertraut sind, eine einfache, aber leistungsfähige Möglichkeit aufzuzeigen, wie die gleichen Scrum-Konzepte auf Produkte angewendet werden können, die den Einsatz von mehr als einem Team erfordern. Mehr als 12 Millionen Menschen nutzen Scrum täglich, und viele von ihnen arbeiten in großen Teams. Nexus wurde entwickelt, um die Bedürfnisse dieser Menschen zu erfüllen, und obwohl es von vielen Organisationen bereits verwendet wird, gab es noch kein Buch, das es beschreibt. Wir hoffen, dass die Leser nach der Lektüre in der Lage sein werden, Nexus anzuwenden, um ihre Scrum-Praktiken zu skalieren und vielleicht sogar zu verbessern. Wie wir gerne sagen: »Skaliertes Scrum ist immer noch Scrum.«
Jeder, der Scrum nutzt, wird von diesem Buch profitieren. Denn irgendwann werden Sie feststellen, dass ein einzelnes Scrum-Team nicht mehr ausreicht, um Ihr Produkt zu liefern. Das Hinzufügen von zusätzlichen Teams klingt einfach, aber nicht gemanagte Abhängigkeiten zwischen Teams überfordern einen rein intuitiven Ansatz schnell. Dieses Buch wird jedem Teammitglied helfen, Nexus besser zu verstehen. Neben Scrum-Teams werden auch Stakeholder dieses Buch hilfreich finden, um die Herausforderungen zu verstehen, die mit der Verwendung eines Multi-Team-Ansatzes einhergehen. Zusätzlich wird es ihnen helfen, die Teams, mit denen sie zusammenarbeiten, besser zu unterstützen.
In diesem Buch gehen wir davon aus, dass Sie bereits mit dem Scrum-Framework vertraut sind. Aufbauend auf diesem Wissen wird erklärt, wie man Scrum skaliert, um ein komplexeres Produkt unter Einsatz des Nexus-Frameworks zu entwickeln.
Kapitel 1, »Einführung in agile Skalierung«, macht genau das. Es führt Sie in den Einsatz von agilen Vorgehensmodellen in Kontexten ein, in denen mehr als ein Scrum-Team an einem Projekt arbeitet.
Kapitel 2, »Einführung in Nexus«, erläutert die Grundprinzipien und Konzepte hinter dem Nexus-Framework, inklusive wann Sie es benötigen und was für den Start erforderlich ist.
Kapitel 3, »Einen Nexus aufsetzen«, konzentriert sich darauf, wie ein Nexus um ein Produkt herum gestaltet wird, auch wenn dieses Produkt erst einmal nur aus einer Idee ohne Team besteht. Für existierende Produkte und Teams beschreiben wir, wie man Teams im Rahmen der Einführung von Nexus hinzufügt. Wir beschreiben auch, wie die Scrum-Teams in einem Nexus organisiert werden und wie Sie Abhängigkeiten im Product Backlog erkennen und minimieren können.
Kapitel 4, »Planen in Nexus«, konzentriert sich auf die Organisation der Arbeit im Nexus-Framework: Beschaffen, Verfeinern und Validieren eines großen Backlogs, um Geschäftsziele zu erreichen, das Setzen von Zielen und die Planung eines Sprints.
Kapitel 5, »Einen Nexus Sprint durchführen«, fokussiert auf die Arbeit innerhalb des Nexus-Frameworks während des Sprints: Arbeiten mit dem Nexus Sprint Backlog, Ausführen des Nexus Daily Scrum, Durchführung des Nexus-Sprint-Reviews sowie der Nexus-Sprint-Retrospektive.
Kapitel 6, »Nexus weiterentwickeln«, behandelt das Managen eines Nexus, einschließlich der Berichterstattung über den Fortschritt, der Verbesserung der Leistungsfähigkeit und des Durchsatzes sowie der Beseitigung von Engpässen.
Kapitel 7, »Nexus im Notfallmodus«, befasst sich damit, wie das Nexus-Framework Organisationen bei der Bewältigung typischer Skalierungsprobleme hilft. Das beinhaltet die Unterstützung verteilter Teams bei der Zusammenarbeit und beim Umgang mit Hindernissen, die dem entgegenstehen.
Kapitel 8, »Retrospektive zur Nexus-Reise«, reflektiert den typischen Weg, den Teams und Organisationen gehen, wenn sie Scrum skalieren. Es beschreibt, wie das Nexus-Framework mit seinen Elementen sie auf dieser Reise beim Umgang mit den typischen Herausforderungen, mit denen sie zu tun haben, unterstützt. Es wird auch aufgezeigt, wie die Reise fortgesetzt werden kann hin zu einer Verbesserung der Fähigkeit, komplexe Anwendungen bereitzustellen.
Wir hatten viel Unterstützung und Rückhalt beim Schreiben dieses Buches. Zuerst möchten wir uns bei Ken und Christina Schwaber bedanken für ihre Unterstützung, Ermutigung und ihren Blick darauf, wie Nexus sich aus Scrum entwickelt hat. Außerdem danken wir Ken Schwaber und Jeff Sutherland für die Entwicklung von Scrum selbst, worauf Nexus basiert. Das Nexus-Framework existiert, weil ein gleichgesinntes Team von Menschen zusammenkam, um seine Erfahrungen in etwas umzusetzen, das in Form des Nexus Guide mit jedem geteilt werden konnte.
Wir sind auch der »Professional Scrum Trainer«-Community zu Dank verpflichtet, deren Mitglieder sich wertvolle Zeit nahmen, um mit ihren durchdachten Vorschlägen und akribischer Kritik zur Verbesserung des Buches beizutragen. Für ihre umfangreichen Beiträge danken wir Peter Götz, Jesse Houwing, Richard Hundhausen, Ralph Jocham, Mikkel Toudal Kristiansen, Rob Maher, Jeronimo Palacios und Steve Porter. Unser Dank gilt auch Eric Naiburg, dessen sorgfältiger Autorenblick uns geholfen hat, Ideen einfacher und effektiver auszudrücken, und Sabrina Love, die unser Cover gestaltet hat.
Schließlich wäre dieses Buch nicht möglich gewesen ohne die Unterstützung des Teams von Pearson/Addison-Wesley, insbesondere unseres Lektors Chris Guzikowski, Chris Zahn, der uns beim Schreiben gecoacht hat, unserer Herstellerin Julie Nahil und unserer Korrektorin Stephanie Geels, die uns alle geholfen haben, das Werk, das Sie gerade lesen, zu verbessern und zu veröffentlichen.
Kurt, Patricia und Dave
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
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
Agile Softwareentwicklung hat, um den von Geoffrey Moore populär gemachten Begriff zu verwenden, »die Schlucht überwunden«.1 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.
Agile Softwareentwicklungspraktiken sind nicht neu. Scrum ist jetzt schon mehr als 20 Jahre alt2 und das Agile Manifest wurde vor mehr als 15 Jahren unterzeichnet3. 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.4
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.
Laut einer Studie von Forrester Research verwenden 90% der agilen Teams Scrum.5 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.6
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.
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.
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.7
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.8
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.9
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 Nexus10, 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.
