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….