Nexus – pures skaliertes Scrum

Vor kurzem habe ich einen einfachen Skalierungsansatz erklärt und dabei auch den Zusammenhang zu Scrum@Scale erläutert. Jetzt ist es Zeit, den zweiten Gründervater von Scrum, Ken Schwaber und dessen Ansatz zu beleuchten.

Die Scrum.org hat ebenfalls ein auf Scrum-basiertes Skalierungsframework entwickelt. Die Scrum.org arbeitet unter der Schirmherrschaft von Ken Schwaber und mittels der Unterstützung zahlreicher Scrum-Trainer gemeinsam am Nexus Guide und entwickelt ihn seit 2015 kontinuierlich weiter.

Wie Nexus aussieht, erfahrt ihr im Folgenden.

Das Nexus-Framework im Überblick

Nexus baut auf Scrum auf und besteht aus dem Nexus Integration Team, Artefakten und Events. Die Scrum-Werte und das empirische Vorgehen stehen dabei weiterhin im Fokus. Das Ziel von Nexus ist es, ein Rahmenwerk für die Entwicklung und Aufrechterhaltung von skalierten Produktbereitstellungs-Initiativen zur Verfügung zu stellen.

Nexus verbindet die Arbeit von drei bis neun Scrum-Teams, die gemeinsam an einem Produkt mit einem gemeinsamen Backlog arbeiten, um ein integriertes Increment zu erstellen. Wenn ein Unternehmen mehrere Produkte besitzt, können mehrere Nexus parallel genutzt werden. Es gilt ein Nexus = ein Produkt. Denn die agile Skalierung im Allgemeinen meint nicht Multi-Projektmanagement! Cross-Nexus-Abhängigkeiten sollten vermieden werden.

Hier seht ihr einmal das Framework im Überblick. Das Bild ist kaum zu unterscheiden vom Scrum-Schaubild.

Intentionally incomplete

Auch bei diesem Framework gilt: „Intentionally incomplete“. Unternehmen die skalieren, werden zusätzliche Patterns, Praktiken und Vorgehensweisen identifizieren, die sie bei ihrer individuellen Problemlösung weiterbringen.

Also immer dran denken: „One size fits all“ gibt es nicht im komplexen Problembereich. Probe-Sense-Respond aus der Cynefin-Matrix gilt und lässt uns emergente Praktiken finden.

Damit man aber ein leichteres Leben hat, findet ihr hier die empfohlenen Ergänzungen. Dass eine Anpassung oder Erweiterung von skalierten Frameworks erforderlich ist, habe ich auch bereits theoriegestützt – mittels Kontingenztheorie – in einem Blogartikel begründet und wenn ihr noch wissen wollt, welche Voraussetzung für die agile Skalierung berücksichtigt werden sollten, ist das auch verlinkt.

Artefakte in Nexus

Die Artefakte und Commitments (Product Goal, Definition of Done, Sprint Goal) aus dem Scrum Guide gelten analog. Das Product Backlog enthält Anforderungen an das Produkt und muss zusätzlich Transparenz hinsichtlich Abhängigkeiten schaffen – und sie bestenfalls eliminieren.

Daraus ergibt sich jeweils ein teameigenes Sprint Backlog, welches zusammengefasst das Nexus Sprint Backlog ergibt. Am Ende eines Sprints ergeben die zusammengefügten Arbeiten aller Scrum-Teams das potenziell auslieferbare integrierte Increment.

Nun möchte ich die Chance nutzen und das Wort „Increment“ erklären: Das Wort und seine Verwendung lassen sich mit den Worten „Zwischenstand“ und „Zuwachs“ beschreiben. Das Produkt wächst mit jedem Sprint und stellt dabei jeweils einen weiteren Zwischenstand zum verfolgten Product Goal dar. Den Zusammenhang zwischen Product Goal und Vision erkläre ich hier.

Events in Nexus

Nexus ergänzt und erweitert die bisher beschrieben Events aus dem Scrum Guide. Ergänzt wird das Cross-Team Refinement.

Dabei werden Product Backlog Items besprochen, zerlegt, auf Abhängigkeiten geprüft und diese bestenfalls minimiert. Je besser dies erfolgt, desto unkomplizierter ist das Nexus Sprint Planning zu bewältigen. Mehr Praxistipps rund um das Cross-Team-Refinement habe ich bereits für dich recherchiert. 

Im Nexus Sprint Planning nehmen geeignete Repräsentanten aller Scrum-Teams zusammen mit dem Product Owner teil. Der Product Owner formuliert ein übergeordnetes Ziel, welches sich auf Sprintziele für jedes Team herunterbrechen lässt, um die passenden Product-Backlog-Einträge pro Team aus dem Product Backlog zu entnehmen. Daraus resultiert pro Team ein Sprint Backlog, das zusammengefasst das Nexus Sprint Backlog ergibt.

Das Daily Scrum jedes Scrum-Teams wird um das Nexus Daily Scrum ergänzt. Im Nexus Daily nehmen geeignete Repräsentanten aller Scrum-Teams teil, um den aktuellen Stand des integrierten Increments, die Herausforderungen und die Abhängigkeiten zu inspizieren sowie zugehörige Maßnahmen einzuleiten. Warum das Nexus Daily nicht ein Scrum-of-Scrum ist, findet ihr hier. 

Die Nexus Sprint Review am Ende des Sprints ersetzt die team-individuellen Reviews, um den gesamten Stand des Produkts zu demonstrieren.

Die team-individuellen Sprint-Retrospektiven am Sprintende ergänzen die Nexus-Sprint-Retrospektive, indem sie Bottom-up-Intelligenz nutzen, um sich auf Probleme zu konzentrieren, die den Nexus insgesamt betreffen.

Accountabilities und das Nexus Integration Team

Die Accountabilities (auch bekannt als Rollen) wie Scrum Master, Product Owner und Developer aus dem Scrum Guide gelten analog. Gleichzeitig gilt die feste Regel „1 Produkt = 1 Product Backlog = 1 Product Owner“ weiterhin.

Richtig: Es gibt nur einen Product Owner für alle Teams. Das ist ein wesentliches Unterscheidungskriterium zu anderen Skalierungsframeworks, in denen es zumeist zu einer Vielzahl von Product Ownern kommt.

Zusätzlich führt Nexus das „Nexus Integration Team“ ein. Die Mitglieder des Nexus Integration Teams sind der Product Owner, ein Scrum Master und einzelne Developer. Das Nexus Integration Team ist für die Erstellung eines integrierten Increments in jedem Sprint rechenschaftspflichtig. Dazu berät und unterstützt es die Scrum-Teams auf vielfältige Weise, um Abhängigkeiten und Probleme zu reduzieren.

Die Zusammensetzung des Nexus Integration Teams ist pro Sprint variabel, sodass stets die notwendigen Fähigkeiten vorhanden sind, die der Nexus gerade benötigt.

Kurz und knapp

Wie ihr sehen könnt, handelt sich bei Nexus um „pures“ skaliertes Scrum. Es ist eine minimale und ausreichende Erweiterung zu Scrum.

Um die Scheu zu verlieren und mit Nexus in Berührung zu kommen, empfehle ich die Lektüre des Nexus Guide. Ich bin mir sicher, dass euch einiges davon bekannt vorkommen dürfte.