Inhaltsverzeichnis

Cover
Titelseite
Impressum
Über den Autoren
1. Widmung
2. Danksagungen
Einleitung
1. Über dieses Buch
2. Törichte Annahmen über den Leser
3. Symbole, die in diesem Buch verwendet werden
4. Über dieses Buch hinaus
5. Wie es weitergeht
Teil I: Agilität verstehen
1. Kapitel 1: Projektmanagement modernisieren
  1. Projektmanagement braucht eine gründliche Veränderung
  2. Einführung in agiles Projektmanagement
2. Kapitel 2: Das Agile Manifest und die Prinzipien anwenden
  1. Das Agile Manifest verstehen
  2. Die vier Werte des Agilen Manifests umreißen
  3. Die 12 Agilen Prinzipien definieren
  4. Die Platinum-Prinzipien ergänzen
  5. Veränderungen als Ergebnis agiler Werte
  6. Der agile Lackmustest
3. Kapitel 3: Warum Agilität besser funktioniert
  1. Agile Vorteile bewerten
  2. Wie agile Ansätze historische Ansätze übertreffen
  3. Warum Leute gern agil sind
Teil II: Agil sein
1. Kapitel 4: Agile Ansätze
  1. Gemeinsamkeiten agiler Ansätze
  2. Die großen Drei im Überblick: Lean, Scrum und Extreme Programming
  3. Die Einzelteile zusammenbringen
2. Kapitel 5: Agile Umgebungen in Aktion
  1. Das Arbeitsumfeld erzeugen
  2. Lowtech-Kommunikation
  3. Hightech-Kommunikation
  4. Werkzeuge auswählen
3. Kapitel 6: Agiles Verhalten in Aktion
  1. Agile Rollen kennenlernen
  2. Neue Werte etablieren
  3. Teamphilosophie verändern
Teil III: Agile Planung und Durchführung
1. Kapitel 7: Die Produktvision und Produkt-Roadmap definieren
  1. Agile Planung
  2. Produktvision definieren
  3. Produkt-Roadmap erstellen
  4. Das Produkt-Backlog fertigstellen
2. Kapitel 8: Releases und Sprints planen
  1. Anforderungen und Schätzungen präzisieren
  2. Release-Planung
  3. Sprint-Planung
3. Kapitel 9: Arbeit im Laufe eines Tages
  1. Planen Sie Ihren Tag: Daily Scrum
  2. Fortschritt verfolgen
  3. Agile Rollen im Sprint
  4. Auslieferfähige Funktionalität erstellen
  5. Das Ende des Tages
4. Kapitel 10: Arbeit präsentieren, Prozesse überprüfen und anpassen
  1. Das Sprint-Review
  2. Die Sprint-Retrospektive
5. Kapitel 11: Das Release vorbereiten
  1. Das Produkt für die Bereitstellung präparieren: Der Release-Sprint
  2. Vorbereitungen für operativen Support
  3. Die Organisation für die Bereitstellung des Produkts vorbereiten
  4. Den Markt auf das Produkt vorbereiten
Teil IV: Agiles Management
1. Kapitel 12: Umfang und Beschaffung managen
  1. Was ist anders an agilem Umfangsmanagement?
  2. Agilen Umfang managen
  3. Was ist anders an agilem Beschaffungsmanagement?
  4. Agile Beschaffung managen
2. Kapitel 13: Zeit und Kosten managen
  1. Was ist anders an agilem Zeitmanagement?
  2. Agile Zeitpläne managen
  3. Was ist anders an agilem Kostenmanagement?
  4. Agile Budgets managen
3. Kapitel 14: Teamdynamik und Kommunikation managen
  1. Was ist anders an agiler Teamdynamik?
  2. Agile Teamdynamik managen
  3. Was ist anders an agiler Kommunikation?
  4. Agile Kommunikation managen
4. Kapitel 15: Qualität und Risiko managen
  1. Was ist anders an agilem Qualitätsmanagement?
  2. Agile Qualität managen
  3. Was ist anders an agilem Risikomanagement?
  4. Agile Risiken managen
Teil V: Agilen Erfolg sicherstellen
1. Kapitel 16: Die Grundlagen schaffen
  1. Verpflichtung der Organisation und der Individuen
  2. Die richtigen Teammitglieder für das Pilotprojekt auswählen
  3. Ein Umfeld erzeugen, das Agilität ermöglicht
  4. Unterstützen Sie Agilität anfänglich und auf Dauer
2. Kapitel 17: Agile Skalierung über mehrere Teams
  1. Agile Projekte mit mehreren Teams
  2. Arbeit durch vertikalen Schnitt leichter verdaulich machen
  3. Abstimmung durch Rollen mit Scrum at Scale
  4. Multi-Team-Koordination mit LeSS
  5. Abhängigkeiten mit Nexus reduzieren
  6. Gemeinsame Programmplanung mit SAFe
  7. Modulare Strukturen mit Enterprise Scrum
3. Kapitel 18: Ein Change Agent sein
  1. Agil zu werden, erfordert Veränderung
  2. Warum Veränderung nicht von selbst geschieht
  3. Strategische Ansätze zur Implementierung und zum Management von Veränderung
  4. Change-Roadmap von Platinum Edge
  5. Stolperfallen vermeiden
  6. Zeichen, dass Ihre Veränderungen nachlassen
