Warum schnellere Teams trotzdem langsam liefern

Traditionelle Produktunternehmen stehen vor einer unbequemen Realität. Wettbewerber tauchen scheinbar aus dem Nichts mit innovativeren, schneller auf den Markt gebrachten und oft dramatisch günstigeren Produkten auf. Die instinktive Reaktion ist, nach Effizienzsteigerungen: schnellere Werkzeuge, schlankere Prozesse, mehr Automatisierung auf Arbeitsplatzebene. Doch Organisationen, die diesen Weg einschlagen, stellen oft fest, dass ihre gesamte Entwicklungsgeschwindigkeit hartnäckig unverändert bleibt oder sogar sinkt.

Dies ist kein Ausführungsfehler. Es ist ein Scheitern eines Paradigmas.

Die bequeme Illusion

Produktentwicklungsabteilungen neigen dazu, Überzeugungen zu vertreten, die zwar intern konsistent, aber grundlegend dysfunktional sind. Die wichtigste davon ist die Überzeugung, dass die Verbesserung der Effizienz einzelner Aktivitäten automatisch zu einer schnelleren End-to-End-Lieferung führt. Wenn unsere Ingenieure schneller entwickeln können, unsere Tester schneller validieren können und unsere Fertigung schneller Prototypen erstellen kann, dann muss sich sicherlich das Gesamtsystem beschleunigen.

Das Problem ist, dass diese Argumentation ignoriert, wie komplexe Produktentwicklung tatsächlich funktioniert. Entwicklung ist keine Abfolge von unabhängigen Aktivitäten, die isoliert durchgeführt werden. Sie ist ein Netzwerk von voneinander abhängigen Arbeitsströmen, Entscheidungen und Feedbackschleifen. Die Optimierung eines Teils dieses Netzwerks, ohne seine Verbindungen zu anderen Teilen zu berücksichtigen, bewirkt oft das Gegenteil des beabsichtigten Effekts.

Betrachten Sie ein gängiges Szenario: Ein Ingenieurteam investiert stark in bessere CAD-Werkzeuge, wodurch die Zeit für die Erstellung detaillierter Entwürfe um 30 Prozent reduziert wird. Das sieht nach einem klaren Gewinn aus. Aber das nachgelagerte Integrationsteam erhält nun mehr Designpakete, als es verarbeiten kann. Warteschlangen bilden sich. Übergabeverzögerungen nehmen zu. Integrationszyklen werden gestört. Der lokale Effizienzgewinn hat zu einer globalen Verlangsamung geführt.

Dieses Muster wiederholt sich in Organisationen. Effizientere Anforderungserfassung führt zu Engpässen in der Architektur. Schnelleres Prototyping überlastet die Validierungskapazität. Beschleunigtes Coding erzeugt Integrationsrückstände. Die Verbesserung an jeder Station ist real, aber das Ergebnis auf Systemebene ist schlechter.

Lokale Optimierung als Anti-Pattern

Der Velocity Loop– ein konzeptionelles Modell zum Verständnis des Wertflusses in komplexen Produktentwicklungen – identifiziert lokale Optimierung als eines der schädlichsten Anti-Muster, in die eine Organisation geraten kann:

Lokale Optimierung Optimierung von Teilen der Organisation, des Prozesses oder der Toolchain auf Kosten des End-to-End-Flusses und der Ergebnisse.

Dieses Anti-Muster entsteht nicht durch einzelne Fehler. Es ist eine strukturelle Folge der Art und Weise, wie die meisten Organisationen aufgebaut sind und gemessen werden. Abteilungen werden anhand ihrer eigenen Leistungskennzahlen beurteilt. Teams werden für ihre eigenen Ergebnisse belohnt. Einzelne Mitarbeiter werden anhand ihrer eigenen Produktivität bewertet. Jeder dieser Anreize führt zu einer lokalen Optimierung und weg vom Gesamtfluss.

Das Ergebnis ist vorhersehbar. Teams werden hervorragend in ihren eigenen Aufgaben, während das Gesamtsystem langsamer wird. Die Kapazitätsauslastung steigt, während der Durchsatz stagniert. Alle sind beschäftigt, aber die Wertschöpfung bleibt zurück.

Ich bin der Ansicht, dass das vorherrschende Paradigma für das Management der Produktentwicklung grundlegend falsch ist. Nicht nur ein wenig falsch, sondern bis ins Mark.

Donald Reinertsen, Autor von Die Prinzipien des Produktentwicklungsflusses

Der orthodoxe Glaube, dass Effizienzsteigerungen zu Geschwindigkeit führen, ist ein solcher Irrglaube. Er ist gut durch Intuition abgesichert und durch sichtbare Aktivitäten verstärkt. In den meisten Produktentwicklungskontexten ist er auch nachweislich falsch.

