Drei Wege, wie Teams zusammenarbeiten, ohne Engpässe zu schaffen

Sie haben ein Plattform-Team, das eine großartige CI/CD-Pipeline gebaut hat. Ein stream-aligned Team muss sie nutzen. Aber anstatt einfach ihre Deployments durchzuführen, fragen sie das Plattform-Team ständig. Das Plattform-Team wird in jedes Release hineingezogen. Bald macht niemand mehr seine eigentliche Arbeit.

Das ist der Moment, in dem es nicht reicht, die Teamtypen zu kennen. Sie müssen auch wissen, wie Teams interagieren. Team Topologies beschreibt drei Interaktionsmuster, die Teams helfen, zusammenzuarbeiten, ohne neue Abhängigkeiten zu schaffen oder sich gegenseitig auszubremsen. Jedes Muster passt zu einer anderen Situation, und zu wissen, welches man wann einsetzt – und wann man wechselt – macht den Unterschied zwischen reibungslosem Delivery und ständigem Koordinationsaufwand.

Collaboration: Gemeinsam an unklaren Problemen arbeiten

Collaboration findet statt, wenn zwei Teams für einen begrenzten Zeitraum eng zusammenarbeiten. Sie teilen Kommunikationskanäle, synchronisieren sich häufig und sitzen oft im selben Raum. Dieses Muster ist nützlich, wenn das Problem noch nicht gut verstanden ist und Fachwissen beider Teams erfordert.

Stellen Sie sich ein stream-aligned Team vor, das eine Funktion hinzufügen möchte, die Änderungen in einem Subsystem erfordert, das von einem Complicated-Subsystem-Team verwaltet wird. Keines der Teams kann das allein lösen. Das stream-aligned Team kennt die funktionalen Anforderungen. Das Complicated-Subsystem-Team kennt die interne Architektur. Sie müssen zusammenarbeiten, um das richtige Design zu finden, zusammenhängenden Code zu schreiben und zu überprüfen, dass nichts kaputt geht.

Collaboration ist mächtig, aber sie hat ihren Preis. Sie bindet Aufmerksamkeit beider Teams und schafft temporäre Abhängigkeiten. Deshalb sollte Collaboration nicht ewig dauern. Sobald das Problem gelöst und das Muster klar ist, sollte die Interaktion auf ein leichteres Muster wechseln. Langanhaltende Collaboration macht Teams voneinander abhängig und lenkt sie von ihren eigenen Wertströmen ab.

Die entscheidende Frage: Brauchen wir noch tiefgehende gemeinsame Arbeit, oder können wir jetzt dokumentieren, was wir gelernt haben, und weitermachen?

X-as-a-Service: Fähigkeiten bereitstellen, ohne an die Hand zu nehmen

Beim X-as-a-Service-Muster stellt ein Team eine Fähigkeit bereit, die andere Teams nutzen können, ohne die Implementierungsdetails zu kennen. Das bereitstellende Team besitzt das Interface, die Verfügbarkeit und die Qualität. Das konsumierende Team nutzt es einfach – wie das Aufrufen einer API oder das Ausführen einer vorgefertigten Pipeline.

Das ist die natürliche Interaktion zwischen einem Plattform-Team und stream-aligned Teams. Das Plattform-Team stellt Umgebungen, CI/CD-Pipelines oder Monitoring-Tools als Services bereit. Stream-aligned Teams müssen nicht verstehen, wie die Pipeline gebaut oder gewartet wird. Sie nutzen sie einfach.

Der Erfolg dieses Musters hängt von einer Sache ab: einem stabilen und klaren Interface. Wenn sich der Service häufig ändert oder die Dokumentation unvollständig ist, werden die konsumierenden Teams frustriert. Sie fangen an, eigene Lösungen zu bauen. Das macht den Sinn eines Plattform-Teams zunichte.

X-as-a-Service reduziert den Kommunikationsaufwand und lässt jedes Team in seinem eigenen Tempo arbeiten. Aber es funktioniert nur, wenn das bereitstellende Team das Interface als Produkt behandelt – nicht als nachträglichen Einfall.

Facilitation: Teams lehren, selbstständig zu werden

Facilitation ist das Muster, bei dem ein Team einem anderen hilft, eine bestimmte Fähigkeit zu verbessern, ohne die Arbeit zu übernehmen. Dies ist das Kernmuster für Enabling-Teams.

