Erfolgsgarantie

Für das Thema Erfolgsgarantie konnte ich glücklicherweise wieder die liebe Lea Lindemann gewinnen. Ich baue aktuell an einer Agile Master Ausbildung, die nach Möglichkeit alles umfassen soll. So kam es, dass wir beide über LinkedIn, über Erfolgsgarantien in der Agilen Welt sprachen. Die Aufnahme ist vom 05.01.2024, ich habe nur etwas länger gebraucht dafür. 🙂 #Elternzeit

Lea Lindemann | LinkedIn

Home | La Agilista (la-agilista.com)

Agile Master Ausbildung: https://znip.academy/agile

Demnächst starten wieder unsere Menschen lesen Module, welches aktuell noch mit Rabatt gibt: https://znip.academy/mk

Erste Folge mit Lea: Value Stream

Diese Folge auf YouTube: https://youtu.be/eq9AWeSfF7o

Quellen

LinkedIn-Post: https://www.linkedin.com/posts/henry-schneider-znip_agile-community-agilitaeut-activity-7134892265683968000-tGgD

Fehlzeiten-Report: https://www.aok.de/pp/gg/update/fehlzeiten-report-2023

Zusammenfassung der LinkedIn-Studie: https://www.welt.de/wirtschaft/karriere/article174855200/Fluktuation-Deutsche-wechseln-haeufiger-den-Job.html

Wieso dieses Thema?

Wir sind über einen LinkedIn Post von Henry Schneider auf dieses Thema gekommen. Ich habe durch die Elternzeit viel Zeit zum Nachdenken und wenig zum Arbeiten. Dabei stelle ich gerade das Agile Master Training zu einer Agile Master Ausbildung um, die alles zu Agilität umfassen soll und Dich 18 Monate bei der Veränderung und dem Erfolg im Unternehmen begleitet. Bei dieser Größe der Ausbildung möchte ich Dir auch gern eine Erfolgsgarantie geben. Nur welche und welche Garantien kann man allgemein im Agilen Umfeld geben?

Und Lea fand, da habe ich einen Punkt.

Also mit was kann ich hinterher, was es wirklich wert ist, diese Ausbildung zu besuchen?
Und ein ähnliches Thema habe ich natürlich auch, wenn ich Workshops anbiete oder wenn ich selbst als Coach eingekauft werde.
Was kauft das Unternehmen da ein? Und meist kaufen sie nur die günstigsten ein, kommen dann so nach sechs bis neun Monaten danach dann wieder zu mir und fragen mich, ob ich das, was jetzt da noch mehr an Schaden ist, beheben könnte und wo ich mir immer so denke, naja, wäre vielleicht leichter gewesen, wenn ich gleich da gewesen wäre.
Auf der anderen Seite habe ich mich dann auch in den Kunden hineinversetzt oder in die Kundin, mich gefragt, naja, aber woher sollen die es denn wissen?
Also was genau kann ich denn als Garantie anbieten, gerade im agilen Umfeld, wo ich viel mit Mindset und Persönlichkeitsentwicklung und Organisation umstrukturieren beziehungsweise die Umstrukturierung ergibt sich dann aus dem anderen Denken zu tun habe.

[2:21] Was für eine Garantie kann ich denn da geben?
Genauso bin ich da drauf gekommen und stelle mir die Frage tatsächlich bis heute noch.
Ich habe schon jetzt so ein paar Ansätze und die möchte ich heute ganz gerne mit dir diskutieren.
Und auch die offensichtlichen Sachen, auf die man normalerweise drauf springt, auch die hatten wir ja kurz schon mal im Vorfeld, im Vorgespräch andiskutiert, da auch drauf zu gehen, auch warum wir die vielleicht für nicht ganz so gut halten, diese offensichtlichen Sachen.
Also das eine ist natürlich tatsächlich, was du sagtest, so dieses, wie kann ich einen Kunden und vielleicht sogar noch im Unterschied dazu den Einkäufer überzeugen, dass meine Leistung das wert ist, aber überhaupt, dass ich vielleicht auch mal für mich selber messen kann, welchen Fortschritt mache ich.

[3:03] Also für mich selber, dass ich, wenn ich in ein Projekt reinkomme und da vielleicht auch über einen längeren Zeitraum bin, dass ich für mich Indikatoren habe, außer das Freudejauchzen der Kunden natürlich, bewege ich tatsächlich etwas in die richtige Richtung.
Und ganz ehrlich, ich habe mir im Vorfeld Gedanken gemacht und bin für mich nicht zu so einem Ergebnis gekommen, wo ich sage, jawohl, das ist was, wo ich jetzt sagen würde, das funktioniert als Metrik immer.
Dann habe ich mich aber auch nochmal gefragt, warum interessiert das Thema?
Zusätzlich zu Kunden überzeugen, Einkäufer überzeugen, eigene Wirksamkeit messen ist auch eigenes Pricing.
Also so, was ist meine Leistung wert? Was kann ich dafür verlangen, wenn wir jetzt weg von, ich verkaufe halt einfach nur stumpf Stunden kommen, dann muss ich da ja irgendwie ein sinnvolles Preisschild dran stecken.
Und das geht natürlich auch viel besser, wenn man irgendwie ermessen kann, was für einen Mehrwert man da liefert. Und das Pricing jetzt noch ein bisschen weiter gesponnen.
Ich erlebe es in vielen größeren Unternehmen, dass die Agilisten, die ganzen Scrum Masterinnen oder Zen Master kann man, egal welches Framework, dass die eher als so ein bisschen überflüssig oder nutzlos angesehen werden, weil das ist eine Person, die wird voll bezahlt.
Und was genau tut die eigentlich?

[4:12] Hat die überhaupt einen Mehrwert jetzt für mein Projekt? Und da verstehe ich auch viele Abteilungsleiter und Projektleiterinnen, dass die halt dann sagen, naja, irgendwie, ich sehe keinen Sinn da drin, jetzt da eine Person mehr zu bezahlen und dafür Geld auszugeben.
Und häufig haben die ja auch gute Gehälter, zu Recht, meiner Meinung nach, zu Recht, denn die Arbeit ist wertvoll und gut.
Nur eben genau das rüberzubringen und da so einen Punkt zu setzen mit, okay, wenn du jetzt hier einen Agilisten reinholst, bekommst du auch Folgendes.
Auch da hast du schon gesagt, naja, viele Sachen werden wir jetzt hier sicherlich auch andiskutieren und es gibt nicht diese eine, wo wir jetzt wahrscheinlich sagen können, genau die ist es, weil logischerweise wir sind im agilen Umfeld unterwegs.
Es ist komplex und dementsprechend gibt es keine Blaupausen und es gibt immer wieder diese individuelle Lösung, aber die kann ich vielleicht an jeden dann als genau diese Garantie dann anpassen.

[5:04] Ich habe mich natürlich ganz strukturiert hingesetzt und überlegt, wie kann man dieses Thema denn diskutieren, was gibt es da überhaupt zu diskutieren.
Habe mich dann gefragt, erstmal warum misst man das und dann aber auch, was messen wir eigentlich.
Und eigentlich messen wir, wenn man fragt, was ist denn jetzt der Mehrwert von einem Coaching oder einer Beratung, dann messen wir immer erstmal diese Veränderung.
Vorher, wie ist es vorher, wie ist es nachher. Und das, finde ich, macht es dann schon ein bisschen schwierig, weil…

[5:30] Du musst ja erst mal, wenn du beim Kunden reinkommst, direkt erst mal Messwerte erheben.
Also weil tatsächlich am Ende eine Messung zu machen und dann das am Anfang nicht zu haben, dann ist halt wieder so ein bisschen, wie messe ich, wie ist eigentlich der Unterschied, wie beziffer ich den jetzt.
Also das heißt, es ist immer irgendwie so ein bisschen vorher, nachher, vielleicht auch ein Zeitverlauf.
Und was ich tatsächlich messe, ich habe mich da hingesetzt, gibt es irgendeine generelle Metrik, die ich verwenden kann und habe gesagt, für mich eigentlich nö.
Also es gibt jetzt keine Metrik, die ich per se, also wenn man jetzt sagt, Lea, du bist doch Agilistin, du kommst jetzt hier ins Projekt, jetzt woran messen wir denn den Erfolg?
Ich kann jetzt nicht sagen, dass da Velocity ist, so ein klassisches Beispiel oder Flowmetriken oder so.
Ich meine, Flowmetriken finde ich schon ziemlich gut, aber so allgemein, die Metrik benutzen wir und dann können wir daran den Erfolg messen.
Nein, was ich mir angucke, das hängt ja völlig davon ab, was meine Kunden erreichen wollen.
Und das ist wieder der Punkt, wo ich sage, da wird es schwierig.
Weil Kunden wollen ja ganz gerne, dass man sehr konkret ist.
Die kommen und stellen eine Frage.
Wann merke ich denn, dass es sich gelohnt hat, sie einzukaufen?
Und dann sage ich, ja, kommt halt drauf an, was sie erreichen wollen. Blöde Antworten.

