Projektmanagement

154 Produkt vs Projekt

Produkt vs Projekt [0:00] Machen heute einen richtig fetten Knoten in deinem Kopf. Während wir versuchen Ungarn zu lösen. Wir schauen uns zwei Begriffe an, die in der agilen Welt parallel synonym, getrennt voneinander, strikt getrennt voneinander verwendet werden und endlich klären wir mal auf, was es mit diesen beiden Begriffen an sich ist. Es gibt Klugscheißerwissen, um auf der nächsten Konferenz. [0:25] Music. [0:34] Und herzlich willkommen zum Snipcast. Dein Podcast für Agili, Was für dich Teams und so weiter relevant ist, Heute ist endlich Janina wieder dabei. Und äh wir haben noch einen dritten Gast. Äh sie schläft grade hoffentlich äh hält sich das auch für ihren Podcast. Also falls da so ein paar Hintergrundgeräusche sind. Ich hoffe, wenn du uns im Auto hörst, dass das nicht ansteckend ist und du uns weiterhin toll folgen kannst und ich bin froh, zu Mert zu sein, so mal wieder einen dynamischen Podcast zu haben. Genau und was ich erzählen wollte, ist mir ist im Wochenbett was aufgefallen, was Parallelen hat zu dem, was wir üblicherweise hier im Podcast erzählen. Ach. Mhm. Wochenbettzeit [1:20] Und zwar ist mir aufgefallen im Wochenbett ne, die Zeit, in der man sein Baby kennenlernt und versucht herauszufinden, wie es tickt, versucht und was ganz Ähnliches machen wir in Menschen lesen. Menschen lesen haben wir ja jetzt neu aufgesetzt, also Menschen lesen, dass es ein Training das wir geben, indem wir unsere, dass es weitergeben, wie Menschen ticken. Ja. Weil uns aufgefallen ist, wie wichtig das ist, wenn man andere Menschen führt, egal ob direkt oder lateral, also wie so ein. [1:53] Coach, ein Master, ein Team Facilitator oder auch nur eine Moderatorin das macht dafür ist es gut, relativ schnell herauszufinden, wie Menschen ticken, was sie jetzt brauchen, um etwas mitzugehen, um entspannt zu sein in stressigen Situationen und nichts anderes habe ich die letzten Wochen im Wochenbett gemacht. Ich habe versucht herauszufinden, wie sie, Dementsprechend ist ja auch meine These zu ihr, dass sie die, gleiche Struktur immer beim Windeln wechseln zum Beispiel braucht, also immer genau die gleiche weil eben Prozederal und, wenn du jetzt nicht viel von dem verstanden hast, was Henri gesagt hat, dann ist Menschen lesen vielleicht was für dich. Wir machen’s dieses Jahr das erste Mal in einem richtig großen Bundle, also weil wir festgestellt haben, es ist so es genau, es ist so intensiv, man kann da so viel drin lernen und man hat also unsere Teilnehmenden haben so viele Aha-Erlebnisse gehabt, dass wir’s jetzt aufgeteilt haben, damit wir eben für jedes Thema intensiv Zeit haben und ja also wärmste Empfehlung, für dich, wenn auch du gerne herausfinden möchtest, wie deine Teammitglieder oder deine Führungskräfte oder deine Coachies ticken und das relativ schnell, dann ist Menschenlesen Gold wert. Wochenbett, genau das. Wir wollen ja heute nicht übers Wochenbett sprechen. Nee. Wir wollen heute sprechen über. Das Thema [3:21] Produkte und Projekte. Produkte die ja so ein bisschen Wert drauf legen manchmal diese voneinander zu unterscheiden, ganz ehrlich, ich habe damals als Softwareentwickler habe ich mich auch gefragt, hä wieso ist das gleich warum äh ich mache da hier ich mache hier Projektarbeit eigentlich den ganzen Tag. Mhm. Mir ist erst später aufgefallen, Nee, eigentlich mache ich Produktarbeit. Genau. Genau genommen sind nur zwei Wörter anders. Äh zwei Buchstaben. Ja, genau. [3:53] Das war’s oder nicht? Nein, du hast wo ist denn wo ist denn genau, wo ist denn für dich so dieser Unterschied zwischen Produkten, Wo ist der Unterschied zwischen Produkt und Projekt? [4:05] Also fängt schon da an, wie ich es eigentlich als Projektleiter damals gelernt habe. Ein Projekt hat einen definierten Anfangs- und einen Endzeitpunkt und der ist eigentlich vorher schon bekannt mit wollen jetzt hier eine neue Brücke bauen, dann und dann zack, fertig. Nächstes Projekt. Mhm. Was ich häufig sehe als Projekt, ist so wir haben ein Produkt, was weiß ich, Microsoft Office zum Beispiel, Den gibt’s dann immer wieder neuere Versionen davon und die Mitarbeitenden, die die arbeiten eigentlich die ganze Zeit an diesem Produkt in dem Fall in dem Projekt wenn wir das Projekt nennen. Die meisten Unternehmen, die machen aufgrund ihrer Budgetierung auch die Projekte immer in Jahresscheiben und dann gibt’s das gleiche Projekt immer wieder nächstes Jahr mit ähnlichen Budget wahrscheinlich. Und das ist eher Produktentwicklung. Also so in meine Worte zusammengefasst. Ein Produkt kann aus mehreren Projekten bestehen. Ja. Äh entweder parallel zueinander laufenden Projekten oder aneinander zeitlich aneinander gereitet. [5:03] Und ein Projekt könnte auch ein Update von einem Produkt sein, durchaus mit ich möchte unsere Fertigungshalle möchte ich mal auf, neuere Fertigungssysteme sehe ich ein bisschen Automatisierung rein, dann ist dieses hier automatisieren neues Projekt danach ist das Produkt eben anders. Okay, also ein Projekt kann auch Teil einer Produktentwicklung sein. Ja. [5:29] Übereinander. Über ein Projekt. Eine Produktentwicklung realisieren über ein Projekt, Ja? Ja, ja, genau und es hat beides Vor- und Nachteile und deshalb wollte ich die Folge einfach mal mit dir machen. Aha. Mhm. Vor- & Nachteile [5:41] Gut, ich sehe ich sehe schon, dich interessiert das direkt, was ich häufig erlebt habe und das jetzt schon in diversesten Unternehmen und das muss ich mal ein Konzern sein, das ist vor allem auch kleine Unternehmen, sind davon, häufig betroffen mit wir haben hier einen Praktikanten der kann ein bisschen Software entwickeln der kann mal eben als Projekt so ein bisschen Software für uns schreiben, weil der Praktikant ist ja nach sechs Monaten oder so was, ist der wieder weg und schreibt halt ein bisschen Software, die was automatisiert in diesem Unternehmen. Mhm. Projekt ist danach abgeschlossen, fertig, ist cool für ein Praktikum. Das Problem ist jetzt, dass dieses. [6:17] Was da rauskommt, meist in den Unternehmensalltag einfließt, weil das war ja gut und wir haben’s ja aus gutem Grund beauftragt und die Jahre essentiell wird. Der Praktikant ist irgendwann weg. Die Praktikantin. Dann fällt dieses System aus oder kommt mit dem neuesten Betriebssystem Update oder sowas, plötzlich nicht mehr klar oder es zu klein geworden, ne? Wechselt die Datenmenge oder die Komplexität einfach. Mhm. Und dann haben wir auch ein Problem, weil es nur als Projekt umgesetzt wurde und nicht als Produkt und daher nicht nachhaltig begleitet wird Support und dass man sich umguckt, wie ist denn das Umfeld und so weiter, müssen wir da unser Produkt vielleicht ein bisschen anpassen und Ähnliches eben als einmaliges Ereignis nur gemacht. Jetzt kenne ich ja mal Projekte, in denen wird auch Wert darauf gelegt, bestimmte Qualitätsmaßstäbe, nachhaltig, zukunftsorientiert und so weiter und so fort umzusetzen. Ja. Ist das dann einfach, falsche Benutzung des Wortes oder gibt es das quasi in kleinerer Variante ab? Genau, das ist dann im Projekt schon vorausschauend geplant. Mhm. Und jetzt kommen wir zu dem Zeitpunkt, dass wir eben feststellen, oh mit dem neuen, Würde das vielleicht nicht funktionieren und jetzt haben wir mehrere Kostenstellen im Unternehmen. Mhm. Wer bezahlt das nächste Update? Mhm. Und das ist dann häufig so ein Problem. [7:39] Wir das als Produkt entwickelt haben, dann haben die eben ein gewisses Betriebsbudget über die Zeit, Da fließt das halt mit ein und die gucken sich das an, weil ich ich bin Herr dieses Produktes und ich möchte, dass das weiterhin zu meinen Kunden eben passt, Deshalb kümmere ich mich dadrum, dass es natürlich immer wieder unseren Kundenbedürfnissen entspricht, eben jetzt ein neues Betriebssystem, Als Projekt gemacht, dann ist es so ein bisschen, ich habe vielleicht schon nachhaltig gedacht am Anfang, doch über die Jahrzehnte dann häufig ist es Feiern forget Multi-Projektmanagement [8:11] Ich habe glaube ich Projektmanagement ein bisschen anders gelernt. Mhm. Als du bin ich aber also habe ich’s auch nicht so tief gelernt wie du. Ich hab’s mehr oder weniger. Ich habe da nur mitgearbeitet. Ich habe keine Zertifizierung oder so was da drin. Und es ist nicht ein Software gewesen, sondern in Hardware, also ging es um das Realisieren von Kraftwerken. Bauen von Kraftwerken Hardware. Ja. Da wäre jetzt von dem, was du erzählt hast, quasi, dass wir bauen ein Kraftwerk, wäre das Produkt, Ja. Und das, was in so einer structure stehen würde, äh wäre, wären dann lauter Einzelprojekte. Das Produkt realisieren. Ja. Es heißt aber, Zumindest in dem Unternehmen, in dem ich gearbeitet habe, heißt es Projektmanagement. Ja. Das heißt dann gerne Multiprojektmanagement, ne, weil ich habe mehrere Projekte, die dieses Vorhaben bedienen, aber da hat niemand von Produktmanagement. [9:05] Deshalb finde ich diese Folge so wichtig und ich kann mich auch irren in unserer Welt, also auch also, Wenn ich mich irre bitte in die Kommentare schreiben. Deshalb ist mir das eben so ein bisschen Anliegen, aufzudröseln, dass wir eben häufig Projektmanagement sagen, obwohl wir Produktentwicklung meinen. Vielleicht gibt es aber ja auch einen Unterschied zwischen Software und Hardwareentwicklung oder zwischen einfach nur im Wortgebrauch, Unternehmen. [9:34] Vor 25 Jahren, also so lang ist es gefühlt her, es sind keine 25 Jahre, aber es sind bestimmt schon 20 Jahre und dem, was heute, also dass man das quasi nachträglich erst eingezogen hat, dass es noch ein Produktmanagement gibt zusätzlich zu einem Projekt Management. Also das ist eine eine neue ähm Spezifizierung ist, weißt du? Ich glaube sogar, dass es umgekehrt, Haben mit dem Produktmanagement oder Produktentwicklung, angefangen und irgendwann kam das Projektmanagement auf und das war neu und hip, so wie es jetzt grade Aktilität ist und dann hat man einfach alles Projektmanagement genannt Um Projektmanagement ist auch super sinnvoll, weil es die Ressourcen wieder freistellt für ein neues Projekt. Wenn wir das im Unternehmen aber nicht machen, dann, meine These, dass es sich eher um Produktentwicklung handelt. Mhm. Kann man mit mir gerne drüber diskutieren. Ist sicherlich auch nicht der Weisheit letzter Schluss. Warum ich das aufwerfe ist. Schon einmal an Produktmanagement gedacht? [10:29] Meist suchen wir Projektleiter, Projektmanager, machen Multiprojektmanagement und so weiter und das ist so quasi die Spitze dessen, was wir im Unternehmen erreichen können, also echt mal abgesehen von Vorständen oder Ähnlichem. Was vielleicht an vielen Stellen sinnvoll wäre, wäre Produktmanagement und wirkliche Teams, die hinter einem Produkt stehen würden, sich da drum kümmern würden, dass dieses Produkt auch weiterhin am Markt erfolgreich bestehen kann gerade die Agilität spricht ja sehr häufig von der Produktentwicklung statt vom Projektmanagement. Also gerade im Scrum, wir entwickeln ein Produkt, das wird iterativ entwickelt und immer wieder besser gemacht an den Kunden angepasst und so weiter. Und das ist halt im Kopf dieser Shift, der stattfindet mit wir kümmern uns jetzt um unser Produkt, und das entwickeln wir immer entlang des Kunden und es gibt ständig wieder kleinere Updates als dieses wir haben ein Lastenheft einfach abgearbeitet und danach ist dieses Produkt auch in diesem Fall kommt ein Produkt raus, ist fertig und danach fasse ich’s aber nie wieder an, Kommt ein neues Projekt, was dann sagt, ich mache da wieder ein Update drauf. Meist gibt es eben ein Problem dieses neue Projekt aufzusetzen, weil es hat vielleicht, 1 zwei Anwender haben halt ein Problem einer gewissen Stelle. Die sind aber zu klein als das, sie genug Geld aufbringen könnten für das nächste Update oder ein neues Team zusammenzustellen, die da eben ein Update drauf machen. Unterscheidet die Agilität anders als klassisches Projektmanagement?…

