zwei erfolgsmodelle mit den gleichen wurzeln gpm ... · training, coaching, supervision themen:...
TRANSCRIPT
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
Scrum und CCPM+
zwei Erfolgsmodelle mit den gleichen Wurzeln
GPM Düsseldorf, 11.01.2010
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
2
The Standish Group's just-released report, "CHAOS Summary 2009," "This year's
results show a marked decrease in project success rates, with 32% of all projects
succeeding which are delivered on time, on budget, with required features and
functions" says Jim Johnson, chairman of The Standish Group, "44% were challenged
which are late, over budget, and/or with less than the required features and functions
and 24% failed which are cancelled prior to completion or delivered and never used."
"These numbers represent a downtick in the success rates from the previous study,
as well as a significant increase in the number of failures", says Jim Crear, Standish
Group CIO, "They are low point in the last five study periods. This year's results
represent the highest failure rate in over a decade"
Situation im IT-Projektmanagement
http://www.standishgroup.com/newsroom/chaos_2009.php
Boston, Massachusetts, April 23, 2009 - New Standish Group
report shows more project failing and less successful projects.
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
3
Zwei Erfolgsmodelle
Scrum
PufferPufferPufferPufferPufferPuffer
PufferPufferPufferPufferPufferPuffer
P3P3P2P2
P1P1
P2P2
P3P3
P1P1
Critical Chain-Projektmanagement
(CCPM)
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
4
Alexander Kriegisch
Freiberuflicher agiler Coach & Projektmanager
#
20 Jahre kommerzielle Programmier-Erfahrung
15 Jahre Vollzeit in Software-Industrie
10 Jahre Beratung
7 Jahre Projektmanagement
Scrum-Master.de
Training, Coaching, Supervision
Themen: Agile Enterprise, Scrum
(Multi-)Projektmanagement
Troubleshooting
Interim-Management
Scrum-Master.de – Agiles Projektmanagement
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
5 Referenzen Scrum-Master.deParallels
Einführung des Scrum-Vorgehensmodells (Standort Moskau)
Coaching und Training
Meta Scrum im Management-Team
skalierter Multi Team Scrum-Prozeß
Einführung von SW-Engineering-Praktiken (Unit Testing, Continuous Integration)
1&1 Internet AG
Einführung des Scrum-Vorgehensmodells
Coaching und Training bereichsübergreifend
Leitung zweier Software-Großprojekte und zweier Forschungsprojekte im Bereich Webhosting
Beratung als "Scrum-Evangelist" für Management (Agile Enterprise) und Teams (Scrum im Projekt)
Sun Microsystems GmbH
Entscheider-Workshop "Selling Agile"
Beratung bzgl. der Frage, wie Scrum komplexe Kundenprojekte und deren Preisfindung verbessern kann
Projekttyp: Rechenzentrums-Aufbau bzw. -Migration
42media group GmbH
Scrum-Coaching und -Training für Geschäftsführung und Entwicklungsabteilung
Verbesserung des bestehenden Scrum-Prozesses
Agile Aufwandschätzung und Release-Planung
Scrum-Rollen im Unternehmen (Agile Enterprise)
Elektrobit Automotive GmbH
Offene Scrum-Einführungsveranstaltung für Belegschaft am Standort Erlangen + Webcast an alle Standorte
Supervision und Mentoring für Scrum-Projekt im Bereich Automotive
Besondere Herausforderung: Projektmitarbeiter über zwei Standorte verteilt
Autoliv
Scrum-Workshop am Standort Elmshorn
Projekttyp: ERP-Eigenentwicklung Großrechner (Host) in COBOL
Besondere Herausforderung: Legacy-Umgebung, traditionelle IT-Prozesse
Kassenärztliche Vereinigung Bayerns
Erste positive Scrum-Erfahrungen im Entwicklungsbereich
Einige anstehende Projektvorhaben geplant mit Scrum als agilem Vorgehensmodell
Scrum-Training für Fachbereichsvertreter unterschiedlicher Standorte als Vorbereitung auf
Product Owner-Rolle
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
6 Wer sonst arbeitet mit Scrum?
Nokia
Microsoft
Yahoo!
Allianz
Siemens
O2
Vodaphone
Netviewer
Die Frage also lautet eher:
Wer arbeitet noch nicht mit Scrum?
Intel
Adobe
Sun
Philips
Xerox
State Farm
State Street Bank
British Telecom
Bose
BBC
IBM
SAIC
LMCO
APL
Ariba
Federal Reserve Bank
TransUnion
IDX
PayPal
HP
Motorola
Patient Keeper
Conchango
BMC
Lexis-Nexis
CapitalOne
u.v.m.
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
8 Scrum-Rollen – die drei Manager in Scrum
Product Owner
verantwortlich für geschäftliche und fachliche Entscheidungen (Anforderungen und deren Priorisierung)
Proxy für sämtliche Stakeholders ("one face to the team")
Team
verantwortlich für technische Entscheidungen (wie werden Anforderungen umgesetzt und wer macht was)
selbstorganisierend, kein "Teamleiter"
akzeptiert Aufgaben, bekommt sie nicht zugewiesen
interdisziplinär, kann Anforderungen komplett ("end to end") umsetzen
Scrum Master
verantwortlich für den Scrum-Prozeß und die Einhaltung seiner Regeln
Moderator, Kommunikationsförderer, Hindernisbeseitiger
verantwortlich für maximale Effizienz in der Umsetzung des Projektauftrags
In Scrum treffen Geschäftsleute geschäftliche, Techniker technischeEntscheidungen. Jeder tut, was er am besten kann und verantwortetes auch!
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
9 Scrum-Prozeß – Sprint und Time-Box
Scrum ist ein iterativ-inkrementeller Prozeß, d.h.
es wird in kurzen, regelmäßigen Iterationen (max. 1 Monat), sog. Sprints
gearbeitet;
in jedem Sprint wird ein vertikaler, voll funktionsfähiger Produktbestandteil
entwickelt, getestet und ausgeliefert;
das Produkt entsteht in Inkrementen, also finden auch Analyse, Design,
Umsetzung, Test und Dokumentation in jedem Sprint statt, nicht z.B. eine
vollständige Spezifikation zu Beginn des Projekts;
Änderungen der Anforderungen und ihrer Prioritäten seitens
Product Owner sind legitim und erwünscht ("embrace change"),
aber niemals während eines laufenden Sprints, nur zu Beginn
eines neuen.
Jeder Sprint und jedes Meeting in Scrum sind "time-boxed", d.h.
streng zeitlich abgegrenzt. Eine Time-Box wird niemals
überzogen! Ein Termin ist ein Termin ist ein Termin.
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
10 Scrum-Grundidee: Entwickeln in Inkrementen
1. Apply: Anwenden
endlich mal anfangen(!)
etwas entwickeln
aktiv eine Idee umsetzen
überprüfbare Fakten schaffen
2. Inspect: Prüfen
kritische Erfolgskontrolle
Fehler in Produkt und Prozeß
analysieren
3. Adapt: Anpassen
Spezifikation präzisieren
Prozeß verbessern
ggf. alternativ vorgehen
auch mal (rechtzeitig!) etwas
„wegwerfen“
Apply
Adapt
Inspect
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
11 Scrum-Prozeß
Sprint
(30 Tage)
24 Std.
Product Backlog
(priorisiert duch
Product Owner)
Sprint
Backlog
Backlog Tasks
(durch dasTeam
ausgearbeitet)
Potenziell
auslieferbares
Produkt-Inkrement
Daily Scrum
Meeting
Quelle: Adaption gemäß Agile Software Development with Scrum von Ken Schwaber & Mike Beedle
Sprint Planning
Meeting
Teil 2
Teil 1Sprint Review
Meeting
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
12 Scrum – Aufwandschätzung und Planung
Die wichtigsten Planungsartefakte in Scrum sind sog. Backlogs:
Product Backlog
Makrokosmos → Produkt-/Releaseplanung → strategisch
Product Owner → fachlich → Anforderungs-Ebene
eindeutig priorisiert nach Business Value
enthält Aufwandschätzungen des Teams
Sprint Backlog
Mikrokosmos → Sprint-Planung → operativ
Team → technisch → Task-Ebene
Restaufwandschätzungen werden täglich aktualisiert
Aufwände werden immer im und vom Team geschätzt, nicht von einzelnen Experten und auch nicht von Vorgesetzten. Wer die Arbeit später macht, schätzt auch den Aufwand!
Weiter in der Zukunft liegende Anforderungen werden gröber und grobgranularer geschätzt, höher priorisierte (=demnächst umzusetzende) genauer und feingranularer.
Das Product Backlog und damit die Spezifikation ist also ständig im Fluß, wird gepflegt, verbessert und verfeinert, denn während des Projekts lernen wir etwas über selbiges.
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
13 Scrum – Tracking und Reporting
Fortschritt wird in Scrum auf operativer Ebene taggenau
ermittelt und graphisch im sog. Sprint Burndown Chart
dargestellt.
Probleme werden sofort sichtbar, man kann rechtzeitig
reagieren und Gegenmaßnahmen einleiten.
Auf strategischer Ebene (Gesamt- oder Teilprojekt) gibt es
das sog. Product Burndown Chart (PBC), in welchem
der gesamte Projektfortschritt dargestellt und über Trends
prognostiziert werden kann.
Im PBC werden auch die sog. Velocity (Geschwindigkeit)
des Teams und ihre Schwankungen sichtbar. Die Velocity
ist ein wichtiger Indikator für die Gesundheit von Team und
Projekt.
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
14 Klassisches Product Burndown Chart (PBC)
durchgezogene Linie für reale Restaufwände
gestrichelte Trendlinie für Prognose desFertigstellungs-Zeitpunkts
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
15 Erweitertes Product Burndown Chart (PBC)
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
16 Erweitertes Product Burndown Chart (PBC)
Gesamt-Burndown (altbekannt)
Zusatzanforderungen, unterhalb der x-Achse
abgetragen
Aus der Summe der Zusatzaufwände
ergibt sich eine neue virtuelle Nullinie
Bereinigter Team-Burndown
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
17 Erweitertes Product Burndown Chart (PBC)
Gesamt-Burndown (altbekannt)
Aus der Summe der Zusatzaufwände
ergibt sich eine neue virtuelle Nullinie
Gemessen an den Anforderungen zu Beginn des Projekts, hätten wir hier bereits fertig sein
können, wenn keine Zusatzanforderungen vom Product Owner gekommen wären.
Bereinigter Team-Burndown
Wenn der Product Owner ab jetzt keine neuen Anforderungen mehr stellt, kann das Team zu diesem
Zeitpunkt den Restaufwand abgearbeitet haben.
Bei gleicher Menge neuer Anforderungen pro Sprint wie bisher,
sieht es aber eher nach diesem Release-
Zeitpunkt aus...
Zusatzanforderungen, unterhalb der x-Achse
abgetragen
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
18 Erweitertes Product Burndown Chart (PBC)
Gesamt-Burndown
Zusatz-anforderungen
VirtuelleNullinie
Team-Burndown Übrigens gilt immer: Der verbleibende
Gesamtaufwand (gelber y-Wert) ...
… entspricht exakt dem jeweiligen Abstand zwischen der blauen und der
roten Linie.
Das ist nicht weiter erstaunlich, summieren sich doch der bereinigte
Burndown und die Zusatzanforderungen gerade wieder zum Gesamtaufwand.
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
19 Scrum – Zusammenfassung
Scrum ist einfach
wenige Rollen (3) mit klaren Verantwortlichkeiten
wenige, aber klare und einzuhaltende Regeln
Scrum ist lean
Vermeidung von Overhead und Verschwendung
write less, talk more
Scrum ist flexibel (=agil)
Anforderungen und Prioritäten dürfen sich ändern
Planung ist wichtig, aber Reaktionsfähigkeit auf geänderte
Umgebungsbedingungen ist wichtiger
Scrum erzeugt Transparenz – gnadenlos!
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
21
CCPM – Vorstellung W.Müller
2010Beratung, Training und Coaching – TOC, CCPM, HSP
Softwareentwicklung Schlund+Partner
Leitung des Project Office
Project
Controlling
Process
ManagementIT-Security
special
Projects
500+1 Projekte mit
40 Projektmanagern
Studium Mechatronik – FH-Karlsruhe
Studium Maschinenbau – TH-Karlsruhe
Entwicklung und Prozessentwicklung
Freelancer in
Softwareentwicklung
1991
im Team mit fünf
erfahrenen
TOC Experten
aus unterschiedl.
Branchen mit
Produktions- und
Projekthintergrund.
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
22
CCPM Testimonials
Berichte auf TOC Anwenderkonferenz
2009 in Darmstadt
http://www.goldratt.com/toctpwp1.htm
http://www.vistem.eu/de/ccpm
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
23
CCPM – zwei Angriffspunkte
#1 korrektes Management
der Ressourcen
PufferPufferPufferPufferPufferPuffer
PufferPufferPufferPufferPufferPuffer
P3P3P2P2
P1P1
P2P2
P3P3
P1P1
#2 korrekter Umgang
mit Schätzungen
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
24
CCPM Staffelung (strategische Priorisierung)
Prj. Prj. Prj. Prj.
P1
Prj.
Prj.
P2
PrjPrj.
Prj.P2
P2
Prj.
Prj.Prj.Prj.
Prj. viele Projekte
+ relativ. statische
Ressourcen
produktionsähnliches
Umfeld
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
25
CCPM Staffelung (strategische Priorisierung)
P1Prj.
Prj.
P2
PrjPrj.
Prj.P2
P2Prj.
Prj. Prj. Prj. Prj.
Prj.Prj.Prj.
Prj.
optimale „Produktion“:
§1 Einlastung muss langfristig mit Leistung des Systems im Gleichgewicht
sein Work-In-Progress begrenzen
§2 Durchlaufzeit ist bei FiFo optimal eindeutige Reihenfolge
CCPM:
• eindeutige Reihenfolge der Projekte
• neue Projekte werden immer als letztes in
die Reihe gestellt
• es werden die Projekte anhand der
Reihenfolge verplant
• bei Ressourcenkonflikten werden diese
transparent am Engpass aufgelöst
s. 4-6-4-Methode [M1]
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
26
P3P2
Ausrichtung der Projekte am Engpass =
strategische Priorisierung
Projektsicht
P1
P2
P3
Engpasssicht
P1
Ressourcenpuffer
im Engpass
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
27
Störungen im Projekt
alles läuft wie geplant …
und das ist die Realität …
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
28
Handling von Unsicherheiten
• jede Schätzung ist falsch!
• je mehr Druck – desto mehr Puffer wird eingerechnet
• Parkinson-Gesetz – es wird immer die geschätzte Zeit
ausgenutzt
• Studentensyndrom – wenn
man einen Puffer hat, ver-
schiebt man den Arbeitsbeginn
bis zum letzten Zeitpunkt
• Murphy schlägt zu.
Es kommt zu Verspätungen
Puffer werden immer aufgebraucht, Verfrühungen
treten nicht auf, Verspätungen werden weitergegeben!
relative
Wahrscheinlichkeit
opt. pes.
0%
max.
typ. Schätzung
sinnvolle Schätzung
50% abs. Wahrscheinlichkeit
real.
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
29
Projektplan gem. CCPM
#1 in typ. Schätzungen sind 50% Puffer
Arbeitspakete um 50% kürzen
#2 Verfrühungen und Verspätungen gleichen sich aus
Projektpuffer um 50% kürzen
Puffer
Puffer
Projektpläne
verkürzen
sich um 25%
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
30
operative Prioritäten = Arbeitspaketebene
8 von 12 = 66% 3 von 4 = 75%
8 von 10 = 80% 1 von 4 = 25%
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
31
Projektcontrolling
Projektgesundheit – „rot“ heißt - es stimmt was nicht bei den
Supportprozessen
Pro
jekt
pu
ffe
rve
rbra
uch
(in
%)
Erledigungsgrad auf der kritischen Kette (in %)
90 – 100 %
90
– 1
00
%
80
– 9
0 %
70
– 8
0 %
60
– 7
0 %
50
– 6
0 %
40
– 5
0 %
30
– 4
0 %
20
– 3
0 %
10
– 2
0 %
0 -1
0 %
80 – 90 %
70 – 80 %
60 – 70 %
50 – 60 %
40 – 50 %
30 – 40 %
20 – 30 %
10 – 20 %
0 – 10 %
Pro
jekt
pu
ffe
rve
rbra
uch
(in
%)
Erledigungsgrad auf der kritischen Kette (in %)
90 – 100 %
90
– 1
00
%
80
– 9
0 %
70
– 8
0 %
60
– 7
0 %
50
– 6
0 %
40
– 5
0 %
30
– 4
0 %
20
– 3
0 %
10
– 2
0 %
0 -1
0 %
80 – 90 %
70 – 80 %
60 – 70 %
50 – 60 %
40 – 50 %
30 – 40 %
20 – 30 %
10 – 20 %
0 – 10 %
Projekt B
Projekt A
Projekt CProjekt D
Einzelprojekt: ein Projekt in Grün fertig
machen ist gar nicht sinnvoll …
Portfolio: übergreifender Blick stärkt
gegenseitige Hilfe zwischen den Projekten
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
32
Scrum und CCPM …
… ungleiche Brüder
… aber gleiche
Wurzeln?
Scrum
PufferPufferPufferPufferPufferPuffer
PufferPufferPufferPufferPufferPuffer
P3P3P2P2
P1P1
P2P2
P3P3
P1P1
Critical Chain-Projektmanagement
(CCPM)
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
33
viele Projekte ein Engpass
• die Wertschöpfung erfolgt in
Form von vernetzten Systemen
• Leistungsfähigkeit hängt von
schwächsten Glied ab
• es gibt nur ein schwächstes
Glied (Constraint)
Management am Constraint
ausrichten
das Beispielprojekt
als Flussbild
Engpass
TOC [M4] oder Trichtermodell [M5]
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
34
Little‘s Law
Wenn mehr Arbeit im System als Kapazität
dann läuft die Durchlaufzeit weg
Bestand [h/Woche]
Auslastung
[%]
mittl. Durchlaufzeit [h]
100%
min. DLZ
DLZ
Bestand
Kapazität
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
35
TOC - fünf Schritte der Fokussierung
#4 den Engpass erweitern
#3 das Management am Engpass ausrichten
#1 Engpass identifizieren
#2 Engpass optimal ausnutzen
#5 wieder bei #1 beginnen
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
36
… aber es sind zwei Engpässe!
P1
Prj.
Prj.
P2
PrjPrj.
Prj.P2
P2
Prj.
Prj.
Prj.Prj.Prj.
Prj.#1
Ressourcen
und Skills
vor allem ein
Engpassteam#2
Kommunikations-
und Denkbandbreite
vor allem beim
Projektmanagementstrat. Ressourcenmanagement [M3]
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
37
Baukasten für Hochleistungssysteme
#1 Ressourcen und Skills
7 Funktionen, die so gebaut sein
müssen, dass sie den Ressourcenengpass
optimal nutzen
#2 Kommunikations-
und Denkbandbreite
6 best Practices mit
Kommunikation optimal
umzugehen
P1Prj.
Prj.
P2
PrjPrj.
Prj.P2
P2Prj.
Prj.
Prj.Prj.Prj.
Prj.
P1Prj.
Prj.
P2
PrjPrj.
Prj.P2
P2Prj.
Prj.
Prj.Prj.Prj.
Prj.
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
38
Die 7 Funktionen
#1 WIP begrenzen nur soviel Arbeit im
System wie leistbar
#2 Engpass identifizieren objektiv den
echten Engpass finden
#3 Endtermin ermitteln nur ehrliche
Termine planen
#4 strategische Prioritäten festlegen Verfahren, um die
richtige Reihenfolge festzulegen
#5 Streuungen verarbeiten Streuungen gegen Termin puffern
#6 operative Prioritäten festlegen Verfahren um die Arbeit den
Ressourcen zu teilen
#7 Fortschritt darstellen den Fokus auf die wirklichen Probleme
lenken
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
39 Engpass Kommunikation die 6 Best Practices
(das +)
#1 Verhalten verbessern 3+1 Verhaltensprinzipien vereinbaren
#2 Vertrauen schaffen positives Verhalten positiv
rückkoppeln
#3 Taktungen auflösen Arbeitsvorräte mit vielen Prozessinstanzen
#4 Kapselung Arbeitspakete möglichst groß mit min. Kopplung
strukturieren
#5 schnelle Eskalation offene Punkte schnell weglösen
#6 no Plan so wenig wie möglich planen – nur das notwendigste
s. High-Speed Projektmanagement [M2]
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
40 Vergleich CCPM/Scrum –
7 Funktionen
WIP begrenzen eindeutige Priorität
und Projektfreigabe am EP
• Einzelprojekt: nach Business Value priorisiertes Product Backlog
• Multiprojekt: analog priorisiertes Project Backlog
Engpass
identfizieren
Ressourcenkonflikte systematisch
auswerten
• Scrum Master als Problem-/ Konfliktbeauftragter
• Blocks List wird systematisch abgearbeitet
• Retrospektiven als KVP-Instanz
Endtermin
ermitteln
klassisch mit Hilfe kritischer Kette
unter Berücksichtigung der echten
Kapazität und Einlastung
• Iteration: Endtermin ist fix; tagaktuelles Sprint Burndown Chart
zeigt Abweichungen sofort
• Gesamtprojekt: Messung der Velocity erlaubt realistische
Endterminermittlung
• Schätzungen kommen immer vom Projektteam, sind daher
realistisch, nicht von oben vorgegeben
strategische
Priorität
FiFo und transparente objektive
Reihenfolgenvertauschung am EP
• Product Owner darf Prioritäten im Product Backlog ändern, ...
• ABER nur zu definierten Zeitpunkten (1x pro Sprint/Iteration)
Umgang mit
Streuungen
Puffer aus Arbeitspaketen in
Projektpuffer, Zulieferpuffer und/oder
Ressourcenpuffer
• feingliedrige Anforderungen + Arbeitspakete
• Vielzahl sorgt für gegenseitigen Ausgleich von Über- und
Unterschätzungen
• Velocity ist ein Durchschnittswert
operative
Priorität
Projektfortschritt auf krit. Kette
gegenüber dem Pufferverbrauch
• selbstorganisierendes Team
• kurze Feedback-Schleifen (Daily Scrum)
Fortschritt
darstellen
• Makro-Ebene (strategisch): Product Burndown Chart
• Mikro-Ebene (operativ): Sprint Burndown Chart, Task Board
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
41 Vergleich CCPM+/Scrum –
6 Best Practices
Verhalten
verbessern
3 Verhaltensprinzipien – sofort, direkt und
Vertrag
+1 keine Überraschungen
• Commitment des Teams pro Iteration/Sprint
• kurze Feedbackschleifen (Daily Scrum)
• tägliche, direkte Zusammenarbeit mit dem Kunden
• Retrospektiven
• Scrum Master wehrt "dysfunctional behaviour" ab
Vertrauen
schaffen
schnelle Kritik und Lob, dem
Vertrauenslevel angepasste Arbeitspakete
• Das Team (kein Vorgesetzter) zeigt in kurzen, regelmäßigen
Abständen das Produkt und bekommt direktes Feedback
• Prinzip "no surprises" für Reviews, denn der Product Owner
weiß auch während des Sprints, woran das Team arbeitet
Taktungen
auflösen
jedes Teilprojekt hat sein eigenen Fluß,
Synchronisation nur an Übergabepunkten
• sinnvolle Taktung auf Sprint-Ebene (Time-Box)
• alles andere ist Selbstorganisation des Teams
• Wo gar keine Taktung mehr möglich ist, Scrum um Kanban-
Elemente erweitern
Kapselung
stärken
nicht nach Organigramm sondern nach min.
Kommunikation strukturieren
• Scrum-Teams sind interdisziplinär
• Team soll Funktionalität "end to end" als Zelle komplett
selbst entwickeln können (weniger externe Abhängigkeiten)
• Aufgaben-, nicht Organigramm-Orientierung
schnell
eskalieren
offen Punkte schnell vom Projektmanager
lösen
• Scrum Master kümmert sich um jegliches Hindernis
• Product Owner bekommt Probleme zeitnah mit, spätestens
täglich im Daily Scrum
wenig planen nur das absolut notwendige, sauberer
Auftrag, klare Verantwortlichkeiten und harte
Vorgaben
• zeitlich weit Entferntes wird grob geschätzt und geplant
• aktueller Sprint wird feingranularer geschätzt
• Tagesplanung obliegt dem selbstorganisierenden Team
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
42
Vergleich CCPM/Scrum – die Stärken
Anwendungs-
gebiete
Staffelung - in jeder
Multiprojektumgebung = mehr Projekte
als verfügbare Ressourcen
Terminabsicherung – in jedem Projekt mit
hohem Fokus auf Termintreue – vor allem
in Multiprojektumgebungen
unabhängig von Branchen
• komplexe Projekte mit unklaren oder zu Beginn
noch unvollständigen Anforderungen
• (nahezu) dedizierte Projektteams
• sich ändernde Prioritäten während der
Projektlaufzeit
• Einzel- oder Multi-Projekt-Umgebung
• skalierbar auf Projekte mit mehreren Teams
• auch außerhalb IT anwendbar
• anwendbar als Management Framework auf
Bereichs- oder C*O-Ebene
Nutzen • >95% Termintreue (ehrliche Termin und
sichere Einhaltung
• 25%-50% schnellere
Durchlaufzeit (durch Reduktion WIP)
• mehr freie Kapazitäten (in Folge meist
Verbesserung der Innovationsfähigkeit
und Qualität)
• mehr Transparenz durch simples, aber glasklares
Reporting
• weniger "work in progress"
= weniger Investition in unfertige Produkte
= geringeres Risiko
= schnellere Durchlaufzeit
= schnellere Amortisation, RoI > 1 früher erreicht
• weniger Overhead (Scrum ist "lean"!)
• Wichtiges wird früher fertig → Investitionsschutz
• Projekte oft früher als geplant fertig (Kunde braucht
nicht alle "goldenen Wasserhähne")
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
43
Zusammenfassung
• Um Höchstleistungen zu erreichen, ist das Management konsequent an Begrenzungen
auszurichten.
• Begrenzungen im Projektgeschäft sind die Ressourcen und die
Kommunikationsbandbreiten.
• Eine gute Projektsteuerung erfüllt idealerweise die zuvor genannten 7 Funktionen und 6
Best Practices.
• Scrum und CCPM+ decken die Funktionen und Best Practices in hervorragender Weise
ab.
• Scrum spielt sein Trümpfe bei Innovationsprojekten aus, in denen dedizierte Ressourcen
zum Einsatz kommen können.
• CCPM+ spielt seine Trümpfe in Standard-Projektumgebungen aus, wo es trotz vieler
Projekte und geteilter Ressourcen auf absolute Termintreue und Durchsatz ankommt.
• Aber Achtung: Weder Scrum noch CCPM+ sind Entschuldigungen für schädliches
Multitasking – im Gegenteil!
• Der Wille zur Veränderung und eine gewisse Disziplin sind Voraussetzungen für beide
Methoden, wenn man Ordnung ins Projekt-Chaos bringen möchte.
Wolfram Müller, Alexander Kriegisch – Scrum und CCPM+ – © 1&1 Internet AG und Scrum-Master.de
44
Mehr?
http://speed4projects.net
Literatur
[M1] „Erfahrungsbericht der 1&1 Internet AG Projekt-Priorisierung
in einem dynamischen und inhomogenen Projektumfeld“,
Projektmagazin 20/06
[M2] „High-Speed-Projektmanagement bei 1&1
Teil 1: Vertrauen übertrumpft Methodik“,
Projektmagazin 05/08
und „Teil 2: So funktioniert es in der Praxis“,
Projektmagazin 07/08
[M3] W.Müller „Ressourcenmanagement im strategischen und
operativen Multipro-jektmanagement“, in „Handbuch Multi-
projektmanagement und -controlling“,
Steinle/Eßeling/Eichenberg (Herausge-ber), Schmidt Verlag
07/2008
[M4] E.Goldratt „das Ziel“ (1990) und „Critical Chain Project
Management“ (2002)
[M5] P.Nyhuis u. H.-P. Wiendahl „logistische Kennlinien“ (2003)
Literatur
[1] "Agile Project Management with Scrum" von Ken
Schwaber, 2004 (ISBN 073561993X)
[2] "The Enterprise and Scrum" von Ken Schwaber, 2007
(ISBN 0735623376)
[3] Scrum-Einführung:
http://scrum-master.de/content/blogsection/4/31/
[4] Scrum-Glossar:
http://scrum-master.de/content/category/3/7/25/
[5] "Scrum and XP from the Trenches", Henrik Kniberg
http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
[6] "Scrum vs. Kanban", Henrik Kniberg
http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf
http://scrum-master.de… oder direkt