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.