Read More

151 Warum sollte ich Agilität einführen?

Warum sollte ich Agilität einführen? Durch die Einführung von Agilität steigern wir die Flexibilität unserer Organisation und können daher besser auf Änderungen unserer Umgebung reagieren. Zudem bekommen wir eine bessere (niedrige) Fluktuation, motivierte Mitarbeitende und niedrige Krankheitsstände. Allein das schafft schoin mehr produktive Arbeitstage und ist damit wirtschaftlich sinnvoll. Unsere Agile Master Ausbildung: https://znip.academy/agile Diese…

Read More

150 Durchlaufzeit

Durchlaufzeit Agile Master Training: https://znip.academy/agile Diese Folge auf YouTube: https://youtu.be/6_XytwfFBPw [0:00] Diese Folge wird dich als Product Ownerin, Führungskraft oder Projektmanagerin sehr interessieren, denn heute geht es ums Messen und welche Größe wir da sinnvoll in der Agilität einführen können, nämlich die Zykluszeiten, Los. [0:18] Music. [0:27] Und herzlich willkommen zum Snipecast. Mein Name ist Henry Schneider und das heutige Thema sind Durchlaufszeiten, Leads Time oder Zykluszeiten. Warum Durchlaufzeiten messen? [0:39] Warum überhaupt durchaus Zeiten messen und wofür brauche ich denn das überhaupt? Da mein Hinweis, Ich setze das zum Beispiel ein, um auch das Management von Agilität zu überzeugen, denn wozu führen wir denn überhaupt Agilität ein? Was soll denn uns das bringen? Die Mitarbeitenden vielleicht glücklicher sind, weniger Fluktuation, weniger Krankheitsstände und ähnliches besseres Arbeiten und so weiter. Lässt sich nicht ganz so leicht greifen und grade uns im Management, ich war ja auch lange Zeit Projektmanager, interessiert doch dann eher, okay Was bringt’s mir denn am Ende in Zahlen und die Durchlaufzeit ist für mich so kleiner Quickwin, das ich wirklich einsetze, um die Manager in meinem Umfeld auch entsprechend zu überzeugen. Von daher, falls du ein Manager bist, der mit mir schon zu tun hatte oder mit meinen Teams, wirst du dich vielleicht sogar jetzt durch diese Folge bisschen dran erinnern, mit Eier stimmt, Ist so eine Größe, die hat der Henry eingeführt. [1:45] Das hat mich dann wirklich davon überzeugt, dass wir jetzt hier anders oder agil arbeiten, weil das hat mir am Ende des Tages was gebracht. Also Heute decke ich ein bisschen auf, wie ich normalerweise, mit Management so ein bisschen fertigt arbeite und das ist die Durchlaufszeit. Und da geht’s vor allem um die Verlässlichkeit unseres Teams oder der Organisationseinheit, die wir vor uns haben also wie verlässlich ist die und was sind das für Zahlen, die am Ende rauskommen, mit denen wir dann in die nächsten Instanzen gehen können, Planen könnt, vielleicht sogar unserem Vorstand entsprechend, Zusagen geben können und diese dann eben auch einhalten. Also sprich wirklich Verlässlichkeit, denn häufig haben wir es, wir haben mehrere Hierarchieebenen vor allem in großen Unternehmen, die miteinander sprechen, die irgendwelche Ziele vorgeben, die sagen, hier, jetzt muss dies gemacht werden, jetzt muss jenes gemacht werden in zwei Wochen großes Presseevent. Da müssen wir plötzlich dies und jenes tun. Und grade dieses mittlere Management. [2:44] Weil die gar nicht wissen wie ihre Teams, Ganz unten auf der operativen Ebene, also auf der Arbeitsebene arbeiten, als auch wie lange brauchen die denn für all diese Sachen? Und da kann eine richtig gute Sache eben die Durchauszeit sein ich einsetze, um allen auf allen Hierarchieebenen plötzlich eine Größe zu geben, mit der sie arbeiten und planen können, als auch Zuverlässigkeit in die Teams reinzubekommen und eben auch Optimierungsmöglichkeiten zu schaffen, also die Durchlaufzeit ist etwas, an der ich ganz gerne optimiere. Und auch hier möchte ich. Achtung Messung [3:23] Anmerken. Es ist eine Messung, wir kriegen beim Messen wirklich, was wir bekommen. Also pass bitte auf mit all den Metriken, die wir einführen, vor allem im agilen Umfeld bekommen, was wir messen. Beispielsweise Janina und ich, also allgemein an der Snippe Academy, sind wir ja Riesenfan von The Losity, die einzuführen. Diese arbeitet mit Storypoints und dementsprechend, wenn ich anfangen würde die Belosity zu messen, oder die Storypoints, also wie viel Komplexität schafft denn mein Team so je Durchlauf je Zyklus je Iteration und die vielleicht danach auch noch bezahle, also sprich ich suche mir irgendeinen Lieferanten, mit dem ich mich drauf einige, je storypoint, der in dem Zyklus erledigt wird kriegst du tausend Euro. Was werden wir dann bekommen? Also wenn wir das messen und auch noch Benefits oder vielleicht sogar irgendwelche Bonusse dadrauf packen, dann bekommen wir mehr davon. [4:19] Also sprich, wenn ich das jetzt auf die Storypoints mache, bekomme ich einfach mehr Storypoints. Wird auch meine steigen, also schön diese ganzen Charts wie wir die eben kennen, ne, über die Zeit, dass die steigt im agilen, weil wir ja immer besser werden. [4:33] An der Stelle, wenn ich da Geld drauf gepackt habe, ist das eine Fehlinterpretation. Wahrscheinlich bekomme ich einfach nur mehr Story-Points und nicht mehr geleistete Arbeit, mehr bewältigte Komplexität oder ähnliches, weil einfach die Storypoint Schätzungen hochgehen weil ich genau das messe, da drauf gucke und das auch noch honoriere durch Geld, also bekomme ich mehr, Dadurch haben wir wirklich nicht viel erreicht. Genauso, wenn wir diese Messgrößen plötzlich einführen würden und damit Teams miteinander vergleichen würden. Dafür sind die nie gedacht. Die sind immer nur zur Optimierung, Steuerung. [5:07] Von einem einzelnen Team um Anhaltspunkte zu bekommen, Dafür sind die da. Nicht um Teams jetzt miteinander zu vergleichen. Denn wenn wir das jetzt tun würden und jetzt sagen würden, oh das eine Team ist vielleicht ein bisschen doof weil die nicht so viele Storypoints schaffen wie ein anderes Team, was. [5:24] Ähnliche Teamgröße hat, dann wären einfach nur mehr Story-Points in diesem Team, was ich gerade als doof betitelt hatte, aufgeschrieben, weil die festgestellt haben, okay, wenn sie weniger Storypoints schaffen, dann kriegen sie halt quasi Ärger. Das sieht nicht so gut aus Also es sollten sie einfach mehr Storys. Kein bisschen Fortschritt an unserem Produkt mehr erzeugt. Dementsprechend achte wirklich drauf, was du misst Nicht zu viel, lass es vor allem super simpel. Sein. Wir haben in der Messenfolge auch schon drauf hingewiesen und in der Überprüfungfolge super simpel. Es muss jeder im Team auch durchführen können diese Messung. Nicht zu viele und jeder darf auch verstehen, wofür das gemacht deshalb fange ich ganz gerne Kamera auch in meinen Scrum-Teams mit der Durchlaufzeit an, beziehungsweise um ganz genau zu sein mit der Zykluszeit und was da die Unterschiede sind. Da komme ich in dieser Folge auch noch drauf. Ich nehme ganz gerne das Wort Durchlaufzeit, weil die meisten damit was anfangen können Zykluszeit eher ein bisschen abstrakter ist. Eine weitere Messgröße, die wir hier in dem Podcast auch schon genannt haben, ist das Birnbaum. Oder das Release-Burn-Down. Auch das sind Messgrößen, mit denen wir arbeiten, wo wir nur ganz andere Sachen machen und auch da wie üblich, versuchen durch die Messung Anhaltspunkte zu bekommen worin wir besser werden können, womit wir vielleicht sogar in Zukunft besser planen können. Diese Zahlen, die wir ermittelt haben, sogar. [6:51] Extra polieren können, um eine Vorhersage treffen zu können, was dieses Team in Zukunft in der Lage ist, zu leisten. Doch jetzt. Durchlaufzeit [7:00] Ganz normal erstmal die Einführung der Durchlaufzeit. Wie mache ich das? Ich möchte dir ganz gerne mein Wissen so nahe bringen, wie wir das nachhaltig in Teams installieren können. Schritt für Schritt auf die Themen eingehen, die häufig nicht im Scrum Guide stehen, was es noch sonst noch so zu den Teams dazu gibt und wie wir das eben Schritt für Schritt einführen, sodass es sich für alle gut anfühlt und vor allem das Unternehmen und die Organisation, auch besser werden. Also Agilität betrachte ich eher als ein Tool und dieses Tool setzen wir ein, um eben Dinge besser zu können, ähnlich wie ein Hammer, mit dem wir halt Nägel vielleicht besser in die Wand drücken können als jetzt mit einer Gurke. Wir nehmen eben den Hammer für wir wollen Nägel in der Wand haben, Klar verändert sich der Blick dadurch auch, wenn ich dieses Tool plötzlich in der Hand habe, sehe ich sehr viele Sachen, die ich plötzlich in die Wand hauen könnte, außer vielleicht nur Nägel oder alles wirkt plötzlich wie Nägel auf uns Daher immer vorsichtig mit diesem Tool und ich gebe dir das jetzt so weiter, wie ich es eben entsprechend einführen würde. Die Durchlaufzeit würde ich in einem Canvan-Team, Starte da, wo du stehst. Ist ja das erste Prinzip so einführen mit okay, wir machen erstmal nichts anderes, außer zusätzlich die Messung der Durchlaufszeit einzuführen. Und das tun wir, um auf lange Sicht eine Durchlaufszeit beziehungsweise in meinem Fall eine Zykluszeit oder eine. [8:27] Zwei Wochen Schrägstrich 14 Tage. Ich nehme ganz gerne das Wort 14 Tage zu erreichen. Warum wollen wir das erreichen? Um eine Vorhersage für die Zukunft zu treffen, damit unsere Manager oder unsere Productownerin, wenn die in anderen Gremien auftreten, oder mit Stakeholdern verhandeln oder vielleicht sogar dem Vorstand des Unternehmens verhandeln, damit die aussagefähig dazu werden, wann denn genau diese Sache, die sie bestellt haben, also der Vorstand, bestellt hat bei diesem Team, wahrscheinlich erledigt sein könnte. Wenn wir eine Zykluszeit von 14 Tagen erreichen, also von hier kommt die Aufgabe rein in unser Backlog zu, Hier ist die Aufgabe erledigt. 14 Tage, dann können wir, wenn wir neue Aufgaben, zum Beispiel vom Vorstand bekommen. [9:17] Sehr wahrscheinlich sagen, mit ja in drei Wochen hast du das passende Ergebnis dazu, in drei Wochen gibt es die erste Version des Ergebnisses dazu. Wir haben das bis dahin gelöst oder oh du brauchst das nächste Woche sehr unwahrscheinlich, dass wir das schaffen. Wir brauchen im Schnitt 14 Tage, Also vielleicht kannst du dir irgendwie ein anderes Team suchen. Bei uns würde das sehr viel Chaos verursachen, Willst du das wirklich, dass wir alles stehen und liegen lassen, dieses Chaos dann einmal in diesem Team haben, dadurch alle anderen Sachen verzögern deine Sache im Taskforce Modus von mir aus eben jetzt schnell lösen oder sollen wir hier wirklich einen nachhaltigen Zyklus auf Unsere Aufgabe vor allem als Team Faszinitatoren oder als Agile Master ist es ja nachhaltig diese Veränderungsprozesse zu installieren, also dass wir auf Dauer, Immer wieder innovativ bleiben, kreativ und die komplexesten Sachen zuverlässig lösen können und nicht einfach so einen Chaosmodus haben, wo, Quasi auch unsere Planung und wir müssen nicht strikt festhalten in der Planung, Planung überhaupt nicht mehr gültig ist. Also ab dem Zeitpunkt, wo wir sie gemacht haben, ist die häufig sowieso schon nicht mehr so genau, Doch wir können uns immer noch dadran orientieren und vor allem eben auch an unseren Zielen, die wir ja erreichen wollen. Also wir führen das ein, um. [10:43] Zuverlässigkeit zu bekommen und ganz am Anfang machen wir nichts anderes außer diese Messung einmal einzuführen. Und diese führen wir ein durch. Durchlaufzeit einführen [10:51] Wir markieren den Zeitpunkt, wo diese neue Anforderung bei uns eingegangen ist im Team und dann markieren wir den Zeitpunkt, Wann sie erledigt ist und mit erledigt meine ich, Erledigt erledigt, durchs Review gegangen, Haken dran, alle Akzeptanzkriterien erledigt und nicht dieses und ich war früher auch so als Softwareentwickler, dieses, Ja, es ist eigentlich schon fertig. Es fehlen nur noch die Dokumentationen. Ja, es ist schon fertig. Es fehlt nur noch das Review. Nein, das Review zählt da mit rein in meine Zykluszeit oder in meine Durchlaufszeit. Zählt damit rein, aus dem Grund, Ich möchte ja auch, dass mein Team möglichst diese Reviews durchführt und nicht einfach nur da. [11:37] Und vielleicht die Product Onerinnen keine Zeit hat weil sie plötzlich wichtigeres zu tun hat und sich daher die Reviews nicht abnimmt will ich nicht. Da will ich das wirklich dann auch die durchaus Zeit dadurch steigt und sich alle damit auseinandersetzen müssen mit hey, Es ist wichtig diese Reviews durchzuführen, damit diese Sachen abgenommen werden und als erledigt gelten Also damit aufnehmen. Genau das tue ich erstmal und dann messen wir erst mal, locker mal so zwei, drei Iterationen. Was auch immer die Zykluslänge bei euch im Team ist, genau die messen wir einfach mal zwei, drei Iterationen und dann kriegen wir so eine Hausnummer. Und ganz ehrlich, meine Erfahrung ist so das einfach nur einführen, ne, kann mal ein Like, wir starten da, wo wir stehen, wir haben hier ein Team, die wollen mal so ein bisschen agil oder kann mal ein Like arbeiten, von mir aus aus crum einführen Wir lassen aber erst mal alles so, wie es ist und schaffen erst mal nur Transparenz und schaffen jetzt diese Messung ein, Ist es häufig so, dass die meisten Personen im Team jeder für sich irgendwie so, zu 7 Aufgaben am Stück gleichzeitig parallel. [12:46] Und diese dauern so acht Monate im Schnitt bis sie erledigt sind. Und falls das anders ist, schreib mir das gerne in die Kommentare. Also falls das anders ist bei deinen Teams, bei meinen Teams, mit denen ich häufig angefangen habe, ist es häufig so, beim die Menschen da drin noch nicht so ein gutes Verständnis haben, dass diese viele Parallelisierung der Arbeit häufig dazu führt, dass wir nicht so schnell fertig werden und eigentlich haben wir ja auch meistens so ein Helfersyndrom und wollen ja allen irgendwie helfen haben wir plötzlich eine Vielzahl an Aufgaben aufm Tisch und davon wird gefühlt keine so wirklich fertig, weil wir uns nicht auf eine Aufgabe konzentrieren können, sondern ständig zwischen den hin und her switchen. Das passiert genau bei dieser Messung denn so. Also jede Person im Team hat an die sieben Aufgaben. Diese dauern im Schnitt acht Monate durchgelaufen sind und das ist erstmal Status quo, den wir haben. Und dann kann ich mit dem Team da drüber sprechen, mit hey, aus folgendem Grund, eben um diese Vorhersagbarkeit zu haben, um auch mal neue Themen aufnehmen zu können, hätte ich ganz gerne, dass wir mit der Zykluszeit oder der Durchauszeit, Richtung 14 Tage kommen. Ich persönlich messe dabei. [13:59] Zeitpunkt, wann diese Aufgabe angefangen wurde, also wenn die auf das Sprint-Backlog oder auf das Kanban-Bort gegangen ist und nicht, wann sie normal im Backlog gelandet ist, also von wir haben diese Aufgabe angefangen sie ist erledigt, erledigt, 14 Tage. Das ist das, wo ich hin möchte mit meinen Teams und das erreichen wir auch nicht immer. Das ist auch klar, nur so im Schnitt ist das eine gute Größe, wo ich finde, die kann man erreichen. Wenn dein Team schon supergut ist und eure Aufgaben entsprechend klein sind, kann das natürlich sein, dass für euch das auch erstrebenswert ist einen Tag oder sieben Tage oder ähnliches zu überlegt euch eine gute Zahl, die für euch so passt. Ich finde 14 Tage super, wenn ich dann eine Productownerin habe diese Kenngröße hat und diese zuverlässig auch vom Team geliefert wird, dann kann diese Product Onerin damit auch super gut ins Management gehen oder dann dieses Management in den Vorstand oder direkt in den Vorstand. Ist mir auch völlig egal, wie die weitere Kette da drumherum ist. Nur wenn wir das erreicht haben, können alle anderen schneller Aussagen dort treffen in den Gremien, wo sie sind ohne immer direktes Team erstmal noch befragen zu müssen und dann ist es ja auch so Neue Aufgaben [15:11] diese Aufgaben angefangen werden können. Also da kommt jetzt eine neue Aufgabe, die habe ich ins eingetragen. Die ist super wichtig, deshalb packe ich die nach ganz oben ins Backblock, würde ja trotzdem. [15:23] Erstmal noch nicht angefangen, weil alle anderen ja noch mit ihren Aufgaben zu tun haben, die sie jetzt ja schon haben. Also ich habe ja da meine sieben Aufgaben und erst wenn ich die erledigt habe, ne Abstand 8 Monate, dann ziehe ich mit die nächste Aufgabe, um dann wieder meine sieben Aufgaben zu haben, also sobald ich eine davon erledigt habe, ziehe ich mir die nächste, habe dann wieder sieben Aufgaben ne mit einer Durchlaufzeit von 8 Monaten. Daher dauert das ja nicht nur acht Monate der Durchauszeit, sondern vielleicht nochmal so fünf Monate vorher, bis ich diese Aufgabe überhaupt anfange. Und genau da tritt jetzt auch schon der Unterschied zwischen Durchlaufzeit, Durchlaufzeit vs Zykluszeit…

