Projektmanagement in agilen Projekten nach Scrum

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

1. Einleitung

2. Einführung in agile Projekte und Scrum
2.1 Historische Entwicklung
2.2 Ziele von agilen Projekten
2.3 Grundlagen und Ablauf von Scrum

3. Klassische und agile Ansätze des Projektmanagements
3.1 Einführung
3.2 Methoden des klassischen Projektmanagements
3.2.1 Work Breakdown Structure
3.2.2 Meilenstein-Trend-Analyse
3.2.3 Earned Value Analyse
3.2.4 Risk Log
3.3 Methoden in agilen Projekten
3.3.1 Allgemeine Planungsmethoden
3.3.2 Scrum Board / Kanban Board
3.3.3 Burndown Chart
3.3.4 Team Velocity
3.3.5 Burnup Chart
3.4 Beurteilung der verschiedenen Planungsmethoden
3.5 Möglichkeiten des klassischen Projektmanagements in agilen Projekten

4. Fazit

Literaturverzeichnis

Abkürzungsverzeichnis

PO - Product Owner

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

ABBILDUNG 1: SCHEMATISCHE DARSTELLUNG VON SCRUM

ABBILDUNG 2: BEISPIEL EINER WORK BREAKDOWN STRUCTURE

ABBILDUNG 3: MEILENSTEIN-TREND-ANALYSE

ABBILDUNG 4: BURNDOWN CHART

ABBILDUNG 5: BURNUP CHART

ABBILDUNG 6: DAS MAGISCHE VIERECK IN SCRUM

ABBILDUNG 7: SCRUM MIT MEILENSTEINPLANUNG

1. Einleitung

Utah, im Februar 2001: Siebzehn Vertreter aus verschiedenen Disziplinen der Software-Ent-wicklung diskutieren gemeinsam über die Grundsätze zukünftiger Softwareprojekte. Sie ver-fassen das Agile Manifest, welches die Trends der letzten Dekade zusammenfasst.¹ Seit Be-ginn der 1990er Jahre hatten Methoden wie Extreme Programming, Scrum oder AdaptiveSoftware Development mehr und mehr Relevanz gewonnen. Das Agile Manifest vereint nundie Prinzipien, welche all diese Methoden gemein haben. Sie stehen dabei im Kontrast zuden traditionellen Vorgehensweisen der Software-Entwicklung, allem voran dem Wasserfall-Modell.

Ausführliche Dokumentation und Planung gibt es der Lehre nach in agilen Projekten nicht. Vielmehr wird in kurzfristigen Zeiträumen gedacht, um anpassungsfähig und flexibel zu sein. Viele Aufgaben des klassischen Projektmanagements existieren in agilen Methoden zudem nicht. Dagegen wird vom Project Management Institute (PMI) gerade die Planung und Steuerung von Projekten als Kernkompetenz des Projektmanagements definiert.² Auf den ersten Blick findet man hier also zwei unvereinbare Positionen vor.

Im Rahmen dieser Arbeit soll untersucht werden, wie im klassischen Projektmanagementund im agilen Vorgehen Projekte geplant werden. Welche Vor- und Nachteile haben die ein-zelnen Tools? Gibt es Situationen, in denen agile Projekte von Methoden aus dem Projekt-management profitieren können? Sind sie vielleicht sogar unter bestimmten Voraussetzun-gen unabdingbar?

Hierfür wird zunächst das agile Vorgehen vorgestellt. Anschließend werden einige Methoden aus dem klassischen Projektmanagement und dem agilen Vorgehen nach Scrum herausgearbeitet. Nach einer Beurteilung der beiden Modelle soll schließlich geklärt werden, ob eine Synthese aus beiden Philosophien möglich ist. Als Basis dient Fachliteratur aus den Disziplinen Projektmanagement und agile Methoden. Darüber hinaus wird auch in der Praxis erworbenes Wissen eingebracht und mit den theoretischen Inhalten verknüpft.

2. Einführung in agile Projekte und Scrum

