Pap

er

FOM – Fachhochschule fürOekonomie & Management

Essen

Master IT-Management

Introduction to

SCRUM - A framework for softwaredevelopment

Betreuer: -

Autor: Simon Pamiés

Essen, den 26. September 2010

Inhalt

Inhalt

1 Einleitung II

2 Definitionen II

2.1 Was ist Agil? . . . . . . . . . . . . . . . . . . . . . . . . . . . . III

2.2 Agile Software-Entwicklung . . . . . . . . . . . . . . . . . . . . III

2.3 “The Agile Manifest” . . . . . . . . . . . . . . . . . . . . . . . . III

2.4 Scrumming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV

3 Wasserfall vs. Agil V

3.1 Probleme im Wasserfall-Modell . . . . . . . . . . . . . . . . . . V

3.2 Agile Methoden als Weiterentwicklung . . . . . . . . . . . . . . V

4 SCRUM VI

4.1 Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII

4.1.1 SCRUM-Master . . . . . . . . . . . . . . . . . . . . . . . VII

4.1.2 Product-Owner . . . . . . . . . . . . . . . . . . . . . . . VIII

4.1.3 Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VIII

4.2 Artefakte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VIII

4.2.1 Product- und Sprint-Backlog . . . . . . . . . . . . . . . . IX

4.2.2 Burndown-Chart . . . . . . . . . . . . . . . . . . . . . . X

4.3 Ereignisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI

4.3.1 Planung eines Release . . . . . . . . . . . . . . . . . . . XI

4.3.2 Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI

4.3.3 Daily SCRUM . . . . . . . . . . . . . . . . . . . . . . . . XI

5 Ausblick XII

I

Definitionen

1 Einleitung

Innerhalb der Softwarebranche lässt sich ein kontinuierlicher Trend zu soge-nannten “agilen Prozessen” feststellen1. Immer mehr Firmen in der IT-Branchewenden sich von “althergebrachten” Modellen hin zur Anwendung von “agilen”Methodiken. Vorreiter dieser Bewegung waren Firmen aus Japan wie Toyotaund Honda (vgl. [Wik10]), die schon früh bei der Entwicklung von Automobi-len vorwiegend starre Vorgehensweisen durch kreativere Ansätze zu ersetzenversuchten2.

Besonderen Einfluss auf den bevorzugten Einsatz solcher Methoden hattenTheorien, die von H. Takeuchi and I. Nonaka an der Hitotsubashi BusinessSchool in Japan entwickelt wurden (die Basis für SCRUM gelegt haben, vgl.[SS07]), und sich mit dem richtigen und schöpferischen Management von Wis-sen und Ideen beschäftigt haben. Besonders bei Firmen aus dem Web-Umfeldlässt sich bis heute eine verstärkte Auseinandersetzung mit dem Thema agi-le Vorgehensweisen feststellen. Beste Beispiele hierfür sind Firmen wie Yahoo,Google, Siemens oder VZnet Netzwerke und sogar einige Bereiche bei Microsofthaben dynamisierte Methodiken eingeführt3.

Die erste dokumentierte Anwendung von SCRUM (in der heutigen Form)basiert auf Recherchen durch die Easel Corporation. Auf Basis einiger For-schungsarbeiten und der Auseinandersetzung mit Experten auf dem Gebietder Motivations- und Produktivitätstheorie entstand unter der Leitung vonSCRUM-Erfinder Jeff Sutherland ein Konzept, welches auch sofort aktiv zurEntwicklung von Software genutzt wurde (vgl. [SS07]). Formalisiert und of-fiziell SCRUM genannt wurde das Ganze im Jahre 1995 auf der OOPSLAKonferenz, welches später auch im sogenannten “Agilen Manifest” mündete.

2 Definitionen

Bevor man tiefer in die Materie einsteigen kann, ist eine Abgrenzung bestimm-ter Begrifflichkeiten rund um das Thema SCRUM notwendig. Die hier genann-ten Definitionen werden im Folgenden vorausgesetzt und erleichtern auch das1 Diese Behauptung wird unterstützt von folgenden einfach nachzuvollziehenden Ergeb-

