Die 175 Flow-Prinzipien: Warum Produktentwicklung oft langsamer ist als nötig

Flow beschreibt den Fluss von Arbeit durch eine Organisation: Anforderungen, Spezifikationen, Designs, Tests, Freigaben, etc. In der Mechanik kann das eine Schraube sein, in der Elektronik ein Platinen-Re-Spin, in der Software ein Feature, im Business eine Budgetfreigabe. Solange Ein Flow-Item nicht abgeschossen wird, verdient das Unternehmen daran kein Geld.

Die Idee hinter Flow ist alt: Schon im frühen indestriellen Zeitalter untersuchten Taylor und Gilbreth Bewegungen und Engpässe in Fabriken. Henry Ford zeigte mit dem Fließband, wie sich ein kontinuierlicher Strom von Arbeit in Produktivität und Gewinn übersetzen lässt. Später verfeinerte Toyota unter dem Namen Lean Manufacturing das Konzept, welches auf Flow basiert.

Mit wachsender Bedeutung von Dienstleistungen und Software wanderten diese Ideen in die Wissensarbeit. Heute spricht man über Flow in Support-Tickets, Change Requests, Deployments und Design-Dokumenten. Donald G. Reinertsen hat die Idee von Flow ins 21. Jahrhundert für die Produktentwicklung übertragen. Sein Buch The Principles of Product Development Flow verbindet Lean, Ökonomie, Warteschlangentheorie und moderne Netzwerktechnik zu einem konsistenten Denkmodell für schnellere, wirtschaftlichere Entwicklung. Um diese Ideen und die 175 Flow-Prinzipien sind das Thema des folgenden Artikels.

Die Geschichte von Flow

Auf dieser Basis hat sich Flow von einem Produktionskonzept zu einem universellen Denkmodell für Wissensarbeit entwickelt. In der Produktentwicklung sind Tickets, Anforderungen, Architekturen oder Testfälle die Work Items. Agile Methoden und DevOps machen diesen Fluss sichtbar und messbar. Kanban-Boards, Durchlaufzeiten, Cumulative-Flow-Diagramme und Telemetrie in Betriebssystemen zeigen den Fluss der Arbeit.

Doch gerade klassisches Systems Engineering und Flow passen ohne Anpassung nicht wirklich zusammen: Phase Gates, zum Beispiel, blockieren den Flow.

Quality Gates: Don’t ask, don’t tell

Wenn ich Manager in meinen Produktentwicklungskursen befrage, geben 95 Prozent zu, dass sie mit dem Design beginnen, bevor sie alle Anforderungen kennen. Tatsächlich beginnt der durchschnittliche Produktentwickler mit dem Design, wenn 50 Prozent der Anforderungen bekannt sind. Sie geben dies jedoch nicht gegenüber dem Management bekannt. Stattdessen führen sie das altbewährte Ritual durch, um die Erlaubnis zum Weitermachen zu bitten. Es gibt eine stillschweigende „Don’t ask, don’t tell”-Politik. Manager vermeiden es höflich, zu fragen, ob die Aktivitäten der nächsten Phase bereits begonnen haben, und Entwickler vermeiden es diskret, zu erwähnen, dass sie bereits weitergemacht haben. In der Praxis herrscht trotz des Vorhandenseins eines dysfunktionalen formalen Verfahrens ein vernünftiges Verhalten vor.

Donald G. Reinertsen, in The Principles of Product Development Flow: Second Generation Lean Product Development

Das Buch

The Principles of Product Development Flow von Donald G. Reinertsen erschien 2009 und gilt inzwischen als Standardwerk für Flow in der Produktentwicklung.

Der Untertitel des Buchs ist: „Second generation lean product development“. Warum zweite Generation? Die erste Generation von Lean-Ansätzen übertrug vor allem Praktiken aus der Produktion: Verschwendung reduzieren, Prozesse standardisieren, „es beim ersten Mal richtig machen“. Reinertsen argumentiert, dass Produktentwicklung ein völlig anderes läuft als die Produktion: Hohe Unsicherheit, starke Variabilität, nicht wiederholbare Aufgaben, ungleich verteilte Verzögerungskosten. Eine zweite Generation von Lean muss deshalb ökonomisch begründet sein, statistisch fundiert, tolerant gegenüber Variabilität und konsequent auf Flow optimiert, nicht auf lokale Effizienz.

Das Herzstück des Buchs ist eine strukturierte Sammlung von 175 Flow-Prinzipien, gegliedert in acht Gruppen. Auf der Companion-Website lpd2.com sind alle Prinzipien aufgeführt, weshalb ich sie hier nicht wiederhole. Das Buch selbst lässt sich hervorragend als Nachschlagewerk und Checkliste nutzen.

Die Theorie: Denkfehler in der Produktentwicklung

