Kaizen 2 go 354 : TWI im Scrum-Kontext

 

Inhalt der Episode:

  • Welche Verbindung gibt es zwischen Scrum und Training Within Industry (TWI)?
  • Was kann die Scrum-Community von TWI-Prinzipien lernen?
  • Warum wird TWI als mögliche Blaupause für Scrum Master vorgeschlagen?
  • Welche Ähnlichkeiten und Unterschiede bestehen zwischen Lean- und Scrum-Ausbildungen?
  • Ist die Ausbildungsdauer für Scrum Master ausreichend?
  • Warum gibt es im Scrum-Kontext oft keinen Konsens über methodische Standards?
  • Wie können die Prinzipien von TWI (Job Instructions, Job Relations, Job Methods) auf Scrum übertragen werden?
  • Wer trägt im Scrum-Kontext die Verantwortung für die Fähigkeiten und Befähigungen der Teammitglieder?
  • Welche Rolle spielen Organisation und Führungskräfte im Zusammenhang mit Scrum Teams und deren Effektivität?
  • Wie unterscheidet sich der Product Owner von einem Chief Engineer im Lean Product Development?
  • Wie könnte ein stärkeres Mandat für Product Owner aussehen?
  • Welche Herausforderungen entstehen durch duale Hierarchien im Scrum-Kontext?
  • Warum gibt es Vorbehalte gegen Standards und Checklisten sowohl im Scrum- als auch im Lean-Kontext?
  • Wie kann die effektive Nutzung von Standards zur Verbesserung der Arbeitsweise beitragen?
  • Welche Synergien könnten sich aus einer engeren Zusammenarbeit zwischen Lean- und Scrum-Experten ergeben?
  • Wie kann die Weisheit beider Methoden für Kunden effektiver genutzt werden?

Notizen zur Episode:

Mitmachen?

Wenn Sie selbst ein interessantes Thema für eine Episode im Umfeld von Geschäftsprozessen haben, können Sie mir das auf dieser Seite mit Vorbereitungsfragen vorschlagen.

Ich freue mich darauf!

Ihnen hat der Inhalt gefallen? Dann bewerten Sie die Episode bitte bei iTunes.
Jetzt eintragen und Artikel/Denkanstöße zukünftig per eMail erhalten.

Artikel teilen auf ...

(Teil)automatisiertes Transkript

Episode 354 : TWI im Scrum-Kontext

Herzlich willkommen zu dem Podcast für Lean Interessierte, die in ihren Organisationen die kontinuierliche Verbesserung der Geschäftsprozesse und Abläufe anstreben, um Nutzen zu steigern, Ressourcen-Verbrauch zu reduzieren und damit Freiräume für echte Wertschöpfung zu schaffen. Für mehr Erfolg durch Kunden- und Mitarbeiterzufriedenheit, höhere Produktivität durch mehr Effektivität und Effizienz. An den Maschinen, im Außendienst, in den Büros bis zur Chefetage.

Götz Müller: Heute habe ich Jan Fischbach bei mir im Podcast-Gespräch. Es ist nicht das erste Mal, dass er heute da ist. Er ist einer der Geschäftsführer und ich glaube, auch Gründer von Common Sense und schon lange, lange im agilen und Scrum-Kontext unterwegs. Hallo Jan.

Jan Fischbach: Hallo Götz, danke für die Einladung.

Götz Müller: Gerne, gerne. Sag vielleicht noch ein paar für die, die die letzte oder die letzten, ich weiß es ehrlich gesagt nicht mehr genau, Episode nicht gehört haben, sag vielleicht noch ein paar Stichworte kurz zu dir.

Jan Fischbach: Wie du schon sagtest, ich bin Geschäftsführer und Berater beim bei der Common Sense Team GmbH mit Sitz in Stuttgart. Wir helfen Firmen in der Verwaltung und Privatfirmen zum Beispiel beim Thema Ablage, und ich bin tätig für das Scrum-Events-Netzwerk, da bin ich Scrum-Trainer seit mehr als 10 Jahren und da helfen wir großen und kleinen Firmen aufs agile Pferd, damit sie mehr Spaß bei der Arbeit haben und zu vernünftigen Zeiten nach Hause gehen können. Und ich wohne oben an der Nordseeküste, wie man an meiner Aussprache wahrscheinlich hört. Böse Zungen behaupten, die Ostfriesen sind da angesiedelt worden, damit keine Menschen zu Schaden kommen, wenn es Sturmfluten ist, aber ich glaube, das dürfen wir nicht stehen lassen.

Götz Müller: Ja, und wo du gerade Stuttgart gesagt hast, aber ich glaube, das hört man schon raus, den Unterschied schon auch, den Kontrast. Ja, das Stichwort Kontrast ist wahrscheinlich ein ganz gutes Thema. Ich habe fast das Gefühl, das ist eine, das wird eine der Episoden sein, mindestens aus zwei Gründen, eine besondere Episode, zum einen, weil es die letzte Episode im zehnten Jahr sein wird. Das habe ich mir vorhin noch mal vors geistige Auge geholt und irgendwie war ich da selber überrascht und zum anderen, weil ich, anders wie in anderen Episoden jetzt hier nicht irgendwie eine Form von, ich nenne das – die, die bei mir schon mal in einer Podcast-Episode als Gesprächsteilnehmer waren, die kennen das, dass ich immer so Leitfragen verschicke, das ist diesmal nicht der Fall – weil wir im Grunde auch ein Stück weit einen besonderen Auslöser hatten für die Episode, vielleicht sagst du, weil du letzten Endes als Person auch da mit ein Auslöser warst, vielleicht sagst du da noch ein paar Sätze schon dazu.

Jan Fischbach: Ja, okay. Ja, wir hatten vor Kurzem unseren kleinen Online Scrum Day, damit versuchen wir die Zeit zwischen den Scrum Days zu überbrücken. Und diesmal hatten wir einen Vortrag von Hugh Alley, der ja sehr bekannt ist für seine Arbeit mit TWI, der hatte uns einen Vortrag gehalten und die Verbindung aufgemacht zum Thema Scrum: Was kann denn die Scrum-Community aus dem Thema TWI mitnehmen? Und wir, also du und ich und Alexander und noch ein paar andere, wir hatten uns hinterher überlegt, ja, was haben wir jetzt eigentlich daraus gelernt und bei diesem Austausch sind wir vielleicht auch ein paar Mythen gestoßen oder unverständige Sichtweisen, wo wir gesagt haben: Das lohnt sich doch mal eine Podcast-Folge dazu zu machen, um diesen Mythen etwas entgegenzusetzen. Zum Beispiel: Scrum ist mit der heißen Prozessnadel gestrickt, oder, da muss sich keiner drum kümmern oder solche Dinge. Und ich fände es cool, wenn wir mal durch diese Dinge irgendwie durchgehen können.

Götz Müller: Ja, ja, und im Grunde so wir wie wir beide ja uns in, grob gesagt, in zwei verschiedenen, zumindest was die Begrifflichkeit angeht, erstmal Communities bewegen, trotzdem aber, glaube ich, und das ist ein Stück weit wahrscheinlich sogar eine Sache, die uns vielleicht von vielen anderen unterscheidet, gucken wir doch ziemlich über den Tellerrand, so nehme ich es bei dir war und so, glaube ich, kann ich es für mich selber auch in Anspruch nehmen, dass wir also schon ein bisschen wissen, was denn passiert auf der anderen Seite des „Ozeans“, könnte man es fast nennen, du hast ja eben, und sonst wäre das in der Form ja nicht passiert, den Hugh Alley eingeladen, zum Thema TWI den kurzen Impulsvortrag zu halten. Für mich ist jetzt TWI eine der Wurzeln, was Lean Management angeht, auch wenn das vielleicht die wenigsten jetzt sogar im Lean-Kontext selber so wissen, und ich kann da von mir sagen vor, sagen wir vor mindestens 12 Jahren wusste ich selber nicht, da kannte ich den Begriff gar nicht und ich vermute mal fast, aus vielen größeren oder kleineren Reaktionen, die mir so begegnen, geht es vielen anderen so. Ich könnte mir vorstellen, dass das jetzt möglicherweise im Scrum-Kontext vielleicht sogar noch ein bisschen extremer ist.

