In IT-Projekten und im tagtäglichen Betrieb von digitalen Produkten oder Services erleben wir immer mal wieder größere Störungen, Ausfälle oder Fehlfunktionen. Nicht selten wird dann schnell die Frage aufgeworfen, wer der Verursacher war und wer die Verantwortung für den entstandenen Schaden trägt. In den betroffenen technischen Teams herrscht zu dieser Zeit hektisches Treiben, um möglichst schnell den normalen Betrieb wiederherzustellen. Nachdem endlich wieder der Normalbetrieb hergestellt werden konnte, meistens nach stundenlangem Tüfteln, werden oft halb gare Informationen und knappe Entschuldigungen an die Betroffenen geschickt und alle kehren zu ihrer regulären Tätigkeit zurück. Nur die als „schuldig“ ausgemachten Personen müssen sich weitere Fragen der Manager gefallen lassen, auf die sie nur verteidigend antworten. Und schließlich gerät der Vorfall wieder schnell in Vergessenheit. Es gibt wohl niemanden, der sich über solche Vorfälle freut, die wir im IT-Jargon Incidents nennen. In diesen Situationen herrscht anstatt Neugier, nur Angst und Stress. Tatsächlich gibt es aber einen guten Grund mit Neugier und sogar Freude auf diese sogenannten Incidents zu reagieren. Denn hinter jeder großen und kleinen Störung verbergen sich große Chancen für grundsätzliche Verbesserungen. Um diese Chancen zu ergreifen, müssen wir, vor allem diejenigen in der Führungsverantwortung, zunächst eine positive Fehlerkultur etablieren. Das gelingt uns, indem wir Fehler als Chancen kommunizieren und damit das negative Stigma entfernen. Im besten Fall erreichen wir dadurch eine lernende Organisation, die systematisch aus unerwünschten Ereignissen und Fehlern Nutzen zieht.

Fataler Systemfehler

In der Theorie mag das vielen einleuchtend erscheinen, doch wie setzen wir es in der Praxis um? Dazu möchte ich über eine praxistaugliche Methode aus meinen Erfahrungen als Scrum Master in einem kritischen Projekt zur Erneuerung von interner Kundenservice-Software berichten. In diesem Projekt hat mein Scrum Team eine Webanwendung inkrementell um neue Geschäftsvorfälle erweitert. Dabei hat es sowohl den technischen Support des Live Betriebs als auch die Weiterentwicklung verantwortet.   Entwickelt haben wir gemäß Scrum-MVP Ansatz (Scrum mit dem sogenannten Minimum-Viable-Product-Ansatz nach Lean Startup). Dementsprechend haben wir die neuen Funktionalitäten sofort bereitgestellt, sobald das Minimum an fachlicher Vollständigkeit erreicht war. Natürlich hat die Komplexität von fachlichen Zusammenhängen und technischen Gegebenheiten auch häufiger zu kleineren und größeren Fehlfunktionen im Live Betrieb geführt und alle Augen waren dann auf unser Scrum Team gerichtet. Wie sollten wir mit dieser Situation umgehen? Das wir, bildlich gesprochen, das Schiff in voller Fahrt immer wieder schnell reparieren konnten, war erfreulich und zeugte von der großen Erfahrung und Kompetenz des Teams. Doch natürlich Stand auch bei uns die Frage im Raum, wie es denn zu den jeweiligen Fehlern überhaupt kommen konnte. Ganz bewusst habe ich als Scrum Master darauf hingewirkt, dass nicht nach den Schuldigen gesucht wurde, sondern danach was wir für die Zukunft aus den Fehlern lernen konnten, um als technisches Team stetig besser zu werden.

Benutzt habe ich dafür das Moderationsformat Blameless Post Mortem. Eine sinngemäße Übersetzung wäre „Fehleranalyse ohne Schuldfrage“. Diese Methode stammt aus dem DevOps Umfeld und wurde insbesondere durch einen Artikel von John Allspan über den Umgang mit Fehlern bei Etsy (eine Online-Shopping Firma) bekannt gemacht.

