Joe Justice: Conway’s Law, Module und Experimente (Teil 2)
In 30 Tagen ein neues Modul Entwickeln, testen und Bauen? Zum ersten Mal? Laut Joe Justice schlägt das als ein sinnvolles erstes Experiment vor für Unternehmen, die sich näher mit Agile Hardware auseinandersetzen wollen.
Dies ist der zweite und letzter Teil der Zusammenfassung des Interviews mit Joe Justice zum Thema Geschwindigkeit (Zum ersten Teil). Auch wenn die Begrifflichkeiten andere sind, so sind dennoch überall die Prinzipien von Product Velocity erkennbar. Was nicht verwunderlich ist, da Joe mich inspiriert hatte, Product Velocity zu entwickeln.
Conway’s Law im Fahrzeugbau
Conway’s Law sagt, dass Organisationen Systeme bauen, die ihrer Kommunikationsstruktur ähneln. Im Gespräch wurde deutlich, wie hart dieses Gesetz im Hardwareumfeld wirkt.
Wenn eine Organisation nach Funktionen geschnitten ist, entsteht ein Produkt voller funktionaler Abhängigkeiten. Wenn eine Organisation nach Produktmodulen geschnitten ist, entstehen Module mit klareren Schnittstellen. Produktarchitektur und Organisationsarchitektur sind gekoppelt.
Tesla und SpaceX nutzen nach Joes Darstellung immer stärker unabhängige Module. Diese Produktstruktur erlaubt Teams, sich passend zu den Modulen zu organisieren. WikiSpeed arbeitete ähnlich. Es gab eine Gruppe für den Antriebsstrang. Diese Gruppe konnte den Antriebsstrang ändern, ohne Sitze, Interieur, Chassis oder Fahrwerk mitzuziehen.
Viele Unternehmen arbeiten andersherum. Sie schaffen Kopplung, weil ihre Silostruktur Überschneidungen zwischen System- und Organisationsstruktur verursacht. Danach brauchen sie Koordination, Architekturboards, Abhängigkeitsmanagement und Freigabeketten. Die Organisation erzeugt das Problem und kauft danach Methoden ein, um es zu verwalten.
Das erklärt auch, warum manche Unternehmen mit Skalierungsframeworks nur begrenzt schneller werden. Sie verwalten Warteabhängigkeiten besser. Sie entfernen sie nicht.
Schnittstellen sind wichtiger als Namen
Ein spannender Teil des Gesprächs drehte sich um semantische Versionierung für Hardware. In der Software beschreibt Semantic Versioning mit Zahlen wie 1.2.3, ob eine Änderung rückwärtskompatibel bleibt, Funktionalität ergänzt oder bestehende Nutzung bricht.
Für Hardware Schnittstellen ist die Idee reizvoll. Ein Scheibenwischer mit haltbarerem Material wäre ein Patch, während ein Scheibenwischer mit zusätzlicher Schmutzerkennung ein Minor Change mit erweiterter Funktionalität wäre. Eine inkompatible mechanische oder elektrische Änderung bricht Abhängigkeiten und verursacht einen Major Change.
Joe reagierte vorsichtig. Ein Name oder eine Versionsnummer darf nicht zur Abkürzung für Prüfung werden und falsche Sicherheit vorgaukeln. Ein System muss ein neues Modul so behandeln, als wüsste es noch nicht, was angeschlossen wurde. Es muss testen, handshaken und selbständig Eigenschaften erkennen und Verhalten prüfen.
Das führt zu einer starken Idee: emergente Architektur. Tesla Fahrzeuge waren laut Joe darauf ausgelegt, angeschlossene Teile aktiv zu erkennen. Das System fragt ständig: Was ist mit mir verbunden? Was ist es? Welche Schnittstelle bietet es? Welche Sicherheitsmechanismen greifen? So kann ein Fahrzeug mit Bauteilen umgehen, die beim ursprünglichen Design noch nicht existierten.
Das Internet funktioniert nach demselben Prinzip. TCP, IP und DNS kannten beim Entwurf nicht jedes daran angeschlossene IoT-Device. Das Protokoll ermöglichte Anmeldung, Adressierung und Austausch. Neue Fähigkeiten kamen später dazu.
Für Hardware ist das eine anspruchsvolle Denkweise. Viele Unternehmen versuchen, das Produkt vor Serienstart vollständig zu definieren. Jede spätere Überraschung gilt als Fehler. Ein innovatives System braucht aber die Fähigkeit, kontrolliert überrascht zu werden.
Semantische Versionierung passt in dieses Bild, wenn sie als maschinenlesbare Dokumentation und Kompatibilitätsinformation genutzt wird. Sie ersetzt keinen Test oder formale Abhängigkeitsprüfung. Missbrauch beginnt dort, wo die Versionsnummer Vertrauen ersetzt.
Weniger Module, weniger kognitive Last
Joe bevorzugt eine kleine Zahl großer Module. Er spricht von ungefähr zehn Modulen, die Menschen noch als Gesamtsystem verstehen können. Darunter können wieder Submodule liegen. Ein Batteriepack hat eigene Struktur. Entscheidend ist, dass die Menschen im System die großen Schnittstellen begreifen.
Das klingt altmodisch in einer Zeit, in der KI Agenten immer größere Entwurfsräume untersuchen. Gerade deshalb bleibt der Punkt relevant. Menschen sind weiter in der Engineering-Schleife. Wer das Gesamtsystem nicht versteht, optimiert lokale Teile und erzeugt neue Abhängigkeiten.
Die Zahl zehn beschreibt ein Ziel: Das System soll im Kopf eines Teams Platz haben. Nicht jede Schraube, sondern die großen Module, ihre Verantwortung und ihre Schnittstellen.
Joe Justice
Viele Unternehmen laufen in die Gegenrichtung. Sie haben tausende Anforderungen, dutzende Tools, große Traceability Netze und ein Produktmodell, das niemand mehr überschaut. Die Werkzeuge ermöglichen die Komplexität. Dann gilt die Komplexität als Beweis für professionelle Entwicklung.
Das ist gefährlich. Requirements Management Tools sind mächtig, denn sie können Transparenz schaffen. Sie können aber auch zehntausende Anforderungen erzeugen, weil es technisch möglich ist. Dasselbe Risiko gilt für semantische Versionierung, Plattformmodelle und digitale Zwillinge. Das Werkzeug löst nicht das Strukturproblem.
Fake Agile Hardware
Agile Hardware ist dann Fake, wenn es Design, Build, Test und Deploy nicht schneller macht.
Das klingt banal, ist aber ein harter Prüfstein. Viele Programme verbessern Sprache, Rollen und Meetingstruktur. Die eigentliche Durchlaufzeit bleibt fast gleich. Dann gibt es mehr Boards, mehr Koordination und mehr Status. Das Produkt wird nicht schneller.
Joe nennt SAFe als bekanntes Beispiel. Er erkennt an, dass SAFe für manche Unternehmen ein Schritt nach vorn sein kann, denn es ist oft schneller als das bestehende System. Aber es reicht nicht, wenn der Wettbewerb aus China, von Tesla oder von schnellen Zulieferern kommt. Ein Release Train Engineer verwaltet Abhängigkeiten zwischen Zügen. Eine produktorientierte Organisation schneidet die Züge anders.
Die entscheidende Frage lautet nicht: Sind wir agil? Die Frage lautet: Können wir sicher, legal und wirtschaftlich schneller designen, bauen, testen und deployen als vorher? Wenn die Antwort nein lautet, ist die Methode Dekoration. Dann klingt die Organisation moderner, arbeitet aber weiter im alten Wartesystem.
Das 30 Tage Experiment
Am Ende des Gesprächs ging es um einen konkreten Einstieg. Was kann ein traditionelles Hardwareunternehmen in 30 Tagen ausprobieren, um Agile Hardware zu testen?
Joe schlägt ein Experiment vor, das bewusst klein beginnt. Das Unternehmen soll etwas auswählen, das es vollständig intern designen, bauen und testen kann. Dann bildet das Unternehmen ein Team mit allen Fähigkeiten, die für diesen End to End Weg nötig sind.
Für 30 Tage bekommt dieses Team die Erlaubnis, alles zu entscheiden, was es für diesen Fluss braucht. Ziel ist eine vollständige Iteration, eine echte Schleife aus Design, Bau, Test und Ergebnis.
Dieser Vorschlag ist stark, weil er nicht mit Organisationstheorie beginnt. Er beginnt mit einem Produktfluss. Das Team erfährt, wo es wartet. Es erlebt, welche Entscheidungen fehlen. Es sieht, welche Schnittstellen stabil sind und welche jede Änderung blockieren.
Ich ergänzte den Value Flow Blick. Der Einstieg kann auch über einen konkreten Engpass erfolgen. Ein Beispiel ist Change Impact Analysis. Entscheidend ist, die Wirkung messbar zu machen. Wie lange dauert der Fluss heute? Wo entsteht die Verzögerung? Welche Maßnahme wird in 30 Tagen getestet? Was hat sich danach verändert?
Beide Perspektiven passen zusammen. Joe beginnt beim physischen End to End Produkt. Michael beginnt beim Engpass im Wertfluss. In beiden Fällen geht es nicht um eine neue Prozessfolie, sondern um einen beweisbaren Eingriff in den Fluss.
Bottom up reicht nicht
Ein 30 Tage Experiment beweist, dass Änderung möglich ist, ersetzt aber keine Führung. Bottom up Initiativen machen sichtbar, dass viele Blockaden nicht technisch sind. Aber sie bleiben lokal, wenn keine strategische Richtung existiert.
Top down Richtung ist nötig, damit Experimente nicht zerfallen. Führung muss entscheiden, welche Flüsse zählen, welche Wartezeiten teuer sind und welche Organisationsgrenzen verändert werden dürfen. Ohne dieses Mandat arbeiten Teams gegen die Struktur. Dann gewinnt die Struktur.
Das erklärt, warum viele Transformationsprogramme enttäuschen. Sie starten bottom up, ohne Macht über Abhängigkeiten. Oder sie starten top down, ohne konkrete Flussarbeit. Beides reicht nicht. Aber verbunden sind sie enorm mächtig. Die oben zitierte Fallstudie von Wagner zeigte das: Wagner entschied sich, MBSE strategisch einzusetzen (Top Down). Die Umsetzung fand dann in kleinen Iterationen von 3–6 Monate Länge statt, die jeweils einen eigenen Return on Investment generierten. Gleichzeitig bewegten sich die kleinen Initiativen in dieselbe Richtung, bis sich daraus größere Ergebnisse herauskristallisierten. Wie zum Beispiel die Zertifizierung in Tagen statt Monaten.
Was bleibt
Joe Justice ist kein weiterer Agile Evangelist, der Hardwareteams erklärt, sie müssten mehr wie Softwareteams werden. Seine These ist schärfer. Hardware ist nicht wegen Hardware langsam, sondern wenn Organisation, Architektur und Validierung auf Warten ausgelegt sind.
Das ist für europäische Industrie unbequem. Viele Unternehmen investieren in Plattformen, Tools, Frameworks und Lieferantennetze. Diese Investitionen helfen nur, wenn sie Abhängigkeiten reduzieren. Eine Plattform, die warten muss, ist kein Geschwindigkeitshebel. Und gerade Tools sind bekannt dafür, zu enttäuschen, weil der erhoffte Geschwindigkeitsgewinn ausbleibt.
Der Maßstab bleibt einfach: Wie schnell entsteht ein legales, sicheres, getestetes und nutzbares Ergebnis?
Joe Justice
Fazit
Agile Hardware beginnt mit der Erlaubnis, einen Produktfluss end to end zu verändern. Der nächste sinnvolle Schritt ist es, viele kleine Experimente an echten Engpässen durchzuführen. Solche Experimente braucht ein kleines Team mit allen nötigen Fähigkeiten, stabile Schnittstellen oder den Auftrag, sie zu stabilisieren. Sie braucht automatisierte Tests dort, wo heute manuelle Freigaben warten. Sie brauchen Messungen, die wirtschaftlich relevant ist.
Danach ist die Diskussion ehrlicher. Wenn der Fluss schneller wurde, liegt der nächste Engpass offen. Wenn der Fluss nicht schneller wurde, ist sichtbar, welche Struktur blockiert. In beiden Fällen entsteht Erkenntnis, die mehr wert ist als ein weiteres Reifegradmodell.
Joe Justice zeigt , dass Geschwindigkeit dort entsteht, wo Produktarchitektur, Teamstruktur und Validierung denselben Fluss bedienen. Alles andere ist Warteschlangenmanagement mit besserem Vokabular.
Kontakt zu Joe Justice
X: https://x.com/JoeJustice
Facebook: https://www.facebook.com/Joe.A.Justice
LinkedIn: https://www.linkedin.com/in/joejustice/
Books: https://leanpub.com/u/joejustice
Classes: https://en.abi-agile.com/
YouTube: https://www.youtube.com/@JoeJustice0
Email: Joe@ABI-Agile.com
