Scrum-Prozess

Die Vorplanung

Vor der eigentlichen Entwicklung müssen natürlich auch bei Scrum eine Projektplanung sowie ein Design der Grobarchitektur erfolgen.

Bei der Projektplanung werden die Vorgaben für das Projekt definiert, beispielsweise welche Mitarbeiter teilnehmen, welche Entwicklungswerkzeuge genutzt und welche Konventionen eingehalten werden sollen. In diesem Rahmen wird ebenfalls eine erste Version des Product Backlogs (Sammlung der Anforderungen) erstellt. Diese Phase findet vor dem eigentlichen Scrum-Prozess statt.

Der eigentliche Prozess

Abbildung 1 zeigt den Scrum-Prozess, die definierten Artefakte und auch die festgelegten Meetings:

Abbildung 1: Der Scrum Prozess (Quelle: http://controlchaos.com/about/)

Das Product Backlog

Der Product Owner erstellt anhand von Nutzenbeschreibungen eine Liste mit Anforderungen – das Product Backlog. Die Reihenfolge der Einträge entspricht der Priorisierung. Alle Projektbeteiligten tragen zu seinem Inhalt bei. Dies geschieht nicht nur zu Beginn einer Entwicklung und ebenso nicht nur zu bestimmten Zeiten, sondern laufend. Sobald Änderungswünsche auftreten oder neue Anforderungen auftreten, werden diese eingestellt. Diese grundlegende Offenheit, fortwährend Änderungen zu akzeptieren und diese nicht als Hindernis, sondern als Notwendigkeit zu betrachten, führt zu einer hohen Flexibilität in der Entwicklung. So kann schnell auf sich ändernde Rahmenbedingungen reagiert werden, ohne das Projekt zu gefährden.

Ein Product Backlog kann beispielsweise folgende Form haben:

Das Planning Meeting und das Sprint Backlog

Das Sprint Planning Meeting findet jeweils vor einem Sprint statt. An diesem Meeting nehmen alle Projektrollen teil. Team und Product Owner entscheiden hierbei über die Inhalte des nächsten Sprints.

Der Product Owner erläutert die »Items« des Product Backlogs und erklärt den fachlichen Nutzen. Er stellt somit die Priorität der einzelnen »Items« dar. Das Team schätzt den Aufwand der »Items« ab.

Aus den „Items« des Product Backlogs werden vom Team Einträge für einen Sprint ausgewählt und in das Sprint Backlog überführt.

Sobald sich das Team und der Product Owner für die Realisierung des Sprint Backlogs im nächsten Sprint einverstanden erklären, startet der Sprint. Die Anforderungen des Sprint Backlogs sind während eines Sprints aus Gründen der Stabilität nicht änderbar.

Die Impediment List

Sobald der erste Sprint gestartet ist, kann jedes Teammitglied die sogenannten Impediments (Blocker) in eine Liste einstellen. Jedes Team Mitglied gibt, sobald sich ein Blocker für die Realisierung eines Tasks ergeben hat, diesen bekannt und stellt ihn in die Liste der Blocker. Es ist die Aufgabe des ScrumMasters diese Blocker zu beseitigen. Ein Blocker kann eine Rahmenbedingung sein, aber auch das Warten auf einen nicht fertiggestellten Task. Der Blocker wird im Daily Scrum Meeting an die anderen Team Mitglieder kommuniziert und in der Impediment List festgehalten.

Beispiel einer Impediment List:

Die zweite Tabelle stellt ein Beispiel einer Impediment List dar. Die Spalten können selbstverständlich noch erweitert werden. Ggf. wäre ein Status pro Zeile noch interessant, wenn nicht nur offene Blocker in der Liste enthalten sein sollen.

Das Daily Scrum Meeting

Hat ein Sprint begonnen, treffen sich das Team und der ScrumMaster täglich zum Daily Scrum Meeting. Das Daily Scrum Meeting ist ein informelles Meeting von maximal 15 Minuten, welches, um es kurz zu halten, oft im Stehen abgehalten wird. In diesem Meeting hat jedes Teammitglied die Aufgabe folgende drei Fragen zu beantworten:

• Was habe ich seit dem letzten Daily Scrum Meeting gemacht?
• Was werde ich bis zum nächsten Daily Scrum Meeting machen?
• Was hindert mich an meiner Arbeit (Blocker/Hindernisse)?

Dieses Meeting ist keine Diskussion, sondern eine rein mündliche Informationsverteilung an das Team.

Die Hauptaufgabe des ScrumMasters ist es, auftretende Blocker zu beseitigen, aber nicht die Steuerung des Teams. Das Team organisiert sich selbst.

Folgende Richtlinien gelten für das »Daily Scrum«:

• Das Treffen startet immer pünktlich.
• Das Treffen sollte immer am gleichen Ort und zur gleichen Zeit stattfinden.
• Das Treffen findet offen statt, jeder darf Teilnehmen, aber die eigentlichen Rollen haben Sprachrecht.
• Das Treffen ist immer auf maximal 15 Minuten, unabhängig von der Teamgröße, beschränkt.
• Die Teilnehmer sollten während des Treffens stehen. Dies soll helfen, das Treffen kurz zu halten.

Das Sprint Review Meeting / Retrospektive

Am Ende eines jeden Sprints erfolgt ein »Review Meeting«, in dem das Team die Ergebnisse dem Product Owner vorstellt. An diesem Termin herrscht eine offene Teilnahme.
Ebenfalls erfolgt am Ende eines Sprints eine rückwirkende Betrachtung, die Retrospektive, auf den Sprint. Hierbei sind nur Team und ScrumMaster eingeladen. Es wird darüber diskutiert, was zukünftig anders gemacht werden soll.

Das Ziel der Sprints

Ein Hauptwert von Scrum ist es, wie bereits erwähnt, neue Anforderungen an das System nach jeder Iteration, jedem Sprint, einfließen lassen zu können. Mit jedem Durchlauf erhält der Kunde ein lauffähiges System, welches sich im Laufe der Zeit dem reinen Endprodukt immer weiter annähert. Im Gegensatz zu anderen iterativen Entwicklungsmodellen liegt bei Scrum das Hauptaugenmerk nicht nur auf lauffähigen, sondern auch tatsächlich einsetzbaren Systemen. So soll die Entwicklung eines Gesamtsystems nicht in einzelne Module getrennt werden, die zwar getrennt voneinander geplant, realisiert, getestet und ausgeliefert werden können, aber als einzelne Module ohne das Gesamtsystem nicht wirklichkeitsgetreu eingesetzt werden können. Damit soll vermieden werden, dass der Kunde erst am Ende ein von den Anwendern tatsächlich im beruflichen Alltag einsetzbares Produkt erhält und erst dann Änderungswünsche auftauchen. Der Grundsatz dabei ist, dass der Kunde erst dann wirklich entscheiden kann, was er tatsächlich an Funktionalität benötigt und wie diese verfügbar ist, wenn er mit einem System arbeitet. Griffiger formuliert kann man sagen, dass der Kunde nicht das bekommen soll, was er spezifiziert hat, sondern das, was er tatsächlich benötigt.

Der Abschluss

Doch wie lässt sich bei so einem Ansatz zu Beginn abschätzen, wann das Endprodukt tatsächlich fertig ist? Wie lassen sich Zeit und Budget für die Gesamtentwicklung planen? Die Antwort lautet: im Allgemeinen gar nicht. Schon der Ansatz, ständig Änderungen zuzulassen, verhindert eine derart feste Planung. Im Regelfall kann nach wenigen Sprints eine lauffähige »Endversion« an den Kunden übergeben werden. Dieser entscheidet nun, ob noch weitere Änderungswünsche bestehen und somit weitere Sprints erfolgen sollen. Sollen keine weiteren Änderungen erfolgen, sei es, dass die aktuellen Wünsche des Kunden alle erfüllt sind oder der Kunde abgewogen hat, dass ein Zusatznutzen durch eine weitere Bearbeitung die dabei entstehenden Kosten nicht mehr deckt, tritt das Projekt in die »Post-Game«-Phase. In dieser wird die Entwicklung abschließend getestet und bei Fehlerfreiheit offiziell freigegeben.

Werden in dieser Phase noch Fehler erkannt, werden diese als »Bugfix« in das Product Backlog übernommen und durch einen weiteren Sprint behoben. Als Möglichkeit, um trotzdem eine Zeit- und Budgetplanung für die Gesamtentwicklung vornehmen zu können, wird häufig mit »Timeboxing« gearbeitet: Es wird ein bestimmtes Zeit-/Budget-Kontingent zur Verfügung gestellt, ohne jedoch die Projekt-Ergebnisse vertraglich abstimmen zu können. Eine Abschätzung, was in diesem Zeitraum realisiert werden kann, kann trotzdem vorgenommen werden – allerdings nie so präzise wie es bei klassischen Modellen getan wird. Ob eine möglichst detaillierte Aussage über Entwicklungszeit und -kosten allerdings bei größeren Entwicklungen im Regelfall die Wirklichkeit widerspiegelt, ist diskussionswürdig. Laut einer Umfrage, dem »Chaos Report« der Standish Group von 2004, überziehen ca. 2/3 aller Projekte weltweit die geplanten Projektkosten oder die Projektdauer oder scheitern ganz.