Scrum

Methode des agilen Projektmanagements

Scrum, welches zu den bekanntesten agilen Vorgehensweisen im Projektmanagement zählt, wurde von den beiden Softwareentwicklern Ken Schwaber und Jeff Sutherland entwickelt. Diese halten in ihrem Scrum-Guide die wichtigsten Informationen hierzu fest. Sie beschreiben es als ein Rahmenwerk, das den Menschen ermöglicht, mit erhöhter Kreativität komplexe Produkte zu schaffen und diese später mit dem höchstmöglichen Wert auszuliefern. Außerdem wird Scrum von ihnen als leichtgewichtig, einfach zu verstehen, aber schwierig zu meistern beschrieben.

Das Scrum-Rahmenwerk besteht aus einem Scrum-Team, aus Scrum-Ereignissen und den so genannten Artefakten. Die Basis bei dem Arbeiten mit Scrum bildet vor allem die „Empirie“. Dies bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf Grundlage des schon Bekannten getroffen werden, was dem Prinzip „Learning by doing“ ähnelt. Die Empirie wird bei Scrum durch den iterativen und inkrementellen Ansatz erweitert und unterstützt.

Drei Säulen

Die drei Säulen Transparenz, Überprüfung und Anpassung bilden die Basis für diese empirische Prozessteuerung.

• Unter Transparenz versteht man, laut Ken Schwaber und Jeff Sutherland, dass die wichtigen Aspekte des Prozesses für jede Person, die für das Ergebnis verantwortlich ist, sichtbar sein müssen.
• Bei dem Begriff Überprüfung ist das ständige prüfen der Artefakte und des Fortschritts in dem Bezug auf das Sprint-Ziel gemeint. Wenn demnach die Überprüfung ergibt, dass Aspekte des Prozesses von den akzeptablen Grenzwerten abweichen, muss so schnell wie möglich eine
• Anpassung geschehen. Im Scrum-Rahmenwerk gibt es vier Ereignisse, die bereits oben erwähnten Scrum-Ereignisse: Das Sprint Planning, das Daily Scrum, das Sprint Review und die Sprint Retrospektive. Diese sollen für Überprüfung und Anpassung sorgen.

Scrum-Team

Ein Scrum-Team besteht aus den Rollen Product Owner, dem Scrum Master und dem Entwicklungsteam.

• Der Product Owner, welcher als eine einzige Person der Produktverantwortliche ist, hat die Aufgabe alle fachlichen Entscheidungen bezüglich des Produktes zu treffen. Er darf kein Entwickler sein, geschweige denn darf er andere Aufgaben, außer die des Product Owners, übernehmen. Er ist dafür verantwortlich die Produktvision dem Rest des Teams deutlich zu machen, da diese die Grundlage für die Motivation des Teams, das Ziel zu erreichen, ist. Außerdem sorgt die Produktvision dafür, dass das Team immer das eigentliche Ziel im Auge behält und verhindert die Frage innerhalb des Teams, ob sie noch in die richtige Richtung arbeiten. Der Product Owner ist ebenfalls für die Verwaltung des Product Backlogs zuständig und entscheidet bei dem Sprint Review Meeting, ob die entwickelten Funktionalitäten den Akzeptanzkriterien entsprechen und somit wie vereinbart umgesetzt wurden. Es darf kein so genannten „Proxy-Product-Owner“ geben, welcher die tiefere Zusammenarbeit mit dem Entwicklungsteam oder andere Aufgaben, wie das Schreiben der User Stories, übernimmt. Dies würde die Konsequenz haben, dass ein Informationsverlust entsteht und die Transparenz verschlechtert wird, wenn der eigentliche Product Owner nicht die Person ist, welche die Stories verfasst. Zudem müssen alle von dem Product Owner getroffenen Entscheidungen von der gesamten Organisation respektiert werden, um ein erfolgreiches Projekt durchführen zu können.

