Die Velocity Loop: Ein DevOps-inspiriertes Modell für physische Produkte

Die meisten Organisationen haben erkannt, dass ihre Produktentwicklung langsamer ist, als sie sein müsste. Weniger können benennen, wo die Verlangsamung wirklich entsteht. Die Velocity Loop liefert Dir genau diese Diagnose in einer einzigen Sicht. Die Velocity Loop habe ich für mein dieses Jahr erscheinende Buch Product Velocity entwickelt.

Im folgenden beschreibe ich, wie die Velocity Loop in der Praxis hilft und aus welchen Bestandteilen sie besteht.

Weiterlesen >>

Die Velocity Loop hilft Dir zu erkennen:

• Wo Intent ins Stocken gerät
• Wo Entscheidungen sich sammeln
• Wo Feedback verloren geht
• Wo Lernen nie zurück ins System findet

Aus der Perspektive des klassischen Systems Engineering handelt es sich nicht um ein reines Umsetzungsproblem. Es ist ein Systemproblem. Klassische Vorgehensmodelle setzen oft auf lineare Phasen, frühe Vollständigkeit und die Illusion, Unsicherheit durch Spezifikation zu eliminieren. Das funktioniert bei einfachen Produkten gelegentlich, bei komplexen, cyber-physischen Produkten führt es aber häufig zu spätem Lernen, teurem Rework und einer Organisation, die sich selbst ausbremst.

Product Velocity ist deshalb eine operative Anforderung für Organisationen, die komplexe Systeme bauen. Die eigentliche Herausforderung ist nicht, ob Geschwindigkeit möglich ist, sondern wie Du sie systematisch und wiederholbar erreichst. Die Velocity Loop adressiert genau das, indem sie die Kernlogik von DevOps auf physische Produkte überträgt. Konkret bedeutet das: kontinuierliches Feedback und Integration werden so angepasst, dass Hardware, Software und Betrieb in unterschiedlichen Geschwindigkeiten evolvieren dürfen, ohne dass die Gesamtsystemleistung kollabiert.

Im Kern verbindet die Velocity Loop vier Praktiken: Business, System Stewardship, Engineering und Delivery. Zusammen bilden sie ein geschlossenes System, das Intent in Ergebnisse übersetzt und Ergebnisse wieder in Lernen zurückführt. Beim Lesen kannst Du die Loop bereits als Spiegel nutzen, und zwar nicht abstrakt, sondern entlang Deiner realen Übergaben, Gremien und Wartezeiten.

Business: Von der Spezifikation zur Richtung

In traditioneller Produktentwicklung wird Business oft als Quelle detaillierter Spezifikationen positioniert. Es wird angenommen, dass Klarheit am Anfang zu geringerem Risiko später führt. In der Praxis passiert häufig das Gegenteil. Du frierst Annahmen ein, bevor sie validiert sind, und verschiebst Lernen an den teuersten Punkt des Lebenszyklus. Genau hier prallt klassisches Systems Engineering in seiner streng phasenorientierten Ausprägung auf die Realität komplexer Märkte und Technologien.

In der Velocity Loop ändert sich die Rolle von Business grundlegend. Statt Lösungen vorzuschreiben, definiert Business Richtung. Dazu gehören Wert-Hypothesen, Prioritäten, Constraints und messbare Erfolgskriterien, die Entscheidungen in der Organisation leiten. Das Ziel ist nicht Vollständigkeit, sondern Relevanz. Ein Minimal Viable Product (MVP) ist nicht deshalb „viable“, weil es viele Features hat, sondern weil es tatsächlichen Wert erzeugt und verwertbares Feedback produziert.

The remaining challenge is not whether it can be done, but how to get there in a systematic and repeatable way.

Michael Jastram, Product Velocity

Business setzt diese Richtung und akzeptiert gleichzeitig, dass Alignment kontinuierlich ist und kein einmaliges Ereignis. Feedback aus Delivery fließt zurück in die Business Schleife. Dadurch können Prioritäten anhand von Evidenz evolvieren, statt auf Annahmen zu beruhen. Aus klassischer Sicht ist das eine Verschiebung von „Requirements als Vertrag“ hin zu „Requirements als Hypothesenraum“, ohne dass Du den Anspruch an Nachvollziehbarkeit verlierst.

