Wie Sie mit einer fast vergessenen Methode in der Agilen Softwareentwicklung die Effizienz steigern und die Lieferzeit verkürzen

In einer äußerst wettbewerbsintensiven und sich ständig verändernden Umgebung ist es von entscheidender Bedeutung, dass Ihre IT-Abteilung einen transparenten und kontinuierlichen Fluss hochwertiger, kundenorientierter IT-Anwendungen sicherstellt.

In diesem Blog-Beitrag zeigen wir Ihnen, wie Sie mit dem Konzept von Drum-Buffer-Rope die Effizienz Ihrer Softwareentwicklungsteams steigern und die Lieferzeiten verkürzen können. Ziel des Ansatzes ist es, die Qualität, Zuverlässigkeit und Kundenzufriedenheit zu steigern und eine stressfreiere Arbeitsweise zu fördern.

Eliyahu M. Goldratt wurde in den 1980er Jahren durch seinen Bestseller “Das Ziel” und als Erfinder der Engpass-Theorie bekannt. Er vertritt die Managementphilosophie, dass kein Unternehmen mehr Arbeit übernehmen sollte, als sein Engpass verarbeiten kann.

Stellen Sie sich eine Autobahn mit einer Baustelle, dem Engpass, vor. Je mehr Autos vor der Baustelle sind, desto höher ist die Wahrscheinlichkeit, dass ein Stau entsteht. Laut Straßenverkehrsordnung gilt zwar das Reißverschlussverfahren, und die Fahrer sollten sich gegenseitig kurz vor der Baustelle einfädeln.

Doch haben Sie es schon einmal erlebt, dass dies optimal funktioniert? Meistens ist es doch so, dass einige Fahrer aggressives Verhalten zeigen und versuchen, sich vorzudrängeln, anstatt in der Reißverschluss-Reihenfolge zu wechseln. Es kommt zu Missverständnissen darüber, wer als Nächster an der Reihe ist, was zu Verwirrung und Verzögerungen führen kann. Im Endergebnis entsteht ein Stau.

Genauso verhält es sich im Geschäftsleben. In jedem Softwareentwicklungsprojekt gibt es einen Engpass, der die Entwicklung verzögert. Bei der Engpass-Ressource stapeln sich die Anfragen und Aufträge. Meist erkennt man es daran, dass es schwierig ist, mit dieser Person oder diesem Personenkreis wegen eines vollen Terminkalenders Termine zu bekommen. In einem Scrum-Team könnte das beispielsweise der Product Owner sein. Oft ist es auch so, dass das gesamte Entwicklungsteam der Engpass ist, insbesondere dann, wenn das Team ein sehr großes Backlog mit vielen Produktideen besitzt.

Zurück zum Autobahn-Beispiel: Fragen wir uns, wie viele Autos in einer idealen Welt optimal auf die Autobahn gelassen werden sollten, um den Spitzenverkehrsfluss zu erreichen? Die Antwort liegt auf der Hand, wenn man die Situation von oben betrachtet.

Die optimale Anzahl ankommender Autos ist so groß, dass sie die Baustelle mit konstanter Geschwindigkeit passieren können. Doch kann dieses Gedankenexperiment auch auf die Software-Entwicklung übertragen werden?

Mit dem Drum-Buffer-Rope-Konzept kann man genau dies leisten. Das Konzept stammt ursprünglich aus der Produktionssteuerung. Eliyahu M. Goldratt spricht von Produktion, wenn der Anteil der tatsächlichen Arbeitszeit (Touch Time) im Vergleich zur Gesamtdauer (Lead Time) weniger als 10% beträgt. Agile Teams ähneln in gewisser Weise Produktionsfabriken, wenn man sich den typischen Produktionsprozess betrachtet.

Stellen Sie sich die Produktion eines elektrischen Geräts vor. Das Produkt entsteht aus einer Vielzahl kleiner Einzelteile, wie etwa dem Motor oder der Verkabelung. Für jedes dieser Teile besteht der Großteil der Zeit aus Warten. Warten in Kisten, dann Transportieren, Herausnehmen, kurzes Bearbeiten, Zurücklegen in eine Kiste, wieder Transportieren und so weiter. Zwischen diesen Arbeitsschritten entstehen oft recht lange Wartezeiten.