Jan Fischbach: Ja. Nee, da gebe ich dir recht. Also wenn du dir anguckst, wie jemand in Scrum ausgebildet wird, dann ist das ja eine sehr schnelle Ausbildung. Das heißt, jemand geht ein oder zwei Tage auf ein Scrum-Master-Seminar, wo man den Leuten die Basics aus dem Scrum Guide beibringt und ein paar komplementäre Praktiken. So, und dann müssen die auch loslaufen. Das ist natürlich einerseits der Vorteil von Scrum, weil sie relativ schnell loslegen können und Leute nicht erst monatelang oder jahrelang in irgendein Studium geschickt werden. Der Jeff sagte immer: Ja, ihr habt jetzt sozusagen den Führerschein bestanden, aber fahren müsst ihr selber. Und Fahrpraxis kriegt man nicht nur durch den Führerschein, sondern die muss man halt selber auch aufbauen. Und Jeff hat immer gesagt, ihr müsst auch Erfahrung sammeln. Deswegen gibt es eigentlich wenig da drauf. Es gibt natürlich Scrum Master 2 und Scrum Master 3 als Prüfung. Aber ich denke, ihr in der Lean-Welt, wenn ich so die die Green Belts und Black Belts und solche Dinge sehe, ich habe den Eindruck, ihr nehmt euch viel mehr Zeit für diese Themen, die wir oft in der Scrum-Welt uns gar nicht nehmen und die Scrum Master sind vielleicht ein bisschen auch allein, die suchen sich ihre eigenen Themen und dann sagt der eine: Ja, ich finde Lego Serious Play cool und der andere sagt, ich finde Design Thinking cool und du und ich, wir sind eher so auf der Lieferfähigkeitsebene eines Teams und sagen dann: Ja, wir müssen jetzt vielleicht andere Themen machen. Aber es gibt da keinen Konsens. Und mir ging das auch so wie dir, TWI habe ich auch per Zufall gefunden und jetzt promote ich das natürlich auch wieder bei jeder Gelegenheit und sage: Da ist eine schöne Blaupause für einen Scrum Master, also man kann immer so Haken dransetzen, ich habe mich um diese und jene Themen gekümmert, aber es ist nicht Teil eines irgendwie offiziellen Curriculums. Und ich weiß nicht, vielleicht magst du erstmal erzählen, wie ist denn eine typische Lean-Ausbildung aus deiner Sicht?

Götz Müller: Ja, da gibt es jetzt diese, mehr oder weniger, formalisierten Ausbildungen, du hast die Belts genannt, wobei die in meiner Wahrnehmung sehr stark eher aus der Six-Sigma-Ebene kommen und dann halt so ein bisschen rübergeschwappt sind. Vermutlich, und das ist so ein Punkt, wo ich auch noch mal bei dir nachhaken will, vermutlich, weil es auf Seiten der Unternehmen eine gewisse Erwartungshaltung gibt und wenn ich da halt in meine eigene Lean-, Six-Sigma-Ausbildung, Black Belt denke, dann war das damals, bei Ericsson, war es Six Sigma, mit dem Lean in Klammern davor, würde ich fast schon sagen, war dort der eingeführte Verbesserungsprozess und ich war damals Teil der 25. Welle. So im Schnitt gab es eine Welle im Jahr, weil die Ausbildung selber, nicht am Stück, aber fünf Monate ging, immer eine Woche und dann wieder vier Wochen am Arbeitsplatz, wo man dann eben auch das Projekt parallel dazu durchgeführt hat. Also es ist, glaube ich, sehr stark formalisiert und noch stärker im Grunde, wenn wir jetzt in das Thema TWI reinschauen, wenn wir uns dort die Job-Trainings angucken, mit den mit den 5×2 Stunden. Und das nehme ich so als den krassen Unterschied zu dem, du hast es gerade angedeutet, mit zwei Tage Scrum-Maste-Einstiegstraining. Gut, kann man sagen 5×2 Stunden sind auch bloß anderthalb Tage, aber da, wo ich eine gewisse Gemeinsamkeit sehe, ist, dass die Leute mehr oder weniger sofort dann auf losgelassen werden, weil es typischerweise ja schon Führungskräfte sind, diese unterste Ebene, die man im amerikanischen Sprachraum die Supervisor nennt, also die so eine Handvoll, zwei Hände voll, Mitarbeiter haben, typischerweise von der Herkunft her in einer Produktionslinie, aber auch da gewisse Widerstände bestehen, und so hast du es ja auch angedeutet: Braucht man das wirklich? Und das möchte ich mal vielleicht auch noch ein bisschen hinterfragen, weil ich glaube, da können wir wieder gegenseitig voneinander lernen, wie war so die Resonanz auf das Thema, auf den Vortrag letzten Endes, auf das Thema TWI im Scrum Kontext?

Jan Fischbach: Also wir haben so im Orga-Team darüber unterhalten und haben festgestellt, ja, eigentlich besetzen wir dieses Thema gar nicht, zum Beispiel Ausbildung, der Hugh hat ja dann gesagt: Gute Führungskräfte sorgen dafür, dass wir gute Leute haben und gute Leute werden gute Prozesse aufbauen und wenn die Prozesse stimmen, kriegen wir auch gute Ergebnisse. Und diese Kette, oder womit fängt denn die Kette bei Scrum an? Wer steht denn da als Leader in der Pflicht? Und da haben wir halt dann diskutiert und sagen: Ja, das wissen wir eigentlich gar nicht so genau. Wir haben noch keinen Konsens. Für mich ist die Antwort da immer klar und ich würde sagen, ja, der Scrum Master ist hier der Anführer in der Hinsicht und das lässt sich auch historisch belegen. Wir haben nur nie über Ausbildung der Leute oder Verbesserung der Prozesse so direkt geredet im Scrum Kontext. Der Jeff hat immer eine Geschichte erzählt, wo er am MIT gearbeitet hat. Er hat sich da im Büro gemietet mit seinem Team und er ist dann von so einem Roboter gejagt worden. Da war auch das Robotics-Labor irgendwie an dieser Uni. Und dann ist er irgendwie über so einen Roboter gestolpert, der da wie so ein Insekt durch das Büro krabbelte und dann hat er das Ding genommen, ist zum Professor Brooks gegangen und sagte: Ist das eigentlich dein Ding? – Oh ja, Entschuldigung. Wir experimentieren gerade mit dieser Robotik. Und er sagte: Ja, was macht ihr denn? – Ja, wir haben jahrelang gedacht, wir bringen den Robotern Algorithmen bei, wo wir ihnen die Karte abbilden, und dann finden sie ihren Weg durch den Raum, und das hat aber nie funktioniert, das ist zu komplex. Und dann haben wir ein ganz einfaches Programm gemacht und haben gesagt: Okay, immer wenn du vor ein Hindernis stößt, geh links oder rechts vorbei und versuch einen neuen Weg zu finden und merk dir den Weg im Kopf. Und damit, mit diesem relativ einfachen Selbstlern-Algorithmus, konnten sie die Roboter besser steuern. Der Jeff sagte dann: Hm, das ist ja eigentlich cool. Wenn ich ein Team aufbauen könnte, das auch diesen Selbstlernmechanismus hat, ich versuche ihnen nicht alle möglichen Regeln beizubringen, sondern sie mit relativ einfachen Regeln auszustatten, damit sie dann loslegen können. So, und der Brooks sagte dann: Ja, probier es mal aus, aber noch ein Tipp – dann hat er den Roboter in der Hand ausgeschaltet und sagte – wenn ich ihn ausschalte, hat er leider wieder alles vergessen, so ja, da musst du dann aufpassen und so ist eben manchmal auch, wenn ich dann mein Team wieder neu zusammenstelle. Dann ist das ganze Wissen wieder weg und wir fangen wieder bei null an, ja, dass wir uns Sachen gegenseitig beibringen müssen und dass wir unsere Lieferkette irgendwie prüfen müssen, unsere Tool Chain und solche Dinge. Wir haben irgendwann mit dem Jeff darüber geredet und haben gesagt wir müssen das Toyota-Kata-Zeug mit aufnehmen. Er hatte auch schon A3-Thinking in seinen Kursunterlagen drin und wir haben dann auch über Toyota Kata gesprochen als ein Beispiel für diesen Selbstlern-Organismus, aber das muss man halt üben. Wir haben das teilweise in Jeffs Trainings geübt, weil vor der Pandemie war er ja immer fünf, sechsmal auch in Deutschland, wo wir zusammen die Trainings gemacht haben und es war dann ein praktisches Hilfsmittel dafür, aber das ist halt nicht so richtig üblich bei Scrum-Mastern.

Götz Müller: Ja, das Stichwort Übung finde ich sehr spannend. Im Englischen wird ja da der Begriff Practice verwendet und da gibt es und das wird, wenn ich es richtig im Kopf habe, auch mindestens an einer Stelle als Prinzip im TWI dargestellt, hervorgehoben, dass diese Übung wichtig ist und dass man es nicht zu früh beenden darf, dort allerdings sehr stark auf die Durchführung einer Arbeitsunterweisung an sich, dass man also zusammen mit der Aussage: Wenn der Schüler nicht gelernt hat, also der die Person, die eben die Unterweisung bekommt, es ist erst rum, wenn man sich jetzt selber als Unterweisender selber weiß, okay, er hat es verstanden oder sie hat es verstanden und kann es jetzt wirklich alleine, so im Vergleich mit Auto fahren, nicht bloß, weil er in der halben Stunde keinen Unfall gebaut hat, kriegt er die Pappe – für die etwas Älteren unter uns, früher war halt der Führerschein aus so einem Stück Papier –, während ich da halt so das Gefühl hab, im Scrum-Kontext ist das nicht so verankert und vielleicht ist es auch ein Teil des Problems. Ich bin mir da aber nicht sicher.

Jan Fischbach: Denke schon. Also wir kommen natürlich ein bisschen aus unterschiedlichen Kontexten. Lean ist ja vor allen Dingen bekannt dafür, vielleicht eher auf dem Shopfloor oder in der Produktion eingesetzt zu werden, obwohl natürlich alle Lean-Praktiker sagen, das ist nicht begrenzt auf Produktion, sondern es ist universell einsetzbar, Techniken ändern sich vielleicht. Und die Scrum-Welt ist ganz stark im IT-Kontext groß geworden. Also der Jeff hatte sich damals angeguckt, was kann uns denn helfen, unsere Softwareprojekte besser zu machen und da haben die sich natürlich ganz viel an Lean orientiert und wenn man den Jeff fragt, er erzählt viel Geschichten von Toyota in seinem Buch Scrum: The Art of Doing Twice the Work in Half the Time, zitiert natürlich auch Taiichi Ōno und Toyota. Das heißt, er greift schon auf diesen Kontext zurück, hat vielleicht mehr einen Produktfokus, weil sie damals ein neues Softwareprodukt entwickelt haben. Sie sind auf das New New Product Development Game gestoßen, wo zwei Japaner beschreiben, wie gute Produktentwicklungsfirmen sich organisieren, und hat das erstmal zum Kontext genommen. Er hat natürlich auch auf den Chief Engineer beim Lean Product Development zurückgegriffen. Das nennen wir bei Scrum Product Owner, aber die Technik, wie Software entwickelt wird, ist nicht, wie man schrauben in irgendwelchen U-Stahl bohrt, oder Löcher, die Arbeitsgänge sind länger, die sind bisschen komplexer, so, da hat sich nie einer Gedanken gemacht: Wie kann ich denn dem Götz beibringen, wie er eine Datenbank abfragt? Da hat sich nie jemand einen Plan gemacht und hingelegt. So, das war eine ganz andere, wäre im Produktionsumfeld undenkbar gewesen, ja, also du würdest keinen an eine Bohrmaschine lassen, ohne den vorher eingewiesen zu haben und die Computer sind halt nicht so gefährlich, dass du dich enthaupten kannst oder skalpieren kannst.

Götz Müller: Ja. Ja, ich meine, ein großer Unterschied, der jetzt gerade auch noch mal, indirekt, von dir eben ein Stück weit zur Sprache kam, es gibt ja diese zwei, Triumvirat wären ja drei, aus dem römischen Kontext, aber diese zwei Personen, also den Product Owner, der in meiner Wahrnehmung sehr stark für den inhaltlichen Teil, also das, was soll das, was dort an Produkt entsteht, was soll das mal später können, der also Leistungsmerkmale festlegt und so weiter, der sich aber, glaube ich, nicht so tief einmischt in das, wie es denn gemacht wird, das Äußerste, was er, glaube ich, festlegt, ist eben die Reihenfolge, dass er halt sagt: Okay, für die nächsten sechs Wochen wird bis zu diesem iterativen Release möchte ich das und das Feature drin haben. Während der Scrum Master dann eher so aus dem Projektmanagement-Hintergrund rauskommt, also für die Abwicklung des Projektes zuständig ist, mit allen Elementen, und da hast ja du noch das Stichwort Chief Engineer genannt, das jetzt aus dem, ich nenne es jetzt mal Toyota-Kontext rauskommt, das ist für mich aber ein Stück, die Vereinigung beider Elemente, aber um was er sich eben im Grunde gar nicht kümmert, weil es mehr oder weniger als irgendwie vorhanden vorausgesetzt wird – da kommen wir aber, glaube ich, noch mal zumindest möchte ich da noch mal abbiegen in diese Gasse – dass die Menschen die notwendigen Fähigkeiten haben. Er muss es sicher sich ein Stück weit überlegen, Was brauche ich denn?, weil er selber keinen organisatorischen Durchgriff hat, wen er da in seinem Team hat, aber er hat halt eine starke Funktion, die im Grunde diese beiden Elemente des Projekt voranzutreiben als auch zu definieren, was steckt denn drin, das vereinigt er für sich.

Jan Fischbach: … dass das auch für den Product Owner gilt. Also die beste Beschreibung für den Product Owner habe ich aus dem Buch Automobilentwicklung mit System, wo halt der Projektmanager beschrieben wird und da würde ich sagen, das ist ziemlich genau die Beschreibung des Product Owners. Das passt ja schon so, die sind fast kongruent diese Rollen. Also Flugzeugproduktion ist halt etwas anderes als ein SAP-System zu bauen, ein ERP-System zu bauen. Bei der Software habe ich vielleicht ein bisschen mehr Freiheiten, weil ich nicht erst den Rumpf festlegen muss, um die Flügelgröße. Da habe ich vielleicht ein bisschen mehr Flexibilität, aber ich muss natürlich auch eine Architektur, ein paar Architekturentscheidungen treffen. So, das ist schon eine Aufgabe der Product Owner, das auch zu machen oder zu organisieren, dass das passiert. So, was auf Team-Ebene passiert, wer Product Owner darf sich auch die Handwerker, da kann natürlich der Handwerker sagen: Alleine komm ich nicht, ich bring noch meinen Kumpel mit. Oder so, ja, das ist schon okay und ein guter Product Owner würde natürlich auch auf disziplinarischen Durchgriff verzichten, weil er weiß, das bringt eh nichts. So, also die reden schon auf Augenhöhe, so wie ja, auch der Chief Engineer mit seinen Mitingenieuren und Ingenieurinnen auch auf Augenhöhe eigentlich redet. Die wissen natürlich, dass ist ein erfahrener Mensch, ich vertraue dem, weil der sich Gedanken um sein Produkt gemacht hat, aber er oder sie wird das Produkt nicht rausbringen ohne unsere Mithilfe, so, und umgekehrt weiß der Chief Ingenieur, die Chief-Ingenieurin weiß natürlich oder Konstrukteurin weiß natürlich: Okay, der Götz ist jetzt mein Experte für die Tragflächen und ich erzähle ihm jetzt mein Problem und er liefert mir eine Lösung, mit der ich mein Problem lösen kann. Heißt, die wissen schon genau, was die anderen da haben und so wünsche ich mir natürlich auch eine Kommunikation zwischen Product Owner und den Developern im Team auch.

Götz Müller: Du hattest eingangs noch erwähnt, dieses Paper, dieses New New Product Development Game, wo ja auch dieser, ich weiß gar nicht, ob sie in dem Begriff wirklich verwenden, Scrum, aber zumindest mal haben sie da die …

Jan Fischbach: Ja, da kommt der Begriff her. Das ist die erste Überschrift Moving the scrum downfield.

Götz Müller: Ah, okay, gut, vielleicht habe ich es dann deshalb überlesen, also dieses Downfield, an das kann ich mich definitiv entsinnen. Was mir dort aber fehlt und vielleicht ist das ein Stück weit, weil das gibt es im Lean-Kontext ja genauso, also da möchte jetzt nicht sagen, dass Lean irgendwie den Vorsprung hat, dass eben ein bisschen in dem Papier, soweit wie ich es, ich habe es jetzt vor kurzem noch mal gelesen halt diese organisatorische Einbettung beschrieben wird. Es wird zum Beispiel, es wird zwar abstrakt ein bisschen erwähnt, aber dass die Führungskräfte in der Organisation, also Linien-Führungskräfte, dass die halt ganz stark die Verantwortung haben für die Befähigung ihrer, in Anführungszeichen, Mitarbeiter, kommt, finde ich ein bisschen zu kurz. Wenn man jetzt ganz tief reingräbt in andere Beschreibungen des Toyota. Entwicklungssystems, nenne ich es jetzt mal, also nicht das Produktionssystem, sondern der Produktentwicklung, dort wird schon deutlich beschrieben, die Pflicht der Linienführungskräfte für die entsprechenden notwendigen Fähigkeiten ihrer Mitarbeiter zu sorgen, damit wiederum der Chief Engineer darauf zugreifen kann. Und da habe ich so ein bisschen das Gefühl, dass das, ja, wie soll man sonst ausdrücken, vielleicht ein Ball ist beim Jonglieren, bei dem man irgendwann mal festgestellt hat: Ja, da ist noch ein Ball in der Luft, wer nimmt denn den und dann aber jeder, also klassisch halt der Product Owner und umgekehrt das Scrum Master genauso halt einen Schritt zurückgetreten ist und dann ist der Ball irgendwie runtergefallen.

