Teamschnitt – Agiler Stolperstein Der Teamschnitt ist ein oft übersehenes Mittel, welches nicht nur bei agilen Teams enormes Potential bietet. Links Heldentreff: https://znip.academy/heldentreff Agile Master Ausbildung: https://znip.academy/agile Diese Folge auf YouTube: https://youtu.be/67nhXUSV7g8 Kapitel 00:00 Intro 00:26 Agile Stolpersteine 00:40 Das Thema 01:14 Häufige Fehler 02:01 Woran merke ich einen ungünstigen Teamschnitt? 03:31 Heldentreff Agile Stolpersteine... The post 158 Teamschnitt https://znipcast.de/blog/158-teamschnitt/ appeared first on Znipcast - für gute Zusammenarbeit | Agile, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

3m

Feb 19, 2024

Agilität in der Selbstständigkeit Wie kann Agilität in der Selbstständigkeit eingesetzt werden? Disclaimer: Es geht hier nicht um Alkohol, sondern um die Journey, die Marcel Hepke mit seinem Unternehmen erlebt. Alkohol ist schlecht für euren Körper, daher fangt am besten gar nicht erst damit an. Wir verzichten daher auf konkrete Links zu Produkten und geben... The post 157 Agilität in der Selbstständigkeit https://znipcast.de/blog/157-agilitaet-in-der-selbststaendigkeit/ appeared first on Znipcast - für gute Zusammenarbeit | Agile, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

29m

Jan 22, 2024

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... The post 156 Value Stream https://znipcast.de/blog/156-value-stream/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

49m

Oct 09, 2023

Feedback Chapters 0:00:34 Das Thema 0:01:01 Was ist Feedback? 0:04:57 Was möchte ich haben? 0:06:45 Kundenfeedback 0:07:42 Tochter an Bord! 0:08:00 Am Produkt 0:09:22 Mitarbeitergespräche (MAG) 0:09:55 Wie kriege ich Feedback? 0:13:04 Raum geben 0:15:00 Welches Feedback möchte ich? 0:15:47 Anonymität 0:18:48 Hierarchie im Feedback 0:20:20 Zusammenfassung Long Summary In diesem Podcast geht es um... The post 155 Feedback https://znipcast.de/blog/155-feedback/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

24m

Jun 26, 2023

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?... The post 154 Produkt vs Projekt https://znipcast.de/blog/154-produkt-vs-projekt/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

29m

Jun 03, 2023

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.... The post 153 Takt https://znipcast.de/blog/153-takt/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

22m

May 20, 2023

Menschen lesen Bundle https://znip.academy/mk Kapitel 00:00 Worum geht es? 00:10 Für Studenten & Alumnis kostenlos 01:18 Warum 3 Module? 02:18 Worum geht es beim Menschen lesen? 03:04 3 Module 05:00 Workbook 05:58 What is in for me? 07:23 Bundle The post Eigenwerbung Menschen lesen Bundle https://znipcast.de/blog/eigenwerbung-menschen-lesen-bundle/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

8m

May 17, 2023

Cargo-Kult [0:00] Beim Schneiden der letzten Folgen aufgefallen, dass ich häufiger das Wort Cargo Kult verwende und wie das im Podcast noch nie erklärt. [0:08] Music. [0:18] Herzlich willkommen zum mein Name ist Henry Schneider und wir unterhalten uns über Themen wie Agilität, Mindset, entwickeln und allem was für dich und deine Teams relevant ist. Schön, dass du dabei bist und los geht’s. [0:34] Schon im Intro erwähnt habe, ist das heutige Thema Cargo Kult, denn es ist ein Begriff, den ich ab und an mal verwende, um bestimmte Dinge zu beschreiben. Diesen Begriff Allerdings im Podcast noch nie beschrieben habe, das holen wir heute nach. Beim geht es um ein Phänomen, was man häufig beobachtet, wenn ich sage mal Invasoren, Was ist Cargo-Kult? [0:55] auf indigene Bevölkerung, meist auf irgendwelchen Inseln oder Ähnliches treffen und der Technologieunterschied sehr groß ist. Kommt es eben dazu, dass die indigene Bevölkerung eben Menschen ähnliche Wesen sieht, die häufig auch eine andere Hautfarbe haben und daher mit Göttern oder Uranen assoziiert werden, weil die Technologie eben so ein Riesenunterschied macht, denn die können offensichtlich Dinge tun, die die indigene Bevölkerung nicht kann, Das ist so im Groben schon der Einstieg in Cargo Kult, denn da ist schon dieses okay, wenn die Dinge besser können, Müssen das quasi Götter oder Ahnen sein. Das Nächste ist das Kaugut, also das englische Wort für Frachtwaren, Ähnliches schon im Namen mit eingebaut ist. Also da drum geht es. Diese, ich sage mal Invasoren oder diese. [1:50] Menschen bringen eben Waren mit auf die meist Inseln, die die in die Genenbevölkerung noch nie gesehen haben und das kann so was wie ein Radio sein, wo plötzlich, Geräusche, Musik stimmen aus einem technischen Gerät kommen, obwohl das gar keine Menschen sind. Kann man sich wahrscheinlich gut vorstellen, wenn man so was vorher noch nie gesehen hat. Das ist Wahnsinn, was die plötzlich drauf haben, für diese gibt es jetzt verschiedenste Entwicklungen, also es gibt einige, die sich vor allem auch sehr stark halten, haben so christlichen Hintergrund und Andeutungen von christlichen Glauben und es gibt Cargo Kulte, auf die ich mich eher beziehe, die sich primär im Zweiten Weltkrieg gezeigt haben, beziehungsweise, danach vorwiegend eben erst mal untersucht wurden und aufgedeckt wurden, beispielsweise auf Hollandier, heute JAYY purer heißt, wo es so war, dass die amerikanischen Militärs auf dieser Insel relativ viele. [2:54] Stationiert hatten, also bis zu 400.000 Menschen, um die zu versorgen einfach mit Frachtflugzeugen da drüber per Fallschirm eben dieses ganze Cargo abgeworfen haben beziehungsweise auch auf also es ist klar so viele Truppen und so viel Material was sie da brauchen Landebahn und ähmnliches gebaut haben, um dort eben dieses ganze Cargo hinzubringen und quasi die Truppen dort mit überschwemmt haben dadurch eben auch diese indigene Bevölkerung indigene Bevölkerung hat das jetzt nur beobachtet und hat sich gedacht, ah entweder das sind unsere Ahnen und Götter, Die bringen uns jetzt all diese tollen Waren oder das hat sich dann über die Zeit erst ergeben, dass ich festgestellt habe, nee, das sind auch nur Menschen, die haben eine andere Hautfarbe und die haben’s irgendwie herausbekommen, unsere Ahnen zu bestehen und genau diese Fracht, und gehen dann davon aus, mit dir Ahnen kommen irgendwann wieder, ne, Tag des jüngsten Gerichts und so was, neben diesen Dieben, das ganze Cargo wieder weg geben uns das wieder zurück, weil das soll eigentlich uns als die indigene Bevölkerung eben dienen uns eben diesen Fortschritt. Was Du siehst ist nicht immer das, was es ist [4:06] Was sie gesehen haben, ist die Kommunikation mit den Ahnen, dass eben entsprechend das Kago kommt. Daher haben sie gesehen, Es wurde viel Wald gerodet und platt gemacht, um eine entsprechend leinende Bahn aufzubauen. Dann wurden da hohe Türme aufgebaut, wo Menschen drinnen sitzen, die die ganze Zeit nach rechts und links schauen und riesen. [4:27] Hörer aufhaben. Und zusätzlich wurde an diesen Landebahnen im Leuchtfeuer errichtet, was eben so in Wellen, angezeigt wird. Nach dem Zweiten Weltkrieg sind die US-Militärs einfach von diesen Inseln verschwunden. Also es ist nicht nur auf dieser einen Insel passiert, es ist auf mehrere Insel passiert. Und plötzlich piept das Cargo aus. Now the problem [4:46] Was haben die indigenen Bevölkerung daraus abgeleitet? A die müssen ähnliche Dinge tun. Das heißt, die haben ihre Wälder gerodet. [4:54] Haben mit Feuer entsprechend mit Fackeln dann sich neben diese Landebahn gesetzt und dann in Wellen diese Leuchtfeuer emittiert, die haben sogar ihre Häuser durchaus abgebaut, um größere Türme aufzubauen, wo dann Menschen eben drin sitzen, die mit aus Holz geschnitzten oder aus Kokosnüssen gebauten Ohrhörern innen drin sitzen und nach rechts und links schauen beziehungsweise den Himmel beobachten in der Hoffnung, dass das Cargo wiederkommt Hoffnung, dass diese Ahnen wiederkommen, denn sie haben begonnen auch ihre Vorratshaltung, abzubauen, also dass sie ähm quasi keine Nahrungslager mehr besaßen, weil es kam ja jetzt über Jahre ständig Cargo vom Himmel und das war viel besser, es war in Dosen verpackt genauso Kleidung und Ähnliches. Es kam plötzlich alles von Himmel und das brauchen sie alles nicht mehr selbst herstellen, sondern einfach nur noch dadrauf warten, Das haben sie jetzt übernommen in quasi die heutige Zeit, dass sie neben den Landebahnen einfach nur dadrauf warten, hat quasi deren eigene Kultur, die sie hatten, zerstört. Ohne genau das zu erreichen, was die Menschen erreichen, die sie imitieren, nicht genau verstanden haben, was dahinter liegt. Sie konnten sich nicht vorstellen, dass es noch andere größere Landmassen gibt, wo diese Sachen zum Beispiel hergestellt werden sie da nur hingeschickt wird, weil das haben sie nicht beobachtet, also genau diese Hintergründe dahinter. Agile Organisationsentwicklung [6:20] Und diese Metapher verwende ich ganz gerne im Agil, weil auch da sehe ich sehr häufig. [6:26] Man sich andere Firmen anguckt, die agil arbeiten, beispielsweise in Google und, Nur das, was man an der Oberfläche beobachtet, in die eigene Firma mitnimmt, dort versucht zu imitieren, um gleiche Ergebnisse zu erreichen Mein Hauptbeispiel ist, plötzlich tragen alle Turnschuhe und haben T-Shirts an und stehen viel rum und das muss auch dazu führen, dass Unternehmen plötzlich viel flexibler ist, dass es besser am Markt agieren kann, dass wir eben agil sind. Da merken wir eben, dass es nur dieses Gesehene an der Oberfläche imitieren, ohne, Zu wissen, was steckt denn alles genau dahinter, was hat denn dazu geführt, dass wir genau. [7:08] Diese Events haben, dass wir diese Rituale haben, dass wir diese Praktiken leben und genau da liegt eben auch dieser Unterschied. Häufig kennen wir wahrscheinlich auch diesen Begriff Zombie-Scrum dazu. Also, Siehe aus wie Scrum nur Herz und Hirn, die sind einfach tot. Und deshalb ist es einfach nur so ein Mit ihr. Ja, es sieht auf der Oberfläche so aus, nur wirkliche Scrum ist es nicht, weil eben genau das Herz und der Verstand dazu fehlen. Dadurch kein wirkliches Crumb gelebt wird und eben, nicht die Ergebnisse erzielt werden, die man eigentlich damit haben möchte. Wenn man sich nicht genau genug damit beschäftigt hat, was steckt denn dahinter, was sind denn überhaupt die Werte, die wir leben, wie kommen wir zu diesen Praktiken? Was ist es denn? Weil man sich manchmal davor scheut oder nicht genug Zeit hat, sich dafür einen Experten ranzuholen, der eben genug Zeit in dieser Sphäre schon verbracht hat und genau das jetzt eben, einem selbst auch. Was machen die anderen? [8:08] Weiteres Wesentliches, was ich in vielen Unternehmen eben auch beobachte, ist, dass sich angeguckt wird, so in der näheren Konkurrenz oder allgemein in der Wirtschaft, was sind denn die Frameworks, die da primär eingesetzt werden? Ist es gerade bei Großkonzernen häufig, safe einfach geguckt wird ah die Telekom die macht safe hm Volkswagen macht safe, die Eon und Airbus die machen auch safe also muss das das richtige Framework sein. Wir machen auch safe. [8:38] Vorher zu gucken, ist denn das das Framework, was zu uns passt, auch ohne zu gucken, Welche Ergebnisse erzielen denn genau diese anderen Firmen jetzt mit diesem, in meinem Beispiel jetzt dem Safeframework? Es gibt noch viel, viel, viel mehr Frameworks, Nexos und Spotify und und Flight Levels, ohne zu gucken, was erzielen die mit diesen Frameworks und passt denn dieses Framework auch zu der Firma, in der ich bin, Jede Firma hat ihre eigene Kultur und da passt nicht unbedingt zwangsläufig jedes Framework dazu. Ich gehe sogar noch einen Schritt weiter. Ich glaube sogar, dass über die Zeit jede Firma mit genug Erfahrung ihr eigenes Framework wird, dass eben gut zu der Firma passt, doch als Einstieg würde ich auch erstmal schon ein gut beschriebenes Framework nehmen nur nicht vielleicht aus dem Eindruck mit Da drüben hat’s funktioniert und deshalb machen wir das jetzt 1:1 genauso, beziehungsweise nicht 1 zu 1 genauso, sondern wir machen nur das, was wir auf der Oberfläche sehen und das könnten auch bei anderen Unternehmen vielleicht irgendwie Steuerkreise sein, die wir jetzt einfach nur imitieren Wir haben gesehen, oh ja, die sind erfolgreich, die haben Steuerkreise, also machen wir jetzt auch Steuerkreise. Das ist es häufig nicht, also da da steckt viel, viel mehr dahinter, was. [9:52] Unter der Oberfläche ist, also typisches Eisbergmodell, da ist super viel unter der Oberfläche los und wir sehen eben nur dieses Stückchen oben und das Stückchen zu imitieren reicht nicht aus. Deshalb nehme ich als Metapher eben ganz gerne diese Cargo-Kulte auch die indigenen Bevölkerung, die haben die Flugzeuge mit Stroh in eins zu eins Maßstab nachgebaut und auf diese Landebahnen gestellt. [10:15] Alleine, also nur, dass man da ein Flugzeug hat in der Größe und diese Landebahn und so weiter nicht automatisch dazu, dass ich dieses Cargo, also diese Waren, erhalte, die von den Göttern plötzlich gesendet werden. Da gehört eben noch viel, viel mehr dazu, nämlich, dass ich irgendwo eine andere Produktion habe, dass ich entsprechend Flugzeuge auch bauen kann, die fliegen können das dann entsprechend abwerfen, dass ich das Ganze auch gut verpacken muss. All das steckt dann noch dahinter. Es reicht nicht nur dieses Stückchen Gesehne an der Oberfläche zu, Was kann ich tun, damit mir das... The post 152 Cargo-Kult https://znipcast.de/blog/152-cargo-kult/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

