In dieser Episode diskutieren die Gastgeber über das Buch „Toyota Kata“ von Mike Rother und seine Bedeutung für die DevOps-Welt. Sie erkunden die Kernkonzepte der Toyota Kata, wie das Improvement Kata und das Coaching Kata, und ziehen Parallelen zu agilen Methoden und DevOps-Prinzipien, insbesondere in Bezug auf kontinuierliche Verbesserung, Prozessfokussierung und die Rolle von Metriken und Feedback. Dabei wird deutlich, dass die Prinzipien von Toyota Kata weit über den Automobilsektor hinausgehen und auch im IT- und Softwareentwicklungsbereich von großer Bedeutung sind.
Inhalt
- Einführung in das Buch „Toyota Kata“ von Mike Rother
- Gemeinsamkeiten und Unterschiede zwischen Toyota Kata und DevOps
- Bedeutung von Improvement Kata und Coaching Kata
- Vergleich zwischen Toyota Produktionsprozess und IT-Entwicklungsprozessen
- Fokus auf Prozessverbesserung und Metriken in beiden Bereichen
- Anwendung der Kata-Prinzipien in der IT und Softwareentwicklung
- Diskussion über spezifische DevOps-Themen wie Continuous Delivery und Wertstromanalyse
- Feedback und kontinuierliche Verbesserung als zentrale Elemente
Shownotes
https://websites.umich.edu/~mrother/Homepage.html
https://www.amazon.de/stores/Mike-Rother/author/B002AQBVLE
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
DevOps. Auf die Ohren und ins Hirn.
Ein Podcast rund um DevOps.
Von Dierk Söllner, Falko Werner und Luca Ingianni.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
Der DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Wir freuen uns heute auf das Thema Toyota Kata.
Zu Gast haben wir, zumindest im Geiste, Mike Rother.
Das ist nämlich der Autor dieses Buchs Toyota Kata.
Und wir haben es jetzt gerade Sommer, die Sommerferien sind gerade zu Ende in Bayern.
Und über die Sommerferien habe ich mir dieses Buch Toyota Kata als Audiobuch angehört.
Und ich fand das sehr interessant und wollte mich mit Falko und auch mit euch,
liebe Hörerinnen und Hörer, so ein bisschen darüber austauschen,
was mir aufgefallen ist an Gemeinsamkeiten.
Vielleicht an Unterschieden und überhaupt, was man halt so daraus mitnehmen kann.
Auch von mir herzlich willkommen und schöne Idee.
Finde ich letztendlich gut.
Du hast dir das Audiobuch angehört, ich noch nicht.
Ich habe so ein bisschen mit Toyota Kata schon Erfahrungen gesammelt in Unternehmensumfeldern,
durch andere Coaches und in verschiedenen Umgebungen.
Nichtsdestotrotz, wenn du sagst, es ist ein Buch von Mike Rother und er ist im Geiste bei uns,
was magst du über Mike irgendetwas sagen, was ist wichtig zu wissen,
was muss man zur Person des Autors des Buches mal gehört haben?
Ja, was gibt es übrigens zu sagen?
Also Mike Rother ist ein Forscher, der ist eigentlich ein Ingenieur, so ähnlich wie wir beide,
der sich fokussiert hat auf diese Themen von Lean Manufacturing, kontinuierlicher Verbesserung
und auf diese Weise, ich glaube, mehr so versehentlich auch Toyota Kata.
Der hat sehr viel gearbeitet im Umfeld der Automobilindustrie.
Nicht nur bei Toyota und Toyotas Zulieferern, sondern auch offensichtlich, das kommt in dem Buch raus,
auch mit deutschen Automobilherstellern.
Ich habe so das Gefühl, der hat beim Daimler was gemacht oder sowas.
Er nennt keine Namen, aber irgendwie klang es immer so nach süddeutschem Raum, wenn ich das gelesen habe.
Na gut, da gibt es ja auch ein paar andere, die nicht nur Daimler heißen oder Mercedes oder was auch immer.
Aber ist ja völlig okay.
Wir müssen ja hier auch keine Namen weiter nennen.
Außer von dem japanischen Automobilhersteller, der im Namen des Titels,
was gibt es noch zu wissen?
Was gibt es noch zu wissen?
Also, der ist, glaube ich, am ehesten berühmt dafür, dass er dieses Buch Toyota Kata geschrieben hat.
Ich muss gerade mal schauen, wann wurde das eigentlich verfasst?
In den 90ern oder so?
Es ist nicht mehr so mega neu.
Er hat aus diesem Buch natürlich sehr viel Kapital geschlagen.
Also, er bietet auch Seminare an.
Er hat als Dozent irgendwie die Ideen darin verbreitet.
Aber er hat auch, also ich meine, er hat das auch wirklich sehr eingehend erforscht
und wahrscheinlich besser erforscht, als es jemand gekonnt hätte,
der einfach ein altgedienter Toyota-Mann ist,
weil er schon auch diese Sicht von außen hat.
Das fand ich auch interessant in dem Buch.
Das hat er immer wieder gesagt.
Manchmal hat er sich mit Leuten bei Toyota unterhalten und die haben ihn überhaupt nicht verstanden.
Und erst Jahre später ist er darauf gekommen,
dass die einfach eine ganz andere Perspektive auf dieselben Fragestellungen hatten als er.
Zum Beispiel, was sind Zielbedingungen?
Was ist eine gut formulierte Zielbedingung?
Und was mache ich, wenn ich die erreiche oder so?
Oder kann ich die überhaupt erreichen?
Und insofern, genau, hat er schon, finde ich, da etwas sehr Richtungsweisendes verfasst.
Ich habe jetzt gerade mal so ein bisschen recherchiert zu dem Thema Buch und Historie und so weiter
und finde da auch viele Neuauflagen, Übersetzungen und anderes.
Insofern gibt es da nicht nur ein Buch,
sondern quasi eine ganze Sammlung von Serien, von Materialien, die hilfreich sind.
Ja, genau.
Mittlerweile gibt es da natürlich einiges mehr zu den Themen,
es gibt Nachfolgebücher, es gibt Arbeitsbücher und alles sowas.
Es gibt, wie gesagt, auch das Hörbuch, das lässt sich gut anhören.
Er hat übrigens auch ein Buch, das wahrscheinlich lesenswert ist, geschrieben über Wertströme,
die ja auch letzten Endes eine Idee waren, die, ich weiß nicht, ob man sagen kann,
Toyota sie erfunden hat, aber die jedenfalls dort sehr viel Interesse genießen, Aufmerksamkeit genießen.
Genau.
Also, lasst uns doch mal kurz darüber reden, um was geht es denn eigentlich in diesem Buch Toyota Kata?
Es geht breit gesprochen darum, wie Toyota, mit welchen Methoden Toyota,
es geschafft hat, zu einem der größten Automobilhersteller der Welt zu werden
und das über Jahrzehnte zu bleiben.
Und was der Mike Rotter beschreibt, ist, dass ganz zentral dafür zwei Praktiken sind,
die auf allen Ebenen bei Toyota angewendet werden, nämlich, und er nennt die Katas.
Er sagt, bei Toyota heißen die gar nicht so, sondern da ist das halt einfach so,
wie man bei Toyota arbeitet, das hat in dem Sinne keinen Namen.
Genau, und Kata für jene, die irgendwie sich mit fernöstlichen Kampfsport,
das ist eine Übung, eine ritualisierte Abfolge von Handlungen, von vielleicht Bewegungen oder sowas,
die dazu dienen, eine Praxis tief zu verankern und deine Fähigkeiten zu verbessern.
Also quasi von dem Gedächtnis und dem aktiven Arbeiten in quasi Muskelgedächtnis zu überführen,
dass man es mehr oder weniger automatisch macht.
Das erinnert mich so ein bisschen an das Thema Scrubbing.
Scrum, das man halt auch in der Softwarewelt sehr häufig findet,
aktives Arbeiten im Team mit bestimmten Regeln, die im Scrum Guide stehen,
die man halt abarbeiten kann, regelmäßig als Event durchlaufen kann,
den Sprint mit den verschiedenen Elementen, unter anderem der Retrospektive.
Und dahinter fragt man ja auch bestimmte Dinge, die Verbesserungen angehen
oder Coaching-Elemente einfließen lassen.
Wo ist denn der Unterschied zwischen einer Kata?
Und solch einem agilen Vorgehen mit bestimmten Ritualen?
Ich glaube, in welcher Sprache der Begriff ausgedrückt wird oder so.
Nee, in der Tat ist es eine Sache, die mir auch viel in einem gewissen Sinne ist,
das Buch fast ein bisschen langweilig zu lesen, weil es irgendwie nichts grundlegend Neues zu bieten scheint.
Da wird dann halt beschrieben, es gibt diese Improvement-Kata, man kann das auch eine Retro nennen.
Es gibt eine Coaching-Kata, es gibt so Sachen wie ein Prozess,
ein Wertfokus, es gibt so Themen wie Visual Management, kann man Bretter und weiß, was weiß ich noch alles,
wo jeder gestandene Agilist halt irgendwie sagt, so, ja, kenne ich alles.
Aber das ist halt ein bisschen so wie, wenn du das Gefühl hast, dass der Goethe ja einfach nur Phrasen gedroschen hat.
Ja, der hat halt diese ganzen ollen Sprüche wieder aufgewärmt, bis du irgendwann darauf kommst,
ach nee, der hat die erfunden und wir wiederholen die jetzt bloß alle.
Keine Ahnung, mit des Pudels Kern oder sowas.
Ja, das ist halt so.
Ja, das ist halt so.
Ja, das ist halt so.
Ja, das ist halt so.
Ja, das ist halt so.
Ja, das ist halt so.
Ja, das ist halt so.
So ist das mit ganz vielen Sachen, die in dem Toyota Kata drinstehen.
Die haben sich zwar mittlerweile verbreitet, aber vielleicht wurden sie ursprünglich wirklich entwickelt,
durchdacht, zur Praxis erhoben, im großen Stil erstmalig bei Toyota.
Das weiß ich offengestanden nicht, das ist vielleicht auch gar nicht erheblich.
Keine großen Unterschiede.
Aber du hast zwei Begriffe gerade genannt, die ich gerne besser verstehen wollte.
Und zwar du hast von Katas, Verbesserungskata und Coachingkata gesprochen.
Was ist der Unterschied?
Genau.
Jetzt habe ich da schon so ein bisschen die Katze aus dem Sack gelassen.
Also, bei Toyota gibt es zwei grundlegende Praktiken.
Diese Verbesserungskata und die Coachingkata.
Diese Verbesserungskata, Improvementkata, ist ein systematischer Ansatz, um Umstände zu verbessern.
Und zwar unter den Einschränkungen von natürlich Unsicherheit, von Unschärfe,
einer komplexen, dynamisch sich verändernden Situation.
Wie kann ich da also meine bestehenden Praktiken weiterentwickeln hin zu etwas,
was hilfreicher, zielführender ist.
Und darüber gelegt, sagen wir mal, ist das Coachingkata,
das ein Ansatz ist, dass Mentoren auf jeglicher Ebene ihren Schützlingen dabei helfen,
dieses Improvementkata richtig anzuwenden.
Das Coachingkata auch sich selbst zu einer Gewohnheit werden zu lassen,
einfach durch Beobachtung.
Das ist halt das, was mein Mentor immer mit mir gemacht hat.
Und dafür zu sorgen, dass also einerseits natürlich Toyota als Organisation sich verbessert,
im Großen oder im Kleinen.
Aber vor allen Dingen, dass dieser Ansatz verbessert, gefestigt und umgesetzt wird.
Das sind die zwei Sachen, die quasi ständig ablaufen.
Und wenn du jetzt sagst, naja, das klingt jetzt natürlich auch wieder sehr nach agilen Vorgehen,
mit Kleinschrittigkeit, mit Feedback und so weiter, dann sage ich, ja, stimmt, genau.
Das ist halt genau das.
Ja, ist auch schön, wenn man die Strukturen an verschiedenen Stellen wiederfindet,
wiederverwendbare Muster hat, die in unterschiedlichen,
unterschiedlichen Unternehmen gut funktionieren und kann man sie auch regelmäßig wieder einsetzen
und weiß, dass sie gut funktionieren, weil sie halt eben nicht aus einem Unternehmen gerade kommen
und nur dort das Nonplusultra sind, sondern sind halt gute oder vielleicht sogar Best Practices.
Genau so ist es.
Und zumindest aus meiner Sicht liegt genau darin, der Wert dieses Buches,
dass es den Blick für uns weitet, die wir vielleicht immer so ein bisschen
in unseren Augen sehen.
Genau so ist es.
Genau so ist es.
Genau so ist es.
Genau so ist es.
Genau so ist es.
Genau so ist es.
Und das für mich ist der große Wert dieses Buchs, dass es wirklich sagt,
nein, das passt nicht nur auf die IT, sondern das passt auf viele Arten von Situationen,
von Aktivitäten, von Organisationen.
Ja, das sieht man ja an verschiedenen anderen Dingen, die in die IT übernommen worden sind,
aus dem Produktionsumfeld.
Da sehe ich Kanban als Signalisierungsmechanismus, Arbeitsweise zum Planen, Strukturieren von
Vorgehen von Arbeit.
von Übergaben und Abhängigkeiten von unterschiedlichen Teams, Teambereichen.
Wir hatten, glaube ich, auch mal für ein skaliertes Umfeld eine frühere Podcast-Folge gehabt zum
Thema Flight Levels, die in dem Umfeld natürlich genauso wiederverwendbar sind, wie das offenbar
bei der kontinuierlichen Verbesserung, die Toyota Kata darstellt.
Sehr gut.
Wollen wir ein Stück weiter in die Tiefe gehen?
Also du sagst, die Coaching Kata baut auf…
…auf der Improvement Kata auf.
Also das Ziel ist quasi die kontinuierliche Verbesserung und das Coaching unterstützt das Ganze.
Also würde ich jetzt sagen, wie läuft dann so ein Improvement Kata ab?
Wer organisiert das?
Wie ist da die Struktur?
Auf was muss man achten?
Gibt es irgendwelche Hilfsmittel?
Also es gibt eine ganze Reihe von Sachen.
Gerade was Hilfsmittel angeht, würde ich sagen, die sind vielleicht tatsächlich ein bisschen
unternehmensspezifischer.
Ob es da vielleicht zum Beispiel…
…Checklisten gibt oder Formulare, dass man sagt, hier ist ein strukturiertes, ein Hilfsmittel,
um dir dabei zu helfen, strukturiert, die gegenwärtige Situation zu durchdenken.
Aber ganz grundsätzlich ist so ein Improvement Kata ja einfach nur ein Ausdruck von einem
klassischen PDCA-Zyklus.
Das ist auch ein Begriff, der in dem Buch vorkommt.
Plan, Do, Check, Act.
Zuerst überlege ich mir die gegenwärtige Situation.
Dann unternehme ich ein Experiment, überprüfe dessen Ergebnis und dann reagiere ich auf
was auch immer das Ergebnis des Experiments war.
Das Interessante daran ist, dass die eben ganz ausdrücklich sagen, man soll sich auf
die Prozessverbesserung, nicht auf die Verbesserung des Outcomes, des Resultats fokussieren.
Will heißen, wenn ich zum Beispiel, angenommen ich habe eine Fertigungslinie und die soll
700 Autos diese Schicht fertigstellen.
Was eben interessant daran ist, ist, dass in diesem Improvement Kata man auch ganz klar
sich auf den Prozess fokussiert und nicht auf das Outcome, auf das Resultat.
Und das heißt, dass das Beispiel, das er in dem Buch bringt, ist zum Beispiel, wenn es
darum geht, ich habe eine Fertigungslinie, die soll in dieser Schicht 700 Autos bauen
oder sowas.
Und sie schafft es nicht.
Irgendwas läuft da schief und es ist absehbar, die kommen ins Rutschen oder sowas.
Dann gibt es jetzt 200.
Dann gibt es zwei Möglichkeiten, wie man vorgeht.
Entweder man sagt, wir müssen jetzt auf 700 Autos kommen, diese Schicht.
Dann wird man da entsprechend irgendwie Prozessänderungen vornehmen, wird, keine Ahnung, ein paar Werker
von woanders abziehen, wird die da schnell noch irgendwie mit dazustecken und schauen,
dass man im Plan bleibt, dass man sein Ziel schafft.
Das wäre vielleicht so die Art und Weise, wie es in vielen Firmen gehandhabt wird.
Und Toyota sagt, nein, das wäre völlig verfehlt, sondern wir nehmen in Kauf, dass
wir jetzt unser Schichtziel verpassen.
Diese Schicht wären es nicht nur 650 Autos, sondern es wären sogar nur 600 Autos, weil
wir machen jetzt nämlich die Pferdescheu und fangen an, Verbesserungen vorzunehmen oder
uns Gedanken zu machen oder sowas, mit dem Ziel, dass in der Zukunft dieses Problem ausgemerzt
ist.
Genau.
Passt also ganz gut zu dem Gedanken des Andern, so des Signals, die Linie zu stoppen, wenn
man ein Problem feststellt, dass man dann sich auch die Zeit nimmt, in die Ursachenanalyse
zu gehen, vielleicht 5Y-Runde durchgeht.
Entsprechend schaut, was ist wirklich die Ursache, vielleicht auch wirklich fünfmal
hintereinander in die Tiefe fragt, was ist der Grund dafür, was ist der Grund dafür,
um dann an dem ursprünglichen Kern des Pudels, von dem du, Gütte, seit ich gerade gesprochen
hast, anzusetzen und wirklich an der Ursache dann auch Veränderungen vorzunehmen und zu
schauen, dass das halt möglichst nicht wieder auftaucht.
Und manchmal sind es ja ziemlich unglaubliche, weit weg.
Von der Wirkung liegende Ursachen, wenn man wirklich in die Analyse reingeht, da zu schauen
und ganz tief zu klicken.
Okay, gut.
Also Fokus auf den Prozess statt auf die Ergebnisse.
Damit man einen stabilen Prozess hat, die Beherrschung des Prozesses quasi steigt, Sicherheit
für die Zukunft, das ist quasi eine Investition in die Zukunft der Produktionslinie und das
kann man natürlich auch auf die IT übertragen.
Das heißt…
Wenn eine Continuous Delivery Pipeline für ein Softwareentwicklungsprojekt Fehler meldet,
dann wirklich halt auch zu schauen, wo ist die Ursache, ist das halt wirklich der Code
Commit, der gerade einen Fehler produziert oder ist vielleicht auch ein Update, eine
Aktualisierung, eine Verbesserung an der Continuous Delivery Pipeline hilfreich, um umzusetzen
und in Zukunft vielleicht weniger Schwierigkeiten zu haben.
Cool.
Genau.
Und dazu muss man aber noch etwas anderes.
Was sehr zentral ist und was auch meiner persönlichen Erfahrung nach häufig sehr schwierig
ist, nämlich man muss die richtige Zielbedingung formulieren.
Target Condition, wie es genannt wird in dem Buch.
Und das ist der Einstieg in so einen Cut-Up-Prozess?
Nicht mal unbedingt ein Einstieg in dem Sinne, weil so eine Zielbedingung kann auch etwas
sehr Großräumiges sein.
Das kann wie eine Vision sein oder sowas.
Es kann kleinräumig sein.
Es kann sein, wir wollen, keine Ahnung, zuverlässig Autos für die Schicht produzieren.
Vielleicht ist das eine Zielbedingung.
Aber es kann auch sein, wir wollen, keine Ahnung, der dominante Autohersteller weltweit sein
oder sowas.
Ach, das ist richtig in Management-Ebenen, in jeder Ebene des Unternehmens einsetzbar,
nicht nur in der Produktionslinie?
Genau.
Aber das Wichtige ist eben, darum, ich habe es ein bisschen zusammengezuckt, als ich gerade
eben das Beispiel mit den 700 Autos gebracht habe, weil es wäre genau eine ganz ungünstige
Zielbedingung, weil damit setzt man einen Anreiz, kurzfristig den Prozess gerade zu
ziehen.
Damit man sein Schichtziel schafft, aber unter vielleicht in Kaufnahme eine Verschlechterung
des allgemeinen Prozesses oder einer Maskierung von Fehlern, was auch aus Toyota-Sicht genauso
schädlich ist.
Was wäre denn ein gutes Beispiel für eine Zielbedingung, wenn das Ziel, 700 Fahrzeuge
pro Schicht herzustellen, eben auf Outcome fokussiert und deswegen eher ungünstig wäre?
Ich versuche mich gerade zu erinnern.
Was?
Was?
Was ist da in dem Buch für Beispiele gebracht worden?
Und mir fällt natürlich jetzt spontan gerade keins ein.
Aber es ging immer darum, dass man im Prinzip in eine ähnliche Richtung denkt, wie im Agilen
dann immer mit dem Wertfokus, dass man also sagt, was ist das dem übergeordnete Ziel?
Zum Beispiel vielleicht für diese Fertigungslinie, wir wollen unsere Zusagen verlässlich einhalten
können.
Nicht 700 Autos, sondern die Linie ist verlässlich.
Ich habe jetzt gerade an Qualität gedacht, also ähnlich wie wir es im DevOps-Umfeld,
häufig mit Prinzipien zu tun haben, Build-Quality-In oder Ende-zu-Ende-Verantwortung auch zu übernehmen.
Halt nicht nur für eine Zahl-Schicht-Ziel oder Produktions-Output, sondern halt eine
Verantwortung auch für andere Dinge, die man aus dem Lean-Umfeld kennt.
Also ein guter, sauberer Arbeitsplatz, verlässliche Abläufe.
Das sind ja auch Dinge, die man mit zum Beispiel Wertstromanalysen oder anderen in dem Umfeld
auch häufiger auftauchen.
Also insofern diese Ende-zu-Ende-Verantwortung finde ich da ganz hilfreich, wo dann Qualität
eben auch mit reinfällt.
Genau, aber was du gerade gesagt hast, auch aus dem DevOps-Kontext, jetzt fällt es mir
nämlich wieder ein, wären dann auch gute Ziele, vielleicht solche Dinge wie Defektraten
oder sowas.
Dass man sagt, wir möchten bitte schön, auch wie man es zum Beispiel von den Dora-Metriken
kennt, mit ihren einander widersprechenden Zielrichtungen, dass man sagt, ich möchte
gerne ein hohes Ziel haben.
Also eine niedrige Produktionsrate haben und eine niedrige Defektrate zum Beispiel.
Also ein mehrdimensionales Ziel, das man dann verfolgt.
Mehrere, keine Ahnung, Messgrößen, die scheinbar widersprechend sind, wo man aber beides trotzdem
anstrebt.
Also letztendlich doch, vielleicht auch eine Steigerung mit der verbesserten Qualität,
eben nicht nur 700 Fahrzeuge zu schaffen, sondern vielleicht konstant regelmäßig 714,
nachdem man die Verbesserung erreicht hat und eine Prozessstabilität.
Und dann halt festgestellt hat, ja, da gab es halt ein Problem.
Das hat auch den Durchsatz, in dem Engpass vielleicht sogar, im besten Fall, den Durchsatz
auch beeinflusst und man kann jetzt auch mehr produzieren, nachdem man weiß, wo die Ursache
liegt.
Was interessanter übrigens auch in dem Buch war, dass Toyota durch Mike Rutter sagt, es
ist in diesem Zusammenhang häufig gar nicht hilfreich, bei der Analyse von Problemen sich
mit den eigentlichen Werkern zu unterhalten und die zu interviewen.
Weil die werden zwar auf jeden Fall eine Antwort haben, werden sie ganz bestimmt, aber sie
werden häufig den Wald vor lauter Bäumen nicht sehen.
Und die werden dir dann sagen, ja, mein Problem ist, dass mir die Schrauben ausgehen.
Wie geht man dann damit um?
Also was ist dann der Ansatz, wenn man eben nicht Go-See machen kann, also sich wirklich
das Thema von der untersten Ebene an betrachtet, sondern wie geht man dann vor?
Das ist genau das, worin die…
Kunst von guten Zielbedingungen liegt.
Dass man sagt, ich gehe nicht auf die unmittelbare Zielbedingung, den Werker dürfen die Schrauben
nicht ausgehen, sondern ich trete einen Schritt zurück und sage, was ist denn das eigentliche
Problem, das ich zu beheben gedenke oder die eigentliche Bedingung, die ich zu verbessern
gedenke.
Insofern wird man natürlich den Prozess beobachten und auch vielleicht die Prozessbeteiligten
mal sprechen, aber nicht in dem Sinne von erzähl mir mal, wo deine Probleme sind und
dann führe ich die einer Lösungsfindung zu, sondern wirklich sich hinstellen und
eigentlich die Probleme zu beheben.
Und dann schauen, was passiert denn da im Prozess eigentlich.
Und übrigens, das fand ich auch ganz spannend, weil das war auch ein neues Learning für
mich eigentlich.
Toyota sagt, häufig ist es klug, eine Prozessanalyse und eine Prozessverbesserung nicht etwa da
zu beginnen, wo man den größten Waste hat, wo man zum Beispiel die größten Digizeiten
hat oder sowas, was ja eigentlich naheliegend wäre, sondern am Ende eines Prozesses, da
wo nämlich der Kunde…
Und das ist ja genau dasselbe übrigens, was wir auch kennen, zum Beispiel aus der Softwareentwicklung,
wenn der Stakeholder ums Eck kommt mit einem ganz eiligen Requirement, das jetzt ganz schnell
umgesetzt werden muss und so und schmeißt mir hier mein ganzes Ding über den Haufen.
Muss ich vielleicht mal Sprint kippen, weil alle meine schönen Planungen sind beim Teufel.
Tut richtig weh und insofern an diesem Ende, wo Bestellungen an den Kunden gehen oder andersrum,
wo der Kunde sich äußert, da Verbesserungspotenziale zu heben, bringt häufig erst überhaupt die
Ruhe und Stabilität in einen Prozess rein, der auf den Schlag den Prozess besser macht,
aber die es einem auch ermöglicht, überhaupt zu verbessern.
Ja, gut, aber das ist ja an sich gar nicht so unintuitiv, wenn man ein Verständnis für
das Pull-System hat.
Also Toyota ist ja einer von den Vorreitern von dem, was man Lean-Management nennt und
sie haben ja bewusst mit Kanban-Karten, Signalsteuerung und Co. die Arbeitsweise am Kunden ausgerichtet,
nach den Kundenbedürfnissen.
Und der Kunde gibt den Takt vor, was letztendlich aber heißt, dass man am Ende des Systems ein
Pull-Prinzip hat und von da an natürlich auch in Verbesserungen gehen sollte, was mir
gerade den Hinweis gibt, wenn ich den nächsten Wertstrom-Workshop mache, dass ich vielleicht
auch bei der Wertstromanalyse bewusst nicht nur nach der Voice of the Customer frage,
also was ist das Ziel oder der Wunsch, Kundenwunsch oder Dankwunsch.
Und dann, wenn man es nochmal hinterfragt, das Kundenbedürfnis, sondern auch, wie endet
der Prozess und die Wertstromanalyse rückwärts vorzunehmen.
Gibt es dazu Aussagen auch in dem Buch, Toyota Kanta?
Nee, darauf geht er nicht ein.
Wertstromanalyse insgesamt kommt nicht wirklich vor in dem Buch, sondern er spricht da wirklich
über Prozessverbesserungen, die vielleicht irgendwie ein Wertstrommodell zugrunde legen,
aber das kommt eigentlich nicht zur Sprache.
Aber was anderes ist auch interessant, weil nämlich…
Also.
Zum einen, ja, Pull-Prinzip und so, aber das, was ich gerade geschildert habe, wenn
die Pulls des Kunden irgendwie zu unrund werden, dann schadet das dem ganzen Prozess.
Mit anderen Worten, einfach nur ein Pull-Prinzip macht diese Sachen ja nicht von alleine auf
einmal irgendwie wunderhübsch.
Und in der Tat, du hast mich gerade daran erinnert, das war eine der Sachen, die ich
auch nicht so ganz erwartet hatte aus dem Buch.
Er hat gesagt, am Anfang seiner Arbeit als Prozessverbesserer ist er auch oft zu forschter
reingegangen, hat gesagt, so, wir machen da jetzt überall irgendwie ein Pull-Prinzip
und kann man Bretter und alles wird wunderhübsch.
Und ist furchtbar auf die Schnauze geflogen, weil der ganze Prozess noch überhaupt nicht
stabil genug war, um sowas einzusetzen.
Sondern dann hattest du auf einmal riesige Unschärfen und Oszillationen und dann kamen
die ganzen Produktionsplaner und haben gesagt, siehste, geht gar nicht.
Wir müssen eine Produktion planen.
Ich hab dir doch gleich gesagt, das geht in die Hose.
Weil die dann, ich sag jetzt mal, das dämpfende Glied waren, dass diese Unsauberkeiten, Unrundheiten
aus dem Prozess so ein bisschen rausgehalten hat.
Mit anderen Worten, einfach nur…
Naiv, ein Pull-Prinzip einzuführen, interessanterweise, macht es schlimmer.
Das Einzige, den Vorteil, den du davon hast, du siehst dann sehr genau, wo es kracht.
An irgendeiner Stelle fliegt dir alles um die Ohren und die ist dann bekannt.
Aber deine Fertigung steht.
Genau, ist schon mal ein großer Wert, aber produziert halt keinen Kundennutzen direkt,
sondern ist ja wie bei der Einführung, wenn man jetzt sagt, agile Transformationen von
einem Unternehmen.
Agilität ist auch ein Werkzeug, das hilft, die Problemstellen…
…sichtbar zu machen, die in einem Unternehmen in der Softwarefertigung auftauchen.
Also auch da ist letztendlich ja nicht Agilität das Allheilmittel für Zusammenarbeit und
die Produkterstellung und Co., sondern ist letztendlich das Ding, das sichtbar macht,
wo die Probleme sind und damit die Chance gibt, sie zu beheben.
Genau, aber trotzdem, da muss man auch aufpassen, weil er hat dann auch gesagt, naja, da hat
er halt auch viel guten Willen verbrannt bei Schichtführern oder Produktionsbüchern,
Planer oder sowas, weil er da halt irgendwie ganz nass vor euch ankam und gesagt hat, so,
jetzt pass mal auf, ich zeige euch jetzt, wie das geht, zack, bumm.
Und es ging natürlich gar nicht.
Ja, auch da, Agilität, kleine Schritte, kontinuierliche Verbesserung, kann man sagen, starte, wo du
bist.
Also im aktuellen System, nicht 25 kann man Boards und komplett Pull-Prinzip von hinten,
sondern in kleinen Schritten schauen, okay, was passiert, wenn wir jetzt am Ende starten
und an einer Stelle den Kunden in den Mittelpunkt stellen.
Dann haben wir natürlich unrunde, vielleicht sogar Jahreszeiten oder anderen Quellen abhängige
Abforderungen im System.
Damit das Pull-Prinzip und Lean funktionieren, gibt es natürlich auch so ein paar Hinweise,
dass man eben bewusst glättet, Anforderungen glättet und einen kontinuierlichen Fluss auch
da produziert.
Also nicht nur, dass das Werkstück oder das Produkt durch die Produktionslinie kontinuierlich
fließt.
Sondern, dass man auch einen möglichst geglätteten Anforderungskanal hat.
Also lineare Auslieferung.
Und übrigens, das ist auch etwas, was Bestandteil von diesem Improvement Cutter ist, such dir
Erprobungsmöglichkeiten mit möglichst kurzen Feedback-Zyklen.
Wenn du die Möglichkeit hast, eine Linie groß umzubauen und der Umbau dauert zwei Wochen
und du hast die Möglichkeit, sie klein umzubauen und der Umbau dauert einen halben Tag, dann
mach das, was einen halben Tag dauert und versetze dich in die Lage zu beobachten.
Kleine Schritte, wie gerade gesagt.
Ja, auch da nochmal konkret.
Das ist der Kern von diesem Improvement Cutter, dass man sagt, auf jeder Ebene, an jeder Stelle
des Prozesses machen wir fortwährend solche Beobachtungen.
Man würde sagen, eine Retro im agilen Sinne.
Wir versuchen, Schwächen zu finden.
Wir versuchen, uns gute Zielbedingungen zu formulieren, die möglichst, ich sage jetzt
mal, ergebnisoffen sind, möglichst zukunftsgewandt und nicht einfach nur, es geht ja nicht um
das Schichtziel zu erreichen, sondern es geht darum, dass Toyota als Ganzes ein kleines
bisschen besser gemacht wird und dann auf dieser Ebene iterieren, Plan-Do-Check-Akt
und so weiter.
Was da noch gar nicht zur Sprache kam, übrigens, sind zwei Sachen, die auch sehr wichtig sind,
nämlich einerseits, dass alle Angestellten daran teilhaben sollen.
Also jeder soll in der Lage sein, Vorschläge zu unterbreiten.
Jeder soll dann auch in der Lage sein, sich zu vermitteln.
Jeder soll in der Lage sein, diese Vorschläge umzusetzen und auszuprobieren.
Es soll keiner eine Scheu haben, auch zum Beispiel eine Andon-Linie zu ziehen und zu
sagen, stopp, hier ist was falsch und wir müssen unsere Aufmerksamkeit darauf lenken.
Und das andere, was ich auch interessant fand, war, dass sie auch gesagt haben, ganz wesentlich
ist, dass man überhaupt einen standardisierten Prozess hat, damit man die nötige Klarheit
hat, damit man etwas hat, was verlässlich genug verstehbar und beschreibbar ist, damit
man es systematisch vermittelt.
Und systematisch verbessern und Verbesserungen beobachten kann, auch ganz im Sinne von so
Dingen wie zum Beispiel im DevOps-Kontext Automatisierung, die natürlich in sich eine
ganz kleine Standardisierung einer Vorgehensweise ist.
Gut, wir haben sehr viel jetzt über Verbesserungen, also Improvement-Kata gesprochen.
Wir haben aber auch gesagt zu Anfang, es gibt eigentlich zwei Typen von Katas.
Ich würde noch ein Stück darauf eingehen wollen, was du aus dem Buch zum Thema Coaching-Kata
sagen kannst.
Also warum gibt es die zweite Form?
Was ist der Mehrwert und wieso wird da unterschieden?
Naja, weil es zwei ganz verschiedene Tätigkeiten sind.
Vielleicht auch ein bisschen auf verschiedenen Ebenen in dem Sinne.
Also jeder soll einen Coach haben, vom Großen bis zum Kleinen sollte jeder irgendwie einen
Coach haben und seinerseits auch gecoacht werden natürlich, damit erwünschte Verhaltensweisen
wirklich durch das ganze Unternehmen verbreitet werden und gefestigt werden.
Und beim Coaching-Kata ist es eigentlich auch wieder nichts Neues, sondern es ist halt einfach
nur der bewährte Ansatz herauszufinden, was braucht denn mein Lerner, mein Schützling,
mein Coachee gerade, was ist ihre Situation, welchen Herausforderungen sehen die sich ausgesetzt
und ihnen dann dabei zu helfen, auch aus eigener Kraft diese Situation durchzuarbeiten und
selbst das Improvement-Kata anzuwenden, das Verbesserungskata anzuwenden und auch die
auf Lösungen zu kommen.
Und der Coach, wie auch in anderen Kontexten, muss sich im Zerfelsfall auch auf die Zunge
beißen und seine eigenen Verbesserungsvorschläge für sich behalten, sondern soll wirklich
nur seinem Coachee zur Seite stehen, während der das Improvement-Kata zur Anwendung bringt.
Gut, also so ein Kata-Coach ist letztendlich vergleichbar zu einem Scrum-Master, der Teams
Arbeitsweisen näherbringt und könnte auch die fünf Coaching-Kata-Fragen einem Software-Entwicklungsteam,
einem DevOps-Team beibringen und das zum Beispiel als Form der Retrospektive nutzen, richtig?
Ja.
Was sind denn die Coaching-Kata-Fragen?
Also wir haben immer von Zielzustand, Target-Konditionierung.
Schon gesprochen, darauf baut sich ja das Ganze auf, dass man Stück für Stück so eine
Struktur hat, der man dann folgen kann, richtig?
Ja, genau.
Also das ist, genauso wie du sagst, der erste Schritt.
Was ist denn mein Zielzustand?
Was ist denn meine Target-Condition, die ich jetzt gerne verfolgen möchte, die ich vertiefen
möchte, die ich verbessern möchte?
Und daran schließt sich fast automatisch die zweite Frage an.
Was ist denn der gegenwärtige Zustand?
In welcher Weise ist mein Prozess, keine Ahnung, nicht verlässlich, nicht…
Nicht robust, was auch immer, ne?
Gibt es einen Grund, warum man zuerst das Ziel und dann die Ist-Situation beschreibt?
Erst wenn ich das Ziel kenne, kann ich den Ist-Zustand ja beschreiben.
Vorher beschreibe ich ja nur irgendwas.
Weiß ich denn, ob ich diesen Zustand, den ich beschreibe, wirklich verbessern will?
Nee, weiß ich nicht.
Erst wenn ich weiß, was das Ziel ist, dann kann ich mir Gedanken machen, wo ich mich
momentan befinde.
Ja und nein.
Man kann natürlich auch sagen, wo stehe ich gerade?
Ist-Situation?
Keine Ahnung.
Das Band läuft unrund und am Ende kommen nicht die 700 Fahrzeuge raus.
Ist natürlich auch eine Beschreibung der Ist-Situation.
Ja, aber die führt uns ja erst noch zu der Zielbedingung.
Nämlich ist das Problem, dass das Band unrund läuft oder ist das einfach nur ein
irgendwie Symptom oder sogar nur ein Bestandteil der Landschaft?
Keine Ahnung.
Oder ist das eigentliche Problem ein Mangel an Verlässlichkeit zum Beispiel?
Und da könnte ich ja sagen, naja.
Unrund oder unrund läuft ist mir zweitrangig, solange ich in der Lage bin, zum Beispiel
verlässliche Zusagen zu machen.
Deswegen, natürlich wird das immer so ein bisschen ein Wechselspiel sein.
Man beschreibt eine Situation und dann überlegt man sich, was steht dahinter im Sinne von,
keine Ahnung, Five Whys oder sowas.
Und wird sagen, okay, jetzt haben wir vielleicht eine neue Zielbedingung erfasst, die auf das
eigentliche Problem abzielt.
Nee, jetzt gehen wir nochmal einen Schritt zurück und überlegen uns, können wir nochmal
eins tiefer einsteigen?
Können wir noch eins grundsätzlicher?
Oder eins ergebnisoffener?
Dass man sagt, vielleicht ist das einfach total egal, wie rund oder unrund das Band ist.
Das Problem liegt ganz woanders.
Vielleicht dürfen wir unseren Kunden einfach nichts versprechen.
Okay, genau.
Also wir haben dann letztendlich so eine Art kleine Feedback-Schleife zwischen Ist-Situation
und Ziel und findet dann letztendlich so ein gemeinsames Verständnis zwischen Coach
und Verbesserer oder Team und sagt, okay, das ist jetzt das, worauf wir uns auch vielleicht
nach einer Fünf-Mal-Warum-Frage.
Frage-Technik-Five-Why einigen.
Das ist unser Ziel.
Und dann gehen wir nochmal konkretisieren die Ist-Situation.
Wie geht es dann weiter?
Dann stellt sich die Frage, was hindert uns daran, unsere Ziel-Situation herzustellen?
Und das kann alles sein.
Das kann Prozess, Arbeitsabläufe, das können Zulieferungen, das können Produkte, Materialien,
Stifte, Platz, Zeit, Geld, irgendwas sein.
Genau, genau.
Und es kann ja durchaus auch, sagen wir mal, vergleichsweise allgemein sein.
Vielleicht ist dann die Antwort auch wieder, was relativ breit ist, das gesagt wird.
Also meine momentane Hürde ist, angenommen, das Problem ist, mir gehen die Schrauben aus.
Ich weiß nicht, wann der Schraubenlieferer mit seinem Flurförderwagelchen vorbeikommt
und mir neue Schrauben bringt oder sowas.
Genau, dann hast du also irgendwie 30, 40 verschiedene Hindernisse, die dir im Weg sind.
Wie entscheidest du, auf welches du dich fokussierst?
Ja, also wiederum.
Das Hindernis kann also vergleichsweise groß und breit sein und, sagen wir mal, ein bisschen unhandlich.
Und insofern stellt sich dann auch wieder die übliche Frage, was ist denn jetzt der nächste Schritt?
Welche Verbesserung wollen wir jetzt als erstes mal ausprobieren?
Okay, also man geht nach gesundem Menschenverstand, überlegt, was ist das, was am erfolgversprechendsten wäre.
Und dann macht man echt einen Test, ein Experiment, so richtig so klassisch, fast wissenschaftlich.
Man misst dann, ist Zustand, verändert es.
Man misst dann den neuen Ist-Zustand, vergleicht, ist es besser geworden, ist es nicht besser geworden.
Und nicht nur das, sondern auch ganz wissenschaftlich, man formuliert eine Hypothese.
Man sagt, mal angenommen, mein Flurförderfritzel mit den Schrauben, der hätte einen Fahrplan,
dann könnte ich meine Pausen entsprechend planen oder sowas und wir hätten die Schrauben nicht mehr ausgehen.
Was weiß ich?
Genau, oder ich kriege die Information, dass nach den letzten 20 Schrauben kann ich demjenigen Bescheid sagen
und der kommt dann vor.
In irgendeiner Art Kommunikation, Kanban, Signalkarte.
Die letzten 20 Schrauben sind im Karton, da ist eine Pappkarte, die nimmst du raus,
geht die Bestellung an denjenigen, der die Schrauben bringt.
Okay, sehr schön.
Genau.
Und dann schlussendlich kommt noch, an welchem Ding, an welcher Metrik, an welcher Begebenheit,
was auch immer, kann ich ableiten oder kann ich Learnings ableiten?
Also das sind jetzt so die sechs Fragen.
Um es nochmal zusammenzufassen.
Was ist meine Zielbedingung?
Da muss man natürlich auch ein bisschen iterieren, haben wir gesagt, bis man die wirklich erfasst hat.
Was ist meine gegenwärtige Situation?
Dann ist die Frage, was ist das Hindernis?
Wie komme ich vom gegenwärtigen Zustand zum Zielzustand?
Dann kommt die Frage, was ist der nächste Schritt?
Was ist meine Erwartung, wenn ich diesen Schritt gemacht habe?
Was glaube ich, was dann passieren wird?
Was wird sich einstellen?
Und dann, woran kann ich beobachten, ob sich diese Erwartung auch tatsächlich bewirkt?
Das sind so die sechs Schritte, die im Rahmen eines Coaching Cutters der Coach seinem Schützling
explizit oder implizit irgendwie durcharbeiten wird.
Und wiederum beim Coaching Cutter ist es ganz wichtig, genauso wie auch beim Improvement Cutter,
nicht zu einer Lösung fürs Jetzt zu kommen.
Es geht überhaupt nicht darum, ob man diese Schicht 700 Autos hinkriegt,
sondern Ziel ist es, dass der Coachee sich weiterentwickelt, Fertigkeiten gewinnt, Sicherheit gewinnt,
im Umgang mit dem Improvement Cutter.
Um das, egal in welchem Zusammenhang, egal auf welcher Unternehmensebene,
zunehmend selbstständig anwenden zu können.
Quasi in den Gehirnmuskel, die Arbeitsweise, die Verbesserungsweise,
die im Coaching Cutter immer wieder geübt wird, dann zu verinnerlichen
und schnell und einfach dieses Denkmuster wiederholen zu können.
Genau, das ist ja auch der Witz, deswegen heißt der Toyota Cutter.
Es ist einfach eine fortwährende Übung.
Ich mache diese Abfolge von Handlungen mit dem Ziel, dass ich eigentlich ganz automatisch
und quasi im Vorbeigehen ständig Verbesserungen im Blick habe.
Insofern ist es wirklich ein spannendes Buch.
Und zwar nicht deswegen, weil es mir etwas Neues gesagt hat,
sondern genau deswegen, weil es laute Dinge wiederholt hat,
die mir aus anderem Kontext schon hinlänglich bekannt sind.
Weil das für mich eine wahnsinnig mächtige Bestätigung dessen ist,
dass wir da irgendwie auf einem richtigen Weg sind.
Und dass wir nicht nur irgendwie in unserer Agilität bleiben,
uns da irgendwie gegenseitig beipflichten und da irgendwelchen Quatsch machen,
sondern nein, das funktioniert.
Und das funktioniert auch nicht nur in irgendwie Software-Architekten-Träumen,
sondern das funktioniert auch ganz klassisch mit gebogenem Blech
und kommt in der Tat sogar von dort her.
Das ist das Wichtige für mich daran, dass das eben eine Bestätigung ist,
eine tiefe Gründung in einem soliden, festen Boden, wo man sagt,
ja, das haben Leute schon jahrzehntelang in verschiedenen Kontexten,
ausprobiert und es war sehr, sehr hilfreich.
Aber ich meine, das hier ist natürlich der DevOps auf die Ohren und ins Hirn Podcast.
Und insofern sollten wir vielleicht nochmal ganz bewusst
als Abschluss dieses Podcasts zusammenfassen.
Wie passt das denn zusammen?
Okay, das heißt, wenn ich jetzt sage,
kontinuierliche Verbesserung ist etwas, was man als DevOps-Prinzip
zum Beispiel von der DASA kennt.
Was sagt Toyota Kata?
Was ist der DevOps-Sicht darauf?
Die stimmen aus meiner Sicht dazu.
Total überein.
Die sagen, kontinuierliche Verbesserung ist das Zentrale.
Wenn du die Wahl hast, zwischen Outcomes zu verbessern und Prozess zu verbessern,
dann entscheide dich für die Prozessverbesserung.
Weil im einen Fall hast du bloß für den einen Tag was besser gemacht
und im anderen Fall hast du für alle Tage was besser gemacht.
Dann weiteres Prinzip aus dem DevOps-Umfeld,
kostfunktionale Teams, Kollaboration, Zusammenarbeit in der Arbeitsweise.
Was gibt es da zu sagen?
Ja, darauf sind wir gar nicht so eingegangen.
Aber das ist natürlich auch,
ein ganz wesentlicher Aspekt von einerseits einem Coaching-Kata
und andererseits auch einem Improvement-Kata.
Es kann ganz natürlich vorkommen,
dass da verschiedene Spezialisierungen ganz eng zusammenarbeiten müssen.
Von mir aus, wie gesagt, die Fertigungsplaner und die Lagerlogistiker
und die Vorarbeiter am Band oder sowas müssen halt gemeinsam irgendwie was auskasperlen,
dass der Prozess als Ganzes, dass die Wertschöpfung als Ganzes erfolgreich verlaufen kann.
Also auch da sehe ich eine völlige Übereinstimmung.
Okay, dann haben wir gesagt, okay, DevOps ist meistens so ein Team-Ding.
Das heißt, den DevOps-Helden können wir mal so ein bisschen außen vor lassen.
Jemand, der wirklich von Anfang bis Ende alles kann.
Du hast kostfunktionale Teams, die Ende-zu-Ende-Verantwortung übernehmen.
Gibt es da aus dem Toyota-Umfeld Unterschiede oder Differenzen zum Thema DevOps?
Auch nicht, sondern ganz im Gegenteil wird sehr darauf gedrungen,
dass man…
Teams, seien es nun irgendwie als Ad-Hoc, einfach Gruppen von Leuten mit gemeinsamen Interessen,
als auch irgendwie fixen Teams, die zum Beispiel für einen bestimmten Bandabschnitt verantwortlich zeichnen oder sowas,
dass die gemeinsam auch in der Lage sind, übrigens auch selbst Entscheidungen zu treffen.
Dass die einfach im Rahmen von so einem Improvement-Cutter sagen,
wir glauben, wir möchten das anders machen und hier sind unsere Kriterien,
um nachzuweisen, dass das tatsächlich funktioniert.
Und dann müssen die keinen…
Manager fragen und sagen, hier, bitte, bitte, dürfen wir, sondern…
Ja, ist der Ding. Sollen die machen?
Wird sich schon zeigen, ob es gelingt oder nicht.
Das ist natürlich schön.
Das heißt, experimentieren ist nicht nur gewünscht, sondern gefordert.
Richtig, genau.
Und alles, was dazugehört.
Auch Toyota-Cutter, genauso wie DevOps, sagt, wir brauchen Rückkopplungsschleifen, ganz ausdrücklich.
Wir brauchen Metriken.
Wir brauchen einen wissenschaftlichen Ansatz mit Hypothesen und allem, was dazugehört.
Das sind…
Das sind also auch wiederum so Gemeinsamkeiten.
Bei Toyota kommen diese Feedbacks dann vielleicht aus dem Prozess raus.
Wenn ich jetzt wieder an mein Band denke, wie viele Autos fallen jetzt runter
oder wie hoch ist meine Defektrate oder sowas.
In einem IT-Umfeld vielleicht genauso.
Da habe ich ja genauso auch eine Defektrate.
Wie viele Failed Deployments habe ich?
Oder wie viele Releases pro Zeiteinheit, pro Sprint, was weiß ich,
was kann ich denn machen, ohne dass ich dabei auf die Schnauze fliege?
Ja, kann ich nach jeder Story einen Release in Produktion bringen?
Oder muss ich bis zum Ende des Sprints oder, keine Ahnung, zu einem anderen längeren Release-Zyklus warten?
Ja, genau.
Ich wollte noch so zwei, drei Dinge abklopfen.
Das eine ist Fokus auf den Prozess.
Ja, also ich glaube, der ist vielleicht bei Toyota sogar noch stärker.
Ich glaube, die sind da noch rigoroser zu sagen, hier ist die Fertigungslinie, so ist unser Ansatz.
Da gibt es ja dann häufig auch Handlungsanweisungen für die Werker, wo dann gesagt wird,
du nimmst bitte…
Eine Schraube Größe 8, tust die in dieses Loch rein, ziehst sie mit 20 Newtonmeter fest und so weiter.
Das kann schon sein, dass es da viel akribischere Anweisungen gibt
und dass dem gegenüber vielleicht in der IT zum Teil das ein bisschen offener gemacht wird,
wo es dann einfach nur heißt, ja, jetzt komm, schreib halt irgendwie Code.
Ja, teils, teils.
Wenn man jetzt überlegt, du hast eine Continuous Delivery Pipeline,
die klar definiert sagt, du nimmst Artefakt, du führst es durch 25 verschiedene Tests.
Am Ende müssen alle Tests erfolgreich abgehen.
Wenn die Tests abgeschlossen sind, dann hast du das Artefakt,
dann kannst du das auf die Testumgebung bringen
und kannst letztendlich verschiedene weitere Teststufen durchlaufen und so weiter.
Das ist ja auch klar und deutlich quasi programmiert.
Aber nicht nur das, sondern auch so Dinge wie eine Definition of Done beispielsweise
oder ein Coding Guidelines oder solche Dinge, wo man schon auch natürlich sagt,
wir wollen da eine gewisse Festschreibung haben und zwar genau zu denselben Zielen,
dass der Prozess irgendwie planbar ist, steuerbar ist, diskutierbar ist.
Aber trotzdem…
Mein Gefühl ist, dass Toyota da noch ein bisschen rigoroser ist,
als ich es häufig wahrnehme, sagen wir mal so.
Na gut, aus meiner Sicht sind wir aber da gerade zwei Dinge,
die miteinander nicht wirklich, also eher Apfel mit Birnen vergleichen.
Der Toyota-Produktionsprozess ist halt der Prozess,
der am Ende die Fertigungslinie abbildet.
Und das ist aus meiner Sicht in der IT eher die Continuous Delivery Pipeline.
Und der Produktentwicklungsprozess wird ja an der Stelle nicht wirklich häufig betrachtet.
Und das ist in der IT…
Das ist in der IT natürlich das, wo Coding, Anforderungsanalyse, Story schreiben,
Code Reviews und anderes alles ablaufen.
Die beiden würde ich ungern mischen.
Aber generell stimme ich natürlich zu.
Genau, da hast du natürlich auch recht.
Also vor allen Dingen, was sie vielleicht gemein haben,
vielleicht sollte man darauf nochmal eingehen,
ist dieser Fokus auf Prozessverbesserung und nicht Verbesserung von Outcomes.
Es ist nicht wichtig, ob du dein Sprintziel schaffst.
Es ist wichtig, dass du dich in die Lage versetzt,
genau, verlässlich in Zukunft dein Sprintziel einzuhalten, zu erreichen.
Genau, dass du lernst, bessere Sprinteinschätzungen zu treffen.
Gute Definition of Readies helfen da und andere Dinge.
Velocity-Ermittlung des Teams, Kapazitätsplanung und ähnliche Aspekte
sind natürlich im Softwareumfeld hilfreich.
Genauso wie Visual Management.
Also Dinge visualisieren.
Wertstromanalyse, Sprint-Backlog in Form von einem Kanban-Board abzubilden
und anderes im IT- und DevOps-Umfeld.
Und so ähnlich geht ja da mit Kanban auch eine Theoretaproduktionslinie vor.
Ja, oder nicht nur Kanban im Sinne von einer Planung oder sowas,
sondern auch Dashboards, wo dann drin steht,
wie viele Autos haben wir denn diese Schicht schon gemacht oder sowas.
Oder wie hoch ist die CPU-Auslastung in meinem Rechenzentrum oder was auch immer.
An vielen Ecken Metriken erfasst.
Und sie möglichst leicht zugänglich, möglichst interpretierbar macht.
Okay.
Gibt es irgendwas, wenn wir jetzt über Toyota Kata sprechen,
was wirklich ein Problem darstellt?
Irgendwas, wo wir sagen, okay, da funktioniert es nicht?
Oder gibt es irgendwo Kritik, die wir an dem Thema Toyota Kata haben
oder generell, die es gibt?
Ja, also es gibt einige Leute, die so ein bisschen an dem Buch rumlörgeln,
wobei ich die nicht so richtig nachvollziehen kann.
Es gibt halt Leute, die sagen, oh, das ist aber so stark auf Toyota fokussiert.
Ach nee.
Also insgesamt, ich finde das Buch gut.
Vielleicht würden sich manche Leute wünschen,
es würde ein bisschen konkretere, ich weiß auch nicht, Kochrezepte anbieten,
wie man zum Beispiel jetzt so ein Improvement Kata macht oder sowas.
Aber ich finde, das Buch bietet da schon ganz schön viel.
Auch im Appendix sind da einige Vorschläge drin,
einige vielleicht Checklisten drin oder sowas, einige Ablaufpläne.
Aber ganz wesentlich ist halt auch, dass man dem Geist dieses Katas genügt
und die konkrete Vorgehensweise anpasst an die Gegebenheiten der eigenen Situation,
des eigenen Produkts, der eigenen Organisation.
Also insgesamt, ich fand das Buch echt toll.
Genau deshalb, weil ich nichts Neues gelernt habe.
Möchten wir noch irgendwas als Schlussbemerkung geben?
Ansonsten hätte ich gesagt, zwei, drei Shownotes und Links.
Michael Rother arbeitet immer noch an der University of Michigan, richtig?
Wenn du das sagst, dann wird das bestimmt stimmen.
Okay, zumindest hatte ich eine Webseite dazu gefunden,
die Toyota-Kata-Website an der University of Michigan-EdU.
Den Link würde ich mit reinhängen und zumindest einen deutschen Link letztendlich,
der so ein bisschen zu dem Thema beschreibt.
Die deutsche Seite von kanbantool.com sind Sachen, die mir auffallen.
Keine Ahnung, vielleicht noch ein Buchlink, ISBN oder irgendwie so ein Thema.
Fände ich ganz sinnvoll und hilfreich.
Genau.
Genau.
Also wir werden sicherlich das Buch selber verlinken.
Auf der Toyota-Kata-Webseite ist das eh drauf.
Das ist mir fast ein bisschen sympathischer, als bei Amazon oder so zu verlinken.
Aber es sei gesagt, es gibt es auch als Hörbuch.
Ich habe bei mir das als Hörbuch angehört.
Mir kam das entgegen.
Ja, ich bin auch ein Hörbuchfreund.
Würde ich mir mal ein paar Gedanken machen.
Bei mir auf der Liste der gerade gelesenen und abgehackten sind schon einige spannende neue Bücher.
Und auch so habe ich ein paar interessante Ideen für die nächsten Podcasts.
Insofern seid gespannt.
Seid aber auch offen für uns zu kontaktieren und als Hörer auch einen Beitrag zu leisten.
Ansonsten vielen Dank fürs Zuhören.
Ja, genau.
Vielen Dank fürs Zuhören, geschätzte Zuhörerinnen und Zuhörer.
Und vielen Dank für die guten Fragen, lieber Falco.
Ja, sehr gern.
Ich freue mich auf unsere nächste Folge.
Geht mir auch so.
Wunderbar.
Also.
Macht’s gut alle zusammen.
Vielen Dank fürs Zuhören und bis zum nächsten Mal.
Ciao.
Ciao.