Die Bugspringflut vor dem Livegang

...oder wie man mit Fehlern umgeht, die erst kurz vor dem Relaunch auffallen. 

Ich bin viel unterwegs. Berate hier, gebe Schulungen da oder leite ein Projekt wieder woanders. Ich habe somit oft Einblick in die Arbeit anderer Scrum Teams. Man trifft auf tolle bunte Scrumboards, unterschiedliche „Definition of Done“- Aushänge und eine sehr unterschiedliche Art und Weise Scrum zu verstehen. Vor allem der agile Ansatz gerät in vielen Fällen an der einen oder anderen Stelle unter die Räder. Einen davon habe ich mir heute ausgesucht: Die Bewältigung der Bugflut vor einem Relaunch. 

Was ist Scrum für mich?Scrum ist eine agile Methode, um Software zu entwickeln. Sie soll helfen Arbeit sichtbar zu machen. Vorhersehbare Arbeiten zu planen und auf unvorhersehbare Arbeiten besser reagieren zu können. Scrum bietet einen Prozess an, der sich selbst reflektiert und flexibel auf Anforderungen reagieren kann. Scrum fußt auf Iteration, Reflektion der eigenen Arbeit und ist leicht, leicht anpassbar und agil...

Agilität... die meisten Scrum Teams kommen bis zu diesem Punkt. Iteration, Standup, Definition of Done, Testing, Retrospektive... wunderbar... klappt prima, wenn da bloß die blöden unplaned Tickets nicht währen! Hier trennt sich der agile vom statischen Scrum.

Bei einem der letzten Relaunches, die ich begleitet habe, sagte jemand zu mir: „Super Relaunch, tolle Software, schöne leise unspektakuläre Umstellung, nur das Bugfixing kurz vor Toressschluss hätten nicht sein müssen. Das hätte man doch vor Wochen schon testen können.“ 

Hmmm... einer Redaktion ein neues Werkzeug und ein neues Layout für „ihre“ Website an die Hand zu geben und zu erwarten, dass sie mit Dummyseiten alle Fehler entdecken, ist nach meinen 11 Jahre Erfahrung mit Redaktionen eher unwahrscheinlich. Sie finden die Fehler in dem Moment, wo sie anfangen „echte“ Inhalte einzugeben. Also kurz vor dem Relaunch. Blöd für die Technik, aber hilft nix.

Und damit ist es eigentlich auch planbar, wenn man tatsächlich einen agilen Prozess hat.

Wie kann ein Scrum Team mit Relaunch-unplanned-Ticktes also umgehen, ohne schlechte Laune zu bekommen? Agil! 

Wir wissen, dass die Redaktion Fehler findet, die wir als Nicht-Redakteure nicht sehen und auch noch 1-fix-2 Funktionen oder Anwendungen benötigt, die noch gar nicht oder nicht richtig umgesetzte sind. Ist einfach so. Hier ist als erstes zu klären, was vor dem Relaunch noch umgesetzt werden soll. Die Redaktion will meist alles, aber in Kooperation mit den Beteiligten Product Owner, Scrum Master und Redaktion lässt sind oft raus schälen, was zum RL fertig sein muss und was noch bis ein, zwei, drei Wochen nach dem RL Zeit hat. Spätestens an dieser Stelle sollte erneut zusammen festgestellt werden, dass bei dem Relaunch um ein Gemeinschaftsproduktion geht, die ohne die anderen Beteiligten unmöglich ist, man Respekt vor der Arbeit des Anderen hat UND man am Relaunchtag eine runde, funktionstüchtige Website am Start haben möchte. Die Waffen, um die Schlacht erfolgreich zu schlagen, sind vor allen anderen kommunikative. Zudem muss der Fokus, auch der des Scrum Teams, auf das gemeinsame (Sprint-)Ziel gerichtet werden. In diesem Fall „Eine runde Website relaunchen“.

Um der zu erwartenden Bugfix-Flut (meist in der Ausspielung) her zu werden, senken wir in den letzten zwei Wochen vor dem Relaunch den Velocity-Faktor um ca. 10% und versuchen schon bei der Sprintplanung mitzudenken, welche Tickets aus dem Sprint fallen werden, wenn es mehr als 10% ungeplante Tickets werden. Wir (in letzter Instanz der Product Owner) achten also auf eine genaue Priorisierung. Ziel des Sprints ist es „eine runde Website zu launchen“.

In dieser „Heißen Phase“ eines Relaunches wird es oft hektisch, man ist manchmal auch nicht mehr so freundlich zu einander, aber eines der wichtigsten Dinge in dieser Zeit ist die Kommunikation zwischen Redaktion(Kunde), Product Owner Scrum Master und Scrum Team. Und das über die definierten Wege, um eine Priorisierung der Anforderungen/Bugs über den Product Owner zu ermöglichen. Der Product Owner taktet die unplaned Bug-Tickets in den Sprint ein und niemand anders. Was rausfallen wird, haben wir ja ggf. bei der Sprintplanung schon berücksichtigt.

Meine Rolle als Scrum Master unseres Teams ist es, das Team mit mir allen zur Verfügung stehenden Mitteln gut gelaunt am Arbeiten zu halten. Vor allen Dingen Infos besorgen und nicht das Gefühl zu vermitteln, dass die 77+X Tickets mich nun überraschen würden. :-)

(Über die Rolle des Scrum Masters im Team schreibe ich eventuell einen weiteren Beitrag. Es würde diesen Blog-Beitrag sprengen. ) 

Was in der heißen Phase gerne passieren darf: Der Kunde/die Redaktion, der Product Owner oder der Scrum Master nimmt die Kommunikation zu den anderen Beteiligten auf und fragt nach, ob alles gut ist, was als nächstes Ansteht und was am Wichtigsten ist. Die besten Fragen, die man in so einer heißen Phase stellen kann sind: „Wie kann ich dir/euch am besten helfen? Was brauchst du/ihr, um weitermachen zu können?“ 

Was in der heißen Phase nicht passieren darf:

Wenn das Scrum Team schlechte Laune bekommt, weil sie „so viele Bugs“ rein bekommen, ist was falsch gelaufen. Es sind nicht viele Bugs, sondern das Team wurde nicht darauf vorbereitet. Scrum kann das händeln, ist aber nur so agil, wie alle Beteiligten.

Hier noch die zweite der zwölf agilen Prinzipien:

„Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." (http://agilemanifesto.org/principles.html)

Viele Grüße Miriam Stroetmann, Scrum Master

Miriam Stroetmann

Miriam Stroetmann

Tue Jan 25 16:31:00 CET 2011 • Tue Jan 25 16:31:00 CET 2011

Agile