17m

May 13, 2023

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... The post 151 Warum sollte ich Agilität einführen? https://znipcast.de/blog/151-warum-sollte-ich-agilitaet-einfuehren/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

22m

May 04, 2023

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... The post 150 Durchlaufzeit https://znipcast.de/blog/150-durchlaufzeit/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

37m

Apr 29, 2023

Agile Master Seminar: https://znip.academy/agile Meta-Studie: https://znipcast.de/149/Q1   [0:00] Habe heute ein Thema mitgebracht, was du garantiert richtig, krass findest und zwar die Metastudie zum Thema Kreativität und was das mit Agilität zu tun hat, warum das für dich wichtig ist, warum das für dich arbeitsplatzsichernd ist, das Und vor allen Dingen was Kreativität eigentlich steigert, das erzähle ich dir heute. Los geht’s. [0:23] Music. [0:42] Organisationen und ganz, ganz viel Teamentwicklung. Mein Name ist Janina Kappelhof, schön, dass du heute da bist, und äh ja, los geht’s. Ich habe euch heute ein Thema mitgebracht, das wahrscheinlich bei dir in LinkedIn oder in verschiedenen Newsfeed Das Thema [1:00] sowieso schon reingespült wurde. Und ich finde das Thema gerade jetzt so interessant, weil es so eine Frage ist, die einfach wahnsinnig viele Unternehmen grade, umtreibt Wir uns solche Entwicklungen und kleine Ausflüge Richtung künstliche Intelligenz angucken, so was wie Chat-GPT, was maßgeblich beeinflussen wird, wie wir lernen und studieren, aber auch wie wir arbeiten. [1:26] So ein bisschen die Frage über, was sind denn die Kompetenzen und die Fähigkeiten, die wir in Zukunft überhaupt noch brauchen werden? Wo lohnt es sich denn Dass ich als Führungskraft meine Mitarbeitende weiterentwickle oder wo lohnt es sich denn, wenn ich Mitarbeiter bin Welche Fähigkeiten sollte ich denn in den Mittelpunkt stellen und besonders fördern? Und eine dieser Eigenschaften, die es da. [1:50] Besonders hervorzuheben gibt, ist das große Feld der Kreativität. Es gibt im Moment wahnsinnig viel solche Buzzwells wie Kreation, also wie arbeiten wir eigentlich? Wie arbeiten wir zusammen? Wie sind wir zusammen in Teams und in Gruppen kreativ, aber eben auch die Frage, was macht eigentlich persönliche Kreativität aus? Ja, wozu denn eigentlich Kreativität? Viele Unternehmen, die wir so. [2:17] Begleiten oder denen wir begegnen, die müssen, die sind in der Zwangslage grade zuschonen, innovativer und Weiterentwicklung von ihren Produkten permanent auf den Markt zu bringen. Also die Samen ja, fast schon Innovationszwang, einfach weil durch die Digitalisierung die Märkte schnelllebiger geworden sind weil durch die Globalisierung die Märkte kleiner und größer zugleich geworden sind. Ich habe halt nicht mehr nur Konkurrenz ausm Nachbardorf oder noch aus Europa, sondern ich habe weltweite Konkurrenz, die sich um den gleichen Markt und die gleichen Kunden bemüht und deswegen eben so eine Art Kreativitäts-Wettrennen entstanden ist und das spielt ja auch Agilität mit rein, Agilität, die schnelllebige Märkte, anpassungsfähigkeit, Kreativität, auf Selbstorganisationslevel und auf enge Feedbackschleifen mit Kunden im Mittelpunkt stellt, dass Agilität also ein Riesenthema. Meta-Studie [3:17] Jetzt gibt es diese neue Studie und das ist eine Metastudie, Metastudie heißt übrigens, dass sie sich verschiedene andere Studien anguckt. [3:26] Im Moment heißt es in der Presse überall Metastudie, aber es geht nicht um um Meter oder um Also um die Firma Meta oder das ist jetzt irgendeine Abkürzung wer im Kreativitätskontext sondern, Es ist einfach eine Studie, die sich 84 andere Studien anguckt die Studienlage aus den Jahren 2000 bis 2021 aus verschiedenen Fachgebieten, also sowohl Psychologie als auch Wirtschaftsinformatik beziehungsweise Informatik und da mal so ein bisschen vergleicht, was ist in diesen Studien so ein bisschen widersprüchlich und was sind dieselben Aussagen? Wenn wir das noch statistisch irgendwie belegen können, was ist dann das Ergebnis, was eigentlich Kreativität steigern kann. Also wir befassen noch mal zusammen, Agilität möchte gerne mehr Kreativität, in den Teams, in den Einzelpersonen. Ich glaube, dass so was wie Selbstorganisation sich vor allen Dingen auf das Thema Kreativität, Lösungsfindung, Problemlösung bezieht und dafür brauche ich Kreativität. Als Unternehmen oder als Produktentwickler oder Dienstleister einfach auch einen gewissen Grundsatz an Innovationsfähigkeit, um am Markt erhalten zu bleiben und deswegen glaube ich, Kreativität wahnsinnig eng verknüpft ist mit Agilität. Gleichzeitig haben wir solche Technologien wie. Technologischer Fortschritt [4:49] Einfach einen wahnsinnigen Fortschritt bedeuten. Wir haben heute Handys, wer vor 20 Jahren schon erwachsen war, so halbwegs erwachsen, so wie ich der kann sich dran erinnern, dass wir ohne Internet und ohne Google Maps unterwegs waren und dieser technologische Fortschritt, der macht einfach auch möglich, dass wir diesen Fortschritt in der Hosentasche haben und macht es eben auch nötig, dass wir mit diesen Fortschritten, mit dieser Schnelllebigkeit umgehen lernen. Also ist ganz existenziell für unser menschliches Wohlbefinden, dass wir einen gewissen Grad an Kreativität und vielleicht auch solche Eigenschaften wie Mut kultivieren können als Einzelperson, aber eben auch als Gesellschaft. Die Studie [5:29] Jetzt will ich euch nicht weiter auf die Folter spannen, bevor ihr jetzt anfangt, einfach die Metastudie zu googeln, das Effektivste. Was Kreativität fördern kann und Kreativität liest sich übrigens bei 70 Prozent aller Teilnehmenden tatsächlich steigern, also Kreativität ist etwas, das sich steigern lässt, und das effektivste Mittel dafür waren zeitaufwendige und ausgiebige Trainings, die gezielt auf Kreativitätstechniken abzielen. Ich finde das so interessant, weil wir in der Agilitäts-Bubble beobachten können, dass die Unternehmen und Führungskräfte möglichst kurze und möglichst zeitknappe Trainings ihren Mitarbeitenden geben. Also da wird wirklich um jeden Tag gefeilscht. Wir wollen aber unseren Mitarbeiter nicht drei Tage abgeben. Wir wollen nur zwei Tage abgeben. Könnt ihr das untertreffen? Können wir da was rauskürzen? Also wirklich dieses dieses zeitintensive und ausgiebige macht Trainings erst überhaupt effektiv und ich glaube, dass man das übertragen kann dieser Metastudie über Kreativität hin zu Agilität, weil beides eben nicht wirklich Fähigkeiten. [6:39] Sondern so eine Art Kombination, ein Zusammentreffen von Einstellungen, individuellen und internen und externen Erwartungshaltung und eben auch so eine Art Übungsfaktor darin ist und Agilität ist da finde ich Kreativität sehr ähnlich. Also das effektivste Werkzeug, um Kreativität oder eben auch Agilität zu fördern, sind meiner Meinung nach und der Studie nach. [7:06] Kreativität, zeitintensive und ausgiebige Trainings, die wirklich über Wochen gehen, die vernünftiges Trainingsmaterial haben sind die vor allen Dingen Assoziations und Kreativitätsübungen beibringen und die nicht nur beibringen im Sinne von hier könnt ihr sie nachlesen, sondern sogenannte Figurale Methoden benutzen, also wirklich das, erlebbar machen und betrachten ein und derselben Assoziationsübungen aus verschiedenen Perspektiven. Also ich muss diese Übung einmal erlebt haben, um sie effizient in einer anderen Situation. [7:40] Anwenden zu können. Und ich muss dir auch reflektiert haben diese Assoziationsübung, mein Verhalten oder das Verhalten von anderen oder das Ergebnis dieser Übung bevor ich daraus einen Effekt ziehen kann für mein Berufsleben und meine Situation, die dann ja wieder ganz anders sein kann, also, Wichtig ist, zeitaufwendig, ausgiebig und eben mit figuralen Methoden, also mit Methoden, in denen man wirklich Dinge von unterschiedlichen Perspektiv betrachtet, ausprobiert und erlebbar fühlbar macht. Es reicht nicht einfach nur ein Buch auszuteilen über Kreativitätstechniken Wer sich Liberating Structure mal angeguckt hat Liberating structures [8:21] Liborating Structure sind unfassbar wertvoll für unseren Workshop-Alltag für unseren Arbeitsalltag als Agilisten. [8:29] Gleichzeitig trauen sich die wenigsten ran, einfach weil es beim Durchlesen ganz einfach klingt oder auch sehr komplex klingt, aber wenn man diese liberalen Storcha einmal angewendet hat Dann landet ihr in meinem Methodenkoffer und dann kann ich die Art hock einfach mal so eben anwenden. Neu kombinieren oder abwandeln und da fängt eben diese Kreativität an. Also es reicht nicht, ein Buch darüber zu lesen oder ein Training zu besuchen, das wirklich nur die Fachlichkeit vermittelt, sondern ich brauche ein Training dazu, das figurale Methoden anwendet und das macht gute Trainings aus und deswegen gibt es auch die Snap Academy. Wir geben uns ganz, ganz viel Mühe, diese figuralen Methoden, das erlebbar machen in unsere Trainings einzubauen und ich glaube, den Höhepunkt erreicht es dieses Jahr mit der Academy Master Ausbildung, also falls du da interessiert bist wirklich als Adriane Master nicht nur Agilität als Fachlichkeit zu lernen, sondern eben mit Hilfe dieser figuralen Methoden effektiv ausgiebiges, zeitintensives Training zu besuchen und hinterher wirklich, Methodenkoffer zu haben, denen du auch anwenden kannst. [9:37] Schau mal auf unserer Webseite vorbei. Da gibt’s noch ganz viele mehr Informationen. Jetzt zurück zu dieser Studie. Ich finde noch zusätzlich zu diesen das Trainings am effektivsten sind, den Asp Kreativität durch Agile Master [9:49] dass im Prinzip eine regelmäßige Retrospektive durchgeführt von einem erfahrenen spielerischen Scrum Master oder Azure Master eben auch diesen Effekt haben kann einen zeitintensives, langfristiges, ausgiebiges Training zu sein für Menschen mit verschiedenen Assoziationsübungen. AKA-Petro-Methoden oder Facilitationsmethoden zu lernen, kreativer zu sein. Also ich glaube, dass so was wie Retrospe wenn ich da regelmäßig die Methoden verändere, wenn ich einen mutigen Sprummaster habe, der genau weiß, wann lohnt es sich die Methode, die Retro-Methode zu ändern. [10:29] Und man behalte ich sie lieber bei, weil sie noch nicht so richtig sitzt, der kann ein ganzes Team kreativer machen. Und Kreativität ist so ein bisschen wie Mut. Da gibt es eben Statistiken zu. Was glauben wir denn, wer das beeinflussen kann, ob das durch Organisationen oder durch na ja Einzelcharaktere beeinflussbar ist und die überwiegende Mehrheit der Menschen glauben, dass Führungskräfte einen Einfluss darauf haben. [10:54] Menschen, Kreativität zeigen oder Mut zeigen oder eben nicht, weil sie eben die Rahmenbedingungen dafür schaffen oder eben nicht, Ist eine wichtige Führungsaufgabe, das zu ermöglichen, dass Kreativität in den Menschen auch sich entwickeln kann. Es gibt aber neben Zeit intensiven und ausgiebigen Trainings auch noch andere Dinge, die Kreativität steigern, bisschen weniger effektiv, aber vielleicht auch ganz interessant für euch zu betrachten Meditation [11:22] Und dazu nennen sind so was wie Meditationen Ich weiß nicht, wie häufig du auf der Arbeit eine Meditation machst oder ihr vielleicht als Team auch eine Meditation macht, eine Gedankenreise oder Achtsamkeitswochen in eurem Unternehmen habt Meditation ist auf jeden Fall etwas, das laut dieser Studie Kreativität steigern kann, Man hat hier übrigens in dieser Studie Kreativität nicht subjektiv gemessen, also im Sinne von fühlst du dich kreativer, sag mal lieber Mensch, sondern man hat Kreativitätstechniken, Objektiv versucht darzustellen, zum Beispiel über solche Fragen wie wofür kann man folgende Alltagsgegenstände noch verwenden, also so eine Art Fremdverbindung. Von Alltagsgegenständen, die wir alle kennen, zum Beispiel eine Büroklammer und dann hat man eben aufgeschrieben, wie viele Dinge finden die Leute, wo man potenziell eine Büroklammer fremd verwenden könnte und hat das eben als Kreativität, Maßstab herangenommen. Neben den Trainings und äh dem Thema Meditation. Kulturen [12:24] Hat auch eine kulturelle Exposition, Auswirkung auf die Kreativität, also je mehr kulturelle, verschiedene Aspekte ich erleben kann in meinem Arbeitskontext oder in meinem privaten Kontext desto kreativer bin ich. Also wenn ich im Ausland studieren konnte oder bin ein paar Wochen im Ausland für mein Unternehmen arbeiten kann oder, Teams zusammenstelle, desto kreativer werden die Einzelpersonen und auch die Gruppen an und für sich. Und hier sind wir auch wieder dabei, liebe Leute, Diversität so so wichtig und Diversität gehört eben auch vernünftig begleitet, weil Diversität oder kulturelle Diversität, ein bisschen zu Reibung führen kann und wenn man das vernünftig begleitet mit jemandem, der sich als Team-Entwickler gut auskennt, dann ist da häufig schon ganz, ganz viel gewonnen. Kulturelle Expositionen dürfen wir übrigens jetzt hier im Sinne von Homeoffice, tatsächlich auch so klein weiter fassen, dass es Sinn macht, den Arbeitsplatz mal zu wechseln und ich weiß, dass es eine ganz emotional geladene Diskussion gibt zwischen Homeoffice oder. [13:37] Also Google und Amazon, die Firmen, die ja viel mit Agilität, Kreativität und Innovation und Fortschritt und so was verbunden sind. Die holen ihre Mitarbeitenden wieder ins Büro zurück, weil es da einfach mehr kulturelle Expositionen gibt Man ist einfach auseinandergesetzt oder mit unterschiedlichen Räumen, mit unterschiedlichen Menschen und das ist nicht kontrollierbar, wie wenn ich im Homeoffice sagt, na ja, ich begegne ja auch den Post aber das ist natürlich eine andere Form von Begegnungen, als wenn ich einen kurzen Plausch an einer Kaffeetheke halte oder zufällig auf, einem Kollegen begegnen. Ein Äquivalenter für im Homeoffice wäre Spaziergänge zu machen oder. [14:18] Homeoffice ab und zu mal in einen Coworking Space zu wechseln, einfach um diese kulturelle Exposition und damit die Kreativität zu steigern Slacktime... The post 149 Kreativität https://znipcast.de/blog/149-kreativitaet/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

19m

Apr 22, 2023

Problem Swarming Unsere Agile Master Ausbildung: https://znip.academy/agile [0:01] Heute geht es ums Problems Roaming und was das vielleicht sogar mit Bienen zu tun hat und warum man in Agilität, ach egal. [0:10] Music. [0:19] Und herzlich willkommen zum Home of Edgial Master. Mit dabei ist heute die bezaubernde Janina Kappelhof. Und ich Henri Schneider. Heutiges Thema Bienenkunde. Ja schon. Schon? Schon? Ja, ist es. Das Thema [0:37] Also gerade in den Kanmanen-Folgen erwähnst du häufiger, ja da gibt’s halt so ein Problem-Screming und dann wird das halt erledigt. Ja. Und dann ist natürlich die Frage ja problem, hm? Ich verstehe die Worte. Und was ist dahinter? Mhm. Okay, also ich finde dieses Thema programms warming ist eins der ersten Dinge, die ein, Problem Swarming [1:01] Master und wir haben übrigens dieses Jahr unsere Ausbildung in Präsenz also alle Infos auf unserer Webseite, wie auch immer. Was man als Addualmaster unbedingt, jemandem beibringen können sollte, ist, wie kommen Teams in diese Handlungen des Problems Warmings? Mhm. [1:21] Ist, wenn ich feststelle, ich habe ein Problem, Zu arbeiten? Das passiert recht häufig, dass ich feststelle, okay, hier ist ein Problem. Mhm. Und kümmern sich darum, dieses Problem zu lösen, Das hat verschiedene Gründe, warum man das unbedingt machen möchte. Also warum ich finde, dass das jeder unbedingt machen möchte. Ich ich stelle mir’s so vor, ich sitze im Büro und auf meinem Rechner irgendwie so ein Pop-up so fatal und dann rote Reißleine direkt an meinem Schreibtisch einfach nur zack und dann, rotes Licht überall und alle Kollegen rennen zu mir an den Arbeitsplatz. Wenn wir von Präsenzteam sprechen, dann funktioniert das genauso. Das sieht wirklich so aus. Das ist häufig dann keine rote Leine, sondern diesen Button. Für manche sind das wirklich dieses gibt ja so bei China guides gibt es diese Buttons ja. Auf die man hauen kann, wo dann Alarm, Alarm oder. [2:17] Man kann es auch selbst besprechen, nicht genau oder es gibt diese ganz häufig sehe ich diese Schweinis Ja, stimmt, die sehe ich auch häufig. Mhm. Das benutzen auch häufig liberating structure Facilitatoren, ne, um die Aufmerksamkeit von der Gruppe auf erlangen, Bei manchen Teams ist es auch so eine Art Reiz, also dass eine bestimmte Lampe angeht, so eine Alarmlampe, dass man quasi die Zeile code oder das Thema den Satz, den man gerade schreibt, noch beenden kann. Nicht ganz so, Heavy Metal rausgerissen wird aus seiner finde ich auch ganz gut. Für manche ist aber dieser visuelle Reiz auch viel krasser als der auditive Reis. [3:00] Gibt es wieder Teams, die markieren das mit so einem Team. Er hat das mit so einem großen, pinken Flamingo, der aufgestellt wurde und wenn der Stand, dann war klar, wir müssen jetzt problem-Storming machen und war ein extreme Programming-Team, jedes extreme Programming-Pair hat dann, aufgehört zu arbeiten und er hat sich diesen Flamingo zugewandt und wenn dann alle Teams beisammen waren oder häufig, wenn schon zwei, drei Pärchen zusammen waren, wurde über dieses Problem gesprochen, weshalb dann das vierte, fünfte Pärchen noch dazugekommen ist. Also problemsforming ist, ich habe ein Problem festgestellt, fataler Aero und ich ziehe die Reißlinie im wahrsten Sinne des Wortes und alle Beteiligten, des Teams kümmern sich darum, dieses Problem jetzt zu lösen. Aber jetzt halte ich die doch alle von der Arbeit ab Halte ich damit alle von der Arbeit ab? [3:47] Sind das sinnvoll? Na ja, in der Regel ist dieser fatale Aero, etwas, das ich nicht für mich schon lösen könnte. Also ich begebe dieses Problem ja grade nur dann raus, wenn es ad hoc keine Lösung gibt in meinem Arbeitsbereich. Mhm. Dieses Reißleine ziehen. Das haben wir in den Kammernfolgen, glaube ich, auch erzählt. Kommt eben aus der lieben Production-Richtung. [4:08] Eben aus dem Bereich Kammbarn, dass die Produktionslinie, wenn sie weiterlaufen würde, Fehler produzieren würde ab dem Zeit, wo ich dieses Problem entdeckt habe. Nehmen wir an, ich würde Autos halt produzieren und ich habe irgendwas im Cockpit, was fehlt oder ich stelle fest, dass irgendein Teig kaputt, wäre es ja unsinnig, würde ich die Montagelinie weiterfahren lassen und dann immer wieder dieses. [4:31] Cockpit einsetzen und dann haufenweise defekte Fahrzeuge herstellen, die ich hinterher alle quasi wieder reparieren muss. Von Hand? Ja. Teuer? Wäre es ja sinnvoll, einfach mal anzuhalten. Alle tun sich zusammen und gucken halt, vielleicht ist in dem Schritt vorher schon irgendwas schiefgegangen und das kann man irgendwie kurz beheben und dann geht’s wieder weiter. Und natürlich kostet das auch Geld, also diejenigen von euch da draußen, die in Produktionsbetrieben arbeiten, die wissen ganz genau, wie toll das sein kann, so eine anzuhalten. Da redet man wirklich über viele Nullen im Minutentakt Das bedeutet also nicht diese Produktionslinie anzuhalten und dann erstmal eine Stunde zu quatschen, Das bedeutet wirklich, wir haben hier ein Problem. Ihr wisst alle Bescheid, wie gehen wir damit um und dann gemeinsam zu entscheiden, wir riskieren Fehlproduktionen und manuelle Nacharbeit, oder Team XY kann sich um dieses Problem kümmern oder wir müssen Experten von außen anfragen, der kommt, aber wir machen’s halt jetzt und nicht erst, wenn wir gleich Pause haben oder Daily in fünf Stunden. Für euch Führungskräfte, wenn ihr zu so einem dazukommt, ist nicht die Frage, wer ist schuld, sondern was braucht ihr, Die Frage ist auch nicht, wer es war übrigens. [5:48] Ist ja nicht immer dasselbe, ne? Und wer war’s? Warum möchte ich das machen? Also zum einen, ich erzeuge halt Warum möchte ich das? [5:55] und du hast jetzt darüber gesprochen, dass Fahrzeuge dann manuell nachbearbeitet werden müssen, wenn ich in der Fahrzeugproduktion bin. Ich habe auch häufig solche Probleme im Code und wenn ich wirklich Continuse integration, Deployment, Teams habe, also wirklich Teams, die Softwareentwicklung richtig gut verstehen auf modernsten Stand, dann habe ich dieses Stück Software ganz ganz schnell verteilt in alle möglichen Windesrichtungen und bis zum Kunden hin und ich will diesen fatalen Airrohr nicht bis zum Kunden hin verteilen. Den so schnell wie möglich aus diesen ganzen Code Dupliketten, die ich in so einem Codeverwaltungstool haben kann, bereinigt und erledigt haben, damit alle Tests grün laufen und dich verlässliche Aussagen darüber machen funktioniert die Software, die ich daraus liefere. Und dasselbe, wenn ich in einem Dienstleistungsverhältnis bin, mein Produkt ist also eine Dienstleistung Ich stelle fest, es haben sich Rahmenbedingungen geändert wie Gesetzestexte. Ich möchte das gerne sofort wissen, und nicht erst in fünf Stunden. Mhm. Wenn ich wirklich über Schnelltaktige, effektive, effiziente Team spreche, wenn ich meine Release sowieso erst in einem Jahr habe, Mich da ein bisschen rein entspannen, aber wir sprechen ja hier von Agilität auf höchstem Niveau und nicht von. [7:15] Pseudo Agilität, wo halt einmal im Jahr geliefert wird. Also von daher, wenn dein Anspruch ist, dass du wirklich agile schnelltaktige Continues, also agile Prinzipien richtig ernst gemeint, dann ist Problem Swaming etwas, das man unbedingt machen möchte Das findet dann häufig eben je nachdem, was denn jetzt hier diese Reißlinie. Reißleine auslöst, findet dann eben in der Regel sofort eine Art ad hoc Besprechung statt. Meiner Erfahrung nach ist die nicht länger als fünf Minuten. Wie durchführen? [7:46] Und es gibt in der Regel innerhalb von einer Stunde eine Lösung. Das sind so meine Größen. Wenn jetzt ein Imperiment auftritt, würdest du eine Triage machen, mit mache ich daraus jetzt ein Problem-Storming? Bringe ich’s zum Daily oder, Einfach nur im Backlog Ich glaube, dass jeder einzelne im Team relativ gut abschätzen kann, ist das etwas, das uns hier richtig im Arsch beißt, wenn wir’s auch nur eine Sekunde länger ignorieren oder ist es etwas, das auch in fünf Stunden, ne, also beim Daily Problem ist und Zeit hat. Also es gibt ja unterschiedliche Klassifikationen von das beißt uns in den Arsch. Wenn ich jetzt festgestellt habe, mein Bürostuhl ist kaputt aber ich kann darauf grundsätzlich noch sitzen, dann ist das was anderes als irgendein Server ist grade nicht mehr am Netz oder irgendwer hat zu Hause kein Internet mehr oder was weiß ich, also was so wirklich ad hoc Probleme machen kann. Okay, cool Also ich glaube, dass jeder einzelne das gut abschätzen kann und auch da wieder, ich weiß es vielleicht nicht, die erste Woche. Ich weiß es nicht. Die zweite Woche und ich weiß es vielleicht auch nicht nach drei Monaten Zusammenarbeit in dem Team. Ich gehe davon aus, dass mit der zunehmenden Reife meines Teams. Jeder einzelne verinnerlicht hat, was zu dieser Reißlinie führen kann. Für mich ist es wichtig, dass die Teams lieber einmal zu viel diese Reißlinie äh Reißleine. [9:07] Reist Leine ziehen und lieber einmal zu häufig Problem Swaming machen als einmal zu wenig, zu wenig kostet mich mehr Geld als einmal zu häufig. Wie kann man das Ganze online umsetzen, finde ich jetzt noch interessant? Also wenn ich wirklich remote arbeitende Teams habe Remote Problem... The post 148 Problem Swarming https://znipcast.de/blog/148-problem-swarming/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

