NBAK09: Work - Feedback. Der einzige Kreislauf, der zählt

Wenn man allen Ballast abwirft - Zertifikate, Rollen, Rituale - bleibt der Kern von agilem Arbeiten übrig: Work und Feedback. In dieser Folge stelle ich mein eigenes Modell vor, die Work-Feedback Loop, und erkläre, warum Feedback, das die nächste Arbeit nicht verändert, gar kein Feedback ist - und warum das ein Kopplungs- und kein Mindset-Problem ist.

Überblick

Wir schleppen uns zu Dailies, schätzen Story Points und pflegen Boards, und trotzdem dauert es Monate, bis Arbeit beim echten Nutzer ankommt. Diese Folge startet Block 2 der Serie und reduziert agiles Arbeiten auf das Wesentliche: einen Kreislauf aus Work und Feedback, dessen Geschwindigkeit über die Lernfähigkeit eines Systems entscheidet.

Zusammenfassung

Die Work-Feedback Loop ist eine Wirkungskette: Work erzeugt einen realen Effekt, dieser Effekt wird als Feedback sichtbar, führt zu einer Entscheidung und verändert die nächste Arbeit. Nur wenn alle vier Schritte gekoppelt sind, lernt das System. Der einzige Maßstab für Agilität ist die Geschwindigkeit dieses Kreislaufs - nicht die Zahl der Zertifikate oder Code-Zeilen. Geschwindigkeit heißt dabei nicht Hektik, sondern die Fähigkeit, schnell zu lernen, ohne Qualität, Sicherheit oder UX zu opfern; dafür braucht es Skills, nicht neue Meetings. Der wichtigste Satz der Folge: Feedback ist erst dann Feedback, wenn es die nächste Arbeit verändert. Wenn ein System auf ein Signal nicht reagiert, ist das kein Mindset-Problem, sondern ein Kopplungsproblem.

Shownotes

• Du erreichst mich hier
• Diese Folge ist Teil einer Serie "No Bullshit Agile Kompakt". Eine Übersicht über alle Folgen findest du hier
• Das Modell im Detail: Die Work-Feedback Loop
• Buch "Agiles Arbeiten in der Praxis": hier
• Diskutier mit auf Mastodon

