Scrum Ausarbeitung

Seminar Software Engineering,
Agile vs. klassische Methoden der Software-Entwicklung
Scrum
eine agile Methode zur Software Entwicklung
Seminararbeit
Wintersemester 2003/2004
Raffael Schweitzer
s0070710
Institut fr Informatik
der Universitt Zrich
Prof. Dr. Martin Glinz
Betreuer: Christian Seybold
Prsentation am 18. November 2003
Seminar Software Engineering

Agile vs. klassische Methoden der Software-Entwicklung, WS 03/04
Scrum
Dozent: Prof. Dr. Martin Glinz

Betreuender Assistent: Christian Seybold
Inhaltsverzeichnis
1
2
3
4
Einleitung ...................................................................................................................................... 3
Was ist Scrum?............................................................................................................................. 4
Geschichte von Scrum ................................................................................................................ 5
Funktionsweise von Scrum......................................................................................................... 6
4.1
Ablauf..................................................................................................................................... 6
4.2
Elemente................................................................................................................................ 7
4.2.1
4.2.2
4.2.3
4.2.4
4.2.5
4.2.6
4.2.7
Scrum Master .................................................................................................................................. 7

Product Backlog und Product Owner .............................................................................................. 7
Scrum Team.................................................................................................................................... 8
Daily Scrum Meeting ....................................................................................................................... 8
Sprint Planning Meeting, Sprint Goal, Sprint Backlog ..................................................................... 9
Sprint............................................................................................................................................. 10
Sprint Review Meeting .................................................................................................................. 11
Einsatzbereiche fr Scrum ........................................................................................................ 11

5.1
Einsatz in neuem oder bestehenden Projekt....................................................................... 11
5.2
Ein grosses oder mehrere voneinander abhngige Projekte .............................................. 12
5.3
Scrum und XP...................................................................................................................... 12
6
Erfolgsfaktoren ........................................................................................................................... 13
6.1
Die menschliche Komponente ............................................................................................. 13
6.1.1
6.1.2
6.1.3
6.1.4
Scrum Master ................................................................................................................................ 13

Kunde............................................................................................................................................ 14
Scrum Team.................................................................................................................................. 14
Scrum Grundwerte ........................................................................................................................ 14
6.2
Grenzen von Scrum............................................................................................................. 14
7
Zusammenfassung und Ausblick ............................................................................................. 15
Abbildungsverzeichnis....................................................................................................................... 16
Quellenverzeichnis ............................................................................................................................. 16
Seite 2 von 16

Scrum

Einleitung
In todays fast-paced, fiercely competitive world of commercial new product
development, speed and flexibility are essential. Companies are increasingly realizing
that the old, sequential approach to developing new products simply wont get the job
done. Instead, companies in Japan and the United States are using a holistic method;
as in rugby, the ball gets passed within the team as it moves as a unit up the field.
H.Takeuchi, I.Nonaka [TAKEUCHI86]
In letzter Zeit machen verschiedene neue Methoden zur Software Entwicklung von sich reden, welche
unter dem Begriff agile Software Entwicklungsmethoden zusammengefasst werden knnen.
Klassische Methoden zur Software Entwicklung gehen meist von einem Ansatz aus, der dem
Vorgehen eines Ingenieurs entspricht. Dabei haben sich im Einsatz verschiedene Nachteile
herauskristallisiert. Dies sind unter anderem:
Grosser Aufwand in der Planungsphase ntig
Anpassungen whrend der Realisierung sind nur mit grossem Aufwand mglich, dadurch
schlechte Umsetzung der Anforderungen bei sich schnell nderndem Umfeld
Oftmals Behandlung der Mitarbeiter als Produktionsfaktor
Die agilen Methoden auf der anderen Seite versuchen genau diesen Problemen entgegenzuwirken.
Ihre grundlegenden Eigenschaften sind dabei meist die folgenden:
Inkrementelles Arbeiten in sehr kurzen Zyklen
Stndige Anpassung an neue Anforderungen
Besondere Bercksichtigung der menschlichen Komponente
Im Folgenden wird nun Scrum, eine dieser neuen agilen Methoden, vorgestellt und Vor- und Nachteile
diskutiert.
Es ist darauf hinzuweisen, dass eine Vielzahl von weiteren neuen Methoden vorhanden ist, welche
ebenfalls als agil zu bezeichnen sind. Wichtige Beispiele sind Extreme Programming (XP)1 und
Dynamic System Development Method (DSDM)2.
1
2
http://www.extremeprogramming.org
http://www.dsdm.org
Seite 3 von 16

Scrum

Was ist Scrum?
Scrum ist ein iterativer Prozess zur Entwicklung von Software in einem chaotischen, sich schnell
ndernden Umfeld. Dabei besteht Scrum aus einer Serie von 30 Tage dauernden Iterationen, den
sogenannten Sprints. Nach jedem Sprint liegt das Produkt in einer neuen, lauffhigen Version vor,
welche dem Kunden ausgeliefert werden knnte.
Zwischen zwei Sprints werden die Fortschritte, welche im letzten Sprint gemacht wurden, durch
Management und Kunden berprft und daraufhin bei Bedarf die Anforderungen an das Produkt neu
gesetzt. Daraufhin kann der nchste Sprint gestartet werden.
Es handelt sich dabei um ein empirisches Prozessmodell, bei
scrum or scrummage:
welchem der Prozess aufgrund von verschiedenen Kontrollen
gesteuert wird.
a rugby play in which the forwards of
Whrend den Kontrollphasen zwischen den Sprints berprft
each side come together in a tight
formation and struggle to gain
das Management und der Kunde die Ergebnisse und fhrt
possession of the ball when it is
gegebenenfalls Korrekturen durch. Dann berlsst es die
3
tossed in among them
Verantwortung fr eine weitere Sprint Phase dem Scrum
Team, welches versucht, die Anforderungen mglichst gut
umzusetzen. Das whrend dem Sprint vom Team Erreichte wird dann wieder vom Management
berprft, worauf der Zyklus von neuem beginnt.
Whrend den Sprints werden Statusdokumente erstellt und regelmssige Treffen abgehalten, welche
ber den Stand der Arbeiten Aufschluss geben.
Im Gegensatz zu klassischen Entwicklungsmethoden legt Scrum den Fokus stark auf die einzelnen
Personen und das Team. Diese tragen sehr viel Verantwortung, welche ihnen vom Management
delegiert wird. Durch diese Betonung der menschlichen Komponente der Software Entwicklung
werden grosse Produktivittssteigerungen erreicht.
Durch die Vorgehensweise von Scrum wird ausserdem Kommunikation und Kooperation zwischen
den Entwicklern untereinander und auch dem Management oder dem Kunden verbessert und
versucht, die gegenstzlichen Interessen der verschiedenen Gruppen unter einen Hut zu bringen.
Einer der Grundstze von Scrum ist dabei, dass der Entwicklungsprozess von smtlichen Strungen
und Hindernissen von aussen abgeschirmt werden muss, um eine mglichst grosse Produktivitt zu
erreichen.
Scrum ist also eigentlich kein Software Entwicklungsprozess, sondern ein sogenannt leichter
Management Prozess, da es keine Praktiken zur Software Entwicklung enthlt. Vielmehr umschliesst
es die bestehenden Praktiken auf der Management Ebene. Aus diesem Grund ist es auch mglich,
eigentliche agile Software Entwicklungsmethoden, wie zum Beispiel Extreme Programming, mit
Scrum zu kombinieren. 3
Merriam Webster Dictionary, http://www.webster.com