Jan Fischbach: Ja, ich glaube, der heruntergefallene Ball gibt es eigentlich ganz gut wieder. Also Nonaka und Takeuchi haben ja erst im New New Product Development Game, aber die haben ja noch mehr Bücher dann auch geschrieben und Paper und die Langfassung von diesem Artikel ist The Knowledge Creating Company und da beschreiben sie diese Produktentwicklung natürlich etwas ausführlicher und was eigentlich erkennbar ist, ist, dass sie immer kleine Teams zusammengestellt haben, die eigentlich in einer miesen Ausgangssituation waren. Irgendwie hat er das beschrieben, irgendwo absetzen und Leiter wegziehen, so ungefähr, ja, und da waren natürlich alle daran interessiert, so viel wie möglich zu lernen. Im New New Product Development haben sie dann auch immer wieder geschrieben: Lernen auf allen Ebenen multilearning und so, und da ist das, da war das vielleicht allen Beteiligten klar, dass sie nur erfolgreich sind, wenn sie möglichst viele Dinge lernen und sich gegenseitig beibringen. Das war, das war dann der Ball, der sich von alleine bewegt hat oder immer wieder. Jeder hat ihn immer wieder angeschubst in den Teams, dass man das aber auch aktiv steuern kann von Scrum-Master-Seite oder dass der Scrum Master eben das auch als Verantwortungsbereich hat, das ist nie explizit so aufgeschrieben worden, oder so definiert worden. Also, als ich das TWI-Zeug kennengelernt habe, war mir sofort klar, dass ist die Beschreibung des Scrum Masters und wenn mich ein Scrum Master mich heute fragt: Was muss ich tun? Dann würde ich sagen: Ja, guck erstmal wie der Lieferprozess ist. Guck dir mal an, sind alle Leute ausgebildet, guck mal auf das Arbeitsklima, so, und wie löst ihr denn eure Probleme kontinuierlich? Da habe ich immer Job Instruction, Job Relation, Job Methods drin. Das ist ganz einfach. Der wird natürlich ein bisschen anders vorgehen, also ein Supervisor, der könnte direktiv arbeiten, der könnte sich seine Liste machen und sagen: So, am Montag muss Jan die Bohrmaschine lernen und am Dienstag muss Götz mit der Stanze umgehen. Die anderen müssen ihm das beibringen und dann würde er halt abhaken, ob das auch gelaufen ist. Das würde ein Scrum Master wahrscheinlich so nicht machen so direktiv, aber er würde sagen, er würde es moderieren im Team und sagen: Hey Leute, welche Kompetenzen brauchen wir denn, um erfolgreich zu sein und dann würden wir uns eine Kompetenzmatrix machen, eine Scale-Matrix und dann würden wir uns einteilen irgendwie. Anders als bei Toyota hat sich eher so eine Skala von 1 bis 9 durchgesetzt bei vielen agilen Teams. 1 heißt, ich kann es im Internet recherchieren und 9 heißt, wenn Google hier etwas ändert rufen die mich vorher an und dann sehe ich halt: rot, gelb, grün, wo sind die Lücken? Und dann würde der Scrum Master sagen: Ja, liebes Team, was sind eure Strategien, um diese Lücken zu schließen? Und er würde wahrscheinlich auf beim Sprint Plannig darauf bestehen, dass ich immer wieder Leute finden, die irgendwas machen, um das einzubauen. So, also er würde mehr machen lassen, aber er würde sagen: Ich kann euch nicht von der Angel lassen, weil wenn Götz jetzt ausfällt und wir deshalb unser Sprint-Ziel nicht schaffen, haben wir alle ein Problem und es gibt nicht meine Story, deine Story, es gibt nur unsere Ergebnisse und wir können, wir werden, das wäre ziemlich dumm, unsere Lieferung von Einzelpersonen abhängig zu machen, lasst uns das nicht, wir sollten das nicht erleben.

Götz Müller: Aber ich, also jetzt auch bei deinen letzten Sätzen glaube ich, dass das eine der großen Unterschiede ist, weil der Supervisor, klar kann er in seiner Matrix sehen: Ja, der, ich sage jetzt mal, der Jan kann das auch jemand anderem unterweisen, das ist halt das voll ausgefüllte Feld und dann sage ich ihm „Bitte unterweis den“, aber das ist ja zumindest am Start die Ausnahme. Das heißt, das Thema Unterweisung ist sehr stark auf ihn fokussiert. Er kann es im Grunde nicht wegdelegieren, wo halt ich so ein bisschen die Gefahr sehe auch, dass das im Scrum-Kontext sehr leicht passiert, weil er ja nicht diese fachliche Kompetenz hat. Der typische Supervisor kann das alles, was er in seiner Matrix findet, und ich glaube, das kann man, das müsste ja ein Übermensch sein, das kann man bei einem Scrum Master nicht voraussetzen.

Jan Fischbach: Nee, und es wird auch nicht zum Thema gemacht in den Ausbildungen. Wir haben uns ja die, du hast es dir ja auch angeguckt, was lernt denn so ein Scrum Master am Anfang? Der lernt halt nur Scam und die Erfinder von Scrum, die haben immer gesagt: Ja, wir brauchen jetzt ja nichts reinzuschreiben, was an anderer Stelle schon ausreichend beschrieben ist. So, wir reduzieren. Der Scrum Guide hatte über 40 Seiten und da waren natürlich verschiedene Praktiken auch aus der Softwaretechnik drin und da haben sie gesagt: Nee, der Kern von Scrum ist, dass es ein selbstorganisiertes Team gibt, dass einen Selbstvermesserungsmechanismus aufbaut und sich sozusagen am eigenen Schopf aus dem Sumpf zieht. So, und die Scrum Master müssen immer wieder gucken, was kann ich tun, um die Produktivität des Teams zu verbessern. Das ist deren Hauptauftrag. Der Jeff hat uns immer gesagt, der Scrum Master muss jeden Tag ein wissenschaftliches Experiment starten, um herauszufinden, wie er die Produktivität des Teams erhöht, nicht nur die Retrospektive am Ende.

Götz Müller: Und jetzt, wo ich dich gerade noch mal gehört habe, ist mir wieder eingefallen, im TWI definiert man ja, oder wird ganz am Anfang schon dargestellt, diese Five Needs of a Supervisor.

Jan Fischbach: Ja, die die finde ich super, die Five Needs.

Götz Müller: Und das wird mir jetzt gerade erst in der Unterhaltung klar, dass das im Grunde auch, zumindest in meiner Wahrnehmung, ein Element ist, das fehlt, weil die die klassischen 3 Needs, die TWI abdeckt, ist halt die Fähigkeit zu unterweisen, die Fähigkeit ein gutes Arbeitsklima zu schaffen und die Fähigkeit, Prozesse zu optimieren. Da könnte man sagen, hat der Scrum Master auch, über das Unterweisen, wie gesagt, haben wir ja gerade schon gesprochen, aber die zwei anderen Elemente, und es wird im Grunde schon deutlich gesagt, zwar dann im Anschluss nie wieder diskutiert, weil es kein Thema ist, aber es wird deutlich gesagt, nämlich die Arbeitsinhalte und alles, was mit der Organisation zu tun hat, mit Führungsstruktur, mit allem, was man sich sonst so vorstellen kann. Und da ist die klare Aussage im TWI und noch konkreter eben in den Job Instructions, das ist die Aufgabe der Organisation dafür zu sorgen, dass also zum Beispiel ein Supervisor erst gar nicht in die Position kommt, wenn er fachlich von dem Thema keine Ahnung hat und auch die sogenannten Policies, was die Organisation ausmacht, weil es ja so hochgradig individuell auch ist. Beim Unternehmen A und beim Unternehmen B, selbst wenn sie in der gleichen Branche sind, kann das unter Umständen ganz anders sein. Der fachliche Anteil, wenn es unterschiedliche Branchen sind, ist sowieso unterschiedlich. Da hätte ja TWI und das Thema Arbeitsunterweisung viel zu viel sich ans Bein gebunden, wenn man das alles abdecken wöllte. Und das, glaube ich, ist halt ein Element, was, ja, ein Stück weit fehlt im Scrum-Kontext.

