Zukünftige Softwaredominanz treibt neue Formen der Zusammenarbeit voran

Die Nachricht vom 28.06.21 war nur eine von mehreren gleichlautenden Verlautbarungen der Autohersteller: Mercedes rückt die Software ins Zentrum seiner Wertschöpfung und stellt 3.000 neue Softwareentwickler ein. Das Geschäftsmodell der Mercedes-Zukunft setzt stark auf ein eigenes Betriebssystem und bezahlte Softwareupdates. Werden wir gerade Zeuge der Umsetzung von Step 2 im Paradigmenwechsel der Autoindustrie?

Step 1 ist die in vollem Gange befindliche Nachhaltigkeits-Transformation. Ein Element darin: Die Emissionen gesundheitsschädlicher Abgasschadstoffe in urbanen Zonen und die globalen CO²-Emissionen müssen verringert werden. Das geht in großem Maßstab nur durch die Elektrifizierung der Fahrzeuge. Hier zählt der Faktor Zeit. Wird ein Fahrzeug heute elektrifiziert, ist es mehr als zehn Jahre im Markt und wird in seinem Lebenszyklus durch den zunehmenden Anteil regenerativer Primärenergie „sauberer“.

Step 2 ist die logische Konsequenz der Elektrifizierung: Ein konsequent elektrifiziertes Auto ist kein „Kraftfahrzeug“ mehr, sondern ein digital vernetzter, mobiler Lebensraum. Ein Computer auf Rädern. Und der funktionale Kern eines Computers ist seine Software.

Die Unabänderlichkeit dieser Logik wird teils bis heute verneint, verdrängt, verharmlost. Spätestens seit sich abzeichnet, dass batterieelektrische Fahrzeuge ab 2025 dem Verbrenner nicht nur in der Reichweite ebenbürtig, sondern auch in den Produktionskosten günstiger sein werden, geht das altbekannte „Auto“ langsam, aber sicher den Weg ins Museum.  Halten wir fest: Das Auto wird zum Smart Transportation Device – und somit von Software gesteuert.

Der Teletext war die größte Errungenschaft des Jahres 1971. Die Rechenleistung stieg in den 50 Jahren bis 2021 um den Faktor 1 Million, und somit stieg die Fähigkeit, komplexe Software zu verarbeiten. Das „Moore’sche Gesetz“, nach dem sich diese Leistung stetig steigert, gilt heute noch wie vor 50 Jahren.

Schaut man sich nun die Errungenschaften der letzten 50 Jahre Entwicklung von Auto und Software nebeneinander an, dann fällt auf: Die Softwareentwickler lernten zunächst in den 90ern von der Autoindustrie! Wie kam das?

Ein Treiber der Produktivitätsgewinne bei Computern war ab den 1990er Jahren die agile Softwareentwicklung. Programmierer mussten in immer kürzerer Zeit immer größere Mengen von Code erzeugen, testen und „auf die Straße bringen“. Mit Produktivität kannte man sich in Software nicht aus. Was lag also näher, als mal bei der Autoindustrie zu schauen, ob und wie man von dort etwas lernen und die Produktivität auch bei der Softwareentwicklung steigern könnte.

Und man wurde schnell fündig: Da waren Eli Goldratt’s Theory of Constraints, es gab das Toyota Produktionssystem, die Lean Production, die Prinzipien von Flow und Kanban, und das Total Quality Management. Tatsächlich: Aus diesen Erkenntnissen leiten sich bis heute auch die Kernsätze modernster lean-agiler Softwareentwicklung ab. Das Ergebnis: Die Softwareentwicklung boomte, Verdoppelung der Rechenleistung alle zwei Jahre hieß Verdoppelung der Produktivität eines Computers. Kein Ende in Sicht.

Aber: Im selben Zeitraum von 50 Jahren stieg die Produktivität im verarbeitenden Gewerbe nur noch um den vergleichsweise lächerlichen Faktor 4. Faktor 4 in 50 Jahren im Vergleich zu Faktor 2 in zwei Jahren heißt: Hardware ist Software als Wirtschaftsfaktor krass unterlegen. Auch deshalb sehen Autos heute noch so ähnlich aus wie der Opel Manta in den 70ern – während ein Großrechner der 70er Jahre heute in jede Smartwatch passt.

