Scrum skalieren – Teil 2: Nexus

Scrum – ein perfekt geeignetes Framework für Projekte mit einem Team von drei bis neun Personen. Was aber, wenn ein Projekt so komplex ist, dass zehn oder mehr Personen daran arbeiten? Dieser Frage widmen wir uns in vier Blog-Einträgen, in welchen wir die Skalierungs-Ansätze Scrum of Scrums (SoS), Nexus, LeSS und SAFe vorstellen. In diesem Teil geht es um das Skalieren von Scrum mit Nexus. 

Nexus – lateinisch für „das Zusammenknüpfen“ – ist ein Framework, das drei bis neun Scrum Teams integriert. Scrum dient dabei als Basis-Rahmenwerk und wird um neue Rollen, Artefakte und Methoden erweitert. Dies ermöglicht eine Skalierung auf mehrere Teams, die aus jeweils drei bis neun Personen bestehen können.

Eine zentrale Funktion für Nexus nimmt das Nexus Integration Team (NIT) ein. Es besteht aus Product Owner (PO), Scrum Master (SM) sowie mindestens einem Entwickler und ist verantwortlich für die Koordination der Zusammenarbeit der einzelnen Scrum Teams. Dies realisiert das NIT, indem es die Teams coacht und sie darin unterstützt, die organisationsspezifischen Standards für Entwicklung, Infrastruktur und Architektur einzuhalten.

Das NIT stellt sicher, dass in jedem Sprint ein integriertes Product Increment produziert wird. Ist diese primäre Aufgabe erfüllt ist, können Mitglieder des NIT auch als Entwickler in der einzelnen Scrum Teams mitwirken. Der Scrum Master ist für die Einhaltung des Nexus Frameworks zuständig und kann parallel als Scrum Master in einem oder mehreren Scrum Teams fungieren. Die Zusammensetzung des NIT ist dabei flexibel, um die Bedürfnisse von Nexus zu reflektieren.

Im Nexus Sprint Planning entscheiden Repräsentanten aller Teams, welche user stories von welchem Team bearbeitet werden. Sie analysieren gemeinsam, welche Abhängigkeiten zwischen ihren Teams bestehen. Ziel ist ein Satz von Sprint Goals, welche gleichgerichtet mit dem Nexus Sprint Goal sind. In einem zweiten Schritt planen die jeweiligen Scrum Teams passende (Sub-)Tasks, um die ausgewählten user stories umzusetzen.

Im Nexus Daily inspizieren Repräsentanten aller Teams den aktuellen Stand des Inkrements. Stellen sie Integrationsprobleme oder teamübergreifende Abhängigkeiten fest, werden diese in den Dailies der einzelnen Scrum Teams besprochen. Auf diese Weise sollen einerseits die Ursachen identifiziert werden, die einer erfolgreichen Integration im Wege stehen. Andererseits soll erkannt werden, welche Informationen mit den anderen Scrum Teams geteilt werden müssen, um ebendiese Integrationsprobleme zu vermeiden.

Das Nexus Sprint Review gibt einen Überblick über das Inkrement. Es ersetzt die einzelnen Scrum Sprint Reviews. Das Ergebnis ist auch hier ein überarbeitetes Product Backlog. Die Nexus Retro wird vor den Scrum Retros der Einzelteams abgehalten. Sie dient als formale Möglichkeit, Nexus-Prozesse zu inspizieren (inspect) und bei Bedarf anzupassen (adapt). Häufig dient das Ergebnis als Input für die einzelnen Scrum Team Retros. Die Nexus Retro besteht aus drei Phasen:

1. In der ersten Phase treffen sich Repräsentanten aus den einzelnen Scrum Teams mit dem Scrum Master und dem Product Owner. Sie benennen teamübergreifende Probleme.
2. In der zweiten Phase finden die Scrum Retrospektiven der einzelnen Scrum Teams statt. Jetzt können die identifizierten Probleme besprochen und konkrete Aktionen erarbeitet werden, die diese Probleme adressieren.
3. In der dritten Phase finden sich die Teilnehmer aus der ersten Phase erneut zusammen. Sie resümieren die Beschlüsse aus den Scrum Teams und fassen diese zusammen, um sie als Ganzes zu adaptieren.

Kurzum: Nexus erleichtert durch die Erweiterung der üblichen Scrum Artefakte, Rollen und Events die agile Zusammenarbeit von bis zu 80 Personen und ermöglicht die Durchführung von umfangreichen Projekten mit einem hohen Maß an Flexibilität.