… neulich in zwei(!) mir bekannten Projekten …

Bugs als Chance !

Warum werden in so vielen Projekten Defects (Bugs) nicht als Chance, d.h. als Chance etwas generell zu verbessern, wahrgenommen?

Man schimpft lieber über die Menge an Defects und/oder den Verwaltungsaufwand und/oder spielt symptomatische „Top X“-Wettkämpfe [„… die Top-10-Defects müssen(!) aber bis zum nächsten Sprint erledigt sein …“, zur Not zieht man den „Überstunden“- und/oder „Wochenendarbeit“-Joker: „… die können ruhig mal ein Stündchen dran hängen …“].

Oder man wettert über „doppelte Buchhaltung“ von Defects in klassischen QA- plus agilen Tools („Defects im ProductBacklog? Viel zu viel Aufwand … das machen wir pragmatischer nebenher … wir sind froh, dass das PBL sauber ist …“), als sich mit der Defect-Thematik proaktiv auseinander zu setzen [tatsächlich zeigt sich schnell, dass selbst die Zeit, die mangels einer Automatik (Batches, Scripts, …) für ein „bio-mechanisches Interface“ beim jeweiligen (Teil-)Transfer zwischen den Tools für Transparenzgewinn investiert(!) wird, nichts ist gegenüber durch „tolerierte“ Defects konzern-weit unnötigerweise und um ein Vielfaches mehr verschwendeter Resourcen].

“Stop worrying about the defect database and
start worrying about why you are still creating code
where defects are discovered a significant amount of time
after the code has been written.”

Mary Poppendieck

Mindset

In vielen Projekten fehlt es bei den Beteiligten – häufig grundsätzlich(!) – an der entsprechenden Einstellung – hierbei denke ich noch nicht einmal an eine „Zero Defects Mentality“ -, ganz zu Schweigen an einer Strategie.

Es werden eher aberdutzende Fehler – wie ein Hamster in seinem Rad kreisend – einfach „runter gekloppt“, als den eigentlichen Problemen auf den Grund zu gehen – Sisyphos lässt grüßen. Gerade in klassischen Wasserfall-Kontexten wird es alternativlos als „normal“ gepredigt, dass „… zum Ende der Release-Phase üblicherweise mit hunderten von Fehlern [zu] rechnen …“ ist.

Möglicherweise werden noch – eher zufällig – Defect-Cluster erkannt, aber eine jeweils konkrete Ursachenanalyse findet nicht statt. Defects aus lange abgenommenen Stories treffen Entwicklungsteams immer wieder geradezu überraschend. Mit völligem Unverständnis seitens des ProductOwners, des Fachbereichs oder der Stakeholder. Obwohl, häufig versteht sich auch der PO nur als Defect-Manager und stöhnt gern über die Defect-Menge, zeigt sich aber bei (s)einer Maßnahmen-Unterstützung erstaunlich phlegmatisch. Dass gerade er fehlerfreie Anwendungen nicht nur fordern, sondern auch fördern muss, wird oft nicht erkannt.

Warum werden keine Vorkehrungen für eine nachhaltige Qualitätsverbesserung getroffen, sondern lieber über „… XP, TDD, TestFirst … und auch Mocking funktioniert bei uns nicht …“ lamentiert?

Es fühlt sich – irgendwie typisch deutsch(?) – an, dass man mal wieder lieber Energie in „einen Sündenbock suchen“ verbrät, als diese Energie in „aus Fehlern lernen“ zu investieren (unerwarteterweise habe ich gerade in einem italienischen Projekt dieses unmittelbare „aus Fehlern lernen“ mit einer erfrischenden Selbstverständlichkeit erlebt; „unerwartet“ deshalb, da ich bei einem freundlichen „a domani“ [wörtliche Übersetzung „bis morgen“] im Alltag häufig schmerzhaft ein „demnächst, irgendwann einmal“ erlernen musste 😉

Lernen als Optimierungspotential

„Wenn Du weißt, dass Du einen Fehler begangen hast und ihn nicht verbesserst, dann ist dies wirklich ein Fehler.“
Konfuzius

In diesem Sinne

CU
@ Boeffi  .net     aktualisiert am 24.05.2018