Jan Fischbach: Was an anderer Stelle schon gut beschrieben ist, das werden wir hier nicht wiederholen. Was zum Beispiel häufig kombiniert wird, ist Scrum und Extreme Programming. Also weil ich will natürlich kompetente Entwickler und Entwicklerinnen haben und denen ist natürlich ganz klar, ich darf keine Schrott-Software bauen. Was nützt mir das Scrum, wenn ich hinterher Crappy Software abgebe? Das sollte man nicht tun. So, und die hohe Expertise, wir streben das in Software-Teams auch an, dass die Entwickler sich zu sehr guten Entwicklern entwickeln, damit wir gute Produkte abgeben, weil Qualität ist, wenn der Kunde wieder kommt und nicht die Software. So. Das heißt, den erfahrenen Praktikern, denen ist das klar, die haben auch ein intuitives Verständnis vom Zusammenspiel zwischen einem Scrum-Team und dem Rest der Organisation. Den Durchgriff von der Organisation sehen wir eigentlich an einem Punkt im Scrum Guide. Da steht nämlich, die Definition of Done muss von der Organisation vorgegeben, und wenn sie das nicht vorgibt, entwickeln halt die Scrum Teams eine Definition of Done. Das heißt, das ist der einzige Punkt, wo wir merken, dass die Organisation was mit dem Scrum Team zu tun hat, ansonsten ist, ja, gibt es wahrscheinlich ein Arbeitsverhältnis zwischen Organisation und Product Owner und es gibt vielleicht irgendwie ein Austausch zwischen Organisation und Scrum Mastern.

Götz Müller: Das ist aber dann vielleicht aber eben ein Punkt, wo wir eben die Organisation nicht vom Haken lassen dürfen im Sinne von auch Auftraggeber, wenn wir uns jetzt beide mit der Rolle sehen, dass wir diejenigen sind, du bildest Scrum Master aus, ich befähige Menschen, sich im Lean-Kontext zu bewegen, also im Grunde machen wir uns ja beide überflüssig und da definiert halt TWI ganz klar, der Organisation, Klammer auf: Für die inhaltliche Ebene bist du zuständig. Also ich erkläre keinem, es fällt mir jetzt halt ein, ich habe das auch mal bei einem Stuckateur gemacht, Job Instruction Training, ich erkläre in dem Job Instruction Training nicht, wie man eine Wand verputzt. Ich könnte das zwar, aber das ist nicht mein Thema, sondern ich befähige die Vorarbeiter, ihre Auszubildenden und die, die es vielleicht noch nicht können oder noch nicht so gut sind, zu unterweisen, wie man Putz aufzieht. Und das ist da, aber zweifelsfrei auch jedem klar, dass es a) diesen Ball gibt, wenn wir wieder die Metapher aufgreifen und b) das den um dehnt sich jemand kümmern muss, sonst fällt er runter und dann ist das eher wie ein Wasserball, dann platzt er und dann wird es nie wieder ein schöner Ball. Und da habe ich so das Gefühl, dass das ein Element ist, was ein bisschen zu kurz gekommen ist.

Jan Fischbach: In dem Trainerhandbuch von TWI finde ich es ja ganz gut, da wird am Anfang ja gleich den Trainern gesagt: Hey, ihr steht nicht über denen, die ihr jetzt ausbildet, ihr seid, ihr habt vielleicht ein bisschen Vorsprung und das wird ja sogar gesagt, also das TWI-Handbuch für die, die es nicht kennen, ist ja eher so wieso ein, ich sage mal wie so ein Theaterstück, Text für ein Theaterstück. Das heißt, es wird genau geschrieben, was der Trainer sagen soll und es gibt auch einen guten Grund dafür und da soll man eben mal anfangen und auch gleich sagen: Hier ich bin, ich stehe nicht über euch, ich habe vor wenigen Monaten erst angefangen, das zu machen und wir sind hier gemeinsam in der Sache und ich erklär euch ein paar Dinge, aber wie du schon sagst, aus dem fachlichen halte ich mich raus, das müsst ihr mit jemand anderem klären. So, und das muss irgendwie die Organisation, die muss das klären und da hapern eben vieles, Scrum Teams auch, ja, weil sie so ein bisschen den Anschluss manchmal an den Rest der Organisation verloren haben. Und was ich besonders kritisch finde, ist, dass wir so duale Hierarchien haben oft im Scrum-Kontext- Das heißt, ich habe jetzt, wie auch immer, ein Scrum Team zusammengestellt. Das hat einen Scrum Master hoffentlich. Es hat einen Product Owner und dann hat es aber noch einen Teamleiter und Bereichsleiter und eine Geschäftsführung. So, und dann gibt es dann im Zweifelsfall vier Leute, die auf eine arme Entwicklerin einreden und die fragt mich dann: Ja, wem muss ich denn jetzt eigentlich zuhören? Und da wünsche ich mir doch, dass diese Hierarchien wieder harmonisiert werden und wir sagen: Also, entweder ist das Scrum Master auch der Teamleiter oder wenn der Teamleiter, wenn es einen Teamleiter hat, verhält er sich wie ein Scrum Master und die Product Owner haben auch ganz klare Aufgaben. So. Wir hatten einen Kurs, da sollten die Teams, die Kursteilnehmer uns ein Bild malen für diese drei Scrum-Verantwortungsbereiche und die haben dann ein Schiff gemalt, eine Gruppe, und das fand ich total cool. Der Product Owner war der Steuermann, der das Schiff gesteuert hat. Die Mannschaft waren die Ruderer oder die Segler, die das Schiff nach vorwärtsgebracht hatten, nach vorne gebracht haben und das Scrum Master war der Smutje in der Kombüse, der für gute Laune und Essen gesorgt hat. Und das war ein sehr schönes Bild und dann habe ich die gefragt. Ja, das ist super, das Bild gefällt mir. Was ist denn die Rolle der übrigen Führungskräfte im Unternehmen? Und dann haben sie gesagt: Ja, das ist doch ganz einfach. Also die kaufen die Schiffe, die legen die Routen fest, die verhandeln mit den Behörden an Land, ob das Schiff da landen kann. So, und das finde ich so cool als wirklich intuitives Verständnis vom Zusammenspiel zwischen den Scrum Teams und dem Rest der Organisation. Und das wünsche ich mir doch, wie du sagst, es fehlt, aus meiner Sicht fehlt das immer. Ich fasse das immer mit Mandat zusammen. Welches Mandat hat der Product Owner, welches Mandat hat der Scrum Master?

Götz Müller: Da muss man, meiner Ansicht nach, aber durchaus ein bisschen, wie soll man es ausdrücken, ein bisschen, ja, es fällt mir nichts Besseres ein, entschuldigend sagen, weil im Grunde das ein klassisches Dilemma von Matrix-Organisation ist. Also wenn ich da an meine eigene Produktentwicklungshistorie im letzten Jahrtausend zurückdenke, da hat man noch nicht über Scrum & Co gesponsert, sondern war das halt klassisch nach V-Modell. Da gab es dieses Thema auch schon, Matrixorganisation mit allen Konsequenzen, dass sich einerseits die Linie in die inhaltlichen Themen eingemischt hat, so nach dem Motto: Du musst es genauso machen, wir wissen sowieso viel, viel besser, wie das Produkt hinterher funktionieren soll. Wobei es ja darum nicht geht, also genau diese Aussage, wie du es gesagt hast: Welchem Herrn soll ich jetzt dienen? Auf wen soll ich jetzt hören, das gab es da auch schon und das ist aber eben ein klassisches Dilemma von Matrixorganisation und da glaube ich halt, dass das Lean Product Development, das ziemlich deutlich definiert hat, weil es diesen Chief Engineer, der ja schon sehr herausragende Rolle hat, gibt. Ich glaube auch fast eine deutlich stärkere Rolle, wie ein Product Owner, vielleicht, weil es in einer größeren Organisation zumindest viel mehr Product Owner gibt, vielleicht für ein eigenes Release, während jetzt im Automobilkontext halt der einem Fahrzeug zugeordnet ist, dass natürlich selber einen Lebenszyklus durchläuft; und wie viele Fahrzeugtypen hat jetzt der klassische Automobilbauer, wenn es ein ganz großer ist, dann kannst du das mit einer, vielleicht mit zwei Händen, bist du dann durch, und damit sind das, ich glaube deutlich stärkere Leuchttürme, weil sie viel präsenter, präsenter sind in allen Konsequenzen.

