6. Januar 2017 / von Gregor Groß

Warum sind wir beim Entwickeln von Hardware agil?

Auf der agile PEP minds

Neulich war ich auf der agile PEP minds1. Ich habe dort gelernt, dass wir, was agile Hardware-Entwicklung angeht, schon richtig weit sind hier bei alpha-board. Nicht nur in einer Session kam die Frage auf, ob hybride Projektmanagement-Ansätze nicht die Zukunft seien, also eine Mischung beispielsweise von klassischem Wasserfall-Projektmanagement und agilen Vorgehensweisen bei der Hardware-Entwicklung.

Ich verstehe den Hintergrund der Frage: auf dieser Konferenz haben sich Leute getroffen, die für das Wort Produktentwicklungsprozess die Abkürzung PEP verwendenn2. Merke: Leute, die sowas abkürzen müssen, kommen aus großen Organisationen. Wir hier bei alpha-board sind so winzig, wir sagen von uns selbst, wir sind das Leerzeichen vor dem K in KMU. In diesen riesigen Organisationen hat man ganz, ganz viele Projekte, die paralell, nebeneinander, übereinander und durcheinander laufen. Wir bei uns haben nur ganz wenige Projekte nebeneinander. Von daher kümmern wir uns je nach Projekt auf verschiedene Arten um unsere Projekte, und zwar in der Art, die am besten passt. Aber wenn wir so groß wären wie die Organisationen, die ihre Leute auf die agile PEP minds geschickt haben, kann man sich diese Frage schon mal stellen:



Welches Projektmanagement passt den zu welchen Projekten?

Um herauszufinden, welcher Ansatz beim Projektmanagement der beste für Dich und Dein Projekt ist, braucht man sich eigentlich nur über zwei Dinge Gedanken machen:

  • Ist das zu lösende Problem bekannt?
  • Gibt es bereits eine Lösung dafür?

Ob das Problem bekannt ist oder nicht und die Lösung bekannt ist oder nicht, lässt sich in einer ganz einfachen Grafik auf zwei Achsen auftragen. Es entstehen vier Felder:



Wasserfall-Projektmanagement

Die bekannteste Art von Projektmanagement, der Wasserfall-Ansatz, passt am Besten für Problem: bekannt und Lösung: bekannt. Hier geht es um reines Implementieren, es sind keine Experimente gefragt. Alles ist bekannt, alles lässt sich planen.

Dies entspricht etwa der Aufgabe, ich solle für alle meine Leser eine Kartoffelsuppe kochen. Ich weiß, wie viele Leute zum Essen kommen. Ich weiß, wieviele Kartoffeln ich brauche und wann ich einkaufen und schälen sollte, um rechtzeitig was Kochendes auf dem Herd zu haben.

Leider sieht die Welt der Hardware-Projekte bei alpha-board nur in den allerseltensten Fällen so aus. Häufig lernen wir und unsere Kunden erst im Laufe des Projektes, was das Problem ist, und wie genau die Lösung aussieht, finden wir ohnehin erst während des Projekts heraus. Die meisten unserer PCB-Designs werden aber am besten so gemanagt3.



Die schlimmste Art des Vertriebs

Nehmen wir an, die Lösung sei bekannt, aber das Problem noch unbekannt bis gar nicht so richtig bekannt. Viele werden nun sagen, was soll das denn für ein Projekt sein? Aber die meisten Startup-Ideen fangen so an: man hat eine Lösung für etwas, weiß aber noch gar nicht so genau, wer die Kunden dafür sein sollen. Ingenieure entwickeln auch gerne sofort einen Prototypen und sind so verliebt in ihn, dass sie sich nie fragen, für wen das sein soll und in welcher Situation genau.

Dafür braucht man auch kein Projektmanagement, denn die Lösung ist ja bereits fertig. Dafür braucht man einen sturen, abgestumpften, aggressiven Vertrieb: ihr habt eine Lösung, aber wisst gar nicht, wer das Problem hat, das sie löst? Dann bleibt euch nur die Drückerkolonne: ihr rennt solange rum und geht allen auf den Geist, bis ihr zufällig was verkauft (vielleicht auch nur, weil jemand euch loswerden will).

