69er - Sprint 3 Retrospective

Gestern, 09. September war erneut eine Retrospective im 69er Projekt, nunmehr in der dritten Iteration.

Summary:
Auch in diesem Sprint war das Team schneller, aber leider auch schlechter. Der agile Arbeitsturnus hat sich so langsam eingespielt und das Team lebt Scrum. Trotzdem ist die Stimmung nicht gut. Der fehlende ScrumMaster ist für das Team spürbar. Viele Hindernisse die sich zu Blocking entwickeln, ohne Aussicht auf Behebung!

Das Ergebnis:
Geplant waren 20 Story Points bei einer verfügbaren Zeit von 78h, sportlich! Von den geplanten User Stories konnten 4 nicht fertig gestellt werden! Warum? 

Es gibt bei diesen Stories ein externes Partner-Unternehmen, auf dessen Service die Applikation angewiesen ist. Die Integration des Services ist zunächst trivial, trotzdem klemmt es. Das Partner-Unternehmen lässt uns hängen - das Team kommt nicht voran. Andere User Stories wurden einfach nicht gut genug getestet und vielen schlichtweg durch, als sie dem Product Owner präsentiert wurden. 

Und so sieht es aus:


Retrospective:

Was war nicht gut?

1. Die Rails Entwickler machen viele Tasks, die nicht Rails related sind - das ist langsam und macht kein Spass
2. Design ist noch immer nicht abgeschlossen, muss ständig neu angefasst werden - wird nie fertig
3. "Springende" Ressourcen sind nicht im agilen Prozess, sie leben ihn nicht
4. Viele externe Hindernisse, die das Team nicht lösen kann und sich "niemand" drum kümmert
5. Stimmung schlecht, Ergebnis stimmt nicht - wir erreichen unsere Ziele nicht

Uhhpf! Nicht gut ...

Was können wir besser machen?

1. Niemand arbeitet allein auf dem Projekt (auf täglicher Basis). Wir arbeiten nur, wenn mindestens 2 Teammitglieder arbeiten, bessere Resourcenplanung ausserhalb des Teams.
2. Reviews schneller(früher) machen, Arbeit (früher) abschliessen
   
3. Product Owner ist zwingend anwesend beim Planning und Demo Meeting

Nun steht der letzte Sprint vor der Tür. Das Product Backlog ist noch immer gut gefüllt und das Projektende ist absehbar. Werden wir es schaffen?

Zurück zum Sprint 3 Planning & Estimation Meeting

69er - Wir brauchen einen ScrumMaster

Im der letzten Retrospective von Sprint 2 hat das Team bemängelt, dass es viele Hindernisse gibt, die offensichtlich viel Engagement benötigen und im Team keine Zeit dafür besteht. Jedes Teammitglied steht unter Druck, denn man hat sich auf eine Ziel committed und man möchte das Spiel gewinnen. Treten Hindernisse auf, geht man diesen nach, soweit es möglich ist. Werden die Hindernissse zu gross, geht dem Team die Luft aus.

Bei einem der Posts zum 69er Projekt habe ich einen Kommentar bekommen, der auf die Pitfalls von Scrum eingeht. Es geht im wesentlichen um die Frage, ob man ohne ScrumMaster ein Scrum Projekt führen kann und was unsere Erfahrungen sind.

"In addition to the disengaged ScrumMaster, there is the team where a worker bee also tries to be ScrumMaster. This works fine as long as the team does not encounter too many impediments. If the team does encounter impediments, however, either the impediments will not be resolved (because the worker bee role is consuming too much time) or the work will not be completed (because the worker bee is now running around trying to eliminate impediments). For this reason, I no longer have team members perform the ScrumMaster role while actually doing work on a sprint (unless it is a very small amount of work)." Boris Gloger, Pitfalls in Scrum

Nun ja, genau diese Erfahrungen kann ich bestätigen. Kleine Hindernisse kann das Team selbst lösen. Werden diese zu Blocking oder mengenmässig grösseren Hindernissen, leidet das Team und damit das Ergebnis.

Beim 69er Projekt wurde das offen in der Retrospective Sprint 2 diskutiert. Das Team bat um einen ScrumMaster. Da man sich allerdings bereits im 3. von 4. Sprints befindet und eine Einarbeitung Zeit und Aufwand bedeutet, hat das Team davon abgesehen.