Reinertsens Ausgangspunkt ist brutal ehrlich: Das dominante Paradigma für Produktentwicklung sei in seinen Grundannahmen falsch. Nicht ein bisschen, sondern fundamental.

Das dominante Paradigma für Produktentwicklung ist in seinen Grundannahmen fundamental falsch.

Donald G. Reinertsen, in The Principles of Product Development Flow: Second Generation Lean Product Development

Ein zentraler Denkfehler ist der Umgang mit Wertschöpfung. Viele Organisationen optimieren Proxy-Metriken: Auslastung, Termintreue, „% value-added time“. Was fast immer fehlt, ist eine explizite Quantifizierung von Wirtschaftlichkeit, insbesondere der Cost of Delay. Wer nicht weiß, was eine Woche Verzögerung kostet, kann weder Prioritäten sinnvoll setzen noch Warteschlangen beurteilen. Das Ergebnis sind Entscheidungen, die anhand von Bauchgefühl, politischer Durchsetzungskraft oder lokalen Optimierungen getroffen werden, aber nicht anhand von wirtschaftlichem Gesamtnutzen.

Der zweite große blinde Fleck sind Warteschlangen. In der Entwicklung gibt es riesige Bestände an angefangener, aber nicht fertiggestellter Arbeit: Specs in Review, Designs „Almost Done“, Tickets „In Progress“. Diese Work-in-Process-Bestände sind finanziell unsichtbar (sie stehen auf keinem Lagerkonto) und physisch unscheinbar (Bits auf Festplatten statt Paletten in der Halle). Hohe Auslastung und große WIP-Bestände wirken zunächst effizient, verlängern aber über Warteschlangen die Durchlaufzeit und treiben Risiken und Kontextwechselkosten in die Höhe.

Dritter Punkt: Variabilität wird fast immer als Problem betrachtet. Standardreaktion sind Checklisten, Stage-Gate-Prozesse, „best practices“ und im Extremfall Six-Sigma-Denken in der Entwicklung (und nicht Produktion, wo es durchaus Sinn macht). Reinertsen dreht das um: Ohne Variabilität gibt es keine Innovation. Entscheidend ist nicht, alle Varianz zu minimieren, sondern ihre wirtschaftlichen Folgen zu minimieren, zum Beispiel durch schnelle Feedback-Schleifen, Experimentieren mit kleinen Losgrößen oder das bewusste Verlegen von Variabilität in frühe, billigere Phasen.

Ohne Variabilität gibt es keine Innovation!

Donald G. Reinertsen, in The Principles of Product Development Flow: Second Generation Lean Product Development

Vierter Fehler: Wir managen Timelines statt Queues. Klassische Projektpläne zerlegen Arbeit in feinste Teilaufgaben mit festen Terminen. Jede Unsicherheit führt zu Puffern, jeder Puffer bläht den Plan weiter auf. Reinertsen argumentiert, dass es deutlich effektiver ist, WIP-Grenzen und Warteschlangen zu steuern als exakte Gantt-Diagramme zu pflegen. Wer seine Queues im Griff hat, bekommt Durchlaufzeiten quasi umsonst unter Kontrolle.

Die Prinzipien: Was bedeutet „Prinzip“?

Reinertsens „Prinzipien“ unterscheiden sich grundlegend von den wenigen, richtungsgebenden Leitprinzipien, wie ich sie in Product Velocity nutze. Sie geben keine normative Orientierung, sondern beschreiben wiederkehrende Mechanismen. Im Kern handelt es sich um systemische Gesetzmäßigkeiten oder Muster, die in der Produktentwicklung immer wieder sichtbar werden und die man verstehen muss, um fundierte Entscheidungen zu treffen.

Solche Aussagen lauten etwa: „Hohe Auslastung erzeugt überproportional wachsende Warteschlangen“ oder „Kleine Batches beschleunigen Feedback“. Das sind keine Kompass-Prinzipien, sondern Entscheidungsbausteine, die typische Ursache-Wirkungs-Zusammenhänge transparent machen.

In der Praxis nutzt man diese Gesetzmäßigkeiten wie Diagnosewerkzeuge. Bei einem Engpass untersucht man nicht reflexhaft die Kapazität, sondern prüft bekannte Einflussgrößen wie Warteschlangen, Varianz, Batch-Größen, WIP-Grenzen oder Feedback-Zyklen. Die Muster machen sichtbar, was im System tatsächlich passiert, und ermöglichen gezielte Eingriffe. Sie ersetzen nicht die Leitprinzipien, aber sie schärfen den Blick für die Mechanik des Flusses und helfen, Probleme strukturiert zu analysieren.

Im Folgenden ein Überblick über die acht Prinzipien-Gruppen und je ein exemplarisches Prinzip.

1. Ökonomische Prinzipien (21 Prinzipien)