2.1 Historische Entwicklung

Das agile Vorgehen umfasst eine Vielzahl von Methoden. Im Rahmen dieser Arbeit wird derFokus der Untersuchung auf das Vorgehensmodell Scrum begrenzt. Der Begriff selbststammt aus dem Rugby-Sport und steht dort für das so genannte Gedränge von Spielern. DieAnfänge von Scrum lassen sich bereits 1986 finden. In der Januar-Ausgabe des Harvard Bu-siness Review dieses Jahres veröffentlichten Hirotaka Takeuchi und Ikujiro Nonaka einenArtikel, in dem sie die Grundzüge eines neuen Projektmanagement-Ansatzes beschrieben.Entgegen dem vorherrschenden sequentiellen Ansatz sollten nach Takeuchi und Nonakaselbstorganisierte, lernende Teams in sich überlappenden Entwicklungsphasen schneller zumErfolg führen.³ In den folgenden Jahren griffen mehr und mehr Experten den Begriff auf undentwickelten die Besonderheiten von Scrum weiter. So formulierte Jeff Sutherland, spätereiner der Unterzeichner des Agilen Manifests, einen Satz, der die Grundidee von Scrum pas-send zusammenfasst:

„Scrum akzeptiert, dass der Entwicklungsprozess nicht vorherzusehen ist. Das Produkt ist die bestmögliche Software unter Berücksichtigung der Kosten, der Funktionalität, der Zeit und der Qualität.“⁴

In den 2000er-Jahren veröffentlichten dann weitere Unterzeichner des Agilen Manifests zahl-reiche Grundlagenwerke. Vor allem Ken Schwaber setzte mit seinen drei Werken „AgileSoftware Development with Scrum“ (2001), „Agile Project Management with Scrum“(2003) und „The Enterprise and Scrum“ (2007) viele Akzente in der frühen Entwicklungs-phase. Bis zum heutigen Tag hat sich Scrum als eine der wichtigsten agilen Methoden wei-terentwickelt und spielt in einer Vielzahl von Unternehmen eine wichtige Rolle im Projekt-alltag.

2.2 Ziele von agilen Projekten

Agile Projekte tragen dieses Adjektiv nicht ohne Grund. In vielen Bereichen erfordern sie Schnelligkeit: Die Schnelligkeit zu liefern, zu entscheiden, zu denken und handeln und vor allem zu verändern.⁵ Alle agilen Vorgehensweisen basieren auf dem bereits erwähnten Agilen Manifest, welches vier Prinzipien beinhaltet:

- Individuen und Interaktionen vor Prozessen und Werkzeugen
- Funktionierende Software vor umfassender Dokumentation
- Zusammenarbeit mit dem Kunden vor Vertragsverhandlungen
- Reagieren auf Veränderung vor dem Befolgen eines Plans

Das bedeutet nicht, dass die Werte auf der rechten Seite nicht beachtet werden - die Werte auf der linken Seite sind lediglich wichtiger einzuschätzen.⁶

Die Idee hinter dem Agilen Manifest ist, dass die Faktoren auf der linken Seite wesentlichmehr zum Erfolg eines Projektes beitragen als die auf der rechten Seite. Mitarbeiter und ihreInteraktionen erschaffen Mehrwert in einem Projekt. Eine funktionierende Basis-Software,die später erweitert werden kann, ist für den Kunden wichtiger als ein nicht funktionsfähigesKomplettpaket. Eine enge, regelmäßige und lösungsorientierte Zusammenarbeit trägt mehrzum Erfolg bei als die Umsetzung hart vorgegebener Kriterien aus Vertragsverhandlungen.Und weil während der Vertragsverhandlungen und auch noch zu Beginn eines Projektes vieleEinflussfaktoren gar nicht bekannt sind, ist das kontinuierliche Reagieren auf neue Anforde-rungen hilfreicher als die sture Abfolge eines zu Beginn definierten Plans. Der Fokus desagilen Vorgehens beruht auf der dauerhaften, iterativen Annäherung an das Endergebnis.

