Agile Projekte mit Scrum

Stellen Sie sich vor, Sie wollen ein Haus bauen. Ihr Bauvorhaben ist einzigartig. Die Architektur des Hauses ungewöhnlich und der beauftragte Ingenieur hat aufwendige Berechnungen der Statik gemacht. Es sollen jedoch neue Materialen verwendet werden, und so ist ungewiss, ob die Voraussagen stimmen und ob die geplanten Massnahmen die Anforderungen wirklich erfüllen. Die zur Verfügung gestellten Baumaschinen sind erst ein halbes Jahr alt. Vom Projektteam hat noch niemand mit den neuen Maschinen gearbeitet. Für die elektrische Verkabelung und die sanitären Anlagen gibt es unterschiedlichste Standards, und so stimmen die Komponenten von verschiedenen Herstellern nicht überein.

Sowohl der Architekt, die Bauleitung als auch die Bauarbeiter konnten mit zahlreichen dieser Komponenten noch keine Erfahrungen machen. Das Haus wird zukünftig von gegen hundert Eigentümern bewohnt, die alle mit verschiedenen Repräsentanten ihre Wünsche an das Haus mitgeteilt haben. Da sich die Eigentümer das neuartige Raumgefühl vor der Fertigstellung nicht vorstellen können, haben sie jedes Mal nach einer Baubegehung neue Wünsche. Sie verlangen jeweils grundlegende Änderungen wie etwa ganze Wände zu verschieben oder die Deckenkonstruktion nochmals herunterzureissen.

Bauen nach Plan

Wie wird dieses Bauvorhaben umgesetzt? Als erstes soll der Architekt nach einigen Berechnungen des Ingenieurs zuerst einen genauen Bauplan erstellen. Die Pläne sollen dann mit den neuen Hauseigentümern besprochen werden. Anschliessend wird aufgrund der zahlreichen Wünsche der Plan angepasst, und der neue Plan muss von den Eigentümern unterzeichnet werden. Jetzt soll das Haus – genau nach Plan – erstellt werden. Wird der Projektleiter mit seinem Plan erfolgreich sein? Sie schmunzeln? Genau so verhält es sich aber in vielen Softwareprojekten. Natürlich ist das den Bauleitern nicht entgangen. Deshalb haben diese damit begonnen, immer ausgeklügeltere Pläne zu machen. Nicht nur in einem einzelnen, sondern in Dutzenden von Plänen wird alles genau festgehalten. Die Prozesse im Projekt werden präzis definiert und überwacht. Es werden Gremien und Prozesse für die Risikobeurteilung, die Qualitätssicherung, die Behandlung von Änderungen geschaffen.

Leider hat dies nicht viel genützt. Die grundlegenden Probleme wurden damit nicht gelöst. Im Gegenteil, die Projekte wurden einfach noch viel teurer. Dieses Scheitern wurde eindrücklich in einer der wohl am häufigsten zitierten Studie der Informatik-Branche dokumentiert, dem sogenannten Chaos-Report der Standish Group. Wie die Studie feststellt, werden nämlich rund ein Drittel der Softwareprojekte nach Baubeginn gar nie fertiggestellt, und etwa die Hälfte der Projekte haben am Schluss rund doppelt soviel gekostet wie ursprünglich geplant. Nur etwa jedes zehnte Projekt wird nach dem ursprünglichen Zeitplan zu den vorhergesagten Kosten gebaut. Leider sehen diese Lösungen am Ende völlig anders aus als geplant.

Scrum, eine agile Methode

So kann das nicht weitergehen, sagten sich im Jahr 2001 zwölf führende Köpfe der Software-Engineering-Branche und legten in einem «Agilen Manifest» neue Grundsätze fest, welche das bisherige Vorgehen auf den Kopf stellten. Die einzelnen Protagonisten des Manifests entwickelten eine Reihe von Methoden, welche alle auf diesen Grundideen aufbauen. Dazu gehört Crystal Clear, Extreme Programming, Feature Driven Development oder eben auch Scrum (Gedränge).


Wie würde die Bauleitung vorgehen, wenn sie Ihr Haus mit einem Scrum-Ansatz bauen würde? Anstatt zu Beginn das gesamte Haus exakt zu planen, werden alle Kundenwünsche von den unterschiedlichen Stakeholdern gesammelt (Product Backlog). Die Kundenwünsche werden vom Product Owner priorisiert. In einem Planungsmeeting, an dem auch die Bauherren teilnehmen, soll bestimmt werden, welches Zimmer als erstes gebaut wird (Release Backlog).

Diese Entscheidung wird von zwei Faktoren stark beeinflusst. Welches Zimmer braucht der Bauherr als erstes – vielleicht soll es sogar bereits bewohnt werden – und welche Risiken bestehen. Wenn es ein Zimmer gibt, ohne dessen Bau das ganze Haus kein Sinn macht, aber auch nicht klar ist, ob das Zimmer auch wirklich erfolgreich gebaut werden kann, macht es wohl Sinn, dieses als erstes in Angriff zu nehmen. Damit würden nicht zu viele Kosten ausgegeben, ohne zu wissen, ob das Zimmer überhaupt erfolgreich gebaut werden kann. Ist einmal festgelegt, welches Zimmer gebaut werden soll, werden in dem Planungsmeeting alle notwendigen Aufgaben festgehalten (Sprint Backlog).

