Zwei Ideen, zwei Hebel: Warum SAFe ohne Reinertsen und DevOps ohne Goldratt ärmer wäre
Wenn Organisationen „agil skalieren“ wollen, reden sie schnell über Rollen, Events und Tools. Das klingt nach Kontrolle. Und genau dort beginnen viele Transformationen zu scheitern. Denn Skalierung ist zuerst eine Frage von Fluss. Und Fluss entsteht nicht durch mehr Prozess, sondern durch bessere Entscheidungen im System.
SAFe und Reinertsen: Flow als ökonomische Disziplin
Donald G. Reinertsens The Principles of Product Development Flow (2009) ist kein „Lean-Buch“. Es ist ein Wirtschaftsbuch über Produktentwicklung. Reinertsen zeigt, warum Warteschlangen (Queues) die unsichtbare Hauptursache für schlechte Performance sind. Und warum „Auslastung maximieren“ in wissensbasierter Arbeit fast immer zu längerer Durchlaufzeit führt. (Google Books)
SAFe übernimmt diese Denkschule sehr direkt. Besonders sichtbar ist das in SAFe Principle #1 „Take an economic view“, das Reinertsen ausdrücklich zitiert. (Scaled Agile Framework) Und ebenso in SAFe Principle #6 „Make value flow without interruptions“ mit Fokus auf WIP-Limits und Bottlenecks. (Scaled Agile Framework)
Wo wirkt Reinertsen/SAFe am stärksten?
- Portfolio- und Entscheidungs-Ebene (LPM): Priorisierung nach Ökonomie statt nach Meinungen. Cost of Delay und WSJF sind genau diese Übersetzung von „Wert“ in „Zeit-Kosten“. Reinertsen prägte WSJF, SAFe nutzt eine angepasste Variante. (Projektmanagement Institut)
- Value-Stream-/ART-Ebene: Fluss steuern. WIP begrenzen. Engpässe sichtbar machen. Cadence für Synchronisation.
- Team-Ebene: Kleine Batch Sizes, schnelles Feedback, aktiv gemanagte Warteschlangen. Nicht „mehr starten“, sondern „mehr fertigstellen“.
Kurz: Reinertsen macht aus „Agil“ eine messbare Fluss-Ökonomie.
DevOps und Goldratt: Die Engpass-Logik als Betriebssystem
Goldratts The Goal (1984) und die Theory of Constraints (TOC) liefern das mentale Betriebssystem für DevOps: Jedes System hat (zu einem Zeitpunkt) einen dominanten Engpass. Optimiere alles andere, und du optimierst oft nur lokal. (Theory of Constraints Institute)
Dass TOC zu den „unterpinning principles“ von DevOps gehört, wird in der DevOps-Welt explizit gemacht. IT Revolution beschreibt The Phoenix Project als Einführung in DevOps und TOC als tragende Prinzipien. (IT Revolution)
Wo wirkt TOC/DevOps am stärksten?
- Operations- und Delivery-Systeme: Deployment-Pipeline, Incident-Flow, Service-Delivery. Engpass finden. Exploit. Subordinate. Dann erst „elevate“.
- End-to-End Value Streams: Nicht einzelne Teams beschleunigen, sondern den Fluss vom Commit bis Production stabilisieren. Das passt auch zu modernen Value-Stream-Mapping-Ansätzen, die explizit das Identifizieren von Constraints fördern. (AWS-Dokumentation)
- Führung: Fokus erzwingen. Schutz vor Überlast. Entscheidungen entlang des Engpasses ausrichten.
Die Synthese: SAFe setzt den Takt. TOC entscheidet, wo du hinschaust.
SAFe ist stark, wenn es darum geht, Entscheidungen, Struktur und Alignment über viele Teams zu organisieren. Reinertsen liefert dafür die ökonomische Logik des Flusses. TOC ist stark, wenn es darum geht, die eine Stellschraube zu finden, die gerade den Durchsatz begrenzt. DevOps operationalisiert das in täglichen Praktiken.
Wer beides kombiniert, bekommt keine „Methoden-Suppe“, sondern ein klares System:
Ökonomie des Flusses (Reinertsen/SAFe) + Engpassfokus (Goldratt/TOC) = schnelle, stabile Lead-Time-Verbesserung.
