Drücken Sie Enter, um das Ergebnis zu sehen oder Esc um abzubrechen.

Scrum in der Hardwareentwicklung: Legen wir los

Es wird viel darüber diskutiert, ob Scrum für die Entwicklung physischer Produkte geeignet sei.

Wikispeed zeigt uns bereits, dass es funktioniert: Das Unternehmen entwickelt ein komplettes Fahrzeug mit Hilfe verschiedener agiler Frameworks. Ziel ist es, das Fahrzeug in kleinen Inkrementen Stück für Stück weiterzuentwickeln. Das Zögern ist in der Hardwareentwicklung aber nach wie vor spürbar.

Was braucht es noch, damit es nicht mehr heißt: “Scrum funktioniert nur in der Software?“ Das Wichtigste ist wohl das Auflösen der engen Verbindung zwischen bestehenden Produktentwicklungsparadigmen und der klassischen Wasserfallentwicklung. Ein etabliertes Paradigma der Wasserfallentwicklung ist der Einsatz von Outsourcing-Strategien. Unternehmen haben dadurch ihre eigene Wertschöpfungstiefe so angepasst, dass ein Großteil der Wertschöpfung von Dienstleistern erbracht wird. Häufig werden sogar nur noch angelieferte Komponenten im letzten Schritt zusammengebaut. Der große Vorteil ist natürlich, dass man Kosten einspart, aber leider bleibt damit auch das Fachwissen über Technologien und Prozesse beim entsprechenden Dienstleister. Das ist ein Nachteil, wenn man die Möglichkeiten agiler Frames ganz ausschöpfen will. Einige Unternehmen haben das bereits erkannt und holen das notwendige Wissen wieder in die eigenen Reihen zurück.

Hardware ist Software

Bis vor einigen Jahren war der Anteil von Software in physischen Produkten relativ gering – die Gewinne hat man mit der Hardware gemacht. Dieses Verhältnis ändert sich aber im Zuge der Digitalisierung rasant. Fast in jedem technischen Produkt tickt heute ein kleiner Prozessor. Für die Zukunft heißt das: Die Gewinne werden immer stärker durch den Softwareanteil erzielt, die physischen Produkte wandeln sich zum Träger für die Software um.

Ein einfaches Beispiel: In der Vergangenheit beurteilten potenzielle Autokäufer die Fahrzeuge nach Kriterien wie Fahrzeugsicherheit, Komfort oder Verbrauch – für die Software im Fahrzeug haben sie sich kaum interessiert. Heutzutage stellen Kunden ganz andere Anforderungen an ein Fahrzeug. Kann ich mein Smartphone mit dem Fahrzeug verbinden? Habe ich Internet im Fahrzeug? Besteht die Möglichkeit, später neue Softwarefeatures in das Fahrzeug zu integrieren? Welche Fahrfunktionen kann das Fahrzeug für mich übernehmen? Der Begriff Internet of Things macht deutlich, in welche Richtung wir uns bewegen.

Konstruktionsprinzip Dopplung

Dass die Software zum bestimmenden Bestandteil eines Produkts wird, wirft völlig neue Fragen auf, die man bei der Entwicklung physischer Produkte berücksichtigen sollte: Wie muss künftige Hardware beschaffen sein, um der Software Flexibilität und Performance bieten zu können? Wie schafft man es, physische Produkte schneller zu entwickeln? Eine Idee dazu ist das Konzept der Microservices, also kleine, entkoppelte Komponenten oder Module, die unabhängig voneinander funktionieren. Dadurch entstehen eigenständige Systeme und ggf. Funktionsdopplungen an verschiedenen Stellen im Produkt. Ja, richtig gelesen: Es gibt mehr Funktionen als eigentlich benötigt werden. Dazu muss man im Vorfeld entscheiden, wo solche Dopplungen überhaupt notwendig sind.

Wie kann das in der Praxis aussehen? Schauen wir uns dazu die Karosserieentwicklung eines Fahrzeugs an. Viele Einzelteile bilden am Ende die gesamte Karosserie. Die Karosserie ist der Träger unzähliger Komponenten, die später in das Fahrzeug eingebaut werden und sie ist unter anderem maßgeblich für die Sicherheit der Insassen verantwortlich. Eine Option ist das gedankliche Zerlegen der Karosserie in drei Teile: Vorderwagen, Fahrgastzelle und Heckwagen. Jedes dieser Module muss nun eigenständig die Aufnahmepunkte für einzubauende Produkte (bspw. Sitze, Lautsprecher, Motor) bereitstellen und die Sicherheit des Fahrzeugs gewährleisten. Dies ist aber nur eine mögliche Variante. Betrachten Sie Ihr Produkt in Ihrem Kontext und finden Sie heraus, wie sich solche Ideen bei der Produktentwicklung integrieren lassen.

Die Möglichkeiten für eine agile Entwicklung physischer Produkte stehen bereits zur Verfügung. Die Frage ist, ob Unternehmen sich überhaupt verändern wollen. Diskutiert wird viel – über Digitalisierung, Industrie 4.0 und Disruption. Aber ist die Dringlichkeit überhaupt groß genug für eine Veränderung? Viele Unternehmen warten noch ab, manche versuchen es zumindest einmal mit einem Digital Incubator.

Wir dürfen uns nicht auf dem ausruhen, was wir bereits erreicht haben, das sind die Lorbeeren von gestern. Schließlich wollen wir auch in Zukunft vorne mitspielen. Im Zuge der globalen Entwicklung haben wir den Start in Deutschland zwar verpasst – Unternehmen wie Tesla, Apple, Google und viele Startups liegen bereits eine Nase vorn. Angesichts der aktuellen Wirtschaftslage können wir den Rückstand aber aufholen. Lasst uns den Rückenwind nutzen, um etwas Neues auszuprobieren! Alles, was es dazu braucht, ist bereits vorhanden. Wir müssen nur noch den Mut haben, zuzugreifen.

  • surfguard

    Eine der Grundlagen agiler Entwicklung ist das Paper „The New New Product Development Game“, in dem auch der Begriff „Scrum“ zum ersten Mal eingeführt wird – dort noch als Metapher aus dem Rugby und nicht als Name eines Frameworks. (https://hbr.org/1986/01/the-new-new-product-development-game)

    Die Produkte, aus deren Entwicklung die Autoren des Papers ihre sechs Prinzipien ableiten, die heute noch alle agilen Methoden zugrunde liegen, sind:
    „- FX-3500 medium-sized copier (introduced by Fuji-Xerox in 1978)
    – PC-10 personal-use copier (Canon, 1982)
    – City car with 1200 cc engine (Honda, 1981)
    – PC 8000 personal computer (NEC, 1979)
    – AE-1 single-lens reflex camera (Canon, 1976)
    – Auto Boy, known as the Sure Shot in the United States, lens shutter camera, (Canon, 1979)“

    Das sind alles anfassbare Produkte! Es sollte also keine Frage sein, ob Scrum in der Hardwareentwicklung möglich ist. Es ist schon seit Jahrzenhten bewiesen, dass es geht. Die Hardwareentwicklung war sogar Vorbild!

    Man darf nur nicht meinen, dass die Einführung von Scrum keine Veränderung bedeutet oder dass nicht andere Arbeitsweisen entwickelt werden müssen. Objektorientierte Methoden, automatisiertes Testing, Deployment-Frameworks und andere Werkzeuge mussten auch erst entwickelt und etabliert werden, um die Softwareentwicklung agiler machen zu können.