Scaled Agile: Hybrid-Strukturen vs. Meta Teams

Bild: Flickr / St Munchin's College - CC BY 2.0

Ein Thema das mich seit meinem ersten agilen Projekt begleitet ist die Frage nach der Skalierung. Dass Scrum in kleinen Teams funktioniert sieht noch fast jeder ein, sobald es in Größenordnungen von fünf Teams aufwärts geht kommen aber Zweifel auf. Einer der häufigsten Einwände: da sich die Teams selbst untereinander koordinieren müssen steigt mit jedem weiteren dazukommenden der Kommunikationsaufwand. Früher oder später ist der nicht mehr zu bewältigen und die Koordination bricht zusammen. Die Teams zerschießen sich dann gegenseitig den Code, arbeiten redundant oder bauen inkompatible Komponenten. Als Lösung wird von klassischen Managern häufig ein Hybrid-Modell installiert: die Entwicklungsteams arbeiten weiter agil, oberhalb von ihnen wird ein Wasserfall aufgesetzt, der die Anforderungen erfasst und auf die Teams verteilt (ein Framework dem man das häufig vorwirft ist das Scaled Agile Framework, bzw. SAFe). Ein solches Modell sieht etwa so aus:


Auf den ersten Blick mag das zwar ganz sinnvoll erscheinen, in der Realität kollabiert die Kommunikation in diesem Modell aber erst recht. Wenn z.B. Team 1 bemerken sollte, dass versehentlich eine nicht umsetzbare Anforderung in eine Story geflossen ist, muss es das an die nächsthöhere Ebene zurückmelden. Diese muss dann gegebenenfalls auch Team 2 zurückrufen, da auch dieses von der Falschannahme betroffen ist. Da aber der Weg von Team 1 nach oben und von dort wieder nach unten Zeit in Anspruch nimmt hat Team 2 bereits mit der Arbeit begonnen. Die war damit umsonst und kann jetzt weggeworfen werden. Noch verheerender wird es wenn von dem Fehler in der Anforderung auch eines der Teams drei bis sechs betroffen ist: der Feedbackweg geht dann noch weiter nach oben und von dort wieder nach unten, die Benachrichtigung der anderen Teams erfolgt noch später, noch mehr Zeit und Geld werden verschwendet. Das ist also kein sinnvoller Weg.

Es bleibt die Frage: Wenn nicht so, wie dann? Dass sich jedes Team mit jedem anderen direkt abstimmt führt ja auch zu Problemen (siehe oben). Ein möglicher Ausweg geht so:


Man sieht: ein deutlich flacheres Modell. Der hier gewählte Lösungsansatz ist der, dass thematisch oder technisch verwandte Teams enger kooperieren als andere. Die Teams eins und zwei arbeiten beispielsweise gemeinsam am CMS, drei und vier am Shop, fünf und sechs an verschiedenen Mobile-Apps. In den zusammengehörigen Teams finden engere Abstimmungen statt, etwa zwischen den POs (die sogar ein Meta-PO-Team bilden können) und zwischen den Entwicklungteams (durch gemeinsame Groomings, Reviews, etc.). Die verschiedenen Gruppierungen stimmen sich dann direkt (ohne koordinierende Management-Ebene) mit den jeweils anderen ab, etwa in Form eines Scrum of Scrums. Reibungsverluste gibt es zwar auch hier (ganz vermeiden kann man die im skalierten Vorgehen nie), sie sind aber deutlich geringer als im oben gezeigten Modell. Zum Einen weil es kaum Kommunikationswege über mehrere Hierarchieebenen gibt, zum anderen weil die Entwickler ohne technikfremde Zwischenpersonen direkt miteinander kommunizieren können. Im Großen und Ganzen erfolgt die Koordination so wesentlich effektiver.

Was dabei allerdings klar sein muss: auch dieses Modell ist nicht universell anwendbar. Es ist eine Lösungsmöglichkeit, die zwar besser als das Hybrid-Modell funktioniert, je nach Kontext aber weiter angepasst werden muss. Für diese Anpassungen gibt es dann wieder weitere Möglichkeiten wie z.B. Communities of Practice, Gilden, teamübergreifende Plannings und Backlogs oder Unterstützungs-, bzw. Spezialistenteams. Das sind dann aber wieder Themen für sich.