nisse (Stand: 05. April 2010): Suche nach offenen Stellen mit dem Wort “SCRUM”auf http://www.monster.de, Aktuell verfügbare Bücher zum Thema SCRUM aufhttp://www.amazon.de, Liste der Referenzen auf z.B. http://borisgloger.com/en/borisgloger-methode/referenzen/

2 Im Englischen nennt man diesen kreativen und schlanken Ansatz in der Automobilbran-che lean production und verbindet damit auch eine Philosophie die hinter der Methodiksteckt (Beispiel: “Toyota Way”).

3 http://www.eweek.com/c/a/IT-Management/MS-Lauds-Scrum-Method-for-Software-Projects/

II

Definitionen

Verständnis. Hauptaugenmerk liegt hierbei auf Erklärungen mit starkem Be-zug zu Prozessen innerhalb von Firmen und im Besonderen auf solche, dieSoftware entwickeln.

2.1 Was ist Agil?

Nach der Definition im Lexikon beschreibt man etwas als “Agil” was Frei-heitsgrade im Bezug auf Bewegung hat. Hierbei wird die Bewegung als etwasverstanden bei dem verschiedenste Fähigkeiten miteinander kombiniert werdenund eine solche erst ermöglichen. Ein Prozess (eine Unternehmung) allgemeinwird dann als agil beschrieben, wenn dieser (diese) sich schnell und effizient ansich ändernde Anforderungen durch die Umgebung anpassen kann. Dabei wirdunter “effizient” eine Wirtschaftlichkeit unter den Gesichtspunkten Preis undSchnelligkeit verstanden. Etwas, das als “Agil” beschrieben wird, kann auchmit dem Attribut “leichtgewichtig” versehen werden.

2.2 Agile Software-Entwicklung

Frei nach einer Definition aus [Pic07] versteht man unter dieser Art derSoftware-Entwicklung eine Gruppe von Methoden, die einen leichtgewichti-gen, stark evolutionären Ansatz fokussiert, und diesen über die Unterteilungin viele kleine Schritte umsetzt.

Hierbei spielen weniger Strukturen und Vorgaben eine Rolle als mehr sichselbstorganisierende Teams von interdisziplinär ausgelegten Personen. Einenhohen Anteil am Erfolg innerhalb eines agilen Prozesses haben kurze Intervalleder Kontrolle und des Abgleichs mit den eigentlichen Zielen und Wünschen desKunden.

2.3 “The Agile Manifest”

Um die o.g. Entwicklung auf Basis agiler Methoden zu untermauern, wurde2001 das sogenannte ”Agile Manifest” erstellt und von namhaften Unterstüt-zern unterschrieben. Das Ziel war es klar darzustellen, welche Prinzipien esim Umfeld agiler Herangehensweisen gibt. Das Manifest enthält die folgendenAussagen:

• Individuen und Interaktionen stehen über definierten Prozessen undvorgegebenen Tools

III

Definitionen

• Funktionierende Software ist wichtiger als eine umfassende Doku-mentation

• Zusammenarbeit mit dem Auftraggeber hat Vorrang vor komple-xen Verträgen

• Schnelle Reaktion auf Änderungen steht über dem Befolgen einesübergreifenden Plans

Es stellt also den Menschen in den Mittelpunkt der Software-Entwicklung (in-dividuals and interactions, collaboration). Schließlich entsteht Software nurdurch die Interaktion und Kollaboration von Menschen. SCRUM ist nicht tech-nologie- oder toolorientiert, sondern fordert und fördert die enge Zusammen-arbeit der Beteiligten. Das “Agile Manifest” formuliert außerdem die Opti-mierung von Kundenzufriedenheit und Wertschöpfung als Ziel der Software-Entwicklung (aus [Pic07]).

2.4 Scrumming