[6:41] Das ist richtig coole Basis für unseren Podcast hier, finde ich.
Also deshalb liebe ich dieses Podcast-Format so, weil es eher eine Diskussion ist mit anderen, die eben auch viel Erfahrung haben, als dieses so mit stumpf, hier werden jetzt hier die ganzen Infos runtergebetet.
Also ich habe so zwei, drei Sachen, wo ich sage, okay, da gibt es eine Metrik, die kann man vielleicht ganz gut verwenden.

[7:02] Auf die möchte ich dann heute noch eingehen. Doch ich möchte ganz gerne damit beginnen, weil du es jetzt eben gerade schon genannt hast.
Dass Velocity, Story Points, Flow, Matrix, das sind ja auch die offensichtlichen Sachen, wo ich auch von den meisten Angelisten höre, na ja, lass doch die jetzt einfach verwenden.
Warum das vielleicht nicht so ist und vielleicht auch erstmal ganz kurz.

[7:21] Was es denn überhaupt ist. Also wir haben auch einzelne Podcast-Folgen dazu, nur vielleicht steigt jemand gerade erst jetzt hier ein.
Wollt ihr dann jetzt etwa nicht die 10 Folgen zu Velocity und Flowmetric und sonst was nach?

[7:34] Weiß ich nicht. Die Velocity-Folge werde ich auf jeden Fall verlinken. Mal gucken.

[7:38] Also das Offensichtlichste ist Story Points.
Also das soll eigentlich eine relative Komplexität messen.
Also all die Features, die wir so implementieren, hauptsächlich in in der Softwareentwicklung, das geht allerdings auch in Hardware und allem, dass wir da sagen, okay, es gibt eine relative Komplexität.
Also sprich, wenn ich nach Berlin fahren möchte, hier von Wolfsburg aus, also ich sitze jetzt gerade in Wolfsburg aus, ist es wahrscheinlich weniger komplex, wie wenn ich nach Hanoi fahren möchte.
Das ist wahrscheinlich deutlich komplexer. Und so kann ich eben die Komplexität jetzt erstmal in Relation setzen.
Und da kann ich Story Points dran packen, dass ich halt sage, im Äquivalent, Die Fahrt nach Berlin ist eine 3 und die nach Hanoi ist eine 20 und schon habe ich meine Story Points.
Ganz, ganz simpel erstmal Story Points erklärt. Und wenn ich da jetzt angekommen bin in Berlin oder in Hanoi, dann mache ich einen Haken dran und dann zähle ich die Story Points quasi.
Und die Grundannahme von Agilität ist jetzt durchaus, wenn ich mit Story Points arbeite, dass das Team natürlich schneller, besser wird, high performing und so weiter und daher mehr Story Points schafft.

[8:43] Das ist jetzt grundsätzlich erstmal die Annahme. Und dazu gibt es die Velocity, die dann eben sagt, okay, über Zeit, also jetzt mache ich die Komponente Zeit noch dazu, das können Sprints sein.

[8:54] Das kann auch wirklich Tage oder was auch immer sein, messe ich mal, wie viele Story Points denn geschafft werden von diesem Team und dann kriege ich so einen Velocity-Grafen raus und der sollte, und das kenne ich auch aus den Scrum Master Trainings, die ich besucht habe, also meist so diese zwei, drei Tage, wo ich sage, ist cool für einen Einstieg und gleichzeitig weiß ich dann immer noch nicht ganz, wie ich es umsetzen soll.
Dass das so eine Exponential-Funktion ist hiermit.
Die Story-Points, die gehen hoch. Wir machen Agilität und…
Unendlich! Ja, genau. Und daher locker hier doing twice the work in half the time, also 400% mehr Output.
Love. Easy.
Und da ist meine Erfahrung aus der Praxis, also, ja, ja, die steigt schon an, doch die konvergiert eher gegen irgendein Limit, was da irgendwann da ist.
Also wenn ich ein Team in einer Performing-Phase habe, habe, wird da irgendwo eine Decke erreicht, da geht es nicht mehr krass drüber.
Einfach aus dem Grund, dass die für diese Story Points einfach viel mehr mitmachen, weil das wegautomatisiert ist zum Beispiel.
Also beispielsweise, dass die Tests gleich noch mit erstellt werden, die automatisierten, oder dass eben die Integration auf eine Produktivumgebung gleich mit drin ist, oder sobald ich meinen Code committed habe, dass der nicht nur automatisch getestet wird, sondern auch gleich beim Kunden direkt mit ausgeliefert wird, was vorher einzelne Steps waren, das ist jetzt alles mit drin.
Also es es gibt so eine Art Deflation in den Storypoints. Daher…

[10:19] Also generell finde ich Story Points als Metrik ein bisschen schwierig.
Also ich habe es selten erlebt, dass diese Metrik wirklich gut funktioniert in der Praxis.
Tatsächlich ist es einfach so, also du hast halt schon so ja eins, zwei, drei, vielleicht fünf Story Points.
Das ist in Relation zueinander passt das irgendwie noch. Aber sobald du dann in diese höheren Storypoint-Regierungen kommst, da ist es dann einfach nicht mehr so, dass dann 13 immer gleich groß ist, sondern das wird dann sehr volatil.
Wozu man ja eigentlich dann diese großen Abstände zwischen den Zahlen hat.
Fibonacci-Metrik, ich habe das immer geliebt zu erklären, warum man die benutzt.
Ich finde das auch total verständlich, aber tatsächlich habe ich selten erlebt, dass irgendwie Storypoints wirklich gut funktioniert haben. Also du hast halt häufig eben dann diese starke Varianz, die es als Planungsmetrik schwierig macht.
Oder eben tatsächlich so, dass ganz häufig da eine politische Komponente drin ist. Sowas wie, ihr müsst ja immer schneller werden.
Oder dass dann gesagt wird, das Team wird immer vorsichtiger, wenn dann gesagt wird, ihr habt den Sprint nicht geschafft.
Und dann ist halt so eine Storypoint-Inflation, dass man halt im Zweifelsfall lieber höher schätzt.
Deswegen tatsächlich finde ich halt Storypoints und Velocity wichtig.

[11:31] Kann man machen, dann kann man aber tatsächlich auch einfach Flowmetriken machen, wo man einfach die Arbeitspakete, die Anzahl der Arbeitspakete misst, ohne irgendwie dieses aufwändige Schätzverfahren, was dann halt doch wieder unsicherheitsbehaftet ist.
Ich finde es spannend. Ich habe andere Erfahrungen mit den Story Points gesammelt.
Ich setze sie daher ganz gerne ein, allerdings nicht für diese Garantie.
Das ist für mich ein anderes Mittel. Auch die Velocity.
Die Velocity ist für mich ein Indikator dafür, wie viel Experimente ein Team gerade verträgt.
Ich kann so eben auch so ein bisschen die Auswirkungen der Experimente sehen.
Also ein bisschen zeitversetzt, ist ganz klar.
Häufig haben die Unternehmen so Experimente, also die steuern die von außen an, dass sie sagen, ja, das Team läuft ja richtig gut.
Der Product Owner oder die Product Ownerin übernimmt jetzt mal noch ein zweites Team. Und ich muss sagen, halte ich für keine gute Idee, halte ich für keine gute Idee.

