Znipcast - für gute Zusammenarbeit | Agile, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy

Technische Schulden in der agilen Softwareentwicklung – Warum sie uns alle betreffen und wie wir sie managen können Einleitung In dieser Folge unseres Podcasts tauchen wir tief in das Thema Technische Schulden ein. Wir erklären, warum Technische Schulden kein reines IT-Thema sind, sondern nachhaltige Auswirkungen auf die gesamte Organisation haben. Unser Ziel: Bewusstsein schaffen, wie technische Schulden entstehen, warum sie langfristig schaden und vor allem, wie wir sie frühzeitig erkennen und aktive Gegenmaßnahmen ergreifen können. Die Folge wurde im April 2024 aufgenommen. Links Unser MeetUp: https://znip.academy/meetup Die Folge mit Lennart: https://youtu.be/1HXpSGRjRqM Agile Arround the Wro(l)d: https://open.spotify.com/show/4ik0kM1ngFvz3SVzKHs00Z Scrum Master Folge: https://www.youtube.com/watch?v=d-OAXCYHr5I Heldentreff: https://znip.academy/held Psychologische Sicherheit: https://znip.academy/ps hybride Arbeit: https://znip.academy/fa Was sind technische Schulden? Technische Schulden sind metaphorisch zu verstehen: Es ist eine Art Kredit, den man bei der Codequalität, der Architektur oder bei der Infrastruktur aufnimmt, um kurzfristig schneller voranzukommen. Diese „Schulden“ entstehen beispielsweise durch unsauberen Code, provisorische Lösungen oder verzögerte Framework- und Bibliotheks-Updates. Unsauberer Code: Schnell implementierte Funktionen, die nur funktionierend, aber nicht wartbar oder erweiterbar sind. Aufgeschobene Updates: Bibliotheken, Frameworks oder Infrastruktur-Komponenten, die nicht rechtzeitig gepflegt oder ersetzt werden. Nutzererlebnis: Schlechte Usability durch unübersichtliche Interfaces, die durch nachträgliches Dranklatschen von Funktionen entstehen. Provisorien im Alltag: Ähnlich wie bei handwerklichen Reparaturen (z.B. provisorische Kabel oder Beleuchtungen) – es funktioniert, aber es ist nicht nachhaltig und verursacht langfristige Probleme. Warum sind technische Schulden problematisch? Langfristig führen nicht kontrollierte technische Schulden zu immer größeren Problemen: Verschlechterte Wartbarkeit: Der Code wird undurchsichtig, Fehlerpotenzial steigt. Verzögerte Releases: Mehrere Sprints werden nur noch für Aufräumarbeiten und Bugfixes verwendet. Innovationshemmnis: Neue Features lassen sich kaum noch einbauen, weil die Infrastruktur oder der Codeblock zu komplex sind. Wirtschaftliche Nachteile: Hohe Kosten für Refactoring, längere Downtimes oder sogar Systemausfälle. Dabei vergessen viele, dass technische Schulden auch eine Investition sind, die sich auszahlen, wenn sie richtig eingesetzt wird. Frühe, kleine Maßnahmen können langfristig enorme Vorteile bringen. Wie geht man mit technischen Schulden um? Es gibt verschiedene Strategien, um technische Schulden aktiv zu managen und abzubauen: Refactoring Die wichtigste Methode: Schrittweise den Code verbessern oder bei Bedarf komplett neu schreiben. Dabei sollte man regelmäßig „aufräumen“ – etwa durch Refactoring-Sprints oder kontinuierliche Code-Qualitätssicherung. Das Ziel: stabilen, wartbaren Code schaffen, der zukünftige Erweiterungen erleichtert. Automatisierte Tests Ein essenzielles Werkzeug, um Risiken beim Refactoring zu minimieren. Automatisierte Regressionstests liefern schnelle Rückmeldung, ob Änderungen funktionieren und bestehende Funktionalität erhalten bleibt. So kann man mit geringem Risiko regelmäßig Updates, Framework- und Bibliotheks-Updates durchführen. Proaktive Planung und technische Investments Framework- und Library-Updates sowie Infrastruktur-Verbesserungen sollten als regulärer Bestandteil des Entwicklungsprozesses geplant werden – ähnlich wie ein Auto regelmäßig gewartet wird. Das spart später immense Ressourcen und verhindert plötzliche Systemprobleme. Slack-Time und technische Rücklagen Ein bewährtes Prinzip ist, in den Sprint-Planungen explizit Zeit für Wartung, Refactoring und Weiterbildung zu reservieren. Das schafft Raum für nachhaltige Verbesserungen und verhindert, dass die Schulden sich ungehemmt anhäufen. Kontinuierliche Weiterbildung & Wissensaustausch Entwickler*innen sollten sich regelmäßig weiter qualifizieren, um auf dem neuesten Stand zu bleiben. Das reduziert die Gefahr, mit veralteter Technik zu arbeiten und technische Schulden zu ignorieren. Stakeholder-Management & Kommunikation Produkt-Owner*innen sollten die Bedeutung technischer Schulden klar kommunizieren. Denn oft wird kurzfristiger Business-Value vorgezogen, während langfristige Konsequenzen unterschätzt werden. Hier gilt: Transparenz schafft Verständnis für notwendige Investitionen in Wartung und Qualität. Frameworks und Rollen für das Management technischer Schulden In agilen Frameworks wie SAFe, Scrum oder Kanban gibt es spezielle Mechanismen, um technische Schulden zu steuern: Scrum & Sprints: Planung von sogenannten Technik-Sprints oder explizit reservierte Backlog-Punkte für Wartung. SAFe & PI-Sprints: Eine Woche ist unverplant und kann von den Teams für technische Verbesserungen eingesetzt werden XP & Refactoring: Refactoring ist strenger Bestandteil von eXtreme Programming   Get shit done, Janina & Henry Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern. Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann buch uns Agile Master Ausbildung, damit Du und Dein Unternehmen zur Höchstleistungsmaschine werden! Flexible / Hybride Arbeit richtig gestalten. Connecte dich gerne hier mit uns: LinkedIn Instagram YouTube Facebook Znip Academy, Deine Akademie für Agilität und Scrum The post 161 Technische Schulden appeared first on Znipcast - für gute Zusammenarbeit | Agile, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy.

Warum ist Psychologische Sicherheit fürs HomeOffice wichtig? Es freut mich, dass du dich für das Thema psychologische Sicherheit und Homeoffice interessierst. Das ist in der Tat ein sehr aktuelles und wichtiges Thema, besonders in der heutigen Arbeitswelt. Unser EMPOWER. MeetUp zu Psychologischer Sicherheit: https://znip.academy/meetup Diese Folge wurde am 09.02.2025 aufgenommen. Links Agile Master Ausbildung: https://znip.academy/agile Menschen lesen (Metaprogramme): https://znip.academy/mk LEGO SERIOUS PLAY: https://znip.academy/lsp Resilienz: https://znip.academy/resilienz Konferenz-Meetup: https://znip.academy/meetup Business Rauhnächte: https://znip.academy/rauh Rauhnachtsjournal: https://znip.academy/rauh-buch Heldentreff: https://znip.academy/held Weiter mit Psychologischer Sicherheit Psychologische Sicherheit ist entscheidend, um im Homeoffice effektiv arbeiten zu können. Sie ermöglicht es den Mitarbeitenden, sich sicher und wertgeschätzt zu fühlen, was wiederum ihre Kreativität und Produktivität steigert. Wenn Mitarbeitende das Gefühl haben, dass ihre Meinungen und Ideen gehört werden, sind sie eher bereit, sich aktiv einzubringen und auch Risiken einzugehen, was zu besseren Ergebnissen führt. Ein zentraler Punkt ist, dass Führungskräfte und Teams ihre eigenen Glaubenssätze über Homeoffice hinterfragen sollten. Oft gibt es Vorurteile, wie zum Beispiel die Annahme, dass Mitarbeitende im Homeoffice weniger produktiv sind. Solche Überzeugungen können die psychologische Sicherheit beeinträchtigen. Es ist wichtig, eine Kultur zu schaffen, in der Vertrauen herrscht und Mitarbeitende sich trauen, ihre Gedanken und Bedenken zu äußern. Um psychologische Sicherheit im Homeoffice zu fördern, können verschiedene Maßnahmen ergriffen werden, wie regelmäßige Reflexionen im Team, offene Gespräche über Bedürfnisse und Ängste sowie die Etablierung von aktiven Meeting-Formaten, die alle einbeziehen. Auch das Einholen von Feedback und das Anbieten von Unterstützung bei Konflikten sind wichtige Schritte. Zusammengefasst: Psychologische Sicherheit ist nicht nur für die individuelle Zufriedenheit wichtig, sondern auch für die gesamte Teamdynamik und letztlich für den Erfolg des Unternehmens. Wenn du mehr darüber erfahren möchtest oder spezifische Fragen hast, stehe ich dir gerne zur Verfügung! Get shit done, Janina & Henry Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern. Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann buch uns Agile Master Ausbildung, damit Du und Dein Unternehmen zur Höchstleistungsmaschine werden! In der Podcastfolge erwähnte Folgen zur Vertiefung: Führungskräfte – Leadership Daily Connecte dich gerne hier mit uns: LinkedIn Instagram YouTube Facebook Znip Academy, Deine Akademie für Agilität und Scrum The post 162 Psychologische Sicherheit fürs HomeOffice appeared first on Znipcast - für gute Zusammenarbeit | Agile, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy.

3 Jahre Znipcast 3 Jahre Znipcast und auch noch verspätet! Wir hatten eine Babypause und sind jetzt wieder da! Von unseren tollen Erlebnissen in der Zwischenzeit möchten wir euch in dieser Folge berichten. Übrigens in der nächsten Folge spreche ich mit Lennart über Technische Schuld.   Diese Folge auf YouTube: https://youtu.be/Vzr2-BkYMPs Links Agile Master Ausbildung: https://znip.academy/agile Menschen lesen (Metaprogramme): https://znip.academy/mk LEGO SERIOUS PLAY: https://znip.academy/lsp Resilienz: https://znip.academy/resilienz Konferenz-Meetup: https://znip.academy/meetup Business Rauhnächte: https://znip.academy/rauh Rauhnachtsjournal: https://znip.academy/rauh-buch Menschen leiten: https://znip.academy/ml Heldentreff: https://znip.academy/held Mind.set: https://znip.academy/mind.set Leadership Stars: https://znip.academy/leadershipstars Teamworks Plus: https://znip.academy/teamworks Karlie Muehlbach: https://znip.academy/karliemuehlbach Katja Schaefer: https://znip.academy/katjaschaefer Backlog Folge Stakeholder Folge SAFe Folge Leadership Folge Jammer Folge Agile Master Folge Agile Coach Folge Vertrauen Folge letzte Folge mit Lea Lindemann – Erfolgsgarantie Beide wieder da Ja, wir waren eine ganze Weile weg. She’s back. Er ist wieder da. Genau. Zu zweit sind wir wieder da. Ich weiß nicht, ob wir diese Folge einfach „Das Baby is da!“ nennen und es dann quasi Hazel und Carolin Kebekus und sowas gleich machen. Unser Baby ist schon ein bisschen größer, aber hey. Euch ist aufgefallen, wir waren lange weg. Wir haben jetzt fast ein Jahr Pause gemacht. Das hier ist nicht die Drei-Jahres-Folge. Die wäre letztes Jahr im Sommer gewesen. Und kommt jetzt dieses Jahr im Sommer zusammen mit der Vier-Jahres-Folge. Unser Backlog hat sich ein bisschen geändert. Wir haben irgendwann festgestellt, unsere Prioritäten haben sich geändert. Unsere Tochter ist noch ganz, ganz klein gewesen. Auf den letzten gemeinsamen Folgen kann man sie noch sehen. Und letztes Jahr im Juni haben wir dann irgendwann die Reißleine gezogen und gesagt, es gibt einfach wichtigere Dinge im Leben, haben den Podcast ein Stück weit sein lassen. Wie im Agilen darf man auf Veränderungen der Umwelt reagieren. Stakeholder hat sich geändert, Prioritäten haben sich verschoben. Und dementsprechend haben wir drauf reagiert, weil klar, Agilität hat keinen Selbstzweck, darf immer Value liefern und der Podcast ist cooles Feedback von euch und baut die Community auf. Ich liebe es, ihn zu machen. Gleichzeitig dürfen wir natürlich auch unternehmerisch ein bisschen denken und da war jetzt gerade nicht die höchste Prio drauf, sondern wir haben lieber die Trainings und Beauftragungen, die wir haben abgearbeitet. 2 Konferenzen mit Kind Wir waren zumindest auf zwei Konferenzen, selbst mit Kind letztes Jahr. Das stimmt. Richtig cool. Wir waren auf der Mind.set in Braunschweig bei MSG David und wir waren auch im Leadership Stars Meeting in Potsdam letztes Jahr und haben da jeweils mit LEGO Serious Play gespielt. Dort haben wir Simulationen mit LEGO, aber vor allen Dingen auch mit Teambuilding und Organisationsentwicklung über Lego Serious Play gemacht. Agile Releasetrains während des Betriebs verändern Das waren richtig coole Konferenzen! Wirklich tolle Tage. Auf dem Mind.set war Janina nur einen Tag dabei. Am zweiten war Henry dabei. Ihr habt einen Agilen Release Train. Sogar mehrere Agile Release Trains gebaut. Es war quasi eine Solution. Und zwar an einem laufenden Zug! Der während der Fahrt verändert wurde. Und wie mache ich eigentlich Agilität und Veränderungen an Systemen, die im Laufen bleiben, die sich bewegen und eben nicht anhalten. Wir haben auch die normalen Anfängerfehler gemacht und begriffen. Von wegen, ja, Führung braucht es jetzt ja nicht mehr. Ihr seid selbst organisiert als Team. Organisiert euch mal. Doch, die braucht es schon. Also es braucht da noch ein bisschen mehr, wie zum Beispiel ein paar Leitplanken, damit das funktioniert und nicht jeder halt irgendwie was baut. Und dann baut halt einer seinen Zug ein bisschen breiter, ohne die anderen darüber zu informieren. Schon kollidiert das mit einem Bahnhof. Aber bevor wir jetzt weiter darauf eingehen, was wir letztes Jahr gemacht haben, diese Folge ist vor allen Dingen dafür da, euch zu sagen, dass wir wieder da sind. Wie geht es mit dem Podcast weiter? Überraschung! Gute Dinge bleiben einem erhalten und kommen immer wieder. Das heißt, wir haben uns vorgenommen, für den Znipcast mindestens zehn Folgen rauszubringen. Ja, also ich würde schon ganz gerne wieder monatlich wenigstens veröffentlichen und uns dann vielleicht raniterieren, ob wir mehr schaffen. Das heißt, ihr könnt jetzt regelmäßig wieder mit Folgen von uns rechnen. Wir nehmen total gerne eure Themenwünsche entgegen, denn bei uns funktioniert vielleicht die Themenwelt gerade ein bisschen anders als bei euch. Von daher super gerne eure Themen. Teamgestalter Wir haben letztes Jahr aber natürlich, obwohl wir den Podcast nicht weitergemacht haben und neben den Konferenzen noch eine ganze Menge geschafft, finde ich. Und da vorweg zu erwähnen, finde ich, Henry bist jetzt geprüfter Teamgestalter! Wir arbeiten schon seit längerem zusammen mit Teamworks. Also der Firma rund um Thorsten Visbal und Svenja Hofert. Janina hat da schon meine Teamgestalter-Ausbildung gemacht und du bist eben jetzt auch offiziell geprüft und abgenommener Teamgestalter. Und das war für dich eine total spannende Zeit, auch in die Trainings da zu gehen. Neben der Teamgestalter-Ausbildung hast du eben auch Psychologie der Veränderung bei Svenja gemacht und Konflikte im kulturellen Rahmen bei Thorsten Visbal. Richtig coole Trainings und vor allem viel, viel besser die Ausbildung, weil wir da so viel ausprobieren können. Die Integrationszeit ist so lang und wir können eben vor Ort mit anderen in einem geschützten Raum Dinge ausprobieren, bevor wir sie dann in einer Auftragssituation durchführen und vielleicht das eine oder andere schief geht. Und ich habe da sehr viel ausprobiert. Wenn ich in etwas keine großen Erfahrungen hatte, habe ich es einfach in dem Kreis ausprobiert. Zum Beispiel eine Aufstellung in einer Workshop-Situation. Da habe ich dann vieles dabei gelernt beim Tun. Denn sich theoretisch darüber zu unterhalten, das ist immer eine schöne heile Welt. Und dann in so einer Situation bringt das für mich viel, viel mehr. Und das Coole ist, ich werde häufig gefragt, wie ich meine Workshops so gut mache. Das ist eine Summe von vielen Ausbildungen und Trainings, die ich besucht habe. Jetzt der Shortcut, genau die Teamworks Plus Ausbildung. Da lernt man so unglaublich viel in Richtung Moderation, Workshops gestalten, Teams zu facilitieren. Und ich sage, da ist eigentlich alles drin, alles auf den Punkt. Das ist genau die Stelle, wo ihr euch den Shortcut nehmen könnt. Menschen lesen Das Training, was sich bei uns am meisten verändert hat, ist, dass Menschen lesen. Denn unsere Trainings werden ja jedes Jahr immer nochmal ein Stückchen besser, weil wir uns auch anpassen und Dinge dazulernen. Mit Menschen leiten waren zusätzliche Komponenten noch dazu gekommen. Es war einfach euer Feedback, dass da so viel mehr Themen noch reingehören und das eben auf Führungskräfte-Level. Wie bringe ich Menschen wirklich in eine Veränderung? Wie kann das funktionieren mit Hilfe von Metaprogrammen? So ist eben Menschen leiten entstanden. Ursprünglich. Jetzt haben wir Menschen leiten integriert ins Menschen lesen und denke jetzt schon wieder über das nächste Modul nach, wo es eben eher um Kontexte, Zeitformen, Convincer und Kriterien geht. Zeitformen, die wir mal beim Heldentreff beleuchtet hatten, wo eben auch das Feedback war mit, oh, das sollte auf jeden Fall auch noch mit rein ins Menschenlesen und wo wir vor allem uns über die Konvinzer unterhalten, eben wann kippt es? Also wann erreiche ich genau diese Metaprogramme? Das ist ja auch ganz interessant mit, okay, was brauche ich denn, damit jemand sich wirklich bewegt. Rauhnächte Die Rauhnächte haben stattgefunden. Man kann jetzt unser Rauhnachts-Journal auf Amazon kaufen, was immer noch krass für uns ist. Und das ist richtig, richtig krass für mich auch zu sehen, wie viele von euch das tatsächlich auch gekauft haben. Wie riesig die Rauhnachts-Community auch geworden ist. Wie viele Menschen wir da auch wieder dieses Jahr neu kennenlernen durften, die wir vorher noch gar nicht getroffen haben. Es ist wirklich toll, mit euch diesen Jahreswechsel zu machen, mit euch Ziele zu setzen, mit euch über solche Dinge zu sprechen und ja auch selber dazu zu lernen. Also Raunechte war auch wieder richtig, richtig toll dieses Jahr. Es war so viel Balsam für die Seele auch. Ich liebe es, auch dieses Feedback, was dann dabei hochkommt. Und welche krass wohltuende Community dadurch. [8:05] Entsteht. Für mich war letztes Jahr das Jahr des Legos. Also Lego Series Play kam überall richtig gut an. Ja, das stimmt. Wir haben ganz, ganz viele Anfragen für Lego Series Play auch bekommen. Ja, und damit waren wir ja nicht nur auf der Mindset, sondern eben auch im Leadership Stars Programm oder Meeting. Auch da fand ich unglaublich, wie weit die Führungskräfte sind, denen wir da begegnet sind. Im Leadership Stars Meeting. Ja, darauf eingelassen haben. Also Wahnsinn, was da scheinbar auch drumherum passiert. Fand ich eine richtig angenehme Basis, eben so mit Menschen zu arbeiten. Also richtig schön, hat mir sehr gefallen. Scheint wirklich viel bei rumzukommen, um genau die richtigen Menschen anzuziehen. Ja, die Menschen in dem Leadership Stars Meeting haben eben die Gelegenheit, sich ihre Führungsrolle aus ganz unterschiedlichen Perspektiven mit unterschiedlichen Werkzeugen und Tools anzugucken und zu reflektieren. Zum Beispiel gab es eine Stilberatung. [9:06] Kleider machen Leute mäßig. Also wie kleide ich mich denn so, dass ich sympathischer ankomme und entsprechend den Menschen mir auch eher geneigt sind zu folgen? Wie mache ich denn quasi das Beste aus meinem Stil? Wir haben aber auch mit Katja Schäfer, zum Beispiel Katja Schäfer Coaching, große Visionsboards erstellt und eben bei uns mit Lego darüber gesprochen, was sind die größten Herausforderungen in Führung. Solche Themen zu besprechen mit einer Gruppe, die so, so weit ist, ist natürlich was ganz Besonderes. Und was für mich großartig ist, dass wir unsere Tochter mitbringen konnten und dass das auch von allen als so professionell wahrgenommen wurde. Es ist ja schnell so dieses, in meinem Kopf zumindest, diese Frage. [9:46] Wo endet Professionalität, wenn ich mein Kind mitschleppe, in Anführungszeichen. Und dass das so professionell auch funktioniert hat, finde ich, ist großartig für diese Arbeitswelt und für diese Welt als Ganzes. [10:00] Dann machst du jetzt KVT und lässt auch immer mehr in Gesprächen einfließen. [10:06] Was wahnsinnig gerne angefragt wird, ist die psychologische Perspektive auf Dinge. Also zum Beispiel, wie gehe ich psychologisch gesehen mit Veränderungsmüdigkeit um? um wie gehe ich psychologisch gesehen mit Jammern, Motzen, Meckern um. Da gibt es ja auch eine Podcast-Folge schon aus dem vorletzten Jahr zu. Und diese psychologische Perspektive eben auszubauen. Dafür habe ich eine KVT-Ausbildung gemacht oder angefangen. KVT ist kognitive Verhaltenstherapie. Das betrachtet nochmal wirklich so ein bisschen, wie bekomme ich diese Menschen mit bestimmten Denkstilen ein Stück weit auch bewegt. Wir sind in diesem, wie bekomme ich die Menschen bewegt, Modus drin. Du über Metaprogramme und Menschen lesen. Wie bewege ich die Menschen über diese Perspektive schnell und einfach? Und ich über diese, okay, wenn es schnell und einfach nicht funktioniert, [10:52] wie kann ich denn über so eine psychologische Perspektive die Menschen in Bewegung bringen? Und auch das ist irgendwie richtig toll, wenn wir gehen in Ausblickrichtung, was bewegt sich denn im Jahr 2024, 2025, was bewegt sich bei uns gerade ganz viel? Ja, da ist so dieses Bewegen ist irgendwie so das Schlagwort. Denn auch ich, Nutze jetzt ja die Zeit, um für 2025 schon die Dinge vorzubereiten, wie zum Beispiel, dass das Agile Master Training als Training dieses Jahr, 2024. [11:25] Nochmal stattfindet und ab nächstem Jahr in eine anderthalbjährige Ausbildung geht. Genau, dieses Jahr sind es noch drei Tage vor Ort. Ab nächstem Jahr sind es dann anderthalb Jahre mit vielen vor Ort Sachen, wo wir Dinge ausprobieren, integrieren und so weiter und den Campus halt mehr zu erweitern. Dass es da mehr Dinge gibt, die man auch benutzen kann für seinen Arbeitsalltag. So Grundlagen wie zum Beispiel… Werkzeugkasten für dich zusammenzustellen. [11:52] PowerPoint-Vorlagen, die einfach nur mit den eigenen Master reingegossen werden und so weiter. Und viel, viel mehr dieses Begleiten in dieser Veränderung, dass man die eigene Organisation eben auch verändern kann, da eben vielleicht Rückfragen hat, dass man eben länger da ist, als nur diesen Theorie-Input zu haben, sondern diese Begleitung, damit wirklich eine nachhaltige Veränderung eben auch passiert. Und das ist vor allen Dingen für die Menschen, die noch sich nicht ganz sicher sind, wie bekomme ich die Menschen wirklich in eine Veränderung, die sehr unsicher sind, wirklich mit ihrem theoretischen Wissen in die Praxis zu gehen. Das ist für die Menschen, die ganz am Anfang der Agilität stehen, die wirklich so Richtung Teamentwicklung, Richtung Agilität, Richtung Agile Master, also auch Richtung skalierende Frameworks noch gar nicht so viel wissen. Es ist für Menschen, die sich intensiv damit beschäftigen wollen, die wirklich verantwortungsbewusst mit ihrer Rolle als Agile Master auch umgehen wollen. Denn es ist so eine sensible Stelle, wo diese Agile Coaches sitzen. Die können so viel kaputt machen, so viel noch schlimmer machen im Unternehmen. Das ist einfach, finde ich, verantwortungsvoll, Menschen vernünftig auszubilden, die in diesen Positionen sitzen. Und es passiert einfach im Moment noch gar nicht. [13:06] Um dann eben Dinge jetzt besser zu machen. Das verändern wir. [13:10] Genau. Und meine Idee ist halt, dass es über die Jahre diese eine Ausbildung wird, wo alles drin ist und wir wirklich viel mit abdecken können und eben zu dieser Veränderung beitragen. Wir sind gestartet mit Snipp mit dem Anliegen, dass Agile Master eigentlich ein Studium sein sollte. Ein richtig, wirklich ausführlich langes Ding, wo man wirklich verschiedene Perspektiven betrachtet. Und ein bisschen so sehe ich diese Agile Master Ausbildung, dass wir vielleicht mit verschiedenen Modulen, mit verschiedenen Inputs von außerhalb dir und mir vielleicht, da wirklich euch umfassend vorbereiten auf den Job des Agile Masters. Wir wirklich alles teilen, was wir können und haben. Mit Soft Skills, mit Hard Skills, mit Skalierung, aber auch mit psychologischer Arbeit mit Menschen. Dass da eben alles drin ist, was du brauchst. Und wir und die Community eben auch zur Verfügung stehen, um dann nochmal Nachfragen zu beantworten oder Erfahrungen aus der Praxis eben zu teilen. Ja. Und die nächste Sache ist, dass ich ganz gerne eine Konferenz zu moderner, neuer Arbeit veranstalten würde. Weil gerade die letzten Jahre hat sich so viel getan, es gibt so viele neue Strömungen. Die würde ich ganz gerne mal übereinanderlegen, integrieren, austauschen, all diese Dinge. Ja, Agilität alleine ist halt einfach so, der Begriff ist so ausgenudelt irgendwie. [14:38] Wir wissen, dass das wichtig ist, dass das richtig ist. Wir wissen, was in diesen Frameworks alles drinsteckt und wir sehen es so schmerzlich häufig einfach scheiße umgesetzt. Entschuldigung. Und da nochmal so ein bisschen einen anderen Twist reinzukriegen, eine neue Perspektive draufzukriegen. [14:53] Das stelle ich mir auf dieser Konferenz vor, die Bühne zu geben für die kleinen, feinen Perspektiven, die Praxisperspektiven. [15:01] Ja, genau. Also ihr seht, bei uns bewegt sich wahnsinnig viel. Wir bewegen auch gerade wahnsinnig viel. Wir haben richtig viel Energie wieder. Wir wollen häufiger Podcast-Folgen rausbringen und alles hat so irgendwie Wirkung und Nebenwirkungen. Und eine Nebenwirkung von unserer Abwesenheit letztes Jahr ist, dass der Algorithmus uns ein bisschen vergessen hat. Das heißt, wenn du weißt, wie wertvoll der Snippcast ist, wenn du uns gerne häufiger hören möchtest, dann nutzt doch gerne jetzt die Zeit, deine Lieblingsfolge zu teilen, damit der Algorithmus weiß, wir sind wieder da. Da, egal welche Folge das für dich ist, ob es eine ganz alte Folge ist, Vertrauensfolge zum Beispiel oder die allererste Folge oder die Mindset-Folge oder wo es um Jammern und Motzen geht oder die letzte Folge mit Lea, egal welche, teil deine Lieblingsfolge am besten jetzt. Diejenigen, die uns noch nicht folgen, ihr seid herzlich eingeladen, auch ein Follow-me dazulassen. Und dann gibt es von uns ab jetzt jeden Monat eine neue Folge. Und wir freuen uns von euch zu hören, welche Folgen eure Lieblingsfolgen sind, sehen wir dann in den Statistiken. Stimmt. Liebe Grüße an euch und bis bald. Tschüss. Get shit done, Janina & Henry Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern. Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann buch uns Agile Master Ausbildung, damit Du und Dein Unternehmen zur Höchstleistungsmaschine werden! In der Podcastfolge erwähnte Folgen zur Vertiefung: Backlog Folge Stakeholder Folge SAFe Folge Leadership Folge Jammer Folge Agile Master Folge Agile Coach Folge Vertrauen Folge letzte Folge mit Lea Lindemann – Erfolgsgarantie Connecte dich gerne hier mit uns: LinkedIn Instagram YouTube Facebook Znip Academy, Deine Akademie für Agilität und Scrum Facebook-Gruppe The post 160 3 Jahre Znipcast appeared first on Znipcast - für gute Zusammenarbeit | Agile, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy.

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.