Die Einführung agiler Softwareentwicklung und von Scrum bei Heise, Teil 3

Inhaltsverzeichnis

Im dritten Teil unseres Blogbeitrags zum Thema Agile soll es um die Events gehen, die in unserem System fest in den Ablauf eingebettet sind. Vieles davon entspricht zumindest halbwegs dem, was in vielen Unternehmen ein agiles System ausmacht. Hier und da weichen wir aber sicherlich von der Norm ab.

Vorab: Die Angst der Entwicklerinnen und Entwicklern vor den zahlreichen agilen Events ist nicht ganz unbegründet. Denn sie sind wirklich zahlreich und insgesamt verbringen viele von uns jetzt wohl mehr Zeit in Meetings als vor der Umstellung. Aber: Die Events haben durchaus eine Daseinsberechtigung und ermöglichen in der Zeit, in der man wirklich entwickelt, einen wesentlich stärkeren Fokus.

Mehr Infos

Dieser Blogbeitrag ist Teil einer Serie

Hier sind die anderen Teile zu finden:

Teil 1 - Die agile Transition

Teil 2 - Rollen und Werkzeuge

Meiner Meinung nach MUSS aber mit der Einführung von Scrum oder Ähnlichem auch eine Änderung in der Meetingkultur einhergehen. Klare Ziele, Struktur, eine strikte Timebox und sofortiges Eingreifen beim Abschweifen sind jetzt wichtiger denn je. Das erfordert gerade anfangs eine gewisse Disziplin und einen aufmerksamen Scrum Master, geht aber zumindest bei einigen Events/Menschen irgendwann in Fleisch und Blut über.

Unsere Events im Einzelnen

Unsere Sprints dauern zwei Wochen. Unser Sprintwechsel fällt immer auf einen Dienstag. Echte Kalenderwochen zur Sprintaufteilung haben sich bei uns nicht angeboten, denn der Tag vor dem Sprintwechsel ist in der Regel Crunchtime voller Rollouts und die würden dann auf einen Freitag fallen.

Daily Scrum:

• tägliche Treffen vormittags
• im Stehen kurze Zusammenfassung geben
• Team, PO und Agile Coach
• 15 Minuten

Der Daily Stand-up gehört wohl in den meisten IT-Teams dazu und läuft bei uns wohl wie überall sonst auch ab. Reihum erzählen alle kurz und knapp, was sie tun und tun werden und ob sie irgendwas aufhält. Kolleginnen und Kollegen, die auswärts arbeiten, werden dort in die Runde mit eingebaut, wo ihre "Telepräsenz" steht. Das ist in der Regel ein iPad mit Bodenständer. Techniken zur schnellen Abstimmung ("Handzeichen auf drei" oder Ähnliches) nutzen wir ab und zu auch.

Sprint Review

• Alle zwei Wochen zur Eröffnung des Sprintwechsels
• Ein bis zwei Vertreter jedes Teams tragen an einem großen Display vor
• Alle Teams, POs und Stakeholder im Zuschauerraum
• 3 x 15 Minuten

Das Review wird in den Teams im Laufe des Sprints vorbereitet. In der Regel passiert das am Tag vor dem Sprintwechsel. Die Zuschauer wechseln in drei Gruppen von Team zu Team und bekommen dort jeweils die Ergebnisse des Sprints präsentiert und können Fragen stellen oder Feedback geben. Die Zuschauer setzen sich aus Stakeholdern, POs und allen anderen Teams zusammen. Bei uns sind Interessierte aus dem ganzen Verlag eingeladen teilzunehmen. Es sollte nach Möglichkeit versucht werden, echte Dinge im Einsatz am Fernseher zu zeigen. Wenn das ein RSS-Feed, ein ausklappendes Menü oder ein durchlaufender Integrationstest ist, dann ist das eben so.

Die vortragenden Teammitglieder können gewechselt werden, damit alle auch die Vorträge der anderen Teams sehen können.

Sprintplanning I/Das Pullen

• alle zwei Wochen nach dem Review
• am gemeinsamen Board werden Storys für den kommenden Sprint gezogen
• alle Teams, POs und Agile Coach
• 45 Minuten

Zunächst ermitteln wir, ob Storys, die aus dem aktuellen Sprint kommen, noch mit in den nächsten gezogen werden müssen. Für mich persönlich ist das immer eine kleine Niederlage. Diese Gamification-Anreize am agilem Arbeiten schlagen bei mir aber auch grundsätzlich ganz gut ein.

Anschließend werden die Storys aus dem Backlog nacheinander verlesen und noch mal kurz erläutert. Bei uns ist dann der Ablauf, dass sich einer aus dem Entwicklungsteam für sein Team meldet. Wenn es dann keine Einwände vom eigenen oder einem anderen Team gibt, ist die Story vergeben und die nächste wird verlesen.

Das geht so lange, bis sich niemand mehr meldet. In manchen Fällen wird noch mal umsortiert, weil sich Synergieeffekte ergeben. Manche Storys gehen einfach schneller, wenn sie in einem Team direkt hintereinander oder gar parallel bearbeitet werden.

Sprintplanning II/Der Task-Breakdown

