Nach dem Scrum Guide Update war es nur eine Frage der Zeit, bis der Nexus Guide ein Update erfährt. Pünktlich zum neuen Jahr ist es soweit, der Nexus Guide 2021 ist da! Neben den naheliegenden Aktualisierungen, welche vom Scrum Guide Update einfließen, beinhaltet dieser Nexus Guide 2021 einige weitreichende Änderungen:
- Weniger Vorschriften
- Erklärung von spezifischer Terminologie
- Ergänzender Theorieabschnitt
Motiviert werden die Änderungen durch das Leitmotiv des neuen Nexus Guides.
Das Leitmotiv des neuen Nexus Guides
Zur Erinnerung: Das Scrum Framework definiert eine Regel, welcher Scrum Teams folgen: Liefere jedem Sprint ein wertvolles und nutzbares Inkrement, welches das Sprint-Ziel realisiert. Das Inkrement ist das Vehikel, um Wert zum Kunden zu bringen. Es ist der Haupttreiber für Transparenz, Inspektion und Anpassung und ermöglicht somit Empirie. Stellt sich bei der Einhaltung dieser Regel ein Hindernis in den Weg, managen Scrum Teams die Beseitigung des Hindernisses selbst.
Nexus ist ein Framework, um Scrum zu skalieren, d.h. mehrere Scrum Teams arbeiten gemeinsam an einem Produkt. Es basiert auf dem Grundprinzip: Skaliertes Scrum bleibt Scrum. Somit gilt die Regel auch für den Nexus und dessen Scrum Teams. Sie lautet: Liefere jedem Sprint ein wertvolles, nutzbares und integriertes Inkrement, welches das Nexus-Sprint-Ziel realisiert.
Stellt sich bei der Einhaltung dieser Regel ein Hindernis in den Weg, managt der Nexus die Beseitigung des Hindernisses selbst. Selbstmanagement passiert, wenn vorgeschrieben wird, was erreicht werden soll, und nicht, wie es erreicht werden soll. Und das ist Leitmotiv des Nexus Guide 2021 Updates: Weniger Vorschriften, um mehr Selbstmanagement zu ermöglichen!
Weniger Vorschriften
Nexus-Events beschreiben nur mehr Zweck und Ergebnis
Einerseits ist der Nexus Guide 2021 klarer geschrieben, andererseits lässt er dem Nexus mehr Freiraum für Selbstmanagement. Das wurde möglich, indem die Events im Nexus Guide nur durch den Zweck und das gewünschte Ergebnis beschrieben sind. Dies lässt sich am Beispiel des Nexus Sprint Plannings veranschaulichen:
Der Zweck des Nexus Sprint Plannings ist es, die Aktivitäten aller Scrum Teams für den nächsten Sprint zu koordinieren. Dem Zweck folgt eine Aufzählung von Ergebnissen, welche nach dem Nexus Sprint Planning erstellt sein müssen:
- Ein Nexus-Sprint-Ziel und Sprint-Ziele der einzelnen Scrum Teams
- Ein Nexus Sprint Backlog und Sprint Backlogs der einzelnen Scrum Teams
Die Kombination aus Klarheit und Freiraum hebt hervor, dass es im Nexus nicht um die einzelnen Scrum Teams geht, sondern um den Nexus als Ganzes. Die Scrum Teams bilden eine Einheit, den Nexus!
Jedes Nexus-Event folgt dem Prinzip: Der Nexus hat Vorrang
Wie können die Events im Nexus strukturiert werden, um dieser Einheit Rechnung zu tragen? In Ansätzen kennen wir das bereits aus dem Nexus Daily Scrum. Es folgt dem Prinzip: Der Nexus hat Vorrang.
Die individuellen Scrum Teams tragen die Probleme und Aufgaben, die während des Nexus Daily Scrum identifiziert wurden, danach zurück in die individuellen Scrum Teams, um sie dort während des Daily Scrum Events entsprechend einzuplanen. -- Nexus Guide 2018
Der neue Guide hebt dieses Prinzip noch einmal stärker hervor:
Das Daily Scrum jedes Scrum Teams ergänzt das Nexus Daily Scrum durch die Erstellung eines Plans für den nächsten Tag, welcher sich hauptsächlich auf die während des Nexus Daily Scrum aufgeworfenen Integrationsprobleme konzentriert. -- Nexus Guide 2021
Und weitet es konsequent auf alle Nexus-Events aus. Im Nexus Sprint Planning wird es mit folgenden Satz auf den Punkt gebracht:
Entsprechende Vertreter aus jedem Scrum Team und der Product Owner treffen sich, um den Sprint zu planen. -- Nexus Guide 2021
Um sich auf teamübergreifende Probleme zu fokussieren, ergänzen die Sprint Retrospektiven der Scrum Teams die Nexus Sprint Retrospektive. Die drei als Sandwich Format bekannten Teile sind hingegen verschwunden.
Mit dieser Änderung erkennt der Nexus Guide an, dass Produktentwicklung komplex ist. Jede Implementierung des Nexus Frameworks ist verschieden. Best Practices, wie die Nexus-Events umzusetzen sind, kann es nicht geben! Bei komplexer Arbeit bewähren sich Prinzipien, welche den Anwendern helfen, Good Practices für ihren Kontext zu finden. Im Falle der Nexus-Events lautet das orientierende Prinzip für alle Anwender: Der Nexus als Einheit hat immer Vorrang!
Dieses Prinzip und die Fokussierung auf Zweck und Ergebnis ermöglichen den Nexus Anwendern, selbstständig die passende Struktur für die Nexus-Events zu wählen. Nun kommen auch Big-Room-Plannings, Sandwich Formate, Open Spaces oder ein String aus Liberating Structures in Frage.
Das Nexus Rahmenwerk ermöglicht mehr Selbstmanagement
Neben der groben Struktur, wie die Nexus-Events abzuhalten sind, finden sich im alten Nexus Guide auch noch Themen und Fragen, welche im Rahmen der Nexus-Events diskutiert werden können. Beim Nexus Daily Scrum finden wir beispielsweise:
- Wurde die Arbeit von gestern erfolgreich integriert? Falls nein, warum nicht?
- Welche neuen Abhängigkeiten wurden identifiziert?
- Welche Informationen müssen zwischen Teams im Nexus geteilt werden?
Diese Fragen werden häufig als Vorschriften aufgefasst und schränken dadurch den Nexus im Selbstmanagement ein. Um mehr Selbstmanagement zu ermöglichen, wird jetzt im Nexus Daily Scrum beschrieben, was in diesem Event erreicht werden soll:
Repräsentanten der Scrum Teams nehmen am Nexus Daily Scrum teil, überprüfen den aktuellen Status des integrierten Inkrements und identifizieren Integrationsprobleme und neu entdeckte teamübergreifende Abhängigkeiten oder Auswirkungen. -- Nexus Guide 2021
Insgesamt schreibt der neue Nexus Guide weniger vor. Praktiken, Formate, Fragen und Themen, wie sie im vergangenen Nexus Guide beschrieben wurden, sollten weiterhin verwendet werden, sind aber nicht Bestandteil des Frameworks. Ein Framework zeichnet sich eben dadurch aus, zu beschreiben, was zu tun ist und nicht wie es zu tun ist.
Erklärung von spezifischer Terminologie
Mitglieder des Nexus Integration Teams sind verantwortlich für die Integration
Die mit Abstand häufigste Frage in meinem Scaled Professional Scrum mit Nexus Training lautet: Wer sind die Mitglieder im Nexus Integrations Team? Im Training gebe ich gerne die Antwort: Die Richtigen!
Um konkreter zu werden, müssen wir uns den Zweck des Nexus Integration Teams vor Augen führen:
Das Nexus Integration Team ist dafür ergebnisverantwortlich, dass mindestens ein integriertes Inkrement (die gemeinsame, fertiggestellte Arbeit eines Nexus) am Ende jedes Sprints erzeugt wird. -- Nexus Guide 2021
Integration umfasst das Beheben aller technischen und nichttechnischen, teamübergreifenden Rahmenbedingungen, welche die Fähigkeit eines Nexus zur Lieferung eines ständig integrierten Inkrements behindern könnten. Neu ist, dass das Nexus Integration Team Bottom-up-Intelligence aus dem Nexus heraus verwenden sollte, um eine Lösung zu erreichen.
Das beantwortet die Frage, wer die Richtigen sind. "Aus dem Nexus heraus" bedeutet nämlich, dass die Mitglieder des Nexus Integration Teams Mitglieder der Scrum Teams sein sollten. "Bottom-up-Intelligence" beschreibt, dass diese Personen die erforderlichen Fähigkeiten und Kenntnisse besitzen, um die Integrationsprobleme zu lösen, mit denen der Nexus zu jedem Zeitpunkt konfrontiert ist.
"Zu jedem Zeitpunkt" bedeutet, dass das Nexus Integrations Team
- stabil sein muss, um alle aktuell bekannten Integrationsprobleme zu beheben, und
- dynamisch sein soll, um seine Zusammensetzung zu ändern, wenn ungeahnte Integrationsprobleme auftreten.
Die einzigen permanenten Mitglieder im Nexus Integrations Team sind der Product Owner und ein Scrum Master.
Scrum Teams entscheiden selbst, wer an den Nexus-Events teilnimmt
Nach Beantwortung der Frage, wer die Mitglieder des Nexus Integration Teams sein sollten, widmen wir uns der am zweit häufigsten Frage: Wer sollte an den Nexus-Events teilnehmen?
Das beantwortet jetzt der Nexus Guide 2021 so:
In skalierter Produktentwicklung ist es möglicherweise nicht für alle Mitglieder des Nexus praktikabel, sich zu beteiligen, um Informationen auszutauschen oder eine Einigung zu erzielen. Sofern nicht anders angegeben, werden Nexus-Events von allen Mitgliedern des Nexus besucht, die nötigt sind, um das beabsichtigte Ergebnis des Events am effektivsten zu erzielen. -- Nexus Guide 2021
Kurz gesagt: Die Scrum Teams entscheiden eigenständig, wer nötig ist, um die Ergebnisse der Events am effektivsten zu erzielen.
Cross-Team Refinement ergänzt die Scrum Team Refinements
Die Verfeinerung des Product Backlogs im skalierten Umfeld dient dem folgenden Zweck:
Sie hilft den Scrum Teams vorherzusagen, welches Team welche Product-Backlog-Einträge liefern wird und
identifiziert Abhängigkeiten zwischen diesen Teams.
Das ist erst mal nichts Neues, denn diese Beschreibung finden wir auch im alten Nexus Guide. Neu ist der Zusatz "Cross-Team". Das Cross-Team Refinement ist ein zusätzliches Event und muss nicht das Refinement der Scrum Teams ersetzen. Der neue Name soll dieser Verwirrung entgegenwirken, indem er den Zweck des Events kenntlich macht.
Diese Verbesserungen am Nexus Guide 2021 zeigen, wie klare Begriffe und Beschreibungen der Nexus-Events, mittels Zweck und Ergebnis, Selbstmanagement ermöglichen.
Nexus Theorie
Zweck des Nexus Frameworks ist, Wert zu skalieren
Der vergangene Nexus Guide hat einleitend mögliche Probleme aufgezählt, welche bei der Skalierung von Scrum auf die Developer zukommen können. Dazu gehören:
- Wie werden sie über Teamgrenzen hinweg zusammenarbeiten und kommunizieren?
- Wie werden sie ihre Arbeit integrieren und das integrierte Inkrement testen?
Das Update des Nexus Guide rückt den Zweck, wofür das Nexus Framework verwendet wird, an erste Stelle:
Das Ziel von Nexus ist es, den Wert zu skalieren, den eine Gruppe von Scrum Teams, die an einem einzelnen Produkt arbeiten, liefern kann. -- Nexus Guide 2021
Der einzige Grund, warum Scrum skaliert wird, ist: Mehr Wert zu liefern, als es ein einzelnes Scrum Team vermag!
Das Nexus Framework ermöglicht das, indem es
- die grundlegenden Bottom-up-Intelligence der Scrum Teams fördert,
- die empirische Prozesssteuerung des Scrum Framework aufrecht erhält und
- die auftretende Komplexität reduziert, mit der die Scrum Teams bei ihrer Zusammenarbeit konfrontiert sind, wenn sie mindestens einmal pro Sprint ein integriertes, wertvolles und nützliches Produktinkrement bereitstellen.
Nexus ein Framework, um Abhängigkeiten zu reduzieren
Skalierte Produktentwicklung ist komplex. Wie entsteht die auftretende Komplexität? Wie kann sie reduziert werden?
Auf diese Fragen gibt der Nexus Guide 2021 Antworten.
Die Komplexität bei der Skalierung von Scrum entsteht durch die dabei auftretenden Abhängigkeiten. Der vergangene Nexus Guide beschreibt folgende Abhängigkeitstypen:
- Anforderungen,
- Domänenwissen und
- Software- und Testartefakte.
Der neue Nexus Guide rückt deren Ursache in den Vordergrund: eine Nichtübereinstimmung zwischen Produktstruktur und Kommunikationsstruktur.
Diese Beziehung ist als Gesetz von Conway bekannt.
Durch Verwendung des Nexus Frameworks können diese Abhängigkeiten reduziert werden. Denn die Elemente im Framework bieten die Möglichkeit,
- Prozesse,
- Produktstrukturen und
- Kommunikationsstrukturen
zu ändern, um Abhängigkeiten zu verringern oder zu beseitigen. Prominente Beispiele hierfür sind das Cross-Team Refinement und das Nexus Daily Scrum. Diese beiden Events helfen, Abhängigkeiten zwischen Einträgen im Product Backlog zu inspizieren und zu eliminieren. Insbesondere ermöglichen sie dem Nexus die Reduzierung der Abhängigkeiten selbst zu managen.
Selbstmanagement schließt De-Skalierung mit ein
Damit der Nexus die Reduzierung der Abhängigkeiten selbst managen kann, nimmt der Nexus Guide ein wichtiges Vorgehen auf:
De-Skalierung, die Reduzierung der Anzahl der Personen, die an etwas arbeiten, kann eine wichtige Methode sein, um mehr Wert zu liefern. -- Nexus Guide 2021
Skalierung des gelieferten Werts erfordert nicht zwingend das Hinzufügen weiterer Personen oder Scrum Teams. Reduzierung von Personen kann ein hilfreiches Vorgehen sein, um mehr Wert zu liefern. Das mag auf den ersten Blick unintuitiv erscheinen, aber mehr Personen bedeuten zwangsläufig, dass die Anzahl der Kommunikationswege steigt, die an der Entscheidungsfindung beteiligt sind. Dies führt zu mehr Abhängigkeiten und steht dem Erzeugen von mehr Wert im Wege.
Fazit: Skaliertes Scrum bleibt Scrum und ermöglicht Selbstmanagement
Das Nexus Guide Update steht unter dem Leitmotiv:
Weniger Vorschriften, um mehr Selbstmanagement zu ermöglichen!
Das Nexus Framework ermöglicht dem Nexus noch besser der einen Regel, welcher er alles unterordnet, zu folgen: Liefere jedem Sprint ein wertvolles, nutzbares und integriertes Inkrement! Während sie mit anderen Scrum Teams zusammenarbeiten, bleiben die Teams in der Lage, ihre Arbeit selbst zu managen, um diese Regel einzuhalten.
Letztlich braucht es das Produktinkrement als Vehikel, um wirklich Wert zum Kunden liefern zu können. Darum geht es doch schlussendlich bei Agilität!
Wenn du mehr darüber erfahren willst, wie Scrum professionell skaliert wird, dann
👉 registriere dich für meinen Newsletter. 👈
Als Steward für Scaled Professional Scrum werde ich dich dort über die neusten Entwicklungen von skalierten Scrum informieren.