Der Wesenskern des Vorgehensmodells Scrum

Die Scrum-Entwickler Ken Schwaber und Jeff Sutherland schufen bereits 2001 das «Agile Manifest». In seinen vier Leitsätzen werden die Werte eines leichten Arbeitens wiedergegeben, auf denen ebenso Scrum in seinem Wesenskern basiert (vgl. dazu www.agilemanifesto.org): 

• Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
• Funktionierende Software ist wichtiger als umfassende Dokumentation.
• Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
• Reagieren auf Veränderungen ist wichtiger als das Befolgen eines Plans.

Sowohl das Manifest als auch Scrum finden ihren Ursprung in der Entwicklung von Software. Bei einem Mangel an der Motivation von Mitgliedern eines Teams, greifbaren Resultaten, Ressourcen wie ­Finanzmitteln oder der Klarheit in der ­Gestaltung des Projekts selbst bietet sich ­Scrum als richtungsweisende Alternative für eine aufstrebende Projektverwirklichung an. Verantwortet wird es stets von klei­neren beziehungsweise einzelnen Teams. Eine professionelle Skalierung ermöglichen unter anderen die Frameworks Large Scale Scrum (LeSS) und Nexus. ­Verbindliche Ereignisse, Rollen und Ar­tefakte stellen den eigentlichen Rahmen des Vorgehensmodells Scrum dar. Scrum bildet weder einen gesamten Projektablauf ab noch gibt es konkrete Handlungsanweisungen. Zudem versteht es sich nicht als universeller Lösungsansatz. 

Die Ereignisse

Ereignisse begünstigen das Entstehen einer bindenden Struktur, die der Projektstabilisierung dient. Am Anfang steht dabei die Vision. Sie geht dem wichtigsten Ereignis im Scrum voraus – dem Sprint. Bei diesem handelt es sich um die verbindliche Zeitspanne einer Iteration zur potenziellen Auslie­ferung eines Produkts (Dauer: eine bis vier Arbeitswochen). Als übergeordneter Container, der weitere spezifische Aktivitäten – so besonders die Daily Scrums – umfasst, wird er nicht unterbrochen, läuft also durchgängig ab. Ihm können weitere Sprints vorausgehen beziehungsweise folgen. Scrum lässt sich insoweit als «kontinuierlicher Verbesserungsprozess» (KVP) verstehen.

Das Sprint Planning

Im Vorfeld werden durch das Sprint Planning die erforderlichen Mittel, eine passende Arbeitsumgebung sowie eben der zeitliche Rahmen bestimmt. Die Repräsentanz sämtlicher Verantwortlichkeiten ist das Scrum-Team. Präzision und Konsistenz der von dieser ausgehenden Planung wirken sich entscheidend auf den Erfolg oder Misserfolg eines Projekts aus.  

Die Planungsphasen

Zwei Phasen der Planung werden unterschieden: Im ersten Meeting, dem Planning 1, wird die Substanz der nur aus bis zu zwei Sätzen bestehenden User Stories ermittelt, um daraus Items und Tasks ­abzuleiten. Seine Dauer ist abhängig von derjenigen des Sprints und umfasst eine bis acht Stunden. 

Das zweite Zusammentreffen, das Planning 2, fokussiert ein weiteres Konkretisieren und Detaillieren von Aufgaben. Laut Scrum Guide soll aus ihm «ein deutlich sichtbares Echtzeitbild der Arbeit» hergeleitet werden. Das Mittel dazu sind Scrum Task Boards. Deren Design ist auf die am höchsten gewichteten Stories ausgerichtet.

Der Plan für den Sprint – dieser folgt einem Sprintziel, insoweit also der Frage «Wofür?» – wird durch den Product Backlog abge­bildet. Qualitative Kriterien werden gesondert in der sogenannten «Definition of Done» (DoD), einem Hilfsmittel, hinterlegt. Sie unterliegt einer Absprache des gesamten Scrum-Teams, woraus eine ­Bestärkung sowohl des Zusammenhalts eines Teams als besonders auch dessen ­interner Kommunikation resultiert.