Doch dieser Ansatz, auch wenn er auf den ersten Blick negativ erscheinen mag, bietet erhebliche Vorteile. Dank der kurzen Bearbeitungszeit für die einzelnen Teile kann man die Zeiten recht genau schätzen. Wenn eine Arbeitszeit länger dauert, gleicht sie sich oft durch die Verkürzung einer anderen aus – das hat nur geringe Auswirkungen auf das Endergebnis. Durch die langen Wartezeiten zwischen den Schritten können wir die Reihenfolge der Teile vor jedem Arbeitsschritt flexibel anpassen, um Terminzusagen einzuhalten. Der Vorrat an Teilen (Work-In-Progress, WIP) lässt sich leicht kontrollieren, da er stets im Blick ist. Die Steuerung des Produktionsprozesses ist unkompliziert, stabil und erfordert nur geringen Aufwand bei der Planung.

Schauen wir uns nun agile Methoden, wie Scrum, an. So erkennen wir, dass sie im Grunde genommen Produktionssteuerung sind – kleine Teilaufgaben (User Stories), die unabhängig sind (nach dem INVEST-Kriterium) und typischerweise in einem Backlog auf ihre Bearbeitung warten.

Da sich in der agilen Softwareentwicklung bereits produktionsähnliche Situationen ergeben, ist es durchaus sinnvoll, bewährte Konzepte aus der Produktionssteuerung zu adaptieren. Denn das Hauptziel sowohl in der Produktionssteuerung als auch beim Lean und Agile Project Management besteht darin, den Work-in-Progress (teilweise fertige Anforderungen und Waren, die auf ihre finale Fertigstellung warten) so zu begrenzen, dass der Fluss und Durchsatz optimal werden – ähnlich wie wir das im Autobahn-Beispiel gesehen haben.

Drum-Buffer-Rope ist ein Produktionsplanungssystem, das von Eliyahu M. Goldratt entwickelt wurde und auf der Theory of Constraints basiert. Es basiert auf der Annahme, dass in einem Wertstrom über einen längeren Zeitraum hinweg ein konstanter Engpass besteht. Dieser Engpass wird genutzt, um die Steuerung zu vereinfachen und den Durchsatz zu optimieren.

Um dieses Konzept zu veranschaulichen, betrachten wir eine Pfadfindergruppe, die gemeinsam am Abend in einem Zeltlager ankommen möchte. Die Herausforderung besteht darin, dass einer der Pfadfinder, Herbie genannt, der langsamste ist. Er stellt den Engpass dar, der dazu führt, dass die Gruppe immer wieder Pausen einlegen muss, um auf Herbie zu warten und sich neu zu organisieren.

Die Gruppe muss ihr Tempo nach Herbie richten. Dafür bekommt Herbie eine Trommel (“Drum”), die er in seinem eigenen Tempo schlägt. Alle anderen Pfadfinder müssen im Einklang mit dem Rhythmus dieser Trommel gehen, auch wenn einige von ihnen aufgrund ihrer längeren Beine schneller wären.

Dieses Konzept basiert auf der Theorie, dass es kontraproduktiv und bestenfalls ineffizient ist, die Auslastung von Ressourcen, die nicht den Engpass darstellen, zu maximieren. Die Hauptaufgabe besteht daher darin, sicherzustellen, dass die Engpassressource optimal ausgelastet wird. Am Engpass wird gewissermaßen der Takt vorgegeben – dies entspricht dem Schlagen der “Trommel”. Alle Planungs- und Steuerungsmaßnahmen sollten sich nach dem Engpass richten.

In einem Softwareentwicklungsprojekt sind typischerweise die Entwickler diejenigen, die die eigentliche Arbeit der Softwareentwicklung ausführen. Sie setzen die Anforderungen und Spezifikationen um und schreiben den Code. Daher bestimmen sie maßgeblich das Arbeitstempo und den Fortschritt des Projekts. Letztendlich ist das Endprodukt eines Softwareprojekts der Code, den die Entwickler erstellen. Die Qualität und Geschwindigkeit ihrer Arbeit haben einen direkten Einfluss auf den Projekterfolg.

Vor Herbie muss stets ein gewisser Abstand eingehalten werden; es muss ein Puffer (“Buffer”) eingerichtet werden. Der Grund hierfür ist einfach: Wenn Herbie stehenbleibt, kann die Gruppe diese Unterbrechung nicht mehr aufholen, da Herbie der Langsamste in der Gruppe ist. Selbst wenn der Pfadfinder vor Herbie anhält, um beispielsweise seinen Schuh zu binden, muss der Puffer groß genug sein, damit der pausierende Pfadfinder seine Aktivität abschließen kann, bevor Herbie zu ihm aufschließt.

