Team Topologies beschreibt die Organisation von IT- und Software-Teams für einen optimalen Arbeitsfluss. Um diesen zu erreichen, definieren Teamtopologien das Design einzelner Teams und ihre optimalen Interaktionsmuster mit anderen Teams. Die Idee stammt von den beiden Beratern Matthew Skelton und Manuel Pais und ist in ihrem Buch “Team Topologies: Organizing Business and Technology Teams for Fast Flow” ausführlich beschrieben.

In diesem Beitrag findest Du eine kurze Einführung der Team Topologie und wie Du damit deine IT- und Software-Organisation für einen optimalen Arbeitsfluss designst. 

Einführung in Team Topologien – Vier Team-Typen und drei Interaktionsmuster

Eine Topologie beschreibt in der Mathematik die Lage und Anordnung geometrischer Gebilde im Raum. In der Informatik beschreibt eine Topologie den Aufbau eines Rechnernetzes, d.h. wie einzelne Computer in einem Netzwerk angeordnet und miteinander verbunden sind. 

Analog dazu beschreiben Teamtopologien die Anordnung von Teams und ihre Beziehung untereinander. Dazu definieren Team Topologies vier Archetypen von Teams und drei daraus aufbauende Interaktionsmuster zwischen Teams.

Stream-Aligned Teams

Ziel: Stream-Aligned Teams stellen Nutzern und Kunden Dienste bereit. Damit realisieren Stream-Aligned Teams Customer und Business Value.

Stream-Aligned Teams richten sich an Wertströmen aus. Dabei ist ein Wertstrom ein geschäftskritischer Prozess, ein Service oder ein Produkt deines Unternehmens. Das heißt, Stream-Aligned Teams erstellen eine Leistung, die von internen Anwendern oder externen Kunden genutzt werden. Dabei haben Stream-Aligned Teams die volle Verantwortung für den kommerziellen Betrieb der Anwendung. Das fängt bei der Evaluierung von Kundenbedürfnissen an, geht über die Konzeption, die Entwicklung bis zum Support. Bei diesen Aufgaben werden sie von den anderen Teams unterstützt. Mit ihrer Ausrichtung an Wertströmen sind Stream-Aligned Teams das Herz deiner Organisation. 

Platform Teams

Ziel: Platform Teams stellen technische Dienste zur barrierefreien Nutzung zur Verfügung. Damit senken sie den Aufwand anderer Teams.

Plattform Teams stellen anderen Teams Infrastruktur und technische Services wie z.B. Deployment- und Monitoring-Systeme bereit. Durch eine Standardisierung sowieeinfache und verlässliche Nutzung, reduzieren Plattform Teams den Aufwand für andere Teams, allen voran für Stream-Aligned Teams. Dabei kann es durchaus sein, dass Plattform Teams ihre Dienste auch gegenseitig nutzen. 

Complicated–Subsystem Teams

Ziel: Complicated-Subsystem Teams entwickeln komplexe Komponenten und Teilsysteme. Damit reduzieren sie den “cognitive load” der Stream-Aligned Teams. 

Wenn einzelne Komponenten einen zu hohen Komplexitätsgrad haben, ist das eine Aufgabe für Complicated-Subsystem Teams. Denn diese Teams entwickeln und betreiben Teilsysteme, für die es sehr spezielles und tiefgreifendes Know-how braucht. Dazu zählen z.B. KI- oder Blockchain Komponenten. Damit müssen auf Wertströme ausgerichtete Teams keine Fähigkeiten in diesen speziellen Bereichen aufbauen. So tragen auch Complicated-Subsystem Teams zu einer systematischen Entlastung der Stream-Aligned Teams bei.

Enabling Teams 

Ziel: Enabling Teams befähigen andere Teams zum Erlernen und der Anwendung neuer Fähigkeiten. 

Enabling Teams sind die Coaches und Trainer deiner Organisation. Denn Enabling Teams befähigen andere Teams, neue spezifische Fähigkeiten mit geringem Aufwand zu erlernen und selbständig einzusetzen. Dazu recherchieren Enabling Teams neue Methoden, Praktiken und Technologien vorausschauend und schulen ihre Kollegen in der Anwendung. Dabei ist der wichtigste Auftrag eines Enabling Teams, sich schnellstmöglich überflüssig zu machen. So ermöglichen Enabling Teams einen schnellen und effizienten Aufbau neuer Kompetenzen, tragen zu einer steilen Lernkurve, Agilität und hohen Innovationskraft deiner Organisation bei. 

Interaktionen zwischen Teams