15m

Apr 15, 2023

147 Mein Team nervt und nörgelt?! Wir reden heute übers Jammern, nörgeln, meckern, motzen, über ganz viel schlechte Laune in Teams und wie du als Agie Coach damit umgehen. [0:13] Music. [0:23] Du hörst den Snipcast, das ist der Podcast in dem wir Themen ein bisschen tiefer legen, die du als Azure Coach oder als Führungskra eines eigenen Teams unbedingt wissen solltest, die dir aber sonst nirgendswo beigebracht werden. Wir teilen hier ganz, ganz viel Praxiserfahrung mit dir. Ich bin Wirtschaftspsychologin und psychologische Beraterin und deswegen gibt es heute wieder ein psychologisches Thema. Das Thema [0:50] Wir kommen in unseren Trainings, insbesondere psychologische Sicherheit oder auch unsere Ausbildung, Coachings zu Edgie Coaches ganz ganz häufig in die Situation, dass wir gefragt werden, was mache ich denn, Denn mein Team sich in so einer endlos Spirale hinein nörgelt. Also einer fängt an, schlechte Laune zu haben und sich über irgendetwas zu beschweren und zu jammern. Und alle anderen steigen ein und schwups ist die Retrospektive irgendwie komplett gelaufen. Das Daily besteht nur noch aus Jammern und auch Kaffeegespräche oder andere Meetings sind, totale Nörgelrunden. Und dafür gibt es Lösungen in Betrachtungsweisen, die zum einen demjenigen, der dann da nörgelt, auch ein bisschen Raum gibt, denn die Frage ist ja, braucht Ansteckungsgefahr! [1:39] die Person vielleicht jetzt auch gerade einfach Raum und gleichzeitig allen anderen und vor allen Dingen dir als Agile Coaches auch ermöglicht dich abzugrenzen und Grenzen zu setzen, also bis hierhin ist nörgeln und jammern und motzen okay und ab hier eben nicht mehr. Der Hintergedanke dabei ist, nörgeln, jammern, motzen eigentlich, na ja, mehr die Emotionen, die dahinter liegen, also. [2:03] Wut, Enttäuschung, Trauer, fehlendes Selbstbewusstsein, all das sind Funktionen im Team, die ansteckend sind. Man weiß nämlich heute, dass Emotionen, unter Teammitglieder ansteckend sind. Wenn also jemand besonders viel gute Laune hat, dann steckt sich das an aber eben andersrum auch wenn jemand besonders schlechte Laune hat, dann steckt sich das auch an und häufig ist eben schon der Start in den Tag ein Riesenunterschied wie man sich den Rest des Tages fühlt und da kannst du als Führungskraft oder als Adlercoach natürlich wahnsinnig viel tun, setzen. [2:39] Bevor so ein Meeting überhaupt losgeht. Vorweg gesagt, alle Emotionen sind gut Alle Emotionen sind gut! [2:45] alle Emotionen haben eine Funktion, die einen haben eine offensichtlichere Funktion, eine, die dir grad in die Karten spielt. Andere haben eine eher, persönliche Funktion und trotzdem sind aber alle Emotionen, die in Teams auftreten, gut. Wichtig ist eben trotzdem, dass Emotionen diese Gruppendynamik beeinflussen. Meetings, Retrospektiven oder auch deine ganzen Teamentwicklungsprozesse, also auf einen längeren Zeitraum betrachtet, absolut Auswirkungen haben, deswegen ist es wichtig, sich mit Emotionen im Team zu beschäftigen. Es gibt immer Menschen, die in Teams mehr jammern als andere. Das hat nichts damit zu tun, dass die einen resilienter sind als die anderen oder dass diejenigen, die weniger. Nörgler = bessere Teammitglieder? [3:29] Motzen, nörgeln, bessere Mitarbeiter sind, im Gegenteil, Menschen, die ihre Emotionen nicht teilen, können eben auch ganz gefährlich werden für deine Gruppendynamik, weil man relativ spät erst mitbekommt, wenn diese Menschen unzufrieden sind. Oder vielleicht ja auch sogar wirklich einen Punkt haben, von daher höre ganz genau hin, wenn gejammert, genügelt, gemotzt wird, wenn Emotionen gezeigt wird und das darf eben so ein bisschen die, gefunden werden zwischen Emotionen zeigen und zu viel oder zu wenig zu zeigen, Was ist das? [4:03] Nörgeln, motzen, meckern. Das sind alles Wörter, die mehr oder weniger aus der gleichen Gruppe kommen, aber sie bedeuten alle ein bisschen was anderes und das schauen wir uns jetzt einfach mal genauer an. Ist so ein bisschen eine weinerliche Art und Weise, manchmal auch ein bisschen theatralisch, ne? So diese jammerige Diva. [4:24] Häufig sehr wortreich, also da bekomme ich häufig sehr, sehr viele Worte zu, wenn jemand jammert, bekomme ganz, ganz viele Erklärung. Gleichzeitig ist dadrunter so eine Art trauriger Unterton und diese jammerige Kommunikation ist leider eine relativ, häufige Kommunikationsform, wie genau das zusammenhängt mit Inter und Intra, also, Prozessen in uns, das schauen wir uns gleich nochmal ein bisschen näher an. Also das Jammern ist eher so eine weinländische Art und Weise, sehr wortreich. Nörgeln, nörgeln hat so einen, aggressiven Unterton, einen sehr anklagenden Unterton, einen ärgerlichen Unterton und manchmal ist es auch so ein bisschen griesgrämig, ne, so nörgelige Teammitglieder sind häufig so, auch wenn sie im Äußeren ganz anders sind, klingen sie so ein bisschen wie alte Rentner, die nörgeln, dass schon wieder ein Kind einen Ball in den Garten geschossen hat oder der Postbote die Briefe geknickt hat. Das ist so eine nagelige. [5:26] Grundstimmung. Und dann gibt es noch das Klagen, soll es häufig sehr schmerzreich, auch so ein bisschen verwandt mit dem Jammern, ne, so ein Jammerndes, Schmerz ausdrücken. Es hat häufig was mit Unzufriedenheit zu tun und auch das ist eher Anklagend, also wenn ich klage über jemanden oder über etwas, dann ist in der Regel jemand anders schuld und in der Regel habe ich wenig Spielraum damit umzugehen. Also jammern, nörgeln, klagen, wirken sehr ähnlich, haben aber ganz unterschiedliche Konnotationen und entsprechend ganz unterschiedliche Funktionen, wenn sie in einem Team auftreten und insbesondere auch wenn sie in einer Gruppendynamik sich multiplizieren. Warum machen sie das? [6:07] Jammern oder nörgeln oder klagen. Warum genau machen Menschen das? Da gibt es eben intrapsychische und interpsychische Funktionen, intrapsychisch ist. [6:19] Brauche das für mich und meine Klärung im Kopf oder meine geistige Gesundheit und interpsychisch ist, ich habe irgendeine Absicht damit, in meiner Beziehung mit anderen. Also in der Gruppe zum Beispiel, in der ich gerade unterwegs bin. Das ist super interessant, drauf zu achten, ist die Funktion von diesen Jammern nörgeln, Klagen dieser einen Person oder der Gruppe etwas intrapsychisches, also die das grade, um in einer Einzelperson gesund zu sein oder in ihrer Gruppe sich zu festigen, wenn der Systemtheorie wissen wir ja, dass Gruppen selbst erhalten sind, also es kann auch ein intrachischer Gruppenprozess sein, jetzt gerade genörgelt wird um sich abzugrenzen von außen oder einen interpsychischer Prozess, also in Beziehung stehend zu anderen, die allererste Funktion, die so ein Jammern haben kann, ist, einfach mal Druck abzulassen. Also da muss er einfach mal was raus. Da ist irgendwie das Fass voll. Man will so ein bisschen durchlüften. Im englischen heißt es dann auch Venting, also ich öffne einfach mal alle Fenster, lass meinem ganzen Frust einfach laufen. [7:28] Erzeuge dadurch Besserung in mir selber oder eben als Gruppe, dass man einfach einen frustrierten Moment erwischt hat. Man braucht dieses Venting einfach, um mal diese ganze Frustration loszuwerden und das ist so der allererste Effekt. Häufig ist man da als Elterncoach oder als Führungskraft so ein bisschen als Mülleimer in der Mülleimer-Funktion. [7:50] Und darf sich das erstmal alles anhören und abgeladen bekommen. Das fühlt sich natürlich, wenn das häufiger passiert, nicht gut an. In dieser Mülleimerfunktion zu sein und was du da tun kannst, das erzähle ich dir später in dieser Podcast-Folge. Die zweite Funktion, die so ein Jammern haben kann, ist, ein bestimmtes Image erzeugen zu wollen. Also zu demonstrieren wie sensibel und feinfühlig ich bin, wie reflektiert, was für hohe Standards ich vielleicht auch habe. Also es kann durchaus sein, dass dieses Jammern auch was damit zu tun hat, dass die Leute eben zeigen wollen. Schau doch mal wie viele Dinge ich wahrnehme, was ich eigentlich alles sehe, das ist häufig ein bewusster oder ein unbewusster Prozess, also die meisten Leute sind sich darüber gar nicht so bewusst, dass sie jammern auch verwenden können oder vielleicht gerade verwenden, um ein bestimmtes Image über sich selbst zu erzeugen.... The post 147 Mein Team nervt und nörgelt?! https://znipcast.de/blog/147-mein-team-nervt-und-noergelt/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

