Scrum

Was ist Scrum?

Scrum ist ein agiles Vorgehensmodell, das ursprünglich für die Softwareentwicklung entwickelt wurde, inzwischen aber in vielen anderen Bereichen eingesetzt wird. Große Aufgabenkomplexe werden in kleine Bestandteile, sog. Inkremente aufgeteilt. Bei Scrum steht die Anwendersicht der Anforderungen im Vordergrund. All diese Anforderungen (= Product Backlog) werden in Intervallen von normalerweise 1 bis 4 Wochen entwickelt, den sog. Sprints (Entwicklungszyklus). Dies liefert Zwischenergebnisse, welche als Basis für die nächsten Entwicklungsschritte dienen. Grundsätzlich sollte nach einem Sprint ein fertiges Teilprodukt (= Product Increment) geliefert werden können. Dieses wird im sog. Review Meeting gemeinsam überprüft und in einem darauf folgenden Planning Meeting wird der nächste Sprint geplant (= Empirie). Somit wird nicht nur das zu entwickelnde Produkt sondern auch die Planung selbst agil, iterativ und inkrementell. Dadurch wird der Hauptplan kontinuierlich konkreter und detaillierter: Die Hauptplan-Aufgaben (der Product Backlog) werden in kleinere Aufgabenpakete aufgeteilt und einzelnen Sprints zugeordnet (Sprint Backlog).

Das führt zu einer kontinuierliche Verbesserung in kleinen bis großen Schritten, je nachdem, wie die aktuellen Anforderungen liegen. Zudem ist Scrum iterativ, es finden also Wiederholungen von Prozessen statt. Dies alles unterscheidet Scrum von gewöhnlichen, starren Projekten, die nach einem vorher entstandenen Plan mit ausufernden Lasten- und Pflichtenheften 1:1 umgesetzt werden. Gerade bei umfangreichen Projekten eignet sich das agile Vorgehensmodell, da hier die detaillierte Planung aller Teilaspekte erfahrungsgemäß nicht gewährleistet werden kann. Das führt dazu, dass während der Umsetzung Fragen auftauchen, die Anforderungen geändert werden und somit Zeit, Ressourcen und finanzielle Mittel überansprucht werden.

Besondere Vorteile von Scrum:

Transparenz für alle Beteiligten: Entwicklungsstand und Probleme werden regelmäßig protokolliert und sind für alle sichtbar.
Kontrolle: Die Funktionalitäten werden regelmäßig geprüft und beurteilt.
Anpassung der Anforderungen: Durch regelmäßige Treffen (Review Meetings, Planning Meetings s. u.) kann das Endprodukt kontinuierlich verbessert werden.

All das macht Scrum zwar nicht zu einem weniger komplexen Ansatz, strukturiert die Arbeit aber besser, was letztendlich kostenffizienter ist. Scrum ist ausgelegt für Teams aus 3 bis 9 Mitgliedern, wobei jedem eine Rolle zugewiesen wird.

Das Rollenmodell von Scrum

Bei Scrum gibt es festgelegte Rollen mit eigenen Rechten und Aufgabenbereichen. Diese haben aber mit der tatsächlichen Unternehmenshierarchie nichts zu tun, sondern nur mit der fachlichen Eignung der Mitarbeiter.

Zum einen gibt es Auftraggeber (Product Owner). Dieser ist meist der Kunde oder ein Vertreter des Kunden, der die fachlichen Anforderungen stellt und die Entwicklungen beurteilt. Er übernimmt die Sicht des letztendlichen Nutzers des Produkts. Da er für die fachlichen Anforderungen verantwortlich ist, ist es seine Aufgabe, den Product Backlog zu pflegen und zu priorisieren. Weiterhin steht er für Rückfragen des Teams zur Verfügung.

Der Scrum Master ist dafür verantwortlich, dass der Scrum-Prozess korrekt abläuft. Dazu ist er das Bindeglied zwischen Product Owner und Entwicklerteam. Er sorgt dafür, dass Hindernisse (Blocker) beseitigt werden. Das könnte z. B. eine fehlende Spezifikation sein, oder auch eine fehlende Ressource. Er moderiert außerdem die Scrum-Meetings und stellt sicher, dass das Team arbeiten kann. Er muss sowohl das Product Backlog als auch das Sprint Backlog im Blick haben.

