Wie funktioniert eigentlich Scrum?

Um ein mit solcher Intensität durchgeführtes Projekt auf Kurs zu halten, ist gründliche Vorbereitung unerlässlich. Am Anfang eines Scrum-Prozesses steht daher stets die sogenannte Vision: Was soll das das fertige Produkt leisten, welchen Bedürfnissen und Ansprüchen des Kunden muss es gerecht werden? Auf Grundlage dieser Vision entwickelt der Product Owner dann das sogenannte Product Backlog. Dabei handelt es sich um eine Art von Produktskizze, die eine umfassende Liste der notwendigen Eigenschaften und Funktionen enthält, mit denen das Produkt ausgestattet werden soll.

Auch das Product Backlog ist im ständigen Wandel: Zu Beginn eines Sprints muss es nicht vollständig definiert sein, sondern nur so viele Punkte umfassen, dass die Entwickler mit der Arbeit am Projekt beginnen kann. Ergeben sich im Verlauf des Sprints Änderungen, können diese jederzeit ins Product Backlog aufgenommen werden.

Ist das Ziel klar konturiert, kann die eigentliche Projektarbeit beginnen. Diese gliedert sich bei Scrum in sogenannte Sprints. Ein Sprint dauert typischerweise 1-4 Wochen und ist auf ein Etappenziel in der Produktentwicklung ausgerichtet. Jeder dieser Sprints wird mit dem ganzen Team zusammen geplant. Dabei wird das Sprint-Ziel bestimmt, der Aufwand abgeschätzt und geprüft, ob sich in diesem Sprint vielleicht noch weitere Etappenziele aus dem Product Backlog umsetzen lassen. Am Ende eines Sprints steht stets ein sogenanntes Increment, ein Teilergebnis, das für sich genommen bereits funktional wäre.

Den Rahmen für die Arbeit im Sprint bildet dabei das sogenannte Sprint Backlog. Darin enthalten sind alle Funktionen, die im Verlauf des jeweiligen Sprints umgesetzt werden sollen. Sie wandern also aus dem Product Backlog in das von den Entwicklern selbst verwaltete Sprint Backlog. Diese Trennung stellt sicher, dass das Team selbstbestimmt arbeiten kann – denn das Sprint Backlog kann der Project Owner nicht verändern oder ergänzen, ohne die Zustimmung der Entwickler einzuholen.

Hat ein Sprint erst einmal begonnen, wird außerdem das Daily Scrum zum festen Bestandteil des Arbeitstages. Diese kurze Teambesprechung von 10-15 Minuten dient dazu, allen einen Überblick über den Status Quo zu verschaffen. Jedes Teammitglied berichtet hier kurz, was es seit dem letzten Daily Scrum geschafft hat, was es bis zur nächsten Besprechung schaffen will, und ob es Hindernisse gibt, die behoben werden sollten. Indem es die offene Kommunikation im Team fördert, trägt das Daily Scrum dazu bei, eventuelle Hindernisse auf dem Weg zum Sprint-Ziel frühzeitig zu erkennen – und zu beheben.

Ist ein Sprint abgeschlossen, folgt direkt die sogenannte Sprint-Review. Sie dient dazu, das Increment – also das Teilprodukt, das im Sprint erarbeitet wurde – den Stakeholdern vorzustellen und zu prüfen, ob diese Teillieferung des Produkts den an sie gestellten Anforderungen von Seiten der Kunden entspricht.

Zumeist übernimmt der Product Owner stellvertretend für den eigentlichen Kunden die Rolle des Stakeholders. Je nachdem, wie intensiv und breit gefächert das Feedback ausfallen soll, können allerdings auch weitere Stakeholder in die Sprint Review einbezogen werden. Diese Rolle können sowohl Auftraggeber als auch Führungskräfte aus dem eigenen Unternehmen und auch User übernehmen, da sie alle Ansprüche an das Produkt des Scrum-Projekts stellen.

Die Ergebnisse der Sprint Review gehen wiederum in den Prozess des Product Backlog Refinements ein. Diese kontinuierliche Pflege und Verfeinerung des Project Backlogs ist Aufgabe des Product Owners und ermöglicht es, anhand der Ergebnisse des jeweils vorhergehenden Sprints Planung und Durchführung des nächsten zu streamlinen.