Teil VI: Der Top-Ten-Teil
1. Kapitel 19: Zehn wesentliche Vorteile des agilen Projektmanagements
  1. Bessere Produktqualität
  2. Höhere Kundenzufriedenheit
  3. Reduziertes Risiko
  4. Bessere Zusammenarbeit und höhere Verantwortlichkeit
  5. Aussagekräftigere Kennzahlen
  6. Bessere Sichtbarkeit der Leistung
  7. Bessere Projektkontrolle und Projektsteuerung
  8. Verbesserte Projektvorhersehbarkeit
  9. Maßgeschneiderte Teamstrukturen
  10. Bessere Teammoral
2. Kapitel 20: Zehn entscheidende Faktoren für den Erfolg agiler Projekte
  1. Dedizierte Teammitglieder
  2. Co-Location
  3. Automatisiertes Testen
  4. Definition of Done befolgen
  5. Deutliche Produktvision und Produkt-Roadmap
  6. Product Owner mit Vollmachten
  7. Vielseitige Entwickler
  8. Scrum Master mit Einfluss
  9. Managementunterstützung für Weiterbildung
  10. Unterstützung beim Übergang
3. Kapitel 21: Zehn Kennzahlen für agile Organisationen
  1. Return on Investment
  2. Umfragen zur Zufriedenheit
  3. Defekte in der Produktion
  4. Sprintziel-Erfolgsquoten
  5. Produkteinführungszeit – Time to Market
  6. Durchlaufzeit und Entwicklungsdauer
  7. Kostenaufwand für Änderungen
  8. Fluktuation im Team
  9. Vielseitigkeit der Qualifikationen
  10. Verhältnis Manager-Produktersteller
4. Kapitel 22: Zehn wertvolle Ressourcen für agile Profis
  1. Downloads zu »Agiles Projektmanagement für Dummies«
  2. Scrum for Dummies
  3. The Scrum Alliance
  4. The Agile Alliance
  5. Agile Community des Project Management Institute
  6. International Consortium for Agile (ICAgile)
  7. InfoQ
  8. Lean Enterprise Institute
  9. Extreme Programming
  10. Platinum Edge
Stichwortverzeichnis
End User License Agreement

Tabellenverzeichnis

Kapitel 2
1. Tabelle 2.1: Individuen und Interaktionen versus Prozesse und Werkzeuge
2. Tabelle 2.2: Nützliche Dokumentationen ermitteln
3. Tabelle 2.3: Kundenunzufriedenheit und wie Agilität helfen kann
4. Tabelle 2.4: Traditionelles und agiles Projektmanagement im Vergleich
Kapitel 4
1. Tabelle 4.1: Wichtige Praktiken bei Extreme Programming
2. Tabelle 4.2: Ähnlichkeiten zwischen Lean, Scrum und Extreme Programming
Kapitel 5
1. Tabelle 5.1: Verbreitete Ablenkungen
Kapitel 6
1. Tabelle 6.1: Eigenschaften eines guten Product Owners
2. Tabelle 6.2: Eigenschaften eines guten Mitglieds des Entwicklungsteams
3. Tabelle 6.3: Eigenschaften eines guten Scrum Masters
Kapitel 8
1. Tabelle 8.1: Untergliedern einer Anforderung
Kapitel 9
1. Tabelle 9.1: Häufig auftretende Hindernisse und deren Lösungen
Kapitel 11
1. Tabelle 11.1: Elemente in Entwicklungssprints und in Release-Sprints
Kapitel 12
1. Tabelle 12.1: Traditionelles und agiles Umfangsmanagement im Vergleich
2. Tabelle 12.2: Agile Artefakte und deren Funktion beim Umfangsmanagement
3. Tabelle 12.3: Traditionelles und agiles Beschaffungsmanagement im Vergleich
Kapitel 13
1. Tabelle 13.1: Traditionelles und agiles Zeitmanagement im Vergleich
2. Tabelle 13.2: Agile Artefakte und Zeitmanagement
3. Tabelle 13.3: Traditionelles und agiles Kostenmanagement im Vergleich
4. Tabelle 13.4: Beispiel eins Scrum-Team-Budgets für einen zweiwöchigen Sprint
5. Tabelle 13.5: Einnahmen aus einem traditionellen Projekt mit einer finalen Version nach sechs Monaten
6. Tabelle 13.6: Einnahmen aus einem Projekt mit monatlichen Releases und einer finalen Version nach sechs Monaten
Kapitel 14
1. Tabelle 14.1: Traditionelle und agile Teamdynamik im Vergleich
2. Tabelle 14.2: Projektmanagement und selbstverwaltete Teams
3. Tabelle 14.4: Traditionelle und agile Kommunikation im Vergleich
4. Tabelle 14.5: Kommunikationskanäle in agilen Projekten
Kapitel 15
1. Tabelle 15.1: Qualität in traditionellen und agilen Ansätzen im Vergleich
2. Tabelle 15.2: Risiko in traditionellen und agilen Ansätzen im Vergleich
3. Tabelle 15.3: Einnahmen aus einem traditionellen Projekt mit einer finalen Version nach sechs Monaten
4. Tabelle 15.4: Einnahmen aus einem Projekt mit monatlichen Releases und einer finalen Version nach sechs Monaten
5. Tabelle 15.5: Kosten des Scheiterns bei einem Wasserfallprojekt
6. Tabelle 15.6: Kosten des Scheiterns bei einem agilen Projekt
7. Tabelle 15.7: Werkzeuge für das Risikomanagement in agilen Projekten
Kapitel 18
1. Tabelle 18.1: Häufig auftretende Probleme bei der agilen Transformation und mögliche Lösungen
Kapitel 21
1. Tabelle 21.1: ROI bei einem traditionellen Projekt
2. Tabelle 21.2: ROI bei einem agilen Projekt

