Warum Effizienzsteigerungen die Entwicklung kaum beschleunigen

Traditionelle Produktentwicklung hat ein Problem: Wettbewerber tauchen scheinbar aus dem Nichts auf und bringen Produkte auf den Markt, die innovativer sind, schneller verfügbar und oft drastisch günstiger. Der reflexhafte Impuls lautet dann: Wir müssen effizienter werden. Also bessere Tools, schlankere Prozesse, mehr Automatisierung am Arbeitsplatz, mehr Auslastung. Und trotzdem passiert in vielen Organisationen etwas Frustrierendes: Die wahrgenommene Entwicklungsgeschwindigkeit bleibt hartnäckig gleich oder sie sinkt sogar.

Das ist meistens kein Problem schlechter Umsetzung. Es ist ein Paradigmenproblem. Lies weiter, um das Paradox zu verstehen.

Falsche Frage

Wenn Du aus der Perspektive klassischer Systems Engineering Denkmuster hinschaust, wird schnell klar, warum. Systems Engineering fragt nicht zuerst: Wie optimiere ich einen Schritt? Es fragt: Was ist das System, was ist sein Zweck, und wo liegt der Engpass, der den Flow bestimmt? In einem technischen System würdest Du auch nicht die schnellste Pumpe kaufen, wenn das Rohr dahinter zu eng ist. Genau diesen Denkfehler machen viele Teams: Sie erhöhen lokale Effizienz, ohne die Systemgrenzen, Schnittstellen und Rückkopplungen im Gesamtprozess zu berücksichtigen.

Lokale Optimierung ist kein Ersatz für Systemoptimierung. Mehr noch: Sie kann das System destabilisieren.

Wenn einzelne Teams ihre Durchsatzrate erhöhen, steigt typischerweise die Menge an Arbeit, die an den nächsten Schnittstellen ankommt. Wenn dort die Kapazität, die Klärungsfähigkeit oder die Entscheidungsbandbreite nicht mitwächst, entstehen Warteschlangen. Warteschlangen sind aber nicht nur Verzögerung. Sie sind auch Informationsverlust, Kontextwechsel, Rework und letztlich Qualitätsrisiko. Und plötzlich hast Du zwar effizientere Arbeitsschritte, aber ein langsameres Gesamtsystem.

Das ist der Kern: Produktgeschwindigkeit ist kein Summenwert aus vielen kleinen Effizienzen. Sie ist eine Eigenschaft des Gesamtsystems. Und Gesamtsysteme werden durch ihren Engpass dominiert, nicht durch ihre bestoptimierte Teilkomponente.

Ein Beispiel

Stell Dir einen Automobilzulieferer vor, der ein neues Steuergerät entwickelt. Das Softwareteam automatisiert Tests und halbiert die Zeit für einen Build. Parallel führt das Unternehmen neue Ticket Workflows ein, um die Entwicklung messbar effizienter zu machen. Ergebnis: Software liefert mehr Änderungen pro Woche. Nur liegen die entscheidenden Verzögerungen gar nicht im Coding, sondern an den Systemgrenzen: bei der Integration in die Hardware, bei der Freigabe der Sicherheitsanforderungen und bei der Abstimmung mit dem OEM. Die Integrationsumgebung ist knapp, die Systemtests laufen in festen Slots, und die Freigabegremien tagen alle zwei Wochen.

Was passiert? Die Warteschlange vor Integration und Freigabe wächst. Es wird mehr parallel begonnen, mehr wird wieder umgebaut, weil sich Anforderungen klären, während Arbeit schon im System ist. Am Ende sieht die Organisation viel Aktivität und viele lokale Effizienzgewinne, aber die Kalenderzeit bis zur SOP Reife bewegt sich kaum.

Global denken, lokal handeln

