Scrum of Scrums im agilen Entwicklungsumfeld
Die Vorteile einer agilen Entwicklung in digitalen Transformations-Projekten und -Programmen innerhalb und außerhalb des Kundenservices haben sich in den letzten Jahren längst bestätigt und etabliert. Ebenso gelingt auch immer besser die Verzahnung mit durch die Organisation vorgegebenen bzw. bestehenden Waterfall-Modellen, die mit festen Releases, Timelines oder Iterationen operieren müssen.
Denn schließlich bedeutet “agile Entwicklung” nicht, dass man dadurch keine Ergebnisse zu festen vorgegebenen Terminen vorweisen müsste. Sondern genau das Gegenteil, nämlich dass man viel präziser auf das Ziel/Ergebnis zusteuert, und sich auf dem Weg dorthin jedoch eine hohe Flexibilität erhält, um im Gegenzug genau dieses Ziel zu erreichen.
Zu viele parallele agile Projekte?
In der Regel laufen agile Projekte jedoch nicht einzeln und isoliert. Vielmehr laufen mehrere Projekte üblicherweise parallel in dieser Struktur, wenn man sich einmal auf sie geeinigt hat. Zudem ändert sich, je nach Bedarf, im Projektverlauf auch die Skalierung der Teams als auch Überschneidungen mit anderen agilen Projekten – temporär oder sogar permanent.
Hier gibt es häufig eine Sollbruchstelle, auf die wir in diesem Tipp der Woche einmal genauer blicken wollen. Wie stellt man sicher, dass viele parallel agierende agile Projekte nicht isoliert agieren, entsprechende Entwicklungsstände transparent bleiben, und auch Abhängigkeiten oder Auswirkungen auf die jeweils betroffenen Projekte bewertet, priorisiert und gesteuert werden?
Man kann natürlich versuchen die jeweiligen einzelnen Projekte in einer Gesamt-Backlog-Active-Done-Char-Übersicht oder einem Kanban-Board einzubetten. Dies wird aber mit der größer werdenden Anzahl von Projekten, Tasks und deren Beschreibungen, Requirements, Akzeptanzkriterien, DoD… etc. irgendwann sehr unübersichtlich, und man verliert den Überblick. Insbesondere den Überblick von Abhängigkeiten oder Überschneidungen, da die Teams trotzdem zumeist innerhalb ihrer eigenen Lanes operieren.
Mehr Überblick durch Scrum of Scrums
Ein Lösungsansatz ist hier eine Scrum of Scrums (SoS) Struktur zu etablieren. Das Prinzip von Scrum of Scrums orientiert sich sehr am klassischen Scrum-Ansatz und bietet die Möglichkeit, Scrum Organisationen oder Projekte agil skalierbar zu halten.
Wichtig ist es dabei, folgende Elemente zu beachten:
- Welche Vertreter der jeweiligen einzelnen agilen Projekte müssen in diesem SoS Gremium dabei sein?
Das können z.B. ein/e Product-Owner, Tribe Lead, Squad Lead, Application Owner o.ä. sein.
- Welches Framework soll für dieses SoS genutzt werden, welche Priorisierungs- und/oder Erfolgskriterien bzw. KPIs sind wesentlich?
Hier sind übergreifende Ziele zu empfehlen, welche sich stark an den wesentlichen Unternehmens-KPIs orientieren. Stellen Sie ein Tracking zur Verfügung, dass den Gesamterfolg (!) anhand der definierten KPIs visualisiert.
- Definition eines von allen Stakeholdern akzeptierten SoS-Scrum Masters.
Dieser verfügt über fundierte Kenntnisse zu den übergreifenden Programmen/Initiativen des Unternehmens als auch idealerweise gute Kenntnisse über die Einzelprojekte als auch Überschneidungen und Abhängigkeiten.
- Welche Regelkommunikations-Frequenz ist für das Team oder Teile des Teams sinnvoll?
Hier empfiehlt es sich analog zu einzelnen Scrums ein Daily Standup im Anschluss an die anderen Standups der Einzelprojekte durchzuführen, da dann alle aktuellen Informationen, Planungen und Veränderungen verfügbar sind. Zudem sollte ein SoS Sprint zeitlich parallel mit den Sprints der anderen Maßnahmen erfolgen. Als Ergebnis kann auch ein Refinement innerhalb des SoS Veränderungen in anderen Einzel-Sprints zur Folge haben, wenn wesentliche Enabler oder Abhängigkeiten dies sinnvoll erscheinen lassen.
- Wie erfolgt die Aufbereitung als auch Dokumentationen der Informationen bzw. Des jeweiligen Einzel-Projektstatus?
Empfehlung ist, dass die jeweiligen Tribe- oder Squad-Leads nur die Tasks aggregieren und in das SoS-Board einkippen, welche entweder hohe Relevanz haben, zeitkritisch sind und/oder Überschneidungen/Abhängigkeiten zu anderen Projekten aufweisen können.
- Wie stelle ich fest, ob das SoS erfolgreich aufgesetzt ist und funktioniert?
Es gibt hier keine Standard-Lösung oder Verfahrensweise. Indikatoren können sein: Wie gut ist die Teilnahme und Beteiligung der Stakeholder innerhalb der Regeltermine? Wie viele Termine können im vorgegebenen Zeitfenster abgeschlossen werden? Wie viele unbekannte Abhängigkeiten/Risiken treten trotz Abstimmung auf? Wie gut ist die Dokumentationsqualität?
- Extra-Tipp: Ein Agile Coach kann besonders zum Start einer SoS-Einführung eine gute Unterstützungslösung sein, bis sich die jeweiligen Arbeits- und Verfahrensweisen im Gesamtteam etabliert haben, und bei Konflikten gerade zum Start zwischen den jeweiligen Betroffenen moderieren.
Fazit
Eine Scrum of Scrums Struktur ist keine Allzwecklösung für alle Situationen und je nach Team- oder Projektgröße oder bei einem bewusst isolierten Projekt, ohne Überschneidungen in andere Bereiche, kann z.B. ein reiner Kanban Ansatz ohne eine personalintensivere Scrum-Organisation ein pragmatischer und kostengünstigerer Ansatz sein.
Je mehr parallele agile Projekte man aber startet und je mehr Abhängigkeiten und Überschneidungen und Interessenskonflikte entstehen, desto hilfreicher ist es eine Gesamtsteuerung im Sinne von agilem Multi-Projektmanagement aus Gesamtunternehmenssicht zu etablieren. Und hierfür kann SoS tatsächlich eine gute Lösung darstellen.
Carlos Carvalho – Senior Consultant