Illustrationsverzeichnis

Kapitel 1
1. Abbildung 1.1: Tatsächliche Nutzung angeforderter Softwarefeatures
2. Abbildung 1.2: Zeitstrahl des agilen Projektmanagements
3. Abbildung 1.3: Wasserfall und agiles Projekt im Vergleich
Kapitel 2
1. Abbildung 2.1: Möglichkeiten für Veränderungen in traditionellen Projekten
2. Abbildung 2.2: Diagramme, Grafiken und Dashboards für Projektstatusberichte verwenden
Kapitel 3
1. Abbildung 3.1: Ein Vergleich von historischem Projektmanagement und agilen Konzepten
2. Abbildung 3.2: Beim Wasserfallprojektzyklus handelt es sich um eine lineare Methode.
3. Abbildung 3.3: Agile Ansätze verwenden einen iterativen Projektzyklus.
4. Abbildung 3.4: Stabilität und Flexibilität bei agilen Projekten
5. Abbildung 3.5: Ein Risiko- und Kostendiagramm, das Wasserfall und agile Methoden vergleicht
Kapitel 4
1. Abbildung 4.1: Frühe Hardware und Software
2. Abbildung 4.2: Der Ursprung des Wasserfalls
3. Abbildung 4.3: Iteration im Wasserfallmodell
4. Abbildung 4.4: Der Scrum-Ansatz
5. Abbildung 4.5: Sprints sind sich wiederholende Prozesse.
Kapitel 5
1. Abbildung 5.1: Bessere Kommunikation durch Co-Location
2. Abbildung 5.2: Ein Scrum-Taskboard an einer Wand oder auf einem Whiteboard
Kapitel 6
1. Abbildung 6.1: Agiles Projektteam, Scrum-Team und Entwicklungsteam
Kapitel 7
1. Abbildung 7.1: Phasen der agilen Planung und Ausführung anhand der Roadmap to Value
2. Abbildung 7.2: Das Product Vision Statement als Teil der Roadmap to Value
3. Abbildung 7.3: Erweiterung von Moores Vorlage für ein Vision Statement
4. Abbildung 7.4: Die Produkt-Roadmap als Teil der Roadmap to Value
5. Abbildung 7.5: Nach Themes gruppierte Features
6. Abbildung 7.6: Produkt-Roadmap mit sortierten Anforderungen
7. Abbildung 7.7: Beispiele für Einträge im Produkt-Backlog
Kapitel 8
1. Abbildung 8.1: Beispiel einer User Story auf Karteikarte
2. Abbildung 8.2: Beispiele für User Stories
3. Abbildung 8.3: Ein Kartenspiel für Schätz-Poker
4. Abbildung 8.4: Story-Größen als T-Shirt-Größen und ihre Fibonacci-Zahl
5. Abbildung 8.5: Release-Planung als Teil der Roadmap to Value
6. Abbildung 8.6: Beispiel für einen Release-Plan
7. Abbildung 8.7: Sprint-Planung als Teil der Roadmap to Value
8. Abbildung 8.8: Beispiel für ein Sprint-Backlog
9. Abbildung 8.9: Verhältnis zwischen Sprint Planning Meeting und Sprint-Dauer
Kapitel 9
1. Abbildung 9.1: Sprint und Daily Scrum in der Roadmap to Value
2. Abbildung 9.2: Beispiel für ein Sprint-Backlog
3. Abbildung 9.3: Ein Burndown-Diagramm
4. Abbildung 9.4: Typische Muster von Burndown-Diagrammen
5. Abbildung 9.5: Beispiel für ein Taskboard
6. Abbildung 9.6: Überprüfung einer User Story
Kapitel 10
1. Abbildung 10.1: Das Sprint-Review in der Roadmap to Value
2. Abbildung 10.2: Feedbackschleifen in agilen Projekten
3. Abbildung 10.3: Verhältnis zwischen Dauer des Sprint-Review-Meetings und der Dauer des Sprints
4. Abbildung 10.4: Die Sprint-Retrospektive in der Roadmap to Value
5. Abbildung 10.5: Verhältnis zwischen Dauer des Sprint-Retrospektive-Meetings und der Dauer des Sprints
Kapitel 11
1. Abbildung 11.1: Teammodell für operativen Support
Kapitel 12
1. Abbildung 12.1: Die Roadmap to Value
2. Abbildung 12.2: Eine neue Anforderung in das Produkt-Backlog einfügen
Kapitel 14
1. Abbildung 14.1: E-Mail versus persönliches Gespräch
2. Abbildung 14.2: Vergleich verschiedener Kommunikationsformen
3. Abbildung 14.3: Typische Muster von Burndown-Diagrammen
Kapitel 15
1. Abbildung 15.1: Feedback zur Qualität in einem agilen Projekt
2. Abbildung 15.2: Testen in jedem Sprint
3. Abbildung 15.3: Eine User Story und ihre Akzeptanzkriterien
4. Abbildung 15.4: »2015 Chaos Report« der Standish Group
5. Abbildung 15.5: Modell der abnehmenden Risiken bei agilen Projekten
6. Abbildung 15.6: Beispiel für eine Definition of Done
Kapitel 16
1. Abbildung 16.1: Aufeinander abgestimmte Abläufe des agilen Transition-Teams und des Scrum-Teams für das Pilotprojekt
2. Abbildung 16.2: Die Roadmap to Value
Kapitel 17
1. Abbildung 17.1: Scrum-Teams, die an vertikalen Scheiben von Produktfeatures arbeiten, am Beispiel von Microsoft Office
2. Abbildung 17.2: Scrum of Scrums zur Koordination zwischen Scrum-Teams
3. Abbildung 17.3: Scrum-of-Scrums-Modell in Scrum at Scale
4. Abbildung 17.4: Scrum-of-Scrums-of-Scrums-Modell in Scrum at Scale
5. Abbildung 17.5: Dritte Ebene des Scrum-of-Scrums-of-Scrums-Modells aus Agile at Scale mit einem Executive Action Team (EAT).
6. Abbildung 17.6: Meta-Scrum für Product Owner in Scrum at Scale
7. Abbildung 17.7: Dritte Ebene des Meta-Scrum-Modells aus Agile at Scale mit einem Executive Meta Scrum (EMS)
8. Abbildung 17.8: Ausrichtung der dritten Ebene des Scrum-of-Scrums-of-Scrums- und Meta-Scrum-Modells aus Agile at Scale.
9. Abbildung 17.9: Das Basisframework von LeSS
10. Abbildung 17.10: Das LeSS-Huge-Framework
11. Abbildung 17.11: Das Nexus-Framework
12. Abbildung 17.12: SAFe 4.5 für Lean Software- und Systementwicklung
13. Abbildung 17.13: Die Essential SAFe-Konfiguration
14. Abbildung 17.14: ES-Canvas für skalierte Softwareentwicklung
Kapitel 18
1. Abbildung 18.1: Das 3-Phasen-Modell (Auftauen, Ändern, Einfrieren) von Kurt Lewin
2. Abbildung 18.2: Platinum Edge Transition-Roadmap
3. Abbildung 18.3: Projekte, die von agilen Techniken profitieren können
4. Abbildung 18.4: Modell für Veränderungen nach Satir

