pm und scrum - vortrag pmi fc 10.10.2011

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

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

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

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

SCRUM & PROJEKTMANAGEMENT

10.10.2011 Felix Rüssel, PMIFC 10/2011 5

Kontext beachten

Beispiele & Erfahrungen

Zusammenfassung

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

Anmerkungen zum PMBoK

9 PMBOK Knowledge Areas

– Project Integration Management

– Project Scope Management

– Project Time Management

– Project Cost Management

– Project Quality Management

– Project Human Resource Management

– Project Communications Management

– Project Risk Management

– Project Procurement Management

5 Process Groups – Initiating – Planning – Executing – Monitoring and

Controlling – Closing

10.10.2011 Felix Rüssel, PMIFC 10/2011 7

Plan

DO

Check

Act

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

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.2011 Felix Rüssel, PMIFC 10/2011 10

SCRUM

RE

AD

Y

DO

NE

PBL SBL Increment

imp

ed

ime

nt

DoR IBL DoD

10.10.2011 Felix Rüssel, PMIFC 10/2011 11

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

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

Einfacher Vergleich

SCRUM • Werte, Mindset, Framework • Komplexe Systeme • Einfache Regeln • Schnelle Realisierung • Schnelles Feedback • Schnelle Anpassung • Strategie kleiner Schritte • Technische Exzellenz nötig • Umsetzung mit Generalisten • Adaptive Planung

– Änderungen günstig

• Wert,Transparenz,Anpassung

Traditionelles PM • Sammlung Best Practices • Deterministische Systeme • Umfangreiche Elemente • Detaillierte Dokumentation • Controlling/Reporting • Vorhersagen, Kalkulation • Management großer Pakete • Arbeitet gern mit Standards • Umsetzung mit Spezialisten • Umsetzung eines Plans

– Änderungen teuer

• Kosten,Kontrolle,Plan

10.10.2011 Felix Rüssel, PMIFC 10/2011 14

KONTEXT BEACHTEN SCRUM & Projektmanagement

10.10.2011 Felix Rüssel, PMIFC 10/2011 16

Beispiele & Erfahrungen

Zusammenfassung

Wie agil ist der Kontext?

Individuen und Interaktionen

Funktionierende Software

Zusammenarbeit mit dem Kunden

Reagieren auf Veränderung

Prozesse und Werkzeuge

umfassende Dokumentation

Vertragsverhandlung

Befolgen eines Plans

Agile Traditionelles Projektmanagement

10.10.2011 Felix Rüssel, PMIFC 10/2011 17

Cockburn Scale

Loss of Live

L L6 L20 L40 L100

Loss of Essential Money

E E6 E20 E40 E100

Loss of Discretionary Money

D D6 D20 D40 D100

Loss of Comfort

C C6 C20 C40 C100

1-6 -20 -40 -100

10.10.2011 Felix Rüssel, PMIFC 10/2011 18

Anzahl zu koordinierender Personen

Ris

iko

klas

se

Cockburn Scale

Loss of Live

L L6 L20 L40 L100

Loss of Essential Money

E E6 E20 E40 E100

Loss of Discretionary Money

D D6 D20 D40 D100

Loss of Comfort

C C6 C20 C40 C100

1-6 -20 -40 -100

10.10.2011 Felix Rüssel, PMIFC 10/2011 19

Anzahl zu koordinierender Personen

Ris

iko

klas

se

Agreement & Certainty Matrix

10.10.2011

Felix Rüssel, PMIFC 10/2011 20

simple

chaotic

Close to certainty

Far from certainty

Close to agreement

Far from agreement

Re

qu

ire

me

nts

Co

mp

lex

ity

Technology complexity

Projektmanagement

Spezifische Herausforderung: Sprache des Auftraggebers sprechen

Budgetierung Finanzen Personal

Kunde Festpreis

Entwicklung SCRUM Teams

10.10.2011 Felix Rüssel, PMIFC 10/2011 21

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.

10.10.2011 Felix Rüssel, PMIFC 10/2011 22

http://www.forbes.com/sites/stevedenning/2011/04/29/scrum-is-a-major-management-discovery/

BEISPIELE & ERFAHRUNGEN

SCRUM & Projektmanagement

Kontext beachten

10.10.2011 Felix Rüssel, PMIFC 10/2011 23

Zusammenfassung

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

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

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

Ohne Fokus kein Committment, ohne Committment und Respekt keine Offenheit.

Transparenz? Produktivität?

10.10.2011 Felix Rüssel, PMIFC 10/2011 27

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

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

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

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

Sprint (Stories, Tasks)

READY

Preparing (Epics -> Stories)

Planned Topics

(Ideas, Epics, Themes)

10.10.2011 Felix Rüssel, PMIFC 10/2011 32

Sprint (Stories, Tasks)

READY

Preparing (Epics -> Stories)

Planned Topics

(Ideas, Epics, Themes)

Sprint (Stories, Tasks)

READY

Preparing (Epics -> Stories)

Planned Topics

(Ideas, Epics, Themes)

Vorausplanung: Abhängigkeiten aufzeigen

Team 1

Team 2

Team 3

Sprint 1 (aktuell)

Sprint 2 Sprint 3 Sprint 4 Sprint 5

10.10.2011 Felix Rüssel, PMIFC 10/2011 33

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

Make it READY

Sprint Planning

RE

AD

Y

Co

mm

itte

d

Sp

rin

t B

ack

log

Story Story

Details Details Details, Details, Details

Details

Epic

Story Story

Story

Story

Story

Story Template

Add Details Discuss! Discuss! Discuss!

10.10.2011 Felix Rüssel, PMIFC 10/2011 35

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

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

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

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

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

10.10.2011 Felix Rüssel, PMIFC 10/2011 41

ZUSAMMENFASSUNG

SCRUM & Projektmanagement

Kontext beachten

Beispiele & Erfahrungen

10.10.2011 Felix Rüssel, PMIFC 10/2011 42

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

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

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

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