Agile Hardware Development beginnt nicht mit einer neuen Organisation.

In den vergangenen Monaten hat mich eine Frage rund um agile Hardwareentwicklung besonders beschäftigt.

Ein Transformationsansatz, an dem ich mitgearbeitet habe, wurde am Ende nicht so umgesetzt, wie wir ihn ursprünglich gedacht hatten.

Eine Erkenntnis daraus ist mir aber geblieben:

Agile Hardware Development beginnt nicht mit einer neuen Organisation. Es beginnt damit zu verstehen, wie Wert tatsächlich durch das Engineering fließt.

In vielen Transformationen sieht der erste Schritt zunächst sehr vertraut aus:

• Neue Rollen

• Neue Teams

• Neue Meetings

• Neue Planungszyklen

Aus bisherigen Planungsformaten werden PI Plannings. Teams arbeiten in Sprints. Features werden geplant, Abhängigkeiten visualisiert und regelmäßig diskutiert.

Auf dem Papier verändert sich viel.

Nur eine entscheidende Frage bleibt manchmal unbeantwortet:

Kommt dadurch auch das Produkt schneller und besser beim Kunden an?

Gerade bei physischen Produkten ist das keine triviale Frage. Hardwareentwicklung bringt längere interne und externe Lead Times, Abhängigkeiten zwischen unterschiedlichen Engineering-Disziplinen sowie die Notwendigkeit einer echten Systemintegration mit sich. Forschung zu Agile Hardware Development beschreibt genau diese Besonderheiten.

Das Problem ist dabei nicht PI Planning, Scrum oder SAFe.

PI Planning ist beispielsweise dafür gedacht, Teams auszurichten, Abhängigkeiten sichtbar zu machen und gemeinsam vorauszuplanen. Auch aktuelle SAFe-Guidance für Hardware geht deutlich über Meetings und Teamstrukturen hinaus und adressiert Digital Engineering, Systems Engineering und kürzere Lern- und Feedbackzyklen.

Das Problem entsteht, wenn wir die Einführung eines Frameworks mit der Transformation des Engineering-Systems verwechseln.

Denn bevor wir fragen, wie Teams organisiert werden sollen, sollten wir verstehen:

• Wie entsteht im Engineering heute eigentlich Wert?

• Wo wartet Arbeit?

• Wo entstehen Übergaben?

• Wo bleiben Entscheidungen liegen?

• Welche Abhängigkeiten verhindern echten Flow?

• Wo entstehen Engineering Changes – und warum?

• Wie schnell können wir die Auswirkung einer Änderung verstehen, validieren und umsetzen?

Diese Fragen verändern die Perspektive.

Plötzlich optimieren wir nicht mehr darauf, dass jeder möglichst beschäftigt ist, sondern darauf, dass Wert möglichst schnell durch das Gesamtsystem fließt. – Ein wichtiger Unterschied.

Queueing Theory zeigt schon grundsätzlich, warum maximale Auslastung und maximale Geschwindigkeit nicht dasselbe sind: Je näher ein System an seine Kapazitätsgrenze kommt, desto stärker können Warteschlangen und Durchlaufzeiten wachsen. Auch im Lean Product Development werden Waiting, Handoffs, Rework und Überlastung deshalb als zentrale Quellen verlorener Zeit betrachtet.

Vielleicht sollten wir deshalb weniger fragen:

„Wie gut sind unsere Engineers ausgelastet?“

Und häufiger:

„Wie lange wartet eine Engineering-Aufgabe eigentlich darauf, dass es weitergeht?“

Genau hier wird Systems Engineering für uns zentral und zwar nicht als weitere Rolle in einem neuen Organigramm, sondern als Möglichkeit, Requirements, Funktionen, Architektur, unterschiedliche Engineering-Domänen, Integration und Validierung als zusammenhängendes System zu betrachten.

