Zum Inhalt springen

Suchen...

Von der Schuldfrage zur Fehlerkultur

Fehlerkultur klingt gut auf dem Vision Board, bricht aber beim ersten echten Bug zusammen. Was wirklich hilft, bevor der Stress kommt.

7 Min. Lesezeit
Cover für Von der Schuldfrage zur Fehlerkultur

Fehlerkultur bezeichnet den offenen Umgang eines Teams mit Softwarefehlern und Defects: Fehler werden nicht versteckt oder sanktioniert, sondern als normaler Teil des Entwicklungsprozesses anerkannt. Das gelingt, wenn Teams zu Projektbeginn gemeinsam klären, was ein Fehler bedeutet und wie damit umgegangen wird. Prozesse allein reichen dafür nicht aus, entscheidend ist die zwischenmenschliche Ebene.

Das Wichtigste in Kürze

  • Fehlerkultur zeigt sich nicht in Hochglanz-Dokumenten, sondern darin, wie ein Team im konkreten Konfliktmoment mit einem gefundenen Defekt umgeht.
  • Wer am Projektanfang gemeinsam klärt, was das Finden von Fehlern für das Team bedeutet, legt den Grundstein dafür, dass Tester Defekte ohne Reibungsverluste kommunizieren können.
  • Qualitätsmanagement gewinnt an Gewicht, wenn Fehler-Metriken in formale Quality-Gates einfließen und Entscheidungen im Projekt beeinflussen, statt in Reports zu verschwinden, die niemand liest.
  • Das Lernen aus Fehlern scheitert meist nicht am Willen, sondern daran, dass keine Zeit dafür eingeplant wird; wer sie sich dennoch nimmt, vermeidet dieselben Fehler im nächsten Abschnitt.
  • Kritik wirkt konstruktiver, wenn man die Botschaft an den Menschen anpasst, ohne den Inhalt zu verfälschen, was Kenntnis der Person voraussetzt und nicht ab Tag eins funktioniert.

Fehlerkultur zeigt, wie es um den Projekterfolg steht

Der Umgang einer Organisation mit Fehlern ist ein verlässlicher Frühindikator für die Erfolgschancen eines Projekts. Wer beobachtet, wie ein Team auf Software-Defects oder auf Pannen im Ablauf reagiert, kann daraus ablesen, wie die Zusammenarbeit funktioniert.

Katja Radom arbeitet seit langem an IT-Transformationsprojekten, aus mehreren Perspektiven: Testing, Testmanagement, Qualitätssicherung, IT-Servicemanagement und Projektleitung. Aus diesen Rollen heraus zeigt sich ein Muster. Die Art, wie Fehler behandelt werden, gibt einen Rückschluss auf die Kultur. Und an dieser Kultur lässt sich etwas verbessern.

Prozesse und Tools bleiben dabei wichtig. Sie reichen aber nicht. Wenn die Kultur nicht stimmt, wirken festgeschriebene Abläufe nicht so, wie sie eigentlich könnten. Die Kultur ist nicht alles, aber sie ist der Hebel mit der größten Wirkung.

Warum gute Fehlerkultur am ersten Tag beginnt

Eine tragfähige Fehlerkultur entsteht, wenn ein Team früh klärt, was passiert, wenn Fehler auftauchen. Dieser Ton lässt sich am Anfang eines Projekts setzen, bevor der erste Defect für Reibung sorgt.

Der konkrete Einstieg ist ein Gespräch mit allen Beteiligten: Ist es für euch schlimm, einen Fehler zu finden oder zu machen? Wenn ja, wie ändern wir das? Wenn ein Team von Beginn an weiß, dass 30 gefundene oder gemachte Fehler kein Drama sind, weil alle in dieselbe Richtung arbeiten, sinkt der Druck im Einzelfall.

Damit rückt Fehlerkultur in die Nähe von People Change Management. Es geht nicht darum, ein Versprechen ins Projekthandbuch zu schreiben, sondern eine gemeinsame Erwartung herzustellen, bevor es ernst wird.

