Seite I

Inhaltsverzeichnis

1.  Einleitung  1

2.  Grundlagen  1

2.1  Definition von Scrum  1

2.2  Rollen  2

2.2.1  Product Owner  3

2.2.2  Team  4

2.2.3  Scrum Master  4

2.3  Artefakte  4

2.3.1  Product Backlog  5

2.3.2  Sprint Backlog  5

2.3.3  Burndown Chart  5

2.3.4  Impediment Backlog  6

2.4  Meetings  6

2.4.1  Sprint Planning  6

2.4.2  Sprint Review  7

2.4.3  Sprint Retrospective  7

2.4.4  Daily Scrum  8

3.  Grenzen und Hindernisse  9

3.1  Rahmenbedingungen  9

3.2  Scrum Prozesse  10

3.3  Kommunikation  10

3.4  Product Owner  11

3.5  Team  12

3.6  Scrum Master  12

„Scrumbut“   13

3   7

Seite II

4.  Mögliche Lösungsansätze  14

5.  Schlussbetrachtung  15

Abk  ürzungsverzeichnis  

PO  Product Owner  

SM  Scrum Master  

Abbildungsverzeichnis   

Abbildung  1: Die definierten Rollen in Scrum  3

Abbildung  2: Beispiel für ein Sprint Burndown Chart  6

Abbildung  3: Der Scrum-Prozess im Überblick  8

Seite 1

1. Einleitung

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. ¹ 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.

2. Grundlagen

2.1 Definition von Scrum

Scrum ist ein agiles Vorgehensmodell und Framework ² , das vor allem in komplexen Softwareentwicklungsprojekten zum Einsatz kommt. Es basiert auf den Annahmen zur empirischen Prozesssteuerung mit den drei Handlungsfeldern Sichtbarkeit, Inspektion

und Anpassung ³ . 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:

¹ Laut einer aktuellen Projektmanagement-Studie werden agile Projekte (67%) deutlich häufiger

erfolgreich abgeschlossen als klassische (40%), vgl. Vigenschow, Toth, Wittwer (2009), S. 13

² vgl. Wirdemann (2009), S. 27

³ vgl. Schwaber (2007), S. 2 ff.

Seite 2

„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. ⁵ 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“ ⁶ 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.

2.2 Rollen

Scrum kennt lediglich drei Rollen, unter denen alle Verantwortlichkeiten innerhalb des

Projekts eindeutig aufgeteilt werden ⁹ : Den Product Owner (PO), das Team und den Scrum Master (SM).

⁴ Schwaber et. al (2001)

⁵ vgl. Schwaber, Sutherland (2010), S. 10

⁶ Schwaber (2007), S. 6

⁷ vgl. Nerur, Mahapatra, Mangalaraj (2005), S. 77

⁸ vgl. Hammerstein (2009), S. 29

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

2.2.1 Product Owner

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. ¹⁰ Der PO kann eine zertifizierte Ausbildung absolvieren. 11

⁹ vgl. Gloger (2008), S. 124 f.

¹⁰ vgl. Wirdemann (2009), S. 43 f. sowie Schwaber (2007), S. 56

¹¹ vgl. Scrum Alliance (2010a)