KanBan

153 Takt

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

Read More

151 Warum sollte ich Agilität einführen?

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

Read More

148 Problem Swarming

Problem Swarming Unsere Agile Master Ausbildung: https://znip.academy/agile Diese Folge auf YouTube: https://youtu.be/l4e6PsnyCNc [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….

Read More

146 Scrum vs KanBan

Scrum vs KanBan Unsere Agile Master Ausbildung: https://znip.academy/agile Dise Folge auf YouTube: https://youtu.be/6YzAK9E0Bys [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…

Read More

137 Skalierung

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…

Read More

115 Work in Progress

Work in Progress (WiP) Heute schauen wir uns das Work in Progress Limit (WiP-Limit) an, welches aus dem KanBan stammt. Work in Progress Limits sind einigermaßen banal, nicht immer leicht umzusetzen und wahrscheinlich auf Grund ihrer Einfachheit so mächtig. Wir lieben sie jedenfalls und möchten dieses Thema auch Dir näherbringen. Hoffentlich hast auch Du einen…

Read More

113 Wie anfangen?

Wie anfangen? Die Große Frage beim Einführen von Scrum, KanBan oder anderen Agilen Frameworks ist ja „Wie anfangen?“. Also beispielsweise nach dem Scrum Master Training, wie fange ich an diese neuen Techniken und Methodiken, vielleicht auch das Mindset im Team zu installieren? Die Ebenen Wir können damit beginnen, welche Ebene wir uns anschauen. Die individuelle…

Read More

Folge 090 Waiting Spalte

Waiting Spalte Heute geht es um, und vielleicht kennst Du das von Deinem Board, die Waiting Spalte. Wir haben uns bereits darüber unterhalten, wofür wir Borads verwenden und wie man diese erstellen kann. Heute geht es um eine konkrete Spalte, die von vielen Teams eingefordert wird. Die Waiting Spalte. Diese Folge auf YouTube: https://youtu.be/_bp0roJo5XQ Kontext…

Read More

Folge 079 Flightlevels einführen

Flightlevels einführen Nachdem wir uns in der letzten Folge über FlightLevel unterhalten haben, geht es heute um das Einführen dieser FlightLevels. Es gibt 3 FlightLevels von 1-3. Eins ganz unten, für hohen Detailgrad und drei ganz oben für die globale Sicht auf die Dinge. Die FlightLevels selbst haben nichts mit Hierarchie zu tun, sondern mit…

Read More

Folge 078 FlightLevel

Flightlevel Auf Hörerwunsch vom lieben Christian geht es heute einmal um Flightlevel. Das ist Janinas Thema. Und sie eröffnet direkt mit einer Überraschung, denn es gibt nicht mehr nur drei Flightlevel sondern nun ganz neu vier davon. Flightlevel passen super zu Lean und Kanban als Skalierungsmodell.   Diese Folge auf YouTube: https://youtu.be/1L8_Kpgnrg0 Die Reihenfolge Die…

Read More

Folge 070 Pull

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

Read More

Folge 069 Wie SAFe bist Du?

Wie SAFe bist Du? Nach dem wir uns in der letzten Folge mit der Mechanik und den Rollen in SAFe beschäftigt haben geht es heute mehr um das drumherum und die Frage wie SAFe bist Du? Letzte Woche ging es also mehr darum wie sieht SAFe von innen aus und diese Woche mehr darum wie…

Read More

Folge 068 Wie SAFe skalierst Du

Wie SAFe skalierst Du? Heute geht es darum wie das Skalierungs-Modell SAFe funktioniert. Es ist ein Hörerwunsch vom lieben Carsten und wir nehmen uns diesem daher schon einmal gern an. Das Thema ist zu groß für den Podcast und bräuchte eigentlich einen eigenen Podcast. Wir geben Dir trotzdem einen kleinen und schnellen Überblick in zwei…

Read More

Folge 067 Scrum Master Trends Report

