Was vorher fertig sein muss
Teams haben Klarheit über eigene Verantwortungen und Services, idealerweise dokumentiert in Team-API-Form.
Was vor Start vorliegen muss
Whiteboard oder Miro-Board mit Heat-Map-Vorlage (Team-Liste vertikal und horizontal, Zellen für Interaktionsmodi); Definitionen der drei Modi mit Beispielen; Liste aktueller Schnittstellen-Probleme; Stifte mit drei Farben für die Modi.
Ein Facilitator mit Team-Topologies-Erfahrung; Team-Leads aller beteiligten Teams; Architektur-Lead oder Engineering-Director als Sponsor; Scribe für Vereinbarungen.
Team-Liste mit Hauptverantwortungen (Stream-Aligned, Platform, Enabling, Complicated-Subsystem); aktuelle Schnittstellen-Beziehungen; bekannte Reibungen oder Eskalationen; geplante Plattform-Initiativen.
Half day (4 h)
Heat-Map mit Teams in Zeilen und Spalten. Farben pro Modus: Blau=Collaboration (intensiv, temporär), Grün=X-as-a-Service (klar definierter Service, dauerhaft), Gelb=Facilitating (Coaching, Enabling). Definitionen sichtbar.
Die eine Frage, die diese Methode beantwortet
Welcher Interaktionsmodus passt pro Team-Paar, und wie vereinbaren wir die Modi verbindlich, um Schnittstellen-Reibung zu reduzieren?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Modi mit Beispielen einführen | 20 min | Drei Modi erklären. Collaboration: zwei Teams arbeiten temporär eng zusammen (z. B. neues Feature, Architekturwechsel). X-as-a-Service: ein Team konsumiert klar definierten Service eines anderen. Facilitating: Enabling-Team unterstützt Stream-Aligned-Team durch Coaching, dauerhaft begrenzt. | Wenn Modi nicht klar werden, wählen Teilnehmer falsch. Konkrete eigene Beispiele bringen, nicht abstrakte Theorie. |
2Phase 2: Aktuelle Interaktion mappen | 60-90 min | Pro Team-Paar aktuellen Ist-Zustand markieren. Welcher Modus läuft heute. Wenn unklar, kennzeichnen. Reibungspunkte mit roter Notiz markieren. | Ehrlich beschreiben, was läuft, nicht was idealerweise sein sollte. Mismatch zwischen Soll und Ist ist häufiger Reibungsgrund. |
3Phase 3: Soll-Modi diskutieren | 60-90 min | Pro Team-Paar Soll-Modus festlegen. Begründung diskutieren. Bei Wechsel zwischen Ist und Soll Übergangs-Plan andenken (z. B. Collaboration -> X-as-a-Service durch Service-Aufbau). | Mischformen vermeiden. Pro Paar genau ein Modus. Wer sagt „mal Collaboration, mal Service“, hat Modus nicht verstanden. Bewusste Wahl ist Kern. |
4Phase 4: Vereinbarungen und Heat-Map | 30-45 min | Heat-Map mit Soll-Modi fertigstellen. Pro Paar Vereinbarung dokumentieren (was bedeutet der Modus konkret, welche Kommunikationswege, SLA). Übergangs-Plan bei Wechseln. | Heat-Map ohne Vereinbarungen ist Diagramm. Pro Paar konkrete Vereinbarung mit Beispiel-Workflow. Vereinbarung sollte 1-2 Sätze sein, nicht abstrakte Definition. |
Was am Ende rauskommt
Heat-Map mit allen Team-Paaren und Modi (farbig); Tabellen-Liste mit Paaren, Modus, Vereinbarung, Übergangs-Plan, Owner. Verlinkt mit Team-API-Seiten der beteiligten Teams. Engineering-Org-Übersicht sichtbar.
Halbjährlich oder bei Org-Wechsel neu. Modus-Wechsel mit Datum und Begründung. Übergangs-Phasen sichtbar machen (z. B. „Q3: Collaboration, Q4: X-as-a-Service angestrebt“). Vorversion archivieren.
Kompakte Arbeitsvorlage für Team Topologies Interaction Modes mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
Wofür wird die Methode eingesetzt?
Welche Frage soll am Ende beantwortet sein?
Welche Daten, Beobachtungen oder Materialien liegen vor?
Owner, Datum, Erfolgssignal.
Konkret gefülltes Szenario, fiktives Beispiel
Konkret gefülltes Szenario, fiktives Beispiel
Sponsor: @julia (CTO). Teilnehmer: 8 Team-Leads, Architecture Lead.
Teams
Heat-Map-Auszug
| Team-Paar | Aktuell | Soll | Vereinbarung |
|---|---|---|---|
| Product A <-> Identity | Collaboration (chaotisch) | X-as-a-Service | Identity bietet Auth-API mit SLA, Product A konsumiert ohne direkten Kontakt. |
| Product A <-> DevEx | Facilitating | Facilitating | DevEx-Coach unterstützt Product A bei Tooling-Migration, dauerhaft 0,5 FTE für 2 Quartale. |
| Product B <-> Data Platform | Collaboration | Collaboration (Q3) -> X-as-a-Service (Q4) | Bis Q3 enge Zusammenarbeit für Data-Pipeline-Aufbau, ab Q4 Self-Service. |
| Product B <-> KI-Plattform | Collaboration | X-as-a-Service | KI-Plattform bietet inference-API, Product B integriert ohne direkte Modell-Diskussion. |
| Identity <-> Infrastructure | X-as-a-Service | X-as-a-Service | Infrastructure stellt Kubernetes-Cluster mit klarem SLA. |
| Security Coaches <-> alle | Facilitating | Facilitating | Sicherheits-Reviews on-demand, max 2 Tage pro Team pro Quartal. |
Reibungspunkte vorher
Übergangs-Vereinbarungen
Nächste Review: 2026-11-18 (Halbjahr).
Symptome erkennen, gegensteuern
Team-Paar wird mit „Collaboration und X-as-a-Service je nach Thema“ markiert, Modus ist unklar.
Pro Paar genau ein Modus. Bei Wunsch nach Mischung Paar in zwei Sub-Bereiche teilen (z. B. „Feature-Bau: Collaboration, Maintenance: Service“). Klarheit erzwingen.
Heat-Map zeigt Soll-Zustand als Ist, Reibungen werden nicht sichtbar.
Phase 2 ist Ist-Mapping. Ehrlich beschreiben, was läuft. Soll kommt in Phase 3. Mismatch zwischen Ist und Soll ist Ausgangspunkt für Aktionen.
Wechsel von Collaboration zu X-as-a-Service wird beschlossen, aber Voraussetzungen (Service-Aufbau, Doku, SLA) fehlen.
Übergangs-Plan mit Voraussetzungen und Stichtagen. „X wird Service ab Q4“ ohne Vorarbeit ist Wunsch. Vorbereitung muss explizit sein.
Enabling-Team (z. B. DevEx) wird dauerhaft in Produkt-Teams eingebettet, verliert Coaching-Charakter.
Facilitating ist zeitlich begrenzt. Enabling-Engagement mit Start- und End-Datum, max 2 Quartale. Bei Verlängerung explizite Re-Vereinbarung.
Diagramm wird gebaut, hängt im Wiki, niemand setzt Modus-Wechsel um.
Pro Paar mit Modus-Wechsel Owner und Frist. Halbjährliche Review-Cadence. Workshop endet mit konkretem Aktionsplan, nicht mit Diagramm allein.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen oder direkt zur nächsten Methode im Katalog.