Wenn Sie sich für Kanban interessieren, dann haben Sie sicher auch Interesse an Scrum? Wenn ja könnte "Reliable Scrum" für Sie interessant sein. Alle Vorteile von Scrum kombiniert mit der Zuverlässigkeit von Critical Chain.

Sind Sie in Projekte involviert? Kennen Sie es auch, dass nicht alle Projekte glatt laufen? Wenn ja dann schauen Sie sich mal Critical Chain an!

Critical Chain setzt auf dem bestehenden Projektmanagement auf und erweitert dieses um zwei einfache Regelmechanismen. Drei einfache Tricks und schon fließen die Projekte wieder.

Überzeugen Sie sich selbst! Hier ein paar Erfolgsgeschichten unserer Kunden. Oder testen sie einfach schnell das Potential, das in Ihrem Unternehmen schlummert.

Drum-Buffer-Rope als bessere Alternative zu Scrum und Kanban >>> ultimate Scrum

"meine" Top 5 der agilen Entwicklungsmethoden:

Aktuell gibt es vor allem im IT-Projektmanagement eine starke Bewegung hin zu Fertigungs-steuerungen. Die bekanntesten Vertreter hier sind Scrum und Kanban. Die Erfolge sprechen für sich - deutlich höherer Durchsatz und stark verkürzte Durchlaufzeiten.

 

Doch in der Fertigungssteuerung ist man schon wieder weiter. Drum-Buffer-Rope und simplified-Drum-Buffer-Rope sind drauf und dran Kanban abzulösen. Die Vorteile sind mehr Flexibilität und deutlich weniger Bestand. Also warum nicht gleich Drum-Buffer-Rope als Steuerung von IT-Projekten verwenden?

Drum-Buffer-Rope in a Nutshell

Drum-Buffer-Rope ist eine Fertigungssteuerung deren Bezeichnung aus den drei Hauptelementen abgeleitet ist. 

Die "Drum" (Trommel) ist hierbei die begrenzende Ressource in einer Wertschöpfungskette - kurz der Flaschenhals. Wenn man einen möglichst guten Durchsatz erreichen will muss man alles tun um diesen Flaschenhals optimal zu nutzen. Er wird zum Taktgeber, symbolisiert als Trommel, für den ganzen Prozess.

Damit der Flaschenhals nie leer läuft sollte vor diesem immer eine gewisse Menge an Arbeit bereit liegen. Das ist der "Buffer" (Puffer).

Damit nicht zu viele Aufträge gestartet werden muss die Freigabe von neuen Aufträgen anhand des Füllstandes des Puffers vor dem Flaschenhals erfolgen. Die Signalleitung von der Trommel zur Auftragsfreigabe wird als "Rope" (Seil) symbolisiert.

Drum-Buffer-Rope wird gerne als Anekdote von Herbie bei der Wanderung der Pfadfinder dargestellt. Die Geschichte stammt aus dem Buch von E. Goldratt "Die kritische Kette".

Hierbei ist die Reihenfolge genau umgekehrt - die Bedeutungen sind aber die gleichen. Die "Drum" ist in dieser Geschichte Herbie (der Kleinste und Langsamste). Der "Buffer" ist der kleine Abstand zum vor ihm Laufenden, so dass Herbie nie stoppen muss. Und die "Rope" ist hier wörtlich das Seil zum Vordersten, so dass dieser nicht wegläuft.

Drum-Buffer-Rope (DBR) als agile Projektsteuerung

Um DBR als Projektsteuerung zu nutzen muss man wie bei Scrum oder Kanban das Projekt in kleinste Einheiten (Stories/Tasks) zerlegen. Zusätzlich muss man einen Arbeitsschritt/Ressource als Engpass (Trommel) definieren und dann den Start von neuen Aufgaben genau an diesem Arbeitsschritt ausrichten. Hierzu wird vor/in diesem Arbeitsschritt ein Arbeitsvorrat (Puffer) installiert. Wenn dieser unter einen definierten Bestand sinkt werden neue Stories/Tasks gestartet.

Drum Buffer Rope als ulitmative Steuerung von agilen Teams