[12:24] Und es dann häufig darum geht, ja, aber warum nicht? Du sagst doch häufig so, mit 60 Prozent ihrer Kapazität sollten sie, dann ist ja noch 40 Prozent übrig, da kann man doch mal noch, ehe ich jetzt dann einen zweiten Produkt ohne einkaufe, also ähnliche Diskussionen wie für den Scrum Master, zwei Projekte.
Und dann kann ich meist sehen, weil einfach plötzlich die ganzen Refinements nicht mehr so gut laufen und sowas, wie die Velocity durch dieses Experiment abnimmt und kann dann halt sagen, siehste, genau das ist der Grund, weshalb ich das für keine gute Idee halte.
Lass uns da mal drüber reden, ob wir das anders hinkriegen und dann das wieder hochgeht.
Ich stimme dir allerdings auch gleichzeitig voll und ganz zu mit all dem, was du gesagt hast, denn vor allem, wenn ich jetzt noch Incentives drauf packe, also viele Unternehmen denken ja darüber nach, jetzt externe einzukaufen und die nach Story Points zu bezahlen oder den Scrum Masterinnen einen Bonus zu geben, wenn die Story Points steigen und das ist ja auch genau das, was wir jetzt gerade andiskutiert haben.
Man kauft uns als Coach ein, also würden wir das jetzt als Garantie nehmen mit, dann haben sich nach sechs Monaten die Story Points verdoppelt.
Könnte man ja sagen, gib mir eine halbe Million und ich verdoppel dir deine Story Points in deinen Team.
Das kann ich dir ganz schnell machen. Wir machen einfach einen kleinen Workshop, wo wir unsere Story-Point-Skala neu definieren und dann kriege ich meinen Bonus.

[13:40] Exakt das ist das Problem an dieser Stelle. Und sagt halt nicht zwingend was.
Genau, das ist halt immer im Kontext nur für dieses eine Team dann zu sehen.
Und ich verstehe, dass man sagt, okay, die Story-Points sind da, also bei vielen Teams sind die durchaus da.
Vor allem, wenn ich Incentives drauf packe, dann habe ich plötzlich eine Inflation und das ist einfach nur eine Zahl.
Dann mache ich es halt doppelt oder viermal so. Ja, ich kenne eher das Umgekehrte, dass die Story Points sozusagen als Druckwerkzeug, also als Negativincentive sozusagen benutzt werden.
Dann hat es natürlich denselben Effekt, dass die einfach zu nichts mehr taugen.
Also dass sie halt auch nicht mal mehr für die Teaminterne und für die Planung des POs taugen, wenn sie halt politisiert werden.
Genau. Und ich sage immer, wir bekommen halt genau das, was wir messen.

[14:22] Und wenn wir halt Story Points messen, dann kriegen wir halt mehr Story Points.
Ja, und nicht mehr Mehrwerte. haben. Genau, deshalb sind wir uns da einig, Story Points und Velocity ist es an der Stelle nicht.

[14:34] Jetzt hast du schön das Flow-Diagramm eingebracht.
Ich glaube, das haben wir hier noch gar nicht im Podcast genau beschrieben.
Ich finde es aber auch cool und die meisten Ticketverwaltungstools, die liefern das sowieso automatisch mit und ich mag das zumindest, da drauf zu gucken, um so ein Gefühl dafür zu bekommen.
Magst du es kurz beschreiben? Du hast die Durchlaufzeiten eigentlich oder den Durchsatz, das heißt im Endeffekt messe ich, wie lange braucht ein Ticket von von wir fangen das an zu bearbeiten bis es ist komplett fertig.

[15:03] Kann natürlich auch sein, dass man sogar noch früher anfängt, wann wird das Ticket eingestellt, sozusagen wann hat der PO die Idee.
Das ist ein bisschen unterschiedlich, sozusagen wo man den Startpunkt definiert.
Aber im Wesentlichen messe ich die Bearbeitungszeit für ein Ticket und dann kann ich natürlich über einen gewissen Zeitraum messen, wie viele Tickets schaffe ich fertig. Das ist dann der Durchsatz.
Dann kann man diese Durchlaufzeiten halt auch über die Zeit tracken und sehen, zum Beispiel werden die Durchlaufzeiten länger oder werden die kürzer.
Wenn wir jetzt eine gewisse Retro-Maßnahme durchführen und die Durchlaufzeiten werden kürzer, dann war das natürlich gut und man versucht halt sozusagen eigentlich eben sozusagen das als Metrik zu benutzen, diese Durchlaufzeit zu verkürzen und dadurch wird man ja dann flexibler, sozusagen je schneller ich die Arbeiten abschließe, desto schneller kann ich auch neue Dinge machen und auf Veränderungen reagieren.
Und das sind halt diese Flow-Metriken.
Da kann man dann noch so, sage ich mal, Side-Metrics nehmen, also Seitenmetriken zum Beispiel Work-Item-Age, dass man nicht nur misst, wann ist das Ticket wirklich fertig, sondern sozusagen, wie alt ist dieses Ticket und das kann man so auch als Alarmzeichen benutzen.
Wenn da ein Ticket nach fünf Tagen immer noch in Bearbeitungsstatus und nicht im Teststatus ist, dann ist das vielleicht eher ungewöhnlich und dann kann man da mal drauf gucken.
Das heißt, diese Bearbeitungszeit, diese Durchlaufzeit ist eigentlich eine super einfache, aber super vielseitige Metrik.
Ist natürlich so, dass das mit der Unterstützung von einem Ticketsystem viel, viel einfacher ist, als wenn du das manuell trackst.

[16:27] Andererseits, zum Beispiel Jira bietet ja auch von vornherein dieses Tracking an. Man muss sich aber in jedem Tool, was man benutzt, sehr sehr gut angucken, wie diese Metrik gemessen wird, weil die Tools da vielleicht recht, Und es setzt natürlich voraus, dass man unheimlich saubere Daten hat.
Das heißt, dass man seine Tickets ordentlich pflegt, dass man da alle Daten dran tut, die auch dann entsprechend durch die Status bewegt.
Und dann kann man da aber auch mit einem kumulativen Flussdiagramm, mit einem Scatterplot und mit sonst was für Diagrammen kann man da echt super viel aus diesem einen Datensatz super viel Informationen gewinnen.
Deswegen finde ich die so sexy. Du hast gerade wahnsinnig viele Fachbegriffe reingebracht.

[17:05] Daher, um nochmal kurz basic zu machen. Wenn ich das einführe in Teams, dann fange ich ganz stumpf, also meistens haben wir ein physisches Board, da einfach nur ganz ans Board rankommt, kommt das Datum dran.
Und wenn es bei dann hängt, kommt auch nochmal das Datum dran.
Und einmal im Monat setze ich mich dann hin und dann gucke ich, wie viel Zeit dazwischen vergangen ist bei all diesen Tickets.
Also so kann man es ganz simpel machen. Und du hast es schon erwähnt, Jira kann das, glaube ich, standardmäßig. Wenn nicht, kann man noch eine Automation reinklatschen.
Und so kenne ich das auch eher von anderen Tools.
Ich glaube, wenn man so Trello oder Monday verwendet, dann müsste man das, glaube ich, nochmal selbst als eigenes Feld hinzufügen. Jetzt sieht man das dann auch in der Datenbank, weil es ist ja auch nur ein Datensatz in der Datenbank.
Also finde ich cool und das finde ich doch ist schon mal eine handfeste Metrik, die man durchaus verwenden kann.

[17:51] Ich denke da an so Sachen, wie das die meisten Firmen ja schon wissen, wie gut ihre Projekte, ich weiß, wir stellen auf Produktentwicklung meist um, wie gut die eben laufen, von denen man hat das geplant.
Nehmen wir mal so einen Berliner Flughafen. Ich habe jetzt nicht die genauen Daten, aber man hat das geplant mit so einem Bauprojekt.
Es geht im Regelfall über zehn Jahre und am Ende hat es 20 Jahre gebraucht.
Ich weiß nicht, ob das jetzt korrekt ist von den Zahlen, aber gefühlt für mich ist das so.
Jeder kann dann in seinem Unternehmen die richtigen Zahlen nehmen und damit ist die Durchlaufzeit nicht bei zehn Jahren, sondern bei 20 Jahren.
Wenn man jetzt nochmal so ein Projekt starten würde und sich dann einen Agilisten reinholt, dann könnte der schon sagen mit, nee, nee.

[18:31] Diese Durchlaufzeit, die kriegen wir aber runter. Die ist dann nicht mehr bei 20 Jahren, sondern es wäre dann schon ein Riesengewinn, wenn die nur noch bei 19 Jahren ist.
Ich wette, wenn man das agil machen würde, dann würde man auch die 10 Jahre schaffen.
Und da könnte man ja schon mal eine Garantie draufpacken. Und ich glaube, so ist das auch in vielen Unternehmen, also auch Maschinenbau oder sowas, wenn man eine neue Maschine plant, dass das häufig über von der Chef hat diese Idee und gibt das halt rein in die Firma, bis dann es kommt am Ende die fertige Maschine raus, schon mal so drei bis fünf Jahre vergehen.

