Table Of ContentAgile IT-Projekte erfolgreich gestalten
Jonathan Brandstäter
Agile IT-Projekte
erfolgreich gestalten
Risikomanagement als
Ergänzung zu Scrum
Jonathan Brandstäter
Essen, Deutschland
ISBN 978-3-658-04429-9 ISBN 978-3-658-04430-5 (eBook)
DOI 10.1007/978-3-658-04430-5
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Natio-
nalbibliografi e; detaillierte bibliografi sche Daten sind im Internet über http://dnb.d-nb.de
abrufb ar.
Springer Vieweg
© Springer Fachmedien Wiesbaden 2013
Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung,
die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zu-
stimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Über-
setzungen, Mikroverfi lmungen und die Einspeicherung und Verarbeitung in elektronischen
Systemen.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in die-
sem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass
solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu be-
trachten wären und daher von jedermann benutzt werden dürft en.
Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier
Springer Vieweg ist eine Marke von Springer DE. Springer DE ist Teil der Fachverlagsgruppe
Springer Science+Business Media.
www.springer-vieweg.de
Vorwort
Das persönliche Interesse an innovativen Themen und letztlich agilem Projekt-
management motivierte mich eine wissenschaftliche Arbeit zum Risikomanage-
ment in agilen IT-Projekten zu verfassen. Nicht zuletzt auch die kontroversen
Diskussionen auf einigen Blogs und Foren, in denen auch kritisiert wurde, man
solle Scrum und Risikomanagement nicht zusammenführen. Und sowieso würde
Scrum bereits in allerlei Hinsicht perfekt sein. – Mit diesem Irrtum möchte ich in
dieser Arbeit aufräumen.
Ein ganz besonderer Dank gilt meinem Gutachter, Tobias Trepper, sowie meiner
Familie und meiner Freundin Sabine, ohne die diese Veröffentlichung nicht mög-
lich gewesen wäre.
Inhaltsverzeichnis
1 Einleitung ........................................................................................................ 1
1.1 Motivation ................................................................................................ 1
1.2 Gegenstand und Ziel der Arbeit ............................................................... 3
1.3 Methodischer Ansatz ................................................................................ 4
1.4 Vorgehensweise zur Auswahl und Evaluation geeigneter RM-Ansätze
für Scrum.................................................................................................. 5
1.5 Vorgehensweise der Arbeit ....................................................................... 6
2 Agiles Projektmanagement in der Softwareentwicklung ............................. 9
2.1 Einleitung ................................................................................................. 9
2.2 Scrum ..................................................................................................... 10
3 Risikomanagement in der Softwareentwicklung ........................................ 21
3.1 Allgemein ............................................................................................... 21
3.2 Einführung in das Projektrisikomanagement ......................................... 23
3.3 Einführung in das Risikomanagement in der Softwareentwicklung ...... 27
4 Scrum – Status quo: Risikomanagement in Scrum ................................... 33
4.1 Methodisches Vorgehen zur Identifikation von Schwachstellen ............ 33
4.2 Scrum als Risikomanagementstrategie: Eine Perspektive auf den
impliziten RM-Ansatz in Scrum ............................................................ 35
4.3 Explizites Risikomanagement in Scrum ................................................. 40
4.4 Schwachstellen im Risikomanagement von Scrum ................................ 47
4.5 Abschließende kritische Betrachtung ..................................................... 56
5 Evaluation einzelner Risikomanagementansätze ....................................... 59
5.1 Methodisches Vorgehen ......................................................................... 59
5.2 Evaluation verschiedener Risikomanagementansätze ............................ 72
VIII Inhaltsverzeichnis
5.3 Auswertung und Interpretation ............................................................... 98
5.4 Abschließende kritische Betrachtung ................................................... 102
6 Kritische Würdigung und Gestaltungsempfehlungen ............................. 105
6.1 Kritische Würdigung der agilen Variante des SRE............................... 105
6.2 Gestaltungsempfehlungen .................................................................... 108
6.3 Fazit ...................................................................................................... 109
7 Abschließende Betrachtung ........................................................................ 111
7.1 Zusammenfassung ................................................................................. 111
7.2 Ausblick ................................................................................................114
Literaturverzeichnis ................................................................................... 117
1 Einleitung
Die Einleitung stellt die Motivation sowie den Gegenstand und das Ziel der vor-
liegenden Arbeit vor. Außerdem wird auf den verfolgten methodischen Ansatz
und den weiteren Verlauf eingegangen.
1.1 Motivation
Die gestiegenen Herausforderungen an die Flexibilität der Unternehmen haben
Einfluss auf den Erfolg des IT-Projektmanagements und sind u. a. auf kürzer
Entwicklungszyklen zurückzuführen (Hoffmann 2008, S. 5-6). So hat eine Aus-
wertung der Jahre 1994 – 2008 der Standish Group ergeben, dass 57 % der agilen
Projekte und 74 % der traditionellen Projekte1 fehlschlugen oder nicht korrekt
umgesetzt wurden (The Standish Group Report 2010, S. 15). KEN SCHWABER,
der Autor des agilen Prozesses Scrum, kommt hingegen zu dem Ergebnis, dass
75 % aller agilen Projekte fehlschlagen2 (AgileCollab 2008). Als Erfolgsfaktor
eines Projektes werden Voraussetzungen verstanden, „die wesentlich zur Errei-
chung der wünschbaren Zustände gemäß Erfolgsermittlungskriterien beitragen“
(Jenny 2010, S. 85). CHOW UND CAO (2008, S. 963) definieren fünf Dimensionen
der Erfolgsfaktoren für agile Projekte. Dabei wird die Unterstützung des Mana-
gements genauso angeführt wie die Erfahrung des Teams. Die fehlende Beach-
tung dessen führt zu unvorhersehbaren Ereignissen, die Auswirkungen auf das
Projekt haben können und als Risiko bezeichnet werden (Sommerville 2004, S.
104-105). Dabei sind agile Prozesse dafür bekannt, durch ihre Struktur Probleme
und Risiken der Softwareentwicklung implizit zu adressieren (Sliger und Bro-
derick 2008, S. 177-182; Nelson et al. 2008, S. 190). Aufgrund der zuvor ge-
nannten Sachverhalte ist zu hinterfragen, wieso ein hoher Prozentsatz an agilen
Projekten trotzdem fehlschlägt bzw. bei der Umsetzung mit Problemen konfron-
tiert wird. Es ist daher anzunehmen, dass Projektmisserfolge auf die falsche An-
wendung des Prozesses zurückzuführen sind. Scrum ist mit 52 % der am weites-
1 Hierbei werden zum Zweck der Verständlichkeit Projekte, die nach dem Wasserfall-Vorgehens-
modell entwickelt wurden, synonym als traditionelle Projekte betrachtet.
2 Es ist anzuführen, dass diese Aussage empirisch nicht belegt wurde. Stattdessen handelt es sich
um die Aussage eines Autors, der zugleich Scrum-Zertifizierungen anbietet, was die hohe Feh-
lerrate relativiert. Ferner liegt es in der Natur agiler Projekte, dass sie durch ihre erhöhte Trans-
parenz frühzeitiger fehlschlagen als Projekte, die nach traditionellen Vorgehensmodellen durch-
geführt werden.
J. Brandstäter, Agile IT-Projekte erfolgreich gestalten, DOI 10.1007/978-3-658-04430-5_1,
© Springer Fachmedien Wiesbaden 2013
2 1 Einleitung
der am weitesten verbreitete agile Prozess, der zugleich bewusst Lücken auf-
weist, wie bspw. im Risikomanagement (RM) (AgileCollab 2008). Da Scrum der
Meinung einiger Autoren (Sliger und Broderick 2008, S. 177-182; Nelson et al.
2008, S. 190) nach implizit Probleme der Softwareentwicklung adressiert, ist zu
hinterfragen, ob das Heranziehen eines RM-Ansatzes aus den traditionellen Vor-
gehensweisen adaptiert werden kann, um den Erfolg der Projekte zu steigern
(Whittaker 1999, S. 29). Obwohl einige Autoren keinen Zusammenhang zwi-
schen RM und Projekterfolg sehen (Ahrendts und Marton 2008, Vorwort), ist
anzumerken, dass durch Beachtung der Erfolgsfaktoren agiler Projekte innerhalb
eines RM ein Erfolg wahrscheinlicher wird.
Gerade bei der Wahl des geeigneten RM-Ansatzes fehlt es an Methoden, die
den Anforderungen agiler Prozesse gerecht werden und die Lücken des RM-
Ansatzes schließen. So konnten NELSON ET AL. (2008, S. 194) zeigen, dass die
Adaption traditioneller RM-Ansätze für Scrum nicht trivial ist, was auf einige
Schwachstellen zurückzuführen ist. Hier sei beispielhaft das Fehlen einer eigen-
ständigen Rolle für das Risikomanagement in Scrum erwähnt (Nelson et al.
2008, S. 197; Nyfjord und Kajko-Mattsson 2007, S. 4). Folglich ist zu bestim-
men, welche Rolle das RM erfüllt. Des Weiteren werden im RM von Scrum im
Gegensatz zum traditionellen RM nur projektinterne (Hazrati 2008) und techni-
sche Risiken (Schwaber und Beedle 2002, S. 44; Nelson et al. 2008, S. 192)
implizit adressiert, jedoch nicht projektexterne Risiken, wie bspw. politische
Risiken (Hazrati 2008), welche ebenfalls Einfluss auf die zuvor genannten Er-
folgsfaktoren haben. Hierbei ist zu erläutern, dass es in der Forschung nur weni-
ge Ansätze gibt, die sich mit dem RM in agilen Prozessen bzw. Scrum auseinan-
dersetzen. Als Beispiel sind NELSON ET AL. (2008) und SLIGER UND BRODERICK
(2008) zu nennen.
Daher geht diese Arbeit der Fragestellung nach, ob traditionelle RM-Ansätze
diese Lücken in Scrum schließen können, ohne Scrum dabei anzupassen. Dabei
sind einige Aspekte zu beachten, wobei diese Arbeit dazu beiträgt, die Schwach-
stellen und korrespondierenden Lösungsansätze zusammenzutragen und sie in
den Entscheidungsprozess zur Wahl eines geeigneten RM-Ansatzes einfließen zu
lassen. Ergebnis dieser Arbeit ist folglich eine Methode zur Entscheidungsunter-
stützung bei der Auswahl verschiedener RM-Ansätze, deren Durchführbarkeit an
vier verschiedenen RM-Ansätzen validiert wird.
1.2 Gegenstand und Ziel der Arbeit 3
1.2 Gegenstand und Ziel der Arbeit
Aus dem Gegenstand der Arbeit ergeben sich zwei Hauptziele. Das erste Ziel
dieser Arbeit ist die Entwicklung einer Methode zur Evaluation von RM-
Ansätzen in Bezug auf ihre Eignung für Scrum. Dabei wird eine Methode kon-
struiert, die es ermöglicht, die Schwachstellen der traditionellen RM-Ansätze in
die Betrachtung einfließen zu lassen, die aber zugleich die Agilität nicht unbe-
rücksichtigt lässt. Ferner ist es dabei das Ziel, eine Methode vorzugeben, die in
zukünftigen Arbeiten weitere RM-Ansätze miteinbeziehen kann, weshalb dieser
Ansatz bewusst einige Stellschrauben offenhält, die eine spätere Skalierbarkeit
ermöglichen. Ziel ist es dabei, einen RM-Ansatz für Scrum zu finden, der alle
Schwachstellen löst, ohne dabei Scrum anzupassen.
Als zweites Ziel ist die Identifikation eines geeigneten RM-Ansatzes für
Scrum zu nennen. Dabei wird die zuvor konstruierte Methode zur Evaluation auf
eine Menge von Risikomanagementansätzen angewendet. Die Anwendung er-
folgt beispielhaft für vier verschiedene Ansätze innerhalb der drei angrenzenden
Domänen von Scrum, d. h. das Projektmanagement, die Softwareentwicklung
und die agilen Varianten. Damit soll zugleich die Methode überprüft und belegt
werden.
Obwohl bereits einige Ansätze den Versuch unternommen haben, einen RM-
Ansatz für Scrum zu adaptieren (bspw. Nelson et al. 2008; Sliger und Broderick
2008), verweist nach Kenntnis des Autors keiner dieser Ansätze auf die ur-
sprüngliche Fassung von Scrum und auch die Gründe für die Wahl des adaptier-
ten RM-Ansatz für Scrum werden nicht näher spezifiziert. So ist die Auswahl
bspw. in NELSON ET AL. (2008, S. 191) geprägt vom Einfluss des zugehörigen
Forschungsinstitutes3. Dabei gibt es Ansätze, die bei der Entscheidung für einen
geeigneten Projektmanagementansatzes bzw. ein Vorgehensmodell im Hinblick
auf dessen Eignung für einen konkreten Projektkontext helfen (bspw. Boehm und
Turner 2004; Filß et al. 2005). Diese Arbeit grenzt sich von der Bewertung und
den Einflüssen eines konkreten Projektgegenstandes ab und fokussiert eine Me-
thode, die unabhängig davon einen RM-Ansatz für das Scrum-Prozessframework
bewertet und auswählt.
Aus diesem Grund lassen sich nachfolgende Forschungsfragen identifizieren,
deren Beantwortung das Ziel dieser Arbeit ist:
(cid:131) Forschungsfrage 1: Welche Bestandteile des Scrum-Frameworks dienen
der Adressierung typischer Probleme der Softwareentwicklung?
3 Dem Software Engineering Institute der Carnegie Mellon Universität.