Ein Ziel ist es die Sprints zu entfernen um damit die unnatürlichen Brüche am Ende der Sprints zu vermeiden und in einen kontinuierlichen Fluss zu kommen. Der Fluss ist wichtig um die Anzahl der offenen Stories und Tasks zu verringern und somit die Durchlaufzeit zu Verkürzen. Am Schluss steigt natürlich auch der Durchsatz.

Keine Panik - viele Dinge aus Scrum bleiben bestehen (das meiste ist ja sehr sehr hilfreich) - nur die Steuerung wird angepasst. Eine Retrospektive alle 2-3 Wochen – ist immer noch sinnvoll. Es gibt weiterhin ein „Planning 1“ – durch „Reliable Scrum“ wird das Backlog aber in den ersten Sprints weitgehend komplett qualifiziert, so das Backlog vollständig priorisiert und geschätzt vorliegt und nur noch angepasst werden muss. Reviews werden natürlich auch gemacht - aber nicht in einem definierten Rhythmus, sonder alle 5-10 Stories, wenn es wirklich Wert ist, etwas zu zeigen. „Dailies”, „Impediment Logs“ und bleibt natürlich alles erhalten.

So was ändert sich dann? Es gibt keine Sprints mehr! Es ist alles ein kontinuierlicher Fluss mit dem Ziel, so wenig wie möglich Stories und Tasks geöffnet haben.

Um das zu erreichen, wird der Prozess in zwei unabhängige Teile geteilt 1. das Schneiden der Stories in Tasks (auf der linken Seite des Taskpuffer) und 2. das Abarbeiten der Tasks (auf der rechten Seite).

Die Steuerung der linken Seite ist extrem einfach. Das Aufteilen von Stories in Task ist ja für eine Person nur wenige Stunden Aufwand – ungefähr so viel wie ein Task selbst. Daher wird das Schneiden von Stories ausschließlich durch die Menge der Tasks im Taskpuffer gesteuert. Wenn nur noch zwei Tasks übrig sind – wird einer der Entwickler die nächste Story aus dem Backlog nehmen und sie in Tasks aufbrechen. Es kann sein, dass die Alarmgrenze von 2 Task zu riskant ist. Sie sehen, dass - wenn ein Pufferloch auftritt – also keine Aufgabe im Taskpuffer mehr übrig ist. Wenn Pufferlöcher auftreten, muss man einfach die Alarmschwelle solange (langsam und schrittweise) erhöhen, bis keine Pufferlöcher mehr auftreten. Die Alarmschwelle sollte dabei nicht die Hälfte der Anzahl der beteiligten Entwickler überschreiten, ansonsten ist dies ein deutlicher Hinweis auf Prozessprobleme.

Das Monitoring geschieht über die, aus dem „Reliable Scrum“ bekannten Werkzeuge, also das klassische „Product Burndown Chart“ und die neue „Fieberkurve“. Diese Diagramme werden immer aktualisiert, sobald eine Story fertig gestellt wurde. Hierdurch entstehen viel mehr Messpunkte und noch feinere „echtzeit“ Transparenz. Übrigens ist dieser Teil im strengen Sinne gar keine Drum-Buffer-Rope Steuerung. Hier spricht man von "Vendor Managed Inventory" oder "Just-In-Time". Der Verkäufer/Lieferant (Backlog) überwacht den Puffer vor der Produktion und füllt diese eigenständig auf.

Und jetzt auf der rechten Seite? Das ist Drum-Buffer-Rope! Ok auch hier muss man etwas genauer hinschauen. Normalerweise hat eine Drum-Buffer-Rope viele Prozessschritte (wie in Kanban). Hier haben wir aber einen kontinuierlichen Prozess mit zwei Schritten "Entwicklung" und "Review/Test". Das besondere ist aber, dass es nur eine Art von Ressourcen gibt – Entwickler. Diese haben zwar Unterstützung durch QA Mitglieder, die die Tests zu schreiben - aber am Ende sind die Entwickler der begrenzende Faktor. Daher macht es keinen Sinn, zwischen den Prozessstufen zu unterscheiden. Beide werden durch die Verfügbarkeit der Entwickler eingeschränkt.

