Lust, Last, List? Ein Scrum Projekt reflektiert von Product Owner, Scrum Master und Scrum Coach

Scrum-Breakfast Bern, 30.03.2011 Lust, Last, List? Ein Scrum Projekt reflektiert von Product Owner, Scrum Master und Scrum Coach Ferdinand Hodel, IT Post Joscha Jenni, mimacom ag Peter Stucker, CSC Post Mail Informationstechnologie

Aufbau und Agenda

Projektsicht Autraggeber – Product Owner
Sortierung PostMail
Täglich 15 Millionen Briefe und Zeitungen, Zehntausende Briefbehälter, Hunderte Transporte
9 Briefzentren, 2 Retourenzentren
4‘600 Leute, 40 Sortiermaschinen, ca. 500 Handsortiergestelle
ca. 300 unterschiedliche Sortierprogramme
Sortierplanung
ca. 600 Mutationen/Monat
Simulationen für grössere Anpassungen Sortierung
Komplexe Zusammenhänge

Projektsicht IT – Scrum Master I
IT1-Softwareentwicklung in Zahlen
Personal:
173 Mitarbeitende, PE = 161.99
Softwareentwicklung:
4 Entwicklungsumgebungen (J2EE, .NET, SAP, Oracle)
2 ESB-Produkte (JCAPS von SUN & PI von SAP)
>10 SAP ERP-Systeme
Intranet:
über 300 Applikationen
pro Tag: ca. 3.2 Mio. Zugriffe, ca. 26 Mio. Seiten, ca. 1.3 Mio Besuche
Projekte/Dienstleistungen:
Weit über 100 Projekte pro Jahr
> 33 Mio. CHF. Umsatz im Bereich Dienstleistungen 2009

Projektsicht IT – Scrum Master II
So ist IT1 aufgestellt
Stand Januar 2011 IT1 Geschäftsanwendungen Urs Rudolf von Rohr Stv. Andreas Blasenbrei IT101 Postapplikationen Jean-Louis Fatton IT102 ERP Systeme Christos Mitos IT103 Produktivitätslösungen Andreas Blasenbrei IT11 Projektmanagement Norbert Zurwerra Stv. Martin Sägesser IT12 Java Roland Räuftlin Stv. Markus Günther IT13 Microsoft/.net Kurt Jost Stv. Stefan Haefeli IT14 Oracle/JCAPS Martin Rohrer Stv. Claudio Baldussi IT15 CCC SAP Reto Gentinetta Stv. Michel Frey IT16 Standort Bellinzona Roger Mossier Stv. Paolo Casella Chef Architektur Martin Schwab Stv. Reto Pestoni Sekretariat Nadja Günthör * Jacqueline Marti * Betreuung lernender Person

Projektsicht IT – Scrum Master III
IT-Post offerierte die Softwarelösung auf der Basis der Systemanforderungen mit 602 PT und einer Umsetzungszeit von rund 12 Monagen
Dienstleistungen Aufwand PT Modul Persistenz 30 Modul Security/Visibility 16 Modul Traceability 2 Modul ReleaseMgmt 53 Modul Plandatenpflege 20 Modul ReleaseCalculation 48 Modul Änderungen zwischen zwei Release ermitteln 40 Modul ReleaseVerifikationDistribution 10 Modul Excel Import/Export 50 Modul Intf. Zstam -> SortPla 54 Modul Intf. SortPla -> Zstam (LPM/SPM) 26 Modul BO Reports 56 Modul Dokumentation 32 Architektur 18 Deploy 15 Einführung 22 Projektmanagement 66 Reserve 44 Total Aufwand in PT 602

Ausgangslage und Einstieg Sicht Product Owner I Darf ich das?
IT Post „Wir wollten schon lange ein Projekt nach Scrum abwickeln“.
Wie weit soll ich als PO Einfluss nehmen, um „Scrum-But“ zu verhindern?
Wie weit soll ich die Management Awareness über die Methode treiben?
Das Vorhaben (und der Hauptknowhowträger…) hat einen explorativen Charakter.
Eine Lösung ist dringend notwendig.

Ausgangslage und Einstieg Sicht Product Owner II
Rollen und Verantwortlichkeiten, inkl. QS
Die meisten Entwickler sind nur 50-60% Ressourcen.  relativer Aufwand für Scrum „Meetings“ ist hoch  sichtbarer Fortschritt pro Sprint (3 bzw. 4 Wochen) eher gering
Spezialisierung war wichtig, auch wenn wir als Team agieren (Lösungsarchitekt, SW-Architekt, GUI Verantwortlicher, DB-Verantwortlicher. u.a.).
Für das agile Vorgehen ist eine entwicklungsnahe QS von Vorteil (mit technischen Skills im Bereich DB-Abfragen und idealerweise sogar Programmierskills für automatisierte Tests).

Ausgangslage und Einstieg Sicht Scrum Master I
Scrum Einführung /Schulung
Zu Beginn wurde eine Scrum-Ausbildung mit dem Kernteam durchgeführt, jedoch veränderte sich die Besetzung im Team aufgrund der knappen Ressourcen nachhaltig. Die neuen Teammitglieder konnten nicht genügend geschult werden.
Funktionsweise der Methode Scrum wurde zum Teil missverstanden oder nicht einheitlich interpretiert.
Einführung Jira als Tool für agile Projekte erfolgte on-the-job.

Ausgangslage und Einstieg Sicht Scrum Master II
Die Kernteammitglieder mussten sich in ihrer Rolle finden.
Der Product-Backlog Owner nimmt mehrere Rollen ein: - Auftraggeber Stellvertreter - Gesamtprojekt-Leiter - Scrumteam Mitglied
QS sehr weit weg vom Geschehen
Der Scrum-Master konnte die erforderliche Zeit in den ersten Sprints bei weitem nicht aufbringen.
Die Verantwortung des Scrum-Teams wurde teilweise massiv unterschätzt.

Ausgangslage und Einstieg Sicht Scrum Berater I
Einführung, Schulung, Know-How Transfer
Frühe Schulungen des Teams zahlen sich aus
Neue Team Mitglieder wie in der Einführung schulen

Ausgangslage und Einstieg Sicht Scrum Berater II
Stakeholder waren klar
Product Owner und Scrum Master definiert
Scrum Team
Rollen haben sich im Scrum Team entwickelt
QS konnte leider nie richtig integriert werden
Scrum Master zu Beginn Scrum-Know-How Träger oder nicht?

Ausgangslage und Einstieg Key Points
QS ist intensiv ins Scrum-Team zu integrieren (erfordert ev. ein Überdenken des Rollenverständnis und der Arbeitsweise von QS).
Bei der Einführung von neuen Methoden sind entsprechend die Ressourcen einzuplanen (Ausbildung und die ersten Sprints).
Spezialisierte Rollen helfen dem Projekterfolg.

Scrum-Prinzipien Sicht Product Owner I
Sprintzielvereinbarungen
Die detaillierten Spezifikationen aus den Anforderungen werden mit einem kleinen zeitlichen Vorlauf auf die Entwicklung erarbeitet.  z.T. Verlagerung Termindruck von IT zu Fach
„ Ziele unterhalb des Radars“: Infrastruktur, Datenlogik, u.v.a. Achtung: QS betrachtet eventuell nur GUI‘s als „potentiell lieferbare und einsetzbare Software“
Über die Sprintziele kann das Team an die Vision des PO herangeführt werden.
Koordination der Einzeltasks ist auch bei Scrum zwingend notwendig, um die Ziele zu erreichen. Persönliche Verantwortung jedes einzelnen ist ein (zu) hehres Ziel.

Scrum-Prinzipien Sicht Product Owner II
„ Fail fast, Learn fast“  weniger Stress für alle
Ressourcen- und Knowhow-Engpässe früh adressierbar.
Viele kleine Fehler statt wenige grosse Fehler.
Deployment Prozess wird eingespielt.
Transparenz bei Erfolg und Misserfolg
Die erreichte Transparenz ist für den PO enorm wichtig und für den Projekterfolg massgeblich verantwortlich.
„ Misserfolg“? „Planungsfehler“? „Niederlage“? Nicht erreichte Ziele sind schwer als Chance kommunizierbar.

Scrum-Prinzipien in der Einschätzung der Beteiligten: Sicht Product Owner III
Einschätzung: das agile Vorgehen hat einen stark positiven Einfluss auf die Qualität der Lösung.
Positive Einschätzung ist mit zunehmender Erfahrung deutlich gestiegen.

Scrum-Prinzipien Sicht Scrum Master I
Sprintzielvereinbarungen und Transparenz bei Erfolg und Misserfolg
Absolute Transparenz gegenüber dem Projektauftraggeber.
Offensichtliche Schwächen bezüglich der Stabilität in der Entwicklungsumgebung und bezüglich dem Ausbildungsstand der Entwickler.
Das Nichterreichen von Sprintzielen wird zu jedem Sprintende unmissverständlich aufgezeigt.
Beim Nichterreichen der Sprintziele entsteht der Eindruck, dass für die jeweilige Situation einzig und allein die IT verantwortlich ist.

Impressionen I - Burn Down Chart

Impression II - Stimmungsbarometer

Scrum-Prinzipien Sicht Scrum Master II
Definition of Done, Sprint- und Task-Readiness
Im Projektkern- und im Scrumteam tat man sich schwer, die Definition of Done zu finden.
Die QS war bei der Defintion of Done nicht beteiligt.
Bezüglich den Anforderungspapiere wurde keine Definiton of Done formuliert, dies weder bei der Erstellung noch bei der Veränderung dieser.
Welcher Prozess läuft ab, wenn ein Module im Status “done“ infolge Fehler von der Entwicklung nochmals bearbeitet werden muss.

