Oft wirft das Vorgehen nach Scrum ein paar Fragen und viele Diskussionen zum Thema “Umgang mit Bugs” auf. Manch einer mag sagen, dass die unten formulierten Regeln unrealistisch sind und man sie deshalb von vornherein ignorieren kann. Ich bin jedoch der Meinung, dass man sich dann daran erinnern sollte, warum man mit Scrum entwickeln will. Es gibt doch etwas, was man verändern will, sei es Time to Market reduzieren, Kundenzufriedenheit erhöhen, Qualität der Software verbessern oder oder oder … Und diese – zugegeben nicht einfach zu erreichenden – Veränderungen treten nunmal in der Regel nicht ein, wenn man so weitermacht wie bisher.

Scrum ist dabei ein Gesamtkonstrukt, das uns hilft, diese herausfordernden Ziele zu erreichen. Cherrypicking ist dabei zwar wie in allen anderen Bereichen nett, wird aber nicht die vollumfängliche Verbesserung bringen, die man sich wünscht – leider oft mit dem Fazit, dass Scrum versagt hat. Der Umgang mit Bugs ist da nur ein Beispiel von vielen.

Daher hier – ganz in der gewohnten Scrum-Manier – ein paar ganz einfache Regeln!

Bugs

Bugs werden sofort gefixt!

  1. Bugs sollten innerhalb von 24 Stunden gefixt sein! Ja, dafür muss im Zweifel ein bereits angefangener Task unterbrochen werden. Solange der Fehler nicht behoben ist, kann die Story nicht abgeschlossen werden. Das Gleiche gilt für Broken Builds, fehlgeschlagene Tests etc.
  2. Häufiger Einwand: Was ist mit Bugs, bei denen das Fixing länger dauert? Zumindest innerhalb der ersten 24 Stunden anfangen und sich dann fragen, was im Vorfeld schiefgelaufen ist.

Ein Bug ist ein Bug ist ein Bug – und damit ein FEHLER!

  1. Wir liefern fehlerfreie Software am Ende des Sprints!
  2. Keine Klassifizierungen in major oder minor oder high, medium low (notwendig). Ist es ein Bug, dann siehe Regel 1. Ist es eine neue Funktionalität –> ins Backlog priorisieren! Es werden keine Bugs zurück ins Backlog geschoben und für spätere Sprints “aufgehoben”!
  3. Häufiger Einwand: Nur Laien behaupten, dass es fehlerfreie Software gibt.
    • Mag sein, dass das Laien behaupten. Allerdings schließt das nicht aus, dass es das oberste, immer, ständig, absolut angestrebte Ziel ist, das es zu erreichen gilt. Und das sollte doch auch der Anspruch eines Teammitgliedes in einem Entwicklungsteams sein, oder? Lasst uns gute Arbeit machen und nicht Zeit mit Ausreden verschwenden!

Create a bug lane!

  1. Fügt über der Taksboard-Lane für die erste Story eine Bug Lane ein. Nehmt für Bugs eine andere Post-it-Farbe (Rot bietet sich an).
  2. Häufiger Einwand: Macht es nicht mehr Sinn, die Bugs den Stories zuzuordnen?
    • Die Arbeit in Scrum ist prioritätenbezogen: Was oben steht, wird zuerst bearbeitet. Außerdem sollte sowieso nur die oberste Story in progress sein, so dass die Zuordnung sowieso stimmt.

Das Team bekommt einmal so viel Zeit wie es braucht, um es richtig zu machen!

  • Unter Berücksichtigung des Level und der Definition of Done kann das Team so viele Stories pullen, wie es glaubt fehlerfrei liefern zu können. Ist die Freiheit berücksichtigt, kann jedoch auch verlangt werden, dass fehlerfrei geliefert wird und man nicht zusätzlich zu so viel Zeit wie man braucht noch mehr Zeit braucht!

Calls / Hotfixes / Change Requests

Manche Teams, die auf Scrum umstellen, haben bereits produktive Systeme zu betreuen – sei es in Form von Maintenance, Calls, Hotfixes, vom Kunden entdeckte Bugs oder auch Change Requests. Dabei stellt sich immer wieder die Frage, wie man mit solchen Änderungen am besten umgeht.

Calls haben sich über Jahre angesammelt, der Überblick ist verloren gegangen? Der Call Stack kann nicht mehr abgearbeitet werden, sondern nimmt mit jedem Sprint zu?

  1. Alle Calls löschen!
  2. Mit der Einführung von Scrum sollten alle Calls gelöscht werden. Ab diesem Zeitpunkt werden alle neuen Calls konsequent sofort behoben (siehe Beschreibung oben). Dauert das Beheben, Ändern oder Hinzufügen von Funktionalität zu lange, muss das System neu geschrieben werden.

