Scaled Agile: Scrum.org veröffentlicht Nexus Guide
![]() |
Grafik: Wikimedia Commons / Scrum.org - CC BY-SA 4.0 |
So wie ich es verstehe ist es eine Weiterentwickelung der Praktiken, die ich bisher als Scrum of Scrums, Retro of Retros, o.Ä. kannte. Diese bestehen daraus, dass die verschiedenen Scrum-Meetings jeweils zweimal durchgeführt werden: einmal ganz normal innerhalb der Scrum Teams, ein zweites mal auf einer Koordinationsebene. Zu dieser nächsthöheren Ebene schickt jedes Team einen Stellvertreter, der von den Teammitgliedern selbst bestimmt wird. Planning und Grooming finden dabei zuerst auf der Koordinationsebene und dann auf der Teamebene statt, bei Dailies, Reviews und Retrospektiven ist es umgekehrt. Dieses Grundmuster findet sich auch in Nexus wieder, wobei folgende Neuerungen eingeführt worden sind:
- Gemeinsames Backlog Zwar behält jedes Team ein eigenes Sprint-Board, es gibt aber nur ein gemeinsames Product Backlog, dessen Stories im übergreifenden Planning von den Teams aufgeteilt werden.
- Gemeinsames Review Gar nicht mal so neu, das habe ich bereits in anderen Zusammenhängen erlebt. Dass die Teams sich gegenseitig zeigen was sie fertiggestellt haben macht ja auch Sinn.
- Übergreifendes Integrationsteam Das ist wirklich neu. Zum einen sind hier die Spezialisten versammelt, die die Teams zwar ab und zu aber nicht in jedem Sprint brauchen, zum anderen gibt es jeweils einen Product Owner und Scrum Master. Die genannten Spezialaufgaben können wenn nötig nach normalem Scrum-Vorgehen in User Stories und Sprints abgearbeitet werden, daneben gehören das Coachen und Beraten (nicht das Kommandieren) der anderen Teams zu den Aufgaben.
Was mir sofort an diesem Modell gefällt ist die Idee, dass die Koordinationsebene (die Abgesandten in den Koordinationsmeetings und das Integrationsteam) den Scrum Teams nicht disziplinarisch vorgesetzt ist. Die schleichende Aushöhlung der Selbstverwaltung auf Team-Ebene ist damit zwar nicht völlig unmöglich aber zumindest unwahrscheinlicher geworden. Auch die Ideen von gemeinsamem Backlog und Review erscheinen sinnvoll, da sie dem Entstehen von Kirchturm- und Scheuklappendenken vorbeugen. Leichte Zweifel habe ich bei dem zweistufigen Planning - wenn im Planning eines oder mehrerer Einzelteams festgestellt wird, dass die im übergreifenden Planning vereinbarte Themenaufteilung doch nicht funktioniert, muss ggf. alles von vorne beginnen. Vermutlich ist das aber der Preis für eine gemeinsame Produktvision und das dazugehörende gemeinsame Product Backlog. Ich bin gespannt ob ich den Nexus einmal in Aktion erleben werde, interessieren würde es mich auf jeden Fall
1Um einen Insider-Witz zu bringen: Safe sein und agil sein schließen sich oft aus