| | |

Wie man Blocker in 60 Minuten bis zum Vorstand eskaliert (und warum VW ein echtes Problem hat)

Wie man Blocker in 60 Minuten bis zum Vorstand eskaliert (und warum VW ein echtes Problem hat)

Agilität ist längst nichts neues mehr und inzwischen eigentlich eine Notwendigkeit zum Überleben. Und zwar nicht nur in der Softwareentwicklung, wo sie herkommt und eigentlich für kleine Teams konzipiert wurde. Auch Organisationen versuchen längst, Agilität zu skalieren. Doch viele scheitern dabei: Sie schreiben sich „agil“ auf die Fahnen, ohne ihre Strukturen zu ändern.

Wie ernst es ein Unternehmen mit Agilität meint, erkennt man nicht an SAFe-Zertifikaten. Sondern zum Beispiel daran, wie es mit Blockern umgeht. Denn Blocker können über Abteilungen hinweg Stillstand verursachen und dabei Ressourcen brach liegen lassen und Zeit verschwenden.

Und genau hier zeigt sich der Unterschied zwischen Lippenbekenntnis und gelebter Agilität: Bei Saab Aeronautics landen Blocker innerhalb von 60 Minuten beim Vorstand. Jeden Tag. Hand aufs Herz: Trauen wir das auch VW zu?

In vielen Unternehmen ist Agilität ein Lippenbekenntnis, statt Transformation.

Agile skalieren heißt Engpässe beseitigen

Die Grundidee von Agilität kennen sicherlich die meisten Leser: kurze Zyklen, schnelles Feedback, kontinuierliche Anpassung. Doch wie bringen wir dieses Prinzip in eine Organisation mit Tausenden von Mitarbeitenden, komplexen Produkten und gewachsenen Strukturen? Viele setzen auf Frameworks wie SAFe oder LeSS, doch diese werden schnell zu bürokratischen Monstern. Skalierung gelingt nicht durch mehr Prozesse, sondern durch mehr Klarheit, konsequente Priorisierung und den gnadenlosen Fokus auf das Entfernen von Engpässen. Und einer der größten Engpässe sind Wartezeiten.

Saab: Agile im Maßstab eines Kampfjets

Saab Aeronautics hat diese Herausforderung angenommen, und das im Bereich Defense, der eigentlich sehr konservativ ist. Nachzulesen ist das im Buch Industrial DevOps von Dr. Suzette Johnson und Robin Yeman.

Der Gripen, ein hochmoderner Mehrzweckkampfjet, ist ein Milliardenprojekt mit über 1000 Ingenieuren in mehr als 100 Teams. Saab hat konsequent agile Prinzipien auf Hardware- und Softwareentwicklung übertragen, mit beeindruckenden Ergebnissen: höhere Geschwindigkeit, bessere Qualität, drastisch niedrigere Kosten. Konkret setzte Saab die folgenden Prinzipien um:

  • Variabilität managen: Saab schafft Transparenz, indem alle Teams im gleichen Takt arbeiten: dreiwöchige Sprints, die gleichzeitig starten und enden. Darüber hinaus arbeitet Saab in vierteljährlichen „Increments“, die größere Integrationspunkte setzen. So wird Variabilität beherrschbar. Abhängigkeiten werden früh sichtbar, Integration wird nicht auf das Ende verschoben, sondern kontinuierlich getestet.
  • Priorisierung: Es gibt immer mehr Arbeit, als Kapazitäten vorhanden sind. Priorisierung ist deshalb essentiell. Product Owner verantworten den Backlog für 4–8 Teams, in dem nicht nur Features, sondern auch Risiken und Prozessverbesserungen stehen. Ziel ist Klarheit: Teams müssen zu Sprintbeginn genau wissen, was zu liefern ist und welche Abhängigkeiten bestehen.
  • Strategische Planung: Saab nutzt strategische Pläne als Leitplanken, die regelmäßig auf Basis von Feedback angepasst werden. Detailliert wird nur, was unmittelbar ansteht. Je näher ein Entwicklungsschritt rückt, desto feiner wird er heruntergebrochen, bis zu den bereits erwähnten dreiwöchigen Iterationen.
  • Kontinuierliche Verbesserung: Jede Retrospektive liefert konkrete Verbesserungen für den nächsten Sprint. Darüber hinaus gibt es eine „Retrospective of Retrospectives“, in der teamübergreifende Themen und Führungsaspekte adressiert werden. Kanban-Boards helfen, den Feedbackzyklus weiter zu verkürzen und Blocker sofort sichtbar zu machen.