Der Begriff wurde durch die Sportart Rugby geprägt und bezeichnet den Neu-start eines Spiels nach Regelverstößen, einem Aus oder einem unerlaubtenVorwärtsspielen des Balls. Die Übersetzung ins Deutsche ist das ”angeordneteGedränge”. Man kann hier noch hinzufügen, dass dieses Gedränge nicht chao-tisch ist, sondern nach strengen Regeln zu erfolgen hat.

Die agile Methode hat diesen Namen (in der Abkürzung SCRUM) bekommen,weil man sich das Vorgehen innerhalb der Methode als die Aneinanderreihungvieler kontrollierter Neustarts vorstellen kann (vgl. [SS07]). Dabei wird im-mer auf Energie, Fokus, Klarheit und Transparenz innerhalb der Planung derBereiche zwischen den Neustarts geachtet.

Eine gute Zusammenfassung des Gedankens ist den beiden Erfindern H. Ta-keuchi und I. Nonaka zuzuschreiben (aus [Sch03]) und verdeutlicht noch einmaldie Idee:

In today’s fast-paced, fiercely competitive world of commercialnew product development, speed and flexibility are essential. Com-panies are increasingly realizing that the old, sequential approachto developing new products simply won’t get the job done. Instead,companies in Japan and the United States are using a holistic me-thod; as in rugby, the ball gets passed within the team as it movesas a unit up the field.

IV

Wasserfall vs. Agil

3 Wasserfall vs. Agil

Die meisten Projekte in der Software-Entwicklung folgen dem sogenanntenWasserfall-Modell. Hier wird der gesamte Prozess global in Phasen unterteilt,deren Reihenfolge genauso wie definiert einzuhalten ist. Wird ein Fehler inner-halb einer Phase festgestellt, müssen alle Phasen bis hin zur aktuellen Phasezumindest zu Teilen wieder durchlaufen werden, um den Fehler zu beheben.Besonders verzögernd wirkt es sich aus, wenn zu einem späten Zeitpunkt fest-gestellt wird, dass schon in der Analyse- oder Design-Phase Fehler gemachtoder gar Anforderungen falsch verstanden oder nicht berücksichtigt wurden.

Abbildung 1: Der Integration der Schritte aus dem Wasserfall-Modell in SCRUM.Links die Hierarchie der Schritte und rechts die Integration bei SCRUM(Bilder frei nach [Bul07])

3.1 Probleme im Wasserfall-Modell

Eine der größten Herausforderungen beim Wasserfall-Modell besteht darin,dass schon sehr früh alle Anforderungen möglichst genau feststehen müssen.Dadurch bekommt man zwar eine fundierte Basis für Vertragsverhandlungen,oft hat aber die Beschreibung am Anfang nur noch wenig mit dem Endproduktzu tun. Durch das Durchlaufen eines solch monolithischen Prozesses kann auchauf neue oder sich ändernde Anforderungen schlecht bis gar nicht reagiertwerden.

3.2 Agile Methoden als Weiterentwicklung

Am Punkt der frühzeitigen Festlegung des Rahmens eines Systems und derSpezifikation der Anforderungen setzen agile Methoden ein: Diese verzichtendarauf, alles im Detail sofort zu spezifizieren, es wird lediglich eine Liste dergenerellen Anforderungen festgelegt. In kurzen Zyklen werden nun jeweils Teiledes Pakets erstellt. Dabei wird der Kunde am Ende jedes Zyklus aktiv mit ein-bezogen und um seine Meinung gefragt. Somit wächst das Produkt evolutionäranhand sich weiterentwickelnder Anforderungen.

V

SCRUM

Die eigentliche Vorgehensweise innerhalb eines Zyklus ähnelt dem Wasserfall-Modell in der Vorgehensweise, ist aber im Gegensatz zur Definition desselbenweder starr, noch monolithisch ausgelegt. Agile Methoden kann man somitauch als eine Art Weiterentwicklung bezeichnen, wobei diese Entwicklung sel-ber eine Stufe der Evolution von Methoden zur Software-Entwicklung darstellt.