2.3 Grundlagen und Ablauf von Scrum

Im Vorgehen nach Scrum gibt es drei Rollen:

- Product Owner (PO): Der Product Owner ist verantwortlich für die Gestaltung desProduktes. Er hat eine Vision der Lösung und entscheidet eigenständig über die In-halte und Eigenschaften, die das Produkt besitzen soll. Die Inhalte und Eigenschaftenwerden in Dokumenten (User Stories) festgehalten. Die User Stories werden in sogenannten EPICs funktional kategorisiert Die Summe dieser EPICs, die letztendlichdie Gesamtheit der noch zu entwickelnden Funktionalitäten bestimmen, bezeichnetman als Product Backlog.
- Development Team (DevTeam): Das Development Team ist ein selbstorganisiertesTeam aus drei bis neun Mitgliedern, welches die vom Product Owner vorgegebenenInhalte umsetzt. In der Art und Weise der Umsetzung ist das Team frei und handeltauf keinerlei Anweisung von außen.
- Scrum Master (SM): Der Scrum Master stellt die Einhaltung der Methodik sicher. Erist ein servant leader, also ein „dienender Anführer“, der auftretende Probleme be-hebt und die Arbeit des Development Team unterstützt (engl. facilitate).

Außerhalb von Scrum liegen die Stakeholder. Dies können Endanwender, Kunden oder auch das Management des Unternehmens sein. Der Product Owner steht in engem Kontakt mit den Stakeholdern, um die verschiedenen Vorstellungen über das Produkt verstehen zu können. Gleichzeitig begleiten die Stakeholder den Fortschritt des Projektes beispielsweise durch die Teilnahme an Präsentationen neuer Funktionalitäten.

Scrum basiert wie viele agile Methoden auf so genannten Sprints. Ein Sprint läuft immerüber einen fest definierten Zeitraum von ein bis vier Wochen und kann nicht verlängert oderverkürzt werden. Vor einem Sprint entscheidet der Product Owner, welche Funktionalitätenin diesem Sprint umgesetzt werden sollen. Dazu sortiert er aus dem Product Backlog die UserStories in das Sprint Backlog und priorisiert diese. Das Development Team weiß nun, inwelcher Reihenfolge welche Funktionalitäten umzusetzen sind. Im Sprint Planning wird nunder geschätzte Aufwand für die Umsetzung aller Stories im Sprint Backlog gegen die Kapa- zität des Development Teams in diesem Sprint gehalten. So wird entschieden, was im kommenden Sprint in welcher Form umgesetzt werden kann und soll. Anschließend ist im Regelfall keine Änderung mehr möglich. Während des Sprints trifft sich das Development Team im so genannten Daily Scrum täglich für ca. 15 Minuten. Es wird von jedem Entwickler kurz ein Überblick gegeben, welchen Tätigkeiten er gerade nachgeht und ob dabei Probleme aufgetreten sind. Nach Ende des Sprints wird im Sprint Review vom Development Team vorgestellt, was in diesem Sprint erreicht wurde. Hieran nehmen auch Stakeholder teil. Zuletzt werden in der Sprint Retrospektive die bisherige Arbeitsweise kritisch hinterfragt und Optimierungspotential diskutiert und erschlossen. Jeder Sprint schließt unmittelbar an den nächsten an, sodass eine kontinuierliche Entwicklung ermöglicht wird.

Abbildung in dieser Leseprobe nicht enthalten

ABBILDUNG 1: SCHEMATISCHE DARSTELLUNG VON SCRUM⁷

3. Klassische und agile Ansätze des Projektmanagements

3.1 Einführung