Seite 4 von 16

Scrum

Geschichte von Scrum
Scrum entstand durch vereinte Bemhungen von Advanced Development Methods [ADM] und
VMARK Software (VMARK). Beide Firmen entwickeln objektorientierte Software.
Sowohl ADM als auch VMARK machten die Erfahrung, dass objektorientierte und
komponentenbasierte Entwicklung durch den definierten Ansatz der klassischen
Entwicklungsprozesse vielfach eher behindert als gefrdert werden.
1995 wollte nun ADM die internen Entwicklungsprozesse optimieren. Dazu wurden Wissenschaftler
der DuPont Experimental Station, welche Forschung im Bereich der Prozessautomation fr
biochemische Prozesse betreiben, mit der Analyse einiger der verbreiteten Software
Entwicklungsmethoden beauftragt.
Die Wissenschaftler kamen zum Schluss, dass die meisten der Entwicklungsmethoden davon
ausgehen, dass Software in wiederholbaren, klar definierten und vorhersagbaren Prozessen entsteht.
Software Entwicklungsprozesse sind jedoch meist nicht vorhersagbar und nicht wiederholbar. Es
handelt sich um empirische Prozesse. Sie waren hchst erstaunt darber, dass die meisten
Methoden einen definierten Ansatz whlen, obwohl dieser unter diesen Umstnden nicht sehr
erfolgreich sein kann.
Diese Erkenntnis fhrte dazu, dass ADM und VMARK begannen, eine eigene Methode zu entwickeln,
welche auf dem empirischen Ansatz beruhte. Hauptschlich handelte es sich dabei um Jeff
Sutherland (VMARK) und Ken Schwaber (ADM), welche gemeinschaftlich Scrum entwickelten.
Ausserdem wurden wiederum die Wissenschaftler der DuPont Experimental Station einbezogen.
Sutherland und Schwaber benutzten hauptschlich Ideen von Ikujiro Nonaka und Hirotaka Takeuchi,
welche diese erstmals 1986 in einem Artikel ausformuliert und in ihrem 1995 erschienenen Buch
The Knowledge Creating Company verfeinert hatten. [TAKEUCHI86] und [TAKEUCHI95]
Takeuchi und Nonaka waren auch die ersten, welche den Begriff Scrum benutzten.
Eine weitere Person, welche an der Entwicklung von Scrum stark beteiligt war, ist Mike Beedle. Er
war einer der ersten, die Scrum einsetzten, und brachte verschiedene Vorschlge in Scrum ein.
Ausserdem zeichnet er fr die Kombination von Scrum mit Extreme Programming verantwortlich
(Siehe Kapitel 5.2).
1996 wurde Scrum erstmals anlsslich der OOPSLA Konferenz4 vorgestellt. Seither ist die Methode
von ber 50 Unternehmen erfolgreich fr die Entwicklung objektorientierter Software eingesetzt
worden.
Mit ihrem Buch zu Scrum haben Ken Schwaber und Mike Beedle nun 2001 eine umfassende
Beschreibung von Scrum geschaffen. [SCRUM01]
Die Begrnder von Scrum engagieren sich ausserdem in der Agile Alliance, welche Vertreter der
verschiedenen agilen Methoden vereint.5
The Eleventh Annual ACM Conference on Object-Oriented Programming Systems, Languages and
Applications, http://www.acm.org/sigplan/oopsla/oopsla96/oopsla96.html, siehe auch [PLOP98]
5
Agile Alliance, http://www.agilealliance.org
Seite 5 von 16

Scrum

Funktionsweise von Scrum
In diesem Abschnitt wird die Funktionsweise von Scrum beschrieben. Dazu wird zuerst der
grundlegende Ablauf eines mit Scrum durchgefhrten Projektes besprochen, um einen berblick ber
die Bestandteile von Scrum zu erhalten. Daraufhin werden die einzelnen Elemente detailliert erklrt.
4.1
Ablauf
Die Aufgaben, welche whrend dem Projekt erledigt werden sollen, sind im Product Backlog
aufgefhrt. Dieser entspricht einer Liste aller geforderten Funktionalitten und nderungen. Ein
Scrum Projekt wird in Iterationszyklen von 30 Tagen aufgeteilt, den sogenannten Sprints. Zu Beginn
jedes Sprints findet das Sprint Planning Meeting statt, in welchem der Product Owner die Elemente
des Product Backlogs priorisiert und das Scrum Team die Aufgaben fr den bevorstehenden Sprint
festlegt. Diese entsprechen dem Sprint Backlog. Whrend dem Sprint trifft sich das Scrum Team
tglich zum Daily Scrum Meeting, welches vom Scrum Master geleitet wird. Am Ende des Sprints
demonstriert das Team die neu geschaffene Funktionalitt im Sprint Review Meeting.
Abbildung 1
Funktionsweise von Scrum
Seite 6 von 16

Scrum
4.2