4 SCRUM

Wie oben beschrieben, verzichtet man im Kontext von SCRUM auf festgelegteRegeln oder starre Strukturen in jedweder Hinsicht. Die Methode selber ver-steht sich deshalb auch eher als Framework, anstatt eines Regelwerks oderHandlungsanweisungen. Es sagt nur etwas über den Rahmen aus und gibtStützen (Prinzipien) an die Hand. Es kann als agiles Managementframeworkzur Entwicklung von Software bezeichnet werden, welches aus wenigen klarenRegeln besteht.

Abbildung 2: SCRUM im Überblick mit allen Faktoren (deutsche Version aus [Sch03]).

Diese beinhalten die Anwendung der drei Rollen Product-Owner, Team undSCRUM-Master, die Verwendung eines priorisierten Product-Backlog sowiedas Erstellen von Produktinkrementen innerhalb kurzer Arbeitszyklen, dieSprints genannt werden.

Dieses Kapitel baut zu großen Teilen auf [SS07], [Pic07] und einer Präsentationdurch die Firma Softhouse (vgl. [Sof09]) auf.

VI

SCRUM

4.1 Rollen

Ein Team besteht grundsätzlich aus einem SCRUM-Master, dem Product-Owner und weiteren Mitgliedern. Alle Beteiligten eines Teams nennt man“Pigs”. Der Owner ist der “Pig” des Product-Backlogs, das Team ist der “Pig”der eigentlich zu erledigenden Arbeit und der Master ist der “Pig” des SCRUM-Prozesses. Jeder andere außerhalb einer dieser Rollen wird als “Chicken” be-zeichnet und hat nichts zu sagen. Die Analogie zwischen den Rollen und einem“Pig” sowie der Beteiligung von anderen als “Chicken” geht auf eine Geschichtezurück, die auch die Machtverteilung ganz gut zeigt.

Abbildung 3: Das Schwein ist viel stärker involviert, (weil es ja Teile seines Körpersdem Projekt zur Verfügung stellt) als das Huhn, welches nur Eier zu-steuert.

4.1.1 SCRUM-Master

Die Person mit der Rolle “Master” kann aus Sicht klassischer Strukturen als derProjektleiter gesehen werden. Es gibt aber Unterschiede, die beachtet werdenmüssen. Der Master hat in erster Linie dafür zu sorgen, dass das Team sichmit den Werten und Prinzipien von SCRUM identifiziert und danach handelt.Er hat außerdem die Rolle eines Coaches und trägt Sorge für eine produktiveErledigung der Arbeit. Dadurch fällt ihm auch die Aufgabe zu alle möglichen“Störungen” von außen vom Team fernzuhalten, damit sich dieses 100% auf dieArbeit konzentrieren kann. Er ist im Vergleich zu einem Projektmanager imWasserfall-Modell mehr im Hintergrund und hat weniger steuernde Aufgaben.Es ist Usus, dass der Master keine sonstigen Aufgaben hat und in keinem Falldarf er gleichzeitig die Rolle des Owners einnehmen.

VII

SCRUM

4.1.2 Product-Owner

Diese Rolle kann man naiv mit der Aufgabe des Kunden gleichsetzen. Der Ow-ner ist die einzige Person, die das Product-Backlog verwaltet und sicherstellt,dass die gelieferte Arbeit den Wünschen entspricht. Sie definiert und priori-siert Features und setzt zugleich Deadlines. Sollte jemand eine Änderung vonPriorisierungen wünschen, dann ist der Owner der richtige Ansprechpartnerdafür. Diese Rolle verkörpert die Differenz zwischen einem klassischen Pro-jektleiter und dem SCRUM-Master. Dazu kommt, dass diejenige Person dieAufgabe hat, die Aufgaben und die Priorisierung für jedermann sichtbar zuhalten und zu jederzeit tiefergehende Informationen zu einem Feature liefernkönnen muss.

4.1.3 Team

Das Team ist eine interdisziplinäre Zusammenstellung aller Personen die füreinen bestimmten Zeitraum an einer Aufgabe zusammenarbeiten müssen. EinTeam bei der Software-Entwicklung besteht also nicht nur aus Entwicklern,sondern je nach Aufgabe auch aus System- oder Datenbank-Administratorenoder UI-Design. Das Team liefert als Ganzes ein lauffähiges Produkt ab, wel-ches die vorher definierten Anforderungen erfüllt und einen Teil des Gesamt-produkts ausmacht.

Jeder im Team beteiligt sich an allen Aufgaben, die anfallen. Sollte der UI-Designer mal nicht ausgelastet sein, dann werden Wege gesucht, um zumindestdie anderen zu unterstützen. Teams sind an keine Weisungen gebunden, son-dern organisieren sich selbst. Es gibt niemanden, der dem Team vorschreibt,wie man zu dem definierten Ziel kommt und auch nicht welche Methoden oderSoftware zu benutzen ist.

4.2 Artefakte

Artefakte sind Werkzeuge, die den Prozess als Ganzes unterstützen und al-len Beteiligten eine Verschriftlichung von Aufgaben und Fortschritt geben. Zuden Artefakten gehört das Product-Backlog, der Release-Burndown-Chart, dasSprint-Backlog und der Sprint-Burndown-Chart. Dies ist die Minimal- als auchdie Maximalausstattung mit Werkzeugen in einem SCRUM-geführten Prozessder Software-Entwicklung. Alle zusätzlichen benutzen Werkzeuge sind nichtBestandteil des Konzeptes.

VIII

SCRUM

4.2.1 Product- und Sprint-Backlog

Ein Backlog ist eine Auflistung von Anforderungen inklusive einer Priorisie-rung derselben, soweit erforderlich. Sie kann durch eine Aufwandsschätzungergänzt werden. Je nach Kontext (Product, Sprint) erfüllt es mehr oder weni-ger spezifische Anforderungen.

Abbildung 4: Beispiel für ein Product-Backlog

Ein Product-Backlog enthält die globalen Anforderungen an die Software undwird vom Product-Owner verwaltet. Es ist am Anfang eines Projekts eine loseSammlung von groben Anforderungen (zumeist Stories4) und wächst mit derZeit. Es ist wichtig, es von einem Pflichtenheft abzugrenzen: Ein Pflichtenheft4 Unter Stories versteht man die Beschreibung einer Funktionalität aus Sicht eines Anwen-

ders, der eine “Geschichte” erzählt, um deutlich zu machen, was er erwartet. Es gibt alsAbgrenzung davon noch Tasks, die zumeist keine direkte Auswirkung auf den Anwenderhaben. Beispiel für einen Task, ist das Aufsetzen eines Servers.

IX

SCRUM

ist nicht auf Veränderung während dem Prozess ausgelegt und die Beschrei-bung der Funktionen ist zumeist schon sehr detailliert vorzufinden. Bei einemProduct-Backlog können zu späteren Zeitpunkten auch noch vorher völlig un-bekannte Anforderungen hinzukommen oder einige verschwinden.

Um für einen Sprint eine genaue Vorstellung von den zu erledigenden Aufgabenund der Zusammensetzung des Ergebnisses zu haben, wird ein Sprint-Backlogerstellt. Dieses ist ein Auszug aus dem Product-Backlog mit einer hohen Detail-treue, genauen Priorisierungen und Aufwänden. Die Detailtreue sollte dadurchreflektiert werden, dass ein Bestandteil (eine Zeile) des Sprint-Backlogs einerTagesaufgabe gleich kommt. Wie auch beim Product ist dieses Backlog nichtfix, sondern kann sich während eines Sprints verändern, wobei nur Mitgliederdes Teams Änderungen vornehmen dürfen.

4.2.2 Burndown-Chart

