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