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.
# Team Topologies Interaction Modes Canvas
## Kontext
Wofür wird die Methode eingesetzt?
## Kernfrage
Welche Frage soll am Ende beantwortet sein?
## Input
Welche Daten, Beobachtungen oder Materialien liegen vor?
## Arbeitsfläche
- Bereich 1:
- Bereich 2:
- Bereich 3:
- Beziehungen / Muster:
## Ergebnisartefakte
- Interaction-Heat-Map:
- Vereinbarungen pro Paar:
## Offene Fragen
- ...
## Nächster Schritt
Owner, Datum, Erfolgssignal.Konkret gefülltes Szenario
## Team Topologies Interaction Modes - Engineering-Org, 2026-05-18
**Sponsor**: @julia (CTO). **Teilnehmer**: 8 Team-Leads, Architecture Lead.
**Teams**
- Stream-Aligned: Product A, Product B, Product C
- Platform: Identity, Data Platform, Infrastructure
- Enabling: DevEx, Security Coaches
- Complicated-Subsystem: KI-Plattform
**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**
- Product A <-> Identity: jedes neue Feature brauchte Slack-DM-Diskussionen mit Identity-Engineers (Collaboration ohne SLA). Lösung: Auth-API-Doku verbessert, SLA fest, kein Direct-Engineer-Kontakt mehr nötig.
- Product B <-> Data Platform: Erwartung Service-Bereitstellung, aber Plattform noch im Aufbau. Lösung: Übergangs-Plan mit klarem Q4-Stichtag für Service-Mode.
**Übergangs-Vereinbarungen**
- Q3 -> Q4: Product B <-> Data Platform wechselt zu X-as-a-Service. Voraussetzung: Self-Service-Doku, API-Stabilität, SLA-Definition durch Data Platform bis Ende Q3.
**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.