Springe zum Inhalt

SCRUM

Diese Methodik, die sich seit etwa 2005 in der Softwareentwicklung immer größerer Beliebtheit erfreut basiert auf folgenden Erkenntnissen:

  • Projekte lassen sich in der Regel nur schwer detailliert zu Beginn planen
  • Kunden können oder wollen ein gewünschtes Ziel oft nur recht vage beschreiben
  • Im Lauf eines Projekts ändern sich die Anforderungen oft stark
  • Teams können ur dann effizient arbeiten, wenn sie sich zumindest zeitweilig fokussieren können und sich nicht ständig alles ändert
  • Kunden sind oft mit den relevanten 80% zufrieden

Um diesen Erkenntnissen Rechnung zu tragen, kombiniert SCRUM die Prinzipien zur Prozesssteuerung und -verbesserung aus den Lean- und Kanban-Ansätzen und ergänzt sie um eine schrittweise (inkrementelle, iterative) Vorgehensweise, um sich so Schritt für Schritt in Richtung des Ziels zu bewegen.

Aus dem Lean-Prozess werden die Gedanken zur Prozessoptimierung und der kontinuierlichen Verbesserung genommen, Kanban steuert bestimmte Visualisierungen bei.

Aufgaben und Rollen

Um sicherzustellen, dass das Richtige getan wird, fordert SCRUM einen Verantwortlichen ein, der entweder der Kunde selbst, oder ein Stellvertreter des Kunden ist und der damit entscheiden kann, was alles getan werden soll und wie wichtig (wertvoll, nutzbringend) im Vergleich untereinander die einzelnen Aufgaben sind. Deise Person wird als Product Owner bezeichnet, also als derjenige, der den Nutzen aus dem entstehenden Ergebnis haben möchte. In Schulprojekten ist das in der Regel die Lehrkraft.

Dem gegenüber stehen diejenigen, die die konkreten Aufgaben erledigen müssen - das Team. Das Team ist dafür verantwortlich, dass zugesagte Arbeitsergebnisse in hoher Qualität rechtzeitig geliefert werden.

In der Praxis gibt es eine wichtige Rolle, die über die Einhaltung der Spielregeln im Ablauf wacht - der sogenannte SCRUM Master. Diese leitet die Besprechungen, sorgt daür, dass Probleme erkannt und kommuniziert werden und kümmert sich damit um einen reibungslosen Ablauf. In Schulprjekten wird diese Rolle eher mit im Team übernommen werden.

Ablauf und wichtige Aktivitäten

Der grundsätzliche Ablauf des SCRUM-Prozesses ist (entnommen von scrum.org) in der folgenden Abbildung skizziert. Ausgehend von einer priorisierten Liste von Aufgaben werden für einen definierten Zeitraum (Sprint) die derzeit wichtigsten ausgewählt. Anschließend wird fokussiert an diesen Aufgaben gearbeitet und am Ende des Sprints werden die Ergebnisse demonstriert. Danach wird der kommende Sprint geplant, usw.

ScrumFrameworkTest

Die zentralen Aktivitäten sind dabei folgende:

Grobplanung

Ziel dieser Aufgabe ist es, jederzeit eine priorisierte Liste der Aufgaben im Projekt vorliegen zu haben, aus der dann für einen Sprint die relevanten ausgewählt werden können - diese Liste wird als Product Backlog bezeichnet. Wichtig dabei ist, dass die Aufgaben so genau beschrieben sein müssen, dass sie einschätzbar sind: Wenn sich das Team dazu verpflichtet, eine dieser Aufgaben innerhalb eines Sprints zu erledigen, dann sollte das mit einer relativ hohen Sicherheit erfolgen.

Man sollte also zu jeder Aufgabe, die demnächst ansteht relativ genau wissen, wie aufwändig sie ist und ob sie ggf. weiter unterteilt werden sollte.

In der Praxis wird versucht, diese Aufgaben als Geschichten (Stories) zu formulieren, z.B.: "Als Benutzer möchte ich möglichst einfach meine letzten Rechnungen abrufen und einsehen können." Diese Art der Formulierung vereinfacht meist die Überprüfung und erlaubt es dem Team, sich den Nutzen und das Ziel der Aufgabe klar zu machen.

Sprintplanung

Zu Beginn jedes Sprints werden die wichtigsten anstehenden Aufgaben aus der Groben Planung genommen und geplant, wieviele davon in dem kommenden Sprint umgesetzt werden können. Dazu müssen die Aufgaben in der Regel detailliert betrachtet und genauer abgeschätzt werden.

Das Ergebnis dieser Planung ist die Liste der Aufgaben, die in dem Sprint erledigt werden sollen und auch realistisch erledigt werden können. Diese Liste wird als Sprint Backlog bezeichnet.

Die Aufgaben sollten in der so entstandenen Aufgabenliste so genau formuliert werden, dass jede Aufgabe von einem Teammitglied in ein bis zwei Tagen erledigt werden kann. Dadurch können Probleme schnell erkannt werden und das Erledigen der einzelnen Aufgaben bringt Erfolgserlebnisse mit sich, die für eine zusätzliche Motivation sorgen.

Die Aufgaben werden in der Regel auf einem Plakat (Kanban-Board) aufgehängt, das z.B. so aussehen könnte:Sprint Backlog.jpeg

Daily SCRUM-Meeting

Während eines Sprints trifft sich das Team täglich zu einem Treffen vor dem Sprint-Backlog. Jedes Teammitglied sagt kurz etwas zu seinen aktuellen Aufgaben, fertige AUfgaben werden von "in Arbeit" auf "fertig" umgehängt und anschließend wird eine neue offene Aufgabe genommen und auf "in Arbeit" gehängt.

So ändert sich das Poster täglich, bis am Ende des Sprints hoffentlich alle Aufgaben im Bereich "fertig" hängen. Diese Aufgaben werden dann im abschließenden Treffen mit dem Product demonstriert und wenn sie für gut befunden werden als "Abgenommen" gekennzeichnet.

Sprint-Review

Am Ende jedes Sprints gibt es ein Meeting, in dem das Team dem Product Owner die erledigten Aufgaben demonstriert. Ist der Product Owner mit dem Ergbnis zufrieden, dann werden die Aufgaben als "abgenommen" gekennzeichnet. Aufgaben, die nicht geeignet demonstriert werden werden dabei als "nicht erledigt" zurückgewiesen und kommen neu in den Bereich der offenen Aufgaben bzw. den Aufgabenvorrat.

Damit die Ergebnisse gut demonstriert werden können empfiehlt es sich, gleich bei der Formulierung der Aufgaben zu beschreiben, wie das Ergebnis gezeigt bzw. überprüft werden soll. Auf diese Weise lassen sich in der Praxis oft Misverständnisse über Inhalt und Umfang von Aufgaben ausräumen.

Restrospektive

Am Ende jedes Sprints sollte sich das Team zusammensetzen und gemeinsam überlegen, was gut und was weniger gute gelaufen war, was also verstärkt, belassen oder verbessert werden sollte. Auf diese Art kann vermieden werden, dass gleiche Fehler mehrfach gemacht werden und oft hilft es auch Schwierigkeiten im Team oder in der Kommunikation mit dem Product Owner bzw. dem Kunden aufzudecken und so auszuräumen.