Das Daily Scrum

Das Daily Scrum, ein tägliches Treffen zum Informationsaustausch und zur ­Statusprüfung («Controlling»), umfasst ebenfalls die Arbeit mit Task Boards, die den Ist-Zustand – Probleme, Hindernisse und Erfolge also – visualisieren. Sein Ziel ist es insbesondere, eine Prognose zur ­Bearbeitung der offenen User Stories zu ermöglichen. Ein Daily Scrum sollte als Stand-up-Meeting durchgeführt werden. Auf seiner Grundlage erfolgen eine Justierung von Aufgaben sowie eine wechselseitige Zuschreibung von Verantwortlichkeiten im Team.

Der Scrum Guide weist zum Planning ­folgende, in jedem Fall abzuhandelnde, zielorientierte Themen – mittelbar als Fragen formuliert – auf:

a) Warum ist dieser Sprint wertvoll?
b) Was kann in diesem Sprint ­abgeschlossen werden?
c) Wie wird die ausgewählte Arbeit ­erledigt?

Der Sprint Review

Im Sprint Review werden den Stake­holdern Inkremente (Teilergebnisse bzw. -produkte), die von diesen abzunehmen sind, präsentiert. Diskutiert wird zudem über Organisatorisches und den allgemeinen Stand in der Produktentwicklung. Der Product Owner lädt zu dieser «Zeremonie» ein.

Die Sprint Retrospective

In der Sprint Retrospective wird der letzte Sprint durch das gesamte Projektteam sowie die Stakeholder betrachtet und ausgewertet (Evaluation). Im Idealfall soll sich daraus eine Optimierung ­eines möglicherweise folgenden Sprints ergeben. Auch hier sind sowohl die Stakeholder als auch das Scrum-Team be­teiligt.

Die Rollen

Die Teamzusammensetzung

Ein Scrum-Team zeichnet sich durch fest bestimmte Rollen aus: den Product Owner, den Scrum Master, das Development Team sowie – mittelbar – die Stakeholder. Seine Mitgliederzahl variiert nach dem Scrum Guide, dieser beschreibt seine Grösse wie folgt: «Klein genug, um flink zu bleiben, gross genug, um wichtige Aufgaben in einem Sprint (dem wertschöpfenden Projektprozess also) zu erledigen.» Optimal dürften drei bis neun Teammitglieder sein.

Die Zusammensetzung eines Teams, für die die eigentlichen Projektinitiatoren verantwortlich sind, sollte einen selbst­organisierenden und besonders cross-funktionalen Charakter besitzen. Daraus sollen nicht zuletzt Entscheidungen des gesamten Teams sowie eine durchschlägige Verantwortung sämtlicher Beteiligter resultieren. Individuelle Kompetenzprofile sollen sich nach Möglichkeit ergänzen. Diversität, nicht nur im Sinne einer gewährleisteten Pluridisziplinarität, sondern etwa auch in puncto einer ausgewogenen Geschlechterverteilung sowie Herkunft, ist dabei von zentraler Bedeutung. Dies gilt zudem für die individuellen Denkpräferenzen.

Der Product Owner

Der Product Owner ist der Produkteigner. Es handelt sich um eine Person, nicht um ein Gremium. Er vertritt sämtliche In­teressen der Stakeholder. Dies geschieht durch eine sichtbare und verständliche Kommunikation. Er formuliert auch das sogenannte Produktziel, eine verbind­liche Bestimmung der Eigenschaften des Produkts (neues Konzept im aktuell gültigen Scrum Guide), und ist verantwortlich für die Maximierung dessen Werts. 

Erforderlich ist für seine Rollenausübung, dass nicht nur der Scrum ­Master sowie das Development Team, sondern die gesamte Organisation seine Entscheidungen zu den Produktanfor­derungen respektieren. 

Der Scrum Master

