Integration der kritischen Kette in Scrum/Agile-Praktiken

Das Critical Chain Projektmanagement fordert eine höhere Flexibilität Ihres Teams:

Aus Wikipedia Critical Chain Projektmanagement:

Ein Critical-Chain-Projektnetzwerk hält die Ressourcen in der Regel gleichmäßig ausgelastet, erfordert jedoch, dass sie in ihren Startzeiten flexibel sind und schnell zwischen Aufgaben und Aufgabenketten wechseln , um das gesamte Projekt im Zeitplan zu halten.

Aber auch (aus Wikipedia Critical Chain Project Management):

Wenn sie ihren „Abschnitt“ des Projekts ausführen, sollten sie sich darauf konzentrieren, die zugewiesene Aufgabe so schnell wie möglich zu erledigen, ohne Ablenkungen oder Multitasking .

Und auch (aus Wikipedia Critical Chain Project Management):

Da die Aufgabendauer mit einer Wahrscheinlichkeitsdauer von 50 % geplant wurde, stehen die Ressourcen unter Druck, kritische Kettenaufgaben so schnell wie möglich abzuschließen und das Studentensyndrom und das Parkinson-Gesetz zu überwinden.

Was mich am meisten beunruhigt, ist die Wahrscheinlichkeit, dass das Team am Ende ein schlechtes Multitasking durchführt. Siehe den Artikel Human Task Switches Considered Harmful von Joel Spolsky:

Aus dem oben erwähnten Artikel von Joel:

Der Trick dabei ist, dass insbesondere beim Verwalten von Programmierern Taskwechsel sehr, sehr, sehr lange dauern. Denn Programmieren ist eine Aufgabe, bei der man viele Dinge gleichzeitig im Kopf behalten muss.

Da Sie angegeben haben, dass Sie in der Softwareentwicklung arbeiten, versuchen Sie sicherzustellen, dass Ihr Entwicklungsteam den Prozess der kritischen Kette versteht, da es sonst ausflippt und viele Aufgaben gleichzeitig erledigt.

Auch aus Joels Artikel:

Tatsächlich ist die wahre Lehre aus all dem, dass Sie die Leute niemals an mehr als einer Sache gleichzeitig arbeiten lassen sollten . Stellen Sie sicher, dass sie wissen, was es ist. Gute Manager sehen ihre Verantwortung darin , Hindernisse aus dem Weg zu räumen , damit sich die Menschen auf eine Sache konzentrieren und sie wirklich erledigen können. Denken Sie bei Notfällen darüber nach, ob Sie das selbst bewältigen können, bevor Sie es an einen Programmierer delegieren, der tief in ein Projekt eingetaucht ist.

Um Ihre Konflikte zwischen Scrum/Agile und Critical Chain zu beseitigen:

Critical Chain hängt von der Tatsache ab, dass Sie nicht genug Zeit haben, um die Arbeit abzuschließen (z. B. geben sie Ihnen 2 Tage, um 4 Tage Arbeit zu erledigen). Wenn Stories in Agile nicht vollständig sind, werden sie einfach abgebrochen oder in den nächsten Sprint übernommen.

Dieser Konflikt lässt sich lösen, wenn man davon ausgeht, dass eine 4-Tages-Aufgabe eigentlich eine 2-Tages-Aufgabe ist. Die eigentliche Arbeit wird in kürzerer Zeit erledigt als bemessen.

Aus dem Parkinsonschen Gesetz :

Die Stock-Sanford-Ergänzung zum Parkinson-Gesetz lautet: „Wenn Sie bis zur letzten Minute warten, dauert es nur eine Minute.“

Natürlich werden einige Aufgaben mehr Zeit in Anspruch nehmen als erwartet, aber Critical Chain geht davon aus, dass die Hälfte der Aufgaben früher und die Hälfte der Aufgaben spät erledigt werden.

Critical Chain verwendet einen Puffer am Ende des Projekts. (Wenn Ihr Projektzeitplan acht Wochen beträgt, geben sie Ihnen vier Wochen Zeit, um die Arbeit zu erledigen, und einen vierwöchigen Puffer am Ende des Projekts.) Bei Agile haben Sie nur Sprints (Iterationen), wenn Sie Arbeit zu erledigen haben.

Um diesen Konflikt zu beseitigen, müssen Sie Ihren Sprint so einstellen, dass Sie immer etwas zu tun haben.

Mit der reduzierten Zeit, um die Aufgaben zu erledigen, wie im ersten Konflikt angegeben, werden viel mehr Aufgaben das Sprint-Backlog füllen. Die Gesamtzeit für den Projektabschluss wird reduziert, als die ideale Zeit für die Projektdauer festzulegen und die verbleibende Zeit als Puffer zu lassen.

