Paper FOM Fachhochschule für Oekonomie & Management Essen Master IT-Management Introduction to SCRUM - A framework for software development 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 sogenannten agilen Prozessen feststellen 1. Immer mehr Firmen in der IT-Branche wenden sich von althergebrachten Modellen hin zur Anwendung von agilen Methodiken. Vorreiter dieser Bewegung waren Firmen aus Japan wie Toyota und Honda (vgl. [Wik10]), die schon früh bei der Entwicklung von Automobilen vorwiegend starre Vorgehensweisen durch kreativere Ansätze zu ersetzen versuchten 2. Besonderen Einfluss auf den bevorzugten Einsatz solcher Methoden hatten Theorien, die von H. Takeuchi and I. Nonaka an der Hitotsubashi Business School in Japan entwickelt wurden (die Basis für SCRUM gelegt haben, vgl. [SS07]), und sich mit dem richtigen und schöpferischen Management von Wissen und Ideen beschäftigt haben. Besonders bei Firmen aus dem Web-Umfeld lässt sich bis heute eine verstärkte Auseinandersetzung mit dem Thema agile Vorgehensweisen feststellen. Beste Beispiele hierfür sind Firmen wie Yahoo, Google, Siemens oder VZnet Netzwerke und sogar einige Bereiche bei Microsoft haben dynamisierte Methodiken eingeführt 3. Die erste dokumentierte Anwendung von SCRUM (in der heutigen Form) basiert auf Recherchen durch die Easel Corporation. Auf Basis einiger Forschungsarbeiten und der Auseinandersetzung mit Experten auf dem Gebiet der Motivations- und Produktivitätstheorie entstand unter der Leitung von SCRUM-Erfinder Jeff Sutherland ein Konzept, welches auch sofort aktiv zur Entwicklung von Software genutzt wurde (vgl. [SS07]). Formalisiert und offiziell SCRUM genannt wurde das Ganze im Jahre 1995 auf der OOPSLA Konferenz, welches später auch im sogenannten Agilen Manifest mündete. 2 Definitionen Bevor man tiefer in die Materie einsteigen kann, ist eine Abgrenzung bestimmter Begrifflichkeiten rund um das Thema SCRUM notwendig. Die hier genannten Definitionen werden im Folgenden vorausgesetzt und erleichtern auch das 1 Diese Behauptung wird unterstützt von folgenden einfach nachzuvollziehenden Ergebnisse (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 auf http://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 Automobilbranche lean production und verbindet damit auch eine Philosophie die hinter der Methodik steckt (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 Bezug zu Prozessen innerhalb von Firmen und im Besonderen auf solche, die Software entwickeln. 2.1 Was ist Agil? Nach der Definition im Lexikon beschreibt man etwas als Agil was Freiheitsgrade im Bezug auf Bewegung hat. Hierbei wird die Bewegung als etwas verstanden bei dem verschiedenste Fähigkeiten miteinander kombiniert werden und eine solche erst ermöglichen. Ein Prozess (eine Unternehmung) allgemein wird dann als agil beschrieben, wenn dieser (diese) sich schnell und effizient an sich ändernde Anforderungen durch die Umgebung anpassen kann. Dabei wird unter effizient eine Wirtschaftlichkeit unter den Gesichtspunkten Preis und Schnelligkeit verstanden. Etwas, das als Agil beschrieben wird, kann auch mit dem Attribut leichtgewichtig versehen werden. 2.2 Agile Software-Entwicklung Frei nach einer Definition aus [Pic07] versteht man unter dieser Art der Software-Entwicklung eine Gruppe von Methoden, die einen leichtgewichtigen, stark evolutionären Ansatz fokussiert, und diesen über die Unterteilung in viele kleine Schritte umsetzt. Hierbei spielen weniger Strukturen und Vorgaben eine Rolle als mehr sich selbstorganisierende Teams von interdisziplinär ausgelegten Personen. Einen hohen Anteil am Erfolg innerhalb eines agilen Prozesses haben kurze Intervalle der Kontrolle und des Abgleichs mit den eigentlichen Zielen und Wünschen des Kunden. 2.3 The Agile Manifest Um die o.g. Entwicklung auf Basis agiler Methoden zu untermauern, wurde 2001 das sogenannte Agile Manifest erstellt und von namhaften Unterstützern unterschrieben. Das Ziel war es klar darzustellen, welche Prinzipien es im Umfeld agiler Herangehensweisen gibt. Das Manifest enthält die folgenden Aussagen: Individuen und Interaktionen stehen über definierten Prozessen und vorgegebenen Tools III
Definitionen Funktionierende Software ist wichtiger als eine umfassende Dokumentation Zusammenarbeit mit dem Auftraggeber hat Vorrang vor komplexen Verträgen Schnelle Reaktion auf Änderungen steht über dem Befolgen eines übergreifenden Plans Es stellt also den Menschen in den Mittelpunkt der Software-Entwicklung (individuals and interactions, collaboration). Schließlich entsteht Software nur durch die Interaktion und Kollaboration von Menschen. SCRUM ist nicht technologie- oder toolorientiert, sondern fordert und fördert die enge Zusammenarbeit der Beteiligten. Das Agile Manifest formuliert außerdem die Optimierung 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 Neustart eines Spiels nach Regelverstößen, einem Aus oder einem unerlaubten Vorwärtsspielen des Balls. Die Übersetzung ins Deutsche ist das angeordnete Gedränge. Man kann hier noch hinzufügen, dass dieses Gedränge nicht chaotisch 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 Aneinanderreihung vieler kontrollierter Neustarts vorstellen kann (vgl. [SS07]). Dabei wird immer auf Energie, Fokus, Klarheit und Transparenz innerhalb der Planung der Bereiche zwischen den Neustarts geachtet. Eine gute Zusammenfassung des Gedankens ist den beiden Erfindern H. Takeuchi und I. Nonaka zuzuschreiben (aus [Sch03]) und verdeutlicht noch einmal die Idee: In today s 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 won t 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. IV
Wasserfall vs. Agil 3 Wasserfall vs. Agil Die meisten Projekte in der Software-Entwicklung folgen dem sogenannten Wasserfall-Modell. Hier wird der gesamte Prozess global in Phasen unterteilt, deren Reihenfolge genauso wie definiert einzuhalten ist. Wird ein Fehler innerhalb einer Phase festgestellt, müssen alle Phasen bis hin zur aktuellen Phase zumindest zu Teilen wieder durchlaufen werden, um den Fehler zu beheben. Besonders verzögernd wirkt es sich aus, wenn zu einem späten Zeitpunkt festgestellt wird, dass schon in der Analyse- oder Design-Phase Fehler gemacht oder 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 Endprodukt zu tun. Durch das Durchlaufen eines solch monolithischen Prozesses kann auch auf neue oder sich ändernde Anforderungen schlecht bis gar nicht reagiert werden. 3.2 Agile Methoden als Weiterentwicklung Am Punkt der frühzeitigen Festlegung des Rahmens eines Systems und der Spezifikation der Anforderungen setzen agile Methoden ein: Diese verzichten darauf, alles im Detail sofort zu spezifizieren, es wird lediglich eine Liste der generellen Anforderungen festgelegt. In kurzen Zyklen werden nun jeweils Teile des Pakets erstellt. Dabei wird der Kunde am Ende jedes Zyklus aktiv mit einbezogen und um seine Meinung gefragt. Somit wächst das Produkt evolutionär anhand sich weiterentwickelnder Anforderungen. V
SCRUM Die eigentliche Vorgehensweise innerhalb eines Zyklus ähnelt dem Wasserfall- Modell in der Vorgehensweise, ist aber im Gegensatz zur Definition desselben weder starr, noch monolithisch ausgelegt. Agile Methoden kann man somit auch als eine Art Weiterentwicklung bezeichnen, wobei diese Entwicklung selber eine Stufe der Evolution von Methoden zur Software-Entwicklung darstellt. 4 SCRUM Wie oben beschrieben, verzichtet man im Kontext von SCRUM auf festgelegte Regeln oder starre Strukturen in jedweder Hinsicht. Die Methode selber versteht sich deshalb auch eher als Framework, anstatt eines Regelwerks oder Handlungsanweisungen. Es sagt nur etwas über den Rahmen aus und gibt Stützen (Prinzipien) an die Hand. Es kann als agiles Managementframework zur Entwicklung von Software bezeichnet werden, welches aus wenigen klaren Regeln besteht. Abbildung 2: SCRUM im Überblick mit allen Faktoren (deutsche Version aus [Sch03]). Diese beinhalten die Anwendung der drei Rollen Product-Owner, Team und SCRUM-Master, die Verwendung eines priorisierten Product-Backlog sowie das Erstellen von Produktinkrementen innerhalb kurzer Arbeitszyklen, die Sprints genannt werden. Dieses Kapitel baut zu großen Teilen auf [SS07], [Pic07] und einer Präsentation durch 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 bezeichnet und hat nichts zu sagen. Die Analogie zwischen den Rollen und einem Pig sowie der Beteiligung von anderen als Chicken geht auf eine Geschichte zurück, die auch die Machtverteilung ganz gut zeigt. Abbildung 3: Das Schwein ist viel stärker involviert, (weil es ja Teile seines Körpers dem Projekt zur Verfügung stellt) als das Huhn, welches nur Eier zusteuert. 4.1.1 SCRUM-Master Die Person mit der Rolle Master kann aus Sicht klassischer Strukturen als der Projektleiter gesehen werden. Es gibt aber Unterschiede, die beachtet werden müssen. Der Master hat in erster Linie dafür zu sorgen, dass das Team sich mit 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 produktive Erledigung 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 die Arbeit konzentrieren kann. Er ist im Vergleich zu einem Projektmanager im Wasserfall-Modell mehr im Hintergrund und hat weniger steuernde Aufgaben. Es ist Usus, dass der Master keine sonstigen Aufgaben hat und in keinem Fall darf 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 Owner ist die einzige Person, die das Product-Backlog verwaltet und sicherstellt, dass die gelieferte Arbeit den Wünschen entspricht. Sie definiert und priorisiert Features und setzt zugleich Deadlines. Sollte jemand eine Änderung von Priorisierungen wünschen, dann ist der Owner der richtige Ansprechpartner dafür. Diese Rolle verkörpert die Differenz zwischen einem klassischen Projektleiter und dem SCRUM-Master. Dazu kommt, dass diejenige Person die Aufgabe hat, die Aufgaben und die Priorisierung für jedermann sichtbar zu halten und zu jederzeit tiefergehende Informationen zu einem Feature liefern können muss. 4.1.3 Team Das Team ist eine interdisziplinäre Zusammenstellung aller Personen die für einen bestimmten Zeitraum an einer Aufgabe zusammenarbeiten müssen. Ein Team bei der Software-Entwicklung besteht also nicht nur aus Entwicklern, sondern je nach Aufgabe auch aus System- oder Datenbank-Administratoren oder UI-Design. Das Team liefert als Ganzes ein lauffähiges Produkt ab, welches die vorher definierten Anforderungen erfüllt und einen Teil des Gesamtprodukts ausmacht. Jeder im Team beteiligt sich an allen Aufgaben, die anfallen. Sollte der UI- Designer mal nicht ausgelastet sein, dann werden Wege gesucht, um zumindest die anderen zu unterstützen. Teams sind an keine Weisungen gebunden, sondern organisieren sich selbst. Es gibt niemanden, der dem Team vorschreibt, wie man zu dem definierten Ziel kommt und auch nicht welche Methoden oder Software zu benutzen ist. 4.2 Artefakte Artefakte sind Werkzeuge, die den Prozess als Ganzes unterstützen und allen Beteiligten eine Verschriftlichung von Aufgaben und Fortschritt geben. Zu den Artefakten gehört das Product-Backlog, der Release-Burndown-Chart, das Sprint-Backlog und der Sprint-Burndown-Chart. Dies ist die Minimal- als auch die Maximalausstattung mit Werkzeugen in einem SCRUM-geführten Prozess der Software-Entwicklung. Alle zusätzlichen benutzen Werkzeuge sind nicht Bestandteil des Konzeptes. VIII
SCRUM 4.2.1 Product- und Sprint-Backlog Ein Backlog ist eine Auflistung von Anforderungen inklusive einer Priorisierung derselben, soweit erforderlich. Sie kann durch eine Aufwandsschätzung ergänzt werden. Je nach Kontext (Product, Sprint) erfüllt es mehr oder weniger spezifische Anforderungen. Abbildung 4: Beispiel für ein Product-Backlog Ein Product-Backlog enthält die globalen Anforderungen an die Software und wird vom Product-Owner verwaltet. Es ist am Anfang eines Projekts eine lose Sammlung von groben Anforderungen (zumeist Stories 4 ) und wächst mit der Zeit. Es ist wichtig, es von einem Pflichtenheft abzugrenzen: Ein Pflichtenheft 4 Unter Stories versteht man die Beschreibung einer Funktionalität aus Sicht eines Anwenders, der eine Geschichte erzählt, um deutlich zu machen, was er erwartet. Es gibt als Abgrenzung davon noch Tasks, die zumeist keine direkte Auswirkung auf den Anwender haben. Beispiel für einen Task, ist das Aufsetzen eines Servers. IX
SCRUM ist nicht auf Veränderung während dem Prozess ausgelegt und die Beschreibung der Funktionen ist zumeist schon sehr detailliert vorzufinden. Bei einem Product-Backlog können zu späteren Zeitpunkten auch noch vorher völlig unbekannte Anforderungen hinzukommen oder einige verschwinden. Um für einen Sprint eine genaue Vorstellung von den zu erledigenden Aufgaben und der Zusammensetzung des Ergebnisses zu haben, wird ein Sprint-Backlog erstellt. Dieses ist ein Auszug aus dem Product-Backlog mit einer hohen Detailtreue, genauen Priorisierungen und Aufwänden. Die Detailtreue sollte dadurch reflektiert werden, dass ein Bestandteil (eine Zeile) des Sprint-Backlogs einer Tagesaufgabe gleich kommt. Wie auch beim Product ist dieses Backlog nicht fix, sondern kann sich während eines Sprints verändern, wobei nur Mitglieder des 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 erledigten Zeilen aus dem Backlog als sehr hilfreich erwiesen. Allen Beteiligten kann somit auf einen Blick der Status verdeutlicht werden. Ein solcher Chart kann sowohl auf 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 der Stunden aufgezeichnet und auf der X-Achse die Zeit. Man sieht deutlich wie 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 optimalen Einsatz von Artefakten und Rollen zu schaffen, definiert SCRUM ein paar einzuhaltende Ereignisse. Diese sind mit Meetings vergleichbar, wobei hier strenge Regeln im Bezug auf Zeit und erlaubten Themen existieren. Dies dient dazu, keine Zeit mit unnötigen Besprechungen zu verlieren, sondern den Fokus zu halten. 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 Vision in ein funktionierendes Produkt verwandeln? zumindest grob behandeln. Das Ergebnis eines solchen Meetings ist der Product-Backlog. In diesem Zusammentreffen aller Owner, dem realen Kunden und vielleicht noch den Verantwortlichen wird die Basis für die weitere Arbeit gelegt und auch schon versucht Risiken zu erkennen. Für den Kunden kann nach einem solchen Meeting eine Kostenschätzung abgegeben werden. 4.3.2 Sprint Der Sprint ist ein fest definierter Zeitraum, in dem die Arbeit an einem Subset der 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 Aufgabe konzentrieren.das Team ist konstant, kann aber pro Sprint Umschichtungen unterliegen. Ein Sprint kann abgebrochen werden, wenn es Änderungen gibt, die mit dem Ziel des Sprints nicht zusammenpassen. Das Team kann dem Owner dann empfehlen, den Sprint abzubrechen. Der Sprint wird immer mit einem Sprint-Meeting (max. 8 Stunden insgesamt pro Sprint) begonnen, bei dem das Sprint-Backlog erstellt wird und eine Vision formuliert wird, die das Endergebnis einfach begreifbar macht. Nach einem Sprint gibt es ein Review-Meeting, an dem auch etwas vorzeigbar sein sollte. Sollte es nichts zum Anfassen geben, dann sind die Ergebnisse des Sprint anderweitig 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öße von 6 bis 10 Personen) und findet immer zur gleichen Zeit am gleichen Ort statt. Jedes Mitglied beantwortet während des Meetings folgende Fragen (und nur 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 der SCRUM-Master. Er ist auch derjenige, der sich allen Problemen annimmt, die der Erledigung oder Fokussierung von Aufgaben im Wege stehen. Er verhindert auch, dass jemand außerhalb des Teams diese Meetings stört oder sich einmischt. 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: In der ersten Phase der Sprints ist die Umstellung schwierig und viele Hindernisse treten auf, die man versucht mit althergebrachten Methoden aus dem Weg zu räumen. Besonders die Einhaltung der Rollen bringt Schwierigkeiten mit sich und ist für Mitarbeiter als auch für das Management ungewohnt. Die erfolgreiche und zielgerichtete Anwendung ist ein Lernprozess, der viel Zeit und Geduld sowie zumindest einen erfahrenen SCRUM-Master benötigt. Ein guter, sehr praxisnaher Bericht ist unter [Kni07] zu finden. Die Einführung von SCRUM in ein Unternehmen ist nicht immer möglich und vor einer Einführung sollten sich alle Verantwortlichen die vorhandenen Strukturen genau anschauen und evaluieren, ob SCRUM überhaupt umsetzbar ist. Es gibt einige Unternehmen mit stark optimierten Strukturen, wo ein solch dynamischer und iterativer Prozess keinen Sinn ergibt und kontraproduktiv wirken kann. Besonders dann, wenn kein Management-Buy-In erfolgt oder erfolgen kann. Auch bei stark verteilten Teams ergibt SCRUM in der Regel 5 keinen 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. Desweiteren fehlt die menschliche Komponente zum Teil völlig und widerspricht somit dem agilen Manifest. XII
Literatur Auch erfordert SCRUM einen hohen persönlichen und motivierten Ansatz beteiligter Personen. Desweiteren ist die optimale Ausnutzung der Zeit zumeist nur durch den Einsatz einer sehr flexiblen Programmiersprache und der Benutzung von automatischen Tests (da jeder manuelle Test Aufwand generiert) gegeben. Eine ausführliche Studie verdeutlicht die Probleme und zeigt Potenziale auf (siehe [Wit09]). Auf lange Sicht ist SCRUM als ein erfolgversprechendes Modell im Bereich der Software-Entwicklung zu sehen (auch in größeren Unternehmen, siehe [Bul07]) und bringt nach einer Eingewöhnungsphase viele Vorteile und führt im Endeffekt zu einer hohen Qualität ausgelieferter Produkte. Literatur [Bul07] Bulling, Rainer: Agile Softwareentwicklung mit SCRUM bei Siemens. 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 und Co lernen können, 2009. Eine Studie über den Erfolg von agilen Projekten XIII