„Team Topologies“ - Das Stream-Aligned Team im Zentrum einer agilen Organisation

Schon lange beschäftige ich mich mit agilen Vorgehensweisen und dabei insbesondere auch mit skalierten Ansätzen wie z.B. LeSS (Large-Scale Scrum). Die spannendsten Fragen dabei sind, bis zu welcher Organisationsgröße diese Ansätze reichen und wie man am besten mit einer agilen Transformation beginnt. Diese Fragen hängen eng miteinander zusammen, da nach meiner Erfahrung, eine Transformation hin zu einer agilen Produktentwicklung gar nicht so selten „von oben“ initiiert wird, aber dennoch meist erstmal als ganz kleines Pflänzchen in der Entwicklungsabteilung begonnen wird. Es gibt Stimmen, die eine komplette Transformation einer Organisation in einem Rutsch, als eine schnelle und trotzdem nachhaltige Möglichkeit sehen, einen Umbau vorzunehmen. Dabei verkennt man meiner Meinung nach massiv, dass eine agile Vorgehensweise viel mehr ist als neue Titel, neue Rollen und neue Prozesse. Es ist vor allem ein Mindset und dies kann nicht auf die Schnelle nachhaltig „implementiert“ werden. Mit einem einzigen Produkt zu beginnen, dieses überhaupt erstmal zu identifizieren und ein Team zu ermächtigen, dieses eine Produkt weiterzuentwickeln, ist bereits eine große Aufgabe und erfordert Zeit und Fingerspitzengefühl in der Etablierung innerhalb einer gewachsenen Organisationsstruktur. Flankiert von Maßnahmen im Umfeld dieser ersten Produktentwicklungseinheit bzw. deren Einbettung in den organisatorischen Gesamtkontext, ist eine notwendige Stabilisierungsmaßnahme, die noch weit vor jeder Skalierung ansteht.

Was heißt es nun eigentlich einen „skalierten agilen Ansatz“ zu wählen? Es gibt dabei mindestens zwei sehr verschiedene Maßnahmen, die gemeint sind:

1. Mehrere Produktentwicklungsteams für die Weiterentwicklung eines Produktes einzusetzen
2. Die gesamte Organisation, also nicht nur die Entwicklungseinheiten, agile oder zumindest agiler, arbeiten zu lassen.

Für ersteres gibt es verschiedene Standard-Frameworks, wie z.B. LeSS (Large-Scale Scrum), Nexus oder Scrum@Scale, um nur ein paar Prominente zu nennen. Richtig durchgesetzt hat sich keines davon. Vielmehr verwenden Firmen leider meist kuriose Mischformen aus diesen Ansätzen und klassischem Scrum, oft noch mit einer Brise Kanban gewürzt und mit ein wenig Wasserfall hier und da. Ich führe das darauf zurück, dass einerseits keines dieser Frameworks einfach umzusetzen ist und zweitens, die Skalierung begonnen wird, wenn Teams bereits einige Monate oder Jahre agile Erfahrung haben und besonders wert darauflegen, selbst-organisiert und eigenverantwortlich vorzugehen und daher sich auch in der Lage sehen, selbst aus dem skalierten agilen Portfolio einzelne Komponenten herauszupicken. Dies kann gelingen, passiert aber leider oft in einem vermeintlich gereiften Umfeld und daher oft ohne Begleitung durch entsprechende Spezialisten in Form eines Scrum Masters oder Agilen Coaches. Letzteres führt dann mittelfristig zu skurrilen Stilblüten und eben nicht echter agiler Vorgehensweise. Übrig bleibt leider der falsche Eindruck, dass Skalierung innerhalb der Entwicklungsabteilung nicht erfolgreich umsetzbar ist.

Die zweite Form von Skalierung bezieht sich auf die gesamte Organisationsstruktur, also der Versuch, eine komplette Firma hin zu einer agilen Vorgehensweise zu transformieren.  Letzteres passiert leider in der Regel völlig losgelöst von agilem Produktdenken, dem Herz und der Seele agiler Vorgehensweise also. Es kommt oft in der Form von SAFe daher und wird von Heerscharen von agilen Coaches trainiert und implementiert. Auf dem Papier ist SAFe eine große Erfolgsgeschichte, verdient man mit der Umsetzung dieses Frameworks doch Unmengen an Geld und finanzieller Erfolg macht sexy. Wie ernsthaft und nachhaltig nach einer Umstellung auf SAFe ein Unternehmen tatsächlich agile ist, darf bezweifelt werden. Eine Umbenennung von Planungsmeetings und die Vergabe von „agilen Titeln“ allein, ist halt nun mal vielmehr ein Cargo-Kult, als eine echte Änderung des Mindset.