Read More

138 Ein Produkt

Ein Produkt Oft werde ich gefragt „Warum nur ein Produkt pro Person in der Agilität?“. Meist mit einem Unterton, als würde ich unmögliches von den Organisationen oder den sich darin befindlichen Menschen verlangen. Und schon sind wir an dem Punkt, wo Janina Kappelhoff ihre Jugendsünden beichtet… Unser aktuelles Scrum Master Training: https://znip.academy/scrum   Diese Folge…

Read More

136 Continious Delivery (CD)

Continious Delivery (CD) Nach der Folge über Continious Integration müssen wir die Kette mit Continious Deployment und Continious Delivery (CD) natürlich weiter betrachten. Quasi eine CI CD CD Chain. 😀 Diese Folge auf YouTube: https://youtu.be/c_wrVAJcHhE Worum geht es heute? Wir setzen fort, was wir letzte Woche begonnen haben. Continious Delivery ist unter anderem auch Bestandteil…

Read More

135 Continious Integration (CI)

Continious Integration (CI) Heute ist das Thema Continious Integration, kurz CI. Es ist damit der erste Teil einer CI/CD Kette, wie wir sie häufig bei Software-Team vorfinden. Vor allem im Agilem Umfeld. Doch die Prinzipien, die dahinter stecken lassen sich auch auf andere Jobs anwenden. Vielmehr noch: Sie wären auch in anderen Berufen und Umfeldern…