Die Kapazitätsauslastungsfalle

Eine der kontraintuitivsten Dynamiken in der Produktentwicklung ist die Beziehung zwischen Kapazitätsauslastung und Durchlaufzeit. Konventionelles Managementdenken betrachtet eine hohe Auslastung als Zeichen von Effizienz: Wenn unsere Leute zu 95 Prozent beschäftigt sind, müssen wir Straffheit betreiben.

Die Realität ist komplexer. In Systemen mit Variabilität – und Produktentwicklung ist nichts, wenn sie nicht variabel ist – führt eine hohe Auslastung zu Warteschlangen. Warteschlangen verursachen Verzögerungen. Verzögerungen verlängern die Zykluszeit. Die Mathematik ist unerbittlich: Wenn sich die Auslastung 100 Prozent nähert, steigen die Wartezeiten nicht linear, sondern exponentiell an.

Wenige Entwickler erkennen, dass Warteschlangen die wichtigste Ursache für schlechte Produktentwicklungsleistungen sind. Der Bestand im laufenden Prozess sammelt sich unsichtbar an, weil er im Gegensatz zu physischen Beständen in einer Fabrikhalle keine sichtbare Präsenz und keine offensichtlichen Lagerhaltungskosten hat. Dennoch dominiert er die Durchlaufzeit und erstickt jegliche lokalen Effizienzverbesserungen.

Die Erhöhung der Kapazitätsauslastung (ein Effizienz-Proxy) hat oft den negativen Effekt, die Durchlaufzeit zu verlängern. Die Optimierung für ausgelastete Teams bedeutet, eine langsamere Wertlieferung in Kauf zu nehmen.

Die Werkzeugfalle

Wenn die Produktentwicklung ins Stocken gerät, greift die Unternehmensleitung oft auf dieselbe Lösung zurück: bessere Werkzeuge. Neue ALM-Systeme, aktualisierte CAD-Plattformen, moderne Software für das Anforderungsmanagement, integrierte PLM-Suiten. Die Logik dahinter ist bekannt: Wenn unsere Werkzeuge schneller sind, wird auch unsere Entwicklung schneller voranschreiten.

Dies ist eine weitere tröstliche Illusion.

Bessere Werkzeuge können vorhandene Fähigkeiten verstärken, aber sie können strukturelle Probleme nicht beheben. Die Übernahme der Sprache, der Rollen oder der Werkzeuge moderner Entwicklungspraktiken ohne die notwendigen kulturellen, strukturellen oder anreizbezogenen Veränderungen ist das, was man als oberflächliche Umsetzung bezeichnen könnte. Sie erweckt den Anschein einer Transformation, ohne dass diese tatsächlich stattfindet.

Ein Tool, das Design-Reviews beschleunigt, nützt nichts, wenn Entwürfe wochenlang in Warteschlangen liegen, bevor sie geprüft werden. Eine Anforderungsplattform mit erweiterter Rückverfolgbarkeit bringt keinen Mehrwert, wenn die Anforderungen nicht auf die geschäftlichen Prioritäten abgestimmt sind. Eine CI/CD-Pipeline, die schnellere Tests durchführt, ist irrelevant, wenn sich die Integrationsstapel monatlich ansammeln.

Investitionen in Werkzeuge müssen mit Investitionen in Abläufe gekoppelt werden. Geschwindigkeit auf Arbeitsplatzebene führt nur dann zu Geschwindigkeit auf Systemebene, wenn Übergaben reduziert, Warteschlangen verwaltet und Rückkopplungsschleifen verkürzt werden. Ohne diese Kopplung werden Werkzeug-Upgrades zu teuren Ablenkungen.

Was erzeugt tatsächlich Geschwindigkeit

Produktgeschwindigkeit ist keine Optimierung. Sie ist eine Paradigmenwechsel. Es verändert, wie Produkte konzipiert, entwickelt und weiterentwickelt werden, anstatt bestehende Prozesse zu beschleunigen.

Der Wandel erfordert Aufmerksamkeit für mehrere Dimensionen, die Effizienzsteigerungen normalerweise ignorieren:

Wertfluss vor lokaler Effizienz. Die Frage ist nicht, wie schnell eine einzelne Aktivität abgeschlossen ist, sondern wie schnell Wert vom Konzept zum Kunden gelangt. Dies erfordert, Verzögerungen sichtbar zu machen, die laufende Arbeit zu begrenzen und die Übergänge zwischen Teams und Praktiken aktiv zu steuern.