In Softwareentwicklungsprojekten mit verschiedenen voneinander abhängigen Teams, wie beispielsweise einem Team von Business Analysten aus dem Fachbereich und einem Scrum-Team von Softwareentwicklern, sind Störungen trotz größter Sorgfalt unvermeidlich. Dennoch ist es von größter Wichtigkeit sicherzustellen, dass diese Störungen nicht bis zum Engpass vordringen und die Auslastung dort beeinträchtigen.

Genau aus diesem Grund wird ein Puffer (“Buffer”) vor dem Engpass eingerichtet. In diesem Zusammenhang könnte der Puffer beispielsweise bedeuten, dass der Product Owner immer über eine ausreichende Anzahl an vorab mit den Business Analysten sehr gut geklärten User Stories verfügt. Dies dient dazu, sicherzustellen, dass das Entwicklerteam stets über ausreichend Arbeit verfügt, da es nichts Schlimmeres gibt, als wenn ein Entwicklerteam ohne Aufgaben dasteht.

Sowohl der Pfadfinder vor Herbie als auch Herbie selbst könnten plötzlich auf Probleme stoßen, die sie aufhalten. Wenn Herbie also seine Schuhe binden muss, geht ohnehin Zeit für die ganze Gruppe verloren. Da das Ziel erst erreicht ist, wenn alle Pfadfinder es erreichen, ergibt es keinen Sinn, dass die vor Herbie gehenden Pfadfinder schneller als Herbie gehen und die Gruppe auseinanderziehen, wenn es zu einer Unterbrechung durch Herbie kommt. Um solche Situationen zu verhindern, nutzt Goldratt ein Seil (“Rope”). Die Pfadfinder befestigen ein Ende des Seils am Bauch von Herbie und das andere Ende am Bauch des ersten Pfadfinders in der Gruppe. Wenn also Herbie anhält, hält die gesamte Gruppe an.

In der Anwendung des Drum-Buffer-Rope-Konzepts in der Softwareentwicklung wird nach Abschluss einer Aufgabe am Engpass unverzüglich eine neue Aufgabe gestartet. Dieser Prozess wird als “Seil” bezeichnet. Man könnte es auch als Ventil bezeichnen. Konkret bedeutet dies, dass, sobald unsere Engpass-Ressourcen, also die Entwickler, eine Anforderung abgeschlossen haben, der Product Owner zusammen mit den Business Analysten neue Ideen in Form von User Stories für die Entwicklung starten kann. Das “Seil” dient als Signal, das anzeigt, wann neue Anforderungen in die Entwicklungsphase übergeben werden sollen.

Ein Nebeneffekt dieses Mechanismus ist es, dass der Product Owner zusammen mit seinen Kollegen aus dem Fachbereich immer eine ausreichende Anzahl an fertigen User Stories bereithält. Es wird nie zu viel und nie zu wenig in der Analysephase vorgearbeitet. Im Endergebnis erhalten Sie ein überschaubares Backlog.

Im Product-Backlog sind nur Features enthalten, für die der Kunde bereit ist zu bezahlen und die Ressourcen zur Verfügung stellt. Alles andere wird in einem Ideenspeicher aufbewahrt und hier nicht berücksichtigt. Die Features im Product-Backlog sind in einer eindeutigen Reihenfolge angeordnet, die vom Product Owner festgelegt wird.

Vom Backlog aus wird eine Prozesskette definiert, typischerweise lautet sie in der Softwareentwicklung Konzeption, Umsetzung, Integration, Tests und Produktivsetzung. Im Rahmen von Drum-Buffer-Rope wird angenommen, dass eine dieser Stufen (bzw. die entsprechenden

Experten) der Engpass ist. In einem Kanban-Board, das die Prozesskette abbildet, erkennt man den Engpass daran, dass vor sich der entsprechenden Spalte die Items stapeln.

Ein einfaches Modell von DBR könnte sein, dass, sobald der Puffer an Features auf 2/3 der festgelegten Menge absinkt, entsprechend neue Features in die Pipeline aufgenommen werden.

Das Monitoring besteht aus einem ““aggregiertes Input-Output-Diagramm“, oder manchmal auch „Flussdiagramm“ genannt. Das Ziel ist es, den Bestand (Differenz zwischen Ein- und Ausgangslinie, im Beispiel New und Completed) so niedrig wie möglich zu halten.

Rapid-Response (RR)-Aufträge, wie beispielsweise Bugfixing oder Incidents, können mit festen Bearbeitungszeiten versehen werden. Für diese RR-Aufträge wird ein bestimmter Anteil der Kapazität der Engpasstufe reserviert. Falls diese Kapazität nicht vollständig genutzt wird, kann sie den normalen Aufträgen zugutekommen.

