PRINCE2 & Agile vereinigtAllheilmittel oder Rohrkrepierer?

Patrick Graffeillepatrick@graffeille.de

+49(0) 171 401 49 94

Kurzvorstellung

Agenda

1. Risiken und Nebenwirkungen!

2. Meine Welt…

3. Projekt KARL – Projektorganisation

4. Projekt TIGER – Business Case

5. Projekt G6 – Planung

6. 42?

Agenda

1. Risiken und Nebenwirkungen!

2. Meine Welt…

3. Projekt KARL – Projektorganisation

4. Projekt TIGER – Business Case

5. Projekt G6 – Planung

6. 42?

Risiken und Nebenwirkungen!

1. Bitte nichts persönlich nehmen!

2. Vortrag beinhaltet NUR EIGENE Erfahrungen

3. Ich beanspruche nicht irgendeine Wahrheit zu kennen, noch bin ich Anhänger einer bestimmten Richtung oder Bewegung

4. Priorität haben funktionierende methodische Lösungen

5. Aufgrund der knappen Zeit werde ich pauschalisieren müssen

Kein Anspruch auf restlos korrekte Theorie!

Agenda

1. Risiken und Nebenwirkungen!

2. Meine Welt…

3. Projekt KARL – Projektorganisation

4. Projekt TIGER – Business Case

5. Projekt G6 – Planung

6. 42?

Meine Welt… Agile

1. Rahmenwerk für die Entwicklung komplexer Produkte

2. Iteratives Vorgehen durchErstellung von (lieferbaren) Teilprodukten

3. Eher Produktionsmethode

4. Setzt bestimmte Kultur voraus

5. SCRUM, Kanban, Lean, DevOps, etc. Kaum Aussagen zur Management Steuerung(Lösung: Agile Skalierung?)

Pic

ture

s: P

RIN

CE2

Agi

le ©

Axe

los

Meine Welt… PRINCE2 1. Rahmenwerk für Projekte

2. Phasenorientiertes Vorgehen

3. Eher Steuerungsmethode

4. Universell einsetzbar

5. Strukturiertes, definiertes Vorgehen

6. Projektmanagement ONLY! (no BAU, neue Orga)

7. Ziel: Gesteuerte und beherrschte Projektumgebung schaffen Kaum Aussagen zur Produktion

Pictures: PRINCE2 Agile © Axelos

Meine Welt…von Äpfeln und Birnen?

Picture: PRINCE2 Agile © Axelos

Anforderung Übergabe

Projekt

PRINCE2

Agile(SCRUM?)

Betrieb

Linie

Agile(Kanban?)

Betrieb

Linie

Agile(Kanban?)

Steuerung

Produktion

Meine Welt… Agile PRINCE2 oder PRINCE2 Agile…?

Fokus liegt auf der Kombination (nicht Vergleich) der beiden Methoden:

1. Im Folgenden stelle ich einzelne, anonymisierte Projekte vor

2. Ich erläutere, wo und wie wir beide Methoden kombiniert haben

3. Anschließend mein persönliches Fazit (lessons learned)

Entscheidung liegt bei Ihnen!

Ist Steuerung in agilen Umgebungen kontraproduktiv? • Ein Kampfflugzeug ist absichtlich mit einer instabilen

Flugzeugzelle gebaut• Diese Instabilität gibt die Möglichkeit, sich schnell an

neue Situationen anzupassen• Steuerung und Führung dennoch notwendig

Agenda

1. Risiken und Nebenwirkungen!

2. Meine Welt…

3. Projekt KARL – Projektorganisation

4. Projekt TIGER – Business Case

5. Projekt G6 – Planung

6. 42?

Projekt KARL – Vorstellung und Auftrag• CIO führt durch Kultur der Angst

• Irrationale Erwartungen

• Armeen von Beratungshäusern mit widersprüchlichen Aufträgen und Ausgangslagen

• 3 Projektleiter pro Projekt (Auftraggeber, Kunde und Dienstleister)

• Keine/kaum Entscheidungen

• „Schwarze Peter“-Meetings

• Politik überall: Gemeinsam lügen bis zum bitteren Ende!

• Gewählte Methode: „Marketing - SCRUM“

1. Produktives Team, das ein verfälschtes SCRUM bestmöglich nutzte

2. Genaue methodische Anleitung für die Produktion

3. Vorbildliche Kommunikation und Zusammenarbeit der heterogenen Teams

1. Alle Rollen oberhalb des Teams(Steuerung und Mngt.) blieben ungeklärt Ausrede: „Die Teams steuern sich selber“

2. SOLL Planung passte nie zum IST und den Meldungen des Teams („parallelisieren!“)

3. SCRUM in name only…Product Owner nicht vorhanden, Master zahnlos

Auftrag: PRINCE2 Überbau zur Steuerung für SCRUM schaffen (inkl. SCRUM Rettung)

Projekt KARL – Methodische Überlegungen

1. Product Owner (SCRUM)• Verantwortet Erfolg des Produkts

• Rücksprache mit den Stakeholdern

• Entscheidet über Product Backlog

2. SCRUM Master• Stellt korrekten SCRUM Einsatz/Prozess

sicher

• Regelt Einwirkung von Außenstehenden

• Beseitigt Hindernisse, die das Team blockieren

3. Manager?• SCRUM braucht keine Manager

• PRINCE2 braucht einen Projektmanager

Benutzer-vertreter

Lieferanten-vertreter

Auftraggeber

ProjektManager

TeamManager

TeamManager

TeamManager

PRINCE2 Agile©: Scrum Master = Teammanager

Product Owner = keine Parallele!

Lenkungsausschuss

Project: Kaffee 2.0PROCEDURE Kaffe Zubereitung

DEPARTMENT Genuß & Spaß

UPDATED 01.11.2013

RACI Charts

Nr. BeschreibungOwner

Manager

Maschine

Kunde

1 Bedarf feststellen A/R I C

2 Kaffeevorrat prüfen I A/R

Project: Kaffee 2.0PROCEDURE Kaffe Zubereitung

DEPARTMENT Genuß & Spaß

UPDATED 01.11.2013

RACI Charts

Nr. BeschreibungOwner

Manager

Maschine

Kunde

1 Bedarf feststellen A/R I C

2 Kaffeevorrat prüfen I A/R

ProjektSicherung

Projekt KARL – Anpassung Methodik 1. Nur 1 Projektmanager

2. Die anderen Projektleiter werden BV

3. Teammanager umbenannt zu Teamcoach

4. Super Product Owner wird aus den Reihen der Benutzervertreter gewählt

5. Projektmanager übernimmt „Außen-Aufgaben“ des SCRUM Master

6. Teamcoach übernimmt „Innen-Aufgaben“ des SCRUM Masters

7. Arbeitsweise des Teams bleibt unverändert (4 Wochen Sprints).

Benutzervertreter&

Product Owner

Lieferanten-vertreter

Auftraggeber

Projektmanager&

Master (Außen)

Team Coach&

Master (Innen)

Team Coach&

Master (Innen)

Team Coach&

Master (Innen)

Steuerung und Management

Produktion

Meinung: PRINCE2 und Agile lassen sich befriedigend kombinieren

Lenkungsausschuss

Projekt KARL – Fazit

1. Projekt endete im Desaster. CIO plus Führung entlassen

2. PRINCE2 und SCRUM Rollen wurden nicht angenommen • Benutzervertreter störten dauernd das Team

• Lieferantenvertreter funktionierten kaum

• Super Product Owner hatte keine Entscheidungsgewalt

3. Projektmanager (Dienstleiter) wurde schnell kalt gestellt

4. Eskalationswege funktionierten weiterhin nicht

5. Team lieferte und lieferte (ohne Master, Product Owner, Leiter,…)

Keine Methode ist sicher gegen Politik

Qu

elle

: PR

INC

E2 A

gile

© A

xelo

s

Agenda

1. Risiken und Nebenwirkungen!

2. Meine Welt…

3. Projekt KARL – Projektorganisation

4. Projekt TIGER – Business Case

5. Projekt G6 – Planung

6. 42?

Projekt TIGER – Vorstellung und Auftrag

• Software Firma

• Mehrere Abteilungen, wobei eine sichnur um einen Kunden kümmert

• In dieser Abteilung SCRUM als führende Methode etabliert

• „SCRUM Guru“ komplett auf Abwegen:• „Keiner steuert uns, auch nicht der Chef“

• „Wir alleine entscheiden, was gemacht wird. Der Kunde hat kein Mitspracherecht“

• „Wenn der Kunde uns nicht versteht und nicht weiß, wofür er bezahlt, dann brauchen wir einen neuen Kunden“

1. Eingespieltes Team mit hoher Affinität zu Methoden

2. Perfekte Rahmenbedingungen für SCRUM (Mehr BAU als Projekt, guter Chef, guter Kunde)

3. SCRUM-fähige Truppe

1. Kunde droht mit Kündigung

2. Kunde will von SCRUM nichts mehr hören

3. Team lehnt Führungskräfte und Kundenwillen vollkommen ab

4. Wildes Backlog ohne Regeln

Auftrag: Business Case als Kommunikationsgrundlage zwischen Kunde und Anbieter etablieren

Projekt TIGER – Methodische Überlegungen

1. Business Case ist Entscheidungsgrundlage Projekt weiterhin wünschenswert?

2. Denkt in Nutzen (Benefit) des Projekts

3. Nutzen auf Projektniveau

1. Geschäftliche Rechtfertigung für Arbeiten wurden bereits vorab vorgenommen Häufig kein Business Case vorhanden

2. Denkt in Einzel-Wert (Value)

3. Gesamte Wertermittlung eher schwierig

• Menge an Features stellt einen Teil des Business Case dar (Wert aber nicht Nutzen)

• PRINCE2 Business Case = Agile Vision bzw. Product Roadmap? Eher nicht…

• Lean Start Up: Minimum Viable Product (MVP) / Prototyping im Business Case abbildbar

• Agiler Wert = PRINCE2 netto Nutzen (d.h. abzüglich Aufwände)

Projekt TIGER – Anpassung Methodik

1. Einführung des Business Case (BC) zur übergeordneten Steuerung des Backlogs. Beides verwaltet der Product Owner(!)

2. Product Owner bespricht den BC mit dem Kunden und der Geschäftsführung

3. BC Leitfaden für Product Owner für Aufbau und Priorisierung des Backlogs

4. Durchführung eines „Sprint Zero“ für einen neuen Business Case

Meinung: PRINCE2 und Agile lassen sich gut kombinieren!

Projekt TIGER – Fazit

1. Re-Fokussierung auf wert- oder nutzenorientierte Produkte bzw. Features(weg von Mengen-orientierter)

2. Einstellung eines neuen, starken Product Owner (als Abteilungsleiter)

3. Weggang/Entlassung des „SCRUM Gurus“

4. Business Case und Product Backlog haben sich für die jeweilige Managementebene als Kommunikationsmittel etabliert

Feedback 1 Jahr später: • Team freut sich über funktionierenden Product Owner auf Backlog Ebene

• Kunde und Chef freuen sich über funktionierenden Product Owner auf Business Case Ebene

• Entwickler sind froh, dass die wert- oder nutzenorientierte Arbeitsweise ihren Alltag nicht zu sehr verändert hat (arbeiten eigentlich immer noch „nur“ das Backlog ab)

• Weggang des „SCRUM Gurus“ nachträglich vom Team als schade aber notwendig eingestuft

Agenda

1. Risiken und Nebenwirkungen!

2. Meine Welt…

3. Projekt KARL – Projektorganisation

4. Projekt TIGER – Business Case

5. Projekt G6 – Planung

6. 42?

Projekt G6 – Vorstellung und Auftrag

• Projekt mit PRINCE2 initiiert

• Produktion schlecht gestartet• M.E. normaler Teamfindungsprozess

• Management hat die Nerven verloren 180 Grad Turnaround zu SCRUM

• Alleiniger Fokus auf die Produktion Führung vernachlässigt!

• Kampf Firmen-Projektmanager (PRINCE2) gegen Firmen-Abteilungsleiter (Kanban)

• Blockade Keine Linienkräfte fürs Projekt

1. Methodische Diskussionen auf hohem Niveau

2. Gutes Team, das gerne mit der Arbeit anfangen wollte

3. Realistische Vorstellungen der Führung bzgl. Ressourceneinsatz und Dauer

1. Verhärtete Fronten

2. Viele methodische Kreis-Diskussionen. Versuch diese „logisch“ zu gewinnen statt per Entscheid

3. Jedes Meeting neue, aberwitzige Beweisführungen!

Auftrag: Re-Etablierung einer Planungsebene, die PRINCE2 sowie agilen Vertretern eine Brücke baut

Projekt G6 – Methodische Überlegungen

1. Produktbasierte Planung

2. Drei Planungsebenen Projekt-, Phasen- und Teamplan (optional)

3. Fokus: Langfristige Planung (Projekt, Phase)

1. Verschiedene Planungstechniken in Agile, z.B. User Stories mit Story Points

2. Feature basierte Planung

3. Fokus: Just in Time Planung (vor Sprint)

• Planung und Schätzung auf Grundlage von Erfahrungswerten (nicht logische Planung)

• Einbindung vieler/aller Teammitglieder

• Produktbasierte Planung = User Storys und Features bzw. Gruppen von Features

• Phaseneinteilung sollte nicht technischen Phasen entsprechen (z.B. Design, Build, test, etc.)

• Agile Akzeptanzkriterien bzw. „Definition of done“ = PRINCE2 Qualität inkl. Abnahme

Projekt G6 – Anpassung der Methodik

1. PRINCE2 Produkte und Agile User Stories

2. PRINCE2 3-Punkt Schätzung und Agile Planning Poker

3. Planungsebenen übersetztinkl. „Projektplan“

4. Wechsel von Kanban auf Timeboxed Ergebnisorientierte Phasen

5. Commitment Team durfte „von unten“ gegensteuern Konform mit PRINCE2 Toleranzen

6. Agile „Definition of done“ kombinierbar mit PRINCE2 Qualität von Produkten

Meine Meinung: PRINCE2 und Agile lassen sich sehr gut miteinander kombinieren

Best Normal Worst

5 8 10

3 4 6

2 3 3

Produkt-beschreibung

Projekt Plan = Roadmap

Phase 1 = Release Plan* Phase 2 = Release Plan* Phase 3 = RP*

Sp

rin

t /

Ite

rati

on

1

Sp

rin

t /

Ite

rati

on

2

Sp

rin

t /

Ite

rati

on

3

Sp

rin

t /

Ite

rati

on

1

Sp

rin

t /

Ite

rati

on

2

Sp

rin

t /

Ite

rati

on

3

Sp

rin

t /

Ite

rati

on

4

Sp

rin

t /

Ite

rati

on

5

Sp

rin

t /

Ite

rati

on

1

Sp

rin

t /

Ite

rati

on

2

Jeder Sprint entspricht einem Teamplan

Projekt G6 – Fazit

1. Erfolgreiches Projekt

2. Sehr unterschiedliche Charaktere, die aber alle irgendwie recht hatten

3. Etwas zu freie Hand durch die Geschäftsführung – kaum Rechtfertigungen(„Die Teams steuern sich selber – Keine Entscheidung durch uns notwendig“)

4. Besser funktionierender Lenkungsausschuss wäre wünschenswert gewesen(„Wieso, ihr macht doch jetzt mehr Agile als PRINCE2“ – Eskalation nur über die Linie?)

5. Etabliertes offene-Punkte Management (Change Management) wäre von Vorteil gewesen (z.T. wieder Eskalationen und Entscheidungen)

6. Schwierige Gradwanderung bzgl. Agile Manifesto„Rather respond to change than follow a plan“

Agenda

1. Risiken und Nebenwirkungen!

2. Meine Welt…

3. Projekt KARL – Projektorganisation

4. Projekt TIGER – Business Case

5. Projekt G6 – Änderungen

6. 42?

42? – PRINCE2 und Agile lassen sich gut kombinieren, aber…

1. Bei der Kombination von Agile und PRINCE2 muss i.d.R. einer teilweise nachgeben Einige Sachverhalte sind nicht sauber zu lösen Kompromisse müssen her!

2. Permanenter Schieberegler Mehr davon heißt i.d.R. weniger hiervon Entscheiden, nicht ewig diskutieren…

3. Beide Methoden (Methodiker) müssen sich verstehen im Sinne der Kommunikation Glossar und Wording ausarbeiten

HabloAgile?

No, I live PRINCE2

street…(?)

Fazit 1/3

42? – Überraschung: Es geht gar nicht um den Namen!?

• Es geht nicht um PRINCE2 und/oder Agile

• Es geht die W-Fragen beantwortet zu bekommen

• Methoden sind kein Selbstzweck!

• In der Praxis existiert sowieso keine Methode in Reinform

Es geht ausschließlich darum, dem Kunden eine funktionierende Steuerung und eine funktionierende Produktion zu liefern

Wie das heißt, spielt keine Rolle!

Fazit 2/3

42? – Die drei Erfolgsfaktoren

1. Analyse des Umfelds

• Firmenkultur?

• Führungsstil?

• Arbeitsweise Team?

• Sprache?

Lösungsraum verstehen!

2. Iterative Schleifen• Keine Methode ist

sofort fertig• Überlegen,

ausprobieren, Feedback, von vorne…

Weniger ist mehr!3. Ehrliche „Methodiker“• Vormachen!• Entscheidern beim Entscheiden helfen• Methodenschwächen zugeben und

Lösungen schaffen• Fehler (vor-)machen!

Fazit 3/3

Vielen Dank für Ihre Aufmerksamkeit!Patrick Graffeille

“Culture eats strategy for breakfast”Peter Drucker

Patrick Graffeille – Kurzprofil

Methoden für Strategie, Projekt und Prozesse

Zur Person

Dipl.-Kfm.

Geboren 1976

Seit 1999 Berater und Trainer

Deutsch, Englisch, Französisch

Themengebiete und Produkte

Strategische Methoden und Werkzeuge

Programm- und Projektmanagement

Prozessmanagement und Optimierung

IT Service-Management

Einsatzszenarien Entwicklung und Umsetzung von Methoden im Allgemeinen:

Strategie (Strategisches Management)

Programme und Portfolios

Projekte und Prozesse

Entwicklung und Umsetzung von Methoden im Speziellen:

Strategielehren nach Mintzberg und Porter

MSP, MoP, PRINCE2 und Agile

ITIL

BPMN

Typische Rollenübernahmen:

Methodenentwickler

Projektmanager / -leiter

Prozessentwickler

Moderator / Coach

Ausbildung und Zertifizierungen Akkreditierter Trainer

PRINCE2

ITIL

Zertifiziert

PRINCE2:2009 Practitioner

ITIL V3 Expert

BPMN Professional

ISO20000

Vertiefte Kenntnisse

Managing Successful Programmes (MSP)

Management of Portfolios (MoP)

CobiT

Diverse strategisches Werkzeuge wie z.B. BCM, SWOT, Lebenszyklus, etc.

patrick@graffeille.de

+49 (0) 171 401 49 94