System Stewardship: Daten in Entscheidungen übersetzen

System Stewardship ist die am wenigsten verstandene und zugleich kritischste Praxis in der Loop. Sie wird häufig mit Dokumentation, Governance oder Prozessverantwortung verwechselt. In Wirklichkeit ist sie eine Entscheidungs- und Struktur-Funktion. Ihre Aufgabe ist es, die Systemarchitektur als lebendes Asset zu pflegen und weiterzuentwickeln, damit Flow über alle anderen Praktiken möglich wird.

Wenn Du klassisches Systems Engineering kennst, dann ist Dir Architekturarbeit vertraut. Der Unterschied liegt im Fokus: System Stewardship ist nicht primär Artefaktproduktion, sondern das aktive Managen von Entscheidungen, Schnittstellen und Abhängigkeiten über die Zeit. Sie transformiert Rohinput aus Business und Delivery in strukturierte Information, mit der Engineering arbeiten kann. Sie macht Architektur-Trade-offs explizit, verwaltet Interfaces und bewahrt Wissen als Single Source of Truth. Nicht mehr Dokumente sind das Ziel, sondern bessere Entscheidungen zur richtigen Zeit.

System Stewardship provides this coordination and serves as the stable anchor that aligns business intent, engineering work, and delivery.

Michael Jastram, Product Velocity

Diese Rolle wird besonders wichtig, wenn Hardware und Software kollidieren. Hardware-Änderungen sind nach Deployment langsam und teuer. Software evolviert schnell und mit geringen Grenzkosten. System Stewardship besitzt diese Asymmetrien. Du machst Commitments sichtbar und nachvollziehbar, damit unterschiedliche Änderungsdynamiken nicht zur organisatorischen Reibung werden. Klassisch würdest Du sagen: Du hältst die Systemintegrität stabil, ohne die Lernrate zu opfern.

Engineering: Für Flow konstruieren, nicht für lokale Effizienz

Engineering ist der Ort, an dem Ideen Realität werden. In vielen Organisationen ist Engineering aber immer noch auf lokale Effizienz optimiert statt auf End-to-End Flow. Teams optimieren Auslastung, Übergaben vermehren sich und Feedback kommt spät. Das ist ein typisches Symptom klassischer, funktional geschnittener Organisationen: Mechanik, Elektronik, Software und Test arbeiten jeweils „optimal“, aber das System als Ganzes ist langsam.

In der Velocity Loop wird Engineering durch strukturierten Input aus System Stewardship geführt. Idealerweise in Form klarer Black-Box-Definitionen, die Verhalten und Schnittstellen spezifizieren, während Implementierungsentscheidungen bei den Teams bleiben. Dadurch entsteht Raum für paralleles Arbeiten, ohne Kohärenz zu verlieren. Du bekommst damit eine moderne Interpretation von Architektur und Schnittstellenmanagement, die nicht auf starre Phasen angewiesen ist.

Über Software, Mechanik und Elektronik gilt dasselbe Prinzip: Optimiere auf Flow. Begrenze Work in Progress. Reduziere Abhängigkeiten. Verifiziere früh. In Software ist diese Logik durch automatisierte Tests und Continuous Integration etabliert. In Hardware sind die Werkzeuge anders, aber das Ziel ist identisch. Frühe Simulation, virtuelles Testen und modellbasierte Ansätze verlagern Lernen dorthin, wo es noch günstig ist. Aus Systems Engineering Sicht ist das die konsequente Operationalisierung von shift left in einer Welt, in der Prototypen, Musterbau und Qualifikation reale Kostenblöcke sind.

Auch Packaging folgt derselben Logik. Stabile Schnittstellen und Downstream Readiness sind technische Enabler für kontinuierliche Integration in Umgebungen, in denen physische und digitale Elemente gemeinsam evolvieren müssen. Wenn Du das nicht bewusst designst, entsteht Integration als Event und nicht als Routine. Und genau dort verschwindet Geschwindigkeit.