Ein Enabling-Team kommt nicht, um die Arbeit für ein stream-aligned Team zu erledigen. Sie kommen, um zu lehren, zu coachen und Beispiele oder Leitfäden bereitzustellen. Ein Enabling-Team, das auf Anwendungssicherheit spezialisiert ist, kann beispielsweise einem stream-aligned Team helfen zu verstehen, wie man sicheren Code schreibt, Secrets verwaltet oder Sicherheitsscans in die Pipeline integriert. Sobald das stream-aligned Team es selbstständig kann, zieht sich das Enabling-Team zurück und wechselt zu einem anderen Team, das Hilfe benötigt.

Facilitation unterscheidet sich von Collaboration, weil das Enabling-Team nicht das Produkt baut. Es unterscheidet sich von X-as-a-Service, weil das Enabling-Team keinen dauerhaften Service bereitstellt. Das Ziel von Facilitation ist es, andere Teams unabhängig zu machen.

Die Falle hier ist die endlose Facilitation. Wenn ein Enabling-Team zu lange bei einem Team bleibt, werden sie zu permanenten Babysittern. Das Team lernt nie, ohne sie zu arbeiten.

Alle drei Muster können parallel laufen

Diese drei Muster schließen sich nicht gegenseitig aus. In einer gesunden Organisation laufen alle gleichzeitig. Ein stream-aligned Team könnte die Dienste des Plattform-Teams über X-as-a-Service nutzen, mit einem Complicated-Subsystem-Team an einer kniffligen Funktion zusammenarbeiten und von einem Enabling-Team in Testpraktiken unterstützt werden.

Wichtig ist, sich bewusst zu sein, welches Muster gerade aktiv ist und wann man wechseln sollte. Collaboration, die ohne klaren Grund fortgesetzt wird, schafft neue Abhängigkeiten. X-as-a-Service mit einem instabilen Interface zerstört Vertrauen. Facilitation, die nie endet, verhindert, dass Teams selbstständig werden.

Praktische Checkliste zur Auswahl von Interaktionsmustern

Bevor Sie eine neue Interaktion zwischen Teams einrichten, gehen Sie diese kurze Prüfung durch:

Das folgende Flussdiagramm fasst die wichtigsten Entscheidungspunkte der Checkliste zusammen:

flowchart TD A[Neue Teaminteraktion erforderlich] --> B{Problem gut verstanden?} B -- Nein --> C[Collaboration] C --> D[Enddatum festlegen] B -- Ja --> E{Kann die Faehigkeit ohne Anleitung bereitgestellt werden?} E -- Ja --> F[X-as-a-Service] F --> G[Interface als Produkt behandeln] E -- Nein --> H[Facilitation] H --> I[Ausstieg des Enabling-Teams planen]
  • Ist das Problem unklar und erfordert gemeinsame Erkundung? Nutzen Sie Collaboration, aber setzen Sie ein Enddatum.
  • Hat ein Team eine stabile Fähigkeit, die andere brauchen? Nutzen Sie X-as-a-Service und behandeln Sie das Interface als Produkt.
  • Muss ein Team eine neue Fähigkeit erlernen? Nutzen Sie Facilitation und planen Sie den Ausstieg des Enabling-Teams.
  • Dauert Collaboration länger als erwartet? Fragen Sie, ob das Muster zur Gewohnheit statt zur Notwendigkeit geworden ist.
  • Verursacht das X-as-a-Service-Interface Frustration? Beheben Sie das Interface oder die Dokumentation, bevor Sie weitere Funktionen hinzufügen.
  • Wird das Enabling-Team nach mehreren Monaten noch benötigt? Das Team lernt möglicherweise nicht. Wechseln Sie zu einem anderen Ansatz.

Das Fazit

Interaktionsmuster sind nicht nur Theorie. Sie sind praktische Werkzeuge, um zu entscheiden, wie viel Koordination gesund und wie viel verschwenderisch ist. Collaboration löst schwierige Probleme, sollte aber temporär sein. X-as-a-Service beschleunigt das Delivery, erfordert aber stabile Interfaces. Facilitation baut Fähigkeiten auf, muss aber einen Ausstiegsplan haben.

Die Teams, die gut liefern, sind nicht die, die bei allem zusammenarbeiten. Sie sind die, die wissen, wann sie zusammenarbeiten, wann sie einen Service bereitstellen und wann sie lehren und sich zurückziehen müssen.