PRINCE2 Agile – Ein erster Blick

In den 1990er Jahren versuchte der Managementguru Tom Peters¹ die Unternehmen agiler zu bekommen, um Verkrustungen und andere negative Begleiterscheinungen durch Bürokratisierung und Tailorisierung zu überwinden². Eines der Stichwörter war Empowering, Mitarbeiter in einem Unternehmen zu befähigen, mehr selbstständig zu erledigen. In den 2000er Jahren setzten sich dann solche Prinzipien auch in der Softwareentwicklung durch und das Agile Manifest entstand als Gegensatz zur Wasserfallentwicklung. Prominenter Vertreter ist neben XP, DSDM oder Kanban meist Scrum. Auf der anderen Seite versuchen sich klassische Projektmanagementmethoden wie die des PMI, der GPM/IPMA  oder PRINCE2 zu agilisieren, also von den Fortschritten in den Softwareentwicklungsmethodiken allgemein zu profitieren. So hat Axelos nun eine Ergänzung zu PRINCE2 herausgebracht: PRINCE2 Agile.

In der Softwareentwicklung machte seit 2001 das Agile Manifesto (Manifesto for Agile Software Development) Furore aus dem sich mehrere agile Varianten entwickelten. In der Softwareentwicklung werden heute häufig agile Methoden eingesetzt.

In den vergangenen Jahren wurde der Druck in der PRINCE2-Community immer größer, auch agile Methoden (auch und gerade für die Lieferebene zu integrieren).

• In 2007 brachte Keith Richards (nein, nicht der von den Rolling Stones) das Werk: Agile Project Management: Running PRINCE2 projects with DSDM Atern heraus. Der Band hat ca. 100 Seiten und basiert noch auf PRINCE2:2005
• DSDM stand auch im Vordergrund bei AgilePM®der APMG mit dem Agile Project Management Handbook, das vom DSDM-Konsortium herausgegeben wird.
• 2012 schrieb Brian Wernham ein hervorragendes Buch: Agile Project Management for Government, in dem er in mehreren Case Studies die Verblendung klassischer PM-Methoden mit agilen (wie Scrum, XP, DSDM usw.) in Regierungsgroßprojekten zeigte.
• Ende 2013 fing auch ich an, aufgrund von Projekterfahrungen über die Ergänzung von PRINCE2 durch agile Methoden Vorträge zu halten.

Wie wird PRINCE2 nun agil? Werfen wir einen Blick auf PRINCE2 Agile und orientieren uns an den Kapitelüberschriften des 350-seitigen Standardwerks.

Part I Introduction and Overviews

1. PRINCE2 Agile introduction

PRINCE2 Agile will mehr Agilität in das Projektmanagement bringen, wie es sich insbesondere in der Softwareentwicklung bewährt hat. Während agile Methoden auch im Business as Usual (BAU) verwendet werden, ist PRINCE2 Agile nur für Projekte. Als ein erstes Element zur Agilisierung wird das Timeboxing eingeführt, das PRINCE2 mit seinen Managementphasen grobgranular schon hat, aber nun feingranularer eingesetzt werden kann.

2. An overview of agile

Historisch am Anfang der formalen Agilität steht das Agile Manifest von 2001, das für viele agile Methodensätze den Ursprung bildet. Hauptunterschied ist, dass Projekte nicht mehr linear und seriell gedacht werden wie bei dem Wasserfallmodell sondern iterativ und inkrementell, eben agil.
Agile Grundprinzipien werden eingeführt: Product Backlog, Sprint Backlog, Sprint, Shippable Product. Hauptziel ist es bei agiler Entwicklung, dem Kunden oder Benutzer möglichst schnell erste Versionen eines Produktes zu zeigen, um Feedback-Schleifen zu seinen Anforderungen zu fahren.

Mit einer Vision wird eine Product roadmap erstellt, die dann in Releases gegliedert wird, um sie in Sprints zu erarbeiten. Der Autor hat eine Vielzahl von agilen Frameworks in PRINCE2 Agile einfließen lassen oder sich inspirieren lassen. Das Produkt ist aber keine Normalisierung all dieser Ansätze, sondern ein pragmatischer Ansatz um PRINCE2 standardisiert zu agilisieren. Die Frameworks (es sind Hyperlinks hinterlegt, die zu Erklärungen führen):

