Zero Bugs: Hör auf, Defekt-Bestände zu verwalten

Porsche hat einen interessanten Erfahrungsbericht über die zero bug policy veröffentlicht, die bei My Porsche angewendet wurde. Die Idee mag auf den ersten Blick unrealistisch wirken. Jeder weiß, dass eine Software ohne Bugs nicht existiert. Selbst die besten Produkte haben Defekte, Regressionen, unerwartetes Verhalten, Randfälle.

Aber darum geht es nicht.

Eine Zero-Bug-Policy verspricht keinen perfekten Code. Sie zielt auf etwas anderes: bekannte Bugs nicht länger als dauerhaften Bestand zu akzeptieren, den man priorisiert, umklassifiziert und aufschiebt.

Das eigentliche Problem bei Bugs ist nicht nur ihr Auftreten. Das eigentliche Problem ist die Organisation, die sich daran gewöhnt, sie zu behalten.

Man öffnet ein Ticket. Man gibt ihm eine Priorität. Man klassifiziert es. Man schaut zwei Wochen später wieder rein. Man ändert die Priorität. Man bespricht es im Komitee. Man schiebt es auf, weil ein Feature-Roadmap-Thema dringender ist. Dann eskaliert ein Kunde, der Bug taucht wieder auf, und das Team behandelt in der Eile, was man längst klar hätte entscheiden müssen.

In diesem Moment ist der Bug nicht mehr nur ein Software-Defekt. Es ist ein Entscheidungsdefekt.

Bugs zählen nicht bis zur Eskalation

In vielen Organisationen befinden sich Bugs in einem seltsamen Zwischenzustand.

Sie existieren. Alle sehen sie. Sie verbrauchen Energie. Sie verärgern Kunden. Sie verstopfen den Support. Aber sie zählen in der Planung nicht wirklich.

Die Roadmap schreitet voran. Die geplanten Features kommen. Die Deadlines sind sichtbar. Die Abwägungen werden bei neuen Themen getroffen. Und die Bugs bleiben daneben, wie eine implizite Last, die man behandeln wird, wenn man Zeit hat.

Nur hat man nie Zeit.

Also werden Bugs erst prioritär, wenn sie zu sichtbar werden: Ein wichtiger Kunde eskaliert, eine Demo bricht zusammen, der Support läuft voll, eine Regression trifft einen kritischen Fluss, ein Führungskraft stolpert darüber.

Diese Logik stellt Roadmap und Qualität künstlich gegenüber. Als ob Features die eigentliche Arbeit wären und Bugs ein Lärm, den man drumherum managen muss. Aber ein Bug verbraucht Kapazität. Er verbraucht auch das Vertrauen der Kunden, interne Glaubwürdigkeit, Support-Zeit und Produktaufmerksamkeit.

Ihn nicht zu zählen macht ihn nicht gratis.

Was „Zero Bugs" wirklich bedeutet

Eine Zero-Bug-Policy bedeutet nicht, dass es nie einen Bug geben wird.

Es bedeutet: null bekannte Bugs ohne Entscheidung.

Die Nuance ist wesentlich. Das Ziel ist nicht, das Unbekannte zu eliminieren. Das Ziel ist, die dauerhafte Akzeptanz bekannter Defekte nicht zu organisieren.

Wenn ein Signal eingeht, muss das Team schnell entscheiden: Ist das ein Defekt oder nicht?

Wenn es ein Defekt ist, wird er behoben.

Wenn es kein Defekt ist, wird er nicht als Bug behandelt. Das kann eine Verbesserung sein. Das kann eine Feature-Anfrage sein. Das kann ein Missverständnis sein. Das kann ein interessantes Thema sein, aber außerhalb der Priorität.

In jedem Fall gibt es eine Entscheidung.

Was die Zero-Bug-Policy ablehnt, ist der dritte Zustand: „Wir wissen, dass es ein Bug ist, aber wir behalten ihn für später in einer Liste."

Dieses „Später" ist oft das eigentliche Problem.

Die Falle des Bug-Backlogs

Ein Bug-Backlog vermittelt ein Gefühl der Kontrolle.