Elemente
4.2.1
Scrum Master
Der Scrum Master ist die neue Management Rolle, welche mit Scrum eingefhrt wird. Er ist die
wichtigste Person im Scrum Prozess und muss eine herausragende Persnlichkeit sein, da er
permanent die Initiative ergreifen und seine Aufgaben beharrlich verfolgen muss.
Der Scrum Master ist verantwortlich dafr, dass die Grundstze von Scrum im Projekt verwirklicht
werden. Ausserdem ist er die Schnittstelle zwischen Management und dem Scrum Team. Dabei muss
er versuchen, das Team whrend eines Sprints mglichst von allen Einflssen von aussen
abzuschirmen.
Bei Beginn eines Projektes untersttzt er das Management und den Kunden bei der Bestimmung
eines geeigneten Product Owners. Zusammen mit diesem und dem Scrum Team legt der Scrum
Master dann jeweils den Backlog fr den nchsten Sprint fest und plant daraufhin mit dem Team den
Ablauf des Sprints.
Der Scrum Master leitet die tglichen Scrum Meetings und fungiert als Coach fr das Scrum Team.
Dabei vergleicht er fortwhrend die gemachten Fortschritte mit den Erwartungen und greift allenfalls
bei Problemen ein. Zustzlich ist er whrend des Sprints verantwortlich fr die mglichst vollstndige
Beseitigung aller Hindernisse, von welchen ihm die Teammitglieder berichten.
Der Scrum Master trifft die Entscheidungen, welche das Team nicht selbst treffen will, sofort an den
Meetings. Dies ist wichtig, da so das Team in der Lage ist, weiterzuarbeiten. Falsche Entscheidungen
knnten spter immer noch revidiert werden.
Die Ausbildung zum Scrum Master ist zertifiziert. Die zertifizierten Scrum Master sind dabei in einer
Web Community zusammengeschlossen. [ALLIANCE]
4.2.2
Product Backlog und Product Owner
Beim Product Backlog handelt es sich um eine der Dringlichkeit nach geordnete Liste aller Features,
Funktionalitten, Technologien, Erweiterungen und Fehlerkorrekturen, welche ins Produkt eingebaut
werden sollen. Die Product Backlog Liste kann von jedem, der am Projekt beteiligt ist, eingesehen
werden. Ausserdem kann jeder die Aufnahme einer neuen Anforderung in die Liste anregen. Dies
knnte zum Beispiel durch das Marketing, die Verkaufsabteilung, die Entwicklungsabteilung oder den
Support geschehen.
W ichtigke it Nr. Be schre ibung
Aufw . Von
Solche Anforderungswnsche
knnen auch sehr vage sein. Je Se hr Hoch
1 Da te nba nk Ve rsionie rung be e nde n
16
KH
strker ein Element in der
Lize nzie rung hinzufge n
Product Backlog Liste priorisiert
2
User Lizenzierung
16
TG
wird, desto detaillierter sollte es
3
Demo / Evaluation Lizenzierung
12
TG
ausformuliert sein.
4 Unte rsttzte Da te iform a te e rw e ite rn
160
TG
Die Liste ist usserst
.. ..
..
..
dynamisch, da sich die
Hoch
Anforderungen an das Produkt
Na m e nsge bung UI ve re inhe itliche n
7
Im Hauptprogramm
24
KH
whrend seiner Entwicklung
8
Im
Import
Modul
24
AM
meist verndern. Zu Beginn des
9 Abfra ge Tool
260
T&M
Projekts muss sie nicht
.. ..
..
..
vollstndig sein, sollte jedoch
Mitte l
bereits gengend Elemente fr
.. ..
..
..
einen ersten Sprint enthalten.
Abbildung 2
Beispiel Product Backlog
Seite 7 von 16

Scrum

Der Product Backlog enthlt ausserdem auch Probleme, welche vor der Erledigung bestimmter
Elemente gelst werden mssen. Whrend das Projekt fortschreitet, werden diese Probleme
sukzessive in normale Elemente, also regulre Anforderungen an das Produkt oder einzusetzende
Technologien, umgewandelt.
Fr ein Scrum Projekt wird ausserdem ein Product Owner bestimmt. Diese Person verwaltet die
Product Backlog Liste. Jeder, der dem Produkt eine neue Anforderung hinzufgen will, muss sich an
den Product Owner wenden, welcher ber die Aufnahme entscheidet und dann die Priorisierung
innerhalb der Liste vornimmt.
Der Product Owner ist insofern wichtig, damit das Scrum Team nicht von allen Seiten mit Wnschen
bedrngt wird und die Ziele fr das Produkt nur an einer zentralen Stelle verwaltet werden, so dass
nur ein einziger, immer aktueller Product Backlog fr das Projekt vorhanden ist.
Der Product Owner fhrt in Zusammenarbeit mit dem Team fr jedes Element der Liste eine grobe
Aufwandschtzung durch. Aufgrund dieser Schtzungen kann das Team dann bestimmen, welche
Elemente es im nchsten Sprint erledigen wird.
4.2.3
Scrum Team
Ein Scrum Team umfasst mindestens fnf und allerhchstens acht Personen. Dies ist wichtig, um
eine mglichst grosse Produktivitt zu gewhrleisten. Werden weniger Personen eingesetzt, so findet
zu wenig Informationsaustausch statt. Bei mehr als acht Team Mitgliedern besteht hingegen grosse
Wahrscheinlichkeit, dass die Kontrollmechanismen von Scrum, wie das tgliche Scrum Meeting,
versagen und zudem zuviel Komplexitt entsteht.
Whrend dem Sprint Planning Meeting erklrt sich das Scrum Team bereit, im nchsten Sprint eine
bestimmte Menge von Elementen des Product Backlogs zu erledigen. Wie das Team dieses Ziel
erreicht, ist ihm selbst berlassen. Es soll sich dafr selbst organisieren. Whrend des Sprints kann
es im Rahmen der durch das Unternehmen vorgegebenen Richtlinien alle Entscheidungen selbst
fllen und erwarten, dass auftretende externe Hindernisse durch den Scrum Master beseitigt werden.
Ein Scrum Team sollte so zusammengesetzt sein, dass seine Mitglieder in ihrer Summe alle
Fhigkeiten mitbringen, welche zur Erreichung der fr diesen Sprint gesetzten Ziele notwendig sind.
So knnen die Mitglieder zum Beispiel Analysten, Designer, Programmierer oder auch
Qualittsingenieure sein. Sinnvoll ist aber, dass mindestens ein erfahrener Ingenieur Mitglied des
Teams ist. Wie das Team die Aufgaben im Einzelnen aufteilt, ist ihm selbst berlassen.
An einem Projekt knnen auch mehrere Scrum Teams beteiligt sein. Dies wird in Abschnitt 5.2
eingehend erlutert.
4.2.4
Daily Scrum Meeting
Das tgliche Scrum Meeting ist das Herzstck von Scrum. Alle Mitglieder des Scrum Teams treffen
sich dazu einmal tglich fr 15 Minuten jeweils zur selben Zeit und am selben Ort. Das Scrum
Meeting wird vom Scrum Master geleitet, der dafr sorgt, dass die Regeln eingehalten werden und
dass das Treffen nicht zu lange dauert.
Whrend des Treffens stellt der Scrum Master jedem Teammitglied die folgenden drei Fragen:
Was hast du seit dem letzten Treffen erledigt?
Was wirst du von jetzt bis zum nchsten Treffen erledigen?
Was hat dich bei deiner Arbeit behindert?
Seite 8 von 16

