Public Domain, http://de.wikipedia.org/wiki/Der_Hobbit#mediaviewer/File:The_Hobbit_-_title_page_of_first_American_print.jp...
AM ANFANG WAR DAS V 
Megaprojekt im Öffentlichen Bereich (200 Mitarbeiter) 
Projektbeginn 
Ende 2009 
Entwicklungsbeginn 
...
PROJEKTSTRUKTUR 
Qualitätsmanagement 
Architektur 
Releasemanagement 
Projektleitung 
Schni1stellenmanagement 
TP 
FK 
TP ...
STATUS QUO 2011 
Prozesse eingebettet 
in V-Model XT 
Fachkonzept 
Parallel zur 
Entwicklung verfasst 
und weiterentwickel...
BEDARF NACH AGILER 
VORGEHENSWEISE 
Lange Releasezyklen 
Fehlende Flexibilität 
und Reaktionsfähigkeit 
in großem 
Entwick...
BEDARF NACH AGILER 
VORGEHENSWEISE 
Lange Releasezyklen 
Fehlende Flexibilität 
und Reaktionsfähigkeit 
in großem 
Entwick...
GERINGE TERMINTREUE MÖGLICH 
Beharren 
wenn Plan nicht mehr 
realistisch ist 
Scheinsicherheit 
Plan schafft Illusion, 
Pr...
WARUM NICHT EINFACH SCRUM? 
Rolle des Product 
Owners unbesetzbar 
Vorurteile und 
Missverständnisse 
Einbettung in 
Gesam...
DAS IST NICHT SCRUM 
Pull statt Push 
Teams legen 
Arbeitsteilung/-umfang 
selbst fest 
Arbeitsumfang pro 
Team 
Warenkorb...
DAS IST NICHT SCRUM 
Arbeitsumfang pro 
Team 
Warenkorb 
Team Commitment 
Fachliche Integration 
Gegen Ende jeder 
Etappe ...
TEAMLEITER BEIBEHALTEN 
Rückhalt im Team 
Komfortabel für das 
Team 
Eine(r) übernimmt 
Verantwortung 
Teamübergreifende 
...
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 Ansat...
LARGE SCALE SCRUM? 
Cross-funktional 
Teams über acht 
Wochen stabil 
Self-managed 
Kein Teamleiter 
Feldtest: Acht 
Woche...
TEAMS AUF ABWEGEN 
Kanban 
Zyklische Aufgaben 
Support für Andere 
Durchsatzoptimierung 
Einfaches Taskboard 
Keine direkt...
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 
...
WARUM? 
Feldtest: Acht 
Wochen 
Viel Erfahrung 
gesammelt 
Sieben Teams 
Zusammenarbeit / 
Abstimmung der Teams 
problemlo...
WARUM? 
Feldtest: Acht 
Wochen 
Viel Erfahrung 
gesammelt 
Ein-Wochen-Iteration 
„Gefühlt“ ein Tag pro 
Woche in Meetings ...
WARUM? 
Cross-funktional 
Etabliert, Stabilität 
bedingt gewährleistet 
Feldtest: Acht 
Wochen 
Viel Erfahrung 
gesammelt ...
WARUM? 
Cross-funktional 
Etabliert, Stabilität 
bedingt gewährleistet 
Self-managed 
Verantwortung 
übernehmen hat nicht ...
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? 
Angemessenes 
Training? ...
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 
Zw...
VIELEN DANK FÜR DIE 
AUFMERKSAMKEIT 
Bei Fragen bitte 
fragen! 
Ramon Anger 
Senior Solution Architect 
CSD Service Indust...
Vom Hybriden zu Scrum und zurück
Nächste SlideShare
Wird geladen in …5
×

Vom Hybriden zu Scrum und zurück

487 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
487
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
6
Aktionen
Geteilt
0
Downloads
4
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Vom Hybriden zu Scrum und zurück

  1. 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. 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. 3. PROJEKTSTRUKTUR Qualitätsmanagement Architektur Releasemanagement Projektleitung Schni1stellenmanagement TP FK TP TP Test Entw. Risikomanagement Projektlenkungsausschuss PMO
  4. 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. 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. 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. 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. 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. 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. 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. 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. 12. SO LEBTE DAS PROJEKT 18 MONATE LANG GLÜCKLICH UND ZUFRIEDEN ... Bildquelle: Rike / pixelio.de
  13. 13. LARGE SCALE SCRUM? Feldtest: Acht Wochen Passte zu Zwischenrelease Sieben Teams Initial alle mit dem gleichen Ansatz Self-managed Kein Teamleiter
  14. 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. 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. 16. LARGE SCALE SCRUM HAT NICHT FUNKTIONIERT Bildquelle: Gabi Schoenemann / pixelio.de
  17. 17. WARUM? Product Owner (Proxy) Gute Erfahrung mit der Rolle
  18. 18. WARUM? Sieben Teams Zusammenarbeit / Abstimmung der Teams problemlos Product Owner (Proxy) Gute Erfahrung mit der Rolle
  19. 19. WARUM? Feldtest: Acht Wochen Viel Erfahrung gesammelt Sieben Teams Zusammenarbeit / Abstimmung der Teams problemlos Product Owner (Proxy) Gute Erfahrung mit der Rolle
  20. 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. 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. 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. 23. KANN MAN EINFACH SO „SELF-MANAGED“ WERDEN? Ausreichende Diskussion? Praxisnahe (Bei)Spiele? Angemessenes Training?
  24. 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. 25. ACHT WOCHEN UMSONST? Bildquelle: Initiative Echte Soziale Marktwirtschaft (IESM) / pixelio.de
  26. 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. 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

×