• Scrum
• Kanban
• Lean
• Lean Startup
• XP (eXtreme Programming) (IT only)
• SAFe (Scaled Agile Framework) (IT only)
• DSDM (Dynamic Systems Development)/AgilePM
• DevOps (IT only)
• FDD (feature-driven development) (IT only)
• Crystal (IT only)
• ASD (Adaptive Software Development) (IT only)
• DAD (Disciplined Agile Delivery) (IT only)

Leicht erkennbar ist, dass einige Methoden nur im IT-Umfeld Sinn machen, andere aber auch in anderen Kontexten Anwendung finden (können).

3. The rationale for blending PRINCE2

Während PRINCE2 seinen Hauptfokus auf den Ebenen Lenken und Managen von Projekten hat, nicht aber auf der Lieferebene, ist es bei den agilen Methoden so, dass diese ihren Schwerpunkt auf der Lieferebene haben und beim Managen und Lenken eher schwach sind. Deshalb macht es Sinn, diese beiden Welten sich ergänzen zu lassen.

In diesem Kapitel werden folgende Fragen beantwortet:

• Für wen ist PRINCE2 Agile?
• Welche Communities werden Nutzen haben von PRINCE2 Agile?
• Wann und wo kann ich PRINCE2 Agile anwenden?
• Handlungspfad für jede Community in jeder Situation
• Aus was besteht PRINCE2 Agile?
• Wichtige Punkte über PRINCE2 Agile und dieses Manual

PRINCE2 Agile ersetzt nicht PRINCE2 sondern hilft PRINCE2-Projekten agile Prinzipien mit zu nutzen oder PRINCE2 mit zu nutzen, wenn man agil in Projekten arbeitet. Agile Methoden sind innerhalb von IT-Kontexten entstanden, sie können aber (partiell) auch außerhalb genutzt werden. Im früheren Werk hatte der Autor DSDM in den Vordergrund gestellt. Hier ist nun eher Scrum im Vordergrund. Es ist einfacher und verbreiteter. Der Ausdruck Agile steht immer für eine Familie von Verhalten, Konzepten, Frameworks und Techniken.

4. The PRINCE2 journey when using agile

In drei Blöcken (1. Pre-Project, 2. Subsequent delivery stages 3. Final delivery stage) werden in jeweils vier Schritten (1. Plan, monitor and control, 2. Behaviour, 3. Process, 4. Products) für PRINCE2 neue Konzepte eingeführt, die für die agile Welt notwendig sind:

• Feature
• User Story
• Epic
• Information radiator
• Burn Chart
• Kanban board
• Stand-up meeting
• Retrospective
• Backlog

Schon der erste Blick zeigt, dass in mehreren agilen Umgebungen Anleihen genommen werden, neben Scrum zum Beispiel auch bei Kanban. In den folgenden Kapiteln werden diese Konzepte dann genutzt oder “embedded”.

5. An overview of PRINCE2

Der Überblick über PRINCE2 definiert Projekt, Programm und Projektmanagement. Die Prinzipien, die Themen und Prozesse werden kurz wiederholt.

6. What to fix and what to flex?

Im klassischen Projektmanagement kannte man das magische Dreieck mit den Zieldimensionen Qualität, Zeit und Kosten. Verkürzt man beispielsweise die Zeit, steigen die Kosten oder die Qualität sinkt (hier dann Umfang). PRINCE2 brachte dann gleichberechtigt drei weitere Zielkriterien ins Spiel: Umfang, Risiko und Nutzen (Benefit, siehe auch Business Case). PRINCE2 Agile gibt nun vor, welche Kriterien man statisch und welche flexibel handhaben soll. Dies folgt dem Scrum-Ansatz: Zeit und Kosten fest, der Rest dann eher flexibel. Bei der Qualität ist dann eher gemeint, dass die Qualitätskriterien des Kunden variabel sein können. Nicht in der Höhe der Qualität, sondern im Umfang. Durch Änderungen können Anforderungen geändert werden. Auch wird die Empfehlung gegeben, Teams nicht zu verändern. Das Sechseck wir nun auch PRINCE Agile Hexagon genannt.