Read More

128 Testmanagement

Testmanagement In dieser Folge geht es darum, was Testmanagement in unserem (Agilen) Umfeld ist, wie man da hin kommt, warum es das nicht nur in der IT gibt und was es mit Psychologischer Sicherheit zu tun hat. Auch Janina Kappelhoff ist wieder mit dabei! Wir (Henry Schneider & Janina) haben überraschender Weise ganz unterschiedliche Erfahrungen…

Read More

118 Planning 2

Planning 2 In der Planning 1 Folge haben wir bereits angedeutet, dass der aktuelle Scrum Guide nicht mehr zwischen Planning 1 und 2 unterscheidet und wir es, allein schon für die Aufteilung der Folgen, trotzdem für sinnvoll halten. Dies ist also die Anschlussfolge zum Planning 1 und beschreibt das Planning-Event zum Start eines neuen Sprints…

Read More

117 Marketing

Marketing In eigener Sache: Psychologische Sicherheit auf 03.01.2023 verschoben – Early Bird bis 30.11.2022 – Studenten kostenlos Passend dazu sprechen wir heute über eine der wichtigsten Aufgaben der Product Ownerin Heute ist Janina nicht da und das wird in nächster Zeit öfter passieren, dass wir alleine aufnehmen. Grund dafür ist, dass unsere Kalender mit Seminaren,…

Read More

Folge 105 Brooks Law

Brooks‘ Law Brooks‘ Law beschäftigt sich damit, dass der Einsatz von zusätzlichen Arbeitskräften in einem verspäteten Projekt dieses nur noch mehr verzögert. Aufgestellt wurde das „Gesetz“ von Frederick Phillips Brooks. Dieses ist auch in der Informatik bekannt, dass Prozesse durch die Aufteilung auf mehrere Prozessoren nicht unbedingt schneller werden, weil die Kommunikationskomplexität, durch die vielen…

Read More

Folge 095 Der Sprint

Der Sprint Heute widmen wir uns dem Sprint. Schon oft angesprochen und auch schon oft Andiskutiert. Beispielsweise bei der Sprintlänge. Beim Sprint handelt es sich um den Namen der Iteration im Scrum. Im Agilen wird häufig in Iterationen, also kurzen Zeitabschnitten entwickelt. Der Sprint ist dabei die Bezeichnung für genau solch einen Zeitabschnitt. Im Scrum…

Read More

Folge 088 Sprintlänge

Sprintlänge Wir haben cooles und vor allem konstruktives Hörer-Feedback auf LinkedIn bekommen. Nämlich vom lieben Simon für die Folge StoryPoints wegstreichen. Danke dafür! <3 Dies hat Janina Wohlert dazu inspiriert die heutige Folge noch nicht über Release BurnDown zu machen sondern erst die nächste Folge. Bestandteile des Feedbacks waren, dass wir häufig den roten Faden…

