SCRUM und Projektmanagement

1. Felix Rüssel, PMI Chapter Frankfurt, Oktober 2011, Mannheim
felix.ruessel@agile-rescue.com // www.agile-rescue.com

2. Wer?
 Informatiker & Wirtschaftsingenieur
(Marketing/Vertrieb)
 SCRUM Master, SCRUM Product Owner,
Scrum Consultant
 Projektleiter agile/traditionell
 Web: www.agile-rescue.com
 Web: www.agile-nearshoring.com
 Blog: www.armerkater.de
 Twitter: armerkater
 Mail: felix.ruessel@agile-rescue.com
10.10.2011 Felix Rüssel, PMIFC 10/2011 2

3. Warum dieser Vortrag?
• Immer wieder erlebt
– Ineffizientes Projektmanagement
– Frustrierte agile Teams
„Wir“ gegen „Die“
• Warum?
– Bürokratie
– Das WARUM nicht verstanden
– Kontext nicht verstanden
– Die eigenen Möglichkeiten überschätzt
10.10.2011 Felix Rüssel, PMIFC 10/2011 3

4. Out of Scope
• Detaillierte Abbildung von PMBoK
Knowledge Areas auf SCRUM
– Verweis auf Literatur & Präsentationen
• PMI-ACP
– Noch keine Meinung gebildet
• Agile Project Management im Detail
– Nicht im PPT aber gerne in Q&A Session
10.10.2011 Felix Rüssel, PMIFC 10/2011 4

5. SCRUM & PROJEKTMANAGEMENT
Kontext beachten
Beispiele & Erfahrungen
Zusammenfassung
10.10.2011 Felix Rüssel, PMIFC 10/2011 5

6. Anmerkungen zum PMBoK
• PMBoK = Project Management Body of
Knowledge
– Best Practices für das Projektmanagement
– Adaptiv: Inhalte ändern sich mit der Zeit, genau
wie sich das Projektmanagement über die Zeit
verändert
– Projektmanagement allgemein– nicht nur IT
• PMBoK ist kein Prozessmodell
• PMBoK != Wasserfall
10.10.2011 Felix Rüssel, PMIFC 10/2011 6

7. Anmerkungen zum PMBoK
9 PMBOK Knowledge Areas 5 Process Groups
– Project Integration Management – Initiating
– Project Scope Management – Planning
– Project Time Management – Executing
– Project Cost Management
– Monitoring and
Controlling
– Project Quality Management – Closing
– Project Human Resource
Management Plan
– Project Communications
Management
– Project Risk Management
Act DO
– Project Procurement
Management Check
10.10.2011 Felix Rüssel, PMIFC 10/2011 7

8. Projektmanagement: Häufige Kritik
• „Nur schlechte Erfahrungen gemacht“
• Kompliziert und aufwändig in der Anwendung, aufwändig zu
lernen (zu viel Bürokratie)
• Hang zu Command & Control, Management by Numbers
– Projektplan  GANTT mit technischen Tasks
– Plan veraltet
• Mangelhafte Interaktion mit Kunden
• Intransparenz: Zahlen verschleiern Realität, Big Bang!
• Menschen sind nur Ressourcen
• Todesmarsch ab Mitte des Projektes
• Keine Anpassungen, da Änderungsmanagement sehr aufwändig
• Verwaltung, nicht Werte schaffen.
• Fokus nur auf Kosten, nicht auf erzeugten Geschäftswert
10.10.2011 Felix Rüssel, PMIFC 10/2011 8

9. Projektmanagement: Stärken
• Status Quo / Rechtssicherheit
• Nachvollziehbarkeit
– Dokumentation
• Management von komplizierten Systemen
• Umfassend: Viele Themen (Risiken, Recht,
Vertragsmanagement, …) abgedeckt.
• Etablierte Begrifflichkeiten
• Management liebt gefühlte „Sicherheit“ (Zahlen)
• Vereinbarkeit Linie & Projekt thematisiert
• Fokus auf Kostenkontrolle
10.10.2011 Felix Rüssel, PMIFC 10/2011 9