Das entspricht auch dem Grundgedanken von Systems Engineering: Nicht einzelne Teile zu optimieren, sondern das Gesamtsystem und insbesondere die Beziehungen zwischen seinen Elementen zu verstehen.

Ein besonders spannender Einstiegspunkt dafür sind aus meiner Sicht Engineering Changes.

Ein Change läuft häufig quer durch das gesamte Unternehmen. Von der Anforderung bis zur Fertigung.

Verfolgt man einen solchen Change End-to-End, wird sehr schnell sichtbar, wo Informationen fehlen, Entscheidungen warten, manuelle Übergaben entstehen oder Auswirkungen auf andere Komponenten nur schwer ermittelt werden können.

Aktuelle Forschung zu MBSE zeigt beispielsweise, wie miteinander verknüpfte System- und Domänenmodelle Impact Analysen unterstützen, Änderungen automatisiert überprüfen und Feedbackschleifen erheblich verkürzen können - Das ist für uns echte Engineering Agility:

Nicht einen Change schneller durch ein Board zu bewegen, sondern das Engineering-System so zu gestalten, dass es einen Change schneller verstehen, bewerten und umsetzen kann.

Besonders sichtbar wird das beim Schritt von Engineer-to-Order zu Configure-to-Order.

Configure-to-Order entsteht nicht dadurch, dass wir Entwickler anders organisieren. Dafür müssen wir unter anderem verstehen:

• Was ist Standard und was ist wirklich kundenspezifisch?

• Wie müssen Produkte modularisiert werden?

• Welche Komponenten können wiederverwendet werden?

• Wo brauchen wir stabile Schnittstellen?

• Welche Plattform trägt unterschiedliche Produktvarianten?

• Wie stellen wir sicher, dass Konfiguration, Engineering, Quality und Testing miteinander funktionieren?

Die Forschung zu modularen Produktarchitekturen und Configure-to-Order zeigt genau diesen Zusammenhang zwischen Produktarchitektur, Modularisierung, Konfiguration und dem Übergang von ETO zu CTO. Produktplattformen und Produktfamilien schaffen dabei die Grundlage, Varianten aus wiederverwendbaren Elementen abzuleiten, statt für jeden Auftrag erneut zu entwickeln.

Und erst daraus ergeben sich aus meiner Sicht die organisatorischen Konsequenzen.

• Welche Teams brauchen wir?

• Wo sollten Verantwortlichkeiten liegen?

• Welche Entscheidungen müssen Teams selbst treffen können?

• Wie schneiden wir Value Streams?

• Welche KPIs fördern Flow – und welche belohnen weiterhin lokale Optimierung?

Vielleicht liegt genau darin ein häufiger Denkfehler bei agilen Hardware-Transformationen:

Wir versuchen zuerst, eine agile Organisation zu bauen – und hoffen anschließend, dass dadurch ein agiles Engineering entsteht.

Wir würde die Reihenfolge umdrehen. Versteht zuerst das Produkt & den Engineering Flow. Lasst uns die technischen Voraussetzungen durch Systems Engineering, Plattformen, Modularisierung, Quality und Testing schaffen. Erst dann gestalten wir eine darauf aufbauende Organisation, die genau diesen Flow unterstützt.

Für mich ist Agilität deshalb weniger eine Organisationsform als eine Fähigkeit des gesamten Engineering-Systems:

Wie schnell können wir neue Erkenntnisse und Veränderungen in validierten Kundennutzen übersetzen?

Deshalb wäre meine wichtigste Frage am Anfang einer agilen Hardware-Transformation weiterhin nicht:

„Wie organisieren wir unsere Teams?“

Sondern:

„Wie muss unser Engineering funktionieren, damit diese Teams überhaupt erfolgreich agil arbeiten können?“

Wie erlebt ihr das?

Wenn ihr vor einer Hardware-Transformation nur eines zuerst untersuchen könntet – das Organigramm oder den Weg eines Engineering Changes vom Auslöser bis zur validierten Lösung:

Wo würdet ihr anfangen?