Skalierte Hardware-Entwicklung - Interview mit Matthias Wolf

Matthias ist einer unserer Hardware-Spezialisten und arbeitet in den großen internationalen Projekten zum agilen Arbeiten. Besonders wichtig ist ihm dabei, dass Entwickler viel Zeit mit dem Produkt verbringen dürfen und durch häufiges Prototyping wieder mehr Freude an ihrer Arbeit haben.BG: Matthias, inwiefern sind Hardwareprojekte anders als Softwareprojekte? Worauf musst du als Coach besonders achten?Matthias: Zunächst einmal gibt es mehr mentale Hürden zu überwinden. Oft werden wir mit der Ansicht konfrontiert, dass “das hier nicht geht” und Scrum überhaupt nur in der Software-Entwicklung funktioniere. Dabei waren die meisten frühen agilen Projekte vor allem Hardware-Entwicklungen: Kameras, Kopierer, sogar Autos. Wichtig ist, nicht zu versuchen, die bekannten Praktiken und Vorgehen aus der Software-Entwicklung eins zu eins auf die Hardware-Entwicklung zu übertragen, sondern vielmehr die dahinter stehenden Prinzipien zu beachten. Im Kern geht es doch darum, dass ein Team Ergebnisse liefert und sich und die eigene Arbeit ständig hinterfragt. Das ist in der Hardware genauso sinnvoll und wichtig.Eine andere Besonderheit ist, dass das “Bauen” tendenziell immer noch länger dauert als bei Software - da ist es oft ja nur mehr ein Knopfdruck. Und auch wenn mit Werkzeugen, wie 3D-Druckern, Laser Cuttern und CNC-Fräsen, die Bauzeiten immer weiter reduziert werden können, ist man von “Sekunden” noch ein Stück entfernt. Feedback dauert dadurch einfach länger. Aus diesem Grund ist es umso wichtiger, dass man sich auf die aktuell wichtigsten Themen fokussiert und offene Fragen möglichst schnell durch kleine, schnelle Prototypen und die damit gewonnenen Daten beantwortet. Oft reicht dafür aber auch eine Skizze, eine Simulation, ein CAD-Modell oder ein Aufbau aus LEGO oder Styropor.Die Entwickler müssen viele der Möglichkeiten auch erst kennenlernen, da die meisten Tools gerade erst entwickelt werden. Continuous Deployment war in der Software-Entwicklung vor einigen Jahren völlig undenkbar, heute ist das ganz normal - auch wenn es noch nicht jeder nutzt. Ähnlich wird es in der Hardware-Entwicklung sein. Ein Beispiel: Ein Werkzeug, das ich auch nutze, ist https://iotify.io/ Mit virtuellen Sensoren und Netzwerken kann man jetzt schon Internet of Things-Produkte in kürzester Zeit entwickeln und dann schnell Realität werden lassen. Da tut sich in den nächsten Jahren noch einiges.BG: Wie siehst du das: Wie hilfreich ist Scrum auch bei großen Projekten und weshalb? Welche Vorteile hast du mit Scrum gesehen?Matthias: Gemeinsame Planungen und Reviews über das gesamte Projekt rufen bei Entwicklern immer viel Begeisterung hervor. Endlich haben sie einen Gesamtüberblick und sehen, was die anderen Teams machen. Und sie erkennen, warum sie tun, was sie tun. Leider erkenne ich auch die Tendenz, dass Manager diese gemeinsamen Termine als Zeitverschwendung betrachten.Gerade zu Beginn wird das Projektziel hinterfragt: Warum machen wir das Projekt? Was wollen wir erreichen? Warum tun wir das überhaupt? Eine Frage, die ich immer wieder stelle: Muss das Projekt überhaupt so groß sein? Kann man sich nicht auf bestimmte Funktionalitäten oder Märkte konzentrieren und so einiges an Komplexität aus dem Projekt nehmen? Leider ist es oft noch so, dass man immer alles will und alles gleichzeitig. Damit macht man sich und den Entwicklern das Leben aber unnötig schwer. Große Projekte benötigen mehr Menschen und das erhöht den Kommunikationsbedarf. Strukturierte Kommunikation über das gesamte Projekt hinweg wird umso wichtiger. Meistens scheitern Projekte nicht an technischen Problemen, sondern an mangelnder Kommunikation oder der Erkenntnis, dass der Kunde das Produkt gar nicht braucht. Gerade da sind Scrum oder Vorgehen wie Lean Startup besonders hilfreich.BG: Du bist sehr in der Lean Startup Community aktiv. Was macht diese Community aus? Welche Ideen heckt ihr da so aus?Matthias: Generell ist die Bereitschaft, Risiken einzugehen und Fehler zu machen, deutlich höher. Ein Fehler ist keine Schande, sondern eine wertvolle Erfahrung auf dem Weg zu einem erfolgreichen Produkt. Gleichzeitig versucht man aber auch, durch kluges Vorgehen das Risiko zu reduzieren. Oft kann man nämlich Annahmen schon im Vorfeld sehr einfach überprüfen und verhindern, dass man Zeit in sinnlose Entwicklungen steckt. Es ist spannend zu sehen, mit wie viel Energie und Einfallsreichtum die Leute an teilweise verrückte Ideen rangehen. Genauso schnell sehen sie aber auch ein, wenn etwas nicht funktioniert und ein Projekt eingestellt werden muss. Diese Bereitschaft, auch mal zu sagen “Das war jetzt nix!”, ohne gleich einen Schuldigen zu suchen, wünsche ich mir auch in etablierten Unternehmen.BG: Gibt es eine Besonderheit, die man bei agilen Hardware-Projekten im skalierten Umfeld beachten muss?Matthias: Interdisziplinäre Teams, die sich häufig am Gesamtprodukt treffen, sind besonders wichtig; die Idee ist aber auch schwerer zu vermitteln. Die Distanz zwischen einem Konstrukteur und einem Firmware-Entwickler, vor allem in der Geisteshaltung, ist oft größer als zwischen einem Frontend- und einem Backend-Entwickler. Deshalb ist räumliche Nähe durch gemeinsame Projekträume und Büros sehr hilfreich.Die Modularisierung des Produkts und die Standardisierung von Komponenten hilft, schnelle Iterationen zu ermöglichen. Dafür ist es auch notwendig, Schnittstellen abzustimmen, gegen die entwickelt werden kann. So kann in einem Sprint ein Modul weiterentwickelt werden, ohne das Gesamtprodukt neu erfinden zu müssen. Oder mehrere Teams können unabhängig an mehreren Modulen arbeiten. Nach wie vor sind Änderungen an der Hardware immer noch teuerer als an Software. Wenn man dem Produktteam jedoch verständlich machen kann, dass Änderungen nicht schlecht sind und man sie am besten von Anfang an vorsieht, steht einem erfolgreichen Produkt wenig im Weg.BG: Lieber Matthias, ich danke dir für unser Gespräch. Ich wünsche dir weiterhin viel Erfolg für deine Projekte.

Wer mehr über das Skalieren erfahren möchte, dem empfehle ich mein neues Buch: "Scrum Think b!g - Scrum für wirklich große Projekte, viele Teams und viele Kulturen".