Wie man mit Bugs umgeht, die beim Entwickeln einer Story entstehen, haben wir in unserm Beitrag "Ja, ok, aber was machen wir mit Bugs?" schon besprochen: Fixen, so lange sie frisch sind!
Viele Teams arbeiten nun aber mit bestehender Software, die (leider, leider) nur in seltenen Fällen mit den entsprechenden Qualitätsmechanismen erstellt wurde. Oder sie ist mittlerwei le so komplex, dass nicht alle Bugs sofort erkennbar sind. Der wunderbare Euphemismus „Legacy-Code“ (legacy = Vermächtnis, Nachlass) schwebt dann als Damoklesschwert über den Teams.
Was machen mit Bugs in der bestehenden Codebasis? Die Bugs, die gemeldet werden, haben meist keinen direkten Bezug zu einer Story im Sprint, verhindern aber die korrekte Laufweise des Produkts.
Hierfür gibt es nun unterschiedliche Ansätze, die aber davon abhängen, wie viele solcher Legacy-Bugs existieren bzw. wie gravierend sie sind.
Strategien je nach Schwere und Menge der Bugs.
Was als "viel", "kritisch" oder "wenig" eingeschätzt wird, muss individuell entschieden werden.
Taucht ein Bug auf, wird dieser direkt bearbeitet. Das oder die ersten Teammitglieder, die ihren Task abgeschlossen haben und einen neuen beginnen können, nehmen sich den Bug vor und lassen die Arbeit an den Stories so lange ruhen, bis der Bug gefixt ist. Ja, das kann tatsächlich im schlimmsten Fall dazu führen, dass eine Story nicht fertig wird. Aber es gilt: Bug geht vor Feature.
Da wir bei Scrum transparent darstellen wollen, woran das Team jeweils arbeitet, werden auch Bugs auf dem Taskboard angezeigt.
Um die Bugs von den Story-Tasks zu unterscheiden, arbeiten einige Teams mit unterschiedlich gefärbten Haftnotizen oder Zetteln. Persönlich ziehe ich eine extra Buglane über den Stories vor. Die zusätzliche Spur stellt eine klare Trennung zwischen „Reparieren“ und „Liefern von neuem Wert“. Die Platzierung der Lane über den Stories macht zusätzlich deutlich, dass Bugs noch vor den Stories gefixt werden müssen.
Variante 2) Bugs im Backlog: Bugbearbeitung als Teil des geplanten Sprints
Sinnvoll bei:
Es gibt einen Punkt, an dem die Bearbeitung der Bugs nicht mehr als zusätzliche Arbeit neben den Stories erfolgen kann. Ob dieser Zustand erreicht ist, muss jedes Team für sich entscheiden.
Ist das der Fall, integriert der PO zusammen mit dem Team die Bugs in das Product Backlog. Gemeinsam entscheiden sie, wie hoch der Anteil der Bugbearbeitung pro Sprint maximal sein darf. In jedem Planning werden dann – neben den normalen Stories – entsprechend auch Bugs geschätzt und geplant. Im Sprint selbst werden die Bugs dann aber auch wie Stories behandelt: Das heißt, sie werden nach ihrer Priorität bearbeitet und nicht – wie in Variante 1 – immer als erstes.
Wenn Bugs mit ins Backlog aufgenommen werden (müssen), dann ist das auch der Punkt, an dem das Unternehmen sich generelle Gedanken über den Umgang mit den Bugs machen muss. Denn jetzt geht Zeit, die eigentlich auf das „Geldverdienen“ (also die Produktion von echten wertvollen Features) verwandt werden soll, auf das Reparieren alter Fehler.
Variante 3) Der Bugsprint: Einen kompletten Sprint für das Fixen von Bugs
Sinnvoll bei:
Ist es dem Team nicht möglich, den Bugs über Variante 1 oder 2 Herr zu werden, wird es Zeit ALARM zu schlagen. Denn im Prinzip heißt das: Unsere Software ist so kaputt, dass wir nichts mehr Neues bauen können.
Ein Lösungsansatz ist, für einen begrenzten Zeitraum alles auf die Bugbehebung zu werfen. In einem oder zwei Sprints – die Anzahl sollte vorher festgelegt werden - versucht das Team, so viele Bugs zu fixen wie möglich. (Und bitte keine Hacks! Es sollen schließlich nicht noch mehr Probleme entstehen.)
Nach dem festgelegten Zeitraum müssen das Team, der PO und alle Verantwortlichen untersuchen, wie erfolgreich dieses Unterfangen war:
Ist selbst nach einem Bugsprint keine Besserung zu erkennen, muss die Geschäftsführung große und schwere strategische Entscheidung treffen: komplett Umbauen, komplett Neubauen, ... (vgl. hierzu z.B. Schwaber „The Enterprise and Scrum, Kapitel 9 #3)
Lassen sich die Fragen so beantworten, dass ein Licht am Ende des Tunnels erkennbar ist, dann ist es eine durchaus sinnvolle Entscheidung, noch mehr Zeit auf die Bugbehebung in Bugsprints zu verwenden. Und man kann nur hoffen, dass dem Team, dem PO und allen technischen Verantwortlichen der Hintern dermaßen auf Grundeis gegangen ist, dass von jetzt an immer die Qualität der Software im Vordergrund steht!
Ich wünsche es keinem Team, dass es jemals zu Variante 3 greifen muss. Glücklicherweise habe ich es bisher auch nie erlebt. Alle Teams, mit denen ich gearbeitet haben, haben es mit Variante 1 und 2 geschafft, die Software wieder auf den richtigen Weg zu bringen, und dabei gelernt, von Beginn an besser Qualität zu liefern.
Rufen Sie uns an: 030 – 555 74 70 0
