Das Beste aus zwei Welten kombinieren

Scrum + Critical Chain = Reliable Scrum

Scrum ist bei Software-Entwicklungen zwar weit verbreitet und bewährt, allerdings garantiert es weder Termintreue noch einen bestimmten Leistungsumfang. Wolfram Müller beschreibt, wie er durch eine Kombination mit der Critical Chain-Methode die Zuverlässigkeit eines nach Scrum durchgeführten Projekts deutlich erhöht. Dieses von ihm "Reliable Scrum" genannte Vorgehen besteht darin, die Unsicherheiten im Projektinhalt und der Abarbeitungsgeschwindigkeit zu modellieren und daraus verlässliche Prognosen für Projektende und realisierbaren Leistungsumfang zu erstellen. Die dafür benötigten Rechenverfahren finden Sie in den beigefügten Excel-Tabellen.

Das Beste aus zwei Welten kombinieren

Scrum + Critical Chain = Reliable Scrum

Scrum ist bei Software-Entwicklungen zwar weit verbreitet und bewährt, allerdings garantiert es weder Termintreue noch einen bestimmten Leistungsumfang. Wolfram Müller beschreibt, wie er durch eine Kombination mit der Critical Chain-Methode die Zuverlässigkeit eines nach Scrum durchgeführten Projekts deutlich erhöht. Dieses von ihm "Reliable Scrum" genannte Vorgehen besteht darin, die Unsicherheiten im Projektinhalt und der Abarbeitungsgeschwindigkeit zu modellieren und daraus verlässliche Prognosen für Projektende und realisierbaren Leistungsumfang zu erstellen. Die dafür benötigten Rechenverfahren finden Sie in den beigefügten Excel-Tabellen.

Die Erfolge von agilen Methoden, insbesondere von Scrum, sind unbestritten. Die enge Zusammenarbeit im Team und die hohe Produktorientierung beflügelt die Kreativität aller Beteiligten. Die vielen Iterationen sowie die starke Einbindung des Auftraggebers stellen den wirklichen Nutzen in den Mittelpunkt. Die Abschottung der Teams während der Sprints verhindert das schlimmste Multitasking und die Retrospektiven sorgen für eine kontinuierliche Verbesserung.

Doch in der Realität fällt es vielen Organisationen immer noch schwer, mit Scrum zu arbeiten. Auch wenn Scrum einfach, eingeübt und schon weit verbreitet ist, sind die Ergebnisse oft nicht zufriedenstellend und es kommt immer wieder zu Verzögerungen. Dieser Beitrag beschreibt eine Möglichkeit, wie sich Scrum optimieren und die Planbarkeit deutlich verbessern lässt: Das "Reliable Scrum" genannte Vorgehen kombiniert Scrum (Schwaber, Sutherland, 2011) und die Critical-Chain-Methode (Goldratt, 2002; Müller, 2010) zu einer Projektmanagementmethodik, mit der die beiden Ziele "Termintreue" und "Erfüllung des Leistungsumfangs" ausgewogen gesteuert werden können.

Warum Reliable Scrum?

Bevor wir uns die Funktionsweise von Reliable Scrum genauer ansehen, werfen wir einen Blick in die Praxis und betrachten anhand einiger Beispiele, warum es für Reliable Scrum überhaupt einen Bedarf gibt.

Scrum kann keinen Scope garantieren – It’s done when it’s done

Angenommen, Sie sind für ein großes Projekt verantwortlich, in dem ein wichtiger Teil agil entwickelt wird, der zu einem definierten Zeitpunkt fertig sein muss. Mit einem Product-Burndown-Chart gibt Ihnen das Scrum-Team jederzeit volle Transparenz über den aktuellen Stand; Sie sehen nach jedem Sprint, ob der Termin gehalten wird oder nicht. Wenn Sie das Team fragen, ob alles rechtzeitig fertig wird, erhalten Sie als Antwort: "Wir liefern das Beste, was wir können", aber: "It's done when it's done!" Zuverlässigkeit bzgl. Scope und Termin ist aber bei Projekten mit vielen zu integrierenden Teilen unverzichtbar – als Verantwortlicher haben Sie jetzt ein Problem.

