PRINCE2 & Agile vereinigt Allheilmittel oder Rohrkrepierer?

Transkript

1 PRINCE2 & Agile vereinigt Allheilmittel oder Rohrkrepierer? Patrick Graffeille +49(0)

2 Kurzvorstellung

3 Agenda 1. Risiken und Nebenwirkungen! 2. Meine Welt 3. Projekt KARL Projektorganisation 4. Projekt TIGER Business Case 5. Projekt G6 Planung 6. 42?

5 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!

7 Pictures: PRINCE2 Agile Axelos Meine Welt Agile 1. Rahmenwerk für die Entwicklung komplexer Produkte 2. Iteratives Vorgehen durch Erstellung 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?)

8 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

9 Meine Welt von Äpfeln und Birnen? Anforderung Übergabe Betrieb Projekt Betrieb Steuerung Linie PRINCE2 Linie Produktion Agile (Kanban?) Agile (SCRUM?) Agile (Kanban?) Picture: PRINCE2 Agile Axelos

10 Meine Welt Agile PRINCE2 oder PRINCE2 Agile? 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 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!

12 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)

13 Projekt KARL Methodische Überlegungen Projekt Sicherung Team Manager Auftraggeber Projekt Manager Team Manager PRINCE2 Agile : Scrum Master = Teammanager Product Owner = keine Parallele! Benutzervertreter Lieferantenvertreter Lenkungsausschuss Team Manager RACI Charts Project: Kaffee 2.0 PROCEDURE Kaffe Zubereitung DEPARTMENT Genuß & Spaß UPDATED Nr. Beschreibung Owner Manager Maschine 1 Bedarf feststellen A/R I C 2 Kaffeevorrat prüfen I A/R RACI Charts Project: Kaffee 2.0 PROCEDURE Kaffe Zubereitung DEPARTMENT Genuß & Spaß UPDATED Nr. Beschreibung Owner Manager Maschine 1 Bedarf feststellen A/R I C 2 Kaffeevorrat prüfen I A/R Kunde Kunde 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

14 Projekt KARL Anpassung Methodik Lenkungsausschuss 1. Nur 1 Projektmanager 2. Die anderen Projektleiter werden BV Benutzervertreter & Product Owner Auftraggeber Lieferantenvertreter 3. Teammanager umbenannt zu Teamcoach 4. Super Product Owner wird aus den Reihen der Benutzervertreter gewählt Projektmanager & Master (Außen) Steuerung und Management 5. Projektmanager übernimmt Außen-Aufgaben des SCRUM Master 6. Teamcoach übernimmt Innen-Aufgaben des SCRUM Masters Team Coach & Master (Innen) Team Coach & Master (Innen) Team Coach & Master (Innen) Produktion 7. Arbeitsweise des Teams bleibt unverändert (4 Wochen Sprints). Meinung: PRINCE2 und Agile lassen sich befriedigend kombinieren

15 Quelle: PRINCE2 Agile Axelos 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

17 Projekt TIGER Vorstellung und Auftrag Software Firma Mehrere Abteilungen, wobei eine sich nur 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

18 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)

19 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!

20 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

22 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

23 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

24 Sprint / Iteration 1 Sprint / Iteration 2 Sprint / Iteration 3 Sprint / Iteration 1 Sprint / Iteration 2 Sprint / Iteration 3 Sprint / Iteration 4 Sprint / Iteration 5 Sprint / Iteration 1 Sprint / Iteration 2 Projekt G6 Anpassung der Methodik 1. PRINCE2 Produkte und Agile User Stories 2. PRINCE2 3-Punkt Schätzung und Agile Planning Poker 3. Planungsebenen übersetzt inkl. 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 Best Normal Worst Jeder Sprint entspricht einem Teamplan Produktbeschreibung Phase 1 = Release Plan* Phase 2 = Release Plan* Phase 3 = RP* Projekt Plan = Roadmap Meine Meinung: PRINCE2 und Agile lassen sich sehr gut miteinander kombinieren

25 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

26 Agenda 1. Risiken und Nebenwirkungen! 2. Meine Welt 3. Projekt KARL Projektorganisation 4. Projekt TIGER Business Case 5. Projekt G6 Änderungen 6. 42?

27 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! Fazit 1/3 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 Hablo Agile? No, I live PRINCE2 street (?)

28 Fazit 2/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!

29 Fazit 3/3 42? Die drei Erfolgsfaktoren 1. Analyse des Umfelds Firmenkultur? Führungsstil? Arbeitsweise Team? Sprache? Lösungsraum verstehen! 3. Ehrliche Methodiker Vormachen! Entscheidern beim Entscheiden helfen Methodenschwächen zugeben und Lösungen schaffen Fehler (vor-)machen! 2. Iterative Schleifen Keine Methode ist sofort fertig Überlegen, ausprobieren, Feedback, von vorne Weniger ist mehr!

30 Culture eats strategy for breakfast Peter Drucker Patrick Graffeille Vielen Dank für Ihre Aufmerksamkeit!

31 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 +49 (0) 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.