Die Freude am Scheitern

Moderne Firmen sprechen meist lieber von «Fehlerkultur» als vom «Scheitern». Damit ist gemeint, dass ein Scheitern zwar nicht erwünscht, aber akzeptiert wird. Denn Fehlschläge führen zu wertvollen Lernerfahrungen, was für den Einzelnen oder ganze Organisationen eine wichtige Voraussetzung für die kreative und innovative Arbeit ist.

Beim Bergsport ist das Scheitern meist offensichtlicher und direkter spürbar als im Arbeitsalltag. Erreicht man den Berggipfel nicht oder fällt beim Sportklettern ins Seil, ist man gescheitert. Bei der Softwareentwicklung ist das Scheitern abstrakter, aber genauso präsent. Auch da können Fehler zu fatalen Folgen führen. Liefert man einem Flugzeughersteller beispielsweise eine schlechte Software, drohen wortwörtlich Abstürze.

Aber ist jeder Fehler richtig und wichtig? Wie und wo kann man sorglos scheitern und wo gilt Null-Toleranz? Dominik Berner, Senior Softwareingenieur und begeisterter Bergsteiger, hat die beiden Welten zusammengeführt und analysiert, wie und wo man gefahrlos scheitern kann und wo mit ernsthaften Konsequenzen gerechnet werden muss.

Nicht jeder Fehler hat fatale Folgen

Dominik Berner teilt das Scheitern daher in vier Kategorien ein: «Sportlich Scheitern», «Kontrollierter Abbruch», «Nochmals davonkommen» und «Katastrophaler Fehlschlag».

«Sportlich Scheitern»: Hier wird zwar das gesetzte Ziel erreicht, aber nicht unbedingt in der perfekten Art und Weise, wie man es sich vorgenommen hat. Zwar steht man auf dem Gipfel, aber auf dem Weg dahin fiel man mehrmals ins Seil. Übertragen auf die Softwareentwicklung könnte es heissen: Ein Feature wird ausgeliefert, aber es wurde nicht ganz so beispielhaft entwickelt, wie man es eigentlich wollte. Oder man hatte sich vorgenommen, mit Test Driven Development an die Entwicklung zu gehen, doch mussten noch ein paar Tests nachgeliefert werden. Oder statt der neuesten Version einer Programmbibliothek musste man schlussendlich mit einer früheren Version vorliebnehmen.

Hier scheitert man nur an seinen idealen Vorstellungen, denn für Aussenstehende ist das Ergebnis ein Erfolg. Solche Dinge passieren im Alltag und sollen uns nicht aufhalten. Diese Situationen sind manchmal ärgerlich, aber kein Grund, alles hinzuschmeissen. Man trainiert vielleicht etwas härter oder liest noch etwas mehr Fachliteratur. Aus den kleinen Fehlern lernt man kontinuierlich.

«Kontrollierter Abbruch»: Mitten in der Steilwand geht es nicht mehr vorwärts. Man merkt, dass man sich schlicht und einfach überschätzt hat. Oder kurz vor Auslieferung eines Software-Updates wird bemerkt, dass es noch Mängel in einem Feature gibt, so dass man Gefahr läuft, in eine technologische Sackgasse zu geraten.

Beim Klettern ist die Konsequenz, sofort abzusteigen. Der Gipfel wird dieses Mal nicht erreicht. In der Softwareentwicklung rollt man die Versionskontrolle zurück, überarbeitet das Backlog neu und beginnt mit dem gewonnenen Wissen nochmals von vorn. Ist man sich dieser Dynamik bewusst, wird so der Schaden klein und überschaubar gehalten.

«Nochmals davonkommen»: Verpasst oder übersieht man den Ausstiegs- oder Abbruchpunkt, wird es gefährlich. Plötzlich findet man sich am Berg in einer Situation wieder, in der ein Sturz Knochenbrüche oder Schlimmeres zur Folge hat. Oder ein Software-Update mit einer kritischen Sicherheitslücke erreicht den Endkunden.

Ob man nun durch eigenes Verschulden oder äussere Einflüsse in dieser Situation ist, spielt keine Rolle. Schlagartig ist nicht mehr das Erreichen des Gipfels das Ziel, sondern unverletzt aus der Situation herauszukommen. Oder nicht mehr das erfolgreiche Feature zu liefern ist das Ziel, sondern das Produkt – oder den Ruf einer Firma – am Markt überleben zu lassen.

«Katastrophaler Fehlschlag»: Gelingt es nicht wieder, in die Zone des kontrollierten Abbruchs zurückzufinden, geht es unweigerlich schief. Die Frage ist nicht mehr, ob jemand verletzt wird, sondern wie schlimm das Ausmass ist. Wer in eine solche Situation kommt, klettert für längere Zeit nicht mehr oder überlegt es sich zweimal, ob er weiterhin Software entwickeln will. Eine Weiterarbeit am Projekt führt nur noch zu höheren Kosten oder Schlimmerem. Hier wollen wir auf keinen Fall hin, sondern nur aus Fallstudien von anderen lernen.