27m

Apr 08, 2023

Scrum vs KanBan Unsere Agile Master Ausbildung: https://znip.academy/agile [0:00] Es gibt einen guten Grund, warum wir jetzt die Master Ausbildung anbieten und nicht nur die Scrum Master Ausbildung, denn es gibt noch mehr agile Frameworks als nur Scrum, Es ist ganz cool, die auseinanderhalten zu können und zu wissen, wo fange ich denn jetzt je nach individuellem Team damit an. [0:18] Music. [0:27] Hallo und herzlich willkommen zum Snipe Cast deinem Podcast für was, wie anders sagen? Ja nicht, immer wieder ein bisschen was anderes drin. Ist der einzige Podcast, den du brauchst, wenn du mit Teams zu tun hast und die ordentlich entwickeln möchtest? Und welches Thema wir heute haben, erzählt uns heute Janina. Das haben wir ja im letzten Podcast so festgelegt. Wir sagen so selten unseren Namen, wenn wir eine gute Idee. [0:58] Ich probiere einfach mal. Ja, neues du hast den Snapcast, wir sind Henry Schneider und Janina Kappelhof Neues Intro [1:07] Wir bringen dir jede Woche die goldenesten, größten Perlen der Teamarbeit und Agilität, aus unserer und aus unserer Coaching-Erfahrung, also wirklich aus der Praxis und heute geht es um ein ganz besonderes Thema, das ich mitbringe ich bin huckt Ich bin so was von aus. Wir reden über etwas, das tatsächlich im Redaktionsplan steht, tatsächlich als nächstes Thema und ich finde, das passt so gut, weil ich habe letzte Woche einen Coaching-Call von dir mit angehört. Ja. Das Thema [1:42] Und mir ist aufgefallen, dass du das immer wieder sagst, aber selten in die Tiefe erklärst Und das machen wir heute. Oh krass, ey, das das große Thema. Und zwar glaube die Frage gestellt. [1:56] Was würdest du denn präferieren, wenn du Agilität einführst und deine Antwort ist in der Regel, Was würdest Du präferieren? [2:02] Kann man. Ist korrekt. Jetzt in der Regel meine Antwort Und eine ganz ähnliche Antwort würde ich auch geben. Das ist so die erste Empfehlung, die wir beide aussprechen und in der Regel ist die Begründung dafür, es ist leichtgewichtiger und man nimmt die Leute halt da mit, wo sie gerade stehen ohne einen Riesenchange einzu, Aber lass uns doch mal ein bisschen auseinanderzupfen, was eigentlich die großen Unterschiede zwischen Scrum, Was ist an KanBan leichtgewichtiger? [2:31] dieses klassische wir starten mit Scrum. Also das ist auch kann man auch genau das was mir dann häufig so entgegnet mit hä? Ich denke du machst Scrum. Du bist doch hier Agilität und so. [2:42] Ja. Und ich nenne mich ja auch selber Scrummaster. Das stimmt. Dass das nicht immer unbedingt mit Scrum starten muss oder dass das nicht unbedingt bedeutet, dass am Ende Scrum dabei rauskommt. Ich finde, das ist etwas, was wir hier mal, heute bisschen näher. Finde ich gut. Also das Thema heute ist, was ist der Unterschied zwischen Scrum und Cadman? Ja. Ach so, ich hätte gedacht, das Thema ist, warum würde ich dann eher mit Kanvan anfangen, aber ja die Antwort habe ich ja schon gegeben. Ach so, ja, genau. Weil’s leichtgewichtiger ist. Ja, das stimmt. Punkt. Aber warum? Was daran ist denn leichtgewichtiger? Wir haben schon ein oder zwei Konkrete kann man folgen ja auch spendiert haben da eben die Prinzipien erläutert, die eigentlich nur dahinter stehen. Mhm und die Werte und die Werte, genau, Das ist es schon fast. Also damit ist es eigentlich erklärt, wie es funktioniert und da drin ist sowohl die Schönheit als auch die Kompliziertheit. Ich finde, wir dürfen hier auch noch mal explizit erwähnen, das Kannen nicht einfach nur ein Bord ist. Ja. Sondern kann man es ein bisschen mehr als ich habe Borden spalten. Das wissen ja auch viele nicht. Viele sagen ach so, Jahn kann man dort haben wir schon seit Jahren. [3:57] Da gehören Prinzipien und Werte dazu, die gelebt werden müssen und wenn man diese Prinzipien oder geliebt werden sollten, wenn man diese Prinzipien weglässt, dann hat man vielleicht ein nettes Board irgendwo an der Wand kleben, aber die Funktionsweise dahinter Ist ein bisschen eine Art Lebenseinstellung, finde ich. Ne, ja, so groß hätte ich’s jetzt nicht gleich äh schon. Aber okay. [4:22] Was ist denn für dich die Lebenseinstellung hinter Kammer? Wirklich so dieser dieser Blick da drauf, also vielleicht auch nicht ganz so viel planen. Also ich finde planen immer gut, also einen Plan zu haben, Finde ich gut dadran, strikt festzuhalten. Eben nicht so sehr und kann man, plant gar nicht so viel, sondern reagiert mehr. Ich persönlich habe das Gefühl, das passt besser zum Arbeitsalltag von vielen Unternehmen, denen ich die ich so sehe. Die wollen häufig Scrum haben, weil sie das eher kennen, brechen sich dann tierisch ein damit ab, diese Prinzipien, die hinter Scrum liegen, zu leben, obwohl sie die vielleicht gar nicht brauchen. Mhm. Das finde ich ist es auf jeden Fall wert, Und ich finde, das ist auch ein bedeutender Unterschied zu Scrum, ne, also kommt ohne Plan aus oder sehr wenig planen. Scrum. Der große Plan [5:15] Und übrigens auch safe und uns Spotify und Nexus, die, bauen ja alles drum herum um dieses Planenevent. Und das ist ein Dreh- und Angelpunkt in DrameWorks. Bei Kanban gibt es eine Spalte, wo sich freigezogen werden kann. Mhm. Was auch immer jetzt grade das nächste Dringendes. Ich schaffe bei Scrum so ein bisschen mehr planerische Verlässlichkeit. Mhm. Währenddessen ich bei Kannbarn mir, jederzeit immer nur angucke, was ist das nächste, wichtigste Thema für mich? Genau. Deshalb habe ich nicht so viel Plan. Der Alltag, den ich erlebe in vielen Unternehmen. [5:55] Ist eher so, wir haben gerade unser Planning gemacht im Scrum und manchmal nur eine halbe Stunde später, irgendein Ereignis im Unternehmen passiert, ja. Was diesen Plan schon wieder über einen Haufen schmeißt. Genau und dann kann ich den Plan eben auch gleich sein lassen. Mhm. [6:11] Arbeitet deswegen mit so einem kontinuierlichen Durchfluss, also ja, bei Scrum oder Safe gibt es oder Nexus gibt es das schon auch, dass man versucht, einen kontinuierlichen Fluss aufzubauen, aber der bewegt sich in einer und da haben wir den nächsten Unterschied. Wir haben bei Scrum und den ganzen Kram haben wir Sprints, also Zeiträume, in denen wir Planen. Das ist eine Folge dieses Planungsanspruchs. Wir haben Iterationen, die sind immer gleich lang, damit wir eben auch Planungsintervalle vergleichen können und bei Kanban haben wir eben keine Sprints, keine fest Zeiträume, in denen wir Planbarkeit herstellen wollen, sondern das ist wirklich ein kontinuierlicher Durchlauf, der von heute auf morgen sich komplett ändern Produkt vs Prozess/Value Stream [6:55] eigentlich wäre es so, wenn ich ein Produkt habe, würde ich eher Scrum empfehlen Wenn ich eher Daily Business habe, mhm. Würde ich eher Canvan machen. Jetzt darfst du den Unterschied dazwischen erzählen, weil die meisten Teams glauben. [7:13] Ja das ist dasselbe. Ja, das stimmt schon. Also ein Produkt wäre wirklich etwas wie wir nehmen hier einen Podcast auf. Wir entwickeln das beste Mikrofon, was uns beide hier im Raum so einfängt vielleicht sogar noch Unterwasser funktioniert, weil das eine witzige Idee wäre, diesen Podcast in der Dusche aufzunehmen oder, Produkt kann aber auch eine Dienstleistung sein, also wenn wir machen, ist das ein Produkt. Wenn wir hier über unser Coach Training reden, dann wäre das, quasi, Da haben wir mitunter auch einen Zeitpunkt dran. Mhm. Also wir Aggilisten rühmen uns ja damit, dass wir im Gegensatz zum Wasserfall, das Releasedatum auch einhalten? Mhm. Wir rühmen uns damit. Mhm.... The post 146 Scrum vs KanBan https://znipcast.de/blog/146-scrum-vs-kanban/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

