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?

Agile Toolbox
Produktentwicklung
Hardware
Scrum
bgloger-redakteur
July 7, 2014

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst
BG

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst

Wer die Zukunft voraussagen will, muss sie gestalten
BG

Wer die Zukunft voraussagen will, muss sie gestalten

Die etwas andere agile Bücherliste.
BG

Die etwas andere agile Bücherliste.

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!
BG

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!

Scrum organisiert am Produkt entlang
BG

Scrum organisiert am Produkt entlang

Trainings verändern - oder sie sind wertlos!
BG

Trainings verändern - oder sie sind wertlos!

Zertifizierung – Das ist hier die Frage
BG

Zertifizierung – Das ist hier die Frage

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind
BG

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind

Organisationsentwicklung am Produkt entlang
BG

Organisationsentwicklung am Produkt entlang

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung
BG

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung

Speed kills – oder rettet?
BG

Speed kills – oder rettet?

Weniger ist mehr – der Upstream ist zu managen
BG

Weniger ist mehr – der Upstream ist zu managen