Agile IT-Projekte erfolgreich gestalten: Risikomanagement als Ergänzung zu Scrum PDF
Preview Agile IT-Projekte erfolgreich gestalten: Risikomanagement als Ergänzung zu Scrum
Agile 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.
The list of books you might like