Delivery: Wo Annahmen auf Realität treffen

Delivery wird oft auf Produktion und Deployment reduziert. In der Velocity Loop ist der Scope größer. Aufbau, Betrieb und Monitoring sind integrale Bestandteile des Entwicklungssystems. Klassisches Systems Engineering behandelt Betrieb häufig als nachgelagertes Thema oder übergibt es an andere Organisationseinheiten. Die Loop zwingt Dich, Betrieb als Teil der Entwicklungsrealität zu verstehen, weil dort die Wahrheit über Dein System entsteht.

Für Hardware umfasst Delivery die physische Realisierung unter Constraints von Tooling, Supply Chains und Fertigungsprozessen. Für Software bedeutet es häufig Konfiguration und Updates. In cyber-physischen Produkten koexistieren beide. Wenn Du sie getrennt behandelst, entstehen nicht abgestimmte Taktungen und verpasste Lernchancen. Du bekommst dann schnelle Software Releases, die an einer trägen Hardware-Änderungsstrategie zerschellen. Oder Du bekommst stabile Hardware, die von einer zu konservativen Update-Praxis ausgebremst wird.

Betrieb ist der Ort, an dem Wert letztlich geschaffen oder zerstört wird. Entscheidungen aus der Entwicklung müssen antizipieren, was nach Deployment passiert. Bugfixes, Performance-Optimierungen und Feature-Upgrades sind die Norm. Delivery umfasst deshalb die systematische Erfassung operationaler Daten als Designziel. Nicht als nachträgliches Add-on, sondern als Teil der Systemarchitektur.

Monitoring schließt die Loop. Nutzungsdaten, Testergebnisse und Felddaten werden zu Feedback, das sowohl Business-Prioritäten als auch architektonische Evolution informiert. In fortgeschrittenen Fällen verändert dieses Feedback ganze Geschäftsmodelle, etwa wenn Unternehmen vom Produktverkauf zur Ergebnisverantwortung wechseln. Aus klassischer Perspektive ist das der Schritt von „Abnahme“ zu „kontinuierlicher Verifikation im Feld“.

Warum die Loop zählt

Die Velocity Loop hilft zu identifizieren, wo Flow bricht und wo Lernen verzögert wird. Sie macht sichtbar: Geschwindigkeit ist nicht primär ein Ausführungsproblem. Es ist ein Problem des Systemdesigns. Und damit liegt es exakt im Kern dessen, was Systems Engineering eigentlich leisten soll, allerdings erweitert um die konsequente Rückkopplung aus Delivery und Betrieb.

Indem die Loop die Interaktionen zwischen Business, System Stewardship, Engineering und Delivery explizit macht, wird Koordination zur First-Class-Aufgabe. Du kannst die inhärente Spannung zwischen Hardware-Stabilität und Software-Adaptivität bearbeiten, ohne das eine zu verlangsamen, um das andere zu schützen. Genau diese Entkopplung durch klare Schnittstellen, konsequente Feedbackpfade und bewusstes Architekturmanagement ist der Unterschied zwischen „wir sind halt langsam“ und „unser System ist so gebaut, dass es nicht schnell sein kann“.

The Velocity Loop does for physical products what DevOps did for software. It replaces linear thinking with closed-loop learning. Not to move faster at any cost, but to move with purpose, clarity, and sustained impact.

Michael Jastram, Product Velocity

Du solltest jetzt in der Lage sein, in Deinem eigenen System zu benennen, wo Deine Velocity Loop bricht. Nicht abstrakt, sondern in konkreten Übergaben, Wartezeiten, Gremienschleifen und verlorenen Feedbackkanälen. Genau darin liegt der Wert des Modells. Es sagt Dir nicht einfach, dass Du schneller sein sollst. Es zeigt Dir, wo Dein System strukturell Geschwindigkeit verhindert, und damit, wo Veränderungen tatsächlich Wirkung entfalten.