Scrum

Durch die Beantwortung dieser Fragen werden verschiedene Ziele erreicht:

Einerseits wird die Kommunikation unter den Teammitgliedern und das Wissen des Einzelnen ber
das Gesamtprojekt stark verbessert, da jeder weiss, was der andere tut. Andererseits werden
Probleme und Hindernisse aufgezeigt, welche das Projekt verlangsamen. Das Treffen hilft ausserdem
bei der schnellen Entscheidungsfindung. Die Teilnehmer des Treffens berichten dabei den Status
ihrer Arbeit primr nicht dem Scrum Master oder einem Vorgesetzten, sondern den anderen
Teammitgliedern
Von den Teilnehmenden gemeldete Hindernisse werden durch den Scrum Master nach Mglichkeit
beseitigt. Sei dies persnlich oder durch Delegation an eine zustndige Stelle. Haben Teammitglieder
weitere Ideen, wie die Produktivitt verbessert werden knnte, oder werden sie zum Beispiel vom
Management mit anderen Aufgaben belastet, so bringen sie dies ebenfalls als Hindernisse in ihrer
Arbeit vor.
Ein Scrum Meeting ist keine Diskussionsrunde. Es werden whrend dem Treffen keine Probleme
gelst oder Designfragen besprochen. Bestehen ber das Treffen hinausgehende Probleme,
Unklarheiten oder zu errternde Designfragen, so wird whrend dem Scrum Meeting ein Treffen
vereinbart, um die entsprechenden Fragen zu besprechen.
Die tglichen Scrum Meetings sind ausserdem eine
Chickens and pigs
effektive Methode, um immer darber informiert zu sein,
A chicken and a pig are together when the
wo das Team momentan steht und ob es erfolgreich ist.
chicken says, Lets start a restaurant! The
Auch Personen, welche nicht zum Team gehren,
pig thinks it over and says, What would we
call this restaurant? The chicken says,
knnen an Scrum Meetings teilnehmen, um sich zu
Ham n Eggs!
informieren. Dabei mssen sie sich aber an bestimmte
The pig says, No, thanks. Id be committed,
Regeln halten. Ken Schwaber stellt in seinem Buch dazu
but youd only be involved!
die Chickens and Pigs Regel auf, welche auf dem
nebenstehenden Witz basiert. [SCRUM01]
Die Teammitglieder entsprechen dabei den Schweinen und die brigen Teilnehmer des Meetings sind
Hhner. Die Hhner mssen sich am Rand, rund um den Kreis der Scrum Teammitglieder aufhalten
und drfen nur zuhren, aber nicht sprechen.
4.2.5
Sprint Planning Meeting, Sprint Goal, Sprint Backlog
Das Sprint Planning Meeting besteht eigentlich aus zwei Teilen. Als erstes findet das Treffen des
Scrum Teams mit Scrum Master und Product Owner sowie interessierten Kundenvertretern statt.
Whrend dieses Treffens erlutert der Product Owner dem Team die am hchsten priorisierten
Elemente des Product Backlog, so dass sich das Team darber klar werden kann, welche Elemente
es im nchsten Sprint erledigen kann. Der Product Owner bestimmt nun mit dem Team das Sprint
Goal, ein Ziel, welches definiert, was im Sprint erreicht werden soll. Gegen dieses Ziel wird am Ende
des Sprints im Sprint Review Meeting geprft, ob der Sprint erfolgreich war.
Im zweiten Teil des Treffens legt nun das Team mit Untersttzung des Product Owners fest, welche
Elemente des Product Backlogs im Sprint erledigt werden sollen. Die Elemente werden dann in
einzelne Aufgaben von 4 bis 16 Stunden Dauer aufgeteilt. Diese Aufgaben entsprechen detaillierten
Teilstcken zur Umwandlung des Product Backlogs zu Software.
Die Summe dieser Aufgaben entspricht dem Sprint Backlog, der whrend dem Sprint abzuarbeiten
ist. Der Sprint Backlog wird dabei laufend angepasst, wenn zum Beispiel Aufwandschtzungen
korrigiert, neue Aufgaben entdeckt oder Aufgaben gestrichen werden.
Wie der Product Backlog, ist auch der Sprint Backlog ffentlich und kann von Aussenstehenden als
Statusinformation eingesehen werden.
Seite 9 von 16

