1. Einleitung
2. Grundlagen
2.1 Definition von Scrum
2.2 Rollen
2.2.1 Product Owner
2.2.2 Team
2.2.3 Scrum Master
2.3 Artefakte
2.3.1 Product Backlog
2.3.2 Sprint Backlog
2.3.3 Burndown Chart
2.3.4 Impediment Backlog
2.4 Meetings
2.4.1 Sprint Planning
2.4.2 Sprint Review
2.4.3 Sprint Retrospective
2.4.4 Daily Scrum
3. Grenzen und Hindernisse
3.1 Rahmenbedingungen
3.2 Scrum Prozesse
3.3 Kommunikation
3.4 Product Owner
3.5 Team
3.6 Scrum Master
3.7 „Scrumbut“
4. Mögliche Lösungsansätze
5. Schlussbetrachtung
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Die definierten Rollen in Scrum
Abbildung 2: Beispiel für ein Sprint Burndown Chart
Abbildung 3: Der Scrum-Prozess im Überblick
Agile Methoden haben im Projektmanagement in den vergangenen Jahren deutlich an Bedeutung gewonnen. Frameworks wie Scrum oder Kanban finden insbesondere in Softwareentwicklungsprojekten immer häufiger Verwendung. Die enge Zusammenarbeit mit dem Kunden, das eigenverantwortliche Arbeiten des Entwicklungsteams und die schnelle Fertigstellung von Teilprodukten sind dabei gute Argumente für den Einsatz agiler Methoden.1 Doch die Anwendung dieser Methoden garantiert nicht den Erfolg eines Projekts. Im Rahmen dieser Arbeit soll beispielhaft das Scrum-Framework dargestellt werden. Dabei werden zunächst die Grundzüge, Rollen und Artefakte vorgestellt. Nachfolgend sollen mögliche Hindernisse und Grenzen aufgezeigt werden. Welche Projekte eignen sich möglicherweise nicht für Scrum und welche Voraussetzungen müssen die einzelnen Stakeholder mitbringen? Welche Probleme können bei der Einführung der Scrum-Methoden in die vorhandene Organisation auftreten und wie können diese möglicherweise angepasst werden? Motivation für diese Arbeit sind praktische Erfahrungen des Autors in der Projektarbeit mit Scrum. Für häufig auftretende Probleme bietet die aktuelle Fachliteratur bislang nur wenige Lösungsansätze. Hier sollen Möglichkeiten vorgestellt werden, die zur Überwindung der dargestellten Hindernisse führen können.
Scrum ist ein agiles Vorgehensmodell und Framework2, das vor allem in komplexen Softwareentwicklungsprojekten zum Einsatz kommt. Es basiert auf den Annahmen zur empirischen Prozesssteuerung mit den drei Handlungsfeldern Sichtbarkeit, Inspektion und Anpassung3. Entwickelt und etabliert wurde Scrum seit Anfang der 90er-Jahre vor allem durch Ken Schwaber und Jeff Sutherland.
Grundlage für Scrum sind die im „Manifesto for Agile Software Development“ beschriebenen Grundsätze:
„Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan.“4
Zu den Unterzeichnern gehören auch Schwaber und Sutherland.
Scrum ist ein iterativer und inkrementeller Prozess mit festen Timeboxen. Diese Timeboxen werden Sprints genannt und sollten höchstens vier Wochen dauern. Ziel jedes Sprints ist ein Inkrement, welches als potenziell auslieferbar („potentially shippable“) gelten kann.5 Das bedeutet, dass nach jedem Sprint ein bereits lauf- und testfähiges Teilprodukt entstanden sein soll. Gleichzeitig sollen so zeitnahe Anpassungen am Projekt möglich sein und das Entwicklungsteam „gemäß dem Auftreten neuer Komplexitäten, Schwierigkeiten und Überraschungen“6 seinen Lösungsansatz modifizieren können. Da zu Projektbeginn keine vollständige Detailplanung erfolgt und im weiteren Verlauf Anforderungen verändert werden können, sind jedoch auch alle Planungen in einem agilen Projekt zunächst ungenau und beruhen unter Umständen auf Spekulationen.7
Unter den agilen Projektmanagement-Methoden gilt Scrum als die am weitesten verbreitete und wird auch von großen Unternehmen wie Google, Nokia oder Siemens eingesetzt.8
Zum Regelwerk von Scrum gehören wenige fest definierte Rollen, Artefakte und Meetings, die in den folgenden Abschnitten erläutert werden.
Scrum kennt lediglich drei Rollen, unter denen alle Verantwortlichkeiten innerhalb des Projekts eindeutig aufgeteilt werden9: Den Product Owner (PO), das Team und den Scrum Master (SM).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Die definierten Rollen in Scrum
Beziehungen und Verantwortlichkeiten der Rollen innerhalb des Scrum-Teams zu den verschiedenen Gruppen von Stakeholdern während eines Scrum-Projekts
Der PO vertritt die Interessen des Kunden im Scrum-Projekt. Er repräsentiert im weiteren Sinne sämtliche Stakeholder und ist für die Nutzenmaximierung des Projekts verantwortlich. Der PO verwaltet das Product Backlog und ist für dessen Priorisierung verantwortlich. Er wählt zudem die umzusetzenden Items aus dem Product Backlog für den nächsten Sprint aus. Der PO ist somit kein reiner Auftraggeber sondern gestaltet den Entwicklungsprozess aktiv mit.10 Der PO kann eine zertifizierte Ausbildung absolvieren.11
Das Team ist für die Erstellung des Produkts zuständig. Es entwickelt eigenverantwortlich die notwendigen Funktionalitäten, um die jeweiligen Ziele eines Sprints zu erreichen. Es entscheidet dabei eigenständig, wie viele Funktionalitäten in dem Sprint umgesetzt werden, wie diese in konkrete Aufgabenpakete aufzuteilen sind und es verpflichtet sich, diese bis zum Ende des Sprints fertigzustellen. Das Team ist funktionsübergreifend besetzt und besteht idealerweise aus fünf bis neun Personen.12 Welches Teammitglied im Laufe eines Sprints welche Aufgaben übernimmt, entscheidet das Team selbständig ohne jede äußere Einflussnahme, z.B. durch SM, PO oder Linienvorgesetzte.13 Entwickler können seit kurzer Zeit, ebenso wie SM und PO, eine zertifizierte Ausbildung absolvieren.14
Der SM vermittelt PO, Team sowie weiteren Stakeholdern die Werte, Praktiken und Prozesse von Scrum. Er überwacht den Scrum-Prozess und stellt dessen Einhaltung sicher. Hierbei unterstützt er das Team, beseitigt Hindernisse die innerhalb der Entwicklung auftreten, stellt die Zusammenarbeit zwischen PO und Team sicher und steht dem PO unterstützend bei Fragen des Scrum Prozesses zur Seite. Während der Sprints versucht er, das Team von äußeren Einflüssen abzuschirmen. Zudem beruft er die Planning-, Review- und Retrospective-Meetings ein und leitet diese. Anders als der klassische Projektleiter ist er nur für die Einhaltung der Scrum-Prozesse und die Maximierung deren Nutzens verantwortlich, nicht jedoch für den Projekterfolg.15 Er ist somit „eher Moderator und Ermöglicher als weisungsbefugter Aufgabenverteiler“.16 SM können eine zertifizierte Ausbildung absolvieren.17
Die im folgenden beschriebenen Artefakte, sind die Dokumente, die als Grundlage zur Arbeit im Scrum-Projekt dienen. In ihnen wird festgehalten, welche Aufgaben zu erledigen sind, welche Hindernisse ihrer Erledigung entgegenstehen und wie der Fortschritt der Arbeiten ist.
Das Product Backlog enthält sämtliche für das Produkt zu liefernde Funktionalitäten. Es wird vom PO erstellt und verwaltet. Dieser ist auch für die Priorisierung der einzelnen Items des Product Backlogs verantwortlich. Aus dieser Priorisierung ergibt sich die Reihenfolge, in der diese abgearbeitet werden sollen. Die Items werden meist in Form so genannter User Stories formuliert und sind noch nicht sehr detailliert. Das Product Backlog ist niemals vollständig sondern wird im Laufe des Projekts fortgeführt.18
Im Sprint Backlog sind alle Arbeitsaufträge enthalten, die zur Erreichung der Ziele des aktuellen Sprints notwendig sind. Die User Stories aus dem Product Backlog sind hierbei bereits in detaillierte Aufgaben zerlegt und ebenfalls priorisiert. Das Sprint Backlog kann nur vom Team verändert werden. Zudem schätzt das Team zu jedem Item des Sprint Backlogs den jeweiligen Aufwand.19
Das Burndown Chart visualisiert den Fortschritt des aktuellen Sprints und wird täglich aktualisiert. Dabei wird der geschätzte verbleibende Restaufwand für die Erreichung der Sprint-Ziele mit der noch zur Verfügung stehenden Zeit in Korrelation gesetzt. Der Vergleich mit der Trendlinie zeigt, ob die Erreichung der Ziele im laufenden Sprint realistisch ist.20
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Beispiel für ein Sprint Burndown Chart
Es sind nur geringe Abweichungen des tatsächlichen Fortschritts gegenüber der Trendlinie erkennbar, es bleibt jedoch ein Restaufwand am Ende des Sprints übrig.
Das Impediment Backlog enthält die aktuellen Hindernisse, die dem Team bei der Erreichung der Sprint-Ziele im Wege stehen. Für die Beseitigung dieser Hindernisse ist der SM verantwortlich. Das Impediment Backlog wird von ihm täglich aktualisiert und priorisiert.21
Zu jedem Sprint gehören ein Planungs-Meeting und eine Vorstellung der erzielten Ergebnisse. Das Team trifft sich zudem noch zu einer Retrospektive und einer täglichen Statusrunde.
[...]
1 Laut einer aktuellen Projektmanagement-Studie werden agile Projekte (67%) deutlich häufiger erfolgreich abgeschlossen als klassische (40%), vgl. Vigenschow, Toth, Wittwer (2009), S. 13
2 vgl. Wirdemann (2009), S. 27
3 vgl. Schwaber (2007), S. 2 ff.
4 Schwaber et. al (2001)
5 vgl. Schwaber, Sutherland (2010), S. 10
6 Schwaber (2007), S. 6
7 vgl. Nerur, Mahapatra, Mangalaraj (2005), S. 77
8 vgl. Hammerstein (2009), S. 29
9 vgl. Gloger (2008), S. 124 f.
10 vgl. Wirdemann (2009), S. 43 f. sowie Schwaber (2007), S. 56
11 vgl. Scrum Alliance (2010a)
12 Schwaber, Beedle (2001), S. 36
13 vgl. Schwaber (2007), S. 104
14 vgl. Scrum Alliance (2010c)
15 vgl. Wirdemann (2009), S. 39 ff. sowie Schwaber (2007), S. 28
16 Keller (2007)
17 vgl. Scrum Alliance (2010b)
18 vgl. Wirdemann (2009), S. 31 sowie Schwaber (2007), S. 10
19 vgl. Schwaber (2007), S. 13
20 vgl. Abbildung 2: Beispiel für ein Sprint Burndown Chart
21 vgl. Gloger (2008), S. 17 sowie Wirdemann (2009), S. 39