Um den Fortschritt innerhalb eines gesamten Projekts oder eines Sprint-Kontexts zu visualisieren, hat sich die grafische Verdeutlichung der erledigtenZeilen aus dem Backlog als sehr hilfreich erwiesen. Allen Beteiligten kann somitauf einen Blick der Status verdeutlicht werden. Ein solcher Chart kann sowohlauf Basis des Product- als auch anhand des Sprint-Backlogs erstellt werden.

Abbildung 5: Ein Burndown-Chart aus [SS07]. Auf der Y-Achse ist die Anzahl derStunden aufgezeichnet und auf der X-Achse die Zeit. Man sieht deutlichwie sich im Laufe der Zeit die Anzahl der Stunde verringert (im Mittel).

X

SCRUM

4.3 Ereignisse

Um Rahmenbedingungen für eine gute Kommunikation und den optimalenEinsatz von Artefakten und Rollen zu schaffen, definiert SCRUM ein paar ein-zuhaltende Ereignisse. Diese sind mit Meetings vergleichbar, wobei hier strengeRegeln im Bezug auf Zeit und erlaubten Themen existieren. Dies dient dazu,keine Zeit mit unnötigen Besprechungen zu verlieren, sondern den Fokus zuhalten.

4.3.1 Planung eines Release

Vergleichbar mit dem Ramp-Up-Meeting im Kontext des Wasserfall-Modells,ist dieses Meeting das erste und soll die Frage “Wie können wir die Visionin ein funktionierendes Produkt verwandeln?” zumindest grob behandeln. DasErgebnis eines solchen Meetings ist der Product-Backlog. In diesem Zusam-mentreffen aller Owner, dem realen Kunden und vielleicht noch den Verant-wortlichen wird die Basis für die weitere Arbeit gelegt und auch schon versuchtRisiken zu erkennen. Für den Kunden kann nach einem solchen Meeting eineKostenschätzung abgegeben werden.

4.3.2 Sprint

Der Sprint ist ein fest definierter Zeitraum, in dem die Arbeit an einem Subsetder Anforderungen hin zu einem funktionierenden Produkt gearbeitet wird.Während eines Sprints finden keine Änderungen an den Anforderungen statt(Aufgabe des Masters) und jeder Beteiligte soll sich zu 100% auf seine Aufgabekonzentrieren.Das Team ist konstant, kann aber pro Sprint Umschichtungenunterliegen. Ein Sprint kann abgebrochen werden, wenn es Änderungen gibt,die mit dem Ziel des Sprints nicht zusammenpassen. Das Team kann demOwner dann empfehlen, den Sprint abzubrechen.

Der Sprint wird immer mit einem Sprint-Meeting (max. 8 Stunden insgesamtpro Sprint) begonnen, bei dem das Sprint-Backlog erstellt wird und eine Visionformuliert wird, die das Endergebnis einfach begreifbar macht. Nach einemSprint gibt es ein Review-Meeting, an dem auch etwas vorzeigbar sein sollte.Sollte es nichts zum “Anfassen” geben, dann sind die Ergebnisse des Sprintanderweitig darzustellen (Präsentation, o.a.).

4.3.3 Daily SCRUM

Unter diesem Begriff versteht man das tägliche Meeting eines Teams, um sichüber den Status und eventuell notwendige Änderungen klar zu werden. Dieses

XI

Ausblick

Meeting sollte maximal eine Länge von 15 Minuten haben (bei einer Teamgrößevon 6 bis 10 Personen) und findet immer zur gleichen Zeit am gleichen Ortstatt. Jedes Mitglied beantwortet während des Meetings folgende Fragen (undnur diese):

• Was wurde seit dem letzten Meeting erreicht?

• Was soll bis zum nächsten Meeting erreicht werden?

• Gibt es Probleme oder steht der Erledigung etwas im Weg?

