Automate everything! #3

Scrum

Viele Stimmen besagen, dass Scrum für Teams mit Betriebsaufgaben nicht geeignet ist. Lange war ich selber auch dieser Meinung. Jedoch haben wir einen Weg gefunden, mit welchem uns Scrum hilft, unsere Arbeit zu planen, trotzdem aber auch betriebliche Aufgaben ganz gut Platz daneben haben.

Daily (Stand-Up)

Wir treffen uns jeden Arbeitstag um 10 Uhr zum Daily auf unserer Jitsi-Umgebung. Dieses Meeting dauert meist zwischen 5 und 10 Minuten. Jeder Teilnehmer erzählt, was er am letzten Arbeitstag erledigt hat und was heute geplant ist. Gibt es Fragen an die Teilnehmerrunde oder zu führende Diskussionen, wird dies zwar erwähnt, aber erst besprochen, wenn alle Teilnehmer ihren Daily-Beitrag geleistet haben. Auf diese Weise können die, die das Thema nicht betrifft, das Daily vorher verlassen. Themen, die umfassender besprochen werden müssen, werden in ein separates Meeting ausgelagert.

Damit ein Daily produktiv wird, gibt es nur einen Weg:
Zuerst muss ein gemeinsames Verständnis geschaffen werden, dass ein Daily ein Mehrwert für das Team ist (also kein Rapportieren an den Vorgesetzten, Projektleiter oder Scrum Master). Wenn jedem Teammitglied bekannt ist, woran die anderen arbeiten, sind Hilfestellungen schneller gewährleistet und die Effizienz wird gesteigert.
Wenn dieses Verständnis geschaffen ist, geht es an die effektive Zusammenarbeit im Team. Schweift ein Teilnehmer in seinen Erzählungen aus, darf mit einem Hinweis «Das verlagern wir besser auf ein bilaterales Gespräch im Nachgang» unterbrochen werden. Sollte dieser Weg nicht funktionieren, können die Beiträge mit Timeboxing eingeschränkt werden. Aber aufgepasst: Das kann ungewollten Stress generieren.

Bi-Weekly Scrum Zeremonie

Review

Alle zwei Wochen treffen wir uns für unser Scrum-Meeting. Meist beginnen wir mit einem Review, in welchem wir über alle Stories des letzten Sprints schauen, um sicherzugehen, dass sie up to date sind. Weiter erfolgt ein kurzer Bericht zum Stand jeder Story. Dies ist effizienter als, wenn alle im Team nachlesen müssen.
Anschliessend gibt es Demonstrationen der erfolgten Umsetzungen. Eine Demo kann auch verwendet werden, um im Team einen Variantenentscheid zu treffen. Wir haben keine definierte Ansprüche an eine Demo. Es kann ein grösserer Merge Request vertont werden, ein Web-Frontend oder auch eine kleine Slideshow gezeigt werden. Wie und was an einer Demo gezeigt wird, liegt in der Verantwortung der Person, welche die Story bearbeitet hat. Bei einer Demo gibt es jedoch immer Platz für Fragen.

Unsere Definition of Done

Wann gilt ein Task im Sprint als abgeschlossen?

• Die Arbeit wurde dokumentiert und das Ticket & Taskboard aktualisiert (Nachvollziehbarkeit gegeben)
• Ein „Peer Review“ wurde durchgeführt
• Team & Stakeholder sind informiert
• Die Story wurde an der Sprint Retro besprochen

Retro

Zum Abschluss des letzten Sprints geht es weiter zur Retro. Wir führen unsere (Starfish-)Retro in einem Markdownfile auf unserem HedgeDoc Server. Hier haben alle Themen Platz – das kann auch mal Frust sein. Action Items erfassen wir dann wiederum nur für Dinge, welche wir effektiv ändern können. Die Themen der Retro werden bereits im Vorfeld zum Meeting ausgefüllt und werden beim Meeting nur noch vertont. Dies spart uns wiederum Zeit, welche wir produktiv einsetzen können. Zum Abschluss gibt jeder Mitarbeiter im selben Markdownfile an, wie viele Tage er/sie im nächsten Sprint mitarbeiten kann. Damit wird abschätzbar, wie viele Stories in den nächsten Sprint aufgenommen werden können. Damit ist dann der letzte Sprint abgeschlossen und wir starten den nächsten.