Das Entwicklungsteam setzt die Anforderungen an das Produkt um. Es besteht zum einen aus Entwicklern, aber auch aus Testern, Redakteuren etc. (Interdisziplinarität). Das Team organisiert sich selbst, was bedeutet, dass es selbst Aufgaben verteilt und auf die selbst gewählte Weise löst. Ist ein Product Increment fertig, präsentiert das Team dieses im Review Meeting. Damit Scrum funktionieren kann, ist es oberste Priorität, dass das Entwicklerteam ohne Hindernisse arbeiten kann.

Scrum-Meetings

Bei Scrum gibt es verschiedene Arten von Meetings, die von unterschiedlichen Beteiligten besucht werden. Um die Meetings und den gesamten Prozess effizient zu halten, ist das Einhalten von Zeiten unentbehrlich. In den Meetings werden Sprints geplant und überprüft. Folgende Meetings gibt es:

Sprint Planning Meeting: Hier zeigt der Product Owner die im Product Backlog am höchsten priorisierten Increments und entscheidet gemeinsam mit dem Team, welche Teile aus dem Product Backlog den kommenden Sprint Backlog darstellen. Product Owner und Team einigen sich auf die Akzeptanzkriterien des zu entwickelnden Product Increments. Autonom plant das Team den kommenden Sprint und die vorhandenen Ressourcen und bricht die Anforderungen in Einzelaufgaben herunter. Dabei können verschiedene Techniken angewendet werden (siehe unten).

Sprint Review Meeting: Hier zeigt das Team dem Product Owner die erreichte Entwicklung des letzten Sprints. Funktionalitäten können überprüft werden und der Product Owner kann Feedback dazu abgeben.

Daily Scrum Meeting: Dieses kurz zu haltende (15 Minuten) tägliche Meeting ist für das Team da, um sich gegenseitig auf dem Laufenden zu halten. Es werden die Fragen beantwortet, was seit dem letzten Daily getan wurde, was bis zum nächsten Daily gemacht wird und was eventuelle Blocker waren, die den Entwickler an der Arbeit gehindert haben. Diese Blocker notiert der Scrum Master und versucht, sie zu lösen.

Retrospective Meetings: Diese werden genutzt um rückblickend zu besprechen, was vorher gut und was schlecht lief und was die Arbeit beim nächsten Mal besser, produktiver, effizienter und angenehmer machen würde.

Sprints

Ein Sprint oder Entwicklungszyklus wird vom Team gemeinsam geplant und durchgeführt. Es ist wichtig, dass das Team innerhalb eines Sprints keine neuen Anforderungen an das Increment erhält, sodass das Team möglichst effizient arbeiten kann. Wie lange ein Sprint dauert, hängt unter anderem davon ab, wie schnell die Entwicklungen ablaufen können, wie komplex ein Sprint ist und wie hoch die Anforderungen. Meist geht ein Sprint 1 bis 4 Wochen. Er endet mit dem Sprint Review Meeting.

Hilfreiche Techniken

User Stories

Aus Sicht des Benutzers werden Anforderungen in Form von User Stories aufgestellt. Eine User Story könnte z. B. sein: Als Mitarbeiterin im Unternehmen möchte ich eine Kühlmöglichkeit haben, um mein Mittagessen dort aufzubewahren. Die Systematik ist also: Als Nutzer will ich Funktion, damit Nutzen. User Stories bilden dann den Product Backlog und können dort weiter spezifiziert werden (Product Backlog Refinement).

Planungspoker

Um abschätzen zu können, wie hoch der Entwicklungsaufwand einzelner Aufgaben bis hin zu User Stories ist, wird seit 2005 gerne auf Planungspoker zurückgegriffen: Auf Spielkarten stehen verschiedene Werte von leicht bis schwer oder wenig bis viel. Die Entwickler schätzen jeder für sich den Aufwand einer Aufgabe mit Hilfe der Spielkarten. Gleichzeitig werden alle Karten aufgedeckt. Die Teilnehmer mit dem höchsten bzw. niedrigsten Wert sollen ihre Beweggründe mitteilen. In einer anschließenden Diskussion wird sich auf eine gemeinsame Schätzung geeinigt.

Weitere Informationen