Um Lieferdaten vorherzusagen, wird für jedes Feature der Zeitbedarf pro Prozessstufe geschätzt. Es gibt verschiedene Ansätze für diese Schätzungen, darunter die 3-Punkt-Schätzung mit Wahrscheinlichkeiten, eine verhältnismäßige Berechnung in Bezug auf den Entwicklungsaufwand oder eine festgelegte Vorgabe bei gleichförmigen Prozessstufen.

Die Engpassstufe spielt eine entscheidende Rolle bei der Planung.

Alle Bearbeitungszeiten der Features in dieser Stufe werden anhand der Kapazität pro Zeiteinheit ermittelt und als „Planned Load“ bezeichnet. Das Produktionsdatum oder Due-Date eines Features setzt sich zusammen aus dem geplanten Ende in der Engpassstufe, der geplanten Downstream-Dauer und einem Sicherheitspuffer. "Downstream" bezieht sich auf die nachfolgenden Schritte oder Arbeitsschritte, die nach dem aktuellen Punkt im Prozess kommen.

Das Startdatum der Entwicklung eines Features wird aus dem geplanten Start in der Engpassstufe abzüglich der geplanten Upstream-Dauer berechnet. "Upstream" bezieht sich auf die vorherigen Schritte oder Arbeitsschritte, die zu einem bestimmten Punkt im Prozess führen. Im Falle eines sprintorientierten Vorgehens wird auf den Beginn des passenden Sprints abgerundet. Die Kapazitäten der Nicht-Engpasstufen werden so eingestellt, dass sie in der Regel die Durchlaufzeit nicht beeinflussen.

Diese Methode ermöglicht eine zuverlässige Vorhersage von Lieferterminen und hilft, die Ressourcen effizient zu planen und zu nutzen.

Unternehmen, die die Theory of Constraints auf ihre Abläufe angewendet haben, können beeindruckende Ergebnisse vorweisen. Eine Metaanalyse von 80 Fallstudien zeigte, dass die Durchlaufzeit im Durchschnitt um erstaunliche 75 Prozent reduziert wurde. Gleichzeitig führte dies zu Umsatzsteigerungen von 39 Prozent und einer verbesserten Termintreue um 50 Prozent.

Klingt das für Sie interessant? Wenn Sie mehr über die Tools und Methoden im Bereich Softwareentwicklung im Kontext der Theory of Constraints erfahren möchten, empfehlen wir Ihnen, unsere weiteren Blogbeiträge zu diesem Thema zu lesen.

Alternativ dazu können Sie noch heute ein kostenloses Beratungsgespräch mit unseren Experten vereinbaren. Dr. Dietmar G. Wiedemann, Berater und Vorstand der Proventa AG, ist Teil der globalen Dolphin Universe Community, die Methoden entwickelt, um Engpässe zu identifizieren und optimal zu managen.

Sie möchten lernen wie Sie diese Methode anwenden können? 

Unser Anspruch ist es, Ihnen die effektivste Agile Coaching Ausbildungen Europas anzubieten.

So sind Sie nach der Ausbildung in der Lage, Menschen, Teams und Unternehmen integral als agiler Coach zu begleiten und ihr persönliches und professionelles Potential zu entfalten.

Eliyahu M. Goldratt: Das Ziel. Campus, Frankfurt 2000.

Eliyahu M. Goldratt: Standing on the Shoulders of Giants: Production concepts versus production applications. The Hitachi Tool Engineering example, Goldratt Consulting, 2008

Steven Balderstone; Victoria Mabin: The performance of the theory of constraints methodology: Analysis and discussion of successful TOC applications. In: International Journal of Operations & Production, 2003.

Wolfram Müller: Drum-Buffer-Rope in der agilen Softwareentwicklung als Alternative zu Kanban und Scrum, 2012

Wolfram Müller: Hybrid ist Pflicht mit Ultimate/Reliable Scrum und Critical Chain zu einer hochskalierbaren agilen Projektorganisation. In: Martin Engstler et. al. (Hrsg.): Projektmanagement und Vorgehensmodelle; Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2015

Dr. Dietmar Wiedemann

Dr. Dietmar Georg Wiedemann ist Vorstand in der Proventa AG. Sein Fokus liegt im Bereich Agile Project Management und Agile Transformationen. Als Agile Coach und ScrumMaster steht er für die stetige Verbesserung des Geschäftsnutzens unserer Kunden. Er ist Motor für Veränderungen und Anpassungen in der Organisation und lebt dabei die agilen Werte Fokus, Commitment, Respekt, Mut und Offenheit vor.