Agiles Projektmanagement E-Book

Jörg Preußig

• Herausgeber: Haufe Lexware
• Kategorie: Fachliteratur
• Serie: Haufe Fachbuch
• Sprache: Deutsch
• Veröffentlichungsjahr: 2024

Seitenzahl: 346

Beschreibung

Erfahren Sie, wie Agiles Projektmanagement funktioniert - und zwar nicht nur in IT-Projekten! Jörg Preußig erläutert, wie agile und klassische Arbeitsweisen sinnvoll kombiniert werden, und geht auch auf die Rahmenbedingungen in Organisationen sowie Chancen und Risiken ein. So werden Ihre Projekte den sich wandelnden Anforderungen gerecht und können erfolgreich durchgeführt und abgeschlossen werden! Inhalte: - Was bedeutet "Agil"? - Klassisches und Agiles Projektmanagement kombinieren - Agile Werte und Prinzipien - Rahmenbedingungen, Chancen und Risiken für Agiles Projektmanagement in Organisationen - Agile Techniken: User Stories, Epics, Story Mapping, Product Backlog, Persona, Sprint, Inkrement, Review, ... - Techniken zur Steuerung agiler Teams: Task Board, Definition of Done, WIP Limits, Daily Scrum, Retrospektiven, Selbstorganisierte Teams, Timeboxing, ... - Techniken zur Kontrolle: Planning Poker, Magic Estimation, Story Points ... - Agile Methoden: Scrum, Kanban & Co. - Improvisationstechniken - Zahlreiche Beispiele und AnwendungsfälleNeu in der 3. Auflage: - Überblick "Was ist agil" - SAFe - Das Scaled Agile Framework - Virtuelles Arbeiten in agilen Teams - Moderation in agilen TeamsDie digitale und kostenfreie Ergänzung zu Ihrem Buch auf myBook+: - E-Book direkt online lesen im Browser - Persönliche Fachbibliothek mit Ihren BüchernJetzt nutzen auf mybookplus.de.

Leseprobe

Inhaltsverzeichnis