Alles ist aufgelistet. Jeder Bug hat eine Priorität. Manche sind blocker, andere major, minor, trivial. Man kann filtern. Man kann sortieren. Man kann ein Komitee einberufen. Man kann Tabellen produzieren. Man kann sagen, dass das Thema unter Kontrolle ist.

Aber einen Bug jeden Monat zu priorisieren ist nicht dasselbe wie ihn zu behandeln.

Oft ist es nur die Akzeptanz, dass er dort bleibt.

Der Defekt-Bestand schafft seine eigene Arbeit. Man muss prüfen, ob der Bug noch existiert. Man muss wissen, ob er noch prioritär ist. Man muss wissen, ob der betroffene Kunde noch Kunde ist. Man muss wissen, ob er noch reproduzierbar ist. Man muss wissen, ob er vor einer anderen Anomalie eingeplant werden muss. Man muss nochmals lesen, umklassifizieren, neu planen.

Die Organisation gibt Energie dafür aus, Defekte zu verwalten, statt die Qualität wiederherzustellen.

Und das Absurdeste: Viele dieser Bugs werden nie behoben werden.

Man weiß es. Das Team weiß es. Der Support weiß es. Der Product Manager weiß es. Aber das Ticket bleibt offen, weil Schließen bedeutet, eine Entscheidung zu übernehmen, die niemand tragen will.

Eine Zero-Bug-Policy erzwingt diese Entscheidung.

Zwei Entscheidungen: Defekt oder kein Defekt

Die Stärke des Porsche-Ansatzes liegt in seiner Einfachheit.

Statt die Kategorien zu vervielfachen, reduziert das Team die Entscheidung:

• defect: Es ist ein Defekt, also wird er behoben;
• no defect: Es ist kein Defekt, also wird er nicht als Bug behandelt.

Diese Vereinfachung bedeutet nicht, dass alles brutal oder automatisch wird. Man muss immer noch den Einfluss, den Kontext, den Kunden, die Häufigkeit, die Schwere verstehen. Aber die Diskussion muss zu einer Entscheidung führen, nicht zu einer neuen Kategorie.

Eine Verbesserung kann nützlich sein, ohne ein Defekt zu sein.

Eine Kundenanfrage kann relevant sein, ohne ein Bug zu sein.

Ein Verhalten kann frustrierend sein, ohne prioritär zu sein.

Was zählt, ist, die Abwägung nicht hinter einer Typologie zu verstecken.

Wenn es ein echter Defekt ist, wird er behandelt. Wenn nicht, wird das akzeptiert. Aber man behält keinen bekannten Bug indefinit in einer Warteschlange, die hauptsächlich dazu dient, eine Entscheidung zu vermeiden.

Bug oder Feature: dem Kunden ist es egal

Aus der Sicht des Kunden hat die Unterscheidung zwischen Bug und Feature wenig Interesse.

Der Kunde fragt sich nicht, ob er unter einem Bug, einem fehlenden Feature, einem schlecht gemachten Feature oder einem Feature leidet, das nicht seinem Bedarf entspricht. Er spürt einen Schmerz.

Eine Software kann keinen einzigen technischen Bug haben und trotzdem dem Kundenbedarf nicht entsprechen. Der Schmerz ist trotzdem real.

Umgekehrt sind manche Bugs objektiv Defekte, aber ihr Einfluss ist gering. Wenn der Benutzer zweimal auf einen Button klicken muss, ist das nicht ideal. Aber wenn daneben ein fehlendes Feature ihn daran hindert, eine Pflichtsteuer- oder gesetzliche Erklärung zu machen, ist das fehlende Feature kritischer als der kleine Bug.

Deshalb darf die Ticket-Kategorie nicht die Schmerzanalyse ersetzen.

Die eigentliche Frage ist nicht: „Ist das ein Bug oder ein Feature?"

Die eigentliche Frage ist:

• Welchen Schmerz erzeugt das?
• Für wen?
• Mit welcher Häufigkeit?
• Mit welchem Einfluss?
• Ist es blockierend?
• Ist es regulatorisch?
• Erzeugt es Support?
• Zerstört es das Vertrauen?

Die Typologie kann helfen zu messen. Sie darf nicht an Stelle des Teams entscheiden.

Eine radikale Position einnehmen: keine separaten Bug-Karten

Man kann noch weiter gehen.

