Agiles Projekt-Controlling

1. Agiles Projektcontrolling Agile Teams machen Controlling mit Spaß! Köln, 17.10.2012

2. 1 Begriffsklärung 2 Gegenstand 3 Beispiel-Projekt 4 Praxis 5 Fazit, Ausblick

3. || Andreas Czakaj IT Director bei Pixelpark Köln Technical Lead, IT Architekt , Scrum Master, IT Consultant, Coach, IT PM, … Background: Java, JEE, SOA, Web, Mobile, eCommerce, Individualentwicklung XP, TDD/BDD, Scrum, Agile 3 Zum Referenten © p i x e l p a r k

4. | Agenda 1 Begriffsklärung 4© p i x e l p a r k

5. || Sicherung des Erreichens der Projektziele durch:  Soll-Ist-Vergleich  Feststellung der Abweichungen  Bewerten der Konsequenzen und Vorschlagen von Korrekturmaßnahmen  Mitwirkung bei der Maßnahmenplanung und Kontrolle der Durchführung Quelle: http://de.wikipedia.org/wiki/Projektcontrolling 5 Definition „Projekt-Controlling“ nach DIN 69901 © p i x e l p a r k

6. || Einhalten von Vorgaben zu:  Umfang / Scope  Budget  Zeitvorgaben  Qualität Auch bekannt als die „Furious Four“ (nach Jonathan Rasmusson) *, oder auch… Jonathan Rasmusson: „The Agile Samurai“, http://pragprog.com/book/jtrap/the-agile-samurai 6 Projekt-Ziele © p i x e l p a r k

7. | Die vier Reiter der Apokalypse Four Horsemen of Apocalypse, by Viktor Vasnetsov. 1887

8. ||  Umfang / Scope „Da ist ein Brett zu bohren.“  Zeitvorgaben ASAP  Qualität „Natürlich 0 Fehler …aber beim Testen nicht übertreiben“  Budget „Budget ist… ${x}“ 8 Soll-Projekt-Ziele in manchen Projekten © p i x e l p a r k

9. ||  Umfang / Scope „Wir sind 80% fertig“  Zeitvorgaben „Wäre schon gut, wenn das noch vor dem Urlaub des Auftraggebers fertig wird.“  Qualität „Am Ende schauen wir noch einmal drüber“  Budget „Sieht rot aus. Aber es sind ja nur noch 20% zu tun.“ 9 Ist-Daten in manchen Projekten © p i x e l p a r k

10. ||  Team fehlt die Orientierung  Stress, Sorgen/Ängste, dauerhaft inakzeptabel  Keine Daten & Insights für Retrospektiven und Verbesserungen  Kein Überblick über mögliche Maßnahmen und Konsequenzen  Diskussionen nach Bauchgefühl  Intransparent, kein Commitment des Teams 10 Probleme beim Controlling ohne Daten © p i x e l p a r k

11. | Agilität braucht Projektcontrolling Projektcontrolling macht Spaß

12. ||  „You can't control what you can't measure“ (Tom DeMarco) *  Zahlen -> Prognosen  Zahlen schaffen Transparenz und Objektivität  Über Bauchgefühl kann man streiten, über Zahlen kann man reden * Quelle: http://en.wikiquote.org/wiki/Tom_DeMarco 12 Fakten, Fakten, Fakten – Zahlen, Zahlen, Zahlen © p i x e l p a r k

13. | Agenda 2 Gegenstand 13© p i x e l p a r k

14. ||  Zeit  Budget  Quality  Umfang / Scope 14 Gegenstand des Controllings © p i x e l p a r k

15. ||  SOLL: Deadline  IST: Jetzt  DIFF: Resttage := Deadline – Jetzt  Tools: Kalender 15 Controlling von Zeit © p i x e l p a r k

16. ||  SOLL ~ einzusetzende Manpower (m/w) *  IST ~ „verbrauchte“ Manpower  DIFF: Delta := IST - SOLL  Tools: Zeiterfassung (bei Multiprojekt-Management) oder Kalender * grob vereinfacht 16 Controlling von Budget © p i x e l p a r k

