Abbildungsverzeichnis
Tabellenverzeichnis
Abkürzungsverzeichnis
1. Einleitung und Motivation
1.1 Thema und Motivation
1.2 Ziel
1.3 Herangehensweise
2. Projektmanagement in der IT
2.1 Grundlagen
2.2 Methoden
2.2.1 Sequentielles Vorgehensmodell
2.2.2 Iterative Entwicklung
3. Agiles Projektmanagement (APM)
3.1 Begriffsdefinition
3.2 Das Agile Manifest
3.2.1 Werte:
3.2.2 Prinzipien:
4. Scrum und Kanban
4.1 Scrum
4.1.1 Grundlagen
4.1.2 Rollen
4.1.3 Projektablauf mit Scrum
4.2 Kanban
4.2.1 Grundlagen
4.2.2 Kanban in der IT
4.3 Scrum und Kanban im Vergleich
4.3.1 Ähnlichkeiten
4.3.2 Unterschiede
5. Verteilte Teams
5.1 Begriffsdefinition
5.2 Notwendigkeit von verteilten Teams
6. Scrum und Kanban bei verteilten Teams
6.1 Risiken von Scrum und Kanban bei verteilten Teams
6.2 Chancen von Scrum und Kanban bei verteilten Teams
6.3 Bewertung der Risiken und Chancen
7. Fazit und Ausblick
Literaturverzeichnis
Abb. 1: Herangehensweise
Abb. 2: Wasserfallmodell
Abb. 3: Scrum Zyklus
Abb. 4: Material- und Informationsfluss
Abb. 5: Kanban-Whiteboard
Abb. 6: Verteilte Teams an verschiedenen Standorten
Abb. 7: Verteilte Team-Mitglieder an verschiedenen Standorten
Abb. 8: Kontroll-Level
Tab. 1: Werte im Agilen Manifest
Tab. 2: Unterschiede von Scrum und Kanban
Tab. 3: Digitale Werkzeuge für verteilte Teams
Tab. 4: Risiken
Tab. 5: Chancen
Abbildung in dieser Leseprobe nicht enthalten
Wenn es darum geht, mit vorhandenen Ressourcen (Budget, Personal, Material) zu wirtschaften und die vorgegebenen oder selbst definierten Fristen einzuhalten, um im Markt konkurrenzfähig zu bleiben, ist ein gewisses Maß an Projektmanagement für Unternehmen unabdingbar. Welche Methoden dabei eingesetzt werden, erschließt sich aus Krite- rien wie Unternehmensgröße, Branche, Produkt oder Projektart.
Während das klassische Projektmanagement an ein Vorgehensmodell gebunden ist und sich somit eher planerisch in bestimmten Phasen aufbaut, steht das Agile Projektmanagement für eine auf Erfahrung aufbauende, anpassungsfähige Projekt- oder Prozesssteuerung innerhalb eines vorgegebenen Rahmens.1
Agile Methoden wie Scrum und Kanban finden im heutigen Projektmanagement, insbesondere in der Softwareentwicklung, immer mehr Anwendung. So steigt laut der Studie „7th Annual State Of Agile Development Survey“2 der Anteil der Unternehmen, die agile Methoden nutzen oder sie einführen wollen, stetig an.
Diese agilen Methoden zu nutzen, birgt gerade zu Beginn der Einführung gewisse Schwierigkeiten. Wie verhält es sich dann erst, wenn verteilte Teams (Individuen an verschiedenen Standorten) die Methoden des agilen Projektmanagements praktizieren?
Ziel dieser Arbeit ist, die Chancen und Risiken beim Einsatz von Methoden des Agilen Projektmanagements in verteilten Teams aufzuzeigen und zu bewerten.
Zum verständlichen Einstieg in das Thema wird im zweiten Kapitel das Projektmanagement in der IT-Branche erläutert. Dabei werden zwei Vorgehensmodelle definiert, welche in der Softwareentwicklung An- wendung finden: Das sequentielle Vorgehensmodell und die iterative Entwicklung.
Das dritte Kapitel dagegen widmet sich dem Agilen Projekt- management, insbesondere dem Agilen Manifest. Kapitel vier be- schreibt die beiden Methoden Scrum (Grundlagen, Rollen und Projekt- ablauf) und Kanban (Grundlagen und Kanban in der IT). Abgeschlossen wird dieses Kapitel durch einen Vergleich von Scrum und Kanban.
Eine Brücke vom Agilen Projektmanagement zu den verteilten Teams schlägt Kapitel fünf. Die Definition von verteilten Teams und die Frage der Notwendigkeit von verteilten Teams sind in diesem Kapitel be- schrieben.
Kapitel sechs beantwortet die Fragestellung dieser Arbeit. In diesem Kapitel werden Chancen und Risiken von Scrum und Kanban in verteilten Teams aufgezeigt und anschließend bewertet.
Fazit und Ausblick befinden sich schließlich in Kapitel sieben, dem letzten Kapitel (Abbildung 1).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Herangehensweise (eigene Darstellung)
Das „Chaos Manifesto 2013“3, eine Umfrage der Standish Group, kam zu dem Ergebnis, dass lediglich 39 Prozent der Software-Projekte er- folgreich verlaufen. 43 Prozent liegen hinter dem Zeitplan, übersteigen das Budget oder enthalten nicht alle benötigten Funktionen. Die restli- chen 18 Prozent der Projekte scheiterten sogar komplett. Zwar verbes- serten sich diese Zahlen stetig leicht seit 2004, jedoch zeigt dieses Ma- nifest deutlich, dass es noch großen Optimierungsbedarf im IT- Projektmanagement gibt.
Für IT-Projekte gelten die allgemeinen Regeln des Projektmanage- ments, wobei der Projektgegenstand das IT-Produkt betrifft. Die Ziele und Bedürfnisse der Stakeholder (jeder der am Projekt direkt beteiligt ist, am Projektablauf interessiert ist oder von dem Resultat betroffen ist) bilden die Orientierungspunkte von IT-Projekten. Mit dem Einsatz von Wissen, Können und Methoden gilt es, diese Ziele und Bedürfnisse zu erfüllen oder zu übertreffen.4
Im Folgenden werden in dieser Arbeit zwei gängige Methoden des ITProjektmanagement beschrieben.
Ein sequentielles Vorgehensmodell ist u.a. das Wasserfallmodell. Se- quentiell bedeutet, dass das Modell aus hintereinander folgenden Pro- zessstufen besteht, wobei nach Ende jeder Stufe eine Ergebnisprüfung erfolgt (Abbildung 2). Das Eingreifen in vorangegangene Phasen ist sehr schwer realisierbar und mit erheblichem Aufwand bzw. erhöhten Kosten verbunden. Da flexible Reaktionen innerhalb eines IT-Projekts sehr oft überlebenswichtig sind, ist das Wasserfallmodell primär für Pro- jekte mit relativ fixen Anforderungen und für insgesamt kleinere Projekte geeignet. Die Vorteile ergeben sich aus der Einfachheit, Verständlichkeit und Übersichtlichkeit.5
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Wasserfallmodell 6
Während sequentielle Modelle es nahezu unmöglich machen in vorran- gegangene Phasen einzugreifen, erlaubt die iterative Entwicklung einen agileren Entwicklungsprozess. Das System oder Produkt besteht aus aufeinander aufbauenden Teilsystemen. Dadurch kann die Komplexität und das Risiko für Softwareentwicklungsprojekte verringert werden. Es ist sogar möglich, dass am Ende einer Iteration die Teilsysteme dem Verbraucher oder dem jeweiligen Stakeholder zu Verfügung gestellt werden. Dadurch bekommen die Entwickler konstruktives Feedback, welches in zukünftige Iterationen einfließen kann. Um die Ziele und Be- dürfnisse der Stakeholder zu erfüllen, empfiehlt es sich iterativ zu ent- wickeln, da die Entwickler auf Änderungen besser reagieren können.
Veränderungen sind bei der iterativen Entwicklung im Vergleich zum sequentiellen Vorgehensmodell möglich, jedoch immer noch kostenin- tensiv.7
Agilität bedeutet Beweglichkeit. Im Projektmanagement-Kontext bedeutet es, Projekte und Prozesse dynamisch und flexibel zu steuern. Wie im zweiten Kapitel beschrieben, wird nun deutlich, dass die iterative Entwicklung (2.2.2) eher agil ist, während das sequentielle Vorgehensmodell (2.2.1) keine agilen Eigenschaften aufweist.
Agilität lässt sich nicht vom Management verordnen, sondern beginnt im Kopf der Beteiligten. Diese müssen die agile Vorgehensweise verin- nerlichen, welche in der täglichen Praxis gebildet wird. Je größer die positiven Erfahrungen, desto selbstverständlicher wird die agile Hal- tung. APM ist in der Theorie einfach zu verstehen, kann aber - gerade zu Beginn - durch fehlendes Engagement in der Praxis schwierig wer- den. Anwender, Kunden, Auftraggeber und Sponsoren stehen genauso im Fokus der Bemühungen wie der Umgang mit den Mitarbeitern. Hier- bei gilt es, Werte und Prinzipien des Agilen Manifests einzuhalten, die helfen können, erfolgreich agil zu arbeiten.8
3.2 Das Agile Manifest
Die zuvor genannten Werte und Prinzipien finden sich im Agilen Mani- fest wieder. Dabei handelt es sich um ein Manifest mit vier Werten und zwölf Prinzipien zur besseren Software-Entwicklung, das von einer Gruppe unabhängiger Denker (The Agile Alliance), darunter auch die Scrum Begründer Ken Schwaber und Jeff Sutherland, verfasst wurde.
Die folgenden vier Werte weisen zum erfolgreichen agilen Arbeiten: „Individuen und Interaktionen mehr als Prozesse und Werkzeuge“ „Funktionierende Software mehr als umfassende Dokumentation“ „Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung“ „Reagieren auf Veränderung mehr als das Befolgen eines Plans“Tabelle 1: Werte im Agilen Manifest 9
Obwohl die Verfasser den zweitgenannten Wert für wichtig empfinden, schätzen sie den Erstgenannten für noch wichtiger ein.
Die zwölf Prinzipien bauen auf den Werten des Manifests auf:
1. Die kontinuierliche und frühe Auslieferung an den Kunden hat höchste Priorität.
2. Änderungen der Anforderung selbst in späten Entwicklungsphasen sind willkommen.
3. Funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate.
4. Tägliche Zusammenarbeit von Experten und Entwicklern.
5. Unterstützendes Umfeld für motivierte Individuen.
6. Effektiver Austausch von Informationen im Gespräch von Angesicht zu Angesicht.
7. Funktionierende Software als Maß für Fortschritt.
8. Nachhaltige Entwicklung durch gleichmäßiges Tempo auf unbe- grenzte Zeit.
9. Fokus auf technische Exzellenz und gutes Design.
10. Einfachheit.
11. Arbeiten in selbstorganisierten Teams fördert gute Resultate.
12. Regelmäßige Reflektion.10
Scrum (englisch für Gedränge) ist ein agiles Managementframework (Rahmenstruktur), welches die Werte und Prinzipien des Agilen Mani- fests lebt. Es besteht aus einer Reihe kurzer Arbeitszyklen (Sprints) die maximal 30 Tage dauern. So kann ein größeres Projekt in einzelne überprüfbare Schritte zerlegt werden um die Transparenz zu erhöhen. Diese neue Form, beeinflusst von innovativen Wegen der Produktent- wicklung, gehört zum Lean Management (schlankes Management) und ist mit 54 Prozent (Scrum) die populärste aller agilen Methoden.11
Alle Arten der Software-Entwicklung, wie ein eigenständiges Produkt, ein Produkt im Auftrag eines Kunden, neue Produkte sowie die Wartung vorhandener Produkte sind mit Scrum möglich.12 Erfolgreiche Unternehmen wie Google oder Toyota nutzen Scrum, um das Potenzial der Mitarbeiter voll auszuschöpfen. Der Mensch steht vielmehr im Mittelpunkt und wird nicht nur als Ressource angesehen.13
Es gibt drei interne Rollen, bis zu sechs Akte und bis zu vier Tools, wel- che an klar definierte Regeln gebunden sind. Scrum gilt als empirischer Prozess, bei dem das Produkt und die Arbeitsweise regelmäßig doku- mentiert und angepasst werden. Das fördert und fordert unter anderem die Zusammenarbeit aller Beteiligten. Der dabei entstehende Lernpro- zess betrifft Teammitglieder, Scrum Master, Product Owner und das Management gleichermaßen. Da die Anwendung von Scrum gerade zu Beginn oft Schwierigkeiten bereitet, ist es verlockend Prozesse im Scrum anstatt eigene Arbeitspraktiken zu ändern.
Scrum beinhaltet drei interne Rollen (Product Owner, Scrum Master und Entwickler-Team) die adäquat besetzt sein und deren Träger eng zusammenarbeiten müssen, um Projekte erfolgreich zu gestalten. Der Product Owner (PO) arbeitet mit einem Team, welches von einem ei- genen Scrum Master betreut wird. Das Verständnis der Rollen und die richtige Besetzung sind äußerst wichtig.14 Alle Parteien müssen ihren Beitrag leisten, um Scrum zu leben. In einem Scrum Team steht nicht der einzelne im Vordergrund, sondern alle Teammitglieder sind gleich- ermaßen für Erfolg und Misserfolg verantwortlich. Ein respektvoller und wertschätzender Umgang ist Grundvoraussetzung für die Kommunika- tion innerhalb des Teams. Daher ist es wichtig, dass schon bei der Teamauswahl darauf geachtet wird, welche Kandidaten ihr Ego hinter das Team stellen können.15
Der Product Owner ist für die Planung und Direktion der Produktent- wicklung zuständig. Er trägt die Verantwortung für die Funktionen und die Reihenfolge, in der sie erstellt werden. Außerdem muss er den fi- nanziellen Aufwand in Relation mit den Ergebnissen rechtfertigen und Entscheidungen rund um das Projekt zeitnah treffen. Er arbeitet konti- nuierlich am Product Backlog und kommuniziert dabei auf täglicher Ba- sis mit dem Team.16
Scrum zeichnet sich durch eine hohe Dynamik aus und ist deshalb an- fällig für chaotische Zustände. Dem vorzubeugen obliegt dem Scrum- Master. Bei ihm liegt die Verantwortung für den kompletten Scrum- Prozess und dessen korrekte Implementierung.
Er steht allen Beteiligten unterstützend zur Seite und vermittelt zwi- schen ihnen. Er gewährleistet einen guten Informationsfluss zwischen Product Owner und Team und ist für die Moderation der Scrum- Meetings zuständig. Die Aktualität der Scrum Artefakte (Product Back- log, Sprint Backlog usw.) immer im Blick, schützt er das Team vor unzu- lässigen Störfaktoren während der Sprints. Daher strebt ein kompeten- ter Scrum Master immer die ständige Optimierung an. Trotz all dieser Aufgaben ist er nicht Vorgesetzter, sondern dem Rest des Teams gleichgestellt.17
Das letzte interne Puzzleteil ist das Entwickler-Team. Es ist interdiszip- linär, selbst organisiert und besteht aus fünf bis zehn Personen. Das Entwickler-Team entscheidet selbstständig über das Zerlegen von An- forderungen und die jeweilige Verantwortlichkeit. Täglich treffen sich die Mitglieder im Daily Scrum um sich gegenseitig mit kurzen Statusberich- ten zu informieren. Nach jedem Sprint präsentiert das Team die Umset- zungen in einem Sprint Review Meeting, während die Restaufwände der jeweiligen Aufgaben von jedem Mitglied im Sprint Backlog aktuali- siert werden. Das Entwickler-Team steht im Zentrum des Scrum- Prozesses, da es für die Umsetzung der Anforderungen sorgt.18
Das Projekt beginnt mit einer Vision des Product Owners oder mit ei- nem externen Auftrag. Wenn allen klar ist, was erstellt werden soll, ist der nächste Schritt, die Funktionalitäten des Produktes festzulegen und zu ordnen. Das Product Backlog kann dabei als eine Art Einkaufsliste gesehen werden, welche die vorher bestimmten Funktionen enthält.
Das Product Backlog wird stetig weiter wachsen, sich verändern und ist somit nie vollständig.19 Steht das vorläufige Product Backlog, wird zum Sprint Planning Meeting 1 geladen. Das SPM1 ist ein eintägiges Meeting, in dem der PO dem Entwickler-Team die höchsten Prioritäten des Product Backlogs vor- stellt. Welche Aufgaben während des Sprints erledigt werden können, entscheidet das Entwickler-Team. Außerdem werden Kriterien festge- legt, die für den Abschluss des Sprints ausschlaggebend sind.
Während im SPM1 der Umfang im Sprint Backlog festgehalten wurde, klärt das Sprint Meeting 2, welches das Entwickler-Team in Eigenver- antwortung führt, den technischen Aspekt. Die zerlegten einzelnen Auf- gaben werden dann am sogenannten Taskboard befestigt. Dies trägt zum Überblick der anstehenden Aufgaben und ihrem jeweiligen Status bei. Pro Sprint-Woche sollte das SPM1 ca. 60 Minuten einnehmen. Auch nach dem SPM2 werden die Resultate im Sprint Backlog festge- halten.20
Nach diesen beiden Planning-Meetings beginnt das Entwickler-Team mit dem Implementieren der Funktionalitäten. Während dieser Zeit des eigentlichen Sprints, der höchstens 30 Tage dauert, setzen sich das Entwickler-Team, der PO und der Scrum Master täglich für einen Daily Scrum zusammen. Dabei wird sichergestellt, dass der Sprint erwar- tungsgemäß verläuft und die definierten Ziele erreicht werden. Jedes Teammitglied gibt dabei Auskunft über den Fortschritt seit dem letzten Daily Scrum, den geplanten Fortschritt bis zum nächsten Daily Scrum und darüber, welcher Umstand gegebenenfalls den Fortschritt hemmt. Der Daily Scrum ist kein Bericht für den PO oder Scrum Master, son- dern ein Kommunikationsmeeting innerhalb des Entwickler-Teams. Transparenz, Vertrauen und erhöhte Leistung sind das Resultat, des-
1 Eisenblatt, Lars: ORDIX news. Vierteljahreshefte des IT-Magazins der Ordix AG Ausgabe 2 von 2012, S. 18.
2 Version One: 7th Annual State Of Agile Development Survey. 2013. http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-Survey.pdf
3 Vgl. The Standish Group: Chaos Manifesto 2013. 2013. http://versionone.com/assets/img/files/ChaosManifesto2013.pdf
4 Vgl. Ruf, Walter / Fittkau, Thomas: Ganzheitliches IT-Projektmanagement. München 2008, S. 9-10.
5 Vgl. Ruf, Walter / Fittkau, Thomas: Ganzheitliches IT-Projektmanagement. München 2008, S. 29-32.
6 Ruf, Walter / Fittkau, Thomas: Ganzheitliches IT-Projektmanagement. München 2008, S. 31, Abbildung 10: Wasserfallmodell.
7 IBM: Infocenter, Iterative Entwicklung. http://pic.dhe.ibm.com/infocenter/clmhelp/v3r0/index.jsp?topic=%2Fcom.ibm.team.con cert.doc%2Ftopics%2Fcpracticeiterativedevelopment.html, Stand: 17. Dezember 2013.
8 Vgl. Röpstorff, Sven / Wiechmann, Robert: Scrum in der Praxis. Heidelberg 2012, S. 5-7.
9 Beck, Kent / Beedle, Mike / Cockburn, Alistair u.a.: Manifesto for Agile Software De- velopment. Stand: 18. Dezember 2013. http://agilemanifesto.org/
10 Beck, Kent / Beedle, Mike / Cockburn, Alistair u.a.: Principles behind the Agile Mani- festo. Stand: 18. Dezember 2013. http://agilemanifesto.org/iso/en/principles.html
11 Vgl. Version One: 7th Annual State Of Agile Development Survey. 2013. http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-Survey.pdf
12 Vgl. Pichler, Roman: Scrum - Agiles Projektmanagement erfolgreich einsetzten. Heidelberg 2009. S. 1-8.
13 Vgl. Gloger, Boris: Scrum - Produkte zuverlässig und schnell entwickeln. München 2009. S. 1.
14 Vgl. Pichler, Roman: Scrum - Agiles Projektmanagement erfolgreich einsetzten. Heidelberg 2009. S. 9.
15 Vgl. Röpstorff, Sven / Wiechmann, Robert: Scrum in der Praxis. Heidelberg 2012. S. 26.
16 Vgl. Gloger, Boris: Scrum - Produkte zuverlässig und schnell entwickeln. München 2009. S. 12.
17 Vgl. Kriegisch, Alexander: Scrum-Master.de - Agiles Projektmanagement. Stand: 20. Dezember 2013. http://scrum-master.de/Scrum-Rollen/Scrum-RollenScrumMaster
18 Vgl. Kriegisch, Alexander: Scrum-Master.de - Agiles Projektmanagement. Stand: 20. Dezember 2013. http://scrum-master.de/Scrum-Rollen/Scrum-RollenTeam
19 Vgl. Gloger, Boris: Scrum - Produkte zuverlässig und schnell entwickeln. München 2011. S. 124.
20 Vgl. Techdivision: Agile Projektentwicklung mit Scrum. 2012. http://www.techdivision.com/fileadmin/mediacenter/Dokumente/2012-02-Whitepaper- Scrum.pdf