• Eine weitere Rolle ist die des Scrum Master, welcher mit der des herkömmlichen klassischen Teamleiter verglichen werden kann, jedoch ist er mehr ein Servant Leader, d.h. wie ein Gastgeber, der sich um seine Gäste sorgt und sich ihnen freiwillig unterordnet, gleichzeitig bestimmt er aber auch die Regeln und den Rahmen. Er fördert dabei das Scrum anhand des Scrum Guides: Der Scrum Master hilft allen Projektbeteiligten die Scrum Theorie, die Praktiken, die Regeln und die Werte bei Scrum zu verstehen. Die Person, welche sich dieser Rolle annimmt, übernimmt keine technischen oder fachlichen Aufgaben, sondern muss eher Soft-Skills innerhalb des Projektteams anwenden. Eine Aufgabe des Scrum Masters ist dabei, die Moderation der internen Teambesprechungen. Außerdem ist der Scrum Master dafür verantwortlich, dass „Impediments“ gelöst werden. Zusammengefasst kann die Rolle des Scrum Master so beschrieben werden, dass er für die Zunahme der Produktivität des Scrum Teams verantwortlich ist. Der Scrum Master sollte keine Person sein, welche bisher ein Vorgesetzter des Teams war, da dies ein gutes Vertrauensverhältnis zwischen Scrum Master und Entwicklungsteam verhindert.

• Das interdisziplinäre Entwicklungsteam, in dem alle notwendigen Fähigkeiten vorhanden sind, um ein Ergebnis ohne externe Hilfe zu liefern, hat das Ziel, am Ende des Sprints ein potenziell auslieferbares Produktinkrement gefertigt zu haben. Das Team arbeitet bei diesem Prozess iterativ und inkrementell. Bei dem Festlegen der Teamgröße eines Entwicklungsteams muss beachtet werden, dass das Team so klein ist, damit die Agilität bestehen bleibt, sie jedoch wiederum so hoch ist, damit in der Zeit eines Sprints bedeutende Arbeit erledigt werden kann. Im Konkreten bedeutet dies, dass die Teamgröße nicht unter drei Personen sein sollte, da durch die Reduzierung der Mitglieder eine geringere Produktionssteigerung und ein Mangel an Fähigkeiten entsteht. Bei Teams mit mehr als neun Personen hingegen ist der Aufwand für die Koordination zu hoch und es resultiert in hoher Komplexität. Zudem kann es zu keinem empirischen Prozess kommen.

Scrum-Artefakte

Die so genannten Scrum Artefakte bestehen aus drei Elementen: das Produktinkrement, das Product Backlog und der Sprint Backlog.

• Ein Produktinkrement ist das Ergebnis aus allen fertiggestellten Product-Backlog-Einträgen innerhalb eines Sprints. Es muss sich am Ende eines Sprints in einem einsatzfähigen Zustand befinden, da das Entwicklungsteam ein fertiges Produktinkrement ausliefern muss. Mit dem Begriff „fertig“ meint man damit, dass es ohne weiteren Aufwand, an den Kunden auslieferbar ist.
• Das Product Backlog kann als Liste, die alle Funktionalitäten und Eigenschaften des zu entwickelnden Produktes enthält, die zum aktuellen Zeitpunkt bekannt sind. Diese Funktionalitäten werden durch den Product Owner und dem Entwicklungsteam gemeinsam, auf Basis der Produktvision, erarbeitet. Der Product Owner ist für die Verwaltung dieser Liste zuständig und priorisiert die Einträge. Um für eine gute Beschreibung der Funktionalitäten zu sorgen, verwendet man bei Scrum häufig die so genannten User Stories. Diese werden so kurz wie möglich und in einer vorgegebenen Notation formuliert.

NOTATION: ICH ALS (ROLLE) MÖCHTE (ZIEL) UM (NUTZEN)

BEISPIEL: ICH ALS „BEWERBER“ MÖCHTE MEINE BEWERBUNG IN 90 SEKUNDEN ABGEBEN UM EINEN SCHNELLE RÜCKMELDUNG ZU ERHALTEN

Die User Stories werden zusammen mit Akzeptanzkriterien verfasst, welche angeben, wann die User Story abgeschlossen ist. Sie helfen den Entwicklern beim Verständnis der User Story und dem Product Owner und den Testern bei der Abnahme beziehungsweise bei den Akzeptanztests.

