Wer schon einmal auf einer Party gewesen ist, wird dieses Phänomen sicherlich kennen. Viele Menschen unterhalten sich und es ist sehr laut. Damit der Gegenüber versteht was man ihm zu sagen hat, muss man lauter und höher sprechen als gewöhnlich.
Dieses Phänomen nennt sich Lombard Effekt und ist begründet in der eingeschränkten akustischen Rückkopplung für den Sprecher.
Einen ähnlichen Effekt gibt es auch in jedem Issue-Tracker. Werden Fehler gemeldet, dann darf der Entdecker eine Priorität vergeben. Damit werden die Fehler in triviale, geringe, bedeutende, kritische und blockierene Fehler unterteilt. Eine sehr hilfreiche Fragmentierung, damit die Entwickler sich zuallererst um blockierende Fehler und zuallerletzt um triviale Fehler kümmern.
Immer wieder geschieht es aber, dass ein System mehr und mehr kritische Fehler aufweist, aber keinerlei triviale Fehler. Auch wenn die Entwickler nur noch Zeit finden kritische Fehler abzuarbeiten, wird der Anteil kritischer Fehler immer größer. Hier tritt der Lombard Effekt im übertragenen Sinn auf. Die Systemnutzer, die Fehler melden, versuchen sich zu übertönen. Die einzige offensichtliche Methode ist es, an der Priorität zu drehen. Dann werden triviale Fehler nur noch als geringe und später als bedeutende Fehler gemeldet. Die Priorität steigt langsam aber sicher an, weil andere Nutzer mit überhöhten Prioritäten nachziehen.
Es gibt zwei klassische Strategien mit diesem Phänomen umzugehen. Beide helfen nur kurzfristig und müssen immer wieder eingesetzt werden.
Die erste Strategie ist das Priorisierungsgremium. Mehrere Stakeholder beraten bei jedem neuen Fehler gemeinsam, welche Priorität dieser hat und ändern die ursprüngliche Priorität, die der Entdecker vergeben hat. Das funktioniert recht gut, ist aber mit viel Arbeit und langen Diskussionen verbunden.
Die zweite Strategie ist das Prioritätsmemo. Dies wird regelmäßig erstellt und an die Stakeholder verschickt. Dieses Memo weißt alle Beteiligten an, das aktuelle Bewertungsschema für Prioritäten zu beachten. Diese Strategie funktioniert in der Regel aber nicht mit externen Kunden.
Diese klassischen Strategien helfen nicht wirklich, aber glücklicherweise existiert auch eine nachhaltige, agile Strategie.
Eine nachhaltige Strategie sollte das grundsätzliche Problem lösen, und nicht nur Symptome bekämpfen. Hier scheint das grundsätzliche Problem zu sein, dass die jeweiligen Nutzer auf ihre Fehlerbeseitigung unangemessen lange warten müssen. Darum versucht jeder möglichst weit vorne in die Warteschlange zu kommen.
Tatsächlich weisen die Systeme häufig auch sehr viele unbearbeiteter Fehler auf, die im Issue-Tracker nur noch verwaltet werden. Manche Fehler sind schon Jahre alt und niemand weiß ob diese im System überhaupt noch existieren.
Vor vielen Jahren gab uns ein agiler Coach den Tipp einfach alle Fehler aus dem Issue-Tracker zu löschen. Sein Argument war einfach und bestechend. Alle aktuellen Fehler würden kurzfristig von den Kunden wieder gemeldet. Alle anderen Fehler existieren entweder nicht mehr oder sind augenscheinlich unwichtig. Natürlich graust es die meisten Verantwortlichen den Issue-Tracker zu leeren. Aber welche drei Jahre alten Fehler werden tatsächlich noch korrigiert?
Fehler häufen sich im Issue-Tracker an, wenn zu wenig Ressourcen zur Fehlerbehebung bereit stehen oder die Qualität der Software nicht ausreichend geprüft wird. Die Wahrheit liegt auch hier irgendwo dazwischen und wird befeuert durch Mitarbeitermangel und überambitionierte Releasepläne.
Bei der Neuentwicklung sollten die Teams immer eine ZERO BUG Strategie fahren. Das heißt, wird ein Fehler gemeldet, dann wird dieser sofort mit höchster Priorität bearbeitet. Erst wenn der Fehler behoben ist, wird die Feature Entwicklung wieder aufgenommen. Dieser Ansatz hat den angenehmen Seiteneffekt, dass mit jeder Iteration ein System ausgeliefert wird, dass keinen zuvor gemeldeten Fehler enthält. Im schlimmsten Fall wird in einer Iteration kein neues Feature umgesetzt. Andererseits ist ein schon ausgeliefertes Feature erst durch die Fehlerbehebung vervollständigt worden.
Wer eine ZERO BUG Strategie verfolgt kann sich außerdem einen Issue-Tracker sparen. Denn wenn immer nur ein aktueller Fehler bearbeitet wird, muss dieser nicht in einem eigenen System verwaltet werden.
Leider wird diese Strategie selten verwendet, weil sie die Auslieferung neuer Features und damit Sales-Erfolge verhindert. Die ZERO BUG Strategie wird gerne zu Gunsten einer Strategie aufgegeben, die nur eine gewisse Anzahl Fehler erlaubt. Solche Strategien können alle unter dem Namen LEGACY BUG zusammengefasst werden, denn die gewisse Anzahl steigt mit jedem Lebensjahr der Software und am Ende stehen wir vor einem System, das Fehler enthält, die seit mehreren Jahren verwaltet werden.