Verantwortlich für die Durchführung und die Einhaltung der Regeln ist derSCRUM-Master. Er ist auch derjenige, der sich allen Problemen annimmt, dieder Erledigung oder Fokussierung von Aufgaben im Wege stehen. Er verhin-dert auch, dass jemand außerhalb des Teams diese Meetings stört oder sicheinmischt.

5 Ausblick

SCRUM ist kein Wundermittel, das, einmal in eine Organisation eingeführt,quasi von selbst alles besser werden lässt. Oft passiert eher das Gegenteil: Inder ersten Phase der Sprints ist die Umstellung schwierig und viele Hindernissetreten auf, die man versucht mit althergebrachten Methoden aus dem Wegzu räumen. Besonders die Einhaltung der Rollen bringt Schwierigkeiten mitsich und ist für Mitarbeiter als auch für das Management ungewohnt. Dieerfolgreiche und zielgerichtete Anwendung ist ein Lernprozess, der viel Zeitund Geduld sowie zumindest einen erfahrenen SCRUM-Master benötigt. Einguter, sehr praxisnaher Bericht ist unter [Kni07] zu finden.

Die Einführung von SCRUM in ein Unternehmen ist nicht immer möglich undvor einer Einführung sollten sich alle Verantwortlichen die vorhandenen Struk-turen genau anschauen und evaluieren, ob SCRUM überhaupt umsetzbar ist.Es gibt einige Unternehmen mit stark optimierten Strukturen, wo ein solchdynamischer und iterativer Prozess keinen Sinn ergibt und kontraproduktivwirken kann. Besonders dann, wenn kein Management-Buy-In erfolgt oder er-folgen kann. Auch bei stark verteilten Teams ergibt SCRUM in der Regel5keinen Sinn, da die Einhaltung der Regeln nicht erfolgen kann.5 Wenn die Mitglieder eines Teams verteilt sind, dann entsteht durch die Einhaltung der

Regeln ein nicht unerheblicher Overhead, der die Produktivität eher senkt. Desweiterenfehlt die menschliche Komponente zum Teil völlig und widerspricht somit dem agilenManifest.

XII

Literatur

Auch erfordert SCRUM einen hohen persönlichen und motivierten Ansatz be-teiligter Personen. Desweiteren ist die optimale Ausnutzung der Zeit zumeistnur durch den Einsatz einer sehr flexiblen Programmiersprache und der Be-nutzung von automatischen Tests (da jeder manuelle Test Aufwand generiert)gegeben. Eine ausführliche Studie verdeutlicht die Probleme und zeigt Poten-ziale auf (siehe [Wit09]).

Auf lange Sicht ist SCRUM als ein erfolgversprechendes Modell im Bereich derSoftware-Entwicklung zu sehen (auch in größeren Unternehmen, siehe [Bul07])und bringt nach einer Eingewöhnungsphase viele Vorteile und führt im Endef-fekt zu einer hohen Qualität ausgelieferter Produkte.

Literatur[Bul07] Bulling, Rainer: Agile Softwareentwicklung mit SCRUM bei Sie-

mens. In: inside (2007), S. 42–43

[Kni07] Kniberg, Henrik: Scrum und XP im harten Projektalltag. (2007)

[Pic07] Pichler, Roman: Agiles Projektmanagement erfolgreich einsetzen.dpunkt.verlag, 2007

[Sch03] Schweitzer, Raffael: Scrum - eine agile Methode zur Software-Entwicklung. 2003. – Hausarbeit

[Sof09] Softhouse: Scrum in five minutes. (2009)

[SS07] Sutherland, Jeff ; Schwaber, Ken: The Scrum Papers: Nuts,Bolts, and Origins of an Agile Process. (2007)

[Wik10] Wikipedia, Deutschland: Toyota-Produktionssystem. http://de.wikipedia.org/wiki/Toyota-Produktionssystem. Version: 2010. –abgerufen am 05.04.2010

[Wit09] Wittwer, Markus: Was (noch) klassische Projekte von Scrum undCo lernen können, 2009. – Eine Studie über den Erfolg von agilenProjekten

XIII