[19:02] Wenn klassisch gearbeitet wird.
Und da kann man durchaus meiner Meinung nach ran mit, okay, wenn man mich jetzt als Coach für ein Jahr oder für zwei Jahre reinholt zu Summe X, dann ist danach die Durchlaufzeit in deinem Unternehmen um 20 Prozent besser oder so. Ja, es ist natürlich schwierig.
Und da machen wir jetzt wieder so ein bisschen den Bogen zum Anfang.

[19:23] Wen interessiert eigentlich diese Durchlaufzeit oder diese Metrik?
Das wäre ja in erster Linie, würde ich ja als Agile Coach erst mal selber sicherstellen wollen, wenn ich verspreche, ich halbiere dir deine Durchlaufzeiten innerhalb von zwei Jahren, dass ich das auch wirklich kann.
Wenn ich jetzt überlege, bei Laufzeiten von Projekten von zwei, drei, vier Jahren, dann dauert es wahrscheinlich schon einiges an Zeit, einiges an Jahren, Jahrzehnten vielleicht, bis ich überhaupt diese Garantie geben mag.

[19:50] Ist natürlich vielleicht auch eine Frage von, wie risikobreudig man da ist.
Was würdest du denn sagen aus deiner bisherigen Erfahrung, wenn du die Velocity nimmst oder die Durchlaufzeit nimmst?
Was ist da für dich ein realistisches Ding an, wie viel steigt die Velocity, wie viel sinkt die Durchlaufzeit?
Es kommt immer darauf an, in welcher Phase das Team ist.
Also je weiter die halt schon sind, desto weniger Raum ist da quasi noch drin.

[20:17] Beispielsweise, wenn es ein Team in die Performingphase geschafft hat und das erlebe ich äußerst selten, dass ein Team wirklich in der Performingphase ist.
Und ich habe es schon erlebt und ich habe auch schon Teams gebaut, die da drin sind, also auch heute noch da drin sind über mehrere Jahre.
Da ist halt bei der Velocity ist da wenig Luft.
Bei der Durchlaufzeit ist aber meistens noch viel Luft, weil die Durchlaufzeit wird häufig vom Umfeld des Teams beeinflusst.
Also dass man da irgendwelche Zulieferungen braucht oder der Funnel am Anfang, dass der noch nicht korrekt gebaut ist oder dass man die abnehmende Stelle nicht betrachtet hat.
Also häufig sind ja in Konzernen Teams nach Fachlichkeit geschnitten.

[20:54] Häufig wirkt es auf mich nicht wie ein Team, sondern wie eine Ansammlung von Menschen, die zufällig das Gleiche tun, dann betrachtet man häufig nicht die Schnittstelle, also das, was danach kommt.
Du hast in unserem letzten Podcast sehr schön eben genau diesen Radio-Stream aufgemacht, mit okay, dann gibt es halt rechts und links dann auch Partner und schmeißt das einfach nur über den Zaun.
Sich dann damit zu beschäftigen, hat denn das überhaupt das richtige Format, damit die daran anknüpfende Abteilung jetzt damit noch besser weiterarbeiten kann. Dadurch kriegt man die Gesamtdurchlaufzeit eben runter.
In dem Team, wenn die in Performing-Phase sind, häufig nicht mehr.
Und da fängt dann eben genau dieses Agile-Coaching an, also dann so ein bisschen der Unterschied zwischen Scrum Master und Agile Coach.

[21:35] Jetzt entferne ich mich vom Team und betrachte das so ein bisschen organisationstechnisch.
Also daher glaube ich, sowohl die Velocity als auch die Durchlaufzeit an der Stelle ein bisschen schwieriger.
Doch wo wir beide, also ich nehme dich da jetzt mal mit rein, weil ich habe das Gefühl, es ist bei dir genauso, eher reingeholt werden, ist ja da, wo es nicht läuft.
Und die haben entweder, starten die jetzt gerade mit Agilität und haben wahrscheinlich noch gar keine Daten, keine Storypoints, keine Durchlaufszeiten und ähnliches.
Das kann man relativ schnell, zumindest die Durchlaufszeiten, dann erstmal ermitteln oder erstmal zwei Wochen spendieren für die Storypoints.
Das geht und das dann zu steigern, easy, das kriegen wir hin.
Dann gibt es eben diese Projekte und da werde ich meist dazu gerufen, dass der Karren völlig im Dreck gelandet ist. Da brennt die Hütte, es geht quasi gar nichts mehr, unglaublich hohe Fluktuationen und Ähnliches.
Und die sind nicht lieferfähig. Also sprich, die Durchlaufzeit, die ist in Richtung unendlich.
Und da ist es schon ein Riesenerfolg, einfach nur garantieren zu können mit… Es kommt was raus.
Wir liefern in einem… Ja genau, es kommt was raus und in einem halben Jahr ist was da.

[22:41] Und was, glaube ich, auch viele Unternehmen jetzt erst realisieren, ist, dass in Zukunft nahezu jedes Unternehmen irgendwie mit Software oder IT zu tun haben wird.
Egal, was sie herstellen, was sie tun und so weiter.
Je besser die IT im Hintergrund ist, desto besser läuft das.
Und meist haben sich die Unternehmen mit IT noch gar nicht beschäftigt.
Daher ist deren IT häufig nicht lieferfähig. Und da geht es wirklich um so Sachen wie, man hört ja häufig diese Gerüchte, dass die Sparkassen-Geldautomaten immer noch mit Windows 98 oder sowas laufen.
Was tierische Sicherheitslücken sind, weil halt die IT nicht in der Lage ist, da einen entsprechenden Rollout zu machen und die dahin überhaupt erstmal zu bekommen mit regelmäßig könnt ihr jetzt liefern, ist halt schon ein Riesengewinn.
Daher ist halt jetzt so mein zweiter Punkt, also nach Durchlaufzeiten kann man verbessern, überhaupt Lieferfähigkeit herstellen.
Ich kann mir gut vorstellen, dass es jeder ausreichend gut ausgebildete oder erfahrene Agilist schaffen sollte, in einem halben Jahr mit, egal was da für ein Projekt oder Team vorgesetzt wird, eine Lieferfähigkeit herzustellen.
Ich meine damit nicht dieses Endprodukt, was ursprünglich mal im Lastenheft festgehalten wurde, sondern ein Produkt rauszubringen, was dann vielleicht so monatlich dann nochmal verbessert werden kann oder sowas.

[23:55] Diesen Zustand zu erreichen. Ich glaube, das ist eine Garantie, die kann man ganz gut geben. Wenn ein Agilist sich damit unglaublich schwer tut, dann würde ich da schon mal ein bisschen nachfragen mit, woran liegt das?
Und da können gute Gründe rausbekommen aus entsprechender Erfahrung, dass der Agilist dann eben sagt, naja, in dem und dem Umfeld, da habe ich schon ein paar Projekte gemacht. Ich habe es im Automobilbau sehr häufig Werkzeuge.
Bis die ausgekühlt sind, dauert es sechs Monate.
Also ich gieße einmal dieses Werkzeug, damit es dann später in die Presse rein kann und bis es ausgekühlt ist, sechs Monate.

[24:27] Das ist halt so eine Zeit, darf man halt auf dem Schirm haben, wenn man so ein Projekt hat.
Und es gibt da andere Lösungen dafür, das zu lösen. Die meisten haben keinen Bock, sich damit zu beschäftigen, aber dafür ist man ja als Agilist da, um da neue Impulse reinzubringen. Ja, definitiv.
Ich denke, bei Lieferfähigkeit auch immer, du hast jetzt ein Hardware-Produkt quasi beschrieben und da hat man natürlich tatsächlich unter Umständen nochmal eine ganz andere Schallmauer als bei Software-Produkten.
Aber überhaupt tatsächlich Lieferfähigkeit und was mir auch häufig begegnet ist im Bereich der Software-Entwicklung, ist, dass das Produkt, also A, dass überhaupt gar kein fertiges Produkt am Ende von so einem Zyklus rausplumpst, weil man keinen Anwender hat.

[25:07] Das heißt, es gibt zwar theoretisch irgendwo irgendwelche Anwender, aber man macht sich nicht die Mühe, ein potenziell auslieferbares Produkt zu schaffen, weil man ja niemanden hat, der es wirklich benutzt.
Und das ist meiner Erfahrung nach der häufigste Gap. Das heißt, im Endeffekt ist es auch Lieferfähigkeit, aber eben auch tatsächlich zu sagen,