InhaltsverzeichnisHinweis zum UrheberrechtmyBook+Impressum1 Einführung1.1 Agil – auch ein Modewort1.2 Projektmanagement versus Prozessmanagement1.3 Klassisch versus agil1.3.1 Steuerung versus Regelung1.3.2 Mischformen1.4 Das klassische Projektumfeld1.5 Ein kritischer Blick1.6 Gängige Irrtümer rund um das Agile Projektmanagement1.6.1 Fehlannahme Nr. 1: Agiles Projektmanagement ist schneller als klassisches Projektmanagement1.6.2 Fehlannahme Nr. 2: Agiles Projektmanagement ersetzt das klassische Projektmanagement1.6.3 Fehlannahme Nr. 3: Agiles Projektmanagement ist etwas komplett Neues1.7 Agiles Projektmanagement und Design Thinking1.8 Agil und klassisch: nicht Entweder-oder, sondern Sowohl-als-auch1.9 Ein Beispiel aus der Praxis1.9.1 Der Projektstart1.9.2 Anforderungen aus Kundensicht1.9.3 Produktentwicklung: die erste Runde1.9.4 Feedback zum Teilprodukt einholen1.9.5 Die Planung anpassen1.9.6 Produktentwicklung: weitere Runden2 Das Agile Manifest: die Basis des Agilen Projektmanagements2.1 Agile Werte2.1.1 Balance zwischen »agil« und »klassisch«2.1.2 Sehr agile Bereiche oder Unternehmen2.2 Agile Prinzipien2.2.1 Prinzip 1: Kundenbindung durch Teilprodukte2.2.2 Prinzip 2: Veränderung begrüßen2.2.3 Prinzip 3: Kurze Entwicklungszyklen2.2.4 Prinzip 4: Kundensicht im Projekt2.2.4.1 DevOps2.2.4.2 Crossfunctional Teams2.2.5 Prinzip 5: Eigenverantwortliche Mitarbeiter2.2.6 Prinzip 6: Direkte Kommunikation2.2.7 Prinzip 7: Funktionierendes Teilprodukt2.2.8 Prinzip 8: Nachhaltiger Projektfortschritt2.2.9 Prinzip 9: Erweiterbare Teilprodukte2.2.10 Prinzip 10: Einfache Lösungen2.2.11 Prinzip 11: Selbstorganisierte Teams2.2.12 Prinzip 12: Kontinuierliche Verbesserung3 Agile Techniken3.1 Was ist was? Agile Prinzipien, Techniken, Praktiken, Methoden3.2 Was sind agile Techniken?3.3 Agile Techniken im Überblick3.4 Anforderungen beschreiben3.4.1 Anwendungsfälle – Use Cases3.4.2 User Stories3.4.2.1 Akzeptanzkriterien3.4.2.2 Kriterien für gute User Stories: INVEST3.4.2.3 User Stories und ChatGPT3.4.3 Epics3.4.4 Story Mapping3.4.5 Product Backlog3.4.6 Persona3.5 Schrittweise entwickeln3.5.1 Iteration (Sprint)3.5.2 Inkrement3.5.2.1 Inkremente außerhalb der Softwareentwicklung3.5.2.2 Das Schichtenmodell3.5.2.3 Beispiele für Inkremente außerhalb der Softwareentwicklung3.5.2.4 Quick Wins als Bestandteil eines Inkrements3.5.2.5 Inkremente versus Prototypen3.5.3 Spike3.5.4 Review3.5.5 Einfachheit3.5.6 Kontinuierliche Integration3.6 Das Team steuern3.6.1 Task Board3.6.1.1 Task Board Tools3.6.1.2 Task Boards für User Stories3.6.1.3 Kontrolle für Projektleiter3.6.2 Definition of Done3.6.3 WIP-Limits3.6.3.1 Produktivität erhalten mit WIP-Limits3.6.3.2 Maximale Produktivität im Team3.6.4 Daily Stand-up (Daily Scrum)3.6.4.1 Sinnvoller Turnus im klassischen Projektumfeld3.6.4.2 Kein Mikro-Management3.6.4.3 Dailies als Ersatz-Retrospektiven3.6.4.4 Fehlleitende Disziplinierung3.6.5 Retrospektiven3.6.5.1 Retrospektive und Reviews trennen3.6.5.2 Struktur einer Retrospektive3.6.6 Osmotische Kommunikation3.6.7 Selbstorganisierte Teams3.6.7.1 Was ist eine gute Gruppengröße?3.6.7.2 Wie führt man selbstorganisierte Teams?3.6.7.3 Voraussetzungen im Team3.6.8 Timeboxing3.6.8.1 Das Pareto-Prinzip3.6.8.2 Klassisch: Termin wird verschoben – agil: Umfang wird reduziert3.6.8.3 Die Pomodoro-Technik3.7 Fortschritt kontrollieren3.7.1 Planning Poker3.7.1.1 Die Schätzkarten3.7.1.2 Die Fibonacci-Reihe3.7.1.3 Ablauf einer Sitzung3.7.1.4 So wird Planning Poker zum Erfolg3.7.1.5 Zusammenstellung des Schätzteams im klassischen Umfeld3.7.1.6 Schätzen der Aufgaben von externen Dienstleistern und Auftragnehmern3.7.2 Magic Estimation3.7.2.1 Ablauf3.7.2.2 Die Vorteile3.7.3 Story Points3.7.4 Burn Down Charts3.7.4.1 Prinzip eines Burn Down Charts3.7.4.2 Idealer Burn Down3.7.4.3 Bezug zu Earned-Value-Diagrammen3.7.4.4 Bezug zur Meilensteintrendanalyse3.7.4.5 Teilaufwandsschätzungen3.7.4.6 Release Burn Down Charts3.7.5 Business Value3.7.5.1 Business Value im klassischen Umfeld3.7.5.2 Kano-Modell3.7.6 Team Velocity3.7.7 OKR4 Agile Methoden4.1 Scrum4.1.1 Begriffe aus der Scrum-Welt4.1.2 Die Artefakte in einem Scrum-Prozess4.1.2.1 Inkrement: das Teilprodukt4.1.2.2 Product Backlog: die Anforderungen an das Produkt aus Sicht der Stakeholder4.1.2.3 Sprint Backlog: Basis für die konkreten Arbeiten4.1.3 Die Rollen in einem Scrum Team4.1.3.1 Der Scrum Master4.1.3.2 Der Product Owner4.1.3.3 Die Developers4.1.4 Die »Ereignisse« in einem Scrum-Projekt4.1.4.1 Sprints4.1.4.2 Sprint Planning4.1.4.3 Daily Scrum4.1.4.4 Sprint Review4.1.4.5 Sprint Retrospective4.1.5 Techniken und Zusatzregeln für Scrum4.1.5.1 Timeboxing4.1.5.2 Definition of Done4.1.5.3 Unveränderlichkeit4.1.6 Scrum But4.1.7 Scrum Zertifizierung4.2 Extreme Programming4.3 Kanban4.4 Scaled Agile – Agilität im großen Maßstab4.4.1 Scrum of Scrum4.4.2 Spotify4.4.3 LeSS4.4.4 SAFe5 Agile Techniken in klassischen Projekten5.1 Das klassische Projektumfeld5.2 Verbreitete klassische Projektmanagement-Techniken5.2.1 Stakeholder-Matrix5.2.2 Kommunikationsplan5.2.3 Feinkonzept5.2.4 Projektstrukturplan5.2.5 Netzplandiagramme5.2.6 Kritischer Pfad5.2.7 Gantt-Diagramm5.2.8 Meilensteindiagramm5.2.9 RACI-Diagramme5.2.10 Statusbericht5.3 Klassisch und agil – eine Herausforderung5.4 Wie der Mix gelingen kann – ein Beispiel aus der Praxis5.5 Wo passt die agile Vorgehensweise?5.6 Klassische Techniken im agilen Umfeld5.6.1 Rollenklärung mit dem RACI-Diagramm5.6.2 Projektstrukturplan5.6.3 Sequenzdiagramm5.6.4 Anforderungsdokumente5.6.4.1 Gliederung nach Anwendungsfällen5.6.4.2 Flexibilität durch sinnvollen Detailgrad5.6.5 Ressourcenplanung5.6.5.1 Mitarbeiter mit mehreren Projekten5.6.5.2 Multiprojektmanagement5.6.5.3 Kurzfristigere Ressourcenplanung5.6.6 Risikomanagement5.6.7 Stakeholdermanagement5.6.8 Gantt-Diagramme5.6.9 Meilensteine und Iterationen5.6.9.1 Meilensteine statt Iterationen5.6.9.2 Meilensteine in Iterationen unterteilen5.6.9.3 Zulieferungen zwischen klassischen und agilen Projekten5.6.9.4 Das Briefsortier-Beispiel – ein Integrationsprojekt6 Klassische Projekte agiler machen6.1 Mehr Zwischenergebnisse und Teilprodukte6.2 Mehr Kundensicht6.3 Mehr Rückmeldungen6.4 Mehr Austausch6.5 Mehr gemeinsamer Überblick6.6 Niemanden überfahren6.7 Die Top 5 der agilen Techniken: Einschätzungen von Projektleitern aus der Praxis6.8 Der agile Festpreis6.8.1 Scheinsicherheit im klassischen Projekt6.8.2 Service Level Agreements mit Bestandskunden6.8.3 Open Book Policy6.8.4 Agiler Angebotsprozess6.9 Unternehmensstrukturen7 Agiles Projektmanagement spielerisch ­vermitteln8 Agiles Führen8.1 Kapitän und Coach: Führung im Spannungsfeld zwischen klassisch und agil8.2 Führung im Wandel der Zeit8.3 Intrinsisch motivieren mit SCARF8.3.1 Grundlagen des SCARF-Models8.3.2 Status8.3.3 Certainty8.3.4 Autonomy8.3.5 Relatedness8.3.6 Fairness8.4 Agile Organisationen8.4.1 Maßnahmen auf dem Weg hin zu einer agilen Organisation8.4.2 Kennzeichen agiler Organisationen8.4.3 Pragmatische Agilität in Organisationen 8.4.4 Fehlentwicklung: Agiles Theater9 Agile Coaches9.1 Das systemisch-lösungsorientierte Coaching9.1.1 Was bedeutet lösungsorientiert?9.1.2 Was bedeutet systemisch?9.1.3 Gesprächs- und Fragetechniken9.1.4 Kontextklärung9.1.5 Askese9.1.6 Musterunterbrechung9.1.7 Ressourcenfokussierung9.2 Agiles Mindset 9.3 Positive Fehlerkultur 9.4 Moderation9.5 Virtuelles Arbeiten und Moderieren9.5.1 Strukturen und Prozesse9.5.1.1 Für klare Absprachen sorgen 9.5.1.2 Virtuelle Zusammenarbeit aufbauen9.5.2 Kommunikation und Interaktion9.5.2.1 Virtuelle und hybride Meetings professionell moderieren9.5.2.2 Formate für den Teamprozess10 Improvisationstechniken10.1 Flexibilität innerhalb von Strukturen10.2 Improvisationstechniken im Überblick10.3 Status10.3.1 Wie setzt sich der Status einer Person zusammen?10.3.2 Der Statusradar10.3.3 Statusverhalten als dynamischer Prozess10.3.4 Statussignale10.3.5 Statusflexibilität und Lieblingsstatus10.3.6 Status und Kooperation in Teams10.3.7 Statusspiele erkennen und nutzen10.3.8 Reaktionsmöglichkeiten10.3.9 Status-Priming10.4 Positives Unterstellen10.5 Angebote machen10.6 Souverän scheitern10.7 Fortschritt machen10.8 Integration von Improvisationstechniken in die Führung agiler TeamsLiteraturIhre Online-Inhalte zum Buch: Exklusiv für Buchkäuferinnen und Buchkäufer!Stichwortverzeichnis

Buchnavigation

InhaltsubersichtCoverTextanfangImpressum

[1]

Hinweis zum Urheberrecht

Alle Inhalte dieses eBooks sind urheberrechtlich geschützt.

Bitte respektieren Sie die Rechte der Autorinnen und Autoren, indem sie keine ungenehmigten Kopien in Umlauf bringen.

Dafür vielen Dank!

myBook+

Ein neues Leseerlebnis

Lesen Sie Ihr Buch online im Browser – geräteunabhängig und ohne Download!

Und so einfach geht’s:

Gehen Sie auf https://mybookplus.de, registrieren Sie sich und geben Sie Ihren Buchcode ein, um auf die Online-Version Ihres Buches zugreifen zu können

Ihren individuellen Buchcode finden Sie am Buchende

Wir wünschen Ihnen viel Spaß mit myBook+ !

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.dnb.de abrufbar.

Print:

ISBN 978-3-648-17602-3

Bestell-Nr. 10248-0003

ePub:

ISBN 978-3-648-17603-0

Bestell-Nr. 10248-0102

ePDF:

ISBN 978-3-648-17604-7

Bestell-Nr. 10248-0152

Jörg Preußig

Agiles Projektmanagement

3. aktualisierte und erweiterte Auflage 2024

© 2024 Haufe-Lexware GmbH & Co. KG, Freiburg

www.haufe.de

[email protected]

Bildnachweis (Cover): © Martin Barraud, iStock

Produktmanagement: Kerstin Erlich

Lektorat: Ulrich Leinz

Dieses Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte, insbesondere die der Vervielfältigung, des auszugsweisen Nachdrucks, der Übersetzung und der Einspeicherung und Verarbeitung in elektronischen Systemen, vorbehalten. Alle Angaben/Daten nach bestem Wissen, jedoch ohne Gewähr für Vollständigkeit und Richtigkeit.

Sofern diese Publikation ein ergänzendes Online-Angebot beinhaltet, stehen die Inhalte für 12 Monate nach Einstellen bzw. Abverkauf des Buches, mindestens aber für zwei Jahre nach Erscheinen des Buches, online zur Verfügung. Ein Anspruch auf Nutzung darüber hinaus besteht nicht.

Sollte dieses Buch bzw. das Online-Angebot Links auf Webseiten Dritter enthalten, so übernehmen wir für deren Inhalte und die Verfügbarkeit keine Haftung. Wir machen uns diese Inhalte nicht zu eigen und verweisen lediglich auf deren Stand zum Zeitpunkt der Erstveröffentlichung.

1 Einführung

1.1 Agil – auch ein Modewort

Der Begriff »agil« hat in den letzten Jahren enorm an Beliebtheit gewonnen und ist zu einem Modewort geworden. Auf der einen Seite ist es erfreulich, wenn sich die dazugehörigen Ideen verbreiten. Auf der anderen Seite ist es zu einer zunehmenden Unschärfe gekommen, was genau mit dem Begriff gemeint ist. Mitunter wird er nur genutzt, um ein gutes Label für das Marketing zu haben. Und ab und an werden Projekte als »agil« bezeichnet, weil man nicht zugeben möchte, dass es sich eigentlich um Chaosprojekte handelt. Es ist also mittlerweile eine gewisse Vorsicht geboten. Nicht überall, wo agil draufsteht, muss es auch drin sein bzw. gelebt werden.

In diesem Buch wird der Begriff so verwendet, wie er sich aus der Softwareentwicklung und dem dort entstandenen Agilen Manifest ableitet, das Sie später noch genauer kennenlernen werden. Nur so viel vorab: Es geht dabei in erster Linie um eine agile, also schnelle Reaktion auf Veränderungen bei den Produktanforderungen. Aus dieser Herausforderung folgen agile Prinzipien und agile Techniken. Auf Basis dieser Prinzipien und Techniken ist der Begriff des »Agilen Projektmanagements« entstanden. Dieses Buch beschränkt sich jedoch nicht nur auf Softwareprojekte. Es betrachtet auch Projekte außerhalb der Softwareentwicklung und ist an all diejenigen gerichtet, die in einem klassischen Projektumfeld von den Techniken des Agilen Projektmanagements profitieren wollen.

Dabei ist dieses Werk nicht etwa eine Werbebroschüre für das Agile Projektmanagement, die dazu anregt, klassische Projekte um jeden Preis in agile Projekte zu wandeln. Vielmehr möchte ich die Chancen und Risiken darstellen, die mit dem Einsatz agiler Techniken und Methoden in einem klassischen Projektumfeld einhergehen.

1.2 Projektmanagement versus Prozessmanagement

ProzessmanagementWasserfallmodellDer Begriff »Agiles Projektmanagement« leitet etwas in die Irre. Denn das ursprüngliche Einsatzgebiet des Agilen in der Softwareentwicklung war nicht das Projektmanagement, sondern das Prozessmanagement. Der Prozess der Softwareentwicklung hatte sich lange Jahre am sog. Wasserfallmodell orientiert. Dabei wurde, vereinfacht gesagt, vorausgesetzt, dass sich die Anforderungen an das Softwareprodukt zu Beginn des Projektes vollständig beschreiben lassen. Diese Beschreibung war dann einer der ersten Prozessschritte zur Produktentwicklung. Weitere Prozessschritte, die sich daran anschlossen, waren beispielsweise: Analyse, Entwicklung und Test. Da diese Schritte ähnlich sequentiell durchlaufen wurden, wie Wasser von oben nach unten fällt, bekam die Beschreibung dieses Prozesses den Namen Wasserfallmodell.

Bei dem Einsatz des Wasserfallmodells kam es allerdings immer wieder zu einer Folge, die niemand wollte: zum Scheitern des Projektes. Die Annahme, man könne die Anforderungen an das Softwareprodukt zu Beginn des Projektes vollständig beschreiben, stellte sich meist als falsch heraus. Denn sehr häufig waren diese Anforderungen schlicht zu komplex und selbst den Auftraggebern des Projektes in der Startphase nicht klar genug.

Der Prozess des Wasserfalls wurde dann nach und nach von agilen Prozessmodellen abgelöst. Bei diesen Prozessen ist es möglich, auch mit unschärferen Anforderungen zu starten.

Der Ursprung des Agilen liegt also im Management von Prozessen und nicht im Management von Projekten. Und genau das sorgt in der Praxis immer wieder für große Verwirrung. Denn Projektmanagement ist natürlich eine eigene Disziplin, die zunächst einmal unabhängig von den Prozessen im Projekt ist. Genau genommen leitet der Begriff »Agiles Projektmanagement« also etwas in die Irre. Denn die agilen Prinzipien und Techniken beziehen sich ja ausschließlich auf das Prozessmanagement. Wenn man »agile« Projekte sauber managen möchte, benötigt man also mehr als diese agilen Prinzipien und Techniken. Viele Aufgaben, die beim Managen eines Projektes anfallen, werden nämlich von den agilen Prinzipien und Techniken nicht umfasst und adressiert, so beispielsweise der Bereich »Ressourcenplanung« oder ein Kick-off-Meeting.

Sie werden sehen: Für ein zielführendes Agiles Projektmanagement benötigen Sie also sowohl ein solides Wissen über die gängigen Techniken des Projektmanagements als auch fundierte Kenntnisse der agilen Prinzipien und Techniken.

1.3 Klassisch versus agil

In der Softwareentwicklung stehen sich zwei Modellarten für den Entwicklungsprozess gegenüber: das Wasserfallmodell und die agilen Modelle.

WasserfallmodellDas Wasserfallmodell wird gemeinhin als »klassisch« bezeichnet, womit es im Laufe der Zeit im Prozessmanagement zur Unterscheidung zwischen »klassisch« und »agil« kam. Es gibt zwischen diesen Polen zahlreiche Modellvarianten und Mischformen. Zur Vereinfachung des Spannungsfeldes zwischen »klassisch« und »agil« verzichte ich hier bewusst auf deren Darstellung und Systematisierung.

Die Begriffe »klassisch« und »agil« wurden auf das Projektmanagement übertragen:

Unter Agilem Projektmanagement ist danach ein Projektmanagement zu verstehen, das sich auf einen agilen Prozess stützt und dabei die agilen Prinzipien und Techniken nutzt.

Das klassische Projektmanagement dagegen ist ein Projektmanagement, das im weiteren Sinne auf einem Wasserfallmodell basiert und dazu passende Techniken des Projektmanagements einsetzt.

1.3.1 Steuerung versus Regelung

Lassen Sie uns einen Ausflug in die Regelungstechnik machen, um den Unterschied zwischen agilem und klassischem Projektmanagement noch deutlicher zu machen. Dort gibt es die Einteilung in die Kategorien »Steuerung« und »Regelung«:

Wenn ich ausreichend Informationen über ein System habe, dann kann ich zukünftige Zustände gut vorausberechnen und dieses System durch Steuereingriffe so beeinflussen, dass es sich in eine gewünschte Richtung verändert. Ich kann es steuern. Bei einer Heizung entspräche das Steuern einem einfachen Verstellen der Heizung auf eine bestimmte Stufe.

Wenn ein System sehr komplex ist und man die zukünftigen Zustände nicht einfach vorausberechnen kann, so benötigt man eine Regelung. Bei einer Heizung könnte der Regler die aktuelle Raumtemperatur und die Außentemperatur mit einbeziehen, um immer wieder angepasst an diese Faktoren sinnvolle Einstellungen der Heizung vorzunehmen. Eine Regelung bezieht also die Dynamik des Systems ein, die sie beeinflussen soll.

Übertragen auf die Produktentwicklung entspricht ein reiner Wasserfallprozess der Steuerung und ein agiler Prozess der Regelung.

