Scrum in einem zweitägigen Minisprint ausprobieren

So wie Srcum ein iterativer Prozess ist, so kann auch die Einführung von Scrum schrittweise erfolgen, der Prozess selbst wird kontinuierlich verbessert.

Ist man sich unsicher, ob Scrum ein geeignetes Instrument für das eigene Unternehmen ist, nimmt man sich zwei Tage Zeit und probiert es aus.

Keine Angst, in den zwei Tagen wird auch gewinnbringend Software entwickelt, nur eben anders.

Vorbereitung

Rollenbestimmung

Jemand übernimmt die Verantwortung Product Owner (m/w/d) zu sein. Das kann jemand aus dem Management sein, auf jeden Fall ist es jemand, der in Geschichten denkt und diese mitreißend erzählen kann. Keinesfalls präsentiert diese Person dem Entwicklungsteam technische Lösungen, die das Dev-Team nur noch implementieren soll. Die technischen Lösungen erarbeitet das Entwicklungsteam, dazu ist es befähigt und motiviert.

Ein Scrum Master (m/w/d) behält im Auge, ob in den beiden Scrum-Probetagen eher Scrum durchgeführt wird, oder eher doch etwas anderes und greift regulierend und moderierend ein. Hier eine scrumerfahrene Person bei der Hand zu haben, ist sicher kein Fehler.

Das Entwicklungsteam ist und bleibt das Entwicklungsteam. Je nach bisher gelebter Kultur wird dieses Team in den beiden Scrum-Propetagen aber viel intensiver zusammenarbeiten.

Geschäftsführung, Teamleiter und andere im Unternehmen etablierten Rollen, können in einem reifen Scrumteam ebenfalls wichtige Funktionen inne haben, halten sich aber in den Scrum-Propetagen beobachtend zurück.

Stories

Vor den Scrum-Probetagen braucht es sprintfähige Geschichten – die Stories. Der Geschichtenerzähler (Product Owner) bereitet wenige (1 bis 3) Geschichten vor, die nicht von möglicherweise bis zum Sprintstart unfertigen Features abhängig sind. Und nachdem ja Scrum und nicht irgendwelche neuen Technologien ausprobiert werden soll, nimmt man Geschichten, die mit im Dev-Team etablierten Know-How umgesetzt werden können.

Abhängigkeiten von externen Dienstleistern werden ebenfalls vermieden.

Eine Geschichte muss drei Fragen klar beantworten:

  • Wer zieht einen Nutzen daraus, wenn die Story umgesetzt wird. Das muss keine reale, aber eine konkrete Person sein (den Begriff Persona merken), von der sich jedes Teammitglied ein Bild im Kopf machen kann.
  • Was stellt den konkrete Nutzen dar? Was steht der zuvor genannten Person nach Umsetzung der Story zur Verfügung? Was kann diese Person dann tun? (Ein fachliche Erzählung, keine Beschreibung einer technischen Lösung)
  • Warum nützt das dieser Person? Wozu nimmt sich das Scrum-Team Zeit, sich genau dieser Geschichte zu widmen? Warum nimmt der Kunde Geld in die Hand? Welchen Sinn erfüllt die Lebenszeit, die jeder einzelne für diese Geschichte investiert?

Geschichten erzählen – Story Telling

Ob man als Product Owner diese drei Fragen beantwort hat, überprüft man vor Start der Scrum-Probetage, in dem man die auf einem A5-Zettel notierten Geschichten dem Dev-Team erzählt. Dies kann in fünfminütigen Meetings in der Vorwoche des Probe-Sprints durchgeführt werden.

Ungläubige Gesichter sind für den Product Owner genauso wertvolles Feedback wie Rückfragen und kritische Anmerkungen. Hat man als Product Owner nicht den Eindruck, dass gutes gemeinsames Verständnis über die 3 W-Fragen (Wer? Was? Warum?) vorhanden ist, so nützt man das Feedback und verfeinert die Geschichten bis zum nächsten Story Telling.

Auf Schätzmethoden in Scrum verzichten wir vorerst. Die Geschichten sollen in gemeinsamer Übereinkunft an ein bis zwei Tagen umsetzbar sein.


Durchführung – der Probesprint

Sprint Planning Meeting 1 (SP1)

Der Product Owner stellt noch einmal jede für den aktuellen Sprint geplante Story vor und die Akzeptanzkriterien werden gemeinsam mit dem Dev-Team erarbeitet: welche fachlichen Kriterien müssen erfüllt sein, damit die Geschichte als erfüllt gilt? Diese Kriterien werden zur Story-Card (der oben genannte A5-Zettel) notiert oder auf ein Flipchart geschrieben und dienen dem Dev-Team zur Orientierung im Sprint Planning Meeting 2 (SP2) und zur eigenen Beurteilung, ob der Product Owner die Story wohl als fertiggestellt abnehmen wird.

Der Scrum Master achtet darauf, dass Diskussionen fachlich bleiben und verweist bei Abdriften in technische Kontroversen auf das SP2. Der Scrum Master fördert auch Teamentscheidungen gegenüber Einzelentscheidungen dominanter Persönlichkeiten.