Hier werden auch die fünf Ziele von PRINCE2 Agile entwickelt:

1. Be on time and hit deadlines
   Der agile Ansatz, Kosten und Zeit vorzugeben, und ggf. andere Parameter zu ändern, fällt anfangs schwer.
2. Protect the level of quality
   Das Level der Qualität wird bestimmt durch Akzeptanzkrietrien des Kunden/Benutzers, nicht durch Höchstzahlen an Ausfällen gleichartiger Produkte zur Prozessverbesserung wie bei Six Sigma.
3. Embrace change
   Änderungen sind jederzeit willkommen, für ein besseres Produkt.
4. Keep teams stable: do not add people to a team in order to try to go faster
   Die Performance eines Teams skaliert nicht linear mit der Anzahl der Teammitglieder.
5. Accept the customer doesn’t need everything
   Wenn anfangs Geplantes nicht die gewünschten Werte liefert und Verzögerungen hinzu kämen, kann es ggf. auch weggelassen werden.

Part II PRINCE2 Agile guidance, tailoring and techniques

7. Agile and the PRINCE2 principles

Die sieben PRINCE2-Prinzipien

• Fortwährende geschäftliche Rechtfertigung (mit minimum viable product MVP)
• Lernen aus Erfahrung
• Definierte Rollen und Verantwortlichkeiten
• Steuern über Managementphasen
• Steuern nach dem Ausnahmeprinzip
• Produktorientierung
• Anpassen an die Projektumgebung

werden ergänzt durch die fünf Agile Behaviours

• Transparency
• Exploration (mit Experiment und Spike)
• Collaboration
• Self-organization und
• Rich communication.

Für die Behaviours wird empfohlen, sie mit einer Ampel (Grün-gelb-rot) fortwährend zu überwachen.

8. Agile and PRINCE2 themes

In dem kurzen Kapitel wird ein Überblick über die wesentlichen Ergänzungen bei den sieben PRINCE2 Themen Business Case, Organisation, Qualität, Pläne, Risiko, Änderungen und Fortschritt gegeben.

Beispielsweise werden auf der Arbeitsebene die Rollen Product Owner, Scrum Master, AgileCoach und Business Ambassador im Thema Organisation integriert. Beim Thema Qualität muss bei variablen Umfang (Scope) beachtet werden, dass Akzeptanzkriterien sich auch ändern können, ohne sich das “Fit for Purpose” ändert bei geänderten Features. Bei den Plänen tritt neben das Gantt Chart auch das Burn Chart. Wegen der Änderungsfreudigkeit der agilen Welt ergeben sich Änderungen auch im Hinblick auf den Änderungsausschuss, das Änderungsbudget und auch das Konfigurationsmanagement. Beim Fortschritt wird der Begriff Geschwindigkeit (Velocity) eingeführt, in dem man zum Beispiel die Rate von 20 bearbeiteten User Stories pro Woche als Geschwindigkeit für das Team extrapoliert.

9. Business Case theme

Der Business Case und seine andauernde Fortschreibung unterscheidet PRINCE2 von anderen klassischen PM-Methoden. Es wird differenziert nach Output, Outcome und Nutzen (Benefit) eines Projekts. Schon im Agilen Manifest wird dagegen der Wert (Value) als eines der wichtigsten Ziele überhaupt adressiert, ohne seine Messung näher zu definieren. Die deutschen Leser kennen die Problematik des Bestimmens des Nutzens oder des Wertes ggf. durch WiBe (Wirtschaftlichkeitsbetrachtungen), die bei fehlender Bestimmbarkeit monetären Nutzens die Nutzwertanalyse empfiehlt. Steve Jenner hat für APMG die Zertifikation “Managing Benefits” entwickelt. PRINCE2 Agile empfiehlt darüber hinaus, auch einen Blick in Managing of Value (MoV) von Axelos zu werfen. So hat man also zahlreiche Möglichkeiten nutzen- und wertorientiert das Projekt auch agil im Auge zu behalten.

Priorisierung zu erreichen. (Diese Rolle kommt aus Scrum).

• Visioning und Projekt Kick-Off
  Die Hauptfrage des Business Cases “Warum mache ich das Projekt?” muss hier jedem Teammitglied klar werden.
• Sprint Zero
  Scrum arbeitet mit Sprints, um ein Timeboxing für kurze Projektzeitabschnitte über die PRINCE2-Phasen hinaus anzuwenden. Mit Sprint Zero wird dann die Zeit vor den “Arbeitssprints” bezeichnet, in der auch noch nach dem Ansatz geforscht werden kann und das “Warum” geklärt wird.

10. Organization theme

Zunächst bedient sich auch das Organisationsthema der klassischen PRINCE2-Rollen (Auftraggeber, Benutzervertreter, Lieferantenvertreter im Lenkungsausschuss, Projektmanager und Teammanager, Projektsicherung, Änderungsausschuss und Projektunterstützung). Darüber hinaus werden weitere Rollen auf Teamebene hinzugefügt. DSDM kennt viele zusätzliche Rollen, Kanban keine. Scrum liegt dazwischen. Als neue Rollen kommen hinzu:

• Der Scrum Master
  Seine Aufgabe ist es, das Team dabei zu unterstützen, Scrum richtig einzusetzen. Er ist kein Teammanager und nicht Vorgesetzter.
• Der Product Owner
  Seine Aufgabe ist es, die Anforderungen des Kunden in das Team zu bringen und dafür auch die kommerzielle Verantwortung zu tragen. Er wird von PRINCE2 Agile im Team verortet und ist die Schnittstelle nach “oben” (Projektmanager/Teammanager).
• Der Customer Subject Matter Expert (CSME)
  kann im Team die Expertise heben.
• Der Supplier Subject Matter Expert (SSME)
  kann im Team die Expertise heben.
• Der Qualitätssicherer vom Kunden (CQA) oder/und Lieferanten (SQA)
  kann im Team arbeiten. In der reinen SCRUM-Lehre dagegen wird angenommen, dass das Entwicklerteam selbst sicherstellt (Team Quality Assurane), dass die Kundenanforderungen erfüllt werden.

Der Team Manager wird in reinen Scrum-Umgebungen als nicht notwendig angesehen. Hier muss man sensibel Lösungen finden, wer die Aufgaben des Teammanagers wahr nimmt. Der Requirements-Engineer/Business-Analyst wird in der reinen Scrum-Lehre als nicht notwendig angesehen, weil diese Aufgaben vom Product Owner durchgeführt werden sollen.

Neu für eine PRINCE2-Umgebung ist, dass die in ITIL schon lange eingeführte Beschreibung von Verantwortlichkeiten nach RACI (Responsible, Accountable, Consulted und Informed) eingeführt wird.

11. Quality theme

Das Thema Qualität wird aus PRINCE2 übernommen und um einige Konzepte aus der Softwareentwicklung ergänzt: Test-driven (aus XP), Behavour-driven oder “done” und “ready”.

12. Plans theme

Bei dem Thema Pläne wird für die Arbeitsebene unterhalb der Projektpläne und Phasenpläne gezeigt, wie agiles Planen integriert werden kann, sei es Timeboxed oder Flow-based, sei es mit Releaseplänen für Features oder Sprints auf Teamebene, um den Backlog abzuarbeiten. Erwähnt sei auch, dass Empirismus empfohlen wird und auch das Thema Schätzen/Estimation gestreift wird.

13. Risk theme

Im Thema Risiko kommen keine entscheidenden Ergänzungen aus der agilen Welt.

14. Change theme

Änderungen sind in der agilen Welt willkommen. In PRINCE2 können Änderungen an Anforderungen unterschiedliche Auswirkungen haben:

Hohe Ebene	Mittlere Ebene	Detailebene
Änderungen betreffen die Baseline	Änderungen können die Baseline betreffen	Änderungen betreffen nicht die Baseline
Möglicherweise negative Änderungen für das Projekt		Normalerweise positive Änderung für das Projekt

Um die Änderungen zu managen sollte man ständig Feedback-Loops durchlaufen:

• Plan (Zukunft), Do (Gegenwart) Review (Vergangenheit) oder
• OODA (Observe, Orientate, Decide, Act oder
• PDCA (Plan, Do, Check, Act) (Demingkreis) oder
• PDSA (Plan, Do, Study, Act) oder
• Build, measure, learn (Lean Startup).

15. Progress theme

Bei dem PRINCE2-Thema Fortschritt geht es darum, zu messen, wie das Projekt gegenüber dem Plan voran kommt. Dazu gehören dann auch Steuerungsmittel, Ausnahmen und Toleranzen. Aus der agilen Welt kommen Burn-down Charts und Burn-up Charts, in denen visualisiert wir in einem Graphen, wie viel von der geplanten Arbeit noch verbleibt bzw. schon erledigt ist. Ein weiteres Steuerungsmittel ist ein “Information Radiator“. Hier geht es darum, möglichst viele Informationen auf einem Whiteboard zu visualisieren in dem Raum, in dem das Team arbeitet. In dem Axelos-Leitfaden “Integrating PRINCE2” wurde das Whiteboard als ausreichendes Steuerungsmittel empfohlen für kleine Projekte, die zum Beispiel nur aus Auftraggeber und Projektmanager bestehen.

16. Agile and PRINCE2 processes

Die PRINCE2 Prozesse werden durch agile Konstrukte ergänzt. Schwerpunktmäßig wird die Arbeitsebene adressiert (Managen der Produktlieferung) die sonst in PRINC2 eigentlich kaum berührt wird. Die folgende Tabelle zeigt, in welchen PRINCE2-Prozessen agile Artefakte und Ereignisse auftreten:

Lenken eines Projektes
Vorbereiten eines Projektes	Vision, Product Roadmap
Initiieren eines Projektes	Product Backlog
Steuern einer Phase	Release(s), Release Backlog. Release Retrospektive
Managen eines Phasenübergangs	Wie Steueren einer Phase
Managen der Produktlieferung	Sprint(s), Sprint Backlog, Sprint Review, Retrospective
Abschließen eines Projektes	Project Retrospective

PRINCE2-Phasen können typischerweise in der Produktlieferung in Releases und diese wieder in Sprints untergliedert werden.

17. Starting up a project, Initiating a project

In der agilen Welt sind die Prozesse, ein Projekt ans Laufen zu bekommen weniger standardisiert. Zwei Konzepte findet man häufiger:

• Project chartering und Visioning
• Sprint Zero (oder Iteration Zero oder Entdeckungsphase)

Agile Artefakte und Ereignisse, die das PRINCE2-Vorgehen ergänzen können, sind die Vision, Projekt-/Release-Retrospektive vorheriger Projekte, der Projekt Kick-Off (Workshop), der Product-Backlog und auch wieder der Information Radiator.
Als eine verwendbare Technik wird das Cynefin Framework von David Snowden als Wissensmanagement Modell eingeführt. Dieses hilft, sich in der Anfangssituation zu orientieren und Ursache-Wirkungsbeziehungen auszuloten. Es kennt fünf Domänen:

• Simple
• Complicated
• Complex
• Chaotic und
• Disorder.

18. Directing a project

Der Prozess Lenken eines Projektes wird durch PRINCE2 Agile nicht verändert.

19. Controlling a stage

In dem PRINCE2-Prozess “Steuern einer Phase” hat der Projektmanager seine bisherigen Aufgaben, aber es können hier oder in der Phase “Managen der Produktlieferung” zahlreiche agile Komponenten hinzukommen.

• Zum Beispiel kann die Phase gegliedert werden in Timeboxen mit einem oder mehreren Releases, die wiederum aus einem oder mehreren Sprints bestehen.
• Arbeitspakete werden mehr mit den Teams zusammen erstellt.
• Bei der Fortschrittsmessung und dem Reporting können beispielsweise Projektmanager oder Teammanager an den täglichen Standups der Teams teilnehmen, an denen der Fortschritt besprochen wird. Information Radiators können hier gefunden werden ebenso wie Burn-Down Charts statt Gantt-Charts.
• Retrospektiven helfen eine kontinuierliche Verbesserung zu gestalten, wenn sie klar strukturiert sind hinsichtlich Ziele, Teilnehmer, Agenda und Logistik oder auch Stimmungsbarometer (“Glad! Sad! Mad!”). Weitere Hinweise gibt es auch im Retrospective Wiki.

20. Managing product delivery

Über die Phase Managen der Produktlieferung sagt PRINCE2 so gut wie nichts. Es werden nur Arbeitspakete angenommen, ausgeführt und abgeliefert. Auch Scrum sagt wenig darüber, wie Arbeitspakete bearbeitet werden. Es wird nur festegelegt, dass Arbeit aus den Release- und Sprint-Backlogs abgearbeitet wird und im Burn-Down Charts sowie mit Information Radiators der Stand visualisiert wird. Hier wird weitere Unterstützung bei Kanban geholt mit sechs Kernpraktiken:

• Visualisierung
  “Work in Progress” kann in vier Stufen gegliedert sein: Ready, Build, Test, Deploy (mit Ready und Done).
• Begrenzung der “Work in Progress”
• Den Flow managen
• Policies explizieren
• Implementieren von Feed-Back-Loops
• Gemeinsames Verbessern und experimentelles Entwickeln

Neben Kanban können aber auch Anleihen bei Lean Startup gezogen werden:

• Build, measure, learn
• Create a minimum viable product (MVP)
• Fail fast
• Validated learning

21. Managing a stage boundary

In der Phase Managen eines Phasenübergangs kommen aus der agilen Welt keine neuen Konzepte hinzu, außer dass Artefakte und Ereignisse entsprechend fortgeschrieben werden müssen. Product Backlog, Release Backlog, möglicherweise auslieferbares Inkrement, Information Radiator, Release Review und Planung, Sprint Planung.

22. Closing a project

Auch in der Phase Abschließen eines Projektes kommen keine neuen agilen Konzepte hinzu, außer dass die Artefakte zum Ende kommen müssen und die letzten Ereignisse stattfinden.

23. Summary of tailoring guidance for the PRINCE2 products

Hier werden in einer Übersicht die PRINCE2 Managementprodukte (in den Kategorien Baseline, Record, Report) dargestellt und kurze Hinweise auf die Nutzung im agilen Umfeld gegeben.

Part III Areas of particular focus for PRINCE2 Agile

Nachdem im zweiten Teil gezeigt wurde, wie PRINCE2 Themen und Prozesse agil ergänzt werden, werden nun im dritten Teil agile Schwerpunkte beleuchtet wie das Agilometer, Requirements und Rich Communication (nicht zu verwechseln mit dem Standard Joyn – Rich Communications Suite enhanced auf der Mobilfunkwelt).

24. The Agilometer

Das Agilometer ist eine Hilfe, um informierte Entscheidungen treffen zu können. In sechs Bereichen wird durch einfache Schieberegler (Suitability Sliders) mit Werten von 1-5 angezeigt, wie ein bestimmtes Thema aktuell ausgeprägt ist.

Die korrekte Anwendung des Agilometers liegt darin, bei niedrigen Werten für eine Dimension sich zu fragen, wie man den Wert steigern kann und nicht Durchschnittswerte zu berichten. Für jede Dimension werden auch Beispiele genannt zur Verbesserung. Als weitere Hilfestellung kann man auch den DSDM Atern Project Approach Questionnaire nutzen.

25. Requirements

Anforderungen (Requirements) werden in PRINCE2 nicht so behandelt, wie man es zum Beispiel aus modernem Requirements-Engineering kennt und bei den agilen Software-Entwicklungsmethoden Standard ist. Bei PRINCE2 stehen eher die Benutzerakzeptanzkriterien im Qualitätsumfeld im Vordergrund. Deshalb ist dem Thema Requirements ein extra Kapitel gewidmet. Zur Orientierung wird die Terminologie veranschaulicht:

 

Approximate level of detail	Preferred PRINCE2 Agile terms	Possible equivalent terms
The highest	Project product description	Vision
High level	Product group Project product description composition High-level requirement	Epic, feature, function, theme, scope
Intermediate level	Product description Intermediate-level requirement	Epic, feature, function, Coarse-grained user story
Low level	Product description Sub-product Low-level or detailed requirement	User story, fine-grained user story

Die unterschiedlichen Detaillevels spiegeln sich auch im Produktstrukturplan von oben nach unten (oder in der Mindmap von innen nach außen) wieder. Kernprinzip ist, dass die Anforderungen immer weiter operationalisiert werden, so dass sie auch mit dem MoSCoW-Prinzip priorisiert werden können:

• Must have
• Should have
• Could have
• Won’t have for now

Kern der Anforderungen in agilen Kontexten sind User Stories (wenn man so will Szenarien), die mit who, what, why klar zum Audruck bringen sollen, was das Ziel ist oder auch mit dem Ausfüllen des Satzes: As a <role>, I want to <function>, so that <benefit> es zum Ausdruck bringen.
Erwähnenswert ist auch der Unterschied zwischen ready und done. Wenn alle Anforderungen klar sind, ist das Team ready, um mit der Arbeit zu beginnen. Ist die Arbeit des Teams fertig, ist sie done.

26. Rich communication

Der lange E-Mail-Thread mit vielen Empfängern ist in der Regel eine arme Kommunikation. Viele Teilnehmer steigen zwischendurch mental aus. Eine reiche Kommunikation nutzt dagegen eine Vielzahl von Medien aus und versucht die (auch in ITIL verwendete) DIKW-Leiter hoch zu klettern: data, information, knowledge and wisdom (Daten, Informationen, Wissen, Weisheit). Dabei kann auch der Kanal (Worte, Stimme, Gesicht-zu-Gesicht) und die Visualisierung (von keine bis zu viel) gesteigert werden, um die Kommunikation anzureichern. Ausführlich werden auch Workshops als Werkzeug erläutert für eine reiche Kommunikation. Empfohlen wird zusätzlich auch ein Blick auf das Zachmann-Framework, das Informatikern lange bekannt ist und sich als Unternehmensontologie für eine Unternehmensarchitektur versteht.

Appendices

A Product description outlines

Hier werden die 26 Standard Managementprodukte von PRINCE2 in Zweck und Zusammensetzung beschrieben ohne agile Ergänzungen.

B Roles and responsibilities

Es werden die Standard PRINCE2 Rollen kurz beschrieben: Lenkungsausschuss, Auftraggeber, Benutzervertreter, Lieferantenvertreter, Projektmanager, Teammanager, Änderungsausschuss, Projektsicherung, Projektunterstützung. Hinzu kommen agile Rollen: Customer Subject Matter Expert (CSME), Customer Representative, Supplier Subject Matter Expert (SSME), Supplier Representative.

C Health Check – PRINCE2 Agile version

In vier Dimensionen werden in Form einer Checkliste Beispiele genannt, die die Frage “Is the following happening” beantworten und dann für den Health Check numerisch bewertet werden können:

• Behaviours
• Evironment
• Process
• Techniques

D Product-based-planning example

Hier wird das Beispiel der Konferenzplanung wieder aufgenommen aus PRINCE2:2009 mit Produktstrukturplan, Produktbeschreibung und Produktflussdiagramm. Neuerung ist, dass auch Mindmaps statt hierarchischer Produktstrukturpläne alternativ verwendet werden können. Dies ist nicht weiter verwunderlich, da ja die gleiche hierarchische Subordinierung verwendet wird, lediglich mit anderer geometrischer Anordnung.

E The fundamental values and principles a agile (including the Agile Manifesto)

Als fundamentale Werte und Prinzipien von Agile werden aufgeführt:

• Das Agile Manifest werden,
• die Theorie von Scrum,
• die fünf Werte von eXtreme Programming (XP)
• die vier Core Values des Scaled Agile Framework (SAFe) V3.0
• die Project Management Declaration of Interdependence
• die acht Prinzipien von DSDM
• die Kanban Methode
• die Prinzipien von Lean Thinking
• die fünf Prinzipien von Lean Startup.

Es wird darauf hingewiesen, dass manches nur für die Softwareentwicklung gilt.

F Transition to agile and what constitutes success

Es wird darauf hingewiesen, dass es unterschiedliche Arten von Erfolg in einem Projekt gibt: für den Business Case, für das Projektmanagement und für Agile als Stil des Arbeitens. Letztlich schlägt es sich im Reifegrad der Organisation nieder und es wird auf das P3M3-Modell von Axelos verwiesen (Deutsch siehe zum Beispiel auch Wolfgang Ksoll: Reifegrade im Projektmanagement mit PRINCE2).

G Advice given a project manager using agile

Für den Projektmanager, der Agile einsetzt, gibt es hier noch kurze, prägnante Hinweise in den Dimensionen:

• Kollaboration und Selbstorganisation.
• Transparenz, Kommunikation und Exploration
• Umgebung
• Planen, überwachen und steuern

H The definitive guide to Scrum

Ein wahres Highlight rundet die Anhänge ab: Der definitive Scrum Guide, der auch offiziell downgeloadet werden kann und www.scrumguides.org. Auch in Deutsch ist er verfügbar: “Der gültige Leitfaden für Scrum“.

Hier die Überschriften:

• Purpose of the Scrum Guide
• Definition of Scrum
• Scrum Theory
  Transparency, Inspection, Adaption (Transparenz, Überprüfung, Anpassung)
• The Scrum Team
  The Product Owner, the Development Team (3-9), the Scrum Master
• Scrum Events
  The Sprint, Daily Scrum, Sprint Review, Sprint Retrospective
• Scrum Artifacts
  Product Backlog, Sprint Backlog, Increment
• Artifact Transparency
  Definition of “Done”
• End Note, Acknowledgements

Eventuell lohnt es sich für agile Anfänger bei dem Scrumguide anzufangen.

Ein Glossary und ein Index runden das Werk nach über 350 Seiten ab.

Zusammenfassung

PRINCE2 Agile ist ein mächtiger Methodenbaukasten geworden. Wer ihn nutzen möchte, sollte mindestens PRINCE2 beherrschen. Scrum ist mehr in den Vordergrund gerückt als früher DSDM. Dadurch ist zum Beispiel der Ansatz bei den Rollen deutlich schlanker und die Verortung des Product Owner in der Arbeitsebene deutlich klarer als die komplexen Rollengefüge aus dem DSDM-Ansatz.

Die Ergänzungen von PRINCE2 durch agile Ansätze sind reichhaltig. Viele vorgestellte Konzepte waren auch dringend notwendig, wie zum Beispiel “Workshop” und “Rich Communication“. In der Softwareentwicklung wird man die Mischung beider Welten sofort gut einsetzen können. Viele Konzepte lassen sich auch außerhalb der IT trefflich nutzen. Das Handbuch ist kein Kochbuch mit Rezepten sondern eher ein Zutatenbuch, mit dem man schmackhafte Mahlzeiten erstellen kann.

Wichtig wird sein, im Rahmen der Ausbildung zu PRINCE2 Agile durch Übungen an konkreten Beispielen den Erwerb und die Anwendung des Wissens zu vertiefen. Hier sei aber auch an die X-Y-Theorie von McGregor erinnert, wo man heute sagt, dass vielleicht 80% der Unternehmen klassische X-Unternehmen sind und nur 20% agilere Y-Unternehmen. Hier muss jeder den passen Fit für sein Unternehmen finden. Gut aber ist, dass nun ein reichhaltiger Entwurf von praktisch bewährten Autoren vorliegt, der qualifiziert geschult und angewendet werden kann.

Insgesamt hat sich das Warten gelohnt. Nun wird man sehen müssen, wie der Markt reagiert, ob es nun zu einer gewissen Konsolidierung der vielen agilen Ansätzen kommt, die sich schmerzarm in klassische Projektorganisationen einbetten lassen.