Read More

Folge 083 BurnDown Chart

BurnDown Chart Heute geht es, endlich wieder mit Janina, um das BurnDown Chart. Ein Artefakt aus dem Scrum. Nicht im Scrum Guide beschrieben und trotzdem ein nützliches Artefakt. Also, wenn Du neben dem Board nach einem möglichen Artefakt im Scrum suchst, könnte das BurnDown Chart eine Antwort sein. Diese Folge auf YouTube: https://youtu.be/-RVYdu4ZdWs Wofür? Und…

Read More

Folge 070 Pull

Pull Heute geht es um das Pull-Prinzip. Warum? Es ist überall in der Agilität und ganz besonders in KanBan. Also heute geht es um das Prinzip des Ziehens. Links Psychologische Sicherheit zyklusbasiert lernen Diese Folge auf YouTube: https://youtu.be/oQ8MxGDrIpU Am Anfang… Für Henry war in der klassischen Projektleitung damals der Umstieg von Push auf Pull eine…

Read More

Folge 060 Videokommunikation mit Olaf Kapinski

Videokommunikation mit Olaf Kapinski Für die heutige Folge habe ich Olaf Kapinski mit dem Thema Videokommunikation gewinnen können. Eigentlich wollten wir über wirksame Kommunikation sprechen, doch das Thema ist so groß, dass wir ein Teilgebiet für Dich daraus gepickt haben. Warum dieser Teil und wie passt er zur Kamera an Folge? Nun mit Olaf Kapinski…

Read More