Joe Justice: Hardware kann schneller werden (Teil 1)
Ein straßenzugelassenes Auto pro Woche klingt nach Hype und maßloser Übertreibung. Doch Joe Justice hat schon vor 20 Jahren jede Woche mit einem kleinen Team ein neues Auto entworfen, gebaut, getestet und verkauft. Wenn das schon vor 20 Jahren ging, warum brauchen etablierte Firmen heute immer noch Jahre für deutlich kleinere Änderungen?
Joe Justice ist Gründer von WikiSpeed, arbeitete bei Tesla und berät heute Unternehmen wie Toyota, Honda und Mercedes Benz. In diesem Interview ging es um die eigentliche Frage hinter Agile Hardware: Was verhindert Geschwindigkeit in physischer Produktentwicklung wirklich?
Die kurze Antwort predige ich hier schon seit Jahren: Nicht die einzelnen Schritte sind langsam, der Gesamtfluss, mit Warteschlangen, Übergaben und langen Entscheidungswege bremsen uns, denn die wurden für eine andere Zeit gebaut.
Die WikiSpeed Geschichte
Joe Justice startete WikiSpeed 2006 mit einer einfachen Idee. Er wollte ein Auto bauen und dabei agile Methoden verwenden. Aus einem Einzelprojekt entstand ein Netzwerk mit 4.000 Beteiligten in 23 Ländern.
Der Arbeitsrhythmus war radikal: Donnerstagmorgen entstand ein neues Fahrzeugdesign in CAD. Danach schnitt eine Maschine die Außenform in Lebensgröße aus Schaum. Donnerstagabend wurde die Form mit Carbonfaser laminiert. Freitag stand das Fahrzeug auf Automessen. Dort sammelte das Team direkte Rückmeldung von potenziellen Kunden. Montag folgten Tests, auch in staatlichen Prüflaboren.
Der interessante Teil für das Systems Engineering liegt in der Taktung. WikiSpeed behandelte ein Auto wie ein Produkt, das in kurzen Iterationen entstehen kann, und zwar als normaler Arbeitsmodus.
Joe beschreibt, dass staatliche Tests nicht automatisch Millionen kosten müssen. WikiSpeed buchte Prüftermine direkt bei den Laboren. Ein Termin für Emissionstests kostete nach seiner Darstellung etwa 200 Dollar. Das Team blockte wiederkehrende Termine, nutzte freie Slots und ging nicht über teure Zwischenhändler.
Regulierung wird oft als Bremse gesehen, doch Wikispeed beweist, dass es auch anders geht und Regulierung in den Wochenrhythmus eingebaut werden kann.
Das Material wartet nicht
Viele Einwände gegen Agile Hardware beginnen mit dem Material. Metall lässt sich nicht deployen, Kunststoff lässt sich nicht kompilieren, ein Scheinwerfer ist kein Microservice.
Joe widerspricht dieser Intuition. Moderne Werkzeuge können Metall in Minuten zurechtschneiden, 3D-Druck und andere Technologien übersetzen Pläne schnell und automatisch in Bauteile.
Das eigentliche Problem kennt die Softwareentwicklung seit Jahrzehnten. Teams warten auf Entscheidungen, Entscheidungen warten auf Meetings, Meetings warten auf Kalender. Verträge warten auf Prüfung. Lieferanten warten in eigenen Warteschlangen. Andere Zeitzonen verstärken das Problem. Am Ende liegt das Produkt nicht wegen Physik still, sondern wegen der Struktur von Organisationen.
Wer heute einen Scheinwerfer entwickeln, fertigen, prüfen und freigeben will, braucht dafür ein Team, das den gesamten Weg beherrscht. Design, Bau, Test, Zulassung und Fertigung müssen in einem Arbeitsfluss liegen. Genau dort bricht die klassische Organisation.
Eine funktionale Organisation trennt CAD, Einkauf, Versuch, Qualität, Fertigung und Legalität. Dies führt zu Übergaben und Warteschlangen, was wiederum die Kosten von Änderungen erhöht. Conway’s Law. Mehr dazu weiter unten.
Tesla und die Frage der Skalierung
Der klassische Einwand gegen WikiSpeed lautet, dass ein Prototyp keine Serienproduktion ist. Als Joe die Chance bei Tesla bekam, genau diese Grenze zu testen, nahm er die Chance mit Begeisterung an. Im Vorstellungsgespräch bei Tesla fragte ihn niemand nach Abschlüssen, sondern technische Fragen zum Bearbeiten von Aluminium, zu Lieferanten und zu Straßenzulassung. Joe hatte Antworten, weil er diese Probleme praktisch gelöst hatte.
Daraus entstand ein Muster, das sich durch das Gespräch zog. Schnelle Hardwareentwicklung skaliert durch weniger Warten.
Schnelle Hardwareentwicklung skaliert durch das Eliminieren vom Warten.
Joe Justice
Ein Team muss die Kompetenz haben, ein Problem end to end zu lösen. Wenn ein neues Bauteil entsteht, dürfen die Prüfungen nicht Wochen später starten, sondern sofort: Tests müssen während der Entwicklung laufen. KI kann dabei als Beschleuniger agieren, zum Automatisieren von Arbeit, die vorher Menschen manuell, langsam und punktuell durchgeführt haben.
Die Dauer eines Tests sagt nichts über seine Qualität. Ein langer Test kann wenig Aussagekraft haben, während ein kurzer Test möglicherweise einen kritischen Fehler zuverlässiger findet. Für Hardware Organisationen ist auch das eine unangenehme Nachricht. Viele haben Sicherheit mit Dauer verwechselt.
Die europäische Ausrede
In Europa klingt der Einwand schnell anders. Tesla und SpaceX hätten Milliarden und China ist ein totalitäres Regime, das unter anderen Bedingungen arbeite. Ein Medizintechnikunternehmen, ein Maschinenbauer oder ein Zulieferer könne so nicht arbeiten. Joe deutet diesen Einwand anders.
Wenn jemand sagt, „bei uns geht das nicht“, heißt das oft: „Ich darf das nicht ändern.“
Joe Justice
Ein Einkäufer kann den Einkaufsprozess optimieren, aber nicht den Produktlebenszyklus umbauen. Ein Abteilungsleiter kann seine Funktion effizienter machen, aber nicht die Entscheidungsarchitektur des Unternehmens ändern. Solche Beispiele gibt es viele: Mitarbeitende dürfen lokal optimieren, aber nicht Conway Drift kompensieren.
Damit werden Ursache und Wirkung verdreht: Die Organisation nennt es „unsere Branche ist anders“. Gemeint ist: Die notwendigen Änderungen liegen außerhalb der eigenen Befugnis. Viele Unternehmen organisieren sich noch entlang von Fähigkeiten: Einkauf hier. Software dort. Versuch dort. Fertigung dort. Qualität daneben. Diese Struktur ist leicht zu führen, solange das Produkt langsam und vorhersehbar ist.
Bei komplexen Produkten versagt dieses Muster. Fahrzeuge, Medizingeräte, Maschinen und Aerospace Systeme bestehen heute aus Software, Elektronik, Mechanik, Daten, Betrieb und Service. Die wertvollen Funktionen entstehen an den Schnittstellen. Genau dort stehen die Silos.
Sloan Silos und die Kosten des Wartens
Joe verwendet den Begriff Sloan Silos für die funktionale Organisation nach Alfred P. Sloan. Diese Struktur hat historisch große Industrieunternehmen steuerbar gemacht. Sie sortierte Menschen nach Fähigkeiten und Managementlogik.
Wenn aber Geschwindigkeit wichtiger wird als Planbarkeit, dann geht das Sloan-Silo nach hinten los Wer nah an der Arbeit ist, stellt Anträge nach oben und wartet auf Entscheidungen. Jede Änderung wandert durch mehrere Kompetenzbereiche. Das führt zu langen Wartezeiten, Missverständnis und Wissensverlust.
Bei komplizierten Produkten funktioniert dieses System langsam. Bei komplexen Produkten funktioniert es nicht mehr zuverlässig. Ich brachte im Gespräch den Unterschied zwischen kompliziert und komplex ein. Ein Auto der 1980er Jahre war kompliziert. Ein modernes Fahrzeug ist ein vernetztes System aus Software, Elektronik, Sensorik, Energie, Cloud und Regulierung. Es reagiert auf Veränderungen nicht linear. Joe stimmt dem zu, ergänzt aber einen Punkt:
Auch ein kompliziertes System wird in Sloan Silos langsam. Komplexität nimmt dem System die Resttoleranz.
Joe Justice
Besonders sichtbar wird dies beim Outsourcing. Wenn ein OEM komplexe Systeme nicht mehr intern beherrscht, wandern wichtige Funktionen zu Zulieferern. Der Zulieferer wird schneller, aber mit eigenem Wissen. Der OEM kauft kurzfristig Fähigkeit ein und verliert langfristig Gestaltungsmacht.
Das ist der Punkt, an dem Geschwindigkeit strategisch wird. Wer die schnellen Teile des Produkts auslagert, lagert Zukunft aus.
Architektur, die nicht wartet
Im Gespräch ging es danach um Produktarchitektur. Joe nutzt dafür lieber den Begriff Modul als Plattform, da Plattform in Unternehmen zu viele Dinge bedeuten kann, von technische Basis über Baukasten bis Geschäftsmodell.
Joe meint etwas Präziseres: ein Design, das nicht wartet. Ein Modul ist dann gut geschnitten, wenn es sich wie eine Black Box ändern lässt, ohne dass andere Module mitgeändert werden müssen. Bei Wikispeed konnte das Team zum Beispiel den Antrieb ändern, ohne Sitze, Chassis oder Interieur anzufassen. Ein Modul besitzt stabile Schnittstellen und minimiert Abhängigkeiten. Das ist keine Architekturästhetik, sondern Architektur für Flow.
Viele Plattformprogramme scheitern hier: Sie bauen große gemeinsame Strukturen, erzeugen aber neue Warteabhängigkeiten. Wenn das NVH Verhalten einer Plattform von Radstand, Batteriegewicht, Reifen, Karosserieform und Zielkosten abhängt, wartet alles auf alles. Dann heißt es zwar Plattform, verhält sich aber wie ein monolithisches Freigabesystem.
Eine gute Plattform abstrahiert. Das Smartphone ist das beste Alltagsbeispiel. Eine App nutzt Kamera, Standort, Netzwerk, Speicher, Sicherheit und Sensorik, ohne jedes Mal ein physisches Gerät neu zu entwickeln. Die Plattform kapselt Hardwarefähigkeit. Sie bringt Sicherheitsmechanismen, Installationsmodell und Schnittstellen mit. Der App Entwickler denkt über seine Funktion nach, nicht über die elektrische Integration der Kamera.
Für Fahrzeuge gilt dasselbe Ziel. Die Plattform muss so viel Stabilität liefern, dass Varianten schnell entstehen können. Sie darf Entwicklung nicht zentralisieren, bis jede Änderung auf ein Komitee wartet.
In drei Wochen: Conway’s Law, Module und Experimente
In dem einstündigen Interview steckt enorm viel Wissen. So viel Wissen, dass es für einen Beitrag zu viel ist. In ein paar Wochen kommt die Zusammenfassung des zweiten Teils. Wer solange nicht warten möchte, kann sich natürlich heute schon das ganze Interview bei YouTube anschauen.
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
Bei Linkedin Diskutieren
Ein Like 👍 oder Share ↻ helfen mir. Danke!