30m

Apr 01, 2023

Intro Heute haben wir ein Thema und wechseln mittendrin noch Richtung uneinig. Wir sind uns heute richtig uneinig. Eigentlich haben wir drei Podcasts in einem aufgenommen. Das ist korrekt. Herzlich willkommen zum, den der Janina jetzt erklärt. Serienüberthemen wie Aktivität, Mindset. Kulturveränderung und alles, was für dich relevant ist. Machen die Welt mit dir zu einem besseren Ort. Schön, dass du da bist und los, Das Thema Schon über Skalierung unterhalten und daraus ist irgendwie die Frage entstanden, wie geht’s denn eigentlich den Teams in skalierten Umfeldern? Und schlecht. Schlecht, warum geht’s denen schlecht, es geht den Team immer schlecht. Was? Nein, mein mein Team ist immer wunderbar, also ich weiß nicht, was du mit deinen Teams machst. In Transformation geht’s den Teams immer schlecht. Nein, was genau meinst du? Ich habe mir dann ich weiß nicht mehr ganz, wie diese Frage entstanden ist und ich habe mir dabei eben so gedacht mit na ja Es ist schon eine Sache. Ich habe dieses Scrum oder kann man auf Teamlevel, ich habe meine Rituale eingeschwungen und so weiter und das geht alles. Und jetzt sind da plötzlich noch andere Teams, weil ich einen skalierten Umfeld bin, Dadurch kommt ein bisschen mehr Komplexität dazu und mit der darf ich ja auch irgendwie umgehen. Mhm. Okay, also für mich wäre, Abhängigkeiten so der allererste Punkt oder der allererste Unterschied, der mir auffallen würde, wäre ich bin abhängiger oder weniger also ich bin als Team nicht so frei mir meinen Rhythmus zu wählen. Mhm. Ich bin als Team nicht so frei meinen Backlog zu verhandeln. Mhm. Ich bin als Team nicht so mein Produkt zu gestalten. Also es ist eine ganze Menge weniger Selbstorganisation. Da hast du, glaube ich, schon einen interessanten Punkt genannt, der so eine Rahmenbedingung ist für das, was wir heute betrachten. Wahrscheinlich, dass die Teams am gleichen Produkt arbeiten. [2:21] Im skalierten Umfeld genau. Ich war gerade so was sagen wie auch sonst kenne ich sehr wenig Teams, die tatsächlich so selbst organisierte Reife haben, dass sie sich ihr Produkt auch selbst überlegen können. Ja. Aber zumindest ein paar Eigenschaften davon in skalierten Umfeldern ist das glaube ich alles sehr viel vorgegebener. Welche Eigenschaft ist haben soll, einfach weil das auf einem anderen Level mhm, vorstrukturiert und koordiniert wird. Mhm. Also ne, wenn wir über Flight Level reden, die Strategie und die Koordinative, die ist schon gelaufen. Ja. Bin nur noch die umsetzende Gewalt. Das ist direkt auch schon ein guter Punkt, der mir in allen skalierten Frameworks auffällt. Eine Art koordinative Ebene gibt. Also die scheint wichtig zu sein auch zum Einrichten, damit das alles zusammenspielt. Mhm. Auf dieser Ebene sollten wir uns natürlich auf eine Art wie auch immer gearteten, gleichen Takt einigen, dann vielleicht auch unsere Ziele miteinander abstimmen. Und. Könnte zum Beispiel über einen User Story Mapping passieren oder vielleicht sogar, wenn ich Sprints habe, dass ich als Product-Onerin habe ich dann ein bisschen mehr Aufgabe, mich da zu koordinieren, dass ich dann vielleicht schon die nächsten Sprints grob mit ihren Zielen vielleicht sogar vorplane. Product Ownerin Aber jetzt war ja deine Frage für diesen Podca wie fühlen sich die Teams? Ja, die Product Onnerin gehört zum Team. Und wie fühlt die sich jetzt? Die. Überfahren glaube ich von der Abstimmung, die plötzlich herrscht. Ich meine, das ist ein Overhead für die Product, Weiß ich gar nicht, denn als von einem nicht skalierten Team habe ich auch Abstimmungsbedarf. Mhm. Nur nicht mit anderen Teams oder anderen Productornern oder irgendeiner strategischen Initiative, sondern ich muss mich abstimmen mit, Kunden mhm. Marktrecherchen, User-Experience, Tests, was auch immer alles dazugehört. Und ich glaube, ich, mich so abstimmen und zusätzlich noch mit den anderen Teams, die am gleichen Produkt arbeiten. Ja, viele richten dann so eine Art Chief Product Ownerinnen ein, die das mehr in Richtung, und Stakeholder sich macht und gleichzeitig habe ich das für meinen wahrscheinlich Modul, auch noch. Nee. Nicht? Nee, das ist mehr oder weniger alles schon geklärt. Ach so, ich kriege nur noch so einen Backlog und das muss ich abarbeiten. Mehr oder weniger? Ja dann, dann fühlen sich Teams in skalierten Umfeldern ja noch wohler, weil sie ja weniger Nachdenken brauchen. Teams nee, das glaube ich eben nicht. Also ich kann mir vorstellen, dass dieser höhere Grad an Abhängigkeit, manche Teams auch einfach sehr entlastend ist. Weil es ein reines Abarbeiten, also und das ist gar nicht negativ gemeint, also das es ist einfach auch schön, wenn ich nicht selber. Koordinieren und so weiter und so fort machen muss, sondern wenn das schon erledigt wurde auf ja in einem anderen Fluglevel. Wenn es schon User-Interface-Designs gibt, an die ich mich nur noch halten muss. Ich muss mich nicht entscheiden, wie das Menü aussieht. Das ist schon lange entschieden worden. Trotzdem, dass beides passiert. Also dass ich zum einen die Strategie für das Produkt zu erfüllen habe, auf dem ich mich auf koordinativer Ebene mit den anderen Teams einige und dass ich für die Funktionen, die ich integriere, also mein Team integriert, dass ich mich da auch mit Kundinnen entsprechend unterhalten und einigen darf, wie das aussieht. Auch weil vielleicht auf koordinativer Ebene und, dann höher auf Portfolio oder strategischer Ebene auch nicht alles gesehen wird, denn viele Sachen werden auch, Expertenebene. Beobachte ich anders? Mag sein, dass wir das anders beobachte ich es auch an. Wenn das auf Teamebene erst diskutiert wird. Ja. Dann ist der Rückweg in die anderen Teams zu spät, braucht ja nicht in die anderen Teams nehmen wir mal an ich hätte einen Scrum Framework mit Sprints dann habe ich, Sprints entsprechend auszuplanen, von mir aus mit einem Release-Burndown für die koordinative Ebene, um die Strategieziele zu erfüllen und gleichzeitig werde ich auch, was weiß ich, technische Schulden von dem Modul, was ich, bearbeite eben auch beseitigen dürfen. Genau und diese technischen Schulden haben Auswirkungen auf die anderen Teams. Das muss wieder zurückgespielt werden, Testframework umstelle, weiß ich nicht, Test modular mache oder umstelle von Red Head, eins auf Red Head zwei, dann hat das Auswirkungen auf die anderen Teams. Ich kann diese nicht mehr alleine treffen, Das mag sein und es gibt genug, die kann ich alleine treffen. Also ich würde mich mal aus dem Fenster lehnen und sagen, in einem großen Konzern, mit mittelständischen Unternehmen, kann ich nicht mal als Team das nicht in einem skalierten Umfeld ist, diese Entscheidung treffen, ohne dass andere Teams davon betroffen sind. Von daher würde ich jetzt sagen, das funktioniert vielleicht in einer Startup-Buble. Nicht in Unternehmen, die bisschen größer sind und glaube ich nicht und vielleicht habt ihr da draußen ja eine ganz andere Beobachtung und könnt uns eure Meinung dazu sagen. Team Henry, Systemgrenze Was hast denn du sonst noch so für Beobachtungen und Teams installierten Umfeldern? Ich finde noch so diese Dimension Systemgrenze ganz interessant, also kommen Teams in so eine Art Wettbewerb oder Konkurrenz miteinander. Ich beobachte das manchmal schon innerhalb eines Team, dass Menschen so was wie Userstories reservieren Mhm. Da möchte ich als nächstes dran arbeiten, so Handtuch einmal ausrollen und fertig. Und ich kann mir vorstellen, dass das in skalierten Umfeldern. Auch ein Thema ist, dass sich diese Teams zwar abgrenzen voneinander und als einzelne Einheit sich verstehen im Organisationssystemkontext oben Teambuilding zu betreiben und gleichzeitig aber nicht zu weit diese Grenze fest sein darf, als dass so was wie Kompetenz und Wissen und Austausch von Experten vielleicht, also dass auch ähm einer meines Team wechselt, dass das trotzdem noch passiert mehr als Schwierigkeit vorstellen. Und das würde ich auf die koordinative Ebene auch bringen, also genau dieses Thema. Du willst eine koordinative entscheiden lassen darüber. Wo die Teams sich abgrenzen von anderen Teams. Ich würde das auf jeden Fall beobachten und da drauf gucken, ja? Entsprechend handeln, ja, das funktioniert System theoretisch nicht, weil du kannst nicht beeinflussen, wo das System selbst seine eigene Grenze setzt, Ich kann die Grenze setzen. Nee. Kannst du nicht? Das sind das sind ja keine offiziellen Entscheidungen, sondern das sind inoffizielle, das sind Bauchgefühlgrößen. Du kannst schon häufig in einem Team, Subgruppen nicht wieder auflösen. Also ich bekomme das manchmal nicht hin, dass wenn wirklich ganz starre Subgruppen entstehen und gar keine aufeinanderzugehen und Teambuilding passieren will, aus welchen Gründen auch immer, dann habe ich manchmal schon in einem einem Team so Gruppen. Mhm. Die bestehen dann aus drei, vier Leuten und auf Organisationsebene kann ich vielleicht sagen, dass das Team Tiger und das ist Team Erdmännchen. Aber ob die sich dann auch so voneinander abgrenzen, oder ob die ganz anders zusammenarbeiten, das ist ein Kulturthema, das kann man nicht bestimmen, Ich kann ja aber, wenn ich in meinem Team beim durchaus feststelle, dass ich noch ein Knut brauche. Dann kann ich das ja auf die koordinative Ebene bringen mit hey wir haben im Team Erdmännchen festgestellt. Wir bräuchten noch ein, Genau und wenn Gnus aber Erdmännchen hassen, weil das Unternehmenskultur technisch eine Systemgrenze ist. Ja. Dann bekommt man das nicht so schnell aufgelöst. Das ist das ist dann Thema der Operativen. Okay, da bin ich wieder bei dir. Man kann das nicht bestimmen, wer sich wo zuständig äh oder zugehörig führt. Das müssen die Leute schon selber entwickeln. Man kann den Dialog initiieren. Braucht auch nicht darüber reden, ob Leute sich zu oder nicht entweder das passiert, das ist eine Erfahrung, Gefühl von Zugehörigkeit ist eine Erfahrung. Würdest du also einfach laufen lassen? Na ich würde das schon beeinflussen wollen, dass ich genug bei Erdmännchen eingliedern kann, aber ich kann das nicht bestimmen. Ich dafür ich brauche dafür eine Begleitung auf der operativen. Dieses Anregen, das würde dann einfach, Direkt auf der operativen Ebene passieren, also das, Einen Gnu. Das ist ein Thema für die Kooperative. Aber ob das passiert, das kann die Kooperation das und das ist das sind wir doch aufm gleichen Platz. Das ist das, was ich meine mit, ich kann mir vorstellen, dass in skalierten Umfeldern. Dieses Thema ist Themengrenze, Teamgrenze so fest zu zurrennen, dass Teambuilding und Performing Teams entstehen und gleichzeitig aber so fluide lassen, dass ich in Erdmännchen packen kann. Das ist eine Herausforderung auf Team-Ebene, würde ich sagen. Das fühlt sich, glaube ich, nicht immer leicht. Wenn man dann permanent durcheinander gemixt wird, nur weil irgendjemand, Es braucht jetzt ein Genug. Finde ich von der von der Teamuhr her, also für diese Teamuhr finde ich das auch nicht gut, die Teams ständig durcheinander zu würfeln. Und grade deshalb finde ich es eben auch wichtig, dass auf koordinativer Ebene zu betrachten und, auch ein bisschen Ruhe reinzubringen, die nicht ständig durcheinander zu würfeln. Und ich hatte eben und da scheinen wir uns doch einig zu sein, gedacht, ich habe jetzt eine Aufgabe, die aufm kritischen Pfad meines Projektes ist und stelle halt in einem Team, von mir aus Team Erdmännchen, fest oder ist wohl eine Iteration in die Hose gegangen und wir sind jetzt grade ein bisschen arg an der Kante des kritischen Falles. Wir bräuchten Unterstützung. Dann sich auf der koordinativen Ebene dadrüber zu unterhalten, könnten denn die anderen oder könnten sie nicht, Das Team Elefanten, das hätte noch Kapazitäten, aber die sehen genauso ausgelastet, weil sich da jetzt was verzögert, dann verzögern wir doch wieder um das ganze Projekt. Was mich gerade irritiert ist, du willst ja wissen, wie fühlt sich denn so ein Team, Das Eigentliche Thema im skalierten Umfeld. Ja, ich wollte dann auch, wie man damit umgeht aber über eine die Koordinative die ganze Zeit. Ja, willst du die nicht direkt eingeführt? Ich glaube, es macht in dem Fall keinen Unterschied, ob ich eine koordinative habe oder nicht, aus Team Perspektive, wenn du wissen möchtest, wie fühlen sich Teams und was kann das Team tun? Dann ist das eine Bitte nach einer zusätzlichen Kompetenz, aber dann, irgendwer irgendeinen Manager, irgendeine Koordinative, wie auch immer, dieses skalierte Framework aussieht, irgendeinen ätzenden Elefanten da rein, nur weil der aufm Papier die Fähigkeiten hat. Mhm. Aber der ist, kein Teil des Teams und das fühlt sich glaube ich sehr unangenehm an und deswegen ist es eine koordinative, jetzt diese Kompetenz irgendwie zu verteilen, aber ob sich das im Team gut anfühlt oder nicht, ist eine ganz andere Frage. Ja, okay. Ja. Und das Thema war ja auch nur Teams in skalierten Umfeldern und da wollte ich so ein bisschen die, was ist da jetzt anders beleuchten? Wir können ja nochmal zurückspulen und nochmal einblenden, welche Frage du mir am Anfang dieses Podcast gestellt. Bisschen mehr, weil ich wusste nicht, dass ich dich auf der Gefühlsebene kriege. So Das Thema ist jetzt Teams in skalierten Umfelden. Ah ja, wir ändern also jetzt nach 20 Minuten das Thema des Podcasts, nur damit die Zuhörer auch mitbekommen. Recht habe. Nein. Wechselwirkungen... The post 145 Teams in skalierten Umfeldern https://znipcast.de/blog/145-teams-in-skalierten-umfeldern/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