In vielen Organisationen würde ich die separaten Bug-Karten in Jira oder äquivalenten Tools abschaffen. Ich würde nur noch Arbeitskarten behalten.

Warum?

Weil die Trennung Bug / Feature am Ende oft zwei Prioritätssysteme schafft. Features werden von der Roadmap gesteuert. Bugs werden von Dringlichkeit, Support, Kundendruck oder Priorisierungskomitees gesteuert. Und zwischen beiden schaut niemand wirklich das Gesamte unter dem Blickwinkel von Schmerz und Wert an.

Eine Arbeitskarte sollte ein zu bearbeitendes Problem darstellen.

Manchmal kommt dieses Problem aus einem Software-Defekt. Manchmal aus einer fehlenden Fähigkeit. Manchmal aus einem schlechten Design. Manchmal aus technischen Schulden. Aber die Abwägung muss dieselbe bleiben: Welcher Schmerz, welcher Wert, welcher Einfluss, welche Entscheidung?

Das morgendliche Daily kann dann dazu dienen, zu entscheiden, was jetzt wirklich zählt. Nicht zwanzig Minuten lang zu debattieren, ob etwas ein Bug, ein Feature, eine Verbesserung oder ein Rework ist.

Natürlich brauchen manche Organisationen Qualitäts-Reporting. Man kann Tags, Metriken, minimale Kategorien beibehalten. Aber das sind sekundäre Informationen. Sie dürfen nicht die gesamte Entscheidung strukturieren.

Entweder jetzt behandeln oder ablehnen

Der schlimmste Zustand eines Bugs ist nicht „nicht behoben".

Der schlimmste Zustand ist „später priorisieren".

„Später" scheint vernünftig. In Wirklichkeit ist es oft eine höfliche Art, nicht zu entscheiden.

Manche Bugs müssen sofort behandelt werden.

Andere müssen explizit abgelehnt werden. Man kann eine minimale Karte schreiben, wenn man einen Nachweis behalten will: „Wird nicht gemacht." Aber man soll kein endloses Bug-Backlog füttern, um den Eindruck zu erwecken, dass das Thema noch existiert.

Die Disziplin ist einfach:

• Wenn es ein echter und wichtiger Defekt ist, wird er behoben;
• Wenn es kein Defekt ist, wird er aus der Bug-Verwaltung entfernt;
• Wenn er zu gering ist, um behandelt zu werden, wird das akzeptiert;
• Wenn er häufig wiederkommt, wird er mit neuen Signalen neu bewertet.

Das Ziel ist nicht, dogmatisch zu werden. Das Ziel ist, die Organisation zu zwingen, eine Entscheidung zu produzieren.

Die Velocity muss die Qualität absorbieren

Einen Defekt sofort zu beheben kann die Velocity beeinflussen.

Das kann dazu führen, ein Feature nicht fertigzustellen. Das kann ein Sprint-Ziel stören. Das kann ein Roadmap-Thema verzögern. Das ist unangenehm, aber normal.

Qualität verbraucht Kapazität.

Wenn ein Team Bugs ignoriert, um seine Velocity zu erhalten, schützt es eine Metrik auf Kosten des Produkts. Es vermittelt den Eindruck, schnell voranzukommen, sammelt aber Reibung, Support, Schulden und Misstrauen an.

Eine Zero-Bug-Policy macht diesen Preis sichtbar.

Wenn Defekte das Team verlangsamen, ist es nicht die Zero-Bug-Policy, die das Problem schafft. Sie zeigt schlicht, dass das System zu viele Defekte produziert oder sie zu spät erkennt.

Die richtige Antwort ist nicht, Bugs im Backlog zu verstecken. Die richtige Antwort ist, das Produktionssystem zu verbessern: Tests, QA, TDD, Automatisierung, Klärung der Spezifikationen, Verantwortung der Entwickler.

Das wird das Thema des nächsten Artikels sein.

Wie man mit einem bestehenden Bestand startet

Die Schwierigkeit entsteht, wenn das Team bereits einen Bug-Bestand hat.

Man kann eine radikale Option wählen: alle bestehenden Bugs schließen und von vorne anfangen. Das ist sauber, aber politisch schwierig. Es erfordert hohes internes Vertrauen und die Fähigkeit, Ablehnungen zu vertreten.

