Klassisches Projektmanagement und agil – (K)ein Widerspruch!? Dies ist das Thema der Präsentation, die Dr. Andreas Wagener und Colette Ziller (OPITZ CONSULTING) auf der OOP 2011 hielten. Wie kann Projektmanagement agil sein? Welche Vorteile hat dies? Welche Rolle spielen in diesem Zusammenhang Crum und Prince2? Auf diese Fragen geben die Experten der IT-Beratung OPITZ CONSULTING Antworten.

1. Klassisches Projektmanagement und agil – (K)ein Widerspruch!?

2. Dr. Andreas Wagener, Project Manager OPITZ CONSULTING Essen GmbH Colette Ziller, Project Manager OPITZ CONSULTING München GmbH (K)ein Widerspruch!? OOP München, 27.01.2011 Klassisches Projektmanagement und agil

3. Agenda Klassische Projektmanagement-Ansätze Agile Methoden PRINCE2 Scrum Agiles PRINCE2 Fazit

5. 1 Klassische Projektmanagement-Ansätze

6. Klassische Projektmanagement-Ansätze

7. Stellschrauben des klassischen PM Umfang Zeit Kosten

8. 2 Agile Methoden

9. Warum agil? Schlechte Kommunikation zwischen Entwicklern und „Kunden“ Häufige, nachträgliche Änderungen an Spezifikationen Projektfortschritt wenig transparent Planeinhaltung über alles

10. Was ist agil – und was nicht?

11. Agile Methoden Extreme Programming Test-Driven Development Agile Unified Process Crystal Scrum Feature Driven Development DSDM Atern

12. Grundsätzliche Unterschiede Anforderungen nur teilweise und grob bekannt Änderungen als Standard Testautomatisierung zwingend notwendig Frühes Kunden-Feedback Vermeidung von Verschwendung Exakter Umfang nicht vorhersehbar Transparenter Projektfortschritt

13. Stellschrauben des agilen PM Umfang Zeit Kosten

14. 3 PRINCE2

15. Vorstellung PRINCE2 Projects incontrolledenvironments Grundprinzipien

16. Vorstellung PRINCE2 Prozesse Projects incontrolledenvironments Themen Grundprinzipien

17. Executive PRINCE2 Prozessmodell Starting Up a project Directing a project Management Initiating a project Controlling a stage Managing stage boundaries Closing a project Delivery Managing product delivery

18. 4 Scrum

19. Scrum Prozess Daily Scrum Sprint Produkt ProduktBacklog SprintBacklog

20. Rollen in Scrum Team ProductOwner Produktverantwortung (Umfang, Releasedatum) Priorisierung der Features Sammlung und Konsolidierung aller Anforderungen Abnahme der Features Business Value (ROI) Aufwandsschätzung Implementierung Selbstorganisation Scrum Master Produktivität des Teams Einhaltung der Rollen und Prozesse (Time-Boxing, …)

21. 5 Agiles PRINCE2

22. Business Case Projekt-Zwischenergebnisse finanzieren Umfang nicht festgelegt Prozesse Themen

23. Organisation Kundensicht vs. Lieferantensicht Mapping der Rollen Prozesse Themen

24. Planung Masterplanung nach PRINCE2 Sprintplanung nach Scrum Prozesse Themen

25. PRINCE2 und Scrum – mögliche Ausprägung Projekt StartingUp Initiating Stage 1 Stage 2 Closing Stage n Sprint Sprint Sprint

26. Prozesse und Risikomanagement Scrum fürs Team PRINCE2 fürs Management Anpassung des Steuerungsgrads Prozesse Themen

27. Qualität und Änderungen Vorausschauende vs. Konvergierende Qualität Änderungen als Ausnahme vs. Änderungen als Regel Prozesse Themen

28. Fortschritt und Reporting Statusberichte vs. Burndown-Charts Team Pläne vs. Sprint Pläne Prozesse Themen

29. Projektabschluss Retrospektiven und Lessonslearned Abschlussberichte Prozesse Themen

30. 6 Fazit

31. Klassisch Agil Projektsichtweise Termingerecht Budgetgerecht Spezifikationskonform Nutzenorientiert Anwenderfokussiert Nachhaltig

32. Executive PRINCE2 und Scrum Starting Up a project Directing a project Management Initiating a project Controlling a stage Managing stage boundaries Closing a project Delivery Managing product delivery Scrum

33. Erfahrungen und ErkenntnissePRINCE2 & Scrum Kombination von PRINCE2 und agilen Vorgehensmodellen sehr empfehlenswert bei „movingtargets“ Grad der agilen „Infiltrierung“ hängt stark vom Umfeld ab Gutes Change Management erforderlich

34. Was muss ich berücksichtigen? Produktplanung: Produktbeschreibungen anfangs high-level, dann immer detaillierter Produkt Backlog lebt Business Case kann sich ändern Scope zu Anfang nicht festgelegt  Muss bei Toleranzen (Scope) berücksichtigt werden Wie viele Sprints in eine Phase? Wer ist der ScrumProductOwner? Senior User? Project Manager? Ist der Projektmanager auch gleichzeitig Scrum Master? … oder doch besser der Team Manager als Scrum Master?

35. Projektverantwortlichkeiten

36. Am Beispiel von Scrum: PRINCE2 Business Case getrieben Management byException Berücksichtigt auch Start und Ende des Projekts Unterstützt beim Risiko-Mgmt. Produktbasiert Planung in Phasen (etwas agil  ) Skaliert gut Anpassbar Anforderungsänderungen sind die Ausnahme Scrum Business Value getrieben Selbstorganisierend Qualität hat oberste Priorität Ergebnisorientiert Transparent: „Echter“ Status jederzeit ersichtlich Agile Planung Skaliert gut Anpassbar Anforderungsänderungen sind die Regel PRINCE2 und Agil – passt das?

37. Rollenmapping Scrum Master  Team Manager ProductOwner  Kleinere Entwicklungsprojekte  Projektleiter Team Manager, Teilprojektleiter

38. Rollen in Scrum Team ScrumMaster ProductOwner Aufwandsschätzung Implementierung Selbstorganisation Produktverantwortung (Umfang, Releasedatum) Priorisierung der Features abhängig vom Business Value und Risiken Berücksichtigung der Anforderungen aller Stakeholder Abnahme der Features Business Value (ROI) Produktivität des Teams Einhaltung der Rollen und Prozesse (Time-Boxing, …)

39. Der Scrum „Prozess“ Daily Scrum ProductOwner Team ProductOwner Team DefiniertPriorisiert Schätzt Review Wählt aus Sprint Produkt ProduktBacklog SprintBacklog

40. Klassisch vs. Agil Umfang Zeit Kosten

41. Kontakt Dr. Andreas Wagener, Project Manager OPITZ CONSULTING Essen GmbHAltendorfer Str. 3  45127 EssenTel. +49 (201) 89 29 94 – 0a.wagener@opitz-consulting.com Colette Ziller, Project Manager OPITZ CONSULTING München GmbHWeltenburger Str. 4  81677 MünchenTel. +49 (89) 68 00 98 – 0colette.ziller@opitz-consulting.com