Nur etwa die Hälfte aller Projekte kommen mit der traditionellen «Wasserfall»-Methode zum geplanten Ziel, so das Fazit von Ken Schwaber zur «klassischen» Software-Entwicklung. Die Ursache ortet er in der Schwierigkeit, dass der Auftraggeber erst zu einem sehr späten Zeitpunkt Einblick in den Entwicklungsstand erhält. Falls sich in der Zwischenzeit die Anforderungen geändert haben – was eher die Regel als die Ausnahme darstellt –, so bleiben diese Veränderungen unberücksichtigt.
Hier setzt Scrum an, das ein Framework und damit quasi ein Grundgerüst für die Projektabwicklung darstellt, aber keine detaillierte Methodik mit festgeschriebenen Prozessen und Werkzeugen bietet. Das entspricht dem Gedanken des «Agile Manifesto» (www.agilemanifesto.org), das den Mensch und die Kommunikation in den Vordergrund stellt. Entsprechend baut Scrum auf sich selber organisierende Entwicklerteams auf, die innerhalb eines kurzen Zeitraums von üblicherweise etwa einem Monat eine vorher festgelegte Funktionalität entwickeln. Am Ende eines solchen so genannten «Sprints» legen Auftraggeber, Projektleitung und Entwickler gemeinsam fest, welche Aufgaben als nächstes anzupacken sind.
Auf der einen Seite bedeutet dies, dass die Ziele für jeden Block neu definiert werden und somit Änderungen an den Anforderungen jederzeit einfliessen können. Auf der anderen Seite bringt dieses Vorgehen die gewünschte Transparenz für den Auftraggeber über den Stand des Projekts. Das ist einer der grossen Vorteile von Scrum: Der Auftraggeber weiss jederzeit, wo das Projekt steht, und kann sofort eingreifen, wenn etwas schief läuft.
Dieses Vorgehen bedeutet, dass insbesondere die Auftraggeber umdenken müssen. Ihnen kommt mit Scrum eine aktive Rolle im Entwicklungsprozess zu, indem sie mitplanen müssen. Hier ortet Ken Schwaber denn auch Widerstände beim Management des Auftraggebers, weil dieser Rollenwechsel noch ungewohnt ist.
Der Lohn dieses von Schwaber als «empirischem Prozess» bezeichneten Vorgehens liegt in einer funktionierenden Software als Endergebnis – auch wenn dieses vielleicht anders ausfällt als ursprünglich geplant. Das mag auf den ersten Blick negativ erscheinen, wenn in einem Projekt nicht sämtlichen vorgängig festgelegten Anforderungen erfüllt werden. Doch laut Schwaber werden etwa 50 bis 60 Prozent der Funktionalität, die in klassischer Software-Entwicklung entstehen, gar nie gebraucht.
Scrum rechnet denn auch damit, dass sich im Laufe des Projekts die Anforderungen ändern. Die Iterationen und die darauf folgende Überprüfung der Ziele verhindern nun, dass Funktionalität entwickelt wird, die sich später als nutzlos herausstellt. Das benötigt intensivere Planung als bei der Wasserfall-Methode, weil die Ziele quasi «just in time» den aktuellen Bedürfnissen angepasst werden. Dafür steigt die Produktivität, weil nur effektiv benötigte Module entwickelt werden. Im Endeffekt resultiert ein Scrum-Projekt also vielleicht in einem geringeren Funktionsumfang. Dafür entspricht das Resultat sehr genau den Ansprüchen zu diesem Zeitpunkt. Projekte, die agil sind, kommen also oftmals weiter.
