Hast Du auch schon einmal gehört, dass man es im agilen Umfeld mit Fehlern nicht so genau nehmen müsse?

„80:20 ist völlig ausreichend – wir sind ja agil!“

Dazu möchte ich heute ein paar Worte verlieren und darüber schreiben, was an diesem Satz eventuell dran ist.

Falls Du meinen letzten Blog Artikel zum Cynefin Modell noch nicht gelesen hast, wäre jetzt eine gute Gelegenheit dazu, denn ich werde mich darauf beziehen.

Lernkultur oder Fehlerkultur?

Heute werde ich den Begriff Lernkultur verwenden. Fehlerkultur klingt so, als wollten wir Fehler kultivieren. Oder es klingt nach Fingerpointing – „Er wars!“. Beides gefällt mir nicht. Hier geht es eher darum, aus Fehlern zu lernen und zu erkennen, wann Fehler nützlich sind und wann sie besser vermieden werden. Wobei ich auch danach Fragen werde, ob wir überhaupt überall von Fehlern sprechen können, wenn etwas nicht so ausgeht, wie wir es uns wünschen.

Lernkultur und Paradigmenwechsel

Im Artikel über das Cynefin Modell schrieb ich vom Paradigmenwechsel beim Übergang von der einfachen bzw. komplizierten Welt zur komplexen bzw. chaotischen Welt. Ich schreibe ab jetzt der Einfachheit halber nur noch von kompliziert und von komplex und meine damit jeweils beide zusammengehörige Lebensräume.

Ich hatte erklärt, dass in der komplizierten Welt klassische Arbeitsweisen wie zum Beispiel Projektpläne sehr hilfreich seien, während in der komplexen Welt agile Methoden zielführender wären. Dieser Übergang wurde von mir als Paradigmenwechsel bezeichnet.

Wenn wir jetzt diese Lebensräume aus der Perspektive des Umgangs mit Fehlern ansehen, erleben wir einen ganz ähnlichen Paradigmenwechsel!

Fehler in der komplizierten Welt

In der komplizierten Welt gibt es ein eindeutiges „Richtig“ oder „Falsch“. Daher können wir auch ganz klar sagen, dass wenn „Falsch“ eintritt ein Fehler gemacht wurde. Da in der komplizierten Welt Pläne funktionieren und Anleitungen erstellt werden können, sollten wir solche Tools nutzen, um Fehler zu vermeiden. Eine gut gemachte Anleitung ermöglicht es auch einem Laien einen komplizierten Prozess zu durchlaufen ohne Fehler zu machen.

Passiert doch einmal ein Fehler, so sollten wir darauf bedacht sein, ihn nicht noch einmal zu wiederholen. Wir könnten zum Beispiel unsere Anleitung anpassen oder an geeigneter Stelle eine Warnung anbringen oder unsere Kollegen schulen.

Fehler in der komplexen Welt

Wie schon im letzten Artikel gelernt, ist hier die Welt nicht so eindeutig und klar. Sie zeichnet sich gerade dadurch aus, dass im vorhinein nicht eindeutig klar bestimmt werden kann, was „Richtig“ und was „Falsch“ ist. Selbst wenn ein Vorhaben in dieser Welt gelingt, können wir nicht mit Sicherheit feststellen, ob wir ein optimales Ergebnis erreicht haben. Wir können lediglich diesen Erfolg mit einem anderen Erfolg vergleichen und feststellen, ob wir mit dem Ergebnis eher mehr oder eher weniger zufrieden sind, als mit dem anderen Ergebnis.

Der Legende nach soll Edison tausende Versuche gebraucht haben, bis er eine funktionierende Glühlampe konstruiert hatte. Er sprach aber nicht von vielen Fehlern, sondern meinte er hätte tausende Wege gefunden, eine Glühlampe NICHT zu bauen.

In der komplexen Welt würde ich daher nicht von Fehlern sprechen, sondern eher von Irrtümern. Aus heutiger Sicht war auch seine funktionierende Glühlampe nicht perfekt, sondern eher der damals aktuelle Stand des Irrtums. Nur eben ein grundsätzlich funktionierender Stand.

Genau wie in der komplizierten Welt ist es auch in der komplexen Welt sinnvoll und wichtig, diese Irrtümer als Lernmomente zu begreifen. Nur kann man hier leider keine Anleitung schreiben, die zum Erfolg führt. Man kann aber sehr wohl Erfahrungen sammeln und nach Gemeinsamkeiten von Irrtümern suchen, um die Wahrscheinlichkeit von zukünftigen nicht funktionierenden Irrtümern zu reduzieren.