[25:27] okay, wir stellen jetzt diesen Kundenfeedback-Loop her. Weiß ich nicht, wie man das dann in schön nennt.
Lieferfähigkeit ist so ein einfacher Begriff. Ich liebe diese Metrik und ich habe sie am Anfang auch nicht geliebt, ich habe sie nicht gemocht.
Fand sie fürchterlich und mittlerweile liebe ich sie, ist dieses Weiterempfehlungs… Net Promoter Score.
Net Promoter Score, genau. Den zu erwägen und da kann man ja wirklich direkt mal Kundenumfrage, also wenn man seine Arbeit beginnt, einmal rausknallen.
Wir messen jetzt einmal Net Promoter Score. Wenn dann schon zurückkommt, wir haben keine Kunden, dann ist der halt bei Null.

[26:02] Dass wir den halt deutlich verbessern, dass der irgendwo so in Richtung 60, 70 Prozent auf jeden Fall kommt, kommt vielleicht sogar Richtung 80 oder dass man dann halt sagt, okay, es gibt nochmal zusätzlichen Bonus für den Agile Coach.
Wenn man über 70 kommt, dann je 10%-Stufen dann nochmal irgendwie einen Bonus.
Könnte man machen und ist auch da wieder, man kriegt dann was man misst. Ja, vorsichtig.
Kann dann sein, dass das dann nur ausgewählte Kunden dann plötzlich daran teilnehmen und so. Da darf man ein bisschen aufpassen.
Ich glaube, wenn man diese Lieferfähigkeit herstellt, kriegt man automatisch einen höheren Net Promoter Score.
Also das würde ich dann anderen weiterempfehlen, weil ein Produkt, was ich nie in der Hand habe oder was absolute Grütze dann jedes Mal ist, würde ich nicht weiterempfehlen.

[26:44] Ja, und überhaupt schon mal diesen Connect herzustellen, okay, wir können etwas ausliefern und das geht auch an die Kunden und wir kriegen von den Kunden Feedback, das ist überhaupt schon Gold wert.
Also tatsächlich bin ich gerade auch in einem Kontext unterwegs, wo mir am Anfang noch gesagt wird, ja, also wir müssten jetzt überhaupt mal an die Kunden ausliefern, das können wir halt jetzt eigentlich noch gar nicht.
Und wenn, dann wollen wir aber eigentlich auch nur so alle drei Monate reicht.

[27:10] Und jetzt gehen wir zum ersten Mal so ein bisschen an die Anwender ran und ich prophezeie dir, dass wir, sobald wir, wir müssen das technisch im Griff kriegen, dass Auslieferung für uns nicht mehr so eine Arbeit ist.
Aber wenn wir das haben, dann werden wir sprintweise releasen, weil jetzt schon die Kunden bei uns nachfragen, ja, könnt ihr das und das machen und so weiter. Und tatsächlich, das Team springt da ja drauf.
Also die freuen sich richtig, wenn sie Feedback kriegen.
Ich finde es erstaunlich, dass diese Gap einfach ganz oft nicht geschlossen ist.
Also das ist auch meine Erfahrung, vor allem in Richtung Design Thinking Projekte, wenn ich die betreue und dann die Menschen, die da im Design Thinking dann mit mir zusammenarbeiten, zu den Kunden halt hinschicke, um erstmal ein paar Kundenkliniken zu machen.
Weil beim Design Thinking kommt ja meist was ganz anderes raus, als ich ursprünglich gedacht habe, weil der Kunde was anderes braucht.
Und dass da jedes Mal dieses Feedback ist mit, boah, das war so toll und was die alles erzählt haben und wie die sich gefreut haben, dass da jemand ihnen überhaupt mal zuhört und ihre Probleme ernst nimmt und so. Und ja, ich stimme dir absolut zu.

[28:12] Warum haben viele Teams keinen Kontakt zu ihrem Kunden?
Aber da sind wir jetzt vielleicht, also wir haben uns ja über Velocity bewegt, dann zu den Flowmetriken, dann haben wir jetzt gesagt, okay.

[28:21] Überhaupt Lieferfähigkeit herstellen, dann halt sozusagen Net Promoter Score als Zufriedenheitsmaß.
Und da bin ich jetzt zu der Einheit gekommen, Zufriedenheit, also überhaupt Zufriedenheit messen.
Weil das ist ja ganz häufig, also ich kriege ganz viel, wenn ich irgendwo bin, positives Feedback, so, oh Lea, das ist so toll, dass du da bist.
Also auch wenn wir keine Metrik haben, mit der das gemessen wird, kriege ich positives Feedback. Da denke ich so, ja, ist nice.

[28:45] Dann frage ich mich, wie mache ich diese Zufriedenheit messbar?
Klar, der Net Promoter Score ist dann dafür das Produkt, aber kann ich als Agile Coach auch die Zufriedenheit meiner Kunden mit meiner Arbeit in irgendeiner Form messbar machen?
Außer einfach dumm hinzugehen, zu fragen, wie zufrieden auf einer Skala von 1 bis 10 kreuzt, bitte mal an. Das ist so ein bisschen mein Klemmer.
Passt doch super, weil wir haben im letzten Heldentreff, dank Felix Medam, also Gruß geht raus, sehr viel über einen Happiness-Index von Entwicklern gesprochen, weil die These ist, je zufriedener die Entwickler, desto besseren Code bekomme ich raus, desto bessere Produkte und so.
Die teile ich, nur die Messung selbst, die finde ich äußerst schwierig.
Ich habe ein paar Ideen dazu, allerdings ist keine wirklich gut, weil die ist von der Tagesform abhängig, was ich so an zufrieden…
Also das ist meine These.
Also bitte, bitte beweist mir das Gegenteil. Bitte, bitte, bitte.
Ich bin da echt gespannt drüber. Wenn man Happiness oder Zufriedenheit eben entsprechend messen kann und rate daher aktuell eher ein bisschen davon ab wegen der Tagesform und deshalb mag ich diesen, würdest du es weiterempfehlen?
Die Frage, mag ich mehr als dieses 1 bis 10, weil es eben tagesformabhängig ist.
Und ich kenne auch Unternehmen, die dann eben, wenn so eine Umfrage gemacht wird, dann eben zusätzlich plötzlich gibt es dann Obstkörbe oder sowas, dann austeilen. Ja, dadurch habe ich jetzt die Zufriedenheit nach oben gesteigert, aber das sagt ja gar nichts über mein Produkt aus.
Ich bin da so ein bisschen über einen längeren Zeitraum mit sehr vielen Messpunkten, könnte ich mir das gut vorstellen.

[30:11] Allerdings, wer hat schon Bock darauf, irgendwie fünfmal am Tag seine Zufriedenheit auszuprobieren?
Ich glaube auch sowas wie zum Beispiel Teamzufriedenheitsmetriken oder Kundenzufriedenheitsmetriken.
Ich glaube, man sollte die Frage immer mal stellen und vor allem, wenn da sehr negative Antworten rauskommen, dann ist das definitiv was zum Aufhorchen.
Aber zum Beispiel würde ich jetzt meine Bezahlung als Agile Coach davon abhängig machen wollen, ob der Kunde jetzt eine 7,5 oder eine 9,8 angehakt hat.
Weil genau wie du sagst, da ist unheimlich viel drin.

[30:42] Tagesform, wie bin ich geprimed vorher. Ich meine, ich kann halt auch einfach mal einen netten Plausch mit dir haben, bevor du die Bewertung machst und du bewertest mich ganz bestimmt nochmal einen Punkt besser oder so.
Einfach nur, weil wir nett gequatscht haben.
Von daher ist es halt einfach nicht, es sagt halt nicht wirklich, es sagt eher was über unsere zwischenmenschliche Beziehung als über meine Leistung als Agile Coach aus. Genau.
Und als Geschäftsführer würde ich mich dann halt auch fragen, wie viel mehr Geld habe ich jetzt dadurch in der Kasse? Ich kenne die Metrik, ich mag sie durchaus.
Also ich finde es ein cooles Feedback und gleichzeitig, das ist nichts,

[31:14] wo ich eine Garantie drauf packen würde, um das dem Geschäftsführer zu verkaufen.
Und wobei, wo war dann, du sagtest ja gerade, wie viel Geld habe ich dadurch mehr?
Dann werden wir jetzt eigentlich, sagen wir mal so bei klassischen KPIs, sowas wie Marge, Umsatz, Verkaufszahlen sozusagen, dass man einfach guckt.
Ich finde, das hängt ein bisschen davon ab, ob man die Metriken benutzen kann, ob wir wirklich mit Kunden arbeiten, die ein Produkt haben.
Also wenn ich jetzt bei einem Unternehmen arbeite, die eine App haben oder irgendwas mit einer Subscription, also was weiß ich, Video-Streaming-Dienst, da könnt ihr mir natürlich sagen, okay, ich komme bei euch rein und mein Ziel ist, dass ich euch als Produkt-Team coache und ich mache das und dann können wir gucken, der Promoter-Score steigt und eure Abo-Zahlen steigen und dann können wir da meine Bezahlung, meinen Bonus dranbringen.

[32:00] Aber was ist, wenn ich jetzt in so einem, sag ich mal, typischen Dienstleistungsteam bin?
So die interne IT, wie du vorhin sagtest, wo es ganz häufig krankt.
Die kriegen halt aus der Firmenstruktur irgendwie so Anfragen und Tickets reingekippt.
Die haben nicht so wirklich ein Produkt.

[32:16] Und trotzdem profitieren die halt von Agile Coaching. Also da wird es dann schon wieder schwierig, sowas zu messen. Du hast eine Idee.
Nein, genau, da habe ich nämlich was. Und das ist auch nur Zufall, weil ich mich im Rahmen unserer Menschen lesen Seminarreihe oder Kurzseminare damit ein bisschen beschäftigt hatte mit, okay, was kriegt man denn raus, wenn man jetzt so ein bisschen mit dem Metaprogramm der Menschen umgehen kann.
Ich sage immer, ich hatte plötzlich in der IT gelernt, dass es echt gut ist, Menschen wieder wie Menschen zu behandeln. Was meine ich damit?
Also ich hatte Burnout, weil zu viele Projekte und so und bin danach wiedergekommen und habe gesagt, jetzt arbeiten wir mal anders zusammen. Und ich hatte einfach nur angefangen mit so, meine Mitarbeitenden in den Projekten, die bekommen einfach mal bessere Stühle und sowas. Also nicht die quasi schon völlig kaputten und sowas, sondern bessere Stühle.
Und plötzlich ging die Motivation nach oben. Jetzt sind wir wieder bei der Happiness und dann ist ja Folge daraus, dass man dann glaubt und da bin ich auch mir ziemlich sicher, dass dann bessere Produkte rauskommen.
Jetzt der Punkt ist aber der, wenn ich die Menschen wieder wie Menschen behandle, kriege ich bessere Gesundheitsstände und weniger Fluktuation.
Und das ist so das, wo ich mich in dieser Menschenlesen-Reihe tatsächlich mit beschäftigt hatte.
Und da gibt es zwei gute Studien, also die werden jährlich aktualisiert.
Einmal die von LinkedIn, die sich mit Fluktuation beschäftigt.
Die hat zum Beispiel festgestellt, dass in IT-Berufen in Berlin die Fluktuation bei 25% liegt.
Das bedeutet, dass ein Viertel der Belegschaft jedes Jahr durchwechselt.

[33:46] Genau. Jetzt habe ich mich mit einigen Personalabteilungen darüber schon unterhalten und festgestellt, ich bin häufig in Konzernen unterwegs.
In den meisten Konzernen ist die Personalabteilung ein eigenes Profitcenter.
Also zwar als Kostenstelle eingestellt, aber eigentlich ein eigenes Profitcenter.
Also die müssen irgendwie Gewinne erwirtschaften.
Gewinne erwirtschaften, indem die für die anderen Abteilungen arbeiten.
Je mehr Fluktuation da ist, desto mehr kriegen die zu arbeiten und zu tun.
Daher ist das durchaus für die Personalabteilung ein Gewinn, wenn die hohe Fluktuation ist, weil ich habe mich all die Jahre gefragt, warum kümmern die sich nicht darum?
Das ist so offensichtlich, weil ich habe in meinem Projekt unglaublich viel Arbeit damit.
Ich muss neue Leute suchen, ich muss Bewerbungsgespräche führen, ich muss sie dann einarbeiten.
Es dauert locker, also das sind ja komplexe Projekte, die ich mit den Teams bearbeite, locker sechs Monate, bis sie auf der gleichen Outcome-Stufe sind, wie die Menschen, die gegangen sind.
Und die Menschen, die gegangen sind die letzten Monate, sind ja dann meist auch nicht mehr so super arbeitsfähig. Also außer ich hab die weggentwickelt.
Das ist eigentlich eine andere Position, eine höhere Position.
Bei mir ist es häufig, dass die dann irgendwie auch Scrum Master oder Agile Coach oder ähnliches werden wollen.
Das ist dann cool. Die gehen mit einem Lächeln und die leisten am Ende nochmal richtig.
Nur die, die kündigen, und viele kündigen ja nicht das Unternehmen, sondern die Chefs, die gehen nicht als High Performer.
Nee, definitiv nicht. Im Regelfall.

[35:08] Daher 25% Fluktuation. Das ist so geschäftsschädigend.
Übel. Übel. Das ist nur in Berlin so. In anderen Regionen ist das nicht so schlimm.
Das ist die LinkedIn-Studio von 2018.
Die verlinke ich, wenn ich nochmal einen Link dazu finde. Da glaube ich, da können wir richtig viel leisten. Und du hast jetzt gerade so eine interne IT-Abteilung angesprochen.

[35:27] Der Service wird natürlich deutlich besser, wenn ich da nicht jede Woche einen anderen Menschen habe. In meinem anderen Job habe ich sehr viel mit depotführenden Stellen zu tun.
Ich ziehe da Millionen von Kundengeldern ab, wenn der Support nicht ordentlich läuft, weil ich da halt wirklich jedes Mal irgendjemand Neues dran habe und gerade wenn es um Geld geht, ist es halt schädlich, wenn so eine Ticketbearbeitung irgendwie drei Monate oder sowas braucht, weil ich jedes Mal dem neuen Bearbeiter wieder alles erzählen muss, bis das mal einer verstanden hat.
Daher, niedrige Fluktuation hilft da.
Und da kann man, glaube ich, auch gut eine Zahl dran machen, dass die Fluktuation irgendwie entweder auf 10 oder 15 Prozent sinkt oder um 20 Prozent oder 30 oder sowas.
Das kann man, glaube ich, sehr gut. Und die zweite Statistik, die ich ganz gerne heranziehe, die wird sogar häufiger aktualisiert als die LinkedIn-Studie.
Deshalb habe ich jetzt die von 2018 zitiert und nicht irgendwie von 2022.

[36:20] Ist der AOK-Vielzeitenreport.
Die AOK als Gesundheitskasse, die hat natürlich auch viele Daten von Mitgliedern und so weiter. Die geben den jährlich raus.
Und der jetzige, der superaktuelle, also aus 2023, ich glaube im Oktober ist der rausgekommen, betrachtet immer das letzte Jahr.
Die dürfen ihre Daten ja auch immer erstmal auswerten. Die haben im Jahr 2022 festgestellt, dass die Vielzeiten im Schnitt so bei 16,2 Tagen liegen.
Pro Person, pro Jahr. Also drei Wochen.

[36:50] Drei Wochen Fehlzeiten im Schnitt, das ist schon viel.
Und dann haben sie sich Unternehmen angeschaut, wo die Mitarbeitenden sagen, das sei ein fortschrittlicheres Unternehmen. Jetzt bin ich gespannt.
Fortschrittlicher würde ich mal sagen, agil. Ich weiß es anmaßend, das jetzt gleichzusetzen. Das stimmt auch mit Sicherheit nicht so richtig.
Die kommen auf 11,6 Tage. Okay, das ist schon ein Unterschied.
Genau, das sind fünf Arbeitstage mehr pro Mitarbeitenden.

[37:19] Und das ist doch logisch, dass sie dann auch mehr leisten können in dieser Zeit.
Also das waren so die Effekte, die ich auch, als ich umgestellt hatte in meinen Projekten damals, erkannt hatte mit, ja, ich habe die Leute einfach mehr zur Verfügung.
Natürlich reißen die in meinen Projekten auch mehr, einfach weil ich sie besser behandelt habe und weil sie eben auch mehr mitbestimmen konnten, weil sie selbst organisierter waren und, und, und.