Man kann auch eine schrittweise Option wählen.

Der Porsche-Artikel schlägt eine stufenweise Reduktionslogik vor: ein letztes Mal priorisieren, eine kleine Anzahl von Defekten pro Sprint behandeln und ein neues temporäres Null definieren. Wichtig ist, dass diese Phase eine Übergangsphase bleibt, keine neue normale Form des Backlogs.

Eine sehr wirksame Methode ist der Weg über den Support.

Jede Woche listet der Support die Top 3 der Kundenmeldungen zu Bugs.

Diese Top 3 werden die Top 3 der zu behandelnden Bugs.

In der nächsten Woche, wenn ein, zwei oder drei Bugs behoben wurden, schlägt der Support die nächsten vor.

Man geht nach Pareto vor. Man behandelt zuerst, was am häufigsten vorkommt, was am meisten schmerzt, was die höchste Support-Last erzeugt. Man fängt nicht damit an, hundert Tickets neu zu priorisieren. Man behandelt die Ärgernisse, die die Organisation wirklich belasten.

Diese Methode hat einen doppelten Vorteil.

Zuerst reduziert sie den sichtbaren Kundenschmerz.

Dann entlastet sie den Support.

Der Support sieht, dass seine Rückmeldungen etwas nützen. Das Produktteam behandelt die Probleme, die wirklich wiederkommen. Die Entwickler verlieren sich nicht in einer abstrakten Liste. Die Führung sieht, wie Ärgernisse verschwinden.

Um aus einem Bug-Bestand herauszukommen, muss man nicht damit anfangen, alles neu zu priorisieren. Man behandelt, was am häufigsten vorkommt und am meisten schmerzt.

Nützliche Metriken, ohne administrative Obsession

Es geht nicht darum, jede Messung abzuschaffen.

Manche Metriken sind nützlich:

• das Rework;
• die Cycle Time;
• die Regressionen;
• die vor der Produktion gefundenen Defekte;
• die in der Produktion gefundenen Defekte;
• die Support-Last durch bestimmte Bugs.

Diese Messungen können die Qualität beleuchten. Sie helfen zu sehen, ob das Team seine Arbeit zu oft wiederholt, ob bestimmte Flüsse regelmäßig brechen, ob ein Bereich des Produkts zu viel Support erzeugt, ob Defekte zu spät erkannt werden.

Aber die Metrik muss ein Werkzeug bleiben.

Wenn das Team mehr Zeit damit verbringt, Defekte zu qualifizieren als das System zu verbessern, recreates es das Problem, das es lösen wollte. Man ersetzt dann das Bug-Backlog durch ein Kategorien-Backlog.

Das Ziel ist nicht, alles zu messen. Das Ziel ist, den Schmerz zu reduzieren und den Fluss zu verbessern.

Fazit

Eine Zero-Bug-Policy macht die Software nicht magisch.

Sie macht es nur unmöglich, bekannte Defekte hinter einem Backlog zu verstecken.

Sie zwingt zur Entscheidung. Sie macht Qualität sichtbar. Sie verhindert, dass Bugs zu einem administrativen Bestand werden. Sie zwingt die Organisation zu wählen: beheben, ablehnen oder als etwas anderes umklassifizieren.

Das ist radikal, aber genau das macht den Ansatz nützlich.

Solange ein Bug sechs Monate lang im Backlog schlafen kann, ist niemand wirklich für die Entscheidung verantwortlich. Eine Zero-Bug-Policy stellt diese Verantwortung wieder in den Mittelpunkt.

Aber sie reicht nicht aus.

Wenn das Team schnell behebt, ohne die Art der Lieferung zu ändern, bleibt es in einer Reparaturschleife. Das eigentliche nächste Thema ist deshalb die Prävention: Verantwortung der Entwickler, klare Spezifikationen, TDD, QA, Automatisierung, zukünftiges Legacy.

Mit anderen Worten: Eine Zero-Bug-Policy behandelt den Bestand. Die Lieferungsqualität verhindert, ihn neu zu erzeugen.

Weiterführendes

Qualität gehört denen, die liefern Das Backlog ist kein Mülleimer: Es ist ein Werkzeug zum Handeln