Agiles Projektmanagement mit Critical Chain und Reliable/Ultimate Scrum

Agile Methoden sind produkt- und teamorientierte Ansätze und stehen im Widerspruch zu Projekten mit hartem Terminen und Abhängigkeiten. Um die Vorteile aus beiden Welten zu nutzen muss man auch an beiden Welten Veränderungen vornehmen.

Das klassische Projektmanagement leidet an zu viel Work-in-Progress und starrer Terminplanung auf Arbeitspaketebene. Hier bietet Critical Chain (CCPM) ein bewährtes Methodenset um Fluss und Agilität zu ermöglichen. Auf der anderen Seite können Agile Methoden keine Termine und Lieferumfänge zusichern. Auch hier existieren mit Ultimate/Reliable Scrum Agile Methoden der 3. Generation, die wiederum Fluss und Zuverlässigkeit ermöglichen. Damit ist der Weg frei – je nach Projektsituation, Projektphase, Teilprojekt oder Arbeitspaket genau die Vorgehensweise zu wählen, die mit geringstem Aufwand die Erfordernisse erfüllt.

In der Praxis wird das Portfoliomanagement, mit dem Konzept der „Virtual Drum“ aus der „Theory of Constraints“, massiv vereinfacht. Hier werden an einen „künstlichen/virtuellen“ Engpass die Projekte so gestaffelt, dass keine Ressource auf Dauer überlastet ist. Im Projektmanagement werden die Terminpläne durch Puffermanagement ersetzt. Zur Steuerung wird nur noch Fortschritt auf der kritischen Kette zu Pufferverbrauch herangezogen. Innerhalb von Arbeitspaketen oder Teilprojekte können nun auch agile Methoden zum Einsatz kommen. Die Teams erreichen mit Hilfe von Ultimate Scrum Boards den Zustand des „one piece flow“ und optimalen Durchsatz. Wie im Projekt wird die Zuverlässigkeit auch hier mit einem Puffer und Puffermanagement sichergestellt – namentlich Reliable Scrum. Es entsteht ein vollskalierbares agiles Projektmanagement Rahmenwerk.

1           Einleitung

Agile Methoden sind produkt- und teamorientierte Ansätze und stehen im Widerspruch zu Projekten mit hartem Terminen und Abhängigkeiten. Um die Vorteile aus beiden Welten zu nutzen muss man auch an beiden Welten Veränderungen vornehmen.

Das klassische Projektmanagement leidet an zu viel Work-in-Progress und starrer Terminplanung auf Arbeitspaketebene. Hier bietet Critical Chain (CCPM) ein bewährtes Methodenset um Fluss und Agilität zu ermöglichen. Auf der anderen Seite können Agile Methoden keine Termine und Lieferumfänge zusichern. Auch hier existieren mit Ultimate/Reliable Scrum Agile Methoden der 3. Generation, die wiederum Fluss und Zuverlässigkeit ermöglichen.

Damit ist der Weg frei – je nach Projektsituation, Projektphase, Teilprojekt oder Arbeitspaket genau die Vorgehensweise zu wählen, die mit geringstem Aufwand die Erfordernisse erfüllt.

2           Unterschied zwischen Projekten und Produkten (Agile)

Diese Abgrenzung hat weitreichende Auswirkung für das Projektmanagement und hilft vor allem die Unterschiede zwischen den agilen und den klassischen Ansätzen zu verstehen.

2.1           Produktion – agile Management

Von Produktion spricht man bei einem Anteil der Bearbeitungszeit zur Durchlaufzeit kleiner 10%. Wenn man sich z.B. die Produktion von einer Schraube, einem Auto oder einem elektronischen Gerät betrachtet sieht das immer wie folgt aus: Das Produkt wird in vielen kleinen Teilen produziert. Viele dieser kleinen Teile bilden zusammen ein Produktionslos (Batch). Aus Sicht des einzelnen Teils besteht der größte Teil der Durchlaufzeit aus "warten". Warten in einer Palette, dann transportierten, herausholen, kurz bearbeiten, wieder in eine Palette, transportieren u.s.w. - zwischen den einzelnen Bearbeitungsschritten entstehen relativ lange Wartezeiten.