Lerngeschwindigkeit vor Prozessgeschwindigkeit. Produktentwicklung birgt Unsicherheit. Um diese Unsicherheit aufzulösen, bedarf es des Lernens. Die Unternehmen, die sich am schnellsten entwickeln, sind nicht diejenigen mit den schnellsten Prozessen, sondern diejenigen, die am schnellsten lernen. Schnelle Feedbackschleifen, schnelle Validierung und kontinuierliche Integration sind keine Effizienzmaßnahmen, sondern Lernmechanismen.

Systemweite Kohärenz vor abteilungsspezifischer Exzellenz. Leistungsstarke Teams, die sich nicht effektiv abstimmen, erzielen nur mittelmäßige Ergebnisse. Architektur, Integration und funktionsübergreifende Abstimmung sind kein Mehraufwand: Sie bilden die Grundlage, die einen reibungslosen Arbeitsablauf ermöglicht.

Bewusste Abstimmung statt kontinuierlicher Synchronisierung. Die verschiedenen Ebenen des Engagements entwickeln sich mit unterschiedlicher Geschwindigkeit. Sie in einen einheitlichen Rhythmus zu zwingen, führt zu Spannungen und Verzögerungen. Eine effektive Produktentwicklung nutzt Kadenz (gezielte, wiederkehrende Abstimmungspunkte), um die Arbeit zwischen den verschiedenen Bereichen zu koordinieren, ohne eine enge Kopplung zu erzwingen.

Sprache für die Unterhaltung

Wenn jemand meint, “wir bräuchten einfach bessere Werkzeuge”, um die Entwicklung zu beschleunigen, können die folgenden Antworten helfen, das Gespräch wieder auf systemisches Denken zu lenken:

“Wo sind die Schlangen?” Bevor Sie über Werkzeuginvestitionen sprechen, sollten Sie verstehen, wo sich die Arbeit ansammelt und auf den nächsten Schritt wartet. Die Wartezeit in der Warteschlange übersteigt normalerweise die Bearbeitungszeit um eine Größenordnung. Bessere Werkzeuge, die größere Warteschlangen schneller bedienen, verbessern die Ergebnisse nicht.

“Was sind die Kosten der Verzögerung?” Effizienzmetriken messen Aktivität. Kosten der Verzögerung messen die Auswirkung. Das Verständnis der wirtschaftlichen Konsequenzen verzögerter Lieferung hilft bei der Priorisierung von Flussverbesserungen gegenüber lokalen Effizienzverbesserungen.

“Was passiert an den Grenzen?” Werkzeuge beschleunigen die Arbeit innerhalb von Teams. Die Geschwindigkeit wird durch das eingeschränkt, was zwischen den Teams geschieht. Übergaben, Genehmigungen, Integrationspunkte und Feedbackschleifen verlangsamen die Entwicklung. Werkzeuge befassen sich selten damit.

“Ist das ein Werkzeugproblem oder ein strukturelles Problem?” Ein Werkzeug kann die Geschwindigkeit einer bestimmten Aufgabe verbessern. Es kann keine Anreize, Berichtsstrukturen oder kulturellen Normen in einer Organisation verändern. Wenn das Problem strukturell ist, ist ein Werkzeug eine Ablenkung.

“Messen wir das Richtige?” Metriken formen das Verhalten. Wenn Teams auf Auslastung hin gemessen werden, werden sie sich auf Beschäftigung optimieren. Wenn Teams auf Durchsatz hin gemessen werden, werden sie sich auf den Fluss optimieren. Die Wahl der Metriken bestimmt, ob sich Investitionen in Werkzeuge in Geschwindigkeitsverbesserungen niederschlagen.

Der Weg nach vorn

Der Wettbewerbsdruck auf Produktentwicklungsabteilungen ist real. Unternehmen wie BYD entwickelt neue Fahrzeugmodelle in 18 Monaten während traditionelle Autohersteller 40 benötigen. SpaceX entwickelt Raketentriebwerke in mehreren Generationen weiter in der Zeit, die Wettbewerber benötigen, um ein einziges Design fertigzustellen. Diese Unterschiede werden nicht durch bessere Werkzeuge oder inkrementelle Effizienzsteigerungen erklärt.

Der Weg nach vorn erfordert eine ehrliche Betrachtung, wo Wert und Feedback im aktuellen Entwicklungsablauf verzögert werden, insbesondere über organisatorische, technische und disziplinarische Grenzen hinweg. Sie erfordert, die Produktgeschwindigkeit als strategisches Führungsthema zu behandeln und nicht als Initiative für Werkzeuge, Prozesse oder Methodologien. Und es erfordert, die bequeme Illusion aufzugeben, dass Effizienzsteigerungen die Lücke schließen werden.

Kleine Effizienzgewinne hier und da reichen nicht aus, um aufzuholen. Das Paradigma selbst muss sich ändern.