Die Drum-Buffer-Rope Steuerung besteht nun aus folgenden drei Teilen:

Die Trommel - dies ist die begrenzende Ressourcen - in diesem Fall die Entwickler. Die Trommel ist wie der Herzschlag der Produktionskette. Sie gibt den Takt vor – nach ihr müssen sich alle richten.

Dann benötigen wir einen Puffer (in der Regel vor der Trommel), aber in diesem Fall, wenn es nur einen begrenzenden Prozessschritt gibt ist der komplette Bestand (Anzahl der offenen Tasks) selbst der Puffer - spielt aber für die Steuerung keine Rolle ob ein angefangener Task im Bearbeitung ist oder in einem Puffer liegt. Keine dedizierten Puffer ist Letzt endlich sogar ideal.

Und das Seil? Das ist die Signalleitung vom Puffer um neue Aufgaben zu starten. In diesem Fall ganz einfach - wenn eine Aufgabe abgeschlossen ist, dann darf eine neue Aufgabe gestartet werden.

Das Monitoring für die rechte Seite besteht aus einem "aggregierten Input-Output-Diagramm", oder manchmal auch "Flussdiagramm" genannt. Das Ziel ist es, den Bestand (Differenz zwischen Ein- und Ausgangslinie) so niedrig wie möglich zu halten.

Dies kann auf sehr einfache Weise erreicht werden. Es werden keine neuen Aufgaben begonnen, bis die ersten "Pufferlöcher" entstehen. Wenn der erste Entwickler keine Task mehr hat, dann kann ein zusätzlicher Task gestartet werden und damit wird der Puffer um eins erhöht. Dies sollte aber eine Ausnahme sein und es müssen die Ursachen hierfür untersucht werden. Pufferlöcher sind voll von Informationen über Hindernisse oder verfahrenstechnische Probleme. Aber schließlich, wenn alles getan wurde und immer noch Pufferlöcher auftreten, dann muss man den Bestand erhöhen um den Durchsatz zu sichern.

Wenn für eine lange Zeit keine Pufferlöcher aufgetreten sind, kann man den Bestand Schritt für Schritt wieder zu reduzieren, z.B. durch eine einfach temporäre Regel „Alle 5 Tasks einen weniger starten“ o.ä.

Das ist es also - jetzt haben Sie:

  • kontinuierlichen Fluss
  • mit der minimal möglichen Anzahl offener Tasks
  • und die kürzeste Lieferzeiten
  • und den Best möglichen Durchsatz

und dass heißt "Ulitimate Scrum" :-)

 

p.s.: es ist mathematisch nachweisbar, dass DBR die optimale Steuerung ist – um jetzt noch weiter die Leistung zu steigern muss man an den Fähigkeiten der Entwickler arbeiten und weiterhin störenden Overhead reduzieren - aber die Luft wird deutlich dünner. Ich persönlich finde es aber überaus positiv, dass der Fokus jetzt weg von den Prozessen hin zu den Menschen wandert - denn dort gehört er hin :-)

Drum-Buffer-Rope im Vergleich

Als nächstes interessiert natürlich wie DBR im Vergleich zu Scrum und Kanban bzgl. Durchsatz, Bestand und Durchlaufzeit aussieht. Der erste Schritt hierzu ist eine Simulation. Eine Simulation ist auch notwendig um genau zu verstehen, wie die Mechanismen tatsächlich funktionieren - nur so weiß man auch um die Grenzen der jeweiligen Steuerungen. Der Bestand wird hier nicht explizit ausgewiesen, da er umgekehrt proportional zur Durchlaufzeit ist (s. Littles Law).

Wenn sie den Simulator selbst ausprobieren möchten, schreiben sie einfach ein Mail an mich mit dem Stichwort "DBR-Simulator". Ich sende ihnen dann den aktuellen Stand zu.

Steuerungsmethode mittlere Durch-laufzeit [Tage] Ende der letzten Story [Tag] Durchsatz [Stories/Woche] mittlere Auslastung in der Engpass-Stufe
First-In-First-Out 6,6 9 2,8 68%
Drum-Buffer-Rope 5,4 10 2,5 63%
Kanban 7,2 10 2,5 63%
Scrum 6,4 11 2,3 63%
keine Steuerung 13,8 17 1,5 39%