Der Paradigmenwechsel

Während es also in der komplizierten Welt sinnvoll ist Fehler zu vermeiden, gehören Versuch und Irrtum in der komplexen Welt einfach dazu!

Wenn wir also einfache oder komplizierte Aufgaben machen, dann sollten wir zusehen keine Fehler zu machen. Das gilt auch für agile Teams, die insgesamt komplexe Aufgaben lösen. Wenn im Zuge dessen aber auch einmal eine Präsentation erstellt wird, in der Zwischenergebnisse gezeigt werden oder eine Mail geschrieben wird, dann sollten diese frei von Tippfehlern und falschen Inhalten sein. Denn die Präsentation und die Mail sind komplizierte Aufgaben, die in diesem Fall nur zufällig in ein komplexes Umfeld eingebettet sind. Der eingangs genannte Satz „80:20 ist völlig ausreichend – wir sind ja agil“ passt hier also ganz und gar nicht.

Andererseits ist es auch nicht sinnvoll in einer Welt, in der sich 100% richtig gar nicht eindeutig bestimmen lässt, immer weiter zu optimieren und so nicht zum Ergebnis zu kommen. Hier kann 80:20 durchaus sinnvoll sein, in dem Sinne, dass zwar nicht alles optimiert wurde, was optimiert werden kann, aber dennoch die Anforderungen an das Ergebnis ausreichend gut erfüllt sind.

 

Das agile Manifest – was sagt das dazu?

In den Prinzipien hinter dem agilen Manifest zur Softwareentwicklung steht unter anderem der Satz „Funktionierende Software ist das wichtigste Fortschrittsmaß.“ Es dürfte klar sein, dass Software besser funktioniert, wenn sie keine Fehler enthält. 

Es steht dort auch „Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.“ Auch technische Excellenz klingt jetzt nicht gerade nach einem Haufen Fehler.

Die Idee dahinter ist zum Einen den Kunden zufrieden zu stellen. Das gelingt sicher besser, wenn er sich nicht permanent über Fehlermeldungen ärgert. Natürlich gibt es auch Fehler in Software, die der Kunde im Zweifel nie bewusst wahrnimmt, weil die entstehenden Fehlermeldungen zum Beispiel automatisch abgefangen und ein Workaround gestartet wird. An der Stelle kommt zum Tragen, dass es zum Anderen gilt jederzeit flexibel auf Veränderungen reagieren zu können. Wenn die Entwickler aber nicht nur den richtigen Sollprozess in ihre Überlegungen für die notwendigen Anpassungen im Blick haben müssen, sondern auch noch zusätzlich sämtliche Umwege zum Kaschieren von nicht beseitigten Fehlern, dann endet das bald im Chaos.

Viele agile Teams entscheiden sich daher für eine Zero-Bug-Policy oder auch Null-Fehler-Toleranz. Das bedeutet, dass erkannte Fehler entweder behoben werden oder der betroffene Teil des Produktes gelöscht wird, falls er nicht zwingend erforderlich ist. Handwerklich falsch geschriebener Programmcode ist kompliziert – auch wenn das Projekt zu dem der Code gehört ein komplexes Problem lösen soll.

Natürlich bezieht sich das Manifest auf agile Softwareentwicklung, allerdings sind die Prinzipien dahinter auch sehr gut auf andere Aufgabengebiete übertragbar.

(Danke an Martin, der mit seinem Kommentar unter dem letzten Artikel diesen kleinen Ausflug anregte.)


Tipp

Der offene und konstruktive Umgang mit Fehlern muss geübt werden. Gerade in Deutschland werden wir in der Schule und häufig auch im Berufsleben eher dazu angehalten Fehler zu vermeiden. Das kann dazu führen, dass Fehler vertuscht werden – was häufig weitere Fehler nach sich zieht.
Besser ist es, wenn Du mit Deinem Team regelmäßig Lernmomente schaffst, in denen auch über Dinge gesprochen werden kann, die nicht optimal gelaufen sind. Ein Format dafür ist die Retrospektive, über die ich früher schon einmal geschrieben habe. Wenn Du möchtest, unterstütze ich gerne dabei!


Der offene Umgang mit Fehlern bedeutet für den einen oder anderen ganz sicher einen Schritt aus seiner Komfortzone. Was das ist und warum die Komfortzone gar nicht immer so richtig komfortabel ist, erzähle ich im nächsten Beitrag.

Wenn Dir mein Blog gefällt, teile den Artikel gerne mit Deinen Kontakten! Hast Du eine Frage, Anregung oder Ergänzung, dann nutze die Kommentarfunktion hier im Blog.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert