Was sind Team Topologies?

Team Topologies (Matthew Skelton, Manuel Pais) ist ein praxisnahes Organisationsmodell, um Teams für schnellen Wertfluss zu strukturieren. Kernelemente sind vier Teamtypen (Stream-aligned, Enabling, Complicated-Subsystem, Platform) und drei Interaktionsmodi (Collaboration, X-as-a-Service, Facilitating). Leitend ist die Begrenzung kognitiver Last je Team sowie die bewusste Gestaltung von Team-Schnittstellen im Sinne von Conway’s Law. 

So setzt man Team Topologies wirksam um:

• Startpunkt: Ist-Kartierung & Hypothesen – vorhandene Teams/Abhängigkeiten sichtbar machen; früh prüfen, welcher der 4 Teamtypen am besten passt (kein Dogma).

• Team-API definieren – explizite „Schnittstelle“ eines Teams (Scope, Ownership, Artefakte, Kommunikationswege, SLOs). Dient als Erwartungsklärung und macht Interaktionen gestaltbar.

• Schnitt & Grenzen über „Fracture Planes“ – natürliche Trennstellen (Domänen, User-Journeys, Compliance, Änderungsfrequenz) nutzen; Ziel sind autonome Stream-aligned Teams.

• Platform als Produkt – TVP – Platform-Teams liefern die „Thinnest Viable Platform“ (kleinst sinnvolles Set an APIs/Docs/Tools) und etablieren Golden Paths für Self-Service, um kognitive Last der Stream-aligned Teams zu senken.

• Gezielte Interaktionsmodi – Collaboration (zeitlich begrenzt für Entdeckung), Facilitating (Enabling hilft), X-as-a-Service (reifer, stabiler Service). Modus bewusst wählen und regelmäßig neu bewerten.

• „Neue Org-Chart-Schablone“ – Team Topologies liefert kein statisches Organigramm; es ist ein adaptives Denkmodell zur Beseitigung von Flow-Hindernissen.

• „Plattform = Ticketfabrik“ – Plattformen werden als Produkt geführt (Nutzerfokus, Metriken, Roadmap), kein internes Outsourcing-Backlog. TVP ist explizit klein gehalten.

• „Interaktionsmodi egal“ – falsch. Falscher Modus (z. B. ewige Kollaboration statt Service) erhöht Reibung.

• „Kognitive Last ignorierbar“ – Kernprinzip ist, Last aktiv zu managen, sonst kollabiert der Flow.

Richtig angewandt reduziert Team Topologies Abhängigkeiten, begrenzt kognitive Überlast, beschleunigt Feedback und synchronisiert Struktur mit Architektur (Inverse-Conway-Maneuver). Ergebnis: schnellerer, vorhersagbarer Wertfluss bei besserer Entwickler-Erfahrung. 

Ein Digitalbereich mit starkem Monolithen organisierte Teams funktional (Frontend/Backend/QA) → viele Handoffs, lange Lead Times. Nach einem Fracture-Planes-Workshop wurden Stream-aligned Teams entlang von Domänen geschnitten; ein Platform-Team lieferte einen TVP mit automatisierten Golden Paths (Build/Deploy/Observability). Team-APIs machten Ownership & Schnittstellen klar. Ergebnis: signifikant kürzere Durchlaufzeiten und weniger Eskalationen. (Vgl. publizierte Fallstudien, u. a. Trade Me; Wealth Wizards.) 

Team Topologies ist frameworkunabhängig. In SAFe-Umgebungen hilft es beim Zuschneiden von Teams/ARTs (wertstromorientiert, autonome Lieferfähigkeit) und beim Aufbau wirksamer Plattform-Capabilities. Außerhalb von SAFe wirkt es als „Team-Betriebssystem“ für Produkt-/Tech-Organisationen. 

So arbeiten gute Coaches damit

• Mappen → Messen → Ändern: Ist-Topologie, Abhängigkeiten, Flow-Metriken; Hypothesen für neuen Schnitt testen.

• Team-APIs einführen: Transparenz über Scope, Artefakte, Support-Fenster, Interaktionsmodi.

• Kognitive Last steuern: Reduktion von „Everything-Teams“, klare Domänenschnitte, Plattform entlastet.

• Interaktionsmodi bewusst wählen: Discovery → Collaboration, Enablement → Facilitating, Reife → X-as-a-Service.

• Platform als Produkt: TVP aufbauen, Golden Paths etablieren, Nutzungs-Metriken tracken (z. B. Time-to-First-Deploy).

Wir setzen Team-Topologies-Prinzipien regelmäßig in Programmen und Produktorgs ein – von Team-Schnitt & Fracture-Planes über Team-APIs bis hin zu Platform-as-a-Product/TVP. Unsere Coaches sind in diesen Mustern ausgebildet und kombinieren sie pragmatisch mit SAFe, Kanban und Value-Stream-Management – Ziel: schneller, stabiler Flow, keine Dogmen.

Wie sich ein überdimensionierter ART partizipativ in zwei Release Trains mit klaren Verantwortlichkeiten je Domäne und Team aufteilen lässt, zeigt unsere Fallstudie zur Aufteilung eines ART.

• Vier Teamtypen & Interaktionsmodi (Überblick, Definitionen).

• Cognitive Load (Grundlage des Designs).

• Team API (Schnittstellen explizit machen).

• Thinnest Viable Platform / Golden Paths (Plattform minimal & wirksam halten).

• Organizing Agile Teams & ARTs at Scale (Team Topologies in SAFe).

• Cross-funktionale Teams

• Agile Release Train (ART)

• Enterprise Agility

Quelle: Team Topologies – Key Concepts, Skelton & Pais