Scrum Master Trends Report Wir haben uns den Scrum Master Trends Report von Scrum.org angeschaut und möchten mit Dir teilen, was wir daraus lesen. Scrum.org ist eine der zwei zentralen Zertifizierungsstellen für Scrum Master. Damit also schon eine wichtige Institution in der agilen Welt. Diese haben Scrum Master im weitesten Sinne befragt. Also auch Agile…

Read More

Folge 065 Boards erstellen

Boards erstellen Nachdem wir uns in der letzten Folge einen Überblick verschafft haben, geht es heute in die Details des Boards erstellen. Also wie gehen wir vor, dass das Team am Ende auch ein sinniges Board hat. Links Diese Folge auf YouTube: https://youtu.be/Qp7ezyJ-8Y8 Das Video The resource utilization trap – YouTube Zum Znipletter: https://mailchi.mp/1c5b65a9807d/newsletter Wie…

Read More

Folge 064 Boards allgemein

Boards allgemein Dies ist die erste von zwei Folgen zu Boards. Hier wollen wir uns allgemein über Boards, was vielleicht eine der auffälligsten Sachen in der Agilität ist, unterhalten. In der nächsten Folge geht es dann mehr um den Aufbau konkret und wie wir Boards in einem Team einführen würden. Diese Folge auf YouTube: https://youtu.be/qAhclqdGb0s…

Read More

Folge 055 Referenz Story

Referenz Story Heute bearbeiten wir wieder einen Hörerwunsch, die Referenz Story für das Refinement. 🙂 Den ein oder anderen mag das vielleicht irritieren, denn das geht schon etwas tiefer in die Schätzmethodiken, die wir so tief noch nicht behandelt haben. Gleichzeitig wird sich Dir als Facilitator die Frage stellen, wie Du denn nun anfangen sollst…

Read More

Folge 054 STACEY

STACEY und seine Matrix Heute beschäftigen wir uns mit der Stacey Matrix von Ralph D. Stacey. Eins vorweg: Talph D. Stacey nimmt heutzutage Abstand von seiner Matrix, da diese missbräuchlich verwendet wurde. Wir an der Znip Academy kombinieren diese gern mit dem Cynefin Framework um geeignete Projektmanagementmethoden für Dein Projekt auszuwählen. Diese Kombination gehört zu…

Read More

Folge 046 Get shit done

