Grundidee
„Team Topologies” von Matthew Skelton und Manuel Pais ist kein weiteres Buch über agile Methoden. Es ist ein Framework für Organisationsdesign — mit einer klaren These: Die Art, wie Teams geschnitten und miteinander verbunden werden, bestimmt maßgeblich die Qualität der Software, die sie produzieren.
Das klingt trivial. Ist es aber nicht. Denn die meisten Organisationen strukturieren ihre Teams nach verfügbaren Personen, historisch gewachsenen Zuständigkeiten oder schlicht nach dem Organigramm — nicht nach dem, was die Software tatsächlich braucht.
Conway’s Law
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
Conway’s Law ist keine Empfehlung — es ist eine Beobachtung. Und eine, die sich in der Praxis immer wieder bestätigt: Die Architektur eines Systems spiegelt die Kommunikationsstrukturen der Organisation wider, die es gebaut hat. Wenn drei Teams an einer Anwendung arbeiten, besteht das Ergebnis aus drei Teilsystemen — unabhängig davon, ob das architektonisch sinnvoll ist.
Skelton und Pais drehen diesen Gedanken um: Wenn die Organisationsstruktur die Architektur bestimmt, dann sollte man die Organisation bewusst so gestalten, dass die gewünschte Architektur entsteht. Sie nennen das den Reverse Conway Maneuver.
Team First: Cognitive Load als Designprinzip
Ein zentrales Konzept des Buches ist die kognitive Last eines Teams. Angelehnt an die Cognitive Load Theory von John Sweller unterscheiden Skelton und Pais drei Arten:
The capacity of working memory is limited. Instructional design must take this limitation into account.
- Intrinsic Cognitive Load: Die inhärente Komplexität der Domäne selbst. Ein Team, das ein Zahlungssystem baut, muss die Regeln des Zahlungsverkehrs verstehen — daran führt kein Weg vorbei.
- Extraneous Cognitive Load: Vermeidbare Komplexität, die durch schlechte Tools, unklare Prozesse oder überladene Zuständigkeiten entsteht. Das ist die Last, die man reduzieren kann und muss.
- Germane Cognitive Load: Die produktive Last — das Lernen und Verstehen neuer Konzepte, das langfristig die Kompetenz des Teams steigert.
Die ideale Teamgröße liegt bei 7 bis 9 Personen — groß genug für Redundanz und Vielfalt, klein genug für echte Kommunikation. Wird ein Team größer, steigt die kognitive Last überproportional. Wird die Domäne zu komplex für ein einzelnes Team, ist das ein Signal, den Teamschnitt zu überdenken — nicht, das Team zu vergrößern.
Die vier Teamtopologien
Das Herzstück des Frameworks sind vier fundamentale Teamtypen. Jeder Typ hat eine klar definierte Verantwortung und ein spezifisches Interaktionsmuster:
Stream-aligned Team
Ausgerichtet an einem Geschäfts- oder Wertschöpfungsstrom. Beispiel: Ein Team, das den gesamten Checkout-Prozess eines Onlineshops verantwortet — von der UI bis zur Datenbank.
Enabling Team
Hilft anderen Teams, neue Fähigkeiten aufzubauen. Beispiel: Ein Team, das Stream-aligned Teams bei der Einführung von Observability-Tooling unterstützt — nicht dauerhaft, sondern bis das Wissen transferiert ist.
Complicated-subsystem Team
Verantwortet eine technisch besonders anspruchsvolle Komponente. Beispiel: Ein Team für die Empfehlungs-Engine, deren Algorithmen Spezialwissen erfordern, das nicht jedes Stream-aligned Team aufbauen kann.
Platform Team
Stellt eine Self-Service-Plattform bereit, die Stream-aligned Teams die Arbeit erleichtert. Beispiel: Ein Team, das CI/CD-Pipelines, Deployment-Infrastruktur und Monitoring als internen Service anbietet.
Die meisten Teams in einer Organisation sollten Stream-aligned Teams sein — sie liefern den Wert. Die anderen drei Typen existieren, um Stream-aligned Teams schneller und effektiver zu machen.
Team-Interaktionsmodi
Ebenso wichtig wie die Teamtypen sind die definierten Interaktionsmuster zwischen Teams. Skelton und Pais beschränken sich bewusst auf drei Modi:
Collaboration
Zwei Teams arbeiten eng zusammen, um ein gemeinsames Ziel zu erreichen. Zeitlich begrenzt und bewusst anstrengend — Collaboration ist kein Dauerzustand, sondern ein Mittel zur Entdeckung.
X-as-a-Service
Ein Team stellt eine Fähigkeit als Service bereit, den andere Teams konsumieren. Klare Schnittstelle, minimale Abstimmung. Das Zielmodell für reife Plattformen.
Facilitating
Ein Team hilft einem anderen, eine Fähigkeit aufzubauen — und zieht sich dann zurück. Der typische Interaktionsmodus von Enabling Teams.
Die Reduktion auf drei Modi ist bewusst. In der Praxis entstehen sonst undurchsichtige Abhängigkeitsgeflechte, die niemand mehr überblickt. Drei Modi sind genug, um die wesentlichen Beziehungen abzubilden — und wenig genug, um sie aktiv zu steuern.
Organisatorisches Gespür
Ein unterschätzter Aspekt des Buches: Skelton und Pais betonen, dass Organisationsdesign kein einmaliges Projekt ist, sondern ein kontinuierlicher Prozess. Teams entwickeln sich, Domänen verschieben sich, und was heute funktioniert, kann morgen zum Engpass werden.
Dafür braucht es organisatorisches Gespür — die Fähigkeit, Signale frühzeitig zu erkennen: Wo entsteht eine zu hohe kognitive Last? Wo blockieren sich Teams gegenseitig? Wo ist ein Collaboration-Modus längst überfällig, obwohl beide Teams so tun, als wäre X-as-a-Service ausreichend?
Topologieentwicklung
Teamtopologien sind nicht statisch. Ein Enabling Team, das seine Aufgabe erfüllt hat, kann aufgelöst oder in ein Platform Team überführt werden. Ein Complicated-subsystem Team kann überflüssig werden, wenn die Komplexität seiner Komponente durch bessere Abstraktionen sinkt.
Die Kunst liegt darin, diese Übergänge bewusst zu gestalten statt sie dem Zufall zu überlassen. Skelton und Pais liefern dafür keine starren Regeln, sondern Heuristiken — und das ist eine Stärke des Buches, keine Schwäche.
Team-API
Ein besonders praktisches Konzept: die Team-API. Gemeint ist damit eine explizite Beschreibung dessen, was ein Team anbietet, wie man mit ihm interagiert und was man von ihm erwarten kann. Nicht als Vertrag im juristischen Sinne, sondern als lebendiges Dokument, das Transparenz schafft.
Eine Team-API kann enthalten: die Verantwortungsbereiche des Teams, bevorzugte Kommunikationskanäle, SLAs für Antwortzeiten, technische Schnittstellen und die aktuellen Interaktionsmodi mit anderen Teams. Das klingt nach Bürokratie — ist aber das Gegenteil. Es ersetzt informelle Erwartungen durch explizite Vereinbarungen.
Zusammenfassung
Team Topologies bietet ein überraschend kompaktes Framework für ein Thema, das die meisten Organisationen seit Jahrzehnten ad hoc lösen. Die Kombination aus Conway’s Law, kognitiver Last, vier Teamtypen und drei Interaktionsmodi schafft ein Vokabular, das Diskussionen über Organisationsdesign strukturiert und produktiv macht.
Herausforderungen
So überzeugend das Framework in der Theorie ist — die Umsetzung in der Praxis hat ihre Tücken. Bestehende Organisationen lassen sich nicht über Nacht umstrukturieren. Politische Widerstände, historisch gewachsene Zuständigkeiten und die schiere Trägheit großer Systeme stehen einer sauberen Implementierung oft im Weg.
Hinzu kommt: Team Topologies setzt voraus, dass man die eigene Domäne gut genug versteht, um sinnvolle Teamschnitte zu definieren. Das ist in der Praxis häufig die größte Hürde — nicht das Framework selbst.
Schlussfolgerung
Team Topologies ist Pflichtlektüre für alle, die sich mit dem Zusammenspiel von Organisationsdesign und Softwarearchitektur beschäftigen. Das Buch liefert keine Patentrezepte, aber ein robustes Denkmodell, das hilft, die richtigen Fragen zu stellen. Und die richtigen Fragen zu stellen ist — wie so oft in der Softwarearchitektur — der schwierigste und wichtigste Schritt.
Geschäftsbereichsleitung «Handel», Prokurist
Kaschef Yawar ist erfahrener agiler Coach und Berater mit über 15 Jahren Erfahrung in der IT-Branche. In verschiedenen Rollen als Scrum Master, Agiler Coach und Trainer unterstützt er Teams und Organisationen bei der agilen Transformation.
