Drei Argumente für Scrum in der Hardware

Als Takeuchi und Nonaka vor bald 30 Jahren das Wort "Scrum" für Produktentwicklung in den Mund nahmen, dachten sie an alles außer Software. Ihre Referenzen waren 3M, Canon und Fujitsu - allesamt Hersteller von physischen Produkten. Und doch stand die Jahrtausendwende ganz im Zeichen der agilen Softwareentwicklung.In den letzten Jahren beobachten wir eine Trendwende. Unternehmen in hoch innovation Branchen wie Medizintechnik, Automobil oder Sensorik und Messtechnik stellen auf agile Entwicklung um. Der Grund dafür liegt auf der Hand - diese Unternehmen stehen vor ganz ähnlichen Problemen wie die Softwareentwicklung damals:

• Die Entwicklungsgesschwindigkeit kann mit dem Veränderungstempo am Markt nicht mehr mithalten. Früher konnten Konzepte monatelang ausgearbeitet, bewertet und dann wieder überarbeitet werden. Bis die Entwicklung anfing, konnte viel Zeit ins Land gehen. Heute gilt: Je früher sich ein Konzept als unmachbar erweist, desto besser. Deshalb setzt Scrum auf die Verifikation des Designs innerhalb von kurzen Iterationen, etwa anhand von Prototypen oder virtueller Integration der Baugruppen. Indem Konzept und Entwicklung Hand in Hand gehen, können Holzwege schnell identifiziert werden - das technische und fachliche Risiko wird nach der Devise "fail early and often" ganz zu Beginn angegangen.
• Außerhalb der Projektwelt gibt es die wirkliche Welt - und diese hat die dumme Eigenschaft, sich nicht immer an Lasten- und Pflichtenheft halten zu wollen. So enstehen selbst spät im Projekt noch neue Anforderungen, die viele Seiten eines sorgfältig ausgearbeiteten Konzepts obsolet machen können. Mit Scrum machen wir das anders: Das Product Backlog listet alles auf, was für das Produkt gebraucht wird. Auch die Rahmenbedingungen (z.B. die Größe des Gehäuses, die Anzahl der Buchsen oder der Preis) sind dort bisweilen akribisch genau fest gehalten. Und dennoch ist das Product Backlog kein abschließendes Dokument. Alles, was zu Beginn noch nicht geklärt sein muss, wird bewusst offen gelassen, um es dann vor der Implementierung im Detail festzulegen. Kommen also neue Anforderungen dazu, die die Rahmenbedingungen nicht wesentlich verletzen und auch keine größeren Umbauten erfolgen, sind Änderungen ein leichtes Ding: Das Backlog enthält einen neuen Punkt, der dann zur gegebenen Zeit mit dem Team spezifiziert wird.
• In einem Punkt sind die Softwareentwickler uns voraus: Durch Testautomatisierung auf Systemebene können sie jede Veränderung sofort auf ihre Auswirkungen für das Gesamtsystem prüfen. Das ist in der Hardware schwieriger. Dort werden Modifikationen häufig nur modular getestet - erst zum Schluss, wenn Änderungen am Prototypen kaum noch bezahlbar sind, ist das Verhalten des Gesamtsystems verifizierbar. Scrum sagt hierzu: Suche dir ein Team, das gemeinsam in der Lage ist, das Produkt in nur zweiwöchigen Iterationen selbständig weiter zu entwickeln. Das bedeutet, dass ein Entwickler auch Konstrukteur sein muss - und umgekehrt. Das bedeutet auch, dass Mechanik und Elektronik Hand in Hand arbeiten müssen, damit sie das Zusammenspiel der Komponenten in Echtzeit verifizieren können. Ähnlich eng muss die Verzahnung zwischen Firmware und Elektronik bzw. Hardware sein. 3D-Drucker und Fräsmaschinen erlauben die schnelle Herstellung von Prototypenteilen. Mit Open Source Hardware kann schon heute auf eine Reihe von existierenden Designs für Testzwecke zurück gegriffen werden. Das agile Hardware-Labor ist eine der großen Herausforderung für Scrum in der Hardware.

Literatur:Takeuchi, Hirotaka und Nonaka, Ikujiro: The New New Product Development Game. Harvard Business Review, January February 1986.http://www.visionmobile.com/blog/2014/02/learned-built-hardware-agile-way/Wer hat Angst vorm ersten Wurf?