Quick Wins für agile Hardware-Entwicklung
Teil 3 der Serie: Status Quo agile Hardware-Entwicklung Ganze Serie
"I have not failed. I've just found 10,000 ways that won't work." — Thomas Alva Edison
Am 29.10.2025 habe ich zusammen mit Dr. Tobias Kästner von inovex Gmbh einen Vortrag über Agile Hardware-Entwicklung: Status Quo auf der Konferenz Power of Electronics (hervorragend organisiert von Elektronik-Praxis) im wunderschönen Würzburggehalten. Hier findet ihr Teile unserer Präsentation, die mit gamma.app erstellt wurde. Für die wunderschönen Ukiyoye-Bilder habe ich Gemini von Google physisch in einem Nebenzimmer manifestiert und ihn/sie/es dann gezwungen, mir diese Bildchen zu malen. Los geht's:
Status Quo bei agiler Hardware-Entwicklung: Linear entwickeln in einer nicht-linearen, dynamischen Welt? Warum klassische Vorgehensweisen öfter scheitern als man denkt und agil einfach besser ist.
Viele Hardware-Entwicklungen folgen noch immer linearen Prozessen – in einer Welt, die längst vernetzt, digital und schnell ist. Wir zeigen, warum klassische Vorgehensweisen an ihre Grenzen stoßen und wie agile Prinzipien helfen, schneller zu lernen, besser zu liefern und näher am Kunden zu entwickeln.
Wir analysieren typische Hindernisse – kulturell, organisatorisch und technisch – und geben konkrete Impulse, wie Unternehmen agil starten können: mit gemischten Teams, iterativer Planung, modularer Architektur und mehr Transparenz.
Unser Fazit: Agile Hardware ist kein Nice-to-have – sondern ein entscheidender Erfolgsfaktor für zukunftsfähige Produktentwicklung.
- Dr. Tobias Kästner: Solution Architect Medical IoT bei inovex GmbH, einem führenden Dienstleister für die digitale Transformation mit Full-Stack Technologiekompetenz von Cloud bis Deep Embedded.
- Gregor Groß: Geschäftsführer alpha-board gmbh, einem Berliner Dienstleister für agile Hardware-Entwicklung, PCB-Design und Fertigungsservice.
Die Präsentationsteile über den Status Quo und Woran es hapert lasse ich weg, denn die haben wir bereits in unserer Blogserie Status Quo in agiler Hardware-Entwicklung ausführlich beschrieben.
Wichtig ist noch, zu verstehen, dass agil vorzugehen in bestimmten Situationen besonders gut ist. Wir haben das mal in dieser Graphik dargestellt:
Wenn man nicht viel weiß, was möglice Endanwender mögen oder wollen, und wenn man auch noch nicht viel über die zu verwendenden technologischen Lösungen weiß, dann passen agile Vorgehensweisen immer gut, um schnell durch den Raum der Lösungen zu iterieren. Ist beides bekannt, kann man agil vorgehen, muss aber nicht. Ist beides Neuland, ist agil u.U. auch nicht besonders gut geeignet, denn dort wohnt Chaos und Drachen und so Zeugs.
Quick Wins für den agilen Start
Uns fallen einige Ansätze ein, um euren agilen Start in die Hardware-Entwicklung zu verbessern:
- Rahmenbedingungen
- Agil Arbeit organisieren
- Arbeit in Iterationen
- Arbeitsplanung mit User Stories
- Mehr Transparenz
- Agile Architektur und Design
Gehen wir das der Reihe nach durch.
Quick Wins: Rahmenbedingungen
Der Rahmen muss passen, sonst wird das nichts mit agil. Diese Punkte sind wichtig:
- Motivation für agil sein muss vorhanden sein
- gemeinsames Verständnis (z.B. Grundlagen-Training für alle, auch die Chefs?)
- Begleitung durch Agile Coach
- passende Projekte!
Quick Wins: Arbeit agil organisieren
Das Ganze kann nur klappen, wenn sich ein agiles Team agil selbstorganisiert. Dafür müsst ihr folgende Voraussetzungen erfüllen:
- interdisziplinäre Teams (move work to people)
- crossfunktional, um alle Fähigkeiten im Team
- enge Zusammenarbeit im Team statt nach außerhalb
- Fokus auf ein Projekt statt mehrere
- stabile Teams (fürs Wachsen innerhalb des Teams)
Quick Wins: Iterieren leicht gemacht
Wichtig ist das zügige Iterieren des Teams durch seine Ideen und technischen Umsetzungen derselben. Auch hierzu ein paar Tipps:
- Kleine Schritte statt detailliert
- Iterationsgetriebenes SCRUM
- Plan, Do, Check und Act ist sehr wichtig (insbesondere Check und am liebsten durch Endanwender)
- Facilitation durch Agile Coach (auf jeden Fall von außen, denn die von innen werden fast immer zerrieben)
- Kontinuierliche Verbesserung und Feedback
Quick Wins: Arbeitsplanung mit User Stories
SCRUM verlangt User Stories. Die sind aus Sicht des Endanwenders zu formulieren und sollen dem Team vermitteln, um was es den Endanwendern geht. Wir müssen also vorher mit Endanwendern reden, logisch, oder? Und das Ganze dient auch dazu, testen zu können, ob wir die gewünschte Funktionalität liefern. Der Fokus ist also von Anfang an auf Endanwender-Bedürfnissen und auf dem Testen:
- Fokus auf Endanwender
- Fokus auf Nutzen
- Test gleich mit definieren
Das Standardformat für User Stories lautet:
Als
möchte ich folgende <Funktionalität>, um folgenden zu erreichen.
Beispiele für User Stories:
Als Biochemiker:in kann ich am Prototyp eine Pumpe vorwärts und rückwärts laufen lassen, um die Probe zwischen Mischkammer und Messkammer hin- und herzubewegen.
Als Biochemiker:in kann ich die Pumprate einstellen, um die Probe erst schnell in die Mischkammer fliessen zu lassen und dann langsam zurück in die Messkammer.
Als Biochemiker:in kann ich die Temperatur der Probe mit einer Auflösung von einem Grad messen, um die Temperatur bei der Berechnung der finalen Konzentration berücksichtigen zu können.
Quick Wins: Mehr Transparenz
Damit agile Arbeit im Team Erfolg hat, ist Transparenz wichtig. Denn das Team organisiert ja seine Arbeit selber. Da wollen wir ja nicht, dass alle anderen denken, die sitzen nur rum. Wichtig sind also:
- Product Backlog (mit priorisierten User Stories und Architektur-Stories)
- Roadmap (für Aussagen zur Zukunft)
- Kanban-Board (für aktuellen Takt, in dem das Team arbeitet)
- Teilen von Information im Team, mit Partnern, Lieferanten
- Automatische Dokumentation (denn wenn die nicht automatisch läuft, wird sie wieder auf später verschoben)
Quick Wins: Agile Architektur und Design
User Stories kümmern sich ja nur um Funktionalität, die sich die Endanwender wünschen. Natürlich gibt es auch Stories, die wir liefern müssen, um all die User Stories zu liefern. Das betrifft u.a. die Architektur unserer Elektronik, denn manches dort ist nur dafür da, damit wir überhaupt User Stories liefern können, wie z.B. Speicher, Busse, Stromversorgung etc.
- Flexible Architektur
- Plug-and-Play-Design (also lieber mehrere kleiner Boards mit separaten Aufgaben als ein riesiges Board mit allem drauf)
- Modulare Kapseln
- Automatisiertes Verschmelzung von Modulen
- Durchgängig
Zumindest am Anfang lohnt es sich, mehrere kleiner Boards statt einem großen zu benutzen. Denn wenn es nur ein großes gibt, neigen die Teams dazu, das wirklich vollzupacken. Und große Boards sind deutlich komplexer als mehrere kleine. Die kleinen Boards könnte man auch wieder verwenden, im nächsten Projekt. Und auch bei Software geht das gut, wenn man z.B. Zephyr OS benutzt.
Wie es weiter geht
Im nächsten Teil reden wir dann über weitere, noch viel konkretere Tipps zum Umsetzen agiler Hardware-Projekte.
Dies ist Teil 3 unserer Serie über agile Hardware-Entwicklung. Hier findest du alle Artikel der Serie. In einer losen Serie wollen wir zeigen, wo wir aktuelle Probleme sehen und welche Lösungen wir schon gefunden haben. Die Inhalte sind aus einem Whitepaper abgeleitet, an dem wir mitgewirkt haben. Das Whitepaper ist fertig und ist eine Zusammenarbeit von: