Scrum - Agiles Projektmanagement

Aus Winfwiki

Wechseln zu: Navigation, Suche
Name des Autors / der Autoren: Sebastian Mohr, Sebastian Wolff
Titel der Arbeit: "Scrum - Agiles Projektmanagement"
Hochschule und Studienort: FOM Neuss


Inhaltsverzeichnis


1 Einführung

Die Welt steckt voller komplexer Prozesse, welche chaotisch agieren und demnach nicht im Voraus planbar sind. In vielen Fällen stört das jedoch nicht, da sich die Ungenauigkeiten in so kleinem Rahmen halten, dass sie das gewünschte Ergebnis dennoch liefern. "Autoräder laufen nicht exakt rund, Zylinder in Motoren bewegen sich nicht hundertprozentig gerade und Bremsen vibrieren."[1] Dennoch erfüllt ein Auto genau den Zweck, den es erfüllen soll: es fährt.

Auch der Prozess der Softwareentwicklung ist ein komplexer Vorgang, welcher unverhersehbare Ungenauigkeiten aufweist. Abweichend vom Beispiel zuvor führen diese Hürden häufig dazu, dass das gewünschte Ergebnis nicht erreicht wird.

Im klassischen Projektmanagement werden in der Projektplanung Gantt-Diagramme erstellt, Meilensteine definiert, ein Budget festgesetzt sowie Start- und Endzeitpunkt festgelegt. Es werden Pufferzeiten eingebaut, falls es Verzögerungen gibt[2]. Das klassische Projektmanagement wird den Anforderungen der Softwareentwicklung nicht gerecht, denn auch ein Softwareentwicklungsprozess läuft meist genauso unrund wie die Räder eines Autos. In der Praxis zeigt sich, dass in nahezu allen Projekten unvorhersehbare, chaotisch auftretende, zuvor in der Planung unberücksichtigte Schwierigkeiten auftreten.

Die Komplexität eines Softwareentwicklungsprojektes steigt mit Anzahl der Anforderungen, der eingesetzten Technologien und der Anzahl der Menschen, die involviert sind[3]. Im klassischen Projektmanagement werden die Anforderungen an eine Softwareapplikation mit dem Kunden oder der Fachabteilung abgesprochen und entsprechend umgesetzt. In der Praxis zeigt sich jedoch spätestens nach Fertigstellung der Software, dass die Anforderungen, welche zu Beginn des Projektes festgelegt wurden zwar zum größten Teil dem enspricht, was IT technisch umgesetzt worden ist, die Software dennoch nicht komplett fehlerfrei ist und der Kunde weitere Ideen zur Verbesserung oder Erweiterung der Software hat.

Scrum ist ein Lösungsansatz, um die Problematik unvorhersehbar eintretender Schwierigkeiten möglichst elegant in den Griff zu bekommen, sowie die Wünsche des Kunden besser zu berücksichtigen. Die Basis von Scrum bilden wiederum Beobachtungen aus der Praxis: Komplexe Vorgänge werden dezentral geplant und gesteuert. Konkrete Bespiele dazu, dass dezentrale Steuerung funktioniert, sind der Straßenverkehr[4] sowie die Marktwirtschaft. Im Straßenverkehr gibt es so viele Teilnehmer, dass eine zentrale Steuerung wegen der Komplexität nicht möglich ist. Dennnoch findet jeder Autofahrer durch Beachtung der Straßenverkehrsregeln früher oder später zu seinem gewünschten Ziel. Auch der Versuch der Vorausplanung einer komplexen Wirtschaft scheiterte nachweislich in der DDR, während die sich selbst regelnden Mechanismen der Marktwirtschaft, die auf Eigenverantwortung der Wirtschaftssubjekte beruht, durchaus funktioniert[5]. Der Grundgedanke von Scrum ist, von der zentralen Planung eines Softwareentwicklungsprojektes abzusehen und den Projektteams, welche für die Durchführung zuständig sind, mehr Eigenverantwortung und Handlungsspielraum zukommen zu lassen - auch in Scrum wird geplant, jedoch können siche die Teams ihre Zeit selbst einteilen und sich selbst organisieren.

Im Folgenden wird erläutert, wie Scrum im Detail funktioniert und welche "Rollen" es gibt. Anschließend wird auf die Praxistauglichkeit des Projektmanagementverfahrens mit möglichen Problemfeldern eingegangen und zuletzt noch ein Fazit gezogen. Es soll analysiert werden, ob Scrum als alternative Projektmanagementmethode bei Softwareentwicklungsprojekten zu empfehlen ist.

2 Entstehung von Scrum

Scrum entstand durch Zusammenarbeit der Firmen "Advanced Development Methods" und "VMARK Software". Beide Firmen waren der Ansicht, dass die klassischen Entwicklungsprozesse bei objektorientierter, komponentenbasierter Programmierung eher hinderlich als nützlich sind. 1995 wurden Wissenschaftler des Fachgebiets "Prozessautomation für biochemische Prozesse" damit beauftragt, bereits existierende Softwareentwicklungsmethoden zu analysieren. Sie stellten fest, dass die meisten Verfahren davon ausgehen, dass "Software in wiederholbaren, klar definierten und vorhersagbaren Prozessen entsteht."[6]

Da die Wissenschaftler der Meinung waren, dass Softwareentwicklung ein einmaliger, unvorhersehbarer Prozess ist, begannen sie eigene Methoden zu entwickeln. Hauptsächlich lassen sich die Entwicklungen auf Jeff Sutherland der Firma "VMARK Software", Ken Schwaber der Firma "Advanced Development Methods" und den Wissenschaftlern von "DuPont Experimental Station" zurückführen. Dabei griff das Team auf Ideen von Ikujiro Nonaka und Hirotaka Takeuchi zurück, die 1995 ein Buch mit dem Titel "The Knowledge Creating Company" veröffentlichten. Sie prägten den Begriff Scrum. Nach Vorstellung von Scrum auf der OOPSLA Konferenz wurde die Methode in einigen Unternehmen eingesetzt. 2001 erschien das erste Scrum Buch, geschrieben von den Entwicklern Ken Schwaber und Mike Beedle. Sie bildeten später die "Agile Alliance", welche Interessengruppen an Scrum vereint[7].

3 Bestandteile von Scrum

Das dritte Kapitel beschäftigt sich mit den einzelnen Bestandteilen des Scrum Prozesses und dessen Rollenverteilung.

3.1 Grundsätzliches

Bild: Abb. 1: ‎Scrum im Überblick
Bild: Abb. 1: ‎Scrum im Überblick

Abbildung 1 gibt einen Überblick über die zentralen Elemente von Scrum. Ein Scrum Projekt besteht aus mehreren kurzen Arbeitszyklen, auch Sprints genannt. Die Dauer eines Sprints beträgt maximal 30 Tage. Das Product Backlog ist die zentrale Sammelstelle für alle Anforderungen eines Scrumprojekts. Hier werden die Softwareanforderungen gepflegt, erweitert und priorisiert. Das Product Backlog ist ständig im Fluss. Am Anfang eines jeden Zyklus wird ein überschaubarer Anteil der Anforderungen in das Sprint Backlog überführt. Jeder Arbeitszyklus (Sprint) wandelt die Anforderungen des Sprint Backlogs in ein lauffähiges, getestetes und dokumentiertes Produktsegment um. Das an jeden Arbeitszyklus angrenzende Sprint Review Meeting dient zur Überprüfung und Genehmigung der Arbeitsergebnisse. Die Sprint Retrospektive findet im Anschluss an das Sprint Meeting statt. Hier wird die Zusammenarbeit des Teams reflektiert, wodurch gegebenenfalls Verbesserungsmaßnahmen abgeleitet werden können, um diese wiederum in die nächste Sprint Planungssitzung mit einzubeziehen.

3.2 Scrum Rollen

Im folgenden Verlauf werden die genannten Bestandteile eines Scrum Projekts detaillierter erfasst. Zudem werden die Organisationseinheiten eines Scrum Projekts umfassend beschrieben. Scrum kennt drei Rollen: Product Owner, Scrum Master und Team.

3.2.1 Product Owner

Der Product Owner nimmt maßgeblichen Einfluss auf das Arbeitsergebnis und ist für dieses wiederum verantwortlich. Er vertritt die fachliche Auftragsgeberseite (Seite der Stakeholder) durch eine enge Zusammenarbeit mit dem Kunden und Anwendern sowie anderen Interessensvertretern. Des Weiteren formuliert er die Kundenanforderungen im Product Backlog. Er ist für die kontinuierliche Bearbeitung des Product Backlog zuständig.

Zudem priorisiert er die Product Backlog Punkte so, dass frühzeitig die Möglichkeit für ein Release mit Kernfunktionalität besteht, um einen schnellen Return of Investigation (ROI) zu erhalten. Er definiert in Zusammenarbeit mit dem Team eine grobe Aufwandsschätzung für jede im Product Backlog definierte Anforderung. Aufgrund dieser Schätzungen kann das Team optimierte Entscheidungen treffen, welche Anforderungen sie in das Sprint Backlog aufnehmen können.

Der Product Owner arbeitet eng mit dem Team zusammen und steht immer für Rückfragen bereit. "Er hilft dem Team, die Kundenbedürfnisse und Anforderungen zu verstehen und diese in Produktinkremente umzusetzen, indem er es mit detaillierten Anforderungen versorgt und die entstandenen Arbeitsergebnisse überprüft. Der Product Owner schlägt also die Brücke zwischen den Endkunden und der Softwareentwicklung."[8] Er beteiligt sich diesbezüglich passiv an den Daily Scrums um sich zu informieren.

Der Product Owner übernimmt somit hauptsächlich Aufgaben zu Beginn und zum Ende eines Sprints. Er nimmt nicht aktiv bei den Daily Scrums teil und spielt nicht die Rolle des Chefs für das Team. Zudem stellt er während des Sprint-Prozesses keine neuen Anforderungen, indem er z.B. das Sprint Backlog mit Zusatzanforderungen bzw. Streichungen von Aufgaben verändert.

Durch den Product Owner werden die Anforderungen an das Projekt zentral verwaltet. Dies hat den Nutzen, dass das Scrum Team nicht von allen Seiten mit Anforderungswünschen attackiert wird.

Die Besetzung des Product Owners ist abhängig von der Projektart und Größe. Häufig handelt es sich um einen Produktmanager oder Marketingmitarbeiter. Da der Product Owner die meiste Verantwortung trägt, liegt es zwar nahe die Stelle mit einem Abteilungsleiter / Manager zu belegen, aber durch einen Vorgesetzten als Product Owner kann sich das Team in seinen Kompetenzen eingeschränkt fühlen. Dennoch muss der Product Owner bevollmächtigt sein, die notwendigen Entscheidungen zu treffen. Zusammengefasst muss der Product Owner die Kundenwünsche fachlich und kompetent vertreten und in das Projekt einbringen.

3.2.2 Team

Das Scrum Team steht im Mittelpunkt des Scrum Prozess, da es verantwortlich ist für die Umsetzung der Anforderungen in Produktfunktionalität. "Ein Scrum Team umfasst mindestens fünf und allerhöchstens acht Personen."[9] Sind mehrere Mitarbeiter notwendig um das Projektziel zu erreichen, werden mehrere voneinander unabhängige aber miteinander kommunizierende Teams gebildet.

"Das Scrum-Team ist interdisziplinär besetzt: Alle Rollen, die zur Umsetzung der Projekt- und Sprint-Ziele benötigt werden, müssen im Team vertreten sein. Beispiele hierfür sind Architekt, Entwickler, Tester, Dokumentationsexperte, User Interface Designer, Datenbankexperte, Konfigurationsmanager."[10] Trotz des jeweiligen Expertenwissens muss jeder Mitwirkende stark teamfähig arbeiten können.

Bild: Abb. 2: Traditionelles Management
Bild: Abb. 2: Traditionelles Management
Bild: Abb. 3: Das Zusammenspiel von Product Owner und Team
Bild: Abb. 3: Das Zusammenspiel von Product Owner und Team

Ein wichtiger Punkt ist die Tatsache, dass das Team nicht von einer höheren Instanz organisiert wird, sondern sich selbst verwaltet. Hierzu gehört z.B. die Entscheidung, welche Anforderungen während eines Sprints umgesetzt werden und wie dies bewerkstelligt wird (Self-Organistaion). „Ein bevollmächtigtes Team muss auch in schwierigen Situationen in der Lage sein, nein zu vielen Anforderungen zu sagen.“[11] Von einem anderen Blickwinkel aus betrachtet ist es auch wichtig, dass das Management das nötige Vertrauen in die Fähigkeit des Team aufbringt, damit dieses autonom agieren kann. Abbildung 2 und 3 zeigen die Unterschiede zwischen dem traditionellen Management und dem Zusammenspiel von Product Owner und Team im Scrum-Prozess. Wird Scrum in ein Unternehmen neu eingeführt, ist zu Beginn für viele Mitarbeiter die autonome, teambasierende Arbeitsweise ungewohnt und es dauert meist einige Sprints bis sich die Denkweise der bisher traditionellen Softwareentwicklung ändert.

Zu Beginn eines Sprints im Sprint Planning Meeting erklärt sich das Scrum Team bereit, eine bestimmte Menge von Anforderungen des Produkt Backlogs im darauffolgenden Sprint zu bearbeiten. In den täglichen Daily Scrum Meetings bringen sich die Teammitglieder durch kurze Statusberichte gegenseitig auf den neuesten Stand. „Damit die Teammitglieder effektiv zusammenarbeiten können, ist es notwendig, dass sich das Team auf gemeinsame Normen einigt. Diese beinhalten beispielsweise Zeit und Ort der Daily Scrum, Architekturprinzipien, Kodierrichtlinien, eingesetzte Werkzeuge oder das Stummstellen von Mobiltelefonen während Besprechungen.“[12]


Ein optimierter Arbeitsplatz kann zu produktiveren Arbeiten führen. Voraussetzung hierfür sind z.B. Arbeitsplätze in unmittelbarer Nähe (Teamraum oder separater Teambereich). „Die räumliche Nähe der Teammitglieder ermöglicht eine enge und spontane Kommunikation, erhöht die Produktivität und begünstigt eine positive Teamdynamik.“[13]

3.2.3 Scrum Master

Der Scrum Master sorgt dafür, dass die Regeln des Scrum-Prozesses im Team und Unternehmen eingehalten werden. In seiner Verantwortung liegt es, dass der Prozess zielgerichtet verläuft. Er ist sowohl der Vermittler zwischen Team und dem Product Owner sowie Unterstützer und sorgt gleichzeitig auch für den Informationsfluss zwischen ihnen. Er unterstützt das Team bei der Durchführung der Sprints und moderiert die Scrum Meetings. Jedes Team hat einen Scrum Master, der eng mit den Teammitgliedern zusammenarbeitet und sie vor externen Einflüssen schützt. „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.“[14] Zudem hilft er dem Product Owner bei der richtigen Formulierung und Priorisierung der Anforderungen in dem Product Backlog.

„Der Scrum Master fungiert als Servant-Leader: als Führungsfigur deren Aufgabe es ist, dem Team zu dienen. Als Scrum Master verfügen Sie zwar über Einfluss, aber über keine Autorität bezüglich der Arbeitsorganisation im Team.“[15]

Der Scrum Master sollte über folgende Fähigkeiten verfügen, um den Scrum- Prozess hilfreich zu unterstützen:

  • Gute Moderationsfähigkeiten in Teambesprechungen
  • Teambildungsprozesse
  • Konfliktmanagement
  • Kollaborative Entscheidungsverfahren
  • Erfahrung in der Softwareprogrammierung

Bei der Besetzung der Scrum Master- Rolle ist es wichtig darauf zu achten, dass dieser nicht gleichzeitig eine Führungsverantwortung, wie z.B. eine Personalverantwortung, für die Scrum-Teammitglieder hat. Dies könnte dazu führen, dass nach dem traditionellen Projektmanagement (siehe Abbildung 2) gearbeitet wird, was nicht im Sinne des Scrum-Prozesses wäre, wo nämlich die Eigenorganisation des Teams im Vordergrund steht. Weiterhin ist darauf zu achten, dass der Scrum Master sich sehr gut mit den Scrum-Prozess auskennen muss, da er ihn überwachen und "coachen" soll.

Zusammengefasst sind die Aufgaben des Scrum Masters die Etablierung von Scrum, die Unterstützung des Teams, sowie die Sicherstellung der Zusammenarbeit von Product Owner und Scrum Team wie auch die Beseitigung von Hindernissen. Er übernimmt nicht traditionell leitende Aufgaben eines Projektleiters.

„Der Scrum Master sollte bemüht sein, sich schnellstmöglich überflüssig zu machen.“[16]

3.3 Projektplanung

Bild: Abb. 4: Der Planungsprozess im Überblick
Bild: Abb. 4: Der Planungsprozess im Überblick

Die Projektplanung in Scrum unterliegt einer festgelegten Vorgehensweise: Zunächst ist es sinnvoll ein Produktkonzept (auch Vision genannt) zu erstellen. Dieses soll die wesentlichen Leistungsmerkmale und Zielgrößen des Produkts veranschaulichen und eine Grundlage für die weitere Ausarbeitung der Anforderungen für das Product Backlog bilden. Dies verhindert frühzeitig eine Überflutung des Product Backlogs mit weniger zielgerichteten Anforderungen.

3.3.1 Product Backlog

"Ein Product Backlog ist nichts anderes als eine Einkaufsliste des Product Owners für sein Team."[17] Es ist das zentrale Mittel im Scrum Prozess zum Erfassen und Managen von Anforderungen. Jedes Scrum Projekt hat sein eigenes Product Backlog, das alle Funktionalitäten des Produktes festlegt.Wichtig ist, dass der Detaillierungsgrad der Anforderungen zu Beginn relativ gering ist, was bedeutet, dass lediglich eine grobe Skizzierung der Anforderungen im zu Beginn Product Backlog vorhanden ist. Auch stehen im Produkt Backlog keine Anforderungen im klassischem Sinne wie z.B.:"Auf der Produkt-Katalog-Hauptseite gibt es ein Display für den Preis". Es handelt sich vielmehr um eine Liste von notwendigen Merkmalen: "Als Buchkäufer kann ich den Preis des Buches einfach erkennen, so dass ich entscheiden kann, ob ich das Buch kaufe."[17]

Ein weiteres wichtiges Merkmal des Product Backlogs ist die ständige Bearbeitung der Anforderungen während des Projektzeitraums. Das bedeutet, dass das Product Backlog ständig im Fluss und somit nie vollständig ist. Man bezeichnet es auch als lebendes Dokument[18].Erst am Ende des Projekts stehen alle umgesetzten Anforderungen in präziser und detaillierter Form im Product Backlog[18]. Die niedergeschriebenen Anforderungen im Product Backlog werden als Product Backlog Items bezeichnet. Sie bestimmen einen "Teil einer Applikation, das vom Scrum- Entwicklerteam geliefert werden muss."[19]´So liefert es dem Kunden immer einen gewissen Wert. In diesem Sinne kann ein Item kein technisches Zwischenprodukt, wie z.B. die Etablierung einer Testumgebung beschreiben, da dies keinen Wert für den Kunden darstellt. Beispiele für Product Backlog Items sind:

  • Als Anwender kann ich den Status meiner Flugbuchung einsehen
  • Kreditkartenrechnung
  • Druckvorschau[20]
Bild: Abb. 5: Product Backlog in Form eines Spreadsheets
Bild: Abb. 5: Product Backlog in Form eines Spreadsheets

In der Abbildung 4 erkennt man zwischen der Vision bzw. Produktidee und der Beschreibung der Anforderungen in das Product Backlog den Zwischenschritt "Schreibe Stories": Dies repräsentiert die Methode, Anforderungen als Stories in das Product Backlog einzupflegen. Dabei hat Mike Cohn folgende Formulierung für User Stories eingeführt:

Als Anwender, mit [der Rolle X]
benötige ich [eine Funktionalität],
damit ich [den Nutzen Y] bekomme.[21]

Hier ein Beispiel: "Als Besucher des Portals, benötige ich die Möglichkeit, mich zu identifizieren, damit ich meine Kundendaten abrufen kann."[22] Diese Art der Formulierung hat den Sinn Anforderungen schnell, einfach und einheitlich strukturiert in das Product Backlog einzutragen.

Im nächsten Schritt müssen die Items in eine Reihenfolge gebracht werden. Diese Reihenfolge wird durch eine Priorisierung nach Nutzen, Risiko und Kosten vom Product Owner und dessen Team vor dem Projektbeginn festgesetzt. Für die identifizierten Risikomöglichkeiten müssen im Vorfeld Gegenmaßnahmen aufgeführt und als neue Einträge ins Produkt Backlog eingetragen werden.

Die Form des Product Backlogs kann variieren. Mögliche Varianten wären Product Backlogs in Form von Mind Maps, Spreadsheets (Abbildung 5) oder Story Cards (große Karteikarten). Letzteres hat den Vorteil das Veränderungen schnell zu korrigieren sind, z.B. durch Zerreisen oder neu schreiben der Story Cards[23].

3.3.2 Releaseplan

Nachdem der Product Backlog erstellt und nach Nutzen, Risiko und Kosten priorisiert wurde, wird nun im Anschluss der Releaseplan erstellt. Der Releaseplan gibt im wesentlichen die Anzahl der benötigten Sprints vor und übernimmt die im Product Backlog erstellte Reihenfolge der Umsetzung der Anforderungen. Er gibt zudem eine Einschätzung, wie schnell das Team die gegebene Funktionalität liefern kann. Um diese Informationen im Releaseplan zu erarbeiten, braucht man die folgenden zwei Informationen:

  • Gesamtaufwand im Produkt Backlog
  • Entwicklungsgeschwindigkeit

Um den Gesamtaufwand zu bestimmen, muss zunächst für jedes Item eine Aufwandsschätzung stattfinden, die vom ausführenden Team durchgeführt wird. Die Aufwandsschätzung findet meist regelmäßig vor jedem Sprint statt, da sich das Product Backlog ständig verändert.

Ist der Aufwand im Product Backlog ermittelt, muss nun die Entwicklungsgeschwindigkeit bestimmt werden. Hierzu wird zunächst die Länge der Sprints festgesetzt, die nur in Ausnahmefällen (z.B. Urlaubszeiten) verändert werden darf. "Sprints sind traditionell 30 Tage lang."[24]Nun gibt es drei verschiedene Optionen zur Ermittlung der Entwicklungsgeschwindigkeit:

  • Die Ermittlung der Geschwindigkeit erfolgt über empirische Messungen von schon ausgeführten Sprints. Diese Messungen greifen zwar auf verlässliche Daten zurück, sind aber nicht in den ersten Sprints anwendbar.
  • Die zweite Möglichkeit wäre die Messung durch historische Daten, wie z.B. alte Softwareprojekte, die das Team durchgeführt hat. Dies kann natürlich zu Falschinterpretationen bezüglich des neuen Releaseplans führen.
    Bild: Abb. 6: Beispiel für einen Releaseplan
    Bild: Abb. 6: Beispiel für einen Releaseplan
  • Die letzte Option wäre eine Simulierung von Teamverfügbarkeit, Leistungsvermögen und einer Aufwandsschätzung sowie die Bestimmung der Wahrscheinlichkeit einer Abnahme der Ergebnisse durch den Product Owner. All dies ist sehr zeitaufwändig und birgt ein hohes Maß an Unsicherheit. Wenn aber keine vorherigen Daten zur Verfügung stehen, ist dies meist die einzige Möglichkeit um die Entwicklungsgeschwindigkeit bestimmen zu können.

Nach der Ermittlung des Gesamtaufwandes und der Entwicklungsgeschwindigkeit können nun Zeitpunkte im Releaseplan festgelegt werden, wie z.B. wann eine Software freigegeben wird.

Abbildung 7 zeigt ein Beispiel für einen Releaseplan.

3.3.3 Sprint Backlog

Das Sprint Backlog dient zur weiteren Differenzierung der Anforderungen aus dem Product Backlog. "Das Sprint Backlog weist die Arbeit oder die Aufgaben aus, die das Team aus den Product Backlog Elementen für diesen Sprint ausgewählt hat."[25] Zu beachten gilt hierbei, dass nur das Team das Sprint Backlog erstellt und ändert.

3.4 Sprint

"Das Ziel dieser Phase [des Sprints] ist die Lieferung von Produktteilen, nach jedem Sprint und nach einer gewissen Anzahl von Sprints sollte soviel Produkt entstanden sein, dass wir es an unsere Kunden ausliefern können."[26]

Ein Sprint dauert in der Regel 30 Tage und kann als eine Art Miniprojekt angesehen werden[27]. Am Ende eines Sprints soll eine dokumentierte, getestete, lauffähige Software als Teil des gesamten zu entwickelnden Softwareprodukts entwickelt worden sein[28][29]. Dabei sollen die Mitarbeiter nicht überbeansprucht werden. "Vielmehr sollte das Team frisch und voller Energie in den nächsten Sprint starten."[30]

Der Sprint ist vergleichbar mit dem japanischen Sashimi.Sashimi ist eine japanische Delikatesse, bestehend aus rohem Fisch, welcher in dünne Scheiben zerteilt wird. Jede dieser Scheiben hat ihren eigenen, vollständigen Geschmack, genau wie jeder Sprint einen vollständigen Programmabschnitt liefert[31].

Bild: Abb. 7: Der Sprint-Ablauf
Bild: Abb. 7: Der Sprint-Ablauf

Die Abbildung 7 zeigt grafisch den Verlauf eines Sprints auf. Vor Beginn eines Sprints muss der Product Backlog bereits erstellt worden sein. Jeder neue Sprint beginnt mit der Sprintplanung bzw. dem Sprint Planning Meeting, welches dazu dient den nächsten Sprint vorauszuplanen. Anschließend beginnt das Team mit der Umsetzung der Aktivitäten und führt Daily Scrum Meetings durch, um den Fortschritt der anderen Teammitglieder zu erfahren und die Tätigkeiten zu synchronisieren[32] .

3.4.1 Sprint Planning Meeting

Im Sprint Plannung Meeting werden die zu erledigenden Aufgaben für den direkt im Anschluss folgenden Sprint festgelegt. Die Gesamtdauer eines Sprint Plannung Meetings beträgt in der Regel 8 Stunden[33]. "In den ersten vier Stunden präsentiert der Product Owner dem Team die Punkte des Product Backlogs mit höchster Priorität."[34] Noch innerhalb der ersten vier Stunden soll das Team selbständig entscheiden, welche Teile des Product Backlogs für den nächsten Sprint ausgewählt werden. Das Team geht diesbezüglich ein Commitment[35] mit dem Product Owner ein. Es verpflichtet sich die bevorstehenden Aufgaben bestmöglich zu erfüllen. Die zweiten vier Stunden des Meetings werden dazu verwendet, den bevorstehenden Sprint möglichst detailliert vorauszuplanen. Dazu wird vom Team der Sprint Backlog erstellt, in welchem die aus dem Product Backlog ausgewählten Punkte in möglichst konkrete Aufgaben zerlegt werden[33].

3.4.2 Daily Scrum Meeting

Das Daily Scrum Meeting wird täglich innerhalb der Teams durchgeführt. Der Scrum Master wohnt den Meetings zwar bei, hält sich jedoch im Hintergrund. Das Meeting ist zeitlich auf 15 Minuten beschränkt[36]. Jeder der Teilnehmer muss reihum folgende drei Fragen beantworten:

  • Was haben Sie in diesem Projekt seit dem letzten Daily Scrum-Meeting durchgeführt?
  • Was planen Sie bis zum nächsten Daily Scrum Meeting?
  • Welche Hindernisse sind bei der Umsetzung für diesen Sprint und das gesamte Projekt aufgetreten?[37]

"Die drei Fragen im Daily Scrum sind sehr effektiv, um den tatsächlichen aktuellen Status zu erheben. Sie unterscheiden sich im Grunde nicht wesentlich von den Fragen, die man in einem traditionellen Meeting erwarten würde."[38] Aus der Zeitbeschränkung und den drei Fragen, die jedes Teammitglied zu beantworten hat, wird ersichtlich, dass es innerhalb des Daily Scrums keine fachlichen Diskussionen geben darf. Diese sollen nach dem Meeting zwischen involvierten Personen stattfinden. Der Scrum Master ist dafür verantwortlich ungeklärte Fragen zu notieren und anschließend Meetings mit den beteiligten Personen zu organisieren[36].

3.4.3 Review Meeting

Das Review Meeting, welches nach jedem Sprint durchgeführt wird, dient zur Überprüfung der Ergebnisse. Es wird geklärt, ob das Team die Ziele des Sprints erreicht hat. Zu Beginn des Meetings erläutert der Scrum Master gemeinsam mit dem Product Owner, welche Aufgaben innerhalb des Sprints zu erfüllen waren. Die Teilnehmerliste kann im Review Meeting um alle Personen erweitert werden, die ein Interesse an dem Projekt haben. Mögliche zusätzlich einzuladene Teilnehmer könnten sein:

  • Management
  • Customer
  • Anwender (bzw. die Fachabteilung)
  • Externe und interne Lieferanten

Da bereits fertiggestellter, einsatzbereiter Programmcode von Team vorgestellt wird, bedarf es seitens des Teams keiner intensiven Vorbereitung. Die Gesamtdauer des Meetings beträgt ca. 90 Minuten. Alle Probleme und neue Ideen sollten in ein weiteres Meeting verlegt werden, im Review Meeting werden lediglich Ergebnisse präsentiert. Der Product Owner kann sich direkt von den Teammitgliedern persönlich die Ergebnisse präsentieren lassen[39].

3.4.4 Sprint Retrospective Meeting

Das Sprint Retrospective Meeting, welches unmittelbar nach dem Sprint Review Meeting und dem nächsten Sprint Planning Meeting stattfindet, wird vom Scrum Master geleitet. In diesem Meeting hat er die Möglichkeit das Team "zu verbessern, um diesen [den Scrum-Prozessrahmen] effizienter und angenehmer für den nächsten Sprint zu gestalten."[40] Die Zielsetzung ist eine "Steigerung der Produktivität, der Leistungsfähigkeit des Teams und der Softwarequalität."[41] An dem Meeting nehmen der Product Owner, der Scrum Master sowie das Team teil. Falls es sinnvoll erscheint, können auch weitere Teilnehmer, wie z.B. der Geschäftsführer hinzugezogen werden. Alle Beteiligten sollen offen und ehrlich diskutieren, was im letzten Sprit positiv oder negativ verlaufen ist[42].

3.4.5 Verfolgen und Optimieren des Sprint-Fortschritts

Im Gegensatz zum klassischen Projektmanagement[2] gibt es in Scrum keine wöchentlichen Projektstatusberichte. Fortschritte des Projektes können lediglich durch Teilnahme an den Daily Scrum Meetings oder Sprint Review Meetings beobachtet werden. Ein Werkzeug für den Scrum Master, um den Fortschritt innerhalb eines Sprints zu verfolgen, ist der Sprint-Burndown-Bericht.
Bild: Abb. 8: Burn Down Report
Bild: Abb. 8: Burn Down Report
In Abbildung 8 ist der ideale Burndown-Bericht dargestellt, welcher in der Realität selten in dieser Form anzutreffen ist. Die x-Achse stellt die Anzahl der Arbeitstage dar, während auf der y-Achse die noch offenen Aktivitäten kummuliert werden. Bei erfolgreichem Abschluss von Aktivitäten, wird der Balken am nächsten Arbeitstag kleiner. In der Regel ist der Sprint-Forschritt auf Grund unvorhergesehenen Hindernissen zu Beginn eines Sprints langsamer[43].

Das Team muss den Bericht täglich aktualisieren. Der Bericht nutzt auch dem Team selbst. Schließlich kann es selbst dafür sorgen, dass es bei Abweichungen vom idealen Plan gegensteuert. Ein weiteres Werkzeug ist der Hindernisbericht. In ihm werden alle Hindernisse festgehalten, die es innerhalb des aktuellen Sprints gab. Vorzugsweise kann ein Flipchart dafür verwendet werden, der laufend ergänzt wird. Durch noch existierende oder schon überwundene Hinternisse kann das Team und der Scrum Master sehen, ob der Sprint erfolgreich abgeschlossen werden kann. Der Hindernisbericht kann im Sprint Review Meeting mit dem Sprint-Burndown-Bericht verglichen werden, um zu analysieren, inwiefern die Hindernisse zu Verzögerungen führten[44].

Durch Berücksichtigung einiger Regeln kann der Sprint-Fortschritt optimiert werden. Es ist empfehlenswert kontinuierliche Reviews vorzunehmen. Dass zum Sprintende ein Review Meeting vorgeschrieben ist bedeutet keineswegs, dass es zwischendurch keine Reviews geben darf. So kann der Product Owner vor unangenehmen Überraschungen zum Sprintende bewahrt werden. Unfertige Arbeitsergebnisse sind zu vermeiden. Sie führen zur Verfälschung des Projektfortschritts und stiften dem Product Owner keinen Nutzen. Dies gilt insbesondere für das Sprintende. Sollten dennoch unfertige Arbeitsergebnisse vorliegen, so müssen sie möglichst zügig innerhalb des Folgesprints abgeschlossen werden, da sonst auch der Folgesprint wieder zu unfertigen Arbeitsergebnissen führen kann. Weiterhin sollte dafür gesorgt werden, dass in einem Sprint möglichst kleine Arbeitspakete sequentiell abgearbeitet werden, statt große Arbeitspakete parallel zu bearbeiten. Je kleiner die Arbeitspakete sind, desto unwahrscheinlicher sind unfertige Arbeitsergebnisse zum Sprintende[45].

Überbelastungen einzelner Teammitglieder müssen vermieden werden, da sie sich kontraproduktiv auf das Gesamtergebnis auswirken. Es soll nicht Ziel sein, dass jeder Mitarbeiter zu 120% ausgelastet ist. Stattdessen muss das Ergebnis im Vordergrund stehen. Es kann durchaus vorkommen, dass einige Mitarbeiter mehr Last tragen müssen als andere. Der Versuch alle Mitarbeiter voll auszulasten führt jedoch meist zu unfertigen Arbeitsergebnissen. Sollte es zu Überbelastungen kommen, so können diese durch die Theorie der Sachzwänge[46] behoben werden. Dazu wird wie folgt vorgegangen[47]:

  1. Es wird analysiert, welcher Mitarbeiter überbelastet ist
  2. Der überbelastete Mitarbeiter muss optimal eingesetzt werden. Dieser sollte von möglichst vielen Nebentätigkeiten befreit werden
  3. Ist dies nicht möglich, müssen sich die anderen Teammitglieder anpassen. Sollten beispielsweise nicht genug Tester vorhanden sein, darf nicht zu viel Software entwickelt werden, was zu partiellen Ergebnissen führen würde
  4. Im nächsten Sprint muss die Überbelastung vermieden werden. Z.B. durch den Einsatz eines weiteren Testers oder durch Umstellung der Arbeitsweise
  5. Mit weiteren Überbelastungen wird genauso verfahren

4 Einsatzbereiche von Scrum

Das folgende Kapitel liefert einen Überblick über die Einsatzgebiete von Scrum. Man unterscheidet die Anwendung von Scrum in kleinen, großen, verteilten und bestehenden Projekten.

4.1 Einsatz in neuen oder bestehenden Projekten

Wird Scrum in ein Unternehmen eingeführt, können sich die Einsatzbereiche zunächst auf neue aber auch auf bestehende Projekte beziehen.

Wird ein Projekt zu Beginn mit der Scrum Methode ausgeführt, ist es vor dem ersten Sprint wichtig, dass zunächst ein Product Backlog vorhanden ist. Der erste Sprint setzt sich meistens mit der Aufsetzung einer Entwicklungsumgebung auseinander. Das Projekt Team sollte zudem auch eine erste Schlüsselfunktionalität des Produktes implementieren, "damit der Kunde merkt, dass es nun ernst gilt, und er sich im Projekt engagieren muss, damit seine Anforderungen an das Produkt umgesetzt werden."[48]

Wird Scrum in einem bestehenden Projekt eingeführt, da dieses z.B. "seit langer Zeit keine funktionierenden Programmteile geliefert"[49] hat, ist es zunächst wichtig die alten Projektmanagementstrukturen zu lösen und mit den Scrum Methoden zu ersetzen. Dies führt meist dazu, dass auch nach der Einführung von Scrum zunächst keine Verbesserungen bzw. Projektergebnisse auftreten, da es an gewisser Einarbeitungszeit in den neuen Prozess bedarf. Trotzdem ist es sinnvoll, "in einem ersten Sprint irgendeine Funktionalität des Produkts zu implementieren, welche in 30 Tagen geschaffen werden kann. So wird bewiesen, dass das Team Ergebnisse liefern kann."[48] Dies ist wichtig, damit der Kunde, sowie das Team wieder Vertrauen in das Projekt entwickeln können. Im weiteren Verlauf können dann sukzessiv die Entwicklungspraktiken an die Vorgehensweise von Scrum angepasst werden.

4.2 Scrum in großen und verteilten Projekten

Es wurde bereits herausgestellt, dass ein typisches Scrum-Projekt aus einem Projektteam von meist fünf bis acht Mitarbeitern besteht. Genügt die Personenanzahl nicht zur Erreichung eines Projektziels innerhalb einer festgesetzen Zeitspanne, wenn es sich beispielsweise um ein großeres Softwareprojekt handelt, werden mehrere Scrum Teams gleichzeitig eingesetzt. Bei größeren Projekten sollte das Management zuvor abwägen, ob mehrere Scrum Teams notwendig sind, oder ob der Projektzeitraum erweitert werden kann. Große Projekte, viele Mitarbeiter im Team, große Teams, verteilt auf viele Räume, all das verlängert das Projekt und verringert die Produktivität. Es gibt auch Fälle, dass Applikationen, an denen große Teams gescheitert sind, später von kleinen Teams in kürzester Zeit problemlos entwickelt werden. Ist es dennoch notwendig mehrere Teams zu bilden, müssen bestimmte Praktiken des Scrum Prozesses variiert werden:

Zu Beginn wird zunächst ein einziges Team von erfahrenen Mitarbeitern gegründet, welche schon Erfahrungen auf dem Gebiet der Softwareentwicklung gesammelt haben, beziehungsweise schon einmal in einem Scrum Prozess mitgewirkt haben. Ist eine spätere verteilte Teamorganisation, z.B. auf zwei Standorte von Nöten, ist es praktikabel Mitarbeiter dieser Standorte von Anfang an in das Start-Team miteinzubeziehen. "So lernen sich die Repräsentanten der verschiedenen Standorte nicht nur kennen, sondern erarbeiten gemeinsam auch die Grundlagen für die Verteilung."[50] Die erste Phase, beziehungsweise der erste Sprint beschäftigt sich bei großen und/oder verteilten Projekten mit organisatorischen Projektpunkten. Hier werden die Voraussetzungen für eine spätere Teamteilung oder Vergrößerung geschaffen. Da ein schneller Return of Investment (ROI) von der gegenseitigen Kommunikation und Zusammenarbeit der Teammitglieder abhängt, ist es wichtig bei verteilten und großen Teams zu Projektbeginn die wesentlichen Kommunikationsmittel bereitzustellen. Neben der Verwendung einer gegeigneten Kommunikationsplattform, muss ein Architekturgrundgerüst mit einer Test- und Entwicklungsumgebung eingerichtet werden. Zudem sollte das erste Team im ersten Sprint Normen und Standarts für Kodier- und Domumentationsrichtlinien festlegen[50].

Sind die Grundlagen für eine Teamvergrößerung beziehungsweise Verteilung gegeben, kann das Scrum Team entscheiden, ob und "wann es seine Produktivität durch weitere Teammitglieder erhöhen will."[51] Diese Art von Wachstum nennt man Organisches Wachstum und wurde von Boris Glober treffend anhand einer biologischen Zelle erläutert: "Das organische Wachstum eines Teams ist vergleichbar mit dem Wachstum und der Ausbreitung einer biologischen Zelle. Die Zelle wächst und wächst und zu einem bestimmten Zeitpunkt teilt sie sich in zwei genetisch identische Zellen. Zuvor hat sie alle Informationen, ihre Gene, verdoppelt, so dass es zu keinem Informationsverlust kommen kann."[52] Glober stellt diese Form des langsamen Wachstums als sehr effektiv dar. Da das Projekt nicht mit mehreren Teams gestartet wird, können sich die Mitarbeiter zunächst besser mit dem Projektziel identifizieren und nehmen wichtige erarbeitete Kenntnisse bei einer späteren Teamtrennung in das eventuelle neue Team mit.

Bei einer Teamtrennung auf mehrere Standorte (z.B Zweigniederlassungen der Unternehmung) sollte jedes Team über einen Scrum Master und Product Owner verfügen. "Dies stellt eine enge Kommunikation zwischen Scrum Master und Team sowie zwischen Product Owner und Team innerhalb eines jeden Standorts sicher."[53]

Zu Beginn dieses Kapitels wurde bereits ein Nachteil der Anwendung von Scrum mit größeren bzw. verteilten Teams herausgestellt. Dies betrifft die Verringerung der Entwicklungsgeschwindigkeit des Projekts durch die ständige Einarbeitung neuer Teammitglieder. Zudem kommt es durch mangelnde Identifizierung zu Demotivation, z.B. durch eine nicht existierende persönliche Zusammenarbeit mit dem Kunden. Ist ein Projekt auf mehrere Standorte unterschiedlicher Zeitzonen oder Länder verteilt, kann es weiterhin zu Kommunikationsstörungen kommen. Gerade um diese Probleme möglichst gering zu halten, ist es wichtig in den ersten Sprints organisatorische Gesichtspunkte abzuklären. Auch sollten die Vergrößerungsschritte nicht direkt hintereinander durchgeführt werden, da sichergestellt werden muss, dass das Projekt mit den Änderungen umzugehen lernt[54].

4.2.1 Optionen für die Projektorganisation

Bei großen und verteilten Scrum Projekten reicht meist ein Product Owner nicht aus. Hat ein Projekt eine gewisse Größe, sodass mehrere Teams benötigt werden, gibt es oft zu jedem Team auch einen verantwortlichen Product Owner. Um eine einheitliche Definition der Anforderungen bei mehreren Product Ownern zu garantieren ist eine gegenseitige Kommunikation wichtig. Aus diesem Grund werden alle Product Owner unter der Leitung eines Chief Product Owners in ein Product Owner Team zusammengeführt. Der Chief Product Owner "bestimmt die Leistungsmerkmale der Softwareversion, sowie Freigabezeitpunkt und -umfang und trägt Verantwortung für das Erreichen der ROI-Ziele."[55] Von Vorteil wäre es, wenn sich im Product Owner Team auch Repräsentanten der Bereiche Marketing, Vertrieb und Service wiederfinden würden, sodass Anforderungsdefinitionen und eine erfolgreiche Markteinführung optimiert werden. Ein Scrum Master sollte einen direkten Bezug zu dem Product Owner Team haben, um gegebenenfalls Hilfestellung in Bezug auf die Organisation leisten zu können.

Roman Pichler unterscheidet in seinem Buch "Scrum - Agiles Projektmanagement erfolgreich einsetzen" zwei spezifische Projektorganisationsformen: Komponententeams und Featureteams. Aus Eingrenzungsgründen werden diese Organisationsformen nicht weiter erläutert.

5 Scrum im Vergleich

In diesem Kapitel wird Scrum mit anderen Softwareengineering Modellen verglichen. Da ein Vergleich zu allen Modellen den Rahmen dieser Fallstudie überschreiten würde, wird nur das bekannteste bzw. meist praktizierteste Softwareengineering Modell zum Vergleich herangezogen. Zudem wird die agile Softwareentwicklungmethode Extreme Programming (XP) erläutert, die den Projektmanagementansatz von Scrum ergänzt.

5.1 Wasserfallmodell

Das Wasserfallmodell beschreibt die Vorgehensweise bei der strukturierten, prozesshaften Entwicklung von Individualsoftware.

5.1.1 Funktion

Die Software wird im Rahmen des Wasserfallmodells stufenweise entwickelt, wobei chronologisch jede Phase abgeschlossen sein muss,

Bild: Abb. 9: Das Wasserfallmodell
Bild: Abb. 9: Das Wasserfallmodell

bevor mit der nächsten begonnen werden kann. Die einzelnden Stufen beschreiben nacheinander folgende Prozesse:

  1. Projektanalyse, bei der ein Projektantrag und ein Grobplan erstellt wird
  2. Spezifikation,welche das Erstellen eines Pflichtenheftes umfasst
  3. Grobentwurf, welcher die Modellierung der Systemarchitektur beinhaltet
  4. Feinentwurf, welcher den Grobentwurf verfeinert
  5. Implemetierung der Software mit gleichzeitiger Dokumentierung
  6. Integration des Endproduktes
  7. Installation der betriebsfähigen Software
  8. Anschließende Wartung der Anwendungssoftware

"Es ist ein stark top-down-orientiertes und dokumentengetriebenes Modell."[56] Im Projektverlauf hat man die Möglichkeit Stufen zu wiederholen, oder auf vorherige zurückzuspringen. Dies ist meist dann notwendig, wenn z.B. Planungslücken vorliegen und diese ausgebessert werden müssen

5.1.2 Wasserfallmodell im Vergleich zu Scrum

"Wesentliche Nachteile [des Wasserfallmodells] sind jedoch die sehr starre, (wenig flexible) sequentielle Durchführung sowie fehlende Bereiche wie z.B. Berücksichtigung von Projektmanagement."[56] Genau dieser Bereich wird durch Scrum mit Hilfe der vordefinierten Rollen weiter spezifiziert. Durch das strenge Abarbeiten der Projektstufen im Wasserfallmodell, kann es durch Ungenauigkeiten in den vorher definierten Anforderungen dazu kommen, dass ganze Prozesse bis zur Analyse zurückgerollt und wieder neu durchlaufen werden müssen. Scrum verzichtet zu Beginn bewusst darauf, "jedes Requirement im Detail zu spezifizieren und mit den Stakeholdern abzustimmen."[57] "Der Vorteil von SCRUM liegt in der Flexibilität, dass das Team direkt auf Analyseergebnisse und neue Erkenntnisse reagieren kann."[57]

5.2 Extreme Programming

Im folgenen Verlauf wird die agile Softwareentwicklungmethode Extreme Programming erläutert.

5.2.1 Funktion

"XP ist ein Ansatz der Softwareentwicklung, der verschiedene, bereits etablierte Verfahren der Softwareentwicklung neu miteinander kombiniert."[58] XP basiert auf den vier Werten: Kommunikation, Einfachheit, Feedback und Mut, sowie auf mehreren Grundsätzen, wie z.B., dass jedes Problem als einfach lösbar áufgefasst werden soll. Diese agile Methode stellt das Lösen einer Programmieraufgabe in den Vordergrund der Softwareentwicklung.

5.2.2 XP und Scrum

Scrum beschäftigt sich ausschließlich mit dem Management der Entwicklung und nicht mit der Entwicklung selbst. Diese Lücken kann XP mit seinen Entwicklungstechniken füllen. Ken Schwaber, der Erfinder von Scrum, befürwortet einen gemeinsamen Einsatz von Scrum und XP: "Ken Schwaber: ... Scrum managt den Prozess, XP liefert die Techniken, wie in einem solchen Prozess entwickelt wird. Scrum und XP sind kompatibel und werden sehr oft zusammen eingesetzt. Ich starte oft mit Scrum, da ich es in zwei Tagen implementieren kann. Danach nutze ich die XP Praktiken um die Qualität der Produkte zu verbessern ..."[59]

Durch eine Reihe von Gemeinsamkeiten ist eine gemeinsame Anwendung im Softwareentwicklungsbereich gegeben:

  1. Entwicklung in Iterationen
  2. Inkrementelle Entwicklung des Produkts
  3. Konzentration auf die Kundenwünsche
  4. Selbstorganisation des eigentlichen Entwicklungsprozesses
  5. Zusammenarbeit zwischen Entwicklern und Kunden

6 Bewertung

Innerhalb dieses Abschnittes sollen Erfolgsfaktoren sowie Mißerfolgsfaktoren aufgezeigt werden.

6.1 Erfolgsfaktoren

Im Folgenden sollen die Erfolgsfaktoren aufgezeigt werden, die maßgeblich für den Einsatz von Scrum sprechen

6.1.1 Entwicklersicht

Für die Softwareentwickler selbst ebnet Scrum den Weg zu größerer Eigenverantwortung und Selbstinitiative. Dem Softwareentwickler kommt wesentlich mehr Verantwortung zu, als er im herkömmlichen Projektmanagement[2] hätte. Er weiß, dass er eines mehrerer Mitglieder eines Teams ist, welches eng zusammenarbeitet, gemeinsame Sprints und Daily Scrum Meetings durchführt. Ohne Mitwirken des einzelnen Entwicklers ist das Team vermutlich nicht in der Lage den Sprint erfolgreich abzuschließen. Verantwortung führt zu Motivation[60]. Das Gefühl innerhalb eines Teams unerlässlich zu sein, sowie den Weg zum Ziel selbst bestimmen zu können, motiviert den Entwickler. "James Coplien beschrieb [...], wie ein Software Development Team, das nie größer als acht Personen war, 1.000.000 Zeilen in C++ geschriebenen Code in 31 Monaten lauffähig auslieferbar lieferte. [...] Das entspricht einer Produktivität, die 37-mal höher ist, als die, die ein Team in diesem Industriezweig üblicherweise liefert."[61]

Forscher, die dieses Team befragten, führten die Produktivitätssteigerung auf intakte Kommunikationskultur sowohl innerhalb des Teams als auch nach außen zurück. Das Team setzte sich jeden Morgen zwei Stunden zusammen und diskutierte die Fortschritte des Vortages, um aufgetretene Probleme zu klären[62]. - sehr ähnlich den Daily Scrum Meetings.

In den Daily Scrum Meetings kann ein Entwickler zeigen, welche Fortschritte er gemacht hat und welche Hürden sich ihm in den Weg gestellt haben[63]. Das führt dazu, dass die Teammitglieder von anderen Teammitgliedern Anerkennung bekommen, was wiederum zur Steigerung des eigenen Selbstwertgefühls führt, was wiederum die förderlich für die Motivation ist. "Ich habe Menschen getroffen, die haben Jobs in Unternehmen nur deshalb angenommen, weil es hieß, man mache dort Scrum."[64]

Durch eigenverantwortliches Arbeiten wird weiterhin die Produktivität der Entwickler gesteigert. Sie können sich die Arbeitszeit selbst einteilen, Arbeitsvorgänge weglassen, die sie für unförderlich für das Projektziel erachten und mehr Zeit mit Aufgaben verbringen, die sie als wichtig erachten. Denn der Entwickler selbst weiß zumeist am besten, wie er seine Zeit produktiv einsetzt, während ein vorgesetzter Projektleiter mangels Fachwissen nicht immer eine optimale Arbeitszeiteinteilung vornehmen kann.

6.1.2 Kundensicht

Der Kunde profitiert von Scrum, da er schneller an produktive Ergebnisse kommt. Eine Kundensoftware wird nicht komplett entwickelt, getestet und nach Monaten der Entwicklung an den Kunden ausgeliefert, während dieser in Zwischenzeit bereits neue Anforderungen an die Software stellt. Stattdessen werden in jedem Sprint Teile der kompletten Software entwickelt, getestet und an den Kunden ausgeliefert[65]. Das hat den Vorteil, dass der Kunde mit einigen Softwaremodulen wesentlich schneller produktiv arbeiten kann, während er andere Module später hinzukommen.

Nicht nur einzelne Teile, sondern die gesamte zu entwickelnde Software selbst ist schneller verfügbar, da die Produktivität der Softwareentwicklung durch Scrum ohne Probleme verdoppelt bis vervierfacht werden kann[62]. Je schneller die Software fertiggstellt wird, desto weniger Kosten entstehen dadurch für den Kunden.

Zudem kann er seine neuen Anforderungen bzw. Verbesserungswünsche an die Software schon bevor die Software komplett entwickelt ist an die Entwickler weitergeben, sodass sie noch in die fertige Software mit einfließen können. Dabei gelten die Prinzipien:

  • Change for Free
  • Money for Nothing

Change for Free bedeutet, dass bestehende Anforderungen während der Sprintplanung durch neue Anforderungen ausgetauscht werden können. Money for Nothing bedeutet, dass ein Projekt, sofern aus Sicht des Kunden genug Funktionalität bereitgestellt worden ist, vorzeitig beendet werden kann, um Geld einzusparen[66]. Dadurch, dass die Meetings der Teams öffentlich sind[39], wird die Transparenz für den Kunden gesteigert, er kann, sofern gewünscht, jeden Fortschritt bis ins kleinste Detail mitverfolgen.

6.2 Misserfolgsfaktoren

In diesem Kapitel sollen erläutert werden, welche praktischen Probleme beim Einsatz von Scrum auftreten können und wo die Grenzen beim Einsatz von Scrum liegen.

6.2.1 Mögliche Problemfelder und Lösungsansätze

Im praktischen Einsatz von Scrum gibt es je nach Rolle typische Probleme, die auftreten können. Die folgenden Kapitel sollen Aufschluss darüber geben, was beim Einsatz von Scrum häufig fehlinterpretiert oder missachtet wird bzw. welche Probleme auftreten können.

6.2.1.1 Scrum Master

Der Scrum Master vermittelt die Scrum Technik selbst, er hat zudem eine Zentrale Rolle bei der Entwicklung mit Scrum[67], daher wird die Rolle in einigen Beispielen aus der Praxis beschrieben und anschließend analysiert, um Misserfolgsfaktoren aufzuzeigen[68].

6.2.1.1.1 Beispiel 1: Scrum Master bei Trey Research[69]

Der Scrum Master bei Trey Research nahm täglich an den "Daily Scrum" Meetings der Teams teil. Dabei stellte er dem einzelnen Teammitgliedern Fragen zum Fortschritt der Aufgaben, die ihnen zugewiesen worden sind. Nachdem er alle Mitglieder über den Status ausgefragt hatte, war er zufrieden, denn die Aufgaben wurden größtenteils erwartungsgemäß erfüllt[70].

Problemanalyse

Der Scrum Master soll nicht an Daily Scrum Meetings teilnehmen. Das Daily Scrum Meeting ist dazu gedacht, um innerhalb der Teams die Fortschritte auszutauschen und anderen Teammitgliedern möglicherweise Unterstützung geben zu können. Durch die Teilnahme des Scrum Masters werden die Projektteams kontrolliert und die gewünschte Eigendynamik und Eigenverantwortlichkeit der Teams wird zerstört. Gerade die Selbständigkeit der Teams führt in der Regel zu Produktios- und Effizienzsteigerungen der Teams. Vermutlich war der Scrum Master früher bereits mit Betreuung von Projekten ohne den Einsatz von Scrum betraut, hat versucht die Regeln von Scrum zu befolgen, hat den Grundgedanken von Scrum dabei jedoch missachtet.

6.2.1.1.2 Beispiel 2: Scrum Master bei Litware[69]

Der Scrum Master bei Litware musste erst noch in Scrum geschult werden. Leider konnte er auf Grund eines Termins an einem Tag der Schulung nicht erscheinen. Später wurden noch die Mitarbeiter der Firma selbst in den Grundlagen von Scrum geschult, damit sie das gesamte Konzept verstehen und sich darauf einstellen können. Der frisch geschulte Scrum Master entwickelte ein Backlog für zwei Teams seiner Firma. Offizieller Projektstart solle am Folgetag sein. Leider konnte der Scrum Master beim Start nicht dabei sein, da er wegen eines wichtigen Termins außer Haus war[70].

Problemanalyse

Die Rolle des Scrum Masters ist nicht mit der Rolle des Projektleiters in herkömmlichen Projekten vergleichbar. Als Scrum Master befindet man sich in einer Rolle des Coaches, des Unterstützers der Teams. Doch wie soll sich ein Team auf seinen Unterstützer verlassen können, wenn dieser schon zum Projektstart nicht dabei ist? Von Anfang an wird dem Projektteam gezeigt, dass die Aufgabe, die das Team zu bewältigen hat, vom Scrum Master als unwichtig angesehen wird. Mit entsprechender Motivation werden die Mitarbeiter das Projekt durchführen. Der Scrum Master bildet den "Leitwolf" eines Teams, er muss es motivieren und unterstützen.

6.2.1.1.3 Beispiel 3: Scrum Master bei Contoso.com[69]

Das Projektteam bei Contoso.com arbeitete hart innerhalb eines Sprints. Gegen Ende des Sprints erfuhr es jedoch, dass ein besonders wichtiger Tag des Sprints wegfällt, da die Firma für die Mitarbeiter einen verpflichtenden Betriebsausflug geplant hat, um das Betriebsklima zu verbessern. Der agierende Scrum Master hat der stellvertretenden Geschäftsführung geraten, den Tag nicht anzusetzen, da das Team ein wichtiges Sprint-Ziel nicht erreichen kann. Weil diese nicht einlenkte, versuchte der Scrum Master es bei der Geschäftsführung selbst. Sie war sich mit der stellvertretenden Geschäftsführung einig. Kurze Zeit später wurde der Scrum Master entlassen[70].

Problemanalyse

Der Scrum Master stand, im Gegensatz zum vorherigen Beispiel, für sein Team. Er wollte unbedingt durchsetzen, dass sein Team das Sprintziel erreicht. Dabei missachtete er die herrschende Firmenpolitik und die übergordneten Ziele, die die Geschäftsführung verfolgte. Die Unternehmensphilosophie, nach welcher das Betriebsklima von besonderer Bedeutung ist, wurde vom Scrum Master missachtet. Auch wenn der Scrum Master für sein Team einsteht, so muss er trotzdem die Unternehmensphilosophie unterstützen.

6.2.1.2 Product Owner

Es gibt einige Faktoren, die ein Product Owner beachten sollte. Zum Einen muss der Product Owner jederzeit für sein Team verfügbar sein. Das Projektziel wird in starkem Maße gefährdet, wenn er nicht an Daily Scrum oder Review Meetings teilnimmt. Weiterhin muss er für ein vollständiges und priorisiertes Backlog sorgen. Ein fehlendes, unvollständig oder falsch priorisierter Backlog gefähret wiederum den Projekterfolg[71].

Falls kein Product Owner gefunden wird, fungiert des öfteren der Scrum Master als Product Owner. Die Doppelrolle kann für eine Weile funktionieren, sollte jedoch möglichst schnell aufgelöst werden[71].

Auch eine zu hohe Anzahl an Product Ownern kann hinderlich sein. Gibt es zu viele Projektanforderungen von Product Ownern an die Softwareentwickler, kommen diese nicht mehr mit der Entwicklung hinterher. Viel wird begonnen zu entwickeln, nichts wird fertiggestellt[72].

Alle Teammitglider sollten vom Product Owner gleich behandelt werden, damit keine Rivalitäten innerhalb des Teams entstehen. Besonders wichtig ist das Vorhandensein von Konfliktfähigkeit beim Product Owner. Scheut er Konflikte und traut sich nicht die Ergebnisse zu kritisieren, hilft das weder dem Team, noch ihm selbst[73].

6.2.1.3 Team

Wenn ein Unternehmen sich dazu entschließt Scrum einzuführen, so sind die Teammitglieder der Projektteams am stärksten von den Änderungen in Scrum betroffen. Sie berichten nicht mehr ausschließlich dem Projektleiter, sondern den anderen Teammitgliedern sowie dem Product Owner. Ihre Arbeit wird nicht mehr fortwährend von einer Person kontrolliert, sondern die Teammitglieder verwalten sich selbst. Dabei liegt die optimale Teamstärke bei ungefähr sieben Personen[74]. Diese grundsätzliche Änderung in der Arbeitsweise birgt in der Praxis einige Probleme, auf die im Folgenden an Hand eines Beispiels näher eingegangen wird.

Beispiel: Die Teams von Service1st[69]

Nach Einführung von Scrum machten sich die Teams von Service1st an die Arbeit und hielten ihre Daily Scrum Meetings ab. Der Scrum Master musste jedoch feststellen, dass die Teammitglieder während der Meetings ihre Fortschritte nicht untereinander austauschten, sondern ihn dabei anschauten und ihm berichteten. Im ersten Sprint nahm sich das Team sehr viel vor, was jedoch nicht erreicht worden ist. Demnach nahm sich das Team im zweiten Sprint weniger vor und plante die Zeit für die einzelnen Arbeitsschritte wesentlich genauer ein. Diesmal war großzügig geplant worden, sodass noch während des Sprints nachträglich Arbeitspakete mit hoher Priorität aus dem Backlog hinzugenommen wurden[75].

Problemanalyse

Die Teammitglieder waren von früher noch gewohnt, dass sie ihrem Projektleiter regelmäßig berichten müssen. Auch nach der Scrum Schulung war dieser Gedanke noch in den Köpfen der Teammitglieder verankert. Sie sahen den Scrum Master als Projektleiter an, welcher das Projekt steuert und die Verantwortung dafür hat. Das Team muss erkennen, dass der Scrum Master nur eine unterstützende Funktion hat und es selbst für den Fortschritt und die Organisation untereinander zuständig ist. Bei der Einführung zum Scrum kommt es des öfteren dazu, dass die Teams sich im ersten Sprint zu viel vornehmen[76]. Den Teams ist nicht von Anfang an bewusst, dass zum Ende des Sprints getestete, fehlerfreie, produktiv einsetzbare Software fertiggestellt worden sein soll. Häufig ist es Teil der Unternehmenskultur, dass Software erst nach Abschluss eines Projektes getestet und gesäubert wird. Das Team muss sich erst auf die neuen Anforderungen einstellen.


6.2.2 Grenzen von Scrum

Es gibt Situation, in denen Scrum nicht eingesetzt werden kann bzw. eingesetzt werden sollte. Scrum fordert ein großes Maß an Eigeninitiative und Verantwortung innerhalb der Projektteams. Die Mitarbeiter müssen in der Lage sein damit umzugehen. Es gibt durchaus Mitarbeiter, welche produktiver Arbeiten, wenn Ihnen genau vorgegeben wird, welche Aufgaben in welcher Form zu erledigen sind. Die Kontrolle und Vorgabe eines Vorgesetzten gibt Ihnen das sichere Gefühl das Richtige zu tun. Würden diese Mitarbeiter ein Projektteam bilden, wären die Resultate mit Einsatz von Scrum schlechter als ohne[67].

Weiterhin muss der endgültige Fertigstellungstermin der Software eine geringe Priorität haben oder in sicherer Entfernung in der Zukunft liegen, denn Scrum ist dynamisch. Neue Anforderungen können in den Backlog eingebaut werden[77], wodurch sich das Projektende verzögern kann. Beim agilen Projektmanagement mit Scrum steht das Ergebnis und der Kunde im Vordergrund, nicht der Termin der Fertigstellung.

Im Backlog kann zudem grob bestimmt werden, was innerhalb eines Sprints erledigt werden soll. Ob die Teams den Backlog vollständig erfüllen liegt allein in der Eigenverantwortung des Teams[78].

Ebensowenig ist die Entwicklung nach Scrum zu empfehlen, wenn es nicht möglich ist, das gewünschte Endprodukt nach einzelnen Funktionalitäten aufzuteilen[78], denn für jedes innerhalb eines Monats entwickelte Softwaremodul müssen Tests und Qualitätsprüfungen durchgeführt werden sowie die Übergabe zum Kunden stattfinden. Ist eine Einteilung in Module nicht möglich, kann Scrum nicht angewandt werden, sodass eine reguläre Entwickung stattfinden muss, bei der alle Tests sowie Qualitätsprüfungen am Ende durchgeführt werden und der Kunde ein fertiges Produkt als Ganzes ausgeliefert bekommt.

7 Fazit

Der Begriff Scrum wurde von uns durch Zufall bei der Themensuche für die Fallstudie entdeckt. Weder im Firmenumfeld, noch in der Fachhochschule fiel zuvor dieser Begriff - sehr bedauerlich, wie wir nach Abschluss dieser Fallstudie feststellten. Scrum versucht genau die Probleme zu lösen, die besondere praktische Relevanz haben: Software wird unfertig an den Kunden weitergegeben, die Funktionalität wurde nicht hinreichend getestet, die Entwicklung dauerte länger als geplant und die Kosten waren höher. Das Grundprinzip sowie die drei existierenden Rollen sind schnell erlernbar, obgleich die tatsächliche Beherrschung der Methodik viel Erfahrung fordert. Viele gute sowie schlechte Methodiken, Verfahren und Produkte aus dem angloamerikanischen Raum eroberten Europa, besonders innerhalb der letzten 15 Jahre - wir würden es begrüßen, wenn Scrum den Weg zu uns finden würde.