Beim Scrum Master handelt es sich ebenfalls um nur eine Person. Seine Hauptaufgabe als Dienstleister dem Product Owner, dem Development Team, aber auch der gesamten Organisation gegenüber besteht in der korrekten Durchführung des Scrum-Regelwerks in Theorie und Praxis. Es besteht eine obligatorische Erreichbarkeit seiner Person als Garant für das Vermeiden oder das Lösen von Problemen während des gesamten ­Scrum-Prozes­ses. Er agiert nicht etwa konventionell in der Rolle eines Projekt­managers, stellt demnach auch keine ­herkömmliche Auto­rität zur Steuerung des Vorgehens dar. Vielmehr moderiert, vermittelt und unterstützt er. Das Development Team und Stakeholder: Besonders durch besagte Selbstorganisation ist das Development Team gekennzeichnet. Praktisch wirkt sich dies auf die Gewichtung von Aufgaben aus. Orientierungsmarke ist stets das Produktziel – ergo der fest umrissene künftige Zustand des Produkts. Stakeholder, zunächst eher «im Hintergrund» angesiedelt, wirken während des gesamten Scrum-Prozesses auf das Projekt­-team ein. Sie lassen sich konkret als Anspruchsgruppe ausmachen, die – abstrakt – als Anforderungen des Markts zu betrachten ist.

Die Artefakte

Ursprünglich aus der Modellierungssprache für Software sowie anderer Systeme stammend beschreibt der Begriff Artefakt eben einen Modellzustand. Dieser ergibt sich als Ergebnis aus einem Arbeitsprozess. Scrum unterscheidet zwischen drei Artefakten, die alle zur Transparenz des Prozesses beziehungsweise zur Kollaboration der Prozessbeteiligten beitragen:

Product Backlog

Aufführung des Auftragsbestands be­ziehungsweise der im Projekt geltenden Anforderungen und Aufgaben. Gepflegt und weiterentwickelt wird der Product Backlog durch den Product Owner. Für den Projekterfolg stellt sich ein gut organisierter sowie priorisierter Product Backlog als essenziell dar. Die Bedarfe werden nicht in absoluten Personalstunden angegeben, sondern auf der Basis von User Stories ein Estimating zur Vermeidung von Vakua in relativen Storypoints eben geschätzt. Das Ziel dieser Art von Schätzungen ist keine Sicherheit, sondern Klarheit. Grundlage sind insoweit das «Wie» und das «Wie viel».

Planning Poker: Basis ist ein spezielles Kartenset für jedes Mitglied eines Development Teams. Der Product Owner stellt pro Product Backlog Item (PBI) eine Nachfrage zu dessen Aufwand. Die Mitglieder legen daraufhin jeweils die Karten mit ihren individuellen Schätzwerten offen, wobei sich je nach Gruppendynamik und damit der zugrunde liegenden hierarchischen Muster auch ein anonymisiertes Vorgehen anbieten kann. Sich anschliessende Diskussionen über den niedrigsten und den höchsten Wert sowie fortlaufende Wiederholungen für das aktuelle und weitere PBI ­dienen dem Konsens. 

Im Übrigen ergeben sich Entscheidungen des Product Owners aus der Rei­henfolge der entsprechenden Einträge. Diese Pflege und Weiterentwicklung ­des Product Backlog wird als Refinement, ­gelegentlich auch noch als Grooming bezeichnet.

Sprint Backlog

Visualisierung der Fortschritte bzw. Verfeinerung der Anforderungen. Der Sprint Backlog dient der Ausrichtung auf den nächsten Sprint (Iteration) und damit auf das nächste Teilprodukt. Die Ver­antwortung für den Sprint Backlog liegt beim Scrum Team.

Product Increment

Produkt beziehungsweise eben Teilprodukt eines Sprints: Beim Product Increment handelt es sich um das angestrebte, keinesfalls gesicherte (Zwischen-)Ergebnis am Ende von Iterationsschleifen. Jedes Product Backlog findet sich in der Summe bisheriger Arbeiten wieder. Notwendigerweise folgende Sprints verdeutlichen, dass ein «werdendes», in Entstehung befind­liches Produkt zugrunde liegt.