Aus Systems Engineering Sicht ist das keine Überraschung, sondern ein typisches Muster. Du hast ein soziotechnisches System mit Kopplungen, Rückkopplungen und begrenzenden Ressourcen. Wenn Du nur an einer Stelle schneller wirst, verschiebst Du Last in den Engpass und erhöhst dort die Work in Progress (WIP). Mehr WIP erhöht aber die Durchlaufzeit. Das ist kein Bauchgefühl, das ist Systemverhalten.

Wenn Du echte Produktgeschwindigkeit willst, musst Du daher anders fragen. Nicht: Wo kann ich einzelne Tätigkeiten effizienter machen? Sondern: Wo verliert das Gesamtsystem Zeit, und warum? Oft sind das klassische Systems Engineering Themen: unklare Systemgrenzen, instabile Schnittstellen, späte Validierung, ungeklärte Anforderungen, fehlende Architekturentscheidungen, oder zu viele gleichzeitige Vorhaben. Beschleunigung entsteht dann, wenn Du den Engpass entlastest, den Fluss stabilisierst, WIP begrenzt und Entscheidungen so triffst, dass sie das System als Ganzes optimieren.

Das Paradigma ändern

Product Velocity basiert auf vier Prinzipien, die zusammen genau das adressieren, was lokale Effizienzsteigerungen nicht leisten können: Sie verschieben den Fokus vom Optimieren einzelner Tätigkeiten hin zum Gestalten eines durchgängigen, stabilen Wertflusses.

Define & Align: Value Thinking
Produktgeschwindigkeit scheitert oft nicht an mangelnder Umsetzung, sondern an unklarer Zielrichtung. Value Thinking zwingt dazu, explizit zu machen, was Wert ist, für wen und in welcher Reihenfolge. Dadurch werden Prioritäten stabiler, unnötige Parallelität reduziert und Arbeit, die keinen klaren Wertbeitrag leistet, gar nicht erst gestartet. Weniger Missverständnisse am Anfang bedeuten weniger Warteschlangen, Rework und Verzögerungen später.

Design & Build: Architect for Flow
Statt Komponenten isoliert zu optimieren, wird die Architektur so gestaltet, dass sie den Fluss durch das Gesamtsystem unterstützt. Klare Systemgrenzen, robuste Schnittstellen und bewusste Entkopplung reduzieren Abhängigkeiten und Engpässe. Architektur wird damit nicht zum Dokumentationsartefakt, sondern zum aktiven Hebel für Durchsatz und kurze Durchlaufzeiten.

Integrate & Validate: Shift Left
Viele Verzögerungen entstehen, weil Integration, Tests und Freigaben zu spät stattfinden. Shift Left verlagert diese Aktivitäten so früh wie möglich nach vorne. Probleme werden sichtbar, solange sie noch billig lösbar sind. Warteschlangen vor Integration und Abnahme schrumpfen, Feedbackzyklen werden kürzer, und das System bleibt steuerbar statt reaktiv.

Operate and Evolve: Accelerate
Geschwindigkeit ist kein Projektziel, sondern eine dauerhafte Eigenschaft des Systems. Dieses Prinzip stellt sicher, dass Lernen, Betriebserkenntnisse und Marktfeedback kontinuierlich zurück in Entscheidungen, Architektur und Planung fließen. So wird das System mit jeder Iteration anpassungsfähiger, statt durch immer neue Effizienzinitiativen weiter zu verkrusten.

Zusammen verschieben diese vier Prinzipien den Blick weg von lokaler Auslastung und hin zu systemischer Wirksamkeit. Genau dort entsteht echte Produktgeschwindigkeit.

Fazit

Effizienz hat ihren Platz. Aber Effizienz ohne Systemblick ist wie das Optimieren eines Zahnrads, während das Getriebe klemmt. Wenn Du das Paradigma wechselst, wirst Du feststellen: Produktgeschwindigkeit ist weniger eine Frage des schneller Arbeitens, sondern eine Frage des besseren Systemdesigns.