Scrum-Prinzipien Sicht Scrum Master III
Eigenverantwortung
Die Scrum-Philosophie basiert auf einer hohen Selbstverantwortung vom Scrum-Team, resp. von jedem einzelnen Entwickler.
Inwiefern wird die Verantwortung vom Management entsprechend delegiert?
Inwiefern ist sich der Entwickler dessen bewusst?

Scrum-Prinzipien Sicht Scrum Master IV
Timeboxing
Eines der wichtigsten Scrum-Prinzipien überhaupt.
Konnte fast nie eingehalten werden, beginnend mit den Ausführungen des Produkt Owners zu Beginn der Sprintplanung, bis hin zu den Abnahmetests.
Timeboxing bedeutet, genügend kleine Pakete zu definieren, welche in der geplanten Zeiten bearbeitet werden können.
Hängt sehr eng mit den Sprintzielen zusammen.

Scrum-Prinzipien Sicht Scrum Berater I
Sprintzielvereinbarungen
Endlich ein Product Owner der Ziele formuliert!
Transparenz bei Erfolg und Misserfolg
Ziele wurden leider vom Team am Anfang zu wenig hinterfragt und/oder waren zu wenig SMART definiert…
… was zu Frustration beim Review-Meeting führte

Scrum-Prinzipien Sicht Scrum Berater II
Definition of Done
Definition of Done war in einem Dokument… zu wenig transparent und zu wenig in den Köpfen
Sprint- und Task-Readiness
Product Owner muss mal spezifizieren, sonst…
Sprintlänge?

Scrum-Prinzipien Sicht Scrum Berater III
Eigenverantwortung
Von Person zu Person unterschiedlich, jedoch durchwegs positiv!
Starke Persönlichkeiten/Leaders haben Verantwortung getragen
Timeboxing
… time over…
War schwierig durchzusetzen

Scrum-Prinzipien Key Points
Timeboxing situativ anwenden
Fortwährende Feedbackloops erzwingen die Entdeckung und die Beseitigung von Hindernissen auf dem Weg zum Projekterfolg.
Die resultierende Transparenz dient dem Auftraggeber und –nehmer.

Rahmenbedingungen Sicht Product Owner I
Vertragsform
Auftraggeber und –nehmer im gleichen Konzern
Werk mit Fixpreis
Change Managment
Change Diskussion „wie klassisch“
Auf Durchgängigkeit von Pflichtenheft  Angebot  Tasks achten.  Schätzung und erbrachter Aufwand vergleichen
Transparenz durch Scrum nützt Auftraggeber  Gegenleistung: Auftraggeber honoriert nachvollziehbare Mehraufwände konziliant

Rahmenbedingungen Sicht Scrum Master I
Vertragsform
Fixpreis vs Design to Cost
Vertrauen, resp. nicht das Gefühl zu haben, über den Tisch gezogen zu werden
Konfliktkultur zwisschen Auftraggeber und –nehmer
Auftraggeber und –nehmer im gleichen Konzern
IT-Post als NonProfitOrganisation ?!

Rahmenbedingungen Sicht Scrum Master II
Infrastruktur (Jira, das Tool)
Das Projekt wurde in Jira zu kompliziert und zu aufwendig angelegt
Jira besitzt keine Schnittstelle zum Faktuierungssystem von IT-Post und somit müssen aufwände doppelt rapportiert werden
Zeitliche Abhängigkeiten können in Jira nicht dargestellt werden
Jira ist in der Handhabung nicht einfach und als Web-Applikation träge
Jira ist in einer reduzierten Form den Projekten möglichst einheiltich zur Verfügung zu stellen

Rahmenbedingungen Sicht Scrum Berater I
Tooling
Ziele definieren!
Mehr Training, bessere Dokumentation
Vertragsform
Fakt
Linke rechte Hosentasche - Politikum
Konflikt: Vertrag mit IT oder? PO vs. SM…

Rahmenbedingungen Sicht Scrum Berater II
Infrastruktur
Entwicklungsumgebung und Aufbau Plattformen
Zu spät ready… organisatorische und betriebliche Schnittstelle, resp. Abhängigkeit
Essentiell für agile Entwicklung

Rahmenbedingungen Key Points
Auch bei den Infrastrukturverantwortlichen und dem Change Management muss das Verständnis für das agile Vorgehen gefördert werden. Auch hier gilt: Agilität bedeutet nicht Chaos
Agiles Vorgehen lässt sich mit Fix-Preis Werkverträgen vereinbaren.
Ein Planungs- und Trackingtool ist zur Unterstützung des agilen Vorgehens zwingend erforderlich.

Bilanz

Impression III - Stimmungsbarometer So macht es definitiv mehr Spass!

Lust, Last, List? Ein Scrum Projekt reflektiert von Product Owner, Scrum Master und Scrum Coach

by Joscha Jenni on May 21, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

Lust, Last, List? Ein Scrum Projekt reflektiert von Product Owner, Scrum Master und Scrum Coach — Presentation Transcript