Koordination im großen Maßstab

Die Koordination über ARTs hinweg ist der Punkt, an dem Large Solution SAFe seinen Wert beweist – oder scheitert. Mehrere Muster helfen dabei:

1. Communities of Practice (CoPs) — ART-übergreifende Gruppen, die nach Fähigkeiten oder Domänen organisiert sind (z. B. Frontend-CoP, Security-CoP, Data-Engineering-CoP). CoPs teilen Wissen, stimmen Standards ab und reduzieren Doppelarbeit. Sie treffen sich regelmäßig, besitzen aber keine Lieferverantwortung – das tun die Teams.

2. Shared Services — Kleine Teams, die Fähigkeiten bereitstellen, die von allen ARTs genutzt werden. Beispiele: Plattform-Team, DevOps/SRE-Team, Datenplattform-Team. Diese Teams arbeiten in ihrem eigenen Rhythmus, richten sich aber am PI-Rhythmus des Solution Train aus.

3. System-Teams — Dedizierte Teams, die Integration, Build-Infrastruktur und systemweite Tests verantworten. Sie stellen sicher, dass die CI/CD-Pipeline auf Lösungsebene funktioniert, und pflegen Integrationsumgebungen.

4. Release-Management — Koordination, wann und wie die Lösung veröffentlicht wird. Bei großen Lösungen kann das Release in einem anderen Rhythmus erfolgen als der PI-Rhythmus. Ein Release kann Arbeit aus mehreren PIs umfassen, oder die Arbeit eines PI wird inkrementell veröffentlicht.

5. Architektur-Councils — Solution Architects aus allen ARTs treffen sich regelmäßig, um die architektonische Ausrichtung abzustimmen, ART-übergreifende technische Entscheidungen zu treffen und die Architektur-Runway auf Lösungsebene zu pflegen.

Der gemeinsame Nenner: Diese Muster schaffen leichtgewichtige, dauerhafte Koordinationsstrukturen, die kontinuierlich arbeiten, nicht nur während Planungsevents. PI Planning ist essenziell, aber nicht ausreichend – Koordination muss auch zwischen Planungsevents stattfinden.

Viele große Lösungen beinhalten externe Lieferanten – Hardware-Anbieter, Drittanbieter-Software-Provider, ausgelagerte Entwicklungsteams. Die Koordination mit Lieferanten erhöht die Komplexität, weil man weniger Kontrolle hat.

Strategien für die Lieferantenkoordination:

1. Rhythmus abstimmen: Wenn möglich, den Lieferrhythmus des Lieferanten mit dem eigenen PI-Rhythmus abstimmen. Selbst wenn der Lieferant nicht SAFe nutzt, schaffen regelmäßige Lieferpunkte Integrationsmöglichkeiten.

2. Verträge als Schnittstellen definieren: Anstatt vorzuschreiben, wie der Lieferant arbeiten soll, klare Schnittstellenverträge definieren (APIs, Protokolle, Datenformate). Gegen den Vertrag testen, nicht gegen die Implementierung.

3. Lieferantenvertreter in PI Planning einbeziehen: Wichtige Lieferantenkontakte zu Pre-PI und Post-PI Planning einladen. Sie müssen nicht am vollständigen ART PI Planning teilnehmen, benötigen aber Einblick in Pläne und Abhängigkeiten.

4. Integrations-Stubs erstellen: Mock-Versionen von Lieferantenkomponenten bauen, damit die eigenen Teams entwickeln und testen können, ohne auf das echte System zu warten. Das entkoppelt das eigene Entwicklungstempo vom Lieferanten.

5. Regelmäßige Integrations-Checkpoints: Regelmäßige Integrationssitzungen (wöchentlich oder zweiwöchentlich) planen, bei denen das eigene System mit tatsächlichen Lieferantenlieferungen integriert wird. Nicht bis zum Ende des PI warten.

Lieferantenkoordination ist oft der frustrierendste Teil von Large Solution SAFe, weil man nicht vorschreiben kann, wie externe Organisationen arbeiten. Fokus auf das Kontrollierbare: Schnittstellendefinitionen, Integrationstests und klare Kommunikation der Erwartungen.

ART-Grenzen sind nicht dauerhaft. Während sich Produkt und Organisation weiterentwickeln, kann eine Reorganisation nötig werden:

Anzeichen, dass ein ART aufgeteilt werden sollte:

• Mehr als 12 Teams – das ART ist zu groß für effektives PI Planning
• Zwei unterschiedliche Value Streams existieren innerhalb eines ART
• Die meisten Abhängigkeiten liegen innerhalb von Untergruppen, nicht über das gesamte ART hinweg
• Die System Demo ist zu lang und unfokussiert geworden

Anzeichen, dass ARTs zusammengeführt werden sollten:

• Zwei ARTs haben umfangreiche Abhängigkeiten, die ständigen Koordinationsaufwand erzeugen
• Ein Value Stream wurde künstlich über ARTs hinweg aufgeteilt
• Ein ART ist zu klein (weniger als 3 Teams), um den Overhead zu rechtfertigen
• Teams werden häufig zwischen ARTs „ausgeliehen"

Anzeichen, dass die ART-Grenzen falsch sind:

• ART-übergreifende Abhängigkeiten übersteigen die Abhängigkeiten innerhalb eines ART
• ARTs stimmen nicht mit der Architektur überein (Verstoß gegen Conway's Law)
• PI Planning erzeugt mehr Inter-ART-Abhängigkeitsketten als Intra-ART-Abhängigkeiten

Die Reorganisation von ARTs ist disruptiv, also nicht leichtfertig durchführen. Aber auch nicht vermeiden – mit falschen Grenzen zu leben erzeugt eine laufende Koordinationssteuer, die sich mit jedem PI potenziert. Der beste Zeitpunkt für eine Reorganisation ist an einer PI-Grenze.