159 Erfolgsgarantie

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.


 


 


The post 159 Erfolgsgarantie appeared first on Znipcast - für
gute Zusammenarbeit | Agile, Scrum, KanBan, Psychologie,
Teamentwicklung und NLP | Podcast der Znip Academy.