Agiles Projektmanagement für Dummies

Schummelseite

EIN MANIFEST FÜR AGILE SOFTWAREENTWICKLER

Das Manifest für agile Softwareentwicklung, auch als Agiles Manifest bekannt, ist eine absichtlich knapp gehaltene Beschreibung der Grundwerte des agilen Projektmanagements. Verwenden Sie dieses Manifest als Leitfaden, um agile Methoden in Ihren Projekten zu implementieren.

»Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen.

Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und ihre Interaktionen stehen über Prozessen und Werkzeugen
Funktionierende Software steht über einer umfassenden Dokumentation
Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung
Reagieren auf Veränderung steht über dem Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

© 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

This declaration may be freely copied in any form, but only in its entirety through this notice.

DIE 12 AGILEN PRINZIPIEN

Die Prinzipien hinter dem Agilen Manifest, im Allgemeine als die 12 agilen Prinzipien bezeichnet, ist ein Satz von Richtlinien, die Projektteams bei der Implementierung agiler Projekte unterstützen. Verwenden Sie diese Prinzipien als Lackmustest, um zu entscheiden, ob Sie in Ihrer Projektarbeit und in Ihrem Denken agil sind oder nicht.

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.
Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
Fachexperten und Entwickler müssen während des Projekts täglich zusammenarbeiten.
Baue Projekte rund um motivierte Individuen auf. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen.
Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist das persönliche Gespräch.
Funktionierende Software ist das wichtigste Fortschrittsmaß.
Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein konstantes Tempo auf unbegrenzte Zeit halten können.
Ständiges Augenmerk auf hohe technische Qualität und gutes Design fördert Agilität.
Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.
Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt daraufhin sein Verhalten entsprechend an.

DER AGILE PLATINUM-EDGE-WERTSCHÖPFUNGSPLAN

Die Roadmap to Value, der Wertschöpfungsplan, ist eine allgemeine Darstellung eines agilen Projekts. Die verschiedenen Phasen der Roadmap to Value sind in der Liste beschrieben, die nach dieser Abbildung folgt.