Nachjustieren im agilen Prozess

Die Grafik veranschaulicht dies. Bei den Anforderungen symbolisieren die roten Punkte eine sehr genaue, feingranulare Beschreibung der Kundenwünsche, also ein klassisches Anforderungsdokument. Die grünen Kreise hingegen stehen für eine ungenauere, grobgranulare Beschreibung der Anforderungen.

Während man beim klassischen Wasserfallmodell davon ausgeht, mithilfe einer genauen Beschreibung der Anforderungen und einer darauf basierenden Planung den Weg der Entwicklung vorab festlegen zu können, bezieht man im agilen Prozess die Veränderungen (also insbesondere ein präziseres oder neues Verständnis der Anforderungen) immer wieder ein und regelt die Richtung der Entwicklung nach (mehr zu den Details der Grafik im Kap. »Ein Beispiel aus der Praxis«).

Entwicklungsprozess, agilerEin agiler Entwicklungsprozess erlaubt zwar Änderungen bei den Anforderungen. Er ist aber in Bezug auf die Entwicklungszeit außerordentlich streng. Reicht ein geplanter Entwicklungszeitraum nicht für die Umsetzung der eingeplanten Anforderungen aus, so wird der Umfang der Anforderungen reduziert.

Stellschrauben im PM-Dreieck

PM-DreieckIn Projekten mit einem klassischen Wasserfallprozess wird stattdessen typischerweise der Zeitraum erweitert. Die Grafik veranschaulicht diesen Zusammenhang anhand des sog. PM-Dreiecks. Im Kapitel »Timeboxing« gehe ich noch genauer auf diesen Zusammenhang ein.

1.3.2 Mischformen

In der Realität gibt es viele Formen des Projektmanagements, die weder auf einem agilen Prozess basieren, noch einen Bezug zum Wasserfallmodell haben. Es ist also per se falsch, alles, was nicht als »Agiles Projektmanagement« zu charakterisieren ist, als »klassisches Projektmanagement« zu bezeichnen. In der Praxis ist diese Schematisierung allerdings leider sehr verbreitet. Die Unterscheidung dient natürlich denen, die mit »Agilem Projektmanagement« etwas völlig Neues zu verkaufen versuchen, verunsichert aber gleichzeitig diejenigen, die ein pragmatisches Projektmanagement betreiben, in dem auch Ideen aus dem Agilen Prozessmanagement enthalten sind.

Projektmanagement, hybridesDer aktuelle Trend ist »Hybrides Projektmanagement«. Hier wird eine Kombination von klassischem und Agilem Projektmanagement propagiert. Dieser neue Begriff macht die Verwirrung komplett. Denn eigentlich landet man mit dem Hybriden Projektmanagement durch die Integration der agilen Prinzipien und Techniken in den Werkzeugkoffer des Projektmanagements wieder genau dort, wo man schon immer war, nämlich beim althergebrachten Projektmanagement. Ohne dieses geht es auch bei der Anwendung von agilen Prinzipien und Techniken nicht. Es bleibt zu hoffen, dass sich der Modebegriff »Hybrides Projektmanagement« wieder hin zum »Projektmanagement« abschleift.

Sie werden sehen, dass viele agile Prinzipien und Techniken auf bewährten Techniken des gängigen Projektmanagements basieren. Auch Leser, die bisher noch nicht mit dem Thema »Agiles Projektmanagement« in Berührung gekommen sind, werden feststellen, dass ihnen aus ihrem Projektalltag einiges davon bereits gut bekannt ist.

1.4 Das klassische Projektumfeld

In diesem Buch geht es insbesondere um den Einsatz des Agilen Projektmanagements im klassischen Projektumfeld. Wie das »Agile Projektmanagement« in einem solchen Projektumfeld umgesetzt werden kann, ist insofern von besonderem Interesse, als diese Kombination insbesondere außerhalb der Softwareentwicklung eher der Regelfall als die Ausnahme ist.

Mit einem klassischen Projektumfeld ist ein Umfeld gemeint, das von folgenden Strukturen geprägt ist:

Die Prozesse der Produktentwicklung laufen weitgehend sequentiell ab (Stichwort: Wasserfall).

Projekte werden mit festen Budgets versehen, zu denen festgelegte Ergebnisse geliefert werden sollen.

Mitarbeiter sind in mehrere Projekte gleichzeitig involviert.

Projektmanager definieren Arbeitspakete für das Produkt und delegieren deren Umsetzung an die Produktentwicklung.

Diese Aufzählung dient nur dem ersten Überblick. In späteren Kapiteln werden wir noch einmal ausführlich auf diese Aspekte zurückkommen.

1.5 Ein kritischer Blick

Später im Buch werden Sie sehen, dass das Agile Projektmanagement mit dem Agilen Manifest in der Theorie ganz sicher auf einem positiven Menschenbild basiert und eine effektivere sowie motivierende Zusammenarbeit im Fokus hat. Allerdings zeigt der Blick in die Praxis, dass es nicht immer im Einklang mit diesen Werten eingesetzt wird. Die Beobachtung der praktischen Umsetzung in der Wirtschaft legt vielmehr nahe, dass die Anlässe für den Einsatz des Agilen Projektmanagements in zunehmendem Maße betriebswirtschaftliche Aspekte sind. Eine sozialwissenschaftliche Studie im Auftrag der Hans-Böckler-Stiftung [BoKä16] legt dies ebenfalls nahe. Durch die Verbindung von agilen Prozessmodellen (siehe das Kap. »Scrum«) und Konzepten aus dem Lean Management wird eine enge Leistungskontrolle möglich. Zudem können Effekte der intrinsischen Motivation, die durch Selbstorganisation entstehen (siehe näher das Kap. »Prinzip 5: Eigenverantwortliche Mitarbeiter«), auch zur Selbstausbeutung von Mitarbeitern genutzt werden. Wo sich wirtschaftliche Interessen auf solche Aspekte fokussieren, ist der Begriff »agil« dann eher ein Feigenblatt für erhöhte Anforderungen und zusätzlichen Stress. In diesem Zusammenhang droht »agil« dann zu einem weiteren Werkzeug der modernen (Selbst-)Ausbeutung zu verkommen, deren Gesamtprogramm beispielsweise Ulrich Bröckling in seinem Buch »Das unternehmerische Selbst« (siehe auch im Literaturverzeichnis unter [Brö07]) fundiert und lesenswert skizziert.

1.6 Gängige Irrtümer rund um das Agile Projektmanagement

Es gibt eine Reihe von fehlerhaften Ansichten rund um das Agile Projektmanagement, die recht verbreitet sind. Im Folgenden werden einige davon kurz beleuchtet.

1.6.1 Fehlannahme Nr. 1: Agiles Projektmanagement ist schneller als klassisches Projektmanagement

Gelegentlich wird davon ausgegangen, dass bei Anwendung des Agilen Projektmanagements das Produkt schneller und damit kostengünstiger entwickelt werden kann als beim klassischen Projektmanagement. Dies ist so nicht der Fall. Zeit und Budget für ein agiles Projekt stehen wie beim klassischen Projektmanagement im Allgemeinen fest. Das Agile Projektmanagement richtet seinen Fokus darauf, mit Änderungen bei den Anforderungen flexibel umgehen zu können. Es kann daher also sein, dass im Verlauf des Projektes bestimmte Anforderungen wegfallen, weil man erkennt, dass sie für den Kunden tatsächlich nicht wichtig sind. Gleichzeitig können aber auch andere Anforderungen hinzukommen. Schneller ist man also höchstens insofern, als man einzelne »Blindleistungen« vermeidet, also weniger Zeit damit verbringt, an den eigentlichen Kundenanforderungen vorbei zu arbeiten.

Zu der verbreiteten Einschätzung, dass Agiles Projektmanagement schneller ist, trägt sicher auch der etwas unglückliche Begriff »Sprint« aus der Methode Scrum bei (siehe das Kap. »Scrum«).