Die Erkenntis:
Im nächsten Scrum Projekt nur noch mit ScrumMaster.

69er - Sprint 2 Retrospective

Am Dienstag vergangene Woche war erneut ein Sprint im 69er Projekt vorüber und es wurde präsentiert, was wir hatten.

Summary:
Das Team war erneut schnell, schneller als geplant und schneller als selbst eingeschätzt, aber es häuften sich auch die Probleme ...

Das Ergebnis:
Geplant waren für Sprint 2 total 25 Story Points (SP's), bei einer verfügbaren Zeit von 144h Stunden. Von den geplanten User Stories wurden nur 18 SP's umgesetzt, 7 SP's waren Not Done. Trotzdem hat das Team während des Sprints zusätzliche User Stories angenommen und somit insgesamt 28 Story Points verdient.

Interpretation, Sprint Burndown:
Das Team hat in der Retrospective das Burndown Chart analysiert und kam zu folgenden Erkenntnissen:

• Wir sind schnell, aber ...
• Viele offene Pendenzen, Hindernisse - daher kein Progress bei 4 Stories (Blocking)
  
• Aufgrund der Blockaden musste das Team andere User Stories vorziehen, da sonst keine Arbeit
  
• Vorgezogene User Stories waren oft nicht abgeklärt- viele offene Fragen, Unklarheiten
  

Retrospective:

Was war gut?

• User Story of Taskboard, quasi manuell, nach wie vor gut
  
• Resourcen konnten arbeiten, wie geplant

Was können wir besser machen?

• Vorgezogenen User Stories oft unklar, Plannig Phase fehlte, viel Input vom PO während des Sprints notwendig
• Es gab eine Demo vom System mitten im Sprint, nicht zum Demo Day wie geplant
• Administrative Arbeiten inkl. Aufwände fallen an, gehören aber nicht zu einer Story und tauchen nicht in der Sprint-Planung auf, was machen wir damit?
• Code Freeze vor dem Deployment wurde nicht für alle Teammitglieder kommuniziert, daher gab es anschliessend viele Merge-Konflikte im Subversion
• Release-Umgebung zur Demo nicht up-and-running, ungeplanter Aufwand im Sprint
• Es gibt keine Release Notes, was haben wir bisher gemacht?
• kein ScrumMaster zum Hindernisse lösen
• Sprint Übersicht ist gut, aber Gesamtperspektive fehlt - wo stehen wir? Werden wir das schaffen?
• Anwesenheit beim Daily Scrum nur sporadisch

Nun, wenn wir die Stimmungbaromether ablesen sieht es nicht mehr so gut aus - wir müssen handeln!

Zurück zum 69er - Sprint 2 Planning & Estimation Meeting
[Update]
Weiter zum Sprint 3 Planning & Estimation Meeting

69er - Sprint 1 Retrospective

Am Dienstag war beim 69er Projekt Sprint 1 Demo Day und Retrospective. Team: Safe!

Dashboard?
Originally uploaded by Jürg

Summary:
Alles in allem kann man sagen, dass das Team unglaublich viele Arbeitspakete bewältigen konnte, mehr als erwartet.

Das Ergebnis:
Geplant waren 12 Story Points, 132h verfügbare Zeit
Realisiert wurden 19 Story Points in 143h. 31 geplante Stunden konnten nicht bezogen werden. Eine User Story wurde vom Product Owner nicht abgenommen, also 18 Story Points insgesamt.

Interpretation, Sprint Burndown:
In der Retrospective hat das Team das Burndown Chart und die Zahlen interpretiert und ein Fazit gezogen. Dabei kam heraus, dass man

• zu pessimistisch geschätzt hat
• Arbeit geplant hatte, die man (noch) nicht machen konnte, daher zu "schnell" war

Hintergrund: Look&Feel der Anwendung sind noch nicht final definiert. Interaction-Designer und Usability Experten arbeiten noch daran, trotzdem hat das Team im Sprint 1 bereits Funktionalitäten entwickeln könnnen, allerdings ohne visuellen Aspekt. Strenggenommen sind diese User Stories nicht DONE. Daher hat das Team eine virtuelle Persona konzipiert (Design-Checker) und eine User Story angehängt, die zur GUI Implementierung in einem späteren Sprint genutzt werden soll. Geplante und verschobene Aufwände/Tasks aus Sprint 1 wurden dort angehängt. Dieser Umstand erklärt den schnell Fortschritt.

Desweitern wurde durchleuchtet, warum das Team mit 31h Restguthaben in der verfügbaren Zeit mit 142h abrechnen konnte, obwohl nur 132h geplant waren. Ein Grund liegt auf der Hand: wir haben mit einem 6h-Tag geplant und kommen daher bei den verfügbaren Ressourcen auf 132h, worst case Szenario quasi. Ein anderer Grund war, dass die geplanten Ressourcen im Verlauf des Sprints nicht eingesetzt werden konnten. Eine Rahmenbedingung, deren man sich bewusst war, daher die 6h-Tag Planung.

Retrospective:

Was war gut?

• Vorbereitende Arbeiten waren sehr gut , z.B. Infrastrukur war bereits da, als das Projekt im Sprint 1 begonnen hat
• Dokumentation im Wiki ist sehr gut, so findet man das verteilte Projekt Know-How
• ein Biergarten Besuch ;-)
  
