Der dunkle Bruder des Feedback

Feedback in der Softwareentwicklung ist nötig. Umso mehr, je unsicherer ist, was eigentlich geleistet werden soll und ob man das schon geleistet hat. Deshalb sind in der Agilität zwei Feedbackschleifen explizit institutionalisiert: Durch automatisierte Tests bekommen Entwickler innerhalb von Sekunden oder Minuten Feedback, ob Veränderungen zu Regressionen geführt haben. Durch Reviews des Implementierten mit Stakeholdern am Ende kurzer Iterationen bekommen Entwickler Feedback innerhalb von Tagen oder wenigen Wochen, ob sie ihr Werkstück näher an die Zielvorstellung jener heranentwickelt haben.

Mit der Agilität ist das Feedback aus dem Schatten von Gevatter Plan getreten. Das ist eine zentrale Leistung der Agilität.

Doch irgendetwas stimmt nicht. Es herrscht jetzt nicht einfach Friede. Die Entwicklung schreitet nicht einfach zügig voran. Ganz merkwürdig zagt und stolpert sie immer noch – trotz des klaren, sauberen Anführers Feedback.

Das liegt an einer Kraft, die bisher unbenannt ist. Sie beeinflusst den Fortschritt stark, doch niemand benennt sie so recht. Alle kennen sie, aber man räumt ihr keinen gleichwertig offiziellen Platz neben dem Feedback ein. Ich will sie deshalb den dunklen Bruder des Feedback nennen.

Was ist Feedback in der Softwareentwicklung?

Bevor ich mich dem dunklen Bruder widme kurz eine Vergewisserung, was eigentlich den lichten Bruder ausmacht. Was ist das eigentlich, Feedback?

Informativ

Zunächst einmal soll Feedback einem Produzenten Informationen liefern. Das bedeutet nach Gregory Bateson einen Unterschied herstellen, der einen Unterschied macht.

Das beginnt mit Daten, die eben noch nicht da waren, es jetzt aber sind. Die könnten darin besteht, dass ein Anwender ein Operationsergebnis vorlegt, das er für falsch hält. Bei Benutzung der Software ist für "1+1" das Ergebnis "10" herausgekommen. ("1+1", "10", "falsch", "2") selbst sind allerdings noch keine Information! Der Anwender erzeugt durch die Daten zunächst nur Wissen beim Entwickler. Das ist der 1. Unterschied.

Zu einer Information wird der Unterschied im Wissen nur, wenn das auch zu einem 2. Unterschied führt. Das ist der Fall, wenn der Entwickler sich aufgrund des Wissens anders verhält. Er denkt jetzt anders oder er handelt anders, weil er dieses Wissen nun hat. Dann macht der 1. Unterschied einen Unterschied für ihn aus.

Das ist der Fall, wenn die Operation eine dezimale Rechenoperation darstellen soll. Dann liegt ein Fehler vor. Der Anwender hält das Ergebnis "10" zurecht für falsch. Der Entwickler verhält sich durch die Daten nun anders: Statt mit dem nächsten Feature zu beginnen, behebt er den Fehler, so dass zukünftig das erwartete Ergebnis "2" errechnet wird. Der Anwender hatte dem Entwickler tatsächlich eine Information gegeben.

Das ist allerdings nicht der Fall, wenn die Operation eine binäre Rechenoperation darstellen soll. Dann liegt kein Fehler vor. Der Entwickler wird sich nicht anders verhalten. Für ihn stellt das Wissen, dass beim Anwender das Ergebnis herausgekommen ist (und der es für falsch hält) keine Information dar. Das Programm verhält sich aus Sicht des Entwicklers wie intendiert. Für seine weiteren Handlungen machen die Daten keinen Unterschied. Der Anwender hatte dem Entwickler keine Information gegeben.

Allerdings stellt dies für den Anwender, wenn der Entwickler es ihm mitteilt, sicherlich eine Information dar ;-)

