SCRUM - agiles Projektmanagement

Veröffentlicht auf 2. Februar 2009

Das agile Projektmanagement ist zur Zeit in vieler Munde. Ein Ableger davon ist SCRUM (englisch für "das Gedränge").
Dahinter versteckt sich die Idee, dass große und komplexe Software Projekte einfacher zu managen sind, wenn sie in mehrere kleine Arbeitsabschnitte (Increment) aufgeteilt werden.

Auf die Softwareentwicklung übertragen bedeutet dies, dass man Software am Besten inkrementell entwickelt und mit dem wichtigsten Teil der Software zuerst anfängt. Besonders dabei ist jedoch der Ansatz des „Increment of Potentially Shippable Functionality“ von SCRUM, der sich etwas von manch anderen agilen Modellen unterscheidet. Es werden nicht nur Meilensteine für die Entwicklung von Software gesetzt, sondern auch die Qualität eines Meilensteins muss so definiert sein, dass der Auftraggeber (Product Owner) mit einer abgeschlossenen Iteration (Sprint – dauert i.d.R. ca. 4 Wochen) immer eine neue, in sich abgeschlossene, Funktionalität erhält, die Produktiv einsetzbar ist (hohes Return on Investment bereits ab der ersten Iteration!). Darin eingeschlossen sind eine angemessene Dokumentation der Software und abgeschlossene bzw. erfolgreiche Tests.
Dieses Arbeitspaket wird in noch kleinere Arbeitspakete (Tasks) aufgeteilt und in einem „Sprint Backlog“ mit zuständigem Bearbeiter und Restaufwand festgehalten. Diese „Tasks“ sind unveränderlich und das „Team“ soll möglichst ungestört, eigenverantwortlich und selbst organisiert an der Fertigstellung arbeiten können. Die Koordination wird durch ein „Daily Scrum Meeting“ gewährleistet, dass allerdings nicht länger als 15 Minuten dauern darf. Hier werden kurz und komprimiert neue Informationen, Probleme und Aktivitäten kommuniziert. Alles weitere wird unter den betreffenden Personen außerhalb des Meetings geregelt. Ziel davon ist es, die unproduktive Zeit von nicht beteiligten Personen auf ein Minimum zu reduzieren.

Am Ende eines „Sprints“ präsentiert das „Team“ dem „Product Owner“ und weiteren Beteiligten, den „Stakeholdern“, in einem „Sprint Review Meeting“ (maximal 4 Stunden) die neu gewonnene Funktionalität. Unfertige Funktionen oder Präsentationen sind hierbei komplett unerwünscht! Die Reaktionen der Beteiligten und neue Anforderungen fließen in den nächsten Sprint mit ein.

Verantwortlich für die Planung und das Management des gesamten Prozesses ist der „Scrum Master“. Er sorgt dafür, dass die Regeln des SCRUM eingehalten werden und das „Sprint Backlog“ täglich aktualisiert wird. Probleme und Hindernisse werden von ihm im „Impediment Backlog“ festgehalten. Durch so genannte „Burndown Charts“ wird der aktuelle Projektfortschritt sichtbar gemacht, darin enthaltene „Trendlinien“ ermöglichen es Probleme und Verzögerungen frühzeitig zu erkennen.

Der Vorteil in diesem Vorgehen liegt darin, dass Fehlentwicklungen bzw. -entscheidungen früh erkannt werden können, da die Anforderungen, Architektur, Technologie, Schnittstellen und Benutzbarkeit früh auf den Prüfstand, durch Entwicklerteam und Auftraggeber, gestellt werden und somit frühzeitig korrigiert werden können.

Den iterativen Entwicklungszyklus von SCRUM kann man mit 3 Worten beschreiben: Apply – Inspect - Adapt
1. Apply
Anfangen nach der Priorisierung des „Product Backlogs“ zu entwickeln!

2. Inspect
Regelmäßige Erfolgskontrolle!
Fehler in Produkt und Prozess analysieren!

3. Adapt
Spezifikation (Product Backlog) anpassen, verfeinern und ggf. neu priorisieren!
Fehler in Produkt und Prozess strikt beseitigen!
Ggf. Alternativen suchen!
Lieber mal etwas wegwerfen, als sich in irgendwas zu verrennen!
Mitarbeiterfähigkeiten, Arbeitsmittel und Methoden optimieren!

Vor jedem Zyklus gibt es ein „Sprint Planning Meeting“ (maximal 8 Stunden), in dem die Arbeitspakete und das „Sprint Backlog“ definiert werden. Im Nachhinein ein „Sprint Retrospective“ (maximal 3 Stunden), in dem alle Beteiligten über den letzten Sprint diskutieren, „Best Practices“ festhalten und Verbesserungsvorschläge machen.

SCRUM erfüllt damit die Anforderungen des Agilen Manifests, das unter anderem von Ken Schwaber und Jeff Sutherland mitformuliert wurde:
1. Individuen und Interaktion gelten mehr als Prozesses und Tools.
2. Funktionierende Programme gelten mehr als ausführliche Spezifikationen.
3. Die stetige Zusammenarbeit mit dem Kunden steht über Verträgen.
4. Der Mut und die Offenheit für Veränderungen steht über dem Befolgen eines festgelegten Plans

Aus meiner eigenen Sicht bevorzuge ich die agile Softwareentwicklung gegenüber anderen Modellen. Richtig eingesetzt, kann sie zu besseren Produkten, durch eine höheren Qualität, eine höhere Mitarbeiterzufriedenheit, durch mehr Kreativität und Spielraum, und eine höhere Kundenzufriedenheit sorgen. Gleichzeitig erfolgt die Entwicklung in einer schlanken Struktur effizienter und schneller, was zu einer früheren Marktreife der Software führt. Durch all diese Punkte können Kosten enorm reduziert werden.
Ein nicht zu unterschätzender Nachteil besteht jedoch schon bei der Einführung von agilen Methoden, die sich anfänglich aus Unkenntnis und Ignoranz viel Kritik ausgesetzt sehen.
Arbeiten zudem das Management, das Team oder der Kunde nicht nach den agilen Regeln zusammen, passt das Firmenumfeld nicht, gibt es Einzelkämpfer oder ist das Team mit der neu gewonnenen Freiheit überfordert, ist SCRUM genauso wie jede andere Methode zum scheitern verurteilt. Diese Phase muss, wenn nötig unter Schmerzen, überwunden werden, um erfolgreich zu werden!

Weitere Informationen zu SCRUM gibt es unter:
http://scrum-master.de
http://de.wikipedia.org/wiki/Scrum
http://en.wikipedia.org/wiki/Scrum_(development)

Ein praktisches SCRUM-Plakat gibt es unter:
http://scrum-master.de/files/Scrum_on_1_page.pdf

Software für agiles Arbeiten:
http://www.userstories.com/products

Buchtipps:

SCRUM
Titel:Scrum - Agiles Projektmanagement erfolgreich einsetzen
Autor: Roman Pichler
Verlag: DPunkt
Fachbuch mit detaillierten Informationen
Weitere Bücher zu SCRUM