In Zeiten agiler Teams schauen wir gerne zu den IT Kollegen aus der agilen Softwareentwicklung, nutzen ihre SCRUM Terminologie und imitieren ihre autonomen Teams. Wir kopieren ihre Spleens und beäugen neugierig ihre Fetische. So begegnete mir diese Woche auf dem Schreibtisch eines Change Managers eine treu-doof dreinblickende Gummiente und ich fragte neugierig nach seinem neuen Haustier. Der Kollege erzählte mir, sein kleiner gelber Freund helfe ihm, Lösungen für knifflige Probleme zu finden, zuverlässiger als das Orakel von Delphi. Geschenkt wurde ihm das possierliche Tier von IT Kollegen, bei denen er häufig an der Tür gelehnt hatte, um seine Herausforderungen in der Change Begleitung zu beschreiben. Die Kollegen hörten aufmerksam zu, machen sich Gedanken zu Lösungsvorschlägen doch zum Antworten kamen sie nie. Sobald der Change Manager seine Ausführungen beendet hatte sagte er „Ach, ich weiß jetzt, wie ich das mache, Danke!“ und verschwand wieder.
Rubber Duck Debugging
Seine nach eigenen Angaben unbewusst angewandte Methode ist in der Softwareentwicklung unter dem Slang-Begriff Rubber Duck Debugging bekannt. Wer einem hartnäckigen Bug in der Software auf die Schliche kommen will, sucht sich einen Gesprächspartner, der den Code nicht kennt. Dem erklärt er, was der Code tun soll, was davon er tatsächlich tut und wo es hängt. Der Fachfremde hört einfach nur zu und nickt. In überraschend vielen Fällen führt das zu einem Gedankenblitz und der Erzähler kommt von selbst auf eine neue Lösung. Der Change Manager grinste und schilderte mir selbstironisch seinen IT-Türrahmen-Dialog: „Also passt auf, hier ist mein Problem mit der Change-Strategie, die Führungskräfte ziehen einfach nicht mit, und das ist total kompliziert weil … und ich kann es nicht auflösen…. und der Vorstand hängt auch mit drin…ähm.., oh, wartet.“ Dann fiel ihm oftmals ein, dass er sich komplizierte Lösungen für einen Sonderfall geschaffen hatte und nun alle Normalfäll so hinzubiegen versuchte, dass sie seinem Sonderfall ähnelten. Häufig stellt er dann fest, dass sein Sonderfall eine Randerscheinung war und die einfache Lösung von Anfang an gereicht hätte. Seinen stummen Helfern von der IT hatte er dann regelmäßig Schokolade zurückgelassen und in seinem Büro weitergearbeitet. Bis ihm die IT-Kollegen die Gummiente schenkten, die nun neben seinem Monitor sitzt während er ihr sein Leid klagt.
Probleme strukturiert erklären
Die Grundannahme dahinter ist, dass wir bei der Fehlersuche in einem Geisteszustand kommen, der uns hindert, das Problem strukturiert zu durchdenken. Wenn wir unser ach so komplexes Problem einem Fachfremden oder Laien erklären, zwingen wir uns, wie Korrekturleser, den ganzen Text auszusprechen, um Fehler zu erkennen. Auch ein Mathematiker, der eine Gleichung Schritt für Schritt erklärt, kann leichter Fehler erkennen. Wir hinterfragen im Erklären unsere Vorannahmen, den Sinn und Zweck und alles, was wir vielleicht als gottgegeben hingenommen hatten. Beim Aussprechen klingt manches plötzlich schwachsinnig und bringt uns zum Ursprung des Übels. Ich begann zu recherchieren und fand ähnliche Muster auf der Frage-Antwort-Plattform Stack Overflow, die für fast jedes erdenkliche Programmierproblem Antworten findet. Wer hier beim Fragenstellen schlampt, wichtige Informationen oder Details auslässt, der wird von der Community einfach ignoriert. Wer sich schon beim Formulieren seiner Frage Mühe gibt, bekommt nicht nur Antworten, schon das verständliche Skizzieren seines Problem führt ihn oft direkt zur Lösung.
Passive Zuhörer
Seitdem experimentiere ich mit Rubber Duck Debugging in anderen Lebensbereichen. Wer von Ihnen erörtert seine Ideen mit dem Hund beim Abendspaziergang? Haben Sie schon mal der Orange auf dem Schreibtisch Augen gemalt und dann von Ihrer Knobelaufgabe erzählt? Meinen im Vergleich zu mir eher wortfaulen Mann wertschätze ich seitdem als Problemlöser, denn sein stummes Nicken scheint magische Kräfte zu haben.