Das Nexus Framework – Schritt für Schritt erklärt

Du möchtest Scrum skalieren und weißt noch nicht genau, welcher der vielen Ansätze zur agilen Skalierung für Deine Organisation der richtige ist? In diesem Artikel stelle ich Dir das Nexus Framework vor, das den wohl einfachsten und elegantesten Weg bietet, mit mehreren Scrum Teams an ein und demselben Produkt zu arbeiten.

Das Nexus Framework ist im Aufbau sehr einfach gehalten und nimmt nur minimale Anpassungen bzw. Erweiterungen an Scrum vor. Der Scrum Guide ist nach wie vor gültig und nichts daran wird durch Nexus ersetzt oder gestrichen. Dabei fokussiert sich das gesamte Framework auf zwei Aspekte:

Nexus nimmt einige Erweiterungen an den Verantwortlichkeiten, Events und Artefakten aus Scrum vor, die ich Dir im Folgenden kurz vorstellen möchte.

Das Nexus Framework behält alle bekannten Scrum Rollen bei, ergänzt diese jedoch um die zusätzliche Verantwortlichkeit des Nexus Integration Teams.

Das Besondere am Nexus Framework ist sicherlich die neue Rolle bzw. Verantwortlichkeit des Nexus Integration Teams (kurz NIT). Dieses Team bildet eben genau den Nexus, der diesem Skalierungs-Framework seinen Namen gab.

Das NIT besteht aus dem Product Owner, einem Scrum Master und weiteren Teammitgliedern. Letztere rekrutieren sich dabei aus jedem Scrum Team des Nexus. Die Aufgaben im Nexus Integration Team haben für die jeweiligen Teammitglieder immer Vorrang vor den Aufgaben des eigenen Scrum Teams.

Natürlich kann die Mitgliedschaft innerhalb des NIT auch wechseln, je nachdem wie es die aktuelle Situation gerade erforderlich macht. Allerdings sollte ein solcher Wechsel eher die Ausnahme als die Regel sein.

Des Weiteren ist es auch möglich, dass jemand Mitglied im Nexus Integration Team ist, der nicht Teil der Scrum Teams ist und quasi “von außerhalb” hinzukommt.

Das ist zum Beispiel immer dann sinnvoll, wenn bestimmtes Know-how im Nexus benötigt wird, das aktuell noch niemand im Nexus besitzt.

Die Hauptaufgabe des Nexus Integration Teams besteht darin dafür zu sorgen, dass die Arbeit aller Scrum Teams (spätestens) zum Ende des Sprints zusammenfließt und ein Integrated Increment entsteht.

Im Nexus Framework existieren die gleichen Events wie in Scrum. Die meisten von ihnen sind dabei Teil eines übergreifenden bzw. umfassenden Nexus Events. Zum Beispiel finden innerhalb der Nexus Sprint Retrospektive weiterhin teaminterne Sprint Retrospektiven statt.

Hierbei gibt es jedoch zwei Ausnahmen:

Auch im Nexus führt jedes Scrum Team seinen eigenen (autonomen) Sprint durch. Die bekannte Regel, dass ein Sprint maximal einen Monat dauern darf, bleibt dabei erhalten.

Im Unterschied zu anderen Frameworks (wie beispielsweise LeSS) muss die Länge der Team-Sprints nicht synchronisiert werden.

Das heißt, dass es durchaus denkbar und möglich ist, dass ein Team innerhalb des Nexus Sprints kürzere Sprints durchführt. Sofern ein Team beispielsweise in der Situation ist, dass zweiwöchige Sprints nicht gut funktionieren, kann es auch einwöchige Sprints einsetzen.

Das Cross-Team Refinement des Nexus Frameworks gewährleistet, dass das Product Backlog ausreichend gepflegt ist.

Es dient zum einen dazu zu entscheiden, welche Product Backlog Items (höchstwahrscheinlich) von welchem Team umgesetzt werden und zum anderen sollen hier potenzielle Abhängigkeiten zwischen Work Items sichtbar gemacht und im besten Fall direkt eliminiert werden.

Kurz gesagt ist das Cross-Team Refinement eine Art Vorbereitung für das “eigentliche Refinement”, welches dann direkt in den jeweiligen Scrum Teams stattfindet.

Im Nexus beginnt jeder Sprint wie in Scrum üblich mit einem Sprint Planning. Weil bei diesem Event mehrere Teams ihre Aktivitäten planen und koordinieren müssen, ist dieser Workshop meistens ein wenig anderes organisiert.

Der Nexus Guide fordert lediglich, dass nach dem Sprint Planning ein Nexus Sprintziel und ein Nexus Sprint Backlog sowie Sprintziele und Sprint Backlogs für jedes einzelne Scrum Team des Nexus existieren.

Üblicherweise erfolgt das Nexus Sprint Planning in zwei aufeinanderfolgenden Phasen. In der ersten Phase entstehen dabei lediglich das Nexus Sprintziel und das Nexus Sprint Backlog.

Ist das geschafft, gehen die Scrum Teams des Nexus in ihre Sprint Plannings und planen dort ihren eigenen Sprint. Dabei entstehen dann die individuellen Sprint Backlogs mit den Sprintzielen der jeweiligen Teams.

