Von klein zu groß - Skalierung von Scrum mit Nexus

Was in kleineren agilen Projekten mit ein oder zwei Scrum-Teams noch gut funktioniert, passt für größere Entwicklungen mit mehreren Teams häufig nicht mehr, denn dort gibt es viele Abhängigkeiten und Gesprächsbedarf. Für diesen Zweck existiert das Nexus Scrum Framework, eine Erweiterung für das bekannte Scrum.

Scrum ist bekannt

Mittlerweile ist sicher jeder schon mit Scrum in Berührung gekommen, sei es aktiv in einem Projekt oder aber zumindest im Zusammenhang mit einer Weiterbildung oder einschlägigen Fachmagazinen zum Thema agiles Projektmanagement.

Daher werden in diesem Artikel fundierte Kenntnisse zum Scrum Framework vorausgesetzt. Die dort verwendeten Begrifflichkeiten werden hier nicht noch einmal erläutert.

Grenzen von Scrum

Sobald das zu entwickelnde Produkt größer wird, wächst auch die Anzahl der beteiligten Mitarbeiter, und damit die Anzahl der Teams, die an der Entwicklung arbeiten. Bald schon entsteht für jede Komponente ein eigenes Team. Scrum ist oftmals das gewählte Vorgehensmodell.

Doch genau da stößt Scrum meistens an seine Grenzen, denn bei vielen Teams, von denen jedes einen Teil zum Gesamtprodukt beiträgt, wird es schnell unübersichtlich und mangelnde Kommunikation und Absprachen erschweren den Fortschritt oder Probleme legen gleich die ganze Entwicklung lahm.

Aus diesem Grund hat Ken Schwaber, einer der Erfinder von Scrum, zusammen mit Scrum.org sein bestehendes Framework erweitert, sodass es auch in größeren agil geführten Projekten funktioniert.

Das Nexus Scrum Framework

Das Nexus Scrum Framework (oder kurz Nexus) ist für drei bis neun Scrum-Teams ausgelegt, die zusammen an einem Produkt arbeiten.

Nexus beschreibt die Zusammenarbeit der Teams, die sich gemeinsam an einem einzigen Product Backlog bedienen. Die Grundlage dieser Methode ist das Scrum Framework. Es beschreibt die Abhängigkeiten und die Kommunikation untereinander. Außerdem erweitert Nexus Scrum um Verantwortlichkeiten, Ereignisse und Artefakte. Im bestehenden Scrum Prozess werden also Elemente hinzugefügt, angepasst oder ersetzt.

Der komplette Prozess mit all seinen Bestandteilen ist in Abbildung 1 skizziert.

Das Nexus Integrationsteam

Neben den aus Scrum bekannten Rollen Product Owner (PO), Scrum Master (SM) und Entwicklerteam führt das Nexus Framework eine neue Gruppe ein: Das Nexus-Integrationsteam.

Dieses besteht aus einem Product Owner, einem Scrum Master und geeigneten Mitgliedern der einzelnen Scrum-Teams. Die Zusammensetzung des Teams kann im Laufe der Zeit variieren. Es sollten immer diejenigen Entwickler im Nexus Integrationsteam mitwirken, die zu den aktuellen Themen beitragen können und Know-How bzw. einen guten Überblick über die in ihrem eigenen Team zu verantwortenden Komponenten besitzen.

