NBA66: Flow-Messung in agilen Teams – was bringt’s, was ist Bullshit?

00:00:00: Hallo und herzlich willkommen bei No-Bullshit-Agile. Mein Name ist Thomas. Jede Woche spreche ich hier

00:00:08: kurz und knapp über Themen rund um agiles Arbeiten. In der letzten Folge ging es mir

00:00:13: um Cargo-Kult. Kurze Zusammenfassung dazu, was bedeutet das? Naja, Unternehmen imitieren

00:00:19: Agilität ohne echtes Mindset und ohne den Willen zur kulturellen Veränderung. Symptome

00:00:25: agiler Scheinwelten kann man erkennen und sollte man auch analysieren und echte Agilität

00:00:32: erfordert eben tiefgehende Veränderungen von Werten und Praktiken. Wenn dich das interessiert,

00:00:38: hör da gerne rein. Den Link zu dieser Folge sowie alle weiteren Links, die ich erwähne,

00:00:43: findest du in den Show Notes. Heute geht es um ein Thema, das unsere Teams umgetrieben

00:00:49: hat und ich glaube, das treibt wirklich viele Teams um. Es geht darum, wie messen wir eigentlich,

00:00:54: ob unser Team wirklich schnell wird? Also egal, meiner Meinung nach, ob du Scrum machst oder kann

00:01:01: man oder irgendwas dazwischen, dieses Thema Flow messen, ja, ich glaube, das treibt einfach viele

00:01:07: um. Das liegt meiner Meinung nach vor allen Dingen daran, dass es nicht so greifbar ist und ich habe

00:01:13: mir halt gedacht, okay, ich gucke mir das nochmal an und mache mal eine Folge dazu und will, ja,

00:01:20: ganz zum Schluss der Folge auch noch sicherlich so ein paar Praxistipps geben. Wir fangen mal an,

00:01:25: was bedeutet das eigentlich Flow? Was meinen wir eigentlich, wenn wir in agilen Teams von Flow

00:01:30: sprechen? Das ist, wie gesagt, gar nicht so einfach. Zumindest tue ich mich damit auch immer

00:01:36: wieder schwer, wenn ich das Leuten erkläre. Also man kann so eine ganz nüchterne Erklärung machen,

00:01:42: Arbeit soll gleichmäßig durch euer System fließen. So, keine Wartezeit und das bezeichnet

00:01:52: den Flow. Was mir dabei ganz wichtig ist und das wird uns jetzt die ganze Folge auch begleiten,

00:01:57: Flow ist kein Ziel. Flow ist ein Zustand und den wollen wir verbessern. So und das Erste,

00:02:05: was ich mir hier notiert habe, wenn ich jetzt von messen rede, ist natürlich sofort die Frage,

00:02:11: wie misst man denn den Flow? Welche Metriken gibt es, um den Flow zu messen? Das habe ich

00:02:19: mal ein bisschen eingeteilt. Es gibt sicherlich so ein paar Klassiker. Sobald man anfängt,

00:02:23: zu dem Thema zu googeln, dann kommt man eigentlich zuallererst mal auf die sogenannte Cycle Time.

00:02:29: Was ist Cycle Time? Das ist die Zeit vom Start der Arbeit bis zur Fertigstellung. Natürlich ist

00:02:36: es so, ihr müsst es selber definieren. Was ist bei euch Start der Arbeit und was ist Fertigstellung?

00:02:42: Das wird uns übrigens auch noch begleiten. Ja, das ist die Cycle Time. Nächste auch super

00:02:48: bekannte Zahl oder Möglichkeit der Messung ist die sogenannte Lead Time. Wie lange dauert es vom

00:02:55: Eingang, einer Anforderung bis zur Fertigstellung? Das ist also größer als die Cycle Time und die

00:03:01: Cycle Time ist ein Teil davon. Der Fokus bei der Lead Time liegt eben vor allen Dingen darauf,

00:03:06: zu sagen, okay, wir gucken uns auch an, wie lange heute dauert es, jemand möchte was von uns und

00:03:13: wann ist es fertig. Die dritte Zahl ist der Durchsatz, Throughput auf Englisch. Da geht es darum,

00:03:20: Anzahl der abgeschlossenen Items pro Zeiteinheit zu messen. Also wie viele Items schaffen wir pro

00:03:27: Woche, pro Monat, was auch immer eure Zeiteinheit ist. Die vierte Zahl, die man messen kann, ist

00:03:33: WIP Work in Progress. Wie viele Items sind gleichzeitig in Bearbeitung? Und da sind wir

00:03:39: ganz schnell auch beim WIP Limit. Zum WIP Limit habe ich ja auch eine Folge gemacht und es gibt

