Scrum in der Hardware: So starten Sie!

​Scrum in der Hardware scheint sich als eine Art Trend und Mythos zu halten, wie es vor noch gar nicht langer Zeit auch mit Scrum in Automobilbereich der Fall war und noch früher mit Scrum selbst. Da ich auch mit Scrum in der Hardware mittlerweile durchaus positive Erfahrungen gemacht habe, finden Sie hier ein kleines Starterset​, das Sie zur Reflexion nutzen können.

​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 den Begriff "Scrum" geht. Die folgenden Kernelemente haben die beiden Japaner in sechs Kernthesen festgehalten:

  • ​Built-in instability
  • ​Self-organizing project teams
  • ​Overlapping development phases
  • ​“Multilearning”
  • ​Subtle control
  • ​Organizational transfer of learning

​Genau genommen sind diese Elemente heute inhärent in Scrum vorhanden und damit auch außerhalb der Software gültig. Was Sie nur jetzt tun müssen, sind die Erkenntnisse auf Ihre Praxis von Scrum in der Hardware zu transferieren.

Eine häufige Erkenntnis - gerade im Hardwarebereich - ist zum Beispiel, dass es keine selbstorganisierenden Projektteams gibt. Wenn Sie ​heute Entwicklungsteams ​betrachten, dann stellen Sie 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.

​Typische Fragen im Vorfeld beantworten

Fragen zu Scrum in der Hardware

​Es sind immer ähnliche Fragestellungen, die bei den Mitarbeitern und im Management auftauchen. Sie können diese Fragestellungen im Vorfeld schon einmal angehen. Vor allem, reden Sie früh mit Kritikern und arbeiten Sie mit offenen Formate ehrlich über die Ansichten und Bedenken. Dann klappt es auch mit Scrum in der Hardware!

  • check
    ​Ja, das erstellen von Inkrementen dauert grundsätzlich länger, als in der Software. Da muss der eine oder andere Manager gedanklich noch seine Hürden überwinden und ein Anwender auf die Grundlagen für Prinzipien und Werte fokussiert werden. Stellt grundsätzlich aber kein Problem dar.
  • check
    ​Nein, auch existierende Hardware Entwicklungen sind in der Regel nicht optimal. Oft fehlt es an elementaren Grundlagen, wie cross-funktionale Teams, miteinander häufig und zielführend kommunizieren oder auch an gemeisamer Planung. Auch hier können Sie einfach ansetzen.
  • check
    ​Doch, Sie können auch frühes Feedback erzeugen, das wenig kostet. Experimentieren Sie mit Pappschachteln, 3D Druck, Knetmasse, gehen Sie zum Konstrukteur in die Werkstatt, visualisieren Sie und sprechen Sie früh und regelmäßig über die Entwicklung und Erkenntnisse.

​Erfolgreiche Muster für Scrum in der Hardware

Grundlagen verstehen

​Auch in der Hardware fängt der erste Schritt mit den Grundlagen an. Sie müssen die Kernelemente von Scrum verstanden haben und dieses 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:

  • ​Lernen Sie die Events in Scrum kennen und verstehen Sie den Inhalt dieser. Auch für Ihre Implementierung brauchen Sie dann genau diese Events.
  • ​Begreifen Sie, was die Rollen für Rechte und Pflichten haben und übertragen Sie dieses Konzept auf Ihren Kontext.
  • ​Was für Artefakte gibt es in Scrum und wie passen diese auf Ihre Situation? Wie können Sie diese interpretieren und in Ihre Praxis überführen

​Dazu bietet es sich an, dass Sie sich bei der Auswahl der Trainer oder der Trainings auch daran orientieren, wie genau die Erfahrungen der Trainer sind.

Keine Softwaremuster kopieren

Wenn Sie die Software Projekte mit Scrum kennen, dann machen Sie nicht den Fehler die Praktiken aus der Hardware 1:1 kopieren zu wollen:

  • ​Ein Inkrement in der Software ​muss nicht identisch ​mit einem Inkrement in der Hardware sein. In ​den meisten Fällen ist es das auch nicht.
  • ​Scrum in der Hardware erstellt nicht so oft "lauffähige" Systeme, wie das die Software tut. Das liegt alleine daran, dass physikalische Aufbauten deutlich teurer sind, als Software zu kompilieren und auf ein Gerät zu spielen.
  • ​Trotzdem kann Hardware auch regelmäßgen Mehrwert liefern, der zum Lernen und für Feedback hilfreich und wichtig ist!

​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 Sie mehrere davon in einem Team haben.

Wenn Sie elektronische Teile verbauen, dann haben Sie praktisch immer Leiterplatten (PCB), also Teile auf denen Sie elektronische Bauteile anbringen. 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 Sie Lean Start-Up nun kennen oder nicht, wichtig für Scrum in der Hardware ist es, dass Sie früh damit beginnen zu evaluieren, ob das, was Sie tun, das Richtige ist. Das klingt trivial, aber es kann häufig schon mit einfachen Prototypenaufbauten, mit Pappschachteln ​für Navigationsgeräte oder 3D Drucke für mechanische Wohnwagenparkhilfen darstellen, sinnvoll sein Erkenntnisse zu erlangen, die viele Kosten sparen und zur Entwicklung beitragen.

Auf die Architektur achten

Modulare Architektur bei Scrum in der Hardware

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.

Auf die Scrum Werte fokussieren

Die Scrum Werte sind ein inhärenter Bestandteil von Scrum. Also auch dann, wenn Sie in der Hardware Ihre Projekte durchführen. 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.

  • ​Mut
  • ​Respekt
  • ​Offenheit
  • ​Commitment
  • ​Fokus

Achten Sie auch bei Scrum in der Hardware darauf, dass Sie sich Gedanken über die Werte machen und diese auch interpretieren. Das tun Sie immer im Team und auch welche Bedeutung diese Scrum Werte für die Organisation haben, ist wichtig für ein gemeinsames Verständnis.

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 verabschiedenen Sie sich 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. Sie können viele Dinge innerhalb eines Sprints tun, bei denen Sie Scrum unterstützt.

Sie können aber wertvolles Feedback und vor allem Mehrwert als Inkrement immer liefern.

  • ​Bauen Sie ein Team von Mitarbeitern auf, die zusammen das Produkt entwickeln. Überlegen Sie welche Disziplinen Sie alles benötigen und bilden Sie dann ein entsprechendes Team, befähigen Sie dieses Team selbst Entscheidungen zu treffen. Selbstermächtigung und -organisation ist das Stichwort. Die wenigsten Teams im Hardwarebereich sind so aufgestellt!
  • Überlegen Sie, wie schnelles Feedback für das Produkt genenriert werden kann. Auch wenn die Hardware nicht Software ist, können mit 3D Druck, Simulationen oder simplen Prototypenaufbauten früh Meinungen und Ansichten von Stakeholdern erreicht werden.
  • ​Schaffen Sie Transparenz in dem Sie alles über den Projektverlauf zeigen, was Sie können. Wo steht das Projekt, wo klemmt es und wie kann schnell Abhilfe erfolgen.
  • angle-double-right
    Nutzen Sie Retrospektiven um sich schnell neuen Herausforderungen stellen zu können. Wo muss was getan werden, damit Sie Probleme im Prozess beseitigen, effizienter und schneller arbeiten können, wie halten und motivieren Sie Mitarbeiter?

Leave a Reply 0 comments

Leave a Reply:







>