Skalierte Agilität – wie Teams effizient orchestriert werden (Teil I)

Die skalierte agile Entwicklung erfordert, dass viele Teams auf ein gemeinsames Ziel hinarbeiten. Eine optimale Teamstruktur minimiert Kommunikations- und Abstimmungsaufwand und verkürzt so die Time to Market - die Dauer zwischen Idee und Lieferung. Aber gibt es überhaupt eine optimale Teamstruktur? Leider lautet die Antwort: normalerweise nicht. Aber es gibt Bausteine und Heuristiken, die zu einer deutlichen Verbesserung gegenüber einer Ad-hoc-Topologie führen können, wie wir in der Praxis gesehen haben.

Was bedeutet skalierte Agilität für Teams?

Bisher haben wir alles richtig gemacht: Unser interdisziplinäres agiles Team produziert kontinuierlich - iterativ - Lösungsinkremente. Jetzt aber soll eine richtig große Anwendung gebaut werden: eine globale Versicherungslösung. Wir skalieren.

Nun haben wir viele Teams und ordnen jedem von ihnen klar separierte Teilaufgaben zu, zum Beispiel verschiedene Features der Gesamtlösung oder Teilbereiche eines Ende-zu-Ende-Prozesses. Eine ideale Situation, was den Synchronisierungsaufwand zwischen unseren Feature-Teams betrifft – leider für uns nur bedingt zu gebrauchen.

Wir stellen nämlich fest, dass unser Technologie-Stack von Frontend über Middleware zu Backend und Datenbanken so groß ist, dass kein cross-funktionales Team aus neun oder elf Menschen die notwendigen Skills zusammenbringen kann. Wir schrauben also unsere Ansprüche herunter: Als nächstes clustern wir Teams in Tribes oder Agile Release Trains (ARTs). Lediglich die Gesamtheit der Cluster muss cross-funktional sein.

Punktwolken im Raum

Aber wie genau clustern wir? Wir erinnern uns an graphentheoretische Cluster-Optimierung. Die Aufgabe: Finde Punktwolken (Team-Cluster) im Raum, so dass die Punkte (Teams) mit den größten Abhängigkeiten und damit dem größten Kommunikationsbedarf möglichst in derselben Wolke oder zumindest in einer nahe gelegenen Wolke liegen. Die Analogie zum Bürogebäude zwingt sich auf: wer viel miteinander zu tun hat, sollte sich im selben Büro oder zumindest im selben Stock befinden. Nur für seltene Fälle sollte man einmal quer durch das Bürogebäude laufen müssen.

Wenden wir also ein Optimierungsverfahren zur Annäherung an die optimale Teamtopologie an. Man ahnt es schon: Das geht so einfach nicht. Uns fehlen zum Beispiel die Daten über die Häufigkeit und Struktur des Kommunikationsbedarfs. Zudem können die sich im Laufe der Zeit ändern. Es muss einen besseren Weg geben.

Auswirkungen schlechter Teamorchestrierung

Kommen wir auf unser Versicherungsportal zurück. Die Teamstruktur folgt der dreistufigen Lösungsarchitektur und enthält Teams für Frontend-, Middleware- und Backend-Komponenten. Zusätzlich wurden beim „vertikalen“ Teamschnitt die (operativen) Wertströme berücksichtigt: Für jeden der durch unser Portal bereitgestellten Dienste umfasst ein Wertstrom alle wesentlichen Schritte, die vom Auslöser bis zur Bereitstellung des Ergebnisses erforderlich sind. Typische Wertströme einer Versicherung sind etwa „Sales“ für die Suche, Auswahl, Konfiguration und den Kauf eines Versicherungsproduktes oder für „Claims“ im Versicherungsfall.

So weit, so gut. In der Praxis haben wir dennoch starke Abhängigkeiten zwischen Teams und Clustern feststellen müssen. Woran lag das? Zum einen wurden die Wertströme zwar definiert, aber nicht immer durch hinreichend abgegrenzte Module mit definierten Schnittstellen abgebildet. Zum anderen führte die mangelnde funktionale Kapselung unterer Schichten sowie die teilweise monolithischen Kernsysteme mit gemeinsamen Datenbereichen zu weiteren horizontalen und vertikalen (schichtübergreifenden) Abhängigkeiten. In der Konsequenz war die Synchronisation – insbesondere zwischen Clustern – aufwändig, dies führte zu Wartezeiten und Verzögerungen. Der "Wertfluss" war gebremst.

Einführung von Teamtopologien

Wie wir gesehen haben, reicht eine Wertstromorientierung allein nicht aus. Wir brauchen auch Unterstützung durch eine modulare Geschäfts- und Systemarchitektur, um eine effiziente Teamorganisation aufzubauen. Wie können nun aber Architektur, Wertströme und Teamtopologie in der Praxis aufeinander ausgerichtet werden?

Eine wertvolle Idee dazu liefern Matthew Skelton und Manuel Pais in ihrem Buch "Team Topologies". Sie führen vier standardisierte und klar definierte Typen von Teams ein (die wir hier Kategorie nennen wollen) und zeigen, dass mit diesen alle in der Praxis relevanten Team-Strukturen aufgebaut werden können. Außerdem beschreiben sie typische Muster, nach denen sich die Kommunikation zwischen den Kategorien richtet.

Die vier Team-Kategorien sind:
 

Stream Aligned Team

Die führende Teamkategorie. Wie das oben erwähnte Feature Team ist ein Stream Aligned Team auf einen oder mehrere Schritte eines einzelnen End-to-End-Wertstroms ausgerichtet. Es lässt sich leicht an Änderungen anpassen und implementiert in der Regel kundenorientierte Lösungsfunktionen.

Platform Team

Durch die Bereitstellung gemeinsamer, generischer Schnittstellen (APIs, Services) stellen diese Teams die Unabhängigkeit und Flexibilität von Stream Aligned Teams sicher. Ein Platform Team ist in der Regel als langfristiger und autonomer Organismus konzipiert und verfügt über Erfahrung sowie Kompetenzen im Produkt-Management.

Enabling Team

Diese Kategorie kann als Verallgemeinerung des SAFe-Konzepts eines Systemteams verstanden werden. Im Gegensatz zu Community of Practices oder Chapters kann es eine vorübergehende Lebensdauer haben, in der es andere Teams auf drei Arten kontinuierlich verbessert:

• Wissen und Fähigkeiten übertragen
• Hindernisse beseitigen
• Erleichterung der Infrastruktur

Complicated Subsystem Team

Diese Kategorie widmet sich speziellen Fähigkeiten für spezielle Komponenten (in einem bestimmten Kontext), beispielsweise Embedded Systems, Krypto-Lösungen oder Versicherungsaltsystemen.

Weiter zum 2. Teil der Serie

Was bieten diese Teamkategorien konkret für Vorteile? Warum sollten sie helfen, die Effizienz der Teamorchestrierung zu steigern, und wie kann ich in der Praxis vorgehen? Antworten darauf finden sich in Teil 2 unserer Serie.

Co-Autor: Stefan Hanslmaier (Allianz – XING)

Quelle Titelbild: AdobeStock/pict rider