10. 10.10.2011 Felix Rüssel, PMIFC 10/2011 10

11. SCRUM
impediment
READY
DONE
Incre
PBL DoR SBL IBL DoD ment
10.10.2011 Felix Rüssel, PMIFC 10/2011 11

12. SCRUM: Häufige Kritik
• Große Veränderung, Anforderungen an Rahmenbedingungen
– Auswirkung auf Linie, Machtkämpfe
• Rechtliche Fragestellungen sind bisher nicht ausreichend
untersucht. Herausforderung „Mitwirkung Kunde“
• Product Owner als Soll-Bruchstelle
• Funktioniert nicht mit Festpreis-Projekten
• Generalisten funktionieren bei uns nicht
• Selbstorganisation nur mit erfahrenem Team.
• Zu kurze Iterationen, zu viele Meetings, zu wenig produktive Zeit
• SCRUM funktioniert nur, wenn alles und jeder SCRUM machen
• Selbstorganisation und Architektur?
• Sehr gutes Engineering Voraussetzungen. Altlasten ein großes
Problem.
• Kein PROJEKTmanagement
10.10.2011 Felix Rüssel, PMIFC 10/2011 12

13. SCRUM: Stärken
• Mindset (Agile)
• Framework zum Management komplexer adaptiver
Systeme
• Einfache Grundstruktur, konkrete Vorgaben
• Kontinuierliche Prozessverbesserung
• Selbstorganisation
– Intensive Interaktion: Team, Kunde, Stakeholder
– Menschen nicht nur Ressourcen
• Transparenz, Adaptiv
– „Fail early“
• Erzeugung von Geschäftswert
10.10.2011 Felix Rüssel, PMIFC 10/2011 13

14. Einfacher Vergleich
SCRUM Traditionelles PM
• Werte, Mindset, Framework • Sammlung Best Practices
• Komplexe Systeme • Deterministische Systeme
• Einfache Regeln • Umfangreiche Elemente
• Schnelle Realisierung • Detaillierte Dokumentation
• Schnelles Feedback • Controlling/Reporting
• Schnelle Anpassung • Vorhersagen, Kalkulation
• Strategie kleiner Schritte • Management großer Pakete
• Technische Exzellenz nötig • Arbeitet gern mit Standards
• Umsetzung mit Generalisten • Umsetzung mit Spezialisten
• Adaptive Planung • Umsetzung eines Plans
– Änderungen günstig – Änderungen teuer
• Wert,Transparenz,Anpassung • Kosten,Kontrolle,Plan
10.10.2011 Felix Rüssel, PMIFC 10/2011 14

16. SCRUM & Projektmanagement
KONTEXT BEACHTEN
Beispiele & Erfahrungen
Zusammenfassung
10.10.2011 Felix Rüssel, PMIFC 10/2011 16

17. Wie agil ist der Kontext?
Agile Traditionelles Projektmanagement
Individuen und Prozesse und
Interaktionen Werkzeuge
Funktionierende umfassende
Software Dokumentation
Zusammenarbeit mit
Vertragsverhandlung
dem Kunden
Reagieren auf
Befolgen eines Plans
Veränderung
10.10.2011 Felix Rüssel, PMIFC 10/2011 17

18. Cockburn Scale
Loss of Live
L L6 L20 L40 L100
Risikoklasse
Loss of Essential
Money E E6 E20 E40 E100
Loss of
Discretionary D D6 D20 D40 D100
Money
Loss of Comfort
C C6 C20 C40 C100
1-6 -20 -40 -100
Anzahl zu koordinierender Personen
10.10.2011 Felix Rüssel, PMIFC 10/2011 18

19. Cockburn Scale
Loss of Live
L L6 L20 L40 L100
Risikoklasse
Loss of Essential
Money E E6 E20 E40 E100
Loss of
Discretionary D D6 D20 D40 D100
Money
Loss of Comfort
C C6 C20 C40 C100
1-6 -20 -40 -100
Anzahl zu koordinierender Personen
10.10.2011 Felix Rüssel, PMIFC 10/2011 19

20. Agreement & Certainty Matrix
Far from
agreement Requirements Complexity
chaotic
Close to simple
agreement
Technology complexity
Close to Far from
certainty certainty
10.10.2011
Felix Rüssel, PMIFC 10/2011 20

21. Spezifische Herausforderung:
Sprache des Auftraggebers sprechen
Budgetierung Kunde
Finanzen Festpreis
Personal
Projektmanagement
Entwicklung
SCRUM Teams
10.10.2011 Felix Rüssel, PMIFC 10/2011 21

22. Warnung! 70% alle SCRUM Einführungen
erfüllen nicht die Erwartungen
Steven Denning / Forbes
• More than 70% of Scrum implementations have
failed to achieve their goals.
• When you try to embed Scrum as a project
management framework within a larger setting
of a traditional management of hierarchical
bureaucracy, there are inevitable tensions.
• Usually the prevailing culture of hierarchical
bureaucracy is triumphant.
http://www.forbes.com/sites/stevedenning/2011/04/29/scrum-is-a-major-management-discovery/
10.10.2011 Felix Rüssel, PMIFC 10/2011 22

23. SCRUM & Projektmanagement
Kontext beachten
BEISPIELE & ERFAHRUNGEN
Zusammenfassung
10.10.2011 Felix Rüssel, PMIFC 10/2011 23

24. Kontext für die Beispiele
• Interne IT: Agile Prozesse / SCRUM
– Aber „Multi-Project-Scrum“
• Extern: Festpreisverträge, Konsortien
– Öffentliche Auftraggeber (EU, Bund, Länder)
– Konzernkunden, Mittelstand
• Rolle/Aufgabe: Konkretes Projekt
– Projektleiter (Außenwirkung)
– Scrum Product Owner (Innenwirkung)
– (Scrum Master)
10.10.2011 Felix Rüssel, PMIFC 10/2011 24

25. Das Geister-Projekt
Herausforderung
• Projekt beschäftigt Teams aber echter Owner fehlt
• Projektleiter wurde abgeschafft („in SCRUM gibt es keine
Projektleiter“)
• Kontext: Multi-Project-Scrum
Herangehensweise
• PO muss konsequent Themen ohne echte „Owner“
abweisen
• Agilen Projektleiter benennen
Erfahrungen
• Senior-Management / Sales ersetzt PL nicht
• Mit PL: Ansprechpartner für PO existiert, Fokus
wiederhergestellt
10.10.2011 Felix Rüssel, PMIFC 10/2011 25

26. Multi-Project-Scrum
Herausforderung
• Ein SCRUM Team mit mehreren Projekten
• Ein Projekt in mehreren SCRUM-Teams
Herangehensweise
• Abstimmung Projektleiter/PO
• Abstimmung POs über Teams und Themen hinweg
• Product Backlog als langfristige Roadmap
Erfahrungen
• Schwierig. Reibungsverluste! Wer entscheidet?
Kommunikation! Lokale Optimierung!
Abhängigkeiten!
• Multitasking: Fokus & Produktivität gehen verloren.
10.10.2011 Felix Rüssel, PMIFC 10/2011 26

27. Ohne Fokus kein Committment, ohne
Committment und Respekt keine Offenheit.
Transparenz?
Produktivität?
10.10.2011 Felix Rüssel, PMIFC 10/2011 27

28. Festpreis
Herausforderung
• Festpreisvertrag
• „Oh, but surely you understood that {some feature or process}
is part of what we asked for.“
Herangehensweise
• Ausschreibung > Initial PBL > Schätzungen (SP2.1) > Angebot
• Längerfristiges Product Backlog & Projektmanagement
Erfahrungen
• Funktioniert ausreichend gut, wenn Ungenauigkeit eingepreist
ist.
• Risiken:
– Festpreis per se, PM auf richtiger Flughöhe!
– „Inventory“: Risiko für Wertverlust
– Vertragliche Risiken müssen verstanden werden, können Projekt
unattraktiv machen, wenn richtig bewertet.
10.10.2011 Felix Rüssel, PMIFC 10/2011 28

29. Werkvertrag & Änderungen
Änderungsmanagement juristisch:
– Jede Änderung ist Vertragsänderung
– Dokumentation erforderlich
Zu klären im Vorfeld:
– Pflicht zur Annahme von Änderungen?
– Wer unterbreitet Angebot?
– Was passiert, wenn Angebot nicht angenommen
wird?
– ….
10.10.2011 Felix Rüssel, PMIFC 10/2011 29

30. Festpreis-Projekte
• Vorteile für Auftraggeber
• Wichtigste Punkte zuerst
• Schnell echte Ergebnisse
• Vereinfachter CR-Prozess bei offenen Stories
10.10.2011 Felix Rüssel, PMIFC 10/2011 30

31. Produktbacklog als
langfristige Roadmap
Herausforderung
• Abstimmung über Teams hinweg (Abhängigkeiten)
• Feste Termine und Lieferzusagen(Festpreis & Multi-
Project-Scrum)
Herangehensweise
• Bestückung zukünftiger Sprints
• Weit in Zukunft: Features/Epics statt Stories
• Schätzung Aufwand & Kapazität (schnell/gut)
Erfahrungen
• Wichtige Diskussionsgrundlage, Abhängigkeiten gut
visualisierbar
• Großteil der Zukunft muss flexibel bleiben
• Risiko: Pull-Prinzip vs. Planung
10.10.2011 Felix Rüssel, PMIFC 10/2011 31

32. Sprint Sprint Sprint
(Stories, Tasks) (Stories, Tasks) (Stories, Tasks)
READY READY
READY
Preparing Preparing
(Epics -> Stories) (Epics -> Stories) Preparing
(Epics -> Stories)
Planned Topics Planned Topics Planned Topics
(Ideas, Epics, Themes) (Ideas, Epics, Themes) (Ideas, Epics, Themes)
10.10.2011 Felix Rüssel, PMIFC 10/2011 32

33. Vorausplanung:
Abhängigkeiten aufzeigen
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
(aktuell)
Team 1
Team 2
Team 3
10.10.2011 Felix Rüssel, PMIFC 10/2011 33

34. Vorausplanung & Pull
• Vorausplanung=Push: Zu starkes „Pushen“
ist eine Form des Wunschdenkens und
schädlich
• Ein bisschen „Pushen“ kann Teil eines Spiels sein.
• Sprint Planning=Pull: Team entscheidet über
Committment.
• Dieses Grundprinzip darf nicht verletzt werden!
10.10.2011 Felix Rüssel, PMIFC 10/2011 34

35. Make it READY
Story
Template
Add Details
Sprint Backlog
READY
Committed
Discuss! Discuss! Discuss! Sprint
Planning
Story
Epic
Story
Story Story
Story
Story
Story
Details Details Details
Details, Details, Details
10.10.2011 Felix Rüssel, PMIFC 10/2011 35

36. Story Points 2.1
Herausforderung
• Schnelle Grobschätzung wird benötigt
• Hohe Unsicherheit, Stories nicht wirklich bekannt
Herangehensweise
• SCHNELL-Schätzungen durch Team
• Schätzungen durch NICHT-Team
• Indikator „x.1“ verdeutlicht Ungenauigkeit
Erfahrungen
• Hilfreich für Grobschätzungen von Epics und unklaren
Stories. Wenn Story bekannt  Team Estimation Game!
• Risiko: Beeinflussung Team im echten Estimation. Gefühl
falscher Sicherheit.
10.10.2011 Felix Rüssel, PMIFC 10/2011 36

37. Velocity~Personentage~EUR
Herausforderung
• Personentage/EUR als Währung innerhalb einer
Organisation
• Grobplanung kommende Sprints
Herangehensweise
• Zeitaufwand (h), gemittelte Kosten (EUR), Ergebnis (SP)
werden in Verhältnis gesetzt
• Wert eines SP in h/EUR für ein Team
Erfahrungen
• Sehr hilfreich für Vorausplanung (Urlaub, Schulungen).
Aber nur Indikator, nicht Gesetz.
• Diskussion um „fast fertig“ gewinnt an Brisanz
• Veränderung über Zeit interessant
10.10.2011 Felix Rüssel, PMIFC 10/2011 37

38. Product Owner
Herausforderung
• Single Wrinkable Neck. Responsible. Super Human!
• Komplexität, Unsicherheit, Geld, Politik, Macht
Herangehensweise
• Unterstützung durch Projektleiter, Analysten, …
• Product Owner braucht Entscheidungsfreiheit
(Macht!)
Erfahrungen
• Echter PO benötigt Entscheidungsfreiheit.
Alternative sind verwaltende Stellvertreter. Wenig
attraktiv, aber häufigste Erscheinungsform.
10.10.2011 Felix Rüssel, PMIFC 10/2011 38

39. Product Owner
Dean Leffingwell:
• „That‘s a really big
deal because that also is
a person that makes decisions on behalf of the
enterprise“
• „It‘s pretty easy to under estimate the impact
and importance of that role and the
training that‘s required“
• „The Role of Product Owner is key.“
http://business901.com/blog1/the-lean-agile-train-software-transcription/
10.10.2011 Felix Rüssel, PMIFC 10/2011 39

40. Product Owner
Reason 5:
Scrum delivers ‘business value’. Well no, actually it doesn’t.
For many reasons. The guys or girls that know about
business are not going to be involved in your project.
They like to lunch with customers, not work on this weird
thing called backlog to explain a bunch of introvert nerdy
software developers what to do. So your team ends up
with a junior help desk employee as a product owner. And
besides, your whole ICT department is a cost center
anyhow. So don’t start about business value.
Maurits Rijk, Why Scrum will never work,
http://maurits.wordpress.com/2011/07/13/why-scrum-will-never-work/
10.10.2011 Felix Rüssel, PMIFC 10/2011 40

41. 10.10.2011 Felix Rüssel, PMIFC 10/2011 41

42. SCRUM & Projektmanagement
Kontext beachten
Beispiele & Erfahrungen
ZUSAMMENFASSUNG
10.10.2011 Felix Rüssel, PMIFC 10/2011 42

43. Zusammenfassung
Der Prozess muss zum Kontext passen
• Anforderungen an den Prozess
• Prozessverständnis beim Auftraggeber
Prüfe Rahmenbedingung & Erwartungen:
• Was kannst Du beeinflussen?
• Quellen von Komplexität und Risiken?
Verstehe Deine Rolle:
• Fokus auf Team/Organisation, Ziel: Steigerung
Produktivität? SCRUM
• Ein Projekt im Fokus? Festpreisvertrag?
Projektmanagement
10.10.2011 Felix Rüssel, PMIFC 10/2011 43

44. Zusammenfassung
• Traditionelles PM und SCRUM können auf
operativer Ebene zusammen eingesetzt werden
– Beide Welten müssen verstanden werden
– Agiles Projektmanagement
• Risiken
– Frankenstein-SCRUM / SCRUM-ZOO
– SCRUM kann Erwartungen nicht erfüllen
• Auf Ebene der Werte sind SCRUM und PM im
Zielkonflikt
10.10.2011 Felix Rüssel, PMIFC 10/2011 44

45. Referenzen
Bücher zur Präsentation
http://astore.amazon.de/scrumprojektmanagement-21
Weitere Bücher zu SCRUM
http://astore.amazon.de/armerkde-21
Gute Präsentation mit detailliertem Vergleich:
Gfrörer: Agil & PMBOK-konform – das passt doch nicht
zusammen, oder doch?
http://www.andrena.de/Entwicklertag/2009/Downloads/Conference-Day/Agil-
PMBOK.pdf
SCRUM Is A Major Management Discovery
http://www.forbes.com/sites/stevedenning/2011/04/29/scrum-is-a-major-
management-discovery/
10.10.2011 Felix Rüssel, PMIFC 10/2011 45

46. Kontakt
 www.agile-rescue.com
 www.agile-nearshoring.com
 www.armerkater.de
 felix.ruessel@agile-rescue.com
10.10.2011 Felix Rüssel, PMIFC 10/2011 46