.st0{fill:#FFFFFF;}

Scrum Einführung

Scrum und Hardware: So startest du!

 Februar 23, 2018

von  Sebastian Schneider

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:

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

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!

  • 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 agile Prinzipien und Werte fokussiert werden. Es stellt grundsätzlich aber kein Problem dar.
  • 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 gemeinsamer Planung. Auch hier kannst du oft schnell Erfolge erreichen, wenn du nur die Hausaufgaben machst.
  • Du kannst auch frühes Feedback erzeugen, das wenig kostet. Experimentiere mit Pappschachteln, 3D Druck, Knetmasse, gehe zum Konstrukteur in die Werkstatt, visualisiere und spreche früh und regelmäßig über die Entwicklung, Lernen 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. 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:

  • Lerne die Events in Scrum kennen und verstehe den Inhalt dieser. Auch für deine Implementierung brauchst du genau diese Events.
  • Begreife, was die Rollen für Rechte und Pflichten haben und übertrage dieses Konzept auf deinen Kontext.
  • Was für Artefakte gibt es in Scrum und wie passen diese auf deine Situation? Wie kannst du Sie diese interpretieren und in deine Praxis überführen?

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:

  • 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 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.

  • Mut
  • Respekt
  • Offenheit
  • Commitment
  • Fokus

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.

  • Baue ein Team von Mitarbeitern auf, die zusammen das Produkt entwickeln. Überlege welche Disziplinen du alle benötigst und bilde Sie dann ein entsprechendes Team, befähige dieses Team selbst Entscheidungen zu treffen. Selbstermächtigung und -organisation ist das Stichwort. Die wenigsten Teams im Hardwarebereich sind (tatsächlich) so aufgestellt!
  • Überlege, wie schnelles Feedback für das Produkt generiert werden kann. Auch wenn die Hardware nicht Software ist, kannst du mit 3D Druck, Simulationen oder simplen Prototypenaufbauten früh Meinungen und Ansichten von Stakeholdern reflektiert werden.
  • Schaffe Transparenz in dem du alles über den Projektverlauf zeigen, was du kannst. Wo steht das Produkt, wo klemmt es und wie kann schnell Abhilfe erfolgen.
  • Nutze Retrospektiven um dich schnell neuen Herausforderungen stellen zu können. Wo muss was getan werden, damit du Probleme im Prozess beseitigst, effizienter und schneller arbeiten kannst, wie hältst und motivierst du Mitarbeiter?

Sebastian Schneider

Ein paar Worte über den Autor

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

Sebastian Schneider CSP-PO
Sebastian Schneider CSP
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Hole dir auch den kostenlosen Online Scrum Kurs

>