• sehr guter Austausch im Team- man weiss praktisch immer, woran alle arbeiten
• Review ist sehr gut, verteilt das Wissen im Team, man lernt viel
• Daily Scrum wird als nüztlich empfunden, er ist kurz gehalten, fokussiert
• Product Owner ist zufrieden mit der Arbeit

Was können wir besser machen?

• Stunden aufschreiben! Am Sprint Ende war nicht ganz klar, wieviel Stunden wir aufgewendet haben
• Einschränkungen, Editierbarkeit im GUI bitte disuktieren, nicht einfach machen - z.b. nach Daily Scrum
• Was haben viele Tasks, die keine Story haben z.B. Testumgebung aufsetzten. Was machen wir damit?

Die Stimmungsbarometer untermauern den aktuellen Befund - alles im grünen Bereich!

Zurück zum Sprint Burndown Chart und Taskboard
Demnächst: Sprint 2 Planning Meeting

Der agile Mentor - Planning Meeting Sprint 1

Im Anschluss an die Retrospective von Sprint Zero kam der eigentlich wichtige Teil, zumindest für mich. Mein nächstes Ziel war es, eine Aufwandschätzung vom Team zu bekommen, um einen Sprint planen zu können. Damit das gesamte Team hinter diesem Ziel steht, habe ich eine List angewandt: Wir haben geschaut, was im Sprint Zero realisiert werden konnte. Bis zu diesem Zeitpunkt wurden keine User Stories verwendet, also haben wir die abgeschlossenen Arbeitspakete im Plannungstool einfach mal zusammengezählt: 21 von 26, nicht schlecht! Oder doch?

Also fragte ich,

• ob dass ein gutes Ergebnis sei? - konnte man nicht richtig beanworten, wahrscheinlich schon
• hatte man sich über-committed? - konnte man nicht richtig beantworten, eher nicht - es sind ja ständig neue Dinge dazu gekommen
• wieviel Aufwand steht hinter 21? - konnte man nicht beantworten
• warum wurde 26 nicht erreicht? - ja, man hätte noch viele Dinge gemacht, die man da nicht sehen könne
• wo stehe man denn im Hinblick auf den Endtermin - konnte man nicht beantworten, eher so ein Bauchgefühl

Viel Verwirrung - und ich kam mir vor wie ein Lehrer vor seiner 8.Schulklasse, der eben verkündet hat, dass man auf der Klassenfahrt kein Alkohol trinken darf, toll!
Was soll denn das? Wo führt das hin? Warum müssen wir das tun?

Ratlosigkeit! Nach ein paar Sekunden Schweigen habe ich vorgeschlagen, dass wir die kommenden zwei Wochen planen (hatten wir bei Sprint Zero nicht gemacht). Wir wollen uns gemeinsam ein Ziel setzten und dieses erreichen und - viel wichtiger - wir wollen wissen, was wir in zwei Wochen erreichen KÖNNEN

Wir befragten das Plannungstool - was gibts überhaupt noch zu tun?