Es ist sehr wichtig, Prioritäten für Aufgaben zu setzen, wie must do(Begründung erforderlich, wenn nicht abgeschlossen) und should dound could do(Begründung nicht erforderlich, wenn nicht abgeschlossen).

Grundsätzlich werden Sie eine pragmatische Scrum-Methodik unter den Augen von Critical Chain ausführen.

Eigentlich funktioniert das Buffer-Konzept ganz gut mit einer agilen Entwicklungsmethode wie Scrum. Ich bin mir zwar nicht sicher, ob ich die Schätzungen halbieren soll, aber wir wenden auch etwas Ähnliches an, indem wir „höchstwahrscheinliche“ – „schlimmste“ Schätzungen verwenden. So machen wir es:

Zuerst führen wir ein ordnungsgemäßes Projektmanagement durch, indem wir mit einem gut gestalteten Projektstrukturplan ( WBS ) bis hin zur Arbeitspaketebene beginnen. Die Liste der Arbeitspakete ist unser Product Backlog. Diese Arbeitspakete werden dann mit einer Bandbreite von „Most Likely“ bis „Worst Case“ geschätzt.

Unser „Budget“ ist die Summe der „höchstwahrscheinlichen“ Schätzungen. Der „Puffer“ wird als Summe der Mittelwerte berechnet – die Summe der wahrscheinlichsten. Einige verwenden 2 x Standardabweichungen, wie in dem von Marcie empfohlenen Cohn-Buch erklärt (siehe Kapitel 17 Pufferpläne für Unsicherheit).

Nun zur Ausführung: Nehmen wir an, dass wir das Projekt gemäß der Kapazität unseres Teams in 6 Sprints abschließen können (nach den wahrscheinlichsten Schätzungen) und unser „ Puffer“ -Budget für weitere 2 Sprints gut ist. Macht insgesamt 8 Sprints, um den Job zu beenden.

Normalerweise teilen wir unsere Projekte in mehrere technische Phasen (oder formellere Veröffentlichungen) auf; jede solche Phase bekommt ihren eigenen Puffer.

Meiner Ansicht nach gibt es ein Potenzial für gute Synergien zwischen CCPM und Scrum

Wenn wir uns auf die Richtung konzentrieren, wie Agile/Scrum durch CCPM-Denken verbessert werden kann:

Die Idee von Projektpuffer versus Aufgabenpuffer – meine Empfehlung ist, Aufgabenschätzungen ganz zu vermeiden. Verwenden Sie einfach kleine Aufgaben ohne Fälligkeitsdatum und ziehen Sie sie so schnell wie möglich zu Ende. Dies vermeidet das Parkinson-Gesetz und geht besser mit Variabilität um.

Sprint-Verpflichtung angesichts von Schwankungen – Verpflichten Sie sich auf der Grundlage des Worst-Case-Szenarios, aber haben Sie einen Umfangspuffer von Dingen, die Sie überliefern können, falls der Durchschnitt eintritt. Planen Sie für Murphy, aber planen Sie auch, dass Murphy nicht auftaucht ...

Geben Sie das Commitment auf die gleiche Weise frei, indem Sie Scope Buffers und Worst-Case-/Durchschnittsszenarien verwenden. Ich sehe die Freigabe-/Projekt-/Lieferzusage als viel wichtiger an als die Sprint-Zusage und viel mehr wert, gepuffert zu werden. Sie kümmern sich nicht um die lokale Optimierung des Sprints (es sei denn, jeder Sprint ist eine Lieferung), Sie können sich mehr um die globale Optimierung der Freigabe/Lieferung kümmern. Beginnen Sie mit der Verwendung von Kontrolldiagrammen, um Möglichkeiten zur Verbesserung von Verpflichtungen und Vorhersagbarkeit zu erlernen.

Vermeiden Sie schlechtes Multitasking, indem Sie Prioritäten im Release-Backlog und im Sprint-Backlog durchsetzen, und begrenzen Sie die Anzahl der Stories, die im Sprint in Bearbeitung sind, sowie der Features, die im Release-Backlog in Bearbeitung sind. „Hör auf zu starten – fang an zu beenden“.

Es gibt auch Aspekte, die dem Staggering-Ansatz in Multiprojektumgebungen ähneln, und das Einfrieren – wenn Kanban verwendet wird, um die Freigabe von Anfang bis Ende zu verwalten – schränkt das Gesamtdesign im Prozess im System ein.

