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 [email protected]