Das Vorgehen nach Scrum bringt viele Vorteile für Projekte mit sich: Flexibilität, angemes-sener Umgang mit Komplexität und Unvorhersehbarkeiten, eigenverantwortliche und krea-tive Arbeitsweise sowie intensive Zusammenarbeit im Team. All das kann dazu beitragen, dass der Kunde eine Lösung erhält, die für ihn am Ende wertvoller ist, als er bei Vertragsabschluss erwartet hatte.⁸ Gleichzeitig ist die klassische Definition von „wertvoll“ im Zusammenhang mit dem Abschluss von Projekten - innerhalb des Budgets, der Zeit, der Qualität und des Umfangs - zu hinterfragen.⁹ Wenn nach Abschluss eines Projekts die Projektmitglieder wegen Unzufriedenheit, Intransparenz, Inflexibilität das Unternehmen verlassen, ist der Erfolg eines Projekts sicherlich differenzierter zu bewerten.¹⁰

Dennoch kann es in Projekten durchaus zu Situationen kommen, in denen Planung und Kon-trolle wichtig sind. Grundsätzlich verringert eine gute Planung die Wahrscheinlichkeit fürUnsicherheiten und verbessert die Effizienz durch Auslastungssteuerung.¹¹ Eine Studie desInternational Benchmark Council hat über 5.000 Projekte untersucht und kam zum Ergebnis,dass 18 bis 36% der Projekte mit guter Planung vorzeitig abgeschlossen werden.¹² Dies lässtsich damit begründen, dass Projekte mit schlechter Planung im Nachhinein ein hohes Maßan Mehrarbeit benötigen, um die Defizite in der Ausbalancierung von Kosten, Zeit, Qualitätund Umfang auszugleichen. Gleiches gilt für die Kontrolle eines Projektes. Hier kann früh-zeitiges Erkennen und Gegensteuern durch den Projektmanager eine weitere Verschlechte-rung des Projektes verhindern.

Die Frage, die sich hier zunächst stellt, ist, welche Ansätze das klassische Projektmanage-ment verfolgt, um ein Projekt erfolgreich abzuliefern. Und was wird stattdessen in agilenProjekten durchgeführt, um die Ergebnisse erwartungsgemäß zu erreichen oder zu übertref-fen?

3.2 Methoden des klassischen Projektmanagements

3.2.1 Work Breakdown Structure

Im klassischen Projektmanagement wird nach der Definition des Projektes zunächst ein Projektplan ausgearbeitet.¹³ Arbeitsabläufe, Aufwände und Ressourcen für jeden Arbeitsschritt werden hier vom Beginn bis zum Abschluss des Projekts dargestellt.

Eine Möglichkeit, die Erkenntnisse darzustellen, ist die so genannte Work Breakdown Struc-ture (WBS). In dieser Methode werden alle Aktivitäten in kleinere, ausführbare Schritte ein-geteilt. Dies führt dazu, dass zum einen das oft abstrakte Projektziel in konkrete und über-schaubare Einzelteile überführt wird. Zum anderen steigert die WBS die Motivation der ein-zelnen Mitarbeiter, denn durch die Erreichung von kleineren Zwischenzielen wird der Fort-schritt am Gesamtprojekt deutlich. Die Qualität der WBS ist ein wichtiger Schritt zur Planungvon Projekten.¹⁴

Abbildung in dieser Leseprobe nicht enthalten

ABBILDUNG 2: BEISPIEL EINER WORK BREAKDOWN STRUCTURE¹⁵

Die Abfolge der Arbeitsschritte erfolgt in Abhängigkeit von der Fertigstellung anderer Ar-beitsschritte. So ist sichergestellt, dass eine Tätigkeit erst dann beginnt, wenn alle anderenTätigkeiten, die für den Beginn notwendig sind, abgeschlossen wurden. Gleichzeitig ist esfür die Planung notwendig, eine Aufwandsschätzung der Tätigkeiten durchzuführen. Die ein-zelnen Arbeitsschritte werden auf der Basis von Erfahrungen, Expertenmeinungen und Da-tenanalysen geschätzt.¹⁶ Der kritische Pfad kann so bestimmt werden. Für die weitere Kon-trolle ist es essentiell, alle Tätigkeiten auf dem kritischen Pfad genauestens zu betrachten, dasonst Verzögerungen im Gesamtprojekt die Folge sind.¹⁷ Die Arbeitsschritte der WBS kön-nen beispielsweise in einem Gantt-Chart abgebildet werden, um alle Abhängigkeiten und denkritischen Pfad zu visualisieren.¹⁸