[37:41] Und ich glaube, auch da kommt man ran. Jetzt habe ich natürlich zusätzlich festgestellt, daher der LinkedIn-Post mit, naja, es kauft ja jetzt aber auch niemand einen Agile-Coach ein mit, naja, mein Gesundheitsstand, der ist nicht so gut, wie ich ihn ganz gerne haben möchte, da hole ich mir mal einen Agile-Coach rein.
Da würde man sich wahrscheinlich auch eher jemand anderes reinholen.
Aber das wäre für mich so eine Metrik, die wahrscheinlich kaum einer auf dem Schirm hat, wo wir durchaus Garantien geben können und was gar nicht so offensichtlich ist, weil es ein Nebenprodukt unserer Arbeit ist.
Allerdings messbar und wo halt Zahlen vorliegen.
Achso, was jetzt noch dazu kommt, ist, 22 haben die festgestellt, dass die Anzahl der psychischen Erkrankungen um 48% gestiegen ist und diese Erkrankungen führen im Schnitt zu 29,6 Fehltagen je Fall, also einen Monat.
Und ich glaube, dass die Menschen in den agilen Projekten, vor allem wenn jemand als Methodiker da ist, der das begleitet, stabiler aufgestellt sind.

[38:40] Resilienter sind, eben weil wir eben genau mit diesen Themen auch arbeiten und daher eben nicht ausfallen.
Und die fallen uns ja in den Projekten dann auch aus, wenn es gerade richtig brennt, wenn das Projekt unter Druck steht und wo ich diesen Ausfall am allerwenigsten brauchen kann.
Also ich kann ihn natürlich an keiner Stelle gebrauchen, aber dort brauche ich ihn am allerwenigsten, weil ich irgendwie kurz vor einer Deadline oder sowas bin.
Dann 30 Tage auf jemanden verzichten zu müssen, da können wir gut ran und das kriegen wir auf ein stabileres Level und gleichzeitig verbindet man ja Agilität eher nur mit diesem Theorie und was man sieht.

[39:14] Ich finde es ganz spannend, weil du hast jetzt ganz viele verschiedene Metriken genannt, die man benutzen kann, aber auch wieder denke ich, das ist abhängig davon, was für ein, also ich denke jetzt als selbstständiger Coach, was für ein Produkt biete ich denn an, ist wieder, also ich kann halt zum Beispiel Fluktuationen, ist Fluktuationen, nicht für jedes Produkt geeignet. Und ich bin gestern bei meinen Überlegungen, habe ich mal überlegt, wenn ich als Agile Coach keine Metrik habe, mit der ich es messen kann, habe ich dann auch vielleicht gar kein Produkt.
Also bin ich nicht sicher, das ist vielleicht ein bisschen eine starre These, aber ich habe halt auch überlegt, weil das ist so mein Ding, dass ich jetzt überlege, ich bin Agile Coach, ich biete viele verschiedene Dinge an, von Mentoring über irgendwie, ich füge euch agile Methoden an, ich verbessere euch mit euch agile Methoden.
Aber das ist jetzt kein Produkt. Also das ist sozusagen, du kannst mich einkaufen, das ist gut, funktioniert gut, aber das ist kein Produkt.
Wenn ich jetzt als Selbstständiger ein Produkt rausbringe, wo ich dann auch sage, ich gebe euch eine Garantie.
Wenn ich keine Metrik habe, habe ich dann vielleicht wirklich auch einfach kein Produkt.

[40:14] Ja, das ist wirklich ein guter Punkt. Da muss er jetzt erstmal drüber nachdenken.
Ich habe direkt daran gedacht, dass ich es halt von vielen Akademien, also internen Akademien von Unternehmen halt so kenne, dass die als Metrik halt nehmen, wie viele Menschen die Durchschulung durchgeschleust haben.
100 Scrum Master pro Jahr ausgebildet.
Ist eine Metrik, kann ich messen, ist ein Produkt, ein Scrum Master Training ist da dran, wahrscheinlich auch noch mit Zertifizierung bei einer der gängigen Akademie, also Zertifizierungsstellen, nicht Akademie.
Ich persönlich, also ich finde die Trainings gut und es ist eine super gute Grundlage, nur ich habe dadurch mein Unternehmen, habe ich da noch nichts verändert.
Das ist immer so mein Punkt. Wir haben bei der Snipp Academy einen Wert, der heißt Nachhaltigkeit und damit meinen wir, dass sich danach was verändert und nicht zwei Wochen später alles beim selben ist, wie es vorher war.
Aber da hängt ein Produkt dran.
Das ist ein Produkt, das Training, das kann ich messen, wie viele durchgeführt, wie viele Teilnehmende da durch und sowas. Ja, ja, auf der Reise war ich gerade.
Dann hast du recht. Wenn ich einfach nur irgendwie berate und das ist mir auch schon passiert, dass ich einfach nur für ein paar Stunden mit jetzt, jetzt coache mal Product Ownerinnen oder sowas eingekauft wurde.

[41:19] Da schon viel drin gemacht habe, aber gar nicht genau wusste, wo wollen wir denn jetzt hin?
Da wäre Lieferfähigkeit dran zu packen oder ähnliches wäre besser gewesen.
Schon hätte ich wieder ein Produkt gehabt. Also ich stimme dir zu.
Habe ich keine Metrik, habe ich kein Produkt.

[41:34] Finde ich eine steile These und klingt für mich jetzt erstmal super schlüssig.
Auch die Frage, eine Metrik oder mehrere?
Ich finde es immer so ein bisschen, du hast ja mehrfach gesagt, du bekommst, was du misst, so ungefähr.
Also wenn ich Storypoints messe und das mehr Storypoints bedeutet, deutet gut, dann gibt es sehr viele Wege, auf die mehr Storypoints entstehen können und meistens ist es nicht der Weg, der mir weiterhilft.
Deswegen einfach dieses Risiko, dass du durch eine Metrik sozusagen einfach nur ein Verhalten provozierst, dass dieses Incentive oder sozusagen das einfach nur eine gute Metrik produziert, aber nicht das gewünschte Outcome, ist ja, dass ich mehrere Metriken habe, also dass ich mehr als eine Sache betrachte.
Für das Unternehmen. Für das Unternehmen finde ich das wichtig.
Pro Person würde ich schon wieder schwieriger finden, denn du hast im Vorgespräch auch mit mir schon ein bisschen über OKRs und sowas gesprochen.

[42:23] Auch da ist es häufig, wenn ich so eine Und-Verknüpfung in den OKRs habe und ich habe eine Sache erledigt, ist jetzt das Key Result erfüllt oder nicht?
Das ist dann immer so, wo ich mir, und so denke ich jetzt gerade auch bei den Metriken, also bestimmt ist das auch in manchen Fällen, also das ist ja alles sehr individuell, sinnvoll dann irgendwie vier, fünf Metriken dran zu haben.
Ich denke jetzt gerade an Joe Justice, wie er damals Wikispeed aufgebaut hatte, als die von Scrum.org eingekauft wurden.
Und mag dieses so ein bisschen die KPIs gegeneinander laufen zu lassen.
Wir haben ja mit Scrum diese drei Rollen.

[42:57] Entwicklerin, Scrum Masterin und Product Ownerin. Und der hat da bei Wikispeed die KPIs draufgepackt.
Aufgabe von der Scrum Masterin ist, mehr Story Points zu schaffen.

[43:08] Wo wir uns am Anfang unterhalten haben, ist vielleicht nicht so das Sinnvollste.
Dagegen laufend hat er aber bei der Product Ownerin draufgepackt, es muss mehr Value je Storypoint erzeugt werden.
Damit habe ich gegenläufig dieses, okay, die eine Person will mehr Storypoints schaffen, die andere Person möchte aber quasi weniger Storypoints, weil dann ist ja automatisch mehr Value dann drin in diesem Erledigten.
Und bei den Entwicklerinnen hat er draufgepackt, dass es weniger Fehlertickets in der Produktiv gibt und hat dann da Incentives draufgepackt.
Und das fand ich eigentlich ganz cool, weil natürlich dann haben die Entwicklerinnen auch mehr Ansporn, der Product Ownerin zu sagen, sagen, wir müssen hier mal technische Schulden abbauen und dies und das, weil weniger Störungen die dann haben.
Ich finde das Konstrukt gruselig und gut gleichzeitig.
Ja, das höre ich mich auch davor. Ich finde es gruselig, weil wenn ich die drei verschiedenen Rollen unterschiedlich inzentiviere, dann arbeiten die potenziell gegeneinander.
Und vor allem je nach Machtposition kommt dann der ein oder andere, kann halt seine Metrik nicht verbessern, weil er einfach nicht in der Machtposition ist, aber das ist vielleicht noch was anderes.
Aber tatsächlich, wenn man dem Team diese drei Metriken gibt, Leute, das sind eure drei Metriken und die sollen alle irgendwie steigen.
Gut, vielleicht nicht unendlich steigen. Wir waren ja vorhin dabei.

[44:25] Velocity steigt halt nicht unendlich und ich behaupte auch keine Metrik steigt unendlich.
Also im Sinne von, dass der Zuwachs immer mehr wird.
Also deswegen, da finde ich halt so ein Dreigestirn aus Metriken vielleicht für das gesamte Team oder die Abteilung oder was auch immer, finde ich ganz gut, weil du halt einfach die Sache aus mehr als einer Dimension betrachtest.
Genau dieses theoretisch, wenn es heißt, arbeitet mehr Tickets ab, also ich möchte gerne schnellere Durchlaufzeiten und damit einen höheren Durchsatz.
Ja klar, kriege ich hin, indem wir totalen Rotz programmieren und das, was am Ende rauskommt, tut nichts.
Und dann kann man halt als Gegenmetrik sagen, okay, wir gucken halt auch, wie viele Fehlerrückläufe haben wir und damit haben wir das ausgehebelt, dass wir sozusagen die eine Metrik optimieren auf Kosten von einer anderen.
Und deswegen, weil ich mir nämlich genau das gedacht habe, so eine einzelne Metrik, das schreit immer nach Game Me.
Ich mag das, also wenn man mehrere Metriken hat, die ins Team zu geben und dann zu sagen, okay, ihr seid ja gemeinsam ein Team, das dann so zu machen,

[45:17] finde ich gut, finde ich richtig gut. Das passt ja auch gut zu dem Scrum-Gedanken.
Jetzt werde ich ja häufig allerdings nicht als, na doch, ich jetzt in meinem Fall schon als Team eingekauft, du jetzt vielleicht aber nicht.
Würdest du dich dann auf all diese drei Metriken einlassen? Ja, gute Frage.

[45:31] Schon irgendwie, ich glaube, ja. Das, was man halt bedenken muss, ist, wie ich eben schon sagte, keine Metrik wächst unbegrenzt, also sozusagen im Sinne von der Zuwachs von Mehrwert.
Also ich kann zwar immer Mehrwert schaffen, aber die Steigerung von wie viel Mehrwert ich in einer Zeit schaffen kann, das kann halt nicht unendlich sein.
Ich glaube, das muss irgendwie immer abgebildet sein. Und auch, dass man sagt, wenn ich halt so gegenläufige Metriken habe wie die dreien, dass die alle drei irgendwie steil wachsen und nur dann kriege ich mein Geld.
Das könnte halt jetzt auch nicht Sinn der Sache sein, weil irgendwo es ist halt dann ein Abwägen.

[46:04] Also wir müssen, um nicht die Fehlertickets zu haben, müssen wir halt eben an anderer Stelle eben langsamer werden.
Ich mag das allerdings für den Auftrag des Agile Coaches, denn dadurch habe ich automatisch mit mehr als einer Person zu tun, um an all diesen Metriken zu schrauben.
Es wird einfach etwas globaler betrachtet. Ich finde das schon, jetzt wo ich mehr darüber nachdenke, finde ich das schon ganz cool.
Das habe ich bis jetzt noch nicht so gemacht, aber ich glaube, ich würde zukünftig auch immer die Frage in meiner Auftragsklärung mit aufnehmen, wie machen wir denn, da ist ein Fortschritt konkret messbar.
Ich bin tatsächlich gespannt, ob ich da vernünftige Antworten mit meinen Kunden erarbeitet bekomme.
Denn häufig ist es ja so, dass die Leute selbst, deswegen finde ich das mit den Metrikenarbeiten auch schwierig, weil Kunden häufig selbst gar nicht so genau wissen, was eigentlich das Problem ist.
Also die merken, irgendwas ist nicht so richtig okay und dann wollen sie, dass du Scrum mit ihnen machst oder dass du ihr Scrum besser machst, damit es irgendwie besser wird.
Ich glaube, dass es sich lohnt, reinzugehen und zu fragen, ja, was wird denn mehr oder was wird denn weniger?

[47:03] Und das ist tatsächlich was, was ich sehr erfolgreich jetzt eingesetzt habe beim OKRs erstellen.
Also für die Key Results diese Frage, wenn wir in Richtung Objective.

[47:14] Uns bewegen, was wird denn mehr und was wird weniger, was steigt oder was sinkt an Metrik.
Und damit, also ich glaube, das kann man sehr, sehr gut benutzen.
Nicht mal, um vertraglich was festzulegen, sondern einfach, um eine gute Auftragsklärung zu machen.
Ich habe jetzt auch ein bisschen gebraucht, um zu diesem Punkt zu kommen, um festzustellen, dass das wichtig ist.
Weil ansonsten bin ich irgendwo drin, tue Dinge, die ich für richtig halte und die anderen auch alle für richtig halten.
Und gleichzeitig ist es dann häufig nicht das, was die Auftraggeberin eigentlich erwartet hatte.

[47:44] Auch weil es nicht so klar formuliert wurde. Und genau wir sollten ja die sein, die das dann wiederum rauskitzeln.
Denn wir kommen ja genau aus diesem Bereich, wo wir sagen, ja, wir können am Anfang noch nicht so genau definieren, was am Ende rauskommt.
Deshalb iteratives Vorgehen und blub, blub, blub.
Daher lasst uns mehr mit unseren Kunden dann auch sprechen.
Was könnte es sein und das dann auch regelmäßig anzupassen. Deshalb sagen wir ja auch immer, der Auftrag ist erledigt, wenn er auch erledigt ist.
Also wir müssen ja nicht auf Krampf immer, wenn wir gesagt haben, wir glauben, es sind zwei Jahre und wir sind nach einem Jahr fertig, dann sind wir nach einem Jahr fertig, dann ist der Auftrag erledigt.
Ja, genau. Also finde ich auch super. Vor allem, wenn man das Ergebnis einfach erreicht hat, dann muss man nicht weiter dran rumdoktern.

[48:24] Lass uns mal gemeinsam nochmal eine Zusammenfassung probieren.
Nein, wir probieren hier nicht, wir machen auch wirklich.
Also jetzt kommt hier unsere Zusammenfassung, an was wir uns alles noch aus unserem tollen Gespräch hier erinnern können.
Also wir sind eingestiegen mit dem Thema, okay, was kann ich denn hier überhaupt als Agilist, wenn ich irgendwo reingehe, als Metrik reingeben?

[48:45] Daran möchte ich gemessen werden. Das soll am Ende besser werden.
Wir sind, du hast zwischendrin schon mal gut zusammengefasst, darüber vorbeigekommen.
Story Points fällt einem als erstes ein, dann Velocity, dann sind wir auf den Flow gegangen, auf die Durchlaufszeiten.
Da könnte man auch noch auf den Takt draufgehen und so weiter.
Also da gibt es gerade aus dem Kanban noch relativ viele Sachen.
Dann sind wir so ein bisschen in die, naja, was daneben noch an Zahlen existiert, Welt abgedriftet.
Also in Richtung Motivation, Happiness.

[49:16] Net Promoter Score, in Richtung Gesundheitsstand und Fluktuation.
Das ist so das, was ich jetzt so habe. Bei mir ist jetzt auch hängen geblieben, genau so unsere abschließende Diskussion mit dem, dass vielleicht eine Metrik alleine es nicht tut und dass wir insgesamt festgestellt haben, ich glaube messen ist schwierig, also so was messe ich überhaupt, wie messe ich das, aber dass es einen unheimlichen Mehrwert bietet darüber zu reden und nachzudenken, also sowohl für sich als auch mit den Kunden zusammen.
Und ich fand deinen Satz richtig toll von wegen, wer keine Metrik hat, hat kein Produkt.

[49:56] Genau, das ist ja so ein bisschen, was wir den Einkäufern auch an die Hand geben wollen. Wie kann ich die Guten von den nicht so guten Agile Coaches unterscheiden?
Da vielleicht dann auch zu sagen, okay, wenn du dich auf so eine Metrik nicht einlassen kannst oder mir vielleicht auch keine liefern kannst, dann ist der wahrscheinlich nicht so gut wie jemand, der das kann.
Wie auch immer die Metrik aussieht, die wird super individuell sein.
Die Metrik muss man sich aber auch angucken.
Also wenn da jemand ist und der sagt, ich verdoppel dir deine Story Points, das ist glaube ich der, den würde ich definitiv nicht empfehlen. Ja, guter Punkt.
Diesen Kanal, damit ihr auch das nächste Mal informiert werdet, wenn wieder genau so ein Thema besprochen wird.
Damit wünsche ich eine tolle Woche. Bis bald. Ciao.