Diese Gruppe sorgt dafür, dass Entscheidungen konsistent auf wirtschaftlichen Gesamtnutzen ausgerichtet sind, statt auf lokale Optima wie „maximale Auslastung“ oder „Minimal-Budget“. Typische Probleme in der Praxis: niemand kennt die Cost of Delay eines Projekts, Roadmaps werden nach „politischer Wichtigkeit“ priorisiert, späte Beschleunigungsaktionen sind extrem teuer, obwohl frühe Tempo-Gewinne viel günstiger wären.

Ein zentrales Prinzip lautet: „Wenn du nur eine Sache quantifizierst, quantifiziere die Cost of Delay.“ Wer weiß, was eine Woche Verzögerung kostet, kann Backlogs, Konflikte um Ressourcen und Eskalationen plötzlich sehr nüchtern beurteilen. In der Praxis heißt das: gemeinsam mit Produktmanagement und Controlling Szenarien durchrechnen (Marktfenster, Preisverfall, Vertragsstrafen), daraus einfache Entscheidungsregeln ableiten und diese Regeln dezentral verfügbar machen.

2. Warteschlangen-Prinzipien (16 Prinzipien)

Hier geht es darum, Warteschlangen sichtbar zu machen und gezielt zu steuern. Typische Probleme: Überlastete Spezialisten, Berge von „Work in Progress“, Projekte, die scheinbar ewig „in Arbeit“ sind. Viele Organisationen messen zwar Durchlaufzeiten, aber nicht die dahinterliegenden Queue-Größen und Auslastungen.

Ein repräsentatives Prinzip: „Wartezeit = Queue-Größe / Bearbeitungsrate“ (Little’s Law). Es ist erschreckend simpel: Verdoppelt sich der Stapel an Arbeit vor einem Team, verdoppelt sich im Schnitt die Wartezeit. In der Praxis lässt sich das nutzen, indem man explizite WIP-Limits einführt und visuell macht, wie viele Elemente vor einem Prozessschritt liegen. Statt die Auslastung nochmals auf 99 % zu treiben, reduziert man bewusst WIP und nimmt scheinbare „Leerlaufzeit“ in Kauf, um die Gesamtdurchlaufzeit deutlich zu verkürzen.

Dies ist übrigens ein Thema mit dem Joachim Pfeffer sich extrem gut auskennt.

3. Variabilitäts-Prinzipien (16 Prinzipien)

Diese Gruppe adressiert den Umgang mit Unsicherheit und Streuung: schwankende Ticketgrößen, unzuverlässige Lieferanten, schwankende Qualität von Requirements. Klassiker: Man versucht, alle Variabilität zu eliminieren, statt die ökonomisch relevante zu reduzieren.

Ein typisches Prinzip: „Variabilität kann wirtschaftlichen Wert schaffen.“ Wenn die positive Überraschung (z. B. ein erfolgreicher Prototyp) deutlich mehr wert ist als die negative (ein verworfener Versuch), dann lohnt sich experimentelles Vorgehen mit vielen kleinen Versuchen. Praktisch heißt das: kleinere, billigere Experimente, bewusst höhere „Failure Rates“ in frühen Phasen, Wiederverwendung, wo Varianz keinen Mehrwert bringt, und Puffer dort, wo die Konsequenzen von Varianz wirklich teuer sind.

4. Losgrößen-Prinzipien (22 Prinzipien)

Hier dreht sich alles um Batch Size: Wie viel Arbeit bündeln wir, bevor wir sie weitergeben oder freigeben? Klassische Muster sind riesige Requirements-Dokumente, große Design-Pakete oder seltene, riskante Releases. Große Batches wirken auf den ersten Blick effizient, verlangsamen aber Feedback und erhöhen Risiko.

Ein repräsentatives Prinzip: „Reduzierst du die Losgröße, verkürzt du die Durchlaufzeit und beschleunigst Feedback.“ In der Praxis bedeutet das: kleinere Requirements-Pakete, häufigere, automatisierte Builds, kontinuierliche Integration auch in Hardware-nahen Bereichen (z. B. frühe Prototypen), mehr „Slice-of-System“ statt „alles zuerst spezifizieren, dann alles designen“.

5. WIP-Begrenzungs-Prinzipien (23 Prinzipien)

Diese Prinzipien beschreiben, wie man Work-in-Process aktiv begrenzt, um Durchlaufzeit und Flow zu kontrollieren. Typische Probleme: zu viele parallel laufende Projekte, „Start-Stop-Start“-Kontextwechsel, technische Schulden, die nie abgebaut werden.

