The agile Bookshelf: Team Topologies

Bild: Pexels / Huy Chien Tran - Lizenz

Bevor es zu seinem Inhalt geht eine Vorbemerkung: das Schöne an diesem Buch ist, dass es selbst so entstanden ist wie agile Produktentwicklung idealerweise ablaufen sollte - iterativ-incrementell. Angefangen hat alles mit einem Blog-Post, weiter ging es mit einer Website, mehr und mehr Inhalte kamen über die Zeit dazu und irgendwann waren es so viele, dass sich der Buchdruck gelohnt hat. Um das so entstandene Werk soll es hier gehen, Team Topologies von Matthew Skelton und Manuel Pais.

Aufgeteilt ist es in drei grosse Abschnitte. Im ersten gehen die beiden Autoren auf die Faktoren ein die die Arbeit von Teams in grösseren Firmen typischerweise beeinflussen. Dazu gehört ganz zentral die Aufbau-Organisation mit ihren Ressorts, Bereichen, Abteilungen und ähnlichen Untereinheiten. Diese sind in der Regel anhand von beruflichen Spezialisierungen geschnitten (z.B. Konzeption, Entwicklung, Test) und behindern so eine ganzheitliche Sicht der Wertschöpfung.¹

Als zusätzliche Dimension dieser Aufbau-Organisation kommt dazu, dass sich üblicherweise auch die Kommunikationsströme an diesen Stukturen ausrichten, und zwar auch dann wenn direkte Kommunikation effektiver und schneller wäre. Da diese Kommunikationsströme meistens auch die Strukturierung der internen IT-Systeme vorgeben (das so genannte Conway's Law) tendieren auch diese dazu eher lokal optimiert zu sein, schlimmstenfalls auf Kosten des Gesamtsystems.

Zu den häufigen Folgen eines derartigen Organisations- uns Systemdesigns gehören zwei folgenschwere Missstände: erstens eine hohe kognitive Belastung der Teams, die dadurch entsteht, dass sie sich gleichzeitig mit (zu) vielen Aufgaben, Abhängigkeiten und Informationen beschäftigen müssen, zweitens die Verlangsamung vieler Vorgänge durch die zahlreichen Abhängigkeiten, durch die fast jedes der (zu) spezialisierten Teams früher oder später zu einem Flaschenhals für die anderen wird.

Als Gegenentwurf definieren Skelton und Pais im zweiten Abschnitt ihres Buchs vier grundlegende Team-Typen, die je nach Kontext gewählt (und später wieder verändert) werden können um eine optimale Balance zwischen möglichst wenigen Abhängigkeiten auf der einen Seite und möglichst geringer kognitiver Belastung auf der anderen Seite zu ermöglichen. Die vier Typen sind Stream-aligned Team, Enabling Team, Complicated Subsystem Team und Platform Team.

Die für die Wertschöpfung beste Variante ist die erste der vier, das Stream-aligned Team, das alle Tätigkeiten entlang der gesamten Wertschöpfungskette selbst ausüben kann, inclusive der Bereitstellung der Infrastruktur und des Betriebs auf Produktion. Die anderen drei Team-Varianten machen vor allem dort Sinn wo Stream-aligned Teams von besonders aufwändigen Teilaufgaben entlastet werden können, sie arbeiten diesen also zu und richten sich an ihnen aus.

Enabling Teams bestehen dabei aus Spezialisten für ein bestimmtes Thema, die dieses aber nicht monopolisieren oder regulieren sondern stattdessen anderen helfen in ihm besser zu werden. Complicated Subsystem Teams übernehmen Entwicklung und/oder Betrieb besonders spezialisierter oder komplizierter Software-Komponenten, die sie anderen zur Verfügung stellen, Platform Teams machen Werkzeuge und Infrastrukturen so verfügbar, dass andere sie einfach nutzen und konfigurieren können.

@tom_geraghty puts together a summary of the main points from the 2021 State of DevOps Report highlighting top take aways including how #TeamTopologies can help to improve flow.#DevOps #SODOR2021
https://t.co/IWnUYSEbe1 pic.twitter.com/qq8FW1pFra

— Team Topologies (@TeamTopologies) August 25, 2021

Im dritten Abschnitt des Buchs werden schliesslich drei möglichst effektive Kooperationsformen zwischen den Teams beschrieben. Es sind Collaboration Mode, in dem vonenander unabhängige Teams auf ein gemeinsames Zeil hinarbeiten, X-as-a-Service Mode, in dem ein Team dem anderen Komponenten, Werkzeuge und Infrastrukturen bereitstellt und Facilitation Mode, in dem ein Team dem anderen hilft Expertise und Erfahrung in einem Wissensgebiet zu entwickeln.

Natürlich gehen Matthew Skelton und Manuel Pais an vielen Stellen noch deutlich tiefer in die Details, zeigen Zusammenhänge, Kontextinformationen und Risiken auf und weisen auf Good Practices und Fallstudien hin. Auch die Informationsgrafiken sind so gut, dass sie es viedient haben hier gesondert erwähnt zu werden. Im grossen und Ganzen ist der Inhalt des Buches aber der hier beschriebene (es zu kaufen lohnt natürlich trotzdem).

Für die Umsetzung der in ihm stehenden Team- und Zusammenarbeitstypen geben die beiden schliesslich noch einen entscheidenden Ratschlag mit. Das Ganze ist nicht gedacht als Analyse-Werkzeug, mit dem man die "historisch gewachsene" Ist-Situation beschreibt sondern als Baukasten für bewusstes und regelmässiges Organisations-(Re)Design, mit dessen Hilfe die eigene Firma immer wieder optimiert und auf neue Rahmenbedingungen angepasst werden kann. Ganz im Sinn eines kontinuierlichen Verbesserungsprozesses.