Das was sich jetzt vielleicht negativ anhört hat aber große Vorteile. Durch die verhältnismäßig kurzen Bearbeitungszeiten kann man die einzelnen Zeiten recht genau schätzen. Wenn eine Bearbeitungszeit einmal überschritten wird, kann sie sich mit der Unterschreitung des nächsten ausgleichen und fällt nicht ins Gewicht. Wenn mehrere Teile parallel zu bearbeiten sind erhält man durch die langen Wartezeiten die Möglichkeit die Reihenfolge der Teile vor jedem Arbeitsschritt zu vertauschen und kann so jeden beliebigen Termin einhalten. Der Work-In-Progress lässt sich leicht Begrenzen, da er sehr überschaubar ist. Produktionsteuerungen sind extrem einfach (s. Henry-Ford, Scrum, Kanban, Drum-Buffer-Rope oder Simplified-Drum-Buffer-Rope).

Hierfür muss man aber einen Preis bezahlen: man muss alle Vorhaben in kleinste und unabhängige Teilaufgaben zerlegen und man braucht irgendwo Warteschlangen (Puffer oder Backlogs) die die mittlere Durchlaufzeit erhöhen.

Wenn man sich nun die agilen "Projektmanagement"-Methoden betrachtet wird man feststellen, dass diese im Kern Produktionssteuerungen sind - kleine Teilaufgaben, unabhängige Teilaufgaben, Puffer in Kanban, Backlog in Kanban und Scrum.

2.2           Projektmanagement

Von Projekten oder Projektmanagement spricht man wenn der Anteil der Bearbeitungszeit zur Durchlaufzeit größer als 20% beträgt. Hierbei wird vor allem der kritische Pfad oder, wenn man die Ressourcenverfügbarkeit mit betrachtet, die kritische Kette (Critical Chain) betrachtet. Das Ziel im Projektmanagement ist typischerweise das vereinbarte Ergebnis in der kürzest möglichen Zeit zu erbringen. Hierzu sind die echten Abhängigkeiten zwischen den Arbeitspaketen zu betrachten. Die Arbeitspakete sind hierbei optimal mit Ressourcen zu versorgen, so dass die Projektlaufzeit minimal wird.

Im Gegensatz zur Produktion strebt man nun aber einen Anteil der Bearbeitungszeit an der Durchlaufzeit von 100% an (wird selten wirklich erreicht - typisch sind effektiv 50-80%). Hieraus ergibt sich, dass man folgende Eigenschaften von Projekten explizit managen muss: die Abhängigkeiten, die Streuungen in den Schätzungen und die operative Ressourcenzuordnung im Multiprojektmanagement. Projektmanagement ist etwas aufwändiger.

Bei Projekten muss man daher: ausreichend konzeptionieren und planen, so dass die Arbeitspakete und ihre Abhängigkeiten klar werden, muss die Aufwände schätzen um die Ressourcenzuordnung sicher zu stellen und die Streuungen in den Arbeitspaketen abpuffern am Projektende oder im Projektportfolio.

3           Projektmanagement agilisieren – Critical Chain

In der Praxis wird das Portfoliomanagement, mit dem Konzept der „Virtual Drum“ aus der „Theory of Constraints“, massiv vereinfacht. Hier werden an einen „künstlichen/virtuellen“ Engpass die Projekte so gestaffelt, dass keine Ressource auf Dauer überlastet ist.

Im Projektmanagement werden die Terminpläne durch Puffermanagement ersetzt. Zur Steuerung wird nur noch Fortschritt auf der kritischen Kette zu Pufferverbrauch herangezogen.

Ausgangspunkte der von Dr. Eliyahu Goldratt entwickelten Methodik sind folgende Annahmen:

  • Multitasking führt zu Mehraufwand, kostet Zeit und ist deshalb zu verhindern.
  • In jeder Entwicklung gibt es einen Engpass und nur dort kann wirklich optimiert werden. Je reibungsloser es hier läuft, desto schneller der gesamte Prozess.
  • Da Mitarbeiter zuverlässig sein wollen,  bauen  sie bei ihren Aufwandsschätzungen oft bewusst oder unbewusst Puffer ein. Doch solche Reserven in einzelnen Aufgaben nützen dem Gesamtprojekt nichts. Werden sie nicht gebraucht, wird der Verantwortliche das nicht kundtun, um beim nächsten Projekt nicht unter Druck zu geraten. Dauert eine Aufgabe hingegen länger, wird der Verzug weitergegeben.

Ziel von Critical Chain ist es, schädliches Multitasking zu verhindern und die Reserven nutzbar zu machen.

Für das Einzel-Projektmanagement bedeutet das:

Die Aufgaben werden so organisiert, dass das Team/die Fähigkeit, deren Verfügbarkeit den größten Engpass bildet, konzentriert eine Aufgabe nach dem anderen abarbeiten kann.

