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…