00:03:44: ja auch den WIP Limit Simulator. Wenn dich das interessiert, ja, wie gesagt, schau da gerne mal

00:03:49: in die Show Notes dazu. Die nächste Zahl, Work Item Age, Alter der noch offenen Task. Wie lange

00:03:59: liegt ein offener Task bei uns in Bearbeitung? Die letzte Zahl, die ich hier so unter Klassiker

00:04:07: zusammengefasst habe, ist Flow Efficiency, Anteil aktiver Bearbeitungszeit an der Gesamtzeit der

00:04:14: Bearbeitung. Also wie lange liegt was, dann bearbeitet ihr es wieder, dann liegt es wieder,

00:04:20: dann bearbeitet ihr es wieder, bis es denn dann irgendwann fertig ist. Es gibt ein paar weitere

00:04:24: Zahlen und ja, die betrachte ich tatsächlich als kritisch. Wenn ich von kritisch spreche,

00:04:31: vielleicht ganz allgemein, so eine erste Kritik hier. Zahlen neigen dazu, dass man sie cheasen

00:04:38: kann. Das passiert vor allen Dingen, wenn sie veröffentlicht werden und wenn sie für Vergleiche

00:04:45: benutzt werden. Also Vergleiche zwischen Teams, aber auch innerhalb des Teams. Diesen Monat versus

00:04:52: letzten Monat und ja, wir neigen halt dazu zu schauen, okay, wie kriegen wir die Zahl besser

00:04:58: und das machen wir dann nicht im Sinne von, okay, wir wollen den Flow optimieren, sondern indem wir

00:05:05: ja cheasen, also auf deutsch gesagt bescheißen, auf irgendeine Art und Weise eine Abkürzung suchen

00:05:10: und deswegen bin ich grundsätzlich bei Zahlen ja kritisch, zumindest sehr vorsichtig. Auch da komme

00:05:17: ich gleich noch mal drauf. Gut, welche Zahlen betrachte ich auf jeden Fall als kritisch? Velocity

00:05:23: und oder Story Points. Vor allem, wenn man die so als eine Speedmetrik benutzt. Die sagen in der

00:05:30: Regel sehr wenig über den echten Fluss. Also wenn die Zahlen, also die Team Velocity zum Beispiel

00:05:38: außerhalb vom Team benutzt wird oder um, wie gesagt, Teams zu vergleichen. Ich habe dazu tatsächlich

00:05:45: in einem Interview, das ich mit dem Marco von ScrumShow hatte, in NBL 25 auch gesprochen. Da

00:05:51: geht Marco da tatsächlich auch noch mal drauf ein aus seiner Sicht. Ja, kritisch finde ich Flow

00:05:57: Efficiency, also dieser Anteil aktiver Bearbeitungszeit an der Gesamtzeit. Das sind

00:06:04: schöne Prozente. Keine Ahnung, wir haben eine Efficiency von 80 Prozent oder 90 Prozent. Aber

00:06:11: was ist der Erkenntnisgewinn da drin? Halte ich auch für, ja, schwierig, sage ich mal. Ganz im

00:06:17: Allgemeinen kann ich auch noch sagen, wenn ihr nur Durchschnitte über alles Mögliche bildet,

00:06:23: der Durchschnitt über den letzten Monat, der Durchschnitt dieses Quartal oder so. Ja,

00:06:28: dann vergebt ihr euch eine große Chance. Denn eigentlich sind die Ausreißer viel interessanter.

00:06:32: Warum gingen Dinge deutlich schneller als der Durchschnitt oder deutlich langsamer? Welche

00:06:38: Storys waren das? In welcher Situation waren wir da als Team? Ist eigentlich viel spannender,

00:06:43: als Durchschnitte von verschiedenen Zeitperioden jetzt zu vergleichen. Ebenso ist es mir sehr

00:06:49: wichtig, wenn ihr Zahlen erfasst, und ich sage gleich auch ein bisschen, was mein Praxisansatz

00:06:55: wäre, dann müsst ihr das institutionalisieren. Das nützt sich, das einmal zu tun oder ziemlich

00:07:01: unregelmäßig, sondern ihr müsst es, wenn, dann wirklich auch regelmäßig tun. Der nächste Punkt,

00:07:06: den ich habe, wir haben jetzt die ganze Zeit auf, ich sage mal, teaminterne Zahlen geguckt. Ich finde,

00:07:12: aber es gibt so zwei Stockwerke, wenn ihr euch das so bildlich vorstellen wollt. Es gibt eben das

00:07:17: Stockwerk 1, das sind diese Teamzahlen, also all die Zahlen, die ihr im Prinzip auch mit steuert und

