Agile Hardwareentwicklung mit Scrum

Die Hammerfrage in jedem Training: Macht Scrum jenseits der Softwareentwicklung Sinn? Die Skeptiker führen als Paradebeispiel gerne den Brückenbau an. Ihr Argument: Das Stück-für-Stück-Bauen, wie es in der Software möglich ist, gehe beim Brückenbau und ähnlich "harten" Produkten sicher nicht.Der Skepsis gegenüber Scrum liegt die Vorstellung zu Grunde, dass agile Entwicklung wie puzzeln sei: Wir suchen uns die einzelnen Teile aus, fügen sie zusammen - und schauen dann, ob das Gesamtbild stimmig ist.

Dabei wird allerdings übersehen, dass auch schon in der Software das vorausschauende Planen im Mittelpunkt steht: Das Product Backlog sollte bereits in den ersten Sprints möglichst vollständig sein. Das Team sollte alle User Stories regelmäßig schätzen und so schon früh einen Überblick über das gesamte Produkt bekommen. Abhängigkeiten und Constraints sollten sichtbar gemacht werden. Und die Entwickler sollten natürlich eine grobe Architektur im Kopf haben, um das Produkt vom Ergebnis her zu denken.

Von Brücken und Schaltplänen

In einem unserer derzeitigen Projekte baut ein Scrum-Team Hardware um. Bevor wir unsere Unterstützung zusagten, haben wir eine Frage gestellt: "Geht es um einen routinierten Umbau oder um eine tatsächliche Neuentwicklung?" Scrum bringt nämlich wenig, wenn keine großen Überraschungen zu erwarten sind. In solchen Fällen reicht ein gut durchdachter, erfahrungsgesättigter und zigmal abgesicherter Fahrplan.In der Neuentwicklung hingegen sind viele Unbekannte im Spiel: Warum ändern wir etwas? Was will der Kunde damit erreichen? Welchen Nutzen versprechen wir uns davon? Mit wie vielen Lösungen wollen wir ins Spiel gehen? Was kommt neu dazu, was ist bisher noch gar nicht ausprobiert worden? Wo lauern Sackgassen? Was sollte zuallererst angegangen werden?Die größte Schwierigkeit in diesem Hardware-Projekt war das Schreiben von User Stories. Laufende Funktionalitäten sind bei Software und auch bei Firmware am Ende von Sprints möglich - in der Hardware sieht es etwas anders aus. Bis wir ein funktionierendes Stück Elektronik in der Hand halten, müssen verschiedene Entwicklungsstufen durchlaufen werden, die Monate dauern: Vom Design zum Schaltbild, vom Schaltbild zum Schaltplan, vom Schaltplan zum Layout. Dann kann die erste Leiterplatte in Auftrag gegeben, mit Elektronik bestückt und schließlich als Prototyp in Betrieb genommen werden.Es ist zwar möglich, bereits in den ersten Sprints embryonale Prototypen zu basteln, die das spätere Produkte sehr grob wiedergeben. Wichtiger ist jedoch die Erkenntnis, dass die Planung in der Hardware einen noch größeren Stellenwert als in der Software einnimmt. Ein Schaltplan erfüllt bereits die Erwartung, alle Funktionalitäten darzustellen, die das Gerät in Zukunft haben soll. Ein Umbau in den späteren Phasen führt dazu, dass alle Stufen erneut durchlaufen werden müssen.

Are you getting the picture?

Gerade in der agilen Hardwareentwicklung macht es deshalb Sinn, User Stories als Bilder unterschiedlicher Schärfe zu sehen: Bereits die ersten Bilder stecken das gesamte Feld ab. Sie sind keine Puzzleteile, sondern versuchen bereits, den gesamten Funktionszusammenhang zu erfassen.

Allerdings sind sie noch recht schwammig: Vieles ist noch in der Klärung - es geht erstmal darum, herauszufinden, was machbar ist und Sinn ergibt. Die späteren Bilder werden immer präziser - Muster und Konturen werden erkennbar, Details gewinnnen an Schärfe. Der Entscheidungspfad weist immer weniger Abzweigungen auf. Gegen Ende halten wir schließlich das in Silikon gegossene Produkt in der Hand und hoffen, dass nach Inbetriebnahme die Elektronik so fließt, wie sie fließen soll.Die Lieferung am Ende eines jeden Sprints besteht dann meistens nicht in der Vorführung einer laufenden Funktionalität, sondern in der Präsentation von Bildern und Klärungsergebnissen. Unser Team hat zum Beispiel im letzten Sprint herausgefunden, dass sein Produkt mit zwei Kabelstandards funktionieren könnte, aber nur einer davon Sinn macht (der andere ist gegenüber Interferenzen nicht robust genug). In einem anderen Sprint hat es ein Schaltbild zusammen mit einer Liste möglicher Funktionalitäten geliefert - zusammen mit der Empfehlung, ob der jeweilige Einbau Sinn macht oder nicht.All das sind Lieferungen, die in die beste Tradition von Review-Meetings passen: Sie geben den Stakeholdern (Benutzer, Kunde, Produktmanagement, Sales, Vertrieb) die Möglichkeit, den Entwicklungsprozess zu verfolgen und in Form von Feedback mitzugestalten.Nota bene: Spannenderweise dachten Takeuchi und Nonaka vor 26 Jahren beim Wort "Scrum" nicht an Software, sondern an die Enwicklung von Kopierern, Autos und Fotokameras. 1986 schrieben sie in "The New New Product Development Game" über die Vorteile interdisziplinärer Teams, die einen klar abgesteckten Auftrag erhalten und sich dann, ausgestattet mit größtmöglichen Freiheiten, an die Arbeit machen.