Get shit done Ich glaube „get shit done“ ist nicht nur eines von Janinas Lieblings Sprüchen, sondern in ihrem Fall sogar ein Lebensmotto. Also es geht auf jeden Fall darum Dinge fertig zu kriegen! Dreh und Angelpunkt unseres Jobs als Scrum Masterin ist es nicht Dinge anzufangen und dies vielleicht auch noch zu tracken (zu…

Read More

Folge 041 KanBan Prinzipien

KanBan Prinzipien In den letzten beiden Folgen haben wir bereits über die KanBan Praktiken gesprochen und heute schließen wir die Serie mit den KanBan Prinzipien ab. Die Prinzipien sind eine Art Leitplanken, die Dir KanBan mitgibt. Bevor es losgeht, haben wir erst einmal die 41. Folge zu feiern! Seit 41 Folgen geben wir dir wertvolles…

Read More

Folge 040 Mehr KanBan Praktiken

Mehr KanBan Praktiken Da wir in der letzten Folge nicht fertig geworden sind mit den KanBan Praktiken, gibt es in dieser Folge die restlichen. Wir starten mit einer Anekdote: KanBan wird in einigen Kirschblütenhainen eingesetzt. Am Eingang gibt es eine kostenlose Eintrittskarte, die man am Ausgang wieder abgibt. Wozu das Ganze, wenn die Karte doch…

Read More

Folge 039 KanBan Praktiken

KanBan Praktiken Teil 1 Heute haben wir endlich unsere KanBan Praktiken Folge. Es geht gezielt darum Arbeit zu erledigen. „Getting Shit Done!“ Dies ist die Folge dazu. Wir starten mit den Praktiken und es gibt noch eine gesondere Folge nur zu dem Thema „Getting Shit Done!“. KanBan ist eine Strategie, die den Flow managed und…

Read More

Folge 037 StoryPoints

StoryPoints Heute beschäftigen wir uns wieder mit einem Begriff aus dem modernen Projektmanagement. Den StoryPoints. Sicherlich wird Dir diese Maßeinheit im Kontakt mit agilen Teams untergekommen sein, da sie häufig verwendet wird. Um Dir nun zu zeigen was es damit auf sich hat und warum wir auf welche Weise im Agilen Umfeld schätzen zeigen wir…

Read More

Folge 032 Cynefin (komplex und chaotisch)

Cynefin Framework – komplex und chaotisch Wir schließen direkt an die letzte Folge zum Cynefin Framework, von Dave Snowden, an und machen mit den Bereichen komplex und chaotisch weiter. Das letzte Mal ging es um die Bereich clear/klar und kompliziert. Wir verwenden auch in dieser Folge wieder Beispiele mit Autos. Du erinnerst Dich vielleicht klar…

Read More

Folge 031 Cynefin (klar und kompliziert)

Cynefin Framework – klar und kompliziert Heute Reden wir über das Wort, welches viele nicht aussprechen können. Nämlich das Cynefin Framework (Wikipedia) von Dave Snowden. Ausgesprochen wird es kəˈnɛvɪn und kommt aus dem Walisischen. Doch hör Dir Dave Snowden einfach selbst an, er erklärt auf YouTube, wie es auszusprechen ist. Übersetzt bedeutet es in etwa…

Read More

Folge 028 Routinen und Rituale

Routinen und Rituale Anknüpfend an die letzte Folge beleuchten wir nun die andere Seite von Routinen und Rituale. Hast Du die Folge 026 Rituale und Routinen noch nicht gehört, dann empfehle ich Dir erst einmal dort rein zu hören. Routine ist eine Wegerfahrung. Also eine Erfahrung die wir im Laufe der Zeit machen. Warum funktionieren…

Read More

Folge 027 Special Talk zum Scrum Guide 2020 – Dauerwerbesendung :-)

Special Talk zum Scrum Guide 2020 Aus aktuellem Anlass war natürlich unser Top Thema der Scrum Guide 2020, welcher am 18.11.2020 released wurde. Die lieben David und De Long vom „Wir müssen reden“ Podcast haben sich mal wieder mit uns (Janina und Henry) zusammen gezoomt. Das Video zu dieser Folge könnt ihr euch natürlich auch…

Read More

Folge 026 Rituale und Routinen

Rituale und Routinen Was haben Biberburgen mit Ritualen und Routinen zu tun? Die zwei großen R’s. Auf Janina wirken Rituale eher gläubig. Stimmt das? Sie ist echt dicht dran. Dafür können wir einmal Wikipedia zitieren. Ein Ritual ist eine nach vorgegebenen Regeln ablaufende, meist formelle und oft feierlich-festliche Handlung mit hohem Symbolgehalt. Sie wird häufig…

Read More

Folge 025 Transparenz

Transparenz Wir haben in der Empirie Folge bereits über Transparenz gesprochen. Für mich ist es der erste Baustein für agiles Arbeiten und gehört damit auch zum Mindset. Damit es nicht so als Nominalisierung im Raum steht widmen wir heute dem Ganzen extra noch eine Folge. Denn es gibt viel mehr dazu zu erzählen. Das erste,…

Read More

Folge 021 Flexibilität erleben

Du willst Flexibilität erleben? Doch lass uns ganz von vorn befinden. 1987… ähhh nein, vielleicht doch 2014 mit Janinas Ernennung zum Scrum Master. Wie ging es Dir damals, als Du zum Scrum Master ernannt wurdest? Was hast Du dann gemacht und wie fühlte sich das an? Wie nachhaltig sind die Trainings, die Du besucht hast?…

Read More