Wie funktioniert das Format Blameless Post Mortem und warum kann ich es zur Nachahmung empfehlen?

Das Blameless Post Mortem ist eine Gruppenmoderation, mit der systematisch die Ursachen eines Fehlers gefunden und Maßnahmen beschlossen werden, sodass dieser Fehler in der Zukunft ausgeschlossen werden kann. Dabei achtet der Moderator darauf, dass nicht der Schuldfrage nachgegangen wird, sondern der Hergang der Dinge sachlich und so neutral wie möglich rekonstruiert wird. Das Format fördert deshalb die Ehrlichkeit und Offenheit der Teilnehmer, weil es allein um das Lernen und die Verbesserung geht. Vorgegangen bin ich mit dem Team folgendermaßen:

  1. Wir benennen ein oder mehrere Personen aus dem Team, die sich um die schnellstmögliche Behebung des Fehlers kümmern und unbehelligt daran arbeiten dürfen. Als Scrum Master sende ich Informationen über den Fortschritt und zu Verhaltensmaßnahmen an die IT-Organisation und der Product Owner (PO) macht das Gleiche für die Fachorganisation, sodass alle wissen, wie sie sich verhalten sollen und das die Situation unter Kontrolle ist
  2. Ich mache einen Termin für das Post Mortem mit dem ganzen Team oder den relevanten Vertretern, der ein bis zwei Tage nach Behebung des Fehlers stattfindet
  3. Ich moderiere den Termin mit der Methode Five-Whys (siehe das Beispiel unten)
  4. Wir vereinbaren verbindlich im Team die Verbesserungs-Maßnahmen und wer sie bis wann umsetzt. Die Maßnahmen werden je nach Wichtigkeit im laufenden Sprint oder in einem der nächsten umgesetzt
  5. Der PO und ich als Scrum Master schicken weitere Informationen an die Stakeholder, die das Vertrauen in unserer Arbeit stärken

Ein Praxis-Beispiel der Five-Whys-Analyse

Five-Whys-Analyse
  • Maßnahme 1: Monitoring und Alarm für Speicherplatz einrichten – als Support Ticket an Systemadministration mit Priorität Hoch – To Do: Entwickler
  • Maßnahme 2: Löschroutine programmieren – DevOps Kollege nicht verfügbar!
  • Maßnahme 3: DevOps Ressourcen Problem transparent machen im Management und Handlungsoptionen prüfen – To Do: Scrum Master

Sehr interessant an der sogenannten Five-Whys-Analyse ist, dass die Fehler, die an der Oberfläche rein technisch anmuten, am Ende ihre Ursache häufig doch in sozialen und strukturellen Problemen finden. Die Five-Why-Analyse muss nicht nach genau Fünf Warums (wie es der Name vermuten lässt) enden, sie kann auch mehr Schritte und auch Abzweigungen haben, die dann jeweils zu einer getrennten Maßnahme führen.

Der Vorteil des Post Mortems mit Five-Whys ist, dass man in einer sachlichen Diskussion zu den echten Ursachen der Fehler vordringt. Dadurch können effektive Maßnahmen beschlossen werden, die verhindern das sich ähnliche Fehler wiederholen. Diese Maßnahmen sollten dann im agilen Entwicklungsprozess (Scrum) zeitnah umgesetzt werden – solange der Schmerz noch frisch ist und die Motivation damit hoch.

Zusammengefasst verlangt das Post Mortem-Format den Teams viel Disziplin und den Willen zur stetigen Verbesserung ab (Dinge, die der Scrum Master bzw. Team Manager aktiv fördern sollte). Es führt aber auch zu einer positiven Fehlerkultur, wodurch das Arbeiten in Unternehmen deutlich optimiert wird.

Jetzt teilen auf:

Jetzt kommentieren