17. ||  SOLL: max. zulässige Abweichung von Kriterien 1..n  IST: erfüllt (ja/nein)  DIFF: Anzahl oder Umfang durchgefallene ToDos  Tools: Definition of Done Qualitätsmanagement Metriken Iterative „Abnahme“ durch Product Owner … 17 Controlling von Qualität © p i x e l p a r k

18. | In agilen Projekten ist Qualität eine Konstante „Continuous attention to technical excellence and good design enhances agility“ * * Agile manifesto, principle 9

19. ||  SOLL: Funktionalität (User Stories, Use Cases, etc) Gesamtumfang ToDos in „Punkten“ / geeigneter Einheit (≠ PT) (Story Points, Use Case Points, Test Points*, etc)  IST: Summe Punkte aller erledigter ToDos  DIFF: Delta := IST - SOLL  Tools: Definition of Done Iterative „Abnahme“ durch Product Owner * siehe auch Harry M. Sneed: Software in Zahlen, http://www.amazon.de/Software-Zahlen-Die-Vermessung-Applikationen/dp/3446421750 19 Controlling von Umfang © p i x e l p a r k

20. | Quelle: Geek & Poke von Oliver Widder „Definition of Done“ …nicht „Almost Done“

21. ||  Zeit Ziel-Termin vs. aktuelles Datum -> Resttage  Budget Personaleinsatz + X  Quality Sammelbegriff für zu definierende Einzelziele in agilen Projekten eine Konstante  Umfang / Scope Funktionalität (User Stories, Use Cases, etc) Umfang in geeigneter Einheit (Story Points, Funktion Points, etc) 21 Gegenstand fürs Controlling © p i x e l p a r k

22. ||  Zeit Ziel-Termin vs. aktuelles Datum -> Resttage  Budget Personaleinsatz + X  Quality Sammelbegriff für zu definierende Einzelziele in agilen Projekten eine Konstante  Umfang / Scope Funktionalität (User Stories, Use Cases, etc) Umfang in geeigneter Einheit (Story Points, Funktion Points, etc) 22 Relevanter Gegenstand des Controllings © p i x e l p a r k

23. | Agenda 3 Beispielprojekt 23© p i x e l p a r k

24. | Agenda 3.1. Briefing 24© p i x e l p a r k

25. ||  Software, die … kann, soll erstellt werden  Ausgangsschätzung: 1.000 Punkte Umfang  Start: 07.01.2013  Go Live 17.06.2013  Code Freeze: 27.05.2013  Scrum in 10 Sprints à 2 Wochen 25 Beispiel-Projekt „One-Two-Three-Four“ © p i x e l p a r k

26. || 26 Initiales Burnup © p i x e l p a r k

27. || 27 Beispiel: Reales (Sprint-)Burnup © p i x e l p a r k

28. || 28 Initiale Schätzung © p i x e l p a r k

29. || 29 Initiale Ressourcenplanung © p i x e l p a r k

30. || 30 Initiale Schätzung II © p i x e l p a r k

31. || 31 Initialer “Tilgungsplan” © p i x e l p a r k

32. || 32 Initiales Burnup Chart © p i x e l p a r k

33. | Planung fertig! Hey ho, let‘s go!

34. | Agenda 3.2. Sprint 1 34© p i x e l p a r k

35. || 35 Abschluss von Sprint 1 – Soll vs. Ist Zeit  Soll: 35,5 PT Manpower  Ist: 32,3  Diff: 3,2 PT  Ursache: Entwickler mussten bei anderem Projekt aushelfen © p i x e l p a r k

36. || 36 Abschluss von Sprint 1 – Soll vs. Ist Umfang  8 Punkte weniger umgesetzt als geplant  weniger Ressourceneinsatz  Velocity war um 0,1 besser als gedacht © p i x e l p a r k

37. || 37 Abschluss von Sprint 1 – Soll vs. Ist Budget  Ressourcenproblemen auch Vorteile: weniger angefallene Kosten (bisher) © p i x e l p a r k

38. || 38 Nach Sprint 1 aktualisierter “Tilgungsplan” © p i x e l p a r k

39. || 39 Abschluss von Sprint 1 – Chart  Immer noch auf Kurs © p i x e l p a r k

40. || 40 Zu erfassende Werte fürs Controlling Messwerte:  Verbrauchte Zeit -> Zeiterfassung (oder noch einfacher)  Umgesetzte Punkte -> Definition of Done, Demo und QS  Neue Gesamtpunktzahl Weitere Parameter:  Aktuelles Datum  Deadline  Verplante PT Ressourceneinsatz  Sprintlänge © p i x e l p a r k

41. | Fürs Controlling sind nur wenige Informationen notwendig …und unser Projekt läuft toll, oder?

42. | Agenda 3.3. Sprint 2 42© p i x e l p a r k

43. | Quelle: Geek & Poke von Oliver Widder Ach ja…

44. || Projektumfang wächst an, z.B. weil  Sprintplanung zeigt, dass ToDos vergessen wurden  Sprintplanung zeigt, dass Aufgaben doch aufwändiger sind als ursprünglich geschätzt  Der Kunde bringt Change Requests ein  Der Kunde will weitere Features  Theorie: andere Features entfallen, sodass am Ende die Gesamtsumme erhalten bleibt -> Es gibt kein Problem  Realität: Gesamtsumme steigt 44 Medic! © p i x e l p a r k

45. || 45 Szenario a: “Ausrutscher” © p i x e l p a r k Situation:  In den verbleibenden 8 Sprints sind 130 Punkte mehr umzusetzen als ursprünglich geplant Optionen:  Deadline & Budget einhalten ‚ -> 122 Punkte streichen  Deadline & Umfang einhalten -> 4,2 PT mehr Manpower pro Sprint  Deadline, Umfang & Budget einhalten -> Velocity auf 4,2 steigern (knapp 20%)  Umfang & Budget einhalten -> Deadline schieben

46. ||  Velocity entspricht der Entwicklungseffizienz  Effizienzsteigerungen sind immer gewünscht, kommen aber nicht aus dem Nichts  Durchschnittliche Produktivitätssteigerung der letzten 20 Jahre in der IT pro Jahr: 5% *  Im Projekt kaum realistisch -> Velocity sollte als Konstante angenommen werden  Übliche alternative Konsequenz: Qualitätseinbußen -> Aufbau „technischer Schulden“ -> Probleme spätestens in der Produktion und im Maintenance * Harry M. Sneed: Software in Zahlen, http://www.amazon.de/Software-Zahlen-Die-Vermessung-Applikationen/dp/3446421750 46 Option 1: Velocity steigern a.k.a. „Gas geben“ © p i x e l p a r k

47. ||  Neue Mitarbeiter in ein laufendes Projekt einführen funktioniert meist nicht (oder nicht effizient) „Adding manpower to a late software project makes it later“ (Fred Brooks)  Alternative in der Praxis: Überstunden Funktioniert kurzfristig, wenn nur für kurze Zeit und im „normalen“ Rahmen Problematisch, wenn Dauerzustand oder „Todesmarsch“ Prinzip 8: „Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely“ 47 Option 2: Mehr Manpower © p i x e l p a r k

48. ||  Auf den 1. Blick verführerisch Hat schon Manchen gerettet…  Problem für Ressourcenmanager / Planung anderer Projekte  Problematisch, wenn wiederholt verschoben wird -> Großer Impact auf Motivation -> Burn Out Treiber 48 Option 3: Deadline schieben © p i x e l p a r k

49. ||  Nach wie vor der Königsweg  Erfordert Verhandlungsgeschick  Die Wortwahl macht‘s: Features SCHIEBEN (in Folgerelease) statt „streichen“ 49 Option 4: Features streichen © p i x e l p a r k

50. || 50 Optionen transparent und quantifiziert © p i x e l p a r k Erst durch das agile Projekt-Controlling werden die Optionen quantifizierbar! siehe Ziel „Bewerten der Konsequenzen und Vorschlagen von Korrekturmaßnahmen“

51. || 51 Szenario b: “Inflation” © p i x e l p a r k Situation:  In den verbleibenden 8 Sprints kommen immer wieder im Schnitt 65 Punkte hinzu Optionen:  ?

54. || 54 Szenario b: “Inflation” © p i x e l p a r k Situation:  In den verbleibenden 8 Sprints kommen immer wieder im Schnitt 65 Punkte hinzu Optionen:

55. | „Welcome changing requirements, even late in the project.“ Geht aber nur, wenn die Spielregeln eingehalten werden… * Agile manifesto, principle 2

57. || 57 Echtes Projektbeispiel © p i x e l p a r k  Auch wir kochen nur mit Wasser -> nur ein Grund mehr, ernsthaftes Projekt-Controlling zu betreiben und permanent zu verbessern

58. || 58 DOs & DONTs aus der Praxis  Rechnen Sie mit Inflation aus internen Gründen  Immer nur nach DoD abgeschlossene Tasks erfassen  ToDos ohne besondere Kenntnisse und Fähigkeiten testbar machen  Werte glätten über Durchschnitte (z.B. immer letzte 3 Sprints heranziehen)  Standard Abweichung beachten, denn Schwankungen haben Ursachen  Scrum Master einbeziehen  Velocity nicht zur (Einzel-)Mitarbeiter-Beurteilung missbrauchen! Widerspricht agiler Denkweise führt zu Reaktanz hat (in Deutschland) rechtliche Implikationen Gezeigte Controllingverfahren funktioniert NICHT  bei Abschätzungen in PT  bei zu kleinen Datenmengen (Miniprojekt, etc)  bei Supportprojekten © p i x e l p a r k

60. || Sicherung des Erreichens der Projektziele durch:  Soll-Ist-Vergleich  Feststellung der Abweichungen  Bewerten der Konsequenzen und Vorschlagen von Korrekturmaßnahmen  Mitwirkung bei der Maßnahmenplanung und Kontrolle der Durchführung Quelle: http://de.wikipedia.org/wiki/Projektcontrolling 60 Fazit © p i x e l p a r k    ()

61. || 61 Ausblick  Kombination mit Messgrößen aus Kanban (für Support-Projekte)  Kombination mit Six Sigma (zur Abschätzung von Wahrscheinlichkeiten)  Integration mit oder in JIRA  Weitere Verifikation / Falsifikation in der Praxis © p i x e l p a r k

62. Vielen Dank für Ihre Aufmerksamkeit. Haben Sie noch Fragen? Berlin, 17.10.2012

63. || Die in dieser Präsentation erarbeiteten Gedanken und Vorschläge sind geistiges Eigentum der Pixelpark AG und unterliegen dem geltenden Urheberrecht. Die ganze oder teilweise Vervielfältigung sowie jede Weitergabe an Dritte ist ohne schriftliche Genehmigung der Pixelpark AG nicht gestattet. Andreas Czakaj IT Director Pixelpark AG Cäcilienkloster 2 D-50676 Köln Tel: +49.221.951515-0 Fax: +49.221.951515-66 andreas.czakaj@pixelpark.com www.pixelpark.com 63 Impressum © p i x e l p a r k

64. || geek&poke (http://geekandpoke.typepad.com/) von Oliver Widder Verwendung nach Creative Commons ShareAlike 3.0 (CC BY-SA 3.0) Four Horsemen of Apocalypse von Viktor Vasnetsov (1848-1926) Verwendung nach Public Domain 64 Quellenangaben nach Creative Commons © p i x e l p a r k

Agiles Projekt-Controlling

You are reading a preview.

Check these out next

Agiles Projekt-Controlling

More Related Content

Similar to Agiles Projekt-Controlling (20)

Recently uploaded (20)