Post on 01-Jun-2020
PRINCE2 & Agile vereinigtAllheilmittel oder Rohrkrepierer?
Patrick Graffeillepatrick@graffeille.de
+49(0) 171 401 49 94
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