„Definition-Of-Fail“ (Firmenfunk Podcast FF51)

Ich habe heute morgen im Auto die Folge FF51 vom Firmenfunk Podcast (Twitter) von
Leonid Lezner (Twitter) angefangen. Titel: „Scheitern und Feiern“ mit Udo Wiegärtner (Twitter). Ich habe den Podcast über die iOS Podcast App abonniert. Im Netz ist die Folge zu finden unter: https://firmenfunk.com/ff051-scheitern-und-feiern

Die beiden unterhalten sich über Scheitern und Versagen in und um Projekte. Dabei kam der Begriff „Definition-Of-Fail“ auf. Im Agilen Umfeld kenne ich die „Definition-Of-Done“ und die „Definition-Of-Ready“, aber von einer „Definition-Of-Fail“ habe ich bisher noch nicht gehört oder gelesen.

Aber alleine die ersten 25 Minuten haben mich schon dermaßen zum Nachdenken gebracht, so dass ich meine Gedanken in diesem Blogbeitrag niederschreiben möchte.

Ich finde das total spannend und wichtig, sich auch über einen „Fail“ Gedanken zu machen und mal aufzuschreiben, wann in einem Projekt oder in einer Firma ein „Fail“ vorliegt. Nicht um jemanden anzuklagen oder an den Pranger zu stellen, sondern um zu lernen und sich kontinuierlich zu verbessern!

Häufig wird mit der Entschuldigung „Wir arbeiten doch agil!“ solange an etwas rumgeschraubt, was man vielleicht nach ein paar Sprint besser hätte einstellen oder nachjustieren sollen. Bsp: Es soll etwas Neues implementiert werden, ein Sprint, noch ein Sprint, vielleicht noch einer, weil die Anforderungen doch nicht ganz klar waren oder die sich ändern. Dann noch zwei, drei, vier Bugfix Sprints und noch ein oder zwei leichte Änderungen und noch ein Bugfix Spring und und und …. Ich denke Ihr merkt worauf das hinausläuft. Mir hat das Beispiel von Herrn Wiegärtner gut gefallen:

Wenn Sie einen Kuchen backen, der Teig schon angerührt ist, sie Ihn probieren und feststellen, er ist versalzen, dann backen sie den Kuchen doch auch nicht zu Ende, oder?

 Udo Wiegärtner Firmenfunk Podcast FF51

Vielleicht hätte man nach dem zweit Bugfix Sprint schon feststellen können, dass ein Feature mit 3 Erstellungssprints höchsten einen Bugfix Sprint haben darf und beim zweiten Bugfix Sprint müssten Alarmglocken angehen, damit man hinterfragt, warum man in diesem Zustand ist. Waren die Specs unzureichend? Wird die Software anders benutzt als erwartet? Beherrschen die Entwickler die Technologie (Stichwort Cloud Plattform) doch nicht so gut und es man müsste eher einen Schulungssprint einlegen? Macht den Leuten das Projekt keinen Spaß, aber sie müssen weil es so bestimmt wurde (Motivationslos-Projekte)?

Wenn man in der Firma oder auch nur in der Abteilung oder Gruppe gemeinsam eine „Definition-Of-Fail“ aufschreibt und später symbolisch auch unterschreibt, dann ist jedem klar wann der Fall eintritt und was dann zu tun ist -> ohne Diskussion, ohne Schuldzuweisungen, ohne Probleme. Oft werden Entscheidungen, etwas nicht mehr zu machen und damit aufzuhören nicht getroffen, weil die entscheidenden Personen nicht wissen was da genau zu tun ist und was es für Konsequenzen gibt.

Ich werde in den nächsten Tagen auf diesem Thema weiter rumdenken und schauen wie ich diesen Gedanken in meine Arbeit integrieren kann.

Danke Leonid und Udo bisher! Mal sehen was mich heute Abend auf der Rückfahrt in Eurem Podcast noch erwartet!