Von Blame Culture zur konstruktiven Fehlerkultur: Ideen aus der DevOps-Welt

Spätestens seit dem Film „Manche mögen’s heiß“ aus den späten 1950er Jahren wissen wir: Nobody’s perfect. Das gilt natürlich auch für IT-Abteilungen, wo Bugs und andere Schwachstellen im Code sowie deren Behebung zum Tagesgeschäft gehören. Doch Fehler sind nicht zwangsläufig etwas Schlechtes. Sie können helfen, Entwicklungs-, Auslieferungs- und Implementierungsprozesse von Software nachhaltig zu verbessern – die richtige Fehlerkultur vorausgesetzt. 

Der Umgang mit Fehlern ist in manchen Unternehmen allerdings noch ausbaufähig – obwohl bekannt ist, dass eine negative Fehlerkultur extreme wirtschaftliche Auswirkungen haben kann: Herrscht eine sogenannte Blame Culture, bei der es vor allem um das Finden und sogar Bestrafen von Fehlern geht, vertuschen Mitarbeiter diese eher, als sie zum Vorteil zu nutzen. Das Ergebnis sind dann meist fehlerhafte Lösungen, deren Probleme den Betrieb der Kunden und damit das Vertrauen in den Dienstleister schädigen sowie zeitraubende Bugfixings nach sich ziehen.

Zero Defects bedeutet nicht Zero Tolerance

Wie vor allem IT-Abteilungen nachhaltiger aus Fehlern bei der Entwicklung von Software lernen können, zeigt die DevOps-Bewegung eindrucksvoll. Sie beeinflusst nicht nur auf technologischer Ebene die Zusammenarbeit zwischen Entwicklern und IT-Betrieb sehr stark, sondern auch insgesamt die Unternehmens- und mit ihr die Fehlerkultur: Der DevOps-Ansatz lehnt eine Strategie ohne Fehlertoleranz ab. An ihre Stelle tritt die Zero-Defects-Philosophie, deren Grundsatz das Streben nach Perfektion ist. Der Unterschied liegt im Detail, denn beide Ansätze verfolgen das Ziel eines „perfekten“ Produkts. Zero Defects bedeutet allerdings, dass durchaus Raum für Fehler ist, aus denen die Beteiligten wertvolle Informationen für die Prozessoptimierung ziehen. Perfektion ist in diesem Zusammenhang eher als Leitmotiv zu verstehen, weniger als tatsächlich erreichbares Endergebnis.

Praktisch steht an erster Stelle des richtigen Umgangs mit Fehlern natürlich deren Prävention und damit zunächst eine exakte Planung. IT-Dienstleister treffen daher mit Kunden klare Absprachen, wie das Design der Software aussehen soll, bevor die Entwickler eine Zeile Code schreiben. Für die möglichst fehlerfreie Umsetzung beinhaltet der DevOps-Werkzeugkasten dann klassische Code Reviews und Tests, also das Prüfen des Codes durch die Ersteller, sowie Peer Reviews, bei denen Kollegen den Code eingängig nach möglichen Fehlern durchforsten. Ein etwas aktuellerer Ansatz ist Test-driven Development (TDD). Die Maßnahme zur Qualitätssicherung stellt das Entwickeln von Tests für die zu schreibende Software vor den eigentlichen Coding-Prozess.

Schrittweise zu mehr Perfektion

Doch, wie erwähnt, werden Fehler trotz aller Präventivmaßnahmen immer wieder vorkommen. Daher sollte die Softwarearchitektur schnelle Bugfixes zulassen: Beispielsweise ermöglichen heutige Cloud-native Anwendungen auf Knopfdruck Installationen und Neustarts innerhalb von wenigen Millisekunden. Die Software-Updates, die meistens täglich stattfinden, werden vom Anwender somit gar nicht mehr wahrgenommen. Auch die Prozesse für Fehlerkorrekturen müssen flexibel sein und Priorisierungen ermöglichen, sodass kleine Bugfixes nicht Wochen dauern. Neben den technischen und prozessualen Grundlagen ist für ein schnelles Bugfixing auch eine gute Teamdynamik wichtig. Sogenannte Dailys, also kurze tägliche Meetings, bieten die Gelegenheit, Fehler zu besprechen – egal ob technische oder organisatorische – und gemeinsam eine Lösung zu erarbeiten. Überhaupt ist klare und verzögerungsfreie Kommunikation ein Schlüsselelement für eine gesunde Fehlerkultur. Das gilt bei IT-Dienstleistern vor allem gegenüber ihren Kunden: Kommt es zu einem Fehler, müssen sie ihre Kunden proaktiv davon in Kenntnis setzen – bestenfalls bevor diese selbst merken, dass etwas nicht stimmt. Noch besser handeln die Dienstleister, wenn sie gleich eine mögliche Lösung in petto haben oder sogar bereits an der Behebung des Problems arbeiten. Zu einer konstruktiven Fehlerkultur gehört auch, umfangreiche Retrospektiven durchzuführen – egal ob teamintern oder mit dem Kunden. Sie bieten die Gelegenheit, Prozesse zur Fehlerbehebung gemeinsam zu analysieren und – wenn nötig – zu optimieren. 

Die schlechte Nachricht ist, dass leider auch die gesündeste und offenste Fehlerkultur nicht an dem Grundsatz „Nobody’s perfect“ rütteln kann. Jedoch – und das ist die gute Nachricht – sorgt sie mit jedem gefundenen und behobenen Fehler für ein klein wenig mehr Perfektion in Unternehmen und DevOps-Teams.

* Christian Wied ist Teamleiter Software Engineering bei Consol in München

trendreport.de 

creativecommons.org