Das Beste aus zwei Welten kombinieren Scrum + Critical Chain = Reliable Scrum

ScrumScrumScrum ist ein Rahmenwerk zur Entwicklung, Lieferung und Wartung komplexer Produkte, das auf eine leichtgewichtige, iterativ-inkrementelle Vorgehensweise in kurzen Lernschleifen setzt. Das Rahmenwerk definiert Rollen, Artefakte (Planungs- und Arbeitsergebnisse) und Ereignisse (Events) sowie das Zusammenspiel dieser drei Elemente. Scrum ist keine Prozessvorgabe, sondern stellt als Rahmenwerk sozusagen ein Spielfeld mit Regeln auf – die konkrete Arbeitsweise können die Anwender von Scrum innerhalb dieses Rahmens selbst definieren. ist bei Software-Entwicklungen zwar weit verbreitet und bewährt, allerdings garantiert es weder Termintreue noch einen bestimmten LeistungsumfangLeistungsumfangLeistungsumfang ist die Menge aller Leistungen, die für die Abnahme eines Projekts verpflichtend zu erbringen sind.. 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 ProjektinhaltProjektinhaltProjektinhalt bezeichnet den zu erstellenden Leistungsumfang eines Projekts. und der Abarbeitungsgeschwindigkeit zu modellieren und daraus verlässliche Prognosen für ProjektendeProjektendeDas Projektende ist der Termin , zu dem der Lenkungsausschuss ein Projekt für abgeschlossen erklärt. 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

ScrumScrumScrum ist ein Rahmenwerk zur Entwicklung, Lieferung und Wartung komplexer Produkte, das auf eine leichtgewichtige, iterativ-inkrementelle Vorgehensweise in kurzen Lernschleifen setzt. Das Rahmenwerk definiert Rollen, Artefakte (Planungs- und Arbeitsergebnisse) und Ereignisse (Events) sowie das Zusammenspiel dieser drei Elemente. Scrum ist keine Prozessvorgabe, sondern stellt als Rahmenwerk sozusagen ein Spielfeld mit Regeln auf – die konkrete Arbeitsweise können die Anwender von Scrum innerhalb dieses Rahmens selbst definieren. ist bei Software-Entwicklungen zwar weit verbreitet und bewährt, allerdings garantiert es weder Termintreue noch einen bestimmten LeistungsumfangLeistungsumfangLeistungsumfang ist die Menge aller Leistungen, die für die Abnahme eines Projekts verpflichtend zu erbringen sind.. 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 ProjektinhaltProjektinhaltProjektinhalt bezeichnet den zu erstellenden Leistungsumfang eines Projekts. und der Abarbeitungsgeschwindigkeit zu modellieren und daraus verlässliche Prognosen für ProjektendeProjektendeDas Projektende ist der Termin , zu dem der Lenkungsausschuss ein Projekt für abgeschlossen erklärt. und realisierbaren Leistungsumfang zu erstellen. Die dafür benötigten Rechenverfahren finden Sie in den beigefügten Excel-Tabellen.

Wir empfehlen zum Thema Hybrides Projektmanagement
Hybrides Projektmanagement - das Beste aus 2 Welten vereinen

Lernen Sie das Wichtigste beim Einsatz von hybridem Projektmanagement, damit auch Sie in Ihrem Unternehmen das Beste aus zwei Welten kombinieren. Mehr Infos

Die Erfolge von agilen Methoden, insbesondere von Scrum, sind unbestritten. Die enge Zusammenarbeit im TeamTeamEin Team ist eine Gruppe von Personen, die gemeinsam eine Aufgabe erledigen sollen. Meist besteht innerhalb des Teams keine formelle Hierarchie. Grundidee der Arbeit im Team ist das Zusammenwirken ergänzender Fähigkeiten und Fertigkeiten der Teammitglieder, um ein Ergebnis zu erreichen, das für jedes einzelne Teammitglied allein nicht leistbar gewesen wäre. 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-MethodeCritical-Chain-MethodeDie Critical-Chain-Methode wird in der Netzplantechnik eingesetzt, um minimale Durchführungsdauern zu erzielen. Im Gegensatz zur Methode des Kritischen Wegs (Critical-Path-Methode) verwendet die Critical-Chain-Methode lediglich eine Pufferzeit für das gesamte Projekt und nicht für einzelne Vorgänge. (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 ZeitpunktZeitpunktIn der Netzplantechnik wird mit " Zeitpunkt " ein Punkt auf einer frei gewählten Zeitachse bezeichnet, solange diese noch nicht auf die Echtzeit abgebildet ist. 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 ProblemProblem1) Aufgabenstellung, für deren Erfüllung noch keine Arbeitsanweisung besteht und für die es eine neue Lösung zu entwickeln gilt (z.B. Produktinnovation). 2) Unerwünschte Abweichung der Ist-Situation von der Soll-Situation (z.B. Kostenüberschreitung). 3) Risikofolge, die Schaden verursachen kann (z.B. Patentklage eines Wettbewerbers). 4) Einschränkende Randbedingung zur Erfüllung von Aufgaben. (z.B. Verfügbarkeit einer Engpassressource)..

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 OwnerProduct OwnerProduct Owner ist eine der drei Verantwortlichkeiten (bis 2020 Rollen) bei Scrum . Der Product Owner ist verantwortlich für das Product Backlog . die StakeholderStakeholderStakeholder (synonym: Projektbeteiligte, Interessensgruppen, Interessierte Parteien) sind: Personen, Personengruppen oder Organisationen, die aktiv am Projekt beteiligt sind oder durch den Projektverlauf oder das Projektergebnis beeinflusst werden die gegebenenfalls den Projektverlauf oder das Projektergebnis beeinflussen 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.

Gleich kostenlos weiterlesen!

  • Zum Newsletter anmelden und diesen Artikel freischalten
  • Jede Woche neue Inhalte, Tipps und Tools per E-Mail
Gratis Newsletter bestellen & sofort weiterlesen

 

Hiermit melde ich mich zum Newsletter an. Ich habe die Datenschutzrichtlinien gelesen und akzeptiere diese. Ihre Daten nutzen wir ausschließlich zum Newsletter-Versand. Sie können sich jederzeit abmelden, indem Sie auf den Link in der Fußzeile unserer E-Mails klicken. Informationen zu unserem Datenschutz finden Sie hier.
Download ZIPDownload ZIP

Jetzt Feedback geben und mitdiskutieren!

Wir würden uns über Ihre Bewertung und/oder einen Kommentar freuen ‒ nur so können wir Ihnen in Zukunft noch bessere Inhalte liefern.

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
4 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 10
Kommentare 4

Alle Kommentare (4)

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.