Feedback, das nicht informativ ist, ist kein wertvolles Feedback. Deshalb ist auch nicht jeder Konsument, der einen Produzenten etwas wissen lässt, also einen 1. Unterschied herstellt, ein guter Feedback-Geber. Oft ist von Feedback-Empfängern nämlich zu hören "Was soll ich damit anfangen?" Das bedeutet, die berichteten Daten machen für sie keinen 2. Unterschied.

Wenn solche Informationsarmut des Feedback seinem Geber nicht mitgeteilt, sondern vom Empfänger geschluckt wird, der sich damit dann still abmüht, um selbst die fehlende Information zu generieren, entsteht ein Problem. Angenommenes informationsarmes Feedback führt zu unnötigen Laststeigerungen bei Empfängern. Doch auch wenn das ein aus meiner Sicht unterschätztes Problem selbst oder gerade in agilen Teams ist, will ich dabei hier nicht verweilen.

Erwünscht

Feedback soll informativ sein. In diesem Anspruch steckt noch eine zweite Eigenschaft von Feedback. Information ist nur Feedback, wenn der Empfänger sie erwünscht erhält!

Das ist für mich eine hier sehr wichtige Regel: Feedback setzt Zug voraus. Das bedeutet zum einen, der Empfänger informiert potenzielle Geber darüber, dass er gerne Informationen bekommen würde, was sie zu seinem Werk denken. Zum anderen bedeutet es, dass der Datenrückfluss zu ihm in einem bestimmten von ihm definierten Rahmen verläuft; insbesondere ist das ein zeitlicher Rahmen. Vorzugsweise erfolgt Feedback sehr zeitnah zum ersten Kontakt der Feedback-Geber (Konsumenten) mit dem Werk des Feedback-Empfängers (Produzent), womöglich sogar synchron.

Spüren Sie in sich selbst hinein: Sie haben den ganzen Tag an einem Feature gearbeitet. Dazu wünschen Sie sich Feedback von einem Anwender.

• Sie liefern es an einen Willigen aus – und der meldet sich in einer Woche per Email mit seinen Daten.
• Oder: Sie liefern nicht aus, sondern setzen sich morgen mit dem Anwender zusammen an einen Tisch und gehen das Feature gemeinsam durch, um Daten zu erheben.

Von welchem Rahmen versprechen Sie sich befriedigerendes und informativeres Feedback?

Die Agilität in Form des Vorgehensmodells Scrum hat diese Feedback-Regel mit zwei Institutionen anerkannt: dem Sprint Review und der Retrospektive. Beide stellen Feedback-Räume dar, die durch ihre Existenz im Vorgehensmodell und konkret im Kalender jedes Teams den Wunsch nach Informationen über die Qualität der produzierten Werke verkörpern.

Im Sprint Review geht es um Software als Werk; Konsumenten und Feedback-Geber sind die Stakeholder. In der Retrospekive geht es um die Arbeitsweise, den Herstellungsprozess; Konsumenten und Feedback-Geber sind die Teammitglieder selbst.

Der dunkle Bruder

Agilität umarmt Feedback und weist ihm einen prominenten Platz zu. Doch die erwünschte Information von Konsumenten über ihre Einschätzung eines Werkes ist nicht alles. Sie ist nur besonders geschätzt und sichtbar.

Ungewollt und unsichtbar hingegen ist ihr dunkler Bruder: der Hilferuf.

Wo in agilen Vorgehensmodellen findet der Hilferuf Erwähnung? Wo ist die Institution, die ihm Raum gibt? Ich sehe sie nicht.

Appellativ

Auch ein Hilferuf ist eine Information, quasi sogar eine gesteigerte. Er wird sich nämlich besonders anstrengen, informativ zu sein. Denn sein Zweck ist es, einen 2. Unterschied zu machen. Der Sender möchte einen anderen Handlungsverlauf beim Empfänger bewirken. Der soll ihn ja in einer Angelegenheit unterstützen, statt seine eigene voranzubringen.

Ob der Hilferuf deshalb vor allem Daten über einen Sachverhalt, z.B. das Operationsergebnis einer Software, oder den Gemütszustand des Senders transportiert, ist dafür unerheblich. Es geht darum, dass der Empfänger sich dem Sender widmet.

Beim Feedback ist dem Geber der Informationsgehalt egal, aber dem Empfänger nicht. Beim Hilferuf ist es umgekehrt.

Unerwünscht

Im Rahmen einer Produktion ist Feedback wichtig und unvermeidbar. Produzenten wünschen sich Feedback von Konsumenten. Hilferufe hingegen sind... Verschwendung. Kein Produzent wünscht sich, einen Hilferuf zu erhalten. Auch wünscht sich kein Produzent, zu einem Hilferuf Anlass zu haben.

Hilferufe sind für Produzenten Unterbrechungen. Sie stören den Produktionsfluss, bringen ihn ins Stocken und sorgen für Turbulenzen durch Rückflüsse.

Hilferufe entstehen spontan. Sie lassen sich nicht planen.

Das scheint mir der hauptsächliche Grund, warum es dafür keinen Rahmen gibt. Feedback ist institutionalisiert, Hilferufe sind es nicht. Sie bewegen sich damit immer knapp außerhalb des Blickfeldes.

Einzig in der co-location der Teammitglieder finden Hilferufe diffuse Anerkennung. Ausgesprochen wird, dass Zusammenarbeit an einem gemeinsamen Ort zur selben Zeit am besten funktioniere – gemeint ist damit jedoch, dass zwischen co-located Teammitgliedern Hilferufe maximal ungehindert ausgesandt werden können.

Andersherum ausgedrückt: Sobald Teammitglieder verteilt arbeiten, werden Hilferufe schmerzlich spürbar. Das soll vermieden werden.

Hilferufe einrahmen

Diesen Zustand finde ich unhaltbar. Der dunkle Bruder Hilferuf muss aus dem Schatten des Feedback heraustreten. Denn alles, was nicht anerkannt wird, stiftet Unruhe – und das, ohne dass man womöglich genau sagen könnte, woher die kommt.

Die Verschwendung, die Hilferufe darstellen, muss auf den Tisch. Sie muss explizit gemacht werden. Es braucht dafür genauso einen Rahmen wie für Feedback.

Hilferufe mögen unliebsam und unplanbar sein. Dennoch, nein, gerade deshalb gehören sie ans Licht in einem eigenen Raum.

Solange Hilferufe überall und jederzeit an Empfänger appellieren können, gibt es weder Chance noch Motivation, sie einzudämmen. Das ist umso schlimmer, da Hilferufe nicht nur ihren Sendern nützen, sondern perverserweise auch Empfängern. Die wollen sie zwar nicht, nutzen sie im Zweifelsfall jedoch.

Hilferufe bieten dem Empfänger die Möglichkeit, von anderen Aufgaben abzulassen, die ihm aus irgendeinem Grunde unliebsam sind. Vielleicht ist er unsicher, vielleicht ist etwas schwierig, vielleicht geht es um Kontakt mit einem unbequemen Kollegen... da kommt ein Hilferuf vielleicht ganz gelegen, um sich der Situation zumindest temporär zu entziehen. Denn ist es nicht gleichermaßen dringend wie wichtig, Hilferufende zu unterstützen?

Hilferufe sind moralisch eingefärbt, ob wir das wollen oder nicht. Ihnen zu widerstehen ist für den Einzelnen sehr schwer. Dazu braucht er die Unterstützung durch die Organisationskultur und/oder einen konkreten Rahmen/Prozess.

Solange Hilferufe nicht gleichermaßen anerkannt sind wie ihr lichter Bruder Feedback, treiben sie ein Unwesen wie Trolle.

In der Softwareentwicklung gibt es bisher nur eine Institution, die sich explizit mit Hilferufen beschäftigt: der Support. Er verkörpert die Anerkenntnis, dass Werke bzw. deren Verständnis bei den Konsumenten nicht perfekt sind. Es kommt zwangsläufig zu Meldungen von Fehlern und Nachfragen in Bezug auf die Nutzung. All das sind Hilferufe der Konsumenten, um die Entwickler als Produzenten nicht bitten.

Eine Fehlermeldung ist kein Feedback, ebensowenig eine Klage darüber, dass eine Funktionalität nur umständlich zu bedienen sei. So informativ beide sein mögen, ihnen fehlt die Erwünschtheit. Diese Informationen werden nicht im vom Produzenten gegebenen Rahmen gegeben. Er zieht nicht an ihnen, sondern bekommt sie 'reingedrückt. Und das einzige Mittel, nicht von ihnen zu stark abgelenkt zu werden, besteht darin, einen Support zwischen Konsumenten und Produzenten zu schalten. Der hilft, filtert, wehrt ab. So werden Hilferufe im Idealfall in normale Anforderungen transformiert, denen sich Produzenten selbstbestimmt widmen, wenn sie dran sind.

Doch jenseits des Supports... nichts. Kein Rahmen zum Umgang mit Hilferufen. Dabei sind die allgegenwärtig. Der Support kümmert sich ja nur um Hilferufe von außerhalb eines Teams bzw. einer Organisation. Was ist mit Hilferufen innerhalb der Grenze, die der Support zieht?

Der Entwickler weiß nicht weiter bei einer Anforderung und ruft den Product Owner um Hilfe an. Der Neuling ruft den Erfahrenen um Hilfe an. Der Technologieunerfahrene ruft den Spezialisten um Hilfe an. Der Product Owner ruft den Entwickler um Hilfe bei der Beurteilung einer neuen Anforderung an. Der Tester ruft den Product Owner um Hilfe beim Verständnis von Akzeptanzkriterien an. Der Manager ruft ein Teammitglied um Hilfe bei der Beurteilung einer Key Account Anfrage an. Das Marketing ruft das Team um Hilfe bei einer Präsentation an. Ein Kunde ruft einen Entwickler direkt um Hilfe an.

Soll ich weitermachen? Denn diese Liste ließe sich beliebig verlängern. Die Hilfsbedürftigkeit ist allerorten riesig. Sie ist bodenlos. Und sie nimmt jeden Tag zu, an dem kein Rahmen existiert, in dem Hilferufe den selben Status haben wie Feedback. Das bedeutet: gleiche Rechte, aber auch gleiche Pflichten.

Bisher haben Hilferufe gleiche oder gar mehr Rechte als Feedback – doch keine Pflichten. Hilferufe sind lokale, temporäre, persönliche Optimierungen Einzelner aus Kosten der Allgemeinheit und des Ganzen.

Der dunkle Bruder des Feedback nimmt sich; er ist ein Dieb. Ja, ein Dieb, wenn auch aus schierer Not heraus. Deshalb erzeugt er Schaden. Was sonst soll ein Dieb erzeugen?

So wie jede Gesellschaft mit einem gewissen Prozentsatz an Verbrechern zurechtkommen muss, müssen Teams auch immer mit einem gewissen Prozentsatz an Hilferufen in der Kommunikation zurechtkommen. Vielleicht liegt darin auch eine gewisse Kreativität und gesunde Reizung des sozialen Systems? Ich glaube jedoch, dass dieser gewisse Prozentsatz in den meisten Teams weit, weit überschritten ist.

Es besteht nicht einmal ein Bewusstsein darüber, dass Hilferufe kontraproduktiv für das sind, was eigentlich hergestellt werden soll. Selbst wenn Hilferufe unvermeidbar sind, hat kein Kunde sie je beauftragt. Er muss sie zwar mit bezahlen, doch ist er froh über jeden, der sich vermeiden lässt.