Beim Klettern sind hier schwerwiegende Verletzungen oder sogar der Tod die Konsequenz. In der Software sind die Folgen eines katastrophalen Fehlschlags oft indirekter aber nicht immer weniger dramatisch. Denken wir nur an das Softwaredebakel Boeing 737 oder die durch Software gefälschten Abgaswerte von VW, um nur zwei prominente Beispiele zu nennen.

Die Kontrolle wiedergewinnen

Die Grenzen zwischen den vier Kategorien des Scheiterns sind natürlich fliessend und hängen stark von den Fähigkeiten und der Erfahrung der beteiligten Personen ab. Sei es beim Klettern oder beim Schreiben von Programmcode. Ein erfahrener Bergsteiger bewegt sich vielleicht auch im alpinen Gelände noch im grünen Bereich, während der absolute Anfänger bereits in der Kletterhalle überfordert ist. Gerade der Übergang von «Kontrollierter Abbruch» zu «Nochmals davonkommen» ist enorm schwierig im Voraus zu erkennen. Plötzlich finden wir uns – ob selbstverschuldet oder nicht – in einer Situation, in der uns die Kontrolle entglitten ist. Ein kritischer Softwarefehler ist gerade in der produktiven Umgebung aufgetaucht, der letzte Sicherungspunkt hat sich gerade aus dem Felsen gelöst. Plötzlich ändert sich das Ziel von «ans Ziel kommen» zu «Schadensbegrenzung».

Was hier geschieht ist enorm spannend: Nach dem initialen Reflex – Flucht, Angriff oder Schockstarre – den es zu überwinden gilt, setzt ein Moment der absoluten Konzentration ein. Softwareentwicklung und Klettern benötigen in dieser Situation systematische Problemlösung und nicht kopfloses Hetzen. Man aktiviert sein Wissen und gräbt alle seine Fähigkeiten aus, um Schritt für Schritt wieder in eine kontrollierte Zone zu gelangen. Die Software wird auf eine stabile Version zurückgesetzt, das Backup eingespielt, der Bug isoliert und ein Patch bereitgestellt.

Ist man dann wieder zurück in der Zone des kontrollierten Abbruchs, ist es meistens empfehlenswert, tatsächlich abzubrechen und der Versuchung zu widerstehen, eine Klettertour doch noch auf dem Gipfel zu beenden oder ein Feature mit einem kleinen Patch auszuliefern.

Klare, offene und ehrliche Kommunikation in der Seilschaft oder im Team sind dabei unerlässlich. Nicht nur im akuten Gefahrenfall, sondern auch, wenn man wieder sicher mit beiden Beinen auf dem Boden steht. Nun ist es ganz wichtig, das Erlebte zu verarbeiten, darüber zu reflektieren und daraus zu lernen.

Wo ist nun die Freude am Scheitern?

Die Krise ist überstanden, der Schaden hielt sich im akzeptablen Ausmass und plötzlich ist sie wieder da, diese eine Situation. Man will sich nochmals am Berg versuchen und den Gipfel doch noch erreichen oder das Feature, dass einem so viel Kopfzerbrechen bereitet hat, doch noch im Produkt sehen.

So stellt man sich wieder der Situation: Mit pochendem Herzen bindet man sich wieder ins Seil ein, nimmt das Kärtchen mit der User-Story vom Scrum Board und beginnt den Einstieg in die Wand oder die Codezeile. Langsam und extra umsichtig tastet man sich an die Schlüsselstelle heran. Und dann ist sie da: Die Stelle, an der es letztes Mal eng wurde. Man atmet tief durch, nickt dem Kletterpartner zu, holt einen Kollegen zum Pair Programming und los geht’s. Zeile für Zeile, Bewegung für Bewegung wird das Problem ausformuliert und mit Tests und Klemmkeilen abgesichert.

So steigt man höher und höher dem Gipfel entgegen. Und schlussendlich schickt man das Feature in die CI-Umgebung wo alles durchläuft und schlussendlich in der Produktion landet. Dann steht man oben und schaut übers Tal oder sieht wie die Benutzer das Feature verwenden.

Man schaut zurück auf das Geleistete, reflektiert über den vorausgegangenen Fehlschlag und eine immense Freude macht sich breit. Darüber, dass man trotz widrigen Umständen sein Ziel erreicht hat. Darüber, dass man es besser gemacht hat, als man es vorher gekonnt hat und dass man ein grosses Stück Erfahrung dazugewonnen hat. Das ist die Freude am Scheitern!