VOM HYBRIDEN ZU SCRUM UND ZURÜCK

Public Domain, http://de.wikipedia.org/wiki/Der_Hobbit#mediaviewer/File:The_Hobbit_-_title_page_of_first_American_print.jpg

AM ANFANG WAR DAS V

Projektbeginn Ende 2009

Entwicklungsbeginn Ende 2010

Pilotbetrieb Anfang 2014

Flächenbetrieb Mitte 2014

V-Modell XT

Megaprojekt im Öffentlichen Bereich (200 Mitarbeiter)

Qualitätsmanagement  

PROJEKTSTRUKTUR

Schni1stellenmanagement  

Releasemanagement  

Architektur  

Projektleitung  

TP  Test  TP  FK   TP  Entw.  

Risikomanagement  

Projektlenkungsausschuss  

PMO  

STATUS QUO 2011

Prozesse eingebettet in V-Model XT

Fachkonzept

Parallel zur Entwicklung verfasst und weiterentwickelt

Entwicklung

Fünf Teams mit 30 Entwicklern (später

sieben Teams mit 50 Entwicklern)

Test

Nachgelagert zur Entwicklung

BEDARF NACH AGILER VORGEHENSWEISE

Lange Releasezyklen

Fehlende Flexibilität und Reaktionsfähigkeit

in großem Entwicklungsteam

Paradox of Expertise

Fachexperten können Anforderungen nicht

IT-verständlich formulieren

Micro Planning

Hoher Aufwand bei Veränderung des

Projektplans

Prozess Schwergewicht

V-Modell XT bot keine

Unterstützung

BEDARF NACH AGILER VORGEHENSWEISE

Lange Releasezyklen

Fehlende Flexibilität und Reaktionsfähigkeit

in großem Entwicklungsteam

Paradox of Expertise

Fachexperten können Anforderungen nicht

IT-verständlich formulieren

Micro Planning

Hoher Aufwand bei Veränderung des

Projektplans

Prozess Schwergewicht

V-Modell XT bot keine

Unterstützung

Geringe Termintreue möglich

Hohe Unsicherheit

Anforderungen zu Beginn jedes Release

unklar / volatil

GERINGE TERMINTREUE MÖGLICH

Beharren

wenn Plan nicht mehr realistisch ist

Scheinsicherheit

Plan schafft Illusion, Problem im Griff zu

haben

Keine Akzeptanz der Veränderung

Planung

Unsicherheit führt zu intensiver Planung

WARUM NICHT EINFACH SCRUM?

Rolle des Product Owners unbesetzbar

Vorurteile und Missverständnisse

Einbettung in Gesamtprozess

schwierig

Scrum bedeutet disruptive

Veränderung

Gefühlt: keine Planung möglich

DAS IST NICHT SCRUM

Pull statt Push

Teams legen Arbeitsteilung/-umfang

selbst fest

Arbeitsumfang pro Team

Warenkorb

Team Commitment

Etappenweises Vorgehen

Kalendermonat

Eingebettet in Release

DAS IST NICHT SCRUM

Arbeitsumfang pro Team

Warenkorb

Team Commitment

Fachliche Integration

Gegen Ende jeder Etappe

Potential Shippable Release

Am Ende jeder Etappe

Automatisierung

Continuous Integration and Delivery

Etappenweises Vorgehen

Kalendermonat

Pull statt Push

Teams legen Arbeitsteilung/-umfang

selbst fest

TEAMLEITER BEIBEHALTEN

Rückhalt im Team

Komfortabel für das Team

Eine(r) übernimmt

Verantwortung

Aufbauorganisation des Gesamtprojekts

reflektiert

Teamübergreifende Koordination durch dedizierte Kollegen

SO LEBTE DAS PROJEKT 18 MONATE LANG GLÜCKLICH UND ZUFRIEDEN ...

Bildquelle: Rike  / pixelio.de

LARGE SCALE SCRUM?

Feldtest: Acht Wochen

Passte zu

Zwischenrelease

Sieben Teams

