Warum komplexe Produktentwicklung trotz Agile und MBSE langsam bleibt

Saab entwickelte den Kampfjet Gripen E mit zwei- bis viertausend Beteiligten in mehr als 100 Teams. Entscheidungen, die in anderen Rüstungsprogrammen Wochen kosten, wurden dort innerhalb eines Vormittags eskaliert und priorisiert. Der Unterschied lag nicht primär in den Methoden, sondern darin, wie schnell Entscheidungen, Wissen und Verifikationsergebnisse durch die Organisation flossen.

Viele Unternehmen haben längst Agile eingeführt, MBSE implementiert und DevOps-Prinzipien übernommen. Trotzdem bleiben Entwicklungszeiten hoch, Entscheidungen langsam und Änderungen teuer. Das Problem: Diese Methoden optimieren lokal. Der Gesamtdurchsatz verbessert sich oft kaum.

Wo Agile und MBSE an Grenzen stoßen

Agile reduziert Feedbackzyklen innerhalb einzelner Teams. MBSE verbessert Systemverständnis und Schnittstellenklarheit. Beides liefert echten Nutzen. Trotzdem bleibt die Gesamtentwicklung in vielen Organisationen langsam.

Der Grund ist strukturell. Agile endet oft an Domänengrenzen. Hardware, Testsysteme, Fertigung, Freigaben und Lieferanten arbeiten mit anderen Geschwindigkeiten und anderen Rhythmen.

Selbst ganzheitliche agile Transformationen lösen dieses Problem nicht automatisch. Zwischen Business, Engineering und Delivery entstehen weiterhin Reibungsverluste. Entscheidungen verlieren sich an Übergängen zwischen Verantwortungsbereichen.

MBSE verbessert den Umgang mit Komplexität, verändert aber nicht automatisch Zusammenarbeit und Entscheidungswege. In vielen Projekten werden Modelle zur zusätzlichen Dokumentation statt zum operativen Entwicklungswerkzeug. Das Systemmodell existiert, aber Architekturentscheidungen entstehen weiterhin in Meetings, PowerPoint-Folien oder persönlichen Abstimmungen.

Das Ergebnis ist lokale Optimierung ohne globale Wirkung. Präzise Modelle veralten. Agile Teams beschleunigen lokale Entscheidungen, während Freigaben, Integration oder strategische Priorisierung weiterhin langsam bleiben.

Das ist kein Methodenproblem. Es ist ein Systemproblem.

Was schnelle Organisationen anders machen

Schnelle Organisationen optimieren nicht primär Ressourcenauslastung. Sie optimieren Entscheidungs- und Feedbackzyklen. Das Ziel ist nicht maximale Aktivität, sondern minimale Wartezeit.

Geschwindigkeit entsteht durch schnelle Erkenntniszyklen und kontrollierte Änderbarkeit über den gesamten Produktlebenszyklus hinweg. Zehn schnelle Teams, die regelmäßig aufeinander warten, sind nicht wesentlich schneller als ein langsames Team.

Saab Gripen E: Entscheidungsgeschwindigkeit als Systemdesign

Der Gripen E ist ein Kampfjet der vierten Generation. Saab entwickelte ihn mit zwei- bis viertausend Beteiligten in mehr als 100 Scrum-Teams. Die Teams waren nach physischen und funktionalen Komponenten organisiert: Rumpf, Strukturen, Cockpit, Steuerungssoftware.

In dieser Umgebung sind teamübergreifende Abhängigkeiten unvermeidbar. Ohne explizite Mechanismen zur Eskalation und Entscheidungsfindung akkumulieren sich ungelöste Blocker, verlangsamen die Designarbeit und verzögern die Integration.

Saabs Lösung war ein explizites System für schnelle Entscheidungen.

Jeden Morgen beginnt der Prozess um 7:30 Uhr mit Daily Scrums auf Teamebene. Danach folgen sukzessive Scrum-of-Scrums-Ebenen. Probleme, die lokal nicht gelöst werden können, wandern sofort nach oben und erreichen das Executive Action Team um 8:30 Uhr.

Jede Ebene versucht das Problem unmittelbar zu lösen. Gelingt das nicht, wird es ohne Verzögerung eskaliert. Führungskräfte sind explizit für die Beseitigung von Blockern verantwortlich, nicht für Statusverwaltung.

Das Ergebnis: Entscheidungen, die in anderen Programmen Wochen oder Monate kosten, werden innerhalb eines Vormittags sichtbar gemacht und priorisiert. Viele Blocker verschwinden noch am selben Tag.

Die Entwicklung des Gripen E verlief nicht völlig frei von Verzögerungen und Budgetanpassungen, war im Vergleich zu anderen modernen Kampfflugzeugprojekten jedoch außergewöhnlich effizient. Software-Releases erfolgten alle sechs Monate. Für ein Rüstungsprogramm dieser Größenordnung ist das ein ungewöhnlicher Rhythmus.