Ich möchte hier im Weiteren auf Skalierungen der ersten Kategorie eingehen und auf einen neuen Ansatz aufmerksam machen, über den ich erst vor Kurzem gestolpert bin. Es handelt sich um „Team Topologies“, das in gleichnamigem Buch von Matthew Skelton und Manuel Pais beschrieben wird. Ausgangspunkt dafür ist Conways Law und das besagt, das Organisationen, die ein System designen, als Ergebnis ein Design wählen werden, das eine Kopie der Kommunikationsstrukturen innerhalb der Organisation darstellt. Entsprechend schlussfolgern die Autoren, dass bereits die Organisationsstruktur entsprechend dem gewünschten Endergebnis gewählt sein muss.

Ein weiteres Schlüsselargument ihrer Ausführungen ist, dass die Komplexität eines Systems anwächst und entsprechend die kognitiven Fähigkeiten jedes Einzelnen, jedes Teams und der gesamten Organisationsstruktur immer stärker gefordert werden. Diese kognitive Last und deren Bewältigung bei der Organisationsstruktur zu berücksichtigen, ist entsprechend entscheidend. Aufgabenbereiche zu identifizieren, die klar getrennt werden können und die eigenverantwortlich bearbeitet werden können, ist das Ziel. Die dafür notwendigen, relativ unabhängigen, Einheiten zu identifizieren und aus ihnen ein System und Sub-System abzuleiten, das zusammenhält, das kohärent ist, klare Grenzen enthält und andererseits lose Kopplungen zwischen manchen Einheiten pflegt, wird als das „Reverse Conway Maneuver“ bezeichnet und „Team Topologies“ beschreibt, wie dieses Manöver in der Praxis aussieht und umgesetzt werden kann.

Es wird im Rahmen des Buches hergeleitet, dass es lediglich vier fundamentale Arten von Teams gibt, die auf drei verschiedene Arten zusammenarbeiten können:

1. „Stream-Aligned Teams“: so etwas wie ein agiles Team, wie z.B. ein Scrum Team
2. „Enabling Teams“: ein Team von Spezialisten, einer technischen oder Produktdomäne, das die nötigen Resourcen hat, um Research zu betreiben, Tools zu evaluieren, technische Vorgehensweisen zu sondieren und vorzuschlagen. Es unterstützt also Stream-Aligned Teams, bessere, weil fundiertere Entscheidungen, für die Umsetzungen zu treffen.
3. „Complicated Sub-System Teams“: ein Team, das für die Umsetzung eines komplizierten Sub-Systems innerhalb eines Produktes verantwortlich ist. Für diese Umsetzung ist Experten-Wissen nötig und kann im Sinne der kognitiven Auslastung nicht innerhalb eines Stream-Aligned Teams umgesetzt werden.
4. „Platform Teams“: ein Team, das zum Zwecke der Reduktion der kognitiven Last von Stream-Aligned Teams, interne Services entwickelt und bereitstellt. Es geht dabei um digitale Services wie z.B. self-service APIs, Support und den Betrieb der entsprechenden Infrastruktur für diese Services.

Anbei eine Illustration aus dem Buch, über diese vier fundamentalen Team-Typen und wie sie zusammenarbeiten:

Vereinfacht zusammengefasst, beschreibt „Team Topologies“, dass es entscheidend ist, ganz im agilen Sinne, dass die Stream-aligned Teams die Produktverantwortung haben und selbstorganisiert handeln. Im Rahmen der Skalierung lassen sich aber Aufgabenbereiche identifizieren, die das Aufstellen einer oder mehrerer der drei anderen „Unterstützer-Teams“ sinnvoll erscheinen lassen, um eine signifikante Entlastung der Stream-aligned Teams herbeizuführen.

Ich kann folgenden Vortrag auf YouTube empfehlen, der das Thema viel ausführlicher beleuchten, als ich hier in der Kürze dazu in der Lage war: Adaptive Organisationsgestaltung mit Team Topologies (youtube.com)

Weiterhin darüber hinaus nochmal die Buchempfehlung: