Was sind Team Topologies?

Team Topologies unterstützen Dich und Deine Organisation dabei, sowohl den Workflow mehrerer Teams zu optimieren als auch die bestmögliche Software-Architektur durch Teamstrukturen aktiv zu fördern. Dabei geht es nicht darum, eine „für immer gültige“ Teamstruktur zu entwickeln, sondern anhand klarer Prinzipien die aktuell passendste Teamstruktur zu entwickeln.

Der Begriff Topologie hat seinen Ursprung im griechischen Wort Topos, was soviel wie Ort, Stelle oder Lage bedeutet. Eine Topologie ist also die „Lehre von der Lage und Anordnung geometrischer Gebilde im Raum und damit ein Teilgebiet der Mathematik.“ (vgl. Wikipedia)

Analog dazu beschreibt eine Team Topologie das Verhältnis mehrerer Teams zueinander, die Strukturen, die sie bilden, und die Interaktionsformen, die sie verwenden, um miteinander zu kommunizieren.

Die meisten Organisationen und Unternehmen schaffen es trotz diverser Versuche und Anläufe nicht, sich organisatorisch so aufzustellen, dass sie Kundenbedarfe optimal erfüllen können. Sie bilden zwar agil arbeitende Teams, aber verstricken sich nichtsdestotrotz in einem dichten Netz von Abhängigkeiten zwischen diesen Teams, die sie nicht auflösen können. Manche von ihnen greifen dann (in Ermangelung einer besseren Alternative) auf das Spotify-Modell, SAFe, LeSS oder sogar das Unfix-Modell von Jurgen Appelo zurück.

Genau diese Prinzipien für Teamstrukturen liefern Matthew Skelton und Manuel Pais mit Team Topologies und bieten Dir damit den aktuell besten Weg für die agile Skalierung..

Bevor ich auf die 4 Teamtypen und 3 Interaktionsarten der Team Topologien eingehe, möchte ich Dir die drei wichtigsten Grundkonzepte erläutern, auf denen der Ansatz von Manuel Pais und Matthew Skelton basiert. Diese Grundkonzepte sind der Team First Approach, die Cognitive Load Theory und Conway’s Law.

Der erste wichtige Grundstein, auf dem Team Topologies basiert, ist der sogenannte Team First Approach. Bis hierher steckt noch keine sonderlich revolutionäre Erkenntnis im Ansatz von Skelton und Pais.

Denn „Team first“ besagt zunächst lediglich, dass komplexe Herausforderungen durch agile Teams besser gelöst werden können als durch eine „Gruppe von Individuen“, von denen jedes seine eigene Aufgabe erledigt.

Hierzu gehören also all jene Aspekte, die hinlänglich bekannt sind: kollaboratatives Arbeiten in interdisziplinären Teams, die schon lange zusammenarbeiten bzw. stabil genug sind, um sich blind verstehen zu können, und die eine optimale Teamgröße nicht unter- oder überschreiten.

Das zweite Element von Team Topologies ist die Cognitive Load Theory. Demnach haben Menschen vereinfacht gesprochen eine begrenzte Kapazität, wenn es darum geht, Informationen zu verarbeiten. Das Gleiche gilt sinngemäß auch für Teams. Selbst herausragende Spitzenteams können nicht alles wissen und können. Und je größer ihr Verantwortungsbereich ist, desto weniger leistungsfähig werden sie arbeiten, weil sie schlichtweg kognitiv überlastet sind.

Der gesamte Team-Topologies-Ansatz basiert also darauf, (langfristig) klar definierte Verantwortungsbereiche für jedes Team zu etablieren. Darüber hinaus entsteht dadurch der positive Nebeneffekt, dass diese klare Begrenzung auch Ownership innerhalb eines Teams für die jeweiligen Domänen entsteht.

Der dritte Baustein in Team Topologies ist das bereits 1968 (!) formulierte Conway’s Law. Dieses auf Melvin Edward Conway zurückgehende „Gesetz“ besagt, dass Organisationen gezwungen sind, in ihren Systemen (Produkten) ihre internen Kommunikations­strukturen abzubilden.

Wenn Du beispielsweise mit vier Teams ein Software-Produkt entwickelst und diese gemeinsam mit einem einzigen Datenbank-Entwickler zusammenarbeiten, dann sind Deine Chancen (sehr) hoch, dass die Software-Architektur Deines Produktes aus vier Modulen besteht, die alle mit einer einzigen großen Datenbank interagieren.

Solange diese Software-Architektur sinnvoll ist, liegt darin natürlich kein Problem.

Problematisch wird es erst, wenn Du eigentlich eine andere Software-Architektur benötigst, beispielsweise um Abhängigkeiten zwischen Deinen Teams zu reduzieren oder um Dein Produkt möglichst flexibel weiterzuentwickeln und einsetzen zu können.

In der Praxis sind dann die Kommunikationsstrukturen zwischen den beteiligten Teams stärker als die auf dem Papier festgehaltene Softwarearchitektur, sodass alle gegen die (ungewollt) entstehende Software-Architektur „anarbeiten“ müssen.

Matthew Skelton und Manuel Pais machen sich die Implikationen aus Conway’s Law mit einem Ansatz zu Nutze, den sie Inverse Conway Maneuver (manchmal auch Reverse Conway Maneuver) nennen.

Hinter diesem Ansatz steckt der Gedanke, sich zunächst zu überlegen, wie die (optimale) Architektur des Software-Produktes gestaltet sein soll, um davon ausgehend die Struktur bzw. den Aufbau der an diesem Produkt arbeitenden Teams zu entwerfen.

Pais und Skelton sprechen deshalb auch von einem sozio-technologischen Ansatz: Team Topologies steuert mit Hilfe der passenden Teamstrukturen die daraus entstehende Software-Architektur.

Matthew Skelton und Manuel Pais definieren in Team Topologies vier unterschiedliche Teamtypen, mit deren Hilfe Du Deine gesamte (Software-)Produktentwicklung abbilden kannst. Diese Teamtypen sind Stream-aligned Teams, Enabling Teams, Complicated-Subsystem Teams und Platform Teams.

Der erste Teamtyp in Team Topologies ist das Stream-aligned Team. Sinngemäß kommt dieser Teamtyp der Idee eines Scrum Teams sehr nahe.

Denn Stream-aligned Teams sind auf die Arbeit an einem klar definierten Wertstrom ausgerichtet.

Dieser Wertstrom kann zu einem einzelnen Produkt gehören, zu einem bestimmten Set an Features, zu einer speziellen Customer Journey oder auch zu einer einzelnen Persona. Deshalb können Stream-aligned Teams auch sowohl Komponenten- als auch Feature-Teams sein.

Viel wichtiger ist vielmehr, dass ihnen eine klar definierte Domäne (also ein Produkt, ein Feature-Set, eine Customer Journey oder eine Persona) zugeordnet ist. Denn diese Domäne sorgt dafür, dass der eingangs erwähnte Cognitive Load dieses Teams nicht überschritten wird. Außerdem sind Stream-aligned Teams so aufgebaut, dass keine Übergaben an andere Teams notwendig sind, wodurch potenziell Abhängigkeiten und somit Wartezeiten entstehen. Stream-aligned Teams können also so autonom wie möglich agieren.

Gleichzeitig sollte eine agile Organisation darauf achten, dass Stream-aligned Teams der am häufigsten vorkommende Teamtyp ist. (Das Verhältnis sollte laut Skelton und Pais dabei am besten zwischen 6:1 und 9:1 liegen.)

Weil Stream-aligned Teams unter konstantem Druck stehen, Arbeit fertig zu stellen, bleibt in der Praxis für viele wichtige Dinge oft zu wenig Zeit.

Das Experimentieren mit neuen Technologien und Methoden, das Ausprobieren neuer Praktiken und dergleichen obliegt in Team Topologies deshalb (in erster Linie) den sogenannten Enabling Teams.

Diese liegen quer zu den Wertströmen der Stream-aligned Teams und arbeiten meistens coachend bzw. befähigend mit diesen zusammen.

Enabling Teams helfen anderen Teams dabei, neue Technologien und Vorgehensweisen in die Praxis umzusetzen und sind deshalb Coaches oder Mentoren für Stream-aligned Teams.

Es ist also nicht ihre Aufgabe, die Probleme anstelle der Wertstrom-Teams zu lösen, sondern eben jene dazu zu befähigen, es selbst zu können.

Auch wenn ihr Name etwas gewöhnungsbedürftig ist, erfüllen Complicated-Subsystem Teams in Team Topologies einen wichtigen Zweck. Denn sie tragen dazu bei, den oben erwähnten Cognitive Load für die Stream-aligned Teams zu reduzieren. Das wird zum Beispiel dadurch erreicht, indem komplexe Komponenten oder umfangreiche Features des Produktes aus der Verantwortung der Wertstrom-Teams herausgenommen werden, um diesen die Arbeit am Wertstrom zu erleichtern. Auf diese Weise können sie sich stärker darauf fokussieren, Kundenbedarfe zu erfüllen, statt sich mit komplexen Themen aufhalten zu müssen.

Die Bildung von Complicated-Subsystems erfolgt dann und nur dann, wenn bestimmte Features oder Komponenten eines Produktes Spezialwissen notwendig machen, das unmöglich oder nur sehr schwer in Stream-aligned Teams aufgebaut werden kann. (Gesichtserkennung, komplexe Handelsalgorithmen oder Künstliche Intelligenz sind gute Beispiele für solche komplexen Themenbereiche, die besonderes Expertenwissen benötigen.)

Daraus folgt auch, dass in einer Organisation nur sehr wenige Complicated-Subsystem Teams existieren.

Der vierte und letzte Teamtyp der Team Topologien ist das Platform Team.

Platform Teams befähigen Stream-aligned Teams so autonom wie möglich arbeiten zu können, indem sie diesen Dienste und Produkte (als Plattform) zur Verfügung stellen. Das können beispielsweise Pipelines sein, Monitoring-Systeme oder auch Arbeitstools wie Azure DevOps bzw. Jira.

All diese Dienste werden von den Stream-aligned Teams zwar für ihre tägliche Arbeit genutzt, müssen jedoch nicht selbst verwaltet, gepflegt oder weiterentwickelt werden.

Neben den vier Teamtypen definieren Manuel Pais und Matthew Skelton in Team Topologies drei verschiedene Interaktionsformen oder -arten, mit deren Hilfe Du darstellen kannst, wie diese miteinander kommunizieren und interagieren wollen bzw. sollen:

Kollaboration als Interaktionsform ist immer dann sinnvoll, wenn das zu lösende Problem bzw. die zu erledigende Aufgabe sehr komplex ist. Beispielsweise dann, wenn es darum geht, eine neue Technologie oder Methode in die Praxis zu überführen. Der Vorteil von Kollaboration liegt also vor allem in der schnellen Anpassbarkeit des aktuellen Vorgehens und der Reduzierung notwendiger Übergaben.

Kollaboration bringt jedoch auch Nachteile mit sich: Die Verantwortlichkeiten für Aufgaben sind meist auf alle Teammitglieder verteilt, sodass es zu Unklarheiten kommen kann.

Außerdem findet Kommunikation meistens häufig und intensiv statt, sodass sie sich auch nachteilig auf den Cognitive Load eines Teams auswirken kann. Letztlich schlägt sich das auch auf die Performance eines Teams durch, weil „mehr geredet als gearbeitet“ wird.

Skelton und Pais empfehlen deshalb, Kollaboration wohl überlegt und nur in den Fällen einzusetzen, in denen sie wirklich sinnvoll ist.

Der Interaktionsmodus X-as-a-Service bietet sich immer dann an, wenn ein oder mehrere Teams auf Dinge zurückgreifen müssen oder wollen, die „einfach funktionieren“. Das kann eine bestimmte Komponente, eine API, eine Plattform, ein Dienst oder auch nur eine Code Library sein. Diese Kommunikationsform setzt natürlich voraus, dass die Umgebungen, Systeme und Voraussetzungen bestmöglich bekannt sind und wenig Überraschungen zu erwarten sind.

Der Vorteil der Interaktionsform X-as-a-Service ist natürlich, dass dadurch eine klare Ownership für das jeweilige Team existiert, das den Service bereitstellt. Gleichzeitig reduziert X-as-a-Service besonders für Stream-aligned Teams den Cognitive Load, weil sie den Service einfach verwenden können und sich nicht mit Details beschäftigen müssen.

Der Nachteil ist allerdings, dass sich durch diese Interaktionsform die API oder Services oft langsamer weiterentwickeln. (Denn diese sind ja darauf ausgelegt, dass sich möglichst wenig ändert und der etablierte Standard beibehalten wird.)

Immer dann, wenn Teams auf die Hilfe anderer Teams angewiesen sind, bietet sich die Interaktionsform Facilitation an. Logischerweise ist Facilitation die typische Interaktionsart der weiter oben beschrieben Enabling Teams.

Die Vorteile liegen darin, dass Probleme und Hindernisse (speziell für Stream-aligned Teams) aufgelöst werden können und die Enabling Teams gleichzeitig Unterschiede zwischen den Teams erkennen können.

Weil diese quer zu den Stream-aligned Teams liegen und dadurch einen besseren Überblick haben.

Die größte Gefahr hingegen besteht jedoch auch darin, dass Facilitation missverstanden wird. Etwa dann, wenn Enabling Teams die „Probleme für andere Teams selbst lösen“ statt diese wirklich zu befähigen, diese Probleme eigenständig auflösen zu können.

Wie Du vielleicht schon bemerkt hast, gibt es in Team Topologies für jede der vier Teamarten typische Interaktionsformen, die besonders passend für sie sind. Andere Interaktionsarten hingegen ergeben für manche Teamtypen überhaupt keinen Sinn. Die nachfolgende Tabelle bietet Dir hierzu einen praktischen Überblick.

Zum Abschluss möchte ich Dir noch ein praktisches Beispiel geben, wie Du mit Hilfe der Team Topologien den Aufbau Deiner Produktentwicklung darstellen kannst.

Auf der Grafik rechts siehst Du drei Scrum Teams, die gemeinsam an einem Produkt arbeiten.

Zusammengehalten werden sie durch das Nexus Integration Team, das die Scrum Teams (als Enabling Team) dabei unterstützt, zum Ende eines Sprints ein nutzbares Inkrement auszuliefern.

Das Besondere an diesem Aufbau ist allerdings, dass sich im Produkt eine sehr komplexe Komponente befindet. Diese wird von einem Complicated-Subsystem Team verwaltet, das kein Teil des gebildeten Nexus ist.

Dieser Umstand fällt jedoch nicht weiter ins Gewicht, weil die Funktionsweise und Grenzen der Komponente klar geregelt und definiert sind. Zwei der Stream-aligned Teams können deshalb den Interaktionsmodus X-as-a-Service nutzen.

In ihrer täglichen Arbeit nutzen die Scrum Teams des Nexus außerdem diverse Softwaretools, die ihnen über ein Plattform Team bereitgestellt werden.

Wenn Du Dich intensiver mit Team Topologies beschäftigen möchtest, habe ich hier noch einige Quellen für Dich zusammengetragen.

Team Topologies ist ein extrem hilfreicher Ansatz, um die agile Transformation Deiner Organisation voranzutreiben.

Zum einen hilft Dir das Modell dabei, die Zusammenhänge zwischen Software-Architektur und Teamstruktur besser zu verstehen. Außerdem gibt es Dir klare Hilfestellungen, nach welchen Prinzipien Du Deine Teams aufstellen solltest, um die gewünschte Architektur bestmöglich zu fördern. Das ist deutlich hilfreicher, als berühmt-berüchtigte Modelle (Stichwort Spotify-Modell) einfach zu kopieren.

Zum anderen kannst Du mit den Team Topologies sowohl den aktuellen Stand Deiner Teamstrukturen als auch das gewünschte Zielbild visualisieren. Das unterstützt Dich dabei, die nächsten Schritte abzuleiten, um zum Zielbild zu gelangen.