Wenn Organisationen \u201eagil skalieren\u201c wollen, reden sie schnell \u00fcber Rollen, Events und Tools. Das klingt nach Kontrolle. Und genau dort beginnen viele Transformationen zu scheitern. Denn Skalierung ist zuerst eine Frage von Fluss<\/strong>. Und Fluss entsteht nicht durch mehr Prozess, sondern durch bessere Entscheidungen im System.<\/p>\n\n\n\n Donald G. Reinertsens The Principles of Product Development Flow<\/em> (2009) ist kein \u201eLean-Buch\u201c. Es ist ein Wirtschaftsbuch \u00fcber Produktentwicklung<\/strong>. Reinertsen zeigt, warum Warteschlangen (Queues) die unsichtbare Hauptursache f\u00fcr schlechte Performance sind. Und warum \u201eAuslastung maximieren\u201c in wissensbasierter Arbeit fast immer zu l\u00e4ngerer Durchlaufzeit f\u00fchrt. (Google Books<\/a>)<\/p>\n\n\n\n SAFe \u00fcbernimmt diese Denkschule sehr direkt. Besonders sichtbar ist das in SAFe Principle #1 \u201eTake an economic view\u201c, das Reinertsen ausdr\u00fccklich zitiert. (Scaled Agile Framework<\/a>) Und ebenso in SAFe Principle #6 \u201eMake value flow without interruptions\u201c mit Fokus auf WIP-Limits<\/strong> und Bottlenecks<\/strong>. (Scaled Agile Framework<\/a>)<\/p>\n\n\n\n Wo wirkt Reinertsen\/SAFe am st\u00e4rksten?<\/strong><\/p>\n\n\n\n Kurz: Reinertsen macht aus \u201eAgil\u201c eine messbare Fluss-\u00d6konomie<\/strong>.<\/p>\n\n\n\n Goldratts The Goal<\/em> (1984) und die Theory of Constraints (TOC) liefern das mentale Betriebssystem f\u00fcr DevOps: Jedes System hat (zu einem Zeitpunkt) einen dominanten Engpass. Optimiere alles andere, und du optimierst oft nur lokal.<\/strong> (Theory of Constraints Institute<\/a>)<\/p>\n\n\n\n Dass TOC zu den \u201eunterpinning principles\u201c von DevOps geh\u00f6rt, wird in der DevOps-Welt explizit gemacht. IT Revolution beschreibt The Phoenix Project<\/em> als Einf\u00fchrung in DevOps und<\/strong> TOC als tragende Prinzipien. (IT Revolution<\/a>)<\/p>\n\n\n\n Wo wirkt TOC\/DevOps am st\u00e4rksten?<\/strong><\/p>\n\n\n\n SAFe ist stark, wenn es darum geht, Entscheidungen, Struktur und Alignment<\/strong> \u00fcber viele Teams zu organisieren. Reinertsen liefert daf\u00fcr die \u00f6konomische Logik des Flusses. TOC ist stark, wenn es darum geht, die eine Stellschraube<\/strong> zu finden, die gerade den Durchsatz begrenzt. DevOps operationalisiert das in t\u00e4glichen Praktiken.<\/p>\n\n\n\n Wer beides kombiniert, bekommt keine \u201eMethoden-Suppe\u201c, sondern ein klares System: Zwei Ideen, zwei Hebel: Warum SAFe ohne Reinertsen und DevOps ohne Goldratt \u00e4rmer w\u00e4re Wenn Organisationen \u201eagil skalieren\u201c wollen, reden sie schnell \u00fcber Rollen, Events und Tools. Das klingt nach … <\/p>\nSAFe und Reinertsen: Flow als \u00f6konomische Disziplin<\/h3>\n\n\n\n
\n
DevOps und Goldratt: Die Engpass-Logik als Betriebssystem<\/h3>\n\n\n\n
\n
Die Synthese: SAFe setzt den Takt. TOC entscheidet, wo du hinschaust.<\/h3>\n\n\n\n
\u00d6konomie des Flusses (Reinertsen\/SAFe) + Engpassfokus (Goldratt\/TOC) = schnelle, stabile Lead-Time-Verbesserung.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"