Jan Fischbach: Das wünsche ich mir natürlich für die Scrum Teams auch. Ja, also die Product-Owner-Rollen sind oft zu schwach besetzt aus meiner Sicht, wenn du zum Beispiel bei StepStone dir die Gehälter anguckst, dann ist der Product Owner nur ganz gering über der oder fast gleiches Gehalt im Durchschnitt wie der Scrum Master und das ist natürlich ein fatales Signal, so, also der müsste natürlich viel besser bezahlt werden, eher in Richtung Chefkonstrukteur oder erfahrener Produktmanager, weil das ist ja die Aufgabe, die sie machen. Wir erzählen das in unseren Trainings immer so, der Product Owner muss das Mandat mit der Geschäftsführung klären. Es gibt eine Prüfungsfrage, da wird gefragt: Wenn CEO oder Geschäftsführung und Product Owner über die Weiterentwicklung des Produkts streiten, wer hat denn das letzte Wort? Und dann ist natürlich die richtige Antwort der Product Owner. Und dann lachen natürlich alle im Raum. Ja natürlich, aber in unserer Organisation wäre jetzt immer der Chef. So, und dann ist das natürlich für uns der Punkt, dass wir sagen: Ja, deswegen müssen wir den Chefs das erklären, wie gut Scrum funktioniert. Und jetzt müssen Chef und Product Owner das Mandat klären, und der Chef sagt dann: Hier hast du Geld und bringen mehr Geld zurück, das sind die Entscheidungen, die du treffen darfst. Das sind die Entscheidungen, in die ich eingebunden werden möchte und alle vier Wochen trinken wir beide einen Kaffee. So, dann ist das Mandat klar.

Götz Müller: Ja, und ich glaube, das ist jetzt noch mal ein guter Punkt, weil das natürlich Softwareentwicklungskontext und wie gesagt, da habe ich ja selber einen gewissen Hintergrund, damals schon unsere Erkenntnis war, dass dieses normative Element der Produktion fehlt. Dass ich also, und das mag jetzt einerseits ein gewisser Vorteil sein, dass im Softwareentwicklungskontext ein Stück weit derjenige, der das Produkt beauftragt auch der Kunde ist, weil in dem Sinne keine Produktion nachgeschaltet ist, für die ich halt diese lästigen Dinge wie Stücklisten, wie Arbeitspläne und und und und und was es noch alles gibt, das muss ich ja im Softwarekontext nicht machen. Das ist zwar einerseits eine coole Sache, weil ich bestimmte Dinge einfach nicht tun muss, aber es fällt mir das, wie ich es gerade genannt habe, dieses normative Element, und trotzdem ist es mir vor, ja, ich glaube, es ist jetzt schon fast zwei Jahre her, ist es mir begegnet, dass ein Entwicklungsleiter in einem Kontext physischer Produkte, aber gleichzeitig agile Entwicklungsmethoden, nenne ich das jetzt mal, dort implementiert, wurden für ihn aus einem Kata-Workshop raus die Erkenntnis des Tages war, dass sein Kunde ja nicht der Produktmanager ist, das ist sein Auftraggeber, sondern dass sein Kunde die Produktion ist, wo ich dachte, ein bisschen überspitzt ausgedrückt, ich bin im falschen Film, aber also das hätte ich mir vorher nicht vorstellen können, dass das jemand das so nicht erkannt hat, aber jetzt auch gerade, wo ich mich selber noch mal reden höre, da habe ich so ein bisschen das Gefühl, vielleicht hat das aus dem agilen Kontext rausgeerbt irgendwie.

Jan Fischbach: Ja, ja, das kann sein. Ich weiß es nicht so genau. Wie die Product Owner mandatiert werden, das ist mir ein Rätsel, weil eigentlich sind sie ja zu schwach mandatiert. Und ich glaube, ich habe viele Product Owner kennengelernt, die haben so richtig das Geld nicht im Blick. Also die wissen vielleicht, was ein ihr Team kostet, aber sie können zum Beispiel gar nicht beziffern, wieviel Umsatz sie mit dem Produkt machen wollen oder tatsächlich machen. Und das sehe ich in ganz kleinen Firmen, die haben zum Glück, da kennen sowieso alle die Zahlen, aber in größeren Firmen, wenn ich zu einer Bank oder zu einem Versicherungskonzern und sage: Was kostet denn dein Produkt und wieviel Umsatz machst du damit, dann zucken die mit den Schultern und sagen: Da haben wir nicht drüber gesprochen, also die würden das wahrscheinlich rausfinden, ja, aber das war gar nicht auf deren Radar, also die Frage: Für wen arbeite ich? Das können die nicht beantworten. Also wenn du oder ich, wenn wir jetzt ein Kundenprojekt haben, dann können wir sehr wohl entscheiden: Hängen wir jetzt noch eine Stunde dran, kriegen wir die bezahlt oder kriegen wir die nicht bezahlt? Und das prägt unsere Entscheidungen. Die großen Firmen, die ja oft, die ja jahrelang unseres Scrum-Trainingskunden waren, da war das ein Rätsel für.

Götz Müller: Mhm, ja, das hängt jetzt vielleicht damit wieder zusammen, Theorie von mir, dass man hinter dem Begriff Product Owner als Außenstehender vielleicht und vielleicht auch jetzt als Auftraggeber oder als derjenige, der sagt, okay, wir stellen jetzt unsere Organisation auf eine agile Basis, dass der vielleicht aus dem alten Modell raus, das dem Produktmanager gleichsetzt. Was aber jetzt, wie ich es bei dir rausgehört habe gerade oder so reininterpretiert habe, nicht der Fall ist, weil der Produktmanager klar die Aufgabe hat, den Business Case für das Produkt zu definieren, also der, wenn der nicht wüsste, was denn sein Produkt über die Laufzeit hinweg einspielen wird vom Markt her und wenn der nicht sagen würde, und dafür kann ich mir dann entsprechend dieses Entwicklungsbudget vorstellen, dann würde er ja nie über eine erste Definitionsphase hinwegkommen, weil eben sein Geschäftsführer oder sein Vorgesetzter sagt: Was soll denn das, wollen wir jetzt würfeln oder wollen wir das irgendwie auf unser Geschäftsmodell abbilden und da habe ich jetzt aber gerade das Gefühl eben, dass, wie du es ausgedrückt hast, dass da der Product Owner, das von ihm gar nicht erwartet wird, und dass das aber, glaube ich, gleichzeitig ein Stück weit das Problem ist.

Jan Fischbach: Ja. Also ich find den Begriff Product Owner sehr künstlich. Damit kann man, zumindest im deutschen Sprachraum kann da keiner etwas mit anfangen. Ich hätte also, ich hätte den Begriff Chefkonstrukteur übernommen, das impliziert gleich ein ganz anderes Standing aus meiner Sicht. Wir müssen ja jetzt in den Scrum-Trainings die Begriffe verwenden erstmal, die im Scrum Guide auch so definiert wurden und Product Owner sagt natürlich schon, es ist der Besitzer, der die Verantwortung hat für das Produkt. Es kommt vielleicht im deutschen Sprachraum nicht so rüber, kann sein.

Götz Müller: Aber also ich werde halt da das Gefühl nicht los, dass seine Position schwächer ist wie das, was ich hinter einen Chief Engineer sehe.

Jan Fischbach: Das sollte eigentlich nicht sein. Also Jeff erzählt dann die Geschichte, wie sie ihren ersten Product Owner gefunden haben und das war halt ganz klar jemand im Produktmarketing, ein Produktmanager, der ganz genau wusste, was er wollte. Und der sagte, er suchte nach dem Smartest Guy in the Room, der diese Aufgabe erfüllen konnte, weil er sagte: Wir sind nicht als Team in der Lage, das allein zu priorisieren, wir verstehen davon zu wenig.

Götz Müller: Mhm gut, das wäre wahrscheinlich eine extra Episode und vielleicht schreiben wir uns das irgendwo auf den großen Plan über dieses Thema noch zu reden. Wenn wir jetzt noch mal zurückkommen, den Titel der Episode habe ich ja gewählt mit TWI im Scrum Kontext, und ich habe bei dir aber eben jetzt nicht nur in der Unterhaltung, sondern an der ein oder anderen Stelle rausgehört, im Scrum-Kontext, ein bisschen flapsig ausgedrückt, schreit jetzt keiner Tschakka!, wenn du mit dem Thema TWI ums Eck kommst.

