Engpasstheorie
Warum die Verbesserung des Engpasses wichtig ist – und alles andere nicht.
1Die Theory of Constraints
In den 1980er Jahren entwickelte Eli Goldratt die Theory of Constraints (TOC). Die zentrale Erkenntnis ist einfach, aber tiefgreifend:
Jedes System hat einen Engpass – einen Schritt, der den Durchsatz des Ganzen begrenzt.
Denken Sie an eine Autobahn: Wenn eine Strecke verstopft ist, verlangsamt sich die gesamte Autobahn. Das Verbreitern der freien Strecken hilft nicht. Sie müssen die verstopfte Strecke beheben.
Dasselbe gilt für Wertströme. Wenn Code Review der Engpass ist, führt schnellere Entwicklung nur zu einem größeren Stapel beim Code Review. Wenn Testing der Engpass ist, bedeutet die Einstellung weiterer Entwickler nur mehr Arbeit, die auf QA wartet.
Das System kann nur so schnell sein wie sein langsamster Engpass.
Dies hat weitreichende Auswirkungen auf Verbesserungen: Die Verbesserung von allem, was nicht der Engpass ist, ist Theater. Es mag sich produktiv anfühlen, hat aber keine Auswirkung auf den Gesamtdurchsatz.
Die Fokussierungskraft
TOC sagt Ihnen genau, worauf Sie sich konzentrieren müssen: den Engpass. Ignorieren Sie alles andere, bis der Engpass beseitigt ist. Dann finden Sie den neuen Engpass und wiederholen Sie den Vorgang. Dies verhindert die häufige Falle, überall zu optimieren, ohne Ergebnisse zu erzielen.
2Den Engpass finden
Wie finden Sie den Engpass? Suchen Sie nach der Stelle, an der sich Bestand (Arbeit) anhäuft.
Der Engpass hat einen Stapel wartender Arbeit vor sich. Wenn Code Review immer einen Rückstand hat, ist Code Review wahrscheinlich der Engpass. Wenn Testing wochenlang Arbeit in der Warteschlange hat, ist Testing wahrscheinlich der Engpass.
Weitere Anzeichen für Engpässe:
- Hohe Auslastung: Der Engpass ist maximal ausgelastet
- Ständiger Druck: Menschen in der Engpassphase sind immer gehetzt
- Nachgelagerte Unterversorgung: Phasen nach dem Engpass warten auf Arbeit
- Vorgelagerte Frustration: „Wir sind fertig, warum bewegt es sich nicht?"
Häufige Software-Engpässe:
- Code Review (zu wenige Reviewer, große PRs)
- Testing (manuelles QA, begrenzte Testabdeckung)
- Deployment (komplexe Releases, begrenzte Deployment-Fenster)
- Architekturentscheidungen (Warten auf den Architekten)
- Produktentscheidungen (Warten auf den Product Owner)
Hinweis: Der Engpass ist oft keine „produktive" Phase. Es könnte ein Entscheidungsträger sein. Es könnte ein Genehmigungsprozess sein. Es könnte eine gemeinsam genutzte Ressource sein.
Ein Team misst und stellt fest, dass sich Arbeit beim Deployment ansammelt. Nur eine Person weiß, wie man deployed. Sie hat Zeit für ein Deployment pro Woche. Alles andere wartet. Lösung: Deployment automatisieren und das Wissen verbreiten. Der Durchsatz verdoppelt sich.
Das Management sieht Entwickler als „unterausgelastet" (90 % vs. 100 %) und weist mehr Arbeit zu. Entwickler beschleunigen. Aber Deployment ist der Engpass – es ist immer noch einmal pro Woche. Die Durchlaufzeit verbessert sich nicht. Der Bestand vor dem Deployment wächst.
3Engpässe ausnutzen und erweitern
TOC schreibt einen fünfstufigen Prozess vor:
1. Engpass identifizieren: Finden Sie heraus, wo sich Arbeit anhäuft.
2. Engpass ausnutzen: Maximieren Sie den Durchsatz durch den Engpass, ohne Ressourcen hinzuzufügen. Wenn Code Review der Engpass ist, priorisieren Sie Reviews vor neuer Entwicklung. Stellen Sie sicher, dass Reviewer nicht abgelenkt werden. Reduzieren Sie die PR-Größe, damit Reviews schneller gehen.
3. Alles andere unterordnen: Nicht-Engpässe sollten dem Engpass dienen. Wenn QA der Engpass ist, drängen Sie nicht mehr Arbeit in QA – passen Sie die Entwicklung an die QA-Kapazität an.
4. Engpass erweitern: Wenn Ausnutzung und Unterordnung nicht ausreichen, fügen Sie dem Engpass Kapazität hinzu. Schulen Sie mehr Reviewer. Automatisieren Sie Tests. Stellen Sie mehr von der eingeschränkten Fähigkeit ein.
5. Wiederholen: Sobald Sie einen Engpass beseitigt haben, entsteht ein anderer. Der Engpass verschiebt sich. Finden Sie ihn und wiederholen Sie den Vorgang.
Dies ist iterative, kontinuierliche Verbesserung. Sie konzentrieren sich immer auf den aktuellen Engpass, nicht verstreut über alle Phasen.
Die Drum-Buffer-Rope-Metapher: Der Engpass ist die „Trommel", die das Tempo vorgibt. Arbeit vor dem Engpass ist der „Puffer". Das „Seil" zieht Arbeit in das System im Tempo, das der Engpass bewältigen kann – nicht schneller.
Der wandernde Engpass
Wenn Sie einen Engpass beseitigen, wird eine andere Phase zum neuen Engpass. Das ist normal. Aber wenn der Engpass zufällig wandert (manchmal Dev, manchmal QA, manchmal Deploy), ist Ihr System instabil. Stabilisieren Sie zuerst, dann optimieren Sie.
- Jedes System hat einen Engpass, der den Gesamtdurchsatz begrenzt
- Die Verbesserung von Nicht-Engpässen hilft dem System nicht
- Finden Sie den Engpass, indem Sie schauen, wo sich Arbeit anhäuft
- Nutzen Sie den Engpass aus, bevor Sie Kapazität hinzufügen
- Wenn Sie einen Engpass beseitigen, entsteht ein anderer – wiederholen Sie den Vorgang