29m

Mar 25, 2023

Neurodiversität Janina Kappelhoff findet das Thema Neurodiversität unglaublich spannendend. Erst dadurch können wir wirkliche Diversität in unseren Teams und Organisationen herstellen. Es geht um gehinfreundliches führen. Beziehungsweise welche Aspekte von verschiedenen Forschungen dürfen wir eigentlich beachten, wenn wir über Teamarbeit oder Zusammenarbeit sprechen? Da hat sie euch heute ein paar Modelle mitgebracht. Los geht’s. Diese Folge auf YouTube: https://youtu.be/E3UtXxiuKtA Links Friederike Fabritius: https://friederikefabritius.com Menschen lesen: https://znip.academy/mk Team Resilienz: https://znip.academy/tr Teamphasen: https://znip.academy/teamuhr Das Thema Was Janina total interessant findet und du sicher auch wahnsinnig interessant, für dich und dein Team, findest... The post 144 Neurodiversität https://znipcast.de/blog/144-neurodiversitaet/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

21m

Mar 18, 2023

Impediment Heute geht es um Impediments oder Impediment. Also Hindernisse. Wir verwenden den englischen Begriff, da dieser in der Agilen Bubble geläufiger ist. Das Thema kommt aus der „Wie anfangen?“ Folge. Diese Folge auf YouTube: https://youtu.be/kms-_8hZKpU Impediments sind Rudelschweine! Impediments sind Hindernisse, die im Arbeitsalltag, vor allem für unser Team auftreten. Im Scrum Guide steht... The post 143 Impediment https://znipcast.de/blog/143-impediment/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