Saab reduzierte nicht die Komplexität. Saab veränderte die Architektur der Entscheidungsprozesse. Wartezeiten wurden nicht ignoriert, sondern systematisch adressiert.

Von DevOps zu Product Velocity

DevOps hat Softwareentwicklung grundlegend verändert. Entwicklung, Integration, Deployment und Betrieb wurden als gemeinsamer Fluss betrachtet. Continuous Integration und Continuous Deployment reduzierten Wartezeiten drastisch.

Das war keine Werkzeugfrage, sondern eine Frage des Systemdenkens.

Für cyberphysische Produkte lässt sich diese Logik nicht direkt übertragen. Hardware benötigt Fertigung. Physik begrenzt Änderbarkeit. Sicherheit und Compliance erzeugen zusätzliche Nachweispflichten. Mechanik, Elektronik und Software arbeiten auf unterschiedlichen Zeitskalen.

Product Velocity überträgt deshalb nicht die Werkzeuge von DevOps, sondern die zugrundeliegenden Prinzipien: Wo entstehen Wartezeiten? Wo stockt der Fluss von Wissen und Entscheidungen? Welche Abhängigkeiten erzeugen Koordinationsaufwand? Was verhindert frühe Integration und schnelle Verifikation?

Die Velocity Loop

Die Velocity Loop beschreibt Produktentwicklung als zusammenhängenden Fluss aus vier Bereichen: Business, Engineering, Delivery und System Stewardship.

• Business definiert Ziele, Prioritäten und Kundenwert.
• Engineering entwickelt Lösungen und Architektur.
• Delivery erzeugt lauffähige Systeme, integriert Änderungen und liefert Verifikationsergebnisse.
• System Stewardship gestaltet Organisation, Verantwortlichkeiten, Plattformen und Entscheidungswege so, dass der Fluss zwischen den anderen Bereichen erhalten bleibt.

Die Schleife macht sichtbar, dass Produktentwicklung kein linearer Prozess ist. Entscheidungen, Erkenntnisse und Verifikationsergebnisse bewegen sich kontinuierlich zwischen den Bereichen. Verzögerungen entstehen meist an den Übergängen.

Die zentrale Frage lautet deshalb nicht: „Welcher Prozessschritt ist langsam?“ Sondern: „Wo stockt der Fluss?“

Die vier Prinzipien

Product Velocity basiert auf vier Prinzipien, die Business, System Stewardship, Engineering und Delivery verbinden.

Value Thinking fragt, ob die richtigen Dinge entwickelt werden. Nicht: Wird Arbeit effizient abgearbeitet? Sondern: Erzeugt sie Kundenwert und strategischen Nutzen?

Architect for Flow fragt, wie Architektur den Entwicklungsfluss beeinflusst. Architektur, die Teams koppelt, erzeugt Koordinationsaufwand. Architektur, die Teams entkoppelt, reduziert ihn.

Shift Left verschiebt Verifikation, Integration und Entscheidungen nach vorne. Je später ein Problem erkannt wird, desto teurer wird die Behebung. Das gilt für cyberphysische Produkte genauso wie für Software.

Accelerate reduziert Feedbackzyklen systematisch und kontinuierlich. Nicht als einmalige Transformation, sondern als dauerhafte Praxis.

Die Prinzipien funktionieren nur gemeinsam. Schnelle Delivery hilft wenig, wenn Architektur starke Abhängigkeiten erzeugt. Value Thinking hilft wenig, wenn Verifikation Monate dauert.

Ein Diagnosewerkzeug für den Einstieg

Viele Organisationen kennen ihre eigentlichen Engpässe nicht. Oft wird diskutiert, welche Methode als nächstes eingeführt werden soll, bevor klar ist, wo der Fluss tatsächlich stockt.

Drei Fragen helfen beim Einstieg:

1. Wo warten Teams regelmäßig auf Entscheidungen?
2. Welche Änderungen erzeugen unerwartete Nebenwirkungen?
3. Welche Erkenntnisse entstehen erst sehr spät im Projekt?

Die Antworten machen organisatorische Kopplung, instabile Schnittstellen und fehlende frühe Verifikation sichtbar.

Diese Fragen lassen sich in Workshops analysieren und in kurzen Interventionen gezielt adressieren.

Der Engpass liegt selten bei individueller Produktivität. Er liegt fast immer im System.

Fazit

Agile und MBSE lösen reale Probleme. Sie garantieren keine schnelle Produktentwicklung. Geschwindigkeit entsteht dort, wo Wissen, Entscheidungen und Verifikation schnell durch die Organisation fließen.

Wenige Unternehmen zeigen heute bereits, dass drastische Beschleunigung möglich ist. Nicht durch einzelne Methoden, sondern durch ein anderes Systemverständnis.

Product Velocity liefert dafür ein Denkmodell. Die Velocity Loop und die vier Prinzipien machen sichtbar, wo der Fluss stockt und warum lokale Optimierung oft wirkungslos bleibt.