Jan Fischbach: … das ist schon auch selten, was ich auch als grundlegende Qualifikation für den Scrum Master sehe, oder Job Methods, wie es eigentlich hieß, die setzen sich nicht mit diesen Themen auseinander, weil wir, der Scrum Guide immer sagt, der Kern von Scrum ist dieses kleine crossfunktionale Team, das sich selbst verbessert, erstmal, so. Und es wird dann so ein bisschen den Scrum Mastern überlassen. Es gibt viel Literatur, man achtet mehr so auf Patterns, weil wir, weil ganz viele Scrum-Leute die erste Generation der Scrum-Leute, da kamen halt ganz viele aus der objektorientierten Programmierung und da war halt Pattern Language, der der heiße Scheiß, sage ich mal. Und sie haben natürlich dann geguckt, welche Patterns gibt es denn bei uns und so. Ich glaube, da kann man dann, wahrscheinlich würden wir beide, wenn wir jetzt über die Pattern setzen, würden wir wahrscheinlich ganz viele Dinge sehen: Ja, haben wir bei Lean auch, macht der und der oder ist die und jene, diese und jene Methode, und so würden wir sicherlich ganz viel gleiches finden. Und Jeff ist sehr akademisch geprägt, der hat ja einen Doktortitel gemacht und war lange im Uni-Kontext. Das heißt, der hat sich, seine Wissensarbeit war immer wieder zu gucken, welche Paper gibt es, was kann ich daraus lernen und hat dann versucht diese Erkenntnis aus der Wissenschaft auf sein Team zu übertragen und war damit auch sehr erfolgreich so, und es kann natürlich sein, dass es einfach eine andere Herangehensweise war. So, und Jeff war ja auch Kampfflieger. Das heißt, Umgang mit schnellen Flugzeugen ist natürlich sehr risikoreich. Das heißt, die mussten sich immer an Prozeduren halten. Es gibt zum Beispiel ein Muster, die Emergency Procedure bei Scrum, die den Piloten aufs Oberschenkel auf den Oberschenkel tätowiert ist, in Anführungszeichen, so, das gibt es bei Scrum auch, aber das ist schon oft Advanced-Zeug. Da hat sich ein bisschen eine andere Herangehensweise wahrscheinlich entwickelt über die Jahre, und man hat dann gar nicht gesehen, welche coolen Ideen eben auch in anderen Sachen sich bewährt haben und die Ausbildung der Leute finde ich nach wie vor einen der wichtigsten Punkte.

Götz Müller: Mhm ja, und gleichzeitig aber klar, bei dem bei dem Stichwort Luftverkehr und das, was du mit der mit der Tätowierung, also sprich Checklisten angedeutet hast, nehme ich ganz oft wahr als eine Sache, wo Menschen sagen: Ah, nee, Checklisten, wir wissen doch was wir tun müssen. So ein bisschen schwingt da immer mit: Das schränkt uns zu sehr ein. Und wenn man dann noch das Stichwort Standards nennt, dann rennt sowieso die Hälfte schreiend davon, dass halt der Wert im Grunde viel zu wenig, ja, gesehen wird, möchte ich es mal ausdrucken und auch da sehe ich eine große Gemeinsamkeit oder Gemeinsamkeit ist vielleicht nicht ganz der richtige Begriff, aber wir leiden, also sowohl die Scrum-Agile-Welt, als auch die Lean-Welt leidet unter vergleichbaren Dingen, weil auch im Lean Kontext, wenn man mit dem Thema Standards ankommt, wenn man mit dem Thema Checklisten ankommt, auch da rennen gefühlt 50% der Menschen schreiend davon, und bei den anderen 50% geht die Hand in die Tasche und das Messer geht auf.

Jan Fischbach: Mhm, da heißt es dann so schön, man sollte sich jetzt ja nicht zu dogmatisch oder zu akademisch sehen, heißt es dann.

Götz Müller: Ja, genau, und da natürlich vielleicht ein Stück weit, TWI mit den Jobmodulen, natürlich da noch mal fast eins draufsetzt. Du hast vorhin gesagt, wie die die Schulungsunterlagen aufgebaut sind, im Grunde ist es ein Drehbuch, wo genau steht und an der Stelle, nimm den Stift in die Hand und schreibt das auf die Tafel. Mehr kann man im Grunde gar nicht vorgeben und in den alten Dokumenten steht mehr oder weniger auf jeder Seite und auch in der Fußnote: Und halt dich sklavisch an das, was da steht, weich bloß keinen Millimeter davon ab, sonst kommt der große Teufel und holt dich und du schmorst für alle Zeit im Fegefeuer. Ich glaube, das wäre jetzt eine Sache von mir jetzt reininterpretiert, das kann man sich, kann ich mir zumindest im Scrum-Kontext gar nicht vorstellen. Und vielleicht ist das auch ein Grund, warum es halt da Widerstände gibt.

Jan Fischbach: Ja. Ja, also, die Scrum Trainings und die Scrum Community lebt natürlich auch von sehr starken Individuen und die haben natürlich auch eine starke Meinung und die würden sich natürlich jetzt nicht irgendwie dazu hinreißen lassen, ich muss jetzt diesen Scrum Guide, also den Scrum Guide vielleicht, aber alles andere würden sie niemals irgendwie eins zu eins einhalten wollen. Vielleicht ist auch eine Softwareentwicklungsgeschichte, das ist vielleicht ein Thema, was die Softwareindustrie anzieht. Das kann natürlich auch sein.

Götz Müller: Ja.

Jan Fischbach: Das ist vielleicht ein Grund, dass wir uns verschiedene Schwerpunkte gesetzt haben. Das muss man ein bisschen gucken, wenn ich agile Coaches ausbilde, dann gebe ich die Aufgabe sich mal so einen Entwicklungsplan zu überlegen für ihr Team und dann habe ich manchmal Leute drinsitzen, die sagen: Ja, wieso soll ich das denn machen? Also es reicht doch, reicht das denn nicht, wenn ich die Retrospektiven moderiere als Scrum Master? Und dann suchen wir nach ein paar lustigen Methoden, dass sie viel Spaß bei der Arbeit haben und so und das ist natürlich auch wichtig, weil diese Methoden natürlich Wissen zutage fördern und dass wir vielleicht auf der anderen Seite nicht reinkommen, aber nur das zu machen, dafür ist ein Scrum Master viel zu teuer, also da kann ich auch, da kann ich einen Kommunikationsexperte und Workshop-Leiter günstiger einkaufen, aber die Produktivität des Teams zu verdoppeln, ja, das hat vielleicht einen Preis, der attraktiv ist.

Götz Müller: Mhm. Ja, aber andererseits, zumindest in meiner Wahrnehmung, widersprich mir da gerne, ist es halt nicht Teil der Ausbildung, während es im TWI-Kontext klar Teil der Methode ist. Das ist der Ausgangspunkt und wenn ich mir die, alleine, wenn ich mir die Karte anschaue, dann steht da: Mach dir den Plan, also fange nicht blind an zu unterweisen, sondern mach dir erstmal einen Plan, wen habe ich als Personen in meinem Team? Was habe ich für Tätigkeiten, wer kann was und wer soll was bis wann können? Und erst dann geht es los mit dem Unterweisen. Und es ist eben ein ganz klarer Teil der Ausbildung, dass ich auch das lerne. Da habe ich das Gefühl, dass Scrum halt ein bisschen zu kurz greift.

Jan Fischbach: Ja, da ist nichts, da ist nichts. Also wenn das nicht zufällig jemand lernt oder wenn nicht zufällig jemand schon in der Produktion mal gearbeitet hat oder mal einen Meister gemacht hat und eine Ausbilder-Eignungsprüfung oder so, ja, dann wäre da nichts. Und das ist halt schade.

Götz Müller: Da würde ich mich aber umgekehrt auch nicht wundern, wenn halt Widerstand, wie du es ausgedrückt hast oder wie ich es rausgehört habe, wenn halt von den Scrum Mastern Widerstand entsteht, weil sie es im Grunde nicht wissen. Und jetzt sind halt wir Menschen ja nicht klassisch so gepolt, dass wir sagen Tschakka, ich weiß das nicht, super Sache!, sondern in der Regel tendieren wir erst eher dazu, dieses Nichtwissen irgendwie so auf die Seite zu schieben und uns da keine Blöße zu geben und das finde ich den Punkt, da ist für mich ganz klar die Organisation wieder in der Pflicht. Und wenn sie das nicht erkennt, dann hat sie abstrakt gesehen, ein Stück weit, ihren Job verfehlt.

