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

Der agile Mentor - Sprint 0

Nachdem ich mich mit der Projektsituation und der Arbeitsweise des Team vertraut gemacht hatte, brauchte ich einen Plan - ganz entgegen den Scrum Prinzipien.

Zunächst gab es vier Punkte, die ich dem Team nahebringen wollte:

1. tägliche Status-Meetings (max. 15 min)
2. fokussiertes Arbeiten im 2 Wochentakt - wir wollen alle 2 Wochen etwas produzieren
3. Aufwandschätzungen zu den Arbeitspakten vom Team
4. Planung der kommenden 2 Wochen

Um diesen Plan umzusetzen und das Commitment vom Team zu bekommen habe ich ein Meeting zu einem Kaffee einberufen. Bereits nach wenigen Argumenten waren das Team dafür, dass man tägliche Statusmeetings einführen sollte, denn oft gingen wichtige Informationen unter oder waren nicht für jeden im Team verfügbar. Da das Team räumlich eng beieinander sass, machten wir die die Stand-up's an einem Arbeitsplatz, wer nicht da war nahm per Skype teil.

Mehr nicht! Das war die erste und einzige Neuerung. Als nächstes wollte ich den 2 Wochen Takt inklusive Planung einführen. Ich hatte etwas Zeit gewonnen, die nächsten Punkte vorzubereiten.

Was daraus wurde und was das Team von den Stand-up's hielt, sollte ich in der ersten Retrospective erfahren.

Dranbleiben!

Zurück zur: Scrum Einführung
[Update]
Weiter zur: Retrospective Sprint Zero

Der agile Mentor - Scrum Einführung

Vor kurzem wurde ich bei einem externen Projekt als agiler Coach hinzugezogen. Bei diesem Team hatte ein Entwickler bereits Erfahrungen mit Scrum. Es wurde der Wunsch geäussert, nach Scrum vorzugehen. Der zuständige Projekt Manager überliess diese Entscheidung dem Team und so arbeitete man nach Scrum. Kurz vor dem ersten Release wurde ich als Entwickler und agiler Mentor hinzugezogen.

Nach wenigen Tagen ergab sich folgende Bild:

Vor dem Projekt wurde ein detaillierte Spezifikation geschrieben, die zum Projektbeginn von einem Entwickler in Arbeitstasks runtergebrochen wurde, ohne Aufwandschätzung. Der Endtermin war fix. Man zerlegte die Realisierungzeit in kleine Teil-Releases und verteilt die Arbeitspakete (gleichverteilt, x Tasks pro Release). Daraus abgeleitet ergab sich eine grobe Releaseplanung bis zum Projektende. Verschiedene Elemente von Continous Integration wurde installiert: Version Control, Build Server, Unit Testing. Rollen, Regel und die Scrum Rituale, Planning & Estimation Meeting, Sprints, Demo, Retrospective und Daily Scrum wurden nicht angewendet. Der Kunde, in seiner Funktion als Product Owners oder im allgemeinen, war im Verlauf der Realisierung nicht involviert. Es gab eine ausführliche Definition von DONE, kaum jemand hielt sich dran. Wöchentlich wurden Status Meetings abgehalten. Als Projektmanagement und Entwicklertool wurde Jira eingesetzt. Wenige Wochen vor dem ersten Release wusste man nicht, ob man fertig würde. Zusammenfassend kann man sagen: kein agil, kein Scrum!

Ok, ich habe mir also eine Strategie zurechtgelegt, wie Scrum vom Team angenommen und vollumfänglich implementiert werden könnte. Grundsätzlich gab es zwei Optionen:

• Sofortige Scrum Einführung mit allen Ritualen, Rollen und Regeln, quasi "von jetzt auf gleich", oder
• Sequentielle Implementierung, nach und nach ein weiteres Element aufnehmen.

Aus der Erfahrung heraus schien mir die erste Option zu unrealistisch. Ein etabliertes, produktives Team ist alles andere als glücklich, wenn ein Aussenstehender ein neues Vorgehen einführt, dazu noch eines, was so radikale Veränderung mit sich bringt und kaum Akzeptanz findet. Ich entschied mich also für die zweite Option.

Als ich zum ersten Mal mit Scrum in Berührung kam, war ich in einem Projekt als Software Engineer tätig, was mässig erforgreich war. Der Kunde wurde mehrfach hingehalten, die Reaktionszeit war schlecht und die Bug Rate war sehr hoch. Die Projektleitung wurde ausgetauscht und mit der neuen Person kam ein neues Vorgehen - agil nach Scrum! Der ScrumMaster hat zu Beginn nur eine Regel eingeführt - wir wollen fokussierter arbeiten und alle 3 Wochen etwas nützliches produzieren.

Ich legte mir einen Plan zurecht - was daraus geworden ist und welche Erfahrungen ich gemacht habe?

Dranbleiben.