Initial alle mit dem gleichen Ansatz

Self-managed

Kein Teamleiter

LARGE SCALE SCRUM?

Cross-funktional

Teams über acht Wochen stabil

Self-managed

Kein Teamleiter

Feldtest: Acht Wochen

Passte zu

Zwischenrelease

Ein-Wochen-Iteration

Hohe Lernkurve erwartet

Sieben Teams

Initial alle mit dem gleichen Ansatz

Product Owner (Proxy)

Für jedes Team

TEAMS AUF ABWEGEN

Kanban

Zyklische Aufgaben Support für Andere

Durchsatzoptimierung

Einfaches Taskboard

Keine direkte Unterstützung, dafür

Flexibilität

Naked Planning

Keine Schätzung Priorität vorgegeben

„Einfach machen“

LARGE SCALE SCRUM HAT NICHT FUNKTIONIERT

Bildquelle: Gabi Schoenemann  / pixelio.de

WARUM?

Product Owner (Proxy)

Gute Erfahrung mit der

Rolle

WARUM?

Sieben Teams

Zusammenarbeit / Abstimmung der Teams

problemlos

Product Owner (Proxy)

Gute Erfahrung mit der

Rolle

WARUM?

Feldtest: Acht Wochen

Viel Erfahrung

gesammelt

Sieben Teams

Zusammenarbeit / Abstimmung der Teams

problemlos

Product Owner (Proxy)

Gute Erfahrung mit der

Rolle

WARUM?

Feldtest: Acht Wochen

Viel Erfahrung

gesammelt

Ein-Wochen-Iteration

„Gefühlt“ ein Tag pro Woche in Meetings

Sieben Teams

Zusammenarbeit / Abstimmung der Teams

problemlos

Product Owner (Proxy)

Gute Erfahrung mit der

Rolle

WARUM?

Cross-funktional

Etabliert, Stabilität bedingt gewährleistet

Feldtest: Acht Wochen

Viel Erfahrung

gesammelt

Ein-Wochen-Iteration

„Gefühlt“ ein Tag pro Woche in Meetings

Sieben Teams

Zusammenarbeit / Abstimmung der Teams

problemlos

Product Owner (Proxy)

Gute Erfahrung mit der

Rolle

WARUM?

Cross-funktional

Etabliert, Stabilität bedingt gewährleistet

Self-managed

Verantwortung übernehmen hat nicht

funktioniert

Feldtest: Acht Wochen

Viel Erfahrung

gesammelt

Ein-Wochen-Iteration

„Gefühlt“ ein Tag pro Woche in Meetings

Sieben Teams

Zusammenarbeit / Abstimmung der Teams

problemlos

Product Owner (Proxy)

Gute Erfahrung mit der

Rolle

KANN MAN EINFACH SO „SELF-MANAGED“ WERDEN?

Ausreichende Diskussion?

Praxisnahe (Bei)Spiele?

Angemessenes Training?

KANN MAN EINFACH SO „SELF-MANAGED“ WERDEN?

Ausreichende Diskussion?

Praxisnahe (Bei)Spiele?

Die richtigen Typen? Bedenken ignoriert?

Angemessenes Training?

Philosophie kann nicht gewechselt

werden

Transitionsprozess

ACHT WOCHEN UMSONST?

Bildquelle: Initiative Echte Soziale Marktwirtschaft (IESM)  / pixelio.de

DAS IST NICHT SCRUM - RELOADED

Bessere Zusammenarbeit mit

Fachkonzept/Test Scrum

Regelmeetings

Kurze Iterationen

Zwei Wochen

Teamleiter

Langsame Transition zu Verantwortung der

Teams

Hohe Akzeptanz in der Organisation

PO Proxy je Team

Paradox of Expertise besser adressiert

VIELEN DANK FÜR DIE AUFMERKSAMKEIT

Bei Fragen bitte fragen!

Ramon Anger Senior Solution Architect CSD Service Industries Capgemini Deutschland GmbH ramon.anger@capgemini.com