NBAK10: Die 4 Zustände: Lernst du oder machst du nur Aktionismus?
Shownotes
- Du erreichst mich hier: https://no-bullshit-agile.de/kontakt.html
- Diese Folge ist Teil einer Serie „No Bullshit Agile Kompakt". Übersicht: https://no-bullshit-agile.de/nba-kompakt-alle-folgen.html
- Thema: Die zwei Geschwindigkeiten des Work-Feedback Loops (Work Speed / Feedback Speed) und die vier Zustände – Learning, Aktionismus, Frustration, Stagnation. Warum nur der Learning-Quadrant lernfähig ist und warum die Zustände strukturell und nicht kulturell sind.
- Das Modell im Detail: https://no-bullshit-agile.de/wfl/
- Buch „Agiles Arbeiten in der Praxis": https://no-bullshit-agile.de/buch-agiles-arbeiten-in-der-praxis.html
- Diskutier mit auf Mastodon: https://mastodon.social/@nobsagile
Transkript anzeigen
00:00:03: Hallo und herzlich willkommen.
00:00:05: Mein Name ist Thomas.
00:00:08: In der letzten Folge haben wir die Einführung in Newark Feedback-Look gestartet, und wir haben darüber gesprochen was Work und was Feedback überhaupt sind.
00:00:18: Wenn ich das interessiert höre dann gerne rein.
00:00:20: den Link dazu findest du in den Schoenlots.
00:00:23: Heute gehen wir an den nächsten Schritt und schauen uns an dass es eigentlich zwei Geschwindigkeiten gibt nämlich die Workgeschwindigkeit, die Geschwindigkeit in der wir unsere Arbeit erledigen und getrennt davon die Feedback-Geschwindigkeit.
00:00:36: Und wenn man das kombiniert, erhält man vier Zustände – ich finde diese Hilfen auch wieder sehr gut zu diagnostizieren!
00:00:43: Wo hast du vielleicht im agilen Arbeiten ein Problem?
00:00:47: Ich will aber vorab einmal ganz kurz noch das Thema Work & Feedback versuchen bisschen besser zu definieren.
00:00:54: Wenn ich von Work spreche, spreche ich von einer Aufgabe die zu erledigen ist.
00:00:59: Dabei geht es nicht um Ist das ein Epic?
00:01:01: Ist das eine Story?
00:01:02: Ist es ein Task?
00:01:03: Sondern es gibt eine Aufgabe.
00:01:05: Ein Stück Software soll erstellt und geliefert werden.
00:01:09: Ich verelge meiner hier.
00:01:10: also wir wollen etwas Kleines.
00:01:13: Story sollen klein sein unsere Arbeit so möglichst klein sein.
00:01:17: sinnvolles liefern Das nennt nicht dann work Und dann bekomme ich Feedback von echten New-Usern, die dieses Stück Arbeit, dieses Work benutzen.
00:01:30: Ich habe ja diese 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.
00:01:54: Feedback, das hatte ich in der letzten Folge auch schon gesagt kann sowas sein wie Analytics-Daten natürlich auch echtes Userfeedback durch Umfrage oder durch Invisibility Lab.
00:02:04: also wir wollen nicht vom Auftrag Geber wenn einer dazwischen ist ein Feedback sondern vor den Benutzern des Systems ein Feed back.
00:02:11: Es geht ja ums Lernen Das ist das Fundament von Agilem Arbeiten wie ich ein bestimmtes Problem lösen soll.
00:02:22: Wie wir das Login wirklich verändern, also stelle ich die Hypothese auf, wir verändern das Log in wie folgt, ich entwickle das... Ich packe das in die Welt da draußen und bekomme jetzt einen Feedback der User ob meine Hypothesie gestimmt hat oder nicht.
00:02:36: und dieses Feedback soll wieder in den nächsten Schritt von Work Einfließen damit eine Sicherheit dar ist dass sich auf dem Markt vernünftig ja agieren kann.
00:02:46: Das ist mir halt nochmal ganz wichtig, dass Ihr Work und Feedback wirklich auch so versteht.
00:02:53: Gut!
00:02:54: Dann würde ich sagen steigen wir mal jetzt in den nächsten Teil ein.
00:02:58: Ich habe zwei Geschwindigkeiten also ich arbeite eine Aufgabe ab.
00:03:04: das dauert eine gewisse Zeit.
00:03:07: Das hängt am Release-Zyklus ab, wie schnell ihr überhaupt was releasesen könnt.
00:03:11: Ob ihr von Hand testet, ob ihr automatisierte Tests habt oder eine Kombination habt und permanent testen könnt... Du kannst dir vorstellen es gibt viele Gründe woran die Geschwindigkeit der Arbeit hängen kann.
00:03:25: Die Workgeschwindigkeit ist die Geschwindigkeit von ich starte eine Aufgabe bis die Aufgabe ist in Produktion unbenutzbar.
00:03:33: Eine ganz andere Geschwindigkeit ist dann die Feedback-Geschwindigkeit.
00:03:37: Wie schnell erhalte ich ein relevantes Signal zurück, das ich koppeln kann mit der Arbeit, die ich da gemacht habe?
00:03:46: Also... Ich bekomme einen Feedback zu dieser Veränderung des Loginmechanismus und dann ist es gekoppelt!
00:03:52: Wie lange dauert das bis ich dieses Feedback
00:03:54: bekomme?!
00:03:55: Und nochmal... Irgendeinen Feedback zur irgendetwas anderem ist nicht gekoppeld.
00:04:00: Das hat mit meiner Arbeit nichts zu tun, nur wenn ich jetzt Koppel kann nicht draus lernen.
00:04:05: Und in der Regel und das kenne ich von mir auch ist es so dass die Feedback Geschwindigkeit wahrscheinlich der begrenzende Faktor ist.
00:04:13: Es dauert in der Regeln ein bisschen länger oder 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.
00:04:25: Wenn man das jetzt mal in so einem Quadranten malt, ich blende dir hier so eine Kapitelmarke ein und dann siehst du eine Grafik.
00:04:31: Und wir uns so vier Quadrantes vorstellen.
00:04:35: links auf der Y-Achse haben wir die Geschwindigkeit der Arbeit.
00:04:39: Links unten langsam, links oben schnell.
00:04:42: Und horizontal die X-Aachse haben wie die Geschwinnigkeit des Feedbacks.
00:04:46: Links ist die Geschwingkeit langsam und rechts ist die Schwindigkeit schnell.
00:04:49: Dann haben wir vier Quadranten.
00:04:53: Oft genug ist es so, dass wir nicht in den Quadranten sind indem wir sein wollen.
00:04:57: Wir wollen die gleiche Geschwindigkeit zwischen Arbeit, Work und Feedback damit wir unseren Zyklus unsere Koppelung insgesamt schnell durchgehen können.
00:05:07: diesen Teil schneller Arbeit, schnelles Feedback wenn man das natürlich versuchen so sicher und so schnell wie möglich zu machen.
00:05:14: den habe ich Learning genannt.
00:05:16: jetzt haben wir ein System indem die nächste Arbeit einen Einfluss hat, und zwar von dem Feedback das ich bekommen habe.
00:05:23: Also kann mein Unternehmen, kann meine Software, kein meinem Produkt lernen?
00:05:27: Sehr sehr oft ist es so dass zwar die Arbeitsgeschwindigkeit schnell ist aber die Feedback-Gelbschwindigkeit langsam.
00:05:34: Es dauert Ewigkeiten.
00:05:36: also fange schon mal irgendwas Neues an.
00:05:38: in dem Moment rate ich halt Ich rate was man wohl als nächstes tun muss Und diesen Quadranten hab' ich Aktionismus genannt.
00:05:46: Der andere Fall?
00:05:48: Die Arbeit ist langsam, Work ist langsam und Feedback ist schnell.
00:05:51: Das ist Frustration.
00:05:53: Da kommt immer schnell Feedback viel Feedback.
00:05:56: Du müsstest das verändern, du müsstest es verändern Und ich kriege das nicht abgearbeitet!
00:06:01: Und der letzte Quadrant... Wenn die Arbeit langsam ist und das Feedback langsam ist, ist Stagnation.
00:06:08: Da werde ich rechts und links auf dem Markt von anderen überholt.
00:06:12: Wenn man sich diese Quadranten jetzt mal anguckt Dann können wir nochmal so ein Side Step hin zu AI machen, denn AI das wissen wir alle beschleunigt zwar den Work-Teil aber eben nicht den Feedback Teil.
00:06:25: Den könne nur echte User liefern also kann ich denen auch nicht weiter beschleünigen und deswegen ist in Arbeit mit AI dieser Feedbackteil der begrenzende Faktor.
00:06:34: es mag ja sein dass sich mein Work-Tail die Geschwindigkeit erhöhen kann aber die Grenze bildet der Feedback-Teile Denn sonst lande ich wieder in diesem Aktionismus Bereich.
00:06:45: Also ich arbeite und arbeite, schubste Code raus.
00:06:48: Es gibt Releases über Release.
00:06:49: Mein Produkt wird immer größer, immer voller... Aber das Feedback kommt einfach nicht an!
00:06:54: Da sehen wir zum Beispiel ein Jira um ganz ehrlich zu sein ne?
00:06:57: da steht so viel Quatsch drin.
00:06:59: Ich kann mir wirklich nicht vorstellen dass das alles auf Userfeedback basiert Um das vielleicht an dieser Stelle noch zu sagen.
00:07:05: Diese Zustände in dem dann Teams oder Unternehmen sind Das hat nichts mit Haltung oder Motivation oder so zu tun.
00:07:13: Ein engagiertes Team kann komplett in diesem Frustrationsbereich feststecken.
00:07:19: Es kann eine disziplinierte Firma geben, die komplett im Aktionismus lebt und wie so oft, ehrlich gesagt so gut wie immer... ...die Ursache sich nicht an Menschen oder so sondern sie liegt am System und in unserem Fall an der Kupplungsgeschwindigkeit.
00:07:34: Wenn du Software entwickelst Du aber keinen direkten Kontakt zu deinen Usern hast weil ein Auftraggeber dazwischen ist zum Beispiel Dann ist es super frustrierend und du wirst nie ein gutes Ergebnis erzählen, aber das Diagnose Tool Workfeedback Loop hilft dir das besser anfassbar zu machen.
00:07:53: Das ist ja genau die Idee hinter diesem Diagnoso- und Denkmodellwork Feedback Loop.
00:07:58: Du siehst es jetzt einfach viel transparenter wo das Problem überhaupt ist.
00:08:02: Ja und wir wissen alle Series of Constraints Wir suchen eigentlich immer nach dem engen Pass Und da hilft dir dieses Schaubild.
00:08:09: Da hilft dir das Verständnis von was ist mit Arbeit, mit Work gemeint?
00:08:14: Was ist mit Feedback gemeint?
00:08:16: und dir hilft das Ververständnis dass da eine enge Kopplung zwischen beiden sein muss.
00:08:21: Sonst sind wir gar nicht im agilen arbeiten und dann suchst du halt wie sonst auch den Engpass.
00:08:27: Ja und eigentlich sollte es gewesen sein.
00:08:29: ich habe so gefühlt die Folge ist ein bisschen länger geworden als fünf Minuten Ist wahrscheinlich gar nicht so schlimm Wie immer.
00:08:36: Freue mich auf kritische Anmerkungen dazu.
00:08:38: Ich freue mich auf Dein Feedback, ich freu mich wenn Du die Feedback Loop, die Workfeedback Loop liest.
00:08:44: Ich habe das als PDF oder als Webseite auch veröffentlicht.
00:08:48: Den Link dazu findes den Shownote und ich würde mich freuen ja wenn wir darüber in den Austausch kommen!
00:08:54: In der nächsten Folge, Folge elf wird es dann darum gehen dass dein Team gar nicht langsam ist sondern euer Feedback zu spät kommt.
00:09:03: Da geht es mir um die Feedback-Response Time.
00:09:05: Was heißt das jetzt schon wieder?
00:09:07: Naja, das bedeutet oft genug muss man sich die Zeit angucken, die es braucht bis ein Feedback ankommt und eine Arbeit beeinflusst und diese beeinfluste Arbeit dann wieder in Produktion ist.
00:09:20: Und wir lernen dabei dann übrigens auch dass ne Feedback Decade also Ein Feedback das ich sofort verarbeiten kann is mehr wert als ein Feedback, das ich erst nach drei oder fünf oder acht Monaten bearbeite weil dieses Feedback gar keine Gültigkeit mehr haben kann.
00:09:39: Gut!
00:09:39: Das soll es dann tatsächlich für heute gewesen sein.
00:09:42: Habt noch eine ganz tolle Woche und bis zum nächsten Mal.
00:09:45: Ciao ciao.
Neuer Kommentar