Seit Anfang des Jahres setzen wir nun SCRUM ein, wobei es, wie man jetzt merkt, doch nur SCRUMBUT war.
I call that phenomena “Scrumbut”. It shows up in the following way:
“We’re doing Scrum but…”
* our sprints are 12 weeks long…
* we do two normal sprints and one bugfix sprint…
* we do all our planning up front…
* we skip the daily meeting…
* our managers decide what’s in each sprint…
* we haven’t read the books yet…
* our team has 30 people…
http://blogs.msdn.com/ericgu/archive/2006/10/13/scrumbut.aspx
Auch bei uns wurden Anpassungen an SCRUM durchgeführt, was dazu geführt hat, dass die letzten Sprints immer schlechter wurden. Gerade die Retrospektive wurde fast nie durchgeführt, da es angeblich nichts zu besprechen gab.
Wir sind nun in Sprint 21 und nach 2 Open Spaces um ausreichenden Erfahrungsaustausch reicher. Wir halten wieder die Retrospektive-Meetings und bei dem letzten haben wir folgende Anpassungen beschlossen:
- Es wurde eine “Definition-of-done” Richtlinie am Whiteboard erstellt.
- Pair-Programming wird häufiger eingesetzt.
- Zu jedem Backlog-Item werden gemeinsam die Architekturveränderungen und die notwendigen Tasks besprochen. Bisher wurde mit den Produkt-Backlogkarten direkt gearbeitet.
Ich rate allen, die SCRUM einführen wollen, sich wirklich so nah wie möglich an SCRUM zu halten. Die Sprints 1 – 15 wirkten bei uns auch sehr gut, doch erst danach fiel uns auf, dass gerade die Sprint-Retrospektive ein sehr wichtiges Meeting ist. All diese Regeln sind durch mehrjährige Erfahrungen entstanden und sie haben sich schon in größeren Firmen bewährt. Warum dann nicht davon profitieren?
Einträge (RSS)
Ja, dass kenn ich nur zu gut. Wenige Regeln, schön! Doch damit ist jede menge Arbeit an der Disziplin nötig. Daher bestätigt sich hier meine Erkenntnis – Jedes noch so kleine Element von SCRUM ist zum erfolgreichen umsetzen Elementar nötig. Hier und da was weglassen!? Geht nicht! Meine manchmal schmerzlichen Erfahrungen zeigten mir eben auch; Akzeptanz- oder ‘Done’ -Kriterien auf, oder neben, den User Stories sind ein äußerst wichtiges Artefakt zur Reflektion und Kommunikation zwischen Team und Product Owner. In diesem Sinne, wie heißt es so schön: -Kontinuierliche Weiterentwicklung von Software und Entwicklungsprozess-! Banzai!
@MikeBild: Genau, so sehe ich das mittlerweile auch. Kontinuierliche Weiterentwicklung – Die Akzeptanzkriterien sollten wir bei uns auch noch genauer definieren.