Diese beiden Tools stellen Grundlagen dar, welche im Projektplan enthalten sein können.Der weitere Fortschritt des Projektes und somit auch die Leistung des Projektmanagers wer-den anhand des Projektplans gemessen.¹⁹ Da der Projektplan den vollständigen Ablauf sowieKosten-, Fortschritts- und Arbeitsschrittdarstellungen enthält, hat er zwar einen relativ fina-len Charakter. Trotzdem sind Änderungen auf Grund neuer Entwicklungen möglich.²⁰

3.2.2 Meilenstein-Trend-Analyse

Eine weitere Möglichkeit zur Verfolgung des Projektfortschritts ist die Meilenstein-Trend-Analyse. Diese baut auf den in der WBS definierten Arbeitselementen auf. Die tatsächlichen Erreichungsdaten wichtiger Eckpfeiler und Bedingungen des Projektes werden hier in Relation mit dem geplanten Erreichungsdaten gesetzt. So entsteht eine Übersicht, die auf einen Blick erkennen lässt, in welche Richtung sich der Trend bewegt. Davon können anschließend Folgemaßnahmen abgeleitet werden.²¹

[...]

¹ Vgl. Beck et al: Manifesto for Agile Software Development, http://agilemanifesto.org/history.html

² Vgl. PMI: A Guide to the Project Management Body of Knowledge: S. 5

³ Vgl. Takeuchi und Nonaka: Harvard Business Review https://hbr.org/1986/01/the-new-new-product-devel-opment-game

⁴ Gloger: Scrum. Produkte zuverlässig und schnell entwickeln, S. 19.

⁵ Vgl. Canty: Agile for Project Managers, S. 1; Kuster et al: Handbuch Projektmanagement, S. 35

⁶ Vgl. Beck et al: Manifesto for Agile Software Development: http://agilemanifesto.org/; Canty: Agile forProject Managers. S. 9-11

⁷ Eigene Darstellung

⁸ Vgl. Verzuh: The Fast Forward MBA in Project Management, S. 22; Canty: Agile for Project Managers, S. 3-5; PMI - A Guide to the Project Management Body of Knowledge, S.3

⁹ Vgl. PMI - A Guide to the Project Management Body of Knowledge, S. 35; Verzuh: The Fast Forward MBA in Project Management, S. 19f

¹⁰ Vgl. Crowder und Friess: Agile Project Management: Managing for Success, S. 65

¹¹ Vgl. Wysocki: Effective Project Management: Traditional, Agile, Extreme, S. 145

¹² Vgl. ebd., S. 143

¹³ Vgl. Maylor: Project Management, S. 131; Kuster et al: Handbuch Projektmanagement, S. 20f

¹⁴ Vgl. Maylor: Project Management, S. 133; Kuster et al: Handbuch Projektmanagement, S. 24; Wysocki: Effective Project Management: Traditional, Agile, Extreme, S. 160

¹⁵ Eigene Darstellung

¹⁶ Vgl. Canty: Agile for Project Managers, S. 5; Verzuh: The Fast Forward MBA in Project Management, S.185ff; Maylor: Project Management, S. 135f; PMI - A Guide to the Project Management Body of Knowledge, S. 147f

¹⁷ Vgl. Maylor: Project Management, S. 138

¹⁸ Vgl. Verzuh: The Fast Forward MBA in Project Management, S. 164

¹⁹ Vgl. ebd., S. 94

²⁰ Vgl. Kuster et al: Handbuch Projektmanagement, S. 52

²¹ Vgl Wysocki: Effective Project Management: Traditional, Agile, Extreme, S. 279f