Bezogen auf unsere Koch-Allegorie wäre das wie folgt: ihr seid alle eingeschworene Vegetarier und ich habe schon mal Rindertartar fertig. Außer wenn ich mit Gewalt drohe, könnte es ein wenig dauern, bis ihr zugreift, oder?



Agil!

Wenn das Problem bekannt ist, aber die Lösung unbekannt, dann habe ich vor mir einen Raum von Möglichkeiten, durch den ich mich schnellstmöglich durch-iterieren will. Genau in diesem Fall helfen agile Methoden viel besser als alle anderen Ansätze. Es geht um Geschwindigkeit, Offenheit und die Freiheit, zu experimentieren. Denn das globale Lösungsmaximum ist unbekannt, und nur durch schnelles Iterieren und Testen können wir es finden. Wir müssen schnell Prototypen für einzelne Funktionen oder alle Funktionen entwickeln. Diese Prototypen müssen schnell in die Hände von Kunden, oder noch besser: Nutzern, damit wir Feedback kriegen, ob wir in die richtige Richtung laufen. Und wenn nicht, schnell eine neue Richtung einschlagen und was anderes ausprobieren.

Nochmal: zum Iterieren im Lösungsraum brauchen wir Freiraum zum Experimentieren. Und es zählt Geschwindigkeit, bei uns und bei unseren Testern. Wir brauchen für agile Entwicklungsmethoden schnell Feedback. Wir verwenden agile Methoden für Hardware-Entwicklung.

Bei der Koch-Allegorie sieht es nun so aus, dass ich nicht für alle meine Leser einfach eine Kartoffelsuppe kochen soll, sondern etwas, das im Schnitt von allen Essern mindestens 8 von 10 Punkten auf einer Zufriedenheitsskala erreicht. Also koche ich verschiedene Mahlzeiten, anfangs vielleicht in Form eines Bufetts, und schaue, welche Dinge mehrheitlich ganz gut ankommen und welche nicht.



Problem unbekannt, Lösung unbekannt: wir entwickeln was ganz Neues!

Wenn das Problem unbekannt ist und die Lösung auch, dann hilft am besten Lean Startup / Design Thinking. Lean Startup ist ein Entwicklungsprozess für Startups, der agile Methoden und Customer Development vereint. Design Thinking ist ein Kreativprozess, der den Enduser in die Mitte der Entwicklung stellt und ihn/sie beobachtet und befragt, um erstmal das Problem ganz genau zu verstehen. Hat man bei beiden Prozessen, Lean Startup und Design Thinking, ein wirklich lösenswertes Problem gefunden, geht es weiter wie oben bei Problem bekannt, Lösung unbekannt - mit agilen Methoden, um Lösungen zu entwickeln, zu testen und zu validieren.

Wir können unsere Kunden auch bei diesen Projekten begleiten. Zum einen halte ich solche Workshops bereits, zum anderen profitieren auch die Entwickler davon, so früh im Projekt beteiligt zu sein und das Problem genau zu verstehen.

Beim Kochen wäre es so, dass ich für alle meine Leser deren jeweiliges Lieblingsessen kochen soll. Dazu sollte ich erstmal mit allen reden, um herauszufinden, was ihr jeweiliges Lieblingsessen ist.



Fazit

Und so einfach ist erklärt, wann welches Projektmanagement am besten passt. Wir nutzen Wasserfall fürs Managen unserer PCB-Designs und agile Methoden für die Hardware-Entwicklungsprojekte unserer Kunden. Drückerkolonne sind wir nicht gerne und Lean Startup / Design Thinking bieten wir gerne an, aber meistens sind unsere Kunden bei Beauftragung schon weiter.



Fußnoten:

  1. Auf der Webseite steht gleich als Erstes: Rulebreakers welcome!. Aber diesem Ruf ist niemand gefolgt, fand ich. So richtig agil war die Konferenz selber noch nicht.↩︎
  2. Anfangs dachte ich, das habe was mit dem ehemaligen Bayern-Trainer zu tun: Pep Guardiola.↩︎
  3. Nur, damit wir bei den Bearbeitern Fokus erzeugen, haben wir für unsere PCB-Designs ein Kanban-Board erzeugt. Das hilft, zu fokussieren, so dass jeder PCB-Designer auch nur an einem Projekt gleichzeitig arbeitet. ↩︎