4.8 12 Votes
Artikel-Rating

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.

Was ist überhaupt eine „Topologie“?

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.

Welches Problem lösen Team Topologies?

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.

Nur um dann festzustellen, dass ihnen das auch nicht weiterhilft.
0
Welche Erfahrungen hast Du mit den genannten Framworks und Methoden gesammelt?x
Was fehlt, ist ein Denkansatz mit klaren Prinzipien, der sie dabei unterstützt, eine (aktuell) passende Teamstruktur zu etablieren.

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..

Grundkonzepte in Team Topologies

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.

Team First Approach

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.

Agile Teams

Cognitive Load Theory

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.

Conway’s Law

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.

Melvin Edward Conway

„Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.“

Melvin Edward Conway, melconway.com

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.

Das Inverse Conway Maneuver

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.

Die 4 Teamarten in Team Topologies

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.

Stream-aligned 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.)

Enabling Teams

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.

Complicated Subsystem Teams

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.

Platform Teams

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.

Die 3 Interaktionsarten in Team Topologies

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

  • X-as-a-Service

  • Facilitation

Kollaboration

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.

X-as-a-Service

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.)

Facilitation

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.

Typische Interaktionsformen der Teamtypen

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.

Kollaboration X-as-a-Service Facilitation
Stream-aligned Team Typisch Typisch Gelegentlich
Enabling Team Gelegentlich Typisch
Complicated-Subsystem Team Gelegentlich Typisch
Platform Team Gelegentlich Typisch

Anwendungsbeispiel für Team Topologies: Nexus Scrum

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.

Mehr über Team Topologies

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

Fazit zu Team Topologies

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.