Das Nexus-Framework in 9 einfachen Schritten erklärt
Bei der Skalierung von Scrum balancieren wir Kosten und Aufwand mit Nutzen und Vorteilen. Kosten und Aufwand werden durch zusätzliche Teams verursacht. Nutzen und Vorteile entstehen dadurch, mehr potentiellen Wert in gleicher Zeit zu liefern.
Scrum-Praktiker wissen, dass die Skalierung von Scrum mehr ist als nur eine Rechenaufgabe. Der gesunde Menschenverstand sagt uns, wenn Teams gemeinsam an einer einzigen Initiative arbeiten, wird es unvermeidlich zu Integrationskonflikten kommen. Diese Konflikte entstehen durch Abhängigkeiten. Wir wissen, dass es Disziplin und Mühe kostet, Abhängigkeiten transparent zu machen und sie zu beseitigen. Dieser Aufwand wird relativiert, wenn am Ende jedes Sprints ein „integrated increment” ausgeliefert werden kann. Nur die Auslieferung wird Wert für die Organisation schaffen.
Das kontinuierliche Eliminieren von Abhängigkeiten und das Integrieren der gesamten Arbeit ist eine bewusste Praxis. Sie ist das Herzstück von Nexus. Im Kern hilft das Nexus-Rahmenwerk dabei, die Arbeit mehrerer Teams kontinuierlich zu einem Produkt zu integrieren.
Scrum-Anwender finden sich im Nexus-Rahmenwerk wieder, da es Scrum nur minimal erweitert. Organisationen, die sich dafür entscheiden, Scrum mit Nexus zu skalieren, sind bestrebt, ihren Nutzern kontinuierlich Wert zu liefern. Sie verschwenden keine Sprints, Mitarbeiter in neuen Rollen zu schulen, neue Prozesse oder Arbeitsweisen einzuführen, neue Infrastrukturen einzurichten oder darauf zu warten, Unterstützung von externen Beratern zu erhalten.
Dieser Artikel bietet Anwendern, welche bereits mit Scrum vertraut sind, eine Übersicht über das Nexus-Rahmenwerk.
Das Nexus-Rahmenwerk erklärt
Wir besprechen das Rahmenwerk Schritt für Schritt. Dabei erklären wir die Elemente, die es ermöglichen, teamübergreifend Abhängigkeiten zu identifizieren und zu beseitigen. Wir starten dabei links mit dem Product-Backlog.
Die Arbeit an einem Produkt erfordert ein Product-Backlog. Es ist die einzige Quelle an Arbeit, die durch die Scrum-Teams erledigt wird. Um diese Arbeit transparent zu machen, ist das Refinement eine hilfreiche Praxis in Scrum. Bei skalierten Scrum ist teamübergreifendes Refinement hingegen vorgeschrieben.
1. Teamübergreifendes Refinement macht das Product-Backlog transparent
In der teamübergreifenden Verfeinerung wird das Product-Backlog zerlegt. Das geschieht soweit bis feststeht, welches Team die Arbeit übernehmen kann und ob es Abhängigkeiten zwischen den Einträgen gibt. Dieser Grad an Transparenz ist nötig, um Abhängigkeiten im Vorfeld zu eliminieren. Es werden Vorhersagen getroffen, welches Team höchstwahrscheinlich an welchen Product-Backlog-Einträgen in den kommenden Sprints arbeiten wird. Teamübergreifende Verfeinerung vereinfacht die Planung der nächsten Sprints.
Repräsentanten aus jedem Scrum-Team nehmen daran teil. Sie werden dabei nicht aufgrund ihrer Rolle ausgewählt, sondern situativ basierend auf der zu verfeinernden Arbeit. Wie oft sich die Repräsentanten zum teamübergreifende Refinement treffen, bestimmt der Grad der Ungewissheit innerhalb des Product-Backlogs. Da die Verfeinerung ein fortlaufender Prozess ist, wird kein Zeitrahmen vorgeschrieben. Typischerweise setzten die Scrum-Teams die Verfeinerung in ihren Teams fort, damit die Product-Backlog-Einträge für die Auswahl in einem Nexus-Sprint-Planning-Event bereit sind.
2. Nexus-Sprint-Planning koordiniert Aktivitäten für den Sprint
Das Nexus-Sprint-Planning leitet den Sprint ein. Innerhalb dieses Events wird die Arbeit und alle dazu nötigen Aktivitäten, die für diesen Sprint nötig sind, koordiniert. Idealerweise nehmen alle Mitglieder des Nexus am Nexus-Sprint-Planning teil.
Das Event beginnt damit, dass Repräsentanten der Scrum-Teams und der Product Owner einen Blick auf das verfeinerte Product-Backlog werfen und ein Ziel für den Sprint festhalten.
3. Nexus-Sprint-Ziel ermöglicht Fokus über Teamgrenzen hinweg
Dieses Ziel stellt ein übergreifendes Ziel für alle Teams in diesem Sprint dar. Es schafft Kohärenz und Fokus für den Nexus. Zudem ermutigt es die Scrum-Teams, zusammen statt an getrennten Initiativen zu arbeiten.
Der Product Owner stellt das Nexus-Sprint-Ziel vor, um den Zweck des Sprints zu klären. Gemeinsam wählen die Scrum-Teams die Product-Backlog-Einträge mit der höchsten Priorität aus, die, wenn sie fertiggestellt werden, das Nexus-Sprint-Ziel realisieren. Der laufende Refinement-Prozess sollte bereits Abhängigkeiten für die ausgewählten Product-Backlog-Einträge identifiziert und weitestgehend eliminiert haben.
Nach der initialen Auswahl der Product-Backlog-Einträge fahren die einzelnen Scrum-Teams mit ihrer Sprint-Planung fort.
Das Nexus-Sprint-Planning dient als Container für die Sprint-Plannings der einzelnen Scrum-Teams. Es ist dann abgeschlossen, wenn ein grober Plan, wie das Nexus-Sprint-Ziel erreicht werden kann, und einen detaillierteren Plan für die ersten Tage des Sprints, erstellt wurde.
Dieser übergreifende Plan wird im Nexus-Sprint-Backlog festgehalten.
4. Nexus-Sprint-Backlog ist ein Echtzeitbild der Abhängigkeiten
Er besteht aus den Einträgen des Product-Backlogs, welche die Developer im Nexus für notwendig halten, um das Nexus-Sprint-Ziel zu erreichen. Dieses neue Artefakt macht die gesamte prognostizierte Arbeit der Teams und alle Abhängigkeiten zwischen ihnen sichtbar.
Das Nexus-Sprint-Backlog hilft dabei, die Arbeit über Teamgrenzen hinweg zu koordinieren. Sollte beispielsweise Scrum-Team A von Scrum-Team B abhängen, um einen Product-Backlog-Eintrag zu erledigen und Scrum-Team A keine Fortschritte bei der Abarbeitung machen, dann würde dieses im Nexus-Sprint-Backlog sichtbar.
Dieses Backlog ermöglicht den Teams während des Sprints zusammenzuarbeiten. Er kann als die Aggregation der Sprint-Backlogs der Scrum-Teams gesehen werden. Er hilft dem Nexus, für die Abhängigkeiten während des Sprints verantwortlich zu bleiben. Das Nexus-Sprint-Backlog stellt ein Echtzeitbild des Arbeitsflusses während des Sprints dar und muss täglich aktualisiert werden. Diese Aktualisierung sollte im Nexus-Daily-Scrum erfolgen.
5. Nexus-Daily-Scrum macht Integrationsprobleme sichtbar
Developer der Teams und das Nexus-Integrationsteam treffen sich vor dem Daily Scrum, um den Fortschritt gegenüber der Erreichung des Nexus-Sprint-Ziels zu überprüfen. Sie überprüfen den aktuellen Stand des „integrated Increment” (die gemeinsam bis jetzt fertiggestellte Arbeit eines Nexus), indem sie alle Integrationsprobleme und neu entstehenden Abhängigkeiten transparent machen.
Die Repräsentanten nutzen diese Informationen als Input für das Daily-Scrum ihres Teams. Die Rolle des Nexus-Integrationsteams dabei ist es, den Teams zu helfen, ihre Integrations- und Abhängigkeitsprobleme und die Notwendigkeit von Maßnahmen auf der Teamebene zu identifizieren.
Natürlich ist dies nicht die einzige Zeit, in der teamübergreifende Kommunikation stattfindet. Das Nexus-Daily-Scrum stellt die minimale Gelegenheit und eine gemeinsame Zeit dar, um das Nexus-Sprint-Backlog zu aktualisieren.
Scrum-Trainings mit Simon Flossmann
Lerne im Training mit unserem Autor und Professional Scrum Trainer Simon Flossmann, das Nexus-Framework anzuwenden, um Scrum zu skalieren: Scaled Professional Scrum™ mit Nexus (SPS)
Hier findet ihr eine Übersicht aller Scrum-Trainings mit Simon Flossmann.
6. Nur ein „integrated Increment” schafft die nötige Transparenz für Empirie
Ein Product-Backlog-Eintrag erfüllt nur dann die Definition of Done, wenn dieser vollständig in das Produkt integriert wurden. Erst dann ist ein neues Inkrement des Produkts erstellt.
Nur die Integration in das Produkt schafft die nötige Transparenz, welche die Empirie antreibt. Spätestens am Ende des Sprints muss ein nutzbares Inkrement erstellt sein. Im Idealfall findet die Integration und Auslieferung häufiger statt.
Die Integration der Arbeit sollte vor allen anderen zu erledigenden Arbeiten kommen. Sollte es zu Integrationsproblemen kommen, müssen diese zuerst behoben werden, bevor weitere Product-Backlog-Einträge umgesetzt und in das Produkt integriert werden können.
7. Nexus-Sprint-Review zur Überprüfung des „integrated Increment”
Das Nexus-Sprint-Review ersetzt die Sprint-Reviews der Scrum-Teams, um eine ganzheitliche Sicht auf das Ergebnis des Sprints zu liefern. Das Ziel ist es, Feedback von Stakeholdern zum Inkrement zu erhalten und Produktverbesserungen zu identifizieren. Da es sich bei diesem Event um eine sehr große Veranstaltung handeln kann, sollte der Fokus auf den High-Level-Ergebnissen liegen. Sollte es nötig sein, einen detaillierten Output zu inspizieren, so kann der Product Owner und Stakeholder jederzeit bestimmte Teile des Produkts während des Sprints überprüfen. Wie bei Scrum dienen die Ergebnisse des Nexus-Sprint-Reviews als Input, um das Product-Backlog anzupassen.
Das Sprint-Review findet am Ende eines Sprints statt. Im Anschluss haben die Scrum-Teams genügend Informationen, um die Sprint-Retrospektive durchzuführen.
8. Nexus-Sprint-Retrospektive ermöglicht nexusweite Verbesserung
Es gibt zahlreiche Möglichkeiten, die Nexus-Sprint-Retrospektive durchzuführen. Ein gängiger Weg ist:
Als Input für die Scrum-Team-Retrospektiven identifizieren Repräsentanten Probleme, die mehrere Teams betreffen. Im Nachgang führt jedes Scrum-Team seine eigene Sprint-Retrospektive durch. Die teamübergreifenden Probleme können hierfür als Grundlage dienen. Nach der Team-Retrospektive kommen die Repräsentanten erneut zusammen, um die Verbesserungen zu visualisieren. Das hilft den Teams während des Sprints verantwortlich für die Umsetzung zu bleiben.
Unabhängig davon, wie ein Nexus seine Sprint-Retrospektive durchführt, muss sie dem Leitprinzip treu bleiben: Der Nexus nutzt „Bottom-up”-Erkenntnisse, um Probleme zu beheben, die den Nexus als Ganzes behindern.
9. Nexus-Integration-Team übernimmt die Verantwortung für die Integration
Das Nexus-Integrations-Team ist das am meisten missverstandene Element des Rahmenwerks. Das Nexus-Integrations-Team ist weder ein separates Team noch soll es die Integrationsarbeit erledigen.
Es bietet die Fokussierung auf die Verantwortung, die Arbeit der einzelnen Teams zu integrieren, um infolgedessen ein nutzbares Inkrement zu erstellen. Ist niemand dafür verantwortlich, führt dies zu Verzögerungen bei der Integration und minimiert die Transparenz. Ohne diese Transparenz ist empirisches Arbeiten nicht möglich.
Die Mitglieder des Nexus-Integrations-Teams kommen aus den Scrum-Teams. Die Zusammensetzung kann sich im Laufe der Zeit ändern, je nach den aktuellen Integrationsanforderungen und Prioritäten. Ihre Arbeit im Nexus-Integrations-Team hat Vorrang.
Product Owner und ein Scrum Master sind ständige Mitglieder im Team. Die restlichen Mitglieder sind Personen mit den notwendigen Fähigkeiten und Kenntnissen, um die Probleme zu lösen, mit denen der Nexus zur Zeit konfrontiert ist.
Anstatt Probleme direkt zu lösen, nutzt das Nexus-Integrations-Team die Fähigkeiten und Wissen der Mitglieder der Scrum-Teams, um optimale Lösungen für identifizierte Probleme zu erreichen. Zu den üblichen Aktivitäten, die das Nexus-Integrations Team durchführt, gehören Coaching, Beratung und die Schaffung eines Bewusstseins für Abhängigkeiten und teamübergreifende Probleme. Nur in Notfallsituationen springen Mitglieder des Nexus-Integrations-Teams ein, um den Teams bei der Lösung kritischer Probleme zu helfen.
Zusammenfassend lässt sich sagen, dass das Nexus-Integrations-Team die zentrale Anlaufstelle für die Integration des Nexus darstellt.
Nexus erweitert Scrum und erhält dessen Wettbewerbsvorteil
Das Nexus-Rahmenwerk erweitert das Scrum-Rahmenwerk, um das Nexus-Integrations-Team, das Nexus-Sprint-Backlog, teamübergreifendes Refinement, und das Nexus-Daily-Scrum.
Nexus stellt somit eine minimale, aber ausreichende Erweiterung zu Scrum dar. Diese Erweiterung ermöglicht es, dass Teams am Ende des Sprints in der Lage sind ein „integrated Increment” zu liefern.
Die Transparenz, welche durch ein „integrated Increment” entsteht, ist der entscheidende Wettbewerbsvorteil von Nexus. Nur dadurch bleiben Organisationen in der Lage, jederzeit auf Veränderungen empirisch zu reagieren.
Das Nexus-Framework für Ihr Unternehmen
Unser Angebot:
– Kostenloses Beratungsgespräch
– Workshop (4 Stunden), der den Kern von Nexus vermittelt
– Einführung von Nexus oder Optimierung einer existierenden Nexus-Implementierung
– Training Scaled Professional Scrum™ mit Nexus (SPS) mit Simon Flossmann
Wir freuen uns auf einen ersten, unverbindlichen Austausch!