 |
| Bild: Pixabay/Geralt - CC0 1.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, Lean-Agile Leader, Epic Owner oder Lead Scrum Master, in der Realität erwiesen sie sich aber fast immer als die klassische Lehmschicht, bzw. Lähmschicht, die in vielen Großunternehmen so verheerend wirkt indem sie Informationen durch Flaschenhälse leitet und starre Prozesse und Hierarchien einführt.1 Da die Lösung allerdings nicht sein kann, dass man auf skaliertes Scrum ganz 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 von Ken Schwaber und Scrum.org.
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 meistens aus