In Phase 1 identifiziert der Product Owner die Produktvision. Die Produktvision definiert, was Ihr Produkt ist, wie das Produkt Ihre Firmen- oder Organisationsstrategie unterstützt und wer das Produkt verwendet. Überprüfen Sie bei länger dauernden Projekten die Produktvision mindestens einmal jährlich.
In Phase 2 erstellt der Product Owner eine Produkt-Roadmap. Bei der Produkt-Roadmap handelt es sich um eine übergeordnete Darstellung der Produktanforderungen und einen allgemeinen Zeitrahmen dafür, wann Sie diese Anforderungen entwickeln werden. Das Ermitteln der Anforderungen, deren Priorisierung und die grobe Aufwandsschätzung für diese Anforderungen sind ein großer Teil der Arbeiten bei der Erstellung der Roadmap. Überprüfen Sie bei länger dauernden Projekten die Produkt-Roadmap mindestens halbjährlich.
In Phase 3 erstellt der Product Owner einen Release-Plan. Der Release-Plan ist ein allgemeiner Zeitplan für die Veröffentlichung nutzbarer Funktionalität. Ein agiles Projekt besitzt viele Releases, wobei die Features mit der höchsten Priorität zuerst eingeführt werden. Üblicherweise besteht ein Release aus drei bis fünf Sprints. Erstellen Sie einen Release-Plan am Anfang eines Release.
In Phase 4 planen der Product Owner, das Entwicklungsteam und der Scrum Master die Sprints, auch Iterationen genannt, und beginnen in diesen Sprints mit dem Erstellen der Produktfunktionalität. Zu Beginn jedes Sprints finden Sprint-Planungs-Meetings statt. Sprint-Planungs-Meetings finden zu Beginn jedes Sprints statt; dort legt das Scrum-Team fest, welche Anforderungen in der nächsten Iteration enthalten sein werden.
In Phase 5 trifft sich das Entwicklungsteam während jedes Sprints zu den Daily Scrum Meetings. Im Daily Scrum treffen Sie sich für maximal 15 Minuten und diskutieren, was Sie gestern erledigt haben, woran Sie heute arbeiten werden und auf welche Hindernisse Sie gestoßen sind.
In Phase 6 führt das Team ein Sprint Review Meeting durch. Im Sprint Review, das am Ende jedes Sprints stattfindet, demonstrieren Sie den Produkt-Stakeholdern die einsatzfähige Produktfunktionalität
In Phase 7 hält das Team eine Sprint-Retrospektive ab. Die Sprint-Retrospektive ist ein Meeting, in dem das Team den beendeten Sprint im Hinblick auf die Prozesse und die Arbeitsumgebung diskutiert und Pläne für Verbesserungen im nächsten Sprint macht. Wie das Sprint-Review-Meeting, in dem das Produkt überprüft und angepasst wird, findet die Sprint-Retroperspektive am Ende jedes Sprints statt.

ROLLEN IM AGILEN PROJEKTMANAGEMENT

Man braucht ein partnerschaftliches Team, um ein Projekt erfolgreich abzuschließen. Agile Projektteams bestehen aus vielen Personen mit den folgenden fünf Rollen:

Product Owner: Die Person, die dafür verantwortlich ist, Brücken zwischen dem Kunden, den Business-Stakeholdern und dem Entwicklungsteam zu schlagen. Der Product Owner ist ein Experte für das Produkt und für die Bedürfnisse und Prioritäten des Kunden. Der Product Owner arbeitet täglich mit dem Entwicklungsteam, um Anforderungen zu verdeutlichen. Er schützt es vor Störungen seitens der Organisation. Manchmal wird der Product Owner auch Kundenvertreter genannt. Vor allem muss der Product Owner bevollmächtigt sein, Entscheidungen zu treffen.
Entwicklungsteam: Die Leute, die das Produkt erstellen. Bei der Softwareentwicklung sind Programmierer, Tester, Designer, Autoren, Dateningenieure und alle anderen, die bei der Produktentwicklung eine praktische Rolle innehaben, Mitglieder des Entwicklungsteams. Bei anderen Produktarten besitzen die Mitglieder des Entwicklungsteams möglicherweise andere Fähigkeiten. Am allerwichtigsten ist, dass die Mitglieder des Entwicklungsteam vielseitig qualifiziert und so in der Lage sind, auf vielfältige Weise zum Erreichen der Projektziele beizutragen.
Scrum Master: Die Person, die für die Unterstützung des Entwicklungsteams verantwortlich ist. Der Scrum Master beseitigt organisatorische Hindernisse und sorgt dafür, dass die Prozesse die agilen Prinzipien befolgen. Ein Scrum Master wird manchmal auch Projektbetreuer genannt. Scrum Master sind gleichberechtigte Servant Leader. Sie sind dann besonders effektiv, wenn sie organisatorisches Gewicht haben, sie also ohne formale Autorität Veränderungen in der Organisation bewirken können.
Stakeholder: All diejenigen, die ein Interesse an dem Projekt haben. Sie sind letztendlich nicht für die Durchführung des Projekts verantwortlich, jedoch liefern sie Input und sind vom Ergebnis des Projekts betroffen. Die Gruppe der Stakeholder ist divers und kann Personen verschiedener Abteilungen und sogar verschiedener Firmen umfassen. Damit agile Projekte erfolgreich sind, müssen die Stakeholder beteiligt werden, regelmäßig Feedback geben und das Entwicklungsteam sowie den Product Owner unterstützen.
Agiler Mentor: Jemand, der beträchtliche Erfahrungen bei der Implementierung agiler Projekte besitzt und der diese Erfahrung mit einem Projektteam teilen kann. Der agile Mentor kann neuen Projektteams und Projektteams, die auf einem höheren Niveau arbeiten wollen, wertvolles Feedback und Ratschläge geben.

ARTEFAKTE IM AGILEN PROJEKTMANAGEMENT

Der Projektfortschritt muss transparent und messbar sein. Agile Projektteams verwenden oft sechs unterschiedliche Hauptartefakte und Liefergegenstände, um Produkte zu entwickeln und um den Fortschritt zu erfassen:

Product Vision Statement: Das Product Vision Statement ist ein Elevator Pitch, oder eine kurze Zusammenfassung, um zu kommunizieren, wie Ihr Produkt die Strategien Ihrer Firma oder Organisation unterstützt. Das Vision Statement muss die Ziele des Produkts verdeutlichen.
Produkt-Roadmap: Die Produkt-Roadmap ist ein allgemeiner Überblick der Produktanforderungen, die zum Erreichen der Produktvision erforderlich sind. Sie erlaubt es einem Projektteam, einen allgemeinen Zeitplan für die Entwicklung und die Bereitstellung dieser Anforderungen zu erstellen. Die Produkt-Roadmap ist eine Orientierungshilfe und allgemeine Sicht des Produkt-Backlogs.
Produkt-Backlog: Die vollständige Liste des Projektumfangs, nach Prioritäten sortiert. Nachdem Sie die erste Anforderung definiert haben, besitzen Sie ein Produkt-Backlog.
Release-Plan: Ein allgemeiner Zeitplan für das Release funktionierender Software.
Sprint-Backlog: Das Ziel, die User Stories sowie die Aufgaben, die zum aktuellen Sprint gehören.
Inkrement: Die einsetzbare Produktfunktionalität, die den Stakeholder am Ende des Sprints demonstriert wird und die potenziell an die Kunden ausgeliefert werden kann.

EREIGNISSE IM AGILEN PROJEKTMANAGEMENT

Die meisten Projekte besitzen Phasen. Agile Projekte enthalten sieben sich wiederholende Ereignisse (Events) für die Produktentwicklung:

Projektplanung: Die anfängliche Planung Ihres Projekts. Zur Projektplanung gehören das Erstellen eines Product Vision Statements und einer Produkt-Roadmap. Sie kann an einem Tag durchgeführt werden.
Release-Planung: Planen der nächsten Gruppe von Produktfeatures, die veröffentlicht werden sollen, und Bestimmen eines Produkteinführungsdatum, für das das Team mobilisiert werden kann. Bei agilen Projekten planen Sie immer nur genau ein Release zur selben Zeit.
Sprint: Ein kurzer Entwicklungszyklus, in dem das Team potenziell auslieferfähige Produktfunktionalität erstellt. Sprints, die auch Iterationen genannt werden, dauern in der Regel zwischen einer und vier Wochen. Sprints können auch eintägig sein, aber nicht länger als vier Wochen dauern. Innerhalb eines Projekts sollte die Dauer eines Sprints gleich bleiben. Hierdurch können die Teams zukünftige Arbeiten anhand der Performance der Vergangenheit präziser planen.
Sprint-Planung: Ein Meeting zu Beginn jedes Sprints, in dem sich das Scrum-Team auf ein Sprintziel verpflichtet. Außerdem werden die Anforderungen ermittelt, die dieses Ziel unterstützen und die Teil des Sprints werden, sowie die einzelnen Tasks, die für die Fertigstellung der jeweiligen Anforderungen erledigt werden müssen.
Daily Scrum: Ein 15 Minuten dauerndes Koordinations- und Synchronisierungsmeeting, das täglich in einem Sprint abgehalten wird. Die Mitglieder des Entwicklungsteams geben an, was sie am Vortag fertiggestellt haben, was sie am aktuellen Tag fertigstellen werden und ob ihnen irgendwelche Hindernisse im Weg stehen.
Sprint Review: Ein Meeting am Ende jedes Sprints, das durch den Product Owner eingeleitet wird und in dem das Entwicklungsteam den Stakeholdern die im Sprint fertiggestellte, einsatzfähige Produktfunktionalität demonstriert. Der Product Owner sammelt Feedback, um das Produkt-Backlog zu aktualisieren.
Sprint-Retrospektive: Ein Meeting am Ende jedes Sprints, in dem das Team seine Prozesse überprüft und anpasst, erörtert, was gut lief, was geändert werden muss, und indem ein Plan für die Implementierung von Veränderungen im nächsten Sprint erstellt wird.

ORGANISATIONEN, ZERTIFIZIERUNGEN UND RESSOURCEN FÜR AGILES PROJEKTMANAGEMENT

Da draußen gibt es eine große agile Projektmanagement-Welt. Hier sind ein paar nützliche Links zu Mitgliedern der Community agiler Praktiker:

Scrum Alliance (www.scrumalliance.org): The Scrum Alliance ist ein gemeinnütziger Berufsverband, der das Verständnis und den Einsatz von Scrum fördert. Er bietet eine Vielzahl professioneller Zertifizierungen an, zum Beispiel zum Certified Scrum Master (CSM).
Agile Alliance (www.agilealliance.org): Agile Alliance ist eine globale agile Community, die das Ziel hat, die agilen Prinzipien sowie gebräuchliche agile Praktiken, unabhängig vom konkreten Ansatz, zu verbreiten.
Extreme Programming (ronjeffries.com/xprog/what-is-extreme-programming): Ron Jeffries war einer der Urheber des Entwicklungsansatzes Extreme Programming (XP). Der Abschnitt »What Is Extreme Programming« auf seiner Website fasst die Kernkonzepte von XP zusammen. Weitere Artikel und Ressourcen zu Extreme Programming stehen auch unter http://wiki.c2.com/?ExtremeProgrammingCorePractices zur Verfügung:
Lean.org (www.lean.org): Lean Enterprise Institute veröffentlicht Bücher, Blogs, Wissensdatenbanken sowie Nachrichten für die größere Community von Lean-Vordenkern und -Praktiken. Wenn Sie agiles Projektmanagement betreiben, denken Sie daran, in allem, was Sie tun, Denkansätze aus dem Lean Management zu berücksichtigen. Lean.org ist ein guter Startpunkt, um mehr zu Lean Management zu erfahren.
Agile Community des PMI (www.projectmanagement.com/practices/agile): The Project Management Institute (PMI) ist der größte, gemeinnützige Projektmanagement-Berufsverband der Welt. Im Bereich »Agile« der PMI-Website finden Sie Artikel, Bücher sowie Informationen zu Seminaren über agiles Projektmanagement. PMI unterstützt eine agile Community für Praktiker und eine agile Zertifizierung, den PMI Agile Certified Practitioner (PMI-ACP).
Platinum Edge (www.platinumedge.com): Seit dem Jahr 2001 unterstützt unser Team bei Platinum Edge Firmen dabei, den organisatorischen Return on Investment (ROI) zu maximieren. Besuchen Sie unseren Blog, um sich über den aktuellen Stand bei Praktiken, Werkzeugen und innovativen Lösungen zu informieren.