Sprint Start

Ein Sprint beginnt damit, dass ein Set von Stories geschätzt wird. Dazu verwenden wir die Fibonacci-Folge. Geschätzt wird jeweils die Komplexität einer Story anhand unserer Referenzstory:

Am Planning vom 6. Februar 2020 wurde eine neue Reference Story definiert. Die Reference Story entspricht 2 Story Points:

• Ansible Playbook/Rolle für Webserver schreiben
• Plain Rocky Server
• Pakete installieren
• Config Files erstellen
• Zertifikate ausstellen
• Dokumentation schreiben
• Definition of Done erfüllt

Zum Schätzen verwenden wir Thunderdome, sodass sowohl HomeOfficers als auch Personen vor Ort mit schätzen können.
Wenn das Resultat nicht klar ist, begründen die beiden mit der höchsten und der niedrigsten Schätzung deren Anzahl Storypoins. Auf Basis dessen wird im Team entschieden, ob es eine zweite Schätzrunde gibt oder es gegebenenfalls während der Diskussion eine Einigkeit gibt.
Meist darf auch ein Votum, dass die Person mit den wenigsten Punkten die Story umsetzen soll, nicht fehlen 😏 .
Wenn alle zu schätzenden Stories mit Storypoints versehen sind, befüllen wir das Sprint-Backlog und klären im Team, ob die Priorisierung passt.
Danach geht’s ans Abarbeiten des Backlogs.

Das Backlog

Grundsätzlich ist jeder Member aufgefordert, Stories in unserem Backlog zu erfassen. Eine Story sollen jegliche Themen sein, die mehr Aufwand zu erledigen bedingen, als die Story nach folgendem Schema zu erfassen:

Als <Rolle> möchte ich <Was?> um <Damit?>

Abnahmekriterien:
- <Zu erfüllende Anforderungen>

Beispiel:
Als Infrastrukturmember und updateliebender Sysler möchte ich ein Grafana Dashboard, um unsere offenen Server Updates zu sehen.

Abnahmekriterien:
- Es gibt ein Grafana Dashboard, in denen alle offenen Server Updates ersichtlich sind.

Wird eine neue Story erfasst, wird diese an den Product Owner oder Scrum Master gesendet, damit wir die Vollständigkeit prüfen und wo möglich gleich eine Priorisierung vornehmen können.

Priorisierung

Das Backlog wird zu Grossteilen vom Product Owner und Scrum Master priorisiert. Parallel werden aber auch die Teammitglieder regelmässig aufgefordert, Priorisierungswünsche zu melden, sodass diese berücksichtigt werden können.

Backlog-Grooming

Alle drei Monate führen wir ein Backlog-Grooming durch.
Wir setzen uns zusammen und schauen alle Stories im Backlog durch. Damit das Ganze etwas mehr Spass macht, trinken wir ein Bier dazu und haben ein paar Spielregeln erschaffen:

• Bei jeder Story starten wir einen Timer von 30 Sekunden.
• In dieser Zeit haben die Teilnehmer Zeit, sich zu melden, wenn die Story im Backlog bleiben soll.
• Diese Person bekommt wiederum 60 Sekunden Zeit, um zu argumentieren, wieso die Story umgesetzt werden soll.
• Im Anschluss erfolgt eine Abstimmung: Meldet sich niemand oder ist die Mehrheit auch nach dem Plädoyer noch gegen die Umsetzung der Story, wird diese geburned.
• Wir löschen die Stories, welche geburned werden, aber nicht gleich, sondern schieben diese in einen separaten Sprint und informieren alle Stakeholder über den gefällten Entscheid.
• Die Stakeholder haben eine Woche Zeit, die Stories durchzuschauen und in gegebenem Fall eine neue Story zur Thematik zu erstellen.

Um noch mehr Schwung in das Ganze zu bringen, haben wir eine kleine Flask-App geschrieben, welche die Stories aus dem Taiga nimmt und entsprechend in den to_be_burned Sprint verschiebt und selbstverständlich dazu ein random „burn“ Gif anzeigt.