Von Quartalen zu Tagen – wie ein Software-Joint-Venture seine Liefergeschwindigkeit neu erfand
Kevin Rassner
Die zweite Demo war wenige Wochen nach der ersten. Dieselben VW-Topmanager, dasselbe autonome Fahrzeug, derselbe Testparcours. Nur das Ergebnis war ein anderes: Hatten sie beim ersten Mal enttäuscht festgestellt, dass das Fahrzeug dem Konkurrenten Mobileye weit unterlegen sei, erkannten sie es beim zweiten Mal kaum wieder. Alle geäußerten Wünsche waren umgesetzt. Jemand fragte, wie das möglich sei in so kurzer Zeit. Die Antwort war: Das war per Design so.
Ich war von März 2021 bis April 2023 als Agile Coach Teil dieses Projekts, eines Software-Joint-Ventures zwischen Bosch und Cariad, dem Software-Ableger von Volkswagen für Fahrassistenzsysteme. Was in dieser Zeit entstand, war aus meiner Sicht eine der ungewöhnlichsten und leistungsfähigsten Projektorganisationen, die ich je erlebt habe. Diese Case Study ist mein Versuch, aufzuschreiben, was wir gemacht haben, warum es funktioniert hat und was andere daraus mitnehmen können.
Wie es begann: Die Machbarkeitsstudie und die Entscheidung
Bevor das große Projekt startete, war ich Teil eines kleinen, sehr schlagkräftigen Teams von zwölf Experten, das die Machbarkeitsstudie für eben dieses Joint-Venture-Projekt durchführte. Als das grüne Licht kam und das eigentliche Projekt anlief, wurde ich gebeten, als Agile Coach in eines der ersten Teams einzusteigen.
Die Rolle war kleiner als das, was ich bis dahin gemacht hatte. Aber es war genau das Team, das die Infrastruktur bauen sollte, auf der das gesamte Projekt aufbauen würde. Wo die Musik spielte, war klar. Ich sagte zu.
In den ersten Teams stieß ich auf zwei Agile Coaches, mit denen ich schnell begann, über das größere Bild nachzudenken: Anne Grätz und Eymeric Gireaux. Eymeric, ein außergewöhnlicher Mensch und einer der klügsten Coaches, mit denen ich je gearbeitet habe, ist im April 2026 im Alter von Anfang vierzig an einem Hirntumor gestorben. Ohne seine Energie und seinen Scharfsinn wäre vieles von dem, was ich hier beschreibe, so nicht entstanden.
Aus eigener Motivation heraus begannen wir drei, das System als Ganzes zu denken. Später bekamen wir ein Mandat dafür — zunächst nur für den Bosch-Teil, weil ein noch nicht unterschriebener Kooperationsvertrag eine Zusammenarbeit mit Cariad noch nicht erlaubte. Später dann gemeinsam.
Das erste große Problem: SAFe oder Prinzipien?
Cariads Agile Coaches kamen frisch aus SAFe-Schulungen und waren überzeugt, dass dieses Projekt ein lupenreines SAFe-Programm werden würde. Eymeric und ich hatten beide jahrelange Erfahrung mit SAFe (ich selbst als Release Train Engineer) und wussten, was das bedeutet hätte: lange Planungszyklen, viele Hierarchieebenen, Koordination über Pläne statt über Ziele.
Der Widerstand war groß. Also schlugen wir einen anderen Weg vor: Lass uns keine Methode wählen, bevor wir unsere Prinzipien kennen. Leiten wir aus den Zielen des Projekts ab, was uns wirklich wichtig ist — und messen wir dann jede Methode daran.
Das klang harmlos. Es war es nicht. Sobald die Prinzipien auf dem Tisch lagen, wurde sichtbar, was wirklich kollidierte. Das Prinzip „Ermögliche schnelle Feedbackschleifen, um unseren Plan und die Umsetzungsstrategie anzupassen” ist unvereinbar mit einem quartalsweisen PI-Planning, das einen festen Plan für zwölf Wochen festschreibt. Komplexe Softwareentwicklung ist nicht deterministisch — ein Plan, der heute gilt, ist in drei Wochen oft Makulatur. Statt Plänen zu planen, begannen wir, Ziele zu planen. Die Pläne dorthin änderten sich ständig. Die Ziele überlebten das Quartal.
Ein anderes Prinzip lautete: „Entwickle die Organisation kontinuierlich weiter, um unsere Ziele zu erreichen.” Das widerspricht der Grundidee, eine Organisationsstruktur vorab zu definieren — so wie SAFe es vorschreibt. Wir erkannten früh, dass die größten Probleme systemischer Natur sind. Also durfte und musste man das System anfassen, wenn Probleme auftauchten. Strukturen sind keine Lösung, sie sind ein Werkzeug. Werkzeuge wechselt man, wenn sie nicht mehr passen.
So argumentierten wir SAFe Stück für Stück weg. Was entstand, war etwas Eigenes.
Was das Betriebsmodell wirklich ausmachte
Vier Dinge haben aus meiner Sicht den größten Unterschied gemacht.
Governance by Technology. Wie viele Meetings braucht man, um 35 Teams zu synchronisieren, die am selben Feature arbeiten? Eines pro Woche — wenn technische Governance vorhanden ist. Saubere Code-Ownerships in GitHub, klare Standards für Tests, für Pull Requests, für Entscheidungsgrundlagen. Das klingt nach Software-Engineering, ist aber vor allem Organisationsdesign: Wenn die Architektur des Systems gut ist, brauche ich keine Koordinationsmeetings, um sie zu pflegen. Die Technik koordiniert.
Demos mit Regeln. Es klingt banal, aber unsere Demos unterschieden sich fundamental von dem, was ich in anderen Projekten gesehen hatte. Keine PowerPoint-Präsentationen. Nur fertige Ergebnisse, im echten Tool, im aktuellen Zustand — kein Polishing, kein „wird gerade noch gebaut”. Jeder Präsentierende musste erklären, welchem Ziel sein Ergebnis diente und wie sich die relevanten Key Results dadurch verändert hatten. Diese Regel erzwang Klarheit, die sonst niemand einfordert.
T-förmige Full-Stack-Teams. Unsere Teams konnten end-to-end liefern — von der Entwicklung über die Integration bis zur Auslieferung in alle betroffenen Produkte. Das eliminierte eine Menge Übergaben und damit eine Menge Wartezeiten.
Die Dreiteilung der Führungsrolle. Basierend auf Daniel Pinks Autonomy, Mastery, Purpose erfanden wir drei Führungsrollen. Der Agile Coach sorgte für Autonomie, indem er coachte und am System arbeitete. Der Tech Lead brachte Mastery: Enablement und technische Orientierung. Der Product Owner gab den Teams Purpose — klare Ziele und Sichtbarkeit des Impacts. Die Rollen ergänzten sich, statt zu konkurrieren.
Dazu kamen Communities of Practice, in denen sich die Träger dieser Rollen austauschten und spezialisieren konnten. Dem CoP für Projektkybernetik stand ich selbst vor. Zusammen mit Dashboarding-Experten arbeiteten wir daran, dass Management-Reports nicht mehr manuell geschrieben werden mussten — weil die Antworten live auf Dashboards zu finden waren.
Die härteste Phase: Als die OKRs die Widersprüche sichtbar machten
Die Einführung von OKRs war ein Kampf. Viele der klassischeren Manager im Projekt hatten das Gefühl, die Kontrolle zu verlieren. „Wie soll ich meine Leute führen, wenn ich ihnen nicht mehr sagen darf, was sie machen sollen?” Wir mussten mehrfach damit drohen, das Mandat zurückzugeben, um alle zurück an den Tisch zu bekommen.
Was dann passierte, überraschte uns selbst: Die OKRs machten sichtbar, wie wenig die Beteiligten im Führungskreis bisher voneinander gewusst hatten. Jeder hatte seine Pläne gemacht, ohne dass die Widersprüche aufgefallen wären, weil niemand verstand, was die anderen wirklich taten. Sobald alle in Zielen kommunizierten, wurden diese Widersprüche offensichtlich. Die ersten Wochen waren anstrengend. Dann wurde es schneller.
Unsere größten Kritiker wurden am Ende unsere größten Fürsprecher. Sie sagten selbst, dass sie nie wieder ein Projekt anders steuern wollen würden. Der Grund: In komplexen Projekten ist es viel robuster, den Outcome zu steuern als Inputs oder Outputs. Wer Pläne steuert, verliert sich in Details. Wer Ziele steuert, bleibt wirkungsfähig.
Die Zykluszeit: Von Quartalen zu Tagen
In einem SAFe-Projekt läuft ein Bug in der Regel folgenden Weg: Er wird während des laufenden PI gemeldet, beim nächsten PI-Planning eingeplant und zum Ende des darauffolgenden PI geliefert. Das sind sechs bis neun Monate.
Wir veranstalteten Hackathons mit Managementbeteiligung, bei denen Bugs noch am selben Tag durch die gesamte Kette wandern mussten — von der Meldung über die Entwicklung bis zur Integration. Was für Außenstehende wie eine selbstverständliche Erwartung klingt, ist es nicht. Andere Projekte vergleichbarer Größe brauchten dafür tatsächlich Quartale.
Möglich war das, weil wir unseren Beitrag nicht am Plan maßen, sondern an unserer Wirkung. Ein Bug, der die Wirkung mindert, muss gelöst werden — ohne dass man dafür erst Rücksprache halten oder eine nächste Planungsrunde abwarten muss. Diese Überzeugung muss tief in der Kultur verankert sein, nicht nur im Regelwerk.
Das Projekt lief von 2021 bis zu meinem Ausscheiden im April 2023 auf über 150 Teams an. Es ist bis heute das einzige Projekt im Bosch-Konzern, das trotz massiver Sparmaßnahmen in der Autonomous-Driving-Sparte nicht eingestellt wurde.
Was ich daraus mitnehme — und was das für andere bedeutet
Die ehrliche Botschaft lautet: Das war eine mutige Transformation, bei der auch genug Kompetenz vorhanden war, die aufgedeckten Probleme wirklich zu lösen.
Das ist der entscheidende Unterschied zu vielen Transformationen, die ich seither beobachtet habe. Halbseidene Transformationen scheitern genau daran: Man investiert die Kraft ins Benennen der Probleme — und scheut dann, den gleichen Aufwand in deren Lösung zu stecken. Das frustriert alle Beteiligten und hinterlässt Skepsis, die das nächste Projekt schon belastet bevor es beginnt.
Wer es ernst meint, sucht sich Unterstützung nicht nur in der Analyse, sondern im Aufbau der Lösungskompetenz und -kapazität. Das gilt für ein Projekt mit 1.200 Mitarbeitenden genauso wie für ein Unternehmen mit 80.
Was wir damals gemacht haben, funktioniert auch ohne 1.200 Mitarbeitende: Erst klären, was einem wirklich wichtig ist. Dann die Methoden wählen. Wer das umdreht, kauft sich eine Methode und sucht darin dann nachträglich die Begründung.
Die OKR-Lektion gilt in jedem Führungskreis: Missverständnisse über Ziele existieren fast immer — sie sind nur unsichtbar, solange man in Plänen kommuniziert. Sichtbar zu machen, was nicht funktioniert, ist kein Rückschritt. Es ist der erste Schritt.
Wenn dich beschäftigt, wie eine solche Transformation in deinem Unternehmen aussehen könnte — oder wie man überhaupt anfängt, Prinzipien vor Methoden zu stellen — meld dich gerne.