Hat das Dev-Team im SP1 noch fachliche Fragen, die der Product Owner nicht unmittelbar beantworten kann, so trifft dieser trotzdem nach bestem Wissen und Gewissen eine Entscheidung. Dem Product Owner gehört das Produkt, die Entscheidung ist mit hoher Wahrscheinlichkeit richtig und kann in nachfolgenden Sprints nachgebessert werden. Keine Entscheidung zu treffen ist auf jeden Fall die falsche Entscheidung.

Das Sprint Planning Meeting 1 wird durch das Commitment des Dev-Teams abgeschlossen. Im Wesentlichen gibt das Entwicklungsteam das Versprechen ab, alles in seiner Macht zu unternehmen, um das Sprintziel zu erreichen (grobe Vereinfachung).

Sprint Planning Meeting 2 (SP2)

Das Dev-Team berät die technische Umsetzung, skizziert die Architektur, das Datenbank-Design – alles, was für die konkrete Implementierung notwendig und nützlich ist – und notiert technische Tasks auf Post-its, die zur Story-Karte (der A5-Zettel) dazugehängt werden.

Der Scrum Master achtet wieder darauf, dass Team-Entscheidungen getroffen werden und nicht der Lauteste gewinnt.

Umsetzung im Sprint

Das Dev-Team organisiert sich selbständig, um die erste Story vollständig umzusetzen (Pair/Team-Programming, Task-Aufteilung). Das Dev-Team konzentriert sich darauf, diese eine Story fertigzustellen, schiebt die Post-Its mit den technischen Tasks auf einem beliebig improvisierten Scrum-Board auf In Arbeit und auf Fertig und führt vielleicht sogar ein Deployment ins Produktivsystem durch. Der Product Owner hält sich daher für eine Abhnahme der Story bereit.

Ist die Story vollständig umesetzt, so ist das Team frei sich auf Neues zu konzentrieren und nimmt die nächste Story in Angriff. (Es sind daher auch nie mehrere Baustellen gleichzeitig offen, die sich gegenseitig und die Köpfe des Dev-Teams behindern)

Stand-Up-Meeting – Hourly statt Daily

Um ein Gefühl für das Daily in einem regulären Sprint zu entwickeln, wird alle 55 Minuten ein fünfminütiges Stand-Up-Metting durchgeführt, in dem jedes Dev-Teammitglied erzählt, woran es gerade arbeitet, ob und welche Schwierigkeiten aufgetreten sind und was als nächster Schritt geplant ist.

Der Product Owner ist Zuhörer des Stand-Up-Meetings, es handelt sich aber um kein Reporting an den Produkt Owner. Das Meeting dient dem Dev-Team, sich Tun und Planung bewusst zu machen und gegebenenfalls anzupassen. Es dient der Beratschlagung, wobei das Meeting sehr kurz gehalten wird und eventuell zusätzlicher Diskussionsbedarf nach diesem Meeting gestillt wird, wobei dann nur die dafür notwendigen Personen beteiligt sind.

Der Product Owner erhält einen guten Überblick über den Fortschritt des Sprints.

Review

Das Scrum-Team präsentiert – am besten im Produktivsystem – die fertiggestellten Stories, betrachtet (hoffentlich) mit Stolz das erbrachte Werk. Neue Ideen, das Produkt weiter zu verbessern, keimen auf. Das Team blickt auf eine erfolgreiche Zusammenarbeit zurück.

Retrospektive

Da die Retrospektive den Abschluss des Probe-Sprints darstellt, wird diesem Meeting eine überproportionale Dauer eingeräumt.

Es gibt viele Retro-Formate, in der ersten Retrospektive notiert jedes Teammitglied auf Post-its die persönlichen Antworten zu folgenden Fragen zum aktuellen Sprint:

  • Was ist gut gelaufen und soll beibehalten werden?
  • Was ist nicht so gut gelaufen und sollte besser abgestellt werden?
  • Was wollen wir ändern?

Jedes Team-Mitglied präsentiert seine Post-its und gemeinsam werden konkrete Maßnahmen beschlossen, die im nächsten Sprint umgesetzt werden und diesen verbessern sollen.

Der Scrum Master achtet wieder darauf, dass jeder Gehör findet, keine Diskussionen außer Kontrolle geraten und wirklich Konkretes und Nützliches aus der Retrospektive hervorgeht.


Den Sprint in gemütlicher Atmosphäre bei einem gemeinsamen Essen oder bei Scotch und einer Zigarre auf der Dachterrasse ausklingen zu lassen, ist sicher kein Fehler. (wobei ich mir bei Scotch und Zigarre nicht ganz sicher bin)

Timeboxing

Die Länge eines Sprints ist nicht vorgeschrieben, viele Teams verwenden zweiwöchige Sprints. Die Meetings im Sprint sind zeitlich eingeschränkt und erfordern konzentriertes und zielgerichtetes Vorankommen.

Timeboxing-Vorschlag für einen Probesprint in Relation zu einem regulären zweiwöchigen Sprint:

zweiwöchiger SprintPropesprint
SP12 h30 min
SP22 h30 min
Daily/Hourly10 – 15 min5 min
Review1 h 30 min20 min
Retro1 h 30 min1 h

Der Retrospektive im Probesprint wird mehr Zeit eingeräumt, um dem Team und Beobachtern ausreichend Möglichkeit zu geben, über diesen Versuch zu reflektieren und Entscheidungen für zukünftige reguläre Sprints zu treffen.

Schreibe einen Kommentar

Menü schließen