36m

Mar 11, 2023

Vulnerable Leadership Vulnerable Leadership ist ein Thema, welches in unserer Social Media Bubble (LinkedIn und Manager Magazine), gerade gehyped wird. So ist es uns auch in unserer aktuellen Psychologische Sicherheit Masterclass begegnent. Wovon Janina Kappelhoff gern berichtet. Es geht darum sich in einer Führungsposition oder mit Führungsaufgabe verletzlich zu zeigen. Psychologische Sicherheit Masterclass: https://znip.academy/ps Unsere... The post 142 Vulnerable Leadership https://znipcast.de/blog/142-vulnerable-leadership/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

15m

Mar 04, 2023

Team Estimation Game Das Team Estimation Game ist Henrys Lieblings Schätzmethode. Du möchtest Agile Master werden? Schau Dir unser diesjährige Präsenzausbildung an: https://znip.academy/agile Diese Folge auf YouTube: https://youtu.be/sYCI25gl6N0 Schätzmethode Wir schätzen in der Agilität relativ zueinander. Warum hat Janina Kappelhoff auch gut in der Wahrnehmungspsychologie Folge beschrieben. Für diese relativen, statt absoluten, Schätzungen benötigen wir... The post 141 Team Estimation Game https://znipcast.de/blog/141-team-estimation-game/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

9m

Feb 25, 2023

Wahrnehmungspsychologie Heute hat Janina Kappelhoff eine Solo-Folge und natürlich geht es um Psychologie, genauer: Wahrnehmungspsychologie! Stell Dir vor, Du könntest einen Projektplan aufstellen und der wäre perfekt und auf den Tag genau. Wie das geht und welche Aspekte zu berücksichtigen sind, darum geht es heute.   Ein Thema, was noch aus den Folgen 066 Haltung... The post 140 Wahrnehmungspsychologie https://znipcast.de/blog/140-wahrnehmungspsychologie/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

12m

Feb 18, 2023

Die eine Frage Es geht um die eine Frage, die Henry Schneider häufiger gestellt wird: Was ist das wichtigste Kriterium für die erfolgreiche Einführung von Agilität? Eine sehr gute Frage! Die Antwort Henrys Antwort ist: SlackTime Diese erfüllt gleich mehrere Kriterien und bildet die Basis für vieles andere. Beispielsweise kann man so erkennen wie ernst... The post 139 Die eine Frage https://znipcast.de/blog/139-die-eine-frage/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

9m

Feb 11, 2023

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... The post 138 Ein Produkt https://znipcast.de/blog/138-ein-produkt/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

16m

Feb 04, 2023

Skalierung Skalierung ist die Königsdisziplin in der Agilität, an der die meisten Firmen scheitern. Nachdem wir uns nun ein bisschen mit Agilität auf dem Teamlevel vertraut gemacht haben, geht es nun auch darum mal zu schauen, wie dies denn mit Skalierung aussieht. Also vielleicht auf organisatorischer Ebene. Denn wie gut ist Dein Scrum, wenn zwei... The post 137 Skalierung https://znipcast.de/blog/137-skalierung/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

30m

Jan 28, 2023

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... The post 136 Continious Delivery (CD) https://znipcast.de/blog/136-continious-delivery-cd/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

28m

Jan 21, 2023

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... The post Continious Integration (CI) https://znipcast.de/blog/continious-integration-ci/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

29m

Jan 14, 2023

Überprüfen Aus der Empirie weißt Du schon, dass Transparenz, Überprüfen und Anpassen die Grundpfeiler der Agilität sind. Bzw. „Inspect before adapt“ könnte man auch sagen. Für alle, die noch ihre Scrum.org Zertifizierung machen ist genau dies wichtig. Also auch Empirie mit Transparency, Inspection und Adaption erklären zu können. Quasi als 3 Säulen des Fundaments. Diese... The post 134 Überprüfen https://znipcast.de/blog/134-ueberpruefen/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

26m

Jan 07, 2023

Jahresrückblick Workshop Letzte Folge dieses Jahr! Diese nutzen wir doch direkt für einen Jahresrückblick Workshop. Naja nicht in dem großen Maße, wie er eigentlich laufen sollte, doch als Hinweis für Dich, dass Du dies auch mit Deinem Team machen könntest. Vielleicht direkt im Januar zum Start ins neue Jahr. Erst einmal: Frohe Weihnachtsfeiertage! Ich hoffe... The post 133 Jahresrückblick Workshop https://znipcast.de/blog/133-jahresrueckblick-workshop/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

22m

Dec 24, 2022

Fokus in Selbstorganisation Der liebe Felix hat uns im letzten Heldentreff eine hervorragende Frage gestellt! Die Frage lautete „Wie schaffe ich es in einem selbstorganisieren Team Fokus zu finden?“. Also Fokus in Selbstorganisation. Präzisiert hatte er diese Frage mit „Was ist mein Ziel im Team und was ist, wenn es keinen Chef gibt, der dies... The post 131 Fokus in Selbstorganisation https://znipcast.de/blog/131-fokus-in-selbstorganisation/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

25m

Dec 17, 2022

Fibonacci Heute wieder eine Solo-Folge von Henry Schneider über die Fibonacci-Folge. Also einer ganz speziellen Zahlenfolge, die wir im Agilen gern verwenden. Diese ist gekoppelt mit Wahrnehmungspsychologie, wozu Janina Kappelhoff noch gesondert berichten wird. Henry hat da nämlich wenig Ahnung von. 😀 Fibonacci-Folge Die Fibonacci-Folge wurde von Leonardo Fibonacci 1202 beschrieben oder erfunden. Damals um... The post 131 Fibonacci https://znipcast.de/blog/131-fibonacci/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

18m

Dec 10, 2022

Langweilig Heute hat uns wieder eine Zuhörerinnenfrage erreicht: „Wie wird es nicht langweilig im Projekt?“. Wenn Du auch eine Frage oder ein Thema für unseren Podcast hast: hello@znipcast.de Performing und nun? Es kommt immer wieder vor, dass Teams in der Performing Phase landen (siehe hierzu Teamphasen). Wo alle Rituale und Routinen eingeschwungen sind. Und einfach... The post 130 Langweilig https://znipcast.de/blog/130-langweilig/ appeared first on Znipcast - für gute Zusammenarbeit | Agilität, Scrum, KanBan, Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy https://znipcast.de.

24m

Dec 03, 2022