<?page no="0"?> Fabian Kaiser, Roman Simschek ® PRINCE2 I L E G A <?page no="1"?> PRINCE2 Agile® is a registered trade mark of AXELOS Limited. All rights reserved. © AXELOS Limited 2019. Used under permission of AXELOS Limited. All rights reserved. <?page no="2"?> Fabian Kaiser Roman Simschek PRINCE2 Agile Die Erfolgsmethode einfach erklärt UVK Verlag · München <?page no="3"?> Roman Simschek und Fabian Kaiser sind die Gründer und Inhaber der Agile Heroes GmbH, einem der führenden Trainingshäuser zum Thema Projektmanagement. Sie beraten in Deutschland, Österreich und der Schweiz namhafte Unternehmen und helfen ihnen dabei, ihre Projekte erfolgreich zu managen und Agilität in Unternehmen einzuführen. www. agile-heroes .de Online-Angebote oder elektronische Ausgaben sind erhältlich unter www.utb-shop.de Bibliografische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über <http: / / dnb.ddb.de> abrufbar. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. ISBN 978-3-7398-3008-7 (Print) ISBN 978-3-7398-8008-2 (E-PDF) © UVK Verlag München 2020 - ein Unternehmen der Narr Francke Attempto Verlag GmbH & Co. KG Druck und Bindung: CPI books GmbH, Leck UVK Verlag Nymphenburger Straße 48 · 80335 München Tel. 089/ 452174-65 www.uvk.de Narr Francke Attempto Verlag GmbH & Co. KG Dischingerweg 5 · 72070 Tübingen Tel. 07071/ 9797-0 www.narr.de <?page no="4"?> Vorwort Verehrte Leserin, verehrter Leser, danke, dass Du Dich zum Kauf dieses Buches entschieden hast. Vielleicht hast Du dieses Exemplar auch im Zuge eines Trainingsbesuches bei uns erhalten. Auch dafür danken wir Dir sehr, für dein Vertrauen. Wie Du bereits gemerkt hast, duzen wir unsere Leser. Wir sind der Meinung, dass in der aktuellen schnellen Welt, in der wir leben, das Du einfacher zu schreiben und zumindest hier in diesem Buch die richtige Wahl ist. Agilität ist ein Megatrend. Woher kommt das? Alle großen, die Welt dominierenden Tech-Unternehmen wie Google, Facebook, Amazon und Spotify nutzen alle die Kunst der Agilität. Ist das Zufall oder besteht eine Korrelation von Agiltiät und Erfolg in der aktuellen Zeit? Und falls ja, welche Methoden wenden diese Top-Unternehmen an? Wie kombinieren diese Player klassisches mit agilem Projektmanagement? Dieser Antwort wollen wir im diesem Buch - PRINCE2 Agile - nachkommen. Vorab möchten wir darauf hinweisen, dass PRINCE2 Agile kein eigenes Framework ist, wie es das klassische PRINCE2-Framework ist. Vielmehr ist es eine Art Toolbox für Dich, in Deinen Projekten herauszufinden, wie klassische und agile Arbeitsweise zusammenpassen und welche Techniken und Tools aus beiden Welten es gibt. Es ist damit eine Anpassung bzw. eine Weiterentwicklung aus dem bestehenden Framework PRINCE2. Dieses Buch ist eine Weiterentwicklung unseres bestehenden PRINCE2-Buches. Um alle Leser jedoch auf denselben Wissensstand zu heben, sind die ersten Teile dieses Buches mit grundlegender PRINCE2-Terminologie ausgestattet. Benötigst Du noch <?page no="5"?> 6 Vorwort Input zu PRINCE2 oder möchtest Du nochmal ein Freshup machen, dann empfehlen wir Dir unser Buch „PRINCE2 - Die Erfolgsmethode einfach erklärt“, welches auf dem Level PRINCE2-Foundation die PRINCE2-Terminologie vollumfänglich erklärt. Das Buch ist wie folgt strukturiert:  Grundlagen des Projektmanagements und Allgemeines zu PRINCE2  Grundlagen von PRINCE2 Agile  Andere agile Methoden  PRINCE2 Agile in Verbindung mit weiteren agilen Methoden  Wichtige Fokusbereiche  Prüfung und Zertifizierung Solltest Du Fragen haben, kannst Du Dich jederzeit gerne an uns wenden:  Fabian Kaiser fkaiser@agile-heroes.de  Roman Simschek rsimschek@agile-heroes.de Beide sind wir telefonisch erreichbar unter 069 9999 15 911. Herzlichsten Dank und viel Erfolg Fabian Kaiser Roman Simschek Frankfurt am Main, November 2019 <?page no="6"?> Inhaltsübersicht 1 Grundlagen ............................................................................................................................... 13 2 Grundlagen der Agilität........................................................................................................ 43 3 Grundlagen von PRINCE2 Agile......................................................................................... 61 4 Die agilen Methoden............................................................................................................. 71 5 PRINCE2 Agile - Tiefgang .................................................................................................... 87 6 Fokusbereiche........................................................................................................................129 7 Prüfung und Zertifizierung ...............................................................................................147 8 Glossar ......................................................................................................................................149 8 Lösungen zu den Übungsfragen ....................................................................................177 <?page no="8"?> Inhalt Vorwort.......................................................................................................................................................5 1 Grundlagen ..........................................................................................................................13 Die Geschichte von PRINCE2 ........................................................................................... 13 Der Gedanke von PRINCE2 Agile.................................................................................... 15 Charakteristika eines Projekts ......................................................................................... 16 Die vier integrierten Bausteine von PRINCE2 ............................................................ 20 Tailoring PRINCE2 ................................................................................................................ 21 Die 7 Grundprinzipien........................................................................................................ 23 Die 7 Themen ........................................................................................................................ 31 Die 7 Prozesse ....................................................................................................................... 35 Übungsfragen zu Kapitel 1............................................................................................... 38 2 Grundlagen der Agilität .................................................................................................43 Der Begriff Agilität ............................................................................................................... 43 Was bedeutet Agilität im Projektmanagement - Überblick................................ 47 Was bedeutet Agilität im Projektmanagement - Einblick ................................... 50 Das Agile Manifest - Eine Geschichte der Agilität................................................... 53 Die agilen Prinzipien........................................................................................................... 56 Übungsfragen zu Kapitel 2............................................................................................... 59 <?page no="9"?> 10 Inhalt 3 Grundlagen von PRINCE2 Agile .................................................................................61 Die Idee hinter PRINCE2 Agile......................................................................................... 61 8 Guidance Points ................................................................................................................ 63 Fix oder Flex? ......................................................................................................................... 64 Die 5 Ziele des Flexiblen.................................................................................................... 67 4 Die agilen Methoden .......................................................................................................71 Die Methode Lean StartUp............................................................................................... 71 SCRUM ..................................................................................................................................... 75 Die Methode Kanban.......................................................................................................... 80 Übungsfragen zu Kapitel 3 & 4 ....................................................................................... 83 5 PRINCE2 Agile - Tiefgang..............................................................................................87 Die Grundprinzipien in PRINCE2 Agile......................................................................... 87 Thema Business Case ......................................................................................................... 90 Thema Organisation ........................................................................................................... 91 Thema Qualität ..................................................................................................................... 94 Thema Pläne .......................................................................................................................... 99 Thema Risiko........................................................................................................................106 Thema Änderungen..........................................................................................................108 Thema Fortschritt ..............................................................................................................110 <?page no="10"?> Inhalt 11 Vorbereiten eines Projekts (SU) und Initiieren eines Projekts (IP) ...................113 Lenken eines Projekts (DP) .............................................................................................118 Steuern einer Phase (CS) und Managen der Produktlieferung (MP) ..............119 Managen eines Phasenübergangs (SB) .....................................................................123 Abschließen eines Projekts (CP) ...................................................................................125 Übungsfragen zu Kapitel 5.............................................................................................126 6 Fokusbereiche.................................................................................................................. 129 Fokusbereich: Das Agilometer ......................................................................................129 Fokusbereich: Anforderungen......................................................................................132 Fokusbereich: Kommunikation.....................................................................................137 Fokusbereich: Häufige Releases ...................................................................................140 Fokusbereich: Verträge....................................................................................................142 Übungsfragen zu Kapitel 6.............................................................................................144 7 Prüfung und Zertifizierung ....................................................................................... 147 8 Glossar .................................................................................................................................149 9 Lösungen zu den Übungsfragen ............................................................................ 177 <?page no="12"?> 1 Grundlagen Die Geschichte von PRINCE2 PRINCE2 wurde 1989 von der britischen Regierungsabteilung „Central Computer and Telecommunications Agency“ als eine Art „Wissensmanagement-Projekt“ in Auftrag gegeben, um die Erfahrungen der bis dato gemachten Projekterfahrungen zu sammeln, zu bewerten und daraus ein Framework zu entwickeln, welches dabei helfen sollte, bei zukünftigen Projekten bereits bekannte Fehler zu vermeiden. Hieraus entstand die erste Best Practice Projektmanagement-Methodik PRINCE; damals noch ohne die Versionsangabe „2“. PRINCE stand und steht für PRojects IN Controlled Environments. Zum damaligen Zeitpunkt war das Framework für IT-Projekte entwickelt worden. Es sollte als Regierungsstandard für Projektmanagement gelten. Schon bald jedoch fanden die darin enthaltenen Methoden auch außerhalb von IT-Projekten eine weite Verbreitung. Aus der Erkenntnis heraus, dass PRINCE auch auf andere Projekte anwendbar ist, wurde die Methodik nochmal stark verschlankt, vereinfacht und schließlich 1996 als allgemeine Projektmanagement-Methode PRINCE2 veröffentlicht. Seitdem wurde die PRINCE2-Methodik zunehmend populärer. Neben der PMBok (PMI) und ICB (IPMA, GPM) zählt PRINCE2 zu den weltweit am häufigsten verwendeten Projektmanagement-Methodiken. In über 50 Ländern wird PRINCE2 geschult, zertifiziert und angewandt. In Großbritannien gilt PRINCE2 sogar als De-Facto-Projektmanagement-Standard. Hier achten Unternehmen in der Tat darauf, dass Projektleiter und Projektmanager eine eingetragene PRINCE2-Zertifizierung haben. Mehr dazu in Kapitel 6 - Prüfung und Zertifizierungen. Die Anforderung nach einem Zertifikat <?page no="13"?> 14 1 Grundlagen einer anerkannten Projektmanagement-Methodik wie PRINCE2 lässt sich immer mehr auch im D-A-CH-Raum verfolgen. Das liegt nicht zuletzt daran, dass die Eigenschaft, ein richtig guter Projektmanager zu sein, aufgrund der aktuellen Änderungsbereitschaft der Unternehmen gefragter ist denn je zuvor. Oft fragt man sich in diesem Zusammenhang, wie PRINCE2 eigentlich eine Allzwecklösung für diese ganz verschiedenen Projekte bieten kann. Die Antwort darauf ist simpel: PRINCE2 ist so generisch wie nötig, jedoch so konkret wie möglich, um als 360º-Methodik, also als ganzheitliche Projektmethodik, wahrgenommen zu werden. Das bedeutet zuallererst, dass die Methoden-Guideline an sich so allgemein formuliert ist, dass daraus kein fachlicher Hintergrund eines Projekts herauszulesen ist. PRINCE2 beschreibt nicht, dass Du jeden Tag mit Deinen Entwicklern zusammen die neu programmierte Software-Funktionalität testen sollst. Vielmehr beschreibt PRINCE2, dass Du als Projektmanager Dich in einem von Dir zu wählenden Turnus mit Deinen Teilprojektleitern austauschen sollst und diese so organisierst, dass sie mit ihren fachlichen Teams die Produkterstellung vorantreiben. Die Methodik gibt die Empfehlungen und Eckpunkte vor, anhand derer Du den Rhythmus für Deine Meetings finden kannst. Du erhältst Hinweise, welche Inhalte ein Bericht enthalten soll. Im Grunde genommen geht es darum, aus der Sicht des Projektmanagers Dir zu jedem Zeitpunkt im Projekt die richtigen Werkzeuge an die Hand zu geben, welche Dir dabei helfen sollen, jederzeit die richtigen Entscheidungen treffen zu können. Und das so generisch wie möglich. Daher ist eines der wichtigsten Grundprinzipien der PRINCE2-Terminologie die sogenannte „Anpassung an die Projektumgebung“. Ohne vorwegzugreifen ist in diesem Kontext ersichtlich, weshalb dieses Grundprinzip als derart wichtig eingestuft wird. <?page no="14"?> 1.2 Der Gedanke von PRINCE2 Agile 15 Video anschauen: Der Gedanke von PRINCE2 Agile Autor Fabian erklärt, was der Gedanke von PRINCE2 Agile war und wieso es entwickelt wurde. www.agile-heroes.de/ buch/ prince2agile Um diese eben beschriebene generische Anwendbarkeit auf Dauer aufrechtzuhalten, ist PRINCE2 keineswegs im Jahre 1996 stehen geblieben. Die heutigen Rechteinhaber, AXELOS, bestehend zu 51% aus Capita (privates Unternehmen in GB) und zu 49% aus Cabinet Office (Behörde in GB), sind mehr denn je damit beschäftigt, die Methodik weiterhin dem Geist der Zeit anzupassen. Dies geschieht durch die regelmäßig stattfindenden Updates. Der Gedanke von PRINCE2 Agile Wie der Hintergedanke der PRINCE2-Methodik ist, sollte nun klar sein. PRINCE2 Agile hingegen ergänzt sich zum Teil von der generischen Sichtweise des „klassischen“ PRINCE2. PRINCE2 Agile ist eine Form der Anpassung der PRINCE2-Methodik; eine Anpassung für die agile Welt des Projektmanagements. PRINCE2 lebt davon, sich an die Bedürfnisse der jeweiligen Projekte anzupassen. So auch an die Welt agiler Projekte. Dass Agilität immer wichtiger wird, haben nicht zuletzt auch die offiziellen Rechte- Inhaber von PRINCE2 bemerkt, weshalb sie sich mit Agilitätsexperten zusammengetan haben, um dieses Framework zu generieren. Zu sagen ist, dass auch diese Variante von PRINCE2 keinen Anspruch auf Vollständigkeit erhebt. Vielmehr geht es darum, dem Anwender und schließlich auch Dir als Leser dieses Buches eine Vorstellung davon zu vermitteln, in welchen Ausprägungen die agile Anpassung dieser Weltmethodik PRINCE2 möglich und vielleicht sogar nötig ist, um erfolgreiche (agile bzw. hybride) Projekte im aktuellen Zeitalter zu managen. <?page no="15"?> 16 1 Grundlagen Charakteristika eines Projekts Bevor wir uns gleich den ersten Inhalten von PRINCE2 Agile widmen, möchten wir an dieser Stelle erst mal mit ganz allgemeinen fachlichen Grundlagen des Projektmanagementwissens beginnen. Generell gilt: Ein Projekt ist eine für einen befristeten Zeitraum geschaffene Organisation, die mit dem Zweck eingerichtet wird, einen oder mehrere Produkte in Übereinstimmung mit einem Business Case zu vereinbarter Qualität zu liefern. Ein Projekt wird hierbei in fünf Dimensionen unterschieden: Einzigartig 1) : Vergleicht man ein Projekt mit einer Aufgabe in Linie, wird klar, dass es sich hierbei um nicht wiederholende Tätigkeiten handelt. In der Linie macht man hingegen - stark vereinfacht gesagt - jeden Tag annähernd dasselbe. Als Controller <?page no="16"?> 1.3 Charakteristika eines Projekts 17 vergleicht man Berichte und berät sich mit dem Management, als Risikomanager identifiziert man Risiken und bewertet sie, als Sachbearbeiter bearbeitet man Auftragseingänge. Im Projekt hingegen erwartet einen täglich eine neue Herausforderung. Man entwickelt und entwirft neue Dinge. Es kommen ständig neue Aspekte zum Vorschein, die im Vorhinein überhaupt nicht klar waren. Die „Einzigartigkeit“ kann man sogar und gerade in der digitalen Welt, in der wir uns befinden, noch viel weiter spannen. Agilität kommt aus der Welt der Software-Entwicklung/ -Technologie. Eine Welt, die bis <?page no="17"?> 18 1 Grundlagen vor 20 bis 30 Jahren vollkommen neu war. Eine Sache hat diese Welt jedoch bis heute behalten: Jede Software und jede Technologie sind absolut einzigartig in ihrer Zusammensetzung verschiedenster Unter-Technologien, manchmal sogar so einzigartig, dass es sich hierbei um eine komplett neue Technologie handelt, die vorher noch nie existiert hat. Das ist eine interessante Art der Einzigartigkeit, galt doch vorher, im klassischen Projektmanagement, lediglich die Einzigartigkeit, dass das Projekt in der Konstellation noch nie durchgeführt wurde. Beispiel Klassisches Projektmanagement Ein Hausbau wurde von Anfang bis Ende geplant. Die Art und Weise, wie ein Haus gebaut wird, verändert sich nur sehr langsam, da wir Häuser bereits seit einer Ewigkeit bauen können und heute einen hohen Standard erreicht haben. Das Ziel eines Hausbaus war immer gleich → Wohnen. Beispiel Agiles Projektmanagement Software-Entwicklung existiert erst seit wenigen Jahrzenten. Die Verwendung der verschiedenen Software ist schier unendlich. Die Art und Weise, WIE eine Software gebaut wird, ändert sich regelmäßig. Hinzukommt, dass eine Änderung bei einem Hausbau in der Regel mit vielen Kosten und einem hohen zeitlichen Aufwand verbunden ist. Eine Software hingegen kann deutlich schneller angepasst werden. Begrenzt 2) : Ein Projekt ist von Natur aus begrenzt. In erster Linie natürlich zeitlich, da ein klar definiertes Ende geplant ist. Natürlich sind auch die anderen Projektdimensionen, wie Budget, Qualität etc., begrenzt. <?page no="18"?> 1.3 Charakteristika eines Projekts 19 Bereichsübergreifend 3) : Ein Projekt stellt in seiner Vollkommenheit seine Interdisziplinarität, also sein fachspezifisch übergreifendes Know-how, unter Beweis. In einem Projekt treffen viele unterschiedliche Fachexperten, oft aus verschiedenen Unternehmen, aus verschiedensten Ländern und Kulturen, manchmal sogar zu völlig unterschiedlichen Zeitzonen, aufeinander. Der einzige gemeinsame Nenner dieser Mitarbeiter ist nur das Projekt. Das bedeutet auch, dass Menschen, die aus so unterschiedlichen „Welten“ aufeinanderstoßen, ein enormes Konfliktpotenzial mit sich bringen. Wenn sich jedoch dieses neue Projektteam, die verschiedensten Entwickler, die unterschiedlichsten Berater, sich erst einmal eingeschwungen haben, ist die Produktivität enorm. Unsicher 4) : In der Annahme, dass ein Risiko in der betriebswirtschaftlichen Welt nicht per se als negativ, sondern vielmehr „wertfrei“ hinzunehmen ist, bezieht sich die Beschreibung „unsicher“ in erster Linie auf die Zielerreichung, die durch viele Bedrohungen, also der negativen Ausprägung einer Unsicherheit, sowie einigen Chancen, den positiven Ausprägungen einer Unsicherheit, gekennzeichnet ist. Das Thema „Risiko“, das sich dahinter vereint, wird in der Geschichte des strukturierten Projektmanagements inzwischen als „Dauerbrenner“ erkannt. Das Gute: Fast alle Projektmanager wissen inzwischen, wie wichtig es ist, überhaupt Risikomanagement zu betreiben. Das Schlechte: Von einem effektiv effizienten Risikomanagement ist der Großteil der Projekte noch sehr weit entfernt. Natürlich, im Daily Business ist es oft stressig. Und natürlich rücken dort Themen, die auf den ersten Blick nicht sehr viel zur Projektumsetzung beitragen, oft sehr schnell in den Hintergrund. Jedoch sollte man sich als Projektmanager in diesem unsicheren Umfeld, in dem man sich im Projekt-Business naturgemäß bewegt, unbedingt mit dem stiefmütterlich behandelten Thema Risikomanagament mehr als nur ein bisschen auseinandersetzen. Verändernd 5) : Der Grund für die Durchführung eines Projekts ist, einem aktuellen Zustand entgegenzuwirken und/ oder einen anderen Zustand herzustellen. Ein Projekt ist somit mit dem Ziel eingerichtet, eine Veränderung herbeizuführen. <?page no="19"?> 20 1 Grundlagen Die vier integrierten Bausteine von PRINCE2 Nachdem wir uns im letzten Kapitel den Grundlagen des Projektmanagements, angehaucht mit einigen PRINCE2-Merkmalen, angeschaut haben, gehen wir nun in die Methodik PRINCE2. PRINCE2 kann man im Grunde in vier einfache Bestandteile gliedern: Grundprinzipien, Themen, Prozesse und die Anpassung an die Projektumgebung. Jeder der vier Bausteine hat eine wichtige Daseinsberechtigung in unterschiedlicher Ausprägung. Im Folgenden gehen wir auf die einzelnen Bausteine ein, bevor diese dann Kapitel für Kapitel näher aufgearbeitet und verknüpft werden.  Die 7 Grundprinzipien: Die Grundprinzipien kann man festen Leitsätzen gleichsetzen. Der PRINCE2-Terminologie zufolge ist jedes der sieben bestehenden Grundprinzipien einzuhalten, sollte man beabsichtigen, ein PRINCE2-Projekt zu initiieren und zu managen. Den sieben Grundprinzipien schenkt das Kapitel 1.6 im Folgenden noch gesonderte Aufmerksamkeit.  Die 7 Themen: Die sieben Themen beschreiben den Inhalt von PRINCE2 beziehungsweise den Inhalt einer richtigen Projektstruktur. Zum Beispiel: Wie man eine richtige Projektorganisation erstellt oder wie Reporting-Strukturen auszusehen haben.  Die 7 Prozesse: Die sieben Prozesse stellen die Ablaufbeschreibung um die sieben Themen herum dar. Wann wer was im Projekt erstellt bzw. durchführt.  Anpassung an die Projektumgebung: Die Anpassung an die Projektumgebung ist in der PRINCE2-Terminologie nicht allzu umfangreich beschrieben, stellt in der Praxis jedoch das größte Thema eines Projektmanagers bei der Verwendung von PRINCE2 dar. Das liegt daran, dass dieser Baustein die PRINCE2-Terminologie vollkommen anpassbar und adaptierbar auf sämtliche Projekte macht. <?page no="20"?> 1.5 Tailoring PRINCE2 21 Tailoring PRINCE2 Wir haben gelernt, dass PRINCE2 Agile eine Tailoring Guidance des bestehenden PRINCE2-Frameworks ist. Doch wie und vor allem wo wird das Framework in der bestehenden Terminologie angepasst? <?page no="21"?> 22 1 Grundlagen Dies geschieht in PRINCE2 Agile vor allem durch:  Die Vereinfachung der Methodik: Oft wurde innerhalb der PRINCE2-Methodik deren umfangreiche Ausprägung kritisiert. Zwar ist eine umfangreiche Methode essentiell, um eine generische Anwendung gewährleisten zu können, jedoch ist die generische Verwendung einer Methode in einer Anpassungsform wie dieser hier nicht mehr derartig notwendig. Die Vereinfachung geschieht z. B. mit der Vereinfachung von Techniken und Praktiken.  Die Formalisierung bzw. Informalisierung: Eine weitere Form der Anpassung ist, Meetings zur formalisieren bzw. sie zu informalisieren. Zugegeben, eine Informalisierung ist in einer agilen Ausprägung natürlich häufiger in Anwendung, als die Meetings noch formeller zu gestalten. Dies geschieht z. B. dadurch, dass Meetings im Stehen bei einer Tasse Kaffee abgehalten werden oder das gesamte Team auf Kosten der Firma gemeinsam zu Mittag ist.  Die Umgestaltung von Formaten: Berichte, Tabellen usw. werden in ihrer Darstellung verändert.  Die Zusammenführung/ Splittung: Es werden z. B. viele einzelne Berichte in einem großen Bericht zusammengeführt. Ziel ist es, hierdurch die Kommunikation noch adressatengerechter aufzuteilen und Unterlagen zu entschlacken.  Das Renaming: Da PRINCE2 eine vordefinierte Art von Wörtern innerhalb der Terminologie aufweist, stoßen viele Organisationen mit ihrem „Slang“ entgegen. Daher hat es sich bewährt, gewisse Begrifflichkeiten auf die Organisation hin anzupassen, um am Ende auch politischen Gegebenheiten auszuweichen. Nicht angepasst werden hingegen die 7 Grundprinzipien. Diese bleiben in vollem Maße bestehen. <?page no="22"?> 1.6 Die 7 Grundprinzipien 23 Die 7 Grundprinzipien Wie in Abschnitt 1.4 beschrieben, sind die Grundprinzipien wichtige, in PRINCE2 vorherrschende Leitsätze. Leitsätze, die sich aus rund 30 Jahren richtig gutem Projektmanagement ergeben haben und daher auch nicht unter die Anpassung bzw. das Tailoring fallen. Viele davon wird man im Rahmen seiner eigenen Projekterfahrung als bekannt und bewährt einstufen. Andere bringen interessante neue Ansätze mit sich. Wer sich im agilen Projektmanagement wie SCRUM oder Kanban bereits auskennt, dem wird auffallen, dass die Grundprinzipien von ihrem Zweck dem Agilen Manifest sehr nahe sind. Die Inhalte sind natürlich unterschiedlich, der Hinter- <?page no="23"?> 24 1 Grundlagen grund, nämlich ein einheitliches Verständnis von Gesetzen, hingegen absolut gleichwertig. Die 7 Grundprinzipien sind:  Fortlaufende geschäftliche Rechtfertigung 1) : Dieses Grundprinzip bezieht sich somit auf den vom Projekt zu liefernden Nutzen oder Mehrwert. Dieser muss von Anfang an gegeben sein, um ein Projekt überhaupt zu initiieren. Ist dies der Fall, kann mit einer Umsetzung des Projekts begonnen werden. Wichtig ist hierbei, dass dieser Nutzen durch eine iterative Vorgehensweise auch ständig überprüft und gegebenenfalls angepasst wird. Der Nutzen stellt eine Projektdimension dar, welche der Projektmanager dauerhaft managen muss. Die geschäftliche Rechtfertigung muss der Projektmanager der PRINCE2-Methodik gemäß in einem Dokument festhalten, welches durch dauerhafte Anpassung sozusagen „lebt“. Dieses Dokument wird als Business Case beschrieben. Hierzu wird es im Folgenden sogar noch ein eigenes Thema geben, welches behandelt wird.  Lernen aus Erfahrung 2) : Dieses Grundprinzip befasst sich im Grunde mit den Erfahrungen aus Vorgängerprojekten. Erfahrung muss hierbei keinesfalls negativ zu bewerten sein. Durchaus können gute Ansätze aus einem Vorgängerprojekt hier ebenfalls Anwendung finden. Im Grunde genommen ist die PRINCE2- Methodik als eine große Sammlung der besten Anwendungen aus Vorgängerprojekten nichts anderes als die Operationalisierung dieses Grundprinzips. Dieses Grundprinzip findet meist zu Beginn des Projekts eine hohe Anwendung, da in frühen Projektphasen eine enorme Unsicherheit herrscht und hier ein starkes Erfahrungsregister aus Vorgängerprojekten gute Unterstützung leisten kann. In der Praxis fällt auf, dass ein bewusstes „Lernen aus Erfahrung“ meist nur sehr halbherzig betrieben wird. Natürlich, unterbewusst haben Senior-Projektmanager einen enormen Erfahrungsschatz, auf den sie zurückgreifen, auch ohne irgendwelche Lessons-Learned-Meetings durchzuführen. Die Erfahrung zeigt jedoch, dass <?page no="24"?> 1.6 Die 7 Grundprinzipien 25 regelmäßige Lessons-Learned-Meetings einen für den Projekterfolg positiven Effekt mit sich bringen. Hierbei ist zu beachten, dass die Betonung auf „regelmäßig“ liegt und die Meetings nicht nur am Ende eines Projekts, wie es in den meisten Projekten gehandhabt wird, abgehalten werden. Sich regelmäßig zu hinterfragen ist im agilen Projektmanagement ein gelebter Ansatz. Auch im klassischen Projektmanagement gehört es der Theorie zufolge (PRINCE2-Methodik) schon längst zum Tagesgeschäft.  Definierte Rollen und Verantwortlichkeiten 3) : Wer kennt es nicht? Innerhalb eines Projekts kommt (gefühlt) aus dem Nichts eine Aufgabe auf, welche zwar bekannt war, jedoch hatte niemand dafür Sorge getragen, dass diese auch ordnungsgemäß erfüllt wurde. Grund hierfür ist, dass sich niemand dafür verantwortlich gefühlt hat. Dieser Planlosigkeit der Verantwortung wirkt die PRINCE2- Methodik stark entgegen, indem sie klare Rollen (Projektmanager, Teammanager etc.) vorgibt und dahinter klar deren Anforderungsprofil, deren Kompetenzen sowie Rechte und Pflichten aufzeigt. In der Praxis ist das Thema Rollen und Verantwortlichkeiten so gelebt, dass zwar offizielle Verantwortlichkeiten delegiert wurden, jedoch ist die jeweilige Hierarchiestufe in ständiger Abstimmung mit der nächsthöheren Hierarchiestufe. Das liegt natürlich daran, dass es Situationen gibt, die dies durchaus hergeben, zum anderen liegt es aber auch daran, dass die jeweiligen Mitarbeiter Angst haben zu entscheiden. Hier muss dann die höhere Hierarchiestufe eingreifen und dem Mitarbeiter entweder diese Angst nehmen oder den Mitarbeiter austauschen, da die Führungskraft durch eine derartige Arbeitsweise schnell in ineffizientes Micro-Management verfällt.  Steuern über Managementphasen 4) : Dass sich ein Projekt durch einen regelmäßigen und wiederkehrenden Kreislauf ausmacht, ist inzwischen klar. Dass dieser Kreislauf unter anderem über so genannte Managementphasen zu funktionieren hat, ist an dieser Stelle neu. Eine Managementphase stellt in der Logik von PRINCE2 eine abgeschlossene, eigenständige Projektphase dar. Diese kann <?page no="25"?> 26 1 Grundlagen zum Beispiel „Initiierungsphase“ oder „Testphase“ heißen. Allein der Name hinter der Managementphase gibt Aufschluss darüber, was in der jeweiligen Phase vonstatten geht. Immer am Ende einer jeweiligen Phase muss der Projektmanager an das Entscheidungskomitee, in PRINCE2 „Lenkungsausschuss“ (LA) genannt (in der Praxis aber auch oft als Steering-Committee bezeichnet), reporten. Hierdurch wird klar, dass ein Abschluss einer Managementphase ein essentielles Ereignis innerhalb eines Projekts darstellt. Ein Ereignis, in dem der Projektmanager sich natürlich rechtfertigen muss, der Lenkungsausschuss wichtige Entscheidungen treffen muss und auch sonstige, für eine Eskalation nicht ausreichende Ereignisse, Vorkommnisse oder einfach Anliegen besprochen werden. Welche Personen beziehungsweise Stakeholder in einem Lenkungsausschuss sitzen, wird unter dem Thema Organisation in Kapitel 5.3 konkret beschrieben. Wie lange eine Managementphase dauert, wie viele es davon gibt, wird ebenfalls noch konkreter unter dem Thema Fortschritt in Kapitel 5.8 beschrieben. In der Praxis werden Phasen oft wenig gelebt. Das liegt u. a. einen an dem hohen Stresslevel der Projektmanager, welche die Einteilung in logisch aufeinanderfolgende Phasen oft in ihrer Projektplanung schlichtweg vergessen oder sie fehlerhafterweise als obsolet ansehen. Neben dem tatsächlichen Vorteil, dass durch eine klare Gliederung der Phasen ein vereinfachtes Fortschritts-Tracking vonstattengeht, da immer zu einem genau bestimmten Zeitpunkt reportet werden muss, ist es auch ein nicht zu verkennender psychologischer Vorteil, dass man Phasen tatsächlich abschließt. Die Projektorganisation ist in ihrem täglichen Business nur von Problemen und Risiken sowie Zeit- und Budgetdruck getrieben. Da ist der Zwischeneffekt, etwas geschaffen beziehungsweise geschafft zu haben, ein super Mechanismus, um die Motivation dauerhaft ausreichend hochzuhalten.  Steuern nach dem Ausnahmeprinzip 5) : Ist das Grundprinzip „Steuern über Managementphasen“ als ein zeitlich getriebener Überwachungs- und Planungs- <?page no="26"?> 1.6 Die 7 Grundprinzipien 27 mechanismus zu werten, bezieht sich das Grundprinzip „Steuern nach dem Ausnahmeprinzip“ deutlich mehr auf die Ereignissteuerung. Um dieses Grundprinzip hinreichend gut zu leben, muss dieses Prinzip auch außerhalb der PRINCE2-Projektorganisation, also der in das Projekt aufgehängten Linie, bekannt, anerkannt und gelebt werden. Hierbei geht es fast um eine Art Wert, also eine innere Überzeugung. Man kann auch von einer Führungsphilosophie sprechen. Bekannt ist dieses Prinzip neben der PRINCE2-Terminologie auch aus der angewandten Betriebswirtschaftslehre, in der es als „Management by Exception“ gelehrt wird. Hierbei geht es im Grunde darum, als Führungskraft Verantwortung an die nächsttiefere Hierarchieebene zu delegieren. Das bringt immense Vorteile mit sich. Zum einen wird der in unserem Beispiel typische Projektmanager durch die Einbeziehung seiner Teammanager entlastet. Zum anderen werden neu einbezogene Mitarbeiter durch den Zuwachs an Verantwortung viel besser in den Projekterfolg einbezogen und dadurch ggf. noch zusätzlich motiviert. Gerade bei Großprojekten, bei denen es eine Vielzahl von Teammanagern gibt, muss das Prinzip gelebt werden, da ansonsten sehr schnell eine Überlastung des Projektmanagers eintritt. Damit dieses Ausnahmeprinzip funktioniert, sind einige wichtige Bestandteile zu beachten: Es sollte im Vorhinein eine klare Kommunikation der Rollen und Verantwortlichkeiten (siehe Grundprinzip „Definierte Rollen und Verantwortlichkeiten“) durchgeführt werden. Des Weiteren müssen auch Toleranzen mitdelegiert werden - also Bereiche, in denen der Projektmanager und der Teammanager Entscheidungen hinsichtlich Zeit, Budget, Qualität, Risiko, Umfang und Nutzen treffen können. In der Praxis ist wird dies meist deutlich intuitiver gehandhabt. Hier geben in aller Regel die Teammanager eine erste Indikation vor, auf deren Basis der Projektmanager dann im Rahmen seiner von dem Lenkungsausschuss vorgegebenen Toleranzen eine Budgetanpassung in seinem Sinne vornimmt. Die Tatsache, dass die Teammanager mit einem extra großen Puffer an Budget in die Verhandlung mit dem Projektmanager gehen, ist ein ungeschriebenes Gesetz. Ebenfalls ist es ein ungeschrie- <?page no="27"?> 28 1 Grundlagen benes Gesetz, dass der Projektmanager sich über diese Tatsache bewusst ist und im Rahmen dessen überdurchschnittlich viel der Budgetplanung der Teammanager wieder kürzt. Im Übrigen spielt sich dieses Szenario auf allen Planungsebenen, also Teammanager, Projektmanager, Lenkungsausschuss und Unternehmensmanagement ab: Die tiefere Ebene kommt mit einer deutlich höheren Budgetplanung als benötigt zur nächsthöheren Hierarchieebene, welche wiederum deutlich mehr aus der Planung streicht, als eigentlich benötigt ist, womit das Ergebnis im Grunde genau dem Planungsbedarf entspricht. Beide Parteien sind sich dessen in den meisten Fällen bewusst.  Produktorientierung 6) : In den meisten Projektmeetings hört man Teilnehmer immer nur über die Projektaktivitäten sprechen: die Aktivitäten aus letzter Woche, die Aktivitäten für diese Woche und welche schiefliefen. Hierbei verliert man jedoch schnell den Blick für das große Ganze und das, was am Schluss das Projekt liefern soll: das Produkt. Diesen Blick wiederherzustellen, ist als Ziel des Grundprinzips „Produktorientierung“ zu sehen. Dem Grundprinzip zufolge geht es darum, den Blick auf die vom Projekt zu liefernden Produkte zu lenken. Wobei Produkte hier nicht unbedingt physische Ware sein müssen, sondern auch immaterielle Produkte oder Dienstleistungen sein können. Das spiegelt sich vor allen in der Planung des Projekts wider. Hierbei plant man von dem Projektendprodukt, also dem Produkt, welches das Projekt am Ende als Output generieren soll, hin zu den jeweils tieferen, feineren Produktgruppen. Erst am Ende der Planungstiefe, also dann, wenn man auf der von den Teams extrem granular zu liefernden Produktebene angekommen, teilt man diese (Teil-)Teilprodukte auf dafür notwendige Aktivitäten auf. Es kommt demnach eine Art Rückwärtsplanung zum Einsatz.  Anpassung an die Projektumgebung 7) : PRINCE2 ist eine sehr umfangreiche Projektmanagementmethodik. Hierbei ist sie für Großprojekte absolut geeignet, durch die Anpassung an die Projektumgebung jedoch so adaptierbar und gene- <?page no="28"?> 1.6 Die 7 Grundprinzipien 29 risch, dass mit der Methodik annähernd jedes Projekt erfolgreich fertiggestellt werden kann.  Oft fällt auf, dass die Tendenz innerhalb der meisten Projekte eher Richtung „Admin Overhead“, also zu viele Templates, zu viel Administration, zu viele Meetings, geht als in eine schlanke, effiziente und damit angepasste Projektumgebung. Das liegt unter anderem an dem Irrglauben, dass wenig bis gar keine Administration Agile bedeutet und viel und umfangreiche Administration automatisch mit klassischem bzw. Wasserfall-Projektmanagement gleichzusetzen ist. „Managt man offiziell ein klassisches Projekt, sollte man automatisch einen hohen Administrationsaufwand mitbringen“, so zumindest die falsche Annahme vieler Projektmanager. PRINCE2 sagt hierzu allerdings klar, dass die Administration sich der Projektumgebung anzupassen hat. Wenn das Projekt beispielsweise weniger risikobehaftet ist, kann einem Projektmanager mehr Freiraum zu Verfügung gestellt werden als bei hohem Projektrisiko. <?page no="29"?> 30 1 Grundlagen <?page no="30"?> 1.7 Die 7 Themen 31 Die 7 Themen Wie bereits beschrieben, sind die sieben Grundprinzipien Werte, die einen erfolgreichen Projektablauf möglichst positiv beeinflussen sollen. Für die Werte muss es allerdings noch eine Beschreibung zur Umsetzung geben. Diese Beschreibung stellen die sieben Themen dar. Sie geben eine Antwort auf die Frage „Wie ist es zu tun? “. Die Inhalte müssen während des Projekts kontinuierlich behandelt werden. Im Folgenden sind die sieben Themen aufgeführt und kurz beschrieben. In den darauffolgenden Kapiteln wird jedes einzelne Thema, auch im Zusammenspiel mit den Prozessen, aufgearbeitet. Die sieben Themen sind:  Business Case 1)  Organisation 2)  Qualität 3)  Pläne 4)  Risiko 5)  Änderungen 6)  Fortschritt 7) Diese werden im Folgenden im Detail beschrieben:  Business Case: Das Thema Business Case wird durch das Grundprinzip der „fortlaufenden geschäftlichen Rechtfertigung“ getrieben. Es geht darum, Mechanismen einzurichten, welche a) dazu da sind, eine geschäftliche Rechtfertigung zu erlangen, und b) sie kontinuierlich zu pflegen. Im Kern geht es darum, ein Projekt so auszurichten, dass es über die gesamte Laufzeit auf Ziele der Organisation abzielt und es einen Nutzen bietet. Im Laufe des Buches gehen wir noch auf ein bestimmtes Dokument, den Business Case, tiefer ein. Dieses Dokument ist sozusagen die aus dem Thema Business Case herauskristallisierte Essenz, die <?page no="31"?> 32 1 Grundlagen schriftlich festgehalten wird. Hierbei ist zu beachten, dass nicht jedes Thema ein eigenes Dokument mit sich bringt.  Organisation: Hierbei widmen wir uns der Operationalisierung des Grundprinzips der „definierten Rollen und Verantwortlichkeiten“. Das Thema beschreibt die benötigten Rollen, die Rollenverteilungen, welche sich ausschließen und welche Kompetenzen und Verantwortungsbereiche hinter den verschiedenen Rollen festgeschrieben sein müssen. Es beantwortet die Frage, wer innerhalb einer Projektorganisation für die jeweilige Umsetzung verantwortlich ist.  Qualität: Das Thema Qualität beschreibt in seiner vollen Ausprägung den richtigen Umgang mit den Stakeholdern in Bezug auf die von Projekt zu erfüllenden Anforderungen. Das hier wichtigste Grundprinzip ist die „Produktorientierung“. Oft kommt es vor, dass Kunden zu Beginn eines Projekts mit nur sehr subjektiven Äußerungen an das Projektteam herantreten. „Das Haus der Chinesen soll deren Kultur entsprechen“ könnte bei der Olympiade eine typisch formulierte erste Anforderung sein. Die Aufgabe des Themas Qualität ist es demnach, dem Projektmanager Leitlinien an die Hand zu geben, mit denen er es schafft, die zuerst nur sehr weich formulierten Kundenqualitätserwartungen in hart definierte Projektabnahmekriterien zu überführen. Es geht darum, die Frage nach dem Was zu beantworten.  Pläne: Hierbei geht es um die Frage, wie etwas geliefert wird. Weiß man bereits aus einer guten Ausarbeitung des Themas Qualität, was der Kunde wünscht, muss man sich im nächsten Schritt mit einer Umsetzung der Kundenwünsche befassen. Damit befasst sich das Thema Pläne. Hierbei ist zu beachten, dass nicht nur die eigentliche Umsetzung geplant wird, sondern auch die Art und Weise, wie die Planung innerhalb eines Projekts durchgeführt wird. Welche Tools werden dafür genutzt? Wie sollte das Layout eines von dem Projekt zu liefernden Projektplans aussehen? Wie feinkörnig sollte die Projektplanung aufgestellt sein? All diese Fragen werden neben der eigentlichen Planung innerhalb <?page no="32"?> 1.7 Die 7 Themen 33 eines Projekts im Thema Pläne genauer beschrieben. Auch diesem hart an der Qualität arbeitende Thema liegt das Grundprinzip der „Produktorientierung“ sowie das Grundprinzip der „Steuern über Managementphasen“ zugrunde. Zweiteres, weil die Planung durch die Entscheidung der Anzahl der Managementphasen massiv beeinflusst wird.  Risiko: Wie bereits beschrieben, wird in der Terminologie von PRINCE2 das Risiko nicht per se als negativ gewertet. Vielmehr geht es darum, Risiken als Unsicherheiten anzusehen, die Auswirkungen sowohl in die negative als auch in die positive Richtung haben können. Wie mit Unsicherheiten in einem Projekt umgegangen werden soll, welcher Prozess nach der PRINCE2-Terminologie verwendet werden soll, welche Strategien es für Gegenmaßnahmen gibt, wird detailliert später im Thema Risiko behandelt.  Änderungen: Dieses Thema befasst sich mit einer Steuerung der Änderung der Anforderungen des Kunden. Hierbei geht es in erster Linie darum, Struktur in das Änderungssteuerungsverfahren zu bringen: Welche Arten von Änderungen gibt es? Welche prozessualen Unterschiede liegen hinter den verschiedenen Arten von Änderungen? Die Antworten liefert das Thema Änderungen. Darüber hinaus befasst sich das Thema Änderungen mit dem Konfiguarationsmanagement innerhalb eines Projekts. Dieses beschreibt, kurz gesagt, die Art und das Management von verschiedenen Versionen von Produkten. Das klingt zunächst sehr kryptisch und zugegebenermaßen ist das nicht für alle Projekte adaptierbar. Jedoch ist u. a. die Versionierung, besonders in der Softwareentwicklung, ein wichtiges Must-have. Versionierung bedeutet, dass jede neu releasede Version der Software sich klar von der vorangegangenen unterscheidet und auch entsprechend durch eine Versionsnummer so gekennzeichnet wird.  Fortschritt: Dieses Thema beschreibt, wie die Reporting-Kultur, die Eskalationswege und der Toleranzbereich eines Projekts aussehen sollen. Es soll hierdurch sichergestellt werden, dass zu jedem Zeitpunkt eine Aussage über den Projekt- <?page no="33"?> 34 1 Grundlagen fortschritt getroffen werden kann und der Projektmanager oder der Lenkungsausschuss dadurch in die Lage versetzt wird, zu jedem Zeitpunkt eine Entscheidung treffen zu können. <?page no="34"?> 1.8 Die 7 Prozesse 35 Die 7 Prozesse Die sieben Prozesse stellen die Ablaufbeschreibung zu den sieben Themen dar. Ein Prozess im Sinne von PRINCE2 hat dieselbe Beschreibung wie im Sinne der allgemeinen BWL: für einen definierten Input wird über eine vorgeschriebene Abfolge von Aktivitäten Wertschöpfung generiert und ein definierter Output als Mehrwert geliefert. Das Zusammenspiel der sieben Grundprinzipien mit den sieben Themen und sieben Prozessen kann man wie folgt zusammenfassen: Innerhalb der Managementphasen stellen die Prozesse die vorgegebenen Aktivitäten von der Projektvorbereitungsphase bis zum Abschluss eines Projekts dar. Innerhalb der vorgegebenen Prozesse werden die sieben Themen - unter Berücksichtigung des vierten Bausteins von PRINCE2, der Anpassung an die Projektumgebung, - behandelt und dadurch die sieben Grundprinzipien eingehalten. Im Folgenden sind die Prozesse aufgelistet und mit einigen prägnanten Worten beschrieben. Eine detaillierte Beschreibung der einzelnen Prozesse ist einer der Hauptbestandteile dieses Buches und verteilt sich daher in Folge auf mehrere Abschnitte. Dieses Buch ist - nebst eigenständiger Fortbildung und/ oder Prüfungsvorbereitung - auch Bestandteil unseres Online-Kurses und der Präsenztrainings. Um die Wortwahl konsistent zu halten, sind die Prozesse sowohl im Deutschen als auch im Englischen genannt. Im Übrigen werden im Folgenden auch die Abkürzungen der englischen Begriffe genannt, die im Buch und in den Trainings verwendet werden.  Vorbereiten eines Projekts - Starting up a project | SU 1) Der Prozess SU kommt bereits vor Beginn eines Projekts zu Anwendung - mit dem Ziel herauszufinden, ob sich ein Projektbeginn überhaupt lohnt. Dieser <?page no="35"?> 36 1 Grundlagen Prozess kommt einer Vorstudie ausgesprochen nahe. Eine Vorstudie kommt vor allem bei Großprojekten zum Einsatz, bei denen für eine solide Planung ein kurzes Vorprojekt initiiert wurde, um die Planung für das Großprojekt an sich sicherstellen zu können.  Lenken eines Projekts - Directing a Project | DP 2) Der Prozess DP wurde für den Lenkungsausschuss entwickelt, damit dieser im Rahmen seiner Möglichkeiten zu jeglichem Punkt im Projekt die letztendliche Kontrolle behalten kann.  Initiieren eines Projekts - Initiating a Project | IP 3) Der Prozess IP ist innerhalb des Projekts der Hauptprozess der ersten Projektphase. Er dient zur allgemeinen Orientierung, zur Erstellung eines Plans und zur ersten Arbeitsverteilung.  Managen eines Phasenübergangs - Managing a stage boundary | SB 4) Der Prozess SB ist ein sich je nach Anzahl an Managementphasen wiederkehrender Prozess, welcher für den Übergang von einer Projektphase in die nächste verantwortlich ist.  Steuern einer Phase - Controlling a Stage | CS 5) CS ist der in PRINCE2 am umfangreichsten beschriebene Prozess. Das liegt daran, dass die Haupt-Managementarbeit des Projektmanagers sich in diesem Prozess abzeichnet.  Managen der Produktlieferung - Managing Product delivery | MP 6) MP dient dazu, dem Projekt- und Teammanager einen Prozess an die Hand zu geben, über den sie ihre Arbeit und Arbeitspakete einander übergeben können. <?page no="36"?> 1.8 Die 7 Prozesse 37  Abschließen eines Projekts - Closing a Project | CP 7) In dem Prozess CP wird dem Projektmanager ein Rahmenwerk zu einem erfolgreichen Projektabschluss mit an die Hand gegeben. Ziel ist es, alle notwendigen Dokumente und Formalitäten über diesen Prozess abzudecken. <?page no="37"?> 38 1 Grundlagen Übungsfragen zu Kapitel 1 Hinweis: Es kann nur eine Antwort richtig sein. Die Auflösung findest Du in Kapitel 9. [1] Was ist eine der sechs Dimensionen der Projektleistung, die gemanagt werden muss?  Kunden  Menschen  Nutzen  Prozesse [2] Was ist ein charakteristisches Merkmal eines Projekts?  geringes Risiko  vermeidet Probleme und Belastungen zwischen Organisationen  Business as usual  bereichsübergreifend [3] Von was für einer Umgebung geht PRINCE2 als Basis aus?  Informationstechnologie  Kunden/ Lieferanten  Beschaffung  Programm [4] Was ist KEIN Faktor der Entscheidung, wie das Projekt in Managementphasen eingeteilt werden wird?  die Länge des Projekts  die Verfügbarkeit von Teammanagern  wann wichtige Entscheidungen im Projekt getroffen werden müssen <?page no="38"?> 1.9 Übungsfragen zu Kapitel 1 39  wie hoch das mit dem Projekt verbundene Risiko ist [5] Welches ist KEIN integrierter Baustein von PRINCE2?  die Grundprinzipien  die Techniken  die Themen  Anpassung von PRINCE2 an die Projektumgebung [6] Welcher Prozess ermöglicht es einer Organisation, eine Vorstellung davon zu bekommen, was mit den geplanten Projektarbeiten verbunden ist, bevor das Projekt genehmigt wird?  Lenken eines Projekts  Initiieren eines Projekts  Vorbereiten eines Projekts  Steuern einer Phase [7] Welches PRINCE2-Grundprinzip unterstützt das Konzept der Planung auf einer überschaubaren und vorhersehbaren Detailebene?  fortlaufende geschäftliche Rechtfertigung  Steuern nach dem Ausnahmeprinzip  Produktorientierung  Steuern über Managementphasen [8] Was ist ein Vorteil von PRINCE2? <?page no="39"?> 40 1 Grundlagen  Stakeholder werden aus der Planungs- und Entscheidungsfindung herausgehalten.  Teilnehmer kennen untereinander ihre Rollen und Anforderungen.  Stakeholder sind an der Sicherung der Projektarbeit nicht beteiligt.  Alle Probleme werden an alle Stakeholder eskaliert. [9] Welches ist eine der sechs Dimensionen der Projektleistung, die gemanagt werden sollten?  Präzision  Zuverlässigkeit  Umfang  Benutzerfreundlichkeit [10] Welches Thema liefert die Informationen, was benötigt wird und wie bzw. von wem es geliefert wird?  Organisation  Pläne  Business Case  Qualität [11] Welche Aussage ist KEIN charakteristisches Merkmal eines Projekts?  Birgt höhere Risiken als der normale Geschäftsbetrieb.  Personen mit unterschiedlichen Fähigkeiten realisieren eine Veränderung, die Auswirkungen auf andere außerhalb des Teams hat.  Der Lebenszyklus umfasst in der Regel sowohl die Lieferung der angestrebten Ergebnisse als auch die Realisierung des gesamten zu erwartenden Nutzens. <?page no="40"?> 1.9 Übungsfragen zu Kapitel 1 41  Eine für die Implementierung von Produkten befristet eingerichtete Managementstruktur. [12] Was ist einer der vier „integrierten Bausteine“ von PRINCE2?  Qualität  Rollenbeschreibungen  Prozesse  Produktbeschreibungen [13] Welcher der folgenden Punkte beschreibt KEINEN PRINCE2- Grundbaustein?  Prozesse  Themen  Anpassung an die Projektumgebung  Risiken [14] Welche der folgenden Aussagen zählt als eine der sechs Projektdimensionen?  Wissen  Partner  Prozesse  Nutzen [15] Welcher der folgenden Punkte beschreibt KEINE Methoden, in dem laut PRINCE2 Agile ein Projekt angepasst werden kann?  Neue Benamung von Meetings  Anpassung der 7 Grundprinzipien <?page no="41"?> 42 1 Grundlagen  Informalisierung von Meetings  Vereinfachung von bestehenden Berichten <?page no="42"?> 2 Grundlagen der Agilität Der Begriff Agilität Eines ist klar: Agilität ist im Trend. Aber wieso wollen auf einmal alle agil sein? Ist es einfach nur cool, etwas oder sich agil zu bezeichnen? Oder gibt es einen Hintergedanken? Im allgemeinen Sprachgebrauch Im allgemeinen Wortgebrauch wird der Begriff „Agilität“ als schnelle Reaktionsfähigkeit beschrieben. Oft werden auch alltägliche Dinge wie ein sportliches Auto oder ein sportlicher Lebensstil als agil beschrieben. Doch woher kommt die Assoziation von Sport und Agilität? Sportler und Sportwagen sind schnell und wendig und damit in der Lage, sich rasch auf neue Situationen einzustellen. Diese und weitere Merkmale finden sich auch in der Dimension der Agilität im (Projekt-)Management wieder. Im (Projekt-)Management Hierbei steht die Konzentration auf die Sicht der Kunden und User im Fokus. Der User muss verstanden werden. Dies gelingt durch frühe, schnelle und schlanke Entwicklungen für den Markt. Hierbei ist für den Lieferanten vollkommen frei zu definieren, wer der Kunde, was der Markt und was das Produkt ist. Dies kann auf sämtliche Wirtschaftsbereiche, sogar in sämtliche Lebenssituationen übertragen werden. Es ist grundsätzlich nicht einfach, sich in die Gedankengänge jener hineinzuversetzen, die das Wort Agilität inflationär und einfach als Buzzword verwenden. Einfach ist jedoch zu verstehen, wieso wir alle inzwischen agil sein wollen. <?page no="43"?> 44 2 Grundlagen der Agilität Grund sind die aktuellen Marktgegebenheiten. Wir möchten das Ganze anhand eines kleinen Beispiels aufzeigen: Steve Jobs präsentiert das erste iPhone → 2,5 Milliarden Menschen nutzen ein Smartphone Deutschland wird Weltmeister → Deutschland scheidet in der Vorrunde aus Barack Obama wird US-Präsident → Donald Trump wird US-Präsident Finanz- und Wirtschaftskrise weltweit → weltbeste Konjunkturentwicklung Facebook gilt als meistgenutzte Social Media-Plattform → Facebook verliert gegen Instagram und SnapChat massiv an Marktanteil Die EU gilt als stabiles und stetig wachsendes Konstrukt → BREXIT Du denkst, all diese Ereignisse, all diese Aufstiege und Abstiege bzw. Veränderungen reichen für mindestens 100 Jahre Weltgeschehen aus? Da müssen wir Dich enttäuschen. Das alles ist gerade einmal in 10 Jahren passiert. 10 Jahre, die die Welt positiv oder negativ verändert haben. 10 Jahre, auf die die Wirtschaft und alle darin befindlichen Unternehmen reagieren müssen. Wir stellen demnach fest, dass sehr große Veränderungen in immer schnelleren Zyklen und unvorhersehbarer aufkommen. Schaut man lediglich auf den technischen Fortschritt, sieht die Kurve der Veränderung noch steiler aus. Themen wie Blockchain, autonomes Fahren, Künstliche Intelligenz und Singularität (also die Verbindung von menschlichem Gehirn und Festplatte) stecken heute noch in den Kinderschuhen. Spätestens 2025 sollten einige dieser Themen jedoch so selbstverständlich sein wie der morgendliche Blick auf das Smartphone, um über Wetter, Verkehr und aktuelles Weltgeschehen Bescheid zu wissen. Projekte, die über mehrere Jahre gehen, haben demnach zwangsläufig ein großes Problem. Denn in der Zeit von der ersten Planung bis zur Auslieferung des Produkts hat sich die Welt einfach zu schnell weitergedreht. Das Produkt wird schlichtweg <?page no="44"?> 2.1 Der Begriff Agilität 45 nicht mehr gebraucht bzw. durch bessere und aktuellere Produkte ersetzt worden sein. Und genau hier kommt Agilität ins Spiel. Agilität bedeutet nichts weiter, als in schnellen Zyklen ein kleines Stück fertiges Produkt auf den Markt zu bringen, schnell vom Markt zu lernen und darauf adäquat zu reagieren. Agilität hat den Anspruch, den Wert des Produktes für den Kunden zu maximieren. Der Hintergedanke hierbei ist jedoch nicht ganz uneigennützig, denn ein wertvolles, von einem Kunden akzeptiertes Produkt ist nicht nur für den Kunden sehr wertvoll. Es beschert dem Unternehmen, das das Produkt am Markt anbietet, in der Regel auch überdurchschnittliche Umsätze und Gewinne. Vereinfacht könnte man auch folgende Formel dafür verwenden: Schnell mit einem Produkt auf dem Markt = schnell den Kunden verstehen = Kunden sind durch das Produkt glücklich = Unternehmen ist glücklich Klingt einfach, nicht wahr? Ist es auch. Unsere Erfahrung aus tausenden Projekttagen und hunderten durchgeführten Trainings kann eine Sache unverblümt bestätigen: Agilität ist einfacher als klassisches Projektmanagement. Im Folgenden gehen wir nochmal auf die im Schaubild dargestellten Begrifflichkeiten ein. <?page no="45"?> 46 2 Grundlagen der Agilität User-Fokussierung Hierunter versteht man, den Kunden bzw. den letztlichen Benutzer vollumfänglich in den Mittelpunkt zu stellen. Das liegt daran, dass das Produkt für den User entwickelt wird und von ihm aus die wertvollsten Anforderungen übermittelt bzw. gestellt werden. Kurzfristigkeit Da wir ein Produkt in eine sich schnell verändernde Welt bringen wollen, dürfen wir keine langen Entwicklungsphasen an den Tag legen, sondern müssen kurzfristig Ergebnisse generieren. Diese Ergebnisse müssen hierbei keine großen Features enthalten. Kleine, aber wertstiftende Teilprodukte sind hierbei absolut ausreichend. <?page no="46"?> 2.2 Was bedeutet Agilität im Projektmanagement - Überblick 47 Änderungsfähigkeit Das unpassendste Verhalten, das ein Mitarbeiter in einem agilen Projekt haben kann, ist das Beibehalten von Plänen, wenn sich andere Gegebenheiten angepasst haben. Dieses Verhalten ist in einem agilen Projekt abzulegen. Es gilt: Wenn während der Produktentwicklung Änderungen am Plan entstehen, sind diese zu begrüßen. Denn Änderungen bedeuteten einen Mehrwert für das Produkt und für den Kunden. Marktfähigkeit Ein Produkt bzw. Teilprodukt, das am Ende jedes Zyklus released wird, muss marktfähig sein. Ist ein Teilprodukt nicht marktfähig, ist es als zu groß eingeplant worden. Was bedeutet Agilität im Projektmanagement - Überblick Nachdem wir uns nun grundsätzlich mit dem Begriff der Agilität beschäftigt haben, schauen wir uns das Ganze tiefgehender im Hinblick auf das Projektmanagement an. Innerhalb des agilen Projektmanagements könnte man „Agilität“ wie folgt definieren: Agilität ist ein inkrementeller Entwicklungszyklus, welcher mit einer Reihe von Prinzipien und Praktiken zur schnellen Lieferung von Produkten verwendet wird. Hierbei ist der Fokus auf den Kunden bzw. Endnutzer gerichtet. Innerhalb vom agilen Projektmanagement kann man sagen, dass kein anderer Stakeholder eine derart hohe Priorität wie der Endnutzer aufweist. Natürlich muss dabei beachtet werden, dass es sich um die Priorität für das Produkt bzw. den Produktnutzen handelt. <?page no="47"?> 48 2 Grundlagen der Agilität Ein Stakeholder, wie beispielsweise der unternehmensinterne Auftraggeber, hat auch innerhalb agiler Projekte einen hohen Stellenwert, da er die Budgetverantwortung trägt. Jedoch ist von einem gewissen Mindset des Auftraggebers hinsichtlich der Philosophie von „Agilität“ auszugehen. Diese Philosophie besagt im Grunde, dass der Kunde bzw. der Kundennutzen an erster Stelle steht. Dies sollte in agilen Projekten auch von einem Auftraggeber verstanden und schließlich umgesetzt werden. Natürlich wirkt das in der Theorie, wie in diesem Buch hier, sehr einfach dahingesagt. In der Praxis, und das zeigen viele unserer Projekterfahrungen, ist dieser Aussage noch eine gewichtige zeitliche Komponente hinzuzufügen. Es geht um die Zeit, die der oder die Stakeholder benötigen, um sich mit dem Gedanken, dem Mindset der Agilität anzufreunden, es zu verstehen. Hierbei spricht man auch von dem so genannten Marturity of Agility - dem Reifegrad an Agilität. Im Folgenden werden wir uns um das Thema „Agiles Mindset“ noch weiter kümmern. Im nachstehenden Bild wird der Gedanke der Agilität noch mehr verdeutlicht. Grundsätzlich gilt innerhalb des Projektmanagements: Ein Projekt erzeugt einen Output, also ein Produkt, und dieses erzeugt ein Outcome, also eine (hoffentlich) positive Auswirkung beim Kunden. Übersetzt in die Welt des agilen Projektmanagements: 1) Arbeit & Entwicklung: also die tägliche Entwicklungsarbeit, die innerhalb der agilen Projekte geleistet werden. führen zu 2) einem Produkt oder Teilprodukt: also den ersten inkrementellen Ergebnissen der Entwicklung, welche an die Kunden kommuniziert werden. Also live genommen werden. <?page no="48"?> 2.2 Was bedeutet Agilität im Projektmanagement - Überblick 49 führen zu 3) Kundennutzen: Der Wert des Teilprodukts ist immer höher als ohne Teilprodukt. Wichtig ist an der Stelle, dass Kunden immer Feedback geben. Oft muss man hierzu natürlich auch aktiv auffordern. Aber in Zeiten, in denen überall Kundenrezensionen Standard sind, fällt dies sicher einfacher als noch vor 20 Jahren. Was passiert nun mit diesem Feedback? Das Feedback wandert zurück zu den Entwicklern, die darauf reagieren. Was lief gut, was lief schlecht? Diese Fragen sind von enormen Wert, da sie die so genannte UX - die User Experience, also wie wohl sich ein Kunde während der Benutzung des Produkts fühlt, massiv beeinflussen. Im unteren Teil des Schaubilds ist die Herangehensweise zu erkennen, wie ein derartiges Produkt innerhalb des agilem Projektmanagements released, also auf den Markt gebracht wird. 4) MVP: Das MVP steht für das so genannte Minimal Viable Product und kommt aus dem Lean-StartUp-Gedanken. MVP bedeutet nichts weiter, als ein neues Produkt begrenzt auf die minimalsten Funktionen und Features zu entwickeln und live zu nehmen, um ein erstes Feedback des Kunden zu erlangen. Es ermöglicht ein deutlich schnelleres „Go Live“ der ersten Version, als auf ein vollumfängliches Produkt zu warten. Mehr zum MVP finden wir dann im Kapitel „Lean StartUp“. 5) und 6) V2 und V3: Dies sind weitere Versionen des Produkts. Sie stellen dann die auf Grundlage des Feedbacks weiterentwickelten neuen Versionen des Produkts dar. Je nachdem, wie umfangreich ein Produkt sein soll, können hier 100 Versionen erstellt werden. <?page no="49"?> 50 2 Grundlagen der Agilität <?page no="50"?> 2.3 Was bedeutet Agilität im Projektmanagement - Einblick 51 Was bedeutet Agilität im Projektmanagement - Einblick Vergleicht man agiles Projektmanagement mit den klassischen Projektmanagement-Techniken wie dem Wasserfall- oder dem V-Modell, so fällt auf, dass zwar eine ähnlich iterative Vorgehensweise vorhanden ist, jedoch ein entscheidender Faktor den Unterschied macht: ein marktfähiges Produkt am Ende einer Iteration. Iteration Eine Iteration stellt eine kurze, zeitlich begrenzte Phase innerhalb eines langfristigen Vorhabens, wie hier im Beispiel ein Projekt, dar. Zu beachten ist hierbei, dass am Ende einer Iteration ein nutzbares Ergebnis vorhanden ist. In PRINCE2 Agile wird dieser Liefergegenstand am Ende jeder Iteration, abgeleitet aus SCRUM, auch gerne als Inkrement bezeichnet. Beispiel: Ein Team von Software-Entwicklern entwickelt ein neues Feature für das neue Tool. Das neue Feature wäre das Inkrement und die Zeit, in der das Feature entwickelt wird, wäre die Iteration gewesen. Verfolgt man im klassischen Projektmanagement spezifizierte Phasen bzw. Iterationen wie Analyse-, Design-, Umsetzung- und Testphase, sind im agilen Projektmanagement die jeweiligen Phasen bzw. Iterationen alle mit den vier genannten Aktivitätsbereichen versehen. Die folgende Grafik veranschaulicht die Vorgehensweise im agilen Projektmanagement. Innerhalb der eben genannten Zeit, in der das neue Feature für die Software entwickelt wird, wird im agilen Projektmanagement sowohl analysiert, designt, umgesetzt und getestet. Das klingt nach hohem Aufwand. Ist es auch. Jedoch muss innerhalb der kurzen Zeit „nur“ ein Software-Feature umgesetzt werden; im klassischen Projektmanagement wäre es eine komplette Software. Der Vorteil dieser Vorgehensweise Durch dieses Vorgehen kann dem Kunden am Ende jeder Iteration ein fertiges und marktfähiges (Teil-)Produkt vorgelegt werden. Der Kunde gibt sein Feedback, das <?page no="51"?> 52 2 Grundlagen der Agilität Projekt nimmt das Feedback - priorisiert und bewertet - als Scope für die nächste Iteration mit auf. Hierdurch entsteht ein deutlich kundennäheres Produkt, als es im klassischen Projektmanagement je möglich wäre. Der Grund für diese iterativ inkrementelle Vorgehensweise liegt auf der Hand: Der Kunde weiß nicht, was er will, bis er das erste Ergebnis live vor sich sieht. Die Erfahrung zeigt dann, dass die Realität mit der Vorstellung nur noch wenig gemein hat. Ist diese Vorgehensweise für jedes Projekt geeignet? <?page no="52"?> 2.4 Das Agile Manifest - Eine Geschichte der Agilität 53 Die Antwort lautet nein. Es scheint zwar oft so, als wären wir ein absoluter Verfechter der agilen Projektmanagement-Vorgehensweise. Jedoch ist dies, wie alles im Leben, immer nur dosiert dort anzuwenden, wo es sinnvoll ist. Generell gilt die Faustformel: Hat man ein derartiges Produkt schon mal entwickelt und kennt man genauestens die Anforderung, sollte man eher zu einer klassischen Projektmanagementmethode tendieren. Ist das Produkt neu und sind die Anforderungen unklar, sollte man eher nach einer agilen Projektmanagementmethodik greifen. Das Agile Manifest - Eine Geschichte der Agilität Nachdem wir nun die grundsätzlichen agilen Gedanken verstanden und unser Agile Mindset mehr und mehr schärfen, erlauben wir uns einen ehrfürchtigen Blick in die Vergangenheit: Agilität hat eine lange Geschichte. Zwar erlebt es im letzten Jahr des 20. Jahrhunderts in sämtlichen Geschäfts- und Unternehmensbereichen einen echten Boom, jedoch arbeiten einige Branchen schon seit rund 30 Jahren mit dem agilen Gedanken. Bereits damals gab es viele unterschiedliche agile Methoden, die das Vorgehen derartig manifestierten, dass es zu verschiedenen „Lagern“ kam: dem agilen Lager und dem Lager des klassischen Projektmanagements. Bis heute gibt es viele Verfechter beider Lager, die sich einen erbitterten Kampf um die „Wahrheit“ im Projektmanagement liefern. Aus unserer Sicht gibt es weder richtig noch falsch. Ein guter Projektmanager sollte sowohl Methoden des klassischen wie auch des agilen Projektmanagements kennen. Und insbesondere PRINCE 2 Agile bildet dabei die perfekte methodische Brücke zwischen beiden Welten. Unserer Meinung nach liegt die Wahrheit letztlich in <?page no="53"?> 54 2 Grundlagen der Agilität der Mitte. Aus den beiden idealtypischen Lagern muss das jeweils Beste selektiert für die Praxis angewendet werden. Ähnlich sehen es auch Vorreiter und Querdenker der beiden Lager. So kamen am 13. Februar 2001 die Vertreter der agilen Welt und der agilen Frameworks zusammen, um eine Art Lobby zu gründen: Repräsentanten von Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming und anderen agilen Methoden versammelten sich in einem beschaulichen, verschneiten Örtchen in den USA. Das Ziel: Eine einheitliche, framework-übergreifende Auflistung von Werten, welche in der agilen Entwicklung als wichtig empfunden werden. Hierzu passt ein Zitat von Jim Highsmith, ein großer Vordenker im Bereich des agilen Projetkmanagements, im Nachgang des Agilen Manifests: „Die Agile-Bewegung ist keine Anti-Methodologie … Wir wollen ein Gleichgewicht wiederherstellen. Wir nutzen die Modellierung, aber nicht um ein Diagramm in einem staubigen Unternehmen abzulegen. Wir akzeptieren Dokumentationen, aber nicht Hunderte von Seiten von nie gepflegten und selten verwendeten Büchern. Wir planen, erkennen aber die Grenzen der Planung in einem turbulenten Umfeld.“ Die folgenden niedergeschriebenen Wertepaare sollen eine aussagekräftige Idee davon geben, welchen validierten Gedankengang ein „Agilist“ an den Tag legen soll. Hierbei gilt der erstgenannte Wert als wichtiger; der zweitgenannte gilt jedoch nicht als unwichtig, lediglich weniger wichtig im Vergleich zum ersten Wert. Wir schätzen … … Menschen und Zusammenarbeit mehr als Tools und Prozesse Hierbei ist gemeint, dass es sinnvoller ist, z.B. Menschen in einen Raum zu setzen als sie regelmäßig über digitale Tools miteinander kommunizieren zu lassen. <?page no="54"?> 2.4 Das Agile Manifest - Eine Geschichte der Agilität 55 … funktionierende Software (Teilprodukt) ist mehr als umfassende Dokumentation Stell Dir vor, es geht zum Ende einer Iteration hin. Die Zeit reicht jedoch nicht mehr aus, das Teilprodukt und die Dokumentation fertig zu machen. In der agilen Denkweise würde man das Teilprodukt dennoch live nehmen und erst im Nachgang die Dokumentation nachziehen. Man würde mutig agieren. … Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen Vertragsverhandlungen sind lästig und zeitaufwändig. In der Praxis diskutieren viele Dienstleister wegen Kleinigkeiten mit dem Kunden, nur um die Zeit abrechenbar zu <?page no="55"?> 56 2 Grundlagen der Agilität machen. Davon wird in der agilen Welt abgesehen. Vertragsverhandlungen sind wichtig, keine Frage. Jedoch sollte dies immer im Verhältnis zum dahinterliegenden Ertrag stehen. … Reaktion auf Veränderung mehr als Planerfüllung Es ist davon auszugehen, dass Änderungen für das Produkt dieses stets wertvoller machen. Daher werden Änderungen sogar begrüßt, da sie das Produkt ein Stück näher zum Kunden bringen. Pläne werden hierbei nicht außer Acht gelassen. Sie werden nur sehr viel kleiner, kürzer und schlanker erstellt, um bei einer Änderung nicht immens Seiten des Planes aktualisieren zu müssen. Die agilen Prinzipien Neben dem agilen Manifest, welches die Abgrenzung von „Agilität“ zu „klassischem“ Projektmanagement darstellt, wurden auch die agilen Prinzipien entworfen und ein gemeinsames Verständnis dafür geschaffen. Die agilen Prinzipien sollen Agilität in einfachen und prägnanten Sätzen verständlich machen. 1) „Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.“ Damit soll ein schnelles Feedback, das zu einem wertvolleren Produkt führt, gewährleistet werden. 2) „Heiße Änderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.“ Hierbei gilt die Grundannahme, dass selbst eine späte Änderung besser ist, als das unveränderte Produkt dem Kunden zu übergeben. 3) „Liefere funktionierende Software (Produkte) regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.“ <?page no="56"?> 2.5 Die agilen Prinzipien 57 Damit man jedoch funktionierende Software innerhalb kurzer Zeitspannen liefern kann, ist die Grundannahme wichtig, dass es sich hierbei um sehr schlanke Lösungen handelt. 4) „Fachexperten und Entwickler müssen während des Projekts täglich zusammenarbeiten.“ Hierbei ist zum einen gemeint, dass alle Projekteilnehmer den vollen Fokus auf das Projekt richten - und nicht mehrere Projekte gleichzeitig bedienen sollen -, zum anderen, dass die Personen persönlich an einem Ort zusammenarbeiten. 5) „Errichte Projekte rund um motivierte Menschen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen.“ Hierbei gilt die Grundannahme, dass motivierte Menschen per se weniger Kontrolle und Steuerung benötigen als unmotivierte bzw. extrinsisch motivierte Mitarbeiter. 6) „Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.“ Auch hierbei geht es wieder um die Zusammenarbeit vor Ort - nicht um digitale Kommunikation. 7) „Funktionierende Software (bzw. Produkt) ist das wichtigste Fortschrittsmaß.“ Statt über Dokumente und Berichte freut sich jeder Stakeholder deutlich mehr über reale Produktergebnisse. 8) „Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.“ Ziel ist somit, dass nach einem erfolgreichen Abschnitt eines Projekt die Auftraggeber unmittelbar danach nicht eine deutlich höhere Geschwindigkeit verlangen. <?page no="57"?> 58 2 Grundlagen der Agilität 9) „Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.“ Das Feedback zu einem guten Produkt macht es zu einem sehr guten Produkt. Ist die Grundannahme, dass ein Team sein Bestes gegeben hat, erfüllt, kann man davon ausgehen, dass das Feedback sehr schmal ausfällt. Das schmale Feedback ist jedoch extrem wertvoll. Geht man jedoch von Anfang an mit einem schlechten Produkt live, ist ein Großteil des Feedbacks, das ankommt, meist schon den Entwicklern und Designern selbst bekannt. 10) „Einfachheit oder die Kunst, die Menge nicht getaner Arbeit zu maximieren.“ Der Begriff „Feature Creap“ beschreibt das Paradoxon, dass man innerhalb eines Produkts sehr schnell sehr viele Features erdenkt. Diese machen das Produkt jedoch, vor allem in der Entwicklung, maximal komplex. Die Kunst hierbei ist, die Features, die nicht notwendig sind, maximal zu minimieren. 11) „Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.“ Selbstorganisierte Teams sind kreativ, da sie Probleme selbst lösen müssen. Diese Kreativität ist nicht von extern steuerbar, weshalb die besten Architekturen und Anforderungen in selbstorganisierten Teams entstehen. 12) „In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.“ Dies geschieht durch so genannte Retrospektiven, in denen Verbesserungsvorschläge generiert und in der folgenden Zeit umgesetzt werden sollen. <?page no="58"?> 2.6 Übungsfragen zu Kapitel 2 59 Übungsfragen zu Kapitel 2 Hinweis: Es kann maximal eine Antwort richtig sein. Die Auflösung findest Du in Kapitel 9. [1] Was ist eine der Fokussierungen im agilen Projektmanagement?  Kunden (User)  Menschen  Gewinn  Software [2] Was ist ein MVP?  Eine Programmiersprache  Das kleinste anzunehmende Produkt des Projekts  Ein Meeting innerhalb von PRINCE2 Agile  Ein Bericht innerhalb von PRINCE2 Agile [3] Das Agile Manifest beschreibt 4 Aussagen, die die Arbeitsweise der Agiltiät klarstellen sollen. Welche der folgenden ist KEINE davon? Wir schätzen:  Menschen und Zusammenarbeit mehr als Tools und Dokumentation  Funktionierende Software mehr als umfassende Dokumentation  Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen  Reaktion auf Veränderung mehr als Planerfüllung <?page no="59"?> 60 2 Grundlagen der Agilität [4] Wie viele agile Prinzipien gibt es?  10  11  12  13 <?page no="60"?> 3 Grundlagen von PRINCE2 Agile Die Idee hinter PRINCE2 Agile Die Idee hinter der Tailoring-Ausprägung von PRINCE2 liegt darin, das große und umfassende Projektmanagement Framework PRINCE2 mit anderen, agilen und schlanken Methoden wie Kanban, Extreme Programming, SCRUM, Lean StartUp und vielen mehr zu vereinen und dadurch kompatibel zu machen. Keine der genannten Methoden stellt allein genommen einen ganzheitlichen Projektmanagementansatz dar. Vielmehr liegt der Fokus in jenen Methoden auf der Umsetzung innerhalb von Projekten und Produktenwicklungszyklen. Anders ist es bei PRINCE2. Diese Methode stellt per se einen generischen Ansatz zum umfassenden Projektmanagement dar. Die Kombination von einem umfangreichen und vor allem ganzheitlichen Framework wie PRINCE2 und einem oder mehreren agilen Frameworks ist nicht untersagt. Im Gegenteil: PRINCE2 begrüßt solche Anpassungen, da die Generik von PRINCE2, welche nur bis zur Ebene der Umsetzung innerhalb eines Projekts beschrieben ist (siehe dicker Strich innerhalb des Schaubildes), durch die agilen Frameworks an Qualität und Verständnis gewinnt. Das Schaubild an sich stellt die verschiedenen Ebenen eines Projekts bzw. einer Projektorganisationsstruktur, in Verbindung von mehreren Phasen eines Projekts, anhand der aus Abschnitt 1.7 bekannten Prozesse von PRINCE2 dar. <?page no="61"?> DP Ebene des Lenkungsausschusses, der über die gesamte Projektlaufzeit besteht. SU/ CS/ SB/ CP Ebene des Projektmanagers, der in den verschiedenen Phasen zu verschiedenen Zeitpunkten eines Projekts einen dieser Prozesse anwendet. 62 3 Grundlagen von PRINCE2 Agile <?page no="62"?> 3.2 8 Guidance Points 63 MP Die Lieferebene, als Prozess für die Teams, stellt die am wenigsten beschriebene Ebene innerhalb von PRINCE2 dar. Das liegt daran, dass es auf dieser Ebene derartig unterschiedliche Ausprägungen von Teams gibt, dass eine Generik fehl am Platz wäre. Umgekehrt bedeutet das vor allem für PRINCE2 Agile, dass hier die meisten Anpassungen, je nach Art der agilen Methodik, Platz finden. Die unten aufgeführten Loops stellen in der agilen Welt einen Anpassungsprozess aufgrund von Feedback dar. Dieses wird natürlich auf der Ebene der Teams behandelt und gegebenenfalls in das Produkt eingearbeitet. 8 Guidance Points Im Folgenden stellen wir Dir die 8 Guidance Points dar, welche PRINCE2 Agile beschreiben. Sie helfen, mit nur wenigen Sätzen zu verstehen, wie es PRINCE2 Agile auf der großen Landkarte der IT-, Agile- und Projektmanagement-Frameworks einzuordnen gilt. [1] PRINCE2 ist die Basis Die Basis von PRINCE2 Agile ist PRINCE2 als ganzheitliches Projektmanagement Framework. PRINCE2 Agile ist keine neue Version, sondern vielmehr eine Leitlinie, wie dem Grundprinzip der “Anpassung an die Projektumgebung“ für den agilen Bereich nachgekommen werden kann. [2] PRINCE2 Agile ist neutral zum Entwicklungsprozess PRINCE2 Agile ist ein Neutral zum Entwicklungsprozess der Organisationen. Unabhängig davon, ob diese mit SCRUM oder Extrem Programming arbeiten, kann PRINCE2 Agile darauf adaptiert werden. [3] Agilität kommt aus der IT. PRINCE2 Agile ist nicht IT-limitiert. <?page no="63"?> 64 3 Grundlagen von PRINCE2 Agile [4] Agile Frameworks sind oft IT-limitiert. PRINCE2 Agile nicht. [5] P2 Agile ist nicht limitiert auf Scrum. Auch wenn Scrum gerade am Markt das Framework ist, distanziert sich P2 Agile dahingehend, dass es nicht nur mit Scrum funktionieren kann, sondern wie wir hier in diesem Buch bemerken auch mit anderen Frameworks ausgezeichnet zusammen wirken kann. [6] SCRUM und Kanban sind die am weitesten verbreiteten Frameworks. Im Gegensatz zu agilen Frameworks und der Idee der Agilität generell ist PRINCE2 Agile nicht aus der IT geboren und auch nicht auf die IT limitiert. Ferner limitiert sich PRINCE2 Agile auch nicht auf die Zusammenarbeit mit SCRUM. Korrekt ist, dass SCRUM und Kanban die verbreitetsten agilen Frameworks sind, jedoch bietet PRINCE2 Agile Anknüpfungspunkte für alle weiteren agilen Frameworks. [7] Agilität ist der Zusammenschluss von Behaviors, Konzepten, Framework und Techniken. Agilität ist ein großer Zusammenschluss von Behaviors, Konzepten, Frameworks und Techniken, welche erst in einem guten Zusammenschluss die Agilität in Fülle wirken lassen. [8] Agilität ist nicht binär. Hierbei ist zu beachten, dass Agilität nicht binär zu betrachten ist. Oft wird die Frage gestellt, ob agil oder nicht. Vielmehr sollte jedoch die Frage nach dem „wie viel agil? “ gestellt werden. Fix oder Flex? Kommen wir zu einer bekannten Dimensionsfestlegung innerhalb von PRINCE2 bzw. innerhalb vieler Projektmanagement-Frameworks. Zeit, Kosten, Qualität, Risiko, Umfang und Nutzen stellen die sechs Projekt- <?page no="64"?> 3.3 Fix oder Flex? 65 dimensionen dar, die ein Projektmanager im Laufe seines Projekts im Blick haben und managen muss. In vielen agilen Frameworks sind diverse Dimensionen sehr flexibel gehalten. Dieser Flexibilität nimmt sich PRINCE2 Agile zumindest in Teilbereichen an. Andere Dimensionen hingegen werden in PRINCE2 Agile maximal „eingefroren“ oder „fixiert“. Gefixte Dimensionen haben keinerlei Toleranzen. Das ist anders als es in PRINCE2 üblich ist. Man hat dort in sämtlichen Dimensionen einen Toleranzbereich vorgegeben, innerhalb dessen die jeweilige Hierarchiestufe einen eigenen Entscheidungsspielraum vorweisen kann. In PRINCE2 Agile hingegen ist die gefixte Dimension auch wirklich als fix anzusehen. Wie also kann man innerhalb eines Projekts agieren, wenn die Dimensionen Zeit & Kosten, wie es in PRINCE2 Agile vorgegeben ist, fixiert sind? Richtig, man muss an den anderen vier Dimensionen „schrauben“. Beispiel: Sechs Wochen vor Projektende erkennt der Projektmanager, dass die Software nicht mehr rechtzeitig fertig wird. Was kann er tun? Die Zeit und das Geld sind fix, es können also nicht mehr Projektmitarbeiter engagiert werden, um das „Gap“ aufzufangen. Mit den bestehenden Mitarbeitern wird die Zeit jedoch gerissen. Eine Verlängerung des Projekts ist aufgrund der gefixten Zeit auch nicht möglich. Die einzige Option bleibt ganz alleine darin, die Qualität und den Umfang des Projekts dahingehend zu verändern, dass die Deadline eingehalten werden kann. Zu verändern heißt natürlich in den meisten Fällen zu verringern. Soll man die Qualität und den Umfang des Projekts wirklich herunterschrauben, nur um innerhalb der Deadline zu liefern? Hat man dann nicht ein schlechtes Produkt auf dem Markt? Wir können Deine Denkweise absolut nachvollziehen. Schließlich ist es so, dass wir gewohnt sind, immer alles perfekt zu machen. Aber wir können Dich in einer Sache <?page no="65"?> 66 3 Grundlagen von PRINCE2 Agile beruhigen: Ein derartiges Projektvorgehen wird es sicher nicht bei einer über einen Fluss führenden Autobahnbrücke geben. Vielmehr kommt ein solches Projekt in der Softwareentwicklung zur Anwendung, wobei die Grundannahme besteht, dass es besser ist, dem Kunden eine minderwertige Software vorzulegen als gar keine Software. Denn jede Minute, in der der Kunde die Software nutzen kann, ist eine wertvolle Minute, in der der Kunde testen und Feedback geben kann. Feedback macht unser Produkt immer viel wertvoller als es jede Art von „Perfektion“ je liefern kann. Bei Bedarf bringen flexible Dimensionen, wie der Name schon sagt, einen großen Toleranzbereich mit. Hier findet das Grundprinzip „Management nach dem Ausnahmeprinzip“ volle Anwendung. Es geht darum, das Projektmanagement mit einem gewissen Toleranzbereich auszustatten. Ferner handelt es sich bei diesen Dimensionen um Nutzen und Risiko, welche per se sowieso nicht maximal gefixt werden können. Denn der Nutzen ergibt sich aus der gelieferten und vor allem vom Kunden wahrgenommenen verstandenen Qualität des Produkts. Risiken hingegen liegen nicht selten vor allem außerhalb der „Macht“ des Projektmanagers, weswegen auch hier eine maximale Fixierung nur bedingt sinnvoll erscheint. Flexible Dimensionen dagegen sind innerhalb des Projekts bzw. innerhalb einer jeweiligen Iteration flexibel zu gestalten. Wie in dem obigen Beispiel beschrieben, ist die Sinnhaftigkeit dieser flexibel gestalteten Dimensionen durchaus verständlich. In der Theorie klingt das sehr einfach und verständlich. Hierbei ist uns aus Tausenden von Projekttagen jedoch auch durchaus bekannt, dass es Parameter gibt, die diese Theorie außer Acht lässt. Themen wie Politik (gerade in Konzernen), persönliche Befindlichkeiten (eigentlich überall), unklar gelebte Rollen und Angst vor Entscheidungen werden hierbei nicht berücksichtigt. Vereinfacht gesagt: Der Faktor Mensch macht oft einfach wirkende Frameworks in der Praxis zu einer echten Herausforderung, zum Spießrutenlauf. <?page no="66"?> 3.4 Die 5 Ziele des Flexiblen 67 © AXELOS Hierbei hilft unserer Meinung nach vor allem Moderationsgeschick und das nötige Händchen Empathie, um solche Probleme frühzeitig zu erkennen und mit dem hier in diesem Buch erlernten Mindset, diesen Problemen entgegenzuwirken. Die 5 Ziele des Flexiblen Wie nun erlernt, benötigt ein agiles Projekt gewisse Dimensionen in einer maximal flexiblen Umgebung. Diese Art von Flexibilität hat gemäß der PRINCE2 Agile Terminologie fünf Ziele zum Ausdruck, die damit verfolgt werden sollten. <?page no="67"?> 68 3 Grundlagen von PRINCE2 Agile Nutze Deadline/ Timeboxes aus Timeboxes bzw. Deadlines sind eine große Hilfe, um die Komplexität zu reduzieren. Ohne eine gesetzte Timebox werden nur unfertige Produkte erstellt. Hält man die Timebox jedoch von Anfang an fix, müssen Produkte so errichtet werden, dass sie innerhalb der Timebox bzw. der Deadline fertig werden. Wird bemerkt, dass man mit einem Produkt die Timebox nicht einhalten kann, kommt die Flexibilität zum Zug, welche es erlaubt, an Umfang und Qualität zu sparen. Schütze dein Qualitätsniveau frühzeitig Damit die Flexibilität in einem Projekt hinsichtlich Umfang und Qualität vor allem zu Ende eines Projekts gewahrt bleiben kann, bedarf es eines frühzeitigen Qualitätssicherungsprozesses. Hält man diesen von Beginn an hoch, müssen keine zeitraubenden QS-Maßnahmen gegen Ende eines Projekts erfolgen, sondern der Fokus kann dann auf die noch zu meisternden Produkte gelegt werden. Heiße Änderungen willkommen Eine Änderung stellt einen Kundenwunsch dar, der zur Steigerung des Produktwertes beiträgt. Dieses Grundverständnis ist notwendig, um die Flexibilität innerhalb eines Projekts zu akzeptieren. Halte das Team stabil Wird gegen Ende einer Phase, einer Iteration oder eines Projekts festgestellt, dass die gewünschte Qualität oder der gewünschte Umfang nicht beendet werden kann, neigt man als Projektmanager dazu, mit mehr Ressourcen entgegenzuwirken. Das hat zur Folge, dass die Geschwindigkeit maximal abnimmt. Einarbeitung und neue Storming-Phasen eines Teams bewirken erst in der Mittelfristigkeit ihren Erfolg. Damit die Flexibilität des Umfangs und der Qualität gewahrt bleiben kann, muss das Team stabil und nicht veränderbar aufgestellt sein. <?page no="68"?> 3.4 Die 5 Ziele des Flexiblen 69 Akzeptiere, dass der Kunde nicht alles braucht Der Qualitätsanspruch vieler Projektmitarbeiter ist es, eine 100%-Lösung abzuliefern. Hierbei sind vor allem viele Features enthalten, die als Entwickler oft Sinn ergeben, dem Kunden jedoch keinerlei Mehrwert stiften. Es ist wichtig, dies zu verstehen und schließlich zu akzeptieren, dass die Einfachheit siegt. ​ Nutze Deadlines/ Timeboxes aus Schütze dein Qualitätsniveau frühzeitig Heiße Änderungen willkommen Halte das Team stabil Akzeptiere, dass der Kunde nicht alles braucht <?page no="70"?> 4 Die agilen Methoden Neben der klassischen Projektmanagementmethode PRINCE2 gibt es eine Vielzahl von agilen Methoden, welche innerhalb von PRINCE2 Agile mit PRINCE2 angepasst werden. Die drei wichtigsten und auch am häufigsten verwendeten Methoden, außerhalb des skalierten Umfeldes, schauen wir uns in diesem Kapitel genauer an. Wir unterscheiden zwischen:  Lean StartUp Einer Methode zum schlanken Aufbau von Organisationen, auch Projektorganisationen.  SCRUM Einer agilen Methode zum operationalisierten Ablauf innerhalb eines Projekts.  Kanban Eine Methode zur Fortschrittsmessung innerhalb eines z. B. SCRUM-Projekts. Die Methode Lean StartUp Wie in der Betriebswirtschaftslehre gelernt, benötigt man eine Strategie, die auf lange Sicht den Weg ebnet. Eine Strategie ist ein Output, der durch lange Überlegungen über die richtige Vorgehensweise zustande kommt. Für ein agiles Projekt, welches in vielen Fällen ein neues Produkt dem Markt zur Verfügung stellt, bietet sich durchaus die Methode „Lean StartUp“ an. Lean StartUp ist eine Strategie, wie ein Produkt auf den Markt released wird. Hierbei geht es vor allem darum, ein Produkt nicht über das „Big Bang“-Prinzip, also ein über lange Zeit entwickeltes Produkt, auf den Markt zu bringen, sondern vielmehr darum, seine Produktvision in ein kleinstes anzunehmendes Produkt zu verändern. <?page no="71"?> 72 4 Die agilen Methoden Dieses kleinste anzunehmende Produkt nennt sich in der Lean StartUp-Welt: Minimal Viable Product (MVP). Durch den Release eines MVPs schafft man es, schnell Feedback des Marktes bzw. des Kunden zu erhalten. Dieses hilft, die weiteren Produkt-Features zu priorisieren und auf Basis dessen dann die weiteren Versionen zu erstellen. Die Methode Lean StartUp wurde ursprünglich für Start-ups entwickelt, welche durch diese Vorgehensweise schnell erfolgreich werden können. Sie eignet sich jedoch in vielen weiteren Bereichen, wie zum Beispiel in SCRUM oder PRINCE2 Agile gemanagten Projekten. Die Methode umfasst im Grunde vier umfangreiche Regelwerke. Man kann es auch als „Motto“ für ein Projekt sehen. Diese sind: 1) Erschaffe, messe, lerne Hierbei geht es darum, dass nach der zyklischen Produktentwicklung Zeit investiert werden sollte, um das Erschaffene zu testen, es zu messen und aus den gemessenen Daten zu lernen. Amazon und weitere große Technik-Riesen können das fantastisch. Sie schalten zwei Arten von Funktionalität live. Die eine bewirkt das Eine; die andere Funktionalität das Andere. Das Interessante? User-Kreis A bekommt Funktionalität 1 und User- Kreis B erhält Funktionalität 2, ohne dass das jemals jemand erkennt. Ziel ist es herauszufinden, welche der beiden Funktionalitäten besser beim User ankommen. Dieses Vorgehen nennt sich A/ B-Testing und hat einen sehr hohen Impact auf das weitere Projekt. 2) MVP Wie bereits oben beschrieben, sollte das MVP immer das erste Inkrement eines jeden Projekts sein. Schlank und mit Grundfunktionalität ist ein GoLive deutlich <?page no="72"?> 4.1 Die Methode Lean StartUp 73 schneller zu vollziehen als mit großen umfangreichen Features. Das, was man dann von den Kunden lernt, ist ungemein wichtig für das Folgeprojekt. 3) Fail Fast Die Regel, die wir Deutsche mit Abstand am wenigsten beherrschen: uns einzugestehen, dass wir nicht erfolgreich sind. In vielen Projekten erleben wir das Gleiche. Am Anfang wollen es alle „Agile“ (sie meinen eigentlich „jung“ und „cool“) machen, haben aber das Thema Agilität nur ansatzweise verstanden. Das Ergebnis ist, dass auf einmal alle in kurzen Hosen zur Arbeit kommen, sich anfangen zu duzen, PostIts an die Wand kleben, jedem möglichst viel Freiraum lassen und denken, dass keine Struktur oder Dokumentation richtig ist. Dann werden, vor allem in Konzernen, viele Millionen „verbraten“, nur um nach der typischen Storming-Phase eines Teams festzustellen, dass Agilität doch nicht nur „cool“ sein bedeutet. Als nächstes werden weitere Millionen in die Hand genommen, um das Projekt einzuschränken, Reportings und Dokumentationen einzuführen, die Stunden in der Erstellung brauchen und am Ende niemand wirklich liest, nur um dem Lenkungssauschuss oder dem Vorstand das Gefühl zu geben, sie würden wieder die Kontrolle über das Projekt erlangen. Monate später und nachdem alle Bemühungen des mittleren Managements auf einmal nicht mehr ausreichen, um zu verbergen, dass das Projekt plötzlich doch zwei Jahre länger dauert als ursprünglich geplant und das Produkt sowieso nur ein Zehntel des eigentlich angestrebten Mehrwertes bietet, hat das Projekt inzwischen einen Punkt erreicht, den alle fürchten: Den Point of no Return. Der Point of no Return ist ein Zeitpunkt im Laufe eines Projekts, bei dem bereits extrem viel Geld investiert wurde und bereits ein halbfertiges Produkt im Raum steht, weshalb ein Abbruch praktisch nicht mehr möglich erscheint. Was wäre hier die Lösung gewesen? Vieles von Lean StartUp hätte hier geholfen. Jedoch hätte die Denkweise Fail Fast dazu geführt, dass ein Projekt sehr schlank <?page no="73"?> 74 4 Die agilen Methoden gestartet wäre und durch das Ausprobieren von „Trial and Error“ sehr schnell erkannt hätte, ob und wenn ja, was der richtige Weg gewesen wäre. Fail Fast bedeutet: Scheitere. Scheitere auch oft. Aber scheitere schnell! Denn nichts ist schmerzhafter als die Erkenntnis, viel Geld in die Entwicklung von Produkten gesteckt zu haben, die am Ende nicht „fliegen“ werden. 4) Verbessere das Lernen Durch ständige Retrospektiven und den Kaizen-Ansatz wird das Lernen zu einem elementaren Bestandteil eines Projekts. Kaizen ist ein japanisches Sprichwort und bedeutet so viel wie „immer nach dem nächsthöheren Ast greifen“. Das sollte stets Motto im Projekt sein. Durch verschiedene Arten von Wissenstransfers kann man ferner sicherstellen, dass auch das Lernen sich stets verbessert. <?page no="74"?> 4.2 SCRUM 75 SCRUM Hierbei handelt es sich um die mit Abstand meistverwendete agile Projektmanagementmethodik der Welt. Kein anderes Framework wird aktuell derart oft in Produktentwicklungen angewendet. Doch woran liegt das? Wieso ist SCRUM so erfolgreich? SCRUM ist extrem einfach gehalten. Alle Regeln umfassen gerade einmal rund 20 Seiten. Kann man sich das vorstellen? Im Vergleich hierzu umfasst die originale Literatur von PMI, einem anderen bekannten klassischen Projektmanagement- Framework, rund zehn große Ordner. Was das in Seiten heißt, können wir nur schätzen. SCRUM trifft einfach den Nerv der Zeit. In Zeiten, in denen Informationen und Komplexitäten unseren Alltag beherrschen, kommt ein schlankes und leicht verständliches Framework gerade recht. Einen Kritikpunkt müssen wir an dieser Stelle jedoch, auch zum Schutz aller anderen Frameworks, gegenüber SCRUM aussprechen: Die kurze und schlanke Art hat natürlich den Nachteil, dass innerhalb von SCRUM alles nur sehr oberflächlich beschrieben ist. Das hat zur Folge, dass maximaler Ausgestaltungsspielraum gegeben ist. Dies ist in den anderen Frameworks durch deutliche und tiefgehende Formulierungen natürlich nicht so. Dennoch beweist die Praxis, dass SCRUM in der Welt des Projektmanagements angekommen ist und so schnell auch nicht mehr wegzudenken ist. Die Rollen innerhalb von SCRUM:  SCRUM Product Owner Der SCRUM Product Owner hat die volle Verantwortung für das Produkt. Er alleine priorisiert, welche Features für ein Produkt umgesetzt werden, welche nach hinten gestellt und welche Features gar nicht umgesetzt werden. Natürlich <?page no="75"?> 76 4 Die agilen Methoden bedarf es hierbei eines großen Vertrauens seitens der Stakeholder und der gesamten Organisation.  SCRUM Master Der SCRUM Master begleitet das Entwicklungsteam auf dem Weg der Erstellung des Produkts. Er unterstützt methodisch in der Anwendung von SCRUM, gilt in vielen Meetings als Moderator und managt während der Entwicklungsarbeit Hindernisse um das Entwicklungsteam herum. Seine Kerndisziplin besteht darin, das Entwicklungsteam vor Dingen, die das Team vor dem Entwickeln abhalten, zu schützen.  SCRUM-Entwicklungsteam Das SCRUM-Entwicklungsteam ist ein 3bis 9-köpfiges Team an Entwicklern, welche in ihrer Gesamtkompetenz dazu befähigt sind, Produkte zu designen, zu entwickeln und zu testen. Der SCRUM-Prozess 1) Stakeholder: Im SCRUM-Prozess kommt der Stakeholder mit 2) Anforderungen auf den 3) Product Owner zu. 4) Durch regelmäßige Refinements werden die Anforderungen konkret beschrieben und dann in das 5) Product Backlog gelegt. Das Product Backlog stellt innerhalb von SCRUM den großen Plan für das gesamte Produkt dar. Innerhalb dessen werden alle Anforderungen von den Stakeholdern an das Produkt niedergeschrieben und seitens des Product Owners beschrieben und priorisiert. <?page no="76"?> 4.2 SCRUM 77 6) Das Sprint Planning dient dann im Rahmen der ersten offiziellen Zeremonie von SCRUM, zum Planen des so genannten Sprints. Der Sprint hat in diesem Schaubild keine eigene Nummerierung, da der Sprint alle dort aufgezeigten Aktivitäten & Zeremonien enthält. Exkurs Sprint: Ein Sprint dauert laut SCRUM zwischen einer und vier Wochen. Je nachdem, wie oft ein Stakeholder ein Reporting haben möchte und Teams sich in Zeremonien begeben möchten, muss ein Zeitraum zwischen diesen Zyklen gewählt werden. Je länger ein Sprint dauert, desto länger dauern auch die Zeremonien. Oft wird der Begriff Sprint auch einer Iteration gleichgesetzt. Dies ist aber nicht immer dasselbe. Gerade in PRINCE2 Agile kann eine Iteration mehrere Sprints beinhalten. 7) Die Ergebnisse des Sprint Plannings werden im Sprint Backlog niedergeschrieben. Hierbei ist nicht unbedingt eine Priorisierung notwendig, solange sich das Team auf das für den Sprint ausgelobte Ziel committet. Im Grunde genommen stehen innerhalb des Sprint Backlogs alle für den Sprint zu erfüllenden Stories drin, die sich das Team nach und nach zur Entwicklung heranzieht. 8) Entwicklungsarbeit und 9) Entwicklungsteam Das Entwicklungsteams setzt innerhalb der Entwicklungsarbeit die Stories aus dem Sprint Backlog Schritt für Schritt um. 10) Daily SCRUM Bei Bedarf trifft sich das Entwicklungsteam jeden Tag mit dem SCRUM Master, um über den aktuellen Sprint-Fortschritt zu sprechen und eventuelle Hindernisse zu identifizieren. Oft wird das Daily SCRUM auch als Daily StandUp beschrieben. Es geht maximal 15 Minuten und sollte persönlich abgehalten werden. Hier haben auch die Stakeholder die Möglichkeit, sich über den aktuellen Entwicklungsstand zu informieren. <?page no="77"?> 78 4 Die agilen Methoden 11) Sprint Review Am Ende jeden Sprints werden die Arbeitsergebnisse dann dem Stakeholder vorgestellt. Im Laufe von PRINCE2 wird es noch mehrere Reviews geben, an denen unterschiedliche Arten von Stakeholdern teilnehmen. 12) Increment Das Increment ist das am Ende entstandene (Teil-)Produkt/ Output des Teams, welches im Sprint Review vorgestellt wird und auf dessen Basis die Stakeholder dem Product Owner Feedback in Form von Anforderungen für den nächsten Sprint geben können. 13) Sprint Retrospektive Eine Zeremonie, bei dem am Ende jedes Sprints über die guten und schlechten Dinge der Zusammenarbeit gesprochen wird. Ziel ist es hier, Verbesserungspotenzial zu erkennen und dieses im nächsten Sprint umzusetzen. <?page no="78"?> 4.2 SCRUM 79 <?page no="79"?> 80 4 Die agilen Methoden Die Methode Kanban Kanban, im Jahre 1947 entwickelt, galt lange Zeit als eine Prozessoptimierungsmaßnahme, bis die Software-Entwicklung die Visualisierungsmethode Kanban für sich erkannte. 1947 erkannte Toyota, dass eine schlanke Planungs- und Ablauforganisation einen großen Einfluss auf den Ausschuss (Waste) innerhalb einer Produktionseinheit hat. Je schlanker und strukturierter diese ablaufen würde, desto höher könne die Auslastung der einzelnen Produktionsstationen sein. Generell gibt es über Kanban eigene Trainings und einige Bücher. Je nachdem, in welchem Branchen- und Anwendungsbereich Kanban Anwendung findet, unterscheidet sich die Ausprägung dieser Methodik jedoch ungemein. Im Projektmanagement gilt: Kanban ist eine Technik, die dazu beiträgt, Arbeiten und To-dos zu strukturieren. Durch einfache Regeln schafft Kanban es, die Arbeit und dadurch den Fortschritt des Projekts bzw. der Produkterstellung zu visualisieren. Kanban ist vor allem durch das gleichnamige Kanban-Board bekannt. Es bietet eine Möglichkeit, anfallende Arbeit zu strukturieren, zu verteilen und zu visualisieren. Das Kanban-Board hat es längst geschafft, außerhalb von Projekten in klassischen Linienorganisationen Anwendung zu finden. Tatsächlich gilt, dass Kanban in allen Arten von Projekten, egal ob agil oder klassisch, Anwendung findet. Innerhalb von PRINCE2 Agile gilt die Methode Kanban als eine Art Visualisierungsmethode, um den Projektfortschritt zu tracken, Transparenz zu schaffen und Reporting zu vereinfachen. Kanban gibt in der Terminologie drei Kanban-Regeln vor: <?page no="80"?> 4.3 Die Methode Kanban 81 Visualisierung Visualisiere Deine To-dos, um die Arbeit transparent zu machen. Transparenz schafft Vertrauen, das im Team zu einem echten Erfolgsfaktor wird. Außerdem vereinfacht die Visualisierung eine Menge: To-dos sind einfacher zu verstehen, es ist einfacher, den Überblick zu behalten, und es ist einfacher, Abhängigkeiten innerhalb mehrerer Tasks zu identifizierten. Limitierte Arbeit Die Arbeit zu limitieren hat einen extremen Vorteil: Das Team und der Entwickler bleiben maximal fixiert. Es gibt Zeiten, in denen gefühlt jede Deadline auf dem gleichen Tag liegt. Viele unterschiedliche Projekte auf einmal bringen dann nicht ansatzweise das gleiche Ergebnis wie eine fokussierte Abarbeitung nacheinander. Alleine der Gedanke bzw. die Ansicht vieler To-dos hat hierbei schon einen großen Effekt. Das ist der Grund, wieso viele Zeitmanagement-Workshops einem als Tipp mitgeben, bei einer Aufgabe, die eine Menge Konzentration benötigt, auch Handy und E-Mail-Programme auszustellen. In Kanban gilt ganz einfach das Prinzip: aus den Augen, aus den Sinn. Je weniger Aufgaben auf dem Kanban-Board zu sehen sind, desto höher ist die Fokussierung des Teams auf die bestehenden To-dos. Pullprinzip Eine weitere Anwendung innerhalb der Methode Kanban ist das Prinzip, sich die Arbeit als Entwickler/ Teammitglied selbstständig auszusuchen und abzuarbeiten. In vielen Projekten ist es die Aufgabe der Projekt- oder Teammanager, die Arbeit an die einzelnen Teammitglieder zu verteilen. Das bewirkt, dass die Teammitglieder natürlich oft nicht die Arbeit machen, die sie lieben. Das hat zur Folge, dass es schwerer ist, hier eine Motivation herzustellen. <?page no="81"?> 82 4 Die agilen Methoden „Ach so? Nur weil sich die Teammitglieder die Arbeit nun selber aussuchen dürfen, heißt das automatisch, dass sie die Arbeit lieben? “ - Nein, hier hast Du natürlich absolut Recht. Es bedeutet jedoch, dass die Chance hierfür deutlich höher ist. Außerdem ist die Chance, dass das Teammitglied die Arbeit als „besser“ ansieht und ein höheres Committment dazu hat, um ein Vielfaches höher. <?page no="82"?> 4.4 Übungsfragen zu Kapitel 3 & 4 83 Übungsfragen zu Kapitel 3 & 4 Hinweis: Es kann maximal eine Antwort richtig sein. Die Auflösung findest Du in Kapitel 9. [1] Wie lässt sich Lean StartUp am besten beschreiben?  Ein Ansatz zur Verbesserung des Systems, mit dem gesteuert wird, wie viele Arbeiten gleichzeitig durchgeführt werden.  Ein Ansatz, der eine verbesserte Zusammenarbeit zwischen Entwicklung und Betrieb IT-Services schafft.  Ein Ansatz zur Anwendung agiler Verfahren für große und komplexe Arbeiten über eine gesamte Organisation hinweg.  Ein Ansatz zur schnellen Bereitstellung neuer Produkte, ursprünglich basierend auf der Gründung neuer Unternehmen. [2] Welche Arten von Veränderung sollten durch PRINCE2 Agile gemanagt werden?  Priorisierung von Ideen zur Verbesserung bzw. zu kontinuierlichen Verbesserungen eines Produkts.  Entwicklung eines neuen Service, der noch nicht verstanden bzw. noch nicht vollständig definiert ist.  Beantwortung einfacher Änderungsanfragen von Vertriebsmitarbeitern.  Bearbeitung einer langen Liste von kleinen Upgrades, welche regelmäßig ergänzt wird. [3] Was beschreibt einen agilen Ansatz, der in PRINCE2 Agile integriert werden kann? <?page no="83"?> 84 4 Die agilen Methoden  Begrenzung der Menge der laufenden Arbeiten und Nutzung von Visualisierung, um Fortschritte anzuzeigen.  Besteht aus einer Sequenz von Phasen wie Design, Build und Test.  Priorisierung und Einreichung häufiger Anfragen zur Verbesserung bestehender operativer Produkte.  Darstellung der beabsichtigten längerfristigen Funktionalität des Produkts in einem Diagramm zur Visualisierung für das Projektteam. [4] Welche Projektdimension ist fix innerhalb eines PRINCE2 Agile Projekts?  Zeit & Qualität  Zeit & Kosten  Qualität & Kosten  Risiko & Nutzen [5] Welche Methode wird NICHT in PRINCE2 Agile aufgezeigt?  Lean StartUp  SCRUM  Kanban  NLP [6] Lean StartUp ist ein Framework, das zu Anfangszeiten zur … verwendet wurde.  Unternehmensgründung  Unternehmensliquidierung  Unternehmensfusion  Unternehmensübernahme  Unternehmensgründung  Unternehmensliquidierung  Unternehmensfusion  Unternehmensübernahme <?page no="84"?> 4.4 Übungsfragen zu Kapitel 3 & 4 85 [7] Kanban beschreibt u. a. einen Ansatz zur  Risikoplanung  Kommunikationsplanung  Kommunikationsdurchführung  Aufgabenplanung [8] SCRUM beschreibt eine Methode zur  Entwicklung neuer Produkte  IT-Prozessoptimierung  Risikosteuerung von Unternehmen  Software-Release-Planung [9] Welcher Bestandteil gehört nicht zu SCRUM?  Rollen  Events/ Zeremonien  Artefakte  Dokumentationen [10] Innerhalb von SCRUM gibt es Iterationen. Wie heißen diese?  Runs  Races  Sprints  Services <?page no="86"?> 5 PRINCE2 Agile - Tiefgang Die Grundprinzipien in PRINCE2 Agile Gehen wir nun in die Detailebene innerhalb von PRINCE2 Agile. Vielleicht hast Du mal ein PRINCE2-Training bei uns besucht oder unser erstes PRINCE2-Buch „PRINCE2 - Die Erfolgsmethode einfach erklärt“ gelesen. Dann wirst Du Dich vielleicht daran erinnern, dass wir davon sprachen, die PRINCE2-Grundprinzipien immer gleich zu lassen. Alles innerhalb von PRINCE2 ist anpassbar bis auf die sieben Grundprinzipien. Und so ist es in der Weiterentwicklung PRINCE2 Agile auch heute noch. Die sieben Grundprinzipien von PRINCE2 bleiben immer bestehen. Vielmehr verändert sich deren Interpretation. 1) Fortlaufende geschäftliche Rechtfertigung - besseres Tracking Um herauszufinden, ob ein Projekt (weiterhin) gerechtfertigt ist, bietet der Business Case eine von vielen Möglichkeiten, diesem Grundprinzip nachzukommen. Durch die iterative Arbeitsweise kann man diesem Grundprinzip am Ende jeder Iteration gerecht werden. Im Vergleich zur klassischen Ausprägung dieses Grundprinzips ist es schwierig, einen genauen „Forecast“ zu treffen. Durch die kurzen und regelmäßigen Feedback-Zyklen ist es jedoch einfach, den Erfolg der jeweiligen Iterationen bzw. Inkremente zu messen. 2) Lernen aus Erfahrung - besser durch Retrospektiven Dieses Grundprinzip wird durch agile Grundzüge ebenfalls noch anwendbarer und plastischer. Durch kurze und regelmäßige Entwicklungszyklen, die Einbindung von Kunden, die Überprüfung und die daraus entstehenden Anpassungen aufgrund des Feedbacks durch zum Beispiel Retrospektiven kommt man auch in einem agilen <?page no="87"?> 88 5 PRINCE2 Agile - Tiefgang PRINCE2-Projekt diesem Grundprinzip erfolgreich nach. Hier eignet sich der Kaizen- Ansatz besonders gut. 3) Definierte Rollen und Verantwortlichkeiten weichen die agilen Methoden auf Die Adaptierbarkeit von neuen Rollen aus verschiedenen Frameworks werden zu den in PRINCE2 benannten Rollen erweitert: zum Beispiel wird ein SCRUM Master hinzugefügt. Hier muss von Aussagen in SCRUM wie beispielsweise: „Es gibt keinen Projektmanager“ abgesehen werden. Merke: PRINCE2 first. 4) Steuern über Managementphasen - Iterationen auch im Agilen vorhanden Das Prinzip, ein Projekt in Phasen zu unterteilen, ist von Natur aus schon zur Agilität kompatibel. In der Welt von PRINCE2A kann eine Phase mehrere Releases enthalten und ein Release mehrere Iterationen bzw. Sprints. Eine Phase ist nicht mit einem Sprint gleichzusetzen. 5) Steuern nach dem Ausnahmeprinzip - hilft zur Selbstorganisation Das Ausnahmeprinzip unterstützt Selbstorganisation, indem es das Team durch Kompetenzen ermächtigt. Der einzige Unterschied zur komplett agilen Selbstorganisation sind die Toleranzen, bis wohin das Team selbst entscheiden darf. Bei einer Überschreitung der Toleranzen muss die nächsthöhere Hierarchiestufe aktiviert werden. 6) Produktorientierung - wird zur Marktorientierung PRINCE2 legt den Fokus auf die Produkte. In der agilen Ausführung jedoch sind wir auf den Wert, den das Produkt am Markt generiert, fokussiert. Die Schnittmenge von beiden Ansätzen ist, sich mehr auf die Produktentwicklung als auf die Aktivitäten, die dafür notwendig sind, zu konzentrieren. <?page no="88"?> 5.1 Die Grundprinzipien in PRINCE2 Agile 89 7) Anpassung an die Projektumgebung - wird nach Agilitätsgrad bestimmt PRINCE2 Agile ist nur eine von vielen Ausprägungen, wie PRINCE2 an die Projektumgebung angepasst werden kann. Wie das PRINCE2 bzw. PRINCE2 Agile Framework weiter angepasst werden kann, beschreibt unter anderem das Agilometer, welches im Laufe des Trainings weiter beschrieben wird. Video anschauen: Die Grundprinzipien von PRINCE2 Agile Autor Fabian erklärt, wie die Grundprinzipien von PRINCE2 in PRINCE2 Agile angepasst bzw. erweitert werden. www.agile-heroes.de/ buch/ prince2agile <?page no="89"?> 90 5 PRINCE2 Agile - Tiefgang Thema Business Case Du erinnerst Dich? Eines der sieben Themen ist das Thema Business Case, welches neben dem eigentlichen Thema auch ein Managementprodukt von PRINCE2 darstellt. Sicher fragst Du Dich, wie das Thema Business Case sich innerhalb der agilen Ausprägung von PRINCE2 verändert. Der Business Case stellt in dem agilen PRINCE2-Kontext das Managementprodukt zur so genannten Total Cost of Ownership dar. Die „TCO“ beschreibt, wie sich ein Produkt neben den eigentlichen Projektkosten vor allem auch bei der Markteinführung und bei dem Marktbetrieb verhält. <?page no="90"?> 5.3 Thema Organisation 91 Wir unterscheiden bei dem vorstehend aufgeführten Schaubild zwischen der Sicht der klassischen Ausprägung 1) und der agilen Ausprägung 2). Klassische Ausprägung Hierbei geht es darum, dass der Business Case 3) den erwarteten Nutzen des Projekts darstellt. Dieser sollte im Laufe des Projekts immer mehr validiert und maximiert 4) werden und bei tatsächlicher Erreichung in den Nutzenmanagementplan (ehemals Nutzenrevisionsplan) 5) eingetragen werden. Agile Ausprägung In der agilen Ansicht des Themas Business Case geht es vor allem darum, innerhalb des Business Case 6) den Wert des Produkts einzutragen. Der agile Gedanke hierbei ist, dass ein wertvolles Produkt langfristig mehr Nutzen generieren wird, weil es kundenfokussierter ist. Diese Wertmaximierung 7) wird dann in den Nutzenrevisionsplan 8) eingetragen, wenn ein tatsächlicher Wert generiert wurde. Thema Organisation In der agilen Anpassung des Themas Organisation wird eine Sache großgeschrieben: SELBSTORGSANITION. Wie aus den agilen Frameworks bekannt, ist die Selbstorganisation eines der wichtigsten Güter. Damit dieses innerhalb von großen PRINCE2-Projektorganisationen Anwendung findet, bedarf es dem ausgeprägten Grundprinzip “Steuern nach dem Ausnahmeprinzip“. Damit Teams selbstorganisiert arbeiten können, müssen sie Kompetenzen besitzen, innerhalb eines gewissen Bereichs selbst entscheiden zu dürfen. Dies funktioniert nur durch genügend Toleranzen innerhalb der Projektdimensionen Zeit, Kosten, Qualität, Risiko, Umfang und Nutzen. <?page no="91"?> 92 5 PRINCE2 Agile - Tiefgang Damit dies funktioniert, müssen die Stakeholder auch damit leben können, nicht jedes Detail zu fixen und selbst entscheiden zu wollen. Im folgenden Schaubild sind mehrere Möglichkeiten aufgezeigt, wie eine typische PRINCE2-Projektstruktur mit den typischen Rollen eines SCRUM-Teams angereichert werden kann. Hierbei ist zu beachten, dass es sich a) um ein Beispiel handelt und neben SCRUM auch jede weitere Methode hier Anklang finden kann; b) die dort aufgeführten Rollen keine offiziellen PRINCE2-Rollen sind, und c) von gewissen SCRUM-Regeln wie „Es gibt keinen Projektmanager“ abgesehen werden muss. Auch hier findet wieder der Leitsatz „PRINCE2 first“ Anwendung. Option 1 Teammanager = Product Owner. Ja, es widerspricht der Regel von SCRUM, dass es innerhalb von SCRUM keine Hierarchien gibt. Es kommt unserer Meinung jedoch nahe an die typische Art von Arbeit eines Product Owners heran. Hierbei geht es primär um die Zusammenarbeit mit den Stakeholdern bzw. hier in unserem Projektbeispiel um die Zusammenarbeit mit dem Projektmanager. Option 2 Der Teammanager fällt weg und der Projektmanager arbeitet mit dem PO oder den POs zusammen. Das würde vor allem dann passieren, wenn es wenige POs wären, die der PM managen müsste. Option 3 Die Rolle des Teammanagers wird ganzheitlich ersetzt und durch die Rolle des Head POs ersetzt. Ein Head PO an sich macht dann am meisten Sinn, wenn innerhalb der PRINCE2 Agile Struktur noch andere Skalierungs-Frameworks wie SAFe (Scalled Agile Framework), LeSS (Large Scaled SCRUM) oder Nexus Anwendung finden. Auch wenn der Name des Head-Product Owners durchaus auch eine andere Bezeichnung findet, wie in der Welt von SAFe - RTE (Release Train Engineer). <?page no="92"?> 5.3 Thema Organisation 93 <?page no="93"?> 94 5 PRINCE2 Agile - Tiefgang Thema Qualität Nachdem wir in Abschnitt 3.2 gelernt haben, welche Projektdimensionen innerhalb von PRINCE2 Agile fix und welche flex sind, könntest Du Dich sicher fragen, wieso, wenn Qualität doch flexibel ist, es eine derart hohe Aufmerksamkeit innerhalb von PRINCE2 Agile erlangt, dass es sogar ein eigenes Kapitel erhält. Nun, zum einen ist Qualität ein eigenes Thema innerhalb der PRINCE2-Terminologie, weshalb allein dieser Fakt ausreicht, um diesem Thema auch innerhalb dieses Buches ein eigenes Kapital zu widmen. Zum anderen kann man sagen, dass Qualität nicht weniger als das Anforderungsmanagement des Projekts darstellt. Und da, wie Du sicher auch aus vielen Projekten weißt, vielen Projekten das Anforderungsmanagement derart schwerfällt, war für uns die Validität dieses Themas einfach uneingeschränkt gegeben. Das Thema Qualität beschreibt, wie mit den Eigenschaftserwartungen (Anforderungsmanagement) des Kunden an das Produkt umgegangen wird. Hierfür sind bereits einige Mechanismen seitens PRINCE2 eingerichtet worden. In vielen agilen Frameworks gibt es weitere Techniken und Methoden, die zu einem besseren Verständnis der Kunden- und Marktqualitätserwartungen beitragen. Auch helfen sie dabei, Produkte schneller marktfähig zu machen und die Verbindlichkeit innerhalb des Teams zu verbessern. Auf der Seite des Schaubilds sind die von PRINCE2 vorgegebenen Techniken zu sehen, welche mit den auf der rechten Seite stehenden Techniken einfach ergänzt oder bei Bedarf ausgetauscht werden können. Auch haben die hier aufgezeigten Techniken keinen Anspruch auf Vollständigkeit. Vielmehr ist es als selbstverständlich anzusehen, dass diese je nach Projektumgebung stark verändert und angepasst werden können. <?page no="94"?> 5.4 Thema Qualität 95 1) Qualitätsmanagementstrategie Eine in dem Prozess IP entwickelte Strategie zur Festlegung des Qualitätsniveaus innerhalb des Projekts. Beispiel: In unserem Projekt benutzen wir ausschließlich MacBooks, um die Technik-Anfälligkeit innerhalb der Produkterstellung zu minimieren. Laut PRINCE2 sollte für ein Projekt nur eine QMS gelten. <?page no="95"?> 96 5 PRINCE2 Agile - Tiefgang 2) Definition of Done Auf der anderen Seite hätten wir die Definition of Done, die aus dem SCRUM- Framework übernommen wurde. Sie beschreibt, welche umfassenden Dinge innerhalb eines Projekts durchgeführt werden müssen, bevor ein Task auf „Done“ gesetzt wird. Dies könnte zum Beispiel sein: Testabdeckung 75% oder Vier-Augen-Prinzip bei der Qualitätssicherung. Oft findet man in verschiedenen Arten von Teams auch verschiedene DoDs vor. Das liegt daran, dass es je nach Teamausrichtung auch verschiedene Arten von Teilprodukt zu erstellen gilt. Bleiben wir bei dem DoD-Punkt „75% Testabdeckung“. Wäre das für die Designer eines Produkts relevant? Wohl kaum. Wie sollte ein Designer sein Design testen? Es ist ja lediglich ein „Bild“ und nicht eine laufende Software. Ist diese „75% Testabdeckung“ für die Front-End- Entwickler (das sind die Software-Entwickler, die u. a. das Design des Designers mit Technik zum „Leben“ bringen. Also das Design auf das Produkt, sagen wir einfach mal die Website, schalten) relevant? Sehr wohl. Die Front-End-Entwickler haben dann die „Ehre“, das Design und die Technik zu verproben und zu testen. Wie solche Tests durchgeführt werden, darüber könnten wir Stunden philosophieren, ja sogar mehrere Bücher darüber schreiben. Testen ist alleine schon ein Bereich, mit dem sich eigene Branchen beschäftigen. Wir möchten Dich bitten, als zukünftiger PRINCE2 Agile Projektmanager an der Stelle uns zu vertrauen: für den Moment reicht das Wissen völlig aus. Auf den ersten Blick wirken die QMS und die DoD sehr ähnlich, praktisch betrachtet kann man jedoch sagen, dass die QMS eher auf der Ebene des Projektmanagers zutrifft und die DoD eher auf der Ebene der Teams verstanden wird. Die DoD ist daher eine Ergänzung zur QMS. 3) Qualitätsmethoden Welche Methoden zum Anforderungsmanagement werden innerhalb des Projekts verwendet? Dieser Frage sieht sich jeder PRINCE2-Projektmanager ausgesetzt und <?page no="96"?> 5.4 Thema Qualität 97 oft gibt es hierfür auch Kritik am PRINCE2-Framework. Hier kommen Kritikpunkte wie „Diese Aussage ist viel zu generisch, als dass sie im operationalisierten Projektgeschäft einem Projektmanager schnell weiterhilft“, und als ob es die intellektuellen Rechteinhaber von PRINCE2 in der neuen PRINCE2-Agile-Version gehört haben, gehen sie hier in Punkt 4) auf die Schmerzpunkte der Praxis ein. 4) User Stories/ Epics und MoSCoW Diese drei genannten Techniken werden in der Welt der Agilität nur zu oft angewendet. Gehen wir die drei Arten von Techniken innerhalb des Projektmanagements nacheinander durch. User Stories Dies ist eine Technik, um - vereinfacht gesagt - das Verlangen des letztlichen Nutzers an dem zu erschaffenden Produkt darzustellen. Eine User Story, oder in der Praxis oft nur als „Story“ bezeichnet, wird in ihrer einfachsten Form wie folgt dargestellt. Ich als >User< möchte >Anforderung an das Produkt< um >Nutzen< Beispiel: Ich als Nutzer von Spotify möchte einen Song in die Warteschleife setzen, um beim Autofahren mein Handy nicht mehr in die Hand nehmen zu müssen. Wichtig hierbei ist, dass diese Anforderung so einfach und klar wie möglich formuliert wird und keine Hinweise zu einer technischen Umsetzung bieten soll. Diese Art von Lösung bleibt ganz alleine dem Entwicklungsteam vorbehalten. „Wie bitte? Ich soll dem Entwickler eine derartig umfassende Anforderung übermitteln, ohne auch nur einen Funkten von Akzeptanzkriterien und Beschreibung mit beizufügen? “ - hören wir Dich schon denken. Die klare Antwort lautet: Nein. Die umfassenden Akzeptanzkriterien sollen innerhalb des Anhangs der User-Story stehen. Diese sind hierbei aber rein fachlich zu sehen, im Sinne von „Die Warteschlange sollte dann <?page no="97"?> 98 5 PRINCE2 Agile - Tiefgang direkt im Anschluss des nächsten Songs abgespielt werden.“ Technische Anforderungen, also auf welcher Code-Basis das passieren soll, bleiben hier vollkommen außen vor. Diese Lösungsfindung obliegt alleine dem Entwicklungsteam. Werden hier zu starre Lösungen bereits an das Entwicklungsteam gestellt, stört das die Kreativität des Entwicklungsteams, was zu einer Demotivation führen kann. Epics Haben wir eben eine User Story kennengelernt, wissen wir, dass die Art von Anforderung einen eher kleinen Impact auf das bestehende Produkt - in dem Fall Spotify - hat. Was aber, wenn wir aufgrund eines Major-Update von IOS oder Android einer komplett neuen Mayor-Version entgegenstehen? Hierbei wäre es sehr unpraktikabel, jede Art von Anforderung über schlanke User Stories in das Projekt zu bringen. Die Lösung für diese Problematik lautet: Epic. Ein Epic ist die Zusammenfassung oder die Klammer um mehrere User-Stories zu einem größeren Thema oder einer größeren Story. Beispiel-Epic könnte sein: Spotify v17 auf IOS 12 lauffähig machen. Und hierunter fallen dann viele weitere User Stories, die notwendig sind. MoSCoW Hat man dann ein großes Epic erschaffen, unter dem eine Vielzahl an umzusetzenden User Stories zu finden sind, steht man der nächsten Anforderungen innerhalb des Anforderungsmanagements gegenüber: Welche von den unzähligen wichtigen User Stories sollten nun zuerst umgesetzt werden? Dies sollte durch eine Priorisierungstechnik, wie es MoSCoW ist, entschieden werden. MoSCoW, das ist nichts weiter als die Unterscheidung zwischen Must Have, Should Have, Could Have & Won´t Have, welche in dieser Reihenfolge die danach priorisierten Stories in eine Umsetzungsreihenfolge bringt. Hier können selbstverständlich auch jegliche Art von anderen Anforderungspriorisierungstechniken angewandt werden. <?page no="98"?> 5.5 Thema Pläne 99 5) Qualitätsregister Das Qualitätsregister beinhaltet die gesamten bekannten Anforderungen des Projekts. 6) Product Backlog und Sprint Backlog Diese Anpassungen, aus SCRUM kommend, stellen eine Verfeinerung des Qualitätsregisters dar. Grundlegend kann man sagen, dass das Qualitätsregister für das gesamte Projekt gilt. Das Product Backlog könnte das Qualitätsregister entweder ersetzen, nämlich dann, wenn es sich um ein einziges, von einem Team zu liefernden, Produkt handelt. Es könnte aber auch zusätzlich zum Qualitätsregister existieren, nämlich dann, wenn es von vielen verschiedenen Teams geliefert wird. Zusätzlich, egal ob das Product Backlog zusätzlich zum Qualitätsregister existiert oder es ergänzt, gibt es ein oder mehrere Sprint Backlogs, welche die Inhalte für den jeweiligen Sprint beinhalten. 7) Produktbeschreibung des Projektendprodukts PEP Die PEP beschreibt das am Ende zu liefernde Endprodukt des Projekts, sozusagen die Produktvision. 8) MVP Das MVP ist uns ja bereits bekannt. Hier können wir zwischen PEP und MVP sehr gut definieren. Denn das MVP sollte die erste Version des späteren Projektendprodukts sein. Thema Pläne Im Thema Pläne werden bekannte Pläne aus dem klassischen PRINCE2-Framework angepasst sowie um weitere Arten von Plänen erweitert. Die Grundstruktur der Hierarchien der verschiedenen Pläne bleibt bestehen. <?page no="99"?> 100 5 PRINCE2 Agile - Tiefgang 1) Wird ein Projekt innerhalb einer Programmstruktur durchgeführt, liegt oberhalb des Projektplans ein Programmplan vor, welcher die großstrukturelle „Roadmap“ des Programms und somit sämtlicher Projekte vorgibt. Definition Programm: Eine dynamische Organisationsstruktur, die zur Koordination und Durchführung mehrerer Projekte geschaffen wurde und meist über mehrere Jahre hinweg besteht. 2) Auf höchster im Projekt befindlicher Ebene bleibt der Projektplan bestehen. Dieser ist selbsterklärend, oberflächlich und granular formuliert. Ein Projekt würde nicht agil gemanagt werden, wüsste man bereits am Tag 1 genau, was das Endergebnis sein sollte. Daher gleicht der Projektplan eher einer Roadmap zur Produktvision: Scharf genug, um eine ungefähre Richtung einschlagen zu können und „High Level“ genug, um die Interpretation und Kreativität des Entwicklungsteams nicht zu gefährden. 3) Die nächsttiefere Planebene stellt die Phasenplan-Ebene dar. Dieser Plan beschäftigt sich vor allem mit der Planung der anstehenden Releases, die in dieser Phase abgeschlossen werden sollen. Gerade wenn viele Teams an einem großen Release arbeiten, wäre dieser Plan die Planungsebene zur Koordination der Releases. 4) und 5) Der Initiierungsphasenplan und der Ausnahmeplan sind wie in der klassischem PRINCE2-Welt optional zu betrachten. Der Initiierungsphasenplan ist der obligatorische Plan, der in dem Prozess Starting Up a Project (SU) für die Initiierungsphasenplan erstellt wird. Der Ausnahmeplan wird im Falle einer (drohenden) Toleranzüberschreitung an den Lenkungsausschuss erstellt und muss reportet werden. 6) Der Releaseplan stellt eine neue Planungsebene innerhalb von PRINCE2 dar. Vorher als Teamplan beschrieben, beschreibt der Releaseplan die Verteilung der Auf- <?page no="100"?> 5.5 Thema Pläne 101 gaben und Tasks an die verschiedenen Teams. Er beschreibt das Vorgehen der Teams innerhalb eines Releases. 7) Der Iterationsplan kann auch als Product Backlog beschrieben werden. Mit diesem Plan arbeiten die Teammitglieder, die mit der Umsetzung der Produkte beschäftigt sind. Er gilt für die kleinste anzunehmende Zeititeration: dem Sprint. Nachdem wir uns nun verschiedene Pläne angeschaut haben, stellt sich sicher die Frage, wie diese Pläne erstellt werden. Hierzu gibt es eine Vielzahl an Prämissen, die beachtet werden sollten.  Anforderung- und Feature-basierte Planung Dies kommt der Produktbasierten Planungstechnik von PRINCE2 sehr nahe. Es bedeutet, dass ein Plan Produktbzw. Feature-basiert und nicht Aktivitätenfokussiert erstellt wird.  Einbindung des Teams in die Erstellung der jeweiligen Planungsebenen Hierdurch wird die Selbstorganisation und das Commitment des Teams extrem gestärkt. Der Grund dafür ist, dass sich das Team bei einem selbst erstellten Plan deutlich mehr identifiziert.  Just-in-time-Planung Wir erinnern uns daran, dass wir innerhalb der agilen Projektwelt Deadlines maximal ausnutzen. Das bedeutet auch, dass wir mit keinen Zeitpuffern arbeiten, sondern vielmehr eine Just-in-time-Planung vollziehen.  Kurzzeitige Planungshorizonte Da wir aber auch wissen, dass wir in einer schnellen Projektwelt leben, machen lange, konkrete Planungszeiträume keinen Sinn. Die Annahme hier ist, dass sich ein Projekt und dessen Anforderungen derart schnell verändern, dass eine lange Planung „Waste“ wäre. <?page no="101"?> 102 5 PRINCE2 Agile - Tiefgang  Aufwandsstatt zeitgetriebene Planung (Mann-Tage) Die Lösung lautet Story Points-Planung, eine Planung der Komplexität, nicht der Zeit. <?page no="102"?> 5.5 Thema Pläne 103 Exkurs: Story Points Eines der Themen, das innerhalb des agilen Arbeitens für Projektmanager nach den klassischen Frameworks extrem neu und ungewohnt erscheint. Man geht weg vom klassischen Gedanken eines Personentages (PT), also der Schätzung nach Zeit hin zu einer Schätzung nach Komplexität. Studien beweisen, dass wir Menschen viel besser darin sind, im Vergleich zu schätzen als aus freier Hand zu schätzen. Gerne können wir das Ganze mal anhand eines kleinen Experiments beweisen. Aufgabe 1 Nimm Dir ein Stück Papier und einen Stift und schätze nun die Einwohnerzahlen folgenden Städte: Köln, Hannover, Berlin, Mannheim und Erfurt. Fertig? Ok, super. Das Ergebnis kommt gleich. Aufgabe 2 Bringe im nächsten Schritt bitte die Städte Hamburg, Heidelberg, London, Karlsruhe in Relation zueinander in eine Reihenfolge, beginnend mit der größten Stadt. Parameter auch hier: Einwohnerzahl. Referenzstadt: Frankfurt am Main mit 750.000 Einwohnern. Was ist Dir hierbei aufgefallen? War es nicht so, dass die Aufgabe 2 viel einfacher war? Das lag daran, dass Du nicht pro Stadt eine konkrete Angabe machen musstest, sondern Du die Städte aneinander verglichen hast. Dies fällt uns Menschen deutlich leichter, und je länger und öfter Du das machst, desto besser und genauer fällt diese Schätzung dann aus. Hier die Auflösung: Aufgabe 1: Köln: 1,1 Mio Hannover: 0,55 Mio <?page no="103"?> 104 5 PRINCE2 Agile - Tiefgang Berlin: 3,6 Mio Mannheim: 0,35 Mio Erfurt: 0,25 Mio Aufgabe 2: London Hamburg Frankfurt (Referenzstadt) Karlsruhe Heidelberg Innerhalb der Schätzung nach Story Points ist der Maßstab nicht mehr PT (Personentage), sondern Story Points. Die Story-Point-Skala orientiert sich an der Fibonacci- Reihenfolge. Wichtig: Sie orientiert sich daran, folgt aber nicht 1: 1 der Abfolge. Die Skala beinhaltet: 0 / 0,5 / 1 / 2 / 3 / 5 / 8 / 13 / 20 / 40 / 100. Zu sehen ist, dass die Skala nicht linear, sondern exponentiell verläuft. Wie kommt das? Die Annahme hinter dieser Art von Skala ist, dass mit zunehmender Komplexität Unsicherheiten und Unklarheiten hinsichtlich der Entwicklung massiv Einzug halten. Beispiel: Man könnte dem Bau eines Papierflugzeugs die Anzahl 1 an Story Points geben, da man davon ausgehen kann, dass die Komplexität nicht allzu hoch ist. Jeder hat auch schon mal einen Papierflieger gebaut. Geht man nun davon aus, statt eines Papierfliegers einen Flieger aus Holz bauen zu müssen, könnte man nun im Verhältnis schätzen: „Ist der Holzflieger komplexer, und wenn ja, wie viel mehr komplex ist der Bau von einem Holzflieger im Vergleich zum Papierflieger? “ Diese Schätzung ist dann ungleich genauer als die freie Schätzung nach der Komplexität eines Holzfliegers, ohne sich im Team auf den Papierflieger als Referenz-Task geeinigt zu haben. Würde jetzt das Team bei der Schätzung herausfinden, dass ein Holzflieger in den gewünschten Eigenschaften rund 50-mal komplexer ist (also 50 Story Points) als der <?page no="104"?> 5.5 Thema Pläne 105 Bau eines Papierfliegers, wäre hier die Story-Point-Karte 100 zu ziehen, da man mit einer relativ hohen Wahrscheinlichkeit davon ausgehen kann, dass Unsicherheiten und Unklarheiten die Komplexität erhöhen. Über einen längeren Projektzeitraum würde die Schätzung mit Story Points immer genauer werden. Doch warum macht man sich den Umstand, eine neue Art von Maßstab zu lernen, wenn wir alle doch seit unserer Kindheit den Maßstab Zeit perfekt verinnerlicht haben? Der Grund ist, dass die Zeit ein gleichbleibender Faktor ist, also die Anzahl an PT immer gleich bleibt, sofern das Team gleich bleibt. Die Anzahl an abzuarbeitenden Story Points hingegen steigt mit zunehmender Dauer der Zusammenarbeit des Teams. Je länger ein Team zusammenarbeitet, desto besser werden die Mitglieder darin, komplexere Aufgaben zu erledigen. Bleiben wir beim Holzflieger-Beispiel: Der Holzflieger hat weiterhin die Komplexität von 100, da die Komplexität nicht geringer wird. Das Team wird einfach nur schneller darin, die 100 Story Points abzuarbeiten. Diese Geschwindigkeit wird in Projekten als „Velocity“ beschrieben und gilt als einer der wichtigsten Parameter für die Performance eines Entwicklungsteams im Verlauf eines Projekts. Planning Poker Als eine Art der Technik, wie Teams Schätzungen vornehmen, hat sich Planning Poker in der Praxis als eine der relevantesten herausgestellt. Hierbei werden jedem Teammitglied die genannten Story-Point-Zahlen auf je einer Karte gegeben. Dann wird eine zu schätzende User Story präsentiert. Die Entwickler haben die Möglichkeit, darüber zu sprechen und sich abzustimmen. Im nächsten Schritt müssen alle Entwickler/ Teammitglieder gleichzeitig eine der ihnen vorliegenden Story-Point-Karten hochhalten. Stimmen alle Karten überein, kann diese Story mit dieser Anzahl an Story Points eingeplant werden. Stimmen die <?page no="105"?> 106 5 PRINCE2 Agile - Tiefgang Zahlen nicht überein, müssen diejenigen Entwickler mit der höchsten und mit der niedrigsten Anzahl Story Points eine fundierte Stellungnahme dazu abgeben. Danach haben die Entwickler wieder die Möglichkeit, zu diskutieren. In der Regel ist dann der zweite oder dritte Schätzversuch derart nahe aneinander, dass es zu einer Übereinstimmung kommt. Vorteil dieser Schätzmethode ist, dass nahezu alle relevanten Probleme und Risiken diskutiert werden können und so auch eher „ruhige“ Entwickler zu Wort kommen. Thema Risiko In klassischen Projekten besteht das Risiko, dass mitten in einem Projekt umfangreiche Änderungen das gesamte Projekt gefährden. In agilen Projekten stellt dies jedoch kein Risiko, sondern den normalen und anzunehmenden Fall dar. Dies ist der Grund, weshalb keine umfangreiche und weit in die Zukunft reichende Planung aufgestellt wird. Im Grunde kann man sagen, dass durch eine agile Vorgehensweise bereits Risikogegenmaßnahmen getroffen werden. Eine weitere Art, Risikomanagement zu betreiben, ist die Durchführung von Daily Standups. Daily Standups helfen durch regelmäßige Austausche, Risiken auf der Lieferebene schnell zu erkennen und frühzeitig zu bearbeiten. In klassischen Projektorganisationen kann dies ebenso durch Meetings geschehen. Jedoch ist ein so regelmäßiges Meeting in den seltensten Fällen, vor allem mit dem gesamten Team, bekannt. <?page no="106"?> 5.6 Thema Risiko 107 © AXELOS In PRINCE2 Agile wird das Agilometer beschrieben, um herauszufinden und zu bewerten, wie agil das Projekt einzustufen ist. Je niedriger die Punktzahl pro Bereich ausfällt, desto eher ist dieser Bereich mit einem höheren Risiko behaftet. <?page no="107"?> 108 5 PRINCE2 Agile - Tiefgang Das Agilometer wird im Lauf des Buchs noch behandelt. Zu erwähnen ist, dass das Agilometer neben der Identifikation des „Agilitätsgrades“ auch ein starkes Instrument zur Identifikation der Risikobelastung eines agilen Projekts darstellt. Operationalisiert würde ein durch das Agilometer identifiziertes Risiko innerhalb eines PRINCE2-Projekts weiterhin im PRINCE2 bekannten Risikoregister seitens des Projektmanagers gesteuert werden. Tiefgehender würden die Teams Risikogegenmaßnahmen innerhalb des Sprint Backlogs erfassen und abarbeiten. Thema Änderungen Das Thema Änderungen ist mit Abstand einer der Hauptgründe, weshalb Projektteams auf die agilen Entwicklungsprozesse zugreifen. Änderungen sind zu jeder Zeit gern gesehen. Die Annahme einer agilen Entwicklungsorganisation ist, dass ein Änderungswunsch, insbesondere wenn er von dem Kunden ausgesprochen wird, wertstiftend für das vom Projekt zu liefernden Produkt ist. Eine Änderung wird erst dann schwierig oder bedenklich, wenn ihr zu wenig oder zu späte Aufmerksamkeit geschenkt wird. Innerhalb des Themas „Änderungen“ unterscheiden wir zwischen zwei Arten von Änderungen, die die Produkte betreffen: Baseline Change und no Baseline Change.  1) Baseline Changes betreffen festgeschriebene Anforderungen, die eine feste, nicht diskutable Spezifikation aufweisen. Fällt hier eine Änderung an, muss diese durch 3) formales Management über den 4) Änderungsausschuss behandelt werden. Hier ist natürlich immer der nötige managementtaugliche Abstand 5) High Level zu wahren. Dann werden von den Teams tiefgehende Diskussionen geführt werden müssen. <?page no="108"?> 5.7 Thema Änderungen 109  2) No Baseline Changes sind kleine und 6) informell zu behandelnde Änderungen, die zwar auch die Spezifikation betreffen, jedoch in dem selbstorganisationslebenden Team entschieden werden. Das 7) Team trägt hierbei die Verantwortung. Zu beachten ist hierbei, dass die Teams Änderungen jedoch auch nur innerhalb ihres Toleranzbereiches selbst entscheiden dürfen. Ist eine Änderung 8) größer als die Toleranz, muss ein Ausnahmebericht angefertigt werden. Im Vergleich zum klassischem PRINCE2 fällt darüber hinaus auf, dass im agilen Bereich das Konfigurationsmanagement extrem kurz beschrieben ausfällt. Konfigurationsmanagement sollte nur auf der oberen Planungsebene vorhanden sein. Das liegt daran, dass es aufgrund der kurzen, aber guten Planung wenig Umfang in einem eventuellen Konfigurationsmanagementsystem gibt. <?page no="109"?> 110 5 PRINCE2 Agile - Tiefgang Thema Fortschritt Die primäre Art, Fortschritt zu überwachen, ist das funktionierende Produkt! In der Fachliteratur wird hier kontinuierlich die „funktionierende Software“ beschrieben. Das liegt daran, dass die agilen Frameworks ausnahmslos aus dem Software-Entwicklungsbereich stammen. In PRINCE2 Agile kann dies durch Output oder releasefähiges Produkt beschrieben werden. Fortschrittmessungen wie „Mann-Tage“ oder „Zeilen von Code“ sind in PRINCE2 Agile keine originäre Messmethode. Der Fokus sollte, wie schon das Grundprinzip „Produktorientierung“ verlauten lässt, auf das funktionierende bzw. realeasefähige Produkt gerichtet sein. Innerhalb von PRINCE2 Agile unterscheiden wir zwischen den Reportings auf Projektebene und den Reportings auf Lieferebene. 1) Projektebene  2) Ereignisgesteuert: Ereignisgesteuerte Reportings sind in der Welt von PRINCE2 Agile dieselben wie die in der Welt von PRINCE2. Diese sind zum Beispiel der Ausnahmebericht oder der Offene Punkt-Bericht, die beide ein Ereignis als Enabler benötigen.  3) Zeitgesteuert: Zeitgesteuerte Reportings sind zum Beispiel der Phasenabschlussbericht und der Projektabschlussbericht. Es handelt sich hierbei um Berichte, die einen zeitlichen Enabler haben.  4) Klare Vorgaben: Grundlegend gelten für diese Arten von Reportings klare Strukturen, vor allem deshalb, weil sie vor allem für hohe Hierarchieebenen innerhalb eines Projekts bestimmt sind. <?page no="110"?> 5.8 Thema Fortschritt 111 5) Lieferebene  6) Information Radiator: Eine Visualisierung der noch zu tätigenden Aufgaben bzw. der noch offenen Stories. In der Praxis wird dies oft durch Tools vollzogen. Das meistgenutzte Tool ist Jira: Es ist außergewöhnlich praktikabel und intuitiv. Auch hierzu haben wir einen günstigen Online-Kurs, der Dir alle Inhalte von Jira schnell und einfach erklärt. Mehr dazu findest du unter: https: / / www.agileheroes.de/ trainings/ jira.  7) Velocity: Wie bereits im Kapitel „Pläne“ beschrieben, ist die Velocity die gemessene Teamgeschwindigkeit, meist ausgedrückt in Story Points. Dies kann mit einem Burn Down Chart verdeutlicht werden. Hier sieht man neben der Velocity auch die offene und die bereits abgeschlossene Arbeit, angereichert mit einer zeitlichen Komponente. Also: Entspricht die abgeschlossene Arbeit der zeitlichen Vorgabe hinsichtlich Abarbeitungsstand?  8) Alles, was den Wert erhöht: Generell gilt vor allem in agilen Projekten der Merksatz: Alles, was zum Erfolg des Produkts und damit zur Wertstiftung für den Kunden beiträgt, ist sinnvoll und willkommen. <?page no="111"?> 112 5 PRINCE2 Agile - Tiefgang <?page no="112"?> 5.9 Vorbereiten eines Projekts (SU) und Initiieren eines Projekts (IP) 113 Vorbereiten eines Projekts (SU) und Initiieren eines Projekts (IP) Auch in diesem Kapitel werden vorhandene PRINCE2-Bereiche, in diesem Fall die Prozesse, mit weiteren agilen Methoden angepasst. Bei den hier modifizierten Prozessen wurde zwar zur umfangreichen Anpassung die agile Methode SCRUM verwendet, jedoch musste SCRUM selbst ebenfalls an die Projektumgebung angepasst werden. Grund dafür ist, dass SCRUM an sich durch die sehr generische Art der Formulierung oft Spielraum in der Interpretation lässt, der in der Praxis sehr unterschiedlich ausgelebt wird. Ein weiterer Kritikpunkt am SCRUM-Framework ist, dass dort nur die Operationalisierung des täglichen Projektgeschäfts beschrieben ist. Liest man den SCRUM Guide, wirkt es so, als wäre SCRUM für Projekte da, die einfach „da“ sind, ohne jemals eine Vorbereitung oder Initiierung durchlaufen zu haben. Mittels der PRINCE2-Prozesse SU & IP erscheint SCRUM deutlich vollkommener und anwendbarer. Umgekehrt kann man ebenso sagen, dass SU & IP durch die Anwendung von z.B. SCRUM deutlich anwendbarer und nahbarer, man könnte sagen „intuitiver“, wirken. Vorbereiten eines Projekts Der Prozess SU beschäftigt sich insbesondere mit der Fragestellung, was für ein Projektszenario vorliegt. Außerdem ist das Ziel, herauszufinden, wie agil dieses Projekt gemanagt werden könnte. Hierzu wird die erste agile Technik „Sprint Zero“ verwendet. Dies soll helfen, ein Projekt auf die agile Anwendung vorzubereiten. Demnach könnte man den gesamten Prozess SU auch „Sprint Zero“ nennen. Zu Beginn finden vor allem die Techniken „Agilometer und Cynefin“ Anwendung, welche im Folgenden beschrieben werden. Ergänzt wird der Prozess ferner durch die Erstellung einer Produktvision und einem MVP - dem Minimal Viable Product. <?page no="113"?> 114 5 PRINCE2 Agile - Tiefgang 1) Sprint Zero Der Sprint Zero ist innerhalb der agilen Welt bekannt als Sprint zur Planung des Projekts. Hier soll herausgefunden werden, wie viel Agilität ein Projekt braucht. Angereichert mit den Aktivitäten aus dem Prozess SU ergibt dies eine vollkommene Projektvorbereitung. Dieser Sprint Zero findet zwar innerhalb von SCRUM keine Anwendung, ist jedoch im PRINCE2 Agile an die Bedürfnisse der Initiierung eines Projekts angepasst worden. 2) Agilometer Eine Technik, die z. B. innerhalb des Sprint Zeros angewendet wird, um herauszufinden, wie viel Agilität die Organisation „verträgt“. Mehr hierzu in Kapitel 6.1. 3) Cynefin verwenden Das Cynefin-Framework hilft neben dem Agilometer dabei, herauszufinden, ob das Projekt eher klassisches Projektmanagement benötigt oder ob es sich, rein von der Produkterstellung her, für eine agile Vorgehensweise eignet. Zum Verständnis: Agilometer überprüft die Organisation auf das Potenzial zur Agilität, Cynefin überprüft das zu erstellende Produkt. 4) Produktvision und MVP definieren Die Produktvision und das MVP haben wir bereits näher betrachtet. Prozessual macht es an dieser Stelle Sinn, dies zu definieren. Selbstverständlich gilt es die Produktvision während des gesamten Projekts zu überprüfen und ggf. anzupassen. 5) Auf alte Retros zurückgreifen Gerade in großen Unternehmen, die entweder mehrere SCRUM-Projekte oder Großprojekte mit mehreren SCRUM Mastern durchführen, ist oft ein eingespielter Kreis an SCRUM Mastern vorhanden. Dies hilft bei Neuprojekten sehr oft dabei, durch das <?page no="114"?> 5.9 Vorbereiten eines Projekts (SU) und Initiieren eines Projekts (IP) 115 Zur-Verfügung-Stellen alter Retrospektiven-Ergebnisse Fehler zu vermeiden und aus Erfahrungen zu lernen. Initiieren eines Projekts Im Prozess IP geht es, wie auch schon im klassischen PRINCE2-Prozess, um die richtige strategische Aufstellung der im Prozess SU erforschten Projektherausforderung. Hier werden die richtigen Techniken und Frameworks zur Kombination mit PRINCE2 ausgewählt und bestehende PRINCE2-Prozesse und Managementprodukte angepasst. Die größte Anpassung an die Projektumgebung findet also im Prozess „Initiieren eines Projekts (IP)“ statt. 6) Auswahl der Lieferstrategie In welchem Abstand wollen wir unser Produkt bzw. die Updates der Produkte liefern? Jährlich, quartalsweise, monatlich oder vielleicht sogar jederzeit? Die Art der Lieferung muss an dieser Stelle definiert werden. 7) Auswahl der Liefermethode Welche Art von zusätzlicher Methodik benötig das Projekt? Ist es Scurm, Kanban, Lean StartUp oder alles zusammen? Diese Frage muss an dieser Stelle beantwortet werden. 8) PRINCE2 & gewählte Methoden matchen Hat man sich für die Methoden entschieden, geht es nun darum, die gewählten Methoden zu matchen und Kompromisse zu finden. Kompromisse sind innerhalb der Methoden essentiell, da die meisten Methoden (so auch PRINCE2) sehr akribisch darauf ausgelegt sind, ihre eigene zu behaupten. 9) Rollen und Verantwortungen anpassen Mit der Methodenanpassung bedarf es auch der Anpassung der Rollen und Verant- <?page no="115"?> 116 5 PRINCE2 Agile - Tiefgang wortungen. Beispiel: Wird der PRINCE2-Teammanager nun zum Product Owner oder gibt es diese Rolle zusätzlich? 10) PRINCE2-Prozesse anpassen Auch die Prozesse innerhalb von PRINCE2 müssen sich einer neuen Struktur anpassen. So könnte es beispielsweise sein, dass der Prozess „Managen der Produktlieferung (MP)“ gänzlich weggelassen wird und durch den SCRUM-Prozess ersetzt wird. 11) Managementprodukte anpassen Die Anpassung trifft natürlich auch auf die Managementprodukte zu. Hier könnten beispielsweise das SCRUM-Product-Backlog oder das Kanban-Board ein PRINCE2- Qualitätsregister ergänzen oder gar ersetzen. <?page no="116"?> 5.9 Vorbereiten eines Projekts (SU) und Initiieren eines Projekts (IP) 117 <?page no="117"?> Lenken eines Projekts (DP) Die PRINCE2 Agile Terminologie liefert in dem Prozess Lenken eines Projekts auch eine Organisationslösung: Die auf der Lieferebene beschriebenen Teammanager oder 1) Product Owner sollten mit in den Lenkungsausschuss in der Rolle des Lieferantenvertreters aufgeführt werden. Das hat den Vorteil, dass sie auf hoher Ebene strategische Entscheidungen mittreffen können, die essentiellen Einfluss auf den Wert des Produkts oder der Produkte haben werden. Hierfür ist es sehr wichtig, dass der bestehende Lenkungsausschuss einige wichtige 2) Behaviors umsetzt: Verständnis von Product Ownership, Planung auf High-Level- Ebene, Verständnis, dass nicht alles geliefert wird. Kurz gesagt: Der Lenkungsausschuss muss ein Verständnis von der Agilität bzw. vom agilen Arbeiten bekommen. Dies ist in vielen Fällen die Aufgabe von Agile Coaches und SCRUM Mastern. Beide Rollen haben in einer agilen Projektorganisation die Aufgabe, die Stakeholder - und das ist ja in vielen Fällen vor allem der Lenkungsausschuss - in ihrem agilen Mindset zu entwickeln. Exkurs: Differenzierung SCRUM Master und Agile Coach Ein SCRUM Master ist eine Person, die in der Materie SCRUM zertifiziert und qualifiziert ist. Es ist eine Rolle innerhalb eines SCRUM-Projekts. Der Agile Coach hingegen ist in seiner Rolle als Coach nicht nur auf die Methodik SCRUM konzentriert. Vielmehr ist es seine Aufgabe, fast alle agilen Methoden zu beherrschen, diese gegeneinander abzuwägen und an den agilen Mindsets der Projektorganisation zu arbeiten, sie zu 3) trainieren. In der Praxis zeigt sich, dass die Wahl eines Agilen Coachs auch stark mit der Projektgröße zu tun hat. Je größer ein Projekt oder Programm ist, desto eher kann ein Agile Coach finanziell sinnvoll und auch bezahlbar sein. Denn faktisch sind hier na- 118 5 PRINCE2 Agile - Tiefgang <?page no="118"?> 5.11 Steuern einer Phase (CS) und Managen der Produktlieferung (MP) 119 türlich höhere Tagessätze zu zahlen als bei team- und fachbezogenen SCRUM Mastern. Unserer Meinung nach stellt sich der Agile Coach auch als eine Art Karriereentwicklungspfad für SCRUM Master heraus. Steuern einer Phase (CS) und Managen der Produktlieferung (MP) In der Prozesskombination CS & MP kommen die in den Prozessen SU & IP initiierten agilen Techniken und Methoden zur Anwendung. Einige Managementprodukte werden deutlich informeller entwickelt. Ferner bemerkt man, dass das Team durch die Abwicklung von offenen Punkten bereits auf niedriger Ebene dazu beiträgt, die Selbstorganisation zu verbessern. <?page no="119"?> 120 5 PRINCE2 Agile - Tiefgang Der größte Unterschied zur rein klassischen Durchführung der Prozesse Steuern einer Phase (CS) und Managen der Produktlieferung (MP) ist die Iteration und Anpassung bereits während und in der Phase statt im klassischem Prozessmanagen eines Phasenübergangs (SB). Zu erwähnen ist ferner, dass viele verschiedene Teams viele verschiedene agile Liefersysteme wie SCRUM, Kanban, XP etc. anwenden können. Steuern einer Phase 1) Feedback-Runden öfter pro Phase Hierbei gilt es, sich bei Retrospektiven zu bedienen. Dies wäre natürlich aber nur eine von vielen Möglichkeiten, wie Feedbacks und Verbesserung innerhalb eines Projekts auf die Projektorganisation eintreffen können. 2) Größere Änderungen auch während der Phase Innerhalb des klassischen PRINCE2 werden größere Änderungen über den Änderungsausschuss koordiniert und meist versucht zu verhindern. Dies geschieht innerhalb von PRINCE2 Agile nicht. Der Änderungsausschuss bleibt zwar immer noch bestehen, wird jedoch deutlich später eingeschaltet, da mehr Änderungskompetenz innerhalb der Teams liegt. 3) Formeller Projektstatusbericht auf Basis vieler Sprints Der Projektstatusbericht bleibt formell bestehen, wird aber statt auf Basis einer Phase, auf Basis vieler Sprints entwickelt. Managen der Produktlieferung 4) Informellere Teamstatusberichte Hier werden deutlich informellere Berichte gepflegt, als es die Grundterminologie <?page no="120"?> 5.11 Steuern einer Phase (CS) und Managen der Produktlieferung (MP) 121 von PRINCE2 vorgibt. Diese sind nicht dokumentengebunden, sondern vielmehr in Form von Daily StandUps durchzuführen. 5) Verwendung von Daily StandUps Wie bereits bei 4) erwähnt, eignen sich Daily StandUps/ Daily SCRUMs ungemein gut, um alte Berichtstrukturen zu verbessern und zu verschlanken. 6) Review Meetings am Ende jedes Sprints/ Iteration Am Ende jedes Sprints und am Ende jeder Phase/ Iteration sollte ein Review angewandt werden, um das Feedback der Stakeholder, in den meisten Projekten seitens des Lenkungsausschusses, einzuholen und ihnen auf schnelle und unbürokratische Weise den Status der Entwicklung vorzuführen. 7) Beseitigung von offenen Punkten im Daily StandUps Das Daily StandUp eignet sich außerdem hervorragend dazu, informelle offene Punkte schnell im Kreise des Teams zu klären und zu beseitigen. Grundlegend kann man zu dem Prozess Managen der Produktlieferung sagen, dass dieser der geringst beschriebene Prozess innerhalb des PRINCE2-Frameworks ist. Hierdurch eignet er sich hervorragend dazu, Techniken aus sämtlichen agilen Frameworks anzuwenden und das ohne große Zustimmung seitens der Projektleitung. Es obliegt ganz allein der Kompetenz des Teams, auf seiner Ebene Methoden und Techniken frei zu wählen und anzuwenden. <?page no="121"?> 122 5 PRINCE2 Agile - Tiefgang <?page no="122"?> 5.12 Managen eines Phasenübergangs (SB) 123 Managen eines Phasenübergangs (SB) In PRINCE2 gibt es zwei Möglichkeiten, den Prozess Managen eines Phasenübergangs (SB) zu erreichen. Entweder durch den Fall, dass ein Ende einer Phase bevorsteht und die nächste Phase geplant werden muss, oder durch den Fall, dass eine Toleranzüberschreitung einen Ausnahmeplan bezweckt. Im agilen Kontext werden bereits während des Prozesses Steuern einer Phase (CS) und Managen der Produktlieferung (MP) viele kleine Anpassungen durchgeführt, was zur Folge hat, dass in dem Prozess Managen eines Phasenübergangs (SB) nur wenige große Anpassungen durchgeführt werden. Weitere agile Aktivitäten im Prozess Managen eines Phasenübergangs sind neben der Planung der nächsten Phase und der dort zu entwickelnden Features die Super- Retrospektiven und die Super Reviews. In diesen werden die vielen Sprints und Iterationen der letzten Phase auf Verbesserungsbedarf überprüft. 1) Super Reviews Wie es der Name schon vermuten lässt, gilt ein Super Review als ein Review, das die normalen Sprint Reviews von Umfang und Größe um Weites übersteigt. In der SAFe- Welt sind derartige Super Reviews als „Solution Demos“ beschrieben, welche ebenfalls am Ende einer Phase, die mehrere Sprints umfasste, durchgeführt wird. Hier sind im Vergleich zu den „kleinen“ Reviews nicht nur der Projektmanager, sondern auch der Lenkungsausschuss und vielleicht sogar ein Programmmanager eingeladen. Um diesen Ebenen gerecht zu werden, sind hierbei nicht minimale Vorführungen, z.B. Codes-Vorführungen, zu machen, sondern große Stücke einer fertigen Software vorzuführen; typisch managementgerecht. 2) Feature-Planung & Priorisierung für Sprints/ Iterationen der nächsten Phase Hierbei geht es darum, die Änderungswünsche der in dem Super Review aufkom- <?page no="123"?> 124 5 PRINCE2 Agile - Tiefgang menden Feedbacks der Stakeholder aufzunehmen, zu priorisieren und in den nächsten Sprint einzuplanen. 3) Super Sprints Retros Im nächsten Step des Prozesses geht es darum, innerhalb des gesamten Projektteams eine Retrospektive durchzuführen. Ob es Sinn macht, diese mit allen Teilnehmern oder mit einer Delegation zu vollziehen, ist nicht sicher zu beantworten. Dies sollte von Dir in der Praxis erprobt und dementsprechend angepasst werden. Aus unserer Praxis können wir beide Optionen empfehlen. <?page no="124"?> 5.13 Abschließen eines Projekts (CP) 125 Abschließen eines Projekts (CP) Im Prozess Abschließen eines Projekts bleiben die meisten Inhalte dem Prozess CP aus dem klassischem PRINCE2 gleich. Einzig ergeben sich auch im Prozess Abschließen eines Projekts die Super-Retrospektiven und Super Reviews, da es sich auch hierbei um den Abschluss einer Phase, in diesem Fall der letzten Phase, handelt. <?page no="125"?> 126 5 PRINCE2 Agile - Tiefgang Übungsfragen zu Kapitel 5 Hinweis: Es kann maximal eine Antwort richtig sein. Die Auflösung findest Du in Kapitel 9. [1] Die Grundprinzipien werden in PRINCE2 Agile um … ergänzt.  den so genannten agilen Anbau  nichts  9 Themen  das Agile Manifest [2] Im Thema Business Case steht die … im Fokus.  Nutzenmaximierung  Wertmaximierung  Risikominimierung  Outputminimierung [3] Welche Rolle kann ein Teammanager in PRINCE2 Agile noch haben?  Lenkungsausschuss  PMO  Softwareentwickler  Product Owner [4] Was beschreibt die Velocity eines Teams am besten?  Die Geschwindigkeit, meist gemessen in Story Points, mit der das Team komplexe Aufgaben löst.  Die Geschwindigkeit, mit der das Team einen Sprint plant.  Die Geschwindigkeit, mit der ein Risiko identifiziert wird. <?page no="126"?> 5.14 Übungsfragen zu Kapitel 5 127  Die Geschwindigkeit, gemessen in Mann-Tagen, mit der das Team ein Produkt auf den Markt bringt. [5] Innerhalb des Themas Änderung differenzieren wir zwischen Baseline Changes und No Baseline Changes. Welcher Change ist informell seitens der Teams zu lösen?  Baseline Change  No Baseline Change <?page no="128"?> 6 Fokusbereiche Die Fokusbereiche bestehen weder aus PRINCE2noch aus anderen agilen Frameworks, sondern sind rein aus der Sicht von PRINCE2 Agile erdacht. Sie sollen, wie der Name schon sagt, auf die dort aufgezeigten Bereiche fokussieren, da in der Praxis diese oft als „Pain Points“ vieler Projekte erkannt wurden. Fokusbereich: Das Agilometer Das Agilometer ist ein Bereich von PRINCE2 Agile, der auf Basis einiger Parameter die Agilität des Projekts bzw. des Vorhabens messen kann. Ziel des Agilometers ist es, die Schlüsselrisiken innerhalb eines Projekts herauszufinden und die Anpassung an die Projektumgebung zu definieren. Flexibilität darüber, was geliefert wird In der Agilität gibt es keinen fixierten Umfang. Je mehr Flexibilität innerhalb der Lieferung der Produkte gegeben ist, desto mehr Agilität herrscht innerhalb des Projekts. Level der Zusammenarbeit Je höher der Grad an Zusammenarbeit ausfällt, desto mehr Produktivität und Geschwindigkeit ist gegeben. Mit Zusammenarbeit ist hier die Arbeit der Abteilungen innerhalb und außerhalb des Projekts gemeint. Einfachheit der Kommunikation Informelle und stressfreie Kommunikation ermöglichen es, viel Zeit in die Anforderungen und die Arbeit des Produktes zu investieren. Hiermit sind zum Beispiel Daily Standups immer zum selben Zeitpunkt und am selben Ort gemeint. <?page no="129"?> 130 6 Fokusbereiche Fähigkeit, iterativ und inkrementell zu arbeiten Schafft es die Projektorganisation, in Phasen viele kleine Produkte zu erschaffen oder läuft das Projekt eher ohne Zyklen auf ein großes und finales Produkt zu? Je nachdem ist das Projekt eher für die agile oder die klassische Arbeitsweise ausgelegt. Vorteilhafte Umgebungsbedingungen Offene Büroräume, Whiteboards und viele Tools zum ständigen Austausch. Akzeptanz von Agile Innerhalb von agilen Projekten passiert es oft, dass das Management mit der neuen hierarchiefreien Arbeit nicht zurechtkommt. Oder das Management möchte von A bis Z alles durchgeplant haben. Das sind nur wenige von vielen Akzeptanzkriterien von Agilität. Anwendung des Agilometers Man startet mit dem Parameter, der das niedrigste Ergebnis aufweist. Hier sollten Maßnahmen zur Verbesserung geplant werden. Dies passiert durch alle Parameter hindurch, bis alle verbessert wurden. <?page no="130"?> 6.1 Fokusbereich: Das Agilometer 131 © AXELOS <?page no="131"?> 132 6 Fokusbereiche Fokusbereich: Anforderungen Anforderungen sind die Basisbestandteile des Umfangs des Projekts. Anforderungen führen dazu, dass sie in Features umgesetzt werden. Man unterscheidet zwischen technischen und fachlichen Anforderungen. Technische Anforderungen Das sind Anforderungen, die an die Technik eines Produkts gestellt werden. Zum Beispiel an die Programmiersprache, an die Architektur, an die Sercurity- Einstellungen uvm. Fachliche Anforderungen Das sind die Use-Cases einer jeden Software. Dies könnte zum Beispiel sein, dass der User innerhalb der Software eine Suchfunktion haben sollte, um schnell am Ziel seiner Suche anzukommen. In der Praxis wirst Du sicher oft erkennen, dass es eine große Diskrepanz zwischen Product Owner und Entwicklungsteam gibt. Diese rührt aus den sehr unterschiedlichen Sichtweisen beider Parteien her. In der Regel ist der Product Owner ein Entsandter einer Fachabteilung, der die Use-Cases der späteren User perfekt versteht. Oft jedoch fehlt es ihm am technischen Know-how, was in der Regel allein durch das Entwicklungsteam kompensiert wird. Dies ist, auch wenn es erst mal fatal klingt, kein K.-o.-Kriterium, da das Entwicklungsteam bei der Anwendung von Technik genügend Kompetenz besitzt, um dies alleine zu entscheiden. Es ist jedoch unvermeidbar, dass ein Product Owner und die Entwickler im Laufe der Entwicklung und schließlich auch im Laufe der Sprints Planning ihre unterschiedlichen Meinungen in die Priorisierung der Stories einfließen lassen. Demnach ist es dem PO wichtig, dass die Fachlichkeiten eines Produkts umgesetzt werden, um möglichst schnell ein vorzeigbares Produkt zu haben. Wenn hier das Entwicklungs- <?page no="132"?> 6.2 Fokusbereich: Anforderungen 133 team ohne Einwand Folge leistet, kommt es mit der Zeit dazu, dass die Entwickler so genannte „Technische Schulden - Technical Debts“ ansammeln. Exkurs: Technische Schulden Eine Technische Schuld ist, wie im Finanzbereich bekannt ist, eine Sache, die irgendwann zurückgezahlt werden muss. Eine Schuld entsteht dann, wenn Fachlichkeit einer technischen Story vorgezogen und dem Entwickler zu wenig Zeit eingeräumt wird, dieser Schuld nachzukommen. Je mehr Zeit vergeht, desto mehr Technische Schulden werden angehäuft. Beispiel: Der Product Owner wünscht eine neue Darstellung des UI (User Interface) also der Grafik auf der Website. Der Entwickler hat dafür wenig Zeit, wird aber seitens des PO angewiesen, statt sie sauber zu programmieren, eine Quickand-Dirty-Lösung bereitzustellen, was dazu führt, dass der Entwickler nur eine Bilddatei auf die Website lädt, die zwar hübsch wirkt, jedoch über keine Funktionalität verfügt. Diese Bilddatei entspricht natürlich nicht der Definition of Done und muss im Nachhinein durch die richtige Programmierung nachgeholt werden. Jetzt zeigt die Praxis jedoch, dass es diese „Zeit zum Nachholen“ nicht mehr gibt, was dazu führt, dass das Bild dort weiter stehen bleibt. Jetzt sollen aber in diesem Bereich weitere Tasks durchgeführt werden. Diese können aber erst erledigt werden, wenn das Bild durch die richtige Programmierung ersetzt worden ist. Die To-do-Liste bzw. die Liste der Technischen Schulden wächst und wächst. Neben Technischen Schulden, die es natürlich zu vermeiden gilt, jedoch nur schwer zu vermeiden sind, müssen Entwickler auch das so genannte Refactoring durchführen. Dieses ist dafür da, die Software-Code-Qualität zu steigern. Exkurs: Refactoring Vor allem große Softwareprojekte brauchen einen gewissen Zeithorizont, um derartig „vorzeigbar“ zu sein, dass sie dem User getrost zur Verfügung gestellt werden <?page no="133"?> 134 6 Fokusbereiche können. Wir wissen ja alle nur zu gut, in welch schneller Welt, vor allem im technischen Bereich, wir leben. Mit der Zeit kommt es somit zu Updates und neuen technischen Defacto-Standards. Auch lernen die Entwickler sehr viel oder erhalten technische Änderungsvorgaben, die sich auf den bestehenden Code auswirken. All das führt dazu, dass der bestehende Code öfter einem Refactoring unterzogen werden muss - er muss erneuert werden. Dies kostet viel Zeit, Zeit, die der Entwickler nicht in die Umsetzung fachlicher Tasks investieren kann. All das lässt vermuten, in welchem Spannungsfeld die Entwickler und ein Product Owner stehen. Hier obliegt es dem SCRUM Master, als Moderator zu agieren. Im folgenden Schaubild wird der Weg einer Anforderung hin zum Value des Produkts klar beschrieben. 1) Kundenqualitätserwartungen Zu Beginn stellt ein Kunde eine weich formulierte, unklar ausgedrückte Anforderung an das Projekt. 2) Projektabnahmekriterien Diese übersetzt der Projektmanager gemeinsam mit dem Kunden dann in eine quantitativ messbare Anforderung an das Projekt. 3) Produktbeschreibung Diese werden dann in der Produktbeschreibung festgeschrieben. 4) Features Hieraus ergeben sich dann die jeweiligen Features bzw. lassen sich schon die ersten Release-Zyklen ableiten. Diese werden dann dem Product Owner übergeben. 5) Epics Die Features werden dann in große User Stories, genannt Epics, verteilt. <?page no="134"?> 6.2 Fokusbereich: Anforderungen 135 6) User Stories Aus den Epics ergeben sich dann viele kleine User Stories. 7) Priorisierung & 8) Backlog Diese User Stories werden dann seitens des Product Owners im Rahmen seines Backlogs priorisiert und „refined“. 9) Tasks & 10) Sprint Backlog Im nächsten Schritt lässt das Team aus den User Stories Tasks entstehen, die dann innerhalb des Teams verteilt und im Sprint Backlog für den jeweiligen Sprint/ die jeweilige Iteration niedergeschrieben werden. 11) Inkremente Die daraus resultierenden Ergebnisse werden als Inkremente bezeichnet und den jeweiligen Stakeholdern am Ende der jeweiligen Iteration vorgeführt, ehe es in die nächste Iteration geht. 12) Value Das Inkrement, welche dann auch live dem Markt bzw. dem User zur Verfügung gestellt wird, erzeugt dann beim User den Value, den Mehrwert. <?page no="135"?> 136 6 Fokusbereiche <?page no="136"?> 6.3 Fokusbereich: Kommunikation 137 Fokusbereich: Kommunikation Kommunikation ist eine wichtige Angelegenheit, um das Feedback des Markts schnell und unbürokratisch in ein starkes Produkt zu verwandeln. Nur durch umfangreiche Kommunikation ist es möglich, den wenigen Berichten und Dokumentationen agiler Methoden zu entsprechen. Nur weil ein Projekt agil gemanagt wird, ist der Bedarf an Informationsaustausch, der in klassischen Projekten durch viele Berichte und umfangreiche Dokumentation gestillt wird, nicht einfach aus der Welt geschafft. Vielmehr möchten agile Projekte diesem durch eine umfangreiche Kommunikation nachkommen. Dies geschieht auf unterschiedlichste Art und Weise. Auch muss man den Adressaten der Kommunikation unterscheiden. Dementsprechend wird der Inhalt der Kommunikation und der Weg, wie die Information zum Adressaten gelangt, unterschieden. Kommuniziert man mit dem Lenkungsausschuss, sollte der Grad der Detailbeschreibung sehr hoch sein. Hier ist ein Dokument von Vorteil, das dem LA aufzuzeigen ist. Kommuniziert man mit einem Teammitglied, ist ein informelles, bilaterales Treffen bei einer Tasse Kaffee, bei der tiefgehende Details besprochen werden, die richtige Wahl. 1) Inhalt der Kommunikation 2) Dieser sollte stets produktbasiert sein, also ohne jede Art persönlicher Kommunikation. 3) Es ist hierbei wichtig zu beachten, dass es immer der minimale Kreis an Adressaten ist, der vor allem in Meetings miteinbezogen werden muss. <?page no="137"?> 138 6 Fokusbereiche 4) Auch sollten auf Meetings immer die richtige Menge Details besprochen werden. Oft neigen vor allem Peer-Groups dazu, in detaillierte Diskussionen abzutauchen. 5) Art der Kommunikation 6) Um die in 4) beschriebene Problematik der richtigen Menge an Details zu managen, hilft die Technik „Timebox“ mit einer vorgeschriebenen Zeit, die Diskussion ein wenig zu straffen und produktiv voranzutreiben. 7) Ferner hilft es, Kommunikation zwischen Menschen im klassischen Face-to-Face auszutragen, um so Kommunikationsfehler zu verhindern. Jeder kennt das Whats- App-Phänomen, bei dem schriftliche Texte oft zu Fehlinterpretationen führen. 8) In der Praxis hat sich gezeigt, dass vor allem die informelle Art der Kommunikation zu immensen Zeitgewinnen beiträgt. Dies liegt oft daran, dass hierbei keine großen Vorbereitungen getroffen werden müssen. <?page no="138"?> 6.3 Fokusbereich: Kommunikation 139 <?page no="139"?> 140 6 Fokusbereiche Fokusbereich: Häufige Releases Um am Markt bzw. beim Kunden schnell Erfolg zu generieren, muss man die Anforderungen verstehen. Durch die heute existierende Schnelllebigkeit sind Anforderungen von vor einem Jahr nichts mehr wert. Wie also schafft man es als Projekt, ein Produkt auf den Markt zu bekommen, das immer den neuesten Anforderungen genügt? Man schafft es, indem man sich von den jährlichen Major Releases hin zu monatlichen Teil-Releases oder sogar dem so genannten „continuous deployment“, also dem andauernden Releasen, entwickelt. Zum Thema „continuous deployment“ muss gesagt werden, dass dieses sich mehr im Operationsbereich eines Produkts als in der Produktentwicklung anbietet. 1) Hierdurch kann ein monatliches bzw. direktes Feedback des Kunden und des Marktes generiert werden und so der 2) Wert des Produktes Schritt für Schritt deutlich schneller gesteigert werden. Durch diese Veränderung entwickeln sich Produkte oft in eine andere Richtung, als es vorher geplant war. Die Chance ist jedoch ausgesprochen hoch, dass es sich hierbei um die richtige Richtung handelt. Ferner bergen diese kurzen Entwicklungszyklen weniger Risiken und letztlich 3) weniger Verschwendung (Waste) mit sich, da das, was entwickelt wird, auch wirklich gebraucht wird. <?page no="140"?> 6.4 Fokusbereich: Häufige Releases 141 <?page no="141"?> 142 6 Fokusbereiche Fokusbereich: Verträge Oft sind Verträge ein großes Problem, das zu Differenzen zwischen Kunden und Lieferant führen kann. Soll ein fixer oder ein flexibler Kostenvertrag abgeschlossen werden? Ein Grund, wieso agile Projekte öfter in kleinen Projekten von kleinen Unternehmen vertreten sind, ist, dass die Vertragsverhandlungen, vor allem von Großunternehmen, Banken oder öffentlichen Einrichtungen, alles andere als agil ablaufen. Kleinere Unternehmen legen aufgrund ihrer Größe deutlich weniger Wert auf starre Vertragsstrukturen. In klassischen Projekten, in denen der Umfang des Projekts sehr klar ist, können Fixpreis-Verträge auf einfache Weise geschlossen werden. Dass hier eine gewisse Unsicherheit mit einhergeht, ist anzunehmen. Auch beweist die Praxis, dass sich eine Vielzahl von Projekten erheblich verkalkuliert und auf Basis dessen ebenfalls enorme Probleme und Differenzen zwischen Kunde und Lieferant auftauchen. Option 1 Für agile Projekte eignet sich ein 1) Werkvertrag/ Fixpreis-Projekt nur bedingt. Das liegt ganz einfach daran, dass am Anfang eines Projekts kein fixer Umfang vorgegeben ist. Ist ein Kunde jedoch bereit, den Preis zu fixieren, den Umfang aber dynamisch zu halten, so ist einem Fixpreis- Projekt nichts entgegenzusetzen. Hierbei ist natürlich ein hohes Maß an juristischem Wissen gefragt, damit diese 2) Verträge richtig und rechtlich bindend aufgesetzt werden. 3) Generell gilt, dass in derartigen Projekten der Scope dynamisch, die Zeit und das Budget variabel sein sollen. In der Regel ist Option 2 gegeben: <?page no="142"?> 6.5 Fokusbereich: Verträge 143 Option 2 4) Time & Material. Time & Material ähnelt einem Diensleistungsvertrag. Es bedeutet dem Grunde nach, dass, so lange Zeit zur Verfügung gestellt wird, der Kunde einen Anspruch auf die dort entwickelten Ergebnisse hat, im Gegensatz zu einem Werkvertrag, wo ein konkretes Werk geschuldet ist, egal wie lange es dauert. 5) Solange Geld fließt, gibt es Ergebnisse seitens des Projekts. 6) Hierbei handelt es sich um einen Dienstleistungsvertrag, bei dem Entwicklungszeit gekauft wird, mit der offenen Option, wie danach das Produkt aussehen soll. <?page no="143"?> 144 6 Fokusbereiche Übungsfragen zu Kapitel 6 Hinweis: Es kann maximal eine Antwort richtig sein. Die Auflösung findest Du in Kapitel 9. [1] Ein Epic ist ein Zusammenschluss mehrerer …  Capabilities  Pläne  User Stories  Prinzipien [2] Für agile Projekte empfiehlt man grundsätzlich den Abschluss eines …  Werkvertrags  Dienstleistungsvertrags - Time & Material [3] Ein Daily SCRUM/ Daily StandUp soll …  die Transparenz, die Kommunikation und das Vertrauen stärken.  dem Team eine Bühne für private Themen geben.  einen formalen Lenkungsausschuss ersetzen.  ein Wissenstransfer sein. [4] Das Agilometer …  stuft die Projektorganisation in einen Agilitätsreifegrad ein, mit den Risikofaktoren identifiziert werden können.  ist ein Informationstool für den Lenkungsausschuss.  dient der Kommunikation.  dient der Transparenz. <?page no="144"?> 6.6 Übungsfragen zu Kapitel 6 145 [5] Was ist kein Vorteil häufiger Releases?  schnelles Marktfeedback  schnellerer Value  weniger Waste  Aufwand mehrerer „Go Lives“ <?page no="146"?> 7 Prüfung und Zertifizierung Die Regularien, um die Zertifizierung von PRINCE2 zu erlangen, sind im Vergleich zu vielen anderen Zertifizierungen sehr eindeutig und klar geregelt. Seit 2017 haben die offiziellen Rechteinhaber von PRINCE2, AXELOS, entschieden, die Zertifizierung ausschließlich über das Prüfungsinstitut PEOPLECERT zu vergeben. PEOPLECERT ist ein weltweit führendes Zertifizierungsinstitut, das die Kompetenz besitzt, Trainingsinstituten wie den Agile Heroes die Akkreditierung für PRINCE2- Trainings und -Prüfungen zu vergeben. Diese Akkreditierung testiert die Qualität unserer Trainings, Online-Kurse, Materialien und Bücher auf höchstem Niveau. Um an einer Prüfung in PRINCE2 Agile teilnehmen zu dürfen, musst Du ein offizielles PRINCE2 Agile Training bei einem offiziellen Trainingsinstitut absolviert haben.  Offene Zertifizierungstrainings: Solltest Du Interesse an einem Zertifizierungstraining haben, kannst Du Dich jederzeit bei einem unserer offenen Trainings anmelden. Jede Woche haben wir ein Training in einer der Städte Berlin, Hamburg, Köln, Frankfurt a.M. , München und Stuttgart.  Online-Trainings: Möchtest Du ein zeit- und ortsungebundenes Training absolvieren, können wir Dir unseren PRINCE2 Agile Online-Kurs ans Herz legen. Dieser ist jederzeit erreichbar und darüber hinaus auch noch kostengünstig.  Inhouse-Training: Möchtest Du hingegen Dein Team komplett in PRINCE2 Agile trainieren und zertifizieren, erstellen wir Dir gerne ein unverbindliches Inhouse- Angebot. Wir liefern unsere Trainings auch gerne weltweit und in englischer Sprache. <?page no="147"?> 148 7 Prüfung und Zertifizierung Alle Information zu den genannten Trainingsoptionen erhältst Du:  per Web: www.agile-heroes/ trainings/ prince2  per Mail: kontakt@agile-heroes.de  per Telefon: 069 9999 15 911 <?page no="148"?> 8 Glossar Abhängigkeiten Beziehungen zwischen Aktivitäten oder Produkten, die Inhalt eines Plans sind. Man unterscheidet externe und interne Abhängigkeiten. Letztere können vom Projektmanager kontrolliert werden, erstere nicht. Ablehnen (Risikobehandlung) Form der Behandlung einer Chance, bei der aus z. B. wirtschaftlichen Gründen die Chance nicht ergriffen und keine Maßnahme zur Risikobehandlung getroffen werden. Abnahmeberechtigter (Produkt) Die Instanz (z. B. Lenkungsausschuss), die über die Kompetenzen verfügt, ein Produkt als vollständig und für den entsprechenden Zweck geeignet abzunehmen. Agile Methoden Methoden für flexible Softwareentwicklung, die Iterationen mit kurzem Zeitrahmen präferieren, in denen die Produkte schrittweise erstellt werden. Prinzipiell ist PRINCE2 hiermit kompatibel. Aktivität Definierter Bestandteil von Plänen oder Prozessen, der einen konkreten Zeitrahmen aufweist, klare Ergebnisse bringt und gemanagt werden muss. Stellt sich als Funktion, Aufgabe oder (Teil-)Prozess dar. <?page no="149"?> 150 8 Glossar Akzeptieren (Risikobehandlung) Form der Behandlung einer Bedrohung, bei der die Verbindung aus Auswirkung und Eintrittswahrscheinlichkeit des Risikos als zu gering eingestuft wird, um entsprechende Reaktionsmaßnahmen zu rechtfertigen. Die Bedrohung wird jedoch weiterhin beobachtet. Änderungsantrag Ein Offener Punkt, der den Vorschlag zur Änderung einer Baseline enthält. Änderungsausschuss Eine Instanz, die vom Lenkungsausschuss die Verantwortung delegiert bekommen kann, Änderungsanträge oder Spezifikationsabweichungen zu bearbeiten. Die Zuteilung eines sog. Änderungsbudgets ist möglich. Änderungsbudget Die Mittel, die dem Änderungsausschuss zur Ausübung seiner Verpflichtungen zur Verfügung gestellt werden. Änderungssteuerung Verfahren zur Erfassung und Bearbeitung aller Änderungen mit Auswirkung auf die Projektziele. Ankündigung der Projektfreigabe Mitteilung des Lenkungsausschusses an alle Stakeholder und Projektbeteiligten, dass das Projekt offiziell freigegeben wurde und die für das Projekt notwendige logistische Unterstützung (z. B. zur Kommunikation) angefordert wird. <?page no="150"?> 8 Glossar 151 Ankündigung der Projektinitiierung Mitteilung des Lenkungsausschusses an alle Stakeholder und Projektbeteiligten, dass das Projekt als lohnenswert eingestuft wurde und nun der Prozess „Initiierung eines Projekts“ beginnt. Ankündigung des Projektabschlusses Information des Lenkungsausschusses über die Beendigung des Projekts, verbunden mit der Auflösung der Projektressourcen und -kommunikationswege. Weiterhin werden auch formale Hinweise gegeben, z. B. bis wann Kosten gegen die Projektkostenstelle gebucht werden können. Annahme Vorläufige Planungsgrundlage, die aufgrund von Faktenmangel zum Erstellungszeitpunkt getroffen wird. Sie kann später noch verändert werden, wenn detailliertere Informationen vorliegen. Anpassung Jeweilige Verwendung der PRINCE2-Methodik in der vorliegenden Projektsituation. PRINCE2 ist hier als flexibles Framework zu verstehen, welches an die tatsächlich vorliegenden Projektbedingungen angepasst werden muss. Arbeitspaket Umfasst die für die Erstellung eines Produkts notwendigen Informationen wie die Beschreibung der zu erledigenden Arbeiten oder die Produktbeschreibungen. Ein Arbeitspaket wird zwischen Projekt- und Teammanager als Arbeitsgrundlage definiert. <?page no="151"?> 152 8 Glossar Auftraggeber Vorsitzender des Lenkungsausschusses, der für den Erfolg des Projekts, die Verteilung der Vollmachten, die korrekte Beachtung der Projektrisiken als auch für den Business Case verantwortlich ist. Aufzeichnungen Fortlaufende Managementprodukte, die den Projektfortschritt dokumentieren. Auslöser Eine Entscheidung oder ein Ereignis, die ein PRINCE2-Projekt auslösen. Ausnahme Situation, in der eine Abweichung von gegebenen Projekttoleranzen eingetreten ist bzw. antizipiert werden kann. Ausnahmebericht Ein vom Projektmanager erstellter Bericht an den Lenkungsausschuss, der eine Ausnahme inklusive deren Auswirkungen und bestehenden Behandlungsmöglichkeiten untersucht. Eine Empfehlung des Projektmanagers ist ebenfalls enthalten. Ausnahmebewertung Beurteilung des Lenkungsausschusses, ob ein Ausnahmeplan akzeptiert oder abgelehnt werden soll. Auswirkung (eines Risikos) Das (erwartete) Resultat des Eintritts eines Risikos. <?page no="152"?> 8 Glossar 153 Baseline-Managementprodukt Managementprodukt, das einen gewissen Stand des Projekts als Ausgangsbasis definiert und nach Bestätigung dem Änderungsausschuss unterliegt. Befugnis Entscheidungskompetenz, um beispielsweise Ressourcen zu verteilen. Benutzer Person oder Gruppe, die mit dem Projekt-Endprodukt nach Projektabschluss arbeitet und durch einen Repräsentanten (Benutzervertreter) im Lenkungsausschuss vertreten wird. Benutzerabnahme Form der Übergabe des Produkts an die späteren Benutzer. Benutzervertreter siehe „Benutzer“ Berichte Managementprodukte, die den gegenwärtigen Status des Projekts dokumentieren. Betriebs- und Wartungsabnahme Übergabe des Produkts an die späteren Unterstützer in der betrieblichen Verwendung des Produkts. Business Case Geschäftliche Rechtfertigung für ein Projekt. Umfasst Gründe, Optionen, Risiken, <?page no="153"?> 154 8 Glossar Zeit, Kosten, erwarteten Nutzen, erwartete negative Nebeneffekte als auch eine Investitionsrechnung des Projekts. Einschränkungen Restriktionen, die für das Projekt herrschen. Eintrittsnähe (Risiko) Der zeitliche Bezug eines Risikos. Neben Auswirkung, Eintrittswahrscheinlichkeit und Relevanz ein wichtiger Faktor zur Risikobewertung. Eintrittswahrscheinlichkeit Die bewertete Häufigkeit, mit der ein bestehendes Risiko tatsächlich eintreten wird. Empfehlung des Projektabschlusses Information des Projektmanagers an den Lenkungsausschuss. Dieser befindet nun, ob er dem Projektabschluss zustimmt oder nicht. Empfehlungen für Folgeaktionen Empfohlene Maßnahmen für z. B. die Beendigung notwendiger Arbeiten oder die Behandlung Offener Punkte. Eine Übersicht all dieser Empfehlungen findet sich im Phasenabschlussals auch im Projektabschlussbericht. Ereignisgesteuerte Steuerungsmittel Ein Werkzeug, von dem bei Auftreten gewisser Ereignisse (z. B. Phasenende oder auch Ende eines Geschäftsjahres) Gebrauch gemacht wird. Erfahrungsbericht Bericht, der sinnvolle Erfahrungswerte für andere Projekte dokumentiert. Somit sol- <?page no="154"?> 8 Glossar 155 len Fehler vergangener Projekte vermieden und Wissen aus positiven Erfahrungen weiterhin genutzt werden. Erfahrungsprotokoll Eine Zusammenstellung bisheriger nützlicher Erfahrungen. Ergreifen (Risikobehandlung) Form der Behandlung einer Chance, bei der Maßnahmen zur Ergreifung des Risikos getroffen werden, um das gewünschte Ergebnis zu erzielen. Ersteller Die/ der Entwickler eines Produkts. Eventualfall (Risikobehandlung) Form der Behandlung einer Bedrohung, bei der Maßnahmen für den Fall zusammengestellt werden, dass das Risiko tatsächlich eintritt. Epic Zusammenschluss vieler User Stories Freigabe Zeitpunkt der Genehmigung von Plänen bzw. der Erteilung von Befugnissen. Governance (Projekt) Teile der Lenkungsform des Unternehmens, die direkt die Projektaktivitäten berührt. Somit werden die Effizienz der Tätigkeiten und die Abstimmung des Projekts auf die Unternehmensziele gewährleistet. <?page no="155"?> 156 8 Glossar Governance (Unternehmen) Ordnungsrahmen für die Leitung und Führung eines Unternehmens. Sie dient u. a. der Aufrechterhaltung effektiver Managementsysteme, dem Schutz der Wirtschaftsgüter als auch der Wahrung einer positiven Unternehmensreputation. Grundprinzip Grundsätze, die bei der Planung und Durchführung eines PRINCE2-Projekts unbedingt einzuhalten sind. Information Radiator Eine Monitoring-Technik, innerhalb der die Führungskräfte des Projekts den Fortschritt der Teams übermittelt bekommen; z.B. ein digitales Kanban-Board. Initiierungsphase Projektphase zwischen Freigabe der Projektinitiierung und Freigabe des Projekts, welche jeweils vom Lenkungsausschuss erteilt werden. Hier soll ein solides Fundament für das Projekt gelegt werden. Integration (PRINCE2) Schaffen der Bedingungen, die für den Gebrauch von PRINCE2 als Projektmanagement-Framework in einer Organisation existieren müssen. Kanban Eine Methode zur Fortschrittsmessung innerhalb eines z. B. SCRUM-Projekts. Kategorie der Risikobehandlung Hier wird differenziert zwischen Chancen und Bedrohungen: <?page no="156"?> 8 Glossar 157 Für Chancen: Steigern, Ergreifen, Ablehnen oder Teilen. Für Bedrohungen: Vermeiden, Reduzieren, Übertragen, Akzeptieren oder Teilen. Kommunikationsmanagementansatz (ehemals Kommunikationsmanagementstrategie) Definition der projektbezogenen Kommunikation inklusive Austauschmedien und -zyklen. Konfigurationsdatensatz Ein Nachweis über Status, Version und Variante eines Konfigurationselements. Es werden auch Verbindungen zu anderen Elementen dargestellt. Konfigurationselement Eine Einheit, die zum Konfigurationsmanagement gehört. Konfigurationsmanagement Technische und organisatorische Behandlung der Konfiguration eines Projekts während dessen Lebensdauer. Konfigurationsmanagementstrategie Eine Strategie, in welcher Weise und von welchen Personen die Produkte eines Projekts dokumentiert, gesteuert und geschützt werden. Konfigurationsmanagementsystem Die zur Realisierung des Konfigurationsmanagements eingesetzten Tools, Prozesse, Techniken und Datenbanken. <?page no="157"?> 158 8 Glossar Konzession Eine vom Lenkungsausschuss akzeptierte Spezifikationsabweichung. Korrekturmaßnahme Eine beim Überschreiten von Toleranzgrenzen oder dem Feststellen mangelhafter Produkte zu ergreifende Reaktionsmaßnahme. Kostentoleranz Spezifische Toleranz für Kostenabweichungen. Kunde Die Gruppe oder Einzelperson, die Auftraggeber für das Projekt ist und Nutzen aus dem Projekt-Endprodukt zieht. Kundenqualitätserwartungen Die kundenseitige Beschreibung der Beschaffenheit und Qualität des Projekt-Endprodukts. Lean StartUp Eine Methode zum schlanken Aufbau von Organisationen, auch von Projektorganisationen. Lieferant Die Gruppe oder Einzelperson, die für die Bereitstellung der Spezialistenprodukte zuständig ist. <?page no="158"?> 8 Glossar 159 Lieferantenvertreter Repräsentant der Lieferantenseite im Lenkungsausschuss. Liefergegenstand Synonym für „Output“ Managementphase Projektabschnitt, der jeweils vom Projektmanager gesteuert und vom Lenkungsausschuss freigegeben und beendet wird. Managementprodukt Ein Produkt, das für die Projektsteuerungs- und Qualitätsaktivitäten erstellt wird und dem Managen des Projekts dient. Unterscheidung dreier Arten: Baselines, Aufzeichnungen, Berichte. Meilenstein Ein definiertes und wichtiges Zwischenergebnis eines Projekts. Minimal Viable Product (MVP) Ein Begriff aus der Methode „Lean StartUp“. Das MVP gilt innerhalb eines Projekts als die kleinstanzunehmende Produktfertigung, um die Grundfunktionalität des Produkts im Markt zu testen. Man könnte es in der SCRUM-Welt auch als erstes Inkrement bezeichnen, auf dessen Basis dann alle weiteren Features entwickelt und released werden. Negativer Nebeneffekt Effekt, der durch die Ausführung des Projekts mit Sicherheit entsteht und für mindestens einen Stakeholder negativer Natur ist. <?page no="159"?> 160 8 Glossar Nutzen Eine messbare Verbesserung, die durch das Projekt entsteht. Nutzenmanagement Plan (ehemals Nutzenrevisionsplan) Plan, der beinhaltet, wie und wann der Nutzen eines Projekts gemessen werden kann. Nutzentoleranz Spezifische Toleranz für Nutzenabweichungen. Beispiel: die Website muss zwischen 1,5 und 2 Sekunden geladen haben. Offener Punkt Ein vorab nicht geplantes Ereignis, welches gemanagt werden muss. Offener-Punkt-Bericht Bericht, in welchem ein Offener Punkt beschrieben, dessen Auswirkungen geschätzt und eine Handlungsempfehlung abgegeben wird. Output Spezialistenprodukt, das ein Benutzer erhält. Phase Teilabschnitt eines Projekts. Es wird zwischen Management- und technischen Phasen unterschieden. Phasenabschlussbericht Bericht, der den aktuellen Projektstatus enthält und am Ende einer Phase vom Projektmanager an den Lenkungsausschuss übergeben wird. <?page no="160"?> 8 Glossar 161 Phasenabschlussbewertung Auswertung des Phasenabschlussberichts durch den Lenkungsausschuss und den Projektmanager. Entscheidet dann über die Genehmigung des nächsten Phasenplans. Phasenplan Basis für die Abwicklung des Daily Business durch den Projektmanager. Plan Eine definierte Strukturierung eines Vorhabens, wobei die jeweiligen Ziele, der Zeitplan und die involvierten Personen enthalten sind. Planmäßiger Abschluss Ein Projektabschluss, welcher weder verspätet noch verfrüht durchgeführt wird. Planungshorizont Zeitliche Spanne, in der granulare Planung möglich ist. Portfolio Der Zusammenschluss mehrere Projekte und Programme großer Unternehmen. PRINCE2 Framework für effizientes Projektmanagement. Steht für “PRojects IN Controlled Environments“. PRINCE2-Projekt Ein Projekt, das den Grundprinzipien von PRINCE2 folgt. <?page no="161"?> 162 8 Glossar Problem/ Anliegen Offener Punkt, der vom Projektmanager zu bearbeiten ist. Produkt Oberbegriff für einen materiellen oder immateriellen In- oder Output. Man trennt zwischen Spezialisten- und Managementprodukten. Produktabnahme Offizielle und formelle Bestätigung über die Fertigstellung eines Produkts. Damit wird auch die Produktqualität gemäß den vereinbarten Eigenschaften verifiziert. Produktbasierte Planung Methode zur Erstellung eines Plans, bei dem stets eine Orientierung an den zu liefernden Produkten erfolgt. Produktbeschreibung Beinhaltet eine nähere Produkterläuterung inklusive Aufbau, Zweck und Qualitätskriterien des Produkts. Wird während der Planung eines Produkts erstellt. Projekt-Produktbeschreibung (ehemals Produktbeschreibung des Projekt-Endprodukts (PEP)) Definiert die tatsächlich zu erbringende Projektleistung. Damit werden Ausmaß und Anforderungen des Projekts mit dem Auftraggeber abgestimmt, Projektabnahmekriterien und -methoden festgehalten und Qualitätserwartungen dokumentiert. Produktcheckliste Übersicht über bedeutendste Produkte inklusive Deadline der Lieferung. <?page no="162"?> 8 Glossar 163 Produktflussdiagramm Eine Darstellungsweise der Chronologie einzelner Produktionsschritte. Die jeweiligen Produktionsdauern sind dabei darin enthalten. Produktstatusauskunft Ein Bericht über den aktuellen Status eines Produktes. Produktstrukturplan Eine hierarchische Darstellung eines Produktes mit seinen Teilprodukten. Programm Eine dynamische Organisationsstruktur, die zur Koordination und Durchführung mehrerer Projekte geschaffen wurde und meist über mehrere Jahre hinweg besteht. Projekt Eine für einen konkreten, befristeten Zeitraum geschaffene Organisation, die der Erfüllung eines definierten Zwecks und der Lieferung eines bestimmten Produkts dient. Projektabnahme Die offizielle Bestätigung, dass die zu Projektbeginn definierten Projektabnahmekriterien und damit auch die Anforderungen der einzelnen Stakeholder erfüllt wurden. Projektabnahmekriterien Eigenschaften, die Projekt-Endprodukt erfüllen muss, um vom Kunden abgenommen zu werden. <?page no="163"?> 164 8 Glossar Projektabschlussbericht Vom Projektmanager anzufertigender Bericht, der die Übergabe der Produkte dokumentiert, den Business Case ein letztes Mal aktualisiert und bewertet, wie erfolgreich das Projekt war. Projektbeschreibung Wird im Prozess „Vorbereiten eines Projekts“ erstellt und beinhaltet den Zweck des Projekts, die Organisation des Projektmanagementteams, den Business Case-Entwurf, den Projektlösungsansatz und die Beschreibung des Projektendprodukts. Projektbüro / Projektunterstützung (Project Managing Office, PMO) Organisiertes Team oder Einzelperson, welches Projektmanagementunterstützungsarbeit leistet. Projekt-Endprodukt Letztendlich zu lieferndes Ergebnis des Projekts. Projektlebenszyklus Gesamter Zeitraum des Projekts über alle Prozesse und Phasen. Projektleitdokumentation Eine Sammlung aller wesentlichen Dokumente des Projekts. Projektlösungsansatz Ansatz für die Art und Weise, wie ein Projekt aufgesetzt werden soll. Hier ist die so genannte „Make-or-Buy-Entscheidung“ zu treffen. <?page no="164"?> 8 Glossar 165 Projektmanagement Die Planung, Delegierung, Überwachung und Steuerung aller Komponenten und Belange eines Projekts. Projektmanagementteam Umfasst alle Mitglieder der Projektorganisation. Projektmanager (PM) Person mit der Durchführungsverantwortung für das Projekt. Der PM leitet das Tagesgeschäft und bildet die Schnittstelle zwischen Lenkungsausschuss und Teammanagern. Projektmandat Die externe Initiation des Projekts. Hiermit beginnt der Prozess „Vorbereiten des Projekts“. Projektplan Ein Plan, der einen Überblick über den Verlauf und die bedeutendsten Produkte des Projekts gibt, welcher aber bewusst nicht zu detailliert ausfällt. Der Projektplan wird während der Projektlaufzeit als Bestandteil der Projektleitdokumentation immer wieder aktualisiert. Projektsicherung Aufgabe seitens des Lenkungsausschusses, der gewährleisten muss, dass das Projekt planmäßig durchgeführt wird. Dabei obliegt jedem Mitglied des Lenkungsausschusses ein gewisser Teil der Sicherungsverantwortung. <?page no="165"?> 166 8 Glossar Projektstandort Ein Standort, an welchem projektbezogene Arbeit verrichtet wird. Projektstatusbericht Vom Projektmanager zu erstellender Bericht, der der Information des Lenkungsausschusses dient. Er wird regelmäßig in definierten Zyklen erstellt. Projekttagebuch Aufzeichnungen des Projektmanagers, in denen Probleme oder Anliegen formlos festgehalten werden. Projektunterstützung Person/ Gruppe zur administrativen Unterstützung des Projektmanagementteams. Protokolle Sammlung von Informationen seitens des Projektmanagers, die weder mit dem Lenkungsausschuss besprochen noch besondere Formkriterien erfüllen muss. Unterscheidung in zwei Arten: Projekttagebuch und Erfahrungsprotokoll. Prozess Strukturierte Abfolge von Aktivitäten, die einen definierten Input in einen definierten Output verwandelt. Prüfer Person/ Gruppe, die die Erfüllung von Qualitätskriterien eines bestimmten Produkts kontrolliert und dabei unabhängig vom Ersteller des Produkts ist. <?page no="166"?> 8 Glossar 167 Puffer Vorab einkalkulierte Reserven in z. B. finanzieller oder zeitlicher Hinsicht, um Planabweichungen kompensieren zu können. Puffer finden im Rahmen von PRINCE2 keinen direkten Einsatz, sondern werden im Rahmen von Toleranzen abgebildet. Qualität Die Aggregation aller Eigenschaften oder Leistungsmerkmale, die ein Produkt, eine Aktivität, eine erbrachte Leistung oder ein System aufweist. Qualitätsdokumentation Dokumentation über den Nachweis der Durchführung der notwendigen Qualitätssicherungsmaßnahmen. Qualitätsinspektion Eine ausführliche und strukturierte Überprüfung der Qualität eines Produkts, die durch ein Prüfungsteam - bestehend aus mindestens zwei Personen - geplant, gesteuert und dokumentiert wird. Qualitätskriterien Qualitative Ansprüche an ein Produkt, die bei der Qualitätsmessung erfüllt sein müssen. Qualitätsmanagement Die Planung, Steuerung und Kontrolle aller Aktivitäten, die mit Qualitätsdefinition und -messung in Zusammenhang stehen. <?page no="167"?> 168 8 Glossar Qualitätsmanagement-Ansatz (ehemals Qualitätsmanagementstrategie) Verfolgte Strategie, um die vorab definierten Qualitätsanforderungen tatsächlich zu erreichen. Qualitätsmanagementsystem Gesamtheit aller mit dem Qualitätsmanagement in Zusammenhang stehenden Standards, Prozesse, Methoden und Personen. Qualitätsprüfung Siehe „Qualitätsinspektion“ Qualitätsprüfungstechnik Methode zur Ausführung der Qualitätsprüfung mit klarer Rollenverteilung und einem definierten Ablauf. Qualitätsregister Hier werden alle Aktivitäten im Rahmen des Qualitätsmanagements gebündelt. Benutzt wird es hauptsächlich von Projektmanager und seiner Projektunterstützung, um die erzielten Fortschritte zu prüfen. Qualitätssicherung Unabhängige Prüfung eines Produkts auf Erfüllung der Qualitätskriterien. Qualitätssteuerung Die Aktivität der Prüfung bestimmter Projektergebnisse und das Einleiten von Korrekturmaßnahmen bei eventuellen Leistungsmängeln. <?page no="168"?> 8 Glossar 169 Qualitätstoleranz Spezifische Toleranz für Qualitätsabweichungen. Dabei ist für jedes Leistungsmerkmal eines jeden (Teil-)Produkts eine individuelle, zulässige Abweichung zu definieren. Reduzieren (Risikobehandlung) Form der Behandlung einer Bedrohung, um durch vorzeitige Maßnahmen einerseits die Eintrittswahrscheinlichkeit und andererseits die Auswirkungen zu verringern, sollte das Ereignis dennoch eintreten. Register Vom Projektmanager zu führende, formelle Listen. Unterscheidung dreier Arten: Register Offener Punkte, Risikoregister, Qualitätsregister. Register Offener Punkte Sammlung und Bearbeitung aller formell erfassten Offenen Punkte. Obliegt dem Projektmanager. Release Ein Bündel zusammengehöriger Produkte, die eine Einheit bilden und auch als solche getestet, übergeben und implementiert werden. Restrisiko Der Teil eines Risikos, der bestehen bleibt, wenn eine Gegenmaßnahme ergriffen wird. Risiko Ein Ereignis oder Bündel von Ereignissen, die bei einem Eintritt das Projekt positiv <?page no="169"?> 170 8 Glossar (Chance) oder negativ (Bedrohung) beeinflussen. Das Risiko ergibt sich aus dem Produkt von Eintrittswahrscheinlichkeit und Auswirkung. Risikobearbeiter Person, die die Maßnahmen einer Risikobehandlung verantwortet, sollte der Risikoeigentümer die Maßnahmen nicht direkt kontrollieren können. Risikobehandlung Umgang und Verfahrensweise mit einem bestimmten Risiko. Risikobereitschaft Sagt aus, wie risikoavers oder risikoaffin eine Projektorganisation ist. Risikobeurteilung Gesamtheit der einzelnen Risikoeinschätzungen einer konkreten Aktivität. Bedrohungen und Chancen werden einander gegenübergestellt. Risikoeigentümer Eine konkrete Person, die für ein Risiko als verantwortlich bestimmt wurde. Risikoeinschätzung Die Betrachtung von Eintrittswahrscheinlichkeit und Auswirkung eines Risikos unter Verwendung vorgegebener Standards. Risikomanagement Alle Aktivitäten, die mit der Identifizierung und Einschätzung von Risiken als auch der Ergreifung von Gegenmaßnahmen in Zusammenhang stehen. <?page no="170"?> 8 Glossar 171 Risikomanagement-Ansatz (ehemals Risikomanagementstrategie) Verfolgte Strategie, die alle wichtigen Aspekte des Risikomanagements wie z. B. Rollenverteilung und Risikotoleranzen enthält. Risikoprofil Gesamtheit der Risiken, der einer Organisation ausgesetzt ist, als auch die Gefährdung, die dadurch entsteht. Risikoregister Sammlung aller Risiken eines Vorhabens inklusive Beschreibung und gegenwärtigem Stand der einzelnen Risiken. Risikotoleranz Spezifische Grenzwerte der Risikobelastung, die für einzelne Risiken als auch für das Gesamtprojektrisiko definiert werden können. Werden diese überschritten, so muss eine Eskalation an den Lenkungsausschuss erfolgen. Risikotoleranzgrenze Eindeutige Linie im gesamten Risikoprofil. Bei einer Überschreitung wird direkt an den Lenkungsausschuss eskaliert. Rollenbeschreibung Beschreibung von Verantwortlichkeiten und Befugnissen einer konkreten Rolle. SCRUM Eine agile Methode zum operationalisierten Ablauf innerhalb eines Projekts. <?page no="171"?> 172 8 Glossar Spezialistenprodukt Ein fachlicher Output, der auf Grundlage eines Plans hergestellt werden soll. Spezifikationsabweichung Offener Punkt, bei dem eine definierte Anforderung an ein Produkt nicht oder vermutlich nicht erfüllt wird. Sponsor Entspricht in der Regel dem Auftraggeber. Stakeholder Verschiedene Personen oder Gruppen, die unterschiedliche Interessen an das Projekt haben. Steigern (Risikobehandlung) Form der Behandlung einer Chance. Durch den Einsatz von Maßnahmen soll die Eintrittswahrscheinlichkeit und - im Falle des Eintritts - die positive Auswirkung des Risikos erhöht werden. Struktur des Projektmanagements Darstellung von Rollen und Personen in Form eines Organigramms. Technische Schulden Eine Schuld entsteht dann, wenn Fachlichkeit einer technischen Story vorgezogen wird und dem Entwickler zu wenig Zeit eingeräumt wird, dieser Schuld nachzukommen. Je mehr Zeit vergeht, desto mehr Technische Schulden werden angehäuft. <?page no="172"?> 8 Glossar 173 Teammanager Rolle, die für die Leitung eines Arbeitsteams und die Lieferung definierter Arbeitspakete an den Projektmanager verantwortlich ist. Teamplan Ein optionaler Plan zur Steuerung der Ausführung der Arbeitspakete innerhalb eines Teams. Teamstatusbericht Vom Teammanager zu erstellender Bericht an den Projektmanager, der den Fortschritt der Arbeit des Teams dokumentiert. Teamstatuskontrolle Prüfung des Arbeitsfortschritts eines Teams, die in regelmäßigen Zyklen erfolgt. Technische Phase Einzelne Projektabschnitte, die sich an der Erstellung der Produkte oder Verwendung von Methoden orientieren. Teilen (Risikobehandlung) Form der Behandlung einer Chance oder Bedrohung nach dem „Gain-Pain-Sharing- Modell“. Dabei wird festgelegt, dass potenzielle Gewinne oder Verluste, die nicht mit Sicherheit anfallen, im Falle des Auftretens zwischen den beiden beteiligten Parteien aufzuteilen. Thema Ein wichtiges Gebiet im Projektmanagement nach PRINCE2, dessen Kenntnis unabdingbar für eine erfolgreiche Projektdurchführung ist. <?page no="173"?> 174 8 Glossar Toleranz Zulässige Abweichung von projektbezogenen Vorgaben, z. B. in finanzieller oder qualitativer Hinsicht, bei der keine Eskalation an den Lenkungsausschuss erfolgen muss. Übergabe Die Übertragung von einzelnen Produkten oder eines Release an den Benutzer. Übertragen (Risikobehandlung) Form der Behandlung einer Bedrohung, wobei ein Teil des Risikos an eine dritte Partei beispielsweise in Form einer Versicherung ausgelagert wird. Umfang Ist die Aggregation aller Produkte inklusive deren Anforderungen. Umfangtoleranz Spezifische Toleranz für den Umfang eines Plans. Unternehmensbzw. Programmstandards Wichtige Leitsätze, denen das Projekt gerecht werden muss. User Story Technik zur einfachen Erfassung der Anforderung des Verwenders des Projekt- Endprodukts. Ich als >User< möchte >Ziel< um >Nutzen<. Variante Eine Abart eines Produkts, das als Baseline definiert wurde. <?page no="174"?> 8 Glossar 175 Verfahren Eine Abfolge von Maßnahmen zur Erfüllung eines bestimmten Zwecks. Vergleichswerte (Baseline) Referenzwerte zur Überwachung und Kontrolle von Einheiten. Vermeiden (Risikobehandlung) Form der Behandlung einer Bedrohung, bei der Maßnahmen ergriffen werden, um das Eintreten eines Ereignisses auszuschließen oder die Auswirkungen des Ereignisses zu eliminieren. Version Klar gekennzeichnete Baseline eines Produkts. Voraussetzungen (Plan) Notwendige Bedingungen, um einen Plan erfolgreich durchführen zu können. Vorbereitung Die vor Projektinitiierung zu erledigenden Tätigkeiten wie z. B. die Erstellung des Business Case-Entwurfs. Vorzeitiger Abschluss Der frühzeitige Abbruch des Projekts, wobei bisher geschaffene Produkte erhalten und existierende Lücken zwischen Projektzielen und tatsächlich erreichtem Ergebnis dem Unternehmens- oder Programmmanagement mitgeteilt werden. <?page no="175"?> 176 8 Glossar Wasserfallmodell Methode zum Projektmanagement, die einen klaren und linearen Ablaufplan hat. Es gibt aufeinanderfolgende Phasen, bei der eine Phase erst beginnt, nachdem die vorherige abgeschlossen wurde. Zeitgesteuertes Steuerungsmittel Steuerungsmittel, welches in festen zeitlichen Intervallen an die jeweils höhere Hierarchiestufe gegeben wird. Zeitplan Diagrammatische Darstellungsweise eines Plans mit Ablaufabfolge der Aufgabenbearbeitung. Zeittoleranz Spezifische Toleranz für Zeitabweichungen. Zielvorgaben Die Planvorgaben bezüglich der Dimensionen Kosten, Zeit, Umfang, Qualität, Nutzen und Risiko. <?page no="176"?> 9 Lösungen zu den Übungsfragen Lösungen zu Kapitel 1 Die richtigen Antworten sind: Frage 1: c Frage 2: d Frage 3: b Frage 4: b Frage 5: b Frage 6: b Frage 7: d Frage 8: b Frage 9: c Frage 10: b Frage 11: c Frage 12: c Frage 13: d Frage 14: d Frage 15: b <?page no="177"?> 178 9 Lösungen zu den Übungsfragen Lösungen zu Kapitel 2 Die richtigen Antworten sind: Frage 1: a Frage 2: b Frage 3: a Frage 4: c Lösungen zu Kapitel 3 & 4 Die richtigen Antworten sind: Frage 1: d Frage 2: b Frage 3: a Frage 4: b Frage 5: d Frage 6: a Frage 7: d Frage 8: a Frage 9: d Frage 10: c <?page no="178"?> 9 Lösungen zu den Übungsfragen 179 Lösungen zu Kapitel 5 Die richtigen Antworten sind: Frage 1: a Frage 2: b Frage 3: d Frage 4: a Frage 5: b Lösungen zu Kapitel 6 Die richtigen Antworten sind: Frage 1: a Frage 2: b Frage 3: a Frage 4: d Frage 5: d <?page no="179"?> Agilität ist ein Megatrend im Projektmanagement. Warum ist das so? Nahezu alle großen Tech-Unternehmen nutzen die Vorteile der Agilität. Denn zukünftige Marktentwicklungen und komplexe Projekte sind kaum mehr in Gänze vorhersehbar und planbar. Vielmehr ist es wichtig und nützlich kurzfristig entstandene Risiken zu berücksichtigen und neue Chancen wahrzunehmen. PRINCE2 Agile ist als Weiterentwicklung kein eigenes Framework wie es das klassische PRINCE2. Vielmehr ist es eine Toolbox um bei der Projektarbeit herauszufinden, wie klassische und agile Arbeitsweisen zielorientiert kombiniert werden können. Dieses Buch ist demnach eine Weiterentwicklung PRINCE2-Bandes derselben Autoren. Allerdings werden gerade in den ersten Abschnitten die wesentlichen Inhalte des klassischen Prince2 nochmals aufgegriffen. www.uvk.de ISBN 978-3-7398-3008-7