NBAK11: Dein Team ist nicht langsam - euer Feedback kommt zu spät

Thomas
Thomas

Warum "langsame" Teams meist kein Geschwindigkeitsproblem haben, sondern ein Timing-Problem. Ich zerlege die Feedback Response Time in Signal, Entscheidung und Umsetzung und zeige, warum ein zu großes Feature dafür sorgt, dass Feedback erst dann ankommt, wenn es keinen Wert mehr hat.

Überblick

Wenn ein Team "langsam" wirkt, liegt das fast nie an der Umsetzungsgeschwindigkeit. Es liegt daran, dass Feedback Wochen oder Monate später kommt – wenn Lernen teuer oder unmöglich geworden ist. In dieser Folge geht es um die Zeit als strukturelle Variable im Work-Feedback Loop.

Zusammenfassung

Zwischen der Wirkung von Arbeit und der Anpassung künftiger Arbeit liegt die Feedback Response Time (FRT), die Summe aus drei Teilen: Zeit bis ein Signal sichtbar wird, Zeit bis zur Entscheidung und Zeit bis zur Umsetzung. Entscheidend ist: Feedback ist nicht zeitlos. Jedes Signal hat ein Gültigkeitsfenster und verliert mit der Zeit an Wert. Überschreitet die FRT dieses Fenster, reagiert das System zwar, aber zu spät, und das Lernen fällt aus. Ein zu großes Feature verlängert den Zyklus so stark, dass Feedback strukturell entwertet wird. Der Engpass liegt dabei fast nie im Signal, sondern in mehrstufigen Entscheidungen, Gremien und Freigaben. Die einzige relevante Frage lautet: Ist unsere Antwortzeit kürzer als das Fenster, in dem das Signal noch relevant ist?

Shownotes

Transkript

 Hallo und herzlich willkommen bei NoBullshit Agile Kompakt, mein Name ist Thomas.
 Wir sind ja bei NBA Kompakt mitten in dem Denkmodell Work Feedback Loop von mir.
 In der letzten Folge haben wir uns angeguckt, wie Work und Feedback zeitlich zusammenhängen.
 Es gibt vier strukturelle Zustände, einer heißt Learning, einer heißt Aktionismus, einer Frustration und einer Stagnation.
 Wenn dich das interessiert, hör da gerne rein, den Link zu der Folge und alle weiteren Links findest du wie immer in den Shownotes.
 Heute schauen wir uns dann den nächsten Teil an, nämlich kommt das Feedback vielleicht zu spät.
 Da ist eine zeitliche Komponente in diesem Feedback drin.
 Oft ist es so, dass Teams gar nicht langsam arbeiten, aber viel zu spät lernen.
 Wir haben ja gelernt, wir wollen das Feedback zu unserer Arbeit auch möglichst schnell wieder einführen in die neue Arbeit.
 Nur so lernen wir ja.
 Und das Feedback, wenn das lange liegt, Feedback hat ein Gültigkeitsdatum, dann altert das und ist vielleicht nicht mehr so viel wert, wie wenn das Feedback früh abgearbeitet würde.
 Um das vielleicht gleich ein bisschen in die Praxis zu führen, ihr released vielleicht ein Feature, aber es dauert aus irgendwelchen Gründen sehr lange, bis ein Feedback dazu ankommt.
 Irgendwelche Kanäle sind vielleicht gestört, da ist irgendwo ein Engpass, sprich ihr entwickelt weiter und in dem Moment ratet ihr ja höchstwahrscheinlich.
 Das heißt, wir haben nicht nur das Problem, Feedback überhaupt zu bekommen, sondern wir haben auch noch das zweite Problem.
 Wann kommt dieses Feedback überhaupt bei uns an?
 Dazu habe ich eine Metrik eingeführt, die ist aber nicht wirklich zu verstehen als eine reine Messmetrik, ihr hebt da keine Zahlen, sondern die ist eine Metrik, um darüber nachzudenken.
 Und diese Metrik habe ich Feedback-Response-Time genannt.
 Und zwar ist das, die Arbeit wirkt irgendwo, ihr habt was released und das kann jetzt eigentlich ein Feedback bekommen, das ist der Startpunkt, bis hin zu, ihr habt vielleicht irgendein Feedback bekommen, das hat wirklich die nächste Arbeit oder die übernächste beeinflusst.
 Und auch das liegt jetzt wieder zum Testen vor, beziehungsweise in der echten Welt vor.
 Das ist der Zeitstrahl für die Feedback-Response-Time.
 Also die Feedback-Response-Time ist nicht nur, wann kommt das Feedback bei euch an, sondern sie beinhaltet auch die Entscheidung, die da drin steckt.
 Wir machen was mit dem Feedback, die Arbeit, die da drin steckt.
 Wir setzen das Feedback um, bis es dann wieder in Produktion und benutzbar ist.
 Wir haben also im Prinzip drei Teile.
 Wir haben das Signal, also da kommt etwas zurück, ein Signal.
 Wir haben eine Entscheidung, irgendjemand muss jetzt sagen, ja, das ist valides Feedback und wir wollen das auch bearbeiten.
 Dann arbeitet der dran und dann haben wir das Deploy, also wir bringen diese Entscheidung durch Code in Produktion.
 Und das Ganze ist die Feedback-Response-Time.
 Wie gesagt, wichtig, das ist keine Formel zum Rechnen, sondern diese drei Punkte Signal, Entscheidung und Release, das sind drei Stellen, an denen ihr aufgehalten werden könnt.
 Und das macht die Feedback-Response-Time in diesem Denkmodell tatsächlich so wertvoll.
 Der wichtigste Punkt ist jetzt tatsächlich, ein Feedback altert.
 Das Feedback hat ein Gültigkeitsfenster, ein Ablaufdatum.
 Ihr bekommt schnell ein Feedback, dann stimmt das natürlich noch mit eurem Code überein und mit dem Markt, in dem das Feedback gekommen ist.
 Wenn das Feedback zu euch erst drei Monate später kommt, kann es viel zu spät sein.
 Das heißt also, Feedback ist nicht zeitlos.
 Und das ist übrigens auch ein ganz schöner Punkt, nochmal drüber nachzudenken, dass es Sinn macht, kleine Iterationen zu releasen, weil dann auch das Feedback zu einer kleinen Iteration schneller kommen kann.
 Ihr seht schon, das hängt alles zusammen und das macht auch total Sinn so.
 Also, wir wollen kleine Arbeit, um schnell was zu releasen und unser Hauptgrund ist, wir wollen schnell Feedback zu dieser kleinen Arbeit bekommen, damit das eben auch Einfluss haben kann auf diese nächste Arbeit.
 Wenn man die Arbeit also nicht frühzeitig releasen kann, um etwas zu lernen, dann sage ich jetzt einfach mal, arbeitet ihr tatsächlich nicht agil.
 Das ist nicht die Idee hinter agilen Arbeiten.
 Das mag gute Gründe geben, alles auch gut für mich, aber eine fundamentale Voraussetzung, damit agiles Arbeiten wirklich funktioniert, die fundamentale Idee hinter agilem Arbeiten ist eben, schnell ein Feedback zu bekommen.
 Und die Feedback-Response-Time hilft dir eben, das auch besser zu zerlegen und zu verstehen.
 Oft genug ist einfach Zeit der Engpass.
 Nicht das Signal, nicht das Feedback selber.
 Das Feedback kommt schon, das Feedback ist schon irgendwie da, aber zum Beispiel muss überhaupt jemand das Feedback annehmen.
 Es muss jemand entscheiden, ist das sinnvolles Feedback, passt das überhaupt rein?
 Es muss jemand entscheiden, ja, dieses Feedback nehmen wir auf.
 Da stecken sehr viele Engpässe drin und was wir ja immer versuchen ist, große Engpässe finden und versuchen sie kleiner zu machen, sie im Zweifel sogar zu eliminieren.
 Das wird nicht immer gehen, aber kleiner machen geht.
 Tun wir das nicht, ein bisschen Rücksprung auf die Folge 10 jetzt nochmal, dann wandern wir von Learning immer weiter in Richtung Frustration oder eben Aktionismus.
 Wie gesagt, hört das uns gerne nochmal in die Folge 10 rein.
 Wichtig ist mir an der Stelle auch noch, habe ich auch in anderen Folgen schon gesagt, dieses schnell, wie schnell können wir das Signal verarbeiten, wie schnell können wir entscheiden, wie schnell können wir es umsetzen.
 Das ist immer relativ, man kann nicht sagen, das muss unter einer Woche sein oder so.
 Da gibt es Rahmenbedingungen, die wir vielleicht gar nicht beeinflussen können, gesetzliche Regelungen oder so.
 Aber wir können ja trotzdem danach streben, diesen Zyklus schneller zu gestalten.
 Und wir können ja weiterhin danach streben, mit dem Wissen, Feedback hat ein Gültigkeitsfenster, ein Verfallsdatum, dass wir uns darum kümmern, gibt es nicht doch irgendetwas, dass unser Feedback schneller ankommen kann.
 Ja, zum Abschluss, wir sind dann soweit auch schon durch, vielleicht so ein paar Inspirationen, ein paar Merksätze oder so.
 Also für mich ist zum Beispiel wichtig, Teams werden in der Regel nicht langsam oder sind nicht langsam, weil sie schlecht arbeiten, sondern das entsteht eben, weil Teams keine Chance haben, früher zu lernen, sie lernen zu spät.
 Und oft genug braucht man keine Tools oder Rollen, um jetzt irgendwie besser zu werden, sondern wir brauchen kleine Zyklen und eben auch den Mut und im Zweifelsfall auch die Technologie, einfach früh releasen zu können.
 Wir werden an der Stelle dann in der nächsten Folge ansetzen und nochmal ein bisschen genauer auf diese Decision Latency, habe ich es genannt, also die Verzögerung in der Entscheidung als unsichtbarer Engpass gucken.
 Für mich wäre es halt interessant, was hast du hier für ein Feedback, kennst du das aus der Praxis, dass irgendwann mal irgendein Feedback ankommt zu etwas, was ihr vor drei Monaten released habt, wie geht ihr mit so einem Feedback um, baut ihr euren Sprint um, sortiert ihr euer Backlog komplett neu, sagt ihr, okay, das ist zu spät, hast du es vielleicht sogar schon mal erlebt, dass Feedback ankam und ihr gesagt habt, okay, das brauchen wir jetzt gar nicht mehr groß bearbeiten, das hat sich einfach komplett überholt, die Situation ist ganz anders.
 Ja, und wie immer, kurz und knapp soll es für heute auch schon gewesen sein, habt noch eine ganz tolle Woche und bis zum nächsten Mal. Ciao, ciao.

Mastodon Diskussionen

Auch interessant