Feedback-Loops etablieren und nutzen

Im letzten Artikel zum „Systems thinking“-Ansatz hab ich erwähnt, dass Fehler in einem komplexen System zunächst mal unvermeidlich sind. Folglich müssen wir damit einfach umgehen, ob wir wollen oder nicht.

Welchen Schluss lässt es zu, wenn Fehler unvermeidlich sind?

Eine Möglichkeit wäre, es wie der Strauß zu machen: den Kopf in den Sand zu stecken und so die Augen vor drohenden Problemen zu verschließen. Eigentlich ist der Strauß aber gar nicht so, wie es uns die Redewendung glauben lassen könnte.

Schließlich „käme Sand in Augen und Ohren“ und außerdem würde der Strauß „wegen des hohen Blutdrucks bewusstlos werden“ sagt Ralph Schumacher, der in Remagen eine Straußenfarm leitet.

Sand – das ist (um sich einer weiteren Redewendung zu bedienen) des Pudels Kern – macht sich gut am Strand und in Dekoschalen, nur eben weder in Augen und Ohren noch in den Zahnrädern unseres Systems.

Fail fast, fail early.

Pragmatisch gesehen lässt die Unvermeidlichkeit von Fehlern nur einen Schluss zu: je früher Probleme erkannt und behandelt werden umso besser.

Dafür spricht:

• Je früher Probleme erkannt werden, desto geringer ist die Wahrscheinlichkeit, dass sie sich auf Folgeprozesse (und damit auf Wartezeiten) auswirken.

• Je näher der Entdeckungszeitpunkt am Zeitpunkt der Entstehung ist, desto wahrscheinlicher ist es, dass das Wissen über die Umstände des Problems noch frisch ist und ein Problem mit dem geringstmöglichen Aufwand behoben werden kann.

• Umgekehrt gilt: je später ein Problem erkannt wird, desto aufwändiger ist in der Regel die Ursachenanalyse und oft sind dann auch zusätzliche Koordinationsaufwände erforderlich.

Wir wollen ja schließlich sicherstellen, dass ein Problem nicht das Unternehmensziel gefährdet und deshalb geht es im zweiten DevOps-Prinzip um Feedback-Systeme.

Wie erkennen wir Probleme frühzeitig?

Im Grunde sind Probleme das Resultat von Abweichungen, die nicht oder erst zu spät erkannt werden.

Wenn wir uns mit Feedback-Systemen beschäftigen, geht es darum, diese Abweichungen und zu deren Entstehung beitragende Faktoren sichtbar und damit behandelbar zu machen. Die Rückmeldungen können sich dabei auf die verschiedensten Aspekte beziehen, unter anderem:

• Ob Erwartungen verletzt werden: sei es beispielsweise die Erwartungen des Kunden an das Ergebnis oder die Erwartungen der am Prozess beteiligten Personen. Beispielsweise ob die Voraussetzungen für folgende Prozessschritte erfüllt sind.

• Die Effizienz und Effektivität von Prozessen: steht der Aufwand im angemessenen Verhältnis zum Nutzen? Erzeugt der Prozess überhaupt einen Nutzen, der mit dem Unternehmensziel im Einklang steht?

• Wie reibungslos funktioniert die Zusammenarbeit? Gibt es Engpässe oder im Gegenteil ungenutzte Ressourcen? Können Entscheidungen getroffen werden, wenn sie benötigt werden, oder gibt es ein Entscheidungsvakuum, das notwendige Schritte verzögert?

• Sind Werkzeuge und Hilfsmittel für ihren Einsatzzweck geeignet oder weisen sie Mängel auf, die uns die Arbeit erschweren? Überhaupt: haben und bekommen alle Beteiligten, was sie brauchen oder müssen sie mit dem klarkommen, was sie haben?

• Gibt es Qualitätsmängel in unserer Arbeit, die später Auswirkungen haben könnten und die wir jetzt vermeiden könnten?