Oder stellen Sie sich z.B. ein börsennotiertes Unternehmen vor. Hier gilt es, große Innovationen zu schaffen. Diese werden auf Messen angekündigt, die Vertriebspipelines müssen gefüllt werden und vor allem muss rechtzeitig Marketing betrieben werden. Aber was, wenn das Produkt dann nicht verfügbar ist? Auf das fertige Produkt warten und dann erst mit dem Marketing zu beginnen, verschenkt wertvollen Vorsprung. Zuverlässigkeit bzgl. Scope und Termin sind entscheidend.

Diffuses Erwartungsmanagement

In einem Scrum-Projekt repräsentiert der sog. Product Owner die Stakeholder und managt das Backlog (d.h. die Liste der zu realisierenden User Stories). Bei mehreren Stakeholdern wird es aber schnell schwierig, alle gewünschten Funktionen (formuliert in sog. User Stories, im Folgenden "Stories") aufzunehmen, denn dies kann u.U. das Projekt sprengen. Aber woher weiß der Product Owner, was zu viel ist? Und wie wird das transparent? Das Hauptproblem ist hier, dass die Stakeholder alle Wünsche äußern können, ohne dass sowohl der Preis als auch die Folgen transparent werden. Die Konsequenz ist eine unklare Erwartungshaltung.

Wunsch-Features dienen als Puffer

Selbst wenn etwas pünktlich fertig wird, ist die Enttäuschung bei den Stakeholdern häufig groß – denn was ist mit all den versprochenen Wunsch-Features? ("Should" und "Could" in der MoSCoW-Terminologie, s. Begriffsdefinition im Glossar des Projekt Magazins www.projektmagazin.de/glossar.) Ich als Stakeholder kann doch davon ausgehen, dass Wünsche erfüllt werden? Scrum arbeitet stark mit Wunsch-Funktionen, die im Notfall als Puffer verwendet werden. Das Problem dabei ist, dass die Stakeholder hören, dass viele Funktionen kommen werden und dann enttäuscht sind, wenn etwas entfällt.

Kein geeignetes Werkzeug für Planung und Steuerung

Dem Product Owner steht in der Regel kein geeignetes Werkzeug zur Verfügung, mit dem er genau erkennen kann, wie viele Stories er in ein Release noch ziehen kann oder daraus entfernen muss. Und wann kann er welche Funktionalität versprechen, wenn sich das Backlog oder die Velocity (Abarbeitungsgeschwindigkeit) laufend ändern?

Backlog und Velocity sind variabel

In vielen Fällen werden das Backlog und die Velocity als unveränderliche Größen betrachtet. Doch sowohl im Backlog (z.B. durch unvorhergesehen Ereignisse oder neue Wünsche) als auch in der Velocity (z.B. durch krankheitsbedingte Ausfälle) gibt es Streuungen, die nicht transparent sind und die mit den Stakeholdern nicht verhandelt wurden. Ein typisches Beispiel ist die Ablösung eines Altsystems. Hier tauchen im Laufe des Projekts immer wieder ungeahnte, nicht dokumentierte Probleme auf, die in Form von zusätzlichen Stories bearbeitet werden müssen. Dadurch müssen auch die Termine jedes Mal neu angepasst werden und die Stakeholder verlieren das Vertrauen in eine termingerechte Fertigstellung.

Stories enthalten Puffer

Für das Team sind wiederum die Sprints heilig – sie versprechen Ruhe vor den Stakeholdern. Für die Stakeholder sind es aber die einzigen Punkte, an denen sich der Fortschritt messen lässt – diese Transparenz ist für die Stakeholder existenziell. Vor dem Sprint einigt sich das Team daher auf eine bestimmte Menge an Stories, die es im Sprint umsetzen möchte und die es damit zusichert. Nach dem Sprint wird abgerechnet (oder neudeutsch "reviewed"). Wenn eine Story dann nicht rechtzeitig fertig wurde, wird das Team mit 0 Story-Points "bestraft". Es ist leicht nachvollziehbar, was im nächsten Sprint passiert: Das Team verpflichtet sich einfach auf weniger Stories und erzeugt damit einen impliziten bzw. verdeckten Puffer. Daher sind auch Scrum-Teams vor den…

Bewertungen und Kommentare

(nur angemeldete Benutzer)

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
Gesamt
Bewertungen 9
Kommentare 4

Alle Kommentare

Marco
Klemm
Klasse Zusammenfassung vieler Scrum-Problematiken. Gerade das mit den versteckten Puffern und dem zu kalkulierenden Gesamt-Leistungsumfang in Sprints ist ein hausgemachtes Problem. In der Praxis spielt es häufiger weniger eine Rolle, dass genau die im Planning "versprochenen" User Stories in den nächsten 3 Wochen fertig werden, sondern dass möglichst viel bis zum *anvisierten Projektende* geschafft wird. Hier bietet IMHO die Verbindung mit Chritical Chain einen sehr guten Ansatz. Beste Grüße, Marco Klemm
Heinrich
Unger
Dipl.-Ing.
Sehr guter Artikel. Nur wie bekommt man vom Auftraggeber einen offiziellen Puffer am Ende des Projekts? Sobald man einen Puffer deklariert, ist der auch schon wegverhandelt und ein neues früheres Enddatum wird verlangt.
Heinrich
Unger
Dipl.-Ing.
Was mir noch aufgefallen ist, ist der Backlog. Es sind bis zu 50% mehr zum Bestcase 250 Points. D.h. der kunde bekommt mehr Leistung ohne Zuzahlung - da möchte ich aber als Dienstleister zumindest objektive Erfüllungskriterien, damit das nicht zum WÜnsch Dir was auf meine Kosten ausartet. Bzw. im vertraglichen Worst Cast - damit ich die Erfüllung meiner Leistung vor Gericht belegen kann, und meinen Geldforderungen erfüllt werden müssen
Guest
Einem Scrum Puristen stehen bei diesem Ansatz natürlich die Haare zu Berge. Durch die Hinzunahme der Critical Chain werden grundlegende Aspekte von Scrum ausgehebelt. Das z.B. ein Scrum Master mit dem Team zusammen die Velocity schätzt, damit überhaupt Wahrscheinlichkeitsraum-Berechnungen möglich werden, hat nichts mehr mit Scrum zu tun. Scrum verwendet gemessene Werte der Realität. Ich brauche bei Scrum keine "Puffer", damit sich das Team sicherer fühlt oder gar motivierter unterwegs ist. Das scheint eher eine Notwendigkeit dieses Denkansatzes zu sein, da die Grundidee wieder klassisch daherkommt: wir planen alles im voraus und ihr habt gefälligst fertig zu werden (ob es paßt oder nicht). Gut, das wird jetzt nicht mehr so explizit betont. Es gibt jetzt mehr Spielraum. Aber mit den agilen Ideen hat das nicht wirklich viel zu tun. Besonders interessant ist die Aussage, daß Reliable Scrum dort "überflüssig" wird, wo Scrum seine größten Stärken hat: nach einem Sprint potentiell auslieferbaren Code zu erzeugen und produktiv zu nutzen. Agil heißt vor allem Komplexität reduzieren, Verschwendung vermeiden, schnell auf den Punkt kommen und das liefern, was als nächstes gebraucht wird. Ein Sprint ist bewußt kurz gewählt, damit schnell auf geänderte Anforderungen reagiert werden kann. Es ist eben nicht das Ziel alles zu einem bestimmten Zeitpunkt fertig zu haben, sondern die wichtigsten Dinge zuerst zu liefern und zwar so, daß man sie auch sofort nutzen kann. Die Stakeholder können nach jedem Sprint entscheiden, ob sie fertig sind oder weitere Funktionalität benötigen und weiter gemacht wird. Insofern stellt sich auch nie die Frage, ob das, was im Product Backlog bereits festgehalten wird oder noch hinzukommt, bzgl. einer Machbarkeit in der Umsetzung bewertet werden muß. Einen Product Backlog würde man in Scrum auch nicht "reduzieren". Damit würde ich ja einen Teil der Ideen, die in der Zukunft einen Business Value generieren könnten, quasi wegwerfen. Wenn die Stakeholder mit diesem Vorgehen nicht zurechtkommen, dann sollte lieber klassisch vorgegangen werden. Ein bischen Scrum bringt zu wenig Effizienzsteigerung als das sich der Aufwand der Scrum-Einführung lohnen würde. Und auch wenn eingangs kritisiert wurde, daß das Vorgehen nach Scrum-Lehrbuch keinen Sinn ergibt, kann ich nur erwidern: Das Scrum-Framework ist in seiner Darstellung auf das absolut notwendigste reduziert worden. Lasse ich was weg, verliere ich Effizienz. Deshalb machen Hybride aus klassisch und agil nur dann Sinn, wenn das Scrum-Framework dabei komplett implementiert wird. Das ist aber hier leider nicht der Fall.
Alle anzeigen