Das Dokument befasst sich mit agilem Projektcontrolling und der Notwendigkeit von Daten zur effizienten Steuerung von Projekten. Es werden Herausforderungen und Lösungen in Bezug auf Zeit, Budget, Qualität und Umfang in agilen Projekten vorgestellt. Zudem werden Methoden zur kontinuierlichen Verbesserung und zum Umgang mit veränderlichen Anforderungen erläutert.

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:
 ?

52. || 52
Abschluss von Sprint 2 – Tilgungsplan
© p i x e l p a r k

53. || 53
Abschluss von Sprint 2 – Chart
 Ups…
© p i x e l p a r k

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

56. |
Agenda
4. Praxis
56© p i x e l p a r k

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

59. |
Agenda
5. Fazit, Ausblick
59© 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