Automotive Software - Wie wir die Car-IT endlich in den Griff bekommen
Wie viele andere verfolge ich seit Monaten die Berichterstattung über die immer wiederkehrenden Dramen der deutschen Autoindustrie beim Thema Embedded Software. Von dem ein oder anderen Hersteller ist besonders viel in den Medien zu lesen. Ich beobachte jedoch, dass sich so gut wie alle großen Hersteller - aber auch Zulieferer - mit der Softwareentwicklung schwertun. Die Komplexität wird unterschätzt, große Vorhaben sind um Jahre im Verzug und auch inhaltlich sind die Lösungen bei Weitem nicht so ausgereift, wie man sich das gewünscht hatte.
Warum ist das so? Ich wage drei Hypothesen.
Hypothese 1: Talentierte Software-Entwickler:innen sind Mangelware.
Software-Entwickler:innen sind rar am Markt und der Wettbewerb um diese ist groß. Zudem ist ein großer Teil der Software für Autos und andere Fahrzeuge sicherheitskritisch und hardware-nah und damit entsprechend komplex. Für viele, die es gewohnt sind (Web-)Applikationen für User zu entwickeln ist das nicht gerade verlockend.
Wenn endlich die Entwickler:innen an Bord geholt wurden, folgt nicht selten der Clash der Ingenieur:innen: Die Expert:innen für Software und Hardware sprechen verschiedene Fachsprachen, gehen Probleme unterschiedlich an und vor allem haben sie oft ein gänzlich anderes Mindset. Die Basis für eine gute Zusammenarbeit fehlt: eine offene Haltung und eine Kultur, in der man aufeinander zugeht und gemeinsam auf ein Ziel hinarbeitet. Das erfordert Arbeit am System. Was mich zur zweiten Hypothese bringt.
Hypothese 2: Die Bürokratie ist überbordend – die Unternehmen stehen sich selbst im Weg.
Als würden das Fehlen und der Clash der Expert:innen ihnen das Leben nicht schon ausreichend erschweren, machen sich die Unternehmen es selbst noch schwerer, indem sie trotz moderner agiler Arbeitsweisen an alten Strukturen und altem Reporting festhalten. Jede Führungskraft will informiert und auf dem neuesten Stand gehalten werden. Aber zu welchem Preis? Freigaben für simple Dinge durchlaufen endlose Umlaufverfahren.
Wenn wir uns für jegliches Risiko absichern wollen, sei es noch so minimal – dann verhindern wir eine konstruktive Fehlerkultur. Wie soll in diesem Umfeld jemals eine wendige und schnelle Entwicklung entstehen? Eine ideale Arbeitsumgebung für Entwicklungsmannschaften sieht anders aus. Das bringt mich zu Hypothese 3.
Hypothese 3: Es gelingt nicht, große Projekte richtig gut zu skalieren.
Wir denken bei der Skalierung von Projekten – also der Zusammenarbeit von mehreren Teams an einem Produkt – oft noch zu sehr in Blaupausen. Oft sogar in solchen, die altmodische Muster reproduzieren. Umfangreiche Frameworks mit starken Vorgaben begünstigen Bürokratie und schränken die Möglichkeit zu experimentieren ein.
Damit zahlen sie auf meine zweite Hypothese ein. In den meisten großen Automotive-Projekten, die ich bisher begleiten durfte, war eine Form von SAFe® im Einsatz. Ich verteufle dieses Framework nicht, jedoch würde ich mit einem leichtgewichtigeren Tool starten, dass näher am Kunden orientiert ist. Dafür würde ich zum Beispiel Ansätze aus LeSS oder Scrum@Scale integrieren, weil diese im ersten Schritt sehr simpel dafür sorgen, dass gewisse Rollen einfach regelmäßig zusammenkommen und ihre jeweiligen Themen in synchronen Meetings klären.
Ein weiteres Hindernis für die Skalierung: die Scheu davor, in den Teamschnitten neue Wege zu gehen. Oft beobachte ich zu viele Abhängigkeiten zwischen zu vielen Teams, die nicht mehr handhabbar sind und zu unglaublichem Aufwand in der Kommunikation und damit zu Traktionsverlusten führen. Die Alternative: Teams im Sinne einer End-to-end-Verantwortung schneiden und somit Autonomie für jedes einzelne Team ermöglichen. Durch diesen systematischen Abbau der Abhängigkeiten ergeben sich Effizienzen, die selbst das ausgefeilteste Skalierungsmodell nicht heben könnte.
Die gute Nachricht ist: All diese Probleme sind lösbar.
- Fachkräfte: Wir haben großartige Universitäten, die hochqualifizierte Leute in den Arbeitsmarkt bringen. Wir haben eine große Tradition im Ingenieurswesen für Hardware und diese können wir in der Softwareentwicklung weiterschreiben.
- Bürokratie: Wir haben tolle Vorbild-Unternehmen, die mit Hilfe einer agilen Transformation bereits einen großen Teil ihrer Bürokratie losgeworden sind (siehe z. B. diese Case Studys).
- Skalierung moderner Arbeitsweisen: Es gibt heute eine Reihe guter Ansätze und Erfolgsbeispiele für die Skalierung agil arbeitender Teams.
Mein Fazit: Wir haben alles in der Hand, um die aktuellen Probleme in der Softwareentwicklung in der deutschen Autobranche zu lösen. Nun brauchen wir nur noch den Mut, diese Tools auch zu nutzen. Schaut euch auch gerne unseren Skalierungsansatz myScaledAgile an, der es sich zum Ziel gesetzt hat, für die jeweilige Unternehmung das passfähigste Framework zu entwickeln.
