Scaled Agile: Scrum.org veröffentlicht Nexus Guide

Grafik: Wikimedia Commons / Scrum.org - CC BY-SA 4.0

Seit Jahren dürfte es der heilige Gral der Scrum-Welt sein - die Frage wie man diese Methode so skaliert, dass sie auch auf große Unternehmen anwendbar ist. Ich habe bereits in mehreren Projekten (zwischen vier und zwanzig Scrum-Teams) miterleben dürfen wie man sich daran versucht hat, und das Ergebnis war nicht selten unagil und unerfreulich: nach und nach wurde die Selbstverwaltung der Teams aufgehoben und stattdessen ein klassisches Mittelmanagement eingeführt. Um den Schein zu wahren wurden einem Teil dieser Leute Scrum-ähnliche Titel gegeben, etwa Scrum-Projektmanager, Chief Scrum Master, Epic Owner oder Lead Product Owner, in der Realität erwiesen sie sich aber fast immer als die klassische Zwischenschicht, die alles verlangsamte indem sie Informationen durch Flaschenhälse leitete und starre Prozesse und Hierarchien einführte. Da die Lösung allerdings nicht sein kann, dass man auf skaliertes Scrum grundsätzlich verzichtet, schaue ich mir ab und zu neue Ideen dazu an, und die Letzte erscheint mir sogar recht vielversprechend: Nexus (Link zum Nexus Guide), entwickelt vom Scrum-Erfinder Ken Schwaber und Scrum.org.

So wie ich es verstehe baut es auf die schon in Scrum vorhandene Idee auf, dass mehrere Teams an einem gemeinsamen Backlog arbeiten (und damit auch einen gemeinsamen Product Owner haben). Zu deren Koordination hat Nexus die Praktiken weiterentwickelt, 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, Refinements und Dailies finden dabei zuerst auf der Koordinationsebene und dann auf der Teamebene statt, bei den Retrospektiven ist es umgekehrt. Backlog Refinements und Sprint Reviews fallen aus diesem Muster heraus und finden als gemeinsame Veranstaltung statt.

Wirklich neu ist in Nexus nur eines: ein Integration Team. [Edit: dieser Abschnitt wurde nach dem Update des Nexus Guide 2018 angepasst] Zum einen sind hier die Spezialisten versammelt, die die Teams zwar ab und zu aber nicht in jedem Sprint brauchen, zum anderen können hier die erfahreneren unter den Teammitgliedern daran arbeiten, dass ihre Erfahrungen auch auf andere Teams übertragen werden. Wichtig ist, dass vor allem das Coachen und Beraten (nicht das Anleiten oder Koordinieren) der eigentlichen Teams zu den Aufgaben des Integration Teams gehört. Es soll kein Selbstzweck werden und kann seine Zusammensetzung immer wieder ändern, je nachdem in welchen Bereichen gerade Coaching- und Beratungsbedarf besteht. Mitglieder der eigentlichen Teams die im Integration Team mitarbeiten müssen dafür soweit wie nötig freigestellt werden.

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. Eine schleichende Aushöhlung der Selbstorganisation 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.


Nachtrag März 2020:
Mittlerweile habe ich in mehreren Nexus-Teams mitgearbeitet und bin sehr angetan.