Bei der Einführung von Feedback gilt: Im ersten Schritt wollen wir überhaupt Feedback generieren und möglichst viele Feedback-Gelegenheiten schaffen.

Während wir bei Feedback vor allem an aktives Reporting denken (etwa der Chef, der seinem Mitarbeiter eine Rückmeldung über seine Leistung gibt), geht es bei Feedback im Sinne der DevOps-Sichtweise eher darum, die Informationslage zu verbessern. Das kann auch passive „Systeme“ beinhalten, denen man bei Bedarf wichtige Informationen entnehmen oder abholen kann.

Daher spreche ich bewusst von Gelegenheiten, um zu unterstreichen, das beide Arten der Feedback-Erbringung wichtig sind. Insbesondere auch im Hinblick auf die Gefahren von Informationsüberflutung, die wir unbedingt vermeiden sollten. Wenn Feedback-Systeme zu Alarm Fatique führen, haben wir es vermasselt.

Daher zunächst mal ein kurzer Blick auf Kriterien für Auswahl von Feedback-Mechanismen.

Menschliche Ressourcen: Was es bei der Auswahl von Feedback-Mechanismen zu beachten gibt

Sobald es an die Etablierung von von Feedback-Systemen geht, stellt sich schnell die Frage nach Aufwand und Nutzen. Als überlegen wir, welche Ressourcen notwendig sind und ob so der gewünschte Nutzen erzielt wird.

Wenn es um Menschen geht, mag ich den Begriff „Ressource“ nicht.

Wir Menschen sind kein „Mittel, um eine Handlung zu tätigen oder einen Vorgang ablaufen zu lassen“ (Ressource). Vielmehr sind wir diejenigen die diese Handlungen ausführen und denen dabei begrenzte Ressourcen zur Verfügung stehen.

Auch wenn sich menschliche Ressourcen nicht so leicht messen lassen wie Zeit und Geld, machen unsere physischen und psychischen Ressourcen die Grenze unserer Belastbarkeit aus. Darum müssen sie bei jeder Kosten-/Nutzenabwägung für oder gegen Feedback-Mechanismen genauso wie bei der Auswahl der eigentlichen Mechanismen berücksichtigt werden.

Die folgenden Kriterien helfen meiner Meinung nach dabei:

1. Das Feedback sollte keine negativen Emotionen beim Empfänger auslösen ohne einen Gegenwert für den Empfänger.

2. Wenn ein Feedback-Mechanismus aktiv Informationen übermittelt, sollte die Möglichkeit zum Opt-Out durch die jeweiligen Empfänger bestehen.

3. Idealerweise sollte das Feedback Hinweise auf mögliche nächste Schritte liefern. Hilfsweise sollte es wenigstens die Informationslage der beteiligten Personen verbessern.

4. Die Frequenz und Darstellung des Feedbacks sollte dem Informationsgehalt angemessen sein und kontinuerlich verbessert werden. So bieten hundert textlastige E-Mails (z.B. Benachrichtigungen eines Monitoring-Systems) gegenüber einer aggregierten Sicht kaum einen Mehrwert und können im Gegenteil dazu führen, dass wichtige Hinweise übersehen oder sogar (unbewusst) ignoriert werden.

5. Wenn das generierte Feedback keinen Hinweis auf nächste Schritte liefern kann, sollte immer geprüft werden, ob es einen besseren Feedback-Mechanismus gibt.

Negative Emotionen vermeiden ist eine Business-Entscheidung

Im Zusammenhang mit Geschäftsentscheidungen über Emotionen nachdenken mag gefühlsduselig klingen, ist in Wirklichkeit allerdings die einzig rationale Herangehensweise an die Zusammenarbeit mit Menschen.

Emotionen beinflussen unser Handeln.

Wir treffen schlechtere Entscheidungen, wenn wir wütend, traurig oder verärgert sind. Wir sind weniger produktiv und neigen zu Handlungen, die sich kontraproduktiv auf das Ergebnis und auf unsere Umgebung auswirken. Wer einmal erlebt hat, welche Auswirkungen es hat, unter Stress ausfallend oder auch nur laut zu werden, und wie positiv es sich dagegen auf das Umfeld auswirkt, wenn genau das nicht passiert, weiß wovon ich rede.

Feedback kann natürlich Emotionen auslösen.

Klar nervt es, wenn unser Code nicht baut, ein Test fehlschlägt oder ein Plausibilitätscheck schon wieder einen Flüchtigkeitsfehler aufzeigt. Wenn wir darauf hingewiesen werden, dass wir trotz aller Bemühungen nicht perfekt sind und nicht auf Anhieb das gewünschte Resultat erreichen.

Andererseits wissen wir auch, dass uns solche Informationen weiterhelfen können. Deshalb können die Emotionen leicht aufgewogen werden, wenn Hopfen und Malz noch in Sichtweite sind und ein Gegenwert für den Empfänger vorhanden ist. Eine gute Faustregel für einen Gegenwert sind eindeutig umsetzbare nächste Schritte (siehe auch GTD und das Team – die Magie der nächsten Schritte) oder dem tatsächlichen Informationsbedarf angepasste Informationen.

Was besser vermieden werden sollte: aktive Übermittlung von personenbezogenen Kennzahlen

Ein Beispiel für Feedback, das leicht den angestrebten Zweck verfehlt, sind personenbezogene Leistungskennzahlen.

Was ist zum Beispiel die Aussagekraft eines Prozentsatzes, der angibt wieviel abrechenbare Arbeit ein Mitarbeiter geleistet hat?

Kennen wir alle Faktoren, die zur Entstehung dieser Kennzahl beigetragen haben? Sind wir über die Varianzen im Bilde, die diese Kennzahl beeinflussen? Können wir aufgrund dieser Kennzahl einschätzen, ob die Tätigkeiten des Mitarbeiters erst ermöglicht haben, dass an anderen Stellen im System abrechenbare Leistungen produziert werden konnten?

Dummerweise führen solche Kennzahlen fast unweigerlich zu negativen Emotionen und bietet gleichzeitig (fast) keinen Anhaltspunkt, was als nächstes zu tun ist:

Nicht mehr an internen Meetings teilnehmen? Neue Mitarbeiter lieber sich selbst überlassen statt bei ihrer Einarbeitung zu helfen? Womöglich Überstunden machen, um Alles unter einen Hut zu kriegen?

Ironischerweise wird das Feedback über diese Kennzahl natürlich zu einer Reaktion führen. Die Zahl der abrechenbaren Stunden wird wahrscheinlich steigen: ob dies aber zu einer Verbesserung des Gesamtsystems führt, auf Kosten von anderen wichtigen Faktoren geht oder gar durch Manipulation erzielt wird, bleibt offen.

Wir sollten auf die Übermittlung solche Kennzahlen besser verzichten und stattdessen versuchen, das System als Ganzes zu messen. Schließlich gilt: Repariere nicht, was nicht kaputt ist, sonst wird es sicher kaputt gehen.

Welche Arten von Feedback gibt es?

Wir können Feedback-Systeme grob in technische und nicht-technische Maßnahmen unterscheiden.

Wenn wir technische Maßnahmen einsetzen können (wie etwa automatische Tests und Plausbilitätsprüfungen), haben diese vor allem eine entlastende Wirkung für die Menschen im Unternehmen.

Sobald diese Feedback-Mechanismen in Stellung gebracht wurden, können sie durchgehend und ohne zusätzlichen Aufwand Feedback liefern. Hierfür eingesetzter Aufwand zahlt sich in mehrer Hinsicht aus:

• Bessere Skalierung: dieser Feedback-Mechanismus skaliert besser als beispielsweise manuelle Prüfungen und kann regelmäßig Rückmeldungen produzieren

• Keine Abhängigkeit von einzelnen Personen: auch wenn die Jungs aus der QA in Arbeit versinken oder der zuverlässige Assistent der Geschäftsführung mal in Urlaub ist und sonst die Stundenerfassung kontrolliert, kann das Feedback dennoch zur Qualitätssicherung beitragen.

• Senken der kognitiven Last bei Entscheidungen: die (unbewusste) Frage „Habe ich an alles gedacht?“ dient der Risikominimierung und hält uns gleichzeitig oft unnötig zurück: mit einem Sicherungsnetz fällt es eben leichter, sich fallen zu lassen. Mit dem so frei gewordenen Kopf können in anderen Belangen bessere Entscheidungen getroffen werden.

Feedback kann auch sehr „low-tech“ ausfallen

Während die ein oder anderen Systeme uns automatisch über Abweichungen informieren, sind wir auch auf Informationsquellen angewiesen, die wir bei Bedarf anzapfen können.

Diese können sehr „low-tech“ ausfallen: die Teilnehmer eines Meetings am Ende einfach mal bewerten lassen, ob sich die investierte Zeit im Hinblick auf die erzielten Resultate gelohnt hat (siehe RoTi in Meetings), kann zum Beispiel wertvolles Feedback zur Effizienz von Meetings liefern.

Auf der Prozessebene kann man von allen Interessenträger so früh wie möglich Feedback einzuholen, indem man beispielsweise auf frühzeitige Zwischenergebnisse hinarbeitet und diese in einem Review-Meeting bespricht.

Auf dem Weg dahin kann man von Maßnahmen Gebrauch machen, mit denen sich Erwartungen abklären lassen und Qualität sicherstellen lässt:

• frühzeitiger und regelmäßiger Dialog über technische und nicht-technische Anforderungen (auch innerhalb des Teams, siehe beispielsweise „Definition of Done – Gemeinsame Erwartungen abgleichen“)

• Besprechen eines möglichen Vorgehens mit einer weiteren Person oder in der Gruppe (zum Beispiel Design-Meetings wie das Sprint Planning in Scrum)

• Anwendung des 4-Augen-Prinzips während der Arbeit (bei der Entwicklung zum Beispiel mittels Pair Programming, siehe auch „Einfach mal zusammen an etwas arbeiten“)

• Peer Reviews, also ein Zwischenergebnis von einer weiteren Person kontrollieren lassen (was in vielen Fällen ohnehin praktiziert wird, etwa beim Korrekturleser ;))

Schließlich können Mittel zur Visualisierung der Arbeit wie Kanban- oder Sprint-Boards im Sinne eines Informationsradiators dafür sorgen, dass jeder im Bilde ist, woran gerade gearbeitet wird und wo eventuell auch Unterstützung benötigt wird.

Last but not least können wir in regelmäßigen Abständen auch den Prozess und unsere Zusammenarbeit hinterfragen und so Anhaltspunkte für Verbesserungsmaßnahmen aufspüren: Retrospektiven oder ähnliche Meetings bieten hier ein adequates Mittel.

Und jetzt?

Allein Feedback zu generieren reicht natürlich nicht. Wenn wir Probleme oder größere Hindernisse sehen müssen wir sie beheben, daraus lernen und bestenfalls Maßnahmen ergreifen, damit sie nicht wieder entstehen können.

Im DevOps-Handbook (Affliate-Link) wird dabei der Ansatz des „Swarmings“ hervorgehoben beziehungsweise das Prinzip der Andon Cord im Toyota-Produktionssystem.

Die Idee: Wir arbeiten nicht um Probleme herum oder warten darauf, dass irgendwann mal Zeit sein wird, sondern stürzen uns auf das Problem. Wir mobilisieren alle Personen, die an der Lösung mitwirken können, und lösen es in Gemeinschaftsarbeit. Sicherlich eine personenintensive Herangehensweise – und vielleicht genau deshalb effektiv.

Der dritte Baustein der DevOps-Philosophie zielt schließlich auf eine Unternehmenskultur ab, in der ständig dazu gelernt wird. Darum geht es dann im dritten und letzten Artikel dieser Serie.