Das Nexus Integrationsteam hat ein Auge darauf, dass am Ende eines Sprints ein nützliches/qualitativ hochwertiges Inkrement („Integrated Increment") herauskommt. Außerdem ist es verantwortlich für die Definition of Done (DoD), die alle Teams bei der Umsetzung zu beachten haben. Später im Review entscheidet die DoD darüber, ob das Ergebnis eines Sprints erfolgreich von den Stakeholdern abgenommen wird.

Typische Aufgaben dieses Teams sind auch Coaching, Beratung und der Blick auf Abhängigkeiten und teamübergreifende Probleme.

Der Product Owner des Nexus Integrationsteams kann gleichzeitig auch Product Owner eines oder sogar mehrerer Entwicklerteams sein. Einerseits spart dies Personalressourcen und damit Geld, andererseits kann er sich aufgrund der vielen Aufgaben unter Umständen nicht intensiv genug um seine Teams kümmern. Daher ist diese Vorgehensweise in der Regel nicht zu empfehlen.

Der Scrum Master hat die Aufgabe, auf die Einhaltung des Scrum Prozesses zu achten. Auch er kann gleichzeitig Scrum Master eines oder mehrerer Teams sein.

Die Teammitglieder des Scrum-Integrationsteams bringen zum Beispiel auch neue Werkzeuge oder Praktiken in die einzelnen Teams, coachen diese und leiten sie an. Dabei hat die Mitarbeit im Scrum Integrationsteam Vorrang vor der Arbeit im eigentlichen Scrum-Team! Das ist ein entscheidender Punkt und stellt sicher, dass teamübergreifende Probleme zuerst beseitigt werden und es nicht zu weitreichenden negativen Folgen für das Inkrement kommt.

Ein Product Backlog für alle

Ein zentrales Artefakt im Nexus ist das Product Backlog. Es gibt nur ein einziges Product Backlog für alle Scrum-Teams und gehört natürlich dem Product Owner des Nexus-Integrationsteams. Er ist alleiniger Eigentümer und damit verantwortlich für die Inhalte dieses Backlogs.

Das Commitment des Product Backlogs ist das Product Goal, welches das fertige Produkt beschreibt. Es wird als langfristiges Ziel des Nexus angesehen.

Nexus Sprint Planning und Sprint Backlog

Im Nexus Sprint Planning kommen PO und ausgewählte Mitglieder der Teams zusammen, um gemeinsam den nächsten Sprint zu planen. Es wird ein globales Nexus Sprint Goal bestimmt, was während des Sprints für das Inkrement erreicht werden soll.

Ziel ist, ein Nexus Sprint Backlog für alle Teams zu füllen, in dem Abhängigkeiten transparent dargestellt sind. Außerdem füllt jedes Team sein eigenes Sprint Backlog und definiert sein eigenes Sprint Goal. In Summe setzt sich also am Ende das Nexus Sprint Backlog aus den Items der einzelnen Sprint Backlogs der Teams zusammen. Im jeweiligen Sprint werden dann für das Integrated Increment die Punkte aus dem Nexus Sprint Backlog umgesetzt.

Cross-Team Refinement

Als ein neues Event wurde das Cross-Team Refinement erdacht. Aufgabe ist, wie im Refinement des normalen Scrum-Prozesses, die Verfeinerung von Product Backlog Items. Zusätzlich werden die umzusetzenden Teams identifiziert und die Abhängigkeiten zwischen den Teams entfernt oder zumindest minimiert.

Wie häufig dieses Refinement stattfindet, wie lange es dauert und wer teilnimmt, kann variieren und ist nicht festgelegt.

Täglich mehrere Dailys

Beim Nexus Daily Scrum kommen ausgewählte Vertreter der einzelnen Teams zusammen, um über den Fortschritt in Bezug auf das Nexus Sprint Goal und Integrationsprobleme zu berichten.

Die teaminternen Dailys sollten erst im Anschluss an das Nexus Daily Scrum stattfinden, denn die dort zuvor besprochenen Probleme sollten mit Vorrang angegangen und beseitigt werden.

Review und Retrospektive

Am Ende eines Sprints findet das Nexus Sprint Review statt. Es ersetzt die von Scrum her bekannten Sprint Reviews der einzelnen Teams. Das Increment wird den Stakeholdern vorgestellt und das Feedback fließt in das Produkt Backlog ein. Das Increment muss natürlich der Definition of Done entsprechen.

Die Nexus Sprint Retrospektive schließt den Sprint ab und beantwortet Fragen wie „Was lief gut?", „Was lief schlecht?" und „Was lässt sich besser machen?". Die daraus gewonnenen Erkenntnisse dienen der Steigerung der Effizienz und der Qualität für zukünftige Sprints.

Fazit

Nexus skaliert das Scrum Framework und ist für die Entwicklung eines Produkts mit mehreren Scrum Teams gedacht. Wird im Unternehmen schon Scrum eingesetzt und sind die einzelnen Mitglieder passend geschult, dann ist der Einsatz von Nexus einfacher, als wenn vorher noch niemand damit gearbeitet hat. Es gibt sogar eine Zertifizierung zum „Scaled Professional Scrum" (SPS).

Der Nexus Scrum Guide gibt den Rahmen vor, geht dabei aber nicht ins Detail. So wird zum Bespiel nicht geklärt, wie und wann sich die Product Owner untereinander abstimmen.

Wie bei Scrum auch, ist es natürlich möglich, die besten Dinge aus dem Nexus Scrum Guide für sein eigenes agiles Projekt herauszupicken. Allerdings sind die Macher sich einig, dass entweder alles wie im Lehrbuch (Nexus Scrum Guide) umgesetzt oder aber gar nicht nach Nexus gearbeitet werden sollte.