00:07:24: mit unter Kontrolle habt und die eine Aussage dazu treffen sollen, sage ich jetzt mal, wie ist der

00:07:31: Flow innerhalb des Teams und wie gut arbeitet ihr als Team zusammen. Geht also schlussendlich darum,

00:07:38: wie schnell fließt die Arbeit durch das eigene System, das ihr wie gesagt unter Kontrolle habt.

00:07:44: Was das eigene System ist, das kann natürlich super unterschiedlich zwischen Teams sein. Bei

00:07:49: uns ist es zum Beispiel so, der Teil des Releases, aber auch der Teil des Customer Feedbacks, weil wir

00:07:55: ja für Kunden was entwickeln, da haben wir sehr wenig Kontrolle drüber. Das ist also nicht mehr

00:08:02: wirklich Kern dessen, was wir als Team leisten können. Es gibt trotzdem ganz tolle Ansatzpunkte,

00:08:08: nämlich mit dem Kunden darüber zu sprechen, dass der Teil, der nicht mehr bei uns im Team direkt ist,

00:08:13: ja einen großen Einfluss darauf hat, dass etwas auf die Straße kommt und Geld verdient. Und da

00:08:19: kann man mit dem Kunden wirklich ganz wundervoll drüber sprechen und meine Erfahrung ist, dass

00:08:24: Kunden auch sehr dankbar sind, dass man ihnen dabei auch ein bisschen hilft, Stück für Stück auch

00:08:28: diesen Teil zu optimieren. Das ist eben dieses Stockwerk 1, von dem ich gerade gesprochen habe

00:08:34: und da gibt es auch das Stockwerk 2 Delivery und da gibt es eine wunderschöne Methodik und Metrik

00:08:41: nämlich DORA, DevOps Research and Assessment. Dazu habe ich sogar zwei Folgen gemacht. Das ist

00:08:47: NBE 37 und NBE 38. In 37 gebe ich so eine Einführung und in 38 mache ich so eine kritische Bewertung

00:08:55: dazu. DORA besteht aus vier Metriken, die da erfasst werden. Das ist Lead Time for Changes,

00:09:01: also wie lange dauert es vom Commit bis zum Go Live. Deployment Frequency, also wie oft

00:09:06: liefert ihr wirklich. Change Failure Rate, also wie oft gehen Deployments dann schief. Und als

00:09:13: letztes Meantime to Restore, also wie schnell erholt ihr euch dann von so einem Problem bei

00:09:18: einem Release. Und DORA wird einmal im Jahr durchgeführt. Das ist eine ziemlich große

00:09:23: Befragung. Jetzt erzähle ich doch ein bisschen, was es ist. Ist also total spannend und bildet

00:09:29: so einen zweiten Flow-Teil und deswegen habe ich gesagt, okay es gibt das Stockwerk 1, das was ihr

00:09:34: intern habt und das Stockwerk 2, also das was dann nach außen schlussendlich Dinge in Produktion

00:09:39: bringt. Super interessant. Ja und ein geschlossenes Bild ergibt sich eben eigentlich nur aus beiden.

00:09:46: Also es kann sein, dass ihr einfach echt richtig, richtig gut und richtig schnell seid und ein

00:09:54: größeres Problem eben beim Liefern besteht. Vielleicht, weil ihr abhängig seid von einem

00:10:01: Lieferteam, das ihr habt oder eben wie bei uns vielleicht durch Abhängigkeiten, die es auf

00:10:05: Kundenseite gibt. Als nächstes möchte ich ein bisschen darüber sprechen, was ist eher ein

00:10:11: Problem, Cargo-Kult auch. Macht man so? Oh Gott, oh Gott. Und was hilft wirklich? Also wo erkennt

00:10:19: man, ob eine Flow-Messung wirklich hilft und was ist nur Show? Also Show meiner Meinung nach ist,

00:10:25: wenn man einfach Metriken sammelt, weil man das so tut. Wenn man die nicht interpretiert,

00:10:30: warum soll man sie dann sammeln? Velocity hatte ich vorhin schon gesagt, vor allen Dingen im

00:10:35: Bereich Team-Vergleich ist keine gute Idee und Flow-Efficiency. Versuchen hochzukriegen, ohne

00:10:42: wirklich die Ursachen zu analysieren. Ja halte ich alles für nicht Zeitverschwendung, sage ich mal,

00:10:48: aber wenn man Zeit investiert, kann man die meiner Meinung nach woanders besser investieren. Ja,

00:10:53: was hilft? Metriken mit Zielen. Wenn ihr euch zuallererst mal fragt, warum messen wir etwas und

00:11:01: was wollen wir mit dem Ergebnis erreichen und was ist auch das erwartete Ergebnis oder was