Die Zeitschätzungen der Mitarbeiter werden um die geschätzten Puffer reduziert. Die gewonnene Zeit wird teilweise als Projektpuffer aggregiert und darf nach und nach verbraucht werden. In der Praxis entsteht, so die Erfahrung von Uwe Techt, VISTEM, jedoch normalerweise ein regelrechter Wettbewerb darin, Puffer zu identifizieren und die Projektlaufzeit zu verkürzen.

Weiteres Verbesserungspotenzial verspricht das Critical-Chain-Konzept fürs Multiprojektmanagement.

Ist die Zahl der Projekte so hoch, dass schädliches Multitasking entsteht, wird dieser „Work in Progress“ so weit reduziert, dass  der Engpass gerade noch ausgelastet ist. Es entsteht eine Situation, in der alle Projekte genug Ressourcen haben – was in klassischen Projektumgebungen meist nur für das Projekt mit der höchsten Priorität gilt. Erst wenn die kritischste Aufgabe fertig ist, wechselt der Mitarbeiter/das Team zur nächsten. Das bedeutet in der Regel laut Techt, dass die Zahl der gleichzeitig aktiven Projekte sinkt, aber die Projektlaufzeiten deutlich kürzer werden.

Die Ressourcen werden operativ nach Fortschritt zu Pufferverbrauch der Projekte gesteuert. Das Projekt mit dem schlechtesten Verhältnis erhält die kritischen Ressourcen und die höchste Aufmerksamkeit.

Bei IT-Projekten erweist sich oft die Integrationsphase (Integration, End-2-End-Tests, Bugfixing) als kritischer Engpass: D.h., das Unternehmen muss klar definieren, wie viele Integrationsprozesse es gleichzeitig verkraften kann, ohne dass die Projekte sich durch schädliches Multitasking gegenseitig behindern. An diesem Engpass werden die Projekte entsprechend getaktet. Die Integration hat höchste Aufmerksamkeit und Unterstützung des Managements inklusive.

Ergebnis: Die Projektlaufzeiten sinken, die Zahl der Projekte, die pro Monat oder Jahr fertig gestellt werden, steigt ebenso wie die Zuverlässigkeit – und das bei gleichen Ressourcen wie zuvor. Es kommt mehr Ruhe in die Projekte und der Stress für alle Beteiligten sinkt.

4           Agile Methoden zuverlässig machen – Reliable/Ultimate Scrum

Innerhalb von Arbeitspaketen oder Teilprojekte können nun auch agile Methoden zum Einsatz kommen.

Wie im Projekt wird die Zuverlässigkeit auch hier mit einem Puffer und Puffermanagement sichergestellt – namentlich Reliable Scrum.

4.1            Reliable Scrum

Ausgangspunkte sind das bekannte Scrum oder Kanban – diese werden ergänzt um zwei Elemente aus Critical Chain:

  • Begrenzung des Work-in-Progress durch sachrichtiges ausbalancieren von Umfang, Ressourcen und Termin
  • Darstellung des Projektstatus als Fieberkurve mit Pufferverbrauch und Fortschritt

Ziel von Reliable Scrum ist es dem Team eine realistische Erfolgswahrscheinlichkeit zu geben und dem Product Owner ein Werkzeug zur Steuerung des Backlogs (Work-In-Progress), so dass zum zugesicherten Termin und die zugesicherten Funktion sicher geliefert werden.

Für das Einzel-Projektmanagement bedeutet das:

Das Backlog wird vervollständigt und geschätzt. Die Abarbeitungsgeschwindigkeit wird ermittelt. Zusammen ergibt sich die Erfolgswahrscheinlichkeit. Das Backlog wird nun so eingestellt und verhandelt, dass die Erfolgswahrscheinlichkeit ausreichend hoch wird.

Durch diese realistische Erfolgswahrscheinlichkeit entsteht ein Puffer am Projektende. Mit diesem Puffer kann das aus Critical Chain bekannt Phasendiagramm (Fieberkurve) gezeichnet werden. Hier können die Stakeholder objektiv verfolgen ob das Projekt auf Kurs ist und der Product Owner kann sein Backlog immer so managen, dass die Erfolgswahrscheinlichkeit erhalten bleibt.

Weiteres Verbesserungspotenzial verspricht Reliable Scrum im Multiprojektmanagement.