Ergänzend zur Sprint Review führt das Scrum Team zudem eine Sprint-Retrospektive durch. Sie dient dazu, den Verlauf des Sprints Revue passieren zu lassen und Prozessoptimierung an der eigenen Arbeitsweise zu betreiben. Daher kommen in der Retrospektive vor allem Kommunikation und Zusammenarbeit im Scrum Team zur Sprache.

Was Scrum als Methode auszeichnet und auch von anderen Methoden des Projektmanagements unterscheidet, ist die Organisation innerhalb des Teams. Im Scrum gibt es drei aktive Rollen: Den Product Owner, den Scrum Master und die Entwickler. Der Product Owner und der Scrum Master schaffen dabei die richtigen Rahmenbedingungen dafür, dass sich das Entwicklungsteam voll und ganz darauf konzentrieren kann, das Projekt voranzutreiben.

Umgangssprachlich wird zumeist zwischen dem Scrum Team und dem Entwicklungsteam unterschieden. Das Scrum Team umfasst dabei Product Owner, Scrum Master und Entwickler, während das Entwicklungsteam nur die Entwickler und den Scrum Master enthält, da sich der Product Owner während der Sprints eher zurückhält und aus einer eher passiven Beobachterrolle heraus das Product Backlog Refinement betreibt.

Sprint abgeschlossen, Backlog aktualisiert – und dann? Ganz einfach: Dann beginnt alles von vorn, denn Scrum verläuft in Zyklen. Die Abfolge der einzelnen Arbeitsschritte ist dabei immer gleich Vorbereitung, Sprint, Review und Retrospektive. Sobald ein Sprint ausgewertet ist, können auch schon die Vorbereitungen für den nächsten beginnen.

Erst dadurch, dass die Ergebnisse eines Sprints immer in die Gestaltung des nachfolgenden einfließen, kommt der agile Charakter der Methode vollständig zum Tragen: Anstatt den kompletten Projektverlauf bis ins Detail zu planen, arbeitet ein Scrum Team in Etappen, die aufeinander aufbauen und es durch ständige Selbstreflexion ermöglichen, jeden Schritt ein wenig präziser durchzuführen als den zuvor. So entsteht in jedem Sprint mit dem Increment ein Teilergebnis, das im Grunde sogar schon einsatzfähig ist – wenn auch in eingeschränktem Lieferumfang – und das mit jeder Wiederholung des Kreislaufs aus Vorbereitung, Sprint und Reflexion weiter ausgebaut und präziser auf die Bedürfnisse des Kunden ausgerichtet wird.

In diesem Punkt unterscheidet sich Scrum wesentlich von klassischen, linear ausgerichteten Methoden des Projektmanegements. Anstatt eines Produkts, das erst nach Abschluss aller Teilprozesse benutzbar ist, erhält der Kunde bereits nach jedem Sprint ein voll funktionsfähiges Increment. Das bedeutet, dass es keine unliebsamen Überraschungen geben kann, weil die Entwicklung im stillen Kämmerlein geschehen ist und der Kunde bis zuletzt nicht sehen konnte, wie das Produkt aussieht und was es kann. Vor allem aber ermöglicht der agile Prozess die flexible Anpassung an veränderte Kundenwünsche oder Bedürfnisse.

Bauen wir nach einer linearen Methode ein Auto, dann fangen wir mit dem Motor an, bauen drumherum eine Karosserie, dazu ein Lenkrad – und wenn wir alles beisammen haben, ist das Projekt abgeschlossen und das Auto fertig. Die große Schwäche dieses Vorgehens? Erklärt der Kunde sich auf halber Strecke durch den Entwicklungsprozess, dass die Zielgruppenanalyse ergeben hat, dass mehr PS sich besser verkaufen, ist es schon zu spät, um den Motor noch zu verändern.

Ein Scrum Team geht hingegen so vor, dass es im ersten Sprint ein Skateboard entwickelt, um etwas auszutesten. Dann entwickelt es das weiter, erst zu einem Roller, dann zu einem Fahrrad, einem Motorrad. Fällt dem Kunden auf, dass er mehr PS braucht, kommen die einfach im nächsten Sprint dazu. Und vielleicht entsteht so Increment für Increment ein Auto. Vielleicht gefällt dem Kunden aber auch schon das Motorrad so gut, dass das Projekt hier abgeschlossen wird. Oder das Scrum Team arbeitet weiter und entwickelt aus dem Skateboard ein Fahrzeug, das es so noch nie gab. Ganz in Anpassung an die Wünsche des Kunden.