Kunde

156 Value Stream

Value Stream Für das Thema Value Stream konnte ich glücklicherweise die liebe Lea Lindemann gewinnen. So kam es, dass wir beide darüber ins Gespräch kamen, wo man diese denn in freier Wildbahn findet und wie sie erstellt werden könnten. Die Aufnahme ist vom 15.06.2023, ich habe nur etwas länger gebraucht dafür. 🙂 #Elternzeit Lea Lindemann…

Read More

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

153 Takt

Takt [0:01] Heute geht es um eine der gefährlichsten Metriken, die ich im agilen Umfeld kenne. Diese FOlge auf YouTube: https://youtu.be/QjpnmUagJ88 [0:16] Und herzlich willkommen zum Snipcast, deinem Podcast für Agilität, Persönlichkeitsentwicklung, Psychologie, allem, was für dich Teams und deine Organisation, relevant ist. Schön, dass du dabei bist und los geht’s. Ich bin Henry Schneider und das heutige Thema ist Takt. Was ist Takt in Agilität? [0:35] Hast du bestimmt schon im agilen Umfeld oder in der Produktion gehört und wir haben dem Ganzen noch gar keine Folge gewidmet, daher ist das heute endlich mal, der Fall Wort Takt ist interessant, das ist ein deutsches Wort ist, was international übernommen wurde und auf Englisch eher Kadenz heißt, doch im lean und kann mein Umfeld wird dir trotzdem eher das Wort Takt begegnen Toyota damals von der deutschen Produktion so übernommen hatte und über Cannban dann in der Toyota Produktion so etabliert hat. Takt ist dazu da um so ein bisschen den Herzschlag von unserer Produktion zu haben und da dran dann zu optimieren. Wurde zusätzlich im Umfeld eingeführt, weil wir ja von Push of Pul umgestellt haben. Dazu haben wir eine eigene Folge gemacht, die die Tür dann entsprechend noch mal an hören kannst, wenn dich das Thema näher interessiert und um mit diesem Pool-Prinzip besser umgehen zu können und anhand dieser Fertigungslinie, die wir haben, auch in der Softwareentwicklung entsprechend optimieren zu können, ist es wichtig, eben zum Beispiel die Taktzeit. [1:44] Einzuführen, um zu wissen, okay wie gut sind wir denn genau bei dem Erfüllen der Kundenbedürfnisse und dafür gibt’s eine ganz einfache und das spielt so ein bisschen in das Thema von der Durchlaufzeit oder der rein und ist gleichzeitig trotzdem eine andere Metrik Bei der Durchlaufszeit ging’s dadrum, wie lange dauert es von der Bestellung bis es ist erledigt Jetzt beim Takt geht es dadrum, wie viele Bestellungen bekomme ich rein und kann ich genauso viel eben auch produzieren? Also. [2:17] Das mal auf Scrum wiederum zu münzen, kriege ich mein Backlog genauso schnell abgearbeitet wie dort neue Items drin landen geht es bei der Taktzeit und die lässt sich relativ einfach auch ermitteln, nämlich ist dass die verfügbare Produktionszeit, die wir haben oder die Softwareentwicklungszeit was es auch immer bei dir ist, durch die Anzahl der Kundenbestellung Sprich, wenn ich jetzt ich als Arbeiter, Produktion oder in einer Softwareentwicklung nur drei Stunden pro Woche zur Verfügung habe für reine Arbeit, weil der ganze restliche Kalender gefüllt ist mit Terminen. Eben 180 Minuten wirkliche Arbeitszeit zur Verfügung pro Woche, wenn ich jetzt zwei Produktionsstücke pro Woche dadurch dann herstellen kann, was weiß ich, von mir aus zwei Anforderungen pro Woche abarbeiten kann. Dann eben die hundert1achtzig Minuten durch die zwei zu rechnen und könnte eben nur einen Kundentakt von 90 Minuten pro, befriedigen. Das heißt. [3:22] Nur wenn alle 90 Minuten von meiner Arbeitszeit, also reine wirkliche Arbeitszeit, neue Anforderungen reinbekommen, dann könnte ich das Ganze entsprechend, befriedigen. Kommen jetzt mehr Anforderungen pro Minute ein oder pro Stunde oder pro Zeiteinheit, dann wird der Takt entsprechend eine geringere Zeit ausweisen. Also würde ich jetzt die 180 Minuten durch drei Anforderungen pro Woche teilen müssen, dann hätte ich pro Anforderungen nur noch sechzig Minuten. [3:51] Reine Arbeitszeit zur Verfügung. Und genau dafür ist eben diese Metrik gut, um festzustellen, reicht denn die verfügbare Arbeitszeit überhaupt aus? Die Kundenanforderungen eben zu bedienen. Und jetzt wieder auf eine Automobilproduktion geguckt, für mich dann schon wichtig, okay, habe ich zum Beispiel einen Takt von zehn Minuten. [4:11] Alle zehn Minuten kommt eine neue Kundenabforderung raus und alle zehn Minuten kommt aber auch gleichzeitig ein Auto raus aus der Produktion, dann alles gleich. Brauche ich da nichts weiter optimieren? Gerät das jetzt irgendwie auseinander, also dass ich feststelle, ich kriege weniger Kundenanforderungen rein und mein Takt bleibt weiterhin bei zehn Minuten, also alle zehn Minuten, kommt aus meiner Fabrik ein neues Auto raus. Habe ich wahrscheinlich eine Überproduktion, sprich Verschwendung und die wollen wir ja im und kann mal ein Umfeld vermeiden und möglichst auch in allen anderen agilen Frameworks. Dann habe ich Verschwendung? Kriege ich mehr Anforderungen von Kunden, also mehr Bestellungen von Autos rein? Als ich schaffe durch meine Durchlaufszeit und deshalb haben wir uns die als erstes angeguckt eben entsprechend auch rauszubringen, haben wir auf der anderen Seite Problem, dass wir die Kundenanforderungen, also die Bestellung, nicht schnell genug abarbeiten können. Und ich habe ja eingangs gesagt, Gefährliche Metrik [5:07] Das ist jetzt eine richtig gefährliche Metrik, denn viele Firmen, die genau diese Metrik benutzen, die gucken nicht, wie können sie anhand dieses Durchflusses entsprechend optimieren die optimieren nur anhand des Taktes und messen auch ihre Menschen da dran. Und das kann dazu führen. [5:24] Einfach nur sinnlos durchproduziert wird, um den möglichst guten Takt zu halten, statt dadrauf zu gucken, was es eben wirklich, und das kann sein, dass dadurch haufenweise kaputte Autos einfach produziert werden, um diesen Takt zu halten, statt dadrauf zu gucken, was da für in dieser ganzen Kette optimiert werden, um. [5:42] Die Produkte auszubringen. Das passiert vor allem, wenn wir in unseren Unternehmen eine Nachbereitung haben oder nachgelagertes Testmanagement oder irgendwas von in der Softwareentwicklung von der Entwicklung in den Betrieb übergehen dann der Betrieb sich um zum Beispiel die ganzen Support-Anfragen oder Ähnliches, Deshalb ist das eine ganz gefährliche Metrik, wenn ich einfach nur den Takt einführe, ohne jetzt wirklich darauf zu gucken, warum interessiert mich das überhaupt. [6:13] Zeit. Warum interessiert mich das überhaupt und ich den Menschen jetzt vielleicht auch noch irgendwie Incentives drauf gebe oder sogar die noch mit anderen Teams und deren Takt vergleiche und es vielleicht sogar Repressalien gibt, wenn der Takt nicht mindestens so gut ist wie der andere, oder jedes Jahr eben der Takt noch mal ein Stückchen mehr verbessert werden muss, dann kann es dazu führen, dass alle nur drauf gucken, diesen Takt möglichst gut zu halten, statt eine gute Qualität zu liefern. Daher, möchte ich dir auch anraten, diese Metrik, Taktzeit wirklich nur mit Augenmaß einzuführen und wirklich nur, wenn du weißt, was du tust ihr auch alle wisst, wofür ihr das tut. Ansonsten hat der Takt natürlich auch viele Vorteile, Vorteile vom Takt [6:57] nämlich können wir unsere Produktion anhand der wirklichen Kundenbedürfnisse auch optimieren, also so, dass wir nicht zu viel Lagerhaltung haben, weil wir einfach zu viel produziert, sondern dass wir entsprechend unseren Takt jederzeit dadran anpassen können, wie viele Bestellungen kommen denn überhaupt rein oder wie viele Anforderungen gibt’s denn von unseren Stakeholdern an unser Team? Wir können die Effizienz optimieren und wir werden vor allem eben auch vorher sagbarer. Da ging’s ja schon genau bei der Durchlaufszeit auch dadrum. [7:25] Vorhersagbarer zu werden, weil der Taktzeit ist es eben genauso. Kenne ich meine Taktzeit und kann anhand der eben auch optimieren. Dann bin ich eben auch aussagekräftig gegenüber anderen Gewerken und weiß eben auch, wie viel können wir denn in Zukunft zum Beispiel leisten weiß, so ein Auto ist halt so die Kette ist länger, das ist mir völlig klar. So ein Auto ist nicht unter zehn Minuten zu produzieren und ich kriege allerdings mehr Nachfragen rein, dann kann ich da entsprechend frühzeitig schon die Hand heben sagen, das ist zu viel. Wir dürfen da irgendwie anpassen. Und eine Anpassung könnte auch der Preis sein, dass zum Beispiel der Preis hochgeht eine höhere Marge in unserem Verkauf haben weniger Bestellungen reinkommen und dann in die Richtung optimiert wird, dass genauso viele Bestellungen reinkommen, wie unsere Produktion eben auch leistbar ist Das können wir auch bei Softwareteams machen, wenn wir da eben unsere Taktzeit kennen, können wir entsprechend optimieren, auch von mir aus am Preis oder dass wir sagen, okay, wir brauchen jetzt mehr Softwareentwicklerinnen in unserem Team, um eben die Anzahl der Anforderungen, die reinkommt, eben auch in gleicher Anzahl auch hinten raus dann, also nach dem Review, eben auch, abfrühstücken zu können. Das ist so deshalb durchaus Zeit und Taktzeit. [8:42] Kommt aus, sind ganz gute Methoden und auch gleichzeitig supergefährliche Metriken, wenn wir nicht genau wissen, was wir tun, warum wir es tun Herzschlag [8:52] Habe ich ja auch gesagt, dass der Takt so ein bisschen der Herzschlag des Ganzen ist. In der Produktion können wir uns das gut vorstellen. Das ist halt alle zehn Minuten kommt ein Auto raus aus der Produktion, also zack, das ist unser Herzschlag. Alle zehn Minuten schlägt das Herz, weil zack neues Auto raus. Und so ist es auch in anderen Gewerken, auch in kreativen Gewerken genau diese Taktzeit oder jetzt nur Takt genannt, eben unser Herzschlag sein. Ihm kann man ist es dazu gedacht, um da regelmäßige Zeitpunkte zu haben, wo wir einmal durchatmen können. [9:25] Auf unseren Prozess gucken können und an unseren Prozessen optimieren können. Also einmal wirklich Ruhe reinbringen in das ganze System. Dann gucken, okay, wo können wir vielleicht noch optimieren, wo können wir noch Verschwendung vermeiden, wo können wir vielleicht auch effizienter werden? Und jetzt hast du dich vielleicht sogar schon gefragt, na ja, äh gut, jetzt begegnen mir das, aber häufiger mal im Scrum oder auch gar nicht. Vielleicht stellst du dir sogar die Frage, der Henry hat gesagt, hier der Takt gehört zu den agilen Metriken oder ist es ein agiles Wort? Im Scrum Guide finde ich das vielleicht sogar gar nicht. Das ist an der Stelle wieder implizit eingebaut, nämlich da ist der Takt zum Beispiel, Sprintzyklus, unsere Interaktion, die wir im Sprint machen, da wird dir schon aufgefallen sein, dass genau beim Sprintwechsel genau dieses Durchatmen passiert, also dieses, noch das Review abnehmen, dann Retrospektive, um unsere Zusammenarbeitsmodell zu optimieren, dann gehen wir ins Blenning für die nächste Itaration. Genau an diesem Zeitpunkt passiert Taktzzyklus. Das Nächste. Also im Scrum sind es die Iterationen und Scrum ist ja nicht das einzige agile Framework. Es gibt ja noch unter anderem würde ich auch Kanban dazu zählen, auch wenn es eher aus dem Lean Bereich kommt, doch wir haben auch XP oder es gibt auch Defops Methoden wie. [10:43] Entsprechend auch ihren eigenen Takt haben. Und so können wir auch im Canvan eigene Takte für eigene Rituale und Routinen eben auch etablieren. Genauso ist auch das Deli durchaus ein Takt, weil es ja täglich stattfindet und das wieder so einen Zeitpunkt zum Durchatmen sein kann Ist uns an der Snippe Academy das auch unglaublich wichtig, dass das Daily wirklich an jedem Tag zur selben Zeit am selben Ort stattfindet, um dann nicht noch mehr Kompliziertheit drauf zu packen sondern wirklich so ein Moment, der Ruhe auch zum Durchatmen und zum gemeinsamen Synchronisieren zu, Wenn wir das agile Framework-Pulse oder Pulse Spot einsetzen, glaube ich sogar noch offensichtlicher, denn da geht’s ja um den Puls, dass der Takt eben genau und dieser Puls eben sein kann, dieses Palz-Meeting, also das Meeting vom Pulsboard, wo alle Gewerke anwesend sind einmal den Projektstand schnell durchsprechen können und danach ihre haben dass es dann auch wieder der Takt. Und wenn das jetzt nur einmal pro Woche stattfindet, dann ist das eben genau der Takt Genauso wenn im Scrum eure Iterationszeit, also eure Sprintlänge drei Wochen ist, dann habt ihr einen Drei-Wochen-Takt könnt sagen, okay, alle drei Wochen haben wir 20 Anforderungen umgesetzt. Das wäre dann eben genau diese Metrik dann die Product Onerinnen entsprechend in die anderen Gremien auch reingehen könnte und wirst du, okay kommen mehr Anforderungen als 20 pro. [12:13] Also pro Sprint rein, dann dürfen wir da vielleicht nochmal, optimieren. Und ja, mir ist klar, dass grade im Kreativbereich, wo wir vor allem in der Softwareentwicklung unterwegs sind, dass nicht alle Werkstücke gleiche Größe haben, doch wir werden über die Zeit so einen Mittelwert bekommen, Also wenn ihr sechs mal gemessen habt, werdet ihr einen Mittelwert für das Team haben und könnt dann in der Retrospektive gemeinsam entscheiden, wollt ihr dadran optimieren, vielleicht mehr Anforderungen gleichzeitig zu schaffen die vielleicht kleiner zu schneiden oder vielleicht vorher besser zu beschreiben oder eben nicht, weil die Taktzeit, die ihr habt, schon ganz gut zu dem Umfeld passt, was ihr, Häufiger Fehler von Menschen, die ausm klassischen Bereich kommen und ich habe das Gefühl, ich war damals als Projektleiter auch so. Meilensteine [13:01] Dass wir die Meilensteine in unserem Projekt mit dem Takt gleichsetzen, weil die Meilensteine auch, gab uns regelmäßig im Jahr passieren oder vielleicht sogar irgendwie quartalsweise, wenn wir sagen, okay, das ist so ein Zeitpunkt zu kommen, da ans nächste Gewerk zu übergeben oder in die nächste Projektphase übergehen. Dem ist allerdings nicht so, dass die Meilensteine auch, den Takt entsprechend. Es ist wiederum eine andere Sache und das ist ein anderes Projektsteuerung. Mechanismus, denn der Takt ist wirklich regelmäßig und der sollte sich generell die ganze Zeit immer durchziehen in gleicher Länge Dass ich da immer an den gleichen Punkten auch messe und daran optimiere, wie viel, also Quantität komme ich da entsprechend, durch und deshalb geht es eher um die Effizienzsteigerung statt um die Effektivitätssteigerung. [13:55] Und wie immer ist es so, dass auf Teamebene, also wenn wir unser Scrum-Team haben mit unseren, Skaliert wirds interessant [14:04] 7 Entwicklerinnen der Projekt Ownerinnen und der Scrummasterin. Dann ist das Ganze noch relativ einfach, also vor allem in Richtung Backlog, wie viel kommt rein, wie viel geht raus? Wie ist unsere Zykluslänge und was können wir da bewältigen und vielleicht auch die Effizienz Zu optimieren, falls es erforderlich ist. Oftmals ist es gar nicht erforderlich, Interessant im skalierten Umfeld, wenn plötzlich noch andere Teams um uns herum sind, mit denen wir auch interagieren dürfen, wo wir vielleicht sogar gemeinsame Anforderungen haben, denn dann sind genau die Takte, die wir festgelegt haben und das ist jetzt der Unterschied, agieren, wenn wir nur von Takt sprechen, ne? Das kann jetzt unsere Interaktionslänge sein oder von der Taktzeit, das ist ja alle wie viel Minuten kommt etwas raus. Also Takt ist Vietration und Taktzeit ist alle wie viel Minuten kommt zu einer Anforderung raus. [14:52] Und das kann im Defox-Team habe ich schon häufiger erlebt auch sein, die Anforderung ist fertig und wird direkt released und bei Scrum-Teams, die grade erst anfangen, ist es häufig so, dass erst alle Anforderungen abgearbeitet sind und dann gibt’s ein Release. Je nachdem, wie das bei dir schon in Richtung Continuous Integration und Continuous Delivery aufgebaut ist, kann das sein, dass ihr schon genauso eine Taktzeit habt dass die Taktzeit dann eben immer genau zum Sprintwechsel passiert oder wenn ihr eine, Termin habt. So und wenn wir jetzt andere Teams um uns herum haben, ist das eben auch dann entscheidend, welchen also Iterationslänge sie haben. Wenn wir zum Beispiel jede Woche, also unsere Sprintlänge, eine Woche ist, dann können wir ja jede Woche, neu abstimmen, vielleicht in einem globaleren Backlog uns neue Anforderungen nachziehen, die entsprechend abarbeiten und wenn’s dann andere Teams um uns herum gibt, die eben alle vier Wochen, nur ihren Sprintwechsel haben, dann das schnell zu Problemen vielleicht sogar Verwerfungen führen. Das kann aber auch alles ganz gut laufen und wenn jetzt auch noch die Tage unterschiedlich sind, also das eine Team hat einen Sprintwechsel immer am Montag und das andere hat es immer am Donnerstag. [16:07] Dann entsteht da vielleicht so ein bisschen luftleerer Raum dazwischen, der, besser genutzt wäre, wäre dieser Synchronisationszeitpunkt, also mit den Takten, dass sie dann gleich synchronisiert sind, besser am gleichen Tag zu haben für eventuelle Abstimmung, denn, Wenn das eine Team am Montag sein hatte und das andere erst am Donnerstag braucht es vielleicht Ergebnisse von dem anderen Team, was erst später plant oder, die Rückmeldung, ob die das jetzt in ihren nächsten Zyklus mit übernehmen oder nicht Daher kann das schnell auseinander geraten, deshalb ist gerade wenn wir uns auf skalierte Ebene begeben, der Takt umso wichtiger Die meisten skalierten Frameworks nehmen dadrauf auch Rücksicht. Also ich denke da so an Save zum Beispiel, die die PI Plannings haben, die entsprechend alle paar Wochen oder Monate stattfinden und wo alle gleichzeitig….

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 015 Weitere Rollen

Weitere Rollen Mit dem Rollen Thema sind wir noch lange nicht durch und machen direkt weiter. Gehören Stakeholder und Kunde zum Team oder stehen die Rollen außerhalb? Ja und Nein ist die Antwort im Podcast. 🙂 Das Team sollte eine feste stabile Menge sein um die Teamdynamik im Griff zu haben und gleichzeitig ist es…

Read More

Folge 014 Überblick zu Rollen

Kurzüberblick zu Rollen Rollen? Vom Yoga? Oder unterm Stuhl? Lass uns eine Defintion für Rollen finden. Wie viele Rollen sind im Scrum Guide beschrieben? 3, 4 oder gar 5? Du erfährst es hier! Produktverantwortlicher Wir haben den Product Owner. Dazu haben wir bereits 3 Folgen gemacht. Methodenverantwortlicher Also schauen wir uns den Scrum Master näher…

Read More