Welche*r Entwickler*in kennt sie nicht, die wirren Fehler­be­schrei­bun­gen der Kundenservice-Mitarbeiter*innen, bei denen man eigent­lich nur Bahn­hof versteht? Man kann den Fehler weder repro­du­zie­ren noch weiß man so rich­tig, wo man anfan­gen soll zu suchen.

Wo kommt der denn her?

Es kann vorkom­men, dass schlaue Track­ing Tools den Fehler auch noch an das falsche Team zurück gespielt und man wundert sich umsonst, dass man die nieder­ge­schrie­bene Spra­che nicht mehr versteht. In diesem Fall muss man dann erst­mal losren­nen, dort­hin, wo man sich eigent­lich nie aufhält — in den Büros der ande­ren Teams. Hat man den Weg gefun­den und sich über­wun­den an die Tür mit dem großen Schild „You may not pass!“ zu klop­fen, wird man meist belohnt (Anmer­kung der Autorin: Ironie kommt ins Spiel): Ein freund­li­ches Lächeln begeg­net einem und alle stre­cken die Arme in die Luft und sagen „Toll, du hast einen unse­rer Fehler mitge­bracht. Danke dir! Wir kümmern uns sofort darum.“Ist der Fehler doch dem rich­ti­gen Team zuge­ord­net worden und man hat das kürzeste Streich­holz gezo­gen, wird man schnell in den Sog der Fehler­be­he­bung hinein­ge­zo­gen. Die Product Owner*in wird ganz hibbe­lig und die Scrum Master*in kramt ihre Velo­city Charts und Release Burn-Downs hervor und rech­net hektisch die Auswir­kun­gen auf den aktu­el­len Sprint aus. Man selber kann neben einer unend­li­chen Leere kaum noch etwas ande­res wahr­neh­men außer das schwarze Loch, was sich vor einem eröffnet. 

Wie bekomme ich ihn wieder los?

Hat man dann nach einem drei­tä­gi­gen Exkurs in Sachen Kryp­to­lo­gie eine erste Hypo­these gebil­det, gibt es genau zwei mögli­che Ergeb­nisse: Entwe­der, es war die rich­tige Hypo­these und man ist inner­halb von 10 Minu­ten mit der Fehler­be­he­bung fertig (Hurra!) oder man hatte nicht den rich­ti­gen Riecher und weiß, dass man noch weitere Tage benö­tigt, bis eine weitere Lösungs­hy­po­these möglich ist. Das Sprint­ziel wird geris­sen. Team­mit­glie­der begin­nen auf einmal, den eige­nen Schreib­tisch zu meiden, da man ja eine Frage stel­len und somit auch sie in den Sog hinein­zie­hen könnte. Die Scrum Master*in steht mit feuch­ten Händen hinter einem und versucht, durch stetige Nacken­mas­sage die Situa­tion noch zu retten. Während­des­sen die Product Owner*in tele­fo­niert und beschwich­tigt mit den Worten „Wir halten die Quali­tät aufrecht und daher benö­ti­gen wir noch etwas mehr Zeit.”

Ist das die Lösung?​

Ein leich­ter Ausweg aus dieser Misere scheint, die Bugs einfach zu sammeln und von einer zustän­di­gen Product Owner*in, der um alles in der Welt Features an den Markt brin­gen möchte, prio­ri­sie­ren zulas­sen? Man kann dann weiter­hin fest­stel­len, dass Jira eine tolle Funk­tion der Filte­rung anbie­tet, mit der man auf magi­sche Weise Tickets verschwin­den lassen kann und nie wieder darüber reden muss. Irgend­wann ist die Liste dann so lang, dass es sich auch nicht mehr lohnt, diese anzu­ge­hen. „Man müsste mal ein biss­chen aufräu­men“, heißt es dann nur.

Zehn Gebote der Fehler­be­he­bung

Was man viel­leicht machen müsste (Anmer­kung der Autorin: Ich verlasse den Bereich der Ironie):

1. Akzep­tanz­kri­te­rien nicht erst im Sprint Plan­ning kurz vor der Angst fest­le­gen, sondern regel­mä­ßig in Team und mit den rele­van­ten Stake­hol­der verhan­deln. Das lässt zu, Stol­per­fal­len auch über die Team­gren­zen hinaus früh­zei­tig zu erken­nen oder durch Diskus­sio­nen bereits zu neuen Lösun­gen zu führen.
2. Nicht Über-Commi­ten im Sprint und genü­gend Zeit und Gedan­ken­gut in die Tests stecken, um nicht Gefahr zu laufen, über­ar­bei­tet, demo­ti­viert oder unge­nau in der Arbeit zu sein.
3. Tests bereits vor der Entwick­lung anhand der fest­ge­leg­ten Akzep­tanz­kri­te­rien schrei­ben. Das hilft die eigene Arbeit zu fokus­sie­ren und wirk­lich nur die abge­stimm­ten Krite­rien in der Lösung zu betrach­ten. Testen wird dadurch verein­facht und kann schnel­ler passieren.
4. Strik­tes Review, Pair Programming oder Mob Programming in der Entwick­lungs­phase anwen­den. Das lässt bereits ein geteil­tes Verant­wor­tungs­be­wusst­sein entste­hen und kann Fehler­quel­len früh­zei­tig identifizieren.
5. Eine Defi­ni­tion of Done erstel­len. Das ist immer gut, um eine Orien­tie­rung zu bekom­men und sicht­bar zu haben, was sich jeder auf die Fahne schreibt, um die best­mög­li­che Quali­tät (=fehler­frei) zu liefern.
6. Konti­nu­ier­li­che Verbes­se­rung der eige­nen Code­qua­li­tät und Arbeits­leis­tung mit anschlie­ßen­der Anpas­sung der DoD. Eine DoD ist nicht in Stein gemei­ßelt und darf bei wieder­hol­ten erhöh­tem Fehler­auf­kom­men auch die Ergeb­nisse von Retro­spek­ti­ven zur Verbes­se­rung der Arbeits­weise enthalten.
7. Den Camping­platz saube­rer verlas­sen, als man ihn vorge­fun­den hat, immer und immer und immer.
8. Tests auto­ma­ti­sie­ren, sofort und immer und so viel wie möglich. Manu­el­les testen kostet Zeit, Ener­gie und kann Fehler beinhal­ten. Je mehr auto­ma­ti­siert passiert, desto mehr Zeit gewinnt man, um Sonder­fälle auch mal manu­ell testen zu können.
9. Bugs sofort lösen bevor sie einen Stau verur­sa­chen. Es ist die Verant­wor­tung des Entwick­lungs­teams fehler­freie und quali­ta­tiv hoch­wer­tige Funk­tio­nen zu liefern. Ein Bug ist ein unan­ge­neh­mes Anzei­chen dafür, dass dies nur unzu­rei­chend geschieht und muss daher sofort besei­tigt werden. 
10. Diszi­plin halten und nicht nach zwei Sprints die oben genann­ten Punkte einfach nicht mehr machen.