• alle zwei Wochen am Sprintwechsel-Tag
• In den Teamräumen am Board
• Jeweils die Entwicklerteams nehmen teil
• Zeitaufwand variiert stark

Beim Task-Breakdown setzen sich die Teams meistens vor einem großen Display, das jemand bedient, zusammen und splitten die gezogenen Storys in einzelne Tasks auf, die dann als Klebezettel am Teamboard in der To-do-Spalte landen. Dabei wird bei uns auch schon häufig in den Code geschaut und verbal programmiert. Die Tasks werden vor dem Kleben im Idealfall noch mal genau erklärt, damit alle im Team eine grobe Ahnung von der Aufgabe haben. Die Tasks haben am Board in der Regel eine Reihenfolge. So muss man im Sprint nicht mehr drauf achten, ob schon alle Voraussetzungen für den Task erfüllt sind.

Task-Breakdown ist eine hohe Kunst. Es kann verdammt schwierig sein, die richtigen Stellen zum Zerschneiden einer Story zu finden. Mitunter ist dieser Schritt langwierig und sorgt für rauchende Köpfe.

Retrospektive

• alle zwei Wochen rund um den Sprintwechsel-Tag
• Besprechung des vergangenen Sprints
• Entwicklerteam, PO, Agile Coach
• etwa 1 h

Die Retrospektive ist bei uns die agile Therapierunde mit dem Scrum Master als Therapeuten. Es ist in unserer Retrospektive üblich, erst mal mit einem grundsätzlichen Stimmungsbild einzusteigen. Jeder markiert sich kurz mit einem Magneten in einem Schaubild und verliert ein paar Worten zum aktuellen Befinden.

Mit verschiedenen Techniken und (mal wieder viel Zettelkleben) werden dem Team und dem PO anschließend die Dinge entlockt, die genervt haben. Positives kann und wird aber natürlich auch erwähnt. Danach wird versucht, daraus Maßnahmen abzuleiten, die auch immer festgehalten werden oder ein Poster an der Wand bekommen, damit sie befolgt werden. Dadurch dass unser Agile Coach an allen Retrospektiven teilnimmt, kann sie teamübergreifende Maßnahmen in Gang bringen, wenn sich bestimmte Probleme in mehreren Teams herauskristallisieren.

Hier kann es auch mal arg menscheln und es ist immer ein bisschen Fingerspitzengefühl gefragt, denn manchmal hängen die Probleme ja auch mit Teammitgliedern zusammen. Im Grunde kann die Retrospektive dafür sorgen, dass sich das System dauerhaft selbst weiterentwickelt.

Backlog-Refinement

• alle ein bis zwei Wochen je nach Lage
• Ausgestaltung der Storys im Backlog oder früheren Stadien
• Entwicklerteam, PO, Agile Coach
• etwa 1 h

In der agilen Arbeitsorganisation ist es wichtig, dass die Storys alle gesetzten Voraussetzungen erfüllen. Diese haben die Teams in der "Definition of Ready" festgeschrieben. Das Backlog-Refinement dient in erster Linie dazu, die kommenden Storys in den Ready-Zustand zu versetzen. Bei uns dient es den POs aber auch dazu, noch weiter entfernte Projekte mithilfe des Teams überhaupt erst mal in Storys aufzuteilen. Das kann ähnlich knifflig sein wie der Task-Breakdown.

Das Schätzen

• Alle ein bis zwei Wochen je nach Lage
• Storys ohne Story Points bekommen im Schätzen eine Aufwandseinschätzung
• Alle Teams, alle POs, Agile Coach
• etwa 1,5 h

Das Schätzen (oder Estimation in der Scrum-Lehre) wird bei uns hauptsächlich (Frank) Schätzing genannt, weil es keinen englischen Begriff bekommen hat. Es ist mein persönliches Lieblingsevent.

Storys, die noch keine Schätzung haben, werden verlesen und erläutert. Oft hört man als Entwickler erstmals davon. Ungeschätzte Storys liegen in der Regel noch etwas weiter in der Zukunft. Danach können in unserem System drei Fragen oder Anmerkungen gestellt werden. Oft mündet das bei uns in wilde Diskussionen über verwendete Techniken, Implementierungsdetails oder der generellen Sinnhaftigkeit der Story. Sicherlich ganz und gar nicht nach Lehre, aber ich persönlich mag das befruchtende Chaos und den Diskurs. Nachdem sich die Gemüter wieder beruhigt haben, stimmen alle für eine Anzahl an Story-Points. Wir verwenden für die Quantifizierung Zweier-Potenzen (2, 4, 8 ,16, 32 usw.). Es passiert natürlich auch, dass es keine Fragen, Anmerkungen oder Meinungsverschiedenheiten gibt und sofort gesittet abgestimmt wird. Das Schätzen erreicht nicht nur, dass die Storys quantifiziert sind, sondern streut auch Wissen über kommende Vorhaben und fördert den Austausch.

Das soll es zum Thema Events in unserem Hause erst mal sein. Im kommenden und letzten Teil der großen Buzzword-Saga, will ich ein Fazit ziehen und gewonnene Erkenntnisse und Tipps aus unserer Reise preisgeben. (sfi)