Über den Autoren

Mark C. Layton, weltweit als Mister Agile bekannt, ist Organisationsstratege, Zertifizierungstrainer der Scrum Alliance und verfügt über mehr als 20 Jahre Erfahrung im Bereich Projektmanagement und Programmmanagement.

Er ist Vorsitzender der Abteilung Los Angeles des Agile Leadership Network, Autor des Buches Scrum für Dummies, Urheber des Videokurses Agile Foundations Complete Video Course (Pearson Education) und Gründer von Platinum Edge, LLC – ein Unternehmen, das sich auf organisatorische Verbesserung spezialisiert hat und Firmen bei der Transformation von Wasserfall zu agilen Methoden unterstützt.

Vor der Gründung von Platinum Edge im Jahr 2001 erwarb Mark seine Expertise als Unternehmensberater, Programmmanagement-Coach und als Projektleiter. Außerdem war er elf Jahre lang Kryptographie-Experte der US-Luftwaffe. Dort wurde er für seine Dienste mit der Commendation Medal und Achievement Medal ausgezeichnet.

Mark hat an der University of California, Los Angeles und der National University of Singapore ein MBA-Studium abgeschlossen. Sein Bachelor-Studium am Pitzer College/University of La Verne im Fachgebiet Verhaltenswissenschaften hat er mit summa cum laude beendet. Außerdem hat er die US Air Force Leadership School mit Auszeichnung abgeschlossen. Mark ist Certified Scrum Trainer (CST), zertifizierter Project Management Professional (PMP), Absolvent der Advanced Project Management Certification (SCPM) an der Stanford University sowie zertifizierter Scaled Agile Framework Program Consultant (SAFe SPC).

Neben der Veröffentlichung seiner Bücher und Videos ist Mark häufig als Redner bei wichtigen Konferenzen zu Lean, Scrum, XP und anderen agilen Lösungen anzutreffen.

Weitere Informationen finden Sie unter platinumedge.com.

Steven J. Ostermiller ist Coach, Mentor und Trainer, der Führungskräfte, Teams und Einzelne befähigt, agiler zu werden. Steve ist Mitgründer und Organisator von Utah Agile (unterstützt durch Agile Alliance, Scrum Alliance sowie Agile Leadership Network), einer professionellen Community, die sich für die Förderung von Agilität bei Firmen und Einzelnen engagiert. Er hat ein Curriculum über agiles Projektmanagement für eine Wirtschaftshochschule entwickelt sowie unterrichtet und ist Mitglied des Beratungsgremiums Projektmanagement dieser Hochschule. Steve war außerdem technischer Redakteur für Projekte wie Scrum für Dummies oder den Agile Foundations Complete Video Course (Pearson Education). Gelegentlich spricht und schreibt er über seine Erfahrungen mit agilen Techniken für Haushalte.

Steve unterstützt das Engagement von Platinum Edge, LLC bei agilen Transformationen durch Audits, Personalbeschaffung, Schulung sowie integriertes Coaching. Er hat mit Führungskräften und einzelnen Teams aus den Bereichen Finanzen, Gesundheitswesen, Medien, Entertainment, Verteidigung, Energiewirtschaft, lokalen und Bundesbehörden, Logistik, E-Commerce, Herstellung, ERP-Implementierungen sowie mit Start-ups und gemeinnützigen Organisationen gearbeitet. Er ist ein Certified Scrum Professional (CSP) sowie ein Project Management Professional (PMP) und ist Bachelor of Science in Business Management/Organizational Behavior von der Marriott School of Management an der Brigham Young University.

Steve verbringt so viel Zeit wie möglich mit seiner hinreißenden Frau und ihren fünf entzückenden Kindern in Utah.

Widmung

Für meine Freunde, Familie und meine Liebsten, für eure unermüdliche Liebe und Unterstützung, wenn ich diesen wilden Ideen nachgehe. Jetzt ist eure Zeit. – Mark

Für Gwen, meine umfassende und definitive Antwort. Und für unsere fünf Kleinen, die mir allen Grund geben, kontinuierlich zu prüfen und anzupassen. – Steve

Danksagungen

Wir möchten noch gemeinsam den zahlreichen Personen danken, die zur ersten Ausgabe dieses Buchs beigetragen und geholfen haben, dass es Realität wird.