Dazu gehören übrigens auch Hilferufe nach außen. Wer in einem Handbuch nachschlagen muss oder StackOverflow befragt, um in seiner eigentlichen Aufgabe weiterzukommen, sendet einen Hilferuf an externe Autoritäten.

Die sind zwar nur halb so schädlich wie Hilferufe an Kollegen, weil durch sie keine weitere Person in ihrer Arbeit abgelenkt wird. Nichtsdestotrotz stellen sie Verschwendung dar.

Maßnahmen

Was können Organisationen tun, um Hilferufe von ihrem Schattendasein zu erlösen? Wie können sie den Spuk beenden und Produktionsprozesse flüssiger machen? Ich sehe drei grundsätzliche Arten von Maßnahmen:

Einhegen

Ohne an der Zahl bzw. Notwendigkeit von Hilferufen etwas zu verändern, müssen Hilferufe als erstes offizielle Räume bekommen, in denen sie erschallen können. Oder umgekehrt: Es braucht ausdrücklich Räume, die frei von Hilferufen sind. Damit meine ich sowohl physische wie zeitliche Räume.

Wie können sich Teammitgliedern physisch Hilferufen entziehen? Das muss zumindest zeitweise möglich sein, wenn es anders nicht geht, um den Fortschritt ihrer eigentlichen Aufgabe zu sichern. Gibt es ein ausgewiesenes Zimmer, in dem man allein arbeiten kann oder in dem nicht gesprochen werden darf?

Wie können sich Teammitglieder wenn schon nicht physisch so doch zumindest temporär Hilferufen entziehen? Nein, einen Kopfhörer und Musik auf den Ohren halte ich da nicht für die passende Maßnahme. Das wäre quasi Zwangsbeschallung; manche Menschen brauchen einfach Ruhe für konzentrierte Arbeit. Wie wäre es mit Sprechzeiten? Das könnten täglich 2-3 Stunden am Stück sein oder über den Tag verteilt periodisch immer mal wieder 5-20 Minuten.

Und was für Einzelne gilt, das gilt natürlich auch für ganze Teams.

Alternativ zu Sprechzeiten können Teams Ansprechpartner für Hilferufe zeitweise oder permanent definieren. Während 3 Entwickler an Wichtigem voranschreiten, steht ein Entwickler der Außenwelt für Hilferufe zur Verfügung.

Umwandeln

Hilferufe einzuhegen ist natürlich nur eine erste Maßnahme, um die stärksten Turbulenzen zu beruhigen. Im nächsten Schritt sollten Hilferufe umgewandelt werden. Das vermeidet sie noch nicht, aber nimmt ihnen sozusagen Kraft. Man kommt aus dem reagieren ins agieren. Man wendet sozusagen Aikido auf Hilferufe an: ihre Energie wird benutzt, um sie in etwas anderes zu verwandeln.

Hier lautet die erste Frage, wie Hilferufe in Anforderungen verwandelt werden können, die dann im Hauptproduktionsprozess behandelt werden. Statt reinzugrätschen, sollen sich Hilferufende in eine Reihe mit allen anderen stellen, die von Einzelnen bzw. dem Team etwas wollen. Das ist eine Maßnahme für sporadische Hilferufe bzw. solche aus verschiedenen Quellen.

Wenn sich hingegen heiße Quellen abzeichnen, d.h. Hilferufer wiederkehrend sich hervortun, und die Frequenz der Hilferufe steigt... dann kann es angezeigt sein, den Spieß umzukehren. Es könnte sich um einen Fall von systematisch mangelhafter Qualität handeln, die gar nicht erst hätte ausgeliefert werden dürfen. Die passende Maßnahme ist dann, proaktiv um Feedback zu bitten. Wo besonders viele Hilferufe erschallen, sollte der Empfänger ein Interesse entwickeln – insbesondere, wenn es um sein Werk als Produzent geht.

