Scrum in der Hardware - eine Zwischenbilanz

Als Takeuchi und Nonaka 1986 den Artikel "The New New Product Development Game" veröffentlichten, fiel das Wort "Scrum" zum ersten Mal im Kontext der Produktentwicklung. Dort ging es nicht um Softwareapplikationen, sondern um Kopierer, Fotokameras und PCs. Dennoch stand die Blütezeit von Scrum ganz im Zeichen der Softwareentwicklung: Das Rahmenwerk, das wir heute kennen, entstand in den 1990er und frühen 2000er-Jahren.Allmählich wird Scrum für die Hardwareentwicklung wieder entdeckt. Das ist kein Zufall: Die Entwickler von Hardwareprodukten stehen heute vor ähnlichen Herausforderungen wie die Softwareentwicklung Anfang der 1990er Jahre. Unternehmen in der Medizin- oder Messtechnik, die vor einem Jahrzehnt mit einer handvoll innovativer Produkte die Marktführerschaft erobert haben, müssen wieder einmal vorangehen. Doch dieses Mal sind die Vorzeichen andere: Ihre Produkte verkaufen sich mittlerweile in der ganzen Welt und die Konkurrenz ist in der Lage, die Produkte aus dem Katalog in kurzer Zeit nachzubauen und preislich zu unterbieten. Um die Marktführerschaft zu erhalten, müssen Unternehmen am Ball bleiben.Am Ball zu bleiben wird umso schwieriger, je erfolgreicher das Unternehmen ist. Denn Wachstum bedeutet häufig auch, dass selbständig agierende, kleine Teams einer übegreifenden Abteilungs- und Projektstruktur weichen müssen. Wie können innovative und zuverlässige Produkte entstehen, wenn ganze Entwicklungsabteilungen vor sich hin arbeiten, die dann auch noch mit QA, Fertigung, Einkauf, Produktmanagement und Vertrieb in Einklang zu bringen sind?Scrum bietet mit seinem Augenmerk auf selbstorganisierte Einheiten, in denen das Wissen der Abteilungen im Mikrokosmos eines Teams gebunden ist, eine erfrischende Alternative zu herkömmlichen Produktentstehungsprozessen. Wie aber sehen die bisherigen Erfahrungen mit Scrum in der Hardwareentwicklung aus? Es ist Zeit, eine Zwischenbilanz zu ziehen.

Eine Mannschaft aufstellen, die alle Positionen beherrscht

Für die erfolgreiche Lieferung eines Hardwareprodukts braucht es nicht nur Spezialisten für Software, Hardware und Konstruktion. Zulieferer, Fertigung und QA können entscheidende Beiträge leisten, wenn es um die richtige Auswahl von Bauteilen oder um geeignete Produktionsverfahren geht. In Scrum haben wir den Vorteil, dass wir jeden dieser Spezialisten völlig unbürokratisch in jene Sprints mit einbinden können, in denen ihr Wissen gefragt ist. Diese sind dann z.B. Teil des 15-minütigen Daily Scrums und können darin selber Aufgaben übernehmen. Je früher sie eingebunden werden, desto überflüssiger werden die üblichen zeit- und kostenintensiven "Nachbesserungsrunden" vor (und häufig sogar nach) dem Produkt-Launch.

Was bringt die Software ohne das Gehäuse?

Gerade in der Hardwareentwicklung können leicht "Paralleluniversen" entstehen. Der Konstrukteur baut sein Gehäuse, der Hardware-Entwickler seine Platine. Erst spät fällt auf, dass beides nicht so richtig zusammenpasst, weil z.B. die Bohrungen für die Befestigungen den Bestückungsraum für die Platine einschränken. Oder weil die vorgesehene Lichtleiterkonstruktion Dichtigkeitsprobleme beim Ausschäumen hervorrufen könnte. Wenn das Wissen um diese Abhängigkeiten im Team vorhanden ist, können die Inkremente auf Komponenten-Ebene (Gehäuse, Platine) zu einem Inkrement auf Produkt-Ebene zusammengeführt werden. Das Team stellt dann im Sprint Review einen Stand des Produkts vor, der bereits aus verschiedenen Perspektiven (Konstrukteur, HW-Entwickler, Fertiger) verifiziert worden ist.

