Die meisten Unternehmen verlieren nicht an Tempo, weil die Ingenieure langsam arbeiten. Sie verlieren an Tempo, weil die Organisation die Arbeit aufhält.
Das war der zentrale Gedanke in meinem Gespräch mit Joe Justice. Joe ist vor allem bekannt für WikiSpeed, Agile Hardware, seine Arbeit bei Tesla und seine Beratungstätigkeit für Unternehmen wie Toyota, Honda und Mercedes-Benz. Seine Botschaft ist einfach und beunruhigend: Die Entwicklung physischer Produkte kann viel schneller voranschreiten, als die meisten Unternehmen glauben.
Der begrenzende Faktor ist selten das Material.
Metall lässt sich schnell schneiden. Kunststoff lässt sich schnell formen. CAD-Modelle lassen sich schnell ändern. Tests lassen sich schnell durchführen, wenn sie automatisiert und auf schnelles Feedback ausgelegt sind. Die eigentlichen Verzögerungen entstehen durch Übergaben, Genehmigungsrunden, Warteschlangen bei Lieferanten, funktionale Silos und unklare Zuständigkeiten.
Das ist auch der Kern von „Product Velocity“. Andere Sprache. Derselbe Feind. Lesen Sie weiter, um sich das Interview anzusehen, oder lesen Sie die Zusammenfassung.
Die Hardware ist nicht der Engpass
Joe’s WikiSpeed Die Geschichte klingt immer noch fast unwirklich. Sein Team entwickelte jede Woche ein neues Autodesign. Sie entwarfen das Auto in CAD, schnitten die Karosserieform aus Schaumstoff aus, umhüllten sie mit Kohlefaser, präsentierten sie potenziellen Kunden und führten Tests in staatlichen Labors durch.
Das Erstaunliche daran ist nicht die Kohlefaser. Das Erstaunliche daran ist die Trittfrequenz.
Die meisten großen Unternehmen betrachten Tests und Freigaben als Schritte in einer späten Phase. Bei WikiSpeed wurden sie als Teil des iterativen Prozesses betrachtet. Das Team wartete nicht auf einen perfekten Entwurf, bevor es mit den Tests begann. Durch die Tests wurde der Entwurf verbessert.
Hier treffen „Agile Hardware“ und „Product Velocity“ aufeinander. Bei „Product Velocity“ geht es nicht darum, durch das Umgehen technischer Standards schneller voranzukommen. Vielmehr geht es darum, die Zeit zwischen einer Entscheidung, einer Designänderung, einem Testergebnis und einem geschäftlichen Ergebnis zu verkürzen.
Ein langsames System verwandelt jeden Lernmoment in eine endlose Besprechungskette. Ein schnelles System verwandelt das Gelernte in die nächste Version.
Das geschäftliche Problem ist die Entscheidungsverzögerung
In dem Interview brachte Joe Justice einen Punkt zur Sprache, der weit über die Automobilbranche hinausgeht. Wenn Menschen sagen: “Das würde hier nicht funktionieren”, meinen sie oft: “Ich darf das, was dem im Wege steht, nicht ändern.”
Diese Unterscheidung ist wichtig.
Ein Beschaffungsleiter kann die Beschaffung verbessern. Ein Testleiter kann die Tests verbessern. Ein Softwareentwickler kann die Software verbessern. Keiner von ihnen kann den Produktfluss allein optimieren, wenn dieser alle Bereiche betrifft.
In traditionellen Organisationen wird die Zuständigkeit nach Kompetenzbereichen aufgeteilt. Die Buchhaltung untersteht der Buchhaltung. Die Software-Entwicklung untersteht der Software-Entwicklung. Die Hardware-Entwicklung untersteht der Hardware-Entwicklung. Der Testbereich untersteht dem Testbereich. Dem Produkt ist diese Struktur jedoch egal.
Der Produktfluss erstreckt sich über Organisationsstrukturen hinweg.
Das führt zu Verzögerungen bei der Entscheidungsfindung. Ein Team, das nah am Geschehen ist, erkennt ein Problem, leitet die Entscheidung an die nächsthöhere Ebene weiter, wartet, erhält eine Teilantwort, verhandelt mit einer anderen Abteilung und wiederholt den Vorgang. Jeder Schritt wirkt verantwortungsbewusst. Das gesamte System wird dadurch träge.
Für Führungskräfte, Das ist die wirtschaftliche Frage.. Die Frage ist nicht, ob der Prozess professionell wirkt. Die Frage ist, wie viel Wert ungenutzt bleibt, während die Organisation auf sich selbst wartet.
Die Architektur bestimmt, was sich bewegen kann
Joe verwendet den Ausdruck “Designs, die nicht warten”. Mir gefällt dieser Ausdruck, weil er viel Plattform-Jargon auf den Punkt bringt.
Eine Plattform sorgt nur dann für mehr Geschwindigkeit, wenn sie Wartezeiten verkürzt. Ein Modul sorgt nur dann für mehr Geschwindigkeit, wenn es geändert werden kann, ohne dass dadurch andere, nicht betroffene Teile des Systems ebenfalls geändert werden müssen. Eine stabile Schnittstelle schafft nur dann einen Mehrwert, wenn sich die Teams darauf verlassen können.
Viele Unternehmen investieren massiv in Plattformen und kommen dennoch nur langsam voran. Der Grund dafür ist einfach: Sie schaffen zwar gemeinsam nutzbare Ressourcen, verringern aber nicht die Abhängigkeiten. Jedes neue Produkt muss nach wie vor auf Entscheidungen derselben Gremien, dieselben Testwarteschlangen und dieselben Verhandlungen mit Lieferanten warten.
Eine nützliche Plattform nimmt Komplexität auf. Eine schwache Plattform verteilt sie weiter.
Das Smartphone ist ein gutes mentales Modell. App-Entwickler gestalten physische Erlebnisse, ohne sich Gedanken über die Kameraintegration, die GPS-Elektronik, das Batteriemanagement oder die sichere Installation zu machen. Die Plattform verbirgt genügend Hardware-Komplexität, um den Produktteams Freiraum zu geben.
In der Automobilindustrie, der Luft- und Raumfahrt, bei Industrieanlagen und medizinischen Geräten ist dieselbe Logik erforderlich, angepasst an die jeweiligen Sicherheits- und regulatorischen Rahmenbedingungen. Das Ziel besteht nicht darin, ein Auto so zu gestalten, dass es sich wie eine App verhält. Das Ziel ist vielmehr, Produktänderungen weniger davon abhängig zu machen, dass sich gleichzeitig auch alles andere ändert.
Conways Gesetz ist kein IT-Problem
Conways Gesetz besagt, dass Organisationen Systeme entwickeln, die ihre Kommunikationsstrukturen widerspiegeln. In der Softwarebranche ist dies mittlerweile allgemein anerkannt. Im Hardwarebereich betrachten viele Unternehmen dies jedoch nach wie vor eher als interessantes Zitat denn als operative Einschränkung.
Wenn ein Produkt nach Funktionen gegliedert ist, werden in der Produktarchitektur funktionale Abhängigkeiten beibehalten. Wenn die Produktarchitektur diese Abhängigkeiten beibehält, verbringen die Teams ihre Zeit damit, diese zu koordinieren. Das Ergebnis ist vorhersehbar: mehr Besprechungen, mehr Planung, mehr Eskalationen und langsamere Veränderungen.
Aus diesem Grund lassen agile Rahmenkonzepte allein zu wünschen übrig. Sie verbessern zwar die Koordination, lassen das Wartesystem jedoch unverändert.
Joe äußerte sich unverblümt zum Thema „Schein-Agilität“. Wenn ein System die Phasen Entwurf, Entwicklung, Test und Bereitstellung nicht beschleunigt, geht es nicht in die richtige Richtung – ganz gleich, wie es genannt wird.
Das ist ein nützlicher Test für jedes Transformationsprogramm. Verkürzt es die Zeit von der Idee bis zum getesteten Ergebnis? Oder die Entscheidungslatenz? Gibt es einem Team genügend Entscheidungsbefugnis, um einen echten Zyklus abzuschließen? Und verändert es die Produktarchitektur so, dass weniger Teams aufeinander warten müssen?
Falls die Antwort „Nein“ lautet, hat die Organisation die Rahmenbedingungen rund um die Arbeit verbessert.
Das 30-Tage-Experiment
Gegen Ende des Gesprächs fragte ich Joe, was ein traditionelles Hardware-Unternehmen in 30 Tagen ausprobieren sollte.
Seine Antwort war praxisorientiert. Sucht euch etwas, das das Unternehmen intern entwerfen, entwickeln und testen kann. Stellt ein Team zusammen, das aus allen Mitarbeitern besteht, die für den gesamten Prozess erforderlich sind. Gebt diesem Team die Erlaubnis, 30 Tage lang alles zu genehmigen, was benötigt wird. Schaut dann, ob sie eine vollständige Iteration abschließen können.
So verwende ich es auch ungefähr Maßnahmen zur Produktgeschwindigkeit.
Ich beginne in der Regel mit dem Wertstrom. Wo verliert das Unternehmen Zeit, und wo muss die Technik warten? Oder die Auslieferung? Wo liegt die Ursache an einer anderen Stelle als das sichtbare Symptom? Anschließend legt das Team ein messbares Ziel fest und führt eine 30-tägige Maßnahme durch.
Das Ziel ist kein Scheintheater. Das Ziel sind Beweise.
Nach 30 Tagen weiß die Organisation mehr als zuvor. Entweder hat sie die Einschränkung verringert oder sie hat die Struktur aufgedeckt, die einer Verringerung im Wege steht. Beide Ergebnisse sind nützlich. Beide sind besser als eine weitere Reifegradbewertung.
Wo agile Hardware und Produktgeschwindigkeit aufeinandertreffen
Joe kommt aus dem Hardware-Bereich. Er hat Autos gebaut, bei Tesla gearbeitet und Industrieunternehmen im Bereich „Agile Hardware“ beraten.
Die Produktgeschwindigkeit ergibt sich aus einer umfassenderen Systemperspektive: Geschäftsabläufe, Entwicklungsabläufe, Bereitstellungsabläufe und Systemverwaltung. Dabei wird untersucht, wie Unternehmen Entscheidungen in Produktergebnisse umsetzen und an welchen Stellen diese Umsetzung ins Stocken gerät.
Die Überschneidungen zwischen „Agile Hardware“ und „Product Velocity“ sind erheblich.
Beide Ansätze betrachten Geschwindigkeit als eine Systemeigenschaft und lehnen die Vorstellung ab, dass mehr Koordination das Problem der Abhängigkeiten löst. Sie stellen Architektur und Organisation gleichermaßen in den Mittelpunkt. Beide betrachten das Testen als Feedback-Mechanismus und nicht als späte Kontrollinstanz. Und beide nutzen kurze Experimente, um Erkenntnisse zu gewinnen, anstatt über Theorie zu diskutieren.
Dieser Unterschied ist von großem Nutzen. Joes Arbeit macht es unmöglich, die physische Realität zu ignorieren. „Product Velocity“ verbindet diese Realität mit Geschäftsergebnissen, Entscheidungsverzögerungen, dem Wertfluss und Führungsentscheidungen.
Für Unternehmen, die komplexe Produkte entwickeln, ist diese Kombination entscheidend. Die Zukunft wird nicht dadurch gewonnen, dass man Software-Methoden auf Hardware-Unternehmen überträgt. Sie wird dadurch gewonnen, dass man Produktsysteme entwickelt, die schneller lernen können als die Konkurrenz.
Dazu gehören Architektur, Teams, Validierung und die Zustimmung der Führungskräfte.
Offen für ernsthafte Experimente
Joe und ich gehen das gleiche Problem aus unterschiedlichen Blickwinkeln an. Deshalb war das Gespräch so wertvoll.
Hier bietet sich eine praktische Möglichkeit für Unternehmen, die eine schnellere Produktentwicklung erproben möchten, ohne ein großes Transformationsprogramm auf den Weg zu bringen. Beginnen Sie mit einem konkreten Produktfluss. Wählen Sie eine Einschränkung aus. Geben Sie einem Team ausreichend Entscheidungsbefugnis. Messen Sie das Ergebnis nach 30 Tagen.
Joe ist offen für eine Zusammenarbeit mit Unternehmen im Bereich „Agile Hardware“. Ich bin offen für eine Zusammenarbeit mit Unternehmen im Bereich „Product Velocity“. In manchen Fällen wäre es sinnvoll, dies gemeinsam anzugehen.
Der Ausgangspunkt ist kein Rahmenwerk.
Ausgangspunkt ist ein Produktfluss, bei dem es zu lange Wartezeiten gibt.
Kontaktieren Sie Michael Jastram
Sitzung: https://meetings-eu1.hubspot.com/meetings/michael-jastram
E-Mail: michael.jastram@formalmind.com
LinkedIn: https://www.linkedin.com/in/jastram/
Produktgeschwindigkeit https://productvelocity.org
YouTube: https://www.youtube.com/jastram
Kontaktieren Sie Joe Justice
X: https://x.com/JoeJustice
Facebook: https://www.facebook.com/Joe.A.Justice
LinkedIn: https://www.linkedin.com/in/joejustice/
Bücher: https://leanpub.com/u/joejustice
Kurse: https://en.abi-agile.com/
YouTube: https://www.youtube.com/@JoeJustice0
E-Mail: Joe@ABI-Agile.com