Den Kuchen haben und ihn essen? Kombination von SAFe und V XT

Neulich, in einer internen Wissensaustausch‑Session, stellte mein Kollege Dr. Felix Herold das SAFe‑Framework und das SAFe Essential Model vor. SAFe skaliert agile Prozesse auf größere Teams und soll Unternehmen eine agile Denkweise ermöglichen. In der Diskussion kam eine Frage auf, die ich hier beantworten möchte.

SAFe – das Scaled Agile Framework – und seine Grenzen

Für große Organisationen wirkt SAFe oft wie das Versprechen, das gesamte Unternehmen unter einem agilen Betriebsmodell zu einen. Es erweitert agile Prinzipien um Ebenen für Koordination, Planung und Governance, die Scrum‑ähnliche Muster auf anderen Zeithorizonten und Abstraktionsebenen einsetzen. Ziel ist, Scrum‑Vorteile auf Enterprise‑Ebene zu übertragen, insbesondere Kundenorientierung, eingebaute Qualität, Transparenz und Lean‑Denken.

SAFe etabliert feste Rhythmen für Planung, Synchronisation und Reflexion, damit Mitarbeitende ein gemeinsames Verständnis von Unternehmens‑ und Produktzielen entwickeln. Das ist die Theorie. In der Praxis hängt der Erfolg wie bei Scrum stark von den Menschen ab, die es vorantreiben. Entwickler sind meist durch das Erstellen und Ausliefern von Software motiviert, nicht durch Zeremonien. Scrum Master, Product Owner und technische Führung müssen daher Rahmen schaffen, in denen Events sinnvoll sind und Teams sich engagieren.

Mit guter Führung funktioniert das sehr gut; ohne sie degeneriert agiles Vorgehen leicht zu einer Abfolge wertarmer Meetings. In ein bis zwei Teams reichen wenige Prozess‑Treiber. Mit wachsender Organisation entstehen jedoch oft Silos oder Prozessverfall. SAFe‑Szenarien mit Agile Release Trains (ARTs) – typischerweise etwa 10 Teams oder mehr – bringen zusätzliche, großskalige Events (z. B. PI Planning mit mehr als 100 Teilnehmenden). Damit Entwickler in solchen Settings fokussiert bleiben, sind erfahrene Moderation und klare Kommunikation nötig, damit jede:r den eigenen Beitrag als relevant erlebt.

SAFe in regulierten Umgebungen

Große Organisationen haben daüber hinaus meist bestehende Prozesse, teils aus regulatorischen Gründen, teils aber auch nur historisch gewachsen. Der Einsatz des SAFe Frameworks ist für solche Unternehmen ist nicht ausgeschlossen, verlangt aber oft erhebliches Tailoring von SAFe oder einen hybriden Ansatz zwischen SAFe und den existierenden Prozessen. Entscheidend ist: Auf Team‑Ebene ist die konkrete Entwicklungsmethodik oft zweitrangig; wichtiger ist, dass Teams auf Portfolio‑/PI‑Ebene im vorgegebenen Takt liefern und reagieren können. ARTs und PIs sind eine Abstraktionsebene über der täglichen Engineering‑Arbeit. Definiert man klare Schnittstellen, dann kann SAFe neben alternativen Teamprozessen bestehen.

Ein konkretes Beispiel ist das V‑Modell XT, das in regulierten deutschen Behörden weit verbreitet ist. Im V‑Modell XT steht das „XT“ für eXtreme Tailoring. Die Kernidee ist, das klassische V‑Modell neu zu denken, indem der Fokus von Aktivitäten hin zu klar definierten Produkten verschoben wird, jeweils mit expliziter Struktur und Qualitätskriterien. Wesentlich ist, dass das V‑Modell XT ausdrücklich auf Anpassbarkeit ausgelegt ist. Diese Flexibilität macht es – innerhalb gewisser Grenzen – kompatibel mit iterativen und sogar Scrum‑basierten Ansätzen. Noch wichtiger: V‑Modell XT bejaht Veränderung und Iteration über den gesamten Entwicklungszyklus hinweg. Diese Eigenschaften machen es zu einem praktikablen Kandidaten für Organisationen, die SAFe in regulierten Umgebungen einführen möchten. Dennoch erfordert das Zusammenwirken beider Frameworks sorgfältige Betrachtung.

Wie man das Beste aus beiden Welten bekommt

1. 1. Klare Verantwortungsgrenzen:
   – SAFe regelt Finanzierung, Kadenz, Koordination und Transparenz auf Enterprise‑Ebene.
2. – V‑Modell XT regelt Engineering, Verifikation, Compliance auf Team‑/Projektschicht.
   2. Tailoring:
   Beide Frameworks müssen an den Kontext angepasst werden. Ein praktikabler Hybrid entsteht iterativ durch Anpassung und Feedback.
   3. Inkrement‑Definition:
   SAFe sieht Inkremente als potenziell auslieferbaren Wert; V‑Modell XT definiert Inkremente als verifizierten, dokumentierten Produktzustand. Praktisch heißt das: Stakeholder müssen kleinere, dafür vollständig verifizierte Inkremente akzeptieren; Teams müssen diese so dimensionieren, dass sie in SAFe‑Cadences passen.
   4. Planung und Commitment neu denken:
   Story‑Points‑Velocity reicht nicht mehr allein. Planung sollte sich an Anforderungsabdeckung, Testspezifikationen und Verifikationsergebnissen orientieren. Teams verpflichten sich zur Lieferung einer verifizierbaren Funktionalität statt zu „x Story Points“.
   5. Traceability und Compliance:
   Testberichte, Akzeptanzkriterien und Trace‑Matrizen müssen in SAFe‑Planung, PI‑Reviews und Artefakte einfließen, um Compliance nachzuweisen.
   6. Moderation und Führung:
   Große Zeremonien benötigen erfahrene Facilitation, damit sie motivierend, fokussiert und entscheidungsorientiert bleiben.
   7. Zombie‑SAFe vermeiden:
   Gefahr ist, SAFe‑Begriffe zu nutzen, ohne inspect‑and‑adapt, gemeinsame Planung und echtes Commitment zu leben. Das Risiko verbaler Agilitätsbekundungen existiert auch in kleinen Scrum‑Teams; kontinuierliche Reflexion und Führung sind zentral.
   8. Iteratives Vorgehen: Ein Hybridmodell reift über mehrere Zyklen. Messen, Feedback einholen und schrittweise anpassen.

Quellen:

• ScaledAgile (Big Picture): https://framework.scaledagile.com/#big-picture
• Agile Scrum: https://agilescrumgroup.de/safe-scaled-agile-framework/
• V‑Model: https://en.wikipedia.org/wiki/V-model
• V‑Model XT: https://weit-verein.de/v-modell-xt-neues-release-2-3/
• V‑Model XT Tailoring tool: https://pa.dipa.online/#/tailoring

Dieser Beitrag ist in etwas ausführlicherer Form in Englischer Sprache auch auf meinem privaten Blog erschienen: https://www.lowlevelnoise.net/can-you-have-your-cake-and-eat-it-combining-safe-and-v-xt/index.html