Idee

Ein Defekt, der aus der Planung herausgehalten wird, verbraucht trotzdem die Kapazität des Teams

Info

Ursprünglich auf Französisch verfasst. Von KI übersetzt — der Sinn wurde bewahrt, nicht der Stil.

Hauptgedanke

Die Roadmap enthält die geplanten Features. Dort sind die Fristen sichtbar, dort wird abgewogen, dort werden Zusagen gemacht. Die Defekte bleiben daneben, als stillschweigende Last, um die man sich kümmert, „wenn man Zeit hat“.

Dabei verbrauchen sie dieselbe Kapazität: Entwicklerzeit, sobald behoben wird, Support-Zeit für jeden erklärten Workaround, Aufmerksamkeit des Produktteams bei jeder erneuten Durchsicht eines Tickets. Und sie verbrauchen, was sich nicht planen lässt — das Vertrauen des Kunden, der zweimal auf dasselbe Verhalten stößt, die interne Glaubwürdigkeit eines Teams, von dem man weiß, dass sich seine Ärgernisse nicht bewegen.

Sie nicht einzutragen macht sie nicht kostenlos. Es macht sie nur dort unsichtbar, wo als Einziges abgewogen wird.

Ergänzt durch „Qualität gehört denen, die liefern“ (2026-06-03). Derselbe Befund lässt sich gegen den Planungseinwand wenden, den man jeder Qualitätsregel entgegenhält: Einen Entwickler zu seinem eigenen Defekt zurückzuholen stört den Sprint, verschiebt das nächste Feature und kostet sichtbar. Qualität kostet Kapazität, und sie aus dem Plan herauszunehmen macht sie nicht kostenlos — es entfernt die Ausgabe nur von dem einzigen Ort, an dem sie sich mit den anderen vergleichen lässt.

Warum das wichtig ist

Damit fällt der Gegensatz zwischen Roadmap und Qualität, der die Features als die eigentliche Arbeit erscheinen lässt und die Defekte als Störgeräusch, das man nebenher verwaltet. Beide zehren vom selben Budget; nur eines wird gezählt.

Es geht also nicht darum, Zeit für die Defekte zu finden, sondern sie in den Plan aufzunehmen, in dem die Zeit verteilt wird.

Nuancen und Grenzen

Eintragen allein genügt nicht. Eine Defektliste ist auch ein Eintrag, und sie kann endlos bestehen bleiben, ohne dass je wirklich abgewogen wird.

Und die Last ist nicht gleichmäßig verteilt: Ein Defekt, auf den nie jemand stößt, verbraucht nichts, solange ihm niemand begegnet.

Offene Fragen

  • Wie beziffert man die Support-Last eines Defekts, bevor man ihn behoben hat?