Wenn mehrere agile Projekte zusammen arbeiten müssen ist oft schwer den Überblick über die einzelnen Teilprojekte zu halten und die Abhängigkeiten zu managen. Die Fieberkurve kann man nun auch für ein Portfolio erstellen und so sicher stellen, dass der Großteil der Projekte „grün“ ist. In dem Moment werden Abhängigkeiten sicher eingehalten und Probleme früh entdeckt.

Ergebnis:  der Auftrag wird deutlich schneller und besser geklärt. Das Team erhält dadurch einen klaren Leuchtturm, Fokus und Motivation. Der Product Owner kann sein Backlog managen und den Status objektiv in Richtung Stakeholder kommunizieren. In Folge werden die Projekte deutlich schneller und zuverlässiger.

4.2           Ultimate Scrum

Die Teams erreichen mit Hilfe von Ultimate Scrum Boards den Zustand des „one piece flow“ und optimalen Durchsatz.

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.

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.

5           Das voll skalierbare agile Projektmanagement Rahmenwerk

Daher gehe ich eine Stufe weiter und zeige hier ein Framework für vollintegriert Projekt- und Produktentwicklung. Beide Steuerungen sind in der Praxis tatsächlich einfach zu kombinieren und zwar an der Stelle der operativen Priorität von Arbeitspaketen/Stories. Alle hier vorgestellten Elemente sind schon in unterschiedlichsten Kontexten erfolgreich im Einsatz - das Framework ist die Zusammenführung.

Das Framework soll kein Rückschritt in die tayloristische prozessuale Welt sein - sondern der Schlüssel, mit sehr wenig zentralen Informationen (strategische und operative Priorität), der zugrundeliegenden Organisation möglichst viel Freiheit für Selbstorganisation zu geben. Hierdurch können sich die positiven Wirkungen der teamorientierten agilen Welt entfalten und die Vorteile einer großen Organisation und Projekten genutzt werden.

Beschreibung:

  • Es handelt sich um ein 3-Schichten-Framework. Jede Schicht hat eigene Charakteristika und Steuerungen.
  • Das Portfolio/Demandmanagement ist, ähnlich wie bei SAFe, ganz oben. Der Demandfunnel wird über aber über Throughput Accounting Ansätze gesteuert (nicht ROI). Zum terminieren kommt entweder eine Drum-Buffer-Rope-Steuerung (für Projekt) oder eine simplified-Drum-Buffer-Rope (für die Kleinaufträge) zum Zuge. Damit werden Trade-Offs schnell transparent und das Board kann die strategischen Prioritäten setzen.
  • Auf der untersten Eben, ähnlich wie bei Safe, finden sich die Teams, die Epics(Teilprojekte) und Arbeitspakete(Stories) umsetzen. Hier kommt im Gegenzug zu SAFe kein reinrassiges Scrum zum Zuge sondern wie schon beschrieben Reliable/Ultimate Scrum. Reliable Scrum um Epics sicher zu einem Termin liefern zu können – damit diese in Projekten funktionieren und Ultimate Scrum um einfacher Kleinaufträge und Stories aus Epics mischen zu können und um schnellere Durchlaufzeiten zu erreichen und einen klaren Fokus des Teams auf Fluss zu ermöglichen.
  • Der Clou ist die Mittelschicht. Die Mittelschicht dient dazu die „operative Priorität“ der Stories in den Backlogs zu liefern – so dass jedes Team genau weiß in welcher Reihenfolge es die Stories ziehen muss um die im Portfoliomanagement genannten Termine erreichen zu können. Hier gibt es zwei bewährte Methoden a) Critical Chain Buffer Management – ergibt eine rot-gelb-grün Ampel und b) die sDBR-Ampel über die Restlaufzeit bis zum Due-Date – auch wieder rot-gelb-grün mit allen Feinabstufungen. Das heißt man kann beides mischen. Wenn die Teams sich "einigermaßen" an die Ampel halten dann werden die Termine insgesamt gehalten.

Das Framework ist ein vollintegrierter Ansatz Projekt- & Produktionsteuerung der neuesten Generation - kombiniert mit den ganzen positiven Aspekten der agilen Methoden.

Twittern

Dieser Inhalt von openPM steht unter einer Creative Commons Lizenz (CC BY 3.0) und kann frei verwendet werden unter Namensnennung durch Link auf http://openpm.info. Unpassende Inhalte, insbesondere Verstöße gegen Urheberrechte, bitte via info@openpm.info melden. Weitere Informationen unter Nutzungsbedingungen