Ein exemplarisches Prinzip: „Begrenze WIP, um Durchlaufzeit zu kontrollieren.“ Statt noch ein Projekt zu starten, obwohl die bestehenden schon kämpfen, wird die Anzahl paralleler Initiativen gedeckelt. Auf Team-Ebene heißt das Kanban mit klaren WIP-Limits, auf Portfolio-Ebene eine harte Grenze für aktive Projekte. Oft genügt es, Projekte zu pausieren oder zu killen, die wirtschaftlich schwach sind, um massiv Tempo auf den wichtigen Streams zu gewinnen.

6. Flusssteuerungs-, Takt- und Synchronisations-Prinzipien (30 Prinzipien)

Diese Gruppe behandelt, wie Arbeit priorisiert, getaktet und synchronisiert wird: Welche Aufgabe kommt als nächstes dran? Wie vermeiden wir Überlastung? Wie koordinieren wir viele Teams? Klassische Probleme: zu viele Ad-hoc-Prioritäten, unvorhersehbare Meetings, Warteschlangen explodieren, wenn „alles gleichzeitig dringend“ ist.

Ein wichtiges Prinzip: „Wenn Dauer und Cost of Delay nicht homogen sind, nutze Weighted Shortest Job First (WSJF).“ Statt einfach „größtes Projekt zuerst“ oder „lauteste Stimme zuerst“ zu bedienen, sortiert man Arbeiten nach (Cost of Delay / Dauer). Kleinere, wirtschaftlich wichtige Jobs kommen nach vorne, große, wenig wertvolle nach hinten. In Verbindung mit festen Takten (z. B. zweiwöchentliche Planungszyklen, regelmäßige Synchronisations-Events) entsteht ein System, das mit Variabilität umgehen kann, ohne ins Chaos zu kippen.

7. Schnellrückkopplungs-Prinzipien (24 Prinzipien)

Hier geht es um Feedback-Schleifen: Wie schnell merken wir, dass wir falsch liegen? Wie früh sehen Kunden etwas? Wie schnell schlägt ein Problem im Feld auf die Entwicklung durch? Typische Probleme: lange Review-Zyklen, späte Tests, Metriken, die nur „nach dem Projekt“ ausgewertet werden.

Ein repräsentatives Prinzip: „Schnelles Feedback ermöglicht schnelleres Lernen.“ Praktisch heißt das: frühe Tests auf Prototyp-Niveau, regelmäßige Demos, Telemetrie im Feld, A/B-Tests, kurze Build- und Testzyklen. Wichtig ist, Feedback ökonomisch zu betrachten: Es lohnt sich, einmal mehr zu testen, wenn dadurch teure Fehlentscheidungen vermieden werden, aber eben nicht jede Abweichung dogmatisch zu korrigieren, wenn der wirtschaftliche Impact gering ist.

8. Dezentralisierungs-Prinzipien (23 Prinzipien)

Die letzte Gruppe behandelt die Frage, wer eigentlich entscheidet. Vollständige Zentralisierung schafft vielleicht formale Konsistenz, ist aber langsam und blind für lokale Informationen. Vollständige Dezentralisierung führt zu Chaos. Reinertsen orientiert sich hier stark an moderner Militärdoktrin: klare Ausrichtung, dezentrale Initiative.

Ein wichtiges Prinzip: „Beschreibe Mission und Randbedingungen, nicht den detaillierten Plan.“ Statt zu definieren, wie Teams jedes Detail umzusetzen haben, legt das Management fest, warum etwas wichtig ist, welches Ergebnis erwartet wird und welche Grenzen gelten (Budget, Zeit, regulatorische Vorgaben). Teams entscheiden dann lokal, welche Maßnahmen im Sinne von Flow und Ökonomie sinnvoll sind. Das setzt Vertrauen, Transparenz und einfache Entscheidungsregeln voraus, zahlt sich aber in Reaktionsgeschwindigkeit und Anpassungsfähigkeit massiv aus.

Fazit: Wie man die 175 Flow-Prinzipien nutzen kann

Reinertsens Buch ist nichts für die schnelle Abendlektüre, aber ein extrem ergiebiger Werkzeugkasten. Am besten nutzt man die 175 Flow-Prinzipien nicht als Theorie-Sammlung, sondern als praktische Checkliste: Wo brechen bei uns Flow-Prinzipien? Wo ignorieren wir Warteschlangen? Wo optimieren wir lokale Effizienz statt wirtschaftlichen Gesamtnutzen?

Die Companion-Website gibt einen schnellen Überblick über die Prinzipien, aber wer tiefer einsteigen will, kommt am Buch selbst nicht vorbei. The Principles of Product Development Flow liefert nicht nur die 175 Prinzipien, sondern auch die zugrunde liegende Ökonomie, Beispiele und typische Fallstricke. Für Organisationen, die ernsthaft an ihrer Produktentwicklungsgeschwindigkeit arbeiten wollen, ist es ein Referenzwerk und eine Einladung, das eigene Denken über Flow grundlegend zu überarbeiten.

Image: Vivek Gupta