Hard- und Software – zwei Seiten der gleichen Medaille

10/08/2018

Mit unseren IoT Produkten OilFox und Raumgold bewältigen wir täglich den Spagat zwischen agiler Hardware- und Software-Entwicklung. Das stellt uns vor große Herausforderungen! Oft kommen wir in die Versuchung, die Disziplinen zu trennen, doch wir widerstehen bisher sehr erfolgreich. Es lohnt sich, wie wir sehen werden!

 

Die eine Seite der Medaille

 

Lange Lieferzeiten, aufwendige Langzeittests, teure Serienwerkzeuge sowie langwierige Prozeduren zur Zulassung bei der Hardware-Entwicklung bereiten nicht nur unserem Management, sondern auch unseren Entwicklern schlaflose Nächte. Denn jeder Verzug bedeutet womöglich das Verschieben von Meilensteinen. Was für die Software kein Problem darstellt, ist für die Hardware typisch und erfordert enorme Anstrengungen: Das Einhalten und Verfolgen eines Zeitplans mit diversen Meilensteinen. Diese sind notwendig, um die Zusammenarbeit mit verschiedenen Lieferanten zu koordinieren. Produktionskapazitäten müssen geplant, Lagerplätze bereitgestellt und die Logistikkette aufeinander abgestimmt werden. Je später Änderungen am Produkt erfolgen, desto aufwendiger und teurer wird es, auch wenn sich das nie vermeiden lässt. Spätere Updates via Funk wie bei der Software sind leider keine Option.

 

Die andere Seite der Medaille

 

Software-Entwicklung dagegen braucht zwar eine Architektur und ein logisches Gesamtkonstrukt, die Entwicklung einzelner Funktionen und Features erfolgt jedoch meist in wenigen Wochen. Viele Änderungen können zudem nachträglich noch durchgeführt werden, nämlich über sogenannte Over-the-Air-Updates, spricht die Aktualisierung und Änderung der Software über Funk. Gerade weil es zwei Geschwindigkeiten sind, die dann im Produkt aufeinandertreffen und kaum zusammenzupassen scheinen, sind wir oft dazu verleitet, die Themen zu trennen. Ehe wir uns versehen haben wir zwei Teams, die unabhängig voneinander arbeiten, aber sich dennoch häufig synchronisieren müssen. 

 

Wozu würde die Trennung der Disziplinen führen?

 

Wir manifestieren die Trennung nach Disziplinen. Zwar wird Hardware immer mehr Mittel zum Zweck und ein Großteil der Wertschöpfung wird über die Software generiert. Unsere Produkte aber kennen keine Disziplinen und sollten das Gesamt-Optimum darstellen, nicht das Optimum einzelner Teilbereiche.

Zudem bauen wir kein interdisziplinäres Verständnis auf. Jede Disziplin versteht sich zwar untereinander, ein übergreifender Austausch findet aber nicht statt. Gerade andere, neue Perspektiven lassen geniale und häufig nicht offensichtliche Lösungen zu. Das ist ein entscheidender Erfolgsfaktor, wofür sich selbst eigene Vorgehen wie Design Thinking etabliert haben. Keine der Disziplinen kann ohne die andere. Haben Sie schon mal eine Software ohne Recheneinheit oder eine Hardware im IoT Bereich ohne Firmware oder Visualisierung gesehen? Eine Symbiose birgt enorme Vorteile (Pilz und Alge, Biene und Pflanze sind nur einige bekannte Beispiele), wenn sie konsequent zu Ende gedacht wird.

 

Wie behalten wir das Gesamtprodukt im Auge?

 

Alle Beteiligten der Hardware und Software für ein Produkt sind im gleichen Team, d. h. die Sprint Meetings werden gemeinsam durchgeführt. Nicht immer können alle gleichermaßen dazu beitragen. Doch die Probleme und Begrifflichkeiten werden geteilt und erzeugen, zumindest mit einem ausreichenden Atem, ein gemeinsames Verständnis. Fortschritte der Hardware werden genauso in den Sprints berücksichtigt und als User Story formuliert, um Anwender und Nutzen zu verdeutlichen. Wir visualisieren die klassischen Meilensteine der Hardware als Teillieferungen und machen Verschiebungen im Release Plan über die Anzahl der verschobenen Wochen (siehe rechts) sichtbar. Auf diese Weise haben wir Orientierungspunkte und sehen frühzeitig, wo Probleme auftreten. Für diese können wir dann gezielt nach Lösungen suchen. Zugleich bedeutet nicht jede Verschiebung sofort die Verschiebung größerer Teillieferungen. Wir können Veränderungen am Produkt vornehmen, um den gesetzten Endpunkt noch zu erreichen. Ganz nach der Ursprungsidee von Scrum und agiler Entwicklung („The New New Product Development Game“; Hirotaka Takeuchi und Ikujiro Nonaka in HBR 1986). Durch die Transparenz und stets aktuelle Sicht auf die Entwicklung erkennen wir, wo Stolpersteine versteckt sein könnten und ob ein Team demnächst Unterstützung braucht, um gewisse Lieferungen zu ermöglichen. Dann greifen sich die Teams unter die Arme und wir arbeiten alle gemeinsam daran als LIV-T erfolgreich zu sein.

 

Haben Sie Fragen zu unseren Produkten oder LIV-T? Hier geht es zu OilFox und Raumgold!

Share on Facebook
Share on Twitter
Please reload

Unsere Posts
Please reload

Tags
Please reload

Follow Us
  • YouTube Social Icon