Interaktionen zwischen Teams kannst Du in drei Klassen einteilen. Diese Muster basieren auf unterschiedlichen Abhängigkeiten, die zwischen Teams auftreten können. 

1. Collaboration: D.h. Team A und B arbeiten gemeinsam und co-kreativ an der Erstellung einer Lösung.
2. X-as-a-Service: D.h. Team A stellt anderen Teams eine Leistung standardisiert zur Verfügung, z.B. über eine API. Das ist ein gängiger Kooperationsmodus z.B. für Platform Teams. 
3. Facilitating: D.h. Team A unterstützt Team B dabei, gewisse Leistungen umzusetzen. Das ist der Default Operating Modus für Enabling Teams.

Mehr zum Thema Abhängigkeiten und ihr Management findest Du in unserem Post zum zweiten Flight Level und im dazugehörigen Arbeitsblatt.

Mit Team Topologies arbeiten – Deine IT- und Software Organisation designen

Theoretisch kann jedes Team mit jedem arbeiten, d.h. Du hättest 48 mögliche Konstellationen (4 Teams x 4 Teams x 3 Interaktionsmuster). Praktisch findest Du jedoch zahlreiche Einschränkungen

1. Enabling, Platform und Complicated–Subsystem Teams sind da, um Stream-Aligned Teams zu unterstützen. 
2. Enabling Teams existieren bedarfsorientiert für einen kurzen Zeitraum, bis die neue Fähigkeit erfolgreich verankert ist. 
3. Manche Team-Konstellationen schließen sich aus, warum sollten z.B. zwei Enabling Teams miteinander arbeiten.
4. Je nach Team-Typ drängt sich ein per default ein dominierendes Interaktionsmuster auf.

Aus diesen Einschränkungen kannst Du folgende vereinfachte Darstellung möglicher Konstellationen ableiten. 

1. Stream Aligned Teams arbeiten gemeinsam mit anderen Stream-Aligned Teams,
2. Platform-Teams streben nach der standardisierten Bereitstellung ihrer Dienste, interagieren also primär im “X-as-a-Service” Modus
3. Complicated- subsystem Teams sind entweder in der Lage, Teilkomponenten so zu standardisieren, dass sie im “X-as-a-Service” Modus genutzt werden können oder sie arbeiten eng mit anderen Teams zusammen.
4. Enabling Teams interagieren im “Facilitating” Modus, um andere Teams bei der Implementierung einer neuen Fähigkeit zu begleiten.

Lass uns nun schauen, wie Du mit diesen Team-Topologien deine Organisation untersuchen oder neu designen kannst. 

Deine Organisation analysieren

Ziel der Team-Topologien ist ein optimaler Arbeitsfluss zwischen Teams für eine dauerhaft hohe Agilität und die kontinuierliche Realisierung von Customer-, User- und Business Value. Solltest Du also den Eindruck haben, dass deine Organisation diesen Anforderungen nicht gerecht wird, kannst Du die Team-Topologien nutzen, um deine bestehende Organisation zu untersuchen. 

1. Im Idealfall  kannst Du jedes Teams einem der vier Archetypen zuordnen. Wenn nicht, ist es deine erste Aufgabe, gemeinsam mit deinen Teams zu überlegen, ob und wie genau eine prototypische Aufstellung der Teams aussehen kann. 
2. In einem zweiten Schritt untersuchst Du die Interaktionsmuster deiner Teams. Das heißt, Du schaust, welche Teams aus welchem Anlass mit anderen Teams interagieren. Schließlich ist dein Ziel nicht, dass jeder mit jedem reden muss, um Arbeit zu erledigen. Sondern zielführende Interaktionsmuster für einen optimalen Arbeitsfluss zu definieren, also das Flight Level 2 zu designen. 

Das heißt, Teamtopologien bieten dir eine Struktur und ein sprachliches Muster, um sinnvoll über den Aufbau deiner Organisation zu sprechen. Dabei geht es nicht um “Schema F” und eine zu technokratische Betrachtung. Schließlich sind Organisationen keine Maschinen, sondern lebendige Systeme. Die Team Topologies versetzen dich nur in die Lage, den Aufbau deiner Organisation sinnvoll zu analysieren und gemeinsam mit deinen Teams auf einen idealen Zustand hinzuarbeiten. 

Das “Reverse Conway” Manöver

Ein zweiter Anwendungsfall für den Einsatz der Team Topologies ist das Reverse Conway Manöver. Dabei leitest Du von der anvisierten System- und Softwarearchitektur deine Organisation ab. Das heißt, Du beginnst mit deiner anvisierten Systemarchitektur und leitest daraus mit den Team Topologien eine ideale Organisation ab. Auch dabei sollte jedes Team einem der vier Archetypen folgen und jede Interaktion sich auf einen dieser Typen zurückführen lassen. Team Topologies geben dir dazu einen Rahmen, um Teams und ihre Interaktionsmuster von Grund auf neu zu denken. 

