Traditionelles Projektmanagement und SCRUM
Upcoming SlideShare
Loading in...5
×
 

Traditionelles Projektmanagement und SCRUM

on

  • 3,055 views

Mehrjährige Beobachtungen beim Einsatz agiler Methoden unter schwierigen Bedingungen haben gezeigt, dass Praktiken aus dem klassischen Projektmanagement nach IPMA oder PMI in Organisationen mit einer ...

Mehrjährige Beobachtungen beim Einsatz agiler Methoden unter schwierigen Bedingungen haben gezeigt, dass Praktiken aus dem klassischen Projektmanagement nach IPMA oder PMI in Organisationen mit einer agilen Entwicklungsabteilung weiterhin einen großen Mehrwert liefern können, um Projekte erfolgreich abzuschließen.

Dieser Vortrag beleuchtet die Vorteile und Schwächen von agilen und klassischen Methoden in der Praxis und zeigt, wie die Kombination von agilen Methoden mit Praktiken aus dem traditionellen Projektmanagement die Erfolgswahrscheinlichkeit von Projekten erhöht.

Dies ist besonders für die Fälle relevant, in denen die Organisation nicht alle die Rahmenbedingungen bieten kann, die für agile Prozesse ideal wären.

Statistics

Views

Total Views
3,055
Views on SlideShare
3,055
Embed Views
0

Actions

Likes
0
Downloads
59
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Traditionelles Projektmanagement und SCRUM Traditionelles Projektmanagement und SCRUM Presentation Transcript

  • Felix Rüssel, Scrum-Day 2011, September 2011, Darmstadt 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  Blog: www.armerkater.de  Twitter: armerkater  Mail: felix.ruessel@agile-rescue.com28.09.2011 Felix Rüssel, Scrum Day 2011 2
  • Warum dieser Vortrag?• Immer wieder erlebt – Ineffizientes Projektmanagement – Frustrierte agile Teams• Warum? – Bürokratie – Kontext nicht verstanden – Das WARUM nicht verstanden – Die eigenen Möglichkeiten überschätzt – „Wir“ gegen „Die“28.09.2011 Felix Rüssel, Scrum Day 2011 3
  • SCRUM & PROJEKTMANAGEMENT Kontext beachten Beispiele & Erfahrungen Zusammenfassung28.09.2011 Felix Rüssel, Scrum Day 2011 4
  • 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 != Wasserfall28.09.2011 Felix Rüssel, Scrum Day 2011 5
  • Anmerkungen zum PMBoK9 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 Check28.09.2011 Felix Rüssel, Scrum Day 2011 6
  • 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äftswert28.09.2011 Felix Rüssel, Scrum Day 2011 7
  • Projektmanagement: Stärken• Status Quo / Rechtssicherheit• Determinismus – Dokumentation/Nachvollziehbarkeit – Management von komplizierten Systemen• Umfassend: Vieler Themen (Risiken, Recht, Vertragsmanagement, …) abgedeckt.• Etablierte Begrifflichkeiten• Management liebt gefühlte „Sicherheit“ (Zahlen)• Vereinbarkeit Linie & Projekt thematisiert• Fokus auf Kostenkontrolle28.09.2011 Felix Rüssel, Scrum Day 2011 8
  • 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 PROJEKTmanagement28.09.2011 Felix Rüssel, Scrum Day 2011 9
  • 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äftswert28.09.2011 Felix Rüssel, Scrum Day 2011 10
  • Einfacher VergleichSCRUM 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,Plan28.09.2011 Felix Rüssel, Scrum Day 2011 11
  • SCRUM & Projektmanagement KONTEXT BEACHTEN Beispiele & Erfahrungen Zusammenfassung28.09.2011 Felix Rüssel, Scrum Day 2011 13
  • 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änderung28.09.2011 Felix Rüssel, Scrum Day 2011 14
  • 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 Personen28.09.2011 Felix Rüssel, Scrum Day 2011 15
  • 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 Personen28.09.2011 Felix Rüssel, Scrum Day 2011 16
  • Agreement & Certainty Matrix Far from agreement Requirements Complexity chaotic Close to simple agreement Technology complexity Close to Far from certainty certainty28.09.2011 Felix Rüssel, Scrum Day 2011 17
  • Spezifische Herausforderung: Sprache des Auftraggebers sprechen Budgetierung Kunde Finanzen Festpreis Personal Projektmanagement Entwicklung SCRUM Teams28.09.2011 Felix Rüssel, Scrum Day 2011 18
  • SCRUM & Projektmanagement Kontext beachten BEISPIELE & ERFAHRUNGEN Zusammenfassung28.09.2011 Felix Rüssel, Scrum Day 2011 19
  • 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)28.09.2011 Felix Rüssel, Scrum Day 2011 20
  • Das Geister-ProjektHerausforderung• Projekt beschäftigt Teams aber echter Owner fehlt• Projektleiter wurde abgeschafft („in SCRUM gibt es keine PL“)• Kontext: Multi-Project-ScrumHerangehensweise• PO muss konsequent Themen ohne echte „Owner“ abweisen• Agilen Projektleiter benennenErfahrungen• Senior-Management / Sales ersetzt PL nicht• Mit PL: Ansprechpartner für PO existiert, Fokus wiederhergestellt28.09.2011 Felix Rüssel, Scrum Day 2011 21
  • Multi-Project-ScrumHerausforderung• Ein SCRUM Team mit mehreren Projekten• Ein Projekt in mehreren SCRUM-TeamsHerangehensweise• Abstimmung Projektleiter/PO• Abstimmung POs über Teams und Themen hinweg• Product Backlog als langfristige RoadmapErfahrungen• Schwierig. Reibungsverluste! Wer entscheidet? Kommunikation! Lokale Optimierung! Abhängigkeiten!• Multitasking: Fokus & Produktivität gehen verloren.28.09.2011 Felix Rüssel, Scrum Day 2011 22
  • Ohne Fokus kein Committment, ohne Committment und Respekt keine Offenheit. Transparenz? Produktivität?28.09.2011 Felix Rüssel, Scrum Day 2011 23
  • FestpreisHerausforderung• 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 & ProjektmanagementErfahrungen• 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.28.09.2011 Felix Rüssel, Scrum Day 2011 24
  • Werkvertrag & ÄnderungenÄnderungsmanagement juristisch: – Jede Änderung ist Vertragsänderung – Dokumentation erforderlichZu klären im Vorfeld: – Pflicht zur Annahme von Änderungen? – Wer unterbreitet Angebot? – Was passiert, wenn Angebot nicht angenommen wird? – ….28.09.2011 Felix Rüssel, Scrum Day 2011 25
  • Festpreis-Projekte• Vorteile für Auftraggeber • Wichtigste Punkte zuerst • Schnell echte Ergebnisse • Vereinfachter CR-Prozess bei offenen Stories28.09.2011 Felix Rüssel, Scrum Day 2011 26
  • Produktbacklog als langfristige RoadmapHerausforderung• 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. Planung28.09.2011 Felix Rüssel, Scrum Day 2011 27
  • 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)28.09.2011 Felix Rüssel, Scrum Day 2011 28
  • Vorausplanung: Abhängigkeiten aufzeigen Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 (aktuell)Team 1Team 2Team 328.09.2011 Felix Rüssel, Scrum Day 2011 29
  • 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!28.09.2011 Felix Rüssel, Scrum Day 2011 30
  • 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, Details28.09.2011 Felix Rüssel, Scrum Day 2011 31
  • Story Points 2.1Herausforderung• Schnelle Grobschätzung wird benötigt• Hohe Unsicherheit, Stories nicht wirklich bekanntHerangehensweise• SCHNELL-Schätzungen durch Team• Schätzungen durch NICHT-Team• Indikator „x.1“ verdeutlicht UngenauigkeitErfahrungen• 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.28.09.2011 Felix Rüssel, Scrum Day 2011 32
  • Velocity~Personentage~EURHerausforderung• Personentage/EUR als Währung innerhalb einer Organisation• Grobplanung kommende SprintsHerangehensweise• Zeitaufwand (h), gemittelte Kosten (EUR), Ergebnis (SP) werden in Verhältnis gesetzt• Wert eines SP in h/EUR für ein TeamErfahrungen• Sehr hilfreich für Vorausplanung (Urlaub, Schulungen). Aber nur Indikator, nicht Gesetz.• Diskussion um „fast fertig“ gewinnt an Brisanz• Veränderung über Zeit interessant28.09.2011 Felix Rüssel, Scrum Day 2011 33
  • Product OwnerHerausforderung• Single Wrinkable Neck. Responsible. Super Human!• Komplexität, Unsicherheit, Geld, Politik, MachtHerangehensweise• 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.28.09.2011 Felix Rüssel, Scrum Day 2011 34
  • Product OwnerDean 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/28.09.2011 Felix Rüssel, Scrum Day 2011 35
  • SCRUM & Projektmanagement Kontext beachten Beispiele & Erfahrungen ZUSAMMENFASSUNG28.09.2011 Felix Rüssel, Scrum Day 2011 36
  • ZusammenfassungDer Prozess muss zum Kontext passen• Anforderungen an den Prozess• Prozessverständnis beim AuftraggeberPrü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? Projektmanagement28.09.2011 Felix Rüssel, Scrum Day 2011 37
  • Zusammenfassung• Traditionelles PM und SCRUM können auf operativer Ebene zusammen eingesetzt werden – Beide Welten müssen verstanden werden – Agiles Projektmanagement• Risiko: Frankenstein-SCRUM• Auf Ebene der Werte sind SCRUM und PM teilweise im Zielkonflikt28.09.2011 Felix Rüssel, Scrum Day 2011 38
  • ReferenzenInteressante Bücherhttp://astore.amazon.de/scrumprojektmanagement-21Gute Präsentation mit detailliertem Vergleich:Gfrörer: Agil & PMBOK-konform – das passtdoch nicht zusammen, oder doch?http://www.andrena.de/Entwicklertag/2009/Downloads/Conference-Day/Agil-PMBOK.pdf28.09.2011 Felix Rüssel, Scrum Day 2011 39
  • Kontakt www.agile-rescue.com www.agile-nearshoring.com www.armerkater.de felix.ruessel@agile-rescue.com28.09.2011 Felix Rüssel, Scrum Day 2011 40