Eskalation in einer Stunde, jeden Tag

Das beeindruckendste Element von Saabs System ist die tägliche Eskalationskette. Sie sorgt dafür, dass jeder Blocker, den ein Team nicht selbst lösen kann, innerhalb eines Vormittags auf Vorstandsebene landet. Das funktioniert folgendermaßen:

  • 7:30 Uhr: Daily Scrum auf Team-Ebene
  • 7:45 Uhr: Scrum of Scrums
  • 8:00 Uhr: Scrum of Scrum of Scrums
  • 8:15 Uhr: Scrum of Scrum of Scrum of Scrums
  • 8:30 Uhr: Executive Action Team

So entsteht ein durchgängiger Kommunikationskanal vom Entwickler bis zum Vorstand. Jede Ebene versucht, Blocker zu lösen. Gelingt das nicht, geht das Thema unmittelbar weiter nach oben. Für die Führungsebene ist das Lösen dieser Hindernisse die wichtigste Aufgabe des Tages.

Das Ergebnis: Entscheidungen fallen in Stunden statt in Monaten

Cariad: Vision richtig, System falsch

VW hatte Cariad gegründet, da der Konzern die Bedeutung von Software verstanden hatte und nun versuchte, die Vision des Software Defined Vehicle (SDV) umzusetzen.

Die Idee war richtig, aber nicht das System. Cariad wurde in ein Organisationsmodell gepresst, das für Hardware optimiert ist: sequentielle Prozesse, Silos, Fokus auf Kostensenkung und Effizienz. Hinzu kam die interne und auch äußerliche Distanz zum Fahrzeugkonzern und der Hardwareentwicklung.

Die Probleme waren vielfältig, die Presse hatte regelmäßig über interne Konflikte, Verzögerungen, Konzernpolitik und ähnliches berichtet. Zwischenzeitlich plante VW sogar eine Zweigleisigkeit in seiner Softwarestrategie: Für den westlichen Markt sollte die Plattform gemeinsam mit Rivian entwickelt werden, während für China und Asien eine eigene Softwarelösung der Partnerfirma Xpeng zum Einsatz kommen sollte. Dieses parallele Vorgehen verdeutlicht, wie zerrissen und inkonsistent die Gesamtstrategie geblieben ist.

Rivian und die Chance zum Systemwechsel

Gerade das Joint Venture mit Rivian sollte viele Probleme lösen, da Rivian bereits erfolgreich Software für Fahrzeuge produziert. Rivian hat einen klaren Scope, erlaubt keine Sonderwünsche, fällt harte Entscheidungen und managt aktiv die Komplexität. Doch VW blieb VW, und auch mit Rivian läuft es nicht rund. Jetzt werden doch wieder Verbrenner ins Spiel gebracht, obwohl die Roadmap längst definiert war. Rivian sagte Nein. CARIAD hätte Ja sagen müssen. Und genau hier zeigt sich das Problem: Solange sich das System nicht ändert, wird jeder Partner an VW scheitern.

Können VW und Cariad sich ändern?

Die Frage ist nicht, ob VW Software kann. Die Frage ist, ob VW sein System ändern kann. Und hier bin ich skeptisch. Die Eskalationskette von Saab halte ich bei VW für schlicht unvorstellbar. Zu tief sitzen Misstrauen, Kontrollwahn und Gremienlogik. Selbst mit gutem Willen ist ein Kulturwandel dieser Größenordnung kaum zu erreichen.

Meine Prognose: VW ist „too big to fail“. Der Konzern wird überleben und sich transformieren. Aber viel zu langsam. Und am Ende wird er ein Schatten seiner selbst sein. Hoffentlich bleibt wenigstens dieser Schatten Deutschland erhalten.

Fazit: Kultur schlägt Framework

Dass Agilität im großen Stil ist möglich, hat Saab bewiesen. Selbst in einer hochregulierten, komplexen Branche mit Milliardenprojekten lässt sich Agilität skalieren, wenn Kultur und Strukturen es zulassen. Möglich ist dies durch radikale Transparenz, konsequente Priorisierung, tägliche Eskalation und eine Führung, die Hindernisse aktiv beseitigt.

In Deutschland ist dieser Wandel schwer. Unsere Unternehmen sind effizient, können sich aber nicht gut anpassen. Aber ohne Systemwechsel bleibt Agilität ein Lippenbekenntnis und die Blocker häufen sich. Saab hat gezeigt, wie es geht. VW zeigt, was passiert, wenn man es nicht tut.

Ähnliche Beiträge

Schreibe einen Kommentar