Perspektivwechsel Teil 17

Schatz, was denkst du gerade? – Warum Gedankenlesen das Gegenteil von Feedback ist

Vielleicht haben Sie diese Geschichte schon einmal gehört: „Mika und Aaron sind Nachbarn. Mika fragt Aaron, ob er sich seinen Rasenmäher ausleihen kann, und Aaron verspricht, den Mäher am nächsten Tag vorbeizubringen. Aber Aaron kommt nicht – weder am nächsten noch am übernächsten Tag.“

Also überlegt Mika: „Warum bringt er mir den Mäher nicht? Er hatte es doch versprochen. Er denkt wohl, ich würde ihn nicht zurückbringen oder kaputt machen. Sicher trägt er mir noch diese alte Geschichte mit der Laubsäge nach. Aber nur weil ich handwerklich nicht so geschickt bin, kann ich

trotzdem einen Rasenmäher bedienen. Das ist mal wieder typisch, der feine Herr hält sich wohl für etwas Besseres…“ Und je länger Mika über die Sache nachdenkt, desto unmöglicher kommt ihm Aarons Verhalten vor. Schließlich ist er sich ganz sicher, dass Aaron ihn hasst. Als sich die beiden dann nach einer Woche wieder über den Weg laufen, brüllt Mika Aaron ins Gesicht: „Behalt doch deinen blöden Rasenmäher!“ und stapft wutentbrannt nach Hause.

Vielleicht hält Aaron Mika wirklich für einen Idioten und will ihm seinen Rasenmäher nicht ausleihen. Vielleicht hat er auch einfach nur vergessen, dass er ihm den Mäher vorbeibringen wollte. Oder er ist krank geworden und lag die ganze Woche im Bett. Das alles können wir nicht wissen, es sei denn, wir heißen Houdini oder Copperfield. Aber genau wie diese hat sich Mika aufgeführt, denn er war sich sicher, die Gedanken von Aaron lesen zu können.

Wir versuchen ständig, mit Gedankenlesen durchs Leben zu kommen, denn es macht die Welt so schön einfach: „Ich muss doch nicht nochmal nachfragen. Wie diese Äußerung gemeint war, das kann ich mir ja denken.“ Oder: „Warum soll ich extra sagen, was ich von den anderen erwarte – das wissen sie doch!“ Dabei sind beide Varianten des Gedankenlesenes weit verbreitet:

  1. Wir meinen, die Gedanken unserer Mitmenschen lesen zu können.
  2. Wir gehen davon aus, dass unsere Mitmenschen unsere eigenen Gedanken lesen können.

So kann es dann zu skurrilen Situationen kommen, wenn etwa das Ehepaar den Urlaub jahrelang in den Bergen verbringt, obwohl beide die Küste lieber mögen und sich das Ganze erst aufklärt, als nach einem Streit beide gleichzeitig sagen: „Ich dachte immer, du willst in die Berge!“ Dabei gibt es verschiedene Irrtümer, denen wir unterliegen können, wenn wir glauben, wir könnten Gedanken lesen:

  • Wir schließen von uns auf andere (sowohl bei Gedanken als auch bei Handlungen)
  • Wir schließen von der Vergangenheit auf die Zukunft („Das hat er doch immer so gemacht!“)
  • Wir scheren verschiedene Personen über einen Kamm („Petra würde es doch auch so verstehen“)
  • Wir passen unsere Schlussfolgerungen unseren eigenen Gedanken/Wünschen an („Das muss einfach klappen“)
Perspektivenwechsel

Was hat das Ganze mit Softwareentwicklung zu tun? Sehr viel, denn der Kern der (agilen) Softwareentwicklung besteht aus Feedback, und Feedback ist das Gegenteil von Gedankenlesen. Um erfolgreich Software zu entwickeln, benötigen wir Feedback – und zwar schnell und ständig und von allen Seiten. Beim Daily Scrum (= Standup Meeting) holen wir uns Feedback von den Teamkollegen, wie der letzte Tag verlaufen ist. Pair Programming dient dem unmittelbaren Feedback über die Qualität unseres Codes, Flüchtigkeitsfehler und Designentscheidungen. Beim Sprint Review holen wir uns regelmäßig Feedback von unserem Kunden, ob wir die Software in die richtige Richtung entwickeln. Und eine der mächtigsten agilen Praktiken, die Retrospektive, dient dazu, über den Entwicklungsprozess selbst zu reflektieren und ihn ständig zu verbessern. Und nicht nur von unseren Kollegen und dem Kunden holen wir Feedback, sondern auch von der Software selbst: Test-First-Vorgehen bedeutet ja nichts anderes, als permanent Rückmeldung über den Zustand unseres Codes zu bekommen. Und ein CI-Server – am besten kombiniert mit einer großen, gut sichtbaren Ampel – dient dazu, allen Teammitgliedern Auskunft über den Zustand des Build-Systems zu geben.

Wenn wir aber der Unsitte des Gedankenlesens verfallen, wird jedes Feedback hinfällig. Warum soll ich meine Zeit beim Daily Scrum vergeuden, wenn ich weiß, was die Kollegen gestern gemacht haben? Wozu brauchen wir Retrospektiven, wo doch alle genau wissen, was die Probleme sind und wir sie einfach nur lösen müssen? Warum soll ich ständig dem Kunden auf die Nerven gehen, wenn doch ganz klar ist, was er von uns erwartet? Und was sollen mir die ganzen Tests und der CI-Server schon Neues sagen, wenn ich doch schon weiß, wie gut mein Code ist?

In einem Projekt mit lauter Superprogrammierern, perfekten Architekten und unfehlbaren Kunden bräuchte man tatsächlich kein Feedback (und diese könnten ja vielleicht auch wirklich Gedanken lesen). In allen anderen Konstellationen ist der Verzicht auf Feedback gleichbedeutend mit überzogenen Budgets, gerissenen Deadlines, unzufriedenen Kunden und Terminen vor Gericht.

Leider ist die Sache mit dem Feedback nicht ganz einfach. Denn wenn man es wirklich ernst meint, müssen wir uns zuerst einmal eingestehen, dass wir ständig Fehler machen. Und wir müssen wegkommen von einer Kultur, in der Fehler verschwiegen und bestraft werden. In diesem Sinne ist das folgende Prinzip eines bekannten Scrum-Trainers sehr hilfreich: „Wir machen keine Fehler – wir lernen!“ Dazu gehört natürlich die Erlaubnis der Chefs, dass jeder auch Fehler machen und lernen darf. Dazu noch eine Anekdote zum Abschluss: Als ein Manager bei IBM einen schweren Fehler gemacht hatte, der das Unternehmen 600 000 US-Dollar kostete, wurde sein Chef Thomas J. Watson (damals Vorstandvorsitzender bei IBM) gefragt, ob er diesen Manager denn nicht feuern wolle. Darauf antwortete Watson: „Ich habe gerade 600 000 US-Dollar in seine Ausbildung investiert. Warum sollte ich einer anderen Firma ermöglichen, einen Mann mit dieser Erfahrung einzustellen?“

Also Schluss mit dem Gedankenlesen und her mit dem Feedback! Fragen Sie doch jetzt gleich mal Ihren Teamkollegen: „Schatz, was denkst du gerade?“.

Arne Roock arbeitet bei der it-agile GmbH in Hamburg. Als studierter Germanist interessiert er sich für informative, leicht verständliche und kooperative Kommunikation. Außerdem beschäftigt er sich seit Längerem mit den Themen Selbstorganisation und Zeitmanagement in der IT.
Geschrieben von
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.