Aus dieser einfachen Betrachtung ergibt sich: Produktivitätssteigerung in großem Maßstab ist zukünftig nur noch durch Softwareentwicklung möglich. Und darum geht es in der Industrie: Gewinn aus Produktivität. Also muss die Autoindustrie heute von den Softwareentwicklern lernen – oder selbst Softwareentwickler werden. Und genau das tut sie.

Es dauerte vor dem Jahrtausendwechsel etwa 20 bis 30 Jahre, bis die Prinzipien schlanker Produktion von Toyota bis zu den letzten Zulieferern durchgedrungen waren. Unternehmen bauten ihre Firmen um eine schlanke Produktion herum auf, der sich alles unterzuordnen hatte. Und es dauerte ebenso 20 Jahre, seit dem „agilen Manifest“ Mitte der 90 Jahre, bis sich ähnliche Erkenntnisse überall in der Softwareentwicklung durchgesetzt hatten.

Nun kommt der entscheidende Quantensprung: Da Software zukünftig alles dominiert, müssen sich über kurz oder lang alle Unternehmen so aufstellen wie Softwareunternehmen. Sie müssen alles der Produktivität der Software unterordnen. Sie müssen Softwareunternehmen WERDEN.

Das meint auch der Microsoft CEO Satya Nadella ganz wörtlich, wenn er sagt: “Every company is a software company. You have to start thinking and operating like a digital company. It’s no longer just about procuring one solution and deploying one. It’s not about one simple software solution. It’s really you yourself thinking of your own future as a digital company.” Denn letzten Endes lässt sich jedes Geschäft durch einen Algorithmus abbilden.

Scrum, SAFe^® und Co: was steckt dahinter?

 Der Maschinenbauer (!) Ken Schwaber und sein Mitstreiter Jeff Sutherland entwickelten in den 1990ern die Scrum Methodik für die Softwareentwicklung und veröffentlichten mit 17 Kollegen im Jahr 2001 das „Agile Manifest“. Bis heute ist das agile Manifest die Grundlage aller agilen Frameworks. Es folgt einigen wenigen Prinzipien, die im Anhang dargestellt sind. Kernsatz: Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen. Ständig neue Wert liefern – das steht im Gegensatz zu der bisherigen Grunderfahrung von Autoentwicklern, dass ein Produkt mehrere Jahre Entwicklungszeit hat.

Die Quintessenz aller agilen Prinzipien heißt in etwa: „Redet viel miteinander, produziert Funktionen mit Wert in konstantem Tempo, in kleinen Inkrementen, vom einfachen zum schwierigen, lernt schnell, lasst das Team entscheiden, stellt die Menschen in den Vordergrund und räumt Ihnen den Weg von Hindernissen frei, damit sie ihre Kreativität entfalten können und durch Eigenmotivation weitgehend selbst organisiert arbeiten können.“

Und es funktionierte. Das Resultat: Eine Produktivitätssteigerung um bis zu 400 % war möglich und konnte in vielen Projekten – von Verteidigung über Raumfahrt bis hin zum Smartphone – bewiesen werden. Deshalb trägt die „Mutter aller Scrum Bücher“ von Jeff Sutherland den Titel „Scrum – The Art of doing twice the work in half the time.“ Nachdem Schwaber und Sutherland mit der Scrum-Methodik die Prinzipien des Manifests durch einfache Regeln auf Teamebene eingeführt hatten, stellte sich nach und nach die Frage, ob man nicht ganze Unternehmen, also Teams von Teams, besser und produktiver aufstellen kann.

Und die Lösung lag wieder bereits in der „lean“-Welt vor: Man verwandle ein ganzes Unternehmen in ein Kanban-System. Unternehmen als Management der Wertströme, mit Elementen aus dem Portfolio-Management, Kundenzentrierung, kontinuierlicher Auslieferung, Freigaben nach Bedarf und vielen agilen Teams. Das Scaled Agile Framework, auch SAFe^® genannt, war geboren. SAFe^® ist zwar nur eines der vielen Frameworks der skalierten Agilität, setzt sich jedoch zunehmend als ein Quasistandard durch. Auch die deutschen OEM setzen mittlerweile zunehmend auf SAFe^® in der Version 5 – und zwar nicht nur in der Softwareentwicklung.

Wann müssen Zulieferer lean-agile Frameworks einführen?

Hier einige Beispiele:

• Autohersteller verpflichten ihre Entwicklungslieferanten zunehmend, nach lean-agilen Methoden zu entwickeln, um sich in die OEM-eigenen Entwicklungsprozesse zu integrieren.
• Anfragen für Entwicklungsprojekte werden teils bereits nach dem agilen Festpreis gestellt, worin der Zulieferer unter Umständen noch keinerlei Erfahrung hat.
• Lastenhefte werden agil und enthalten damit weniger fixe Vorgaben. Sie beinhalten somit mehr Entwicklungsrisiken für Lieferanten.
• Es wird eine höhere Flexibilität und Geschwindigkeit in der Ressourcen-Allokation des Zulieferers vom OEM gefordert, sowohl in der Entwicklung als auch im operativen und Finanzbereich.
• Das Produktportfolio der Zulieferer muss sich immer schneller wechselnden Rahmenbedingungen von Gesetzgebern und Herstellern anpassen. Proaktives Portfolio-Management wird erforderlich, es löst damit Silo Strukturen ab, die bisher schnellere Fortschritte in Entwicklung, Vertrieb, Marketing und Business Development behindern.

Nicht alle „pain-points“ gelten für alle Unternehmen gleichermaßen. Eine spezifische Analyse ist wichtig und sollte durch erfahrene Experten durchgeführt werden.

Gibt es allgemeingültige Richtlinien für agile Zusammenarbeit?

Mit dem „VDA Red Book Agile Collaboration“ liegt seit kurzem eine umfassende Darstellung sinnvoller Prinzipien und Standards lean-agiler Zusammenarbeit vor. Siehe hierzu die Buchempfehlungen.

Wie kann sich unser Unternehmen besser auf die kommenden Veränderungen einstellen?

Aus obigen Überlegungen – in Verbindung mit den Herausforderungen von Klimawandel und Nachhaltigkeitszwang – ergibt sich eine logische Kausalkette an Aufgaben, ob für Autozulieferer, Maschinenbauer oder andere produzierende Unternehmen. Die Folgen äußern sich in Themen, die viele Hersteller und Zulieferer nicht länger ignorieren können, insbesondere wenn sie stark in Entwicklungsprozesse eingebunden sind:

• Mit endlichen Ressourcen leben – one planet – many individuals
• Die Softwaredominanz akzeptieren – every business is a software business
• Den agilen Kulturwandel einleiten – culture proves in building great things in half the time
• Von der Softwareentwicklung lernen – agile goes hardware development
• Indirekte Bereiche in den Wertschöpfungsprozess integrieren – lean goes indirect
• Lean Portfolio Management einführen – enterprise goes Kanban
• Von Zulieferern zu atmenden Netzwerken – business ecosystems im Mittelstand

Es bleibt spannend, denn das Veränderungstempo steigt.  Lean-agile Methoden sind nicht neu – aber in der Schlagkraft ein echter Paradigmenwechsel. Abwarten ist für Entwicklungsunternehmen keine Option.

Aktuelle Buchempfehlungen:

• VDA Agile Collaboration (2021)
• Pfannstiel/Siedl/Steinhoff. Agilität in Unternehmen. Springer Gabler (2021)

Anhang: die Prinzipien des agilen Manifests:

• Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
• Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
• Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
• Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
• Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
• Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
• Funktionierende Software ist das wichtigste Fortschrittsmaß.
• Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
• Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
• Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell.
• Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbst organisierte Teams.
• In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.