Kunden bezahlen einen fixen Betrag zur Wartung der Software und erwarten daher sofortige Änderungen!

  1. Der PO entscheidet über Priorisierung und Funktionalität!
  2. In diesem Fall muss oft zuerst genau definiert werden, was unter Maintenance fällt und in welchem Zeitraum diese abgearbeitet werden müssen (sofern es vertraglich festgelegt ist). Oft versucht der Kunde, neue Funktionalität und Change Requests als Maintenance einzubringen. Hier muss der PO die notwendigen Abgrenzungen und Entscheidungen treffen. Auf jeden Fall sollte Transparenz darüber geschaffen werden, wie viele Ressourcen und wie viel Zeit durch die Maintenance-Zahlungen des Kunden zur Verfügung stehen würden. Danach kann sich die Zeit richten, die das Team pro Sprint für Maintenance-Aufgaben nutzen kann (z.B. immer an den ersten oder letzten zwei Tagen eines Sprints). Hier sollte aber wieder darauf geachtet werden, dass es eine Teamleistung ist und diese timeboxed abläuft.

Der Kunde meldet Fehler im Live-System, die seine Arbeitsfähigkeit beeinträchtigen und verlangt sofortiges Hotfixing!

  1. Für den Fehler entschuldigen und sofort beheben!
  2. Halten sich diese Hotfixes im Rahmen, können sie vom Team im laufenden Sprint bearbeitet werden. Umgang wie mit neu entdeckten Fehlern (siehe oben). Nimmt das Hotfixing die gesamte Zeit in Anspruch, sollte eine grundlegende Überarbeitung angestoßen werden.

Es gibt eine überschaubare Menge an Bugs, diese können jedoch nicht in einem Sprint abgearbeitet werden. Das Team, das die Bugs fixen muss, ist nicht für die Produktion der Fehler verantwortlich.

  1. Mit dem Product Owner ein Bug-Burn-Down vereinbaren!
  2. Wie viele offene Defects gibt es und bis wann will man sie gelöst haben? Beispiel: 100 Bugs in 10 Sprints -> 10 Bugs pro Sprint werden gefixt. In der restlichen Zeit wird Funktionalität entwickelt. So schafft man einen Übergang zu einer fehlerfreien Software und bestraft das Scrum-Team nicht damit, ausschließlich die Fehler der anderen beheben zu müssen.

 

Um diesen Umgang mit Fehlern zu ermöglichen und Fehler möglichst früh zu erkennen, gehört daher das nötige Handwerkzeug zur Basisausrüstung eines Entwicklungsteams:

  • Continuous Integration
  • Den eigenen Code in der eigenen Entwicklungsumgebung fehlerfrei laufen lassen
  • Absichern des Codes durch automatisierte Unit-Tests
  • Systematische Integration des unit-getesteten Codes in die Teamumgebung und Systemintegrationsumgebung – sofortige Behebung von entstehenden Fehlern

Erst hier ist die Entwicklungsphase abgeschlossen. Erst dann bekommt der (interne oder externe) Kunde die Software.

  • Laufen des Codes auf der User Acceptance Test Umgebung
Und immer dran denken: weniger diskutieren, mehr fixen (Zwinkern)


Avatar of Kristina Klessmann
Über Tatsachen reden statt Floskeln zu schwingen ist die Art und Weise, wie Kristina Klessmann an ihre Arbeit herangeht und dabei verlangt sie nicht nur von anderen, sondern vor allem von sich selbst Flexibilität im Denken. Direkte Fragen, die von ehrlichem Interesse getragen und manchmal mit ein wenig Ironie garniert sind, sind für sie der Schlüssel zum Gegenüber. Pragmatismus im Handeln, anpacken und auch den ersten Schritt für andere in die Veränderung zu gehen, ist ihre zweite große Stärke.
  • Michael Pitra

    “Dauert das Beheben, Ändern oder Hinzufügen von Funktionalität zu lange, muss das System neu geschrieben werden.”

    Das ist leider kein sinnvoller Beitrag. Fängt man in einem Team an, Scrum einzuführen, hat jedoch eine große Applikation zu betreuen, kann man nicht einfach diese Applikation “neu schreiben”. Das wird kein Kunde/Fachbereich/whatever akzeptieren, im Gegenteil, er wird sagen, dass die Einführung von Scrum ein Nachteil ist. Viel besser ist es hier, Schritt für Schritt mit neuer Funktionalität die man entwickelt punktuelles Refactoring zu betreiben und die Applikation sanft in den Zielzustand zu überführen.