PRAXISLEITFADEN AGILITÄT

Die Daten für das Cataloging-in-Publication der Library of Congress in den USA sind beantragt.

ISBN: 978-1-62825-4-174

Herausgeber:Project Management Institute, Inc.14 Campus BoulevardNewtown Square, Pennsylvania 19073-3299 USATelefon: +1 610-356-4600Fax: +1 610-356-4647E-Mail: customercare@pmi.orgInternet: www.PMI.org

©2017 Project Management Institute, Inc. Alle Rechte vorbehalten.

Die Inhalte des Project Management Institute, Inc. sind durch die Urheberrechte der Vereinigten Staaten geschützt, die in den meisten Ländern anerkannt sind. Ein Nachdruck bzw. eine Reproduktion der Inhalte von PMI ist nur mit vorheriger Genehmigung gestattet. Weitere Einzelheiten verfügbar auf http://www.pmi.org/permissions.

Für Handelsbestellungen und Preisangaben ist die Independent Publishers Group zuständig:Independent Publishers GroupOrder Department814 North Franklin StreetChicago, IL 60610 USATelefon: +1 800-888-4741Fax: +1 312- 337-5985E-Mail: orders@ipgbook.com (nur für Bestellungen)

Bei allen sonstigen Anfragen wenden Sie sich bitte an das PMI Book Service Center.PMI Book Service CenterP.O. Box 932683, Atlanta, GA 31193-2683 USATelefon: +1-866-276-4764 (innerhalb der USA oder Kanada) oder +1-770-280-4129 (außerhalb der USA)Fax: +1-770-280-4113 E-Mail: info@bookorders.pmi.org

Gedruckt in den Vereinigten Staaten von Amerika. Ohne vorherige schriftliche Zustimmung des Herausgebers darf dieses Buch weder ganz noch auszugsweise vervielfältigt oder weitergegeben werden, unabhängig davon, in welcher Form und auf welche Art und Weise – sei dies elektronisch, von Hand, per Fotokopie, Aufzeichnung oder mittels Datenspeicherungs- oder -beschaffungssystem.

Das in diesem Buch verwendete Papier erfüllt die Norm “Permanent Paper Standard” der “National Information Standards Organization” (Z39.48—1984) der Vereinigten Staaten.

PMI, das PMI-Logo, PMBOK, OPM3, PMP, CAPM, PgMP, PfMP, PMI-RMP, PMI-SP, PMI-ACP, PMI-PBA, PROJECT MANAGEMENT JOURNAL, PM NETWORK, PMI TODAY, PULSE OF THE PROFESSION und das Motto MAKING PROJECT MANAGEMENT INDISPENSABLE FOR BUSINESS RESULTS sind eingetragene Marken des Project Management Institute, Inc. Für eine vollständige Liste der PMI-Marken wenden Sie sich an die PMI-Rechtsabteilung. Alle sonstigen hierin aufgeführten Marken, Dienstleistungsmarken, Handelsmarken, Handelsaufmachungen, Produktnamen und Logos sind das Eigentum ihrer jeweiligen Inhaber. Alle hierin nicht ausdrücklich gewährten Rechte sind vorbehalten.

SAFe ist eine eingetragene Marke von Scaled Agile, Inc.

Agile Alliance und das Agile Alliance-Logo sind Marken der Agile Alliance.

Dieser Leitfaden wurde zusammen mit der Agile Alliance® finanziert und wurde in Zusammenarbeit mit den Mitgliedern der Agile Alliance® entwickelt. Die Agile Alliance® befürwortet keine agile Methode oder Zertifizierung.

10 9 8 7 6 5 4 3 2 1

ANMERKUNG

Die Veröffentlichungen von Standards und Richtlinien durch das Project Management Institute, Inc. (PMI), zu denen das vorliegende Dokument zählt, werden durch einen freiwilligen Prozess der Entwicklung von Standards durch Konsens entwickelt. Dieser Prozess bringt Freiwillige zusammen und/oder erfragt die Meinung von Personen, die ein Interesse an dem durch diese Veröffentlichung abgedeckten Thema haben. Das PMI leitet zwar den Prozess und erstellt Regeln, um Fairness bei der Entwicklung des Konsens zu fördern, schreibt aber das Dokument nicht selbst und testet, bewertet und überprüft nicht unabhängig die Genauigkeit oder Vollständigkeit von Informationen oder die Zuverlässigkeit von Urteilen, die in seinen Veröffentlichungen zu Standards und Richtlinien enthalten sind.

Das PMI lehnt die Verantwortung für jede persönliche Verletzung, für Eigentums- und sonstige Schäden jeglicher Art ab, ob spezielle Schäden, mittelbare Schäden, Folgeschäden oder kompensatorischen Schadenersatz, die sich direkt oder indirekt aus der Veröffentlichung oder Anwendung dieses Dokuments oder dem Vertrauen auf dieses Dokument ergeben. Das PMI lehnt jede explizite oder implizite Verantwortung, Garantie oder Gewährleistung für die Genauigkeit oder Vollständigkeit sämtlicher hierin veröffentlichter Informationen und die Verantwortung oder Gewährleistung dafür ab, dass die Informationen in diesem Dokument einen besonderen Zweck oder ein spezielles Bedürfnis erfüllen. Das PMI verpflichtet sich nicht, die Leistung von Produkten oder Dienstleistungen eines einzelnen Herstellers oder Verkäufers aufgrund dieses Standards oder Ratgebers zu garantieren.

Die Tatsache, dass das PMI dieses Dokument veröffentlicht und verfügbar macht, stellt keine professionelle oder sonstige Dienstleistung für eine bestimmte Person oder Einrichtung oder in deren Namen dar und erfüllt auch keine Pflicht einer Person oder Einrichtung gegenüber jemand anderem. Jeder, der dieses Dokument verwendet, sollte sich auf sein eigenes unabhängiges Urteilsvermögen verlassen oder, falls angebracht, den Rat einer kompetenten Fachkraft heranziehen, um, unter welchen Umständen auch immer, die jeweils angemessene Sorgfaltspflicht zu bestimmen. Informationen und sonstige Standards zu dem in dieser Veröffentlichung behandelten Thema können von anderen Quellen erhältlich sein, die der Benutzer eventuell konsultieren möchte, um zusätzliche Standpunkte und Informationen zu bekommen, die nicht durch diese Veröffentlichung abgedeckt sind.

Es steht nicht in der Macht des PMI, die Einhaltung des Inhalts dieses Dokuments zu kontrollieren oder durchzusetzen und das PMI unternimmt auch keine diesbezüglichen Anstrengungen. Das PMI zertifiziert, testet und inspiziert keine Produkte, Entwürfe oder Anlagen unter Sicherheits- oder Gesundheitsgesichtspunkten. Dem PMI darf keine Zertifizierung und kein sonstiger Vermerk hinsichtlich der Erfüllung jeglicher auf Gesundheit oder Sicherheit bezogenen Informationen in diesem Dokument zugeschrieben werden, da diese einzig und allein in der Verantwortung des Zertifizierers oder des Urhebers des Vermerks liegen.

VORWORT

Das Project Management Institute und die Agile Alliance® haben diesen Praxisleitfaden erstellt, um ihrem jeweiligen Umfeld agile Arbeitsansätze näherzubringen. Ziel dieses Praxisleitfadens ist es, Projektteams mit Werkzeugen, situationsbezogenen Leitlinien und einem Verständnis über vorhandene agile Methoden und Ansätze auszustatten, um so zu besseren Ergebnissen zu kommen.

Der Einsatz agiler Vorgehensweisen ist nicht nur auf Softwareentwicklung beschränkt; auch Projektteams in anderen Branchen arbeiten damit. Beide Organisationen haben erkannt, dass es notwendig ist, für eine gelungene Verbreitung von Agilität eine gemeinsame Sprache und Offenheit und eine Bereitschaft zur Flexibilität der Art und Weise, wie Produkte und Liefergegenstände auf den Markt gebracht werden, zu etablieren. Darüber hinaus wissen beide Organisationen, dass es mehrere Wege gibt, um zu einer erfolgreichen Auslieferung zu gelangen. Es gibt ein breites Spektrum an Werkzeugen, Methoden und Rahmenwerken; Teams haben die Wahl unter mehreren Ansätzen und Praktiken, die zu ihrem Projekt und der Kultur ihrer Organisation passen, um das erwünschte Ergebnis zu erzielen.

Die Ausschussmitglieder des Praxisleitfadens Agilität bringen unterschiedliche Perspektiven mit und arbeiten nach unterschiedlichen Ansätzen. Einige Ausschussmitglieder sind unabhängige Berater, andere wiederum sind in Organisationen tätig. Sie alle arbeiten seit vielen Jahren nach agilen Methoden.

INHALT

1. EINFÜHRUNG .............................................................................................................................. 1

2. EINE EINFÜHRUNG IN AGILITÄT ................................................................................................. 72.1 Planbare Arbeit und Arbeit unter hoher Unsicherheit im Vergleich ............................... 72.2 Das Agile Manifest und agile Denkweise ........................................................................ 82.3 Lean und die Kanban-Methode ...................................................................................... 122.4 Unsicherheit, Risiko und Auswahl des Lebenszyklus ................................................... 13

3. AUSWAHL DES LEBENSZYKLUS ............................................................................................... 173.1 Merkmale von Projektlebenszyklen ............................................................................... 18

3.1.1 Merkmale von prognostizierten Lebenszyklen ................................................. 203.1.2 Merkmale von iterativen Lebenszyklen............................................................. 213.1.3 Merkmale von inkrementellen Lebenszyklen ................................................... 223.1.4 Merkmale von agilen Lebenszyklen .................................................................. 243.1.5 Agile Eignungskriterien ...................................................................................... 253.1.6 Merkmale von hybriden Lebenszyklen .............................................................. 263.1.7 Kombination aus agilem und plangetriebenem Ansatz .................................... 273.1.8 Überwiegend plangetriebener Ansatz mit einigen agilen Komponenten ......... 283.1.9 Ein überwiegend agiler Ansatz mit einer plangetriebenen Komponente ......... 283.1.10 Hybride Lebenszyklen und ihre Zweckdienlichkeit ........................................ 293.1.11 Hybride Lebenszyklen als Übergangsstrategie ............................................... 30

3.2 Agile Ansätze mischen ................................................................................................... 313.3 Projektfaktoren mit Einfluss auf die Anpassung ........................................................... 32

I

4. AGILITÄT IMPLEMENTIEREN: EINE AGILE UMGEBUNG SCHAFFEN .......................................... 334.1 Es beginnt mit einer agilen Denkweise ......................................................................... 334.2 Dienende Führung stärkt das Team ............................................................................... 33

4.2.1 Aufgaben der dienenden Führungsperson ........................................................ 344.2.2 Die Rolle des Projektmanagers in einer agilen Umgebung .............................. 374.2.3 Projektmanager arbeiten nach dem Prinzip der dienenden Führung .............. 38

4.3 Zusammensetzung des Teams ....................................................................................... 384.3.1 Agile Teams ........................................................................................................ 394.3.2 Agile Rollen......................................................................................................... 404.3.3 Generalisierte Spezialisten ............................................................................... 424.3.4 Teamstrukturen .................................................................................................. 434.3.5 Dedizierte Teammitglieder ................................................................................. 444.3.6 Teamarbeitsplätze .............................................................................................. 464.3.7 Überwindung von Organisations-Silos .............................................................. 47

5. AGILITÄT IMPLEMENTIEREN: AUSLIEFERUNG IN EINER AGILEN UMGEBUNG ......................... 495.1 Auftrag für Projekt und Team ......................................................................................... 495.2 Allgemeine agile Praktiken ............................................................................................ 50

5.2.1 Retrospektiven ................................................................................................... 505.2.2 Vorbereitung des Backlogs ................................................................................ 525.2.3 Feinabstimmung des Backlogs ......................................................................... 525.2.4 Daily Standups (tägliche Kurzbesprechungen) ................................................. 535.2.5 Präsentationen/ Prüfungen ................................................................................ 555.2.6 Planung für iterationsbasierte Agilität .............................................................. 555.2.7 Ausführungspraktiken, die Teams bei der Lieferung von Wert unterstützen ................................................................................................. 565.2.8 Wie Iterationen und Inkremente zur Auslieferung eines funktionsfähigen Produkts beitragen......................................................................... 57

5.3 Lösung von Herausforderungen in agilen Projekten ..................................................... 575.4 Messungen in agilen Projekten...................................................................................... 60

5.4.1 Agile Teams messen Ergebnisse ....................................................................... 61

II Inhalt

6. ÜBERLEGUNGEN ZUR PROJEKTAGILITÄT IN ORGANISATIONEN .............................................. 716.1 Veränderungsmanagement ............................................................................................ 71

6.1.1 Triebkräfte für Veränderungsmanagement ....................................................... 736.1.2 Änderungsbereitschaft ...................................................................................... 73

6.2 Organisationskultur ........................................................................................................ 756.2.1 Schaffung einer sicheren Umgebung ................................................................ 756.2.2 Bewertung der Kultur ......................................................................................... 75

6.3 Beschaffung und Verträge ............................................................................................. 776.4 Geschäftspraktiken ........................................................................................................ 796.5 Koordination und Abhängigkeiten mehrerer Teams (Skalieren) .................................. 80

6.5.1 Regelwerke ......................................................................................................... 806.5.2 Überlegungen ..................................................................................................... 80

6.6 Agilität und das Projektmanagementbüro .................................................................... 816.6.1 Ein agiles PMO ist wertgesteuert ...................................................................... 816.6.2 Ein agiles PMO sucht sich die richtigen Mitglieder .......................................... 816.6.3 Ein agiles PMO ist multidisziplinär .................................................................... 82

6.7 Struktur der Organisation .............................................................................................. 836.8 Weiterentwicklung der Organisation ............................................................................. 84

7. AUFRUF ZUM HANDELN ............................................................................................................ 87

ANLAGE A1 ZUORDNUNG ZUM PMBOK® GUIDE .............................................................................................. 89

ANLAGE A2 ZUORDNUNG ZUM AGILEN MANIFEST .......................................................................................... 97

ANLAGE A3 ÜBERBLICK ÜBER AGILE UND „LEAN“-REGELWERKE ................................................................. 99

ANHANG X1 MITWIRKENDE UND LEKTOREN .................................................................................................. 115

III

ANHANG X2 ASPEKTE, WELCHE DIE ANPASSUNG BEEINFLUSSEN ................................................................ 119

ANHANG X3 WERKZEUGE FÜR DIE AUSWAHL GEEIGNETER AGILER METHODEN .......................................... 125

QUELLENVERZEICHNIS ............................................................................................................... 139

LITERATURVERZEICHNIS ............................................................................................................ 141

GLOSSAR .................................................................................................................................... 149

INDEX ......................................................................................................................................... 157

IV Inhalt

LISTE DER ABBILDUNGEN UND TABELLEN

Abb. 2-1. Die vier Werte des Agilen Manifests ................................................................... 8

Abb. 2-2. Die zwölf Prinzipien hinter dem Agilen Manifest ............................................... 9

Abb. 2-3. Die Beziehung zwischen den Werten und Prinzipien des Agilen Manifests und allgemeinen Praktiken ............................................ 10

Abb. 2-4. Agilität ist ein Oberbegriff für viele Ansätze .................................................... 11

Abb. 2-5. Unsicherheits- und Komplexitätsmodell gemäß der Komplexitätsmatrix nach Stacey ...................................................................... 14

Abb. 3-1. Das Kontinuum von Lebenszyklen .................................................................... 19

Abb. 3-2. Prognostizierter Lebenszyklus .......................................................................... 21

Abb. 3-3. Iterativer Lebenszyklus. .................................................................................... 21

Abb. 3-4. Ein Lebenszyklus mit unterschiedlich großen Inkrementen ........................... 22

Abb. 3-5. Iterationsbasierte und flussbasierte agile Lebenszyklen ................................ 24

Abb. 3-6. Agile Entwicklung, gefolgt von plangetriebenem Rollout ................................ 27

Abb. 3-7. Gleichzeitige Verwendung von agilem und plangetriebenem Ansatz in Kombination ...................................................................................... 27

Abb. 3-8. Ein überwiegend plangetriebener Ansatz mit agilen Komponenten ............... 28

Abb. 3-9. Ein überwiegend agiler Ansatz mit einer plangetriebenen Komponente ........ 28

Abb. 5-1. Burndown-Chart für verbleibende Story Points ............................................... 62

Abb. 5-2. Burnup-Chart zur Anzeige fertiggestellter Story Points .................................. 63

Abb. 5-3. Beispiel eines Kanban-Boards .......................................................................... 65

Abb. 5-4. Feature-Grafik .................................................................................................... 67

Abb. 5-5. Burnup-Chart zum Produkt-Backlog ................................................................ 68

V

Abb. 5-6. Fertigstellungswert in einem agilen Kontext .................................................... 69

Abb. 5-7. Kumulatives Flussdiagramm fertiger Features ................................................ 70

Abb. 6-1. Die Beziehung zwischen Veränderungsmanagement und agilen Ansätzen ...... 72

Abb. 6-2. Beispiel zur Beurteilung von Organisationskultur ........................................... 76

Abb. 6-3. Initiale Reihenfolge eines Änderungs-Backlog ................................................ 85

Abb. 6-4. Verwendung von Backlogs und Kanban-Boards zur Organisation und Nachverfolgung von Änderungsarbeit ....................................................... 86

Abb. A3-1. Agile Ansätze nach Breite und Ausführlichkeit .............................................. 100

Abb. A3-2. Kanban-Board, welches die Grenzen der laufenden Arbeit zeigt, und ein Pull-System zur Optimierung des Arbeitsflusses ............................. 105

Abb. A3-3. Die Methoden der „Crystal“-Familie .............................................................. 106

Abb. A3-4. Projektlebenszyklus in der feature-gesteuerten Entwicklung ...................... 109

Abb. A3-5. DSDM-Ansatz zu einschränkungsgesteuerter Agilität .................................. 110

Abb. A3-6. Vertreter von Scrum-Teams nehmen an SoS-Teams teil ............................... 112

Abb. X3-1. Modell für die Eignung eines agilen Ansatzes ............................................... 127

Abb. X3-2. Engagement für die Bewertung des Ansatzes ............................................... 129

Abb. X3-3. Vertrauen in die Teambewertung .................................................................... 130

Abb. X3-4. Bewertung der Entscheidungsbefugnisse des Teams ................................... 130

Abb. X3-5. Bewertung der Teamgröße .............................................................................. 131

Abb. X3-6. Bewertung der Erfahrung ................................................................................ 131

Abb. X3-7. Bewertung des Zugangs zum Kunden/zu eigenen Unternehmensvertretern ................................................................................. 132

Abb. X3-8. Bewertung der Änderungswahrscheinlichkeit ............................................... 132

Abb. X3-9. Bewertung der Kritikalität von Produkt oder Dienstleistung ......................... 133

Abb. X3-10. Bewertung der inkrementellen Lieferung ....................................................... 133

Abb. X3-11. Spinnendiagramm der Eignungsbewertung ................................................... 134

Abb. X3-12. Apotheken-Projekt .......................................................................................... 135

Abb. X3-13. Beispielprojekt „Militärisches Nachrichtensystem“ ...................................... 137

VI Liste der Abbildungen und Tabellen

Tabelle 1-1. Elemente innerhalb und außerhalb des Leitfadens ............................................ 4

Tabelle 3-1. Merkmale von vier Kategorien von Lebenszyklen ............................................ 18

Tabelle 3-2. Anpassungsoptionen für eine bessere Passform ............................................. 32

Tabelle 4-1. Attribute erfolgreicher agiler Teams ................................................................. 40

Tabelle 4-2. Rollen in agilen Teams ...................................................................................... 41

Tabelle 5-1. Agile Schmerzpunkte und Möglichkeiten der Problemlösung ........................ 58

Tabelle A1-1. Abbildung von Projektmanagement-Prozessgruppen und Wissensgebieten ........................................................................................ 90

Tabelle A1-2. Anwendung von Agilität auf Wissensgebieten des PMBOK® Guide ................ 91

Tabelle A2-1. Die im Praxisleitfaden Agilität behandelten Werte des Agilen Manifests ....... 97

Tabelle A2-2. Zuordnung der Prinzipien hinter dem Agilen Manifest im Praxisleitfaden Agilität ................................................................................. 98

Tabelle A3-1. Scrum-Ereignisse und -Objekte ...................................................................... 101

Tabelle A3-2. eXtreme Programming und seine Praktiken .................................................. 102

Tabelle A3-3. Prägende Prinzipien und Eigenschaften der Kanban-Methode ..................... 104

Tabelle A3-4. Kernwerte und allgemeine Eigenschaften von Crystal .................................. 107

Tabelle A3-5. Die wichtigsten Elemente des Agile Unified Process ..................................... 111

Tabelle A3-6. Vergleich von LeSS und Scrum ....................................................................... 113

Tabelle X2-1. Anpassungsrichtlinien ..................................................................................... 121

VII

1

1EINFÜHRUNG

Willkommen zum Praxisleitfaden Agilität! Dieser Leitfaden wurde von Project Management Institute (PMI) und Agile Alliance® gemeinsam erarbeitet. Zu den Mitgliedern des Autorenteams, das diesen Leitfaden für die Praxis entwickelte, gehören ehrenamtliche Mitarbeiter beider Organisationen, die das Fachwissen zahlreicher Agilisten und Führungskräfte mit unterschiedlichen Perspektiven, Überzeugungen und Kulturen einfließen lassen.

Dieser Praxisleitfaden richtet sich mit seinen praktischen Anleitungen an Projektleiter und Teammitglieder, die ihre Planung und Ausführung von Projekten auf einen agilen Ansatz umstellen. Das Autorenteam ist sich durchaus bewusst, dass plangetriebene Ansätze und ihr Gebrauch nachdrückliche Unterstützung genießen und im Gegenzug es eine leidenschaftliche Diskussion zum Wechsel auf agile Denkweisen, Werte und Grundsätze gibt. Jedoch konzentriert sich dieser Praxisleitfaden auf einen praktischen Ansatz zur Agilität in Projekten. Dieser Praxisleitfaden will das Verständnis vermitteln, wie man von einem plangetriebenen Ansatz zu einem agilen Ansatz gelangen kann. So gibt es denn in beiden auch ähnliche Vorgänge − wie etwa die Planung −, die zwar unterschiedlich gehandhabt werden, aber in beiden Umgebungen vorkommen.

Unser Autorenteam ging mit einer agilen Denkweise an die Zusammenarbeit und Entwicklung dieser ersten Ausgabe des Praxisleitfadens heran. Im Zuge der Änderung von Technik und Kultur werden künftige Aktualisierungen und Feinabstimmungen des Praxisleitfadens aktuelle Ansätze widerspiegeln.

Unser Team entschied sich bei diesem Praxisleitfaden für einen weniger förmlichen und deshalb lockereren Schreibstil, als es bei PMI-Standards üblich ist. Der Leitfaden enthält neue Elemente wie Tipps, Infoboxen und Fallstudien, um wichtige Punkte und Schlüsselkonzepte besser zu veranschaulichen. Unser Team möchte den Praxisleitfaden mit diesen Änderungen leser- und benutzerfreundlicher gestalten.

Dieser Praxisleitfaden geht über die Anwendung der agilen Praxis in der Computersoftwareentwicklung hinaus, weil die agile Praxis sich inzwischen auch in andere Umgebungen als der Entwicklung von Computersoftware ausgebreitet hat. Fertigung, Bildung, Gesundheitswesen und andere Wirtschaftszweige übernehmen agile Praktiken zu einem unterschiedlichen Grad. Dieser Einsatz jenseits von Softwareentwicklung gehört ebenfalls zum Inhalt und Umfang dieses Praxisleitfaden.

2 Abschnitt 1

Warum also einen Praxisleitfaden Agilität und warum jetzt? Projektteams arbeiten schon seit mehreren Jahrzehnten gemäß agilen Methoden und Ansätzen. Das Agile Manifest [1]1 formulierte bestimmte Werte und Prinzipien der agilen Praxis, als der Einsatz agiler Praktiken merklich in Fahrt kam (siehe Abschnitt 2.1). Heute arbeiten Projektleiter und Teams in einem Umfeld, das von exponentiellen Fortschritten in der Technik und von Forderungen aufseiten der Kunden nach immer schnellerer Auslieferung von Werten umgewälzt wird. Agile Methoden und Ansätze ermöglichen einen wirksamen Umgang mit disruptiven (umwälzenden) Technologien. Darüber hinaus setzt das erste agile Prinzip die Zufriedenheit des Kunden an oberste Stelle und ist der Schlüssel zur Lieferung von Produkten und Dienstleistungen, die den Kunden begeistern (siehe Abschnitt 2.1). Schnelle und transparente Rückkopplungsschleifen zum Kunden sind dank dem weit verbreiteten Einsatz von Social Media allgemein verfügbar. Deshalb können Organisationen ihren Blick nicht länger nach innen richten, sondern müssen nach außen in Richtung Kundenerlebnis schauen, wenn sie wettbewerbsfähig und relevant bleiben wollen.

1 Die Zahlenangaben in Klammern beziehen sich auf das Quellenverzeichnis am Ende dieses Praxisleitfadens.

AGILITÄTSBASIERTES LERNEN

Das Bildungswesen ist ein fruchtbarer Boden und wie geschaffen für die Verbreitung agiler Praktiken jenseits der Softwareentwicklung. Lehrer an Realschulen und Gymnasien und Dozenten an Universitäten in aller Welt beginnen mit dem Einsatz agiler Praktiken, um eine Kultur des Lernens zu schaffen. Agile Methoden werden eingesetzt, um den Fokus auf die Priorisierung konkurrierender Anliegen zu lenken. Persönlicher Austausch, sinnvolles Lernen, sich selbst organisierende Teams, inkrementelles und iteratives Lernen unter Einsatz der Phantasie sind allesamt agile Grundsätze, die die Denkweise der Schulklasse ändern und Bildungsziele fördern können (Briggs, 2014).*

*Briggs, Sara. „Agile Based Learning: What Is It and How Can It Change Education?“ Opencolleges.edu.au 22. Februar 2014, zitiert nach http://www.opencolleges.edu.au/informed/features/agile-based-learning-what-is-it-and-how-can-it-change-education/

3

Disruptive Technologien führen durch den Abbau von Zugangsbarrieren zu raschen Veränderungen der Rahmenbedingungen. Reifere Organisationen neigen zunehmend dazu, sehr komplex zu sein und Innovationen oft nur schleppend umzusetzen, und sie hinken hinterher, wenn es darum geht, ihren Kunden neue Lösungen zu liefern. Diese Organisationen finden sich im Wettbewerb mit kleineren Organisationen und Startups wieder, die in der Lage sind, rasch Produkte herzustellen, die den Bedürfnissen des Kunden entsprechen. Dieses Tempo der Veränderungen wird weiterhin große Organisationen antreiben, eine agile Denkweise anzunehmen, damit sie wettbewerbsfähig bleiben und ihren Marktanteil halten können.

Der Praxisleitfaden Agilität ist projektorientiert und behandelt die Auswahl des Projektlebenszyklus, die Implementierung agiler Praktiken und Überlegungen zu agilen Projekten auf Organisationsebene. Veränderungsmanagement ist unerlässlich für die Implementierung oder Umstellung von Praktiken, liegt aber außerhalb von Inhalt und Umfang dieses Praxisleitfadens, weil das Veränderungsmanagement eine eigenständige Disziplin ist. Eingehendere Informationen über Veränderungsmanagement finden sich in Managing Change in Organizations—A Practice Guide [2].

Weitere Elemente, die dem Inhalt und Umfang dieses Praxisleitfadens entsprechen bzw. darüber hinausgehen, sind in Tabelle 1-1 aufgeführt.

DISRUPTIVE TECHNOLOGIE

Disruptive Technologie wird besonders durch die Umstellung auf Cloud-Computing möglich. Unternehmen in aller Welt nutzen das Modell für schnellen und billigen Zugang zu Rechnerressourcen und für den Zugang zu traditionellen Märkten. Cloud-Computing verlangt am Anfang weniger Vorabinvestitionen und wird stattdessen im Lauf der Zeit über ein Abonnement in Form eines zeit- oder nutzungsabhängigen Modells bezahlt. Aktualisierungen von Anwendungen, der Infrastruktur oder von Plattformen werden auf iterative und inkrementelle Weise in die Cloud gestellt und halten dadurch Schritt mit den technischen Verbesserungen und den sich entwickelnden Anforderungen der Kunden.

4 Abschnitt 1

Tabelle 1-1. Elemente innerhalb und außerhalb des Leitfadens

Innerhalb von Inhalt und Umfang Außerhalb von Inhalt und Umfang

Implementierung agiler Ansätze auf Projekt- oder Teamebene

Behandlung der meisten agilen Ansätze, die nach Branchenerhebungen besonders gefragt sind

Zu berücksichtigende Eignungsfaktoren bei der Auswahl eines agilen Ansatzes bzw. einer agilen Praxis

Zuordnung von agilen Prozessen zu Prozessen und Wissensgebieten des PMBOK® Guide

Erörterung über den Einsatz von Agile in anderen Disziplinen als Softwareentwicklung

Anleitung, Methoden und Ansätze, die bei der Implemen-tierung von Agile in Projekten oder Organisationen zu berücksichtigen sind

Definitionen allgemein akzeptierter Begriffe

Organisationsweite Implementierung von Agile oder Einrichtung agiler Programme

Behandlung von Nischenansätzen, unternehmensspezi-fischen Verfahren oder Methoden mit unvollständigen Lebenszyklen

Empfehlung oder Fürsprache für eine(n) bestimmte(n) Ansatz/Praxis

Änderung oder Abwandlung von Prozessen bzw. Wissensgebieten des PMBOK® Guide

Beseitigung des Einflusses der Softwareindustrie auf agile Ansätze (Hinweis: Software ist in diesem Praxis-Guide enthalten, obwohl der Einsatz von Agile in vielen anderen Branchen jenseits von Software zunimmt.)

Schrittweise, präskriptive Anleitungen zur Implementierung von Agile in Projekten oder Organisationen

Neue Begriffe bzw. Definitionen

Dieser Praxisleitfaden ist für Projektteams gedacht, die sich in der verworrenen Mitte zwischen plangetriebenem und agilem Ansatz befinden, die versuchen, rasche Innovation und Komplexität anzugehen, und die sich für die Verbesserung des Teams einsetzen. Dieser Praxisleitfaden liefert nützliche Orientierungshilfen für erfolgreiche Projekte, die Geschäftswert liefern, um die Erwartungen und Bedürfnisse der Kunden zu erfüllen.

5

Dieser Praxisleitfaden gliedert sich wie folgt:

Abschnitt 2 Eine Einführung in Agilität: Dieser Abschnitt beschreibt die Denkweise, Werte und Prinzipien des Agilen Manifests. Darin werden zudem die Konzepte von Arbeit in stabilen und volatilen Umgebungen sowie die Zusammenhänge zwischen schlanken Ansätzen (lean), der Kanban-Methode und agilen Ansätzen behandelt.

Abschnitt 3 Auswahl des Lebenszyklus: Dieser Abschnitt stellt die in diesem Praxisleitfaden erörterten Lebenszyklen vor. Hier werden auch Eignungskriterien, die Anpassung von Leitlinien und häufige Kombinationen von Ansätzen besprochen.

Abschnitt 4 Agilität implementieren: Erschaffung einer agilen Umgebung: Dieser Abschnitt behandelt entscheidende Faktoren, die bei der Schaffung einer agilen Umgebung zu berücksichtigen sind, wie dienende Führung (servant leadership) und Zusammensetzung des Teams.

Abschnitt 5 Agilität implementieren: Auslieferung in einer agilen Umgebung: Dieser Abschnitt enthält Informationen zur Organisation von Teams sowie allgemeine Praktiken, die Teams zur regelmäßigen Lieferung von Kundenwert einsetzen können. Hier sind Beispiele empirischer Messungen für Teams und zur Statusmeldung aufgeführt.

Abschnitt 6 Organisatorische Überlegungen zur Projektagilität: In diesem Abschnitt werden Faktoren der Organisation untersucht, die den Gebrauch agiler Ansätze beeinflussen, darunter Kultur, Umsetzungsbereitschaft, Geschäftspraktiken und die Rolle eines Projektmanagementbüros.

Abschnitt 7 Aufruf zum Handeln: Der Aufruf zum Handeln bittet um Beiträge, welche die fortlaufende Verbesserung dieses Praxisleitfadens ermöglichen.

Anlagen, Anhänge, Quellenverzeichnis, Bibliografie und Glossar enthalten weitere nützliche Informationen und Begriffsdefinitionen.

uu Anlagen. Enthalten obligatorische Angaben, die zu umfangreich für die Aufnahme in den allgemeinen Teil des Praxisleitfadens sind.

uu Anhänge. Enthalten nicht obligatorische Informationen, die den allgemeinen Teil des Praxisleitfadens ergänzen.

uu Quellenverzeichnis. Zeigt, wo Standards und andere Publikationen zu finden sind, die in diesem Praxisleitfaden genannt werden.

uu Bibliografie. Nennt abschnittsbezogen weitere Publikationen, die ausführliche Angaben zu den Themen in diesem Praxisleitfaden enthalten.

uu Glossar. Bietet eine Liste von Begriffen und zugehöriger Definitionen, die in diesem Praxisleitfaden verwendet werden.

7

2EINE EINFÜHRUNG IN AGILITÄT

2.1 PLANBARE ARBEIT UND ARBEIT UNTER HOHER UNSICHERHEIT IM VERGLEICH

Projektarbeit erstreckt sich von planbarer Arbeit bis zu Arbeit unter hoher Unsicherheit. Projekte planbarer Arbeit zeichnen sich durch eindeutige Verfahren aus, die sich bei ähnlichen Projekten in der Vergangenheit als erfolgreich erwiesen haben. Die Herstellung eines Autos, Elektrogeräts oder eines Hauses nach einem fertigen Entwurf sind Beispiele planbarer Arbeit. Die Produktion und einschlägigen Prozesse sind in der Regel gut bekannt und es gibt meist nur geringe Ausführungsunsicherheit und -risiken.

Neue Entwürfe, neue Problemlösungen und neuartige Arbeit sind exploratorisch. Hier müssen Fachleute zusammenarbeiten und Probleme lösen, um zu einem Ergebnis zu gelangen. Beispiele für Berufe, deren Arbeit mit einem hohen Grad an Unsicherheit behaftet ist, sind Software-Entwickler, Produktdesigner, Ärzte, Lehrer, Rechtsanwälte und viele Ingenieure. Angesichts der zunehmenden Automatisierung von planbarer Arbeit befassen sich Projektteams stärker mit Projekten mit hoher Unsicherheit, welche die in diesem Praxisleitfaden beschriebenen Methoden erfordern.

Projekte mit hoher Unsicherheit zeichnen sich durch hohe Änderungsfrequenz, Komplexität und Risiken aus. Diese Eigenschaften können für herkömmliche planungsgetriebene Ansätze problematisch werden, da diese darauf abzielen, die meisten Anforderungen bereits im Voraus zu bestimmen und die Änderungen durch ein Änderungsantragsverfahren zu steuern. Agile Ansätze wurden dagegen geschaffen, um die Machbarkeit in kurzen Zyklen auszuloten und auf der Grundlage von Evaluierung und Feedback rasch anzupassen.

8 Abschnitt 2

2.2 DAS AGILE MANIFEST UND AGILE DENKWEISE

Vordenker in der Softwarebranche formalisierten die agile Bewegung 2001 mit der Veröffentlichung des Manifests für Agile Softwareentwicklung (siehe Abb. 2-1).

Abb. 2-1. Die vier Werte des Agilen Manifests

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 Vertragsverhandlung

Reagieren auf Veränderung 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.

© 2001, die Verfasser des Agilen Manifests

9

Aus diesen Werten flossen zwölf klärende Prinzipien; zur Erläuterung siehe Abb. 2-2.

Abb. 2-2. Die zwölf Prinzipien hinter dem Agilen Manifest

1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

2. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.

3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.

4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.

5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen.

6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.

7. Funktionierende Software ist das wichtigste Fortschrittsmaß.

8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.

10. Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.

11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.

12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.

10 Abschnitt 2

Obwohl diese Prinzipien ihren Ursprung in der Softwarebranche haben, werden sie inzwischen in vielen anderen Branchen angewendet.

Die Verkörperung von Denkweise, Werten und Prinzipien definiert den agilen Ansatz. Die verschiedenen agilen Ansätze, nach denen heute gearbeitet wird, haben gemeinsame Wurzeln in der agilen Denkweise, den agilen Werten und den agilen Prinzipien. Die Beziehung ist in Abb. 2-3 dargestellt.

Abb. 2-3. Die Beziehung zwischen den Werten und Prinzipien des Agilen Manifests und allgemeinen Praktiken

Wie in Abb. 2-3 gezeigt, stellt das Modell nach Ahmed Sidky Agilität als Denkweise dar, die von den Werten des Agilen Manifests definiert, von den Prinzipien des Agilen Manifests geleitet und durch unterschiedliche Praktiken umgesetzt wird. Obwohl der Begriff „agil“ erst nach dem Manifest allgemeine Verbreitung erfuhr, gab es die von den Projektteams heute verwendeten Ansätze und Methoden bereits viele Jahre, in einigen Fällen sogar Jahrzehnte, vor dem Agilen Manifest.

Agilität ist eine Denkweise, die sich durch Werte definiert, von Prinzipien geleitet wird und durch viele verschiedene Praktiken in Erscheinung tritt. Agilisten wählen die Praktiken je nach Bedarf aus.

Vier Werte ZwölfPrinzipien PraktikenAgile

Denkweise

11

Abb. 2-4. Agilität ist ein Oberbegriff für viele Ansätze

Agile Ansätze und agile Methoden sind übergeordnete Begriffe, die eine Vielzahl von Rahmenwerken und Methoden abdecken. Abb. 2-4 stellt Agilität in einen Zusammenhang und verbildlicht den Oberbegriff, der sich auf jede Art von Ansatz, Methode, Rahmenwerk, Verfahren oder Praxis bezieht, die die Werte und Prinzipien des Agilen Manifests erfüllen. Abb. 2-4 zeigt außerdem Agilität und die Kanban-Methode als Teilmengen von Lean, weil sie die eigens benannten Instanzen der schlanken Denkweise (lean thinking) sind, denen schlanke Konzepte (lean concepts) gemeinsam sind, wie: „Ausrichtung auf Wert“, „kleine Losgrößen“ und „Vermeidung von Verschwendung“.

AgilitätKanban

Scrum

Crystal

ScrumBan

AUP

FDDXP

DSDM

Lean

Ist Agilität ein Ansatz, eine Methode, eine Praxis, ein Verfahren oder ein Rahmenwerk? Je nach Situation könnte jeder dieser Begriffe zutreffen. Dieser Praxisleitfaden verwendet den Begriff „Ansatz“, es sei denn, einer der übrigen Begriffe ist offensichtlich zutreffender.

12 Abschnitt 2

Im Allgemeinen gibt es zwei Strategien, um agilen Werten und Prinzipien zu entsprechen. Die erste besteht darin, einen formellen agilen Ansatz zu wählen, der bewusst gestaltet wurde und nachweislich zu den erwünschten Ergebnissen führt. Dann wird Zeit gegeben, die agilen Ansätze zu lernen und zu verstehen, bevor eine Änderung oder Anpassung durchgeführt wird. Verfrühte und planlose Anpassung kann die Wirkung des Ansatzes und damit den Nutzen schmälern. (Siehe Anhang X2 zu Anpassungsüberlegungen).

Bei der zweiten Strategie werden Änderungen so in Projektpraktiken implementiert, dass sie dem Projekt-zusammenhang entsprechen und zu Fortschritt bei einem grundsätzlichen Wert oder Prinzip führen. Es werden Timeboxen zur Erstellung von Features oder bestimmte Methoden zur iterativen Feinabstimmung von Features verwendet. Eine Überlegung ist die Aufteilung eines großen Projekts in mehrere Auslieferungen, wenn der spezifische Projektzusammenhang dafür geeignet ist. Es werden Änderungen implementiert, die dem Projekt zum Erfolg verhelfen. Die Änderungen müssen dabei nicht Teil der formellen Praktiken der Organisation sein. Das endgültige Ziel besteht nicht darin, agil um der Agilität willen zu sein, sondern in der Lieferung eines ständigen Wertflusses an Kunden und in der Verwirklichung besserer Geschäftsergebnisse.

2.3 LEAN UND DIE KANBAN-METHODE

Eine Betrachtungsweise der Beziehung zwischen Lean, Agilität und der Kanban-Methode besteht darin, Agilität und die Kanban-Methode als Nachkommen von Lean Thinking (schlanke Denkweise) zu sehen. Mit anderen Worten: Schlanke Denkweise ist eine Obermenge, die Attribute mit Agilität und Kanban teilt.

Dieses gemeinsame Erbe weist starke Ähnlichkeiten auf und konzentriert sich auf Lieferung von Wert, Respekt vor Menschen, Transparenz, Anpassung an Veränderungen, kontinuierliche Verbesserung und Vermeidung von Verschwendung. Projektteams finden es manchmal nützlich, verschiedene Methoden zu mischen – was immer für die Organisation oder das Team funktioniert, sollte unabhängig vom jeweiligen Ursprung gemacht werden. Ziel ist es, das beste Ergebnis unabhängig vom verwendeten Ansatz zu erreichen.

Die Kanban-Methode orientiert sich am ursprünglichen System der schlanken Fertigung und wird speziell für Wissensarbeit eingesetzt. Sie kam Mitte der 2000er Jahre als Alternative zu den damals vorherrschenden agilen Methoden auf.

13

Die Kanban-Methode ist freier als manche agilen Ansätze und weniger disruptiv, weil sie den ursprünglichen Ansatz des „Beginne dort, wo du bist“ verkörpert. Projektteams können die Kanban-Methode relativ leicht einführen und sich an andere agile Ansätze herantasten, wenn sie dies für notwendig oder geeignet erachten. Weitere Einzelheiten zur Kanban-Methode finden sich in Anlage A3, Übersicht über agile und schlanke Rahmenwerke.

2.4 UNSICHERHEIT, RISIKO UND AUSWAHL DES LEBENSZYKLUS

Manche Projekte sind mit beträchtlicher Unsicherheit behaftet, was ihre Anforderungen betrifft und wie diese Anforderungen mit dem aktuellen Wissen und der vorhandenen Technik erfüllt werden sollen. Diese Unsicherheit kann zu einer hohen Änderungsfrequenz und hoher Komplexität im Projekt führen. Diese Eigenschaften sind in Abb. 2-5 gezeigt.

Mit der Zunahme der Unsicherheit in einem Projekt steigt auch das Risiko von Nacharbeit und die Notwendigkeit, einen anderen Ansatz zu verwenden. Um die Auswirkung dieser Risiken abzufedern, wählen Teams Lebenszyklen, die ihnen die Bearbeitung von Projekten mit einem hohen Grad an Unsicherheit durch kleine inkrementelle Arbeitsschritte erlauben.

Wenn Teams in kleinen Schritten (increments) arbeiten, können sie ihre Arbeit überprüfen und ggf. ihre nächsten Schritte ändern. Wenn Teams in kleinen Schritten liefern, können sie die wirklichen Anforderungen des Kunden schneller und genauer verstehen als bei einer statischen, schriftlichen Spezifikation.

FA

LL Es gibt und wird vermutlich immer viele Diskussionen um die Kanban-Methode und die

Frage geben, ob sie zur schlanken oder agilen Bewegung gehört. Sie wurde in und um schlanke Fertigung entwickelt, genießt aber allgemeine Verbreitung in agilen Umgebungen.

14 Abschnitt 2

Uns

iche

rhei

t der

Anf

orde

rung

en

Hohe

Uns

iche

rhei

tGe

ringe

Uns

iche

rhei

t

Technischer Grad der Unsicherheit

Geringe Unsicherheit Hohe Unsicherheit

Grundsätzlichriskant

Adaptive Ansätze sind hier

gut geeignet

Lineare Ansätzesind hier

gut geeignet

Kompliziert

Komplex

Chaos

Einfach

Abb. 2-5. Unsicherheits- und Komplexitätsmodell gemäß der Komplexitätsmatrix nach Stacey

Teams können Projekte mit klaren und stabilen Anforderungen und klaren technischen Herausforderungen ohne große Schwierigkeiten planen und handhaben. Wenn jedoch die Unsicherheit im Projekt steigt, steigt auch die Wahrscheinlichkeit von Änderungen, verschwendeter Arbeit und Nacharbeit, was teuer und zeitraubend ist.

15

Manche Teams haben Projektlebenszyklen weiterentwickelt, um iterative und inkrementelle Ansätze zu verwenden. Viele Teams stellen fest, dass es ihnen leichter fällt auf Änderungen zu reagieren, wenn sie die Anforderungen iterativ untersuchen sowie schrittweise und dafür häufiger liefern. Diese iterativen und inkrementellen Ansätze mindern Verschwendung und Nacharbeit, weil die Teams Feedback bekommen. Diese Ansätze arbeiten mit:

uu sehr kurzen Rückkopplungsschleifen

uu häufiger Anpassung des Prozesses

uu Neuausrichtung der Prioritäten

uu regelmäßig aktualisierten Plänen

uu häufiger Auslieferung.

TIP

P

Was bedeuten einfache, komplizierte und komplexe Projekte? Denken Sie an Großprojekte wie den Berliner Flughafen. Oberflächlich betrachtet schien das Projekt ziemlich überschaubar: einen weiteren, ausreichend großen, Flughafen bauen. Es bestand starkes Einvernehmen in Bezug auf die Voraussetzungen (siehe Y-Achse in Abb. 2-5). Es bestand wenig Unsicherheit darüber, wie das Projekt fortschreiten sollte, als das Projekt begann. Und wie bei vielen Großprojekten gab es auch hier unterwegs einige Überraschungen.

Wenn ein Team an einem Projekt arbeitet, bei dem es wenig Gelegenheit für zwischenzeitige Liefergegenstände oder wenig Gelegenheit für Prototypen gibt, wird das Team höchstwahrscheinlich einen prognostizierten Lebenszyklus für das Management wählen. Das Team kann aus Erfahrungen lernen, aber keine agilen Ansätze zur Handhabung der iterativen Aufdeckung von Anforderungen bzw. keine inkrementellen Liefergegenstände für Feedback nutzen.

Das Flughafenprojekt war keinesfalls einfach. Allerdings haben viele Projekte, die in der Komplexitätsmatrix nach Stacey unten links beginnen, keine echte Möglichkeit, auf andere Ansätze umzustellen. Das Projekt ist nach den Anforderungen und den Auslieferungsmöglichkeiten zu bewerten, um den besten Ansatz für den Lebenszyklus des Projekts festzulegen.

16 Abschnitt 2

Diese iterativen, inkrementellen und agilen Ansätze funktionieren gut bei Projekten mit neuen oder neuartigen Werkzeugen, Methoden, Materialien oder Anwendungsgebieten. (Siehe Abschnitt 3 über die Auswahl des Lebenszyklus.) Sie funktionieren auch gut für Projekte, die:

uu Forschung und Entwicklung benötigen

uu eine hohe Änderungsfrequenz aufweisen

uu mit unklaren oder unbekannten Anforderungen, Unsicherheit oder Risiko behaftet sind oder

uu ein schwer zu beschreibendes Ziel haben.

Mit dem Bau eines kleinen Inkrements, das dann getestet und geprüft wird, kann das Team in kurzer Zeit und zu geringen Kosten Unsicherheit ausloten, das Risiko senken und die Lieferung des geschäftlichen Werts maximieren. Diese Unsicherheit kann sich auf die Eignung und Anforderungen (wird das richtige Produkt erstellt?), auf technische Machbarkeit und Leistung (kann das Produkt so erstellt werden?) oder auf Prozess und Mitarbeiter (kann das Team so effektiv arbeiten?) beziehen. Alle drei Eigenschaften – Produktspezifikation, Lieferfähigkeit und Prozesseignung – besitzen in der Regel Elemente mit einem hohen Grad von Unsicherheit.

Allerdings sind iterative und inkrementelle Ansätze nicht uneingeschränkt anwendbar. Wenn sowohl technische Unsicherheit als auch Unsicherheit der Anforderungen sehr hoch sind (oben rechts in Abb. 2-5), dann verschiebt sich das Projekt von komplex zu chaotisch. Damit das Projekt auf zuverlässige Weise realisierbar wird, muss eine der Variablen (sowohl technische Unsicherheit als auch Unsicherheit der Anforderungen) eingeschränkt bleiben.

17

3AUSWAHL DES LEBENSZYKLUS

Projekte können viele Formen annehmen, daher gibt es eine Vielzahl von Möglichkeiten, sie anzugehen. Projektteams müssen die Eigenschaften und verfügbaren Optionen kennen, damit sie den Ansatz auswählen können, der für die jeweilige Situation am meisten Erfolg verspricht.

Dieser Praxisleitfaden nennt vier Typen von Lebenszyklen, die wie folgt definiert werden:

uu Prognostizierter Lebenszyklus. Ein traditionellerer Ansatz, bei dem die meiste Planung im Vorfeld und die Ausführung dann in einem Durchgang erfolgt; ein sequenzieller Prozess.

uu Iterativer Lebenszyklus. Ein Ansatz, bei dem Feedback zulässig ist, um unfertige Arbeit zu verbessern und diese Arbeit abzuändern.

uu Inkrementeller Lebenszyklus. Dieser Ansatz erzeugt fertige Liefergegenstände, die der Kunde eventuell sofort einsetzen kann.

uu Agiler Lebenszyklus. Ein sowohl iterativer als auch inkrementeller Ansatz zur Weiterentwicklung von Aufgaben und häufigen Lieferung.

WIE SOLL MAN NICHT-AGILE ANSÄTZE BEZEICHNEN?

Es gibt keinen Einzelbegriff, unter dem man alle nicht-agilen Ansätze zusammenfassen könnte. Anfangs verwendete der Praxisleitfaden den Begriff plangesteuert, um die Betonung des im Voraus ausgearbeiteten Plans und die anschließende Ausführung dieses Plans zu beschreiben. Bisweilen werden die Bezeichnungen Wasserfall oder seriell für diesen Lebenszyklus bevorzugt. Letzten Endes einigten wir uns auf den Begriff plangetrieben bzw. prognostiziert, weil er im A Guide to the Project Management Body of Knowledge (PMBOK® Guide) [3] und in der Software Extension to the PMBOK® Guide Fifth Edition [4] verwendet wird.

Viele Organisationen befinden sich nicht in diesen Extremsituationen, sondern eher irgendwo in der Mitte. Das ist nur natürlich, aber es braucht eine Möglichkeit, um die beiden Enden des Spektrums zu diskutieren. Wenn agil an einem Ende liegt, dann ist das andere Ende plangetrieben.

18 Abschnitt 3

3.1 MERKMALE VON PROJEKTLEBENSZYKLEN

Tabelle 3-1 fasst die Merkmale der vier Kategorien von Lebenszyklen zusammen, die in diesem Praxisleitfaden besprochen werden.

Tabelle 3-1. Merkmale von vier Kategorien von Lebenszyklen

Es muss darauf hingewiesen werden, dass alle Projekte diese Merkmale aufweisen – kein Projekt ist jemals völlig frei von Überlegungen zu Anforderungen, Auslieferung, Änderung und Zielen. Die einem Projekt innewohnenden Merkmale bestimmen, welcher Lebenszyklus am besten zum Projekt passt.

Ein anderer Weg zum Verständnis der unterschiedlichen Projektlebenszyklen ist ein Kontinuum, das von den prognostizierten Zyklen an einem Ende bis zu den agilen Zyklen am anderen Ende reicht und in dessen Mitte die überwiegend iterativen oder inkrementellen Zyklen angesiedelt sind.

Abb. X3-1 in Anlage X3 des PMBOK® Guide – sechste Auflage zeigt das Kontinuum als flache Linie. Diese Sicht betont die Verschiebung der Projektmerkmale von einem Ende zum anderen. Eine andere Darstellungsweise für das Kontinuum ist ein Quadrat wie in Abb. 3-1.

Anforderungen Maßnahmen Lieferung ZielAnsatz

Merkmale

Plangetrieben

Iterativ

Inkrementell

Agil

Fest

Dynamisch

Dynamisch

Dynamisch

Wird einmal für das gesamte Projekt durchgeführt

Wird wiederholt, bis es richtig ist

Wird für ein bestimmtes Inkrement einmal durchgeführt

Wird wiederholt, bis es richtig ist

Eine einzelne Lieferung

Eine einzelne Lieferung

Häufige kleinere Lieferungen

Häufige kleine Lieferungen

Kosten steuern

Richtigkeit der Lösung

Schnelligkeit

Wert für den Kunden durch häufige Lieferungen und Feedback

19

Abb. 3-1. Das Kontinuum von Lebenszyklen

Kein Lebenszyklus passt perfekt zu allen Projekten. Vielmehr gibt es für jedes Projekt eine Stelle im Kontinuum, die ein optimal ausgewogenes Verhältnis der Merkmale für den spezifischen Kontext bietet. Insbesondere gilt:

uu Prognostizierte Lebenszyklen. Nutzen das, was bekannt und erwiesen ist. Dank dieser geringeren Unsicherheit und Komplexität können Teams die Arbeit in eine Abfolge vorhersagbarer Gruppierungen gliedern.

uu Iterative Lebenszyklen. Erlauben Feedback zu teilweise abgeschlossenen oder unfertigen Arbeiten, um diese Arbeiten zu verbessern und zu ändern.

uu Inkrementelle Lebenszyklen. Erzeugen fertige Liefergegenstände, die der Kunde ggf. sofort einsetzen kann.

uu Agile Lebenszyklen. Nutzen die Aspekte von iterativen wie von inkrementellen Merkmalen. In agilen Ansätzen arbeiten Teams in Iterationen am Produkt, um fertige Liefergegenstände zu erzeugen. Das Team erhält früh Feedback und gibt dem Kunden Einblick und Sicherheit sowie Kontrolle über das Produkt. Infolge der frühen Lieferung durch das Team wird die Investitionsrendite auf das Projekt eventuell früher realisiert, weil das Team die Arbeit mit dem höchsten Wert zuerst liefert.

Lief

erfr

eque

nz

Nied

rigHo

ch

Grad der Änderung

Plangetrieben

Inkrementell

Iterativ

Agil

Niedrig Hoch

Kontinuum

20 Abschnitt 3

3.1.1 MERKMALE VON PROGNOSTIZIERTEN LEBENSZYKLEN

In prognostizierten Lebenszyklen werden die hohe Sicherheit fester Anforderungen, eines stabilen Teams und eines geringen Risikos genutzt. Infolgedessen werden die Projektvorgänge oft seriell ausgeführt, wie in Abb. 3-2 gezeigt.

Zur Verwirklichung dieses Ansatzes braucht das Team ausführliche Pläne, damit es weiß, was es wie zu liefern hat. Diese Projekte sind erfolgreich, wenn potenzielle Änderungen beschränkt werden (z. B. Änderung der Anforderungen; Mitglieder des Projektteams ändern, was das Team liefert). Teamleiter versuchen, die Änderungen in einem prognostizierten Projekt zu minimieren.

Die Einschränkungen können angesprochen werden, wenn das Team zu Anfang des Projekts ausführliche Anforderungen und Pläne aufstellt. Das Team kann dann anhand dieser Einschränkungen Risiken und Kosten steuern. Auf dem Weg durch den ausführlichen Plan überwacht und steuert das Team Änderungen, die Inhalt und Umfang, Terminplan oder Budget beeinflussen könnten.

Weil prognostizierte Projekte ihren Fokus auf eine auf Abteilungsebene effiziente, serielle Arbeitsabfolge (sog. Silodenken) richten, liefern sie ihren geschäftlichen Wert in der Regel erst am Ende des Projekts. Wenn im prognostizierten Projekt Änderungen oder Unstimmigkeiten mit den Anforderungen auftreten oder wenn die technische Lösung nicht mehr so einfach ist, entstehen dem prognostizierten Projekt unvorhergesehene Kosten.

OHNE PLANUNG GEHT ES NICHT

Im Zusammenhang mit Lebenszyklen muss man sich vergegenwärtigen, dass sie alle das Element der Planung enthalten. Was die Lebenszyklen unterscheidet ist nicht die Frage, ob eine Planung erfolgt, sondern wie viel und wann.

Am prognostizierten (plange-triebenen) Ende des Kontinuums bestimmt der Plan die Arbeit. Im Vorfeld wird so viel Planung erledigt wie möglich. Anforderungen werden so ausführlich wie möglich identi-fiziert. Das Team schätzt, wann es welche Liefergegenstände bereit-stellen kann, und führt umfassende Beschaffungsvorgänge aus.

Bei iterativen Ansätzen werden Prototypen und Machbarkeitsstudien ebenfalls geplant, aber deren Ergebnisse werden zur Änderung der anfangs erstellten Pläne benutzt. Frühere Prüfungen unfertiger Arbeiten beeinflussen die künftige Projektarbeit.

Dagegen wird in inkrementellen Vorgehensweisen die Lieferung von aufeinanderfolgenden Untermengen des Gesamtprojekts geplant. Teams können mehrere aufeinanderfolgende Lieferungen im Voraus oder nur jeweils eine Lieferung planen. Die Lieferungen fließen in die künftige Projektarbeit ein.

Agile Projekte planen ebenfalls. Der entscheidende Unterschied besteht darin, dass das Team plant und die Planung anpasst, sobald zusätzliche Informationen aus der Prüfung der häufigen Lieferungen verfügbar werden. Unabhängig vom Projektlebenszyklus braucht jedes Projekt Planung.

21

Abb. 3-2. Prognostizierter Lebenszyklus

3.1.2 MERKMALE VON ITERATIVEN LEBENSZYKLEN

Iterative Lebenszyklen verbessern das Produkt oder Ergebnis durch aufeinanderfolgende Prototypen oder Machbarkeitsnachweise. Jeder neue Prototyp führt zu neuem Feedback vonseiten der Stakeholder und zu Einblicken für das Team. Dann baut das Team die neuen Informationen ein, indem es einen oder mehrere Projektvorgänge im nächsten Zyklus wiederholt. Teams können innerhalb einer Iteration Timeboxen, welche sich über mehrere Wochen erstrecken können, einsetzen, um Erkenntnisse zu gewinnen und dann den Vorgang auf der Grundlage dieser Erkenntnisse nachzuarbeiten. Auf diese Weise tragen Iterationen dazu bei, die Unsicherheit im Projekt zu erkennen und zu senken.

Projekte profitieren von iterativen Lebenszyklen bei hoher Komplexität, bei häufigen Änderungen im Projekt oder wenn Stakeholder unterschiedliche Ansichten über das erwünschte Endprodukt haben, die sich auf Inhalt und Umfang auswirken. Iterative Lebenszyklen brauchen eventuell länger, weil sie auf das Lernen und nicht auf das Auslieferungstempo optimiert werden.

Abb. 3-3 illustriert einige Elemente eines iterativen Projektlebenszyklus für eine einzelne Produktlieferung.

Abb. 3-3. Iterativer Lebenszyklus.

Analysieren Designen Erstellen Testen Ausliefern

AnalysierenAnalysieren

Designen

Prototyp erstellen Verfeinern

Erstellen

TestenAusliefern

22 Abschnitt 3

3.1.3 MERKMALE VON INKREMENTELLEN LEBENSZYKLEN

Einige Projekte werden auf die Schnelligkeit der Auslieferung hin optimiert. Viele Firmen und Initiativen können nicht warten, bis alles fertig ist; in diesen Fällen sind die Kunden bereit, eine Teilmenge der Gesamtlösung abzunehmen. Diese häufige Auslieferung kleinerer Liefergegenstände nennt man inkrementellen Lebenszyklus (siehe Abb. 3-4).

Abb. 3-4. Ein Lebenszyklus mit unterschiedlich großen Inkrementen

Analysieren

Designen

Erstellen

Testen

Ausliefern

Analysieren

Designen

Erstellen

Testen

Ausliefern

Analysieren

Designen

Erstellen

Testen

Ausliefern

Waren Sie schon einmal an einem Projekt beteiligt, dessen Anforderungen sich scheinbar täglich änderten, und haben gedacht: „Wir werden wissen, wie die Anforderungen aussehen, sobald wir einen Prototyp liefern, der abgenommen wird“? Falls ja, dann war das ein Projekt, bei dem agile Ansätze hilfreich gewesen wären. Ein Prototyp fördert Feedback und ein besseres Verständnis der Anforderungen, die in die einzelnen Liefergegenstände eingearbeitet werden können.

TIP

P

Sie sind sich nicht sicher, wie ein neuer Geschäftsservice in der Praxis funktionieren könnte? Erstellen Sie einen Machbarkeitsnachweis mit Evaluierungskriterien zur Untersuchung der erwünschten Ergebnisse. Setzen Sie iterative Ansätze ein, wenn Sie vermuten, dass die Anforderungen sich je nach Kundenfeedback ändern werden.

23

Inkrementelle Lebenszyklen optimieren die Arbeit, um Wert an die Sponsoren oder Kunden öfter als in einem einzelnen Endprodukt zu liefern. Teams planen erste Liefergegenstände, bevor sie mit ihrer Arbeit beginnen, und nehmen die Arbeit an diesem ersten Liefergegenstand so bald wie möglich auf. Manche agilen Projekte liefern Wert innerhalb weniger Tage ab Aufnahme des Projekts. Andere brauchen eventuell länger, zwischen einer und mehreren Wochen.

Mit Fortschreiten des Projekts kann das Team vom ursprünglichen Ziel abweichen. Das Team kann die Abweichungen steuern, weil es Werte früher liefert. Der Grad an Änderung und Abweichung ist weniger wichtig als dafür zu sorgen, dass Kunden bereits vor Projektende einen Wert erhalten.

Die Lieferung eines einzelnen Features oder eines fertigen Arbeitspakets an den Kunden ist ein Beispiel für den inkrementellen Ansatz.

Bauunternehmer wollen beispielsweise vielleicht erst ein fertiges Zimmer oder Stockwerk eines Gebäudes zeigen, bevor sie mit dem Rest des Gebäudes weitermachen. In diesem Fall können sie ein Stockwerk unter Umständen mit Armaturen, Farbe und allem Übrigen ausstatten, was für das fertige Stockwerk vorgesehen ist, bevor sie die nächste Etage in Angriff nehmen. Der Kunde kann die Ausführung, Farbe und weitere Einzelheiten sehen und abnehmen; auf diese Weise sind Anpassungen möglich, bevor weitere Investitionen in Form von Zeit und Geld erfolgen. Dieser Ansatz senkt das Potenzial für Nacharbeit bzw. Unzufriedenheit des Kunden.

Vollständigkeit und Auslieferung sind subjektiv. Das Team braucht vielleicht Feedback zu einem Prototypen und kann dann beschließen, ein Minimum Viable Product (MVP) an eine Teilmenge von Kunden auszuliefern. Das Feedback der Kunden hilft dem Team herauszufinden, was es für die folgende Lieferung der endgültigen und fertigen Features braucht.

Der wesentliche Unterschied besteht darin, dass agile Teams geschäftlichen Wert häufiger liefern. Wenn dem Produkt schrittsweise Features und Benutzergruppen hinzugefügt werden, wird von inkrementeller Lieferung gesprochen.

24 Abschnitt 3

3.1.4 MERKMALE VON AGILEN LEBENSZYKLEN

In einer agilen Umgebung geht das Team davon aus, dass sich die Anforderungen ändern. Der iterative bzw. inkrementelle Ansatz liefert Feedback, damit der jeweils nächste Projektabschnitt besser geplant werden kann. In agilen Projekten dagegen deckt die inkrementelle Auslieferung verborgene oder missverstandene Anforderungen auf. Abb. 3-5 veranschaulicht zwei mögliche Wege zur inkrementellen Auslieferung, damit das Projekt den Bedürfnissen des Kunden entspricht und bei Bedarf angepasst werden kann.

Abb. 3-5. Iterationsbasierte und flussbasierte agile Lebenszyklen

Anforderungen

Analyse

Design

Erstellen

Testen

Anforderungen

Analyse

Design

Erstellen

Testen

BEMERKUNG: Alle Timeboxen sind gleich groß. Jede Timebox führt zu funktionierenden, getesteten Features.

Anforderungen

Analyse

Design

Erstellen

Testen

Anforderungen

Analyse

Design

Erstellen

Testen

Nach Bedarf wiederholen

...

Anforderungen

Analyse

Design

Erstellen

Testen

Anforderungen

Analyse

Design

Erstellen

Testen

Iterationsbasierte Agilität

Anforderungen

Analyse

Design

Erstellen

Testen

Anzahl der Features innerhalb der WIP-Grenze

Anforderungen

Analyse

Design

Erstellen

Testen

Anzahl der Features

innerhalb der WIP-Grenze

Anforderungen

Analyse

Design

Erstellen

Testen

Anzahl der Features innerhalb der WIP-Grenze

Nach Bedarf wiederholen

...

Anforderungen

Analyse

Design

Erstellen

Testen

Anzahl der Features

innerhalb der WIP-Grenze

Anforderungen

Analyse

Design

Erstellen

Testen

Anzahl der Features innerhalb der WIP-Grenze

BEMERKUNG: Im Fluss ist die Zeit, die zur Fertigstellung eines Feature benötigt wird, nicht für jedes Feature gleich.

Flussbasierte Agilität

25

Bei einem iterationsbasierten agilen Ansatz arbeitet das Team mit Iterationen (Timeboxen von gleicher Dauer), um fertige Features zu liefern. Das Team arbeitet gemeinsam an der wichtigsten Funktionalität, um diese als Team fertigzustellen. Danach arbeitet das Team an der zweitwichtigsten Funktionalität und stellt sie fertig. Das Team kann unter Umständen an einigen Features gleichzeitig arbeiten, aber das Team behandelt nicht die gesamte Arbeit für die Iteration auf einmal (d. h. es wird nicht an allen Anforderungen und dann an allen Analysen usw. gearbeitet).

Bei einem flussbasierten agilen Ansatz holt das Team je nach der vorhandenen Arbeitskapazität Features aus dem Backlog, statt nach einem iterationsbasierten Terminplan zu arbeiten. Das Team definiert seinen Arbeitsfluss mit Spalten auf einem Task -Board und verwaltet die laufende Arbeit in jeder Spalte. Die Fertigstellung der einzelnen Features kann unterschiedlich lange dauern. Teams halten den Umfang laufender Arbeiten klein, damit Probleme besser früh erkannt und Nacharbeit verringert werden können, falls Änderungen notwendig werden. Ohne Iterationen zur Definition von Planung und Prüfpunkten legen das Team und die geschäftlichen Stakeholder den geeignetsten Terminplan für die Planung, Produktprüfungen und Retrospektiven fest.

Lebenszyklen gelten als agil, wenn sie die Prinzipien des Agilen Manifests erfüllen. Insbesondere steigt die Zufriedenheit der Kunden mit früher und kontinuierlicher Lieferung wertvoller Produkte. Darüber hinaus gilt ein inkrementeller Liefergegenstand, der funktioniert und wertstiftend ist, als wichtigster Messwert für Fortschritt. Agile Lebenszyklen kombinieren iterative und inkrementelle Ansätze, um sich an einen hohen Grad von Änderungen anzupassen und Projektwert öfter zu liefern.

3.1.5 AGILE EIGNUNGSKRITERIEN

Es gibt verschiedene Bewertungsmodelle, die bei der Feststellung helfen, ob und wie gut agile Ansätze passen. Diese Modelle bewerten Faktoren von Projekt und Organisation in Bezug auf Einsatz und Eignung. Sie liefern Einstufungen zur Ausrichtung der Organisation und zu möglichen Risikobereichen. Anhang X3 enthält eine Zusammenfassung verbreiteter Bewertungsmodelle, die als agile Eignungskriterien dienen können.

26 Abschnitt 3

3.1.6 MERKMALE VON HYBRIDEN LEBENSZYKLEN

Es ist nicht notwendig, ein ganzes Projekt nach einem einzigen Ansatz durchzuführen. Projekte kombinieren oft Elemente unterschiedlicher Lebenszyklen, um bestimmte Ziele zu erreichen. Eine Kombination aus plangetriebenem, iterativem, inkrementellem oder agilem Ansatz wird „hybrider Ansatz“ genannt.

Abb. 3-6 zeigt die grundlegenden, reinen Ansätze für Projektarten, die zu einer Mischform kombiniert werden. Die frühen Prozesse arbeiten mit einem agilen Entwicklungslebenszyklus, dem dann eine plangetriebenen Rollout-Phase folgt. Dieser Ansatz empfiehlt sich, wenn in der Entwicklungsphase des Projekts Unsicherheit, Komplexität und Risiko bestehen, die von einem agilen Ansatz profitieren würden, und darauf eine fest definierte, wiederholbare Rollout-Phase folgt, die auf plangetriebene Weise durchgeführt werden kann, vielleicht sogar von einem anderen Team. Ein Beispiel für diesen Ansatz ist die Entwicklung eines neuen Hightechprodukts, dem die Einführung sowie Schulungen für Tausende von Anwendern folgen.

BEISPIEL FÜR EIN PROJEKT MIT HYBRIDEM LEBENSZYKLUS

Ein Pharmaunternehmen, das am Ende seines Entwicklungsprozesses und dessen gesamten Lebenszyklus stand, bekam ein zeitraubendes Zulassungsverfahren bei der amerikanischen Arzneimittelbehörde (FDA) auferlegt. Der Lebenszyklus sah aus wie Abb. 3-6. Während Projektteams die Arzneimittelversuche auf agile Weise durchführten, mussten sie die Arzneimittel einer externen Gruppe vorlegen, um das Zulassungsverfahren der FDA zu durchlaufen. Ein Berater half mit der Integration des Zulassungsverfahrens der FDA in den agilen Entwicklungsprozess, um einen gestrafften hybriden Ansatz entstehen zu lassen.

Kurz gesagt: Der Prozess musste am Schluss als gesonderte Phase stattfinden, weil die Zulassung durch die FDA am Ende des Entwicklungsprozesses erfolgen bzw. nach jeder (noch so kleinen) Änderung wiederholt werden muss. Die Integration mit dem iterativen Verfahren brachte keinen Erfolg. Aber der Berater erstellte einige nützliche Kurzanleitungen und Prüfprotokolle, die das endgültige Zulassungsverfahren der FDA verkürzten.

27

Abb. 3-6. Agile Entwicklung, gefolgt von plangetriebenem Rollout

3.1.7 KOMBINATION AUS AGILEM UND PLANGETRIEBENEM ANSATZ

Eine weitere Vorgehensweise ist die Kombination aus agilem und plangetriebenem Ansatz während des Lebenszyklus.

Abb. 3-7. Gleichzeitige Verwendung von agilem und plangetriebenem Ansatz in Kombination

In Abb. 3-7 wird eine Kombination aus plangetriebenem und agilem Ansatz in ein und demselben Projekt gezeigt. Vielleicht stellt das Team inkrementell auf Agilität um und verwendet einige Ansätze wie kurze Iterationen, tägliche Standups und Retrospektiven, aber andere Aspekte des Projekts, wie die Vorabschätzung, Arbeitszuweisung und Fortschrittsnachverfolgung, folgen noch plangetriebenen Ansätzen.

Plangetriebene und agile Ansätze werden häufig gemeinsam verwendet. Allerdings wäre es irreführend, diesen Ansatz agil zu nennen, weil er agile Denkweisen, Werte und Prinzipien eindeutigerweise nicht vollständig verkörpert. Die Bezeichnung plangetrieben wäre allerdings auch falsch, weil es sich um eine Mischform handelt.

Agil

Plangetrieben

Agil

Plangetrieben

Agil

Plangetrieben

Agil Agil Agil Plangetrieben Plangetrieben Plangetrieben

28 Abschnitt 3

3.1.8 ÜBERWIEGEND PLANGETRIEBENER ANSATZ MIT EINIGEN AGILEN KOMPONENTEN

Abb. 3-8 zeigt ein kleines agiles Element in einem überwiegend plangetriebenen Projekt. In diesem Fall wird ein Teil des Projekts mit Unsicherheit, Komplexität oder möglichem Inhalts- und Umfangszuwachs auf agile Weise angegangen, während der übrige Teil des Projekts nach plangetriebenen Ansätzen gehandhabt wird. Ein Beispiel für diesen Ansatz wäre ein Ingenieursbüro, das eine Anlage mit einer neuen Komponente baut.

Abb. 3-8. Ein überwiegend plangetriebener Ansatz mit agilen Komponenten

Das Projekt besteht zum überwiegenden Teil aus Routinearbeit und ist vorhersehbar, wie viele andere Anlagenprojekte, welche die Organisation bereits durchgeführt hat, allerdings wird hier neues Bedachungsmaterial eingesetzt. Der Auftragnehmer plant eventuell einige kleinere Einbauversuche am Boden, um die beste Einbaumethode festzulegen und Probleme früh aufzudecken, wenn es noch ausreichend Zeit zu deren Behebung gibt; er wird die Prozesse dann inkrementell durch Versuche und Anpassungen verbessern.

3.1.9 EIN ÜBERWIEGEND AGILER ANSATZ MIT EINER PLANGETRIEBENEN KOMPONENTE

Abb. 3-9 zeigt einen überwiegend agilen Ansatz mit einer plangetriebenen Komponente. Dieser Ansatz ist dann geeignet, wenn ein bestimmtes Element nicht verhandelbar oder mit einem agilen Ansatz nicht ausführbar ist. Beispiele hierfür sind die Integration einer externen Komponente, die von einem anderen Anbieter entwickelt wurde, der aber nicht teamorientiert oder inkrementell als Partner mitwirken kann oder wird. Nach Lieferung der Komponente ist eine einzige Integration notwendig.

Abb. 3-9. Ein überwiegend agiler Ansatz mit einer plangetriebenen Komponente

Plangetrieben Plangetrieben Plangetriebenieben Plangetrriebenieben PlangetrPlangetrAgil Agil Agil

Agil Agil AgilAgilAgilAgilPlangetrieben Plangetrieben Plangetrieben

29

3.1.10 HYBRIDE LEBENSZYKLEN UND IHRE ZWECKDIENLICHKEIT

Projektteams können einen hybriden Lebenszyklus auf der Grundlage von Projektrisiken gestalten. Bei einem Bauprojekt auf einem Universitätsgelände müssen zum Beispiel mehrere Gebäude renoviert oder neu gebaut werden. Ein inkrementeller Ansatz würde Ressourcen darauf bündeln, dass einige Gebäude früher fertiggestellt werden als andere, und damit die Investitionsrendite früher bereitstellen. Jeder einzelne Liefergegenstand ist ggf. ausreichend bekannt, sodass das betreffende Gebäude von einem allein plangetriebenen Lebenszyklus profitieren kann.

Das Ziel von Projektmanagement ist es, in einem bestimmten Umfeld auf bestmögliche Weise geschäftlichen Wert zu erzeugen. Es macht dafür keinen Unterschied, ob dies auf agile oder plangetriebene Weise geschieht. Die folgende Frage ist zu stellen: „Wie können wir den größten Erfolg erzielen?“

Ist Feedback notwendig, wenn das Team Wert erzeugt? Falls ja, hilft ein schrittweises Vorgehen. Ist Risikosteuerung notwendig, wenn Ideen ausgelotet werden? Falls ja, sind ein iterativer oder agiler Ansatz hilfreich.

Wenn die Organisation keinen inkrementellen Wert liefern kann, sind agile Ansätze eventuell nicht sinnvoll. Das ist in Ordnung – agil sein um der Agilität willen ist nicht das Ziel. Ziel ist es, einen Lebenszyklus oder eine Kombination von Lebenszyklen auszuwählen, die für das Projekt, die Risiken und die Kultur geeignet sind.

Bei Agilität geht es um häufige, kundenorientierte Lieferungen. Diese Lieferungen erzeugen Feedback für das Team. Das Team nutzt das Feedback zur Planung und Plananpassung des nächsten Arbeitsabschnitts.

Eine staatliche Behörde hat-te ein Projekt zur Entwicklung von Kreditversicherungsanträgen. Das mehrjährige Projekt sollte das alte Versicherungssystem mit einer neu-en, reaktionsfreudigeren Benutzer-oberfläche und Systemintegrationen ersetzen. Der Großteil des Projekts wurde mit einem agilen Ansatz mit kontinuierlichen fachlichen Vorgaben durchgeführt.

Die Berechnungen der Versicherungsprämien wurden von der Organisation für wirtschaftliche Zusammenarbeit und Entwicklung (OECD) als 200-seitige Spezifikation vorgegeben. Die Schritte wurden sehr klar und relativ unmissverständlich erläutert (oder Zwischenergebnisse von der Fachseite bestätigt) und von einem gesonderten Team, das sich durch die Berechnungsschritte arbeitete, entwickelt. Die beiden Teams arbeiteten gemeinsam an den Variablen der Eingangswerte, die für die Berechnung notwendig waren, und an der Frage, wie die Ausgabewerte verwendet und angezeigt werden sollen; im Übrigen arbeitete das Berechnungsteam aber überwiegend plangetrieben.

Als die Aufgabe des Berech-nungsteams erledigt war, wurden die Ausgabewerte aus den Berech-nungen der Versicherungsprämien auf den Bildschirmen und in den Berichten angezeigt. Dann gaben die fachlichen Anwender Feedback zu Erscheinungsbild und Gebrauch der Informationen. Die beiden Teams arbeiteten gleichzeitig, aber es gab wenig Notwendigkeit zur Zusammenarbeit. Die räumliche Nähe der beiden Teams vereinfachte die Abfrage der Fortschritte bei der Entwicklung, aber im Großen und Ganzen handelte es sich um zwei getrennte Teilprojekte.

30 Abschnitt 3

3.1.11 HYBRIDE LEBENSZYKLEN ALS ÜBERGANGSSTRATEGIE

Viele Teams können nicht über Nacht auf eine agile Arbeitsweise umstellen. Für Menschen, die an eine plangetriebene Umgebung gewöhnt und dort erfolgreich sind, sehen agile Methoden ganz anders aus und wirken ganz anders. Je größer die Organisation ist und je mehr Teile sie besitzt, um so länger wird die Umstellung dauern. Deshalb ist die Planung einer schrittweisen Umstellung sinnvoll.

Eine schrittweise Umstellung bedeutet, zuerst iterative Methoden hinzuzufügen, welche das Lernen und die Ausrichtung zwischen Teams und Stakeholdern verbessern. Später kann man das Hinzufügen weiterer inkrementeller Methoden in Erwägung ziehen, um die Wertschöpfung und Bereitstellung der Investitionsrendite für Sponsoren zu beschleunigen. Diese Kombination unterschiedlicher Ansätze gilt als hybrider Ansatz.

Probieren Sie diese neuen Methoden an einem weniger riskanten Projekt mit einem mittleren bis niedrigen Grad an Unsicherheit aus. Wenn die Organisation dann mit einem hybriden Ansatz Erfolg hat, können Sie sich an komplexere Projekte heranwagen, die mehr von diesen Methoden brauchen. Auf diese Weise lässt sich die fortschreitende hybride Umstellung an die Situation der Organisation und die spezifischen Risiken anpassen sowie an die Bereitschaft des Teams, die Änderungen anzunehmen und aufzugreifen.

31

3.2 AGILE ANSÄTZE MISCHEN

Agile Teams beschränken ihre Praktiken selten auf einen agilen Ansatz. Jeder Projektzusammenhang weist seine eigenen Besonderheiten auf, wie etwa die unterschiedliche Mischung von Fähigkeiten und Erfahrungen der Teammitglieder, die einzelnen Komponenten des in der Entwicklung befindlichen Produkts sowie Alter, Größenordnung, Kritikalität, Komplexität und regulatorische Einschränkungen der Umgebung, in der die Arbeit stattfindet.

Agile Rahmenwerke werden nicht für das Team maßgeschneidert. Das Team muss vielmehr die Praktiken anpassen, um regelmäßig Wert liefern zu können. Teams praktizieren oft ihre eigene Sondermischung von Agilität, selbst wenn sie ein bestimmtes Rahmenwerk als Ausgangspunkt benutzen.

MISCHUNG VON ANSÄTZEN

Ein Beispiel für die Anpassung agiler Rahmenwerke: Eine der häufigsten Mischungen, die weit verbreitet ist, umfasst den koordinierten Einsatz des Scrum-Rahmenwerks, der Kanban-Methode sowie Elemente aus der Methode des eXtreme Programming (XP). Von Scrum werden Produkt-Backlog, Produktverantwortlicher, Scrum Master und ein funktionsübergreifendes Entwicklungsteam mit Sprint-Planung, Daily Scrum, Sprint-Review und Sprint-Retrospektiven verwendet. Ein Kanban-Board verhilft dem Team zu mehr Effektivität, indem es den Arbeitsfluss abbildet, Hindernisse leicht sichtbar macht und die Steuerung des Flusses durch Begrenzung der parallelen Arbeit ermöglicht. Darüber hinaus steigern die an XP angelehnten Entwicklungspraktiken, wie der Einsatz von Story-Karten, fortlaufende Integration, Refaktorierung, automatische Tests und testgetriebene Entwicklung, die Wirksamkeit des agilen Teams noch weiter. Zusammenfassend führt die Mischung von Praktiken aus diesen unterschiedlichen Quellen zu einem kombinierten Ergebnis mit höherer Leistung als die der jeweiligen Komponenten allein.

32 Abschnitt 3

3.3 PROJEKTFAKTOREN MIT EINFLUSS AUF DIE ANPASSUNG

Manchmal muss ein Ansatz genauer an die Projektattribute angepasst werden. Tabelle 3-2 listet einige Projektfaktoren und Anpassungsoptionen auf, die man in Erwägung ziehen kann.

Tabelle 3-2. Anpassungsoptionen für eine bessere Passform

Weitere Informationen zu Faktoren, die die Anpassung beeinflussen, finden sich in Anhang X2, Attribute mit Einfluss auf Anpassung.

Projektfaktor Anpassungsoptionen

Nachfragemuster: stetig oder sporadisch

Erforderliche Prozessverbesserungsquote je nach Teamerfahrung

Der Arbeitsfluss wird häufig durch verschiedene Verzögerungen oder Hindernisse unterbrochen

Die Qualität der Produktinkremente ist niedrig

Es wird mehr als ein Team zur Erstellung eines Produkts benötigt

Die Mitglieder des Projektteams haben keine Erfahrung mit agilen Ansätzen

Viele Teams finden, dass ein bestimmter Rhythmus (in Form einer regelmäßigen Timebox) hilfreich ist für das Review, Retrospektive und die Annahme neuer Arbeit. Darüber hinaus brauchen manche Teams mehr Flexibil-ität bei der Annahme von zusätzlicher Arbeit. Teams können nach flussbasierter Agilitätnach einem Rhythmus arbeiten und dadurch von beiden Modellen profitieren.

Häufigere Retrospektiven und Auswahl von Verbesserungen.

Die Arbeit kann in Kanban-Boards abgebildet werden. Es kann weiterhin mit Grenzen für die einzelnen Bereiche des Arbeitsprozesses experimentiert werden, um den Fluss zu optimieren.

Es empfiehlt sich der Einsatz verschiedener testgetrie-bener Entwicklungspraktiken. Diese Disziplin zur Vermeidung von Fehlern macht es schwer für Fehler, unentdeckt zu bleiben.

Um mit minimaler Unterbrechung von einem auf mehrere agile Teams zu skalieren, sollten zuerst Informationen über agiles Programmmanagement oder formelle Rahmenwerke zur Skalierung eingeholt werden. Dann kann ein Ansatz gestaltet werden, der zum Projektzusam-menhang passt.

Es empfiehlt sich, Teammitglieder in den Grundlagen der agilen Denkweise und ihren Prinzipien zu schulen. Wenn das Team sich für einen bestimmten Ansatz wie Scrum oder Kanban entscheidet, sollte ein Workshop dazu angeboten werden, damit die Teammitglieder den Gebrauch erlernen können.

33

4AGILITÄT IMPLEMENTIEREN: E INE AGILE UMGEBUNG SCHAFFEN

4.1 ES BEGINNT MIT EINER AGILEN DENKWEISE

Projektmanagement nach einem agilen Ansatz verlangt, dass das Projektteam eine agile Denkweise annimmt. Die Antworten auf die folgenden Fragen werden bei der Ausarbeitung einer Implementierungsstrategie helfen:

uu Wie kann das Projektteam agil handeln?

uu Was kann das Team zügig liefern und frühes Feedback dafür bekommen, das dem nächsten Lieferzyklus zugute kommt?

uu Wie kann das Projektteam transparent handeln?

uu Welche Arbeit kann zugunsten von Aufgaben mit höherer Priorität vermieden werden?

uu Wie kann der Ansatz der dienenden Führung dazu beitragen, dass das Team seine Ziele erreicht?

4.2 DIENENDE FÜHRUNG STÄRKT DAS TEAM

Bei agilen Ansätze wird großer Wert auf dienende Führung als Methode zur Stärkung der Teams gelegt. Dienende Führung ist die Praxis, durch Dienst am Team zu führen; der Fokus liegt darauf, die Bedürfnisse und Weiterentwicklung der Teammitglieder zu verstehen und zu bedienen, um die höchstmögliche Teamleistung zu ermöglichen.

Die Rolle einer dienenden Führungsperson besteht darin, die Entdeckung und Definition von Agilität durch das Team herbeizuführen. Dienende Führungspersonen praktizieren Agilität und strahlen dies aus. Dienende Führungspersonen gehen in dieser Reihenfolge an Projektarbeit heran:

uu Zweck. Es wird mit dem Team an der Definition des „Warum“ oder Zwecks gearbeitet, damit das Team sich für das Projektziel engagieren und daran orientieren kann. Das gesamte Team optimiert auf Projektebene, nicht auf der Ebene einzelner Personen.

uu Menschen. Sobald der Zweck festgelegt ist, wird das Team dazu aufgefordert, eine Umgebung zu schaffen, in der alle erfolgreich sein können. Jedes Teammitglied wird gebeten, projektübergreifende Beiträge zu leisten.

uu Prozess. Es sollte nicht der „perfekte“ agile Prozess verfolgt, sondern vielmehr auf die Ergebnisse geachtet werden. Wenn ein funktionsübergreifendes Team oft fertige Werte liefert und über das Produkt und den Prozess nachdenkt, dann ist dieses Team agil. Es ist nicht so wichtig, wie das Team seinen Prozess nennt.

34 Abschnitt 4

Die folgenden Merkmale der dienenden Führung ermöglichen Projektleitern, agiler zu werden und den Erfolg des Teams herbeizuführen:

uu Förderung von Eigenwahrnehmung

uu Zuhören

uu Den Teammitgliedern dienen

uu Mitarbeitern helfen, sich weiterzuentwickeln

uu Coaching statt Kontrolle

uu Förderung von Sicherheit, Respekt und Vertrauen sowie

uu Förderung der Energie und Intelligenz von anderen.

Dienende Führung ist nicht auf Agilität beschränkt. Aber einmal praktiziert, sehen dienende Führungspersonen in der Regel, wie gut sich die dienende Führung in die agile Denkweise und agilen Werte integriert.

Wenn Führungspersonen ihre dienende Führung oder teamfördernden Fähigkeiten ausarbeiten, steigt die Wahrscheinlichkeit, dass sie agil werden. Infolgedessen können dienende Führungspersonen ihren Teams bei der Zusammenarbeit zur schnelleren Wertlieferung verhelfen.

Erfolgreiche agile Teams machen sich eine wachstumsorientierte Denkweise zu eigen, in der Leute daran glauben, dass sie neue Fähigkeiten erlernen können. Wenn das Team und die dienenden Führungspersonen daran glauben, dass sie alle lernen können, wachsen die Fähigkeiten eines jeden Einzelnen.

4.2.1 AUFGABEN DER DIENENDEN FÜHRUNGSPERSON

Dienende Führungspersonen steuern Beziehungen, um die Kommunikation und Koordination innerhalb des Teams und über die Organisation hinweg aufzubauen. Diese Beziehungen helfen den Führungspersonen bei der Navigation durch die Organisation, um so das Team zu unterstützen. Diese Art der Unterstützung trägt dazu bei, Hindernisse aus dem Weg zu räumen, und hilft dem Team bei der Verschlankung seiner Prozesse. Weil dienende Führungspersonen Agilität verstehen und einen spezifischen Ansatz zu Agilität praktizieren, können sie zur Erfüllung der Bedürfnisse im Team beitragen.

35

4.2.1.1 DIENENDE FÜHRUNGSPERSONEN VERMITTELN UND FÖRDERN

Wenn Projektmanager als dienende Führungspersonen auftreten, verlagert sich der Fokus von „Koordination steuern“ auf „Zusammenarbeit vermitteln und fördern“. Vermittler helfen allen, ihr bestes Denken und ihre beste Arbeit einzubringen. Vermittler fördern Beteiligung des Teams, Verständnis und gemeinsame Verantwortung für die Ergebnisse des Teams. Vermittler helfen dem Team, brauchbare Lösungen zu erarbeiten.

Dienende Führungspersonen fördern die Zusammenarbeit und das Gespräch innerhalb des Teams und zwischen Teams. Zum Beispiel hilft eine dienende Führungsperson dabei, Engpässe innerhalb eines Teams und zwischen mehreren Teams aufzudecken und mitzuteilen. Dann beheben die Teams diese Engpässe.

Darüber hinaus fördert ein Vermittler die Zusammenarbeit durch interaktive Meetings, informellen Dialog und Wissensaustausch. Dienende Führungspersonen erreichen dies, indem sie zu unparteiischen Brückenbauern und Coaches werden, statt Entscheidungen zu treffen, für die andere die Verantwortung tragen sollten.

4.2.1.2 DIENENDE FÜHRUNGSPERSONEN RÄUMEN ORGANISATORISCHE HINDERNISSE AUS DEM WEG

Der erste Wert des Agilen Manifests stellt Personen und ihre Beziehungen über Prozesse und Werkzeuge. Eine dienende Führungsperson kann kaum eine bessere Aufgabe übernehmen als Prozesse einer genauen Prüfung zu unterziehen, welche die Agilität eines Teams oder einer Organisation behindern, und an der Verschlankung dieser Prozesse zu arbeiten. Wenn zum Beispiel eine Abteilung umfangreiche Dokumentation erfordert, könnte die Aufgabe der dienenden Führungsperson folgendermaßen aussehen: Zuerst Zusammenarbeit mit der Abteilung, um die erforderliche Dokumentation zu prüfen. Danach Unterstützung bei der Ausarbeitung eines gemeinsamen Verständnisses, wie agile Liefergegenstände diese Anforderungen erfüllen. Schließlich eine Bewertung der Menge der benötigten Dokumentation, damit die Teams mehr Zeit mit der Lieferung wertvoller Produkte als mit der Erstellung umfangreicher Dokumentationen verbringen.

Dienende Führungspersonen sollten auch andere Prozesse unter die Lupe nehmen, die langwierig sind, Engpässe hervorrufen und die Agilität eines Teams oder einer Organisation behindern. Beispiele für Prozesse oder Abteilungen, die dafür infrage kommen, sind Finanzen, Änderungssteuerungsgremien oder Audits. Dienende Führungspersonen können in Partnerschaft und gemeinsam mit anderen arbeiten und sie zur Prüfung ihrer Prozesse herausfordern, um agile Teams und Führungspersonen zu unterstützen. Was nützt es beispielsweise einem Team, alle zwei Wochen ein Arbeitsprodukt zu liefern, wenn das Produkt dann in eine Warteschlange oder einen Prozess eingereiht wird und wegen langwieriger Freigabeprozesse sechs Wochen oder mehr bis zur Freigabe warten muss? Viel zu viele Organisationen haben solche Engpässe in ihren Prozessen, die Teams an der schnellen Lieferung wertvoller Produkte oder Dienstleistungen hindern. Eine dienende Führungsperson hat die Fähigkeit, diese organisatorischen Hürden zu ändern oder aus dem Weg zu räumen und damit die Lieferteams zu unterstützen.

36 Abschnitt 4

4.2.1.3 DIENENDE FÜHRUNGSPERSONEN MACHEN DEN WEG FREI FÜR DIE BEITRÄGE VON ANDEREN

In der Agilität steuert das Team seinen Arbeitsprozess und sein Arbeitsprodukt. Dieses Selbstmanagement und diese Selbstorganisation gelten für alle, die der Organisation und dem Projekt dienen und helfen. Dienende Führungspersonen arbeiten an der Erfüllung der Bedürfnisse von Teams, Projekten und der Organisation. Dienende Führungspersonen können zum Beispiel mit der Hausverwaltung zusammenarbeiten, um Platz für das Team zu bekommen, mit dem Management arbeiten, um dem Team die Ausrichtung auf jeweils nur ein Projekt zu ermöglichen, oder mit dem Produktverantwortlichen arbeiten, um mit dem Team Storys zu entwickeln. Manche dienenden Führungspersonen arbeiten mit Auditoren an der Feinabstimmung der Prozesse, die in einem regulatorischen Umfeld notwendig sind. Andere wieder arbeiten mit der Finanzabteilung an der Umstellung der Organisation auf inkrementelle Budgetierung.

Die dienende Führungsperson konzentriert sich darauf, den Weg für das Team frei zu machen, damit es seine bestmögliche Arbeit leisten kann. Eine dienende Führungsperson beeinflusst Projekte und fordert die Organisation zum Umdenken auf.

4.2.1.4 BETRACHTUNG DER AUFGABEN IN DIENENDER FÜHRUNG

Dienende Führungspersonen tragen die unterschiedlichsten Titel, wirklich wichtig ist aber das, was sie tun. Hier sind einige Beispiele für Aufgaben, die eine dienende Führungsperson ggf. hat:

SOZIALE IM VERGLEICH ZU TECHNISCHER KOMPETENZ

Neben der dienenden Führung legen Teammitglieder Wert auf ihre soziale Kompetenz und emotionale Intelligenz – nicht nur auf ihre technischen Fähigkeiten. Alle im Team arbeiten daran, mehr Initiative, Integrität, emotionale Intelligenz, Aufrichtigkeit, Kooperation, Bescheidenheit und Bereitschaft zu unterschiedlichen Wegen der Kommunikation zu zeigen, damit das gesamte Team gut zusammenarbeiten kann.

Das Team braucht diese Fähigkeiten, damit es gut auf Änderungen in der Projektausrichtung und auf technische Produktänderungen reagieren kann. Wenn alle sich an die Arbeitsweise und die Teamkollegen anpassen können, steigen die Erfolgschancen des Teams.

37

uu Stakeholder darüber aufklären, warum und wie Agilität gelebt werden sollte und kann. Die Vorteile für den geschäftlichen Wert erklären auf der Grundlage von Priorisierung, größerer Rechenschaftspflicht und Produktivität befähigter Teams sowie besserer Qualität durch häufigere Prüfungen usw.

uu Unterstützung des Teams durch Mentoring, Zuspruch und Unterstützung. Fürsprache für Schulung und Karriereentwicklung der Teammitglieder. Das Oxymoron „Wir führen Teams, indem wir hinter ihnen stehen“ beschreibt die Rolle der Führungsperson bei der Weiterentwicklung ihrer Teammitglieder. Mithilfe von Unterstützung, Zuspruch und beruflicher Weiterentwicklung gewinnen Teammitglieder Selbstvertrauen, übernehmen größere Rollen und leisten ihre Beiträge auf höherem Niveau innerhalb ihrer Organisationen. Eine besonders wichtige Rolle der dienenden Führungsperson besteht darin, Teammitglieder zu fördern und über ihre gegenwärtigen Rollen hinauswachsen zu lassen, selbst wenn das ihr Ausscheiden aus dem Team bedeutet.

uu Dem Team mit technischer Projektmanagementarbeit helfen, wie z. B. quantitativer Risikoanalyse. Manchmal besitzen Teammitglieder nicht das Wissen oder die Erfahrung in den jeweiligen Rollen oder Funktionen. Dienende Führungspersonen, die Methoden besser kennen oder darin geschult wurden, können das Team ihrerseits durch entsprechende Schulung oder Übernahme dieser Vorgänge unterstützen.

uu Erfolge des Teams sowie Unterstützung und Brückenbauen zu externen Gruppen feiern. Aufwärtsspiralen der Wertschätzung und Entgegenkommen schaffen, um die Zusammenarbeit zu stärken.

4.2.2 DIE ROLLE DES PROJEKTMANAGERS IN EINER AGILEN UMGEBUNG

Die Rolle des Projektmanagers bei einem agilen Projekt ist nicht ganz klar, weil viele agile Rahmenwerke und Ansätze die Rolle des Projektmanagers nicht berücksichtigen. Manche Agilisten sind der Auffassung, die Rolle eines Projektmanagers sei nicht notwendig, weil sich selbst organisierende Teams die ehemaligen Aufgaben des Projektmanagers übernehmen. Pragmatische Agilisten und Organisationen wissen jedoch, dass Projektmanager in vielen Situationen wertvolle Beiträge leisten können. Der wesentliche Unterschied besteht darin, dass ihre Rollen und Aufgaben etwas anders aussehen.

TIP

P Der Wert von Projektmanagern liegt nicht in ihrer Position, sondern in ihrer Fähigkeit, alle anderen besser zu machen.

38 Abschnitt 4

4.2.3 PROJEKTMANAGER ARBEITEN NACH DEM PRINZIP DER DIENENDEN FÜHRUNG

Der PMBOK® Guide – Sechste Auflage definiert den Projektmanager als „die von der Trägerorganisation zur Führung des Teams ernannte Person, die für die Erreichung der Zielvorgaben des Projekts verantwortlich ist“.

Viele Projektmanager sind daran gewöhnt, im Mittelpunkt der Projektkoordination zu stehen, den Status des Teams zu verfolgen und gegenüber dem Rest der Organisation zu vertreten. Dieser Ansatz war sinnvoll, als Projekte in vereinzelte Funktionen zerlegt wurden.

In Projekten mit einem hohen Änderungsaufkommen herrscht jedoch mehr Komplexität als eine einzelne Person steuern kann. Stattdessen koordinieren funktionsübergreifende Teams ihre eigene Arbeit und arbeiten mit dem geschäftlichen Vertreter (dem Produktverantwortlichen) zusammen.

Bei der Arbeit an einem agilen Projekt stehen Projektmanager nicht mehr im Mittelpunkt, sondern dienen Team und Management. In einer agilen Umgebung sind Projektmanager dienende Führungspersonen, die ihre Hauptarbeit auf das Coaching von Mitarbeitern verlegen, die Hilfe wünschen, und mehr Kooperation im Team fördern und die Bedürfnisse der Stakeholder in Einklang bringen. Als dienende Führungspersonen fördern Projektmanager die Verteilung von Verantwortung im Team. Dies heißt im Klartext: An die Mitarbeiter, die das Wissen besitzen, um die Arbeit zu erledigen.

4.3 ZUSAMMENSETZUNG DES TEAMS

Eine zentrale Säule in den Werten und Prinzipien des Agilen Manifests ist die Bedeutung von Einzelpersonen und Interaktionen. Agilität optimiert den Wertfluss und legt den Fokus auf die rasche Lieferung von Features an den Kunden statt darauf, wie Mitarbeiter eingesetzt werden.

TIP

P Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.

39

Wenn Teams sich Gedanken über die Optimierung des Wertflusses machen, werden die folgenden Vorteile offensichtlich:

uu Die Zusammenarbeit unter den einzelnen Kollegen wird wahrscheinlicher

uu Teams stellen wertvolle Arbeit schneller fertig

uu Teams verschwenden viel weniger Zeit, weil sie nicht mehrere Aufgaben gleichzeitig erledigen und den Zusammenhang wiederherstellen müssen.

4.3.1 AGILE TEAMS

Agile Teams konzentrieren sich auf schnelle Produktentwicklung, damit sie Feedback bekommen. In der Praxis zählen die wirkungsvollsten agilen Teams meist drei bis neun Mitglieder. Idealerweise sind alle Mitarbeiter in einem agilen Team an ein und demselben Teamarbeitsplatz. Teammitglieder widmen sich zu 100 % dem jeweiligen Team. Agilität fördert Teams, die sich selbst managen, wo die Teammitglieder entscheiden, wer die Arbeit im definierten Inhalt und Umfang der nächsten Periode ausführen wird. Agile Teams gedeihen unter dienender Führung. Die Führungspersonen unterstützen den Arbeitsansatz der Teams.

Funktionsübergreifende agile Teams produzieren in hoher Frequenz funktionierende Produkterweiterungen, weil die Teams für die Arbeit gemeinsam verantwortlich sind und zusammen alle notwendigen Fähigkeiten zur Lieferung fertiggestellter Arbeit haben.

Unabhängig vom allgemeinen agilen Ansatz gilt: Je stärker ein Team seine laufende Arbeit begrenzt, um so wahrscheinlicher können die Mitglieder des Teams kooperieren, um die Arbeit insgesamt schneller zu erledigen. Teammitglieder in erfolgreichen agilen Teams arbeiten auf unterschiedlichen Wegen zusammen (zum Beispiel paarweise, durch Swarming oder Mob-Programming), damit sie nicht in die Falle der Mini-Wasserfälle tappen, statt gemeinsam zu arbeiten. Mini-Wasserfälle entstehen dann, wenn das Team alle Anforderungen in einem bestimmten Zeitraum angeht, dann an allen Designs arbeitet und dann zu allen Entwicklungsschritten übergeht. In dieser Situation stellt das Team womöglich irgendwann während der Entwicklungsphase oder anschließenden Testphase fest, dass es nach überholten Annahmen arbeitet. In so einem Fall hätte das Team Zeit verschwendet, weil es alle Anforderungen gleichzeitig angangen hätte. Wenn stattdessen Teammitglieder gemeinsam eine kleine Anzahl an allgemeinen Features erstellen, lernen sie während des Arbeitsverlaufs und liefern kleinere fertige Features.

Agile Projekte profitieren von Projektteamstrukturen, welche die Zusammenarbeit innerhalb eines Teams und zwischen mehreren Teams verbessern. Tabelle 4-1 zeigt, wie Teammitglieder mit ihrer Zusammenarbeit die Produktivität steigern und innovative Problemlösungen herbeiführen.

40 Abschnitt 4

Tabelle 4-1. Attribute erfolgreicher agiler Teams

4.3.2 AGILE ROLLEN

Agilität besetzt gewöhnlich drei Rollen:

uu Funktionsübergreifende Teamkollegen

uu Produktverantwortlicher und

uu Vermittler im Team.

Tabelle 4-2 beschreibt diese Teamrollen.

Attribut Ziel

Dedizierte Mitarbeiter

Funktionsübergreifende Teammitglieder

Zusammenlegung an einem Arbeitsort oder Fähigkeit zur Bewältigung von Standort-schwierigkeiten

Gemischtes Team aus Generalisten und Spezialisten

Stabile Arbeitsumgebung

• Mehr Konzentration und Produktivität• Kleines Team, weniger als zehn Leute

• Häufig entwickeln und liefern• Fertigen Wert als unabhängiges Team liefern• Alle Arbeitsvorgänge integrieren, um fertige Arbeit zu liefern• Feedback von innerhalb des Teams und von anderen erhalten, z. B. vom Produktverantwortlichen

• Bessere Kommunikation• Bessere Teamdynamik• Wissensaustausch• Geringere Lernkosten• Selbstverpflichtung zur Zusammenarbeit

• Spezialisten bieten einschlägige Sachkenntnis und Generalisten Flexibilität• Das Team startet mit speziellen Kompetenzen und verbreitert sein Wissen über das Spezialgebiet hinaus auf mehrere Gebiete und entwickelt sogenannte generalisierte Spezialisten

• Für die Lieferung voneinander abhängig• Vereinbarter Arbeitsansatz• Vereinfachte Teamkostenberechnungen (Run Rate)• Erhalt und Expansion von geistigem Kapital

41

Tabelle 4-2. Rollen in agilen Teams

Rolle Beschreibung

Funktionsübergreifende Teamkollegen

Produktverantwortlicher

Vermittler im Team

Funktionsübergreifende Teams bestehen aus Teamkollegen, die alle notwendi-gen Fähigkeiten zur Herstellung eines funktionsfähigen Produkts besitzen. In der Softwareentwicklung bestehen funktionsübergreifende Teams in der Regel aus Designern, Entwicklern, Testern und allen anderen notwendigen Rollen. Die funktionsübergreifenden Entwicklungsteams bestehen aus Fachleuten, die in regelmäßigem Rhythmus ein potenziell herausgebbares Produkt liefern. Funktionsübergreifende Teams sind entscheidend, weil sie fertige Arbeit in der kürzestmöglichen Zeit mit höherer Qualität ohne externe Abhängigkeiten liefern können.

Der Produktverantwortliche (Product Owner) ist dafür zuständig, die Richtung des Produkts zu steuern. Produktverantwortliche stufen die Arbeit nach ihrem geschäftlichen Wert ein. Produktverantwortliche arbeiten täglich mit ihren Teams, indem sie ihnen Feedback zum Produkt geben und die Richtung für das nächste Stück Funktionalität festlegen, das entwickelt/geliefert werden muss. Das bedeutet, dass die Arbeit klein ist, oft so klein, dass sie auf einer Karteikarte beschrieben werden kann.

Der Produktverantwortliche arbeitet mit Stakeholdern, Kunden und den Teams gemeinsam daran, die Richtung für das Produkt festzulegen. In der Regel haben Produktverantwortliche einen betriebswirtschaftlichen Hintergrund und bringen fundierte Sachkenntnis in die Entscheidungen ein. Manchmal erbitten Produktverantwortliche Hilfe von Leuten mit fundierter Domänenkenntnis, wie Architekten, oder mit tiefgreifender Erfahrung im Kundenumfeld, wie Produkt-manager. Produktverantwortliche brauchen Schulungen dazu, wie man den Arbeitsfluss durch das Team organisiert und steuert.

Bei Agilität stellen die Produktverantwortlichen das Backlog für das und mit dem Team auf. Der Backlog hilft den Teams zu sehen, wie sie ohne Verschwend-ung den höchsten Wert liefern können.

Ein entscheidender Erfolgsfaktor für agile Teams ist starke Produktverantwortung. Wenn das agile Team nicht auf den höchsten Wert für den Kunden achtet, erstellt es unter Umständen Features, die nicht geschätzt werden oder anderweitig unzureichenden Wert bieten, und betreibt dadurch vergeblichen Aufwand.

Die dritte Rolle, die man in der Regel in agilen Teams findet, ist der Vermittler, eine dienende Führungsperson. Diese Rolle mag als Projektmanager, Scrum Master, Projektteamleiter, Team Coach oder Vermittler bezeichnet werden.

Alle agilen Teams brauchen dienende Führung in ihrem Team. Es braucht Zeit, bis die Kompetenzen der dienenden Führung wie Vermittlung, Coaching und Beseitigung von Hindernissen erlernt sind.

Anfangs laden viele Organisationen agile Coaches von außen ein, die ihnen helfen, solange die interne Coaching-Kompetenz noch nicht voll entwickelt ist.

Externe Coaches haben den Vorteil, dass sie Erfahrung besitzen, aber auch den Nachteil schwacher Beziehungen in der Kundenorganisation. Interne Coaches dagegen haben starke Beziehungen in ihrer Organisation, aber es fehlt ihnen eventuell an der Vielfalt an Erfahrungen, die sie besonders effektiv machen würde.

42 Abschnitt 4

4.3.3 GENERALISIERTE SPEZIALISTEN

Agile Teams sind funktionsübergreifend, aber oftmals starten die einzelnen Mitglieder nicht so. Viele erfolgreiche agile Teams setzen sich jedoch aus generalisierten Spezialisten oder sogenannten „T-Shaped“-Personen zusammen.

Dies bedeutet, dass die Teammitglieder sich nicht nur auf ein Spezial-gebiet konzentrieren, sondern zusätzlich auch noch weitreichende, weitere Fähigkeiten besitzen. Agile Teammitglieder entwickeln diese Merkmale, weil sie intensiv zusammenarbeiten, sich als Schwarm organisieren und ihre Arbeit rasch erledigen, was regelmäßig erfordert, dass sie sich gegen-seitig helfen.

Der Durchsatz einer einzelnen Person ist nicht relevant. Die Ausrichtung auf den Durchsatz einer einzelnen Person kann sogar schädlich sein, wenn dadurch ein Engpass für den Rest des Teams entsteht. Das Ziel besteht darin, dass das Team die Lieferung der fertigen Arbeit optimiert, um Feedback zu bekommen.

Wenn der Kunde überzeugende Ergebnisse wünscht, wie die rasche Lieferung von Features in ausgezeichneter Qualität, kann das Team nicht nur aus Spezialisten zusammengesetzt werden im irregeleiteten Bemühen um maximale Ressourceneffizienz. Das Ziel des Teams ist Flusseffizienz und damit ein optimierter Durchsatz des gesamten Teams. Kleine Losgrößen fördern die Zusammenarbeit als Team. Es ist Aufgabe des Produktverantwortlichen, dafür zu sorgen, dass das Team sich mit Arbeit mit dem höchsten Wert beschäftigt.

„I-SHAPED UND T-SHAPED“

Manche Personen verfügen über eine hochgradige Spezialisierung auf einem Gebiet, leisten außerhalb dieses Gebiets aber kaum Beiträge. Diese Leute bezeichnet man in agilen Gemeinschaften als „I-shaped“ (I-förmig), weil sie wie der Buchstabe I über Tiefe, aber nicht viel Breite verfügen. „T-shaped“ (T-förmig) dagegen bedeutet, dass Personen ihr Fachwissen auf einem Gebiet mit unterstützenden, aber nicht so stark entwickelten Fähigkeiten auf verwandten Gebieten und guten Kooperationsfähigkeiten ergänzen. Zum Beispiel gilt eine Person, die einige Produktbereiche testen und andere Produktbereiche entwickeln kann, als „T-shaped“.

Eine „T-shaped“ Person besitzt eine bestimmte, anerkannte Spezialisierung und Hauptaufgabe, aber auch die Fähigkeiten, Vielseitigkeit und Eignung zur Zusammenarbeit, um im Bedarfsfall anderen Personen unter die Arme zu greifen. Diese Zusammenarbeit senkt die Zahl der Übergaben und Einschränkungen, die damit einhergehen, wenn nur ein Einzelner die Arbeit verrichten kann.

43

4.3.4 TEAMSTRUKTUREN

In vielen verschiedenen Branchen arbeiten Teams nach agilen Prinzipien und Praktiken. Mitarbeiter werden in funktionsübergreifende Teams platziert, um iterativ Arbeitsprodukte zu entwickeln.

Manche Organisationen können funktionsübergreifende Teams an einem Ort zusammenlegen, bei anderen sieht die Lage wieder anders aus. Statt alle Teammitglieder an einem Arbeitsort zu versammeln, arbeiten manche Organisationen mit verteilten oder verstreuten Teams. Ein verteiltes Team besteht aus Subteams, welche an verschiedenen Orten sitzen. Die Subteams an sich sind jedoch an einem Ort versammelt und unabhängig. Bei verstreuten Teams arbeitet jedes einzelne Teammitglied an einem völlig anderen Ort, entweder in einem Büro oder von zu Hause aus. Diese Aufteilungen sind wegen der höheren Kommunikationskosten nicht ideal, können aber funktionieren.

FA

LL

Das Kernteam, das zusammengestellt wurde, um diesen Praxisleitfaden zu schreiben, hat einen vielfältigen Hintergrund – manche sind Vertreter von PMI, andere wieder von Agile Alliance. Sie organisierten sich selbst und arbeiteten inkrementell an der Fertigstellung der Arbeit. PMI stellte eine Gruppe von Fachexperten zusammen, welche die Arbeit inspizierte, was dem Team während der Entwicklung das Einbeziehen von Feedback und die Verbesserung des Produkts ermöglichte. Das Kernteam war jedoch nicht repräsentativ für ein typisches agiles Team, weil die Arbeitszeit der Teammitglieder nicht zu 100 % diesem Vorhaben gewidmet wurde.

44 Abschnitt 4

4.3.5 DEDIZIERTE TEAMMITGLIEDER

Was passiert, wenn Teammitglieder ihre Zeit nicht zu 100 % dem Team widmen? Dieser Umstand ist zwar nicht ideal, lässt sich manchmal aber leider nicht vermeiden.

Das Hauptproblem mit Personen, die nur 25 % oder 50 % ihrer Kapazität für das Team aufwenden, besteht darin, dass sie mehrere Sachen gleichzeitig machen und zwischen den Aufgaben hin und her wechseln. Multitasking senkt den Arbeitsdurchsatz des Teams und beeinflusst dessen Fähigkeit, die Lieferung zuverlässig vorherzusagen.

2 Der Entwicklungsprozess „Follow the Sun“ bedeutet, dass die Arbeit am Ende eines jeden Arbeitstages von einem Standort an den nächsten übergeben wird, der viele Zeitzonen entfernt liegt, um die Produktentwicklung zu beschleunigen.

In einem großen, in den USA ansässigen Finanzinstitut gab es ein Programm mit einer Reihe von Teams, deren Mitglieder an der Ostküste der USA und an verschiedenen Standorten in Indien arbeiteten. Als das Team seine Arbeit aufnahm, war es ein großes verstreutes Team (UX, Analysten, Entwickler und Tester), das nach der Entwicklungspraxis „Follow the Sun“2 arbeitete, d. h. es gab eine gewisse Überschneidung bei den Arbeitszeiten der einzelnen Teammitglieder, welche die Arbeit dadurch direkt weiterreichen konnten. Teammitglieder hatten täglich gemeinsame Standups und ließen mithilfe von Webcams alle daran teilnehmen. Schlüsselrollen (Analysten, Produktverantwortliche, UX-Designer und Entwicklungsleiter) in den USA kamen früh zur Arbeit, um Fragen ihrer Kollegen in Indien zu beantworten und beim Abbau von Hindernissen zu helfen.

Als das Produkt expandierte und mehr Mittel bewilligt wurden, entstand der Beschluss, das Team in fünf kleinere Teams aufzuteilen. Dazu wurden an verschiedenen Standorten Teams zusammengelegt. Es wurde entschieden, an den einzelnen Standorten funktionsübergreifende Teams zusammenzulegen, die aus Entwicklern und Testern bestanden.

Es gab auch einen Kern von Analysten, die an den beiden Standorten in den USA ansässig waren und mit ihrem ebenfalls in den USA ansässigen Produktmanager und Produktverantwortlichen und dann jeweils mit den einzelnen Teams zusammenarbeiteten. Es gab zwar eine gewisse Struktur zur Durchführung von Produktprüfungen als ganzes Programm, aber die meisten übrigen Vorgänge wurden auf Teamebene durchgeführt, je nachdem, was am besten für das jeweilige Team funktionierte, damit es sich selbst organisieren konnte.

TIP

P

Multitasking hemmt den Fortschritt des gesamten Teams, weil Teammitglieder mit der Umstellung auf andere Zusammenhänge bzw. mit dem Warten, bis der andere seine übrigen Arbeiten erledigt hat, Zeit verschwenden. Wenn die Leute sich zu 100 % ihrem Team widmen, hat das Team den höchstmöglichen Durchsatz.

45

Der Produktivitätsverlust beim Wechsel zwischen Aufgaben beträgt zwischen 20 % und 40 %. Der Verlust steigt exponentiell mit der Anzahl an Aufgaben.

Wenn jemand an zwei Projekten arbeitet, ist er nicht zu je 50 % bei den Projekten. Die Person ist aufgrund der Kosten des Aufgabenwechsels jeweils nur mit 20 % bis 40 % bei ihren Projekten.

Multitasking erhöht auch die Wahrscheinlichkeit von Fehlern. Der Wechsel zwischen Aufgaben verbraucht Kognitive Leistungsfähigkeit. Weiterhin reduziert Arbeiten im Multitasking die Fähigkeit, sich an den jeweiligen Zusammenhang zu erinnern.

Wenn alle Mitglieder eines Teams zu 100 % einem Projekt zugewiesen sind, können sie fortlaufend als Team zusammenarbeiten und die Arbeit aller Mitglieder effektiver gestalten.

Tabelle A1-2 zur Projektmanagement-Prozessgruppe und Zuordnung von Wissensbereichen enthält weitere Tipps zu Teams in agilen Umgebungen, insbesondere zu den Prozessen im Wissensbereich „Ressourcenmanagement in Projekten“.

TIP

P

Nicht alle Teams haben alle Rollen, die sie brauchen. Manche Teams brauchen zum Beispiel Unterstützung von Datenbank-Administratoren oder Forschungsanalysten. Wenn ein Team vorübergehend Spezialisten zugewiesen bekommt, muss unbedingt dafür gesorgt werden, dass alle die gleichen Erwartungen haben. Wird dieser Spezialist zu 100 % dem Team zugewiesen und für wie lange? Die Erwartungen aller Beteiligten (Spezialist und Team) müssen geklärt werden, um den Umfang des Einsatzes festzulegen. Teilzeiteinsätze führen zu Risiken für das Projekt.

FA

LL

Da die Mitglieder des Kernteams, die diesen Praxisleitfaden ausarbeiteten, nicht 100 % ihrer Kapazität den Bemühungen des Teams widmen konnten, war ihr Durchsatz erheblich geringer, als wenn sie sich die Zusammenlegung an einem Arbeitsplatz geleistet hätten und ihre Aufmerksamkeit voll und ganz dem Projekt hätten widmen können. Die verteilte Zusammenarbeit war wirtschaftlich möglich, stellte aber nur einen Bruchteil der Kapazität bereit. Dennoch war es nicht machbar, alle Mitglieder an einem Ort zu versammeln und sich voll auf die Aufgabe zu konzentrieren. Daher identifizierte das Team seine verstreute Aufstellung als potenzielles Risiko. Das Team verfolgte und überwachte den Fortschritt seiner Arbeit mittels Werkzeugen zur Zusammenarbeit und passte Aufgaben entsprechend der Kapazität der einzelnen Mitglieder an.

46 Abschnitt 4

4.3.6 TEAMARBEITSPLÄTZE

Teams brauchen einen Platz, an dem sie gemeinsam arbeiten, ihren Zustand als Team verstehen und kooperieren können. Manche agilen Teams arbeiten gemeinsam in einem Raum. Manche Teams haben einen Teamarbeitsplatz für ihre Standups und Grafiken und arbeiten ansonsten in ihren jeweiligen Cubicles oder Büros.

Während Firmen auf offene, kooperative Arbeitsumgebungen umstellen, müssen Organisationen auch ruhige Plätze für Arbeitskräfte schaffen, die unterbrechungsfreie Zeit zum Denken und Arbeiten brauchen. Deshalb gestalten Firmen ihre Büros mit einem ausgewogenen Verhältnis von Gemeinschafts- und Gesellschaftsräumen und Ruhezonen oder privaten Räumen, in denen Einzelpersonen ohne Unterbrechungen arbeiten können (manchmal „Caves and Commons“, in etwa: „Höhlen und Gemeinschaftsräume“ genannt).

Wenn die Teammitglieder geografisch verteilt sind, entscheidet das Team, wie viel von ihrem Arbeitsplatz virtuell ist. Technologien wie das Teilen von Dokumenten, Videokonferenzen und andere Tools zur virtuellen Zusammenarbeit helfen den Teammitgliedern, auch aus der Ferne mitzuarbeiten.

Geografisch verteilte Teams brauchen virtuelle Arbeitsplätze. Darüber hinaus sollten die einzelnen Mitglieder des Teams in regelmäßigen Abständen zu persönlichen Treffen einberufen werden, damit sie Vertrauen zueinander fassen und die Zusammenarbeit miteinander lernen können.

Manche Methoden, um die Kommunikation in verstreuten Teams zu managen, sind sogenannte Fishbowl-Windows und Paarweises Arbeiten aus der Ferne:

uu Für das „Fishbowl-Window“ werden langfristige Videokonferenzschaltungen zwischen den verschiedenen Standorten, über welche das Team verstreut ist, eingerichtet. Die Videoschaltung erstreckt sich über den gesamten Arbeitstag. Auf diese Weise können sich die Teammitglieder gegenseitig sehen und spontan miteinander kommunizieren und dadurch die Verzögerung in der Zusammenarbeit senken, die sich durch die geografische Trennung sonst unweigerlich ergibt.

uu „Paarweises Arbeiten aus der Ferne“ erreicht man durch virtuelle Konferenztools, mit denen man Bildschirme teilen kann, sowie durch Sprach- und Video-Verbindungen. Solange die Zeitverschiebung berücksichtigt wird, ist diese Methode fast genauso effektiv wie das paarweise Arbeiten von Angesicht zu Angesicht.

TIP

P Bilden Sie Teams, indem Sie Leute mit unterschiedlichen Fähigkeiten aus verschiedenen Funktionsbereichen zusammenbringen. Klären Sie Manager und Führungspersonen über die agile Denkweise auf und binden Sie sie früh in die agile Transformation ein.

47

4.3.7 ÜBERWINDUNG VON ORGANISATIONS-SILOS

Bei der Bildung agiler Teams wird am besten mit der Schaffung eines grundlegenden Vertrauens und einer sicheren Arbeitsumgebung begonnen, damit alle Teammitglieder mit gleicher Stimme gehört und berücksichtigt werden können. Darin und im Aufbau einer agilen Denkweise besteht der grundlegende Erfolgsfaktor. Alle übrigen Herausforderungen und Risiken können abgefedert werden.

Oftmals bringen Silo-Organisationen Hindernisse für die Bildung funktionsübergreifender agiler Teams mit sich. Die zum Aufbau funktionsübergreifender Teams gebrauchten Mitglieder unterstehen in der Regel verschiedenen Managern, und ihre Leistung wird von ihren Managern nach unterschiedlichen Kennzahlen beurteilt. Manager müssen auf die Durchflusseffizienz (und teambasierte Kennzahlen) statt auf Ressourceneffizienz achten.

Zur Überwindung von Organisationssilos muss mit den einzelnen Managern dieser Teammitglieder zusammengearbeitet werden, um sie zu überzeugen, die notwendigen Personen dem funktionsübergreifenden Team zuzuteilen. Dadurch wird nicht nur Teamsynergie erzeugt, sondern die Organisation sieht auch, wie der wirksame Einsatz ihrer Mitarbeiter das Projekt oder das in der Erstellung befindliche Produkt optimiert.

Weitere Informationen über Teams finden sich in Anhang X2, Attribute mit Einfluss auf Anpassung.

TIP

P

Konzentrieren Sie sich als agiler Projektleiter zunächst darauf, wie Sie ein funktionsübergreifendes Team bilden können, dessen Mitglieder sich zu 100 % einem Team widmen. Selbst wenn das bedeutet, dass Sie nur die wichtigsten Teammitglieder, wie Entwickler und Tester, dazu bringen können, täglich zusammenzuarbeiten und zu kommunizieren, ist das ein Schritt in Richtung Agilität.

49

5AGILITÄT IMPLEMENTIEREN: AUSLIEFERUNG IN EINER AGILEN UMGEBUNG

5.1 AUFTRAG FÜR PROJEKT UND TEAM

Jedes Projekt braucht einen Projektauftrag, damit das Projektteam weiß, warum dieses Projekt wichtig ist, welche Richtung das Team einschlagen soll und worin das Projektziel besteht. Allerdings reicht der Projektauftrag allein für das Team vielleicht nicht aus. Agile Teams brauchen Teamnormen und ein Verständnis ihrer Zusammenarbeit und deshalb eventuell einen Teamauftrag.

Der Prozess der Teamauftragserstellung hilft dem Team zu lernen, wie es zusammenarbeiten und um das Projekt herum zusammenwachsen kann.

Bei einem agilen Projekt braucht das Team zumindest den Leitgedanken oder Zweck des Projekts und einen eindeutigen Satz an Arbeitsvereinbarungen. Ein agiler Projektauftrag beantwortet die folgenden Fragen:

uu Warum machen wir das Projekt? Das ist der Leitgedanke des Projekts.

uu Wem nützt es und wie? Das kann Teil des Leitgedankens oder Zwecks des Projekts sein.

uu Was sind die Fertigstellungskritierien (definition of done) für das Projekt? Das sind die Freigabekriterien des Projekts.

uu Wie werden wir zusammenarbeiten? Das erklärt den beabsichtigten Arbeitsfluss.

Eine dienende Führungsperson kann im Auftragsvergabeprozess vermitteln. Ein Team kann durch gemeinsame Arbeit zusammenwachsen, und der Projektauftrag ist ideal, um mit der Arbeit zu beginnen. Darüber hinaus wollen die Teammitglieder vermutlich auch zusammenarbeiten, um zu sehen, wie sie miteinander zurechtkommen.

50 Abschnitt 5

Teams brauchen keinen formellen Teamauftragsprozess, solange sie verstehen, wie sie zusammenarbeiten sollen. Manche Teams profitieren jedoch von einem Teamauftragsprozess. Hier sind einige Vorschläge zur Auftragserstellung, die Teammitglieder als Grundlage für ihren Teamauftrag heranziehen können:

uu Teamwerte wie nachhaltiges Tempo und Kernarbeitszeiten

uu Arbeitsvereinbarungen, zum Beispiel, was „ready“ (bereit) bedeutet, damit das Team Arbeit annehmen kann; was „done“ (erledigt) bedeutet, damit das Team die Fertigstellung einheitlich beurteilen kann; Einhalten der Timebox oder etwa Begrenzungen laufender Arbeit

uu Grundregeln, etwa, dass in einem Meeting nur eine Person redet, und

uu Gruppennormen, zum Beispiel, wie das Team mit Meetingzeiten umgeht.

Die dienende Führungsperson kann gemeinsam mit dem Team auch noch andere Verhaltensweisen ansprechen.

Denken Sie daran, dass der Teamauftrag bestimmt, wie die Teammitglieder miteinander umgehen. Ziel des Teamauftrags ist es, eine agile Umgebung zu schaffen, in der Teammitglieder im Rahmen ihrer Möglichkeiten als Team zusammenarbeiten können.

5.2 ALLGEMEINE AGILE PRAKTIKEN

Abschnitte 5.2.1 bis 5.2.8 beschreiben einige der häufigsten agilen Projektpraktiken.

5.2.1 RETROSPEKTIVEN

Die wichtigste Praxis überhaupt ist die Retrospektive, weil sie dem Team erlaubt, seinen Prozess besser zu verstehen, diesen zu verbessern und anzupassen.

Retrospektiven helfen dem Team, aus seiner früheren Arbeit am Produkt und dessen Prozess zu lernen. Eines der Prinzipien hinter dem Agilen Manifest lautet: „In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.“

51

Viele Teams setzen Iterationen – insbesondere zweiwöchige Iterationen – ein, weil zur Iteration eine Präsentation und am Ende eine Retrospektive gehören. Das Team braucht allerdings keine Iterationen, um eine Retrospektive durchzuführen. Teammitglieder können sich an diesen Schlüsselpunkten zu einer Retrospektive entschließen:

uu Wenn das Team ein Release abschließt oder etwas liefert. Es muss sich nicht um einen gewaltigen Schritt handeln. Es kann ein beliebiges Release sein, auch wenn es noch so klein ist.

uu Wenn mehr als ein paar Wochen seit der letzten Retrospektive vergangen sind.

uu Wenn das Team festgefahren wirkt und der Fluss von fertigen Arbeiten durch das Team unterbrochen ist.

uu Wenn das Team einen neuen Meilenstein erreicht.

Teams profitieren davon, wenn sie ausreichend Zeit zum Lernen freihalten, entweder durch eine zwischengeschaltete Retrospektive oder eine Retrospektive am Projektende. Teams müssen etwas über ihr Arbeitsprodukt und ihren Arbeitsprozess lernen. Manche Teams haben beispielsweise Schwierigkeiten mit der Fertigstellung ihrer Arbeit. Wenn Teams ausreichend Zeit einplanen, können sie ihre Retrospektive zur Erfassung von Daten strukturieren, diese Daten verarbeiten und entscheiden, was sie später als Experiment versuchen wollen.

Vor allem ist zu beachten, dass es bei einer Retrospektive nicht um Schuldzuweisungen geht; die Retrospektive bietet Teams Gelegenheit, aus früheren Arbeiten zu lernen und kleine Verbesserungen anzubringen.

Bei der Retrospektive geht es um qualitative (Gefühle der Mitarbeiter) und quantitative (Messungen) Daten, dann darum, diese Daten zur Ursachenbestimmung zu nutzen, Gegenmaßnahmen zu entwerfen und Maßnahmenpläne auszuarbeiten. Für das Projektteam ergeben sich eventuell zahlreiche Maßnahmen zur Beseitigung von Hindernissen.

Es empfiehlt sich, die Anzahl an Maßnahmen auf die Kapazität des Teams zu beschränken, mit der es Verbesserungen in der kommenden Iteration oder Arbeitsperiode umsetzen kann. Wenn versucht wird, zu viele Dinge auf einmal zu verbessern, und dann nichts davon zu Ende gebracht wird, ist das weitaus schlimmer, als von vornherein die Fertigstellung weniger Posten zu planen und diese dann erfolgreich abzuschließen. Wenn es die Zeit erlaubt, kann das Team dann immer noch an der nächsten Verbesserungsmöglichkeit auf der Liste arbeiten. Bei Auswahl der Verbesserungen durch das Team muss entschieden werden, wie die Ergebnisse bewertet werden. In der nächsten Periode misst man dann die Ergebnisse, um Erfolg oder Scheitern der einzelnen Verbesserungen zu bestätigen.

Ein Moderator aus dem Team führt durch einen Vorgang, um die Wichtigkeit jeder einzelnen Verbesserung in eine Reihenfolge zu bringen. Sobald das Team die Verbesserungen in eine Reihenfolge gebracht hat, wählt es eine geeignete Anzahl aus, an denen für die nächste Iteration gearbeitet wird (oder fügt sie dem Arbeitsfluss hinzu, wenn es sich um ein flussbasiertes Projekt handelt).

52 Abschnitt 5

5.2.2 VORBEREITUNG DES BACKLOGS

Der Backlog ist die geordnete Aufstellung der gesamten Arbeit für ein Team und wird in Form von Storys präsentiert. Es ist nicht notwendig, alle Storys für das gesamte Projekt vor Aufnahme der Arbeiten zu erstellen – nur genug, um die erste Freigabe in groben Zügen zu verstehen, und ausreichende Arbeitspakete für die nächste Iteration zu haben.

Produktverantwortliche (oder ein Team von Produktverantwortlichen, dem der Produktmanager und alle relevanten Produktverantwortlichen für diesen Produktbereich angehören) können einen Produkt-Meilensteinplan aufstellen, um die voraussichtliche Abfolge der Liefergegenstände im Laufe der Zeit abzubilden. Der Produktverantwortliche passt den Meilensteinplan auf der Grundlage dessen an, was das Team liefert. (Siehe Anhang X3, Agile Eignungskriterien-Tools, für Beispiele von Meilensteinplänen.)

5.2.3 FEINABSTIMMUNG DES BACKLOGS

Im iterationsbasierten agilen Projektmanagement arbeitet der Produktverantwortliche oft in einer oder mehreren Sitzungen während einer Iteration gemeinsam mit dem Team an der Ausarbeitung von Storys für die kommende Iteration. Zweck dieser Meetings ist die Feinabstimmung von genügend Storys, damit das Team versteht, worum es sich bei den Storys handelt und wie groß die Storys im Verhältnis zueinander sind.

Es gibt keine einhellige Meinung darüber, wie lang die Feinabstimmung dauern sollte. Es gibt ein Kontinuum aus:

uu Feinabstimmung „Just-in-time“ für flussbasierte Agililtät. Das Team hebt die nächste Karte vom Aufgabenstapel ab und bespricht sie.

uu Viele iterationsbasierte agile Teams nutzen hierfür eine einstündige Diskussion in einer Timebox in der Mitte einer zweiwöchigen Iteration. (Das Team wählt eine Iterationsdauer, die ihm ausreichend häufiges Feedback gibt.)

uu Mehrere Feinabstimmungsgespräche für iterationsbasierte agile Teams. Teams können dies nutzen, wenn das Produkt, der Produktbereich oder das Problemgebiet neu für sie sind.

TIP

P

Mithilfe von „Impact Mapping“ (Mapping von Geschäftszielen auf User Storys) können Sie sehen, wie das Produkt zusammenpasst. Unter normalen Umständen leitet der Produktverantwortliche diese Arbeit. Eine dienende Führungsperson kann eventuell notwendige Meetings moderieren und damit dem Projekt dienen.

53

Meetings zur Feinabstimmung gestatten dem Produktverantwortlichen, dem Team Ideen für Storys vorzustellen. Sie gestatten ferner dem Team, etwas über die möglichen Herausforderungen oder Probleme in den Storys zu erfahren. Wenn der Produktverantwortliche im Unklaren über die Abhängigkeiten ist, kann er das Team um ein Feature-Spike bitten, um die Risiken zu verstehen.

Der Produktverantwortliche hat viele Möglichkeiten zur Durchführung der Meetings zu Vorbereitung und Feinabstimmung von Backlogs, zum Beispiel:

uu Die Teams dazu auffordern, als Kombination aus Entwickler, Tester und Business Analyst/Produktverantwortlicher zu arbeiten, um die Story zu erörtern und zu schreiben.

uu Dem Team das allgemeine Story-Konzept vorstellen. Das Team bespricht und verfeinert es zur notwendigen Anzahl an Storys.

uu Zusammen mit dem Team nach Möglichkeiten suchen, um die Storys gemeinsam auszuloten und zu schreiben, und dabei darauf achten, dass alle Storys so klein sind, dass das Team einen steten Fluss fertiger Arbeiten produzieren kann. Ggf. kann darauf hingearbeitet werden, mindestens eine Story pro Tag abzuschließen.

Teams machen es sich oft zum Ziel, nicht mehr als eine Stunde pro Woche mit der Feinabstimmung von Storys für den nächsten Arbeitsstapel zu verbringen. Teams möchten möglichst viel Zeit mit Arbeiten statt mit der Planung der Arbeit verbringen. Wenn das Team mehr als eine Stunde pro Woche zur Feinabstimmung von Storys braucht, könnte der Produktverantwortliche zu viel vorbereiten, oder dem Team fehlen entscheidende Fähigkeiten zur Bewertung und Feinabstimmung der Arbeit.

5.2.4 DAILY STANDUPS (TÄGLICHE KURZBESPRECHUNGEN)

Mit Standups synchronisieren sich die Teammitglieder gegenseitig, decken Probleme auf und sorgen dafür, dass die Arbeit reibungslos durch das Team fließt.

Für Standups sollten Timeboxen von höchstens 15 Minuten aufgestellt werden. Das Team geht das Kanban-Board oder die Aufgabentafel durch, und jeder aus dem Team kann das Standup moderieren.

In iterationsbasierter Agilität beantworten alle in der Runde die folgenden Fragen:

uu Was habe ich seit dem letzten Standup fertiggestellt?

uu Was plane ich bis zum nächsten Standup fertigzustellen?

uu Worin bestehen für mich Hindernisse (oder Risiken oder Probleme)?

54 Abschnitt 5

Fragen dieser Art führen zu Antworten, die es den Teammitgliedern gestatten, sich selbst zu organisieren und sich gegenseitig für die Fertigstellung der am Vortag und während der Iteration zugesagten Arbeit zur Rechenschaft zu ziehen.

Flussbasierte Agilität geht anders an Standups heran, denn sie konzentriert sich auf den Durchsatz des Teams. Das Team betrachtet die Tafel von rechts nach links. Die Fragen lauten:

uu Was müssen wir tun, um dieses Arbeitspaket weiterzubringen?

uu Arbeitet irgendjemand an etwas, das nicht auf der Tafel steht?

uu Was müssen wir als Team fertigstellen?

uu Gibt es Engpässe oder Blockaden im Arbeitsfluss?

Eines der Anti-Muster, die man oft in Standups sieht, besteht darin, dass sie zu Statusbesprechungen werden. Teams, die früher in einer plangetriebenen Umgebung gearbeitet haben, verfallen vielfach in dieses Anti-Muster, weil sie an Statusmeldungen gewöhnt sind.

Ein weiteres Anti-Muster, das man oft in Standups sieht, besteht darin, dass das Team damit beginnt, Probleme zu lösen, sobald diese sichtbar werden. Standups dienen der Feststellung, dass es Probleme gibt – nicht ihrer Lösung. Probleme werden auf einen „Parkplatz“ gestellt und es wird, ggf. unmittelbar nach dem Standup, ein weiteres Meeting einberufen, um die Probleme dort zu lösen.

Teams führen ihre eigenen Standups durch. Gut geführte Standups können sehr nützlich sein, wenn die Teamarbeit enge Zusammenarbeit erfordert. Es wird eine bewusste Entscheidung darüber getroffen, wann das Team Standups braucht oder effektiv nutzen kann.

TIP

P Fordern Sie die Teammitglieder statt einen Projektmanager oder eine Führungsperson dazu auf, das Standup zu moderieren, damit es nicht zu einer Statusbesprechung wird, sondern vom Team dazu genutzt wird, sich selbst zu organisieren und gegenseitig Zusagen zu machen.

55

5.2.5 PRÄSENTATIONEN/PRÜFUNGEN

Mit der Fertigstellung der Features, gewöhnlich in Form von Anwender-Storys, führt das Team in regelmäßigen Abständen das funktionsfähige Produkt vor. Der Produktverantwortliche sieht die Präsentation und akzeptiert Storys oder lehnt sie ab.

In iterationsbasierter Agilität führt das Team alle fertiggestellten Arbeitspakete am Ende der Iteration vor. In flussbasierter Agilität führt das Team die fertiggestellten Arbeitspakete zu einem bestimmten Termin vor, in der Regel dann, wenn ausreichend Features zu einem zusammenhängenden, wertstiftenden Paket kombiniert wurden. Teams sowie der Produktverantwortliche brauchen Feedback, um zu entscheiden, wie frühzeitig Produktfeedback eingefordert werden muss.

Im Allgemeinen führt man mindestens alle zwei Wochen vor, was im Team als Arbeitserzeugnis vorliegt. Diese Frequenz genügt den meisten Teams, damit die Teammitglieder das Feedback bekommen, das sie davor schützt, in eine falsche Richtung weiterzuarbeiten. Die Zeitspanne ist auch ausreichend, damit die Teams die Produktentwicklung so sauber halten können, dass sie ein vollständiges Produkt erstellen können, so oft sie dies wünschen oder müssen.

Ein grundlegendes Kriterium für die Agilität eines Projekts ist die häufige Auslieferung eines funktionsfähigen Produkts. Ein Team ohne Präsentationen oder Releases kann nicht schnell genug lernen und arbeitet wahrscheinlich nicht nach agilen Methoden. Das Team braucht möglicherweise zusätzliches Coaching, um zu einer häufigen Auslieferung zu gelangen.

5.2.6 PLANUNG FÜR ITERATIONSBASIERTE AGILITÄT

Jedes Team verfügt über unterschiedliche Kapazität. Jeder Produktverantwortliche hat eine unterschiedliche, durchschnittliche Story-Größe. Teams betrachten ihre Story-Größe, damit sie nicht die Lieferung von mehr Storys zusagen als Kapazität innerhalb diese Iteration im Team vorhanden ist.

Wenn Mitarbeiter nicht zur Verfügung stehen (z. B. Feiertage, Urlaub oder sonstige Gründe, die sie von der Mitarbeit am nächsten Aufgabensatz abhalten), weiß der Produktverantwortliche, dass das Team eine geringere Kapazität hat. Das Team kann nicht dieselbe Menge Arbeit fertigstellen wie in der vorhergehenden Periode. Bei gesunkener Kapazität planen Teams nur die Arbeit, die der vorhandenen Kapazität entspricht.

Teams schätzen, was sie fertigstellen können, und das entspricht einem Wert für Kapazität (siehe Beispiele in Abschnitt 4.10). Teams können ihre nächste Auslieferung nicht mit 100-prozentiger Gewissheit vorhersagen, weil sie das Unvorhergesehene nicht kennen können. Kleinere Storys und Lernen aus dem Teamfortschritt anhand eines fertigen Produkts zeigt Teams, was sie in Zukunft bewerkstelligen können.

Agile Teams planen nicht nur einmal in einem einzelnen Block. Agile Teams planen stattdessen ein wenig, liefern, lernen und planen dann ein bisschen mehr in einem fortlaufenden Zyklus.

TIP

P Machen Sie das Team auf das Anti-Muster aufmerksam und helfen Sie dem Team dabei, Verbesserungen für seine Standups auszuloten.

56 Abschnitt 5

5.2.7 AUSFÜHRUNGSPRAKTIKEN, DIE TEAMS BEI DER LIEFERUNG VON WERT UNTERSTÜTZEN

Wenn das Team nicht auf Qualität achtet, wird es schnell unmöglich, auch nur irgendetwas kurzfristig freizugeben.

Die folgenden technischen Praktiken, die zum großen Teil aus dem eXtreme Programming stammen, helfen dem Team ggf. mit seiner höchstmöglichen Geschwindigkeit zu liefern:

uu Fortlaufende Integration (Contiuous Integration). Unabhängig vom Produkt wird eine häufige Integration von Arbeit in das Ganze vorgenommen und dann erneut getestet, um festzustellen, ob das Gesamtprodukt noch wie beabsichtigt funktioniert.

uu Tests auf allen Ebenen. Tests auf Systemebene werden für End-to-End-Informationen und Tests auf der Komponentenebene (Unit Tests) für die einzelnen Bausteine durchgeführt. Dazwischen muss festgestellt werden, ob und wo Bedarf für Integrationstests besteht. Teams finden „Smoke Tests“ als ersten Anhaltspunkt dafür hilfreich, ob das Arbeitsprodukt tauglich ist. Erfahrungsgemäß hilft es, Teams entscheiden zu lassen, wann und welche Regressionstests durchgeführt werden sollen, um die Produktqualität mit guter Erstellungsleistung (Build Performance) aufrechtzuerhalten. Agile Teams bevorzugen überwiegend automatisierte Tests, damit sie eine Liefergeschwindigkeit aufbauen und beibehalten können.

uu Akzeptanztestgetriebene Entwicklung (Acceptance Test-Driven Develoment, ATDD). Bei ATDD bespricht das gesamte Team gemeinsam die Abnahmekriterien für ein Arbeitsprodukt. Dann entwickelt das Team die Tests; das erlaubt dem Team, gerade so viel Code und automatisierte Tests zu schreiben, wie zur Erfüllung der Kriterien notwendig sind. Bei Projekten, die keine Software betreffen, überlegt man sich, wie man die Arbeit testen kann, während das Team Wertpakete fertigstellt.

uu Test- und verhaltensgetriebene Entwicklung (Test-Driven Development, TDD und Behavior-Driven Development, BDD). Das Schreiben automatisierter Tests vor dem Erzeugen des Produkts hilft sogar bei dessen Erstellung und schützt vor Fehlern. Bei Nicht-Software-Projekten wird überlegt, wie ein „Probelauf“ mit den Designs des Teams gemacht werden könnte. Hardware- und Maschinenbauprojekte arbeiten oft mit Simulationen für Zwischentests ihrer Designs.

uu Spikes (Forschung oder Versuche in Timeboxen). Spikes sind zum Lernen nützlich und können eingesetzt werden für: Schätzung, Definition von Abnahmekriterien und Verständnis, wie die Aktivität eines Anwenders durch das Produkt fließt. Spikes sind hilfreich, wenn das Team entscheidende technische oder funktionale Elemente erlernen muss.

57

5.2.8 WIE ITERATIONEN UND INKREMENTE ZUR AUSLIEFERUNG EINES FUNKTIONSFÄHIGEN PRODUKTS BEITRAGEN

Iterationen helfen einem Team, einen Rhythmus für die Auslieferung und viele Arten von Feedback zu schaffen. Teams produzieren schrittweise Wert für Auslieferung und Feedback. Der erste Teil dieser Auslieferung ist eine Präsentation. Die Teams bekommen Feedback darüber, wie das Produkt in einer Präsentation aussieht und funktioniert. Rückblickend untersuchen die Teammitglieder dann, wie sie ihren Prozess untersuchen und anpassen können, um erfolgreich zu sein.

Präsentationen oder Prüfungen sind ein notwendiger Teil des agilen Projektflusses. Die Präsentationen sollten entsprechend dem Lieferrhythmus des Teams angesetzt werden.

5.3 LÖSUNG VON HERAUSFORDERUNGEN IN AGILEN PROJEKTEN

Agile Ansätze entstanden aus der Notwendigkeit heraus, Probleme im Zusammenhang mit einem hohen Grad an Änderungen, Unsicherheit und Komplexität in Projekten zu lösen. Aufgrund dieser Ursprünge enthalten sie eine Vielfalt an Werkzeugen und Methoden, um mit Situationen umzugehen, die bei plangetriebenen Vorgehensweisen Probleme darstellen. Siehe Tabelle 5-1.

TIP

P Teams sollten oft Präsentationen anbieten, um Feedback zu bekommen und ihren Fortschritt zu zeigen. Fordern Sie das PMO und andere beteiligte Parteien auf, den Präsentationen zuzuschauen, damit die Leute, die über das Projektportfolio entscheiden, den tatsächlichen Fortschritt sehen können.

58 Abschnitt 5

Tabelle 5-1. Agile Schmerzpunkte und Möglichkeiten der Problemlösung

Schmerzpunkt Möglichkeiten der Problemlösung

Unklarer Zweck oder Auftrag für das Team

Unklare Arbeitsvereinbarungen für das Team

Unklare Teamzusammensetzung

Unklare Anforderungen

Negatives Anwendererlebnis

Falsche Schätzung

Unklare Arbeitsaufgaben oder Arbeitsfortschritte

Team kämpft mit Hindernissen

Arbeitsverzögerungen/Überschreitungen aufgrund unzureichend abgestimmter Posten im Produkt-Backlog

Defects (Fehler im Produkt)

Arbeit ist nicht abgeschlossen

Technical Debt (mindere Codequalität)

Agile Auftragsvergabe zum Zweck – Leitgedanke, Auftrag und Auftragstests

Agile Auftragsvergabe zur Ausrichtung – Werte, Prinzipien und Arbeitsvereinbarungen

Agiler Teamauftrag für die Teamzusammensetzung – Grenzen, zugesagte Mittel und vorausschauende Analyse

Helfen Sie den Sponsoren und Stakeholdern, eine Produktvision zusammenzustellen. Erwägen Sie die Erstellung eines Meilensteinplans für das Produkt, indem Sie Speci�cation by Example, User Story Mapping und Impact Mapping verwenden. Bringen Sie das Team und den Produktverantwortlichen zusammen, um die Erwartungen und den Wert einer Anforderung zu klären. Zerlegen Sie den Meilensteinplan nach und nach in ein Backlog kleinerer, konkreter Anforderungen.

Die im Entwicklungsteam ausgeübten Praktiken für die Gestaltung des Anwendererlebnisses beteiligen Anwender schon früh und häu�g.

Reduzieren Sie Story-Größe durch Aufteilen der Storys. Setzen Sie relative Schätzung im gesamten Team für Ihre Schätzungen ein. Ziehen Sie agile Modellierung oder agiles Spiking in Betracht, um die Story zu verstehen.

Helfen Sie dem Team zu lernen, dass es seine Arbeit selbst steuert. Mithilfe von Kanban-Boards kann der Arbeits�uss veranschaulicht werden. Ziehen Sie ein Daily Standup in Betracht, bei dem das Board durchgegangen und sichtbar wird, in welchem Status sich welche Arbeit be�ndet.

Eine dienende Führungsperson kann dabei helfen, diese Hindernisse aus dem Weg zu räumen. Wenn das Team nicht weiß, welche Optionen ihm zur Verfügung stehen, kann ein Coach hinzugezogen werden. Manchmal muss das Team Hindernisse nach oben weitergeben, die das Team oder die dienende Führungsperson nicht beseitigen konnten.

Produktverantwortlicher und Team bearbeiten die Storys gemeinsam. Legen Sie eine „De�nition of Ready“ für die Storys fest. Storys können in kleinere Storys aufgeteilt werden.

Denken Sie über die technischen Praktiken nach, die in der Umgebung funktionieren. Einige Möglichkeiten: Paararbeit, gemeinsame Produktverantwortung, umfangreiche Tests (testgetriebener Ansatz und automatische Tests) und eine robuste „De�nition of Done“ (Liste der Fertigstellungskriterien).

Das Team de�niert die Liste der Fertigstellungskriterien für Storys, einschließlich der Abnahmekriterien. Fügen Sie auch die Freigabekriterien für Projekte hinzu.

Refaktorierung, agile Modellierung, umfassende Tests, automatische Analyse der Codequalität, De�nition of Done.

59

Tabelle 5-1. Agile Schmerzpunkte und Möglichkeiten der Problemlösung (fortges.)

Schmerzpunkt Möglichkeiten der Problemlösung

Produktkomplexität ist zu hoch

Langsame oder gar keine Verbesserung im Teamarbeitsprozess

Zu viel Vorausarbeit führt zu Nacharbeit

Fehlstarts, vergeblicher Aufwand

Inef�zient geordnete Arbeitspakete im Produkt-Backlog

Ungleichmäßiger Arbeits�uss mit Hektik/Warten

Unmögliche Forderungen vonseiten der Stakeholder

Unerwartete oder unvorhergesehene Verzögerungen

Silo-Teams anstelle von funktionsübergreifenden Teams

Regen Sie das Team bei Software- und anderen Projekten stets zum Nachdenken über folgende Frage an: „Was ist die einfachste Lösung, die funktionieren könnte?“ und wenden Sie folgendes agiles Prinzip an: „Einfachheit – die Kunst, die Menge nicht getaner (nicht notwendiger) Arbeit zu maximieren.“ Damit lässt sich Komplexität abbauen.

Erfassen Sie nicht mehr als drei Elemente, die jeweils in einer Retrospektive verbessert werden sollen. Die dienende Führungsperson sollte dann dem Team lernen helfen, wie diese Elemente integriert werden können.

Statt viel Vorausarbeit können Team-Spikes zum Lernen eingeführt werden. Messen Sie darüber hinaus die laufende Arbeit am Anfang des Projekts und untersuchen Sie die Optionen des Teams zur Lieferung von Wert statt Designs. Verkürzen Sie die Iterationen und erstellen Sie eine robuste Liste der Fertigstellungskriterien.

Bitten Sie den Produktverantwortlichen, zu einem integralen Bestandteil des Teams zu werden.

Stufen Sie Arbeitspakete nach Wert ein, einschließlich der Kosten einer Verzögerung geteilt durch die Dauer (CD3) sowie anderer Wertemodelle

Planen Sie mit der Kapazität des Teams und nicht mehr. Bitten Sie die Mitarbeiter, nicht mehrere Aufgaben gleichzeitig zu erledigen, sondern sich einem Team zu widmen. Bitten Sie das Team zur paarweisen Arbeit, zum Swarming oder Mob-Programming, um die Kompetenzen gleichmäßig im ganzen Team zu verteilen.

Dienende Führungspersonen arbeiten mit den betreffenden Stakeholdern (und eventuell mit dem Produktverantwortlichen) zusammen.

Bitten Sie das Team, sich häu�ger zu melden, setzen Sie Kanban-Boards zur Abbildung des Arbeits�usses und der Einschränkungen des Arbeitsfortschritts ein, damit die Auswirkungen der Forderungen auf Team oder Produkt verstanden werden. Darüber hinaus sollten Hindernisse und deren Beseitigungen auf einem eigenen „Hindernis-Board“ nachgezeichnet werden.

Bitten Sie die Mitarbeiter, die an Projekten beteiligt sind, sich selbst als funktionsübergreifende Teams zu organisieren. Mit den Fähigkeiten der dienenden Führung kann Managern vermittelt werden, warum Agilität funktionsübergreifende Teams benötigt.

60 Abschnitt 5

5.4 MESSUNGEN IN AGILEN PROJEKTEN

Die Umstellung auf Agilität bedeutet den Einsatz anderer Messungen. Der Einsatz von Agilität bedeutet die Ausrichtung auf neue Kennzahlen, die für Team und Management von Bedeutung sind. Diese Kennzahlen sind wichtig, weil sie auf Wert für den Kunden ausgerichtet sind.

Ein Problem mit Statusmeldungen besteht darin, dass Teams die Fertigstellung des Projekts nicht immer genau vorhersagen oder das Projekt anhand des Ampelstatus beschreiben können. Projektleiter beschreiben das Projekt zum Beispiel als „zu 90 % fertiggestellt“. An dem Punkt versucht das Team, die einzelnen Teile zu einem Produkt zu integrieren. Das Team entdeckt fehlende Anforderungen oder Überraschungen oder stellt fest, dass das Produkt sich nicht so integrieren lässt wie erwartet.

Das Projekt ist nur zum Teil fertig, und die Statusmeldung nach dem Ampelprinzip gibt nicht den tatsächlichen Zustand wieder. Allzu oft merkt das Projektteam, dass es noch einmal so viel Zeit braucht, um den Rest des Projekts fertigzustellen. Bei allzu vielen Projekten merkt das Team, dass es wegen der aufgetauchten Probleme – höchstens – zu 10 % fertig ist.

Das Problem mit plangetriebenen Messungen liegt darin, dass sie oftmals nicht die Wirklichkeit abbilden. Es geschieht oft, dass die Ampel des Projektstatus bis einen Monat vor dem Freigabetermin auf Grün steht; das nennt man manchmal „Wassermelonenprojekt“ (außen grün und innen rot). Oft schalten die Projektstatusampeln scheinbar ohne Vorwarnung auf Rot, weil es bis einen Monat vor Freigabetermin keine empirischen Daten über das Projekt gibt.

Kennzahlen für agile Projekte enthalten bedeutsame Informationen, welche eine fortlaufende Leistungsbilanz bieten, da agile Projekte regelmäßig Wert (fertige Arbeit) liefern. Projektteams können diese Daten für bessere Prognosen und zur Entscheidungsfindung heranziehen.

Ersatzmessungen wie prozentuale Fertigstellung sind weniger nützlich als empirische Messungen, wie zum Beispiel die Anzahl fertiger Features. Weitere Informationen zum Wertmanagement finden Sie in Abschnitt 4.10. Agilität hilft Teams, Probleme und Schwierigkeiten zu erkennen, damit das Team sie diagnostizieren und angehen kann.

Neben quantitativen Werten kann das Team auch qualitative Werte erheben. Einige dieser qualitativen Werte konzentrieren sich auf die vom Team gewählten Praktiken und bewerten, wie gut das Team diese Praktiken anwendet, zum Beispiel die Kundenzufriedenheit mit den gelieferten Features, die Stimmung im Team und alles andere, was das Team als qualitativen Wert verfolgen will.

61

5.4.1 AGILE TEAMS MESSEN ERGEBNISSE

Agilität bevorzugt empirische und wertbasierte Messungen gegenüber plangetriebenen Messungen. Agilität misst, was das Team liefert, nicht die vom Team vorhergesagte Lieferung.

Ein Team, das an Projektbasispläne und Schätzungen von Fertigstellungswert und Investitionsrendite gewöhnt ist, mag es verwirrend finden, an einem Projekt zu arbeiten und nicht einem Basisplan zu folgen. Agilität basiert auf Arbeitsprodukten, die für den Kunden von nachweisbarem Wert sind.

Basispläne sind oft Gegenstand eines Prognoseversuchs. Agilität beschränkt das Team bei seiner Schätzung im Höchstfall auf die nächsten paar Wochen. Wenn die Arbeit eines Teams in Agilität geringe Veränderlichkeit besitzt und die einzelnen Teammitglieder nicht mehrere Aufgaben gleichzeitig erledigen, kann die Kapazität des Teams Stabilität erreichen. Dies wiederum erlaubt bessere Prognosen für die nächsten Wochen.

Wenn das Team die Arbeit im Iterations- oder Flussmodus fertiggestellt hat, kann das Team neu planen. Agilität erzeugt nicht die Fähigkeit, mehr Arbeit zu leisten. Es gibt jedoch Nachweise, dass die Wahrscheinlichkeit der Auslieferung einer Arbeitsaufgabe steigt, je kleiner sie ist.

Bei der Entwicklung von Softwareprodukten geht es wie bei jeder anderer Wissensarbeit um das Lernen – und zwar während Wert geliefert wird. Entwicklung von Hardware und im Maschninenbau sind in den Designphasen des Projekts ähnlich. Lernen findet durch Experimentieren, Auslieferung kleiner Wertinkremente und Feedback zur bisher geleisteten Arbeit statt. Viele andere Produktentwicklungsprojekte enthalten ebenfalls eine Lernkomponente.

Sponsoren wollen in der Regel wissen, wann das Projekt fertig ist. Sobald das Team eine zuverlässige Geschwindigkeit (Velocity: durchschnittliche Anzahl von Storys oder Story Points pro Iteration) oder die durchschnittliche Fertigstellungszeit festgestellt hat, kann das Team vorhersagen, wie lange das Projekt noch dauern wird.

Wenn das Team zum Beispiel durchschnittlich 50 Story Points pro Iteration abarbeitet und nach eigener Schätzung noch 500 weitere Story Points hat, dann schätzt das Team, dass es noch etwa zehn Iterationen geben wird. Wenn der Produktverantwortliche die verbleibenden Storys genauer definiert und das Team weiter an seinen Schätzungen arbeitet, kann die Projektschätzung sich nach oben oder unten verändern, aber das Team kann eine Schätzung abgeben.

Wenn das Team eine durchschnittliche Fertigstellungszeit von drei Tagen pro Story hat und es noch 30 Storys gibt, dann braucht das Team noch 90 Werktage, also etwa vier bis fünf Monate.

Zeigen Sie die Schwankungsbreite der Schätzung mithilfe von Burndown-Charts oder einem anderen Wert der Veränderlichkeit, den die Sponsoren verstehen.

62 Abschnitt 5

Weil Lernen ein so großer Teil des Projekts ist, muss das Team Unsicherheit ausgleichen und den Kunden Wert liefern. Das Team plant den nächsten kleinen Teil des Projekts. Das Team meldet empirische Daten und plant weitere kleine Schritte neu, um die Unsicherheit im Projekt zu bewältigen.

Manche iterationsbasierten Projekte arbeiten mit Burndown-Charts, um zu sehen, in welche Richtung sich das Projekt im Lauf der Zeit entwickelt. Abb. 5-1 zeigt ein Beispiel für ein Burndown-Chart, in der das Team die Auslieferung von 37 Story Points geplant hat. Story Points bewerten die relative Arbeit, das Risiko und die Komplexität einer Anforderung oder Story. Viele agile Teams schätzen ihren Aufwand anhand von Story Points. Die gestrichelte Burndown-Linie ist der Plan. In Abb. 5-1 kann das Team ab dem dritten Tag erkennen, dass diese Auslieferung gefährdet ist.

Abb. 5-1. Burndown-Chart für verbleibende Story Points

Verbleibende Story Points

LEGENDE

Tag1

40

35

30

25

20

15

10

5

0Tag2

Tag3

Tag4

Tag5

Tag6

Tag7

Tag8

Tag9

Tag10

Verbleibende Story Points

63

Manche Projektteams bevorzugen Burnup-Charts. Die Daten aus Abb. 5-1 sind in Abb. 5-2 als Burnup-Chart abgebildet.

Abb. 5-2. Burnup-Chart zur Anzeige fertiggestellter Story Points

Burnup-Charts zeigen die fertiggestellte Arbeit. Die beiden Grafiken in den Abb. 5-1 und 5-2 basieren auf denselben Daten, stellen diese jedoch unterschiedlich dar. Teams bevorzugen ggf. eine der beiden Betrachtungsweisen.

Wenn ein Team während einer Iteration sieht, was noch nicht fertig ist, kann das Team den Mut verlieren und deshalb die verbleibende Arbeit auf die Schnelle erledigen, ohne aber die Abnahmekriterien zu erfüllen. Das Team könnte jedoch eine Menge guter Gründe haben, warum die Arbeit nicht wie erwartet fertig wird. Burndowns zeigen die Auswirkungen von Multitasking unter den Teammitgliedern, von zu großen Storys oder abwesenden Teammitgliedern.

LEGENDE

Tag1

35

30

25

20

15

10

5

0Tag2

Tag3

Tag4

Tag5

Tag6

Tag7

Tag8

Tag9

Tag10

Erledigte Story Points

Erledigte Story Points

64 Abschnitt 5

Besonders bei Teams, für die Agilität noch neu ist, zeigt Burnup die Änderungen an Inhalt und Umfang während der Iteration. Burnups zeigen Teams, was sie erreicht haben; das hilft den Teams, die nächste Aufgabe in Angriff zu nehmen.

Unabhängig davon, ob ein Team Burndown- oder Burnup-Charts einsetzt, sieht es, was es im Lauf der Iteration fertiggestellt hat. Am Ende der Iteration kann das Team seinen nächsten Kapazitätswert (Anzahl von Storys oder Story Points) darauf basieren, was es in dieser Iteration fertiggestellt hat. Damit kann der Produktverantwortliche gemeinsam mit dem Team die Planung dessen anpassen, was das Team mit größerer Wahrscheinlichkeit in der nächsten Iteration liefern kann.

Velocity, die Summe der Story-Point-Größen für die in dieser Iteration tatsächlich fertiggestellten Features, erlaubt dem Team durch den Blick auf seine fortlaufende Leistungsbilanz die genauere Planung der nächsten Kapazität.

Flussbasierte agile Teams gebrauchen andere Messwerte: Vorlaufzeit (die Zeit, die insgesamt benötigt wird, um ein Arbeitspaket zu liefern, gemessen von seinem Eintrag auf dem Board bis zur seiner Fertigstellung), Fertigstellungszeit (die Zeit, die zur Verarbeitung eines Arbeitspakets gebraucht wird) und Reaktionszeit (die Zeit, die ein Arbeitspaket bis zur Arbeitsaufnahme wartet). Teams messen die Fertigstellungszeit, um Engpässe und Verzögerungen zu sehen, die nicht unbedingt innerhalb des Teams bestehen.

TIP

P Teams stellen möglicherweise fest, dass eine stabile Velocity bisweilen erst nach vier bis acht Iterationen erreicht wird. Die Teams brauchen das Feedback aus jeder Iteration, damit sie lernen, wie sie arbeiten und wie sie besser werden können.

65

Kanban-Board

BereitEntwicklung

und Test der Einheit

Entw. fertig Systemtest Fertig

8 3 2Fertigstellungszeit: Vom Zeitpunkt, an dem mit einer Aufgabe begonnen wird, bis zur Fertigstellung.

Vorlaufzeit: Vom Zeitpunkt, an dem etwas auf das Board gesetzt wird, bis zur Lieferung. Weil die Reihen-folge der Arbeitspakete in der Spalte „Bereit“ geändert werden kann, ist diese weniger vorhersehbar.

In dieser Spalte gibt es eine Obergrenze. Es kann jederzeit etwas herausgenommen und dafür etwas anderes hinzugefügt werden.

Lieferung an Kunden

Abb. 5-3. Beispiel eines Kanban-Boards

66 Abschnitt 5

Vorlaufzeit ist nützlich, um die Fertigstellungszeit vom ersten Blick auf ein bestimmtes Feature bis zur Dauer der Freigabe an den Kunden zu verstehen. Anhand der Grenzen für die laufende Arbeit (work in progress, WIP) oben in den Spalten, die hier in Kästchen abgebildet sind, kann das Team sehen, wie die Arbeit über das Board gezogen wird. Wenn das Team seine WIP-Grenzen erreicht hat, kann es keine Arbeit von links in die nächste Spalte ziehen. Stattdessen arbeitet das Team von der ganz rechts liegenden vollen Spalte her und fragt: „Was machen wir als Team, damit wir diese Arbeit in die nächste Spalte bringen können?“

Jedes Feature ist einzigartig und so ist seine Fertigstellungszeit. Ein Produktverantwortlicher stellt jedoch möglicherweise fest, dass kleinere Features kürzere Fertigstellungszeiten haben. Der Produktverantwortliche möchte Durchsatz sehen, deshalb erzeugt er kleinere Features oder arbeitet mit dem Team daran.

Burnups, Burndowns (Kapazitätswerte) und Vorlaufzeit sowie Fertigstellungszeit (Vorhersagbarkeitswerte) sind nützlich für aktuelle Messungen. Sie helfen einem Team verstehen, wie viel Arbeit noch ansteht und ob das Team rechtzeitig fertig wird.

Die Messung von Story Points ist nicht dasselbe wie die Messung fertiggestellter Storys oder Features. Manche Teams versuchen, Story Points zu messen, ohne das eigentliche Feature oder die Story fertigzustellen. Wenn Teams nur Story Points messen, messen sie Kapazität und keine beendete Arbeit, was gegen das Prinzip „funktionierende Software ist das wichtigste Fortschrittsmaß“ (oder ein entsprechendes Produkt, wenn es nicht um Software geht) verstößt.

Jedes Team hat seine eigene Kapazität. Wenn ein Team Story Points einsetzt, muss klar sein, dass die Anzahl an Story Points, die ein Team innerhalb einer bestimmten Frist fertigstellen kann, spezifisch für dieses Team ist.

TIP

P

Wenn Teams von externen Personen oder Gruppen abhängig sind, messen Sie die Fertigstellungszeit, um zu sehen, wie lange das Team zur Fertigstellung der Arbeit braucht. Messen Sie die Vorlaufzeit, um externe Abhängigkeiten zu sehen, nachdem das Team die Arbeit fertigstellt. Teams können auch die Reaktionszeit messen, die Zeit von „Bereit“ bis zur ersten Spalte, um zu sehen, wie lange sie im Durchschnitt brauchen, um auf neue Anfragen zu reagieren.

67

Wenn Teams ihre eigenen Messeinheiten benutzen, können sie ihre Arbeit besser beurteilen, schätzen und liefern. Der Nachteil der relativen Schätzung besteht darin, dass man unmöglich mehrere Teams vergleichen oder schneller machen kann.

Das Team kann fertiggestellte Arbeit in einem Burnup- oder Burndown-Chart für Features und in einem Burnup-Chart für das Produkt-Backlog messen. Diese Grafiken zeigen die Fertigstellungstrends im Lauf der Zeit, wie in Abb. 5-4 dargestellt.

Abb. 5-4. Feature-Grafik

Burnup- oder Burndown-Charts für Features können aufzeigen, dass die Anforderungen während des Projekts gestiegen sind. Die Linie der fertigen Features zeigt, dass das Team Features in einem gleichmäßigen Rhythmus fertigstellt. Die Linie der Features insgesamt zeigt, wie sich die Gesamtzahl der Features im Projekt im Laufe der Zeit ändert. Die Burndown-Linie der verbleibenden Features zeigt, dass die Fertigstellungsquote der Features unterschiedlich ausfällt. Jedes Mal, wenn dem Projekt Features hinzugefügt werden, ändert sich die Burndown-Linie.

Der Fertigstellungswert in Agilität beruht auf fertigen Features, wie in Abb. 5-5 gezeigt. Das Burnup-Chart zum Produkt-Backlog zeigt fertiggestellte Arbeiten im Vergleich zur erwarteten Arbeit insgesamt anhand von Meilensteinen, in festen Abständen oder Iterationen.

700

600

500

400

300

200

100

0

Anzahl der verbleibenden Features

Features: Fertiggestellt, verbleibend und insgesamt

Anzahl der fertiggestellten Features

Anzahl der Features insgesamt

Feat

ures

Zeit

LEGENDE

68 Abschnitt 5

Abb. 5-5. Burnup-Chart zum Produkt-Backlog

Ein Team kann jeweils nur eine Story fertigstellen. Bei der Fertigstellung eines großen Features, das mehrere Storys enthält, wird das Team unter Umständen am Ende der Iteration noch Storys unerledigt haben. Daher wird das gesamte Feature möglicherweise erst nach mehreren weiteren Iterationen abgeschlossen. Das Team kann seinen fertiggestellten Wert mit einem Burnup-Chart zum Produkt-Backlog wie in Abb. 5-5 abbilden.

Wenn das Team den Fertigstellungswert messen muss, kann es das Burnup-Chart in Abb. 5-6 als Beispiel heranziehen. Die linke Y-Achse stellt Story Points als Inhalt und Umfang dar und die rechte Y-Achse zeigt die Projektausgaben.

Iteration oder Zwischentermin

Kum

ulat

ive

Feat

urep

aket

e

FP 3

FP 2

FP 1

FP 3

FP 2

FP 1

FP 3

FP 2

FP 1

FP 3

FP 2

FP 1

FP 3

FP 2

FP 1

69

Abb. 5-6. Fertigstellungswert in einem agilen Kontext

Herkömmliche EVM-Kennzahlen wie Terminentwicklungsindex (SPI) und Kostenentwicklungsindex (CPI) lassen sich leicht in agile Begriffe übersetzen. Wenn das Team beispielsweise geplant hat, 30 Story Points in einer Iteration fertigzustellen, tatsächlich aber nur 25 fertiggestellt hat, dann ist der SPI 25/30 oder 0,83 (das Team erfüllt die geplante Quote nur zu 83 %). Desgleichen ist der CPI der Fertigstellungswert (Wert der fertiggestellten Features) bis zum aktuellen Datum, geteilt durch die Ist-Kosten bis zum aktuellen Datum, wie in Abb. 5-6 gezeigt: 2,2 Mio. € / 2,8 Mio. € = 0,79. Das bedeutet ein Ergebnis von nur 79 Cent für jeden Euro gegenüber Plan (aber hier wird natürlich vorausgesetzt, dass die Prognose noch stimmt).

1.10.2013 1.2.2014 1.5.2014 1.10.2014 1.2.2015 1.5.2015 1.10.2015 1.2.2016 1.5.2016 1.10.2016 1.2.2017 1.5.2017

3.000

2.500

2.000

1.500

1.000

500

0

6.000.000 €

5.000.000 €

4.000.000 €

3.000.000 €

2.000.000 €

1.000.000 €

0 €

Fortschritt des Projekts ABCIn

halt

und

Um

fang

(Pu

nkte

)Ausgaben

AusgabenPrognostizierter

FortschrittErstellter Inhalt

und UmfangPrognostizierte

Ausgaben

Ist-Kosten

Geplanter Wert

Fertigstellungswert

Terminplanabweichung

Kostenabweichung

PROGNOSEN

FAKTURIERUNG

VERTRÄGE

UMSATZ

LAGER

KONFIGURATION

BERICHTWESEN

SAP-SCHNITTSTELLE

CPI =FertigstellungswertIst-Kosten

SPI =Fertiggestellte FeaturesGeplante Features

LEG

END

E

70 Abschnitt 5

Ein kumulatives Flussdiagramm, das in Abb 5-7 zu sehen ist, zeigt die laufende Arbeit im Gesamtüberblick. Wenn ein Team viele Storys hat, die auf die Testphase warten, schwillt der Testbereich an. Die Anhäufung von Arbeit ist auf einen Blick erkennbar.

Teams haben Schwierigkeiten mit angehäufter Arbeit: das Team hat laufende statt fertiggestellter Arbeit. Wenn Teams eine große Menge laufender Arbeit haben, verzögert sich die Feature-Auslieferung insgesamt. Je länger ein Team zur Lieferung braucht, desto mehr Druck entsteht für das Team, weil noch mehr Features im selben Zeitraum anstehen.

Abb. 5-7. Kumulatives Flussdiagramm fertiger Features

Dieser kumulative Fluss wird an die Projektaufgabentafel oder das Kanban-Board angepasst.

20

18

16

14

12

10

8

6

4

2

0

Feat

ures

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Warteschlange Analyse Entwicklung Test Einsatz

Monate

LEG

END

E

Reaktionszeit

Vorlaufzeit

Fertigstellungszeit

Arbeitspakete in W

arteschlange

Verbleibende Arbeit

FertiggestellteArbeit

71

6ÜBERLEGUNGEN ZUR PROJEKTAGILITÄT IN ORGANISATIONEN

Jedes Projekt existiert in einem organisatorischen Zusammenhang. Kulturen, Strukturen und Richtlinien können sowohl die Richtung als auch das Ergebnis eines Projekts beeinflussen. Diese Dynamik kann für Projektleiter zur Herausforderung werden.

Projektleitern sind einerseits oft die Hände gebunden, wenn sie die Dynamik der Organisation nach ihren Bedürfnissen ändern wollen, andererseits erwartet man von ihnen, dass sie mit dieser Dynamik umzugehen wissen.

In diesem Abschnitt wird betrachtet, wie die Organisation − und in gewissen Umständen auch der Projektzusammenhang − Einfluss auf Projekte nehmen. Führungskräfte können Optionen für Änderungen prüfen, um den Erfolg des Projekts zu steigern.

6.1 VERÄNDERUNGSMANAGEMENT

Veränderungsmanagement behandelt die Fähigkeiten und Methoden zur Beeinflussung von Änderungen zur Unterstützung der Agilität.

Die PMI-Publikation Managing Change in Organizations: A Practice Guide [2] beschreibt einen umfassenden und ganzheitlichen Ansatz zur erfolgreichen Einführung bedeutsamer Änderungen. Empfohlen werden unter anderem:

uu Modelle zur Beschreibung der Änderungsdynamik

uu Regelwerk zur Herbeiführung der Änderung sowie

uu Anwendung der Veränderungsmanagementpraktiken auf Projekt-, Programm- und Portfolioebene.

Abschnitte 6.1.1 und 6.1.2 untersuchen die spezifischen Überlegungen des Veränderungsmanagements im Zusammenhang mit Agile.

Abb. 6-1 zeigt die Beziehungen zwischen diesen beiden Themen.

Die Agilität eines Projekts wird effektiver und nachhaltiger umgesetzt, wenn die Organisation sich anpasst, um es zu unterstützen.

72 Abschnitt 6

Abb. 6-1. Die Beziehung zwischen Veränderungsmanagement und agilen Ansätzen

Überlegungenzur Agilität

Veränderungs-management

Im Praxisleitfaden Agilitätbeschriebene Konzepte

InManaging Change in Organizations:

A Practice Guidebeschriebene Konzepte

73

6.1.1 TRIEBKRÄFTE FÜR VERÄNDERUNGSMANAGEMENT

Bei allen Projekten geht es um Veränderungen. Es gibt jedoch zwei maßgebliche Faktoren, die den Einsatz von Veränderungsmanagementpraktiken in einem agilen Zusammenhang zusätzlich sinnvoll machen:

uu Änderungen im Zusammenhang mit schnellerer Lieferung. Agile Ansätze legen den Akzent auf die frühzeitige und häufige Lieferung von Projektergebnissen. Allerdings kann es sein, dass die Empfängerorganisation nicht ganz darauf vorbereitet ist, diese Ergebnisse in diesem höheren Tempo aufzunehmen. Eine beschleunigte Lieferung wird die Fähigkeit der Organisation testen, diese Lieferung auch zu verarbeiten. Es reicht nicht, die Neuerungen eines Projekts erfolgreich zu identifizieren und zu liefern. Wenn die Organisation sich dem Ergebnis des Projekts widersetzt, wird die angestrebte Investitionsrendite verzögert. Die Annahme von und Anpassung an Projektergebnisse aufseiten des Kunden tritt in einer agilen Umgebung sogar noch stärker in den Vordergrund.

uu Änderungen bei agilen Ansätzen. Organisationen, die gerade erst mit agilen Ansätzen beginnen, erfahren auch selbst einen hohen Grad an Änderung. Mit engerer Zusammenarbeit können häufigere Übergaben zwischen Teams, Abteilungen oder Lieferanten notwendig werden. Die Zerlegung der Arbeit in iterative Prototypen bedeutet Nacharbeit, die negativ gesehen werden könnte. Führungskräfte sollten eventuell mit Methoden des Veränderungsmanagements die Hürden angehen, die bei der Umstellung auf agile Ansätze entstehen.

6.1.2 ÄNDERUNGSBEREITSCHAFT

Organisationen, die mit dem Gebrauch agiler Ansätze beginnen, sollten die Kompatibilität dieser Methoden mit ihren gegenwärtigen Ansätzen verstehen. Manche Organisationen verfügen über Eigenschaften, die agile Prinzipien der abteilungsübergreifenden Zusammenarbeit, des kontinuierlichen Lernens sowie sich entwickelnde interne Prozesse besser unterstützen. Beispiele für diese änderungsfreundlichen Eigenschaften sind:

uu Änderungsbereitschaft aufseiten der Unternehmensleitung

uu Bereitschaft der Organisation, die Art und Weise, wie Mitarbeiter betrachtet, beurteilt und bewertet werden, zu ändern

uu Zentralisierung oder Dezentralisierung der Funktionen Projekt-, Programm- und Portfoliomanagement

uu Ausrichtung auf kurzfristige Budgetierung und Messwerte statt langfristige Ziele und

uu Erfahrung und Kompetenzen im Talent- und Mitarbeitermanagement.

74 Abschnitt 6

Umgekehrt gibt es etablierte Eigenschaften, die sich auf dem Weg zu einer agilen Organisation als Hindernisse erweisen. Beispiele hierfür sind:

uu Die Arbeit wird in Abteilungssilos zerlegt, was zu Abhängigkeiten führt, die eine schnellere Lieferung behindern, anstatt mit Beratung durch Kompetenzzentren funktionsübergreifende Teams zu bilden.

uu Beschaffungsstrategien basieren auf kurzfristigen Preisgestaltungsstrategien statt auf langfristigen Kompetenzen.

uu Führungspersonen werden für lokale Effizienz statt für den durchgängigen Fluss der Projektlieferung oder die Optimierung des Ganzen (in Bezug auf die Organisation) belohnt.

uu Mitarbeiter leisten spezifische Beiträge mit begrenzten Mitteln oder wenig Anreizen zum Ausbau ihrer Fähigkeiten, statt dass „T-shaped“-Spezialisten aufgebaut werden.

uu Dezentralisierte Portfolios ziehen Mitarbeiter auf zu viele Projekte gleichzeitig, statt dass sie sich jeweils auf ein Projekt konzentrieren können.

Der Grad, zu dem eine Organisation zur Prüfung und Änderung dieser Praktiken bereit ist, bestimmt, wie schnell und wirksam agile Ansätze übernommen werden können. Projektleiter können, in Reaktion auf diese Agilitätshindernisse in der Organisation, verschiedene Ansätze ausprobieren, um die kulturelle Kompatibilität hinsichtlich der folgenden Eigenschaften schneller herbeizuführen:

uu Sichtbare und aktive Unterstützung durch die Unternehmensführung

uu Veränderungsmanagementpraktiken, einschließlich Kommunikation und Coaching

uu Schrittweise Temposteigerung bei der Übernahme agiler Praktiken Projekt für Projekt

uu Stufenweise Einführung agiler Praktiken in das Team

uu Vorbildhafte Führung durch Einsatz agiler Methoden und Praktiken, wo dies möglich ist.

75

6.2 ORGANISATIONSKULTUR

Die Kultur einer Organisation ist ihre DNA − ihre Kernidentität. Kultur wird stets Einfluss auf den Einsatz agiler Ansätze nehmen. Organisationskultur ist auf einem Kontinuum angesiedelt und reicht von stark plangetriebenen Organisationen bis zu schlanken Startups, wo alles ein Experiment ist. Obwohl agile Ansätze gut zur schlanken Startup-Kultur passen, können auch stark plangetriebene Organisationen empirische Messungen, kleine Experimente und Lernen fördern und sich damit der Agilität annähern.

6.2.1 SCHAFFUNG EINER SICHEREN UMGEBUNG

Die Kultur einer Organisation zu ändern ist schwierig. Deshalb besteht in einer Organisation, die eine neue Methode ausprobieren möchte, die wichtigste kulturelle Norm in der Schaffung einer sicheren Arbeitsumgebung.

Nur in einer sicheren, von Ehrlichkeit und Transparenz geprägten Umgebung können Teammitglieder wie Führungskräfte wirklich über ihre Erfolge nachdenken und sicherstellen, dass ihre Projekte weiter Fortschritte machen, oder aber die aus gescheiterten Projekten gewonnenen Erfahrungen anwenden, um nicht wieder in die alten Muster zurückzufallen.

6.2.2 BEWERTUNG DER KULTUR

Jedes Projekt steht in einem Spannungsfeld mit konkurrierenden Zielen. Wie kann das Team ohne Qualitätseinbußen schnell arbeiten? Wie kann das Team Flexibilität wahren und gleichzeitig einen festen Termin erfüllen? Und am wichtigsten: Wie wird das Team die Anforderungen des Kunden zufriedenstellend erfüllen?

Projektleiter mögen das Gefühl haben, dass ihre Aufgabe in der Erfüllung aller Erwartungen aller Stakeholder liegt; wenn sie dann jedoch eine Wahl treffen müssen, folgen die Prioritäten oft der Kultur und den Anforderungen des Geschäftsumfelds der Organisation. Zum Beispiel legt ein Mobilfunkprojekt mehr Wert auf eine höhere Umsetzungsgeschwindigkeit, während ein staatliches Programm mehr auf allgemeine Anwendbarkeit und Stabilität ausgelegt ist.

„Kultur isst Strategie zum Frühstück“ − Peter Drucker

Dieser Satz betont die Bedeutung, die dem Engagement und der Leidenschaft der Menschen für eine Sache zukommt. Unabhängig von einer Strategie oder einem Plan, die mit dem Team umgesetzt werden soll, hängt der Erfolg von den Leuten ab, die diesen Plan implementieren. Wenn die Mitarbeiter, die die Strategie vorantreiben sollen, nicht engagiert hinter der Änderung stehen oder − schlimmer noch − dem Job oder der Organisation gegenüber gleichgültig sind, bestehen kaum Chancen auf die Umsetzung von Änderungen.

76 Abschnitt 6

Um diese Dynamiken zu handhaben, sollten Projektleiter sich die Zeit nehmen, um zu beurteilen, worauf der Schwerpunkt in der Organisation am häufigsten gelegt wird. Abb. 6-2 veranschaulicht, wie diese Beurteilung aussehen könnte. In diesem Beispiel beginnt ein Projektleiter ein Gespräch mit Stakeholdern, Teammitgliedern und dem oberen Management über Prioritäten der Organisation. Diese Prioritäten werden dann als Positionen auf einer Skala zwischen zwei Endpunkten festgehalten. Anhand dieser Ergebnisse lassen sich anschließend agile Methoden finden, die diesen Prioritäten am besten entsprechen.

Abb. 6-2. Beispiel zur Beurteilung von Organisationskultur

Es gibt mehrere Modelle zur Beurteilung dieser Dynamik; letzten Endes ist aber das verwendete Modell bzw. die Methode nicht so wichtig. Entscheidender ist, dass Projektleiter sich die Mühe machen, die Kräfte zu verstehen, die ihren Kontext prägen. Sind die Organisation und die Anforderungen der Branche, die eine Organisation erfüllen muss, verstanden, können die richtigen Gespräche, die richtigen Kompromisse und vor allem die richtigen Methoden gewählt werden.

Quantität Qualität

{Andere Faktoren}

Schnelligkeit Stabilität

Ausführung

Flexibilität Vorhersehbarkeit

(Er-)Forschung

77

6.3 BESCHAFFUNG UND VERTRÄGE

Wie weiter oben in diesem Leitfaden erwähnt, wird im Agilen Manifest die Zusammenarbeit mit dem Kunden höher bewertet als die Vertragsverhandlung. Das Scheitern vieler Projekte liegt im Zerfall der Beziehung zwischen Kunde und Lieferant begründet. Projekte unterliegen größerem Risiko, wenn die Vertragsparteien die Perspektive „Gewinner gegen Verlierer“ einnehmen. Ein kooperativer Ansatz dagegen verfolgt eine Beziehung mit geteiltem Risiko und geteiltem Lohn, bei der alle Seiten gewinnen. Manche Methoden der Vertragsverhandlung können diese Dynamik formalisieren, wie etwa folgende:

uu Mehrstufige Struktur. Statt eine gesamte Vertragsbeziehung in einem einzigen Dokument formal festzulegen, können die Projektparteien mehr Flexibilität erreichen, wenn sie unterschiedliche Aspekte in unterschiedlichen Dokumenten beschreiben. Überwiegend unveränderliche Elemente (z. B. Garantieleistungen, Schlichtung) können in einem Hauptvertrag festgelegt werden. Andere Posten, die Veränderungen unterliegen (z. B. Preise für Dienstleistungen, Produktbeschreibungen), werden in einem Anhang mit Dienstleistungen aufgeführt. Der Anhang kann dann auf den Rahmenvertrag für die Dienstleistung Bezug nehmen. Schließlich können Elemente mit höherer Dynamik, wie Inhalt und Umfang, Terminplan und Budget, in einer schlanken Leistungsbeschreibung formalisiert werden. Die Auslagerung der sich häufiger ändernden Elemente eines Vertrags in einem Einzeldokument vereinfacht Anpassungen und schafft Flexibilität.

uu Betonung auf gelieferten Wert. Viele Lieferantenbeziehungen unterliegen festen Meilensteinen oder definierten Phasenabschlüssen, die sich auf Zwischenlieferungen statt auf den vollständigen Liefergegenstand von inkrementellem, geschäftlichem Wert konzentrieren. Oftmals wird dadurch der Einsatz von Feedback zur Verbesserung des Produkts beschränkt. Stattdessen können Meilensteine und Zahlungskonditionen auf der Grundlage wertgesteuerter Liefergegenstände strukturiert werden, um dem Projekt zu mehr Agilität zu verhelfen.

uu Inkrementeller Festpreis. Statt den Inhalt und Umfang und das Budget eines gesamten Projekts in einer einzigen Vereinbarung festzuschreiben, kann das Projekt den Inhalt und Umfang in Miniliefergegenstände mit Festpreis zerlegen, so etwa User Stories. Der Kunde erhält damit mehr Kontrolle darüber, wie das Geld ausgegeben wird. Für den Lieferanten limitiert es das finanzizelle Risiko, sich mit der Verpflichtung zu einem einzelnen Liefergegenstand oder Feature zu übernehmen.

TIP

P

Kultur gegen Struktur

Manche Leute bestehen auf der Aufstellung neuer Organisationsstrukturen, bevor ein kultureller Wandel stattfinden kann. Andere wieder behaupten das Gegenteil: Diese neuen Organisationsstrukturen seien nur oberflächliche Anpassungen, bis die kollektive Kultur sich in eine bedeutsame Richtung bewegt. In Wirklichkeit kann das eine nicht ohne das andere vonstatten gehen. Projektleiter, die Agilität erreichen wollen, sollten den gegenwärtigen und zukünftigen Zustand beider Aspekte in ihrer Organisation berücksichtigen.

78 Abschnitt 6

uu Obergrenzen für Zeit und Material. Ein herkömmlicher Zeit- und Materialansatz birgt für den Kunden unerwünschte Risiken. Eine Alternative hierzu ist die Begrenzung des Gesamtbudgets auf einen festen Betrag. Damit kann der Kunde neue Ideen und Innovationen in das Projekt einbringen, die in der ursprünglichen Planung nicht vorgesehen waren. Wenn Kunden neue Ideen einbringen wollen, müssen sie dies innerhalb eines bestimmten Rahmens tun und die ursprünglichen Arbeitspakete durch die neuen ersetzen. Wenn die geleisteten Arbeitsstunden sich dem vertraglichen Maximum nähern, muss die Verwendung der verbleibenden Arbeitsstunden sorgfältiger geplant werden. Zusätzliche Arbeitsstunden für den Eventualfall können in das Maximalbudget eingeplant werden, falls dies als hilfreich erachtet wird.

uu Abstufungen für Zeit und Material. Eine weitere Alternative ist der Ansatz des geteilten Finanzrisikos. In der Agilität sind Qualitätskriterien Fertigstellungskriterien. Deshalb kann der Lieferant durch einen höheren Stundensatz belohnt werden, wenn die Lieferung vor dem vertraglich festgelegten Termin liegt. Im umgekehrten Fall würde der Lieferant bei verspäteter Lieferung mit Abzügen bestraft.

uu Vorzeitige Kündigung. Wenn ein agiler Lieferant bereits bei Fertigstellung der Hälfte von Inhalt und Umfang ausreichend Wert liefert, sollte der Kunde nicht gezwungen sein, die verbleibende Hälfte zu bezahlen, wenn er sie nicht mehr braucht. Stattdessen kann ein Vertrag dem Kunden eine vorzeitige Beendigung des Projekts gegen die Zahlung einer Ablösesumme anbieten. Der Kunde begrenzt sein Budgetrisiko und der Lieferant erhält eine Vergütung für Dienste, die nicht mehr benötigt werden.

uu Dynamischer Inhalt und Umfang. Bei Verträgen mit festem Budget kann der Lieferant seinem Kunden die Option auf Änderungen von Projektinhalt und -umfang an bestimmten Stellen im Projektverlauf anbieten. Der Kunde kann den Featureumfang an die Kapazität des Lieferanten anpassen und damit Innovationschancen ausnutzen. Gleichzeitig begrenzt dies beim Lieferanten die Gefahr, sich zu übernehmen.

uu Stärkung des Teams. Der wohl kooperativste Ansatz zur Auftragsvergabe besteht darin, die Dienste des Lieferanten direkt in die Kundenorganisation einzubetten. Die Finanzierung von Teams statt eines spezifischen Inhalts und Umfangs wahrt die strategische Entscheidungsfreiheit des Kunden in Bezug darauf, welche Arbeiten tatsächlich erledigt werden sollten.

79

uu Bevorzugung von Komplettanbietern. Zur Streuung von Risiken können Kunden nach einer Mehrlieferantenstrategie verfahren. Hier besteht allerdings die Versuchung, die Arbeiten so zu vergeben, dass jeder Lieferant nur eine Sache erledigt. Dadurch entsteht ein Geflecht aus Abhängigkeiten, bevor eine verwendbare Dienstleistung oder ein Produkt überhaupt erst entstehen kann. Stattdessen empfiehlt es sich, hauptsächlich Aufträge zu vergeben, die einen vollständigen Wert liefern (etwa vollständige unabhängige Leistungsumfänge, sogenannte Feature-Sets).

Es ist möglich, agile Verträge aufzusetzen. Agilität baut auf der Synergie von Kooperation und Vertrauen auf. Der Lieferant kann dazu beitragen, indem er Wert früh und oft liefert. Der Kunde kann seinen Beitrag durch zeitnahes Feedback leisten.

6.4 GESCHÄFTSPRAKTIKEN

Die Bereitschaft und Fähigkeit, bei Bedarf innerhalb einer Organisation neue Kompetenzen zu schaffen, ist ein Zeichen für die Agilität einer Organisation. Dabei muss es sich nicht immer um umwälzende Änderungen handeln und sie würden sich weniger störend auswirken, wenn die Organisation sich auf Agilität und die gelieferten Ergebnisse konzentriert. Transparenz und offene Kooperation sind unabdingbar.

Bei der Lieferung von Werten können funktionsübergreifende Teams und Einzelpersonen auf Probleme mit den einzelnen Support-Funktionen in der Organisation stoßen.

Liefert ein Team regelmäßig Wert, haben die Finanzabteilungen beispielsweise die Chance, das Produkt anders zu kapitalisieren. Wenn das Team Verträge mit anderen Organisationen hat, müssen eventuell die Beschaffungsabteilungen diese Verträge abändern, um es diesen anderen Organisationen zu ermöglichen, häufig Wert zu liefern und mit dem Team synchron zu laufen.

Sobald die Teams zusammenhängend und kooperativ arbeiten, werden sie interne Managementpraktiken hinterfragen. Das Personalwesen stellt womöglich fest, dass Anreize für Einzelpersonen weniger sinnvoll sind. Weiterhin haben Manager möglicherweise Schwierigkeiten mit der Leistungsbeurteilung von sich selbst organisierenden Mitarbeitern. In jedem Fall lässt sich dadurch ermitteln, inwieweit bestehende Praktiken agile Arbeitsweisen unterstützen.

Auf ihrem Weg zu mehr Agilität wird es Organisationen offensichtlich werden, in welchen weiteren Geschäftsbereichen Änderungen an wechselseitigen Beziehungen und der Erledigung von Aufgaben vorgenommen werden müssen. Die Änderungen, die anderen Bereichen der Organisation von Nutzen waren, sollten jetzt aufgegriffen werden, damit die gesamte Organisation effektiver werden kann.

80 Abschnitt 6

6.5 KOORDINATION UND ABHÄNGIGKEITEN MEHRERER TEAMS (SKALIEREN)

Bei vielen Projekten ergeben sich auch dann Abhängigkeiten, wenn sie nicht innerhalb ein und desselben Programms verwaltet werden. Aus diesem Grund muss die Funktion der Agilität innerhalb eines bestimmten Programm- und Portfoliomanagementkontexts verstanden werden.

6.5.1 REGELWERKE

Vorgaben der am weitesten verbreiteten agilen Methoden, wie Scrum und eXtreme Programming, konzentrieren sich auf die Vorgänge eines einzigen, kleinen, in der Regel örtlich zusammensitzenden, funktionsübergreifenden Teams. Das ist bei Vorhaben, für die ein einzelnes Team ausreicht, sehr nützlich. Bei Initiativen allerdings, die die Zusammenarbeit mehrerer agiler Teams in einem Programm oder Portfolio erfordern, kann dies zu unzureichender Steuerung führen.

Um genau diesen Umständen Rechnung zu tragen, ist eine Reihe von Regelwerken (wie das Scaled Agile Framework, Large Scale Scrum und Disciplined Agile) und Ansätzen (z. B. Scrum of Scrums) entstanden. Weitere Einzelheiten hierzu finden sich in Anlage A3.

6.5.2 ÜBERLEGUNGEN

Es gibt mehr als eine Möglichkeit zur Skalierung der Arbeit. Das Team muss eventuell die Arbeit mehrerer agiler Projekte in ein einzelnes agiles Programm skalieren. Oder die Organisation entwirft eine Struktur, die agile Ansätze über das gesamte Portfolio hinweg unterstützt.

So ist es zum Beispiel hilfreich, klein anzufangen und so schnell wie möglich herauszufinden, was im Kontext der Organisation gut funktioniert. Teams können erfolgreiche Ergebnisse auch dann erzielen, wenn nicht alles vollständig in einen agilen Ansatz umgewandelt wurde.

Unabhängig vom Ansatz ist das funktionierende agile Team ein entscheidender Erfolgsfaktor. Wenn ein agiler Ansatz für ein einzelnes Team keinen Erfolg hat, sollte nicht versucht werden, ihn zu skalieren und auf breiterer Ebene einzusetzen; stattdessen sollten die Hürden innerhalb der Organisation angegangen werden, die die Teams von einer agilen Arbeitsweise abhalten.

Das Ziel groß angelegter agiler Projekte liegt darin, die Anstrengungen verschiedener Teams so zu koordinieren, dass für den Kunden Wert entsteht. Es gibt mehr als einen Weg, das zu tun. Teams können dazu ein formelles Regelwerk einsetzen oder mit agiler Denkweise bestehende Praktiken des Programmmanagements anpassen.

81

6.6 AGILITÄT UND DAS PROJEKTMANAGEMENTBÜRO

Das Projektmanagementbüro (Project Management Office, PMO) dient dazu, dem geschäftlichen Wert einen Weg durch die Organisation zu bahnen. Projekten beim Erreichen ihrer Ziele zu helfen kann einer dieser Wege sein. Ein anderer Weg kann die Durchführung oder Organisation von Schulungen für Teams sowie das Unterstützen von Projekten durch das PMO sein. Manchmal berät das PMO das Management bezüglich des relativen geschäftlichen Wertes eines bestimmten Projekts oder einer Reihe von Projekten.

Weil Agilität zu kulturellem Wandel führt, muss die Organisation im Lauf der Zeit eventuell auch sich selbst und das PMO verändern. Manager entscheiden zum Beispiel, welche Projekte wann finanziert werden sollen, und Teams entscheiden, was sie an Schulung oder Beratung brauchen.

6.6.1 EIN AGILES PMO IST WERTGESTEUERT

Jedes Projekt sollte den richtigen Wert zur richtigen Zeit an die richtige Zielgruppe liefern. Ziel des PMO ist es, dieses Ziel herbeizuführen und zu ermöglichen. Ein agilitätsbasierter PMO-Ansatz beruht auf einer Denkweise, welche die Zusammenarbeit mit dem Kunden einbezieht, und existiert in allen PMO-Programmen. In vielen Fällen bedeutet dies, dass das PMO wie eine Beraterfirma arbeitet und seine Arbeit an die spezifischen, von einem bestimmten Projekt gewünschten Bedürfnisse anpasst. Manche Projekte brauchen Werkzeuge und Vorlagen, andere wiederum profitieren vom Coaching der Führungskräfte. Das PMO sollte versuchen, das Benötigte zu liefern, und am Puls des Kunden zu sein; nur so kann sichergestellt werden, dass es die Bedürfnisse der Kunden kennt und sich darauf ausrichten kann. Dieser Ansatz konzentriert sich auf die Vorgänge des PMO, die für die von ihm unterstützen Projekte als besonders wertvoll gelten.

6.6.2 EIN AGILES PMO SUCHT SICH DIE RICHTIGEN MITGLIEDER

Ein PMO kann zur Fortschrittsbeschleunigung bei einem wertbasierten Auftrag versucht sein, bestimmte Lösungen oder Ansätze zu erzwingen, zum Beispiel dieselbe Vorgehensweise für alle, um ein paar schnelle Erfolge vorzuweisen. Eine überlegtere Perspektive berücksichtigt jedoch auch den Wunsch nach Mitarbeiterengagement. Dies wird erreicht, indem man nur diejenigen einlädt, die an einem positiven Mitwirken innerhalb des PMO interessiert sind. Stärkeres Engagement mit PMO-Praktiken führt zu höherer Nachhaltigkeit. Wenn das PMO seinen Kunden Wert liefert, steigt die Wahrscheinlichkeit, dass Kunden seine Dienste anfordern und seine Praktiken übernehmen.

82 Abschnitt 6

6.6.3 EIN AGILES PMO IST MULTIDISZIPLINÄR

Zur Unterstützung projektspezifischer Bedürfnisse muss das PMO neben dem eigentlichen Projektmanagement noch verschiedene andere Kompetenzen beherrschen, weil verschiedene Projekte unterschiedliche Fähigkeiten erfordern. Ein Projekt verlangt zum Beispiel, dass die Organisation Personalplanungsherausforderungen angeht, während ein anderes Projekt Veränderungsmanagementverfahren für die Einbindung der Stakeholder benötigt oder einzigartige Geschäftsmodelle zur Unterstützung der Kundenziele braucht.

Manche Organisationen entwickeln ihre PMOs in agile Kompetenzzentren, die folgende Dienste bieten:

uu Ausarbeitung und Implementierung von Standards. Erstellen von Vorlagen für User Stories, Test Cases, kumulative Flussdiagramme usw. Bereitstellung agiler Werkzeuge und Schulung unterstützender Gruppen über iterative Entwicklungskonzepte.

uu Weiterentwicklung von Personal durch Schulung und Betreuung. Koordinierung agiler Schulungen, Coaching und Betreuung von Mitarbeitern bei der Umstellung auf eine agile Denkweise und Steigerung ihrer Fähigkeiten. Ermutigung und Unterstützung der Mitarbeiter für die Teilnahme an Veranstaltungen zur Agilität vor Ort.

uu Multiprojektmanagement. Koordination zwischen agilen Teams mittels Kommunikation zwischen den Projekten. Förderung des Austauschs von Erkenntnissen zu Fortschritt, Problemen und Retrospektiven sowie Verbesserungsversuchen. Hilfe beim Managen wichtiger Kundenfreigaben auf Programmebene und Investmentfragen auf Portfolioebene mithilfe des geeigneten Regelwerks.

uu Wissensaufbau der Organisation. Sammlung von Velocityprofilen der Projekte sowie die Erfassung, Speicherung und Indizierung dieser Erkenntnisse aus Retrospektiven.

uu Umgang mit Stakeholdern. Anbieten von Schulungen für Produktverantwortliche, Anleitung zu Akzeptanztests und zur Evaluation von Systemen sowie des Feedbacks dazu. Hervorheben der Bedeutung von Fachexperten für Projekte.

uu Anwerbung, Auswahl und Bewertung von Teamleitern. Erarbeitung von Leitlinien für Interviews mit Agilisten.

uu Ausführung spezieller Projektaufgaben. Schulung und Vermittlung von Moderatoren für Retrospektiven, von agilen Problemlösern, sowie von Mentoren und Trainern.

83

6.7 STRUKTUR DER ORGANISATION

Die Struktur einer Organisation hat starken Einfluss darauf, wie gut sie sich auf neue Informationen oder sich verändernde Markterfordernisse einstellen kann. Eine Aufstellung der wichtigsten Eigenschaften:

uu Örtlichkeit. Örtlich verteilte und verstreute Projektorganisationen haben bei ihrer Projektarbeit mit mehreren Herausforderungen zu kämpfen. Projektleiter und regionale Manager haben eventuell andere oder sogar konkurrierende Ziele. Darüber hinaus können kulturelle Unterschiede, Sprachbarrieren und geringere Sichtbarkeit die Produktivität dämpfen. Glücklicherweise lassen sich engere Zusammenarbeit und mehr Vertrauen mithilfe von agilen Ansätzen fördern. Projektleiter sollten in diesen Situationen den Dialog auf Team- und Führungsebene fördern, um die Methoden an den Kontext anzupassen und die Erwartungen an den dafür notwendigen Aufwand zu managen.

uu Funktionale Strukturen. Die Strukturen mancher Organisationen sind auf einem Spektrum angesiedelt, das von stark projektbezogen über Matrix-Struktur bis zu stark funktional reicht. Projekte mit stark funktionalen Strukturen stoßen eventuell auf allgemeinen Widerstand gegenüber organisationsübergreifender Zusammenarbeit.

uu Größe des Projektliefergegenstands. Mit der Verkleinerung von Projektliefergegenständen fördert man häufigere Übergaben über verschiedene Abteilungen hinweg und damit häufigeren Austausch und einen schnelleren Wertfluss durch die Organisation.

uu Zuweisung von Mitarbeitern an Projekte. Ein weiterer Ansatz besteht darin, aus jeder Abteilung jeweils eine Person vorübergehend, aber dafür vollständig dem Projekt mit der höchsten Priorität zuzuweisen.

uu Beschaffungslastige Organisationen. Manche Organisationen entscheiden sich dafür, Projekte hauptsächlich durch externe Anbieter implementieren zu lassen. Obwohl die Projektziele klar sein können, müssen Anbieter ihre eigene finanzielle Tragfähigkeit im Auge behalten. Darüber hinaus verbleibt das entsprechende Projektwissen bei den Anbietern, wenn diese ihre Pflichten erfüllt und den Auftrag erledigt haben. Dadurch werden die internen Kompetenzen eingeschränkt, die für nachhaltige Flexibilität und Geschwindigkeit notwendig sind. Agile Methoden wie Retrospektiven und die Nachverfolgung von möglichem Verbesserungsbedarf, solange der Anbieter noch eingebunden ist, können den Verlust von Projektwissen abmildern helfen.

84 Abschnitt 6

6.8 WEITERENTWICKLUNG DER ORGANISATION

Wenn ein bestimmter Problembereich angegangen oder ein neuer hybrider oder agiler Ansatz implementiert wird, empfiehlt sich eine inkrementelle Vorgehensweise. Eine übliche Praxis besteht darin, den Änderungsprozess als agiles Projekt mit seinem eigenen Änderungs-Backlog zu behandeln, der vom Team nach empfundenem Wert oder anderen Überlegungen eingeführt und priorisiert werden kann. Jede dieser Änderungen kann als Experiment behandelt werden, das über kurze Zeit getestet wird, um dessen Eignung in unveränderter Form oder die Notwendigkeit weiterer Feinabstimmungen/Überlegungen festzustellen.

Mit Kanban-Boards lässt sich der Fortschritt festhalten, indem die bereits verwendeten neuen Ansätze als „fertig“ (ready), die Ansätze in der Versuchsphase als „in Arbeit“ (in progress) und die noch nicht eingeführten Ansätze als „muss noch gemacht werden“ (to do) angezeigt werden. Siehe Abb. 6-3 mit einem initialen Board und gegliederten Backlog. Abb. 6-4 zeigt ein Beispiel für mögliche Arbeitsfortschritte auf einem Board.

85

Priorisiertes Backlog

Analyseder

Maßnahmen

Erledigungder

Maßnahmen

Risiko-managementoder Risiko-minderung

Entscheidung nach Aktion erforderlich

Im Wartezu-stand:

Festgefahrene Posten

Fertig

In Arbeit

Änderung1

Änderung2

Änderung3

Änderung4

Änderung5

Änderung6

Änderung7

Änderung8

Änderung9

Änderung10

Abb. 6-3. Initiale Reihenfolge eines Änderungs-Backlog

86 Abschnitt 6

Abb. 6-4. Verwendung von Backlogs und Kanban-Boards zur Organisation und Nachverfolgung von Änderungsarbeit

Mithilfe dieser Werkzeuge zur Organisation und Steuerung der Änderungsimplementierung zeigt sich der Fortschritt und ein Modell der Ansätze, die implementiert werden. Werden diese Änderungen auf transparente und ansprechende Weise eingeführt, steigen ihre Chancen auf Erfolg.

Priorisiertes Backlog

Analyseder

Maßnahmen

Erledigungder

Maßnahmen

Risikomanage-ment oder

Risiko-minderung

Entscheidung nach Aktion erforderlich

Im Wartezu-stand:

Festgefahrene Posten

Fertig

In Arbeit

Änderung1

Änderung2

Änderung3

Änderung4

Änderung5

Änderung6

Änderung7

Änderung8

Änderung9

Änderung10

87

7AUFRUF ZUM HANDELN

Die Übernahme von Agilität und den zugehörigen Projektmanagementansätzen hat seit der Erstveröffentlichung des Agilen Manifests 2001 stark zugenommen. Die Übernahme und der Wunsch, mit einer agilen Denkweise zu arbeiten, ist nicht mehr nur auf Organisationen mit einer bestimmten Größe oder rein auf IT spezialisierte Organisationen beschränkt. Diese Denkweise gilt universell und die Ansätze sind in vielen Umgebungen erfolgreich.

Heute ist der Wunsch danach, „agil zu sein“, höher denn je. Die Debatte über den besten Weg zur Agilität hält an und sorgt für die anhaltende Innovation. Ein Aspekt bleibt jedoch unverändert: Inspektion, Anpassung und Transparenz sind für die erfolgreiche Lieferung von Wert entscheidend.

In diesem Praxisleitfaden sehen Sie vielleicht nicht alles, was Sie erwartet haben. Unser Kernteam ist sich bewusst, dass Sie manche Elemente oder Ansätze, die wir vorstellen, mit aller Vehemenz ablehnen. Wir appellieren an Ihre Leidenschaft, das Gespräch weiterzuführen und die nächste Iteration dieses Praxisleitfadens zu verbessern. Das ist Ihre Reise: Lernen, experimentieren, Feedback sammeln und wieder experimentieren. Helfen Sie uns dann bei unserer Retrospektive; geben Sie uns Feedback zur Anleitung und leisten Sie Beiträge zu künftigen Ausgaben dieses Praxisleitfadens. Schließlich ist Inspektion ohne Anpassung vergeudeter Aufwand.

Zu guter Letzt fordern wir Sie auf, sich in den Communities von Projektmanagement und Agilität zu engagieren, um den Diskurs über diese Themen weiter voranzubringen. Wenden Sie sich auf Konferenzen und Tagungen an Vertreter von PMI und Agile Alliance® und suchen Sie das Gespräch mit ihnen. Nutzen Sie Social Media und stellen Sie Ihre Gedanken und Meinungen in einem Blog vor.

Sie können Feedback geben und sich am Gespräch über den Inhalt dieses Praxisleitfadens beteiligen. Besuchen Sie dazu den Blog „Agile in Practice“ auf https://www.projectmanagement.com/blogs/347350/Agile-in-Practice.

89

ANLAGE A1 ZUORDNUNG ZUM PMBOK ® GUIDE

Tabelle A1-1 veranschaulicht die Zuordnung von Projektmanagement-Prozessgruppen zu den im PMBOK® Guide – Sechste Auflage definierten Wissensgebieten.

Diese Anlage beschreibt, wie hybride und agile Ansätze die in den Wissensgebieten des PMBOK® Guide beschriebenen Attribute angehen (siehe Tabelle A1-2). Sie zeigt, was gleich bleibt und was sich eventuell ändert, sowie einige Leitlinien, die man mit Blick auf eine größere Erfolgswahrscheinlichkeit in Betracht ziehen sollte.

90 Anlage A1

Tabelle A1-1. Abbildung von Projektmanagement-Prozessgruppen und Wissensgebieten

4.1 Projektauftrag entwickeln

4.2 Projekt--managementplan entwickeln

4.3 Projektdurchfüh-rung lenken und managen4.4 Projektwissen managen

4.5 Projektarbeit überwachen und steuern4.6 Integrierte Änderungssteue-rung durchführen

4.7 Projekt oder Phase abschließen

Wissensgebiete

Projektmanagement-Prozessgruppen

Planungs-prozessgruppe

Ausführungs-prozessgruppe

Initiierungs-prozessgruppe

Überwachungs- und Steuerungs-prozessgruppe

Abschluss-prozessgruppe

Integrations-management in Projekten

Inhalts- und Umfangs-management in Projekten

Terminplanungs-management in Projekten

Kostenmanage-ment in Projekten

Qualitäts-management in Projekten

Ressourcen-management in Projekten

Kommunika-tionsmanage-ment in Projekten

Risikomanage-ment in Projekten

Beschaffungs-management in Projekten

Management der Projekt-stakeholder

4.

5.

6.

7.

8.

9.

10.

11.

12.

13. 13.1 Stakeholder identi�zieren

13.2 Engagement der Stakeholder planen

13.3 Engagement der Stakeholder managen

13.4 Engagement der Stakeholder überwachen

12.1 Beschaffungs-management planen

12.2 Beschaffungen durchführen

12.3 Beschaffungen steuern

11.1 Risikomanage-ment planen11.2 Risiken identi�zieren11.3 Qualitative Risikoanalyse durchführen11.4 Quantitative Risikoanalyse durchführen11.5 Risikobewälti-gungsmaßnahmen planen

11.6 Risikobewäl-tigungsmaßnah-men umsetzen

11.7 Risiken überwachen

10.1 Kommunika-tionsmanagement planen

10.2 Kommunika-tion managen

10.3 Kommunika-tion überwachen

9.1 Ressourcen-management planen9.2 Ressourcen für Vorgänge schätzen

9.3 Ressourcenbe-schaffung9.4 Team entwickeln9.5 Team managen

9.6 Ressourcen steuern

8.1 Qualitäts-management planen

8.2 Qualität managen

8.3 Qualität lenken

7.1 Kostenmanage-ment planen7.2 Kosten schätzen7.3 Budget festlegen

7.4 Kosten steuern

6.1 Terminmanage-ment planen6.2 Vorgänge de�nieren6.3 Vorgangsfolge festlegen6.4 Vorgangsdauer schätzen6.5 Terminplan entwickeln

6.6 Terminplan steuern

5.1 Inhalts- und Umfangsmanage-ment planen5.2 Anforderungen sammeln5.3 Inhalt und Umfang de�nieren5.4 Projektstruktur-plan erstellen

5.5 Inhalt und Umfang validieren5.6 Inhalt und Umfang steuern

91

Tabelle A1-2. Anwendung von Agilität auf Wissensgebieten des PMBOK® Guide

PMBOK® Guide Wissensgebiet Anwendung in einem agilen Arbeitsprozess

Abschnitt 4Integrationsmanagement in Projekten

Abschnitt 5Inhalts- und Umfangsmanagement in Projekten

Iterative und agile Ansätze fördern die Einbindung von Teammitgliedern als lokale Domänenexperten im Integrationsmanagement. Die Teammitglieder legen fest, wie Pläne und Komponenten integriert werden sollen.

Die Erwartungen des Projektmanagers laut den Abschnitten über die Grundsätzen des Integrationsmanagements im PMBOK® Guide ändern sich in einer adaptiven Umgebung nicht, aber die Steuerung der detaillierten Planung und Lieferung des Produkts wird an das Team delegiert. Im Fokus des Projektmanagers stehen der Aufbau eines kooperativen Umfelds zur Entscheidungs�ndung und sicherzustellen, dass das Team in der Lage ist, auf Änderungen zu reagieren. Dieser kooperative Ansatz kann noch weiter gesteigert werden, wenn die Teammitglieder eine breite Basis an Fähigkeiten statt einer engen Spezialisierung besitzen.

Bei Projekten mit sich entwickelnden Anforderungen, hohem Risiko oder erheblichen Unsicherheiten sind Inhalt und Umfang am Anfang des Projekts oft nicht klar, oder sie entwickeln sich während des Projekts weiter. Bei agilen Methoden wird absichtlich weniger Zeit damit verbracht, Inhalt und Umfang im frühen Stadium des Projekts zu de�nieren und zu vereinbaren, und mehr Zeit damit, den Prozess für die laufende Entdeckung und Verfeinerung festzulegen. In vielen Umgebungen mit neu entstehenden Anforderungen wird festgestellt, dass es häu�g eine Lücke zwischen den tatsächlichen Geschäftsanforderungen und den ursprünglich festgelegten gibt. Daher werden bei agilen Methoden Prototypen und Freigabeversionen bewusst erstellt und geprüft, um die Anforderungen zu verfeinern. Inhalt und Umfang werden aus diesem Grund während des Projekts laufend de�niert und überprüft. In agilen Ansätzen stellen die Anforderungen den Backlog dar.

92 Anlage A1

Tabelle A1-2. Anwendung von Agilität auf Wissensgebieten des PMBOK® Guide (fortges.)

PMBOK® Guide Wissensgebiet Anwendung in einem agilen Arbeitsprozess

Abschnitt 6Terminplanungsmanagement in Projekten

Abschnitt 7Kostenmanagement in Projekten

Adaptive Ansätze bedienen sich kurzer Zyklen zur Aufnahme von Arbeiten, Prüfung der Ergebnisse und passen sich bei Bedarf an. Diese Zyklen geben rasch Feedback zu Ansätzen und zur Eignung der Liefergegenstände und treten in der Regel als iterative Terminplanung und bedarfsorientierte, pull-basierte Terminplanung in Erscheinung, die im Abschnitt über die wichtigsten Trends und neu entstehende Praktiken im Terminplanungsmanagement im PMBOK® Guide besprochen wurden.

In großen Organisationen gibt es oft eine Mischung aus kleinen Projekten und groß angelegten Vorhaben, die langfristige Strategiepläne erfordern, um die Entwicklung dieser Programme anhand von Skalierungsfaktoren zu managen (z. B. Teamgröße, geogra�sche Verteilung, gesetzliche Bestimmungen, Komplexität der Organisation und technische Komplexität). Soll der gesamte Lieferlebenszyklus für größere, unternehmensweite Systeme adressiert werden, muss eventuell ein ganzes Spektrum an Methoden unter Verwendung eines prognostizierenden Ansatzes, adaptiven Ansatzes oder einer Mischform aus beiden übernommen werden Die Organisation muss eventuell Praktiken aus verschiedenen Kernmethoden kombinieren oder eine Methode übernehmen, bei der das bereits geschehen ist, und einige Grundsätze und Praktiken traditionellerer Methoden hinzunehmen.

Die Rolle des Projektmanagers verändert sich nicht dadurch, dass Projekte mit einem prognostizierten Entwicklungslebenszyklus oder in adaptiven Umgebungen gemanagt werden. Für die erfolgreiche Nutzung adaptiver Ansätze muss der Projektmanager jedoch mit den Werkzeugen und Methoden vertraut sein, damit er sie effektiv anwenden kann.

Projekte mit einem hohen Grad an Unsicherheit oder solche, bei denen der Inhalt und Umfang noch nicht vollständig de�niert ist, pro�tieren möglicherweise wegen häu�ger Änderungen nicht von detaillierten Kostenberechnungen. Stattdessen können vereinfachte Schätzmethoden eingesetzt werden, um eine schnelle high-level Prognose für die Arbeitskosten des Projekts zu erstellen, die dann bei Eintreten von Änderungen leicht angepasst werden kann. Detaillierte Schätzungen sind kurzfristigen Planungshorizonten nach dem Just-in-time-Konzept vorbehalten.

In den Fällen, in denen stark veränderliche Projekte auch einem strengen Budget unterliegen, werden Inhalt und Umfang sowie Terminplan häu�ger angepasst, um innerhalb der Kostenvorgaben zu bleiben.

93

Tabelle A1-2. Anwendung von Agilität auf Wissensgebieten des PMBOK® Guide (fortges.)

PMBOK® Guide Wissensgebiet Anwendung in einem agilen Arbeitsprozess

Abschnitt 8Qualitätsmanagement in Projekten

Abschnitt 9Ressourcenmanagement in Projekten

Um Änderungen zu steuern, erfordern agile Methoden häuge Schritte zur Sicherstellung und Überprüfung der Qualität während des gesamten Projekts statt erst gegen Ende des Projekts.

Wiederkehrende Retrospektiven prüfen regelmäßig die Effektivität des Qualitätsprozesses. Sie suchen die grundlegende Ursache von Problemen und schlagen Versuche mit neuen Ansätzen vor, um die Qualität zu verbessern. Nachfolgende Retrospektiven evaluieren sämtliche ausprobierten Prozesse, um festzustellen, ob sie funktionieren und fortgeführt, angepasst oder eingestellt werden sollen.

Um eine häuge, inkrementelle Lieferung zu unterstützen, konzentrieren sich agile Methoden auf kleine Arbeitsbündel und umfassen so viele Elemente des Liefergegenstands des Projekts wie möglich. Verfahren mit kleinen Arbeitsbündeln zielen darauf ab, Unstimmigkeiten und Qualitätsprobleme früher im Problemlebenszyklus zu erkennen, wenn Änderungen weniger teuer sind.

Bei Projekten mit einer hohen Variabilität sind Teamstrukturen von Nutzen, die Fokus und Kollaboration maximieren, darunter sich selbst organisierende Teams mit allgemeinen Spezialisten.

Kollaboration verfolgt den Zweck, die Produktivität zu erhöhen und innovative Problemlösungen zu ermöglichen. Kollaborative Teams können neben anderen Vorteilen beschleunigte Integration einzelner Arbeitsvorgänge erleichtern, Kommunikation verbessern, den Wissensaustausch erhöhen und Flexibilität hinsichtlich Arbeitszuweisungen ermöglichen.

Obwohl die Vorzüge einer Kollaboration sich auch auf andere Projektumgebungen erstrecken, sind kollaborative Teams oft maßgeblich für den Erfolg von Projekten mit einem hohen Maß an Variabilität und schnellen Änderungen, da dort weniger Zeit für eine zentralisierte Arbeitszuweisung und Entscheidungsndung vorhanden ist.

Planung für physische und Humanressourcen ist bei Projekten mit hohen Schwankungen weniger gut vorhersagbar. In diesen Umgebungen sind Vereinbarungen über schnelle Bereitstellung und schlanke Methoden ausschlaggebend dafür, Kosten zu steuern und den Terminplan einzuhalten.

94 Anlage A1

Tabelle A1-2. Anwendung von Agilität auf Wissensgebieten des PMBOK® Guide (fortges.)

PMBOK® Guide Wissensgebiet Anwendung in einem agilen Arbeitsprozess

Abschnitt 10Kommunikationsmanagement in Projekten

Abschnitt 11Risikomanagement in Projekten

In Projektumgebungen, die von Unklarheit und Wechselhaftigkeit gekennzeichnet sind, gibt es das Bedürfnis, sich neu ergebende und sichtbar werdende Einzelheiten häu�ger und schneller mitzuteilen. Dies regt die Verschlankung des Zugangs der Teammitglieder zu Informationen, häu�ge Team-Checkpoints und, soweit möglich, die Zusammenlegung der Arbeitsplätze an.

Darüber hinaus fördern die transparente Veröffentlichung von Projektartefakten und die Durchführung regelmäßiger Stakeholderprüfungen die Kommunikation mit Management und Stakeholdern.

Umgebungen mit hoher Variabilität bergen automatisch mehr Unsicherheit und Risiken. Um diese zu adressieren, nutzen Projekte, die mithilfe adaptiver Ansätze gemanagt werden, häu�ge Prüfungen inkrementeller Arbeitsprodukte und funktionsübergreifende Projektteams, um die Weitergabe von Wissen zu beschleunigen und um sicherzustellen, dass Risiken verstanden und gemanagt werden. Risiken werden berücksichtigt, wenn die Inhalte jeder Iteration ausgewählt werden, und Risiken werden während jeder Iteration außerdem ermittelt, analysiert und gemanagt.

Zusätzlich werden die Anforderungen als lebendes Dokument geführt, das regelmäßig aktualisiert wird, und Arbeiten können während der Laufzeit des Projekts neu priorisiert werden, wenn ein verbessertes Verständnis der aktuellen Risikobelastung dies erfordert.

95

Tabelle A1-2. Anwendung von Agilität auf Wissensgebieten des PMBOK® Guide (fortges.)

PMBOK® Guide Wissensgebiet Anwendung in einem agilen Arbeitsprozess

Abschnitt 12Beschaffungsmanagement in Projekten

Abschnitt 13Management der Projektstakeholder

In agilen Umgebungen können spezielle Lieferanten zur Vergrößerung des Teams eingesetzt werden. Diese gemeinschaftliche Arbeitsbeziehung kann zu einem Beschaffungsmodell mit geteiltem Risiko führen, bei dem Käufer wie Lieferant Risiko und Lohn des Projekts teilen.

Größere Projekte gehen bei manchen Liefergegenständen eventuell nach einem adaptiven Ansatz vor und folgen bei anderen Teilen einem stabileren Ansatz. In diesen Fällen kann für die Auftragsvergabe eine übergeordnete Vereinbarung, wie ein Dienstleistungsrahmenvertrag, verwendet werden, wobei die adaptiven Arbeiten in einem Anhang oder Nachtrag aufgeführt werden. Damit können Änderungen am adaptiven Inhalt und Umfang auftreten, ohne dass der Rahmenvertrag davon betroffen ist.

Projekte, die einem hohen Grad an Änderung unterliegen, brauchen eine aktive Einbindung und Mitwirkung der Projektstakeholder. Um rechtzeitige, produktive Diskussion und Entscheidungs�ndung zu unterstützen, arbeiten adaptive Teams, anstatt über mehrere Managementebenen hinweg, direkt mit den Stakeholdern zusammen. Oft tauschen Kunde, Nutzer und Entwickler Informationen in einem dynamischen Prozess der Mitgestaltung aus, der zu einer stärkeren Einbindung der Stakeholder und höhere Zufriedenheit führt. Regelmäßige Interaktionen mit dem Kreis der Stakeholder während der gesamten Projektlaufzeit mindern das Risiko, bauen Vertrauen auf und unterstützen Anpassungen früher im Projektzyklus; damit werden die Kosten gesenkt und die Erfolgschancen des Projekts erhöht.

Zum schnelleren Informationsaustausch innerhalb der Organisation und über die Organisation hinweg fördern agile Methoden aggressive Transparenz. Mit der Einladung von Stakeholdern zu Projektmeetings und Prüfungen oder der Veröffentlichung von Projektartefakten, sollen etwaige Fehlausrichtungen, Abhängigkeiten oder sonstige Themen, die mit dem sich ändernden Projekt zusammenhängen, so rasch wie möglich aufgedeckt werden.

97

ANLAGE A2 ZUORDNUNG ZUM AGILEN MANIFEST

Diese Anlage beschreibt, wie die Elemente des Agilen Manifests im Praxisleitfaden Agilität behandelt werden.

Tabelle A2-1. Die im Praxisleitfaden Agilität behandelten Werte des Agilen Manifests

Wert Themen des Praxisleitfadens Agilität nach Abschnitt und Titel

Individuen und Interaktionen mehr als Prozesse und Werkzeuge

Funktionierende Software mehr als umfassende Dokumentation

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

Reagieren auf Veränderung mehr als das Befolgen eines Plans

4.2 Dienende Führung stärkt das Team4.3 Zusammensetzung des Teams5.1 Auftrag für Projekt und Team5.2.4 Daily Standups (tägliche Kurzbesprechungen)6.2 Kultur der Organisation

5.2.2 Vorbereitung des Backlogs5.2.3 Feinabstimmung des Backlogs5.2.5 Präsentationen/Prüfungen5.2.7 Ausführungspraktiken, die Teams bei der Lieferung von Wert unterstützen

4.3 Zusammensetzung des Teams5.4 Messungen in agilen Projekten6.2 Kultur der Organisation6.3 Beschaffung und Verträge6.7 Struktur der Organisation

5.2.1 Retrospektiven5.2.3 Feinabstimmung des Backlogs5.2.5 Präsentationen/Prüfungen

98 Anlage A2

Tabelle A2-2. Zuordnung der Prinzipien hinter dem Agilen Manifest im Praxisleitfaden Agilität

Prinzip Themen im Praxisleitfaden Agilität

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

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 Projektes täglich zusammenar-beiten.

Errichte Projekte rund um motivierte Individuen. 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 im Gespräch von Angesicht zu Angesicht.

Funktionierende Software ist das wichtigste Fortschrittsmaß.

Agile Prozesse fördern nachhaltige Entwick-lung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

Ständiges Augenmerk auf technische Exzellenz 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 sein Verhalten entsprechend an.

3.1 Merkmale von Projektlebenszyklen5.2.7 Ausführungspraktiken, die Teams bei der Lieferung von Wert unterstützen

5.2.3 Feinabstimmung des Backlogs

5.2 Allgemeine agile Praktiken

4.2 Dienende Führung stärkt das Team5.2.2 Vorbereitung des Backlogs5.2.3 Feinabstimmung des Backlogs

4.3 Zusammensetzung des Teams5.1 Auftrag für Projekt und Team5.2.1 Retrospektiven

4.3.4 Teamstrukturen5.2.4 Daily Standups (tägliche Kurzbesprechungen)

5.2.7 Ausführungspraktiken, die Teams bei der Lieferung von Wert unterstützen5.2.8 Wie Iterationen und Inkremente zur Auslieferung eines funktionsfähigen Produkts beitragen

5.1 Auftrag für Projekt und Team

5.2 Allgemeine agile Praktiken

5.2.2 Vorbereitung des Backlogs5.2.3 Feinabstimmung des Backlogs

4.3 Zusammensetzung des Teams

5.2.1 Retrospektiven

99

ANLAGE A3 ÜBERBLICK ÜBER AGILE UND „LEAN“-REGELWERKE

Diese Anlage beschreibt einige häufig verwendete agile Ansätze. Diese Ansätze können in unveränderter Form angewandt oder passend zu einer bestimmten Umgebung oder Situation kombiniert werden. Ihre Verwendung ist aber nicht zwingend, vielmehr kann ein agiler Ansatz auch völlig neu erarbeitet werden; Voraussetzung ist nur, dass er der Denkweise, den Werten und Prinzipien des Agilen Manifests folgt. Wenn die agilen Prinzipien befolgt werden, um Wert in einem nachhaltigen Tempo zu liefern, und der Entwicklungsansatz die Zusammenarbeit mit dem Kunden fördert, braucht man keinen speziellen Ansatz. Ein Link zu weiteren Informationen über die jeweiligen Ansätze findet sich im Literaturverzeichnis dieses Leitfadens.

A3.1 AUSWAHLKRITERIEN FÜR DEN PRAXISLEITFADEN AGILITÄT

Die Anzahl der agilen Ansätze und Methoden ist so groß, dass nicht alle ausdrücklich in diesem Praxisleitfaden vorgestellt werden können. Abb. A3-1 zeigt eine Auswahl agiler Ansätze nach Ausführlichkeit der Anleitung und Grad der Lebenszyklusabdeckung. Für eine nähere Betrachtung wurden die folgenden verbreiteten Ansätze ausgewählt:

uu Auf ganzheitliche Verwendung ausgelegt. Bestimmte agile Ansätze konzentrieren sich auf einen einzelnen Projektvorgang, wie Schätzung oder Reflexion. Die aufgeführten Beispiele umfassen nur die agilen Regelwerke mit einer ganzheitlicheren Ausrichtung. Manche sind umfassender als andere, aber alle ausgewählten Ansätze sind als Anleitung für einen breiten Satz von Projektvorgängen gedacht.

uu Für eine allgemeine Verwendung formalisiert. Manche agilen Regelwerke sind in ihrem Wesen proprietär und für den spezifischen Einsatz in einer einzelnen Organisation oder innerhalb eines bestimmten Zusammenhangs konzipiert. Bei der Beschreibung der Regelwerke in den Abschnitten A3.2 bis A3.14 wurde der Fokus auf allgemeine Verwendbarkeit in den unterschiedlichsten Zusammenhängen gelegt.

uu In der modernen Anwendung verbreitet. Manche agilen Regelwerke sind ganzheitlich konzipiert und gut formalisiert, werden aber in den meisten Projekten oder Organisationen nicht eingesetzt. Die in dieser Anlage beschriebenen Regelwerke wurden, wie jüngste Wirtschaftsumfragen zeigen, von einer großen Anzahl an Branchen übernommen.

100 Anlage A3

Abb. A3-1. Agile Ansätze nach Breite und Ausführlichkeit

Grad

der

Lebe

nszy

klusa

bdec

kung

Ausführlichkeit der Anleitung

Agile UP

Kanban

DSDM

Scrum

XP

FDD

SAFe®

LeSS

Lean

DisciplinedAgile

Crystal-Methoden

Scrum ofScrums

Teammethode

SkalierterAnsatz

LEGENDE

101

A3.2 SCRUM

Scrum ist ein Prozessregelwerk für ein Einzelteam, das zur Steuerung der Produktentwicklung eingesetzt wird. Das Regelwerk besteht aus Scrum-Rollen, -Ereignissen, -Objekten und -Regeln und liefert Arbeitsergebnisse nach einem iterativen Ansatz. Scrum läuft unter Timeboxen von 1 Monat oder weniger mit gleichbleibenden Zeitspannen namens Sprints, in denen ein potenziell freigabefähiges Inkrement des Produkts erzeugt wird. Tabelle A3-1 listet Scrum-Ereignisse und -Objekte, die zur Projektausführung verwendet werden.

Das Scrum Team besteht aus Product Owner, Entwicklungsteam und Scrum Master.

uu Der Product Owner stellt die Wertmaximierung des Produkts sicher.

uu Das Entwicklungsteam ist ein funktionsübergreifendes, sich selbst organisierendes Team. Seine Mitglieder verfügen innerhalb des Teams über alles, was sie zur Lieferung eines lauffähigen Produktes brauchen, und sind von niemandem außerhalb des Teams abhängig.

uu Der Scrum Master muss sicherstellen, dass der Scrum-Prozess aufrechterhalten wird, und sorgt dafür, dass das Scrum-Team die Praktiken und Regeln einhält. Außerdem coacht er das Team zur Beseitigung von Hindernissen.

Tabelle A3-1. Scrum-Ereignisse und -Objekte

Ereignisse Objekte

Sprint

Sprint-Planung

Daily Scrum

Sprint-Review

Sprint-Retrospektive

Produkt-Backlog

Sprint-Backlog

Inkremente

102 Anlage A3

A3.3 EXTREME PROGRAMMING

eXtreme Programming (XP) ist eine Softwareentwicklungsmethode, die auf häufigen Zyklen basiert. Die Bezeichnung beruht auf dem Grundsatz, dass eine bestimmte bewährte Praxis auf ihre reinste und einfachste Form destilliert und diese Praxis während des gesamten Projektverlaufs kontinuierlich anwendet wird.

XP ist am bekanntesten dafür, dass sie einen ganzheitlichen Satz an Praktiken populär gemacht hat, die in Softwareprojekten bessere Ergebnisse herbeiführen sollen. Mit einem Satz zwölf grundlegender Praktiken erhielt die Methode erstmals eine feste Form. Durch Hinzunahme verschiedener anderer Begleitpraktiken wurde diese Form dann schrittweise weiterentwickelt. Siehe auch Tabelle A3-2.

Tabelle A3-2. eXtreme Programming und seine Praktiken

Diese Entwicklung ist das Ergebnis der Ausgestaltung und Übernahme von Methoden auf der Basis der Hauptwerte Kommunikation, Einfachheit, Feedback, Mut, Respekt. Weiterhin fließen auch die folgenden Grundprinzipien ein: Menschlichkeit, Wirtschaftlichkeit, beidseitiger Vorteil, Selbstgleichheit, Verbesserung, Vielfalt, Reflexion, Fluss, Chancen, Redundanzen vermeiden, Fehlschläge hinnehmen, Qualität, kleine Schritte, akzeptierte Verantwortung.

XP Praxisbereich Primär Sekundär

Organisationsebene

Technische Ebene

Planungsebene

Integration

• Zusammensitzen• Das ganze Team• Informativer Arbeitsbereich

• Paarprogrammierung• Testgetriebene Programmierung• Inkrementelle Konzeption

• User Stories• Wochenzyklus• Quartalszyklus• Puffer

• 10-Minuten-Build• Fortlaufende Integration („Continuous Integration“)• Testgetrieben

• Echte Kundenmitwirkung• Teamkontinuität• Nachhaltiges Tempo

• Gemeinsamer Code/Collective Code Ownership• Dokumentation von Code und Tests• Refactoring

• Fehler-Ursachen-Analyse• Schrumpfende Teams• Pay per use• Ausgehandelter Vertrag zu Inhalt und Umfang• Daily Standups (tägliche Kurzbesprechungen)

• Einheitliche Codebasis• Inkrementelle Bereitstellung• Tägliche Bereitstellung

103

A3.4 KANBAN-METHODE

Kanban ist im „Lean Manufacturing“ ein System zur Planung der Lagerbestandsaufnahme und -auffüllung. Diesen „just in time“-Prozess der Lagerauffüllung sah man ursprünglich in Lebensmittelgeschäften, in denen die Regale dann aufgefüllt wurden, wenn es dort Lücken gab, und nicht, wenn der Lieferant Bestände hatte. Ausgehend von diesen Lagerbestandssystemen nach dem „just-in-time“-Prinzip entwickelte Taiichi Ohno die Kanban-Methode, die dann 1953 im Hauptwerk von Toyota eingesetzt wurde.

Das Wort Kanban bedeutet wörtlich „sichtbares Zeichen“ oder „Karte“. Physische Kanban-Boards mit Karten ermöglichen die Visualiserung und machen den Fluss der Arbeit durch das System für jedermann leicht sichtbar. Dieser „Information Radiator“ (große Anzeige) besteht aus Spalten, die für die Stadien stehen, welche die Arbeit bis zu ihrer Fertigstellung durchfließen muss. Das einfachste Board besteht aus drei Spalten („muss noch gemacht werden“, „in Arbeit“ und „fertig“). Diese Form lässt sich auf beliebig viele Stadien erweitern, die das Team für notwendig erachtet.

Die Kanban-Methode ist auf viele Situationen anwendbar und wird entsprechend eingesetzt, ermöglicht sie doch einen kontinuierlichen Arbeits- und Wertfluss an den Kunden. Die Kanban-Methode ist weniger eng ausgelegt als manche agilen Ansätze und damit weniger disruptiv in ihrer Implementierung, weil sie den ursprünglichen Ansatz des „Beginne dort, wo du bist“ verkörpert. Organisationen können die Kanban-Methode relativ leicht einführen und sich an die komplette Umsetzung herantasten, wenn sie dies für notwendig oder geeignet erachten.

Im Gegensatz zu den meisten agilen Ansätzen schreibt die Kanban-Methode keinen Einsatz von Iterationen mit Timeboxen vor. Iterationen können in der Kanban-Methode verwendet werden, aber von einem Prinzip sollte nicht abgewichen werden: Dass fortlaufend einzelne Posten durch den Prozess gezogen werden und die laufende Arbeit im Hinblick auf Flussoptimierung eingeschränkt werden muss. Die Kanban-Methode ist am besten geeignet, wenn ein Team oder eine Organisation auf Folgendes angewiesen ist:

uu Flexibilität. Teams sind in der Regel nicht an Timeboxen gebunden und arbeiten an der Aufgabe mit der höchsten Priorität im Backlog.

uu Eins nach dem anderen. Teams konzentrieren sich auf den Fluss der Arbeit durch das System bis zur Fertigstellung. Sie beginnen erst dann mit neuen Arbeiten, wenn die laufende Arbeit erledigt ist.

uu Erhöhte Produktivität und Qualität. Produktivität und Qualität steigen dadurch, dass die gleichzeitig laufenden Arbeiten eingeschränkt werden.

104 Anlage A3

uu Mehr Effizienz. Jede Aufgabe wird auf Mehrwert geprüft, und die Aufgaben, die keinen Mehrwert liefern, werden entfernt.

uu Fokussierung der Teammitglieder. Wenn die gleichzeitig laufende Arbeit begrenzt ist, kann sich das Team ganz auf einzelne Arbeitspakete konzentrieren.

uu Veränderliche Auslastung. Dies beschreibt den Zustand, in dem das Eintreffen der Arbeit nicht vorhergesehen werden kann und Teams keine vorhersehbaren Zusagen treffen können − selbst über kurze Zeiträume. Das Team konzentriert sich ganz auf die Erledigung der Arbeit, ohne weit vorauszuplanen.

uu Weniger Verschwendung. Transparenz macht Verschwendung sichtbar, sodass sie beseitigt werden kann.

Die Kanban-Methode wurde aus den Prinzipien des „Lean Thinking“ abgeleitet. Die einschlägigen Grundsätze und die Kerneigenschaften der Kanban-Methode sind in Tabelle A3-3 aufgeführt.

Die Kanban-Methode ist ein ganzheitliches Regelwerk für einen inkrementellen, evolutionären Prozess- und Systemwandel in Organisationen. Die Methode arbeitet mit einem „Pull-System“, um die Arbeit durch den Prozess zu „ziehen“. Wenn das Team einen Posten fertigstellt, kann das Team den Posten in diesen Schritt „ziehen“.

Tabelle A3-3. Prägende Prinzipien und Eigenschaften der Kanban-Methode

Prägende Prinzipien Kerneigenschaften

Mit dem Ist-Zustand beginnen

Anstreben von inkrementellen, sich entwickelnden Veränderungen vereinbaren

Respekt für aktuelle Prozesse, Rollen, Verantwortung und Titel

Führungsverhalten auf allen Ebenen fördern

Arbeitsfluss visuell darstellen

Gleichzeitig laufende Arbeit einschränken

Fluss steuern

Prozessrichtlinien ausdrücklich festlegen

Feedback-Schleifen implementieren

Gemeinsam besser werden

105

Kanban-Boards, wie in Abb. A3-2, sind ein „Low-Tech, High-Touch“-Verfahren, das auf den ersten Blick übermäßig simpel erscheint, seinen Anwendern aber schon bald seine ganze Leistungsfähigkeit offenbart. Anhand von Richtlinien für den Eintritt in und den Austritt aus Spalten sowie Einschränkungen, wie z. B. die Begrenzung der gleichzeitig laufenden Arbeit, bieten Kanban-Board eine klare Sicht auf Arbeitsfluss, Engpässe, Blocker und den Status insgesamt. Darüber hinaus dient das Board als „Information Radiator“ für alle, die es sehen, und gibt aktuell Auskunft über den Status der Arbeit des Teams.

Abb. A3-2. Kanban-Board, welches die Grenzen der laufenden Arbeit zeigt, und ein Pull-System zur Optimierung des Arbeitsflusses

In der Kanban-Methode ist es wichtiger, Arbeit fertigzustellen als neue Arbeit aufzunehmen. Es wird kein Wert aus nicht fertiggestellter Arbeit gewonnen, sodass das sich Team gemeinsam an die Umsetzung und Befolgung der Grenzen für die gleichzeitig laufende Arbeit (Work in Progess, WIP) hält und jeden Posten durch das System zieht, bis er „erledigt“ ist.

6Noch zu

erledigen4

Analyse5

Entwicklung3

Test4

Einsatz

In Arbeit Fertig In Arbeit Fertig

106 Anlage A3

A3.5 CRYSTAL-METHODEN

Crystal ist ein Verbund von Methoden. Crystal-Methoden werden auf die Größe des Projekts abgestimmt und besitzen je nach Größe (Anzahl der am Projekt beteiligten Personen) und Kritikalität des Projekts unterschiedlich strenge Maßstäbe.

Abb. A3-3. Die Methoden der „Crystal“-Familie

Leben(L)

UnentbehrlicheMittel

(E)

Frei verfügbareMittel

(D)

Komfort(C)

Kriti

kalit

ät(M

änge

l füh

ren

zu V

erlu

st v

on ..

.)

Crystal Clear Crystal Yellow Crystal Orange Crystal Red

L3

E3

D3

C3

L10

E10

D10

C10

L30

E30

D30

C30

L80

E80

D80

C80

L150

E150

D150

C150

L300

E300

D300

C300

L600

E600

D600

C600

Anzahl der beteiligten Personen(Gesamtzahlen +–20 % Mitarbeiter)

1-4 6-20 20-40 5-100 100-200 200-500 500

LEG

END

E

107

In der Crystal-Methodik wird berücksichtigt, dass jedes Projekt eventuell einen leicht angepassten Satz von Richtlinien, Praktiken und Prozessen braucht, um den besonderen Merkmalen des Projekts gerecht zu werden. Die einzelnen Methoden der Familie sind je nach ihrem „Gewicht“ mit unterschiedlichen Farben gekennzeichnet, nach denen die jeweilige Methodik ausgesucht werden kann. Die Bezeichnung Crystal erinnert an einen Edelstein, dessen einzelne Facetten jeweils für zugrunde liegende Kernprinzipien und Werte stehen. Die Facetten sind, wie in Tabelle A3-4 gezeigt, eine Darstellung von Methoden, Werkzeugen, Standards und Rollen.

Tabelle A3-4. Kernwerte und allgemeine Eigenschaften von Crystal

Kernwerte Allgemeine EigenschaftenA

Menschen

Wechselbeziehung

Gemeinschaft

Können

Fähigkeiten

Kommunikation

Häufige Auslieferung

Reflektive Verbesserung

Enge oder osmotische Kommunikation

Persönliche Sicherheit

Fokus

Leichter Zugang zu Expertenanwendern

Technische Umgebung mit automatisierten Tests, Konfigurationsmanagement und häufiger Integration

A Je stärker diese Eigenschaften in einem Projekt vertreten sind, um so wahrscheinlicher ist der Erfolg.

108 Anlage A3

A3.6 SCRUMBAN

Scrumban ist ein agiler Ansatz, der ursprünglich als Übergangslösung von Scrum zu Kanban konzipiert wurde. Mit dem Aufkommen weiterer agiler Regelwerke und Methodiken wurde es zu einem eigenständigen und sich entwickelnden hybriden Regelwerk, in dem Teams Scrum als Regelwerk und Kanban zur Prozessverbesserung einsetzen.

In Scrumban wird die Arbeit in kleine „Sprints“ untergliedert. Die Methode nutzt Kanban-Boards zur bildlichen Darstellung und Überwachung der Arbeit. Die Stories werden auf dem Kanban-Board platziert, und das Team verwaltet seine Arbeit anhand von Grenzen für die gleichzeitig laufende Arbeit. Es werden täglich Meetings abgehalten, um die Zusammenarbeit im Team aufrechtzuerhalten und Hindernisse aus dem Weg zu räumen. Für das Team wird ein Auslöser („Trigger“) eingerichtet, damit es weiß, wann als nächstes geplant werden muss – meist wenn die laufende Arbeit einen vorgegebenen Grenzwert unterschreitet. In Scrumban gibt es keine vordefinierten Rollen, sondern das Team behält seine gegenwärtigen Rollen.

A3.7 FEATURE-GESTEUERTE ENTWICKLUNG

Feature-gesteuerte Entwicklung (Feature-Driven Development, FDD) soll die spezifischen Bedürfnisse eines großen Softwareentwicklungsprojekts erfüllen. Features beziehen sich auf Lieferungen von kleinerem geschäftlichem Wert.

In einem feature-gesteuerten Entwicklungsprojekt gibt es sechs Hauptrollen. Einzelpersonen können eine oder mehrere dieser Rollen übernehmen:

uu Projektmanager

uu Hauptarchitekt

uu Entwicklungsmanager

uu Hauptprogrammierer

uu Klassenverantwortlicher (Class Owner) und/oder

uu Domänenexperte.

109

Ein feature-gesteuertes Entwicklungsprojekt wird um fünf Prozesse oder Vorgänge herum organisiert, die iterativ durchgeführt werden:

uu Entwicklung eines Gesamtmodells

uu Aufstellung einer Feature-Liste

uu Featureweise Planung

uu Featureweise Konzeption und

uu Featureweises Bauen.

Der Lebenszyklus und die Wechselbeziehungen dieser fünf Prozesse sind in Abb. A3-4 veranschaulicht.

Feature-gesteuerte Entwicklungsvorgänge werden von einem Kernsatz an bewährten Praktiken des Software-Engineering gestützt:

uu Modellierung des Domänenobjekts

uu Featureweise Entwicklung

uu einzelne Klassenverantwortung

uu Featureteams

uu Inspektionen

uu Konfigurationsmanagement

uu Regelmäßiges Bauen der Lieferung und

uu Sichtbarkeit von Fortschritt und Ergebnissen.

Abb. A3-4. Projektlebenszyklus in der feature-gesteuerten Entwicklung

Modellüberarbeitung

Feature-weisesBauen

Entwicklung eines Modells

auf hoher Ebene

Entwicklung einer

Feature-Liste

Featureweise Planung

Featureweise Konzeption

110 Anlage A3

A3.8 DYNAMIC SYSTEMS DEVELOPMENT METHOD

Die Dynamic Systems Development Method (DSDM) ist ein agiles Regelwerk zur Projektlieferung, das ursprünglich konzipiert wurde, um die in den 1990ern verbreiteten iterativen Methoden zu straffen. Sie wurde als Form der nichtkommerziellen Zusammenarbeit unter Branchenführern entwickelt.

DSDM ist am besten für ihre Ausrichtung auf die einschränkungsgesteuerte („constraint-driven“) Lieferung bekannt. Das Regelwerk legt Kosten, Qualität und Zeit von Anfang an fest und erfüllt diese Einschränkungen mit einer formalisierten Priorisierung von Inhalt und Umfang (siehe Abb. A3-5).

Abb. A3-5. DSDM-Ansatz zu einschränkungsgesteuerter Agilität

Der Einsatz des DSDM-Regelwerks wird von acht Prinzipien geleitet:

uu Ausrichtung auf den geschäftlichen Bedarf

uu Pünktliche Lieferung

uu Zusammenarbeit

uu Keine Kompromisse bei der Qualität

uu Inkrementeller Aufbau auf festen Fundamenten

uu Iterative Entwicklung

uu Kontinuierliche und klare Kommunikation

uu Demonstration von Souveränität über den Projektverlauf (mit geeigneten Methoden).

Fest

Variabel

Features Kosten Zeit

Kosten FunktionalitätZeit

DSDM-AnsatzTraditioneller Ansatz

Qualität

Qualität

111

A3.9 AGILE UNIFIED PROCESS

Der Agile Unified Process (AgileUP) ist eine Weiterentwicklung des Unified Process (UP) für Software-Projekte. Er verfügt über schnellere Zyklen und leichtere Prozesse als sein Vorgänger, der Unified Process. Die Absicht ist der Durchlauf von mehr iterativen Zyklen über sieben Schlüsseldisziplinen und die Eingliederung des damit einhergehenden Feedbacks vor der formellen Übergabe. Die Disziplinen und Leitprinzipien sind in Tabelle A3-5 aufgeführt.

Tabelle A3-5. Die wichtigsten Elemente des Agile Unified Process

A3.10 REGELWERKE ZUR SKALIERUNG

A3.10.1 SCRUM OF SCRUMS

Die Methode Scrum of Scrums (SoS), auch „Meta-Scrum“ genannt, wird eingesetzt , wenn es statt eines großen Scrum-Teams zwei oder mehr Scrum-Teams mit jeweils drei bis neun Mitgliedern gibt, die ihre Arbeit koordinieren müssen. Ein Vertreter aus jedem Team trifft sich mit den anderen Team-Vertretern in der Regel zwei bis drei Mal pro Woche, eventuell sogar täglich, zu einem Meeting. Das Meeting wird ähnlich wie das Daily Standup in Scrum abgehalten, bei dem der Vertreter über die fertiggestellte Arbeit, den nächsten Satz an Arbeiten sowie über gegenwärtige Hindernisse und mögliche künftige Hindernisse (die andere Teams blockieren könnten) berichtet. Dadurch soll sichergestellt werden, dass die Teams ihre Arbeit koordinieren und Hindernisse beseitigen, damit alle Teams so effizient wie möglich arbeiten können.

Große Projekte mit mehreren Teams führen oft zu einem „Scrum of Scrum of Scrums“, das demselben Muster folgt wie ein SoS: ein Vertreter aus jedem SoS berichtet, wie in Abb. A3-6 gezeigt, einer größeren Gruppe von Vertretern.

Disziplinen innerhalb einer Freigabe Die Leitprinzipien der Disziplinen

Modell

Umsetzung

Test

Bereitstellung

Konfigurationsmanagement

Projektmanagement

Umgebung

Das Team weiß, was es tut

Einfachheit

Agilität

Ausrichtung auf Aktivitäten mit hohem Wert

Werkzeugunabhängigkeit

Maßgeschneiderte Anpassung

Situationsspezifisch

112 Anlage A3

Abb. A3-6. Vertreter von Scrum-Teams nehmen an SoS-Teams teil

A3.11 SCALED AGILE FRAMEWORK

Aufgabe des Scaled Agile Framework (SAFe®) ist es, eine Wissensbasis an Mustern zur Skalierung der Entwicklungsarbeit auf allen Unternehmensebenen bereitzustellen.

SAFe® konzentriert sich auf die folgenden Grundsätze:

uu Eine wirtschaftliche Sicht einnehmen.

uu Systemdenken anwenden.

uu Veränderlichkeit annehmen; Optionen beibehalten.

uu Inkrementell mit schnellen, integrierten Lernzyklen bauen.

uu Meilensteine auf die objektive Bewertung von funktionsfähigen Systemen ausrichten.

Scrumof

Scrums

Scrum ofScrums ofScrums

Scrum-Teams

113

uu Die gleichzeitig laufende Arbeit sichtbar machen und einschränken, Arbeitspaketgrößen verringern und Längen der Warteschlangen steuern.

uu Entwicklungstakt angleichen; mit domänenübergreifender Planung synchronisieren.

uu Die intrinsische Motivation von Wissensarbeitern freisetzen.

uu Entscheidungsfindung dezentralisieren.

SAFe® konzentriert sich auf die detaillierte Beschreibung von Praktiken, Rollen und Vorgängen auf der Ebene von Portfolio, Programm und Team. Dies erfolgt im Hinblick auf die Organisation des Unternehmens und in Ausrichtung auf Wertströme, die sich auf die kontinuierliche Bereitstellung von Wert an den Kunden konzentrieren.

A3.12 LARGE SCALE SCRUM (LeSS)

Large Scale Scrum (LeSS) ist ein Regelwerk zur Ausrichtung mehrerer Entwicklungsteams auf ein gemeinsames Ziel und damit eine Erweiterung der in Abb. A3-6 gezeigten Scrum-Methode. Das organisatorische Kernprinzip ist die Beibehaltung möglichst vieler Elemente aus dem herkömmlichen Scrum-Modell mit einem Team. Damit können Modellerweiterungen, die zu unnötiger Verwirrung oder Komplexität führen, minimiert werden. Tabelle A3-6 zeigt den Vergleich von LeSS und Scrum.

Tabelle A3-6. Vergleich von LeSS und Scrum

Zur Ausweitung von Scrum ohne Verlust seiner wesentlichen Elemente fördert LeSS den Einsatz der wichtigsten Grundsätze, wie Systemdenkweise, Ausrichtung auf das ganze Produkt, Transparenz (und andere).

Ähnlichkeiten zwischen LeSS und Scrum LeSS-Verfahren, die Scrum ergänzen

Ein einzelner Produkt-Backlog

Eine Definition of Done für alle Teams

Ein potenziell lieferbares Produktinkrement am Ende eines jeden Sprint

Ein Product Owner

Komplette, funktionsübergreifende Teams

Ein Sprint

Sprint-Planung ist formeller in die beiden Teile „Was“ und „Wie“ unterteilt

„Organische“ teamübergreifende Koordination

Allgemeine teamübergreifende Feinabstimmung

Allgemeine Retrospektive mit Ausrichtung auf teamübergreifende Verbesserungen

114 Anlage A3

A3.13 ENTERPRISE SCRUM

Enterprise Scrum ist ein Regelwerk zur Anwendung der Scrum-Methode auf eine umfassendere Ebene der Organisation statt auf die Entwicklungsarbeit für ein einzelnes Produkt. Insbesondere rät das Regelwerk den Leitern der Organisation Folgendes:

uu Ausdehnung von Scrum auf alle Aspekte der Organisation;

uu Verallgemeinerung der Scrum-Methoden, sodass sie leicht auf diese Aspekte angewandt werden können, und

uu Bedarfsweise Skalierung der Scrum-Methode mit zusätzlichen Methoden.

Die Absicht ist der Einsatz agiler Ansätze über die Projektausführung hinaus, indem man disruptive Innovation ermöglicht.

A3.14 DISCIPLINED AGILE (DA)

Disciplined Agile (DA) ist ein Regelwerk zur Prozessentscheidung, das verschiedene bewährte Praktiken der Agilität in ein umfassendes Modell integriert. DA wurde als Gegengewicht zu verbreiteten Methoden entwickelt, die entweder als zu eng in ihrer Ausrichtung (z. B. Scrum) oder zu einengend in ihren Vorgaben (z. B. AgileUP) erachtet wurden. Um dieses Gleichgewicht zu erreichen, mischt DA verschiedene agile Methoden nach den folgenden Grundsätzen:

uu Menschen zuerst. Aufzählung der Rollen und Organisationselemente auf unterschiedlichen Ebenen.

uu Lernorientiert. Fördert Verbesserung in Zusammenarbeit.

uu Vollständiger Lieferlebenszyklus. Förderung verschiedener zweckdienlicher Lebenszyklen.

uu Zielorientiert. Anpassung der Prozesse, um bestimmte Ergebnisse zu erzielen.

uu Unternehmensbewusstsein. Anleitung zur abteilungsübergreifenden Führung und Aufsicht.

uu Skalierbar. Abdeckung mehrerer Dimensionen von Programmkomplexität.

115

ANHANG X1 MITWIRKENDE UND LEKTOREN

X1.1 AUSSCHUSS PRAXISLEITFADEN AGILITÄT

Die folgenden Personen gehörten dem Ausschuss für das Projekt an, der für den Entwurf des Leitfadens, seiner Prüfung und für Entscheidungen über Empfehlungen vonseiten der Lektoren zuständig war.

X1.1.1 VERTRETER DES PROJECT MANAGEMENT INSTITUTE:

Mike Griffiths, PMP, PMI-ACP (Vorsitzender des Ausschusses)Jesse Fewell, CST, PMI-ACPHoria Slușanschi, PhD, CSMStephen Matola, BA, PMP

X1.1.2 VERTRETER DER AGILE ALLIANCE:

Johanna Rothman, MS (Stellvertretende Vorsitzende des Ausschusses)Becky Hartman, PMI-ACP, CSPBetsy Kauffman, ICP-ACC, PMI-ACP

116 Anhang X1

X1.2 FACHEXPERTENPRÜFER DES PRAXISLEITFADENS AGILITÄT

Die folgenden Personen wurden als Fachexperten geladen; sie prüften den Entwurf und gaben im Rahmen ihrer Expertenprüfung Empfehlungen ab.

Joe Astolfi, PMP, PSMMaria Cristina Barbero, PMI-ACP, PMPMichel Biedermann, PhD, PMI-ACPZach BonakerRobert Bulger, PfMP, CSMSue BurkShika Carter, PMP, PMI-ACPLauren Clark, PMP, CSMLinda M Cook, CSM, CSPOPamela Corbin-Jones, PMI-ACP, CSMJeff CovertAlberto Dominguez, MSc, PMPScott P. Duncan, CSM, ICP-ACCSally Elatta, PMI-ACP, EBACFrank R. Hendriks, PMP, PMI-ACPDerek HuetherRon JeffriesFred KoosPhilippe B. Kruchten, PhD, PEngSteve Mayner, SPCT4, PMPMichael S. McCalla, PMI-ACP, CSPDon B. McClure, PMP, PMI-ACPAnthony C. Mersino, PMI-ACP, CSPKenneth E. Nidiffer, PhD, PMPMichael C. Nollet, PMP, PMI-ACP

Laura Paton, MBA, PMPYvan Petit, PhD, PMPDwayne Phillips, PhD, PMPPiyush Prakash, PMP, Prince2Dave Prior, PMP, CSTDaniel Rawsthorne, PhD, PMPAnnette D. Reilly, PMP, PhDStephan Reindl, PMI-ACP, PMPReed D. Shell, PMP, CSPCindy Shelton, PMP, PMI-ACPTeresa ShortLisa K. Sieverts, PMP, PMI-ACPChristopher M. Simonek, PMP, CSMRobert “Sellers” Smith, PMP, PMI-ACPRam Srinivasan, PMP, CSTChris Stevens, PhDKaren Strichartz, PMP, PMI-ACPRahul Sudame, PMI-ACPJoanna L. Vahlsing, PMPErik L. van DaalenAnnette Vendelbo, PMP, PMI-ACPDave Violette, MPM, PMPAnton Vishnyak, PMI-ACP, CSMChuck Walrad, MA, MS

117

X1.3 FOKUSGRUPPE FORMAT

Die folgenden Personen waren an der Ausarbeitung von Stil und Form der neuen Inhalte im Praxisleitfaden Agilität beteiligt:

Goran Banjanin, PgMP, PMPAndrew CraigCătălin-Teodor Dogaru, PhD, PMPJorge Espinoza, PMPJennifer M. Forrest, CSM, PMPHelen Fotos, PMP, PMI-ACPDave Hatter, PMP, PMI-ACPChristopher Healy, PMPMike Hoffmann, MBA, PMPChadi Kahwaji, PMP

Rajaraman Kannan, PMP, MACS CPAmit Khanna PMP, PMI–ACPAriel Kirshbom, PMI-ACP, CSPBernardo Marques, PMPNoura Saad, PMI-ACP, CSPOKurt Schuler, PMPDemetrius L. Williams, MBA, PMPLiza WoodMelody Yale, CSP, SPC4

X1.4 PMI STANDARDS MEMBER ADVISORY GROUP (MAG)

Die folgenden Personen sind Mitglieder der PMI Standards Member Advisory Group, die für Anleitungen und die endgültige Freigabe des Praxisleitfaden Agilität im Auftrag des PMI zuständig war.

Maria Cristina Barbero, PMI-ACP, PMPBrian Grafsgaard, PMP, PgMPHagit Landman, PMP, PMI-SPYvan Petit PhD, PMPChris Stevens, PhDDave Violette, MPM, PMPJohn Zlockie, MBA, PMP, PMI Standards Manager

X1.5 AGILE ALLIANCE® BOARD

Die folgenden Personen gehören dem Vorstand der Agile Alliance an, der für Anleitungen und die endgültige Freigabe des Praxisleitfadens Agilität im Auftrag der Agile Alliance zuständig war.

Juan BandaPhil Brock (Managing Director)Linda CookStephanie DavisEllen Grove

Paul Hammond (Vorsitz)Victor Hugo GermanoRebecca Parsons (Schriftführerin)Craig SmithDeclan Whelan

118 Anhang X1

X1.6 MITARBEITER DES PMI BETREUERSTABS UND IN DER AKADEMISCHEN FORSCHUNG

Die folgenden Personen unterstützten den Ausschuss bei der Ausarbeitung und Freigabe des Entwurfs und leiteten Beiträge zur Fokusgruppe Format und zum Marketing des PMI.

Melissa M. Abel, Marketing Communications SpecialistKarl F. Best, PMP, CStd, Standards SpecialistAlicia C. Burke, MBA, CSM, Product Manager, CredentialsEdivandro C. Conforto, PhD, PMI Consultant on Agile ResearchDave Garrett, CSPO, Vice President, TransformationErica Grenfell, Administrative Assistant to VP, Organization RelationsM. Elaine Lazar, MA, MA, AStd, Project SpecialistAndrew Levin, PMP, Project ManagerTim E. Ogline, User Experience DesignerStephen A. Townsend, Director of Network ProgramsMichael Zarro, PhD, UX Researcher

X1.7 PRODUKTION PMI

Donn Greenberg, Manager, VeröffentlichungenKim Shinners, Mitarbeit in der Veröffentlichung (Produktion)Roberta Storer, ProduktredakteurinBarbara Walsh, Betreuerin, Veröffentlichungen (Produktion)

X1.8 MITGLIEDER DER GRUPPE EHRENAMTLICHER ÜBERSETZUNGSPRÜFER DER DEUTSCHEN FASSUNG

Guido Matern, PMPWolf Dieter Moggert, PMP, PMI-ACP, PMI-PBA, ITIL ExpertMatthias Seul, PMI-ACP, CSM, CSPO, CSP, SAFe AgilistSebastian Stuecker, PMP, PMI-SP, PMI-ACP

X1.9 MITGLIEDER DES ÜBERSETZUNGSPRÜFUNGSKOMITEES

Barbara Walsh, Betreuerin, Veröffentlichungen (Produktion)Margaret Lyons, PrüfungsautorinStephen Townsend, Director, Network ProgramsVivian Isaak, Präsidentin, Magnum Group, Inc., ÜbersetzungsfirmaBrian Middleton, Strategische Lösungen, Magnum Group, Inc., Übersetzungsfirma

119

ANHANG X2 ASPEKTE, WELCHE DIE ANPASSUNG BEEINFLUSSEN

X2.1 EINFÜHRUNG

Dieser Anhang liefert auf übergeordneter Ebene Anleitung zur Entscheidung, wann und wie agile Ansätze angepasst werden sollen. Er kann zur Bestimmung der Umstände herangezogen werden, die eine Änderung oder Einführung neuer Methoden rechtfertigen, und bietet einige weiterführende Empfehlungen.

X2.2 EINE WARNUNG VORAB

Anpassung ist ein Thema für Fortgeschrittene, an das sich nur erfahrene Agilisten heranwagen sollten, die agile Ansätze in ihrer ursprünglichen Form bereits in verschiedenen Umgebungen erfolgreich angewendet haben. Mit anderen Worten: Sammeln Sie Erfahrung und Erfolg mit einem Ansatz, bevor Sie versuchen, diesen Ansatz anzupassen.

Gibt es bei der Anwendung einer agilen Praxis Schwierigkeiten, dann wird häufig überlegt, ob sie überhaupt ausgeführt werden soll oder nicht. Eine Aussage wie „Retrospektiven waren unbeliebt, also haben wir sie abgeschafft“ veranschaulicht dieses Problem und deutet auf tiefer liegende Schwierigkeiten im Team hin, die sich durch eine Anpassung der Methode wahrscheinlich nicht beheben lassen. Die Situation wird noch verschlimmert, wenn der Vorgang der Retrospektive ausgelassen wird, da dieser eigentlich auf die Verbesserung des Prozesses abzielt.

Das Shu-Ha-Ri-Modell zum Erwerb von Fähigkeiten beschreibt die Entwicklung vom Befolgen der Regeln (Shu 守 bedeutet gehorchen und schützen) über das bewusste Abweichen von den Regeln (Ha 破 bedeutet verändern oder abweichen) bis schließlich zur Entdeckung eines eigenen Weges durch stete Praxis und Verbesserung (Ri 離 bedeutet trennen oder verlassen). Wir müssen auf der Ebene Shu beginnen und praktizieren, bevor wir auf die Ebene Ha wechseln können, um den Prozess anzupassen, oder die Ebene Ri erreichen, wo wir einen neuen, maßgeschneiderten Prozess erfinden.

120 Anhang X2

Und schließlich sollte die Anpassung in Zusammenarbeit mit den Teamkollegen oder den Personen vorgenommen werden, die wahrscheinlich von der Änderung betroffen sind. Die betroffenen Teamkollegen oder Personen müssen in den Denk- und Entscheidungsfindungsprozess über die Änderung der Prozesse eingebunden sein, damit sie die Änderung annehmen und sich dafür engagieren („Buy-In“). Nur so kann die Umstellung gelingen. Bleiben Mitarbeiter bei der Anpassung eines Prozesses außen vor, führt dies oft zu Widerstand und Ablehnung gegenüber der Änderung, selbst wenn sie eigentlich sinnvoll wäre. Oftmals können erfahrene Coaches oder Führungspersonen dabei helfen, Mitarbeiter effektiv einzubinden.

X2.3 GEBRAUCH DIESES ANHANGS

Damit Sie von den Anleitungen in diesem Anhang auch wirklich profitieren, empfehlen wir Ihnen zunächst die erfolgreiche Anwendung der agilen Ansätze in ihrer ursprünglichen Form. Danach sollten Sie sich die Richtlinien zur Anpassung in Tabelle X2-1 ansehen, die zu Ihrer Situation passen, und die entsprechenden Empfehlungen lesen. Besprechen Sie dann die Änderung mit den Mitarbeitern, die davon betroffen sein werden, und vereinbaren Sie die Vorgehensweise.

Wie in Abschnitt 5 erörtert, kann eine Änderung gut beurteilt werden, indem sie zunächst in einer oder zwei Iterationen ausprobiert wird, bevor es zu einer dauerhaften Übernahme kommt. Es kann auch ein flussbasierter Ansatz in Erwägung gezogen und versucht werden, mehrere Features zu liefern. Dann kann mithilfe einer Retrospektive darüber nachgedacht und die Lage neu bewertet werden.

Wenn die beteiligten Personen wissen, dass sie experimentieren und Feedback zum Experiment geben können, steigt die Wahrscheinlichkeit, dass sie etwas Neues ausprobieren. Wenn das Team den Ansatz für die Dauer einer Timebox ausprobiert hat, sollte es im Rahmen einer Retrospektive die Wirksamkeit dieses Ansatzes prüfen und festlegen, ob er in unveränderter oder verbesserter Form verwendet oder abgeschafft werden soll.

Schließlich können erfolgreich übernommene und angepasste Ansätze zu Standardprozessen gemacht werden, die für Projekte mit diesen Eigenschaften herangezogen werden. Es wird auch empfohlen, den Richtlinien aus Abschnitt 5 zu folgen, welche die Übernahme (oder Anpassung) neuer Ansätze beschreiben.

X2.4 ANPASSUNGSEMPFEHLUNGEN

Im Folgenden sind einige bewährte Praktiken aufgeführt, die vor der Anpassung eines Ansatzes berücksichtigt werden sollten.

121

X2.4.1 VORSICHT VOR ABSCHAFFUNGEN

Viele agile Praktiken sind sich gegenseitig stützende Konstrukte. So ermöglichen zum Beispiel das Zusammenlegen der Arbeitsplätze und häufige Meetings leichte Anforderungen, weil Verständnislücken rasch geschlossen werden können. Ebenso erlaubt das vorbehaltslose Testen in eXtreme Programmming (XP) ein effektives Refactoring, weil eine Praxis die andere stützt. Etwas abzuschaffen, ohne die ausgleichende Praxis zu verstehen oder zu berücksichtigen, führt nur zu mehr Problemen, statt sie zu lösen.

X2.4.2 GEBRAUCH DER TABELLE MIT DEN ANPASSUNGSRICHTLINIEN

Auf Tabelle X2-1 suchen Sie nach den Umständen, die einer bestimmten Situation entsprechen, und gehen dann die Anpassungsempfehlungen durch. Besprechen Sie etwaige Änderungen mit dem von der Änderung betroffenen Personenkreis und planen Sie zunächst eine kurze Versuchsphase; nehmen Sie danach eine ehrliche Prüfung vor, bevor Sie die Änderung endgültig übernehmen.

Tabelle X2-1. Anpassungsrichtlinien

Situation Anpassungsempfehlung

Sehr große Projektteams Strukturieren Sie große Projekte in mehrere kleinere Projekte um. Probieren Sie zunächst ein technisches Versuchsprojekt und dann ein Implementierungsprojekt.

Ziehen Sie häu�gere Freigaben mit jeweils wenigen Features in Betracht, weil dadurch die Bildung kleinerer Projektteams möglich wird.

Erwägen Sie die Verkleinerung des Teams auf seine notwendigen Mitglieder. Zu viele Mitarbeiter sind in einem Prozess oft eher hinderlich als förderlich. Die Verkleinerung eines Teams kann auch Personalabwanderung und Kosten senken.

Teilen Sie große Teams in mehrere kleine Teams auf und nehmen Sie Synchronisierung und Koordination mithilfe von Programmmanagement vor.

Mit agilem und „Lean“ Programmmanagement kann ein größeres Vorhaben organisiert werden.

Ziehen Sie ein skaliertes agiles oder „Lean“ Regelwerk wie DA, SAFe® oder LeSS in Betracht. Sie alle bieten nützliche Vorschläge, bringen aber auch Implementierungsrisiken und Prozesskomplexität/-kosten mit sich.

122 Anhang X2

Tabelle X2-1. Anpassungsrichtlinien (fortges.)

Situation Anpassungsempfehlung

Verteilte Teams

Manche sicherheitskritischen Produkte erfordern eventuell mehr Dokumentationen und Konformitätsprüfungen als agile Prozesse standardmäßig vorgeben

Stabile Anforderungen und Ausführungsprozesse

Innerhalb funktionaler Organisationen be�nden sich Teams oft in Funktionssilos

Viele Projekte haben (einige) Teammitglieder an anderen Standorten. Werkzeuge wie Instant Messaging, Videokonferenzen und elektronische Team-Boards helfen bei der Überbrückung vieler Kommunikationslücken.

Wenn von stabilen Teams ausgegangen werden kann, sollten Sie so bald wie möglich Meetings vereinbaren, die alle Mitglieder an einem Ort zusammenführen („Face-to-Face Meetings“). Dadurch werden künftige Gespräche über größere Entfernungen effektiver. Bei Menschen, die sich schon einmal persönlich getroffen haben, entsteht mehr Vertrauen, sodass sie sich mit geringerer Zurückhaltung am Diskurs beteiligen.

Bei Meetings mit Teilnehmern an anderen Orten, wo Mimik und Körpersprache verloren gehen, sollten Sie reihum ein kurzes, persönliches Stimmungsbild („Check-in“) erfragen, um die Mitwirkung und den Konsens für Entscheidungen sicherzustellen.

Überlegen Sie auch den Einsatz iterationsbasierter agiler Ansätze. Wenn Teammitglieder viele Zeitzonen weit voneinander entfernt sind, sollten Sie nicht so oft alle am Gesamtprojekt beteiligten Personen einbeziehen, dafür aber häu�gere Meetings im kleinen Kreis (mit jeweils zwei oder drei Teilnehmern) fördern.

In diesen Umgebungen kann man trotzdem nach agilen Ansätzen vorgehen, allerdings brauchen sie die geeigneten zusätzlichen Konformitätsprüfungen, Dokumentationen und Zerti�zierungen, die von der Umgebung gefordert werden. In diesen Fällen könnte das Team die Dokumentation zusammen mit den fertiggestellten Features liefern. Features werden unter Umständen erst dann fertiggestellt, wenn die Dokumentation vollständig ist.

Ziehen Sie einen hybriden Ansatz (mehrere Ansätze gemischt) in Betracht. Damit gewinnen Sie die Vorteile besserer Kooperation und Kommunikation durch Agilität einerseits und die von der Produktumgebung geforderte erhöhte Sorgfalt andererseits. Entwickler von Luftfahrtsystemen und Pharmaunternehmen bedienen sich agiler Ansätze im Verbund mit ihren eigenen zusätzlichen Prozessen, um die Vorteile zu nutzen und die geeignete Kontrolle zu behalten.

Ist Agilität wirklich notwendig? Wenn die Unsicherheit der Anforderungen niedrig ist, bei niedrigen Änderungsfrequenzen oder minimalem Ausführungsrisiko ist die komplette Bandbreite agiler Ansätze womöglich nicht erforderlich. Zwar pro�tiert jedes Projekt von erhöhter Zusammenarbeit und Transparenz, aber bestimmte iterative Bau- und Prüfzyklen sind dann vielleicht doch zu viel des Guten.

Wenn Bau-/Feedback-Zyklen nicht routinemäßig Anforderungen aufdecken oder verfeinern, können Sie ihre Dauer ausdehnen, um die Folgekosten der Prüfzeit zu minimieren.

Bei Projekten mit hohen Änderungsraten während der Konzeptions- und Entwicklungsphase, die aber einen de�nierten und wiederholbaren Prozess bei der Übergabe an den Kunden haben, sind hybride Ansätze, die für die einzelnen Projektphasen das jeweils geeignete Lebenszyklusmodell verwenden, womöglich sinnvoller.

Agilität fußt auf der Idee funktionsübergreifender Teams. Sie können Mitarbeiter bitten, selber und ohne Beteiligung des Managements funktionsübergreifende Teams aufzustellen, und dann sehen, was passiert.

Wenn das Vergütungssystem so angelegt ist, dass es Funktionsbereiche anerkennt und belohnt, sollten Sie das zuerst ändern. Mitarbeiter handeln eventuell erst dann im Interesse des Produkts oder Teams, wenn ihre Vergütung auf positive Weise davon betroffen ist.

123

Tabelle X2-1. Anpassungsrichtlinien (fortges.)

Situation Anpassungsempfehlung

Transparenz kann Angst machen

Viele Teammitglieder besitzen geringes technisches Domänenwissen

Fehlendes Engagement für Agilität durch Führungskräfte

Die Begriffe und Sprache der Agilität passen nicht zur Kultur der Organisation

Agilität schafft eine Kultur der Transparenz: Menschen zeigen und teilen ihre Arbeit während der gesamten Entwicklungsphase. Dieses Teilen von vorläu­gen Liefergegenständen und diese Offenheit und Ehrlichkeit über Erfolge, Niederlagen und den Ist-Zustand nennt man Transparenz. Transparenz erfordert Mut.

Seien Sie Vorbild und zeigen Sie Transparenz in Entscheidungs­ndungsprozessen mithilfe eines Status-Boards.

Agile Ansätze fördern die lokale Entscheidungs­ndung sich selbst leitender Teams über Arbeitspakete, wie Abfolge der Aufgaben und Auswahl eines Problemlösungsansatzes, und nutzen dies auch. Wenn die Mehrheit der Teammitglieder unerfahren ist, können konsensbasierte Ansätze zu Problemen und Nacharbeit führen. Für diese Teams ist eventuell zusätzliche Unterstützung bei der Aufgabenverteilung und Leitung notwendig, bis das Team die nötigen Fähigkeiten erwirbt. Mit anderen Worten: Verkünden Sie nicht einfach, dass nach Agilität gearbeitet wird, und lassen Sie dann ein unerfahrenes Team alles heraus­nden, da sie ermächtigt sind, eigene Entscheidungen zu treffen. Diese eigenen Entscheidungen könnten aufgrund der fehlenden Erfahrung suboptimal ausfallen und erheblichen Schaden anrichten. Stellen Sie lieber Kompetenzzentren auf, die Hilfestellung bieten und Domänenwissen aufbauen.

Wenn das Engagement für Agilität durch Führungskräfte fehlt, gibt es für die Teams einen Kon�ikt zwischen der agilen Denkweise und ihren Ansätzen einerseits und der plangetriebenen Denkweise und ihren Ansätzen andererseits.

Suchen Sie nach Gemeinsamkeiten. Zum Beispiel nach Bereichen, die entsprechend dem Bedarf der Organisation verbessert werden können, und setzen Sie dann Experimente und Retrospektiven für die weitere Entwicklung ein.

Ziehen Sie Ausbildung/Schulungen für Führungskräfte in Betracht. Sie können Agilität auch als „Lean Thinking“ erläutern: kurze Zyklen, kleine Arbeitspaketgrößen, häu­ge Überprüfungen und Retrospektiven mit kleinen Verbesserungen.

Wandeln Sie die Begriffe so ab, dass die Mitarbeiter sie verstehen und mit den Vorgängen (statt mit der Sprache) der Agilität einverstanden sind. Erläutern Sie die präzise Bedeutung der einzelnen Begriffe.

Wenn die Organisation beispielsweise das Wort „Spiel“ unprofessionell ­ndet, dann verwenden Sie Formulierungen wie „Planungsspiel“ nicht. Sagen Sie dann lieber „Planungs-Workshop“.

125

ANHANG X3 WERKZEUGE FÜR DIE AUSWAHL GEEIGNETER AGILER METHODEN

X3.1 EINFÜHRUNG

Die Literatur über Agilität enthält viele Werkzeuge, um festzustellen, unter welchen Umständen welcher agiler Ansatz geeignet ist. 1994 wurde für die Dynamic Systems Development Method (DSDM) ein Fragebogen für Projekte und Organisation entwickelt, um die voraussichtliche Eignung von Agilität sowie mögliche Problemfelder einschätzen zu können.

Die Ansätze der „Crystal“-Familie gingen ebenfalls nach Eignungskriterien vor und platzierten Projekte nach Teamgröße und Kritikalität von Produkt oder Dienstleistung, die es zu entwickeln galt. Nach Empfehlung von Crystal sollten kleinere, weniger kritische Projekte mit weniger straffer Steuerung und einfacheren Ansätzen durchgeführt werden. Bei großen Projekten, von denen Aufträge oder sogar Leib und Leben abhängen, sollte dagegen mehr Sorgfalt und Validierung an den Tag gelegt werden.

Seit der Entwicklung dieser Ansätze wurden noch viele weitere Modelle geschaffen, anhand derer festgestellt werden kann, wo und wann agile Ansätze angemessen sind. Boehm und Turner übernahmen einige Elemente aus der DSDM und von Crystal und entwickelten daraus ein verbreitetes Bewertungsmodell, das der Feststellung dient, ob Projekte mit agilen oder traditionelleren Ansätzen angegangen werden sollen.

Ausgehend von diesen vorherigen Modellen und auch unter Berücksichtigung des Mittelweges hybrider Ansätze wird das folgende Modell vorgestellt. Es ist eine Synthese mehrerer Auswahlwerkzeuge, anhand derer Organisationen bewerten und erörtern können, ob Projekte nach einem plangetriebenen, hybriden oder agilen Ansatz durchgeführt werden sollen.

126 Anhang X3

X3.2 DAS MODELL IM ÜBERBLICK

Organisations- und Projektattribute werden nach drei Hauptkategorien bewertet:

uu Kultur. Ist ein positives Umfeld vorhanden, in dem der Ansatz befürwortet wird und Vertrauen in das Team besteht?

uu Team. Hat das Team die geeignete Größe, um Agilität erfolgreich anzuwenden, haben die Mitglieder die notwendige Erfahrung und Zugang zu Unternehmensvertretern, um erfolgreich zu sein?

uu Projekt. Gibt es hohe Änderungsfrequenzen? Ist eine inkrementelle Lieferung möglich? Wie wichtig ist das Projekt?

Fragen in diesen Kategorien werden beantwortet und die Ergebnisse in einem Spinnendiagramm dargestellt. Wertgruppierungen um den Mittelpunkt der Grafik zeigen eine gute Eignung für agile Ansätze an. Ergebnisse in den Außenbereichen lassen darauf schließen, dass ein plangetriebener Ansatz geeigneter wäre. Bei Werten im mittleren Bereich (zwischen agil und plangetrieben) würde sich ein hybrider Ansatz gut eignen. Ein Beispiel ist in Abb. X3-1 dargestellt.

127

Abb. X3-1. Modell für die Eignung eines agilen Ansatzes

Team

größ

e

E

rfahru

ng

Zugang Engagement Vertrauen Entscheidungs�ndung

Te

am

Kultur

ProjektÄnderungen Kritikalität Lieferung

109876543210 Agil Hybrid Plange-

trieben

128 Anhang X3

X3.3 ANLEITUNG ZUM AUSFÜLLEN

X3.3.1 BEANTWORTEN SIE DEN FRAGEBOGEN ALS GRUPPE

Bei kleinen Projekten kann diese Gruppe einfach aus Sponsor, technischem Leiter und einem Kunden bestehen. Bei größeren Projekten sind daran Vertreter der Sponsorengruppe, des Projektausführungsteams, der betroffenen Unternehmensgruppe(n), der Gruppe(n) für Führung und Aufsicht über das Projekt und der Gemeinschaft der Kunden beteiligt. Kein Stakeholder sollte ein Projekt alleine schätzen oder planen, weil er nur einen Gesichtspunkt vertritt und persönliche Vorlieben hat; und deshalb sollte auch keine einzelne Person die Eignung eines Ansatzes bewerten, weil auch jede Person eine begrenzte und einseitige Perspektive einnimmt.

Vielmehr liegt der Wert des Werkzeugs in dem Diskurs, den es unter den am Projekt beteiligten Parteien fördert. Auch wenn die Ergebnisse auf einen hybriden Ansatz hindeuten, die Stakeholder aber nach einem überwiegend agilen oder plangetriebenen Ansatz verfahren wollen, folgen Sie dem Konsens der Stakeholder. Dieses Werkzeug eignet sich nur zur Diagnose auf hoher Ebene; die endgültige Entscheidung sollte bei den beteiligten Personen liegen und von diesen gestützt werden.

X3.3.2 BEWERTEN SIE DIE FRAGEN VON 1 BIS 10

Besprechen und vereinbaren Sie als Gruppe ein Benotungsschema, das die subjektive Bewertung der Frage am genauesten wiedergibt (oder erarbeiten Sie einen Kompromiss). Definitive Optionen werden mit 1, 5 und 10 nur für den Anfangs-, Mittel- und Endpunkt des Antwortspektrums vorgegeben. Allerdings ist es völlig in Ordnung (und wünschenswert), Noten wie 2 für „fast eine 1, aber nicht ganz“ oder eine 7 für „irgendwo zwischen 5 und 10“ zu vergeben. Diese Bewertung ist eine Diskussionsgrundlage. Ansichten sind subjektiv und es sind Grautöne zu erwarten.

Wenn sich die Gruppe nicht auf eine Note einigen kann, besprechen Sie die Probleme offen und ehrlich. Bevor Sie Kompromisse vorschlagen (d. h. Verwendung von Durchschnittsnoten oder Markierung der Noten vom PMO mit einem blauen X und vom Entwicklungsteam mit einem grünen O), sollten Sie die Erfolgswahrscheinlichkeit des Projekts bedenken, wenn die Teilnehmer nicht einmal bei einer einfachen Benotung ein Einverständnis erzielen können. Wenn bei der Erörterung der Probleme die Meinungsverschiedenheiten aufgedeckt werden können, dann waren Sie erfolgreich; handeln Sie daraufhin eine Vereinbarung aus. Wenn die Bewertung einen plangetriebenen Ansatz nahelegt, aber alle nach einem agilen Ansatz vorgehen wollen (oder umgekehrt), ist das auch in Ordnung. Sie müssen nur die Probleme verstehen und besprechen, wie die Folgen eines solchen Ansatzes gehandhabt werden.

129

X3.3.3 INTERPRETATION DER ERGEBNISSE

Markieren Sie die Antworten auf die Fragen auf einer Spinnendiagrammsvorlage zur Eignungsbewertung und verbinden Sie die einzelnen Punkte. Ergebnisse, die um die Mitte der agilen Zone herum gruppiert sind, lassen auf eine gute Eignung für einen rein agilen Ansatz schließen.

Ergebnisse, die sich überwiegend in der hybriden Zone befinden, deuten darauf hin, dass eine Kombination aus agilen und plangetriebenen Ansätzen am besten geeignet ist. Es ist allerdings auch möglich, dass ein agiler Ansatz mit einigen Schritten zur Risikominderung, wie zusätzliche Einweisung und Schulung oder besondere Sorgfalt bei Validierung und Dokumentation bei äußerst kritischen Projekten, ausreichend ist. Alternativ könnte auch ein plangetriebener Ansatz mit einem gewissen Machbarkeitsnachweis oder zusätzlichen Prozessen funktionieren.

Ergebnisse, die überwiegend in der plangetriebenen Zone angesiedelt sind, lassen auf eine gute Eignung für einen rein plangetriebenen Ansatz schließen. Wie in Abschnitt X3.3.2 (Benotung der Fragen) erwähnt, zielt dieses Diagnosewerkzeug darauf ab, sinnvolle Gespräche mit den betroffenen Parteien über den geeignetsten Ansatz zu führen. Wenn der vom Werkzeug empfohlene Ansatz nicht akzeptabel ist, kann auch ein anderer Ansatz gewählt werden. Nutzen Sie die Ergebnisse als Eingangswerte für den Risikomanagementprozess, weil das Werkzeug Unstimmigkeiten aufzeigt, die gesteuert werden müssen.

X3.4 FRAGEN ZU EIGNUNGSKRITERIEN

X3.4.1 KATEGORIE: KULTUR

X3.4.1.1 ENGAGEMENT FÜR DEN ANSATZ

Besteht bei den leitenden Sponsoren Verständnis und Engagement für die Verwendung eines agilen Ansatzes in diesem Projekt? Siehe Abb. X3-2.

Abb. X3-2. Engagement für die Bewertung des Ansatzes

Teilweise

5Ja

1Nein

10

Bewertung = _______

130 Anhang X3

X3.4.1.2 VERTRAUEN IN DAS TEAM

Betrachten Sie die Sponsoren und Unternehmensvertreter, die mit dem Team arbeiten werden. Sind diese Stakeholder zuversichtlich, dass das Team ihren Leitgedanken und ihre Bedürfnisse in ein erfolgreiches Produkt oder einen erfolgreichen Service verwandeln können? Mit laufender Unterstützung und Feedback in beide Richtungen? Siehe Abb. X3-3.

Abb. X3-3. Vertrauen in die Teambewertung

X3.4.1.3 ENTSCHEIDUNGSBEFUGNISSE DES TEAMS

Darf das Team autonom seine eigenen lokalen Entscheidungen über seine Vorgehensweise treffen? Siehe Abb. X3-4.

Abb. X3-4. Bewertung der Entscheidungsbefugnisse des Teams

WahrscheinlichJa

1

Bewertung = _______

Unwahrscheinlich

10

Wahrscheinlich

5Ja

1Unwahrscheinlich

10

Bewertung = _______

131

X3.4.2 KATEGORIE: TEAM

X3.4.2.1 TEAMGRÖSSE

Wie groß ist das Kernteam? Benutzen Sie die folgende Skala: 1-9 = 1, 10-20 = 2, 21-30 = 3, 31-45 = 4, 46-60 = 5, 61-80 = 6, 81-110 = 7, 111-150 = 8, 151-200 = 9, 201+ = 10. Siehe Abb. X3-5.

Abb. X3-5. Bewertung der Teamgröße

X3.4.2.2 ERFAHRUNG

Betrachten Sie die Erfahrung und Fähigkeiten der Teammitglieder, welche Kernteamrollen besetzen werden. Es ist zwar normal, dass Rollen sowohl von erfahrenen als auch unerfahrenen Personen besetzt werden. Damit agile Projekte reibungslos laufen, sollte jede Rolle zumindest mit einem erfahrenen Mitglied besetzt werden. Siehe Abb. X3-6.

Abb. X3-6. Bewertung der Erfahrung

51 10

Bewertung = _______

Teilweise

5Ja

1Nein

10

Bewertung = _______

132 Anhang X3

X3.4.2.3 ZUGANG ZUM KUNDEN/ZU EIGENEN UNTERNEHMENSVERTRETERN

Wird das Team täglich Zugang zu mindestens einem Vertreter des eigenen Unternehmens/Kunden haben, um Fragen zu stellen und Feedback zu bekommen? Siehe Abb. X3-7.

Abb. X3-7. Bewertung des Zugangs zum Kunden/zu eigenen Unternehmensvertretern

X3.4.3 KATEGORIE: PROJEKT

X3.4.3.1 ÄNDERUNGSWAHRSCHEINLICHKEIT

Welcher Anteil der Anforderungen wird sich wahrscheinlich monatlich ändern oder wird neu dazukommen? Siehe Abb. X3-8.

Abb. X3-8. Bewertung der Änderungswahrscheinlichkeit

25 %

550 %

15 %

10

Bewertung = _______

Teilweise

5Ja

1Nein

10

Bewertung = _______

133

X3.4.3.2 KRITIKALITÄT VON PRODUKT ODER DIENSTLEISTUNG

Bewerten Sie die Kritikalität (geht es nur um Geld oder gar Leib und Leben?) des zu bauenden Produkts oder zu erbringender Dienstleistung, um die voraussichtliche Höhe der vermutlich notwendigen zusätzlichen Sorgfalt bei Verifikation und Dokumentation festzustellen. Stellen Sie mithilfe einer Bewertung, die Verlust aufgrund möglicher Mängel miteinbezieht, fest, wozu ein Scheitern führen könnte. Siehe Abb. X3-9.

Abb. X3-9. Bewertung der Kritikalität von Produkt oder Dienstleistung

X3.4.3.3 INKREMENTELLE LIEFERUNG

Können Produkt oder Dienstleistung inkrementell gebaut und bewertet werden? Stehen Vertreter vom eigenen Unternehmen oder den Kunden zur Verfügung, um zeitnahes Feedback zu den gelieferten Inkrementen zu geben? Siehe Abb. X3-10.

Abb. X3-10. Bewertung der inkrementellen Lieferung

Wesentliche Mittel

5Zeit

1Viele Leben

10Ein LebenFrei verfügbare Mittel

Bewertung = _______

Vielleicht/Manchmal

5Ja

1Unwahrscheinlich

10

Bewertung = _______

134 Anhang X3

X3.5 DIAGRAMM ZUR EIGNUNGSBEWERTUNG

Abb. X3-11 ist das Spinnendiagramm, die zur Eignungsbewertung herangezogen wird.

Abb. X3-11. Spinnendiagramm der Eignungsbewertung

Team

größ

e

E

rfa

hrung

Zugang Engagement Vertrauen Entscheidungs�ndung

Team

Kultur

Projekt

Änderungen Kritikalität Lieferung

109876543210 Agil Hybrid Plange-

trieben

135

X3.5.1 FALLSTUDIEN

Zur Veranschaulichung der Funktionsweise eines Spinnendiagramms zeigen wir Ihnen hier zwei Beispiele zur Verwendung des Modells zur Bewertung sehr unterschiedlicher Projekttypen. Das erste Beispiel betrifft das Projekt einer Online-Apotheke (siehe Abb. X3-12), das zweite (Abb. X3-13) ist ein Beispiel für ein militärisches Nachrichtensystem. Die beiden Fallstudien illustrieren einige Unterschiede, die in Projekten angetroffen werden können. Die Anordnung um die Mitte herum zeigt eine gute Eignung für agile Ansätze an, während Noten im Randbereich plangetriebene Ansätze nahelegen. Manche Projekte gruppieren sich um die Mitte herum, haben aber Ausreißer auf einer oder zwei Achsen. Diese Projekte können am besten mit einem hybriden Ansatz umgesetzt werden.

Abb. X3-12. Apotheken-Projekt

Team

größ

e

E

rfa

hrung

Zugang Engagement Vertrauen Entscheidungs�ndung

Team

Kultur

Projekt

Änderungen Kritikalität Lieferung

109876543210 Agil Hybrid Plange-

trieben

136 Anhang X3

X3.5.1.1 APOTHEKEN-BEISPIEL

Das Projekt bestand aus der Entwicklung einer Online-Apotheke, um preisgünstigere verschreibungspflichtige „Medikamente“ aus Kanada (hauptsächlich) an Kunden in den USA zu verkaufen. Der Verkauf dieser Arzneimittel ist in Kanada und den USA umstritten, und deshalb ist die Branche von schnellen Regulierungsänderungen und scharfem Wettbewerb gekennzeichnet. Das Projekt unterlag äußerst volatilen Anforderungen und großen Änderungen im wöchentlichen Rhythmus. Es arbeitete mit sehr kurzen Iterationen (2 Tage) und wöchentlichen Freigaben, um die hohe Änderungsfrequenz auszugleichen.

In Abb. X3-12 sind ein hohes Niveau an Engagement und Vertrauen bei den Personen sichtbar, die auf eigenständige Weise arbeiten konnten. Da es sich bei dem Projekt um eine Webseite handelte, war es einfach, neue Erweiterungen der Funktionalität zu zeigen. Jedoch die Kritikalität des Systems war ziemlich hoch, weil es um die wirtschaftliche Grundlage der Apotheke, den Vertriebskanal, ging. Wie erwähnt gab es sehr hohe Änderungsfrequenzen, aber das kleine, erfahrene Team wusste damit umzugehen und hatte leichten Zugang zu einem versierten Unternehmensvertreter. Der Ansatz war sehr erfolgreich und äußerst agil.

X3.5.1.2 BEISPIELPROJEKT „MILITÄRISCHES NACHRICHTENSYSTEM“

Im Kontrast zum kleinen Projekt des ersten Beispiels handelt es sich beim zweiten Beispiel um ein Großprojekt zur Entwicklung eines militärischen Nachrichtensystems, das zum Zeitpunkt der Untersuchung bereits seit fünf Jahren lief. Siehe Abb. X3-13.

137

Abb. X3-13. Beispielprojekt „Militärisches Nachrichtensystem“

Team

größ

e

E

rfahru

ng

Zugang Engagement Vertrauen Entscheidungs�ndung

Te

am

Kultur

Änderungen Kritikalität Lieferung

Projekt

109876543210 Agil Hybrid Plange-

trieben

138 Anhang X3

Es gab kaum Befürworter für einen agilen Ansatz, da ein agiler Ansatz nicht in Betracht gezogen wurde. Die Anbieter wurden im Allgemeinen respektiert. Dennoch wurde ihnen sehr unterschiedliches Vertrauen entgegengebracht. Die Entscheidungsfindung fand nicht vor Ort statt, sondern oblag Architektur- und Anforderungsausschüssen. Obwohl es möglich war, Konzeptionselemente inkrementell in einem Labor zu testen, konnte man sie nicht zusammenfügen, um ihre durchgehende Funktionalität nachzuweisen. Viele Menschenleben waren potenziell gefährdet, weshalb die Kritikalität sehr hoch war. Die Anforderungen waren festgeschrieben, weil Änderungen so viele Organisationen von Subunternehmern betrafen.

Das Projekt war sehr groß und umfasste schon bei einem einzigen Lieferanten mehr als 300 Mitarbeiter. Trotz der Größe wurde jede Rolle mit vielen erfahrenen Mitarbeitern ausgefüllt. Und schließlich gab es keinerlei Zugang zum Unternehmen/Kunden. Allerdings standen Vertragsanalysten für Spezifikationen zur Verfügung. Antworten erfolgten in der Regel innerhalb von 10 Tagen oder führten Rückfragen zur weiteren Klärung. Teile des Projekts hätten ausgegliedert und als agile Projekte betrieben werden können, doch im Kern der Initiative steckte ein einzelnes plangetriebenes Großprojekt.

X3.6 ZUSAMMENFASSUNG

Werkzeuge zur Auswahl sind nützlich zur Identifizierung potenzieller Eignung und Lücken der jeweils betrachteten agilen Methoden. Sie sollten nicht als definitive Einschluss- oder Ausschlusskriterien verwendet werden, sondern als Grundlage einer objektiven Diskussion mit allen beteiligten Parteien dienen.

139

QUELLENVERZEICHNIS

[1] Manifest für Agile Softwareentwicklung. (2001). Zitiert nach http://agilemanifesto.org/

[2] Project Management Institute. 2013. Managing Change in Organizations: A Practice Guide. Newtown Square, PA: Verfasser.

[3] Project Management Institute. 2017. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sechste Auflage. Newtown Square, PA: Verfasser.

[4] Project Management Institute. 2013. Software Extension to the PMBOK® Guide Fifth Edition. Newtown Square, PA: Verfasser.

141

LITERATURVERZEICHNIS

Im Folgenden sind, untergliedert nach Abschnitt bzw. Thema, Vorschläge zur weiteren Lektüre aufgeführt:

ABSCHNITT 2 – EINE EINFÜHRUNG IN AGILITÄT

Briggs, Sara. „Agile Based Learning: What Is It and How Can It Change Education?“ Opencolleges.edu.au 22. Februar 2014, zitiert nach http://www.opencolleges.edu.au/informed/features/agile-based-learning-what-is-it-and-how-can-it-change-education/.

Manifesto for Agile Software Development, 2001, http://agilemanifesto.org/.

Peha, Steve. „Agile Schools: How Technology Saves Education (Just Not the Way We Thought it Would).“ InfoQ. 28. Juni 2011, zitiert nach https://www.infoq.com/articles/agile-schools-education.

Principles behind the Agile Manifesto, 2001, http://agilemanifesto.org/principles.html.

Rothman, Johanna. 2007. Manage It! Your Guide to Modern, Pragmatic Project Management. Raleigh: Pragmatic Bookshelf.

Sidky, Ahmed (Keynote). 2015. https://www.slideshare.net/AgileNZ/ahmed-sidky-keynote-agilenz.

Stacey Complexity Model. 2016. http://www.scrum-tips.com/2016/02/17/stacey-complexity-model/.

ABSCHNITT 3 – AUSWAHL DES LEBENSZYKLUS

„Agile Modeling (AM) Home Page: Effective Practices for Modeling and Documentation“, Agile Modeling, (ohne Datum), http://www.agilemodeling.com/

Anderson, David und Carmichael, Andy. 2016. Essential Kanban Condensed. Seattle: Blue Hole Press.

Anderson, David. 2010. Kanban: Successful Evolutionary Change for Your Technology Business. Seattle: Blue Hole Press.

142 Literaturverzeichnis

Benson, Jim und DeMaria Barry, Tonianne. 2011. Personal Kanban: Mapping Work | Navigating Life. Seattle: Modus Cooperandi Press.

Burrows, Mike. 2014. Kanban from the Inside: Understand the Kanban Method, connect it to what you already know, introduce it with impact. Seattle: Blue Hole Press.

Domain Driven Design Community. 2016. http://dddcommunity.org/.

Gothelf, Jeff und Seiden, Josh. 2016. Lean UX: Designing Great Products with Agile Teams. Sebastopol: O’Reilly Media.

Hammarberg, Marcus und Sunden, Joakim. 2014. Kanban in Action. Shelter Island: Manning Publications.

„Kanban“, Wikipedia, zuletzt geändert am 4. Mai 2017, zitiert am 22. November 2016 nach https://en.wikipedia.org/ wiki/Kanban.

„Kanban (development)“, Wikipedia, zuletzt geändert am 4. Mai 2017, zitiert am 29. November 2016 nach https://en.wikipedia.org/wiki/Kanban_(development).

Larsen, Diana und Nies, Ainsley. 2016. Liftoff: Start and Sustain Successful Agile Teams. Raleigh: Pragmatic Bookshelf.

„Learning Kanban“, Leankit, (ohne Datum), https://leankit.com/learn/learning-kanban/.

Leopold, Klaus, und Kaltenecker, Siegfried. 2015. Kanban Change Leadership: Creating a Culture of Continuous Improvement. Hoboken: Wiley.

„Make a big impact with software products and projects!“ Impact Mapping, (ohne Datum), https://www.impactmapping.org/.

Patton, Jeff, und Economy, Peter. 2014. User Story Mapping: Discover the Whole Story, Build the Right Product. Sebastopol: O’Reilly Media.

Reinertsen, Donald. 2009. The Principles of Product Development Flow: Second Generation Lean Product Development. Redondo Beach: Celeritas Publishing.

Rothman, Johanna. „Dispersed vs. Distributed Teams“ Rothman Consulting Group, Inc., 25. Oktober 2010, http://www.jrothman.com/mpd/2010/10/dispersed-vs-distributed-teams/.

Schwaber, Ken, und Sutherland, Jeff „The Scrum Guide™“, Scrum.org, Juli 2016, http://www.scrumguides.org/scrum-guide.html und http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf#zoom=100.

Skarin, Mattias. 2015. Real-World Kanban: Do Less, Accomplish More with Lean Thinking. Raleigh: Pragmatic Bookshelf.

„The High Cost of Multitasking: 40% of Productivity Lost by Task Switching“, Wrike.com, 24. September 2015, https://www.wrike.com/blog/high-cost-of-multitasking-for-productivity/.

Wells, Don. „Extreme Programming: A Gentle Introduction“, Extreme Programming, 8. Oktober 2013, http://www.extremeprogramming.org/.

143

ABSCHNITT 4 – AGILITÄT IMPLEMENTIEREN:

Amabile, Teresa, und Kramer, Steven. 2011. The Progress Principle: Using Small Wins to Ignite Joy, Engagement, and Creativity at Work. Boston: Harvard Business Review Press.

„Early Warning Signs of Project Trouble—Cheat Sheet“, 2017, https://agilevideos.com/wp-content/uploads/2017/02/WarningSignsOfProjectTrouble-CheatSheet.pdf.

Dweck, Carol. 2006. Mindset: The New Psychology of Success. New York: Penguin Random House.

Kaner, Sam. Facilitator’s Guide to Participatory Decision-Making. 3rd ed. 2014. San Francisco: Jossey-Bass.

Keith, Kent. The Case for Servant Leadership. 2008. Westfield: Greenleaf Center for Servant Leadership.

Rothman, Johanna. 2016. Agile and Lean Program Management: Scaling Collaboration Across the Organization. Victoria, British Columbia: Practical Ink.

Rothman, Johanna. „Dispersed vs. Distributed Teams“ Rothman Consulting Group, Inc., 25. Oktober 2010, http://www.jrothman.com/mpd/2010/10/dispersed-vs-distributed-teams/.

Rothman, Johanna. 2007. Manage It! Your Guide to Modern, Pragmatic Project Management. Raleigh: Pragmatic Bookshelf.

Rothman, Johanna. 2016. Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects. Raleigh: Pragmatic Bookshelf.

Schwaber, Ken, und Sutherland, Jeff „The Scrum Guide™“, Scrum.org, Juli 2016, http://www.scrumguides.org/scrum-guide.html und http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf#zoom=100.

Sinek, Simon. 2011. Start with Why: How Great Leaders Inspire Everyone to Take Action. New York: Portfolio, Penguin Random House.

„The High Cost of Multitasking: 40% of Productivity Lost by Task Switching“, Wrike.com, 24. September 2015, https://www.wrike.com/blog/high-cost-of-multitasking-for-productivity/.

EXPERIENCE REPORTS:

„Experience Reports“, Agile Alliance, (ohne Datum), https://www.agilealliance.org/resources/experience-reports/.

ZUSTAND DES PROJEKTES UND DES TEAMS:

„Early Warning Signs of Project Trouble—Cheat Sheet.“ 2017. https://agilevideos.com/wp-content/uploads/2017/02/WarningSignsOfProjectTrouble-CheatSheet.pdf

„TeamHealth Radar – Summary View“, Agilehealth. 2014. http://agilityhealthradar.com/wp-content/uploads/2014/11/bigradar.gif.

144 Literaturverzeichnis

RESSOURCENEFFIZIENZ:

Modig, Niklas, und Åhlström, Pär. 2015. This is Lean: Resolving the Efficiency Paradox. London: Rheologica Publishing.

Rothman, Johanna. „Resource Efficiency vs. Flow Efficiency, Part 5: How Flow Changes Everything”, Rothman Consulting Group, Inc., 20. September 2015, http://www.jrothman.com/mpd/agile/2015/09/resource-efficiency-vs-flow-efficiency-part-5-how-flow-changes-everything/.

SKALIERUNG:

Disciplined Agile 2.X—A Process Decision Framework. 2016. http://www.disciplinedagiledelivery.com/.

Kniberg, Henrik. „Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds“, Crisp, 14. November 2012, http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify.

„Overview—Large Scale Scrum“, LeSS. 2016. http://less.works/.

„SAFe® for Lean Software and System Engineering“, SAFe®. 2016. http://www.scaledagileframework.com/.

KÖNNEN:

Beck, Kent. Paint Drip People, 4. August 2016, https://www.facebook.com/notes/kent-beck/paint-drip-people/1226700000696195/.

„Generalizing Specialists: Improving Your IT Career Skills“, Agile Modeling, (ohne Datum), http://www.agilemodeling.com/essays/generalizingSpecialists.htm.

Hunter, Brittany. „Of Software Designers & Broken Combs“, Atomic Object, 27. Juni 2013, https://spin.atomicobject.com/2013/06/27/broken-comb-people/.

ABSCHNITT 5 – AGILITÄT IMPLEMENTIEREN: AUSLIEFERUNG IN EINER AGILEN UMGEBUNG

Larsen, Diana und Nies, Ainsley. 2016. Liftoff: Start and Sustain Successful Agile Teams. Raleigh: Pragmatic Bookshelf.

RETROSPEKTIVEN:

Derby, Esther und Larsen, Diana. 2006. Agile Retrospectives: Making Good Teams Great. Raleigh: Pragmatic Bookshelf.

Gonçalves, Luis, und Linders, Ben 2015. Getting Value out of Agile Retrospectives: A Toolbox of Retrospective Exercises. Victoria, British Columbia: Leanpub.

145

BACKLOG:

Adzic, Gojko, Bissett, Marjory, und Poppendieck, Tom. 2012. Impact Mapping: Making a Big Impact with Software Products and Projects. Woking, Surrey: Provoking Thoughts.

Patton, Jeff, und Economy, Peter. 2014. User Story Mapping: Discover the Whole Story, Build the Right Product. Sebastopol: O’Reilly Media.

Rothman, Johanna. „We Need Planning; Do We Need Estimation?“ Rothman Consulting Group, Inc., 21. Januar 2015, http://www.jrothman.com/mpd/project-management/2015/01/we-need-planning-do-we-need-estimation/.

STANDUPS:

Brodzinski, Pawel. „Effective Standups around Kanban Board“, Brodzinski.com, 30. Dezember 2011, http://brodzinski.com/2011/12/effective-standups.html.

Fowler, Martin. „It’s Not Just Standing Up: Patterns for Daily Standup Meetings“, Martinfowler.com, 21. Februar 2016, http://martinfowler.com/articles/itsNotJustStandingUp.html.

Hefley, Chris. „How to Run Effective Standups and Retrospectives“, Leankit, 15. September 2014, https://leankit.com/blog/2014/09/run-effective-standups-retrospectives/.

FERTIGSTELLUNGSWERT:

Griffiths, Mike. „A Better S Curve and Simplified EVM“, Leading Answers, 6. Juni 2008, http://leadinganswers.typepad.com/leading_answers/2008/06/a-better-s-curve-and-simplified-evm.html.

ABSCHNITT 6 – ÜBERLEGUNGEN ZUR PROJEKTAGILITÄT IN ORGANISATIONEN

Bankston, Arlen, und Augustine, Sanjiv. Agile Team Performance Management: Realizing the Human Potential of Teams, 14. Juni 2010, www.lithespeed.com/transfer/Agile-Performance-Management.pptx.

Browder, Justin, und Schoeff, Brian. Perfect Strangers: How Project Managers and Developers Relate and Succeed. CreateSpace Independent Publishing Platform, 2016, https://www.createspace.com/.

Griffiths, Mike. „Agile Talent Management“, Leading Answers, 14. Oktober 2015, http://leadinganswers.typepad.com/leading_answers/2015/10/agile-talent-management.html.

Kohn, Alfie. 1999. Punished by Rewards: The Trouble with Gold Stars, Incentive Plans, A’s, Praise, and Other Bribes. New York: Mariner Books.

Mar, Kane. „How to do Agile Performance Reviews“, Scrumology, (ohne Datum), https://scrumology.com/how-to-do-agile-performance-reviews/.

McChrystal, Stanley, Collins,Tantum, Silverman, David, und Fussell, Chris. 2015. Team of Teams: New Rules of Engagement for a Complex World. New York: Portfolio, Penguin Random House.

Pink, Daniel. 2011. Drive: The Surprising Truth About What Motivates Us. New York: Riverhead Books.

146 Literaturverzeichnis

ABSCHNITT 7 – AUFRUF ZUM HANDELN

Dennis, Pascal. 2006. Getting the Right Things Done: A Leader’s Guide to Planning and Execution. Cambridge: Lean Enterprise Institute.

Griffiths, Mike. „Introducing Agile Methods: Mistakes to Avoid—Part 3“, Leading Answers, 15. März 2007, http://leadinganswers.typepad.com/leading_answers/2007/03/introducing_agi_2.html.

Little, Jason. Lean Change Management: Innovative Practices for Managing Organizational Change. Happy Melly Express, 2014, http://www.happymelly.com/category/hm-express/.

Rising, Linda, und Manns, Mary Lynne. 2004. Fearless Change: Patterns for Introducing New Ideas. Upper Saddle River: Addison-Wesley Professional.

„The IDEAL Model“, Software Engineering Institute, Carnegie Mellon, 2006, http://www.sei.cmu.edu/library/assets/idealmodel.pdf.

ANHANG A1 – ZUORDNUNG ZUM PMBOK® GUIDE

Larsen, Diana und Nies, Ainsley. 2016. Liftoff: Start and Sustain Successful Agile Teams. Raleigh: Pragmatic Bookshelf.

ANHANG A2 – ZUORDNUNG ZUM AGILEN MANIFEST

Manifesto for Agile Software Development, 2001, http://agilemanifesto.org/.

Principles behind the Agile Manifesto, 2001, http://agilemanifesto.org/principles.html.

ANHANG A3 – ÜBERBLICK ÜBER AGILE UND „LEAN“-REGELWERKE

Agile Business Consortium, 2014, https://www.agilebusiness.org/what-is-dsdm.

Ambler, Scott. „The Agile Unified Process“, Ambysoft, 13. Mai 2006, http://www.ambysoft.com/unifiedprocess/agileUP.html.

Anderson, David. 2010. Kanban: Successful Evolutionary Change for Your Technology Business. Seattle: Blue Hole Press.

Beedle, Mike. Enterprise Scrum: Executive Summary: Business Agility for the 21st Century, 7. Januar 2017, http://www.enterprisescrum.com/enterprise-scrum/.

147

Cockburn, Alistair. 2004. Crystal Clear: A Human-Powered Methodology for Small Teams. Upper Saddle River: Pearson Education.

Cockburn, Alistair. „Crystal Methodologies“, alistair.cockburn.us, 28. März 2014, http://alistair.cockburn.us/Crystal+methodologies.

Disciplined Agile 2.X—A Process Decision Framework, 2016, http://www.disciplinedagiledelivery.com/.

Joint MIT-PMI-INCOSE Community of Practice on Lean in Program Management. 2012. The Guide to Lean Enablers for Managing Engineering Programs. Newtown Square, PA: Verfasser.

„Kanban“, Wikipedia, zuletzt geändert am 4. Mai 2017, zitiert am 22. November 2016 nach https://en.wikipedia.org/wiki/Kanban.

„Kanban (development)“, Wikipedia, zuletzt geändert am 4. Mai 2017, zitiert am 29. November 2016 nach https://en.wikipedia.org/wiki/Kanban_(development).

Reddy, Ajay, und Speranza, Jack. 2015. The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban. Boston: Addison-Wesley Professional.

„Overview—Large Scale Scrum“, LeSS, 2016, http://less.works/.

„SAFe® for Lean Software and System Engineering“, SAFe®, 2016, http://www.scaledagileframework.com/.

Schwaber, Ken, und Sutherland, Jeff „The Scrum Guide™“, Scrum.org, Juli 2016, http://www.scrumguides.org/scrum-guide.html und http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf#zoom=100.

„Scrum of Scrums“, Agile Alliance, (ohne Datum), https://www.agilealliance.org/glossary/scrum-of-scrums/.

„Scrumban“, Wikipedia, 2. März 2017, https://en.wikipedia.org/wiki/Scrumban.

„State of Agile Report: Agile Trends“, VersionOne, 2017, http://stateofagile.versionone.com/.

Sutherland, Jeff. „Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies.“ Cutter IT Journal 14, Nr. 12 (2001): 5–11. http://www.controlchaos.com/storage/scrum-articles/Sutherland 200111 proof.pdf.

„The 2015 State of Agile Development“, Scrum Alliance®, 2015, https://www.forrester.com/report/The+2015+State+Of+Agile+Development/-/E-RES122910

Wells, Don. „Extreme Programming: A Gentle Introduction“, Extreme Programming, 8. Oktober 2013, http://www.extremeprogramming.org/.

Why Scrum? State of Scrum Report, 2016, https://www.scrumalliance.org/why-scrum/state-of-scrum-report/2016-state-of-scrum.

148 Literaturverzeichnis

ANHANG X2 – ASPEKTE, WELCHE DIE ANPASSUNG BEEINFLUSSEN

Griffiths, Mike. „Agile Suitability Filters“, Leading Answers, 2007, http://leadinganswers.typepad.com/leading_answers/files/agile_suitability_filters.pdf.

Jeffries, Ron. „We Tried Baseball and It Didn’t Work“, ronjeffries.com, May 2, 2006, http://ronjeffries.com/xprog/articles/jatbaseball/.

Rothman, Johanna. „One Experimental Possibility: Self-Organization from Component Teams to Feature Teams“, Rothman Consulting Group, Inc., 23. September 2014, http://www.jrothman.com/mpd/agile/2014/09/one-experimental-possibility-self-organization-from-component-teams-to-feature-teams/.

149

GLOSSAR

1. ABKÜRZUNGEN

ATDD acceptance test-driven development / Acceptance Test-Driven Development (akzeptanztestgetriebene Entwicklung)

BDD behavior-driven development / Behavior-Driven Development (verhaltensgetriebene Entwicklung)

BRD business requirement documents / Business Requirement Documents (Dokumentation der geschäftlichen Anforderungen)

DA Disciplined Agile / Disciplined Agile (diszipliniertes, agiles Rahmenwerk)

DoD definition of done / Definition of Done (Liste von Fertigstellungskriterien)

DoR definition of ready / Definition of Ready (Liste von Arbeitsbereitschaftskriterien)

DSDM Dynamics Systems Development Model / Dynamic Systems Development Method (Dynamische Systementwicklungsmethode)

Evo evolutionary value delivery / Evolutionärer Wertbeitrag

LeSS Large-Scale Scrum / Large-Scale Scrum (groß angelegtes Scrum)

LSD Lean Software Development / Lean Software Development

PDCA Plan–Do–Check–Act / Plan–Do–Check–Act (Planen, Durchführen, Prüfen, Handeln; Demingkreis)

PMO project management office / Projektmanagementbüro (Project Management Office)

ROI return on investment / Kapitalrendite (Return on Investment)

RUP Rational Unified Process / Rational Unified Process

SAFe® Scaled Agile Framework® / Scaled Agile Framework®

SBE specification by example / Specification by Example (Spezifikation durch die Verwendung von Beispielen)

XP eXtreme Programming / eXtreme Programming

150 Glossar

2. DEFINITIONEN

A3 / A3. Eine Denkweise und ein systematischer Problemlösungsprozess, der die relevanten Informationen auf einem einzigen DIN-A3-Bogen zusammenträgt.

Agil / Agile. Ein Begriff, welcher bestimmte Wertvorstellungen und Grundsätze, die im agilen Manifest festgelegt wurden, beschreibt.

Agile Coach / Agile Coach. Eine Person mit Wissen und Erfahrung im agilen Management, die Organisationen und Teams während ihrer Umwandlung schulen, betreuen und anleiten kann.

Agile Denkweise / Agile Mindset. Eine Denk- und Verhaltensweise, die auf den vier Wertvorstellungen und zwölf Grundsätzen des Agilen Manifests beruht.

Agile Prinzipien / Agile Principles. Die zwölf Prinzipien der agilen Projektlieferung gemäß dem Agilen Manifest.

Agile Unified Process / Agile Unified Process. Ein einfacher und verständlicher Entwicklungsansatz für Geschäftsanwendungssoftware mittels agiler Methoden und Konzepte. Dabei handelt es sich um eine vereinfachte Version des Rational Unified Process (RUP).

Agiler Lebenszyklus / Agile Life Cycle. Ein sowohl iterativer als auch inkrementeller Ansatz zur Weiterentwicklung von Aufgaben und häufigen Lieferung.

Agiles Manifest / Agile Manifesto. Die ursprüngliche und offizielle Definition agiler Wertvorstellungen und Grundsätze.

Agilist / Agile Practitioner (also Agilist). Eine Person mit agiler Denkweise, die mit gleichgesinnten Kollegen in funktionsübergreifenden Teams zusammenarbeitet. Wird auch als „Agil Praktizierende(r)“ bezeichnet.

Akzeptanztestgetriebene Entwicklung (Acceptance Test-Driven Develoment, ATDD) / Acceptance Test-Driven Development (ATDD). Eine Methode zur gemeinschaftlichen Erstellung von Akzeptanztestkriterien, die vor Aufnahme der Auslieferung zur Ausarbeitung von Abnahmeprüfungen herangezogen werden.

Anti-Muster / Anti-Pattern. Ein bekanntes, fehlerhaftes und deshalb nicht empfehlenswertes Arbeitsmuster.

Auswirkungszuordnung / Impact Mapping. Eine strategische Planungsmethode, die der Organisation beim Bau neuer Produkte als Wegweiser dient.

Automatische Codequalitätsanalyse / Automated Code Quality Analysis. Die skriptgesteuerte Prüfung der Quellcodebasis auf Fehler und Schwachstellen.

Backlog / Backlog. Siehe Produkt-Backlog.

Backlog Refinement (Feinabstimmung des Backlogs) / Backlog Refinement. Die fortschreitende Ausarbeitung von Projektanforderungen bzw. der laufende Vorgang, bei der/dem das Team gemeinsam Anforderungen prüft, aktualisiert und aufstellt, um den im Kundenauftrag gestellten Bedarf zu erfüllen.

Blocker / Blocker. Siehe Hindernis.

Broken Comb / Broken Comb. Das Bild des „gebrochenen Kamms“ bezieht sich auf eine Person mit unterschiedlichem Spezialisierungsgrad auf mehreren, vom Team benötigten Fachgebieten. Wird auch als „paint drip“ (Farbtropfen) bezeichnet. Siehe auch T-shaped und I-shaped.

Burndown Chart / Burndown Chart. Grafische Darstellung der verbleibenden Arbeit im Vergleich zu der in einer Timebox verbleibenden Zeit.

151

Burnup Chart / Burnup Chart. Grafische Darstellung der erledigten Arbeit auf dem Weg zur Freigabe eines Produkts.

Collective Code Ownership / Collective Code Ownership. Die „gemeinsame Verantwortung für den Code“ ist eine Methode zur Beschleunigung der gemeinsamen Projektarbeit, bei der jeder im Team befugt ist, beliebige Produkte der Projektarbeit oder Liefergegenstände zu verändern; dadurch werden Verantwortungsgefühl und Rechenschaft im gesamten Team gestärkt.

Daily Scrum / Daily Scrum. Eine kurze, täglich anberaumte Teambesprechung, bei der die Fortschritte vom Vortag geprüft, die Ziele für den aktuellen Tag aufgestellt und aufgetretene oder zu erwartende Hindernisse beleuchtet werden. Wird auch als Daily Standup bezeichnet.

Definition of Done (DoD) / Definition of Done (DoD). Die Prüfliste eines Teams zu allen Kriterien, die erfüllt werden müssen, damit ein Liefergegenstand als einsatzbereit für den Kunden betrachtet werden kann.

Definition of Ready (DoR) / Definition of Ready (DoR). Die Prüfliste eines Teams für eine anwenderzentrierte Anforderung, die alle notwendigen Informationen besitzt, damit das Team die Arbeit daran aufnehmen kann.

DevOps / DevOps. Eine Sammlung von Praktiken zur Erzeugung eines reibungslosen Lieferflusses durch bessere Zusammenarbeit zwischen Entwicklungs- und Betriebspersonal.

Dienende Führung / Servant Leadership. Die Praxis, durch Dienst am Team zu führen; man konzentriert sich darauf, die Bedürfnisse und Weiterentwicklung der Teammitglieder zu verstehen und zu bedienen, um die höchstmögliche Teamleistung herbeizuführen.

Diszipliniertes, agiles Regelwerk (Disciplined Agile, DA) / Disciplined Agile (DA). Ein Prozessentscheidungsrahmen, der vereinfachte Prozessentscheidungen zu inkrementellen und iterativen Lösungsbeiträgen ermöglicht.

Dokumentation der geschäftlichen Anforderungen (Business Requirement Documents, BRD) / Business Requirement Documents (BRD). Aufstellung aller Anforderungen für ein bestimmtes Projekt.

Doppelschleifen-Lernen / Double-Loop Learning. Ein Prozess, der die zugrunde liegenden Werte und Annahmen hinterfragt, um Ursachen besser herauszuarbeiten und bessere Gegenmaßnahmen zu entwickeln, statt nur auf die Symptome zu achten.

Dynamic Systems Development Method (DSDM) / Dynamic Systems Development Model (DSDM). Ein Regelwerk zur agilen Projektauslieferung.

Einzelschleifen-Lernen / Single-Loop Learning. Die Praxis, Probleme nur durch bestimmte, im Voraus definierte Methoden zu lösen, ohne die Methoden in Anbetracht der gemachten Erfahrungen zu hinterfragen.

Evolutionärer Wertbeitrag (Evo) / Evolutionary Value Delivery (Evo). Wird allgemein als die erste agile Methode gewürdigt, die im Gegensatz zu allen anderen Methoden eine besondere Komponente enthält: die Ausrichtung auf die Bereitstellung mehrerer messbarer Wertanforderungen an die Stakeholder.

eXtreme Progamming / eXtreme Programming. Eine agile Softwareentwicklungsmethode, die zu höherwertiger Software, besserer Reaktionsfähigkeit auf Änderungen in den Anforderungen des Kunden und zu häufigeren Produktfreigaben in kürzeren Zyklen führt.

Feature-Gesteuerte Entwicklung (Feature-Driven Development) / Feature-Driven Development. Eine leichtgewichtige agile Softwareentwicklungsmethode, ausgerichtet auf die Funktionalitäten, die für den Kunden von Wert sind.

152 Glossar

Flow Master / Flowmaster. Der Coach für ein Team und Manager von Serviceaufträgen, der im kontinuierlichen Arbeitsfluss oder Kanban-Kontext tätig ist. Entspricht dem Scrum Master.

Fortlaufende Auslieferung / Continuous Delivery. Die Praxis, inkrementelle Veränderungen an Features sofort an den Kunden auszuliefern, oft mittels kleiner Arbeitspakete und Automatisierung.

Fortlaufende Integration / Continuous Integration. Eine Praxis, bei der die Arbeitsergebnisse aller Teammitglieder häufig integriert und untereinander validiert werden.

Fortschreitende Ausarbeitung / Progressive Elaboration. Ein iterative Prozess, welcher den Detailgrad eines Projektmanagementplans schrittweise erhöht, wenn mehr Informationen und genauere Abschätzungen verfügbar werden.

Funktionale Anforderung / Functional Requirement. Ein bestimmtes Verhalten, das ein Produkt oder eine Dienstleistung an den Tag legen sollte.

Funktionale Spezifikation / Functional Specification. Eine bestimmte Funktion, die ein System oder eine Anwendung ausführen muss. Wird in der Regel in einem entsprechenden Dokument für funktionale Spezifikationen dargestellt.

Funktionsübergreifendes Team / Cross-Functional Team. Ein Team aus Fachleuten, die alle notwendigen Fähigkeiten zur Lieferung nützlicher Produktinkremente besitzen.

Gebrauchstauglich / Fit for Use. Beschreibt ein Produkt, das in seiner aktuellen Form verwendet werden kann, um seinen beabsichtigten Zweck zu erfüllen.

Gemischte, agile Methodik / Blended Agile. Zwei oder mehr agile Rahmenwerke, Methoden, Elemente oder Praktiken, die gemeinsam verwendet werden, beispielsweise Scrum gemischt mit XP und Kanban-Methode.

Hindernis / Impediment. Eine Hürde, die das Team am Erreichen seiner Ziele hindert. Wird auch als Blocker bezeichnet.

Hoshin-Management / Hoshin Kanri. Eine Strategie oder Methode zur Aufstellung von Vorschriften.

Hybrider Ansatz / Hybrid Approach. Eine Kombination aus zwei oder mehr agilen und nicht agilen Elementen, die zu einem nicht agilen Endergebnis führen.

IDEAL / IDEAL. Ein Modell zur Organisationsverbesserung, das nach den fünf Phasen benannt ist, die es beschreibt: Initiating, Diagnosing, Establishing, Acting, Learning (Initiieren, Diagnostizieren, Einrichten, Ausüben, Lernen).

Information Radiator / Information Radiator. Eine gut sichtbare, fassbare Anzeigetafel, auf der Informationen für den Rest der Organisation mitgeteilt werden und die Weitergabe von aktuellem Wissen ohne Störung des Teams ermöglicht.

Inkrement / Increment. Ein funktionaler, geprüfter und akzeptierter Liefergegenstand, welcher eine Teilmenge des allgemeinen Projektergebnisses bildet.

Inkrementaller Lebenszyklus / Incremental Life Cycle. Ein Ansatz zur Bereitstellung fertigerLiefergegenstände, die der Kunde ggf. unmittelbar verwenden kann.

I-shaped / I-shaped. Bezieht sich auf eine Person mit hochgradiger Spezialisierung in einem Bereich und keinerlei Wissen oder Kompetenz auf den übrigen vom Team benötigten Wissensgebieten. Siehe auch T-shaped und Broken Comb.

Iteration / Iteration. Der Entwicklungszyklus eines Produkts oder Liefergegenstands in einer Timebox, in dem die gesamte Arbeit, die zur Auslieferung des Werts notwendig ist, erledigt wird.

Iterativer Lebenszyklus / Iterative Life Cycle. Ein Ansatz, der Feedback zulässt, damit unfertige Arbeiten verbessert und verändert werden können.

153

Kadenz / Cadence. Ausführungsrhythmus. Siehe auch Timebox.

Kaizen-Ereignisse / Kaizen Events. Ereignisse, die auf die Verbesserung des Systems abzielen.

Kanban-Methode / Kanban Method. Eine agile Methode, die sich am ursprünglichen Kanban-System zur Lagerbestandskontrolle orientiert und speziell für Wissensarbeit eingesetzt wird.

Kanban-Board / Kanban Board. Visualisierungsinstrument; es ermöglicht Verbesserungen am Arbeitsfluss, indem es Engpässe und Arbeitsmengen sichtbar macht.

Large-Scale Scrum (Groß angelegtes Scrum, LeSS) / Large-Scale Scrum (LeSS). Large-Scale Scrum ist ein Regelwerk zur Produktentwicklung, das Scrum mit Richtlinien zur Skalierung ausstattet und gleichzeitig die ursprünglichen Zwecke des Scrum beibehält.

“Lean”-Softwareentwicklung (Lean Software Development, LSD) / Lean Software Development (LSD). “Lean”-Softwareentwicklung ist eine Anpassung von “Lean”-Fertigungsprinzipien und -praktiken an den Bereich der Softwareentwicklung; sie beruht auf einer Anzahl von Grundsätzen und Praktiken zu Qualität, Schnelligkeit und Ausrichtung auf den Kunden.

Lebenszyklus / Life Cycle. Der Prozess, in dem ein Produkt erdacht, geschaffen und verwendet wird.

Methoden der “Crystal”-Familie / Crystal Family of Methods. Eine Sammlung leichtgewichtiger, agiler Softwareentwicklungsmethoden, die sich auf die Anpassungsfähigkeit an einen bestimmten Umstand konzentrieren.

Mob-Programming / Mobbing. Eine Methode, bei der mehrere Teammitglieder sich gleichzeitig auf eine bestimmte Aufgabe konzentrieren und ihre Beiträge koordinieren.

Neigung der Organisation / Organizational Bias. Die Vorlieben einer Organisation auf mehreren Skalen, ausgedrückt in den folgenden Grundwerten: Erkundung gegenüber Ausführung, Schnelligkeit gegenüber Stabilität, Quantität gegenüber Qualität sowie Flexibilität gegenüber Vorhersehbarkeit.

Paararbeit / Pair Work. Eine Methode, bei der zwei Teammitglieder gleichzeitig an derselben Aufgabe arbeiten.

Paarprogrammierung / Pair Programming. Arbeit zu zweit, die auf das Programmieren konzentriert ist.

Paarweises Arbeiten / Pairing. Siehe Paararbeit.

Paint Drip / Paint Drip. Siehe Broken Comb.

Persona / Personas. Ein archetypischer Anwender, der für eine Gruppe ähnlicher Endnutzer steht und mit seinen Zielen, Beweggründen und repräsentativen persönlichen Eigenschaften beschrieben wird.

Plan–Do–Check–Act (PDCA) / Plan–Do–Check–Act (PDCA). Eine iterative Managementmethode zum Planen, Durchführen, Überprüfen, Handeln, die in Organisationen zur Unterstützung der Steuerung und kontinuierlichen Verbesserung von Prozessen und Produkten eingesetzt wird.

Plangesteuerter Ansatz / Plan-Driven Approach. Siehe Plangetriebener Ansatz.

Plangetriebener Ansatz / Predictive Approach. Ein Arbeitsmanagementansatz, der während des gesamten Lebenszyklus eines Projekts einen Arbeitsplan und das Management dieses Arbeitsplans einsetzt.

Produkt-Backlog / Product Backlog. Eine geordnete Liste anwenderzentrierter Anforderungen, die ein Team für ein Produkt pflegt.

154 Glossar

Produktverantwortlicher / Product Owner. Eine Person, die für die Maximierung des Produktwerts verantwortlich ist und letzten Endes die Verantwortung für das erzeugte Endprodukt übernimmt und darüber Rechenschaft ablegt. Siehe auch Service Request Manager.

Projektmanagementbüro / Project Management Office (PMO). Eine Projektmanagementstruktur, die projektbezogene Führungsprozesse standardisiert und die Verteilung von Ressourcen, Methodologien, Werkzeugen und Methoden unterstützt.

Rahmenwerk (auch Regelwerk) / Framework. Ein grundlegendes System bzw. Gedanken- oder Faktengebäude zur Unterstützung eines bestimmten Ansatzes.

Refaktorierung / Refactoring. Eine Methode für die Produktqualität, bei der die Gestaltung eines Produkts durch Erhöhung seiner Wartungsfreundlichkeit und anderer erwünschter Eigenschaften verbessert wird, ohne das erwartete Produktverhalten zu ändern.

Retrospektive / Retrospective. Ein regelmäßig stattfindender Workshop, bei dem die Teilnehmer ihre Arbeit und Ergebnisse untersuchen mit dem Ziel, sowohl den Prozess als auch das Produkt zu verbessern.

Rollierende Planung / Rolling Wave Planning. Eine iterative Planungsmethode, bei der die kurzfristig zu erledigende Arbeit im Detail geplant wird, während in der Zukunft liegende Arbeit auf einer höheren Ebene geplant wird.

Scaled Agile Framework (SAFe®) / Scaled Agile Framework (SAFe®). Eine Wissensbasis integrierter Muster für Lean-Agile-Entwicklung auf Unternehmensebene.

Schwenk / Pivot. Eine geplante Kurskorrektur, die zum Austesten einer neuen Hypothese über das Produkt oder die Strategie gedacht ist.

Scrum / Scrum. Ein agiles Regelwerk zur Entwicklung und Pflege komplexer Produkte; enthält spezifische Rollen, Ereignisse und Objekte.

Scrum Master / Scrum Master. Der Coach des Entwicklungsteams und Prozessverantwortliche im Scrum-Rahmenwerk. Räumt Hindernisse aus dem Weg, ermöglicht produktive Meetings und schützt das Team vor Störungen. Siehe auch Flow Master.

Scrum of Scrums / Scrum of Scrums. Eine Methode, um Scrum für mehrere Teams zu dimensionieren, die am selben Produkt arbeiten; damit werden Gespräche zum Fortschritt ihrer gegenseitigen Abhängigkeiten koordiniert und der Fokus darauf gerichtet, wie die Bereitstellung der Software, insbesondere in sich überschneidenden Bereichen, integriert werden kann.

Scrum-Tafel / Scrum Board. Ein Information Radiator, der zur Verwaltung des Produkts und für Sprint Backlogs verwendet wird und den Arbeitsfluss sowie seine Engpässe aufzeigt.

Scrum Team / Scrum Team. Beschreibt die Kombination aus Entwicklungsteam, Scrum Master und Produktverantwortlichem in Scrum.

Scrumban / Scrumban. Ein Managementrahmen, der sich ergibt, wenn Teams Scrum als ihre gewählte Arbeitsweise verwenden und die Kanban-Methode als Perspektive nutzen, aus der sie ihre Arbeitsweise betrachten, verstehen und fortlaufend verbessern können.

Service Request Manager (Serviceanfragemanager) / Service Request Manager. Die Person, die für die Bestellung von Service Requests (Serviceanfragen) verantwortlich ist, um Wert in einer kontinuierlichen Arbeitsfluss- oder Kanban-Umgebung zu maximieren. Entspricht dem Product Owner.

155

Sich selbst organisierendes Team / Self-Organizing Team. Ein funktionsübergreifendes Team, dessen Mitglieder je nach Bedarf nahtlos die Führung übernehmen, um die Ziele des Teams zu erreichen.

Silo-Organisation / Siloed Organization. Eine Organisation, deren Struktur nur den Beitrag zu einer Teilmenge der Aspekte zulässt, die für den Wertbeitrag an den Kunden notwendig sind. Siehe als Gegenteil dazu Wertstrom.

Smoke Test / Smoke Testing. Die Verwendung einer leichtgewichtigen Testreihe, mit der sichergestellt werden soll, dass die wichtigsten Funktionen des in der Entwicklung befindlichen Systems wie beabsichtigt laufen.

Spezifikation durch die Verwendung von Beispielen (specification by example, SBE) / Specification by Example (SBE). Ein kollaborativer Ansatz zur Definition von Anforderungen und geschäftsorientierten Funktionstests für Softwareprodukte, bei dem die Anforderungen durch realistische Beispiele statt durch abstrakte Aussagen erfasst und dargestellt werden.

Spike / Spike. Eine kurze Zeitspanne innerhalb eines Projekts, meist von fester Dauer, in der ein Team einen Lösungsaspekt untersucht oder einen Prototyp dazu anfertigt, um die Machbarkeit der Lösung nachzuweisen.

Sprint / Sprint. Beschreibt eine Iteration mit Timebox in Scrum.

Sprint-Backlog / Sprint Backlog. Eine Liste der vom Scrum-Team identifizierten Aufgaben, die während des Scrum Sprint fertiggestellt werden müssen.

Sprint-Planung / Sprint Planning. Eine Gemeinschaftsaktion in Scrum, bei der das Scrum-Team die Arbeit für den aktuellen Sprint plant.

Story Point / Story Point. Ein Wert ohne Messeinheit, der in relativen User-Story-Schätzmethoden verwendet wird.

Swarming / Swarming. Eine Methode, bei der mehrere Teammitglieder sich gemeinsam auf die Lösung eines bestimmten Hindernisses konzentrieren.

Technical Debt / Technical Debt. Die verzögerten Kosten von Arbeiten, die nicht zu einem früheren Punkt im Produktlebenszyklus erledigt wurden.

Testgetriebene Entwicklung / Test-Driven Development. Eine Methode, bei der Tests vor Aufnahme der Arbeit definiert werden, damit die laufende Projektarbeit kontinuierlich validiert und eine Einstellung auf fehlerfreies Arbeiten möglich wird.

Timebox / Timebox. Ein fester Zeitabschnitt, zum Beispiel eine Woche, 14 Tage, drei Wochen oder ein Monat. Siehe auch Iteration.

T-shaped / T-shaped. Bezieht sich auf eine Person mit hochgradiger Spezialisierung in einem Bereich und allgemeinen Kompetenzen auf den übrigen vom Team benötigten Wissensgebieten. Siehe auch I-shaped und Broken Comb.

User Story / User Story. Eine kurze Beschreibung des Werts eines Auslieferung für einen bestimmten Anwender. Es handelt sich um das Versprechen, ein Gespräch zu führen, um Einzelheiten zu klären.

User-Story-Zuordnung / User Story Mapping. Die visuelle Gliederung von Arbeit in ein nützliches Modell; sie trägt zum Verständnis der Gruppen hochwertiger Features bei die im Lauf der Zeit erstellt werden sollen, identifiziert Auslassungen im Backlog und ermöglicht die effektive Planung von Releases, die Anwendern Wert bieten.

UX-Design / UX Design. Der Prozess zur Verbesserung des Benutzererlebnisses (englisch: User Experience), bei dem man sich auf die Verbesserung von Anwendbarkeit und Zugänglichkeit konzentriert, die sich in der Wechselbeziehung zwischen Anwender und Produkt ergeben.

156 Glossar

Veränderungsmanagement / Organizational Change Management. Ein umfassender, zyklischer und strukturierter Ansatz für den Wechsel von Einzelpersonen, Gruppen und Organisationen von ihrem gegenwärtigen Zustand zu einem künftigen Zustand mit dem Ziel, geschäftlichen Nutzen daraus zu erzielen.

Verhaltensgetriebene Entwicklung (Behavior-Driven Development, BDD) / Behavior-Driven Development (BDD). Eine Praxis zur Systemgestaltung und -validierung, die nach testgetriebenen Grundsätzen und mit Skripts arbeitet, die an die englische Sprache angelehnt sind.

Wertstrom / Value Stream. Ein Organisationskonstrukt, das sich auf den Wertfluss an die Kunden in Form von Lieferung bestimmter Produkte oder Dienstleistungen konzentriert.

Wertstromanalyse / Value Stream Mapping. Eine Methode des “Lean”-Unternehmensmanagements zur Dokumentation, Analyse und Verbesserung des Flusses von Informationen oder Werkstoffen, die zur Erzeugung eines Produkts oder einer Dienstleistung für einen Kunden notwendig sind.

Zweckdienlich / Fit for Purpose. Beschreibt ein Produkt, das für seinen beabsichtigten Zweck geeignet ist.

157

INDEX

AA3, 150Abhängigkeiten, Koordination mehrere Teams und, 80Abnahmekriterien

Ausführungspraktiken und, 56Iterationen und, 63

Agildefiniert, 150Implementierung von, 33–47Popularisierung des Begriffs, 10Übernahme von, 87verschiedene Ansätze und, 11

Agile Alliance, 1, 43Agile Coach, 150Agile Denkweise

Agiles Manifest und, 8–12, 10ausgehend mit, 33definiert, 150Silo-Organisationen und, 47Tempo der Veränderungen und, 3universale Anwendung von, 87Zusammenarbeit mit dem Kunden, 81

Agile Eignungsfilter, 25Agile Methoden

Kanban-Methode und, 12Regelwerke und, 11, 80

Agile Praktiken, 50–57Agile Prinzipien

agilitätsbasiertes Lernen und, 2Änderungsbereitschaft und, 73definiert, 150funktionsübergreifende Teams und, 43

Agile Rollen, 40–41

Agile TeamsAspekte von erfolgreichen, 39–40Rollen in, 40–41

Agile Umgebung, Schaffung, 33–47Agile Unified Process, 150Agiler Ansatz

Komponenten von, 10mischen, 31plangetriebener Ansatz verbunden mit, 27plangetriebene Komponente und, 28Umstellung auf, 73

Agiler Lebenszyklusagiles Manifest und, 25definiert, 150flussbasiert, 24iterationsbasiert, 24Kontinuum der Lebenszyklen und, 19Merkmale, 24–25

Agiles Manifestagile Lebenszyklen und, 25definiert, 150Denkweise und, 8–12Praktiken und, 10Prinzipien von, 9, 10, 50Veröffentlichung von, 87Werte von, 2, 8, 10, 35, 77zentrale Säulen, 38

Agiles PMO Siehe ProjektmanagementbüroAgilist

definiert, 150Rolle des Projektmanagers und, 37

Agilität einer Organisation, Hindernisse für, 74Agilitätsbasiertes Lernen, 2

158 Index

Akzeptanztestgetriebene Entwicklung (Acceptance Test-Driven Development – ATDD)definiert, 150Lieferung des Werts und, 56

Akzeptanztests, 82Allgemeine Spezialisten, 42An XP angelehnte Entwicklungspraktiken, 31Anbieter, Projektwissen und, 83Änderung(en). Siehe auch Unsicherheit

agiler Ansatz und, 73Anforderungen und, 24Bereitschaft für, 73–74Kanban-Board und, 85Hindernisse für, 74schnellere Lieferung und, 73Sicherheit und, 75Tempo von, agile Denkweise und, 3

Änderungsantragsverfahren, 7, 8–12Änderungssteuerungsgremien, 35Anforderungen

alle angehen, 39Burnup-/Burndown-Charts für Features und, 67fehlende, 60iterative Erkundung von, 15Kultur und, 75prognostizierte Lebenszyklen und, 20Prototypen und, 22Unsicherheit und, 13, 14, 16, 22, 24

Angehäufte Arbeit, 70verschwendete, 14

Anpassunghybride Umstellung und, 30Lieferung von Wert und, 87PMO und, 81Projektfaktoren mit Einfluss, 32Prozesse und, 15, 28verfrühte und planlose, 12

AnsatzMischung von, 31Verwendung des Begriffs im Guide, 11

Ansatz des „Beginne dort, wo du bist“, 13, 16Ansatz für Obergrenzen für Zeit und Material, 78Anti-Muster

definiert, 150Standups und, 55

Arbeit, angehäufte, 70Arbeitsplätze des Teams, 46Arbeitsvereinbarungen, 50Arbeitszuweisung, 27ATDD. Siehe Acceptance Test-Driven DevelopmentAufgabentafel. Siehe auch Kanban-Board;

Projektaufgabentafel durchgehen, 53Aufruf zum Handeln, 87Auftrag, Projekt, 49–50Ausführungspraktiken, 56Auswirkungszuordnung

definiert, 150Produktverantwortlicher und, 52

Automatische Codequalitätsanalyse, 150Automatische Tests, 31, 56Automatisierung, 7

BBacklog. Siehe Produkt-BacklogBacklog Refinement (Feinabstimmung des Backlogs),

52–53definiert, 150Länge der Feinabstimmung und, 52Meetings durchführen für, 53

Basispläne, 61Batch-Größen, 42BDD. Siehe Behavior-Driven DevelopmentBerliner Flughafen, 15Beschaffung

Geschäftspraktiken und, 79Verträge und, 77–79

Beschaffungslastige Organisationen, 83Beschränkungen, 20, 31, 42Beziehung zwischen Kunde und Lieferant, Zerfall, 77Blocker. Siehe HindernisBRD. Siehe Dokumentation der geschäftlichen AnforderungenBroken Comb, 150Budgetierung, inkrementelle, 36Burndown-Chart

definiert, 150Feature-Grafiken und, 67Story Points und, 62

159

Burnup-/Burndown-Chart für Features, 67Burnup-Chart

Änderung von Inhalt und Umfang und, 64definiert, 151Feature-Grafiken und, 67Fertigstellungswert und, 68–69Produkt-Backlog, 68Story Points und, 63

CCloud Computing, 3Coaching, 38, 55Collective Code Ownership, 151CPI. Siehe Kostenentwicklungsindex

DDA. Siehe Diszipliniertes agiles RegelwerkDaily Scrum, 151Daily Standups, 27, 44, 53–54

Anti-Muster und, 54flussbasierte agile, 54iterationsbasierte agile, 53

Dedizierte Teammitglieder, 44–45Definierbare Arbeitsprojekte, 7Definition of Done (DoD), 151Definition of Ready (DoR), 151Denkprozess. Siehe agile DenkweiseDenkweise. Siehe agile DenkweiseDenkweise für Zusammenarbeit mit dem Kunden, 81DevOps, 151Dienende Führung

agile Teams und, 39Befähigung von Teams und, 33–38definiert, 151Eigenschaften, 34Moderation und, 35, 52organisatorische Hindernisse und, 35Projektmanager und, 38Projektmanager unter Verwendung, 38Rolle, 33Teamaufstellungsprozess und, 49, 50Verantwortung von, 34, 36–37

Dienstleistung(en); Service(s)Lieferung von, 35PMO und, 82

Disciplined Agile (DA), 80, 151. Disruptive Technologien, 2, 3Diszipliniertes, agiles Regelwerk, 151. Siehe Disciplined

Agile (DA)DoD. Siehe Definition of DoneDokumentation der geschäftlichen Anforderungen (BRD),

151Doppelschleifen-Lernen, 151DoR. Siehe Definition of ReadyDSDM. Siehe Dynamic Systems Development MethodDurchflusseffizienz, 42Durchsatz, 42

Multitasking und, 44Produktverantwortlicher und, 66Standups und, 54

Dynamic Systems Development Method (DSDM), 151Dynamischer Ansatz zur Auftragsvergabe von Inhalt und

Umfang, 78

EEignungsfilter, 25Einzelschleifen-Lernen, 151Elemente außerhalb von Inhalt und Umfang, 4Elemente innerhalb von Inhalt und Umfang, 4Elemente innerhalb und außerhalb des Leitfadens, 4Emotionale Intelligenz., 36Engpässe, 35, 42, 64Entwicklungsprozess „Follow the Sun“, 44Erwartungen, Festlegen von, 45EV. Siehe FertigstellungswertEVM-Kennzahlen, traditionelle, 69EVO. Siehe Evolutionärer WertbeitragEvolutionärer Wertbeitrag (Evo), 151eXtreme Programming (XP)

definiert, 151Lieferung des Werts und, 56Mischung von Ansätzen und, 31Zusammenarbeit und, 80

FFachleute (SMEs), 43, 82Feature-gesteuerte Entwicklung, 151Feature-Grafiken, 67

160 Index

Feedbackagile Teams und, 39, 42Integration von, 43Iterationen und, 57Planung und, 29Präsentationen und, 55Prototypen und, 22, 23Verschwendung, Nacharbeit und, 15

Feedback-Schleifen, 2, 15Feinabstimmung des Backlogs. Siehe Backlog Refinement

(Feinabstimmung des Backlogs)Fertige Arbeit. Siehe WertFertigstellungswert (EV), 61

fertige Features und, 67–68Messung von, 68–69

Fertigstellungszeitflussbasierte agile Teams und, 64interne Abhängigkeiten und, 66Vorlaufzeit und, 66

Festpreis von Miniliefergegenständen, 77Fishbowl-Windows, 46Flow Master, 152Flussbasierter agile Lebenszyklus

iterationsbasierter agiler im Vergleich mit, 24, 25Standups und, 54

Flussdiagramm, kumulatives, 70, 82Fortlaufende Auslieferung, 152Fortlaufende Integration

definiert, 152Lieferung des Werts und, 56Mischung von Ansätzen und, 31

Fortschreitende Ausarbeitung, 152. Siehe auch Backlog Refinement

Fortschrittsnachverfolgung, 27. Siehe auch Kanban-BoardFunktionale Anforderung, 152Funktionale Spezifikation, 152Funktionale Strukturen, 83Funktionsübergreifende(s) Team(s)

agile Prinzipien und, 43definiert, 152dienende Führung und, 33funktionale Produktinkremente und, 39Geschäftspraktiken und, 79Produktentwicklung und, 43Projekte mit hohem Änderungsaufkomnen und, 38Projektführung und, 47Rolle, agiles Teammitglied, 41Scrum-Regelwerk und, 31

GGebrauchstauglich, 152Gemischte agile Methodik, 152Geografisch verteilte Projektorganisationen, 83Geografisch verteilte Teams, 46Geschäftspraktiken, 79Geschäftsservice. Siehe Serive(s)Geschwindigkeit

definiert, 64relative Schätzung und, 67

Groß-angelegtes Scrum. Siehe Large-Scale ScrumGrundlagen, 1–5

agilitätsbasiertes Lernen und, 2disruptive Technologien und, 3Elemente innerhalb und außerhalb von Inhalt und Umfang, 4Entwicklung des Guide, 1Strukturierung des Guide, 5Zweck des Guide, 2

Grundlagen des Guide. Siehe GrundlagenGrundregeln, 50Gruppennormen, 50Guide to the Project Management Body of Knowledge, A.

Siehe PMBOK Guide

HHindernis(se)

definiert, 152dienende Führung und, 35

Hindernisse, Agilität einer Organisation und, 74Hoshin-Management, 152Humanressourcen; Personalwesen, 79, 82Hürden innerhalb der Organisation, 35Hybrider Ansatz, 27, 152Hybrider Lebenszyklus

als Übergangsstrategie, 30als zweckdienlich, 29Beispiel für, 26Merkmale davon, 26–27

IIDEAL, 152Information Radiator, 152Inhalts- und Umfangszuwachs (schleichend), 28Inkrement(e), Lieferung eines Arbeitserzeugnisses und, 57Inkrementelle Vorhaben, 20

161

Inkrementeller Lebenszyklusdefiniert, 152Kontinuum der Lebenszyklen und, 19Merkmale, 22–23unterschiedlich große Inkremente und, 22

Inspektion, Lieferung von Wert und, 87Integration. Siehe fortlaufende IntegrationInterne Prozesse, evolvierende, 73I-shaped, 42, 152Iteration(en)

definiert, 152Lieferung eines Arbeitserzeugnisses und, 57Story Points und, 61, 64Velocity (Geschwindigkeit) und, 64

Iterationsbasierte AgilitätBurndown-Charts und, 62flussbasierte Agilität im Vergleich mit, 24, 25Planung für, 55Standups und, 53

Iterativer Lebenszyklusdefiniert, 153Kontinuum der Lebenszyklen und, 19Lieferung eines einzelnen Produkts, 21Merkmale, 21–22

KKadenz

definiert, 153Lieferung eines Arbeitserzeugnisses und, 57

Kaizen-Ereignisse, 153Kanban, das Kanban „durchgehen“, 53Kanban-Board

Backlog für Änderungen, gegliedert, 85Beispiel für, 65definiert, 153Fortschritt der Arbeit und, 86Mischung von Ansätzen und, 31

Kanban-Methode, 16, 153Aufkommen der, 12Lean und, 12–13Mischung von Ansätzen und, 31schlanke Ansätze und, 11

Kapazitätswerteaktuelle Messungen und, 66iterationsbasierte Agilität und, 55Story Points und, 66

Kapitalrendite (ROI), 30, 61Kennzahlen. Siehe Messungen; Maßnahmen; KennzahlenKollaboration

abteilungsübergreifend, 73Beziehung mit geteiltem Risiko und geteiltem Lohn, 77Denkweise für Zusammenarbeit mit dem Kunden, 81Entgegenkommen und, 37Moderation von, 35, 38schneller erledigte Arbeit und, 39Teamaufstellugnsprozess und, 49Transparenz und, 79

KommunikationModeratoren und, 35verteilte Teams und, 46

Kompetenz, soziale im Vergleich zu technischer, 36Kompetenzen

Hindernisse und, 74interne, 83PMO und, 82

Komplettanbieter, 79Komplexität. Siehe auch Komplexitätsmatrix nach Stacey

hybride Lebenszyklen und, 26iterative Lebenszyklen und, 21Problemlösung und, 57Projekte mit hohem Änderungsaufkomnen und, 38Unsicherheit und, 7, 13

Komplexitätsmatrix nach Stacey, 14, 15Komponententests, 56Kompromisse, 76Kontinuierliches Lernen, 73Koordination

dienende Führung und, 35Multi-Team, 80

Koordination mehrerer Teams, Skalieren und, 80Kostenentwicklungsindex (CPI), 69Kultur. Siehe Kultur der OrganisationKumulative Flussdiagramme, 70, 82Kundenanforderungen. Siehe AnforderungenKundenfeedback-Schleifen, 2Kundenzufriedenheit, 2, 25, 60Kündigungsoption, Verträge und, 78

162 Index

LLarge-Scale Scrum (LeSS) (groß angelegtes Scrum), 153Laufende Arbeit (Work in Progress, WIP), 31, 39

Aufgabentafel und, 25Kanban-Board und, 66kumulatives Flussdiagramm und, 70

Leadership (Führung). Siehe dienende FührungLean

agiler Ansatz und, 11Kanban-Methode und, 12–13

„Lean“-Softwareentwicklung (LSD), 153Lebenszyklus. Siehe auch agiler Lebenszyklus; hybrider

Lebenszyklus; inkrementeller Lebenszyklus; iterativer Lebenszyklus; prognostizierter LebenszyklusArten des, 17Auswahl des, 17definiert, 153Eigenschaften, 18Kontinuum des, 19Planung und, 20

Leitgedanke des Projekts, 49Lernen

auf Organisationsebene, 82kontinuierliches, 73Wert und, 61–62

LeSS. Siehe Large-Scale Scrum (groß angelegtes Scrum)Liefergegenstände. Siehe auch Service(s)

Anforderungen undMiniliefergegenstände, 77Reduzierung der Größe des Projekts, 83vorläufige, 15wertgesteuerte, 77

Lieferteams, 35Lieferung von Features. Siehe LieferungenLieferung von geschäftlichem Wert, 16, 23, 29Lieferungen. Siehe auch Lieferung von geschäftlichem Wert

beschleunigte, 73häufige, 55Iterationen, Inkremente und, 57kundenorientierte, 29laufende Arbeit und, 70subjektives Wesen von, 23

LSD. Siehe „Lean“-Softwareentwicklung

MMachbarkeitsnachweis, 22Managing Change in Organizations: A Practice Guide, 3, 71Manifest. Siehe Agiles ManifestManifest für Agile Softwareentwicklung, 8Maßnahmen, 51Meetings. Siehe Daily StandupsMeilensteinplan, Produkt-, 52Mentoring, 37, 82Messungen; Maßnahmen; Kennzahlen

agile Projekte und, 60–70Basispläne und, 61Ergebnisse und, 61–70EVM, 69Fertigstellungswert und, 68–69flussbasierte agile Teams und, 64Kapazität für, 66qualitative, 60Story Points und, 66Veränderlichkeit und, 61Vorhersehbarkeit, 66

Methoden der “Crystal”-Familie, 153Methoden der Vertragsverhandlung, 77–79

Abstufungen für Zeit und Material, 78Festpreis-Inkremente, 77gelieferter Wert und, 77Komplettanbieter, 79mehrstufige Struktur, 77Obergrenzen für Zeit und Material, 78Option der vorzeitigen Kündigung, 78Option mit dynamischem Inhalt und Umfang, 78Stärkung des Teams, 76

Miniliefergegenstände, Festpreis, 77Minimum Viable Product (MVP), 23Mini-Wasserfälle, 39Mischung von Ansätzen, 31Mitarbeiter, Entwicklung der, 82Mob-Programming, 39, 153Moderatoren, 35, 51Multiprojektmanagement., 82Multitasking

Burndowns und, 63Produktivität und, 44–45

MVP. Siehe Minimum Viable Product

163

NNacharbeit

Risiko der, 13, 14Verringerung potenzieller, 23

Neigung der Organisation, 153Nicht-agile Ansätze, 17Normen, Gruppen-, 50

OOCM. Siehe Veränderungsmanagement in OrganisationenOption der vorzeitigen Kündigung, Verträge und, 78Organisation(en)

beschaffungslastige, 83Evolvieren der, 84–86Silo-, 47, 155

Organisationskultur, 75–77Beurteilung, 74–75Beurteilung, Beispiel für, 76Organisationsstruktur in Vergleich zu, 77PMO und, 81sichere Umgebung und, 75

Organisationssilos. Siehe Silo-Organisation

PPaararbeit, 39Paarprogrammierung, 102, 153Paarweises Arbeiten. Siehe PaararbeitPaarweises Arbeiten aus der Ferne, 46Paint Drip. Siehe Broken CombParkplatz, Probleme und, 54PDCA. Siehe Plan-Do-Check-ActPersona, 153Persönliches, paarweises Arbeiten, 46Phase Gates 77Plan-Do-Check-Act, 153Plangesteuerter Ansatz, 153

agiler Ansatz verbunden mit, 27Messungen und, 60mit agilen Komponenten, 28

Plangetriebener Rollout, nach agiler Entwicklung, 26–27Planung

Feedback und, 29iterationsbasierte Agilität und, 55Lebenszyklen und, 20Neuplanung und, 61

PMBOK Guide, 17, 38PMO. Siehe ProjektmanagementbüroPräsentationen

Lieferungen und, 57Prüfungen und, 55

ProblemeProblemlösung, 57–59Standups und, 54

Problemlösung, 57–59, 82Problemlösung, Ermöglichen von, 39–40Product, Minimum Viable, 23Produkt-Backlog. Siehe auch Backlog Refinement

definiert, 153erste Reihenfolge eines Änderungs-Backlogs, 85vorbereiten von, 52Scrum-Regelwerk und, 31

Produkt-Backlog, Burnup-Chart zum , 68Produktivität

Aufgabenwechsel und, 44–45erhöhen, 39–40

Produktlieferung. Siehe LieferungenProdukt-Meilensteinplan, 52Produktverantwortlicher

definiert, 154Durchsatz und, 66funktionsübergreifende Teams und, 38Meilensteinplan und, 52Rolle, agiles Teammitglied, 41Scrum-Regelwerk und, 31

Prognostizierte Komponente, agiler Ansatz mit, 28Prognostizierter Lebenszyklus

Kontinuum der Lebenszyklen und, 19Merkmale, 20–21

Project Management Institute (PMI®), 1, 43Projekt(e)

Groß-, 15innewohnende Merkmale und, 18

Projektarbeit, 7Projektaufgabentafel

durchgehen 53kumulatives Flussdiagramm und, 70laufende Arbeit und, 25

Projektauftrag, 49–50Projekte mit hohem Änderungsaufkomnen, 38Projekte mit hohem Grad an Unsicherheit, 7Projektfaktoren, Anpassungsoptionen und, 32

164 Index

Projektlebenszyklus. Siehe LebenszyklusProjektleiter, Stakeholder und, 75Projektmanagement, Ziel , 29Projektmanagementbüro (Project Management Office –

PMO), 81–82definiert, 154innovationsorientiert, 81multidisziplinär, 82Präsentationen und, 57wertgesteuerter, 81

Projektmanageragile Umgebung unddefiniert, 38dienende Führung und, 38Rolle, 37

Projektrisiken, hybrider Lebenszyklus und, 29Projektwissen, Anbieter und, 83Prototyp erstellen, 15, 22Prüfungen, Präsentationen und, 55

QQualitative Werte, 60Quantitative Risikoanalyse, 37

RRational Unified Process (RUP), 149Reaktionszeit, 64, 66Refactoring

definiert, 154Mischung von Ansätzen und, 31

Regelwerk; Rahmenwerkagile Methoden, 80definiert, 154

Regulatorisches Umfeld, 36Relative Schätzung, 67Retrospektive, 27, 50–51

definiert, 154Produktwissen und, 83Schlüsselpunkte, 51

RisikoBeziehung zwischen Kunde und Lieferant und, 77Festpreis-Inkremente und, 77hybrider Lebenszyklus und, 29

Projekte mit hoher Unsicherheit und, 7Teilzeiteinsätze und, 45Unsicherheit, Auswahl des Lebenszyklus und, 13–16

ROI. Siehe KapitalrenditeRolle(n)

agile Teams und, 40–41Projektmanager, 37vorübergehend zugeteilte Spezialisten und, 45

Rollierende Planung, definiert, 154RUP. Siehe Rational Unified Process

SSAFe® Siehe Scaled Agile Framework®

SBE. Siehe Spezifikation durch die Verwendung von Beispielen

Scaled Agile Framework (SAFe®), 154Schätzung

relative, 67Vorab-, 27

Scheitern des Projekts, 77Schlanke Denkweise, 11, 12Schmerzpunkte, Problemlösung und, 57–59Schnellere Lieferung, Änderungen verbunden mit, 73Schwenk, 154Scrum

definiert, 154Regelwerk für, 31Zusammenarbeit und, 80

Scrum Masterdefiniert, 154Scrum-Regelwerk und, 31

Scrum of Scrums, 154Scrumban, 154Scrum-Tafel, 154Scrum-Team, 154Selbstmanagement, 36Serieller Lebenszyklus, 17. Siehe auch prognostizierter

LebenszyklusService Request Manager, 154Sich selbst managende Teams, 39Sich selbst organisierende Teams

Beispiel eines Finanzinstituts, 44definiert, 155Fallbeispiel, 43Projektmanager und, 37Standups und, 54

165

Sicherheit, sichere Umgebung, 75Silo-Organisation

definiert, 155funktionsübergreifende Teams und, 47

Skalieren, 80SMEs. Siehe Fachleute (SMEs)Smoke Test

definiert, 155Lieferung des Werts und, 56

Software Extension to the PMBOK® Guide Fifth Edition, 17Softwareentwicklung

agile Praktiken und, 2agiles Manifest und, 8lernen und, 61Vordenker in, 8

Soziale Kompetenz, 36Soziale Medien, 2Spezialisten, allgemeine, 42Spezifikation durch die Verwendung von Beispielen

(SBE), 155SPI. Siehe TerminentwicklungsindexSpike(s)

Backlog Refinement und, 52definiert, 155Lieferung des Werts und, 56

Sponsor, Projektfertigstellung und, 61Sprint, 155Sprint-Backlog, 155Sprint-Planung

definiert, 155Scrum-Regelwerk und, 31

StakeholderInformieren, 37Management, 82Projektleiter und, 75

Standups. Siehe Daily StandupsStärkung des Teams als Ansatz, 76Statusbesprechungen, 54Statusmeldung nach dem Ampelprinzip, 60Statusmeldungen, Ampelstatus, 60Stories. Siehe auch User Story

Backlog Refinement und, 52, 53jeweils nur eine fertigstellen, 68zuverlässige Geschwindigkeit und, 61

Story PointBurndown-Chart und, 62Burnup-Chart und, 63definiert, 155fertig, 63Iterationen und, 61, 64Messung und, 66Velocity (Geschwindigkeit) und, 64

Story-Karten, 31Strategie

Kultur und, 75Leidenschaft für eine Sache und, 75

Struktur der Organisation, 83Swarming, 39, 155

TTDD. Siehe Testgetriebene EntwicklungTeam(s). Siehe auch Agile Teams; funktionsübergreifende(s)

Team(s); sich selbst organisierende(s) Team(s)angehäufte Arbeit und, 70Autorenteam, Guide und, 1Erstellen eines Projekts und, 49–50Geschäftspraktiken und, 79Kernmitglieder von, 45Koordinierung mehrere Teams, 80Lieferung, 35Moderator, Rolle, 41sich selbst managen, 39verteilt, 43, 44, 45, 46zusammengelegt, 39, 43, 44, 45Zusammenstellung von, 38–47

Teamauftrag. Siehe Projektauftrag, 49–50Teamleiter, 82Teammitglieder, dedizierte, 44–45Teammoderator, Rolle, 41Teamrollen, agile, 40–41Teamstrukturen, 43Technical Debt, 155Technische Fähigkeiten, 36Technologien, disruptive, 2, 3Teilzeiteinsätze, Risiken und, 45Terminentwicklungsindex (SPI), 69

166 Index

TestAkzeptanz, 82auf allen Ebenen, 56automatisierte, 31, 56Unsicherheit und, 16

Testgetriebene Entwicklung (Test-Driven Develoment, TDD).definiert, 155Lieferung des Werts und, 56Mischung von Ansätzen und, 31

Tests auf Systemebene, 56Timebox(en). Siehe auch Spike(s)

definiert, 155Standups und, 53Verwendung von, 12

Training, 82Transparenz

Erfolg und, 85Lieferung von Wert und, 87Zusammenarbeit und, 79

T-shaped, 42, 155

UÜbergangsstrategie, hybride Lebenszyklen als, 30Umstellung auf andere Zusammenhänge, 44, 45Unsicherheit. Siehe auch Änderung(en)

Anforderungen und, 13, 14, 16, 22, 24Erkundung von, 16Komplexität und, 7, 13mittlerer bis niedriger Grad an, 30Risiko, Auswahl des Lebenszyklus und, 13–16technischer Grad an, 14

Unsicherheits- und Komplexitätsmodell, 14User Story

als Miniliefergegenstand, 77definiert, 155Präsentationen und, 55

User-Story-Zuordnung, 155UX-Design, 155

VVeränderlichkeit, Messung, 61Veränderungsmanagement (OCM), 3, 71–74, 156

agile Ansätze und, 71–72Bereitschaft für Änderungen und, 73–74Triebkräfte für, 73

Verhaltensgetriebene Entwicklung (Behavior-Driven Development – BDD)definiert, 156Lieferung des Werts und, 56

Verschwendete Arbeit, 14Versicherungssystem, 29Verteilte Teams, 43, 44, 45Verzögerungen, 64Videokonferenzen, 46Virtuelle Arbeitsplätze, 46Visuelles Werkzeug. Siehe Kanban-BoardVollständigkeit

Arbeitsvereinbarungen und , 50subjektives Wesen von, 23

Vorabschätzung, 27Vorläufige Liefergegenstände, 15Vorlaufzeit

Fertigstellungszeit, 66flussbasierte agile Teams und, 64interne Abhängigkeiten und, 66

Vorübergehend zugeteilte Spezialisten, 45, 83

WWasserfall-Lebenszyklus, 17. Siehe auch prognostizierter

LebenszyklusWechsel zwischen Aufgaben, Produktivität und, 44–45Weniger Verschwendung, 15Wert. Siehe auch Lieferung von geschäftlichem

Wert; LiefergegenständeBeschleunigung, 30inkrementell, 29Kennzahlen und, 60lernen und, 61–62liefern, 16, 23, 56Methoden der Vertragsverhandlung und, 77Optimierung des Flusses von, 38–39

Wert für den Kunden. Siehe WertWerte des Teams, 50Wertstrom, 156Wertstromanalyse, 156WIP (Work in Progress). Siehe Laufende ArbeitWissen, Produkt-, 83Wissensaufbau der Organisation, 82

167

XXP. Siehe eXtreme Programming

ZZeit- oder nutzungsabhängiges Modell, 3Zeit-und-Material-Ansatz

Abstufungen für, 78Obergrenzen, 78

Zulassungsverfahren bei der FDA (USA), 26Zusammengelegte Teams, 39, 43, 44, 45Zweckdienlich

definiert, 156hybride Lebenszyklen und, 29

Zweckdienlichkeit, Anpassungsoptionen zur Verbesserung der, 32