Schnell wurde festgestellt, dass man im Planungstool Tasks, Issues, Bugs, Packages, Components, SubTask u.v.m. auf gleicher Ebenen behandelt und viele Zusammenhänge, z.B SubTask --> Tasks --> Components bestehen. Ausserdem fehlte die Aufwandschätzung pro Arbeitspaket, unabhängig von der Granularität. Von meinem Standpunkt aus sah das alles unübersichtlich aus. Ich konnte mir absolut kein Bild darüber machen, was noch getan werden musste und wie Arbeitspakete zusammen hingen- keine Ahnung, und ich war nicht allein! Also beschloss man, schnell ein paar Arbeitspakete zu eleminieren und zusammenzufassen - eben aufräumen.

Ich beobachtet das Geschehen und so langsam wurde mir klar, dass das Plannungstool eher ein Gedächtnisstütze jedes Einzelnen war. Alles, was einem so eingefallen ist bei er Bearbeitung von Issues, wurde als Task, SubTask, Component, Issue oder was auch immer hinuzugefügt. Damit änderte sich die Menge und Inhalt der Informationen im Tool quasi stündlich. Das Plannungstool diente der Dokumentation.

Planung? Auf dieser Basis unmöglich!

Nach der Bereinigung verständigte man sich auf eine Entität für planbare Arbeitspakete im Plannungstool - Task. Components, SubTasks, Issues und alles andere sind Dokumentation, Tasks sind Arbeitspakete, planbare Arbeitspakete.

Ok, ich gab dem Team die Aufgabe, für die nächsten Tasks die Aufwände zu schätzen. Was die nächsten Tasks sind, sollte das Team selbst entscheiden. Ich beschäftigte mich damit, die verfügbaren Ressoucen abzuklären.

Am Ende beschloss das Team Arbeit für 184h anzunehmen.

Zürück zur: Retrospective Sprint Zero
Weiter zur: Retrospective Sprint 1

Der agile Mentor - Retrospective Sprint Zero

Nachdem im Sprint Zero der Daily Scrum von Team eingeführt wurde, lebte die Kommunikation auf - in manchen Punkten mussten Teammitglider sogar gebremst werden. Im Grossen und Ganzen haben wir es erreicht nicht mehr als 15 min pro Daily Scrum zu nutzen.

Vierzehn Tage später, am Ende von Sprint Zero plante ich eine Retrospektive, um den Puls des Teams zu fühlen. Dabei wurden folgende Punkte mit Verbesserungspotenzial festgehalten:

• Daily Scrum schweift teilweise ab
  
• AJAX Exception Handling fehlerhaft
• Close Event bei Lightboxe löst einen Reload aus - Usability!
• viel unused Code, viel FIXME und TODO
• Testabdeckung mangelhaft
• Exception bei Suche
• Wireframe zum Task - Wo liegt der? Bessere Vorbereitung!
• Tooling und Infrastruktur Handling kompliziert

Ok, gut!

Wir haben die Punkte angesehen und ein paar herausgenommen, die im kommenden Sprint 1 verbessert werden können.

Zurück zu: Sprint Zero
Weiter zum: Planning Meeting Sprint Zero

Sprint Retrospective

Scrum, ein Management Framework für agile Software Entwicklung, definiert Rollen, Rituale und Artefakte und den Zyklus

Plan->Do->Reflect->Improve

Für jeden Zyklus gibt es ein Ritual: Sprint Planning, der Sprint, Sprint Review und Sprint Retrospective.

Die Sprint Retrospective soll reflektieren, wie ein Sprint gelaufen ist. Die Sprint Retrospective wird meistens im Anschluss an den Sprint Review durchgeführt.
Das gesamte Team wird eingeladen, der Product Owner ist anwesend, der Scrum Master moderiert. Andere Stakeholder sind willkommen, allerdings nur als Zuschauer.

Während der Sprint Retrospective sollte das Team:

• Das Product-Burndown Chart auswerten. Wie ist es gelaufen? Hat das Team in diesem Sprint geliefert, was geplant und angenommen wurde? Man kann die aufgewendeten Stunden des Sprints im Vergleich zu den User Stories setzen und mit vorherigen Sprints vergleichen und graphisch darstellen. Das Team sollte Schwankungen im Graph untersuchen und erkennen, ob man besser oder schlechter wird. Das Warum sollte herausgefunden werden.
  