00:11:06: prognostizieren wir denn? Dann sind solche Metriken sicherlich hilfreich, wenn ihr die ganze Zeit auch

00:11:15: den Kontext beachtet. Also nicht den Durchschnitt angucken, sondern wirklich gucken, was ist in den

00:11:22: Ausreißern passiert und in welchem Kontext waren wir da? Also waren unheimlich viele Leute krank oder

00:11:27: hat sich herausgestellt, diese Funktion, die wir da entwickeln, war super kompliziert oder,

00:11:33: oder, oder. Super interessant, ne? Und eben, was hilfreich ist, End-to-End denken. Also das ganze

00:11:42: Bild, das Stockwerk 1 und das Stockwerk 2 betrachten, auch wenn vielleicht Stockwerk 2 für

00:11:47: euch schwieriger zu steuern ist. Ja, denkt daran, Metriken sind eben kein Selbstzweck. Das ist auch

00:11:54: nur ein Werkzeug und nur wenn ihr damit arbeitet, bringt es auch was und zwar ihr als Team, nicht

00:12:00: wer anders. Okay, dann würde ich euch gerne noch ein paar Praxisempfehlungen geben. Also wie fängt

00:12:06: man damit an? Wie gesagt, ganz wichtig finde ich vorab das Gespräch dazu, was ist Flow und warum

00:12:14: fangen wir an, den Flow zu messen? Was haben wir vor? Was wollen wir erreichen? Alleine da drin,

00:12:20: in dieser Diskussion, die ihr da führt, steckt einfach schon unheimlich viel. Und dann, wie

00:12:26: immer, würde ich vorschlagen, klein anzufangen. Also, Cycle Time, finde ich, ist eine gute Zahl,

00:12:32: mit der man sich beschäftigen kann und ich finde, Work in Progress sich anzugucken, wie viel Arbeit

00:12:38: haben wir gleichzeitig in der Luft, halte ich für sehr sinnvoll. Dann denke ich, macht es einfach

00:12:44: Sinn, das Ganze zu visualisieren, möglichst einfach, um es auch sichtbar und anfassbar zu

00:12:52: haben. Und dann institutionalisiert ist, dass ihr darüber redet, über diese Zahlen. Was sagt euch

00:12:59: das? Was hattet ihr prognostiziert? Welche Veränderungen haben stattgefunden und ist das

00:13:05: Outcome so, wie ihr gedacht habt? Und ja, es ist wichtig, das reine KPI-Denken da einfach

00:13:13: möglichst zu vermeiden. Ich habe noch einen schönen Satz, der das Thema ganz gut abschließt.

00:13:19: Messen hilft nicht beim Liefern, aber beim Lernen. Und ich denke, das ist halt auch so eine ganz,

00:13:26: ganz wichtige Komponente. Die ganzen Gespräche, die Gedanken, die da einfließen in dieses Thema

00:13:32: Flow-Management, da entstehen dann im Zweifelsfall Zahlen, ja, aber der Weg dahin, das ist echt das

00:13:39: Entscheidende, da lernt ihr wirklich, wirklich viel. Und wenn ihr für euch feststellt, okay,

00:13:45: für uns macht es keinen Sinn, den Flow zu messen, dann ist das ein gutes Ergebnis und packt euch

00:13:51: das doch auf Wiedervorlage für nächstes Quartal oder in einem Monat oder was auch immer für euch

00:13:57: ein guter Zeitraum ist. Messen hilft nicht beim Liefern, aber beim Lernen. Ja, und ich denke,

00:14:03: das soll es einfach auch gewesen sein, kurz und knapp wie immer. Ich freue mich immer über Feedback,

00:14:07: wenn ihr was habt, in den Channels steht, wie ihr mich erreichen könnt. Ich freue mich tatsächlich

00:14:12: auch sehr über Kritik, da kann ich einfach viel daraus lernen. Deswegen meldet euch einfach,

00:14:17: wenn ihr irgendwelche Anmerkungen habt. Ansonsten habe ich noch eine ganz große Bitte. Wenn dir die

00:14:22: Folge gefallen hat, wenn dir der Podcast gefällt, dann teile das gerne, teile das mit deinen

00:14:27: Kolleginnen und Kollegen, teile es auf Social Media. Je mehr Leute von dem Podcast erfahren,

00:14:32: desto größer wird die Diskussion und dann kann ich halt die Punkte wieder aufnehmen,

00:14:36: kann daraus neue Folgen machen und ja, das kommt schlussendlich dir ja auch zugute. Ich sage dafür

00:14:41: auf jeden Fall vielen Dank. Ansonsten sage ich, habt noch eine ganz tolle Woche und bis zur nächsten

00:14:46: Folge bei No-Bullshit-Agile.