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:

Die transformative Kraft spielerischer Methoden in agilen Transformationsprozessen
BG

Die transformative Kraft spielerischer Methoden in agilen Transformationsprozessen

Agile Produktentwicklung und Product Ownership – Warum werden Produkte immer noch klassisch aufgesetzt?
BG

Agile Produktentwicklung und Product Ownership – Warum werden Produkte immer noch klassisch aufgesetzt?

Scrum by the book - Die Power agiler Prinzipien
BG

Scrum by the book - Die Power agiler Prinzipien

Organisieren für das Dringliche – oder der Verlust des Wesentlichen
BG

Organisieren für das Dringliche – oder der Verlust des Wesentlichen

Agile im Jahr 2025: Die Weiterentwicklung einer bewährten Methode
BG

Agile im Jahr 2025: Die Weiterentwicklung einer bewährten Methode

Statt einer Rezension – OKR als Rezept
BG

Statt einer Rezension – OKR als Rezept

Strategie als Praxis: Wie Sie Ihre Organisation nachhaltig transformieren
BG

Strategie als Praxis: Wie Sie Ihre Organisation nachhaltig transformieren

Scrum als Motor für Wissenstransfer und kontinuierliches Lernen
BG

Scrum als Motor für Wissenstransfer und kontinuierliches Lernen

Scrum als Treiber von Diversität und Inklusion: Innovation durch Vielfalt
BG

Scrum als Treiber von Diversität und Inklusion: Innovation durch Vielfalt

FRAGE: Warum macht ihr eigentlich kein SAFe®?
Boris Gloger

FRAGE: Warum macht ihr eigentlich kein SAFe®?

FRAGE: Was würdet ihr Kund:innen raten, die mit denselben Herausforderungen, wie BG sie aktuell hat, zu euch kommt?
Boris Gloger

FRAGE: Was würdet ihr Kund:innen raten, die mit denselben Herausforderungen, wie BG sie aktuell hat, zu euch kommt?

FRAGE: Wie wird darüber entschieden, welche:n Berater:in wir bekommen? Können wir die Berater:innen vorher kennenlernen?
Boris Gloger

FRAGE: Wie wird darüber entschieden, welche:n Berater:in wir bekommen? Können wir die Berater:innen vorher kennenlernen?