Wir sind auch denjenigen sehr dankbar, die geholfen haben, dass diese zweite Ausgabe ein noch wertvollerer Praxisleitfaden wird: David Morrow für sein Verständnis und die technische redaktionelle Bearbeitung; Caroline Patchen, die sichergestellt hat, dass diese Konzepte durch klare Visualisierung besser verständlich sind; Jeff Sutherland, Ken Schwaber, Kurt Bittner, Patricia Kong, Dean Leffingwell, Alex Yakyma, Inbar Oren, Craig Larman, Bas Vodde, Mike Beedle und Michael Herman, die der Öffentlichkeit Skalierungsmodelle zur Verfügung gestellt und uns wertvolles Feedback über das neue Kapitel zur Skalierung gegeben haben.

Ein Gruß geht auch an die Erstunterzeichner des Agilen Manifests. Danke, dass ihr zusammengekommen seid, einen gemeinsamen Nenner gefunden und eine Diskussion in Gang gesetzt habt, die uns dazu inspiriert, weiterhin agiler zu werden.

Einleitung

Willkommen bei Agiles Projektmanagement für Dummies. Agiles Projektmanagement ist mittlerweile ebenso gebräuchlich wie alle anderen Managementtechniken, die heutzutage in der Geschäftswelt eingesetzt werden. In den vergangenen anderthalb Jahrzehnten haben wir große und kleine Unternehmen auf der gesamten Welt darin ausgebildet und gecoacht, wie sie erfolgreich agile Projekte durchführen können. Aufgrund dieser Arbeit haben wir den Eindruck gewonnen, dass Bedarf an einem leicht verdaulichen Leitfaden besteht, den auch der Laie verstehen und nutzen kann.

In diesem Buch räumen wir mit einigen der Mythen darüber auf, was agiles Projektmanagement ist und was nicht. Die Informationen in diesem Buch geben Ihnen das Vertrauen zu wissen, dass Sie agile Techniken erfolgreich einsetzen können.

Über dieses Buch

Agiles Projektmanagement für Dummies ist mehr als nur eine Einführung in agile Praktiken und Methoden; Sie werden auch die Schritte kennenlernen, um agile Techniken bei einem Projekt anzuwenden. Das Material in diesem Buch ist mehr als nur graue Theorie. Das Buch soll als Praxishandbuch dienen und Ihnen die Werkzeuge und Informationen an die Hand geben, die Sie benötigen, um in den Schützengraben des Projektmanagements mit agilen Prozessen erfolgreich zu sein.

Törichte Annahmen über den Leser

Da Sie dieses Buch lesen, haben Sie vermutlich irgendwie mit Projektmanagement zu tun. Vielleicht sind Sie ein Projektmanager, ein Mitglied eines Projektteams oder ein Stakeholder eines Projekts. Oder vielleicht haben Sie bisher keine Erfahrungen mit formalen Projektmanagementansätzen und sind jetzt auf der Suche nach einer Lösung. Vielleicht haben Sie den Ausdruck agil schon mal gehört und wollen mehr darüber erfahren. Oder Sie sind bereits Teil eines Projektteams, das versucht, agiler zu sein.

Unabhängig von Ihrer Erfahrung oder davon, wie vertraut Sie bereits sind, enthält dieses Buch Einsichten, die auch für Sie interessant sein können. Nicht zuletzt hoffen wir, dass es Klarheit zu Missverständnissen und Mythen über agiles Projektmanagement schafft, die Ihnen vielleicht begegnet sind.

Symbole, die in diesem Buch verwendet werden

In diesem Buch werden die folgenden Symbole verwendet:

Über dieses Buch hinaus

Obwohl dieses Buch das Spektrum des agilen Projektmanagements im Großen und Ganzen abdeckt, können wir nur so viel behandeln, wie auf eine bestimmte Seitenanzahl passt. Wenn Sie am Ende dieses Buchs angekommen sind und denken: »Das war ein tolles Buch! Wo kann ich mehr darüber erfahren, wie ich meine Projekte mit einem agilen Ansatz voranbringen kann«, dann sollten Sie Kapitel 22 aufschlagen, oder einen Blick auf die englischsprachige Dummies-Website unter www.dummies.com werfen.

Auf der deutschsprachigen Website zu diesem Buch finden Sie die Downloads und Beispieldateien zum Buch in einer ZIP-Datei, auf die wir im Verlauf des Buchs mit den entsprechenden Symbolen hinweisen. Die Adresse der Website lautet:

http://www.wiley-vch.de/ISBN9783527714766

Wie es weitergeht

Wir haben dieses Buch so geschrieben, dass Sie es in beliebiger Reihenfolge lesen können. Je nach Ihrer Rolle können Sie den bestimmten Bereichen dieses Buchs Ihre besondere Aufmerksamkeit schenken. Zum Beispiel:

Wenn Sie sich erst neu mit Projektmanagement und agilen Ansätzen befassen, beginnen Sie bei Kapitel 1 und lesen dann das Buch von vorn nach hinten bis zu seinem Ende.
Wenn Sie ein Mitglied eines Projektteams sind und die Grundlagen des Arbeitens in einem agilen Projekt kennenlernen wollen, schauen Sie sich die Informationen in Teil III an.
Wenn Sie ein Projektmanager sind und sich fragen, welche Auswirkungen agile Ansätze auf Ihren Job haben, schauen Sie sich Teil IV an.
Falls Sie die Grundlagen agilen Projektmanagements kennen und agile Praktiken in Ihrem Unternehmen einführen oder agile Praktiken in Ihrer Organisation skalieren wollen, dann finden Sie in Teil V eine Menge hilfreicher Informationen.