Manchmal trifft sich abschließend auch noch einmal der gesamte Nexus, um die geplanten Sprints vorzustellen.

Das ist besonders dann hilfreich, falls während der zweiten Phase Abhängigkeiten zu anderen Teams entdeckt wurden, die noch besprochen werden müssen.

Das Nexus Daily Scrum ist ein zusätzlicher Event des Frameworks. Es dient vor allem dazu, Integrationsprobleme und neue entdeckte Abhängigkeiten zwischen den einzelnen Scrum Teams zu identifizieren. Des Weiteren wird in diesem Termin auch der Fortschritt hinsichtlich des Nexus Sprintziels überprüft.

Das Nexus Daily Scrum findet vor den Dailies der einzelnen Scrum Teams statt, damit entdeckte Abhängigkeiten und Herausforderungen anschließend in den Dailies der jeweiligen Teams weiterbesprochen werden können.

Hilfreiche Fragen für das Nexus Daily Scrum sind beispielswesie:

Genau wie in Scrum findet im Nexus eine Sprint Review statt. Hierzu treffen sich alle beteiligten Scrum Teams des Nexus gemeinsam mit ihren wichtigsten Stakeholdern, um Feedback zum aktuellen Stand des Produktes zu erhalten. Die Nexus Sprint Review ersetzt dabei individuelle Team Reviews.

Wichtig ist dabei jedoch, dass alles, was in der Nexus Sprint Review gezeigt wird, auf Basis des Integrated Increments erfolgt. Das heißt, eine Software-Demo neuer Funktionen wird im Master Branch des Produktes durchgeführt.

Der Nexus Sprint endet wie in Scrum üblich mit einer Sprint Retrospektive. Die Nexus Sprint Retrospektive ersetzt jedoch nicht die individuellen Scrum Team Retrospektiven, sondern nimmt diese in sich auf und erweitert den Rahmen, sodass auch der Nexus als Ganzes durch diesen Event verbessert wird.

Wie das geschieht, schreibt Euch der Nexus Guide natürlich wieder nicht genau vor. Üblich ist jedoch meistens der folgende Ablauf:

Zunächst treffen sich Vertreter aus den einzelnen Scrum Teams (oder auch der gesamte Nexus) und es werden teamübergreifende Abhängigkeiten und Probleme identifiziert.

Daran anschließend führt jedes Scrum Team des Nexus seine eigene Sprint Retrospektive durch, berücksichtigt dabei jedoch auch Themen aus dem ersten Teil der Nexus Sprint Retrospektive.

Sind die Team Retrospektiven abgeschlossen, treffen sich noch einmal Vertreter aus den Scrum Teams (oder auch der Nexus als Ganzes) und die Ergebnisse werden vorgestellt und besprochen.

Weiterhin existieren im Nexus wie bisher alle bekannten Scrum Artefakte mit den jeweiligen Commitments. Das heißt, es gibt ein Product Backlog mit einem Produktziel, für jedes Team des Nexus ein Sprint Backlog mit einem eigenen Sprintziel und ein Inkrement, das eine Definition of Done besitzt..

Hinzu kommt jedoch ein neues Artefakt: das Nexus Sprint Backlog mit dem Nexus Sprintziel.

Das Product Backlog unterscheidet sich im Nexus bis auf Kleinigkeiten nicht von dem, was Du aus Scrum bereits kennst. Das heißt, es gehört weiterhin dem Product Owner und besitzt eine Priorisierung, die sich aus dem aktuellen Produktziel ergibt.

Das Nexus Sprint Backlog ist ein neues Artefakt, das bei der Skalierung mit dem Nexus Framework genutzt wird. Sein Hauptzweck besteht darin, Abhängigkeiten zwischen den Scrum Teams und den Fluss der Arbeit zu visualisieren. Dabei solltest Du jedoch zwei wichtige Dinge im Blick behalten:

Das Nexus Sprint Backlog visualisiert deshalb in erster Linie teamübergreifende Abhängigkeiten, ohne dabei zu sehr ins Detail zu gehen. So kann es beispielsweise im Nexus Daily Scrum genutzt werden, um diese Abhängigkeiten im Blick zu behalten, zu besprechen und aufzulösen.

Wie Scrum fordert Nexus, dass zum Ende eines jeden Sprints ein nutzbares Produktinkrement entsteht. Weil im skalierten Umfeld aber mehrere Teams an ein und dem gleichen Produkt arbeiten, spricht der Nexus Guide statt von einem Inkrement stets von einem Integrated Increment. Das soll hervorheben, dass zum Ende eines Nexus Sprints die Arbeit aller beteiligten Scrum Teams zusammenfließt und beispielsweise keine parallelen Branches für jedes Team existieren.

Die Definition of Done (DoD) für das Integrated Increment gilt deshalb logischerweise für alle Scrum Teams des Nexus. Allerdings gibt es hier eine kleine Besonderheit, denn die DoD ist “nur” eine Minimalanforderung für alle beteiligten Teams. Das bedeutet, falls eines der Teams sich eine “härtere” bzw. “stärkere” Definition of Done geben möchte, dann ist das vollkommen in Ordnung. Es darf nur eben kein Team eine “schwächere” DoD verwenden.