---
title: "Multi-Team-Koordination"
description: "Abhängigkeitsmanagement zwischen Cloud-Teams: wie Plattform-Teams, Applikationsteams und die Fachbereiche mehrere Workstreams parallel koordinieren — ohne Engpässe und Eskalationskaskaden."
sidebar:
order: 9
label: "Multi-Team-Koordination"
source_url: "https://framework.stackit.cloud/de/adoption/adapting-operating-models/multi-team-coordination/"
source_file: "docs/de/adoption/adapting-operating-models/multi-team-coordination.mdx"
---
## Die Abstimmungsproblematik bei Cloud-Projekten
Technisch ist eine Cloud-Migration planbar. Organisatorisch eher selten. Sobald mehrere Teams parallel auf der gleichen Plattform arbeiten, entstehen Abhängigkeiten, die zu Beginn niemand vollständig sieht.
Ein gängiges Muster: Das Applikationsteam wartet auf die Landing Zone des Plattform-Teams. Das Plattform-Team wartet auf die IAM-Entscheidung des Security-Teams. Das Security-Team wartet auf die regulatorische Freigabe durch Compliance. Alle warten — und der Go-Live-Termin naht.
Dieses Kapitel beschreibt, wie Abhängigkeiten frühzeitig sichtbar werden und wie Teams trotz Abhängigkeiten parallel arbeiten können.
## Das Topologieproblem: Warum klassische Projektstrukturen scheitern
In klassischen IT-Projekten gibt es einen Projektleiter, der alle Abhängigkeiten kennt und steuert. Bei Cloud-Transformationen wird die Arbeit auf Teams mit unterschiedlichen Kadenzen, unterschiedlichen Prioritäten und unterschiedlichen Anreizstrukturen verteilt.
Ein Plattform-Team arbeitet in zweiwöchigen Sprints. Ein Compliance-Team arbeitet im Quartalsrhythmus. Ein Applikationsteam arbeitet nach einer Produkt-Roadmap. Diese drei Rhythmen erzeugen systematisch Fehlausrichtungen.
**Die Lösung ist nicht eine stärkere zentrale Steuerung, sondern eine bessere Sichtbarkeit und klarere Schnittstellen.**
## Vier Koordinationsmechanismen
### 1. Teamtopologie und Interaktionsmodi definieren
Bevor Teams zusammenarbeiten, sollte klar sein: In welcher Beziehung stehen sie zueinander?
**Plattform-Team → Applikationsteams:** Das Plattform-Team stellt Services (Kubernetes-Cluster, Networking, IAM-Templates) bereit. Applikationsteams konsumieren diese Dienste. Die Interaktion sollte möglichst über Self-Service-Schnittstellen (Servicekatalog, Terraform-Module, Dokumentation) erfolgen — nicht über Tickets.
**CCoE → alle Teams:** Der CCoE setzt Standards, prüft Architekturentscheidungen und unterstützt bei Eskalationen. Er ist kein Freigabegremium, sondern ein Enabler mit Vetorecht bei kritischen Sicherheits- und Compliance-Fragen.
**Applikationsteams untereinander:** Shared-Service-Abhängigkeiten (z. B. eine zentrale Datenbank, die von mehreren Teams genutzt wird) sind der häufigste Abstimmungsengpass. Diese sind explizit als „Plattform-Service“ zu behandeln und vom zuständigen Team als internes Produkt mit SLA zu betreiben.
### 2. Dependency Board
Ein einfaches, aber effektives Instrument: eine Tafel (physisch oder digital), die alle teamübergreifenden Abhängigkeiten visualisiert.
| Abhängigkeit | Lieferndes Team | Empfangendes Team | Geplant für | Status |
| ------------------------------- | --------------- | ------------------ | ----------- | ----------- |
| Landing Zone Prod | Plattform | App-Team Billing | Woche 14 | in Arbeit |
| IAM-Rollenkonzept | Security | Plattform | Woche 12 | blockiert |
| Datenschutzrechtliche Freigabe | Compliance | App-Team CRM | Woche 16 | offen |
| CI/CD-Pipeline-Template | Plattform | App-Team Logistik | Woche 13 | fertig |
Das Dependency Board wird wöchentlich aktualisiert. Blockaden werden sofort sichtbar — bevor sie zum Engpass werden.
### 3. Regelmäßige Sync-Formate
15 Minuten täglich. Was wurde gestern gemacht? Was ist heute geplant? Was blockiert? Blockaden
mit teamübergreifenden Abhängigkeiten werden sofort eskaliert — nicht als Ticket, sondern als
direkte Ansprache.
45 Minuten. Das Plattform-Team stellt vor: Was ist neu verfügbar? Was kommt in den nächsten zwei
Wochen? Welche Änderungen haben Breaking-Change-Potenzial? Alle Applikationsteams sind
vertreten.
30 Minuten. Review des Dependency Boards. Welche Abhängigkeiten sind offen, welche eskalieren?
Entscheidungen über Verschiebungen werden hier getroffen, nicht per E-Mail.
Management, CIO, Tech Leads. Stand der Gesamtmigration, strategische Kursanpassungen,
Ressourcenentscheidungen. Keine Detailgespräche — nur Entscheidungen.
### 4. Inner-Source-Prinzip für Plattformkomponenten
Wenn alle Teams die gleiche STACKIT-Infrastruktur nutzen, entsteht ein gemeinsamer Code-Base-Effekt: Terraform-Module, Helm-Charts und CI/CD-Templates werden doppelt entwickelt.
Inner Source bedeutet: Plattformkomponenten werden intern wie Open-Source-Projekte geteilt. Jedes Team kann seinen Beitrag leisten. Das Plattform-Team pflegt und prüft. Ergebnis: keine Duplikate, schnellere Iteration, gemeinsames Qualitätsbewusstsein.
In der Praxis: ein internes Git-Repository mit Terraform-Modulen für STACKIT-Ressourcen, versioniert und dokumentiert. Applikationsteams nutzen, verbessern und teilen zurück.
## Wenn Abstimmung eskaliert
Manchmal reichen Prozesse nicht aus. Dann braucht es klare Eskalationswege.
**Eskalations-Trigger:** Eine teamübergreifende Abhängigkeit ist seit zwei Wochen blockiert und hat einen Go-Live-Termin gefährdet.
**Eskalationspfad:**
1. Direktes Gespräch zwischen den betroffenen Teamleitungen: 24-Stunden-Frist zur Lösung
2. Bei keinem Ergebnis: Einbindung des CCoE als neutraler Mediator
3. Bei keinem Ergebnis: Der Lenkungsausschuss trifft die Entscheidung — mit allen Konsequenzen
**Was auf keinen Fall passieren sollte:** Das Lösen von Blockaden durch E-Mail-Pingpong ohne definierten Eskalationspunkt. Zeitdruck löst strukturelle Abhängigkeitsprobleme nicht.
## Umsetzungsschritte
1. **Teamtopologie dokumentieren** — Wer arbeitet mit wem zusammen? In welchem Modus (Collaboration, X-as-a-Service, Facilitating)? Schriftlich, als Basis für alle weiteren Abstimmungsformate.
2. **Dependency Board aufsetzen** — Einfach starten: Eine Tabelle in Confluence oder Jira reicht. Wichtig: ein wöchentlicher Prüftermin im Kalender.
3. **Sync-Formate etablieren** — Platform Sync und Dependency Review als wiederkehrende Termine anlegen. Agenda-Vorlagen erstellen.
4. **Den Eskalationspfad kommunizieren** — Alle Teams wissen, an wen und wann eskaliert werden muss. Nicht als Bedrohung, sondern als Sicherheitsnetz.
5. **Ein Inner-Source-Repository erstellen** — Beginnen Sie mit dem Terraform-Modul, das die meisten Teams benötigen. Dokumentieren Sie, wie Beiträge geleistet werden.