Welcher Entwickler kennt sie nicht, diese wirren Fehlerbeschreibungen der Kundenservice Mitarbeiter, bei denen man eigentlich nur Bahnhof versteht? Man kann den Fehler weder reproduzieren noch weiß man so richtig, wo man anfangen soll zu suchen.

Wo kommt der denn her?

Es kann vorkommen, dass schlaue Tracking Tools den Fehler auch noch an das falsche Team zurück gespielt und man wundert sich umsonst, dass man die niedergeschriebene Sprache nicht mehr versteht. In diesem Fall muss man dann erstmal losrennen, dorthin, wo man sich eigentlich nie aufhält - in den Büros der anderen Teams. Hat man den Weg gefunden und sich überwunden an die Tür mit dem großen Schild „You may not pass!“ zu klopfen, wird man meist belohnt. (Anmerkung des Autors: Ironie kommt ins Spiel) Ein freundliches Lächeln begegnet einem und alle strecken die Arme in die Luft und sagen „Toll, du hast einen unserer Fehler mitgebracht. Danke dir! Wir kümmern uns sofort darum.“Ist der Fehler doch dem richtigen Team zugeordnet worden und man hat das kürzeste Streichholz gezogen, wird man schnell in den Sog der Fehlerbehebung hineingezogen. Der Product Owner wird ganz hibbelig und der ScrumMaster kramt seine Velocity Charts und Release Burn-Downs hervor und rechnet hektisch die Auswirkungen auf den aktuellen Sprint aus. Man selber kann neben einer unendlichen Leere kaum noch etwas anderes wahrnehmen außer das schwarze Loch, was sich vor einem eröffnet. 

Wie bekomme ich ihn wieder los?

Hat man dann nach einem dreitägigen Exkurs in Sachen Kryptologie eine erste Hypothese gebildet, gibt es genau zwei mögliche Ergebnisse:Entweder, es war die richtige Hypothese und man ist innerhalb von 10 Minuten mit der Fehlerbehebung fertig (Hurra!) oderman hatte nicht den richtigen Riecher und weiß, dass man noch weitere Tage benötigt, bis eine weitere Lösungshypothese möglich ist. Das Sprintziel wird gerissen. Teammitglieder beginnen auf einmal, den eigenen Schreibtisch zu meiden, da man ja eine Frage stellen und somit auch sie in den Sog hineinziehen könnte. Der ScrumMaster steht mit feuchten Händen hinter einem und versucht, durch stetige Nackenmassage die Situation noch zu retten. Währenddessen der Product Owner telefoniert und beschwichtigt mit den Worten „Wir halten die Qualität aufrecht und daher benötigen wir noch etwas mehr Zeit."

Ist das die Lösung?

Ein leichter Ausweg aus dieser Misere scheint, die Bugs einfach zu sammeln und von einem zuständigen Product Owner, der um alles in der Welt Features an den Markt bringen möchte, priorisieren zulassen? Man kann dann weiterhin feststellen, dass Jira eine tolle Funktion der Filterung anbietet, mit der man auf magische Weise Tickets verschwinden lassen kann und nie wieder darüber reden muss. Irgendwann ist die Liste dann so lang, dass es sich auch nicht mehr lohnt, diese anzugehen. „Man müsste mal ein bisschen aufräumen“, heißt es dann nur.

10 Gebote der Fehlerbehebung

Was man vielleicht machen müsste (Anmerkung des Autors: Ich verlasse den Bereich der Ironie):​

  1. Akzeptanzkriterien nicht erst im Sprint Planning kurz vor der Angst festlegen, sondern regelmäßig in Team und mit den relevanten Stakeholder verhandeln. Das lässt zu, Stolperfallen auch über die Teamgrenzen hinaus frühzeitig zu erkennen oder durch Diskussionen bereits zu neuen Lösungen zu führen.
  2. Nicht Über-Commiten im Sprint und genügend Zeit und Gedankengut in die Tests stecken, um nicht Gefahr zu laufen, überarbeitet, demotiviert oder ungenau in der Arbeit zu sein.
  3. Tests bereits vor der Entwicklung anhand der festgelegten Akzeptanzkriterien schreiben. Das hilft die eigene Arbeit zu fokussieren und wirklich nur die abgestimmten Kriterien in der Lösung zu betrachten. Testen wird dadurch vereinfacht und kann schneller passieren.
  4. Striktes Review, Pair Programming oder Mob Programming in der Entwicklungsphase anwenden. Das lässt bereits ein geteiltes Verantwortungsbewusstsein entstehen und kann Fehlerquellen frühzeitig identifizieren.
  5. Eine Definition of Done erstellen. Das ist immer gut, um eine Orientierung zu bekommen und sichtbar zu haben, was sich jeder auf die Fahne schreibt, um die bestmögliche Qualität (=fehlerfrei) zu liefern.
  6. Kontinuierliche Verbesserung der eigenen Codequalität und Arbeitsleistung mit anschließender Anpassung der DoD. Eine DoD ist nicht in Stein gemeißelt und darf bei wiederholten erhöhtem Fehleraufkommen auch die Ergebnisse von Retrospektiven zur Verbesserung der Arbeitsweise enthalten.
  7. Den Campingplatz sauberer verlassen, als man ihn vorgefunden hat, immer und immer und immer.
  8. Tests automatisieren, sofort und immer und so viel wie möglich. Manuelles testen kostet Zeit, Energie und kann Fehler beinhalten. Je mehr automatisiert passiert, desto mehr Zeit gewinnt man, um Sonderfälle auch mal manuell testen zu können.
  9. Bugs sofort lösen bevor sie einen Stau verursachen. Es ist die Verantwortung des Entwicklungsteams fehlerfreie und qualitativ hochwertige Funktionen zu liefern. Ein Bug ist ein unangenehmes Anzeichen dafür, dass dies nur unzureichend geschieht und muss daher sofort beseitigt werden. 
  10. Disziplin halten und nicht nach zwei Sprints die oben genannten Punkte einfach nicht mehr machen.