Erfolgreich dank Scrum, oder doch nicht?

Man stelle sich vor - man trainiert, arbeitet hart an sich, bereitet sich gut vor und dann kommt endlich der lang ersehnte Tag des Marathons, 42 km - los gehts! Man checkt immer wieder die Zeit, passiert die Zwischenstation, schaut sich um - wer ist vor mir, wer ist neben mir und dann, plötzlich ist der Zieleinlauf in Sichtweite - 5 sec. 4 sec. 3 sec. 2 sec. 1 sec - ZIEL! Der Blick zur Uhr - Enttäuschung und ziemlich genau das emfpand ich nach Abschluss des letzen Scrum Projekts.

Um den getrübten Eindruck mit meinem Team zu teilen haben wir das thematisiert und – ich war völlig überrascht – das Entwicklerteam hatte einen weitaus positiveren Eindruck als ich. Das konnte ich kaum glauben und habe versucht herauszufinden, warum ich das anders sah.

Ich stellte dem Entwicklerteam die Frage, warum das Projekt rückblickend so positiv für Sie war. Die Erkenntnis - durch unserer Vorgehen wurde ein Prozess vorgeben, den man bislang vermisst hatte. Es wurden Code Reviews durchgeführt, Pair Programming, automatisiertes Testen, Don’t-repeat-yourselves und damit verbunden aktives Refactoring, Visualisierung der Arbeit mit deren aktueller Status, Wer macht Was im täglichen Meeting und vieles mehr. All das wurde positiv bewertet. Gut!

Fast schon überwältigt habe von den positiven Schwingungen musste ich mich also Fragen – warum empfandest Du das anders als das Team? Nun, ich musste nicht lange überlegen, fand eine Reihe Argumente Warum aber sah das Team das anders?

Ich realisierte, dass mein Team und ich nicht vom selben sprachen: Scrum und agil!

Was das Team in dem Projekt erstmals angewendet hat, waren verschiedene Praktiken aus eXtreme Programming (XP), und zwar iterativ. Scrum hingegen ist nach meiner Interpretation, eher ein Framework für agile Software Entwicklung, genauer: ein Management Modell für agiles Vorgehen und genau hier haben wir extreme Abstriche gemacht.

Wir hatten keinen richtigen Product Owner, aber einen internen Projektleiter, der den Kunden „gespielt“ hat. (Proxy-Customer) Wir hatten keinen ScrumMaster. Diverse Scrum Rituale wurde, auch aufgrund der fehlenden Rollen und deren Aufgaben, weggelassen. Es gab Arbeiten, die von Personen erledigt wurden, deren Zugehörigkeit zum Team nicht gegeben war.

Subtrahiert man das alles von der Scrum Theorie, was bleibt dann übrig?

• Big Bang Delivery am Projektende, statt regelmässiges Feedback mit kurzen Release Zyklen
  
• Kein Feedback vom Kunden während der Realisierung, nur interner Input
  
• Keine Priorisierung der Arbeit , da keine wirkliche „Business Value“ Beurteilung
• Keine Früherkennung von „Fehlern“, da kein Feedback
  
• Kein ROI Bewertung während der Entwicklung, da kein Feedback
  
• Fragen und Abklärungen nur über Dritte, kein direkter Kundenkontakt
• Sequentielles, phasenorientiertes und teilweise unabgestimmtes Vorgehen

Kurz –das ist nicht agil, das ist kein Scrum!

Was haben wir daraus gelernt?

Bei den Software Entwicklern kommt XP und iteratives Vorgehen gut an, es macht ihnen Spass und Scrum ist kein Scrum, solange:

• kein "richtiger" Product Owner am Tisch sitzt und Scrum aktiv lebt
• nicht alle notwendigen Ressourcen „scrumisiert“ sind und sich zum Team bekennen
• solange man kein fixed time, fixed scope und fixed budget vorfindet
• wenn bereits (zeitlich) früher gelagerte Projektphase durchlaufen wurden, z.B. Analyse, Grobspezifikation, Detailspezifikation, Design, etc

Treffen die genannten Punkt zu,

1. ist das Ökosystem nicht Scrum kompatibel
2. kann man die Realisierung(-sphase) mit XP Praktiken empfehlen

69er - Projektende

Heute, nach nunmehr 4 Sprints à 2 Wochen ist das 69er Projekt zu Ende.

In Ruby gibt ein Prinzip: DRY - Don't repeat yourselves - und gemäss DRY möchte ich die Dokumentation vom 69er Projekt hiermit beenden, ich würde mich nur wiederholen. Trotzdem möchte ich noch ein Resümee ziehen und ein paar Zahlen zeigen, z.B. das Product Burndown Chart:

Im 69er Projekt wurden total 88 Story Points realisiert, im Schnitt 22 Story Points pro Sprint. Geplant war zu Beginn eine Velocity von 20 SP's pro Sprint. Das Team hat geliefert - das Backlog ist leer und wir haben noch ca. 20% Budget.

Heute, am Demo Day von Sprint 4 löst sich das Team auf, die Entwicklungen sind eigentlich abgeschlossen. Der Product Owner war anwesend und letztendlich haben wir heute ein Abnahme gemacht. Es wurden noch ein paar Dinge aufgenommen, die nachgebessert werden sollten ... Klingt nach einem neuen Sprint? Hm.

Bislang habe ich im Projekt ein bischen die Kappe des Scrum Masters aufgehabt und das Team "geführt", sobald man vom agilen Vorgehen abgekommen war. Mühsam, aber unter dem Strich sehr wichtig. Da ich bisher davon überzeugt war, dass neben mir auch andere im Team den agilen Prozess verinnerlicht haben und durchaus gewillt sind, so zu arbeiten, habe ich mich heute in der Retrospective als "Moderator" zurückgehalten und das Team machen lassen.

Kurz gesagt: ich war entäuscht. Niemand hat die Funktionalität gezeigt, die im Sprint 4 entwickelt wurde. Stattdessen war "hm, was haben wir denn alles so gemacht" rum-geklicke angesagt. Viel unötige Diskussionen, Fragen zur Spezifikation und Feedback bzw. Änderungswünsche. Darüber hinaus wurde keine Retrospective gemacht.
Die anstehenden Arbeiten wurden nicht genauer besprochen, in Tasks zerlegt, geschätzt, priorisiert - eben all das, was wir nunmehr 3 Sprints durchgezogen haben. Ich hätte erwartet, dass man eine Sprint 5 Planung macht und dem agilem Vorgehen weiter folgt. Naja.

Da kommt mir die einleitender Aussage von der Projektleitung zu Beginn des Projektes in den Sinn - sie ist zieht sich durch das gesamte Projekt:

"Wie ihr das macht, ist egal. Es muss am Ende nur funktionieren."

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 - Sprint 3 Planning & Estimation Meeting

Der 3. Sprint im 69er Projekt steht an und es gilt erneut: Team, let's plan!, ABER bei diesem Planning & Estimation Meeting gibt es eine Besonderheit, die ich in meinem agilen Dasein bisher auch noch nicht erlebt habe - der Product Owner ist nicht anwesend.

Wir haben vom PO mit auf dem Weg bekommen, dass auch im kommenden Sprint der Schwerpunkt auf dem User Interface liegen soll, denn nach nunmehr etlichen Iterationen beim Design haben wir eine finale Version, endlich.

Ok, wie sieht es mit den Ressourcen aus?


Plannning & Estimation

Da wir in diesem Sprint nicht so viel verfügbare Ressourcen haben, geht das Team mit weniger geplanter Arbeit in den Sprint. Nimmt man den Durchschnitt aus Sprint 1 und Sprint 2 beträgt die Velocity bisher 23 Story Points/Sprint. Um den limitierten Ressourcen Rechnung zu tragen, wollen wir 20 Story Points annehmen.

Das Team geht Story für Story aus dem Backlog durch und fragt zunächst, ob alle Fragen benantwortet sind, oder anders gesagt, wissen wir, was hier die Aufgabe ist. Wenn nicht, wird das an der Story vermerkt und diese zurückgelegt. Der interim ScrumMaster geht diesen Stories im Sprint nach und klärt die Fragen.

Gut, nachdem alle Stories im Backlog sortiert wurden nach klar und unklar, beginnt das Team die Arbeit zu schätzen. Dabei werden pro User Story kurz die Task herausgebrochen (nur grob) und überschlagen. Am Ende kommt man auf die Story Points pro User Story.

Und so sieht Sprint 3 aus:

Das Team hat 20 Story Points angenommen. Diese 20 SP's entsprechen ca. 81h Arbeitsaufwand. Verfügbare Arbeit ist 78h, d.h. wir haben ein kleines over commitment.

[Update]

Weiter zur Sprint 3 Retrospective

Zurück zur Sprint 2 Retrospective

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