• Die Team Velocity auswerten. Zur Ermittlung der Velocity (Geschwindigkeit) summiert man alle Story Points des Sprints, die mit DONE abgearbeitet wurden und setzt sie in Relation zu dem Total aller geschätzten Story Points im Product Backlog. Das kann man graphisch darstellen und erhält über mehrere Sprints einen Trend. Dieser Trend ist sehr wichtig für das Sprint Planning. Die Velocity ist ein Anhaltspunkt für die Arbeit, die ein Team für einen Sprint annehmen kann. Das Team sollte auch hier Schwankungen in der Kurve hinterfragen, Überstunden berücksichtigen und den totalen Aufwand errechnen: Wieviel Stunden wurden effektiv aufgewendet? Was wurde geliefert?
  
• Diskutieren, was gut gelaufen ist. Jedes, wirklich jedes Teammitglied hat Erfahrungen gemacht, die jetzt ausgewertet werden sollten. Positive Punkte werden jetzt hervorgehoben. Es wird sichergestellt, dass diese im nächsten Sprint wiederholt werden können.
• Diskutieren, was nicht so gut gelaufen ist. Punkte, die vom Team in diesem Sprint als nicht so gut erachtet werden, sollten auf den Tisch gebracht werden. Es ist wichtig, das Warum herauszufinden, um die Ursache im kommenden Sprint abzustellen.
• Entscheiden, was im nächsten Sprint verändert wird. Das Team sucht sich ein paar wenige Dinge heraus, die im kommenden Sprint anders gemacht werden sollen. Das sollten aktive und realistische Punkte sein, die auch wirklich in einem Sprint verändert werden können.

Das ist ein kontinuierlicher Lernprozess.

Die Sprint Retrospective ist kein auferlegtes Muss vom Management. Hier ist das Team auf sich gestellt - selbstorganisierend und selbstregulierend.

Scrum Projekt Abschluss

Wir schreiben die 10. Woche im aktuellen Scrum-Projekt und nach der Auslieferung von Release 4.0. am 18.Juni geht das Projekt dem Ende zu.
Momentan gibt es noch ein paar Abnahmen mit dem Kunden und die Inbetriebnahme beim Provider. Dannach ist das Projekt abgeschlossen. Zeit, mal ein paar Zahlen zu generieren:

Zeitraum: 13. April bis 18. Juni, 47 Arbeitstage
Team: 4 Developer, 1 Product Owner, 1 Scrum Master

# Story Points: 80 PT
Gesamtaufwand: 188 MT (47 Tage x 4 Developer)

# Sprints: 5, davon 1x 3 Wochen, 2x 1 Woche, 2x 2 Wochen
User Stories/Sprint: 9PT/1, 1PT/2, 26PT/3, 23PT/4, 21PT/5
Durschnitt/Sprint: 16 PT pro Sprint

# Releases: insgesamt 4
User Stories/Release: 9PT/1, 27PT/2, 23PT/3, 21PT/4
Durchschnitt/Release: 20 PT pro Release

# Bugs: 24

Ok, der Blick zurück - jetzt wird's interessant. Wie wurde denn das gesamte Projekt vor Beginn vom Team geschätzt?

Insgesamt wurden 50 Story Points für die gesamte Realisierung VOR Projektbeginn geschätzt. Aus Erfahrung aus anderen Scrum Projekten ist man von 2.5 MT pro 1 SP ausgegangen. Das ist die Basis für die Schätzung. Mit einer pessimistischen und optimistischen Abweichung kann man den Know-How Gap vom neuen Projekt ein bischen ausbalancieren. Mit einer Abweichung von -25% und + 40% kommt man dan bei optimisticher, realistischer und pessimistischer Schätzung auf:

Mit heutigem Wissen kann man dass richtige Verhältniss MT pro User Story leicht errechnen:

Die Aufwandschätzung lag also im realistischen Bereich oberhalb der +40% Grenze!!! Mehr als doppelt so teuer! Die berichtigte Aufwandschätzung sieht wie folgt aus:



Bleibt die Frag offen, wieso 50 SP geschätzt und doch 80 realisert worden..... Das genau ist der Vorteil von agiler Entwicklung. Ein mal mehr war der Kunde "moving target" - d.h. er hat seine Prioritäten im Projekt verlangert, neue Ideen eingebracht und andere verworfen.

Sprint 4 Retrospecitve

Im Sprint 4 hat sich herauskristalisiert, dass die Eigenverantwortlichkeit vom Team nicht unbedingt mit guten Consulting beim Kunden einher geht. Der Scrum Master versteht seine Rolle als Coach und Schiedsrichter, er ist also inhaltlich beim Produkt nicht Ansprechpartner. Der Product Owner bringt wenig visionäre Ansätze ins Team und somit ist die Produktentwicklung schleppend. Das Team stellt den Antrag, einen Produkt Manager auf der Seite des Anbieters zu stellen, der dem Kunden mit Visionen und strategischer Aussichtung des Produkts behilflich ist ... es gibt eine neue Rolle im Scrum!

Was war gut:

• Team arbeitet sehr selbständig
• gute Zusammenarbeit
• GUI hat eine neue Richtung eingeschlagen - Web 2.0
• Entscheid: TargetProcess soll eingeführt werden und Excel ablösen
  
• Viele "Should be in" wurden realisiert
  

Was ist verbesserungswürdig:

• Sprint Planning Meeting erneut schlecht vorbereitet (vom Kunden und Team)
  
• Kommunikation mit Kunden wird schlechter, Briefings sehr schlecht
• Mangelndes Consulting vom Team beim Kunden
• viele, kleine User Stories, die das Produkt nicht weiter bringen
  

Massnahmen:

• User Stories für den kommenden Sprint müssen vor dem Planning Meeting vorliegen
• Mehr Consulting Leistung vom Team, neue Rolle: Product Manager wird vom Team gestellt
• Product Owner zum Sprint Retrospective Meeting einladen
  

Sprint 3 Retrospective

Der Puls schlägt höcher - das so im allgemeinen die Tendenz.

Das Team findet im Kern, dass die Aufgaben sehr gut abgearbeitet wurden. Die Stimmung ist gut.

Was war gut:

• Scrum Methodik hat sich langsam etabliert, Routine
  
• Sehr gute & schnelle Release-Auslieferung
• Ein neuer Mitarbeiter wurde innerhalb kurzer Zeit eingearbeitet

Was ist verbesserungswürdig:

• Schätzung der "Must be in"Story Points zu ungenau -> Viele "Should be" in abgearbeitet
• Dokumenten-Dschungel im Wiki - Reorganisation notwendig
• Zu viele Meetings mit zu vielen Excel Problemen
• Product Owner ist am Planning Meeting nicht gut vorbereitet

Massnahmen:

• Crash Course-> User Stories Applied für bessere Estimation
• Excel als Planning Tool abschaffen
• Wiki Reorganisieren
  

Sprint 2 Retrospecitve

Sprint 2 war ein guter Sprint. Das Team "kämpft" mit der Methodik. Inhaltlich wird am Produkt nicht viel entwickelt - Scrum steht im Zielfeuer...

Der Product Master hat zu schlichten und das Team auszurichten.

Was war gut:

• Gute Auslastung und Zusammenarbeit im Team
• Planning und Estimation sehr gut dokumentiert
• Meetings werden pünktlich aufgesucht, immer vollzählig
• Team arbeitet selbständig
• "Should be in" Task wurden vom Team im Sprint zugewiesen und angenommen
• Gute Doku im Wiki
  

Was ist verbesserungswürdig:

• User Stories kommen zu spät vor der Estimation ins Team - Vorbereitung notwendig
• User Stories vom Product Owner ungenau
• Produckt Backlog inkonsistent (Excel)
• Kunden vom Test Director abbringen, da er dort User Stories erfasst
• After Scrum Sitzung oft endlos und ohne Ziel, keine Moderation
• Testing nicht instituionalisiert
  

Massnahmen:

• Sitzungsabläufe werden neu festgelegt
• Ziel und Zeit pro Sitzung im After Scrum, Moderator
• Team physisch zusammenlegen (bislang verteilt)