8 Fußnoten / Quellen

  1. ↑ Schwaber, Ken (2007), Agiles Projektmanagement mit Scrum, S.3
  2. ↑ 2,0 2,1 2,2 Vgl. Zingel, Harry (2000-2005)
  3. ↑ Vgl. Schwaber, Ken (2007), Agiles Projektmanagement mit Scrum, S.4
  4. ↑ Vgl. Schwaber, Ken (2007), Agiles Projektmanagement mit Scrum, S.XIIff
  5. ↑ Kirstein, Roland (2006), S. 3
  6. ↑ Schweitzer, Raffael (2003/2004), S.5
  7. ↑ Vgl. Schweitzer, Raffael (2003/2004), S.5
  8. ↑ Pichler,Roman (2008) S.11
  9. ↑ Schweitzer, Raffael (2003/2004) S.8
  10. ↑ Pichler,Roman (2008) S.15
  11. ↑ Pichler,Roman (2008) S.13
  12. ↑ Pichler,Roman (2008) S.18/19
  13. ↑ Pichler,Roman (2008) S.17
  14. ↑ Schweitzer, Raffael (2003/2004) S.7
  15. ↑ Pichler,Roman (2008) S.21
  16. ↑ Pichler,Roman (2008) S.19
  17. ↑ 17,0 17,1 Gloger, Boris (2008) S.146
  18. ↑ 18,0 18,1 Vgl. Pichler,Roman (2008) S.28
  19. ↑ Gloger, Boris (2008) S.152
  20. ↑ Vgl. Gloger, Boris (2008) S.152
  21. ↑ Vgl. Gloger, Boris (2008) S.153
  22. ↑ Vgl. Gloger, Boris (2008) S.154
  23. ↑ Vgl. Gloger, Boris (2008) S.149
  24. ↑ Vgl. Ken Schwaber,Mike Beedle:Agile Software Development with SCRUM.Prentice Hall (2001), zitiert nach: Pichler,Roman (2008) S.62
  25. ↑ Schwaber, Ken (2007), Agiles Projektmanagement mit Scrum, S.13
  26. ↑ Gloger, Boris (2008), S.181
  27. ↑ Vgl. Pichler, Roman (2008), S.81
  28. ↑ Vgl. Pichler, Roman (2008), S.83
  29. ↑ Vgl. Schwaber, Ken (2007), Agiles Projektmanagement mit Scrum, S.15
  30. ↑ Pichler, Roman (2008), S.81
  31. ↑ Vgl. Schwaber, Ken (2007), Agiles Projektmanagement mit Scrum, S.57
  32. ↑ Vgl. Schweitzer, Raffael (2003/2004) S.8
  33. ↑ 33,0 33,1 Vgl. Schwaber, Ken (2007), Agiles Projektmanagement mit Scrum, S.8
  34. ↑ Schwaber, Ken (2007), Agiles Projektmanagement mit Scrum, S.8
  35. ↑ Verpflichtung gegenüber dem Product Owner
  36. ↑ 36,0 36,1 Vgl. Gloger, Boris (2008), S.201
  37. ↑ Vgl. Schwaber, Ken (2007), Agiles Projektmanagement mit Scrum, S.9
  38. ↑ Gloger, Boris (2008), S.202
  39. ↑ 39,0 39,1 Vgl. Gloger, Boris (2008), S.209
  40. ↑ Schwaber, Ken (2007), Scrum im Unternehmen, S.123
  41. ↑ Pichler, Roman (2008), S.111
  42. ↑ Vgl. Pichler, Roman (2008), S.112ff
  43. ↑ Vgl. Pichler, Roman (2008), S.117
  44. ↑ Vgl. Pichler, Roman (2008), S.119
  45. ↑ Vgl. Pichler, Roman (2008), S.121ff
  46. ↑ Vgl. Avraham Y. (2008)
  47. ↑ Vgl. Pichler, Roman (2008), S.123ff
  48. ↑ 48,0 48,1 Schweitzer, Raffael (2003/2004), S.11
  49. ↑ Schweitzer, Raffael (2003/2004), S.11
  50. ↑ 50,0 50,1 Pichler, Roman (2008), S.130
  51. ↑ Gloger, Boris (2008) S.278
  52. ↑ Gloger, Boris (2008) S.279
  53. ↑ Vgl. Pichler, Roman (2008), S.126
  54. ↑ Vgl. Pichler, Roman (2008), S.131
  55. ↑ Pichler, Roman (2008), S.134
  56. ↑ 56,0 56,1 Bergsmann, Johannes (2008)
  57. ↑ 57,0 57,1 Bullig, Rainer (2008)
  58. ↑ Zivkovi, Sini (2008)
  59. ↑ Interview Ken Schwaber (2008)
  60. ↑ SalesBusiness (Nov 2007)
  61. ↑ Gloger, Boris (2008), S.67
  62. ↑ 62,0 62,1 Vgl. Gloger, Boris (2008), S.68
  63. ↑ Vgl. Schwaber, Ken (2007), Scrum im Unternehmen, S.122
  64. ↑ Gloger, Boris (2008), S.70
  65. ↑ Vgl. Gloger, Boris (2008), S.181
  66. ↑ Vgl. Sutherland, Jeff (2008)
  67. ↑ 67,0 67,1 Vgl. Schweitzer, Raffael (2003/2004), S.13
  68. ↑ Vgl. Schwaber, Ken (2007), Scrum im Unternehmen, S.121
  69. ↑ 69,0 69,1 69,2 69,3 Bei Trey Research, Litware, Contoso.com, Service1st handelt es sich um Eigennamen US ansässiger Firmen, bei denen Scrum eingeführt worden ist. An Hand dieser Praxisbeispiele werden Problemfelder erläutert
  70. ↑ 70,0 70,1 70,2 Vgl. Schwaber, Ken (2007), Agiles Projektmanagement mit Scrum, S.27ff
  71. ↑ 71,0 71,1 Gloger, Boris (2008), S.365
  72. ↑ Gloger, Boris (2008), S.365-366
  73. ↑ Vgl. Pichler, Roman (2008), S.110ff
  74. ↑ Vgl. Schwaber, Ken (2007), Agiles Projektmanagement mit Scrum, S.120
  75. ↑ Vgl. Schwaber, Ken (2007), Agiles Projektmanagement mit Scrum, S.105ff
  76. ↑ Vgl. Schwaber, Ken (2007), Agiles Projektmanagement mit Scrum, S.105ff
  77. ↑ Vgl. Pichler, Roman (2008), S.81
  78. ↑ 78,0 78,1 Vgl. Schweitzer, Raffael (2003/2004), S.14

9 Abkürzungsverzeichnis

AbkürzungBedeutung
OOPSLAThe Eleventh Annual ACM Conference on Object-Oriented Programming Systems, Languages and Applications
ROIReturn of Investigation

10 Abbildungsverzeichnis

Abb.-Nr.Abbildung
1Scrum im Übberblick
2Traditionelles Management
3Das Zusammenspiel von Product Owner und Team
4Der Planungsprozess im Überblick
5Product Backlog in Form eines Spreadsheets
6Beispiel für einen Releaseplan
7Der Sprint-Ablauf
8Burn Down Report
9Das Wasserfallmodell

11 Literatur- und Quellenverzeichis

Gloger, Boris (2008) Gloger, Boris: "Scrum - Produkte zuverlässig und schnell entwickeln", 1. Auflage, Carl Hanser Verlag, München
Pichler, Roman (2008) Pichler, Roman: "Scrum - Agiles Projektmanagement erfolgreich einsetzen", 1. Auflage, dpunkt.verlag, Heidelberg
Schwaber, Ken (2007) Schwaber, Ken: "Agiles Projektmanagement mit Scrum", 1. Auflage, Microsoft Press, Redmond, Washington 98052-6399
Schwaber, Ken (2007) Schwaber, Ken: "Scrum im Unternehmen", 1. Auflage, Microsoft Press, Redmond, Washington 98052-6399
Avraham Y. (2008) Avraham Y: "The Theory of Constraints and its Thinking Processes", http://www.goldratt.com/toctpwhitepaper.pdf, zugegriffen am 17. Januar 2009
Bergsmann, Johannes (2008) Dipl.-Ing. Bergsmann, Johannes "Quality Newsletter 2003/2: Vorgehensmodelle S4", http://www.software-quality-lab.at/swql/fileadmin/download/Newsletter/SWQL-Newsletter-200311.pdf, zugegriffen am 13. Dezember 2008 14:00
Bullig, Rainer (2008) Bullig, Rainer "Inside April 2007: Agile Softwareentwicklung mit SCRUM S43", http://www.medical.siemens.com/siemens/de_DE/gg_hs_FBAs/files/PLM-FE-MI/Artikel-inside-Agile-SCRUM-2007-Apr.pdf, zugegriffen am 13. Dezember 2008 14:00
Grund, Matthias (2004) Grund, Matthias: "SCRUM: Management-, Organisations- und Prozessinnovation für mehr Effizienz in der Softwareentwicklung", http://www.andrena.de/fileadmin/pdf/Methoden/Scrum/Whitepaper_SCRUM.pdf, zugegriffen am 04. Dezember 2008
Interview Ken Schwaber (2008) Interview mit Ken Schwaber anlässlich der XP Days Germany 2004; Das Interview wurde geführt von Matthias Grund;http://www.andrena.de/fileadmin/pdf/Methoden/Scrum/Interview_Ken_Schwaber.pdf, zugegriffen am 13. Dezember 2008 14:00
Kirstein, Roland (2006) Kirstein, Roland: "Markt und Marktwirtschaft", http://opus.zbw-kiel.de/volltexte/2007/5725/pdf/2006-11_markt.pdf, zugegriffen am 25. November 2008
Ludewig,Jochen (2002) Ludewig,Jochen: "Modelle im Software Engineering – eine Einführung und Kritik", http://www.iste.uni-stuttgart.de/se/publications/download/Modelle.pdf, Stuttgart, zugegriffen am 04. Dezember 2008
SalesBusiness (Nov 2007) SalesBusiness: "Motivation durch Beteiligung", http://manus-collegium.de/pdf/Salesbusiness.pdf, zugegriffen am 15. Januar 2009
Schweitzer, Raffael (2003/2004) Schweitzer, Raffael: "Seminar Software Engineering,Agile vs. klassische Methoden der Software-Entwicklung", http://www.ifi.uzh.ch/rerg/fileadmin/downloads/teaching/seminars/seminar_ws0304/07_Schweitzer_Scrum_Ausarbeitung.pdf, Zürich, zugegriffen am 04. Dezember 2008,
Sutherland, Jeff (2008) Sutherland, Jeff: "Agile Contracts: Money for Nothing and Your Change for Free", http://jeffsutherland.com/scrum/2008/10/agile-contracts-money-for-nothing-and.html, Boston, zugegriffen am 04. Dezember 2008
Zingel, Harry (2000-2005) Zingel, Harry: "Grundzüge des Projektmanagements", http://www.zingel.de/pdf/10proj.pdf, zugegriffen am 25. November 2008
Zivkovi, Sini (2008) Diplomarbeit: Zivkovic, Sini; Extreme Programming - Theorie und praktische Erfahrungen;http://diuf.unifr.ch/people/fuhrer/studproj/zivkovic/xp_da_public.pdf, zugegriffen am 13. Dezember 2008 14:00
Von „http://winfwiki.wi-fom.de/index.php/Scrum_-_Agiles_Projektmanagement“
Persönliche Werkzeuge