• Das letzte Artefakte, der Sprint Backlog, ist die Menge der Einträge, die für den aktuellen Sprint ausgewählt worden sind und somit die gesamte Arbeit, welche erledigt sein muss, um das Sprint-Ziel zu erreichen. Daher kann der Sprint Backlog auch als Prognose behandelt werden, was im nächsten Produktinkrement enthalten sein wird. Für den Sprint Backlog ist ausschließlich das Entwicklungsteam zuständig und nur die Mitglieder des Teams wählen die Einträge aus dem Product Backlog aus, die im Sprint bearbeitet werden.

Scrum Ereignisse

Um bei Scrum an kritischen Stellen für Transparenz zu sorgen, gibt es die Scrum Ereignisse. Diese haben den Zweck der Überprüfung und Anpassung und sind alle zeitlich begrenzt beziehungsweise haben einen zeitlichen Rahmen, den es einzuhalten gilt. Dieser Zeitrahmen wird von Schwaber und Sutherland als „Time Box“ bezeichnet. Die Entwicklungsphase in der das Team ein Inkrement erstellt wird „Sprint“ genannt. Der Sprint umgibt die restlichen Sprint Ereignisse, bei denen die meisten Meetings sind, als Container.

In der Sprintphase findet das Sprint Planning, das Daily Scrum, die Entwicklungsarbeit, das Sprint Review und die Sprint Retrospektive statt. Nach dem Scrum Guide von Schwaber und Sutherland darf ein Sprint eine maximale Time Box von 30 Kalendertagen haben und der nachfolgende Sprint beginnt direkt nach dem Beenden des aktuellen Sprints.

• Chronologisch beginnt der Sprint mit dem Sprint Planning, welches in zwei Teile aufgeteilt ist.

• 1. In Teil 1 klärt der Product Owner das Entwicklungsteam auf, was er am Ende der Sprintphase haben möchte, beziehungsweise was das Inkrement beinhalten muss. Daraufhin gibt das Entwicklungsteam Rückmeldung und prognostiziert was sie in diesem Sprint denken zu schaffen.
  2. Der zweite Teil dient dem Entwicklungsteam zur Planung, wie sie das zuvor vereinbarte Ziel erreichen wollen. Dabei ist es für den Scrum Master eine wichtige Aufgabe, auf die Teamdynamik zu achten und zum Beispiel sehr dominante Teammitglieder zu zügeln.
• Folgend auf das Sprint Planning beginnt die Entwicklungsphase, in der jeden Tag das Daily Scrum stattfindet. Dieses Meeting hat eine Time Box von 15 Minuten und soll weniger ein Statusmeeting sein, sondern mehr eine Besprechung, welche der Planung dienen soll um gemeinsam abzusprechen, was noch erledigt werden muss. Außerdem hat das Daily Scrum den Effekt der Risikominimierung, da frühzeitig erkannt wird, wenn das Team in eine falsche Richtung läuft.

• Am Sprintende erfolgt das Sprint Review Meeting. Hierbei wird das entstandene Inkrement vom Entwicklungsteam vorgestellt und zusammen mit den Stakeholdern, die nicht zwingend bei dem Sprint Review dabei sein müssen, und dem Product Owner das Ergebnis überprüft und der eventuell vorhandene Änderungsbedarf geklärt. Der Product Owner vergleicht das entwickelte Produktinkrement mit den Akzeptanzkriterien, falls dann keine Abweichungen vorhanden sind, muss er das entwickelte Produktinkrement abnehmen. Dabei spielt es keine Rolle, ob das Ergebnis gegebenenfalls nicht seinen Vorstellungen entspricht. Das Review Meeting soll den Nutzen haben, dass durch die Resonanz aller Beteiligten der Wert des zu entwickelnden Produktes gesteigert und die weitere Entwicklung geplant wird. Daher beschreiben Schwaber und Sutherland das Ergebnis des Reviews, als überarbeitetes Product Backlog.

• Den Abschluss des Sprints bildet das Retrospektive Meeting – Sprint Review -, bei dem das Entwicklungsteam unter Moderation des Scrum Masters den vergangenen Sprint betrachtet und Aktionen zur Verbesserung der Teamarbeit herausarbeitet, die bis zur nächsten Retrospektive durchgeführt werden sollten. Allgemein soll sich das Team offen klarmachen, was im vergangenen Sprint gut und was schlecht gelaufen ist.