Jan Fischbach: Ja, also in vielen Opposition ist Scrum so eine Graswurzelbewegung, wo dann ein oder zwei Teams mal anfangen und von unten her die Sache klären und sagen: Wir wollen jetzt besser zusammenarbeiten, weil wir mit unserer eigenen Geschwindigkeit nicht zufrieden sind. Und die wollen eigentlich dem Management darüber irgendwie aus dem Weg gehen. Die haben keine Lust, sich mit denen auseinanderzusetzen, weil die sagen: Ja, die checken das sowieso nicht, was wir da tun, weil die kommen ja gar nicht aus der Software-Expertise und wenn wir uns so sehr mit denen beschäftigen, dann verbieten die uns das oder kürzen unser Budget noch mehr oder solche Dinge, weiß ich nicht, also die Scrum Teams, mit denen ich zu tun habe, in den Trainings, die sind oft verzweifelt, was ihre eigene Organisation angeht, die trauen denen das gar nicht mehr zu, dass man aus diesen unglücklichen Leuten, die insgesamt in der Organisation sind, wieder eine lustige Company zu machen.

Götz Müller: Ja, aber trotzdem muss die Organisation, weil du wirst ja nicht von den Teams bezahlt, muss die Organisation dann ein Stück weit schon den Geldbeutel aufmachen.

Jan Fischbach: Ja. Musst du, also manche haben dann so ein Budget, wo sie das dann mitfinanzieren. Und viele Hindernisse, auf die die Scrum Teams stoßen, also wir sind ja nicht besser, weil wir Scrum machen, sondern wir sind ja besser, weil wir anfangen, diese Hindernisse aus dem Weg zu räumen, ja. Wenn also ein Team zu viele Dinge gleichzeitig macht, das ist ein großes Hindernis, dann muss man verhandeln und sagen, wir wollen mal eine Sache nach der anderen machen und nicht 1000 Dinge gleichzeitig, dann sind wir schneller fertig mit einer Sache, so. Oder weil wir besser priorisieren, weil wir zum Beispiel Features, die keinen Wert bringen, dass wir die gar nicht erst anfangen. Deswegen müssen wir ganz viele Dinge, die nichts bringen, lassen wir, und damit sparen wir viel Zeit, und der Kunde ist eher zufrieden und er muss nicht so viel bezahlen, weil die Features, die vorher gebaut, aber nicht genutzt wurden, mussten ja mitfinanziert werden. Wir sind mit Scrum also nicht besser, weil wir den Scrum Guide einhalten, sondern weil wir genau auf diese Hindernisse reagieren, die die Organisation vorher abgehalten hat, zu liefern. So, und wenn wir jetzt aber so ein Scrum Team aufbauen und sagen, ihr müsst das jetzt mal mit eurer Organisation, dass wir nicht 1000 Dinge gleichzeitig machen. Wir müssen jetzt eine Reihenfolge hinbringen. So wer setzt sich denn jetzt dahin, um die Themen zu durchzupriorisieren? Da reagieren die Scrum Teams und sagen: Ja, mhm, das wollen die, glaube ich, nicht hören über uns.

Götz Müller: Da höre ich jetzt ein vergleichbares Dilemma raus, im Lean Kontext ist ja manchmal so der Gedanke da: Ja, ich fange mit 5S an und der Rest regelt sich dann von alleine. Also sprich ich packe halt mal den großen, oder vielleicht an der Stelle sogar eher noch den kleinen, Methodenkoffer aus, was absolut nützlich ist, aber wenn es halt nicht in etwas Größeres eingebettet ist, dann kann man im Grunde die Uhr so danach stellen, wann das Thema mehr oder weniger wieder einschläft, weil nicht die Effekte, die daraus erzielt werden können, wie halt jemand, ich verwende jetzt ein bisschen überspitzt den Begriff, Unbedarftes, wenn er mal etwas von Toyota und Lean gehört hat: Coole Sache, größter Automobilhersteller, absolut profitabel, machen wir auch, so machen wir mal 5S. Ja, das ist ein erster Schritt, aber nur ein ganz kleiner erster Schritt. Und wenn ich sonst nichts tue, passiert auch nichts.

Jan Fischbach: Ja, genau, und sie haben dann die alten Werk-, Arbeitsstationen. Es ist keine U-Zelle, es ist kein Flow in der Halle, so, aber es ist sehr aufgeräumt. Dann ist natürlich keine höhere Geschwindigkeit da.

Götz Müller: Gut. Ich glaube, wir könnten, ich gucke mal bisschen auf die Uhr, wir sind schon ziemlich gut an der Stunde dran, das wird eine der längeren Episoden definitiv. Ich glaube, wir könnten noch eine Weile weitersprechen, aber vielleicht ist jetzt der ein oder andere, der im Auto sitzt und im Auto zuhört, angekommen.

Jan Fischbach: Der ist schon da.

Götz Müller: Deshalb lass uns an der Stelle vielleicht einen Knopf dran machen, vielleicht mit der Aufforderung an die Zuhörer: Wenn Ihnen in dem Kontext und ich glaube, dadurch, dass wir jetzt in zwei Communities unterwegs sind, möglicherweise eben auch jemand aus der Scrum-agilen-Ecke die Episode hört, jetzt so ein bisschen die Aufforderung an alle Zuhörer, Feedback zu geben, vielleicht auch der Gedanke eben, kommt mir jetzt gerade, am neunten Januar, die Episode wird vorher online gehen, haben wir ja noch mal unser gemeinsames Treffen der Communities. Da wird ja auf der Lean Base auch ein bisschen was veröffentlicht, vielleicht wird es auch so ein gemeinsames, sich in die Arme fallen und heulen drüber, weil die Welt da draußen so schlimm ist, aber wir sind ja im Grunde angetreten, beide angetreten, sie besser zu machen.

Jan Fischbach: Ja, sind wir. Und ich glaube, wir können viel voneinander lernen. Also ich wünsche mir so, ich wünsche mir mal so gemeinsame Projekte, wo ein agiler Mensch und ein Lean-Mensch irgendwie zusammen auf eine Sache gucken, machen wir ja zumindest auch Götz. Ende Januar haben wir ja auch einen Termin, wo wir uns nochmal von unterschiedlichen Sichtweisen auf ein Unternehmen gucken, aber ich glaube, es steckt so viel Weisheit in den Methoden, die sind aber versteckt hinter Begriffen, die unverständlich sind für jemanden, der außerhalb dieser Community ist und wenn wir gemeinsam irgendwie an verschiedene Themen mal rangehen und sagen: Wir gucken das an und wir reflektieren das gemeinsam oder wir fragen, was hat dir denn geholfen, um besser zu werden, oder was meinst du denn, warum diese Organisation hier besser geworden ist, dass wir … also, da möchte ich gerne dazu einladen, dass man aktiv nach Leuten nicht aus der eigenen Community, sondern aus anderen Communities mal sucht und sagt: Hier, wollen wir mal Geschichten erzählen und uns auch gegenseitig angucken. Das würde mich sehr freuen, weil ich glaube, da können wir ganz viel voneinander lernen, zum Wohle unserer ganzen Kunden, die wir haben.

Götz Müller: Genau, das war jetzt ein wunderbares Schlusswort. Jan, ich danke dir für deine Zeit heute.

Jan Fischbach: Danke dir, lieber Götz.

Götz Müller: Das war die heutige Episode im Gespräch mit Jan Fischbach zum Thema TWI im Scrum-Kontext Notizen und Links zur Episode finden Sie auf meiner Website unter dem Stichwort 354.

Wenn Ihnen die Folge gefallen hat, freue ich mich über Ihre Bewertung bei Apple Podcasts. Sie geben damit auch anderen Lean-Interessierten die Chance, den Podcast zu entdecken.

Ich bin Götz Müller und das war Kaizen to go. Vielen Dank fürs Zuhören und Ihr Interesse. Ich wünsche Ihnen eine gute Zeit bis zur nächsten Episode. Und denken Sie immer daran, bei allem was Sie tun oder lassen, das Leben ist viel zu kurz, um es mit Verschwendung zu verbringen.
Jetzt eintragen und Artikel/Denkanstöße zukünftig per eMail erhalten.

Artikel teilen auf ...

Hinweis: Ich behalte mir vor, Kommentare zu löschen, die beleidigend sind oder nicht zum Thema gehören.