Scrum/Agile verschafft Ihnen einen großen Vorsprung gegenüber typischem CCPM – aufgrund der Arbeit mit End-to-End-Storys im Backlog, der Ressourcenflexibilität aufgrund des Strebens nach kollektiver Eigenverantwortung und des geringeren Synchronisierungsbedarfs aufgrund von Feature-/Scrum-Teams eine viel einfachere kritische Kette mit geringerem Bedarf an Fütterungspuffern, Ressourcenpuffern usw.

Wenn Sie Abhängigkeiten zwischen Teams und anderen externen Einheiten haben, können Sie ein Übersichtsdiagramm Ihres Projekts erstellen, das in der agilen Welt auch als „Lookahead Planning“ bekannt ist. Wenn Sie jedoch ZU VIELE Abhängigkeiten sehen, kann dies ein Hinweis darauf sein, dass Ihre Teams nicht ideal aufgestellt sind, um die Arbeit zu bewältigen.

Es gibt noch viel mehr zu dieser Diskussion, aber unterm Strich - keine Feinde, sondern Cousins ​​... jetzt wird Ihnen der CCPM-Berater sagen, dass CCPM viel stärker und Agile eine lokale Lösung ist, aber seien Sie stark ;-) CCPM hat an seinem Ende viel zu lernen aus der agilen Welt – Flexibilität bei den Funktionen/Anforderungen, frühes Feedback, Team-Empowerment, all die großartigen Dinge, die eine CCPM-Umgebung verbessern und helfen können, mit Variabilität umzugehen und die Vorhersagbarkeit und den Durchsatz selbst für eine großartige CCPM-Implementierung zu verbessern. Ich sehe Agile/Scrum als eine Möglichkeit, den Process of Ongoing Impromevement (POOGI) in der CCPM-Welt anzuwenden.

Hoffe das hilft.

Es wird ein bisschen ein Mischmasch sein, aber die Theorie scheint darauf hinzudeuten, dass Sie dies erreichen könnten, indem Sie:

1. Verkürzung des Sprints um x Tage zB 3 Tage
2. Verwenden Sie alle oder einen Teil dieser 3 Tage als Puffer
3. Lassen Sie NICHT zu, dass Geschichten abgebrochen oder vorgetragen werden. Sie müssen innerhalb des Sprints plus Puffer abgeschlossen werden.
4. Erweitern Sie bestimmte Ergebnisse über mehrere Sprints (erweitern Sie die Geschichten) und erstellen/verwalten Sie einen Puffer, der sich aus allen Puffertagen aller Sprints zusammensetzt, z. B. 9 Tage, wenn Sie einen 3-Tage-Puffer verwenden und die Geschichte auf 3 Sprints verteilen.

Wäre toll, Feedback zu diesem Ansatz in der Praxis zu hören.

Dies wird wahrscheinlich keine beliebte Antwort sein, aber wenn Sie Scrum machen, werfen Sie das meiste von dem, was Sie bei Ihrem PMP gelernt haben, weg. Das sind völlig unterschiedliche Denkprozesse.

Kritische Kettenprozesse gehen davon aus, dass Sie einen riesigen, detaillierten Zeitplan mit Ressourcen- und Aufgabenabhängigkeiten haben. In Scrum haben Sie ein gut priorisiertes Backlog, aus dem das wichtigste Feature / die wichtigste Aufgabe immer als nächstes erledigt wird. Das Team kommuniziert täglich (wenn nicht öfter) und zeigt dem Kunden alle zwei Wochen oder 30 Tage Funktionen, und Aufgaben/Funktionen werden entsprechend neu priorisiert. Dadurch werden die Ineffizienzen für Sie aus dem Prozess herausgepresst, ähnlich wie es die kritische Kette in einem traditionellen Projektmanagement-Projekt tun würde.

Nun, wenn Ihnen das Konzept der „Puffer“ gefällt, können Sie sie immer noch mit Scrum verwenden. Ich empfehle das Buch „Agile Estimating and Planning“ von Mike Cohn. Er hat einige großartige Techniken für den agilen Umgang mit Schätzungen und "Puffer".

Ich komme erst spät dazu, aber ich kann das Buch nur empfehlen. Es ist ein in eine Geschichte verpacktes Lernen und lässt sich schnell lesen. Es ist nicht die beste Fiktion der Welt, aber es bringt den Punkt auf den Punkt, ohne lehrbuchtrocken zu sein. Ich stimme zu, dass diese beiden Methoden verwandt und nicht diametral entgegengesetzt sind.

Scrum und Critical Chain sollen unterschiedliche Probleme lösen. Bei Scrum haben Sie es mit einem schlecht definierten Produkt zu tun. Agile Methoden sollen ein zu Projektbeginn wenig verstandenes Produkt möglichst effizient entwickeln.

Mit Critical Chain haben Sie ein klar definiertes Produkt/Ziel Ihres Projekts, aber eine große Unsicherheit, wie lange die einzelnen Schritte dauern werden. Aus diesem Grund wird es in großen Projekten schwierig, Ihre kritischen Ressourcen zu beschäftigen, da die Ergebnisse der Arbeit anderer Ressourcen möglicherweise nicht bereit sind, wenn die kritische Ressource sie benötigt.

Critical Chain löst dieses Problem mit Techniken aus Goldratts Theory of Constraints. Goldratts ursprüngliches Buch ist ziemlich alt, und das Verständnis der Technik hat sich seit seiner Veröffentlichung erheblich verbessert. Allerdings bleiben die neuen Ergebnisse in der Fachliteratur verstreut.

Oh ja, das Dividieren durch zwei kommt einfach von der üblichen Praxis, Ihre beste Schätzung für eine Aufgabendauer zu nehmen und sie zu verdoppeln.

Critical Chain wurde erfunden, um das allgegenwärtige Problem des Pufferns von Aufgaben in einem Zeitplan mit abhängigen Aufgaben zu bewältigen und wie frühere Beendigungen niemals ausgenutzt werden konnten, während verspätete Beendigungen alle abhängigen Aufgaben verschleierten. Es „funktioniert“, indem alle Aufgabendauern halbiert werden, wodurch sichergestellt wird, dass die meisten Aufgaben nicht vorzeitig beendet werden. Die entfernte Zeit wird dann als letzte abhängige Aufgabe in der Kette zu einem "Kettenpuffer" hinzugefügt. Um den Fortschritt im Zeitplan zu verfolgen, werden alle Aufgaben, die rechtzeitig oder vorzeitig abgeschlossen werden, als verspätet markiert, aber alle Aufgaben, die verspätet beendet werden, werden als abgeschlossen markiert, und die zusätzliche Zeit (zusätzlich zu der für die Aufgabe zugewiesenen Zeit) ist im Kettenpuffer 'gefressen'.

Das Ziel von Critical Chain war es sicherzustellen, dass keine Aufgabe warten musste, weil jemand früher fertig war. Es funktioniert nur, wenn Sie viele Ressourcen haben, die ständig von Aufgabe zu Aufgabe wechseln können. Das Gleiche erreichen wir in Scrum, indem wir Teammitgliedern KEINE Komponentenaufgaben von Backlog-Elementen zuweisen, sondern Teammitglieder die Aufgabe mit der höchsten Priorität übernehmen lassen, die noch nicht begonnen wurde und die sie erledigen können, sobald sie ihre aktuelle Aufgabe abgeschlossen haben. Dies ermöglicht uns, ein Pull-System wie in Lean/TPS zu verwenden, und stellt sicher, dass „fertige“ Aufgaben gestartet werden, sobald eine geeignete Ressource verfügbar ist.

Kurz gesagt, Sie brauchen oder wollen Critical Chain nicht innerhalb eines richtig implementierten Scrum-Prozesses ... es ist eine Lösung für ein nicht vorhandenes Problem.

Wenn Ihr Projekt:

1. kann von einem Team bearbeitet werden
2. können so aufgeteilt werden, dass jeder Teil von einem Team bearbeitet werden kann

Dann ist Scrum genau das Richtige für Sie (wenn Sie natürlich auch Agilität brauchen).

Szenarien mit mehreren Teams und mehreren Projekten mit hohen gegenseitigen Abhängigkeiten erfordern eine Synchronisation zwischen den Teams. Critical-Chain-Projektmanagement ist ein Spielbuch für ein solches Szenario. Verwenden Sie es, wenn Sie es brauchen, aber spielen Sie nicht damit, wenn Sie es nicht brauchen.

Das gesagt:

Die agile Aufgabenschätzung ist grob – Sie können dies der Pufferschätzung zuordnen. Die beliebte modifizierte Fibonacci-Reihe würde Ihnen zB ca. 30 % Puffergröße. Ordnen Sie dies der Anzahl der Sprints zu, die Sie benötigen, um eine „Aufgabe“ zu erledigen. Beispiel: Team A benötigt 3 Sprints, um Feature X zu liefern: Fügen Sie einen Puffer von einem Sprint hinzu, um die Deadline zu berechnen.

Sie könnten Abhängigkeiten in teamübergreifenden Sprint-Retros oder ähnlichem regelmäßig neu bewerten, Ihr Aufgabennetz neu planen und so Terminerwartungen im Puffer aktualisieren.