Multi-Team-Koordination

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.

Seitlich wischen, um die ganze Tabelle zu sehen

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

Daily Standup (teamintern)

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.

Platform Sync (wöchentlich)

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.

Dependency Review (zweiwöchentlich)

30 Minuten. Review des Dependency Boards. Welche Abhängigkeiten sind offen, welche eskalieren? Entscheidungen über Verschiebungen werden hier getroffen, nicht per E-Mail.

Lenkungsausschuss (monatlich)

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.