Scrum und Hardware funktioniert nicht - scheint sich (immer noch oder wenigstens ab und an) als Mythos zu halten. Diese Art von Haltung kennen wir aus dem Bereich Scrum in Automobilbereich der Fall war oder noch früher mit Scrum selbst. In diesem Artikel möchte dir ich dir einige Startpunkte mit auf den Weg geben.
Scrum in der Hardware
Die Grundlage über "gute Entwicklungsprozesse", die Takeuchi und Nonaka 1986 in ihrem New New Product Development Game beschrieben hatten, sind bis heute gültig. Wer sich das Paper einmal genauer ansieht, wird feststellen, dass es hier nicht um Softwareprozesse ging, sondern um physische Produkte: Auto, Kamera, Kopierer. Das Paper wird auch als Quelle genannt, wenn es um das agile Framework "Scrum" geht. Die folgenden Kernelemente haben die beiden Japaner in sechs Kernthesen festgehalten:
Genau genommen sind diese Elemente inhärent in Scrum vorhanden und damit auch außerhalb der Software gültig. Was du nur jetzt tun musst, sind die Erkenntnisse auf deine Praxis von Scrum und Hardware zu transferieren.
Eine häufige Erkenntnis - gerade im Hardwarebereich - ist zum Beispiel, dass es keine selbstorganisierenden Teams gibt. Wenn du aktuell Entwickler betrachten, dann stellst du schnell fest, dass solche Teams einen sehr großen Anteil an erfolgreicher Entwicklung haben. Und dazu müssen Sie überhaupt keine Software entwickeln. Weitere Aspekte schauen wir uns später noch genauer an.
Als grundlegende Wissensquelle für Scrum in der Hardware kann dieses Paper für alle Interessenten nur wärmstens empfohlen werden.
Klarheit über Typische Fragen im Vorfeld klären
Es sind immer ähnliche Fragestellungen, die bei den Mitarbeitern und im Management auftauchen. Du kannst diese Fragestellungen im Vorfeld schon einmal angehen. Vor allem: Rede früh mit Kritikern und arbeite mit offenen Formate ehrlich über die Ansichten und Bedenken. Dann klappt es auch mit Scrum und Hardware!
Erfolgreiche Muster für Scrum in der Hardware
Grundlagen verstehen
Auch in der Hardware fängt der erste Schritt mit den Grundlagen an. Du musst die Kernelemente von Scrum verstanden haben und verinnerlichen. Dazu stehen natürlich verschiedene Möglichkeiten zur Verfügung, am effektivsten sind direkte öffentliche oder inhouse Scrum Trainings oder aber Online Scrum Kurse:
Dazu bietet es sich an, dass du dir bei der Auswahl der Trainer oder der Trainings auch daran orientieren, wie genau die Erfahrungen der Trainer sind.
Keine Softwaremuster kopieren
Wenn du die Software Produkte mit Scrum kennst, dann mache nicht den Fehler, die Praktiken aus der Software 1:1 für die Hardware kopieren zu wollen:
Teamgröße in der Hardwareentwicklung
Schauen wir in den Scrum Guide, in Studien von Jeff Sutherland und eigene Erfahrungen, dann sind die Teams häufig mit Scrum Master und Product Owner weniger als zehn. In den Studien von Jeff Sutherland sind die effektivsten Teams vier bis fünf Entwickler.
In der Hardware haben wir häufig typische Funktionen auf Personen verteilt, die wir alle brauchen. Beginnen wir mit dem Konstrukteur. Dann haben wir in der Regel je nach Produkt auch Elektronikentwickler, die sich Steuerung und Co kümmern. Hier findet sich oft der Fall, dass diese noch weiter spezialisiert sind und du mehrere davon in einem Team hast.
Wenn Sie elektronische Teile verbauen, dann haben Sie praktisch immer Leiterplatten (PCB), also Teile auf denen du elektronische Bauteile anbringst. Für diese Aufgaben findet sich auch ein Designer, Ingenieur oder Konstrukteur.
Werden Teile eingekauft, dann findet sich auch ein Einkäufer im Team, ein Test- und Qualitätsingenieur sind ebenso mit im Boot, wie vielleicht jemand von der Simulation.
Build-Measure-Learn
Ob du Lean Start-Up nun kennst oder nicht, wichtig für Scrum und Hardware ist es, dass du früh damit beginnst zu evaluieren, ob das, was du tust, das Richtige ist. Nutze Prototypenaufbauten mit Pappschachteln für Navigationsgeräte oder 3D Drucke für mechanische Wohnwagenparkhilfen, um sinnvoll, validierbare Erkenntnisse zu erlangen, die viele Kosten sparen und zur Entwicklung positiv beitragen.
Auf die Architektur achten
Nicht nur im Softwarebereich ist die Frage nach einer geeigneten Architektur eine häufig gestellte, sie gilt auch ganz besonders im Hardwarebereich.
Wer Wikispeed als Beispiel für agile Hardwareentwicklung nicht gelten lassen will, weil es eben doch nichts mit der deutschen Automobilindustrie zu tun habe, der kommt aber früher oder später bei dessen Architektur raus: Wikispeed ist von Anfang an so ausgelegt, dass sich die Hardware inkrementell weiterentwicklet werden kann. Die deutsche Automobilindustrie eher auf günstige Entwicklung.
Das macht die Software schon lange. Will ich konsequent die Ziele von Scrum, Flexibilität und Kundenzufriedenheit, erreichen, dann benötige ich genau so eine modulare Architektur.
So lange es geht virtuell bleiben
Halten die physische Arbeit so lange wie möglich "virtuell". Überlege immer, wie du ohne hohe Kosten, die Aufbauten und Produktionen verursachen, lange virtuell bleiben kannst.
Du kannst einen schnelles agiles, iteratives und inkrementelles Vorgehen durch CAD-Zeichnungen, Simulationen und ähnliche Techniken durchführen. Wenn du dann Erfahrungen machen konntest und am Besten auch noch aus dem komplexen Umfeld in das komplizierte oder gar einfache eintauchen kannst, wird auch die eigentlich Produktion oder der Aufbau günstiger und viel besser absehbar.
Kann Logik aus Hardware in die Software verlagert werden?
Je nach Produkt kannst du versuchen, dass die tatsächliche Komplexität in die Software zu verlagern. So kann Hardware generischer werden und vielleicht sogar mehrfach in anderen Produkten verwendet werden.
Das geht natürlich nicht immer, hängt auch wiederum sehr an der Architektur und muss natürlich auch abgewogen werden.
Achte auf regelmäßige Integration von Software und Hardware
Auch nicht ungewöhnlich für jeden Agilisten 😉 ist es natürlich immer eine häufige Integration von Software und Hardware. Auch wenn die Hardware vielleicht länger identisch bleibt und mehr Zyklen für ein neues Inkrement nutzt, darf das Gesamtprodukt nicht leiden. Und das erreichst du in der Regel nur, in dem du oft und regelmäßig versuchst sowohl die Software und die Hardware miteinander verbindest.
Auf die Scrum Werte fokussieren
Die Scrum Werte sind ein inhärenter Bestandteil von Scrum. Also auch dann, wenn du in der Hardware deine Produktentwicklungen durchführen möchtest. So oft ich auch in enttäuschte oder gelangweilte Gesichter schaue, wenn ich die Scrum Werte erwähne - sie sind zusammen mit agilen Prinzipien einfach essentiell wichtig.
Achte bei Scrum und Hardware darauf, dass du dir Gedanken über die Werte machst und diese auch interpretieren. Das tust du bitte immer im Team. Ebenso welche Bedeutung diese Scrum Werte für die Organisation haben, ist wichtig für ein gemeinsames Verständnis und zu klären.
Auf was es ankommt
Iterative und inkrementelle Entwicklung ist wichtig, auch für die Hardware. Eine implizite Annahme, die viele Menschen sofort treffen ist, dass nach jedem Sprint ein vollständiges System "lauffähig" sein muss. Nehmen wir einmal das erste Inkrement von Tesla. War das ein Auto? Nein, es war eine Webseite mit der Möglichkeit seinen Namen und Kreditkartennummer einzutragen. Dieses Inkrement (genau genommen ist es ein MVP - minimal viable product) finden Sie heute auch nicht in einem Tesla. Der Wert steht im Vordergrund.
Also verabschiede dich von der Annahme, dass nach zwei Wochen eine neue Einparkhilfe, eine Nockenwelle, ein Auto oder ein neues Tablet aus dem Sprint purzelt. Es gibt dort häufig (noch) physikalische Grenzen, die wir nicht übergehen können. Aber das ist auch nicht nötig.
Du kannst wertvolles Feedback und vor allem Mehrwert als Inkrement immer liefern.
