NBAK10: Die 4 Zustände. Lernst du oder machst du nur Aktionismus?

Dein Team liefert wie verrückt und wird trotzdem nicht besser? Dann steckt ihr wahrscheinlich im Aktionismus. In dieser Folge zeige ich die vier strukturellen Zustände des Work-Feedback Loops - Learning, Aktionismus, Frustration, Stagnation - und wie du erkennst, in welchem ihr gerade seid. Wichtig: Diese Zustände sind strukturell, nicht kulturell.

Überblick

Der Work-Feedback Loop hat zwei unabhängige Geschwindigkeiten: Work Speed - wie schnell das System Arbeit mit realem Effekt erzeugt -  und Feedback Speed - wie schnell dieser Effekt als relevantes Signal zurückkommt. Die meisten Organisationen optimieren nur die erste und übersehen die zweite. Genau dort sitzt aber oft der Engpass.

Zusammenfassung

Kombiniert man beide Geschwindigkeiten, ergeben sich vier Zustände. Im Learning-Quadranten (Work schnell, Feedback schnell) ist das System adaptiv – das ist der einzige Zustand, in dem strukturelles Lernen möglich ist, und er muss geschützt werden. Aktionismus (Work schnell, Feedback langsam) bedeutet viel Output bei niedriger Lernrate; der Engpass ist die Verarbeitung der Realität. Frustration (Work langsam, Feedback schnell) heißt: Probleme werden erkannt, aber nicht entschieden – der Engpass sitzt in der Entscheidung. Stagnation (beides langsam) ist doppelt blockiert. Entscheidend: Diese Zustände sind strukturell, nicht kulturell. Ein engagiertes Team kann in Frustration feststecken, eine disziplinierte Firma in Aktionismus. Und verschiedene Ebenen können gleichzeitig in verschiedenen Zuständen sein – ein Team im Learning, das Portfolio darüber in Stagnation. Das Modell ist kein Reifegrad, sondern ein Diagnose-Werkzeug: Finde den langsameren der beiden – das ist dein Engpass.

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 at Real Kompakt, mein Name ist Thomas.
 In der letzten Folge haben wir die Einführung in die Work Feedback Loop gestartet
 und wir haben darüber gesprochen, was Work und was Feedback überhaupt ist.
 Wenn dich das interessiert, hör da gerne rein, den Link dazu findest du in den Show Notes.
 Heute gehen wir dann den nächsten Schritt und schauen uns an, dass es eigentlich zwei Geschwindigkeiten gibt,
 nämlich die Work Geschwindigkeit, die Geschwindigkeit, in der wir unsere Arbeit erledigen
 und getrennt davon die Feedback Geschwindigkeit.
 Und wenn man das kombiniert, erhält man vier Zustände und ich finde, die vier Zustände helfen auch wieder sehr gut zu diagnostizieren,
 wo hast du vielleicht im agilen Arbeiten ein Problem.
 Ich will aber vorab einmal ganz kurz noch das Thema Work und Feedback versuchen, ein bisschen besser zu definieren.
 Wenn ich von Work spreche, spreche ich von einer Aufgabe, die zu erledigen ist.
 Dabei geht es nicht um, ist es ein Epic, ist es eine Story, ist es ein Task, sondern es gibt eine Aufgabe.
 Ein Stück Software soll erstellt und geliefert werden.
 Ich verallgemeine hier also, wir wollen etwas Kleines.
 Storys sollen klein sein, unsere Arbeit soll möglichst klein sein, Sinnvolles liefern.
 Das nenne ich dann Work.
 Und dann bekomme ich Feedback.
 Feedback von echten Usern, die dieses Stück Arbeit, dieses Work benutzen.
 Ich habe ja dieses Stück Arbeit aufgeschrieben und gesagt, das entwickeln wir als nächstes, weil ich eine Hypothese hatte.
 Wir müssen diesen Teil des Logins verbessern, wenn wir jetzt über Webentwicklung sprechen.
 Und wir haben auch eine Hypothese, warum wir es verbessern müssen.
 Und wir erhalten dann hoffentlich zeitnah ein Feedback der User.
 Und bei Usern geht es mir um die Benutzer des Systems.
 Feedback, das hatte ich in der letzten Folge auch schon gesagt, kann sowas sein wie Analytics-Daten.
 Natürlich auch echtes User-Feedback durch Umfrage oder durch ein Usability-Lab.
 Also wir wollen nicht vom Auftraggeber, wenn da einer dazwischen ist, ein Feedback,
 sondern wir wollen von den Benutzern des Systems ein Feedback.
 Es geht ja ums Lernen.
 Das ist das Fundament von agilem Arbeiten.
 Das Fundament ist, ich bin mir nicht sicher, wie ich ein bestimmtes Problem lösen soll.
 Wie wir das Login wirklich verändern.
 Also stelle ich die Hypothese auf, wir verändern das Login wie folgt.
 Ich entwickle das, ich packe das in die Welt da draußen und bekomme jetzt ein Feedback der User,
 ob meine Hypothese gestimmt hat oder nicht.
 Und dieses Feedback soll wieder in den nächsten Schritt von Work einfließen,
 damit eine Sicherheit da ist, dass ich auf dem Markt vernünftig agieren kann.
 Das ist mir halt nochmal ganz wichtig, dass ihr Work und Feedback wirklich auch so versteht.
 Gut, dann würde ich sagen, steigen wir mal jetzt in den nächsten Teil ein.
 Ich habe zwei Geschwindigkeiten.
 Also ich arbeite eine Aufgabe ab.
 Das dauert eine gewisse Zeit.
 Also keine Ahnung.
 Das hängt am Release-Zyklus ab.
 Wie schnell ihr überhaupt was releasen könnt.
 Ob ihr von Hand testet, ob ihr automatisierte Tests habt, ob ihr eine Kombination habt, ob ihr permanent testen könnt.
 Du kannst dir vorstellen, es gibt viele, viele Gründe, woran die Geschwindigkeit der Arbeit hängen kann.
 Also die Work-Geschwindigkeit ist die Geschwindigkeit von, ich starte eine Aufgabe bis die Aufgabe ist in Produktion und benutzbar.
 Eine ganz andere Geschwindigkeit ist dann die Feedback-Geschwindigkeit.
 Wie schnell erhalte ich ein relevantes Signal zurück, das ich koppeln kann mit der Arbeit, die ich da gemacht habe.
 Also, ich bekomme ein Feedback zu dieser Veränderung des Login-Mechanismus, dann ist das gekoppelt.
 Wie lange dauert das, bis ich dieses Feedback bekomme?
 Und nochmal, irgendein Feedback zu irgendetwas anderem ist nicht gekoppelt.
 Das hat mit meiner Arbeit nichts zu tun.
 Nur wenn ich es koppel, kann ich daraus lernen.
 Und in der Regel, und das kenne ich von mir auch, ist es so, dass die Feedback-Geschwindigkeit wahrscheinlich der begrenzende Faktor ist.
 Es dauert in der Regel ein bisschen länger, oder auch sehr viel länger, hängt ein bisschen davon ab,
 bis ich Feedback zu meiner gelieferten Arbeit von den Usern bekomme,
 als es gedauert hat, diese Arbeit in Produktion zu bringen.
 Und wenn man das jetzt mal in so einem Quadranten malt,
 ich blende dir hier so eine Kapitelmarke ein, dann siehst du so eine Grafik.
 Und wir uns so vier Quadranten vorstellen.
 Links auf der Y-Achse haben wir die Geschwindigkeit der Arbeit.
 Links unten langsam, links oben schnell.
 Und horizontal, die X-Achse, haben wir die Geschwindigkeit des Feedbacks.
 Links ist die Geschwindigkeit langsam und rechts ist die Geschwindigkeit schnell.
 Dann haben wir vier Quadranten.
 Und oft genug ist es so, dass wir nicht in dem Quadranten sind, in dem wir sein wollen.
 Wir wollen die gleiche Geschwindigkeit zwischen Arbeit, Work und Feedback,
 damit wir unseren Zyklus, unsere Kopplung insgesamt schnell durchgehen können.
 Diesen Teil, schnelle Arbeit, schnelles Feedback.
 Wir wollen das natürlich versuchen, so sicher und so schnell wie möglich zu machen.
 Den habe ich Learning genannt.
 Jetzt haben wir ein System, in dem die nächste Arbeit einen Einfluss hat,
 und zwar von dem Feedback, das ich bekommen habe.
 Also kann mein Unternehmen, kann meine Software, kann mein Produkt lernen.
 Sehr, sehr oft ist es so, dass zwar die Arbeitsgeschwindigkeit schnell ist,
 aber die Feedbackgeschwindigkeit langsam.
 Es dauert Ewigkeiten, also fange ich schon mal irgendwas Neues an.
 In dem Moment rate ich halt.
 Ich rate, was man wohl als nächstes tun muss.
 Und diesen Quadranten habe ich Aktionismus genannt.
 Der andere Fall, die Arbeit ist langsam, Work ist langsam und Feedback ist schnell,
 das ist Frustration.
 Da kommt immer schnell Feedback, viel Feedback, du müsstest das verändern,
 du müsstest das verändern und ich kriege das nicht abgearbeitet.
 Und der letzte Quadrant, das ist das, wenn die Arbeit langsam ist
 und das Feedback langsam ist, ist Stagnation.
 Da werde ich rechts und links auf dem Markt von anderen überholt.
 Wenn man sich diese Quadranten jetzt mal anguckt,
 dann können wir nochmal so einen Side-Step hin zu AI machen,
 denn AI, das wissen wir alle, beschleunigt zwar den Work-Teil,
 aber eben nicht den Feedback-Teil.
 Den können nur echte User liefern.
 Also kann ich den auch nicht weiter beschleunigen.
 Und deswegen ist in der Arbeit mit AI, dieser Feedback-Teil,
 der begrenzende Faktor.
 Es mag ja sein, dass ich meinen Work-Teil die Geschwindigkeit erhöhen kann,
 aber die Grenze bildet der Feedback-Teil.
 Denn sonst lande ich wieder in diesem Aktionismus-Bereich.
 Also ich arbeite und arbeite, ich schubse Code raus,
 es gibt Releases über Releases,
 mein Produkt wird immer größer, immer voller,
 aber das Feedback kommt einfach nicht an.
 Da sehen wir zum Beispiel an Jira, um ganz ehrlich zu sein.
 Da steckt so viel Quatsch drin, ich kann mir wirklich nicht vorstellen,
 dass das alles auf User-Feedback basiert.
 Um das vielleicht an dieser Stelle noch zu sagen,
 diese Zustände, in denen dann Teams oder Unternehmen sind,
 das hat nichts mit Haltung oder Motivation oder so zu tun.
 Ein engagiertes Team kann komplett in diesem Frustrationsbereich feststecken.
 Es kann eine disziplinierte Firma geben, die komplett im Aktionismus lebt.
 Und wie so oft, ehrlich gesagt, so gut wie immer,
 die Ursache liegt nicht an Menschen oder so,
 sondern sie liegt am System und in unserem Fall an der Kopplungsgeschwindigkeit.
 Wenn du Software entwickelst, du aber keinen direkten Kontakt zu deinen Usern hast,
 weil ein Auftraggeber dazwischen ist zum Beispiel,
 dann ist das super frustrierend und du wirst nie ein gutes Ergebnis erzielen.
 Aber das Diagnose-Tool Work-Feedback-Loop hilft dir, das besser anfassbar zu machen.
 Das ist ja genau die Idee hinter diesem Diagnose- und Denkmodell Work-Feedback-Loop.
 Du siehst es jetzt einfach viel transparenter, wo das Problem überhaupt ist.
 Und wir wissen alle, Theory of Constraints, wir suchen eigentlich immer nach dem Engpass
 und da hilft dir dieses Schaubild, da hilft dir das Verständnis von
 was ist mit Arbeit, mit Work gemeint, was ist mit Feedback gemeint
 und dir hilft das Verständnis, dass da eine enge Kopplung zwischen beiden sein muss,
 sonst sind wir gar nicht im agilen Arbeiten
 und dann suchst du halt wie sonst auch den Engpass.
 Ja, und eigentlich soll es das gewesen sein,
 ich habe so das Gefühl, die Folge ist ein bisschen länger geworden als 5 Minuten,
 ist wahrscheinlich gar nicht so schlimm.
 Wie immer, ich freue mich auf kritische Anmerkungen dazu,
 ich freue mich auf dein Feedback,
 ich freue mich, wenn du die Feedback-Loop, die Work-Feedback-Loop liest,
 ich habe das ja als PDF oder als Webseite auch veröffentlicht,
 den Link dazu findest du in den Shownotes
 und ich würde mich freuen, wenn wir darüber in den Austausch kommen.
 In der nächsten Folge, Folge 11, wird es dann darum gehen,
 dass dein Team gar nicht langsam ist, sondern euer Feedback zu spät kommt.
 Da geht es mir um die Feedback-Response-Time.
 Was heißt das jetzt schon wieder?
 Naja, das bedeutet, oft genug muss man sich die Zeit angucken,
 die es braucht, bis ein Feedback ankommt und eine Arbeit beeinflusst
 und diese beeinflusste Arbeit dann wieder in Produktion ist.
 Und wir lernen dabei dann übrigens auch,
 dass eine Feedback decayt.
 Also ein Feedback, das ich sofort verarbeiten kann,
 ist mehr wert als ein Feedback,
 das ich erst nach 3 oder 5 oder 8 Monaten bearbeite,
 weil dieses Feedback gar keine Gültigkeit mehr haben kann.
 Gut, das soll es dann tatsächlich für heute gewesen sein.
 Hab noch eine ganz tolle Woche
 und bis zum nächsten Mal.
 Ciao, ciao.