Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Vom Hybriden zu Scrum und zurück

582 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
  • Als Erste(r) kommentieren

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

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

×