New, In Progress, Done – mehr nicht?

Ein Scrum Board kennt drei Zustände für Aufgaben, die im Sprint ausgeführt werden müssen. Nach dem Sprint Planning sind alle Aufgaben im Zustand „New“. Die so überschriebene Spalte des Scrum Boards repräsentiert das Sprint Backlog. Von links nach rechts sind die Aufgaben themenweise gruppiert und von oben nach unten sind die Themen priorisiert.
Sobald jemand eine Aufgabe beginnt, wandert diese Aufgabe in den Zustand „In Progress“. Ein guter Zeitpunkt um das zu machen ist das Daily Standup Meeting, aber natürlich kann man auch zu anderen Zeiten Aufgaben beginnen. Das Daily dient nur dazu, das Team zu informieren, was man an einem Tag alles tun möchte. „In Progress“ ist die Aufgabe erst, wenn man sie wirklich beginnt.
Den letzten Zustand „Done“ erreicht eine Aufgabe erst, wenn sie komplett abgeschlossen ist. Aufgaben von „In Progress“ nach „Done“ zu verschieben ist ebenfalls etwas, das im Daily Standup passieren sollte. Während es zumeist kein Problem ist, außerhalb des Daily Standup eine Aufgabe „In Progress“ zu nehmen, kann man mit dem Zustandswechsel auf „Done“ eigentlich problemlos bis zum nächsten Daily Standup warten.

Ein Team, das ich als Scrum Master begleite, ist da ziemlich pfiffig. Die Teammitglieder hängen Aufgaben, die am nächsten Tag nach „Done“ geschoben werden können an den rechten Rand der „In Progess“ Spalte.
Damit wissen im nächsten Daily Standup alle Bescheid, auch wenn ein Teammitglied ausserplanmäßig ausfällt.

Warum ist es wichtig, dass das Scrum Board genau drei Spalten hat?
Die Antwort ist ganz einfach: eine Aufgabe kann nur in diesen drei Zuständen sein. Solange sie noch nicht erledigt ist, ist sie „In Progess“ und wenn sie noch nicht „In Progress“ ist, ist sie „New“.

In den letzten vier Monaten bin ich drei Scrum Teams begegnet, deren Boards zusätzliche Spalten hatten. Ich habe diese Teams gefragt, wozu sie diese Spalten benötigen. Der häufigste Vertreter von Spalte Vier+N war „QA“. Diese Spalte wird immer dann angewendet, wenn jemand den Mitgliedern des Teams nicht zutraut, selbst Verantwortung für die Qualität ihrer Arbeit zu übernehmen und eine Kontrollinstanz einbauen wollte. Das widerspricht aber einem Grundprinzip agiler Softwareentwicklung. Vertraue dem Team und behandle die Teammitglieder wie erwachsene Menschen.

Die Spalte „QA“ und ähnliche Konstruktionen führt in allen Teams, die ich beobachten konnte, zu zwei Anti-Pattern die in agiler Softwareentwicklung vermieden werden sollten. Das erste Anti-Pattern ist, dass die Leute abstumpfen. Es gibt ja für alles noch eine Kontroll-Instanz. Und je besser die ist, desto schlechter droht die Qualität der Tasks zu werden. Man entzieht damit dem einzelnen Teammitglied die Verantwortung für die eigene Arbeit.

Das zweite Anti-Pattern ist, dass Aufgaben nicht bis zu ihrem tatsächlichen Ende gebracht werden. Der Idealfall: ein Teammitglied, angenommen ein Junior Developer, ist irgendwann der Meinung, fertig zu sein. Wenn sich der Junior Developer unsicher ist, ob die Aufgabe korrekt bearbeitet wurde, wird er sich selbst an einen Senior Developer wenden*. Der macht vielleicht noch ein paar Anmerkungen und nach deren Einarbeitung ist die Aufgabe erledigt.
Gibt es die Spalte Vier, wird der Junior Developer sich geistig von der Aufgabe lösen, sobald er sie dorthin schiebt. Es ist dann nicht mehr seine Aufgabe. Das ist ungünstig, weil die Aufgabe ja noch nicht „Done“ ist. Sie ist nach wie vor „In Progress“. Das Teammitglied, das eine Aufgabe in Spalte vier schiebt, wendet sich der nächsten Aufgabe zu und gibt damit die Verantwortung für seine Arbeit ab. Irgendwann wird sind jemand um „QA“ kümmern – völlig entkoppelt von der vorherigen Bearbeitung.
Und was dann? Die Aufgabe geht wieder zurück auf „In Progress“?
Dazu müsste der vorherige Bearbeiter entweder seine neue Aufgabe unterbrechen oder aber er stapelt Aufgaben, die aus „QA“ zurückkommen.
Geht die Aufgabe wieder auf „New“? Wie soll dann der Junior Developer lernen, was er falsch gemacht hat? Dazu müsste dann zu jeder Aufgabe die Historie gepflegt werden. Das wiederum ist bei der Kurzlebigkeit von Scrum Board Tasks Zeitverschwendung.
Alles in allem sind Spalte Vier und weitere keine gute Lösung bei einem Scrum Board, weil man die Verantwortung der einzelnen Teammitglieder reduziert und die Menge der tatsächlich in Bearbeitung befindlichen Aufgaben verschleiert. Oft wird diese Spalte sogar zu einem Bottleneck, weil zu wenige Teammitglieder als würdig befunden werden, QA zu betreiben. Dann kommt es kurz vor Sprint-Ende zu einem hektischen QA-Tag – was nichts anderes bewirkt, als dass die Qualität sinkt.

Immer wenn jemand von mir verlangt, eine Spalte Vier wie z.B. „QA“ auf einem Scrum Board einzuführen, antworte ich, dass Qualität nicht gesichert, sondern produziert wird. In einem agilen Team sind Spalte-Vier-Tätigkeiten wie „QA“ eben nicht zusätzliche Spalten eines Scrum Boards zwischen „In Progress“ und „Done“, sondern werden kontinuierlich von allen Teammitgliedern verantwortungsbewusst ausgeführt. „QA“ ist immer „In Progress“.

* Wenn nicht ohnehin Pair Programming praktiziert wird.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.