Denken wir für einen Augenblick an Spaghetti Bolognese oder Maultaschen mit Kartoffelsalat. Es gibt verschiedene Rezepturen, aber am Ende bleiben es die gleichen Gerichte. Hier findet sich die traditionelle Produktentwicklung wieder: Wird zum Beispiel ein Auto entwickelt, nutzen die Hersteller zwar verschiedene Motoren (Zutaten), aber letztlich bleibt es ein Fahrzeug mit Verbrennungsmotor (Gericht). Wer kennt gegrillte Wassermelone mit Bacon? Obwohl jeder die Zutaten kennt, hört sich die Kombination erst einmal ungewöhnlich an. Ähnlich ungewohnt fühlt sich die agile Entwicklung von physischen Produkten an. Agile Frameworks wie Scrum sind inzwischen State of the Art in der Softwareentwicklung. In der physischen Produktentwicklung geht es ebenfalls voran, im direkten Vergleich steckt die Hardware aber noch in den Kinderschuhen.Viele müssen sich erst an die Zutaten und die Zubereitung dieses Gerichts gewöhnen. Das Gute ist, man hat die Möglichkeit, das in kleinen Schritten zu tun. Der große Vorteil der agilen Produktentwicklung liegt genau darin, iterativ und inkrementell zu entwickeln. Wichtig ist nur, dass man diese ersten kleinen Schritte auch wirklich geht. Ich möchte mit Ihnen einige Erfahrungen teilen, die uns in agilen Hardware-Projekten immer wieder helfen.
Fangen wir mit der iterativen Produktentwicklung an. Wie schafft man es, alle zwei bis vier Wochen einen neuen Produktstand zu liefern? Lösen wir uns von dem Gedanken, dass ein "Produkt" ausschließlich immer etwas zum Angreifen sein muss und verstehen wir es stattdessen als einen Fortschritt. In der Hardwareentwicklung kann auch eine technische Zeichnung nach zwei Wochen eine Lieferung sein. Genauso gut kann der Einbau einer Komponente in ein bestehendes System eine neue Lieferung darstellen. Wenn man jetzt auch noch den Kunden bei der Vorstellung der Lieferungen einbezieht, fängt man schon an, sich im agilen Kontext zu bewegen.
Wie muss außerdem die Architektur eines Produkts aufgebaut sein? Prinzipiell kann eine Produktarchitektur vertikal oder horizontal geschnitten werden. Horizontal bedeutet, dass spezialisierte Teams für spezifische Produktentwicklungsschritte notwendig sind. Konstrukteure kümmern sich zum Beispiel nur um CAD Zeichnungen oder Qualitätsprüfer haben nur die Produktqualität im Blick. So entsteht eine Spezialisierung der Teams einerseits und Abhängigkeiten innerhalb der Produktentwicklung andererseits. Vertikale Architekturen ermöglichen hingegen, dass interdisziplinäre Teams ein Produkt von der ersten Skizze bis zum letzten Qualitätscheck für den Kunden umsetzen. Produkte können dadurch entkoppelt und die Abhängigkeiten innerhalb der Produktentwicklung verringert werden.Worauf muss man bei der Gestaltung der Schnittstellen achten? Bei Schnittstellen gilt: So wenige wie möglich, aber so viele wie nötig. Je weniger Schnittstellen ein Team zu anderen Modulen hat umso besser. Zusätzlich ist es sinnvoll, Schnittstellen klar zu definieren.Beispielsweise kann ein USB-Anschluss die Schnittstelle zwischen zwei Produkten sein. Dadurch entsteht für die Entwicklung eine Unabhängigkeit zwischen den Produkten.
Unabhängig von unseren bisherigen Erfahrungen geht es darum, herauszufinden, was im jeweiligen Unternehmens- bzw. Produktentwicklungskontext funktioniert. Im agilen Kontext heißt dieser Prozess "inspect and adapt". Man stellt fest, wo man sich gerade befindet und was bereits funktioniert (inspect). Anschließend werden die entsprechenden Maßnahmen für eine gewünschte Veränderung eingeleitet (adapt). Dabei spielt es im Übrigen keine Rolle, ob man diese Vorgehensweise im operativen oder strategischen Bereich einsetzt.Im täglichen Umgang mit agilen Entwicklungsframeworks bei Kunden treffen wir dabei anfänglich häufig auf Widerstand. Interessanterweise wandelt sich der Gegenwind nach einiger Zeit in eine positive Einstellung. Beispielsweise sind die Mitarbeiter über die regelmäßigen Lieferungen, die Unabhängigkeit und die neue Art der Zusammenarbeit erfreut - von der Freude über die Integration der Kunden im Review mal ganz abgesehen. Auch Entscheidungen werden transparenter und deutlich schneller getroffen als in der Vergangenheit. Spätestens wenn Mitarbeiter anfangen, die agile Produktentwicklung zu verteidigen, sind wir auf dem richtigen Kurs.Letztlich fängt alles bei Ihnen an. Entwickeln Sie Ihr eigenes Kochrezept, um Produkte agil zu entwickeln. Die ersten Zutaten gebe ich Ihnen gleich mit auf den Weg: Zu Beginn geht es darum, ein Bewusstsein für Agilität zu schaffen. Ideal ist es, ein Team aus Freiwilligen zu finden, die ein Pilotprojekt starten wollen. Trainings in Scrum oder Kanban gehören zu den Grundlagen und mit Unterstützung von außen fällt es manchmal leichter, die Prozesse aufzusetzen und zu etablieren. Zum Schluss würzen wir das Menü noch mit etwas Mut, schließlich kann auch mal etwas schieflaufen, aber das gehört dazu. Fehler helfen uns, neue Erfahrungen zu sammeln und die richtigen Entscheidungen zu treffen. Wenn wir wissen, worauf es bei Lieferungen, der Architektur und den Schnittstellen ankommt, schaffen wir den Rest auch noch. Packen wir es an.