Hilferufe sind insofern Signal eines Mangels an anderer Stelle. Im Sinne einer Wurzelproblemanalyse sollte also gefragt werden, woher der Mangel stammt. Kann nahe seinem Ursprung Abhilfe geschaffen werden, um die Hilferufe zu reduzieren?

Vermeiden

Ein verbreitetes Wurzelproblem, das zu späteren Hilferufen führt, ist Qualitätsmangel. Wenn in einem Produktionsprozess upstream schlechte Qualität hergestellt wird, kommt es downstream früher oder später zu Hilferufen. Gargabe in, garbage out.

Hilferufe lassen sich also oft vermeiden, indem mehr auf Qualität geachtet wird. Die ist dann insbesondere wichtig an Schnittstellen, d.h. beim Übergang von einem Produktionsschritt zum nächsten, z.B. von der Anforderungsanalyse zur Programmierung oder von der Programmierung zum Kunden.

Immer wenn Übergaben stattfinden, kommt es zu Verlusten. Dem sollte bewusst entgegengewirkt werden. Das trifft umso mehr zu, je stärker das Gefälle zwischen Geber und Nehmer. Wenn der Geber mehr weiß als der Nehmer, dann kann der Nehmer Lücken nur schwer selbst schließen und ist zu Hilferufen gezwungen. Das ist nicht nur der Fall zwischen Kunde und Product Owner sowie Product Owner und Entwickler, sondern auch zwischen einer erfahrenen Entwicklerin und einer weniger erfahrenen.

Solche stark abschüssigen Übergabepunkte gilt es zu identifizieren. Entweder muss dort das Niveau angeglichen, die Qualität der Übergabe erhöht oder explizit Feedbackschleifen eingebaut werden.

Angleichung von Niveau bedeutet Lernen. Auch das geschieht zu selten in vielen Organisationen. So bleiben Entwickler in einem alten Technologiestand oder in Rollen stecken. Wissensinseln entstehen. Abhängigkeiten ziehen ein. Hilferufe nehmen zu.

Dem gilt es durch explizites und kontinuierliches Lernen entgegenzuwirken. Nicht umsonst plädieren wir in der Clean Code Developer School für regelmäßige Fortbildung. Die muss zu verschiedenen Themen schlicht Grundbestandteil jedes Budgets und jedes Kalenders sein.

Gerade die Hilferufe aufgrund von technischer "Unterbildung" gehen schnell unter und sorgen dann abseits des Radars für Stockungen. Sie tragen stark zur vorherrschenden Meinung bei, dass co-location zwingend sei – und inflexibilisieren damit Teams.

Was tun?

Am wichtigsten ist Bewusstseinsschaffung. Fangen Sie an, den Unterschied zwischen Feedback und Hilferufen zu sehen. Schärfen Sie dann Ihren Blick dafür, wo und wann überall Hilferufe an Sie ergehen – oder Sie sich zu Hilferufen genötigt sehen.

Und dann schalten Sie schrittweise Maßnahmen zu, um Hilferufe einzugehen, umzuwandeln, einzudämmen. Überlegen Sie auch, ob Sie eine Möglichkeit sehen, (gewisse) Hilferufe zu zählen. Dann können Sie jenseits eines Gefühls verfolgen, ob Ihre Maßnahmen einen Effekt haben. Wie oft werden Sie durch Fragen von Kollegen unterbrochen? Wie viele Emails vom Support haben Sie in Ihrer Inbox?

Hilferufe sind nicht böse. Der dunkle Bruder des Feedback will keinen Schaden zufügen. Hilferufe sind Mittel zur lokalen Verbesserung, gerade weil ihr Sender das Gute will. Dennoch passiert es: Das Gute für's große Ganze wird durch Hilferufe beeinträchtigt.

Doch wenn Sie den dunklen Bruder wahrnehmen und umarmen, wenn Sie ihm sichtbar Raum geben, dann kann es besser werden.