Erfahrungen bei der Einführung agiler Methoden im JBF-Team agile@JBF Erfahrungen bei der Einführung agiler Methoden im JBF-Team D.Brotzer, SYRACOM AG; O. Fischer, Technische Architektur | JBFOne 2009

Agenda Szenen aus dem Projektalltag Was haben wir gesehen? - Die Ausgangslage agile Methoden SCRUM Szenen aus dem agilen Projektalltag Erfahrungsbericht JBF

Szenen aus dem Projektalltag

Agenda Szenen aus dem Projektalltag Was haben wir gesehen? - Die Ausgangslage agile Methoden SCRUM Szenen aus dem agilen Projektalltag Erfahrungsbericht JBF

Was haben wir gesehen? Unklare Anforderungen Projektstatus und –fortschritt ist nicht transparent Lange Reaktionszeiten auf neue Anforderungen Relativ hoher Anteil ungeplanter Tätigkeiten Wissensinseln

Agenda Szenen aus dem Projektalltag Was haben wir gesehen? - Die Ausgangslage agile Methoden SCRUM Szenen aus dem agilen Projektalltag Erfahrungsbericht JBF

Das agile Manifest wichtiger als wichtiger als wichtiger als wichtiger

Agilität schafft Sicherheit und Transparenz Klare Priorisierung der Anforderungen oberstes Ziel: Maximierung des Geschäftswerts/Kundennutzens Setzen von Sicherungspunkten kurze, gleich lange Iterationen Regelmäßige Produktinkremente und Einholung von Feedback Kunde muss jedes Inkrement abnehmen Mehr Flexibilität auf Kundenseite Kunde kann Anforderungen im laufenden Projekt ändern, streichen, ergänzen oder ersetzen Mehr Transparenz über Projektstatus und -fortschritt Schätzgrößen werden frühzeitig mit empirischen Daten hinterlegt

Firmen, die auf Agilität setzen

Agenda Szenen aus dem Projektalltag Was haben wir gesehen? - Die Ausgangslage agile Methoden SCRUM Szenen aus dem agilen Projektalltag Erfahrungsbericht JBF

Sprint Planning Meeting Die SCRUM-3 x 3-Matrix Product Backlog Sprint Backlog Impediment List 3 Artefakte Scrum Master Product Owner Team 3 Rollen Sprint Planning Meeting Daily Scrum Meeting Sprint Review Meeting 15' (Retrospective) 3 Meetings

Der SCRUM-Prozess

SCRUM MACHT PROBLEME SICHTBAR

SCRUM = RISK-MANAGEMENT

Agenda Szenen aus dem Projektalltag Was haben wir gesehen? - Die Ausgangslage agile Methoden SCRUM Szenen aus dem agilen Projektalltag Erfahrungsbericht JBF

Szenen aus dem agilen Projektalltag

Agenda Szenen aus dem Projektalltag Was haben wir gesehen? - Die Ausgangslage agile Methoden SCRUM Szenen aus dem agilen Projektalltag Erfahrungsbericht JBF

Ziele von agile@JBF … Verbesserung des Know-How-Transfers kürzere Reaktionszeiten auf Anforderungen weniger Aufwände für Bewertungen einfachere Priorisierung von Anforderungen mehr Transparenz für alle mehr Kommunikation, mehr Austausch von Informationen im Team

Der Projektherzschlag von agile@JBF Sprint 1 28 Tage Sprint 2 28 Tage Sprint 3 28 Tage Sprint 4 28 Tage Sprint 5 28 Tage Sprint 6 28 Tage Milestones M1 M2 M3 M4 M5 Final Release Mittwoch Donnerstag Freitag vor Sprintende Der JBF- Entwicklungsprozess basiert auf SCRUM Die Dauer eines Sprints beträgt 4 Wochen  6 Sprints pro Release Ein Sprint dauert jeweils von Donnerstag bis Mittwoch Sprint-Endgame 3 Tage vor Sprintende (Freitag, 12 Uhr) Code Freeze Entwicklertests zur Stabilisierung und Aushärtung des Systems Zeitliche Freiräume können zur Spezifikation kommender Features genutzt werden Retrospektive nicht vergessen! Sprint Review Meeting mit dem Product Owner zur Abnahme der Features Release-Endgame Letzter Sprint vor dem finalen Release zur Aushärtung des Systems Keine neuen Features mehr Daily scrums der Teilteams sind zeitlich versetzt Spezifi- zierung Spezifi- zierung CM + Bug Test Spezifi- zierung Entwurf + Konstruktion Sprint-Endgame Planning Meeting CM + Bug Test Spezifi- zierung Entwurf + Konstruktion Sprint-Endgame Planning Meeting CM + Bug Test Spezifi- zierung Entwurf + Konstruktion Sprint-Endgame Planning Meeting Planning Meeting CM + Bug Sprint-Endgame Planning Meeting CM + Bug Sprint-Endgame Release-Endgame Test Test Entwurf + Konstruktion Entwurf + Konstruktion

Detailplanung eines Sprints 28 Tage Sprint - Endgame Retrospektive Code Freeze Sprint - Endgame Retrospektive Sprint Review Spezifizierung Spezifizierung Planning Meeting CM + Bug CM + Bug CM + Bug Planning Meeting Test Test Test Entwurf + Konstruktion Entwurf + Konstruktion Entwurf + Konstruktion Mo. Di. Mi. Do. Fr. Mo. Di. Mi. Do. Fr. Mo. Di. Mi. Do. Fr. Mo. Di. Mi. Do. Fr. Mo. Di. Mi. Do. Fr. Mo. Di.

Teamstruktur: das Prinzip des JBF Molecule Product Owner Team Scrum Master Team Team Product Owner Scrum Master Scrum Master Product Owner Scrum Master Herleitung der organisation: Wir sind mit einem Scrum-Master und zwei Pos gestartet, haben aber erkannt, dass Scrum Master und PO Vollzeit Team Product Owner

Teamstruktur: The JBF Molecule Klaus Huthmacher Frank Gamerdinger Server 5 TM WS & Sec 4 TM Markus Gäbelein Simon Schrezen- meier MIAMI 3 TM Maintenance 1 (+3) TM Roman Koutny Ellen Rottmann Michael Jung Oliver Fischer Simone Sänftl Marek Nowak Client 4 TM BiTemp 5 TM Hans Kellner Markus Haseneder

… und wie wir die Ziele erreicht haben Verbesserung des Know-How-Transfers Einführung Maintenance-Team für Supportaufgaben rollierend und interdisziplinär besetzt gemeinsames Bearbeiten neuer Features (Pair-Designing,Pair-Programming) kürzere Reaktionszeiten auf Anforderungen Anforderungen können jederzeit gestellt werden neue Anforderungen werden durch PO zeitnah bewertet kürzere Time-to-market durch 4-Wochen-Sprints Verbesserung des Know-How-Transfers Einführung eines rollierend, interdisziplinär besetzten Maintenance-Teams für Supportaufgaben (Bearbeitung von Tickets, Bugs & Wishes und Supportanfragen) Gemeinsame Bearbeitung von neuen Features im Team, Pair-Programming bei kritischen Tasks (Auflösen der Wissens-Inseln) Kürzere Reaktionszeiten auf Anforderungen Anforderungen können jederzeit gestellt werden Product Owner tagen jede Woche, neue Anforderungen werden zeitnah bewertet Arbeit in 4-Wochen-Sprints ermöglicht eine kürzere Time-to-market Weniger Aufwände für Bewertungen Es werden nur die Anforderungen detailliert bewertet, analysiert und geschätzt, die auch in den nächsten zwei Sprints umgesetzt werden Anforderungen, die eine niedrige Priorität haben, werden nur soweit analysiert, wie für eine Priorisierung erforderlich Einfachere Priorisierung von Anforderungen Anforderungen werden Kontingenten (Projekte, Betrieb, Strategie, …) zugeordnet und gemeinsam mit einem JBF-externen Kontingent-Verantwortlichen priorisiert.

… und wie wir die Ziele erreicht haben (Fortsetzung) weniger Aufwände für Bewertungen nur Anforderungen für die nächsten zwei Sprints werden detailliert bewertet, analysiert und geschätzt einfachere Priorisierung von Anforderungen Anforderungen werden Kategorien (Projekte, Betrieb, Strategie, …) zugeordnet gemeinsame Priorisierung mit den jeweils Verantwortlichen mehr Transparenz für alle Backlogs sind für alle sichtbar Burndown Charts sind für alle sichtbar für alle offene Meetings Verbesserung des Know-How-Transfers Einführung eines rollierend, interdisziplinär besetzten Maintenance-Teams für Supportaufgaben (Bearbeitung von Tickets, Bugs & Wishes und Supportanfragen) Gemeinsame Bearbeitung von neuen Features im Team, Pair-Programming bei kritischen Tasks (Auflösen der Wissens-Inseln) Kürzere Reaktionszeiten auf Anforderungen Anforderungen können jederzeit gestellt werden Product Owner tagen jede Woche, neue Anforderungen werden zeitnah bewertet Arbeit in 4-Wochen-Sprints ermöglicht eine kürzere Time-to-market Weniger Aufwände für Bewertungen Es werden nur die Anforderungen detailliert bewertet, analysiert und geschätzt, die auch in den nächsten zwei Sprints umgesetzt werden Anforderungen, die eine niedrige Priorität haben, werden nur soweit analysiert, wie für eine Priorisierung erforderlich Einfachere Priorisierung von Anforderungen Anforderungen werden Kontingenten (Projekte, Betrieb, Strategie, …) zugeordnet und gemeinsam mit einem JBF-externen Kontingent-Verantwortlichen priorisiert.

… und wie wir die Ziele erreicht haben (Fortsetzung) mehr Kommunikation, mehr Austausch von Informationen im Team regelmäßiger Informationsaustausch durch Daily Scrum Meeting Vorstellung von Sprintergebnissen im gesamten Team was wir uns nicht vorgenommen, aber nebenbei trotzdem erreicht haben: Anzahl offener Tickets ist deutlich gesunken, Ticketlösungsrate wurde erhöht Teamzufriedenheit ist gestiegen Qualitätsverbesserung Bessere Planbarkeit Ticketlösungsrate verbessert, keine auffälligen Tickets im OKLF

agile@JBF im Zeitverlauf 2009 2010 Sprints 2009-01 2009-02 2009-03 2009-04 2009-05 2009-06 2009-07 2009-08 2010-01 2010-02 Start mit einem Scrum Master zwei Product Ownern aber ohne Tool Auslieferung Milestonebuilds Taskgröße max. 5 PT Definition of Done Nutzung von Rational Team Concert Maintenance-Team Mehrere Product Owner JBF Molecule Intensivierung Pair working “Die Dinge, die wir erst lernen müssen, bevor wir sie tun, lernen wir beim Tun.“ - Aristoteles Reviewmeetings Ein Scrum Master je Team Schätzpoker

Fragen? – Diskussion? David Brotzer Oliver Fischer SYRACOM Consulting AG Oliver Fischer Anwendungsentwicklung Technische Architektur Teamleiter JBF oliver.fischer@fiducia.de 0 89 / 99 43 – 31 47 david.brotzer@syracom.de +49 89 31 20 29 30

Ihr IT-Partner Vielen Dank