Der Scrum-Prozess im Überblick

Iteration = Sprint

In einer Iteration (Sprint) von maximal drei Wochen wird eine erste Version dieses Zimmers umgesetzt. Täglich werden Statusmeetings von 15 bis 20 Minuten durchgeführt. In einer Übersicht wird dargestellt, welche Sprint-Aufgaben erledigt und welche noch zu bearbeiten sind.


Das nach drei Wochen fertiggestellte Zimmer kann dann von den Auftraggebern sorgfältig begutachtet werden, bevor weitere Teile des Hauses gebaut werden. Änderungswünsche werden alle im Product Backlog festgehalten. Es sind durchaus grundlegende Änderungen denkbar. Vielleicht wird das Zimmer sogar neu gebaut oder neu unterkellert.

Vor dem nächsten Sprint wird dann wieder in Zusammenarbeit mit dem Auftraggeber definiert, welche Aufgaben anstehen. Während den drei Sprint-Wochen hingegen, werden möglichst keine Änderungen an der Planung vorgenommen.
Damit unterscheidet sich das Vorgehen grundsätzlich von einem traditionellen Ansatz, in dem zuerst das gesamte Haus geplant und dann als ganzes umgesetzt wird. Hier wird Zimmer für Zimmer umgesetzt.

Man spricht auch von einem «Value up»-Paradigma. Es soll in erster Linie eine für den Auftraggeber nutzbare Funktionalität erstellt werden. Dies garantiert nur ein fertiggestelltes Zimmer – also eine zusammenhängend nutzbare Funktionalität. Feature für Feature wird die Software dann fertiggestellt. Ist ein Auftraggeber unter grossem Zeitdruck, kann er damit auch das Ergebnis des einen Sprints bereits ausbreiten.


Änderungen werden bewusst zugelassen, ja sogar vorgesehen. Die Protagonisten des agilen Vorgehens schrecken nicht einmal von Änderungen an der Architektur eines Systems zurück. Daher gehen Techniken wie automatisierte Unit-Tests und systematisches Refactoring Hand in Hand mit einem Entwicklungsansatz, in dem das Design während des Projekts geändert wird. Dank Unit Testing kann die Funktionsfähigkeit nach jeder Änderung überprüft werden. Refactoring hilft, das Design laufend wieder zu verbessern.



Sprint Burndown Chart

Stetiges Feedback

Aufgrund der regelmässigen Kommunikation, in welcher Reflexion eine wichtige Rolle spielt, und des stetigen Feedbacks des Auftraggebers wird der Entwicklungsprozess laufend verbessert. Da nach jedem Sprint ausführbarer Code geliefert wird, bleiben insbesondere Erkenntnisse, die mit einem traditionellen Ansatz erst während der Testphase sichtbar würden, nicht verborgen. Die Auftraggeber können sich zu einem frühen Zeitpunkt einen Eindruck der Funktionalität am laufenden System machen.


Agile Vorgehensweisen wie Scrum sind somit geeignet, wenn Softwareprojekte starken Innovations-Charakter haben. In solchen Projekten sind die Anforderungen nur diffus bekannt oder sie werden sich während des Projekts stark ändern. Agile Vorgehen gehen damit von oftmals realistischen Annahmen aus und reduzieren durch den Value-up-Ansatz die Projektrisiken ganz entscheidend. Was nicht vorausgesagt werden kann, wird auch nicht versprochen.



Scrum liefert jedoch wenig Unterstützung, wenn spätere Entscheidungen nachvollziehbar sein müssen. Auch die Akzeptanz des Managements gegenüber einer agilen Vorgehensweise, bei der wenig feste Zusagen zu Zeit, Qualität und Kosten gemacht werden, dürfte wohl vielfach fehlen. Zudem bleibt es umstritten, ob die agilen Methoden auch im Umfeld sehr grosser Projekte angewandt werden können.

Nur wenige Vorgaben

Im Vergleich zu anderen Vorgehensweisen fällt bei Scrum auf, wie wenig vorgegeben wird. Im Unified Process zum Beispiel werden 80 Artefakte, 40 Rollen und 150 Tätigkeiten beschrieben. Mit 4 Artefakten, 4 Rollen und 4 Tätigkeiten dürfte Scrum wohl das untere Ende der Skala an möglichen Vorgaben darstellen.

Die Gestaltung der meisten Aktivitäten wird also dem Team überlassen. In Scrum spricht man von kontrolliertem Chaos, das für innovative Projekte notwendig sei. Der Erfolg von Scrum ist vielleicht gerade aufgrund dieser Tatsache erklärbar. So stellt Scrum eine generell für iterative Vorgehen minimale Menge an sinnvollen Vorgaben dar, die rasch erklärt und verstanden werden. Für viele einfache Projekte dürften diese Vorgaben ausreichend sein. Sie können aber auch in anderen, komplexeren Vorgehensweisen wie dem Rational Unified Process durchaus umgesetzt werden.



Im Vergleich zu anderen agilen Methoden setzt Scrum die Kommunikationsaspekte in den Vordergrund. Gerade bei den Meetings wird relativ genau beschrieben, wie diese organisiert werden sollen. So machte das tägliche Scrum-Meeting Furore, das im Stehen abgehalten werden soll.