Ein Solution Train ist das Organisationskonstrukt in SAFe, mit dem mehrere Agile Release Trains (ARTs) und Lieferanten koordiniert werden, um eine große integrierte Lösung zu entwickeln (z. B. komplexe Software-Plattformen oder cyber-physische Systeme). Er gehört zur Large Solution-Konfiguration und bringt zusätzliche Rollen, Events und Artefakte ein (u. a. STE, Solution Management, Solution Architect/Engineering, Pre-/Post-PI-Planning, Solution Intent).
Wann sinnvoll (Einsatzkriterien)
Ein Solution Train lohnt sich, wenn mehrere Bedingungen gleichzeitig gelten:
- Ein integriertes Inkrement über mehrere ARTs ist zwingend (gemeinsame System-/Lösungsintegration pro PI).
- Hohes Integrations- und Abhängigkeitsrisiko, das mit bilateraler Abstimmung nicht mehr beherrschbar ist.
- Großskalige Lösungen ohne Bedarf an Portfolio-Governance (ansonsten Full SAFe).
- Lieferanten/Partner müssen in denselben Takt (Cadence) integriert werden.
Nicht sinnvoll ist ein Solution Train, wenn ARTs keine gemeinsame integrierte Lieferung benötigen oder Abhängigkeiten durch Sequenzierung (Portfolio-Steuerung) lösbar sind – dann ist der Overhead unnötig.
Praxisbezug (Kernelemente & Events)
- Rollen:
- Solution Train Engineer (STE) – Servant Leader/Coach; facilitiert Events/Prozesse, koordiniert ARTs und Lieferanten, fördert Flow & Transparenz.
- Solution Management – inhaltliche Ausrichtung (Capabilities, Roadmap).
- Solution Architect/Engineering – technische Kohärenz/Runway über ARTs hinweg.
- Events/Syncs:
- Pre-/Post-PI-Planning,
- Solution Demo,
- Solution Syncs (PM-Sync, Architect-Sync, SoS auf Large-Solution-Ebene).
- Artefakte:
- Solution Intent,
- Solution Roadmap,
- Capability/Feature-Kanban.
Typische Missverständnisse
„Solution Train = Reporting-Schicht“ – falsch. Ziel ist integrierte Lieferung und Entscheidungs-/Lösungs-Synchronisation, nicht Statusberichte.
„Wir brauchen immer einen Solution Train, sobald >1 ART“ – nein. Nur, wenn Integration pro PI nötig ist.
„STE ist ein ‚Super-RTE‘“ – der Systemfokus ist größer (übergreifende Flow-, Risiko- und Abhängigkeitssteuerung, Lieferanten-Einbindung).
Typische Probleme (und Antipatterns)
- Kein echtes integriertes Inkrement → Solution Train liefert nur Meetings, nicht Wert.
- Event-Overhead ohne Klarheit → Pre-/Post-PI zu „Ritualen“ ohne harte Outputs.
- Unreife Architektur/Runway → Integration kollabiert.
- Schwacher STE → fehlende Steuerung übergreifender Risiken und Lieferanten.
- Falscher Zuschnitt → Abhängigkeitsspaghetti durch falschen ART-Schnitt.
STE-Rolle im Zusammenspiel
- Koordination & Flow (A): STE accountable für Events und Flow, R mit RTEs, C mit Solution Mgmt/Arch, I Business Owners.
- Inhalt (R): Solution Management, STE C/I.
- Technische Kohärenz (R): Solution Architect/Engineering, STE C/I.
- Lieferantenintegration (R): STE gemeinsam mit Procurement/Partner-Leads, Fokus auf Cadence & Definitionen.
Beispiel aus der Praxis
Ein Hersteller eines Fahrassistenz-Systems (15+ ARTs, mehrere Zulieferer) litt unter schwankender Integrationsqualität. Einführung eines Solution Trains mit striktem Pre-/Post-PI, Solution Demo, Architect-Sync und Supplier-On-Cadence führte zu früheren System-Feedbacks, niedrigerer Nacharbeitsquote und klareren Risiko-ROAMs.
Alternativen bzw. Vorstufen
- Kein Solution Train: Wenn Integration nicht PI-taktgebunden nötig ist, reicht Portfolio-Sequenzierung + ART-Syncs.
- Temporäre Cross-ART-Initiativen: Für begrenzte Integrationsphasen ohne dauerhafte Large-Solution-Struktur.
- Team Topologies + Value-Stream-Schnitt: Abhängigkeiten durch guten Zuschnitt minimieren, bevor man skaliert.
So nutzen gute Coaches den Solution-Train-Hebel
- Einsatzkriterien prüfen: Nur starten, wenn Nutzen > Overhead.
- Operating Model klären: Calendar-of-Syncs, harte Inputs/Outputs für Pre-/Post-PI.
- System-Metriken etablieren: Integration-Success-Rate, Time-to-Integrate, Dependency-Lead-Time.
- Lieferanten on-cadence bringen.
- STE Enablement: Fortgeschrittene Facilitation, Risiko-/Abhängigkeitsmanagement, Supplier Management
CALADE-Perspektive
Wir bringen Erfahrung ein, wenn es darum geht, zu entscheiden, ob eine Solution-Ebene sinnvoll ist oder nicht. Statt reflexartig auf Skalierung zu setzen, prüfen wir gemeinsam mit Kunden, ob der Zuschnitt und das Integrationsrisiko einen Solution Train rechtfertigen. Falls ja, unterstützen wir beim Aufbau und der Etablierung der Struktur – von den Events über Solution Intent bis zur Lieferanten-Einbindung.
Da die Rolle des Solution Train Engineer (STE) hohe Erfahrung erfordert, stellen wir im Angebotsbereich „Experten“ qualifizierte STEs bereit, die nicht nur Events orchestrieren, sondern Flow, Risiken und Abhängigkeiten systemisch steuern.
Weiterführende Begriffe
- Large Solution SAFe
- Solution Train Engineer (STE)
- Pre-/Post-PI-Planning
- Solution Intent
- Solution Architect/Engineering
- ART Sync / PM-Sync / Architect-Sync
← zurück zur Übersicht