Folgende ersten Erkenntnisse lassen sich aus der Tabelle ableiten:

  • Eine Steuerung hat gefehlt. Es ist die First-In-First-Out (FiFo) oder schlicht „nach Priorität abarbeiten“. Das ist immer die optimale Strategie (s. "die neun produktionslogistischen Grundgesetz" von P. Nyhuis und Hans-Peter Wiendahl) > Das ist die Referenz! Auch der Simulator zeigt FiFo als die optimale Strategie: höchster Durchsatz, höchste Auslastung des Engpass und damit kürzeste Durchlaufzeit.
  • Die für mich wichtigste Fragestellung war: "in wie weit unterscheiden sich Scrum, DBR und Kanban bzgl. Durchsatz und mittlere Auslastung des Engpass?" > das Ergebnis ist eindeutig - alle drei Steuerungen befreien in gleicher Weise das Engpassteam von negativen Multitasking und zeigen damit die gleichen Ergebnisse beim Durchsatz und mittlere Auslastung im Engpass.
  • Bei Scrum war ich mir nie sicher, um was für eine Steuerung es sich eigentlich handelt? Die Modellierung im Simulator hat hier die Antwort geliefert: bei Scrum handelt es sich um eine FiFo-Steuerung mit „verzögerter“ Auslieferung/Takt. Wenn man die Velocity korrekt vorhersehen könnte, die Anzahl der Stories genau planen könnte und die Sprintlänge auf 1 Tag ansetzen würde - bekommt man die gleichen Ergebnisse wie bei FiFo > bleibt bei Scrum meine einzige Kritik, dass die mittlere Durchlaufzeit sich mit mittel um Sprintlänge/2 verlängert. Das ist in den Simulationsergebnissen eindeutig zu erkennen.
  • Achtung: in der Praxis weist Scrum durch die vielen gemeinsamen Meetings leider auch einen recht hohen Overhead auf, daher ist die Velocity und damit der Durchsatz typischerweise geringer als in Kanban und DBR. Der Simulator berücksichtigt diesen Overhead nicht, daher ist dieser Effekt in den Simulationsergebnissen nicht erkennbar.
  • Im Vergleich ist Kanban die einfachste Steuerung (die wenigsten Regeln und Artefakte). Wenn man die Kanban-Limits richtig setzt wird auch hier der Durchsatz optimal. > mein Kritik ist hier klar die höheren Bestände als bei den anderen Steuerungen und damit Letzt endlich auch die längeren Durchlaufzeiten.
  • DBR hat die Nachteile von Scrum und Kanban nicht > es ist optimal in Bezug auf Durchsatz, Bestand und Durchlaufzeit. DBR erlaubt auch Terminzusagen oder Rapid-Response-Aufträge, was aber durch etwas höheren Planungsaufwand erkauft wird.
  • Kanban und Scrum haben beide das Problem, dass sie sich erst „einregeln“ müssen. Velocity und Kanban-Limits werden über die Zeit angepasst. In dieser Anpassungszeit ist der Durchsatz nicht optimal > DBR plant am Engpass und kennt diesen Effekt nicht. DBR kann damit auch flexibler auf Bedarfsänderungen reagieren
  • Der Gegenpol zu FiFo bildet die Gleichverteilung der Ressourcen also "keine Steuerung". Alle neuen Aufträge werden sofort gestartet und parallel bearbeitet > hier kommt es zu negativem Multitasking und damit zu verlängerten Durchlaufzeiten und reduziertem Durchsatz.

Zusammenfassung

In der Praxis kann mit allen drei Steuerungen (Scrum, Kanban und DBR) der Durchsatz optimiert werden. Daher treten andere Entscheidungskriterien wie Innovationshöhe, Einfachheit oder Bestand/Durchlaufzeit in den Vordergrund.

Systemisch kommt Drum-Buffer-Rope (DBR) dem Optimum (FiFo) am nächsten - Durchsatz, Bestand und Durchlaufzeit sind optimal.