Transkript

 Hallo und herzlich willkommen bei No Bullshit Agile Kompakt, mein Name ist Thomas.
 Mit der letzten Folge, der Folge 8, mit dem Thema warum Agilität nicht tot ist,
 haben wir hier bei der Reise in BA Kompakt tatsächlich das Fundament abgeschlossen
 und im nächsten Schritt und damit zuallererst mal mit dieser Folge geht es jetzt um den Kern von agilem Arbeiten.
 Und im Prinzip ist agiles Arbeiten zweierlei, auf der einen Seite haben wir Arbeit, Work
 und auf der anderen Seite haben wir Feedback und daraus ergibt sich ein Kreislauf, ein Zyklus, eine Kopplung.
 Das Feedback soll Einfluss haben auf die Arbeit, Work und Feedback sind gekoppelt.
 Das einzige Maß, was wir hier haben, der große Maßstab, an dem wir uns orientieren sollen, ist jetzt,
 was für eine Geschwindigkeit haben wir, in welcher Geschwindigkeit dreht sich dieser Kreislauf.
 Also Work mit einer Handlungsabsicht, wir haben etwas vor, weil wir eine Hypothese haben und deswegen wollen wir etwas implementieren.
 Dann haben wir das Feedback dazu, da gleichen wir das Feedback, was wir bekommen haben, mit unserer Handlungsabsicht ab
 und treffen eine Entscheidung, was das für uns bedeutet, für die nächste Arbeit, also für den nächsten Teil Work.
 Und fundamental wichtig, und das ist für mich das Fundament von agilem Arbeiten,
 wenn das Feedback die nächste Arbeit nicht verändert, dann ist es nicht wirklich ein Feedback.
 Und das bedeutet eben, wir haben dann nicht irgendwie ein Mindset-Problem oder ein Team-Problem im agilen Arbeiten,
 sondern was wir in Wirklichkeit haben, ist halt ein Kopplungsproblem.
 Work und Feedback sind eben nicht gekoppelt.
 Um mal einzusteigen, ein bisschen in die Denke, man kann sich natürlich mal die Frage stellen,
 die habe ich mir dann auch gestellt, warum veranstalten wir diesen ganzen Zirkus überhaupt?
 Daily Storypoints, Methoden, Jira-Boards, Abläufe, warum tun wir uns das überhaupt an?
 Und vor allen Dingen, wenn es dann doch Monate dauert, bis irgendetwas Neues in Produktion ist,
 beim Nutzer ankommt und wir die erste Chance haben auf dem Feedback.
 Oft genug, und das ist so ein bisschen auch der Anlass gewesen,
 warum ich diese Word-Feedback-Loop, dieses Denkmodell angefangen habe zu schreiben,
 haben wir halt in meinen Augen ein bisschen den Fokus verloren.
 Wir diskutieren über Save vs. Scrum, wir diskutieren über alle möglichen Dinge,
 aber darunter haben wir ein Riesenproblem, unser Handwerk ist verrottet,
 denn das Handwerk ist Work und Feedback.
 Und deswegen finde ich es schön und befreiend, mal alles wegzulassen,
 alles, was du über agiles Arbeiten weißt,
 und sich wirklich mit dieser Kopplung nur zu beschäftigen,
 die Kopplung zwischen Work und Feedback.
 Und das Ganze hier, diese Folge, ist jetzt der Start.
 Ich werde jetzt ein paar mehr Folgen machen,
 um dieses Denkmodell von mir, die Work-Feedback-Loop, ein bisschen auseinanderzunehmen.
 Ja, wie schon gesagt, wir reduzieren mal alles auf Skelett.
 Wir haben Work, wir arbeiten an etwas,
 wir haben eine Hypothese aufgestellt, warum wir daran arbeiten,
 wir bekommen möglichst schnell ein Feedback dazu,
 und wir können unsere Hypothese mit der Wirklichkeit vergleichen
 und aufgrund dessen eine Entscheidung treffen,
 die dann in die nächste Arbeit einfließt.
 Und diese Loop wollen wir so schnell und so sicher wie möglich drehen.
 Sicher meint hier halt, wir wollen dabei halt keine oder so gut wie keine Fehler machen.
 Und was mir auch wichtig ist, das ist hier kein Ablaufplan,
 das ist keine To-Do-Liste,
 sondern hier geht es mir eben um eine Kopplung und eine Wirkungskette.
 Weil ich es schon höre und ich es auch nachvollziehen kann,
 wäre für mich noch Folgendes wichtig.
 Man könnte denken, weil ich jetzt ja dieses Geschwindigkeitsthema reingebracht habe,
 naja, wenn wir jetzt einfach schneller coden,
 dann bricht uns das System zusammen.
 Und das ist vollkommen richtig.
 Und gerade über die letzten drei, vier Jahre,
 gefühlt in meinen Augen, vor allen Dingen in 2025,
 ist durch LLMs jetzt eben noch das deutlich offensichtlicher geworden.
 Wir erhöhen einen Teil der Geschwindigkeit,
 die Work-Geschwindigkeit,
 und wundern uns, dass das System nach einem halben Jahr dann doch zusammenbricht.
 Und das meine ich eben damit.
 Wir brauchen eine richtige Geschwindigkeit.
 Die kann vielleicht aufgrund von Regulatorien oder so langsam sein,
 aber sie muss halt so schnell wie möglich sein.
 Und der Fokus auf Work und Feedback hilft dir eben genau das zu erkennen.
 Und das ist das Fundament, warum ich das Ganze auch Denkmodell nenne.
 Das ist keine Methode oder so, die man anwendet,
 sondern es soll dich in die Lage versetzen,
 intensiver darüber nachzudenken,
 wie funktioniert mein System und wo ist denn was kaputt.
 Um das System stabil zu halten,
 brauchen wir halt grundsätzlich mal Skills,
 und zwar auf beiden Seiten des Kreislaufs.
 Und jetzt siehst du auch, wie das Bild sich langsam schließt.
 Wenn wir auf die Work-Seite gucken,
 um das stabil zu halten,
 brauchen wir Kenntnisse in der Architektur,
 wir brauchen Testing, wir brauchen DevOps,
 wir brauchen gutes Slicing von Storys.
 Die Liste kann man viel, viel länger machen.
 Und auf der anderen Seite, auf der Feedback-Seite,
 brauchen wir sowas wie Usability-Untersuchungen,
 wir brauchen Analytics-Daten,
 wir brauchen schnelle Feedback-Kanäle zu unseren Usern.
 Und dann siehst du,
 da tauchen jetzt auf einmal wieder alle Begriffe auf,
 die wir also kennen.
 Ich habe ja mal über den agilen Eisberg gesprochen
 und die Dinge, die unterhalb der Wasseroberfläche sind,
 das sind die Dinge,
 die Work und Feedback sicher machen.
 Der fundamentale Satz für diese Folge ist tatsächlich für mich,
 Feedback ist keine Information.
 Es ist erst dann Feedback,
 wenn das nächste Stück Arbeit dadurch verändert wird.
 Ist das nicht der Fall,
 nutzt uns dieses Feedback nichts.
 Und oft genug reagieren wir auf Signale nicht gut genug,
 weil es zu teuer ist,
 weil das Feedback zu spät ankommt.
 Da kann man eine lange Liste machen,
 da gibt es nochmal eine explizite Folge dazu.
 Aber das ist halt sehr wichtig zu verstehen.
 Agiles Arbeiten bedeutet,
 wir sind in einem komplexen Umfeld
 und wir müssen eben anerkennen,
 dass wir etwas liefern mit einer Hypothese
 und es prüfen müssen.
 Work und Feedback.
 Was du machen kannst,
 kleiner Praxistest für dich.
 Nimm dir mal irgendwas ganz Konkretes,
 an dem du gerade arbeitest.
 Ein Release, vielleicht ein Meeting,
 irgendeine Policy, die ihr vielleicht habt.
 Und frag dich mal,
 welchen realen Effekt soll das denn haben?
 Wo und wann wird dieses Signal sichtbar,
 was wir uns da erarbeiten?
 Wann können wir eine bindende Entscheidung darauf treffen?
 Und diese Entscheidung,
 die wir da treffen,
 verändert die wirklich die nächste Arbeit?
 Ist da wirklich eine Kopplung da?
 Ich bin mir ganz sicher,
 oft genug wirst du feststellen,
 da ist keine Kopplung.
 Und dann scheitert agiles Arbeiten.
 Und es ist eben wichtig,
 diesen fundamentalen Blick zu behalten
 und die Kopplung nicht zu vergessen.
 Ein Feedback, das irgendwann kommt,
 kann zum Beispiel viel zu spät kommen.
 Gut, das soll hier kurz und kompakt
 jetzt tatsächlich mal der Einstieg
 in dieses Denkmodell Work-Feedback-Loop sein.
 Das lange Dokument dazu,
 das verlinke ich dir natürlich auch in den Shownotes.
 Schaut da gerne schon mal rein.
 Aber wie gesagt, die nächsten Folgen,
 da nehme ich das jetzt auch tatsächlich
 ein bisschen weiter auseinander.
 Also wir merken uns,
 agiles Arbeiten ist Work und Feedback
 und das muss eng gekoppelt sein.
 Und diese Kopplung,
 die muss auch relativ schnell sein.
 Und im Prinzip mal ist alles andere jetzt bei Werk,
 um diesen Kern gut zu machen.
 Ja, ganz konkret werde ich in der nächsten Folge
 darüber sprechen,
 dass es vier Zustände gibt,
 wenn man sich Work und Feedback anguckt
 und überlegt,
 wie gut sind die gekoppelt oder nicht gekoppelt.
 Und da werden wir feststellen,
 ganz, ganz viel ist tatsächlich
 in so einem Quadranten,
 den ich dann Aktionismus genannt habe.
 Ja, ansonsten würde ich sagen,
 das soll es für heute auch schon gewesen sein.
 Ich freue mich wie immer über Feedback,
 gerne auch über kritisches Feedback.
 Wie du mich erreichst,
 findest du in den Shownotes.
 Und ansonsten sage ich,
 habe noch eine ganz tolle Woche
 und bis zum nächsten Mal.
 Ciao, ciao.