Scrum
4.2.6
Sprint
Whrend dem Sprint versucht das Scrum Team, das gesetzte Sprint Goal zu erreichen. Auf welche
Art und Weise es dies tut, ist grsstenteils ihm selbst berlassen. Es passt sich dabei den
Umstnden, der eingesetzten Technologie und den organisatorischen Rahmenbedingungen an.
Ein Sprint dauert in der Regel 30 Tage. Einzige vorgeschriebene Fixpunkte dabei sind das tgliche
Scrum Meeting und der Sprint Backlog, der immer auf dem aktuellen Stand gehalten werden muss.
Am Ende des Sprints muss zudem eine neue Produktversion vorliegen, welche die whrend des
Sprints geschaffene Funktionalitt beinhaltet. Sinnvoll ist dabei auch, jeden Tag eine lauffhige
Version des Produkts, einen Daily Build, zu erstellen und mit diesem Regressionstests durchzufhren.
Whrend des Sprints gibt das Management die Zgel vollstndig aus der Hand und berlsst das
Team seiner eigenen Verantwortung. Das Risiko hlt sich dabei in Grenzen, da ein Sprint auf 30 Tage
limitiert ist. Gesetzt den Fall, dass das Team whrend eines Sprints tatschlich kein ntzliches
Ergebnis produziert, so ist doch festzuhalten, dass es in dieser Zeit mit grosser Wahrscheinlichkeit
viele wichtige Erfahrungen gesammelt hat, welche fr die weitere Entwicklung von Nutzen sind.
Dokumentationen erstellt das Team nur, falls diese whrend des Sprints hilfreich sind.
Benutzerdokumentationen fr den Kunden sind in jedem Fall zu erstellen.
Niemand kann von aussen Ziel und Umfang des Sprints verndern oder dem Team Vorgehensweisen
vorschreiben, whrend der Sprint im Gange ist. Von den vier Projektvariablen sind Zeit, Kosten und
Qualitt whrend eines Sprints fixiert. Nur der Umfang kann verndert werden, wobei jedoch das
Sprint Goal unangetastet bleiben muss.
So kann der Fall eintreten, dass sich das Team bei der Zuweisung von Elementen aus dem Product
Backlog whrend des Sprint Planning Meetings grob verschtzt hat. Dann ist es sinnvoll, dass das
Scrum Team mit dem Product Owner ber eine Erweiterung beziehungsweise Verringerung der fr
den Sprint geplanten Aufgaben verhandelt. Dabei sollte das Sprint Goal, wie bereits erwhnt, nicht
verndert werden. Am Ende des Sprints kann das Management dann am Sprint Review Meeting
entsprechend der weniger beziehungsweise zustzlich produzierten Funktionalitt dem Product
Backlog Elemente hinzufgen oder berflssige entfernen.
Das Scrum Team hat ausserdem jederzeit die Mglichkeit, einen Sprint abzubrechen. Dies kann zum
Beispiel sinnvoll sein, wenn das Sprint Goal obsolet wird oder zu viele Hindernisse auftauchen,
welche das Erreichen des Sprint Goals in jedem Fall verunmglichen. Dann muss ein neues Sprint
Planning Meeting angesetzt werden, um ein neues Sprint Goal festzulegen.
Der Abbruch eines Sprints ist jedoch sehr selten, da einerseits ein Sprint nur 30 Tage dauert, also
eine berschaubare Zeitspanne umfasst, andererseits die Hemmschwelle fr einen Abbruch meist
hoch ist.
900
800
762
Verbleibende Arbeit (h)
752
700
664
619
600
500
400
304
300
264
200
180
104
100
20
29
31
27
25
23
21
19
17
15
13
11
Abbildung 3
Bei diesem Sprint wurden dem Sprint
Backlog zu viele Elemente zugewiesen.
Deshalb ist mit dem Product Owner
entschieden worden, den Umfang der
Aufgaben zu verringern.
Das fhrte zum starken Abfall der
verbleibenden Arbeitsstunden zwischen
dem 13. und dem 15. Tag.
Nach der Reduktion der Aufgaben
verlief der Sprint ohne grosse Probleme
und wurde erfolgreich abgeschlossen.
Zeit
Abbildung 3
Beispiel fr den Verlauf eines Sprints

Seite 10 von 16

Scrum
4.2.7

Sprint Review Meeting
Mit dem Sprint Review Meeting wird am Ende des Sprints die neu erstellte Produktversion dem
Management, den Kunden, den Usern und dem Product Owner vorgestellt. Das Treffen wird vom
Scrum Master geleitet und das Produkt wird durch das Team prsentiert. Dabei wird versucht,
mglichst alle Aspekte der neuen Produktversion aufzuzeigen, wie neue Funktionalitt, Architektur
oder Design. Ausserdem wird ber den Verlauf des Sprints berichtet.
Die Resultate des Sprints werden so dem im Sprint Planning Meeting beschlossenen Sprint Goal und
dem fr den Sprint zugewiesenen Product Backlog gegenbergestellt. Aufgrund dieser
Standortbestimmung knnen nun die Zuhrer ber das weitere Vorgehen bezglich des Projekts
entscheiden. Dies wird vielfach zur nderung von Elementen des Product Backlogs fhren.
Das Sprint Review Meeting ist sehr informell gehalten. Es soll sich primr um eine Arbeitssitzung
handeln, bei dem Fragen gestellt, Beobachtungen weitergegeben oder Vorschlge gemacht werden
knnen.
Anschliessend an das Sprint Review Meeting und die Korrektur der Anforderungen an das Produkt
kann ein neuer Sprint mit einem Sprint Planning Meeting initiiert werden. Ist der Kunde jedoch mit
dem entstandenen Produkt zufrieden oder ist die zur Verfgung stehende Zeit oder die bewilligten
Sachmittel aufgebraucht, kann die Entwicklung an dieser Stelle auch beendet werden.
5
5.1
Einsatzbereiche fr Scrum
Einsatz in neuem oder bestehenden Projekt
Scrum eignet sich sowohl fr den Einsatz bei neuen Projekten als auch zum Retten von
festgefahrenen Projekten, welche mit herkmmlichen, klassischen Methoden begonnen wurden.
Wird ein Projekt von Anfang an mit Scrum durchgefhrt, so muss zuerst ein gengend grosser
Product Backlog vorhanden sein. Ausserdem sollte ein System Framework fr die Entwicklung des
Systems in der gewhlten Technologie erstellt werden. In einem ersten Sprint wird dann die
Entwicklungsumgebung fr das Projekt aufgesetzt sowie eine erste Schlsselfunktionalitt des
Produkts implementiert. Diese erste erstellte Funktionalitt ist wichtig, damit der Kunde merkt, dass es
nun ernst gilt, und er sich im Projekt engagieren muss, damit seine Anforderungen an das Produkt
umgesetzt werden.
Wird Scrum in einem laufenden, festgefahrenen Projekt eingefhrt, so hat das Projektteam meist
entweder bisher noch gar keine oder seit langer Zeit keine funktionierenden Programmteile geliefert.
Der Kunde rechnet in einem solchen Fall oftmals nicht mehr mit einem erfolgreichen Abschluss des
Projektes. Darum geht es nun als erstes darum, das Vertrauen des Kunden in das Projektteam und
das des Projektteams in sich selbst wiederherzustellen. Es ist deshalb sinnvoll, in einem ersten Sprint
irgendeine Funktionalitt des Produkts zu implementieren, welche in 30 Tagen geschaffen werden
kann. So wird bewiesen, dass das Team Ergebnisse liefern kann. Dann kann meist in einem Sprint
Planning Meeting mit der regulren Entwicklung weitergefahren werden.
Whrend der weiteren Durchfhrung des Projekts sollten in beiden Szenarien dann die
Entwicklungspraktiken des Teams sukzessive optimiert beziehungsweise an die Vorgehensweise von
Scrum angepasst werden.
Seite 11 von 16

Scrum
5.2

Ein grosses oder mehrere voneinander abhngige Projekte
Wie in Abschnitt 4.2.3 bereits erwhnt, setzt sich eine Scrum Team typischerweise aus fnf bis acht
Personen zusammen. Dies limitiert die Grsse eines mit Scrum durchfhrbaren Projekts betrchtlich.
Fr grssere Projekte knnen jedoch mehrere Scrum Teams gleichzeitig eingesetzt werden. Diese
starten einen Sprint alle zur selben Zeit und prsentieren ihre Ergebnisse am Sprint Review Meeting.
Zur Koordination der einzelnen Teams untereinander finden jeweils ein- bis zweimal wchentlich ein
Treffen mit je einem Mitglied von allen Teams statt, ein sogenanntes Scrum of Scrums. Diese
Struktur kann sich auch ber mehrere Ebenen fortsetzen. Jeff Sutherland, einem der Mitbegrnder
von Scrum ist es auf diese Weise gelungen, erfolgreich mit Scrum ein Projekt mit ber 800
Mitarbeitern durchzufhren.
Eine hnliche Ausgangslage liegt vor, wenn in einem Unternehmen mehrere Applikationen
gleichzeitig entwickelt werden, welche jeweils Komponenten der anderen wiederverwenden sollen.
Scrum schlgt in diesem Fall vor, dass zuerst nur mit einer einzigen Applikation gestartet wird. Sind
bei dieser einmal gengend stabile Komponenten vorhanden, welche wiederverwendet werden
knnen, so sind diese auszugliedern und einem neuen Scrum Team, dem Shared Resources Team,
zu bergeben, welches neu die Pflege dieser Komponenten bernimmt.
Nun kann nacheinander mit der Entwicklung der weiteren Applikationen begonnen werden, welche
Komponenten des Shared Resources Teams verwenden oder ihm ihrerseits weitere Komponenten
zur Pflege bergeben knnen.
Bei der Entwicklung der Applikationen sollte darauf geachtet werden, dass zum Beispiel eine
Schichten-Architektur mit Komponenten verwendet wird, um Wiederverwendung zu vereinfachen.
Dabei ist jedoch festzuhalten, dass Wiederverwendung fr die Scrum Teams nur zweite Prioritt hat.
Ihr Ziel wird immer noch durch das Sprint Goal bestimmt.
Die oben beschriebene Vorgehensweise kann leicht fr ein grosses Projekt mit mehreren Scrum
Teams bernommen werden, welche alle an derselben Applikation arbeiten. Dies wird mglich, indem
den einzelnen Teams Elemente des Backlogs dermassen zugewiesen werden, dass diese alle auf
denselben Grundobjekten beruhen, dann aber jeweils einzelne Teilaspekte des Gesamtprodukts
behandeln. Ein Beispiel dafr wre das Grundobjekt Person. Teams knnten sich nun mit den
Aspekten Angestellter, Adressdaten oder Mitarbeitervergnstigungen befassen. Auf diese Weise
kann die Problemstellung oftmals auf die der Wiederverwendung reduziert werden.
5.3
Scrum und XP
Da Scrum primr die Management Ebene der Software Entwicklung betrachtet, kann es leicht mit
anderen Methoden kombiniert werden, welche auf die Entwicklungspraktiken fokussieren. Dies wurde
vor allem mit Extreme Programming (XP) versucht.
Dabei zeigte sich, dass sich die beiden Methoden sehr gut ergnzen. Einzig beim Planning Game
(XP) respektive Sprint Planning Meeting (Scrum) liegt eine berschneidung vor. Diese ist jedoch nicht
gravierend. Eine Kombinationsmglichkeit ist, dass User Stories von XP als Backlog Elemente fr den
Product Backlog verwendet werden.
Seite 12 von 16

Scrum

Es gibt verschiedene Versuche, welche Scrum mit XP kombinieren. Ein erster stammt von Ken
Schwaber und Martin Fowler, welche ihr Produkt xp@Scrum beispielsweise erfolgreich bei Trans
Canada Pipeline Ltd. eingefhrt haben.6
Die Firma PatientKeeper, in welcher Jeff Sutherland, der andere Mitbegrnder von Scrum, ttig ist,
bietet ebenfalls einen eigenen Ansatz an. [SUTHERLAND]
Ausserdem hat Mike Beedle ein hnliches Produkt kreiert, das er XBreed (Crossbreed) nennt und
welches zustzlich zu XP und Scrum noch weitere Elemente enthlt. [XBREED]
Abbildung 4
Kombination von Scrum und Extreme Programming
Erfolgsfaktoren
6.1
Die menschliche Komponente
Es ist festzuhalten, dass die menschliche Komponente beim Einsatz von Scrum eine usserst
kritische Rolle spielt. Dem einzelnen Mitarbeiter wird durch diesen Ansatz sehr viel Verantwortung
bertragen. Dabei kann es auch passieren, dass dies von den Beteiligten ausgentzt wird. Scrum
geht jedoch von einem positiven Menschenbild aus, das voraussetzt, dass die Mitarbeiter sich fr das
Projekt motivieren lassen. Die Mitarbeiter mssen sich dabei ihrer Verantwortung bewusst sein und
entsprechend handeln. Ist dies nicht der Fall, so sind Projekte mit Scrum zum Scheitern verurteilt
6.1.1
Scrum Master
Der Scrum Master ist in jedem Scrum Projekt die zentrale Figur. Er ist Motivator und Facilitator, muss
das Team von usseren Einflssen abschirmen und Hindernisse beseitigen. Mit seinem Einsatz und
Durchsetzungsvermgen steht und fllt Scrum. Entscheidend ist vor allem auch, dass er vom
Unternehmen die entsprechenden Kompetenzen erhlt, um auftretende Hindernisse beseitigen zu
knnen. Dies setzt vom Unternehmen ein grosses Vertrauen in Scrum voraus, da so bestehende
unternehmensweite Vorschriften in Frage gestellt werden knnen.
http://www.computerworld.com/softwaretopics/software/appdev/story/0,10801,69183,00.html und
[ADM] , http://www.controlchaos.com/XPKane.htm
Seite 13 von 16

Scrum
6.1.2

Kunde
Damit ein Scrum Projekt Erfolg haben kann, muss der Kunde sich aktiv am Entwicklungsprozess
beteiligen. Die Interaktion des Kunden mit dem Scrum Team und dem Product Owner an den Sprint
Review Meetings ist absolut notwendig. Nur so ist das Team in der Lage, auch die gewnschte
Software zu liefern. Der Kundenvertreter muss dazu kompetent und auch weisungsbefugt sein.
6.1.3
Scrum Team
Dass die Zusammenarbeit innerhalb des Scrum Teams von entscheidender Bedeutung ist, muss
kaum mehr erwhnt werden. Jeder einzelne hat die ihm bertragenen Aufgaben nach bestem
Gewissen zu erledigen und die anderen bei ihrer Arbeit zu untersttzen. Dabei muss darauf geachtet
werden, dass nicht wieder eine Rckkehr zu den klassischen Rollen in einem Entwicklungsteam
stattfindet. In einem Scrum Team sind prinzipiell alle gleichgestellt. Andererseits sollte aber in jedem
Team ein Entwickler mit grosser Erfahrung vertreten sein, der in Architekturentscheidungen das
Vorgehen in die richtigen Bahnen lenkt und die unerfahrenen Teammitglieder untersttzt.
6.1.4
Scrum Grundwerte
Ken Schwaber und Mike Beedle haben fnf Grundwerte definiert, welche Voraussetzung fr den
erfolgreichen Einsatz von Scrum sind. [SCRUM01] Diese Grundwerte sind implizit in den oben
erwhnten Erfolgsfaktoren enthalten. Sie sind usserst allgemein gehalten und sicherlich auch
ausserhalb von Scrum erstrebenswert. Aus diesem Grund wird an dieser Stelle nur eine Auflistung
wiedergegeben:
Commitment
Be willing to commit to a goal. Scrum provides people all the authority they need
to meet their commitments.
Focus
Do your job. Focus all of your efforts and skills on doing the work that youve
committed to doing. Dont worry about anything else.
Openness
Scrum keeps everything about a project visible to everyone.
Respect
Individuals are shaped by their background and their experiences. It is important

to respect the different people who comprise a team.
Courage
Have the courage to commit, to act, to be open, and to expect respect.
6.2
Grenzen von Scrum
Bezglich des Einsatzes von Scrum in grsseren, komplexen Projekten konnten leider keine
unabhngigen Berichte gefunden werden. Die Anwendbarkeit auf diese Art von Projekten wird aber
auch von langjhrigen Praktikern, bei allem Lob fr Scrum, bezweifelt. [RISING00] Der Ansatz von
Scrum scheint eher fr berschaubare Projekte bis mittlerer Grsse geeignet.
Scrum setzt voraus, dass sich das zu erstellende Software Produkt in einzelne Funktionen,
beziehungsweise Elemente, aufteilen lsst, deren Erstellung wiederum in einzelne Arbeiten aufgeteilt
werden kann. Diese Bedingungen sind bei der Entwicklung von objektorientierter Software vielfach
gegeben. Ein Einsatz ausserhalb dieses Bereichs ist aber oftmals nicht problemlos mglich.
Seite 14 von 16

Scrum

Da der Erfolg von Scrum, wie im vorherigen Abschnitt erwhnt, teilweise stark von einzelnen
Personen wie dem Scrum Master abhngig ist, muss auch berlegt werden, was bei Ausfall einer
Schlsselperson mit dem Scrum Projekt geschieht. Gibt es irgend eine Standardprozedur fr einen
solchen Fall? Diese Frage konnte im Rahmen dieser Arbeit nicht schlssig beantwortet werden.
Ein weiteres Thema, welches in den vorhandenen Unterlagen nicht abschliessend behandelt wird, ist
die Frage der Dokumentation. Aussagen dazu sind immer sehr allgemein gehalten, so zum Beispiel,
dass Dokumentationen nur dann erstellt werden sollen, wenn sie fr den Entwicklungsprozess
notwendig sind. Ausserdem mssen fr die Prsentation der neuen Produktversion am Ende eines
Sprints sicherlich ein oder mehrere bersichtsdiagramme erstellt und bei der Fertigstellung des
Produkts dem Kunden eine Benutzerdokumentation abgegeben werden. Weitere Dokumente wren
aber gerade bei einem Produkt mit lngerer Lebensdauer ntzlich, um die Pflegbarkeit der Software
zu gewhrleisten.
Zusammenfassung und Ausblick
Bei Scrum handelt es sich um einen leichtgewichtigen Managementprozess, der sich auf Projekte von
verschiedenen Grssen anwenden lsst.
Die Grundeigenschaften von Scrum sind:
Kleine Teams, welche die Kommunikation und den informellen Informationsaustausch frdern
Anpassungsfhigkeit bezglich Vernderungen von Technologie und Benutzeranforderungen
Hufige Erstellung von neuen Produktversionen, welche inspiziert, angepasst, getestet und
dokumentiert werden knnen
Aufteilung der zu erledigenden Arbeit in kleine, voneinander mglichst unanbhngige