1.6.2 Fehlannahme Nr. 2: Agiles Projektmanagement ersetzt das klassische Projektmanagement

Agiles Projektmanagement kann kein Ersatz für das klassische Projektmanagement sein, denn vom Ursprung her ist es Prozessmanagement (siehe hierzu bereits das Kap. »Projektmanagement versus Prozessmanagement«). Es geht also im Schwerpunkt darum, den Produktentwicklungsprozess zu steuern. Viele Aspekte, die für ein sauberes Projektmanagement notwendig sind, werden dort gar nicht berücksichtigt. Auch Unternehmen, die vorbildlich agil mit Scrum arbeiten, nutzen deswegen zusätzlich Prozesse oder Elemente aus dem klassischen Projektmanagement.

1.6.3 Fehlannahme Nr. 3: Agiles Projektmanagement ist etwas komplett Neues

Das Agile Projektmanagement hat sich über einen langen Zeitraum aus der Praxis heraus entwickelt. Die dort verwendeten Techniken sind Best Practices, die sich mit der Zeit besonders etabliert haben. Einige davon haben in abgewandelter Form auch schon im klassischen Projektmanagement Anwendung gefunden. Ein einfaches Beispiel sind Daily Stand-up Meetings, die als besondere Form von regelmäßigen, kurzen Statusmeetings verstanden werden können. Es ist eher das Zusammenspiel der verschiedenen Techniken, der Mix daraus, die dann eine besondere und gewissermaßen auch neue Form des Projektmanagements ergeben.

1.7 Agiles Projektmanagement und Design Thinking

Design ThinkingKundenfeedbackDas Design Thinking (zu Deutsch etwa »Denken wie ein Designer«) ist eine Methode, bei der es um die Entwicklung neuer Ideen und Produkte, also um das Thema Innovation geht. Die Vorgehensweise der Design Thinker weist viele Gemeinsamkeiten mit dem Agilen Projektmanagement auf. In beiden Disziplinen sind schnelle Teilergebnisse gefragt, die zur Rückkopplung mit dem Kunden dienen. So soll erreicht werden, dass man möglichst wenig Zeit damit verbringt, an den Wünschen des Kunden vorbei zu arbeiten. Das Feedback des Kunden trägt also wesentlich dazu bei, dass die Produktentwicklung in eine für ihn sinnvolle Richtung geht.

Ein wichtiger Unterschied zwischen beiden Disziplinen besteht in dem Zielbild des Produktes. Das Agile Projektmanagement startet damit, dass die Kundenwünsche relativ bekannt sind, nur eben noch nicht so detailliert, wie man es für eine genaue Produktspezifikation bräuchte. Design Thinking kann hingegen mit einem völlig unklaren Zielbild starten, da es ein Innovationsprozess ist. Man weiß also unter Umständen noch fast gar nichts über das Produkt, das am Ende des Prozesses stehen soll.

Dieser Unterschied zwischen beiden Disziplinen spiegelt sich auch in den Teilprodukten wider. Während Design Thinking ein »schnelles erstes Ergebnis« propagiert, fordert das Agile Projektmanagement ein »funktionsfähiges Teilprodukt«. Das »schnelle erste Ergebnis« ist eine mögliche erste (und dann später in weiteren Iterationen verfeinerte) Produktidee, die völlig frei von Zwängen entwickelt wird. Das »funktionsfähige Teilprodukt« entspricht bereits weitgehend der Kundenerwartung und ist im Idealfall schon als Teillösung in der Kundenumgebung einsetzbar.

Es scheint keine gemeinsamen Wurzeln zwischen dem »Agilen Projektmanagement« und »Design Thinking« zu geben. Vermutlich ist ihr relativ zeitgleiches Bekanntwerden dem gesellschaftlichen Trend zuzuschreiben, dass sowohl Innovation als auch Produkterstellung in immer kürzeren Zeiträumen passieren müssen.

Zum »Design Thinking« gibt es kein grundlegendes Standardwerk, sondern viele Bücher und Artikel, die die Methode behandeln. Zu den wichtigsten Autoren im Bereich »Design Thinking« gehören der mutmaßliche Namensgeber David Kelley [Kell01], sowie Tim Brown [Brow09] und Nigel Cross [Cros09]. Im deutschsprachigen Raum vertritt Ulrich Weinberg über das Hasso-Plattner-Institut einen Strang von Design Thinking. Es scheint, dass der amerikanische Original-Ansatz mehr Gewicht auf die technisch funktionalen Prototypen legt, während die deutschen Ableger den Empathie-Aspekt stärker betonen, so z. B. Meinel/Weinberg [MeWe15]. Eine kurze und übersichtliche Einführung zum Design Thinking findet sich im TaschenGuide »Design Thinking« [KeST17].

1.8 Agil und klassisch: nicht Entweder-oder, sondern Sowohl-als-auch

Das Agile Projektmanagement wird oft als Gegenentwurf zum klassischen Projektmanagement verstanden. Wie wir oben bereits festgestellt haben, hält diese Auffassung einer genaueren Betrachtung nicht stand. Es mag sein, dass in Einzelfällen ein Vorgehen nach dem Agilen Projektmanagement das klassische Projektmanagement weitgehend ersetzt. In den meisten Fällen ist in der Praxis aber eine Kombination aus beiden Bereichen anzutreffen.

PM-Prozess, allgemeinProject Management InstituteDie Grafik zeigt den allgemeinen PM-Prozess, so wie er von namhaften Standardisierern wie z. B. dem Project Management Institute (PMI) oder der Gesellschaft für Projektmanagement (GPM) gesehen wird. Dieser Prozess besteht im Wesentlichen aus vier Phasen (es gibt noch eine Variante mit einer fünften Phase, der »Steuerung«, die aber für die Betrachtung hier nicht relevant ist). Jedes Projektmanagement durchläuft diese Phasen.

Allgemeiner Prozess des Projektmanagements

Welche formalen Methoden während des Prozesses eingesetzt werden, bleibt in manchen Unternehmen vollständig dem Ermessen des Projektmanagers überlassen. Im Extremfall, der übrigens sicherlich kein Einzelfall ist, setzt der Projektmanager gar keine Methoden ein, sondern leitet das Projekt ad hoc nach eigenem Gutdünken. Dies geschieht meist aus Unkenntnis darüber, dass es bewährte Methoden des Projektmanagements gibt. In der Praxis kann das dann etwa so aussehen wie in der Abbildung unten.

Das Beispiel macht deutlich, dass man Projekte durchführen kann, ohne auch nur eine einzige Technik zu nutzen, die der Erfahrungsschatz des Projektmanagements bereithält. Es ist bewusst überzeichnet. Unrealistisch ist das Beispiel allerdings nicht. Einige Leser werden sicherlich schon Vergleichbares erlebt haben. Nun könnte man hier einwenden, dass es sich ja bei dem Auftrag gar nicht um ein Projekt handelt, weil es z. B. weder ein klares Budget noch einen klaren Endtermin gibt. Formal betrachtet ist es zumindest zweifelhaft, ob man hier überhaupt von einem Projekt sprechen kann. In der Praxis gibt es allerdings zahlreiche Projekte, die die formalen Kriterien nicht einhalten. Der Begriff »Projekt« wird in vielen Unternehmen inflationär benutzt und auf alle möglichen etwas größeren Aufgaben ausgedehnt, die den Mitarbeitern aufgetragen werden.

Ein professionelles Projektmanagement zeichnet sich dadurch aus, dass während der einzelnen Phasen bewährte Techniken des Projektmanagements zum Einsatz kommen.

Beispiel

Initiierung:

Ein Mitarbeiter trifft seinen Chef auf dem Gang und bekommt zu hören: »Gut, dass ich Sie treffe! Ich habe über unsere Kundenliste nachgedacht. Die ist zu unübersichtlich. Da müssen wir mal was tun.«