Die richtige Lösung für das richtige Problem

Wenige Unternehmen sind es gewohnt, Kunden und User zu ihren Sprint Reviews einzuladen. Am Ende entstehen so Produkte, die ein Problem lösen, das der Kunde so gar nicht hat. Dabei kann gerade in der Hardwareentwicklung mit einfach Mitteln (3D-Drucker, virtuelle Modellierung) ein sehr konkretes Bild des künftigen Produktes vermittelt werden. Dafür braucht es einen Product Owner, der direkte Anbindung an den Markt hat (und nicht nur auf die Anforderungen des Vetriebs angewiesen ist), den Kunden mit einer eigenen Vision führen kann (anstatt ihn zu fragen, was er denn haben möchte) und in die Stärken seines Entwicklungsteams vertrauen kann. So können die Reviews genutzt werden, um das Produkt durch Kunde und User validieren zu lassen und so möglichst früh Weichenstellungen in der Entwicklung durchzuführen.

Über den Sprint hinausschauen

In der Softwareentwicklung messen wir den Durchsatz an entwickelten Funktionalitäten pro Sprint, um die Geschwindigkeit des Teams zu bestimmen. In der Hardwareentwicklung müssen wir anders vorgehen, da die Laufzeiten bis zur Fertigstellung einer Funktionalität länger sind. So sind mehrere Entwicklungsschritte (z.B. Platzstudie, Stromlaufplan, Layout, PCB) erforderlich, bis eine Funktionalität (z.B. das Auslesen von RFID-Tags) fertig ist. Deshalb bauen wir das Product Backlog auf zwei Ebenen auf:

  1. Auf der Feature-Ebene sind die Funktionen des Produkts aus Benutzersicht mit ihren Rahmenbedingungen beschrieben (z.B. das Auslesen und Beschreiben von Datenträgern mit einer bestimmten Geschwindigkeit und Leseabstand).
  2. Auf der System-Ebene sind die Entwicklungsschritte innerhalb der verschiedenen Disziplinen (Konstruktion, Hardware, Software) beschrieben, die zum Erreichen der gewünschten Funktionalität erforderlich sind. Wir ermitteln die Geschwindigkeit auf dieser zweiten Ebenen (wie viele Entwicklungsschritte schafft das Team pro Sprint), um die Dauer bis zum Erreichen der ersten Ebene (fertig gestellte Funktionalitäten) zu ermitteln. Hierbei ist die Berücksichtigung von harten Abhängigkeiten (wann läuft die Entwicklung leer, weil sie z.B. auf Lieferungen der Software angewiesen ist?) wichtig, um eine rechtzeitige Einplanung in die Sprints zu ermöglichen.

Scrum ist seinerzeit angetreten, um Unternehmen, die sich in Entwicklungsphasen und Abteilungsdenken verzettelt hatten, wieder lieferfähig zu machen. Mit Scrum haben wir ein vergleichweise leichtes Regelwerk, das durch kurze Iterationen und interdisziplinäre Teams den Augenmerk auf eine zuverlässige Integration des Produkts bei einer klaren Ausrichtung am Markt legt. Nirgendwo ist dieser Bedarf dafür aktuell größer als in der Hardwareentwicklung.Whitepaper Scrum in der HardwareentwicklungTipp: Am 10.2.2015 diskutieren wir von 16 bis 17 Uhr in einem Webinar über Scrum in der Hardwareentwicklung. Unsere Gäste sind Claus Höhn, Entwicklungsleiter der Business Unit Identification bei Balluff GmbH und Christoph Wehe, Product Owner bei Thermo Fisher Scientific Inc. Alle Infos dazu gibt es hier

Agile Toolbox
Produktentwicklung
Hardware
bgloger-redakteur
January 21, 2015

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?