Teams mit den richtigen Leuten besetzen

Wenn Du erst einmal weißt, mit welchem Teamtopologien Du es zu tun hast, dann kannst Du daraus auch eine gute Aufstellung dieser Teams ableiten. Schließlich resultieren aus den Aufgaben und Interaktionsmustern ganz andere soziale Skills.

1. Enabling Teams brauchen Mitarbeiter, die Freude daran haben, anderen Wissen zu vermitteln und gut darin sind, sie darin zu befähigen.  Sie sehen als Servant Leader ihren wichtigsten Auftrag darin, sich überflüssig zu machen.
2. Als Mitglied in einem Stream-Aligned Teams ist es von großem Vorteil, wenn Du dich empathisch in die Lage deiner Kunden und Anwender versetzen kannst. Dabei hast Du es als Entwickler mit einer völlig anderen “Spezies” zu tun, als wenn Du z.B. ein kompliziertes Teilsystem für andere Entwickler zur Verfügung stellst.
3. In deinen Complicated- subsystem Teams finden sich möglicherweise am besten die “Nerds” zurecht, also jene Mitarbeiter, die ihre große Stärke darin haben, sich in sehr komplexe Fragestellungen einzuarbeiten.
4. Mitarbeiter, die gerne “ihre Ruhe haben“ und sozialen Austausch eher meiden, sind vielleicht am besten in einem Team aufgehoben, das dem Interaktionsmuster “X-as-a-Service” folgt. Schließlich werden hier Leistungen mit einer hohen Standardisierung zur Verfügung gestellt, während Du bei Collaboration oder dem Facilitating ganz andere soziale und interpersonelle Skills benötigst.

Systemarchitekten als Organisationsentwickler

Schließlich resultiert aus den Team Topologies und vor allem aus dem Reverse Conway Manöver eine völlig neue Rolle für den System Architekten. Denn statt nur Architektur zu planen, brauchen Architekten soziale und interpersonelle Skills, um Organisationen nach ihrer gewünschten Architektur auszurichten. Schließlich lehrt uns Conway’s Law bereits seit über 50 Jahren, dass Softwarearchitekturen und Organisationsdesign auf das engste miteinander verbunden sind.

Fazit –  Hilfreiches Referenzmodell auf dem Weg zu mehr Agilität 

Team Topologies liefern dir konkretes Handwerkszeug, um den Aufbau deiner Organisation zu besprechen und zu optimieren. Dabei sind Team Topologies für viele Organisationen sicher ein idealer Zielzustand, auf den Du hinarbeitst, den Du, auf Grund von gewachsenen Strukturen, vielleicht nie oder nicht so schnell erreichst. Auf diesem Weg dorthin helfen dir Team Topologien jedoch als einfaches, gut einsetzbares Referenzmodell, um immer wieder den Sinn und Unsinn von Team-Aufstellungen zu hinterfragen und vor allem sinnvolle Interaktionsmuster auf dem zweiten Flight Level zu designen.

Viel Erfolg dabei.

Zusätzliche Ressourcen

Podcast

#21 Team Topologies mit Robert Ruzitschka

byAndreas Diehl

Unser Host: Andreas Diehl

Robert Ruzitschka ist Community Lead und Agile Engineering Coach bei der österreichischen Raiffeisenbank International mit 45.000 Mitarbeitern. Im Podcast sprechen wir über die IT Transformation der Raiffeisen Bank International und welchen Beitrag Team Topologies für die Entwicklung des Operating und Organisationsmodells hatte.

Weiterführende Links:

• Team Topologies im #DNO Blog
• Mit Robert auf LinkedIn vernetzen
• Robert auf Medium folgen

Episode play icon

#21 Team Topologies mit Robert Ruzitschka

Unser Host: Andreas Diehl Robert Ruzitschka ist Community Lead und Agile Engineering Coach bei der österreichischen Raiffeisenbank International […]

16. Oktober 2023

Andreas Diehl

Buch

Team Topologies: Organizing Business and Technology Teams for Fast Flow

von Matthew Skelton und Manuel Pais

Amazon

Mehr lesen

Tool

Flight Level 2 Arbeitsblatt

Das Flight Level 2 ist die koordinative Ebene des Flight Level Modells von Klaus Leopold. Auf ihr synchronisieren sich alle Teams, die in gegenseitiger Abhängigkeit stehen und an einem Wertstrom arbeiten.

PDF