Warum agile Hardware-Entwicklung Sinn macht
3. Juni 2025Stell dir vor: Du entwickelst ein innovatives, vernetztes Gerät, ein embedded system oder IoT-Device, mit viel Soft- und Hardware dabei – aber während dein Softwareteam in zweiwöchigen Sprints neue Funktionalitäten umsetzt, hängt die Hardware monatelang im Entwicklungs-, Layout- und Inbetriebnahme-Prozeß und kommt über Prototypen-Level nicht hinaus. Die Software kann nicht live getestet werden, bis die Prototypen laufen. Alles erfolgt sequentiell und im Geheimen.
Was dabei verloren geht? Geschwindigkeit, Flexibilität und letztlich Marktchancen.
Und Zufriedenheit geht auch verloren, denn das haben sich anfangs alle anders vorgestellt, vom Team bis zum Management und den Kunden.
Trotzdem haben agile Methoden die Softwarewelt im Sturm erobert, soweit, dass agil dort schon Bestandteil des Studiums ist. In der Hardwareentwicklung dagegen herrscht oft noch Stillstand: viele Teams arbeiten mit Prozessen, die eher an die 1990er erinnern. Warum? Häufig hört man:
„Hardware ist hard – das geht bei uns nicht anders.“
Geht Hardware agil zu entwickeln?
Die Wahrheit ist: moderne Produkte sind längst keine reine Hardware oder reine Software mehr. Sie sind Systeme – komplexe Verbindungen aus Sensorik, Logik, User Interface und Vernetzung. Ein intelligenter Haushaltshelfer, ein Medizinprodukt oder ein smartes Industriebauteil – sie alle vereinen physische Hardware-Komponenten mit eingebetteter Software.
Don't go chasing waterfalls ... (Lyrics von Waterfalls, TLC)
In einem solchen Umfeld hilft klassische Phasenplanung kaum weiter. Was heute funktioniert, kann morgen schon überholt sein – sei es durch technologische Sprünge oder sich immer schneller wandelnde Nutzerbedürfnisse. Agile Hardware-Entwicklung hilft insbesondere in Fällen mit hoher Ungewissheit bei technischen Anforderungen oder Zustimmung aller Stakeholder (aber auch nicht immer, wenn beide gleichzeitig ungewiss sind).
Vorteile agiler Hardware-Entwicklung
Deshalb brauchen gerade Projekte mit viel Soft- und Hardware drin, die heutzutage immer öfter auftreten, agile Denkweisen: interdisziplinäre Teams, kurze Lernzyklen, schnelles Feedback. Es geht nicht darum, blind Scrum zu übernehmen, sondern Agilität als Haltung zu verstehen: als Bereitschaft, Unsicherheit aktiv zu gestalten – nicht auszusitzen. Und zügig durch den Raum der möglichen Lösungen zu iterieren, mit schnellen Prototypen, weitestgehender Automatisierung, Transparenz im Team und nach außen, mit offenen Formaten und Modularisierung von Hard- und Software.
Unser Fazit: Agilität in der Hardware ist nicht nur möglich, sie wird zur Notwendigkeit. Wer heute noch zögert, riskiert den Anschluss an Innovationsdynamiken.
Aktuelle Probleme beim agilen Entwickeln von Hardware
Das ist zumindest der Eindruck, den wir haben: es gibt kaum erfolgreiche Projektbeschreibungen von agiler Hardware-Entwicklung. Nun gibt es aber auch nicht besonders viele Projektbeschreibungen von anderen Entwicklungen. Aber weil es kaum Berichte von erfolgreichen Projekten gibt, hält sich die Mär, es gab auch noch nie erfolgreiche Projekte.
Glaubt mir, agil Hardware entwickeln im Team ist leichter als eine Leiterplatte zu zeichnen.
Wenn wir in Projekten tätig sind, die agil Hardware entwickeln wollen, sind uns schon einige Probleme aufgefallen. Da die Hardware komplexer scheint, wird sie häufig zuerst fertig gestellt, was sequentielle Abarbeitung bedeutet. In den Teams wird zwar Arbeits- und Wissensteilung gepredigt, aber alle benutzen proprietäre Dateiformate in teuren Programmen, die nur sie selber lizensiert haben (z.B. für Stromlaufplan und Layout Altium statt einem offenen Tool wie KiCAD). Diese teuren Programme erzeugen Experten, die dann als einzige wichtige Prozess-Schritte übernehmen und somit gleich zu Flaschenhälsen werden, dem genauen Gegenteil, weshalb wir überhaupt gemischte Teams haben wollen. Auch beliebt: alle ausser dem Agile-Team bleiben nicht-agil, vom Chef über den Einkauf beispielsweise. Es gibt noch viel mehr Probleme, auf die wir noch zurück kommen.
In einer losen Serie von Blogposts 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 noch in Arbeit und ist eine Zusammenarbeit von: