Download - zwei Erfolgsmodelle mit den gleichen Wurzeln GPM ... · Training, Coaching, Supervision Themen: Agile Enterprise, Scrum (Multi-)Projektmanagement Troubleshooting Interim-Management

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


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.




3

Zwei Erfolgsmodelle

Scrum

PufferPufferPufferPufferPufferPuffer


P3P3P2P2

P1P1

P2P2

P3P3

P1P1

Critical Chain-Projektmanagement

(CCPM)


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


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


6 Wer sonst arbeitet mit Scrum?

Nokia

Microsoft

Yahoo!

Google

Allianz

Siemens

XING

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.


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!


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.


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


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


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.


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.


14 Klassisches Product Burndown Chart (PBC)

durchgezogene Linie für reale Restaufwände

gestrichelte Trendlinie für Prognose desFertigstellungs-Zeitpunkts


15 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



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



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.


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!


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.


22

CCPM Testimonials

Berichte auf TOC Anwenderkonferenz

2009 in Darmstadt

http://www.goldratt.com/toctpwp1.htm

http://www.vistem.eu/de/ccpm


23

CCPM – zwei Angriffspunkte

#1 korrektes Management

der Ressourcen



P3P3P2P2

P1P1

P2P2

P3P3

P1P1

#2 korrekter Umgang

mit Schätzungen


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


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]


26

P3P2

Ausrichtung der Projekte am Engpass =

strategische Priorisierung

Projektsicht

P1

P2

P3

Engpasssicht

P1

Ressourcenpuffer

im Engpass


27

Störungen im Projekt

alles läuft wie geplant …

und das ist die Realität …


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.


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%


30

operative Prioritäten = Arbeitspaketebene

8 von 12 = 66% 3 von 4 = 75%

8 von 10 = 80% 1 von 4 = 25%


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


32

Scrum und CCPM …

… ungleiche Brüder

… aber gleiche

Wurzeln?

Scrum



P3P3P2P2

P1P1

P2P2

P3P3

P1P1

Critical Chain-Projektmanagement

(CCPM)


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]


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


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


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]


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.


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


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]


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


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


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")


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.


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“,


und „Teil 2: So funktioniert es in der Praxis“,


[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

http://speed4projects.net/





















http://scrum-master.de/