Teilaufgaben
Die Mglichkeit, ein Projekt jederzeit als beendet zu erklren, sei dies aus zeitlichen,
finanziellen, wettbewerbstechnischen oder anderen Grnden
Die grosse Strke der Methode liegt in der Einfachheit ihres Ansatzes und ihren klar definierten
Regeln. Scrum ist in seinen Grundzgen jedem nach kurzer Zeit verstndlich.
Durch die bertragung von Verantwortung auf jeden einzelnen knnen grosse Produktivittssteigerungen erreicht werden. Diese Delegation von Kompetenzen kann aber bei Missbrauch auch
zum Scheitern der Methode fhren.
Sehr vielversprechend tnt die Kombination von Scrum mit Extreme Programming, die naheliegend
scheint.
Scrum wird momentan immer noch stark von seinen Erfindern getragen. Inwieweit sich die Methode
nach deren Ausscheiden halten wird, kann heute noch nicht mit Sicherheit beantwortet werden. Durch
den simplen Aufbau von Scrum und durch die Organisation der Scrum Master in einer Community mit
klar definierten Regeln sind die ntigen Voraussetzungen fr eine weitere Verbreitung auf jeden Fall
gegeben.
Seite 15 von 16

Scrum

Abbildungsverzeichnis
Abbildung 1
Funktionsweise von Scrum, nachgebildet gemss Graphik

http://www.controlchaos.com/Scrumo.htm
Abbildung 2
Beispiel Product Backlog, nachgebildet gemss Graphik

http://www.mountaingoatsoftware.com/scrum/productbacklog.php
Abbildung 3
Beispiel fr den Verlauf eines Sprints, nachgebildet gemss Figure 4.8, S.79, in
[SCRUM01]
Abbildung 4
Kombination von Scrum und Extreme Programming, gemss Graphik

http://www.controlchaos.com/xpScrum.htm
Quellenverzeichnis
[SCRUM01]
Schwaber, K., Beedle, M.: Agile Software Development with Scrum, Prentice Hall,
2001, http://www.agilescrum.com
[PLOP98]
Beedle, M., Devos, M., Sharon, Y., Schwaber, K., Sutherland, J., SCRUM: An
extension pattern language for hyperproductive software development, Paper for
Conference on Pattern Languages of Programs (PLoP), 1998,
http://www.mikebeedle.com/pub/scrum.pdf
[TAKEUCHI86]
Takeuchi, H., Nonaka, I., The new new Product Development Game, Harvard
Business Review 86116, 1986,
http://harvardbusinessonline.hbsp.harvard.edu/b01/en/common/item_detail.jhtml?id
=86116
[TAKEUCHI95]
Takeuchi, H., Nonaka, I., The Knowledge Creating Company, Oxford University
Press,1995, http://www.oup-usa.org/isbn/0195092694.html
[RISING00]
Rising, L., Janoff, N.: The Scrum Software Development Process for Small Teams,
IEEE Software, 2000, http://members.cox.net/risingl1/articles/IEEEScrum.pdf
[ADM]
Offizielle Webseite zu Scrum von ADM (Ken Schwaber),

http://www.controlchaos.com
[ALLIANCE]
Webseite der Community der zertifizierten Scrum Master, siehe vor allem auch
Artikelsammlung, http://www.scrumalliance.org
[SUTHERLAND] Webseite von Jeff Sutherland, Mitbegrnder von Scrum, siehe vor allem SCRUM
Log, http://www.jeffsutherland.com
[XBREED]
Offizielle Webseite zu XBreed von Mike Beedle, http://www.xbreed.net
Seite 16 von 16

Scrum Ausarbeitung

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Scrum Ausarbeitung

Hochgeladen von

Copyright:

Verfügbare Formate

Seminar Software Engineering,

Agile vs. klassische Methoden der Software-Entwicklung

Prsentation am 18. November 2003

Seminar Software Engineering

Dozent: Prof. Dr. Martin Glinz

Scrum Master .................................................................................................................................. 7

Einsatzbereiche fr Scrum ........................................................................................................ 11

Scrum Master ................................................................................................................................ 13

Seminar Software Engineering

Dozent: Prof. Dr. Martin Glinz

Grosser Aufwand in der Planungsphase ntig

Oftmals Behandlung der Mitarbeiter als Produktionsfaktor

Inkrementelles Arbeiten in sehr kurzen Zyklen

Stndige Anpassung an neue Anforderungen

Besondere Bercksichtigung der menschlichen Komponente

Seminar Software Engineering

Dozent: Prof. Dr. Martin Glinz

Was ist Scrum?

Merriam Webster Dictionary, http://www.webster.com

Seminar Software Engineering

Dozent: Prof. Dr. Martin Glinz

Geschichte von Scrum

Seminar Software Engineering

Dozent: Prof. Dr. Martin Glinz

Funktionsweise von Scrum

Funktionsweise von Scrum

Seminar Software Engineering

Dozent: Prof. Dr. Martin Glinz

Product Backlog und Product Owner

Seminar Software Engineering

Dozent: Prof. Dr. Martin Glinz

Daily Scrum Meeting

Was hast du seit dem letzten Treffen erledigt?

Was wirst du von jetzt bis zum nchsten Treffen erledigen?

Was hat dich bei deiner Arbeit behindert?

Seminar Software Engineering

Dozent: Prof. Dr. Martin Glinz

Durch die Beantwortung dieser Fragen werden verschiedene Ziele erreicht:

Sprint Planning Meeting, Sprint Goal, Sprint Backlog

Seminar Software Engineering

Verbleibende Arbeit (h)

Beispiel fr den Verlauf eines Sprints

Seminar Software Engineering

Dozent: Prof. Dr. Martin Glinz

Sprint Review Meeting

Seminar Software Engineering

Dozent: Prof. Dr. Martin Glinz

Ein grosses oder mehrere voneinander abhngige Projekte

Seminar Software Engineering

Dozent: Prof. Dr. Martin Glinz

Kombination von Scrum und Extreme Programming

Die menschliche Komponente

Seminar Software Engineering

Dozent: Prof. Dr. Martin Glinz

Scrum keeps everything about a project visible to everyone.

Individuals are shaped by their background and their experiences. It is important

Have the courage to commit, to act, to be open, and to expect respect.

Grenzen von Scrum

Seminar Software Engineering

Dozent: Prof. Dr. Martin Glinz

Zusammenfassung und Ausblick

Anpassungsfhigkeit bezglich Vernderungen von Technologie und Benutzeranforderungen

Aufteilung der zu erledigenden Arbeit in kleine, voneinander mglichst unanbhngige