Slidedeck meines Vortrags auf den Berlin Days of Softwareengineering am 07.10.2014 Slidedeck of my talk at Berlin Days of Softwareengineering on 2014.10.07

1. Public Domain, http://de.wikipedia.org/wiki/Der_Hobbit#mediaviewer/File:The_Hobbit_-_title_page_of_first_American_print.jpg
VOM HYBRIDEN ZU SCRUM UND ZURÜCK

2. AM ANFANG WAR DAS V
Megaprojekt im Öffentlichen Bereich (200 Mitarbeiter)
Projektbeginn
Ende 2009
Entwicklungsbeginn
Ende 2010
Pilotbetrieb
Anfang 2014
Flächenbetrieb
Mitte 2014
V-Modell XT

3. PROJEKTSTRUKTUR
Qualitätsmanagement
Architektur
Releasemanagement
Projektleitung
Schni1stellenmanagement
TP
FK
TP
TP
Test
Entw.
Risikomanagement
Projektlenkungsausschuss
PMO

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. TEAMLEITER BEIBEHALTEN
Rückhalt im Team
Komfortabel für das
Team
Eine(r) übernimmt
Verantwortung
Teamübergreifende
Koordination durch
dedizierte Kollegen
Aufbauorganisation
des Gesamtprojekts
reflektiert

12. SO LEBTE DAS PROJEKT 18 MONATE
LANG GLÜCKLICH UND ZUFRIEDEN ...
Bildquelle: Rike / pixelio.de

13. LARGE SCALE SCRUM?
Feldtest: Acht
Wochen
Passte zu
Zwischenrelease
Sieben Teams
Initial alle mit dem
gleichen Ansatz
Self-managed
Kein Teamleiter

14. 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

15. 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“

16. LARGE SCALE SCRUM HAT NICHT
FUNKTIONIERT
Bildquelle: Gabi Schoenemann / pixelio.de

17. WARUM?
Product Owner
(Proxy)
Gute Erfahrung mit der
Rolle

18. WARUM?
Sieben Teams
Zusammenarbeit /
Abstimmung der Teams
problemlos
Product Owner
(Proxy)
Gute Erfahrung mit der
Rolle

19. WARUM?
Feldtest: Acht
Wochen
Viel Erfahrung
gesammelt
Sieben Teams
Zusammenarbeit /
Abstimmung der Teams
problemlos
Product Owner
(Proxy)
Gute Erfahrung mit der
Rolle

20. 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

21. 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

22. 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

23. KANN MAN EINFACH SO
„SELF-MANAGED“ WERDEN?
Ausreichende
Diskussion?
Praxisnahe
(Bei)Spiele?
Angemessenes
Training?

24. KANN MAN EINFACH SO
„SELF-MANAGED“ WERDEN?
Ausreichende
Diskussion?
Praxisnahe
(Bei)Spiele?
Angemessenes
Training?
Philosophie kann
nicht gewechselt
Die richtigen Typen? Bedenken ignoriert?
werden
Transitionsprozess

25. ACHT WOCHEN UMSONST?
Bildquelle: Initiative Echte Soziale Marktwirtschaft (IESM) / pixelio.de

26. 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

27. 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