Dies ist die Initiierung des Prozesses.

Planung:

Der Mitarbeiter geht zu einem Kollegen und sagt: »Ich habe gerade den Chef getroffen. Der will eine andere Kundenliste. Lass uns die morgen mal zusammen überarbeiten.«

Dies ist die Planung.

Durchführung:

Die beiden Mitarbeiter setzen sich tags darauf ein paar Stunden zusammen und erstellen eine neue Kundenliste.

Abschluss:

Der Chef bekommt die neue Kundenliste per E-Mail zugeschickt. Da er keine Zeit hat, schaut er sich das Dokument nur oberflächlich an und nickt es ab.

Projektmanagement kann als ein Methodenkoffer voller Techniken verstanden werden, die man im Projektmanagementprozess je nach Bedarf einsetzt. Typische Beispiele für solche bewährten Techniken sind ein Kick-off-Meeting, ein Projektstrukturplan oder ein Meilensteindiagramm.

Projektmanagement mit dem klassischen Methodenkoffer

In größeren Unternehmen wird häufig ein bestimmter Satz an Techniken für die Projektabwicklung vorgeschrieben, und daneben bleibt ein gewisser Spielraum für die Projektleiter. Zu den klassischen Techniken, die zum Pflichtprogramm in vielen Unternehmen gehören, zählen beispielsweise die Kick-off-Meetings und Meilensteindiagramme. Oft hat jeder Projektleiter über die Zeit seinen eigenen Methodensatz zusammengestellt, mit dem er seine Projekte abwickelt.

Mit den Techniken des Agilen Projektmanagements bekommen Projektmanager einen zweiten Methodenkoffer an die Hand, mit dem der PM-Prozess angereichert werden kann. Typische agile Techniken, die sich sehr leicht adaptieren und in ein vorhandenes klassisches Projektmanagement integrieren lassen sind z. B. Task-Boards oder Planning Poker.

Diese Verfahrensweise hebt das Denkmuster »Agil gegen Klassisch« auf. Es gibt dann kein Entweder-oder, sondern ein Sowohl-als-auch. Dass diese Sichtweise in vielen Unternehmen bereits gelebte Praxis ist, bestätigt eine aktuelle Studie der Hochschule Koblenz [KoKu17], an der im Herbst 2016 ca. 1.000 Personen teilnahmen. Sie kam unter anderem zu den folgenden Ergebnissen:

37 % der Befragten gaben an, Projekte/Entwicklungsprozesse anhand einer »Mischform« zu bearbeiten.

Nur 20 % der Teilnehmer bearbeiten Entwicklungsprozesse durchgängig agil.

71 % sagten, dass die Rahmenbedingungen es nicht erlauben, durchgehend agil zu arbeiten, z. B. aufgrund von Festpreisen oder Zielvorgaben.

Klassische und agile Techniken im Projektmanagement

Es spricht also Vieles für eine pragmatische Kombination aus »agil« und »klassisch«. Natürlich sind dabei längst nicht alle Kombinationen sinnvoll. Auf diesen Zusammenhang werde ich in den nachfolgenden Kapiteln immer wieder eingehen. Ganz sicher gilt beim Projektmanagement nicht der Grundsatz »Viel hilft viel«. Ein zu geringer Grad an Methodik führt schnell zu Ineffizienz durch Chaos, ein zu hoher Grad an Methodik zu Ineffizienz durch Überladung des Prozesses.

Chaos-ProjektDas klassische Projektumfeld gibt bestimmte Strukturen und Grenzen vor, deren Einhaltung wichtig ist. Gleichzeitig kann durch den klugen Einsatz agiler Techniken der Spielraum innerhalb dieser Strukturen wirkungsvoll genutzt werden. Man könnte auch formulieren, dass die angemessene Berücksichtigung der klassischen Werte die Basis dafür bildet, mit den agilen Werten erfolgreich zu sein. Die klassischen Werte sind es letztlich, die ein Projekt davor schützen, ins Chaos abzugleiten. Das zeigt auch die Grafik. Die Kreise stellen jeweils einen Satz von Techniken dar, die in einem Projekt verwendet werden. Der Kreis nahe des Ursprungs steht also für einen sehr geringen Einsatzgrad sowohl agiler als auch klassischer Techniken. Projekte im Umfeld von großen Konzernen tendieren dazu, sich weit unten rechts in diesem Schema wiederzufinden, also sehr viele klassische Techniken einzusetzen. Der Kreis nahe der Mitte steht für eine ausgewogene Kombination agiler und klassischer Techniken.

Methodeneinsatz im Projektmanagement

Letztlich muss jeder Projektmanager selbst entscheiden, welche agilen und klassischen Techniken im Projekt zum Einsatz kommen sollen. Bei dieser Entscheidung soll dieses Buch eine Hilfestellung bieten.

1.9 Ein Beispiel aus der Praxis

Das in diesem Kapitel dargestellte Beispiel führt Sie an die wesentlichen Zusammenhänge eines agilen Entwicklungsprozesses heran und macht es einfacher, die theoretischen Aspekte und Techniken des Agilen Projektmanagements gedanklich einzuordnen.

Das Beispiel ist bewusst sehr schlicht gehalten. Es geht dabei nicht um eine möglichst hohe Realitätsnähe, sondern um maximale Verständlichkeit.

1.9.1 Der Projektstart

Maria Müller leitet ein kleines Software-Unternehmen mit vier Entwicklern. Ein Kunde, Paul Schmidt, meldet sich. Er braucht eine Kalender-Applikation. Frau Müller trifft sich mit ihm, um zu verstehen, was genau hinter diesem Wunsch steckt. Dabei lässt sie sich alles beschreiben, was die Kalender-Applikation aus Sicht des Kunden braucht (Techniken »Anwendungsfälle«, »User Storys«).

Paul Schmidt sagt, dass er Termine eintragen und verschieben können will und zwischen einer Tages- und Wochenansicht wechseln möchte. Diese Anforderungen hält Maria Müller einzeln fest:

Neuen Termin in den Kalender eintragen

Vorhandenen Termin verschieben

Zur Tagesansicht wechseln

Zur Wochenansicht wechseln

1.9.2 Anforderungen aus Kundensicht

Der Kunde äußert einen weiteren Wunsch: Es soll möglich sein, in der Applikation Terminkategorien wie z. B. »beruflich« und »privat«, zu unterscheiden. Frau Müller will die Anforderungen ihres Kunden richtig verstehen. Dazu muss sie wissen, was genau der Kunde mit der fertigen Applikation an dieser Stelle machen will.

Also fragt sie nach und bekommt heraus, welche konkreten Vorstellungen Herr Schmidt hierzu im Kopf hat. Sie schreibt sie auf:

Neue Terminkategorie anlegen (z. B. beruflich, privat, Urlaub)

Einem neuen Termin eine bestimmte Kategorie zuweisen

Die Kategorie für einen bestehenden Termin ändern

Herr Schmidt beschreibt das Produkt aus seiner Sicht. Er beantwortet Frau Müller die Frage, was er alles mit dem fertigen Produkt machen können will. Dies ist die Basis für eine agile Produktentwicklung, damit der Kunde im weiteren Projektverlauf wirklich mitreden kann. Am Ende des Gesprächs hat Maria Müller ein Verständnis dafür entwickelt, was ihr Kunde eigentlich braucht. Da sie sich in ihrem Geschäft auskennt, kann sie den Aufwand für die Produktentwicklung abschätzen. Sie nennt dem Kunden den Endtermin der Entwicklung, der in zwei Monaten sein wird. Gleichzeitig vereinbart sie mit ihm, alle zwei Wochen ein Teilprodukt zu präsentieren. Außerdem erklärt sich Herr Schmidt bereit, kurzfristig für Nachfragen zu den Anforderungen zur Verfügung zu stehen. Frau Müller hat nun also eine ganze Reihe von sog. Anwendungsfällen gesammelt und versteht auf diesem Beschreibungsniveau, was der Kunde möchte.