Offenheit auf dem Vision Board reicht nicht

Eine erklärte Offenheit verpufft, sobald der erste echte Fehler auftaucht. Eine Teststrategie oder ein Projekthandbuch kann festhalten, dass man offen mit Fehlern umgeht: Wenn dann etwas passiert, ist dieser Satz schnell vergessen.

Der Unterschied liegt in der Wiederholung. Im agilen Umfeld bietet sich die Retrospektive an, um das Thema regelmäßig aufzugreifen. In nicht-agilen Kontexten hilft ein fester Rhythmus, in dem sich das Team zusammensetzt und fragt, wie es lief.

Wirksam wird das erst, wenn es bis zur Projektleitung und zu den Stakeholdern verankert ist. Dann lässt sich auch einmal sagen: Wir haben gerade zu viel Reibung, weil auf einer bestimmten Ebene etwas nicht klappt. Innehalten und schauen, was sich ändern lässt, gehört zur Kultur dazu.

Versetz dich in die Rolle des anderen

Konflikte zwischen Rollen lösen sich leichter, wenn du verstehst, welchen Auftrag dein Gegenüber hat. Manager sind nicht selten Teil des Problems, doch hinter ihrem Verhalten stecken eigene Ziele und Zwänge.

Die nützliche Frage lautet: Was ist eigentlich die Aufgabe des Managers, welche Ziele hat er, welche habe ich? Manchmal ist es schlicht unvermeidbar, dass diese Ziele sich reiben. Wer das weiß, geht entspannter damit um, als wenn er erwartet, dass der andere genauso tickt wie er selbst.

Das gilt nicht nur für unterschiedliche Länder, sondern auch für unterschiedliche Rollen und Verantwortlichkeiten. Im Zweifel hilft Nachfragen. Gerade wenn es ohnehin schon kriselt, kannst du wenig verlieren. Eine Antwort bekommst du nicht garantiert, aber ohne Frage garantiert keine.

Stereotype über Kulturen taugen nur als Ausgangspunkt

Nationale Klischees über den Umgang mit Fehlern sind teils berechtigt, teils faul. Die Amerikaner, die Fehler feiern, die ernsten Norddeutschen: Solche Schubladen kommen irgendwo her, treffen aber längst nicht auf jeden zu.

Der produktive Umgang ist Neugier statt Schublade. Du vergleichst dein konkretes Gegenüber gegen das Klischee und schaust, was tatsächlich da ist. Das gilt für internationale Teams genauso wie für Kollegen aus dem eigenen Kulturraum.

Wie macht man Fehler im Projekt sichtbar genug

Fehlervermeidung gewinnt an Gewicht, wenn sie ins übergreifende Qualitätsmanagement eingebunden ist statt im Maschinenraum unter ferner liefen zu landen. Auf größeren Projekten heißt das konkret: Das Finden und Vermeiden von Fehlern fließt in ein Quality Gate ein.

Sobald dieses Gewicht in Projektentscheidungen einfließt, entsteht eine andere Dynamik. Wer testet und wer Dinge fertigstellt, damit getestet werden kann, arbeitet anders, als wenn am Ende nur ein Report entsteht, den niemand liest.

Kleinere Projekte haben selten einen formalen Quality-Gate-Prozess. Auch dort lassen sich Teile dieses Gedankens übernehmen. One size fits all gibt es hier nicht, aber Bausteine.

Aus Fehlern lernen kostet Zeit, die man einplanen muss

Lernen aus Fehlern scheitert meist nicht am Willen, sondern an fehlender Zeit. In vielen Projekten wird ein Bug geschlossen und nie wieder angesehen, nach dem Projekt passiert gar nichts mehr.

Die Analyse von Defects und von Pannen im Team braucht einen eigenen Slot. Der liegt selten im heißen Moment, etwa wenn ein in Stein gemeißelter Go-Live-Termin näher rückt und plötzlich weniger Testzeit bleibt. Dann gelingt es nicht immer.

Es muss kein dreitägiges Off-Site sein. Auch im kleinen Rahmen lohnt sich die Auswertung, wenn die Erkenntnisse in den nächsten Sprint oder Projektabschnitt einfließen. Du sparst hinterher Zeit, weil dieselben Fehler nicht noch einmal passieren. Der Reflex zum sofortigen Erfolg steht dem oft im Weg.

Ehrlich bleiben gehört dazu: Auch das funktioniert nicht jedes Mal. Aber ab und zu funktioniert es, und wer es gar nicht versucht, bei dem kann es nie funktionieren.

Kritik braucht erst die Beziehung, dann den Inhalt

Schwierige Botschaften kommen besser an, wenn man sein Gegenüber schon kennt. Am ersten Tag eines Projekts treffen Menschen aufeinander, die sich noch nicht einschätzen können. Die große Kritik gehört nicht an Tag eins.

Derselbe Inhalt lässt sich auf verschiedene Arten übermitteln. Je mehr Ausdrucksformen du für deine Botschaft kennst und je besser du die Person einschätzt, desto eher kannst du die Form anpassen, ohne den Inhalt zu verfälschen. Ganz vermeiden lässt sich ein Knall nie.

Der gesellschaftliche Eindruck, Kritik sei kaum noch möglich, spiegelt sich im Projektalltag nicht eins zu eins. Offenheit ist die Voraussetzung dafür, dass dieser Weg überhaupt funktioniert.

Wie nimmst du selbst Kritik an, ohne dich zu verteidigen

Der erste Impuls nach einer Kritik führt selten zu einer guten Reaktion. Hilfreicher ist, zunächst zuzuhören und den Impuls zu unterdrücken. Nach ein paar Minuten, manchmal erst am nächsten Tag, schaust du mit anderen Augen auf dieselbe Sache.

Dabei hilft eine einfache Frage: Welche Relevanz hat das, worüber ich mich gerade ärgere, morgen noch? In einer Woche? In einem Monat? Spätestens beim Monat lautet die Antwort oft: total egal. Diese Distanz macht den Blick neutraler.

Trennen lohnt sich außerdem: Was habe ich selbst in der Hand und kann ich ändern, und was ist eigentlich ein Problem des Gegenübers? Oft sagt eine Botschaft mehr über das Innenleben des Senders als über den, an den sie gerichtet ist.

Wenn du jemanden im Eifer überfahren hast, hilft ein nachträgliches Wort: Es tut mir leid, dass ich dich so überfahren habe, lass uns noch einmal darüber reden. Sich zu entschuldigen fällt vielen schwer, wirkt aber.

So startest du Fehlerkultur im Team, ohne sie zu erzwingen

Der einfachste Startpunkt ist der Beginn eines Vorhabens oder ein neu zusammengesetztes Team. Diese Luxussituation hast du nicht immer, deshalb braucht ein Start mitten im Laufenden Fingerspitzengefühl.

Frontal vorzupreschen kann nach hinten losgehen. Wenn ein Tester die Idee zur besseren Fehlerkultur über den Projektleiter ins Team trägt und dabei alle den Initiator anschauen, wird das leicht schlecht aufgenommen. Besser läuft es in der Gruppe und über die Gelegenheiten zum Austausch, die das jeweilige Setting hergibt.

Ein gangbarer Weg sieht so aus:

  • Zuerst mit jemandem sounden, mit dem du gut vernetzt bist.
  • Im Idealfall mehrere Mitstreiter gewinnen.
  • Gemeinsam ausprobieren: Was machen wir heute? Funktioniert das für uns? Wenn nicht, was ändern wir?
  • Niemals alles auf einmal umstellen.

Agile, hybride und Wasserfall-Teams brauchen dabei unterschiedliche Settings. Der Versuch, alles gleichzeitig zu ändern, ist zum Scheitern verurteilt.

Diese Seite teilen

Ähnliche Beiträge