Die zu Beginn gesammelten Anwendungsfälle geben erst einmal nur die Richtung für die ersten Schritte der Entwicklung vor. Im weiteren Verlauf der Zusammenarbeit wird der Kunde noch besser verstehen, was er genau braucht. Er kommt dann vielleicht auf weitere oder neue Ideen. Außerdem werden sich mögliche Missverständnisse aufklären. Änderungen an den Anforderungen werden daher von Anfang an fest eingeplant.

Die Summe der gesammelten Anwendungsfälle bildet den Startpunkt für die Produktentwicklung.

1.9.3 Produktentwicklung: die erste Runde

Nun kann Maria Müller die Produktentwicklung starten. Dazu bespricht sie gemeinsam mit ihrem Team, welche Anwendungsfälle im ersten Schritt innerhalb der ersten zwei Wochen umgesetzt werden sollen. Folgende Entscheidungskriterien spielen dabei eine Rolle:

Was ist dem Kunden besonders wichtig?

Welche Abhängigkeiten gibt es? Was gehört zusammen?

Was sollte z. B. aus technischen Gründen zuerst gemacht werden?

Was kann während der zwei Wochen geschafft werden?

Jetzt hat Frau Müller eine To-do-Liste für die nächsten zwei Wochen, die sog. erste Iteration. Diese Liste hängt sie an einer Pinnwand für alle im Projektbüro sichtbar auf (Task Board).

Task BoardIn unserem Beispiel sind die Anwendungsfälle gleichzeitig auch die Arbeitspakete. In der Praxis werden die Anwendungsfälle erst noch auf konkrete Arbeitspakete handlicher Größe (1 bis 5 Tage) heruntergebrochen. Für diese wird dann der Begriff »Tasks« verwendet. Die Tasks werden auf Karten geschrieben und an das Task Board gehängt, und zwar in den Bereich »To-do«.

Die gesammelten Anwendungsfälle als To-do

Task Board mit Iterationsplanung

Nun startet die Entwicklung. Jeden Tag trifft Maria Müller sich kurz mit dem Team am Task Board. In diesem Daily Stand-up-Meeting bespricht sie, wer gerade welche Aufgaben hat, und stellt sicher, dass alle gut vorankommen. Wenn jemand ein Problem nicht lösen kann, klärt sie, wer ihn unterstützt.

Wenn ein Entwickler eine Aufgabe vom Task Board übernimmt, hängt er die entsprechende Karte von »To-do« nach »In Work«. Er ist fortan für diese Karte verantwortlich, insbesondere dafür, dass die Karte rechtzeitig nach »Done« kommt, was erst möglich ist, wenn er die Aufgabe erledigt hat. Mit der Zeit wandern die Karten so über das Task Board.

Zwischendurch kommt ein Entwickler zu Frau Müller, weil er nicht weiß, wie genau der Dialog bei »Termin anlegen« aussehen soll. Soll bei der Eingabe des konkreten Datums ein Textfeld erscheinen oder eine kleine Kalenderansicht zur Auswahl eines Datums? Frau Müller klärt die Frage kurzfristig mit dem Kunden, so dass der Entwickler keine Zeit verliert.

Task Board während der Iteration

Wann immer ein Entwickler eine konkrete Frage zu Details eines Anwendungsfalles hat, sorgt die Chefin dafür, dass er schnell eine Antwort bekommt. Viele Fragen kann sie auch direkt beantworten, ohne Rücksprache mit dem Kunden.

1.9.4 Feedback zum Teilprodukt einholen

Nach zwei Wochen ist eine erste Version des Produktes fertig und vorführbereit (Inkrement). Dieses Teilprodukt bzw. Inkrement zeigt Frau Müller Herrn Schmidt. Er kann es nun selber ausprobieren. Er fügt neue Termine ein, verschiebt vorhandene etc. Dabei fällt ihm auf, dass er Termine gar nicht löschen kann. Diese Anforderung, die am Anfang des Projektes vergessen wurde, ist ihm sehr wichtig.

Daher nimmt Frau Müller jetzt also »Einen vorhandenen Termin löschen« als neuen Anwendungsfall auf. Was sie allerdings nicht tut, ist, ihn nun einfach dem Task Board hinzuzufügen! Denn dadurch würden sich Projektkosten und -dauer unkontrolliert verändern.

1.9.5 Die Planung anpassen

Gemeinsam mit ihrem Team schätzt Frau Müller daher erst einmal den Aufwand für den neuen Anwendungsfall. Es gibt grundsätzlich drei Möglichkeiten, wie dann weiter verfahren werden kann:

Der neue Anwendungsfall wird der Planung hinzugefügt. Gleichzeitig wird ein anderer Anwendungsfall mit gleichem Umfang, der dem Kunden aber weniger wichtig ist, aus der Planung gestrichen.

Der neue Anwendungsfall wird der Planung hinzugefügt und es wird vereinbart, dass das Projekt entsprechend länger läuft.

Der neue Anwendungsfall wird der Planung hinzugefügt und es wird vereinbart, dass der Kunde das Budget erhöht. Frau Müller kann dann vorübergehend einen weiteren Entwickler beschäftigen und das Projekt zum vereinbarten Termin abschließen.

Dem Kunden werden diese Optionen vorgestellt. Er entscheidet, wie die Planung angepasst werden soll. Da die Anforderungen aus seiner Sicht beschrieben sind, kann er auch die Konsequenzen von Streichungen und Verschiebungen einzelner Anforderungen besser abschätzen. In der Praxis verschieben sich dadurch häufig Anwendungsfälle, die dem Kunden nicht so wichtig sind, nach hinten in spätere Iterationen. Tendenziell bekommt der Kunde so in frühen Entwicklungsrunden die Produktmerkmale, die ihm besonders wichtig sind (Business Value).

1.9.6 Produktentwicklung: weitere Runden

Mit der angepassten Planung geht es jetzt weiter. Wie vor der ersten Runde legt Maria Müller nun fest, was in den kommenden zwei Wochen entwickelt werden soll. So startet die zweite Entwicklungsrunde. Während der Entwicklung stellen sie und ihr Team fest, dass sie nicht alle Anforderungen schaffen werden, die für diese Iteration geplant sind. Frau Müller kommuniziert ihr Problem rechtzeitig an Herrn Schmidt. Vielleicht bespricht sie dabei auch mit ihm, welche Anforderungen später realisiert werden könnten. Dann reduziert sie den Umfang so, dass sie die Iteration rechtzeitig abschließen können (auf die vertraglichen Aspekte dieser »agilen« Zusammenarbeit zwischen Auftraggeber und Auftragnehmer geht das Kapitel »Der agile Festpreis« näher ein).

Den Umfang zu reduzieren und damit termintreu zu bleiben, ist ein wichtiger Unterschied zur typischen klassischen Vorgehensweise. Im klassischen Projektmanagement werden Meilensteine verschoben, wenn es eng wird. Bei der iterativen Vorgehensweise werden dagegen die Iterationsenden eingehalten und dafür der Umfang reduziert. Das ist wichtig, um das Vertrauen der Stakeholder zu erhalten und immer wieder zeitnah Feedback von ihnen zu bekommen. Frau Müller gleicht damit das Ergebnis der Produktentwicklung immer wieder mit den Vorstellungen des Kunden ab. Runde für Runde (Iteration für Iteration) nähert sie sich so dem Produkt an, das der Kunde wirklich brauchen kann. Die folgende Abbildung zeigt diese Idee des schrittweisen Nachsteuerns.

Eine wesentliche Basis für das Agile Projektmanagement ist die Erkenntnis, dass Projektanforderungen ein bewegliches Ziel darstellen, da die tatsächlichen Anforderungen noch unklar bzw. unscharf sind (dargestellt durch die grünen Kreise). In diesem Sinne peilt der Projektleiter in jeder Iteration (grüne Pfeile) das Ziel (blaue Kästen) erneut an und steuert damit die Richtung der Entwicklung nach. Natürlich macht dieses Vorgehen nur dann Sinn, wenn man sich mit den erstellten Inkrementen (gelbe Kästen) dem Ziel auch immer weiter annähert. Dazu müssen die Anforderungen zumindest auf Ebene der groben Granularität weitgehend feststehen. Die agilen Prinzipien und Techniken dienen dann dazu, diese Annäherung in der Produktentwicklung zu unterstützen.

Stehen die Anforderungen im Detail fest (rote Punkte), so ist es durchaus sinnvoll, das Produkt entsprechend dem klassischen Wasserfall-Modell (roter Pfeil) zu entwickeln. In der Praxis stellt sich allerdings häufig heraus, dass die Annahme, die Anforderungen seien genauestens bekannt, ein Trugschluss ist. Dann führt das klassische Vorgehen zu dem zunächst verstandenen Produkt (oberes blaues Kästchen) und nicht zu dem tatsächlich gewünschten Produkt (unteres blaues Kästchen). Änderungen in den Anforderungen ergeben sich in der Praxis durch eine veränderte Sichtweise der Auftraggeber, einem neuen Verständnis der Problemstellung oder neuer zusätzlicher gewünschter Produkteigenschaften.

Agiles Nachsteuern

2 Das Agile Manifest: die Basis des Agilen Projektmanagements

Im Februar 2001 haben 17 Experten aus dem Bereich der Softwareentwicklung am Rande einer Konferenz ein Dokument erstellt, das Werte und Prinzipien für eine moderne Form der Softwareentwicklung beschreibt: das Agile Manifest.

2.1 Agile Werte

Agiles ManifestIm Agilen Manifest [BetA01] ist zu den agilen Werten Folgendes zu lesen:

Das agile Manifest: Die Werte

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 Interaktionen

mehr als

Prozesse und Werkzeuge

Funktionierende Software

mehr als

umfassende Dokumentation

Zusammenarbeit mit dem Kunden mehr als

mehr als

Vertragsverhandlung

Reagieren auf Veränderung mehr als

mehr als

das 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.

Werte, Agiles ManifestAuf diesen Werten basieren also die agilen Prinzipien und agilen Techniken, die in ihrer Summe das Agile Projektmanagement ausmachen. Eine wichtige Aussage im Manifest ist vor allem diejenige, dass auch die rechte Seite »geschätzt« wird. Es geht also darum, eine angemessene Balance zwischen den beiden Seiten zu finden. Letztlich benötigt man jeweils beide Seiten.

Beispiel

Nehmen wir das Wertepaar »Funktionierende Software mehr als umfassende Dokumentation«. Auch wenn man dem agilen Wert »Funktionierende Software« folgt, muss man trotzdem noch ein Handbuch für den Kunden erstellen und die Software so dokumentieren, dass eine Erweiterung der Funktionalität durch neue Mitarbeiter möglich ist.

2.1.1 Balance zwischen »agil« und »klassisch«

Wie wichtig dieser Gedanke einer Balance zwischen »agil« und »klassisch« gerade im klassischen Projektumfeld ist, zeigt das folgende Beispiel aus der Praxis.

Beispiel

In einem großen, internationalen Konzern gibt es einen Bereich, der seinen Kunden als Produkt das Outsourcing ihrer IT-Systeme anbietet. Für diese Kunden werden beispielsweise Webseiten, Webshops und zugehörige Prozesse betrieben. Bemerkt der Kunde ein Problem, beispielsweise, dass sein Webshop nur sehr langsam reagiert, so ruft er einfach eine Service-Hotline an. Der Hotline-Mitarbeiter stuft das Problem dann ein und eröffnet ein sog. Ticket in einem Vorgangssystem. Anschließend weist er das Ticket demjenigen Mitarbeiter zu, der für den Kunden verantwortlich ist. Das Vorgangssystem erzeugt automatisch eine E-Mail an den entsprechenden Mitarbeiter, so dass dieser über seine neue Aufgabe informiert ist. Vermutlich werden Sie solche Systeme aus der eigenen Berufspraxis kennen.

Im Konzern kommt es rund um das Ticket-System nun zu folgenden typischen Abläufen: Der Mitarbeiter, der für das Ticket verantwortlich ist, schaut es sich an. Stellt er fest, dass es vermutlich ein Datenbankproblem ist, sendet er das Ticket mit einem kurzen Vermerk an einen Datenbankexperten weiter. Dieser wiederum wirft einen kurzen Blick auf den Vorgang, denn so richtig Zeit hat er natürlich gerade nicht dafür. Er kommt zu dem Schluss, dass es sich eher um ein Problem in der Benutzeroberfläche handelt und schickt das Ticket an den entsprechenden Experten weiter. Wenn dieser allerdings gerade im Urlaub oder anderweitig nicht verfügbar ist, bekommt es ein Vertreter, der sich mit der Applikation des Kunden nicht gut auskennt. Er untersucht das Ganze kurz, findet keinen Anhaltspunkt für die Ursache des Problems und schickt das Ticket daher wieder an den Datenbankexperten zurück. Der Kunde, der nach wie vor Probleme mit seinem Webshop hat, ruft ein zweites Mal an, jetzt schon ziemlich unter Dampf. Er besteht darauf, dass das Problem »eskaliert« wird. Auf Seiten des Konzerns wird jetzt der sog. Escalation-Manager eingeschaltet.

Ticket-Ping-PongEskalation, Kunden-Die Zahl der Eskalationen durch Kunden ist irgendwann so hoch, dass das Management davon Wind bekommt und der Sache nachgeht. Es stellt sich heraus, dass es auf Ebene der Mitarbeiter bereits ein geflügeltes Wort für die Kernproblematik gibt: Ticket-Ping-Pong. Um diese Situation zu ändern, wird seitens des Managements ein mehrstufiges Programm von Kommunikationstrainings aufgesetzt, das alle Mitarbeiter durchlaufen müssen. Dieses Programm zieht sich über drei Jahre hin. Das Ergebnis liefern Messungen: Mit den Kommunikationstrainings ist eine deutliche Abnahme des Ticket-Ping-Pongs und eine erhöhte Kundenzufriedenheit verbunden.

Das interessante an diesem Beispiel ist, dass alle Mitarbeiter die Prozesse korrekt befolgen und das Werkzeug (Ticket-Tool) auch korrekt verwenden, und trotzdem nichts erreicht wird, was dem Kunden etwas bringt. Im Wesentlichen ging es bei der Lösung des Ticket-Ping-Pong-Problems also darum, den Fokus von »Prozesse und Werkzeuge« zu verschieben auf »Individuen und Interaktionen«. In den Kommunikationstrainings wurden dazu unter anderem die folgenden Lösungen erarbeitet:

»Wenn der Kunde anruft, versuchen wir schon beim ersten Telefonat möglichst viel Detailinformation zu bekommen.«

»Wir informieren den Kunden zwischendurch aktiv über den Stand der Fehlersuche und -behebung.«

»Wenn der Experte, dem wir das Ticket zuweisen, im nächsten Raum sitzt, gehen wir einfach mal vorbei und sehen, ob wir das Problem kurz gemeinsam besprechen können. Wenn er weiter weg sitzt, versuchen wir ihn kurz anzurufen.«

Für alle agilen Werte lassen sich zahlreiche solcher Praxisbeispiele finden, insbesondere im Kontext von Konzernen. Allgemein lässt sich die These aufstellen, dass Konzerne die Effizienz ihrer Strukturen teils vor allem dem systematischen Ausbau der rechten Seite verdanken. Denn die rechte Seite der Werte (also »Prozesse und Werkzeuge«, »umfassende Dokumentation«, »Vertragsverhandlung« und »Befolgen eines Plans«) sorgt für Struktur und Sicherheit. Dies wiederum sind Werte, die im Konzernumfeld viel gelten.