Agilität ist tot! Lang lebe Agilität!

Titelbild Podcast Business Akupunktur

Jan Fischbach über den Kern von Scrum

Scrum heißt: „Wie verbessern wir uns? Wie machen wir tolle Produkte? Und ein bisschen auch, wie gehen wir mit Komplexität um? Wie können wir das beeinflussen?“ Darum geht es eigentlich.

Jan Fischbach über Scrum und Agilität in 2024

Die Scrum-Welle ist durch. […] Es gibt halt so Wellen. So und was wir jetzt halt sehen, viele Firmen, die halt eine agile Practice aufgebaut haben, da werden jetzt wirklich im großen Stil auch Leute gefeuert.

Jan Fischbach über sein Verständnis von Agile Coaches

Und wir [Jan und seine Kollegin Maria] sind aneinander geraten. Da habe ich gesagt: „Halt mir die [Agile Coaches] Leib. Die reden nur. Die ändern ja nichts!

Jan Fischbach über das Ubongo Flow Game

Ich weiß gar nicht, ob ich mich als Erfinder sehe. Eigentlich habe ich es [das Ubongo Flow Game] nur weiterentwickelt. Ich habe damals das Lego-Flow-Game gespielt. Das war mitten im Sommer. Wer das Lego-Flow-Game von Sally Ann Freudenberg und Karl Scotland kennt, weiß, das wird mit Lego-Steinen gespielt, mit Adventskalendern.

Jan Fischbach über das Buch "Visible Ops"

Also das Buch [Visible Ops] finde ich heute immer noch gut. Ich habe damals im Rechenzentrum gearbeitet, hatte gerade eine ITIL-Schulung hinter mir.

Zusammenfassung

​In dieser Episode spreche ich mit Jan Fischbach, einem langjährigen Scrum-Trainer und Berater, zum Thema Agilität und Scrum. Wir diskutieren die historischen Wurzeln von Scrum, die auf verschiedene Strömungen des Managements, der Psychologie und der Militärtaktik zurückgehen, und wie Scrum von Toyota und anderen Unternehmen beeinflusst wurde. Die Ursprünge von Scrum gehen auf verschiedene Ideen aus dem 19. und 20. Jahrhundert zurück. Wir zeigen auf wie Scrum helfen kann, Produkte zu verbessern, mit Komplexität umzugehen und sich kontinuierlich zu verändern. Dann sprechen wir über die Rolle des Scrum Masters und des agilen Coachs, die beide als Führungskräfte agieren sollen, die das Team und die Organisation unterstützen und verbessern. Wir betonen die Wichtigkeit, das Mandat für diese Rollen zu klären, den Wert, den sie liefern, zu messen und empirisch zu arbeiten. Wir ermutigen die Zuhörer, sich mit anderen aus der agilen Community auszutauschen, sich an das große Ganze zu erinnern und Spitzenleistung anzustreben.

Die Episode gibt auch einige Tipps und Ressourcen für diejenigen, die mehr über Scrum und Agilität lernen wollen: Wir empfehlen das Buch Visible Ops als eine gute Einführung in DevOps und die Prinzipien hinter ITIL und Lean. Jan Fischbach verweist auf seinen Blog, auf dem er verschiedene Artikel über die Geschichte und die Ideen von Scrum geschrieben hat, sowie auf das Scrum Events Netzwerk, das er mit anderen Trainern und Beratern gegründet hat.

Transkript der Episode

​Dierk

Hallo und herzlich willkommen zur 31. Episode des Business Akupunktur Podcasts mit dem Titel Agilität ist tot, lang lebe Agilität. Ich freue mich auf dieses Thema und meinen Gast Jan Fischbach, vor allen Dingen auf meinen Gast, denn ich verfolge Jan schon seit Jahren als Inspirationsgeber zu meinen Themen über die verschiedenen sozialen Plattformen. Ich glaube, wir haben auf Xing gestartet und das hat ja schon was zu heißen und was zu bedeuten.

Teilnehmende meiner Schulung kennen vielleicht auch das Ubongo Flow Game, was ich sehr gerne spiele. Ein super tolles Spiel und das ist von Jan entwickelt worden. Also insofern freue ich mich auch über dieses Thema mit Jan, zumindestens mal kurz zu sprechen. Jan schreibt fundierte Blogbeiträge und ich lese aus diesen Blogbeiträgen sehr viel raus. Also da ist sehr viel Wissen drin. Da sieht man, dass sich Jan mit diesen Themen beschäftigt und nicht mal nur eben was runterschreibt.

Die sind mir für mich immer sehr hilfreich und einige davon werden wir heute auch thematisieren. Es gibt einen ganz besonderen, über den ich quasi nochmal den Kontakt zu Jan aufgenommen habe. Aber wie gesagt, wir werden auch ein paar mehr aus seinem Veränderungsblog heute zitieren.

Jan ist Trainer und Berater sowohl beim Common Sense Team als auch im Scrum Events Netzwerk, hat bis zum Jahr 1999 Elektrotechnik studiert und ist quasi genau wie ich dann Quereinsteiger. Ich als BWLer, Jan als Elektrotechniker und Jan war dann in verschiedenen Unternehmen im Bereich IT und Prozesse tätig.

Im Jahre 2013 hat er mit anderen Kollegen und Kolleginnen das Common Sense Team gegründet. Jan gibt einerseits viele Scrum Trainings und er macht aber auch andererseits Beratungsprojekte, in denen es um die Einführung von Unternehmenssoftware geht. Vielleicht seid ihr Jan ja auch schon mal begegnet auf einer agilen Konferenz, zum Beispiel bei den Scrum Days in Stuttgart oder eben in diesem Jahr war er bei der Lean Around the Clock in Mannheim.

Hallo Jan, herzlich willkommen und vielen Dank für deine Zeit. Habe ich bei deiner Vorstellung irgendetwas vergessen?

Jan Fischbach

Hallo Dierk, vielen Dank erstmal für die Einladung und die Blumen, die du mir gerade überreicht hast. Für das Autoren-Ego ist das natürlich immer ganz gut, wenn jemand auf die Blogbeiträge eingeht. Ja, was gibt es noch zu mir zu sagen? Ich wohne in Ostfriesland, oben an der Nordseeküste. Das heißt, wenn ich zu meinen lieben Kunden in der Republik unterwegs bin, fahre ich viel Zug, ich fahre gerne Zug. Man muss gerade viel Geduld mitbringen, aber das gehört zum Job dazu.

Dierk

Richtig, finde ich auch. Und wenn wir schon über das Zugfahren sprechen, es gibt Menschen, die haben sich daran gewöhnt, auf der Autobahn im Stau zu stehen. Und wir als Zugfahrer haben uns auch daran gewöhnt, dass es eben auch mal eine Verspätung gibt. Für manche Menschen ist Stau auf der Autobahn normal, für mich auch nicht. Aber dass so sind, unterschiedlich sind eben die Menschen.

Jan, was hast du denn gedacht, als du zum ersten Mal den Titel Business Akupunktur gehört hast? Weil das ist ja die Frage, mit der ich immer einsteige, wenn ich meine Gäste in diesem Podcast die Aufnahme bringe.

Jan Fischbach

Genau. Ich habe zwei Dinge damals gedacht. Das erste war, wenn man sich diese Anleitung anguckt zur Akupunktur, dachte ich, oh Gott, wer kann sich diese ganzen Linien und Punkte merken? Ergibt das alles einen Sinn so? Also weiß jemand, wo er genau hinpiksen muss?

Ich habe auch schon Leute erlebt, die Akupunkturbehandlung hinter sich hatten. Das hat denen geholfen. Also scheint zu wirken, aber andererseits gibt es natürlich wenig wissenschaftliche Studien. Wirkt denn das auch mehr als über den Placeboeffekt hinaus? Aber das ist ja auch schon eine Wirkung.

Dierk

Ja, also der Titel, der ist mir irgendwann mal bei einem Hundespaziergang eingefallen. Ich habe bei Hundespaziergängen immer meine besten Ideen, glaube ich, meine inspirierendsten Ideen. Was ich einfach da interessant finde, ist, um mit kleinen Nadelstichen einfach Veränderungen herbeiführen. Und dann, wer heilt, hat Recht. Gibt ja auch diesen schönen Spruch. Also, sofern, wenn wir mit unseren Nadelstichen heute auch über das Thema Agilität zum Beispiel, wenn wir damit helfen können, dann ist das ja schon mal gut.

Ich habe ja gesagt, ich sehe dich als Inspirationsgeber. Wir sind in Kontakt gekommen von vor vielen Jahren, als du mir das Buch VisibleOps empfohlen hast. Das war so für mich auch ein bisschen der Einstieg in das ganze Thema DevOps und Gene Kim und so weiter. Vielleicht kannst du mal kurz sagen, warum du das Buch damals gut fandest und ob du es heute auch noch gut findest.

Jan Fischbach

Also das Buch finde ich heute immer noch gut. Ich habe damals im Rechenzentrum gearbeitet, hatte gerade eine ITIL-Schulung hinter mir.

Und ich musste mir Gedanken über unsere eigenen Prozesse machen im Rechenzentrum. Und da bin ich irgendwie auf eine Handreichung für Wirtschaftsprüfer gestoßen zur Bewertung von Rechenzentrumsprozessen. Und da gab es irgendwie diesen Hinweis auf das VisibleOps Handbook. Und die Geschichte, die Gene Kim dort beschreibt, er hat ja ursprünglich eine Software entwickelt gegen Internetwürmer und Viren, und hat dann in der Praxis festgestellt, dass oft Leute seine Software einsetzen, um Änderungen an Systemen zu überwachen und damit ein Change Management initiieren. Und das fand ich eigentlich ganz gut und es erklärt aus meiner Sicht viel besser ITIL und auch DevOps, weil die Prinzipien besser herüber kommen. Der Schritt zu den Tools ist dann kleiner. Aber wenn man über die Tools einsteigt, ist es oft sehr schwierig zu verstehen, warum man das eigentlich macht.

Dierk

Ja, guter Punkt. Ich kenne auch Unternehmen, die sagen, wir machen DevOps, weil sie eine Jenkins Pipeline oder sonst was eingebaut aufgebaut haben.

Jan Fischbach

Genau, sie haben ein DevOps Team. Sie haben ein DevOps Team. Mhm. Mhm. Ja.

Dierk

Ja, ja, ja. Wir machen DevOps. Hab ich auch schon erzählt. Die da machen Dev und die machen Ops. Aber gut, wir haben ja andere Themen. Wir wollen ja auch so ein bisschen in der Fassade von Agilität gucken. Da ist natürlich DevOps auch mit einem Thema. Aber wollen wir nicht abschweifen. Vielleicht noch ganz kurz eine Geschichte von dir. Wie bist du dazu gekommen, das Ubongo Flow-Game zu entwickeln – kann man das so sagen – zu erfinden?

Jan Fischbach

Ich weiß gar nicht, ob ich mich als Erfinder sehe. Eigentlich habe ich es nur weiterentwickelt. Ich habe damals das Lego-Flow-Game gespielt. Das war mitten im Sommer. Wer das Lego-Flow-Game von SallyAnn Freudenberg und Karl Scotland kennt, weiß, das wird mit Lego-Steinen gespielt, mit Adventskalendern. Im Sommer habe ich einfach keine Chance gehabt, an irgendwelche Adventskalender heranzukommen. Ich musste mir also überlegen, wie kann ich bauen? Ich stand da vor meiner Spielesammlung.

Ich habe so geguckt und gedacht, wo ist was mit Bauen. Und da kam das Ubongo-Spiel mir gerade Recht. Ich habe es ausprobiert. Das  funktioniert relativ gut. Also immer noch eine sehr schöne, sehr schöne Übung. Guckt es euch an, in den Show Notes ist sicherlich der Link zur Anleitung. Ein super Spiel.

Dierk

Richtig, auf jeden Fall, weil das finde ich auch das Schöne, dass du es eben entsprechend bereitstellst, dass man sich das quasi kostenlos benutzen darf. Und wenn man die Quelle angibt, nämlich genau diese drei Erfinder, du bittest ja auch darum, diese drei Namen zu nennen, mache ich auch dann sehr, sehr gerne. Und wenn jemand Lust hat, der darf sich sicherlich bei dir gerne melden oder bei mir, wenn er da ein bisschen einsteigen möchte, um sich dieses Spiel erklären zu lassen oder es vielleicht sogar auch irgendwie anzuwenden.

Dauert auch nur eine Stunde bei mir meistens, oder?

Jan Fischbach

Ja, gute Stunde plane ich auch immer ein.

Dierk

Aber gut, wir wollen über was anderes sprechen. Wir wollen über das Thema Agilität sprechen. Und wir haben uns beide ein bisschen schwergetan, damit für diese Folge und für das, was wir erreichen wollen mit der Folge, so einen richtig tollen Titel zu finden. Wir haben den Titel gewählt: „Agilität ist tot! Lang lebe Agilität!“ Ist jetzt nicht so der Burner. Wir hatten überlegt, ob wir das Ganze auch „Hinter die Fassade von Agilität gucken“ nennen. Egal, wir haben uns jetzt für diesen Titel entschieden und wollen so ein bisschen auch über das, was du wie gesagt in deinen Blogbeiträgen geschrieben hast, so ein bisschen gucken, wie wir im Jahre 2024 zu Scrum und Agilität stehen. Und vielleicht kannst du mal erstmal einsteigen, dass du so ein bisschen erklärst, Scrum ist ja für dich ein wichtiger Teil deiner Arbeit, ein großer Teil deiner Arbeit, wie erklärst du Scrum?

Jan Fischbach

Ich habe gerade letzte Woche wieder ein Training gehabt in einem Verwaltungsbereich. Der Chef lief mir über den Flur und der Chef sprach: „Ja, super, das mit dem Scrum. Wir überlegen noch, ob Scrum uns hilft, ob das überhaupt anwendbar ist.“ Und da steckt immer so ein bisschen die Methodensicht dahinter. Und das ist eigentlich nie das Thema bei meinen Schulungen. Wir sagen immer bei uns im Scrum Events Netzwerk, es geht nicht um die Einführung von Scrum, sondern geht es darum, dass wir uns verbessern. Können wir uns verbessern?

Und wenn ich den meisten Organisationen die Frage stelle: „Könnt ihr euch verbessern oder müsst ihr euch auch verbessern?“ da sagen die natürlich: „Ja“. Und was Scrum uns hier gibt, ist ein Rahmen für diese Verbesserung auf der einen Seite.

Dass wir regelmäßig einen Rhythmus reinbringen. Eine Rolle festlegen, die uns nerven darf, um Verbesserungen anzustreben. Und so ein bisschen auch sich das Mandat abzuholen, dass man das tun darf. Also Agilität heißt: „Wir dürfen über Verbesserungen und über unsere eigenen Prozesse reden“. Das ist der eine Teil. Und was Scrum auch sehr gut kann, ist Produkte entwickeln. Vielleicht kommen wir nachher noch dazu, ein bisschen hinter die Ideengeschichte zu gucken, wie das eigentlich entstanden ist.

Scrum ist da sehr gut und greift aber auch Ideen auf, die eigentlich sehr alt sind. Also das, was wir in Scrum machen, ist bestimmt 150 Jahre alt. In den 90ern hat irgendjemand eine Schleife rumgewickelt, Scrum draufgeschrieben. Das ließ sich eine ganze Zeit lang gut verkaufen. Jetzt müssen wir wieder zu den Kernpunkten zurückkommen. Also Scrum heißt: „Wie verbessern wir uns? Wie machen wir tolle Produkte? Und ein bisschen auch, wie gehen wir mit Komplexität um? Wie können wir das beeinflussen?“ Darum geht es eigentlich.

Dierk

sehr schön ja ja also wenn ich dann da so mal auf meine art und weise reflektiere wie ich es kommen erkläre würde ich das im prinzip ähnlich sehen wie du ich fange an bei einem dreitägigen training da geht es erstmal einen halben tag nicht um Scrum sondern um agilität also warum überhaupt Agilität.

Und wo können wir das anwenden oder warum machen wir das überhaupt? Was sind so Inhalte von Agilität? Also ich heb das quasi eine Stufe höher und dann werden eben natürlich ein paar Methoden, ein paar Werkzeuge erzählt und ich nerve meine Teilnehmenden immer mit meinem Lieblingsthema und das heißt kontinuierliche Verbesserung. Das ist der wichtige Punkt. Ja.

Jan Fischbach

Ich sitze hier gerade in unserem Büro in Stuttgart. Ein Zimmer weiter sitzt mein lieber Kollege Jean-Pierre Berchez und ich kann jetzt auf sein Flipchart gucken und er fängt eigentlich mit dem House of Scrum an. Das heißt, er malt so die empirischen Zusammenhänge und die Scrum-Werte.

Man sagt dann: „Ganz oben in der Dachspitze, unter dem Dach im Dachfenster, da ist dann die Mechanik von Scrum.“ Aber die Art und Weise, wie wir miteinander umgehen und wie wir messen, ob wir erfolgreich sind, das ist der viel wichtigere Teil und er sagt dann immer so nach der ersten Stunde: „Jetzt haben wir die Werte, jetzt könnten wir eigentlich auch aufhören. Wenn ihr das jetzt beherrscht, werdet ihr wahrscheinlich auch zu ähnlichen Ergebnissen kommen. Und der Rest, der jetzt kommt, ist eigentlich nur noch Mechanik und bekannte Praktiken, oder häufige Praktiken, die wir immer anwenden bei Scrum Teams.“

Dierk

Richtig sehr schön. Und insofern, das passt ja eigentlich auch zu dem Titel, wo wir beide nicht so ganz glücklich waren, aber wo uns dann doch kein Besserer eingefallen ist, dass es eben nicht darum geht, Scrum einzuführen. Auch das würde ich nicht empfehlen. Das ist für mich auch ein ganz wichtiger Punkt, dass ich das klar mache, sondern dass es darum geht, Agilität quasi reinzubringen in die Unternehmen, in die Abläufe usw. Und das auch nicht zum Selbstzweck, nämlich wir haben ein Problem,

Wie können wir dieses Problem lösen? Also wie könnte mir Agilität helfen oder wie kann mir auch was anderes auch helfen? Interessant finde ich, dass du gesagt hast, Agilität oder die Idee hinter Scrum, die ist 150 Jahre alt. Da hast du einer von mir so viele gelobten Blogbeiträge geschrieben. Wieso ist Scrum 150 Jahre alt?

Jan Fischbach

Ja. Ich saß irgendwann mal beim Jeff Sutherland im Training. Wir haben sehr viele Trainings mit Jeff gemacht.

Die sind eigentlich für die Newbies immer völlig überfordernd. Der zieht da seine hunderte von Folien durch. Man muss sich echt konzentrieren. Aber für uns Co-Trainer ist das immer super interessant. Wir sitzen dahin und denken: „Ah ja cool, die Geschichte kannte ich noch gar nicht.“  Oder „Ah stimmt, die hat er mal erzählt.“ Und da hat er irgendwann ein Buch aufgelegt über die Produktentwicklung und Prozessentwicklung bei Toyota. Das habe ich mir dann besorgt. Da stand an einer Stelle: „Irgendwann haben wir die Kunst, Kennlinien zu pflegen vergessen (

bei der Produktentwicklung).“ Da dachte ich: „Hä, was ist denn das genau?“ Und da habe ich versucht  rauszufinden, was damit eigentlich gemeint war. Und so habe ich mich dann auf die Reise gemacht, die verschiedenen Konzepte oder Ideen rauszufinden. Das hat jetzt 2016 oder so angefangen. Ich glaube, drei Jahre habe ich erst mal nur geforscht, bis ich so die Grundzüge verstanden habe.

Und Ideengeschichte ist ja keine Chronologie, sondern Ideengeschichte verfolgt, wie Menschen mit verschiedenen Ideen umgehen, wie sie die angepasst haben an bestimmte Bedingungen und wie sie sich weiterentwickelt haben. Und das, was wir heute Scrum nennen, beruht auf ganz vielen Dingen, die bereits Ende des 19. Jahrhunderts entstanden, als der Maschinenbau sich entwickelt hat, als die ersten großen Fabriken entstanden sind, wo man sich überlegen musste, wie organisiert man das eigentlich.

Die erste Welle ist vielleicht als Scientific Management bekannt geworden, dann die nächste Welle Qualitätsmanagement oder auch dann Lean später in den 80ern und heute sprechen wir von Scrum und Agilität. Und wir wissen, dass der Jeff ganz viele Dinge von Lean übernommen hat, von Toyota.

Er hat sich dann überlegt, wie kann uns das denn bei der Softwareentwicklung helfen, gute Ergebnisse zu liefern. Es gibt also eine unglaubliche Geschichte. Also wenn man da reinguckt, das ist nicht nur Zufall, sondern die Leute haben sich gegenseitig beeinflusst. Es gab weltweite Netzwerke von Leuten, die sich getroffen haben und ausgetauscht haben.

Das fand ich schon ziemlich cool. Ich hab’s eigentlich gemacht, weil ich Scrum besser erklären wollte. Wenn man diese ganzen Begriffe wie Product Owner, Scrum Master erklärt – das sind ja künstliche Begriffe – da kann keiner was mit anfangen.

Ich wollte eigentlich wissen, kann man das so erklären? Greift das auf irgendwas zurück, was wir schon kennen? Zum Beispiel der Product Owner ist viel besser als Chefkonstrukteur eines Autos erklärt. Und dann weiß man auch, wern setzt man denn als Chefkonstrukteur für ein Auto ein? Vielleicht jemand, der schon länger erfahren ist im Unternehmen und nicht vielleicht gerade so ein Anfänger.

Ich fand es ziemlich spannend, die Zusammenhänge zu sehen und ich versuche immer wieder mal darauf zurückzugreifen, wenn ich Scrum Trainings gebe, sodass die Leute sehen: „Ja, wir reden jetzt nicht über neue Dinge hier, sondern wir reden über ganz viele Sachen, die schon da waren. Und lass uns doch mal in unserer eigenen Geschichte gucken, auf welche Kultur-Artefakte oder Rituale wir auch selber zurückgreifen können, sodass wir das irgendwie auch in der Organisation verankern können.“

Ich weiß nicht, wo fängt für dich denn die Geschichte bei Scrum an? Ich meine, jetzt hast du ein bisschen was gesehen, aber wenn ich die meisten frage, wo fängt für dich Scrum an, dann ja, was war für dich der erste Punkt, wo du sagtest, ja, da fängt für mich Scrum an?

Dierk

Ich weiß gar nicht, ob ich also ich weiche dieser Frage mal ein bisschen aus, indem ich aus meiner Sicht erzähle, was ich Überraschendes erlebt habe. Ich gebe viele Scrum Trainings für Bundeswehr-Offiziere, für Abgänger von der Bundeswehr. Berufsförderungsdienst nennt sich das. Die Menschen werden dann auf die Zeit nach der Bundeswehr vorbereitet und Bundeswehr, denken wir alle, hat mit Agilität nicht viel zu tun.

Manchmal habe ich in den Trainings Menschen sitzen, die sagen, hey, wenn wir in unsere Bücher gucken, also in die Bundeswehr Verwaltungsbücher, die Ausbildungsbücher, da steht ganz viel über Scrum und Agilität drin. Das heißt, die Bundeswehr ist eigentlich im Kern agil.

Dumm ist nur, dass das niemand liest und umsetzt. Also das, was wir von der Bundeswehr wissen, was wir von Verwaltung wissen, aber insbesondere von der Bundeswehr, wenn die sich die Menschen an die Bücher halten würden und an die Grundgedanken, dann würde die Bundeswehr agil sein. Und wie gesagt, die Teilnehmer sind teilweise frustriert über das, was sie bei der Bundeswehr erleben. Also insofern, um den Kreis auch zu schließen.

Nach diesen drei Tagen gibt es immer Teilnehmende, die sagen, das glaube ich nicht, das wird so nicht funktionieren. Also ähnlich auch wie dein Leiter, der dir da über den Weg gelaufen ist. Wir gucken mal, ob das für uns passt so ungefähr.

Ich hoffe, ich verstehe mehr als nur das, was sie für die Prüfung brauchen. Die verstehen, was dahintersteckt, der Grundgedanke. Und das ist im gesunden Menschenverstand. Das wäre sozusagen meine Antwort darauf. Das ist ein gesunder Menschenverstand. Und insofern hoffe ich, dass ich deine Frage jetzt für dich zufriedenstellend beantwortet habe, auch wenn ich hier ein bisschen ausgewischt bin. Mhm.

Jan Fischbach

Ja, da hast du gut beantwortet. Bei Bundeswehr fällt mir immer gleich Auftragstaktik und Scharnhorst ein. Und man muss auch wissen, der Scharnhorst war irgendwie ganz fasziniert davon, dass die Franzosen damalsfreiwillig kämpfen für die Französische Republik und in Preußen können wir uns davon eine Scheibe abschneiden. Er hat dann die preußische Armee reformiert.

Und er sagte zu den Offizieren, er hat ein schönes Handbuch geschrieben, ich glaube schon 1700 irgendwas, ja ganz am Ende, 90 oder so, ein Handbuch für Offiziere. Und er hat dann so ein bisschen dargelegt, ja die meisten Leute wissen gar nicht mehr, was das bedeutet, Offizier zu sein, und das Geschehen auf dem Schlachtfeld kann man eigentlich nicht kontrollieren.

Er hat dann das Konzept der Auftragstaktik entwickelt oder „Führen mit Auftrag“ und Clausewitz hat das dann übernommen. Clausewitz  war eine große Inspiration für John Boyd und John Boyd war eine große Inspiration für Jeff Sutherland, der auch in militärische Offiziersausbildung hatte vorher. Von daher schließt sich schon der Kreis. Also die haben schon gesagt, die haben wirklich gesagt, sie referenzieren auch auf diese Leute.

Dierk

Ja, richtig. Und insofern, das ist eben dann für mich immer auch hilfreich für alle anderen in der Gruppe, in dem Training, wenn Teilnehmer selber sagen, hey, das, was du uns hier erzählt hast, das müssten wir eigentlich alle wissen und kennen, wenn wir diese Bücher eben lesen würden und verstehen würden. Und vor allen Dingen, wenn es eben so gelebt werden würde bei uns in der täglichen Ausbildung.

Da haben wir auch schon mal ein tolles Zitat. Die Bundeswehr ist agil. Zumindest wenn man auf die Bücher guckt.

Jan Fischbach

Na ja, es gab immer einen großen Kampf zwischen denen. Es war ein Widerstreit zwischen den sogenannten Normaltaktikern undden Auftragstaktikern. Scharnhorst ist ja schon früh gestorben. Der hatte so was wie so ein Barcamp ins Leben gerufen, die militärisch-politische Gesellschaft ist es, glaube ich.

Er hat dann alte und junge Offiziere zusammengebracht, die auch unterschiedliche Ideen hatten und die haben die dann diskutieren lassen. Das hat er ein paar Jahre durchgehalten. Auch dann ist das wieder wegen Krieg in Vergessenheit geraten.

Aber die Normaltaktiker haben gesagt: „Ja, das ist ja gut, wenn wir ein bisschen mehr Freiräumen geben Aber wir brauchen Regeln. Wir brauchen Workflows. Das muss abgegrenzt sein.“ Und Scharnhorst und seine Schüler sagten: „#das könnt ihr machen, aber in der Hitze des Gefechts würde das nicht funktionieren.“ Und erst in den Einigungskriegen Deutschlands, so 1870, war irgendwie klar, dass die Auftragstaktik besser funktioniert als die Normaltaktik. Erst da hatte sich das eigentlich entschieden. 60, 70 Jahre hat dieser Kampf gedauert.

Also wenn sich heute jemand wundert, warum wird Agilität nicht sofort angenommen, dann kann man die Geschichte gucken. Das ist halt kein Selbstgänger. Ja.

Dierk

Ja, ja. Wobei wir haben es nicht 60 Jahre Zeit, Jan. Wir haben nur drei Tage Zeit für das Training. Also jetzt Spaß beiseite. Jetzt können wir lange darüber plaudern. Das ist auch für die anderen interessant. Aber warum ist es denn wichtig, dass wir uns mit diesen Hintergründen beschäftigen? Warum ist das für dich wichtig?

Jan Fischbach

Also erstmal war es für mich ein ganz praktisches Problem. Ich will das Scrum so erklären, dass die Leute das besser verstehen und andocken können. In den  ersten Trainings, die wir gemacht haben, war immer Widerstand. Ja, da saßen die Leute dann so mit verschränkten Armen. Also für die Hörer, Dierk und ich, wir können uns sehen hier.

Ihr könnt uns leider nicht sehen. Aber die Kollegen saßen dann immer so mit verschreckten Armen: „Was soll denn das hier mit dem Scrum und wieso kann ich denn nicht so weiterarbeiten wie bisher?“ Und da hat man eine Front aufgemacht, die eigentlich sinnlos war für das Training. Und ich wollte irgendwie einen Einstieg finden, dass es leichtgängiger wird. Und wenn wir sagen, okay, guck mal, das gab es schon bei uns in der Kultur. Das ist jetzt nichts Neues, kein amerikanischer Import oder so. Unter dem Verdacht steht das ja immer. Sondern da gibt es hier eine kleine weltweite Community von progressiven Managern, würde ich das mal sagen, die empirisch arbeiten. Und wenn wir die Prinzipien dahinter verstehen und die Grundlagen, warum das sich so entwickelt hat, dann ist es für uns viel einfacher, wenn wir Dinge anpassen wollen.

Wenn wir uns die Situation angucken, wenn wir nur sagen, wir nehmen jetzt den Scrum Guide und kopieren das eins zu eins, das wird so nicht funktionieren. Aber wenn wir die Prinzipien dahinter verstehen, dann kann ich für meine Situation eine gute Lösung finden. Das muss ja nicht immer nach dem Scrum Guide gehen. Ich bin froh, dass wir den Scrum Guide haben und ich finde auch gut, dass im letzten Scrum Guide Update Jeff und Ken reingeschrieben haben: „Also wenn ihr Scrum macht, dann versucht so nah an diesen Scrum Guide auch zu kommen. Dann nützt es auch was, dann hilft es euch.“

Jeff sagt es auch: „Wir starten immer erst mal da, wo wir sind.“ Und wenn wir aber nicht verstehen, warum wir diese Dinge machen, dann wird das ein mechanisches Scrum, ein Zombies Scrum und das fühlt sich irgendwie schwierig an. Jeff sagt immer: „Good Scrum is fast, easy and fun.“ Und wenn das nicht fast, easy and fun ist, dann ist es nicht gut. Ja.

Dierk

Er erinnert mich an dieses Cheat-Sheet von Henrik Kniberg. Also wenn das Team Spaß hat, dann ist es gut. Und das trifft auch nicht jedermanns Meinung von Business. Also Arbeit und die Spaß macht, da geht ja gar nicht. Okay, gut. Ja.

Jan Fischbach

Ja. Ja, genau. Aber das hast du bestimmt auch in dem Ubongo Flow-Game überlebt. Ich frag immer: „In welcher Runde hattest du den meisten Spaß?“ Und die letzte Runde ist halt wirklich immer sehr chaotisch. Das sagen die dann immer: „Ja, also ich hatte den Eindruck, das ist chaotisch. Wenn ich jetzt die Zahlen nicht gesehen hätte, hätte ich gar nicht gedacht, dass wir so viel mehr schaffen.“ Und dann frag ich immer, wo wart ihr denn motivierter? Und dann sagen sie ja eigentlich in der letzten Runde, auch wenn es so chaotisch war.

Dierk

Ja, also wir wollen nicht zu viel spoilern an der Stelle, aber bei mir ist es häufig so, dass in der zweiten Runde, dass sie in der zweiten Runde schon merken, dass es mehr Spaß macht und dass sie in der ersten Runde häufig quasi schon die Regeln brechen wollen und das tun wollen, was man in der zweiten Runde macht. Also das finde ich immer auch das Schöne an diesem Spiel, wo ich dann sagen muss, nein, stopp, haltet euch an die Regeln. Ja, das ist doch blöd. Ja, das sollte er ja rausfinden. Aber gut, wie gesagt, wir wollen nicht allzu viel spoilern.

Jan Fischbach

Ja, genau.

Dierk

Also insofern, so geht es für mich auch. Und das werde ich jetzt wahrscheinlich auch in meinen Scrum Trainings aufnehmen, diese Historie. Ich gehe nur zurück bis zu Toyota TPS, um auch klarzumachen, dass man schon auch auf die Kultur achten muss. Und für mich ist es eben schon so wichtig herauszuarbeiten, dass Scrum schon, aus meiner Warnung heraus, vielleicht siehst du es anders, so ein bisschen amerikanische Kultur in sich trägt, zumindest so wie ich es verstehe. Und ich sehe schon,

Jan Fischbach

Oh, da kann ich dir eine schöne Geschichte gleich erzählen.

Dierk

Ja, gerne, gerne. Vielleicht lern ich da noch was dazu. Also insofern ist für mich aber wichtig, auszuarbeiten, dass Scrum sozusagen nicht irgendwo irgendwie entwickelt wurde, sondern dass Scrum eben selbst sagt, wir setzen auf Toyota auf, auf TPS und so weiter. Und dass man dabei auch beachten muss, dass da eben schon eine kulturelle Sicht auf die Arbeit beachtet werden muss. Und die ist in Japan anders als in Deutschland und in Amerika.

Jan Fischbach

Also die Ursprünge, gerade dieses Scientific Management, die lassen sich zurückverfolgen auf Wilhelm Wundt, der 1880 oder so, ich weiß gar nicht genau, in Leipzig das erste Labor für experimentelle Psychologie entwickelt hat.

Also man hat sich überlegt, das ist zu schwierig, man kann den Menschen nicht so in Formen oder Schemata pressen. Aber wir können einzelne Aspekte beobachten, also Handbewegungen, Augenbewegungen, Lesebewegungen und so weiter. Und der hatte in seinem Labor, das war sozusagen der heiße Scheiß damals, viele ausländische Studierende, unter anderem auch Amerikaner,

Der James McKeen Cattell war sein erster Assistent von Wilhelm Wundt und er ist zurückgegangen in die USA und hat dort die American Psychology Association gegründet, der auch viele andere Psychologen dann waren und die haben hinterher den Kern von Scientific Management aufgebaut. Also wie kann man Bewegungen in der Industrie untersuchen, so dass man weniger Ermüdungserscheinungen hat, dass man das leichtgängiger machen kann.

Also es gibt diesen Weg, Europa, USA. Dann hat sich aus dieser Scientific-Management -Bewegung ein Gruppe entwickelt, die dann die Ausbildung von Fachkräften organisiert hat. Erst im Ersten Weltkrieg und dann auch im Zweiten Weltkrieg. Sie haben sich dann ein Programm überlegt: „Wie bildet man Leute aus? Wie schafft man ein gutes Arbeitsklima? Wie verbessert man Dinge kontinuierlich.“ Das war ein entscheidender Punkt für den Materialüberschuss der Alliierten im Zweiten Weltkrieg.

Nach dem Zweiten Weltkrieg ist das von den USA nach Japan gegangen. Die Japaner haben es versucht anzupassen. Das hat nicht so funktioniert. Sie haben dann noch mal einen der Originaltrainer geholt vom TWI-Programm, so hieß das damals, Training Within Industry, haben es dann aufgesetzt, dann funktionierte es.

Toyota bildet zum Teil heute danach noch aus. Die Handbücher sind im Netz, die sind so gut, die funktionieren heute immer noch. Und dann gab es in den 80ern eine schöne Geschichte bei General Motors. General Motors schließt ein Automobilwerk, das als das schlimmste Automobilwerk in den USA bekannt wurde. Selbst die Gewerkschaft hat der Schließung zugestimmt.

Und GM hat aber gesagt, also wenn Toyota das mit uns nochmal aufmachen würden, dann würden wir nochmal investieren. Toyota hat gesagt, ja, ist für uns eine super Gelegenheit, auf den amerikanischen Markt zu kommen. Viele Lean-Leute, die wir heute kennen, waren damals so wie John Shook, waren Mittelmanager dort in diesem Werk.

Es gibt da eine schöne Szene, wo John Shook dann zusammen mit japanischen Kollegen kommt und sagt: „Ja, also diese strengen, rigiden Management-Methoden, die ihr hier so macht, das mag ja in Japan funktionieren. Das passt bestimmt super zu eurer Kultur. Aber wir hier in Amerika, wir sind anders. Wir müssen uns das anpassen.“

Und Isao Kato ging dann zum Bücherregal und zog das alte Job-Methods-Handbuch von 1944 aus dem Regal und sagte: „Hm, das ist gar nicht aus Japan. Das habt ihr uns nach dem Zweiten Weltkrieg beigebracht. Erst haben wir es angepasst. Da funktionierte es nicht. Und erst als wir es so gemacht haben, wie sie drin stand, da funktionierte es.“ Also es ist kein typisches japanisches Ding, sondern es ist ein amerikanisches Ding. Das haben die Amerikaner wohl vergessen.

So, und dieses TWI-Programm ist für mich immer auch eine Blaupause. Was macht denn Scrum Master eigentlich? Aber da kommen wir nachher noch mal drauf zu sprechen. Kultur spielt eine Rolle, aber speziell bei Toyota können wir nachweisen, dass Toyota das gelernt hat und konsequent umgesetzt hat. Da ist sicherlich viel besser als andere Firmen. Aber das ist jetzt nicht so, dass wir sagen können: „Das ist typisch japanisch oder typisch deutsch oder typisch amerikanisch.“

Dierk

Okay, also mein learning das, was du ja einen vorhin auch schon so gesagt hast, was ich jetzt so richtig verstanden habe. Ein Austausch auch über die Jahrhunderte jetzt im Wechsel, die über die Jahrhunderte hinweg der Austausch zwischen Menschen, die Dinge verbessern wollen, die Dinge anders angehen wollen und dass das eben etwas ist, was man lernen kann. Man muss es lernen wollen und konsequent umsetzen. Und dann hat es nichts mit japanischer, amerikanischer oder europäischer Kultur zu tun. Sehr schön.

Jan Fischbach

Da haben sich gegenseitig beeinflusst. Also, man wird da mal ein bisschen bescheiden, wenn man denkt, was wir heute alles mit Internet und so und Flugzeugen organisiert kriegen und weiß, dass man das vor 150 Jahren auch schon gut hingekriegt.

Dierk

ja ja ja man sollte bescheiden werden nicht alle werden dann bescheiden okay gut

Jan Fischbach

Ja, Bob Emiliani ist immer sehr kritisch mit den Lean-Leuten und sagt dann immer, ja, also wir müssen uns immer auch an die eigene Nase packen. Wir erzählen immer, wie toll Lean ist und wenn wir uns die Realität angucken, das geht für Agilität gleichermaßen, dann müssen wir uns auch schon daran messen lassen, ob sie erfolgreich umgesetzt wurde. Und das ist halt nur ein sehr kleiner Teil. Und Bob Emiliani sagt dann, vielleicht müssen wir uns davon verabschieden, dass ein einzelner Berater, eine Beraterin irgendwie jetzt hier die Welt aus den Fugen nimmt, hebt, sondern vielleicht brauchen wir eher einen hundertjährigen Plan, wie wir sozusagen von Generation zu Generation dieses wichtige Wissen weitergeben.

Was ich in dieser Geschichte halt sehr interessant fand, war, warum hat Japan das eigentlich gemacht? Die Japaner haben 1867 einen neuen Kaiser gekriegt, der hat das Land geöffnet oder war auch irgendwie ein bisschen gezwungen, das zu öffnen Er hat dann festgestellt, naja, in vielen Bereichen sind wir sehr hinter der Zeit und wenn wir uns jetzt nicht stark verändern, radikal verändern, dann werden wir hier kolonialisiert von anderen Mächten. Der Kaiserhof hat dann Berater rausgeschickt und auch Berater ins Land kommen lassen. und sie haben eine unglaubliche Aufholjagd gestartet und nach dem Zweiten Weltkrieg seit dieser Zeit gehört Japan eben auch zu G7. Also man sieht, dass dieses empirische Herangehen und dieses Wissbegierige, dieses Lernen, dass das eine ganze Generation, ein ganzes Land verändert hat. Oder wie das TWI-Programm in den USA auch dazu beigetragen hat, das Land zu verändern. Vor dem zweiten Weltkrieg hatten die Amerikaner, ich weiß nicht, 300, 400.000 Soldaten. Die Regierung war immer ein bisschen kritisch oder skeptisch. So eine Armee entwickelt immer auch ein Eigenleben und ist das unkontrollierbar und so waren sie erstmal dagegen. Nach dem Zweiten Weltkrieg haben die Amis eine Armee von 13 Millionen Soldaten gehabt und sind zur größten militärischen Macht aufgestiegen. Also wenn wir über Scrum reden, das sagt der Jeff auch immer, lass uns mal auf die höheren Ziele gucken. Was wollen wir denn eigentlich erreichen? Natürlich hilft Scrum einem Team vielleicht besser zu arbeiten. Aber wenn wir jetzt auf die Probleme gucken, die uns eigentlich bevorstehen, dann müssen auch unsere Ziele ganz andere Dinge sein. Wie gestalten wir eigentlich die Zukunft? Wie gehen wir mit der Energie um? Wie schaffen wir Frieden auf unserem Kontinent? Wie sorgen wir für ein gutes Auskommen für alle, dass auch der soziale Friede irgendwie gewährleistet wird? Da können wir ja auch im Kleinen dazu etwas beitragen. Das macht es für mich interessant, diesen Fokus aufzumachen und sagen, okay, das ist möglich, wenn wir alle zusammen was ausprobieren wollen. Und dem Kleinen bedeutet das dann wieder, morgen ist ja mein Daily.

Dierk

Ja, und ich weiß nicht, mir haben die Ohren geklingelt, als du gerade eben gesagt hast, dass der neue japanische Kaiser festgestellt hat, sie hinken hinterher, sie müssen mächtig was verändern, sie müssen mächtig aufholen und wenn nicht werden sie von anderen Ländern kolonialisiert, habe ich gedacht, ob das nicht jetzt auch gerade für Deutschland gilt. Aber das wäre vielleicht zu weit gedacht. Oder ist das auch das, was dich so ein bisschen damit antreibt?

Jan Fischbach

Ja, ich weiß nicht, die Verwaltung zum Beispiel steht unter Druck und viele Systeme sind abgeschottet. Wir schimpfen immer über die Bürokratie und die hinterherhinkende Digitalisierung. Ich weiß nicht, wenn da irgendwelche ausländischen Firmen um die Ecke kommen und sagen, wir haben die fertige Software, wir docken die mit unserer KI an und Bürgerrechte und Datenschutz bleiben da vielleicht auf der Strecke, dann betrifft uns das schon.

Wie viel Geduld haben wir da? Was wollen wir da experimentieren? Wenn wir uns aber gegenseitig helfen, so geht was.

Dierk

Ich habe ja eben gefragt, warum ist das wichtig, dass wir darüber sprechen? Das denke ich, haben wir jetzt erklärt, dass man zumindest, wenn man Scrum wirklich verstehen will, dass man dann sich über auch die Historie und all diese Dinge unterhalten muss, dass man da einsteigen muss. Jetzt gucken wir mal auf die Realität. Die Realität ist, dass wir seit einiger Zeit eine große Diskussion über den Nutzen von Scrum haben und von Agilität.

Das sieht man bei LinkedIn, das sieht man aber auch an anderen Stellen. Also Scrum hilft uns nicht, wie auch immer. Also insofern, es gibt eine große Diskussion. Und da war ich ein bisschen überrascht, dass du mir erzählt hast, viele Scrum Master werden gerade entlassen. Das heißt ja eigentlich, die Firmen zeigen damit, sie brauchen diese Menschen nicht mehr.

Jan Fischbach

Ja.

Dierk

Was bedeutet das jetzt für uns? Und auch da hast du einen Blogbeitrag geschrieben, der ist relativ aktuell aus diesem Jahr, der ist aus dem März. Also insofern, vielleicht können wir da noch ein bisschen darauf eingehen, was sind die aktuellen Probleme, die du so wahrnimmst, die ich so wahrnehme, wenn wir uns um Scrum und Agilität aktuell kümmern.

Jan Fischbach

Also erstmal betrifft mich das ganz banal oder unser Team als Trainer. Die Scrum-Welle ist durch. Die Leute kaufen nur noch selektiv Scrum-Trainings ein. Aber es ist jetzt nicht mehr so, dass wir jetzt hier Scrum-Trainings von der Stange ohne Ende verkaufen. Das heißt, das ist ein Hinweis. Entweder sind die durchagilisiert – nein sind sie nicht – oder die beschäftigen sich gerade mit anderen Themen. Es gibt halt so Wellen.

So und was wir jetzt halt sehen, viele Firmen, die halt eine agile Practice aufgebaut haben, da werden jetzt wirklich im großen Stil auch Leute gefeuert. Die überlegen sich, naja, wenn wir Leute entlassen, wen können wir entlassen? Die Entwickler können wir nicht entlassen, die produzieren die Software. Und die Projektleiter können wir auch nicht entlassen. Die haben halt die Kundenkontakte, die Menschen, die Projekte, die Scrum Master sind irgendwie dazwischen. Das fällt am wenigsten auf, wenn die nicht mehr da sind.

Das gilt aber im Prinzip auch für jede Mittelmanagementrolle, die sich immer fragen muss, was können Sie da irgendwie bewegen.

So, das bedeutet jetzt für uns, dass wir uns mal die Frage stellen müssen: „Welchen Wert liefert denn jetzt ein Scrum Master? Und wenn ich die Frage aufwerfe mit anderen Scrum Masters, dann gibt es sehr unterschiedliches Bild. Einige sagen: „Ich habe eigentlich noch nie Gedanken darüber gemacht.“ Einige sagen – ja, du hast es so schön gesagt, der Feel-Good-Manager: „Ja, mir reicht es, wenn ich ein paar bunte Retros moderiere, ein paar bunte Zettel an die Wand hänge und das Scrum ist hierarchiefreier Raum und wir müssen hier eine schöne Arbeitswelt gestalten.“ So wie ein Ponyhof, sage ich mal, das ist ganz despektierlich. Und da denke ich: „Naja, da muss man sich nicht wundern, wenn diese Rolle in Frage gestellt wird.“ Ich weiß nicht, kannst du das nachvollziehen? Kennst du durch die Erfahrung?

Dierk

Ich kann das absolut nachvollziehen, weil ich immer wieder erlebe, dass ich zu Teams komme, dass mir Menschen ihr Verständnis im Unternehmen von Scrum berichten, was da heißt, das Team entscheidet, was sie umsetzen.

Ja, und zwar sozusagen relativ frei. Also natürlich entscheidet das Team, was sie umsetzen, aber mit einer gewissen Vorgabe, mit einer sinnvollen Vorgabe, mit einem Blick auf Business, mit einem Blick auf Wert und so weiter. Aber es ist eben immer auch in diesem Jahr 2024 erlebe, dass mir Menschen erzählen, wir machen Scrum und das Team. Also mit das Team meinen sie die Entwickler. Die entscheiden doch, die gucken mich immer ganz groß an, die entscheiden doch, was sie umsetzen dürfen. Und das ist dann der Ponyhof, nur anders ausgedrückt.

Jan Fischbach

Dann muss man sich natürlich nicht wundern, wenn jemand diese Rolle in Frage stellt. Ich gebe den Scrum Master in meinen Trainings mit: „Passt mal auf, ihr seid eine Mittelmanager-Rolle.“ Was ich sehr schwierig finde, ist diese duale Hierarchie. Ein Team hat einen Scrum Master, einen PO, einen Teamleiter und einen Bereichsleiter. Ich plädiere davor, diese Rollen zu harmonisieren. Entweder einen Teamleiter oder einen Scrum Master, aber nicht beides.

Also, dass man das ein bisschen in Einklang bringt, weil das führt oft zu Verwirrung und diese Rolle des Scrum Master ist dann auch schwierig zu vermitteln. Also, wir tun jetzt mal so, als sei der Scrum Master ein Mittelmanager. Der erste Scrum Master, wenn man Jeff fragt, war ja auch der Teamleiter. Und das passt historisch auch gesehen zu dieser Rolle, der Teamleiter, der verantwortlich für das produktive Team ist. Und der muss sich fragen, das Team gibt ja eigentlich etwas von seinem Gehalt ab, um diesen Teamleiter zu finanzieren.

Die einzige Begründung, dass sie das tun können, sie können das Geld ja viel besser selber einstreichen. Die einzige Begründung ist doch, dass sie das gerne machen, wenn es mit Scrum Master besser ist als ohne Scrum Master. Das heißt, am Ende muss ich mich fragen, wenn mein Gehalt, sage ich mal, 50.000 ist als Scrum Master und ich aber 100.000 Euro einspiele oder 150.000 für das Team, dann ist das ein gutes Invest. Dann weiß ich, ich kriege mehr raus, als ich investiert habe. Scrum Master würden jetzt sagen: „Ich kann das gar nicht so an Zahlen festmachen oder das fällt mir auch schwer, das genau zu beschreiben.“ Das ist auch völlig in Ordnung. Was ich nur schwierig finde, ist, wenn wir diese Rechnung nicht machen für uns, selbst in Größenordnung, kommt halt jemand anders und was der rechnet, habe ich halt nicht unter Kontrolle.

Deswegen ist es viel besser, dass wir uns selber sagen, okay, woran würden wir eigentlich merken, dass es besser wird? Also sind Leute eingearbeitet? Sind meine Teams flexibel, weil ich Kopfmonopole entschärft habe, weil ich Wissen transferiert habe? Haben wir ein gutes Arbeitsklima, dass wir nicht ständig neue Leute suchen müssen? Und wird täglich was verbessert, sodass wir eigentlich mit den gleichen Leuten ohne mehr Stress mehr leisten können. Dann stimmt ja am Ende auch das Geld oder der Impact, den wir eigentlich erreichen wollen. Und dann ist die Rolle Scrum Master auch in Ordnung. Das heißt, ob einem das nun gefällt oder nicht, für diese Frage, was ist der Scrum Master wert, müssen die Scrum Master für sich eine Antwort finden. Aber das gilt natürlich für jede Führungsrolle in einem Unternehmen. Also das gilt für den Teamleiter, das gilt für den Bereichsleiter oder sonst irgendwelche Positionen in der Hierarchie. Sie müssen sich immer fragen, was ist mein Nutzen und wie komme ich an eine Antwort?

Und ist die Antwort eine andere als von denen, die über meine Position entscheiden? Und da müssen wir als Scrum-Community oder auch Lean-Community einerseits werben, dass diese Rolle etwas bringt. Aber wir müssen uns auch helfen, gegenseitig das zu beschreiben.

Dierk

Ja, und wir müssen ja dieser Werbung, müssen wir auch wirklich, wie du auch sagtest, wirklich Zahlen entgegenstellen oder beiseite stellen. Nicht entgegen, sondern beiseite stellen. Was ich interessant fand, war der Hinweis, dass der erste Scrum Master ein Abteilungsleiter war oder ein Teamleiter war. Ja, Teamleiter war. Das ist ja das, was wir heute eigentlich nicht wollen, wenn wir Scrum by the book machen.

Wo ich aber auch wiederum Firmen sehe, die genau diesen Schritt sozusagen rückwärts machen. Gar nicht mal abwertend gemeint. Die eben feststellen, bei uns passt das mit Scrum irgendwie nicht. Warum auch immer. Das lassen wir jetzt auch mal außen vor. Die aber dann sagen, wir führen wieder einen Teamleiter ein. Der soll aber bitteschön agil führen. Da kann man sich jetzt wieder streiten. Aber insofern, da finde ich einfach, dass für mich das Learning ist, aus dem, was du so erzählt hast, es muss dieser Beweis geführt werden, es muss dieser Nachweis geführt werden, insbesondere unter der Tatsache, und das sehe ich genauso, wie du es gesagt hast, für mich sind Scrum Master und auch Product Owner Führungskräfte. Moderne Führungskräfte, weil wenn ich das sage bei meinen Bundeswehr-Kollegen, dann gucken die mich erstmal wieder groß an und sagen, hä, Führungskräfte, wie soll das denn gehen?

Dann ist aber immer die Frage, was kann der Scrum Master wirklich bewegen? Also vielleicht können wir da noch mal ein bisschen drauf eingehen. Was kann der Scrum Master wirklich bewegen in modernen Organisationen?

Jan Fischbach

Ja, da gibt es einen Blogbeitrag von meinem Kollegen Wolf Steinbrecher, der mit mir im Common Sense Team Geschäftsführer ist.

Und er sagt, ist ja schön und gut mit der Lieferfähigkeit und mit den Zahlen, aber was kann denn ein Scrum Master wirklich bewegen? Was kann ein Teamleiter eigentlich bewegen? Also, wenn die Frage so formuliert wird: Was kann ein Teamleiter bewegen“, dann ist allen klar, naja, der wird jetzt nicht das Unternehmen komplett verändern. Das ist ja nur ein Teamleiter und kein Geschäftsführer oder Geschäftsführerin.

Und was lässt die Organisation auch zu? Es gibt ja Organisationen, die sagen, wir machen Scrum, aber das ist so fragmentiert. Da sind dann Leute nur zu 20% im Scrum-Team drin und die machen jeden Donnerstag ihr Daily oder Weekly oder so. Dieses fragmentierte Arbeiten  ist natürlich schwierig. Der Scrum Master muss sich jetzt hier nicht darum kümmern, dass die jetzt ihr Daily Scum machen, sondern eigentlich muss er natürlich da hinterher gehen und sagen: „eute, wir müssen auch noch mal darüber reden. Also nur ein Vollzeit Team, das konzentriert an Sachen arbeiten kann, kann auch ein gutes Scrum Team werden, wenn ihr die Arbeit so zersplittert, dann werdet ihr keine Ergebnisse bekommen.“ Und der Scrum Master muss sich dementsprechend auch das Mandat holen. Also wenn ihr als Scrum Master, als Scrum Masterin anfangt, ihr lieben Zuhörer, Zuhörerinnen da draußen, dann klärt doch bitte das Mandat und fragt nach, welche Erwartung ist denn an diese Rolle geknüpft. Und wenn die Erwartungen zu gering sind, dann solltet ihr diesen Job besser nicht machen.

Das ist dann einfach frustrierend. Aber wenn ihr als gutes Scrum Master handeln könnt, dann hat das natürlich Abstrahleffekte. Ich habe einen Kunden, das ist eine Bank, und da haben die im Jahresabschluss mit Scrum angefangen. Und die anderen, die da drumherumarbeiten, haben gesagt: „Da wird immer so viel gelacht. Das ist immer so lustig. Was machen die denn da?“ Dieses trockene Thema Jahresabschluss wird da agil bearbeitet.

Und das hat dann dazu geführt, dass auch an den Rest der Organisation die Frage gestellt wird: „Wie arbeiten wir eigentlich zusammen?“ Also dieses Vorbildsein, als vorbildliches Team arbeiten, das hat schon Effekt, aber wir müssen uns nichts vormachen. Es ist jetzt auch nicht so, dass der Scrum-Master der Ersatzgeschäftsführer ist. Das sollte er auch nicht sein. Ihr könnt halt durch gutes Vorbild führen, aber ihr solltet das Mandat klären.

Dierk

Und dieses Mandat dann auch beweisen oder nachweisen und immer wieder den Nachweis führen, was man tut und auch immer den Finger in die Wunden legen, wenn dieses Mandat auch nicht allen bekannt ist. Also wenn man Mandat bekommt, braucht man ja auch Unterstützung dabei bei der Umsetzung dieses Mandates.

Jan Fischbach

Ich weiß nicht, wenn du viele Offiziere trainierst, dann werden die sicherlich auch erzählen, wie die ihre Aufträge annehmen. Meine liebe Kollegin Nadja Böhlmann, die sagt immer: „Da ist ein richtiges Gespräch so. Und die sagen auch, wir gehen es hier nicht auseinander, bis das geklärt ist.“ Ich weiß nicht, was ist deine Erfahrung?

Dierk

Ich fange erst mal mit einem kleinen Spaß an sozusagen, der vielleicht dann so die Bundeswehrbehörden in ein schlechtes Licht rückt. Ich hoffe, das sei mir verziehen. Die erste Frage, die kommt, ist, bei den Behörden bin ich überhaupt zuständig?

Ja, das wird nicht eine gute Frage. Wenn ich mir die Frage selbst beantworten kann, dann spare ich erstmal viel Arbeit, wenn ich mich dafür nicht zuständig erkläre. Das hilft mir aber nicht. Also das war jetzt sozusagen der kleine Joke auf deine Antwort, auf seine Frage.

Die richtige Antwort sollte sein, dass sie das unterschiedlich wahrnehmen. Also es gibt Offiziere, die eben berichten, dass sie das so machen, wie wir es im Prinzip gerade gesagt haben. Es gibt ein Gespräch, man gibt wieder, wie man den Auftrag verstanden hat. Das ist ja das, wo du ja auch darauf hinauswillst.

Du hast das und das gesagt, ich habe das und das verstanden, haben wir das gleiche Verständnis. Und manche nehmen den Auftrag eben blind entgegen, blind oder stumm, wie man das in diesem Fall so sagt, und führen den Auftrag aus, weil sie das ja als wichtig empfinden. Sie haben den Eindruck, sie haben die Einschätzung, sie sind so auch vielleicht trainiert worden, dass sie den Auftrag ausführen, so wie sie ihn verstanden haben, ohne ihn zu hinterfragen.

Jan Fischbach

Und so werde ich das richtig verstanden. Also ich war nie bei der Bundeswehr, deswegen. Ich habe auch keine Offiziersausbildung. Deswegen kann ich da nicht qualifiziert was zu sagen. Was ich mitgenommen habe, ist, dass gute Offiziere eben auch gucken, hat der Befehlsempfänger  das jetzt verstanden oder muss ich da nochmal nachhaken? Also die delegieren das jetzt nicht blind weg.

Die achten aufeinander und die helfen sich. Die wissen auch, ich kann nämlich jetzt nicht rausreden: „ich habe dem das gesagt oder so.“ Also wenn das eine wichtige Operation ist, dann können die sich nicht rausreden und hinterher sagen: Er hat das halt doof gemacht oder so.“ Sondern die haben auch selbst ein Interesse, dass genau diese Delegation, Auftragserklärung, Auftragsannahme und so, dass es auch gut läuft.

Und so einen Dialog wünsche ich mir eben auch dann den Unternehmen, dass die Geschäftsführung die Scrum Master vernünftig mandatiert. Und wenn Sie den Eindruck hatten, dass Sie das nicht verstanden haben, dass Sie auch noch mal nachhakt und das umgekehrt, die Scrum Master auch nicht blind jeden Auftrag annehmen, sondern auch mal horchen, was da so gebraucht wird.

Dierk

und dass sie sich ihr Mandat abholen. Das ist vielleicht so eine Art Zusammenfassung, dass sie sich ihr Mandat abholen, um eben dafür sorgen zu können, dass sie Dinge bewegen oder bewegen dürfen, dass sie den Auftrag haben, das zu tun. Vielleicht du sagst ja, du warst nicht bei der Bundeswehr. Ich war bei der Bundeswehr. Ich habe es nur bis zum Gefreiten gebracht. Also Offizier war mir auch verwehrt. Da war ich wahrscheinlich damals schon zu freiheitsliebend oder wie auch immer. Aber was wir damals hatten, es gibt da so ein Thema Stubendurchgang. Also wir mussten unsere Stube selber reinigen. Wir waren drei Gruppen in diesem Zug und ich war in der Gruppe mit dem jüngsten und nettesten Unteroffizier. Und der hat uns, im heutigen sich würde man sagen, der hat uns wertgeschätzt.

Der hat die Zügel etwas schleifen lassen, aber er hat uns motiviert, sozusagen seine Aufgabe zu verstehen. Und unseres war zwar die sauberste Stube. Beim Stubendurchgang hatte Oberfeldwebel die anderen beiden Stuben, wo richtig harte Knechte noch dabei waren.

Die hat er auseinandergenommen, weil die eben nur auf Auftrag hin sauber gemacht haben. Und wir haben bei uns gereinigt, weil wir gesagt haben, es gibt einen Stubendurchgang. Wir wollen unseren Unteroffizier nicht hängen lassen. Also wir haben quasi für uns und für ihn gereinigt und haben ein besseres Ergebnis erzählt.

Jan Fischbach

Wenn man diesen Sinn der Arbeit dahinter versteht, dann sieht man ja auch selber mehr. Wir haben zwei schöne Beispiele über Agilität in der Verwaltung. Das ist einmal der Bauhof in Herrenberg oder die kommunalen Servicebetriebe in Tübingen, die dann mit mehr Agilität experimentiert haben. Und der Effekt war, dass die Leute einfach mehr Verantwortung übernommen haben von sich aus. Also da war zum Beispiel eine Truppe, die ist nur für das Leeren der Mülleimer zuständig, die andere sind für den Zustand der Parkbänke und der Dritte für den Grünschnitt.

So, und dann haben die das in Bezirke eingeteilt und dann haben die festgestellt: „Wenn ich da jetzt den Grünschnitt mache, dann kann ich ja den Müll auch mitnehmen.“ Also das große Ganze sehen und dann immer sagen: „Wie will ich denn mithelfen?“ Das auch diskutieren zu dürfen oder auch einfach mal ansprechen dürfen, das ,finde ich, macht den Mehrwert hier von Agilität aus.

Dierk

Ja. Ja, ja. Ein Thema werde ich mit dir auch noch besprechen. Auch das hast du in diesem Jahr schon mal behandelt. Und ich wollte dich mal fragen, wie denkst du über Agile Coaches?

Jan Fischbach

Ah, ein schönes Thema. Da kannst du mich wahrscheinlich manchmal mit jagen. Meine Kollegin Maria Kühn ist bei mir im Team, die sich sehr viel Mühe gibt bei dem Thema systemische Organisationsentwicklung, die es sehr gut macht. Und wir sind aneinander geraten. Da habe ich gesagt: „Halt mir die vom Leib. Die reden nur. Die ändern ja nichts.“

Also meine Frau ist Sozialarbeiterin, Sozialpädagogin. Ich weiß, dass Familienaufstellung und solche Dinge, dass das funktioniert; und dass zum Beispiel bei Suchterkrankungen ein systemischer Ansatz viel besser zum Ziel führt, als wenn man eine Person, die halt polytoxisch ist, wenn man die nur zwei Wochen zur Entgiftung dann zur Therapie schickt. Wenn die dann zurückkommt in ihr krankes Umfeld, wird sie genau so weiterhin Substanzen missbrauchen. Das ist mir schon klar, dass es so funktioniert.

So, vom Begriff her, „Agile Coach“ muss man noch einmal zurückgehen. Agile Coach war eigentlich nur eine andere Bezeichnung für Scrum Master. Also die Teams, die nicht Scrum gemacht haben, haben trotzdem so eine Coach-Rolle gehabt, so eine Teamleiter-Rolle, und die haben in dem Zusammenhang Agile Coach genannt.

Heute ist das Industrieverständnis oft anders. Das heißt, der Agile Coach ist sozusagen der Scrum Master XXL oder der Scrum Master++, der verbesserte Scrum Master, der noch mehr zu sagen hat. Das finde ich einerseits kritisch. Die Scrum.org sagt zum Beispiel 100% Scrum Master und will sich bewusst abgrenzen von der Rolle Agile Coach. Die Scrum Master sind genauso dafür zuständig, Scrum in der Organisation zu fördern.

Und es gibt einige Agile Coaches, die von sich aus sagen: „Ich will eigentlich dieses große Scrum-Verständnis gar nicht haben, ich habe eine systemische Ausbildung.“ Und sie ändern aber nichts an den Strukturen. Und ich habe mich immer gewundert, wo kommt das her? Die sagen, wir müssen Konfliktmanagement machen oder solche Dinge.

Und man guckt auf diese Struktur und denkt: „Na ja, vielleicht schaffen wir einfach mal die Ursachen ab für diese Konflikte. Dann brauchen wir auch kein Pflaster drauf zu kleben.“ Und das vermisse ich doch bei einigen Agile Coaches, dass sie Verantwortung für die Strukturen übernehmen. Natürlich, irgendwann ist ein Punkt, wo ich vielleicht auch mal über Gefühle oder Selbstverständnis und auch psychologische Sicherheit reden muss. Das ist auch wichtig. Aber das heißt nicht, dass man an die Struktur nichts ändern soll. Und ich habe ein bisschen hinterher geforscht.

Und ich habe einen schönen Beitrag gefunden, der auf einen alten Streit referenziert aus den 50er Jahren zwischen den Leuten, den Scientific Management Leuten, also den Taylor Leuten und den Human-Relations-Leuten um Elton Mayo.

Ich muss ein bisschen ausholen, um das besser zu verstehen. Aber die Auswirkungen sind so, dass wir heute immer noch drunter leiden. Deswegen müssen wir das einmal erklären. Der Taylor selber hat zum Beispiel gesagt, die Arbeiter dürfen streiken, wenn die Arbeitsbedingungen nicht in Ordnung sind. Der Taylor wird immer sehr negativ dargestellt in der agilen Szene. Ich denke, wir müssen unser Verständnis von Taylor revidieren hier.

Also ich sage nicht, dass es ein einfacher Mensch war, aber so wie er dargestellt wird, passt das, glaube ich, nicht. Und wir haben aus agiler Sicht einiges dem  Taylor zu verdanken. Und der Taylor und die Scientific Management Leute, die Community, mit denen er zusammengearbeitet hat, haben immer auf die Strukturen geguckt.

Also wie organisieren wir den Betrieb so, dass die Arbeit gut funktioniert, dass das Arbeit fließt, dass die Leute auch die Arbeiter davon was haben? Der Taylor sagt immer, die Arbeiter müssen auch von profitieren, wenn sie besser arbeiten. Wir wollen die beteiligen durch bessere Leistungsanreize. Und damit es aber funktioniert, müssen wir die Grundlagen auch ändern. Also er sagte, das ist jetzt nicht, dass man so ein paar Sachen einführt, dann hat sich das schon getan, sondern wir müssen das ganze System der Zusammenarbeit ändern. Daher sprachen wir von einer mentalen Revolution.

Scientific-Management-Leute, die haben dann auch in der Roosevelt-Administration sehr, also in den 30er Jahren, auch sehr gut mit der Verwaltung dort gearbeitet und Roosevelt hat viel für die Arbeitnehmer getan. Da waren auch Gewerkschafter, der Sidney Hillman, der war in der Regierung irgendwie beteiligt, hat viel für die Arbeitnehmer getan. Das waren deutliche Verbesserungen für die Arbeitnehmerschaft.

Das fanden die Arbeitgeber jetzt aber nicht so richtig lustig. Nach dem Zweiten Weltkrieg haben sie versucht, das Rad zurückzudrehen. Aber sie konnten natürlich nicht einfach stumpf ganz banal das Rad zurückdrehen. Sie mussten sich jetzt was überlegen, wie sie das den Arbeitern schmackhaft machen. Und da kam mal diese Human Relations Theorie vom Elton Mayo und den Leuten, die da drumherum waren, kam denen ganz gelegen. Und die sagen: „Man muss auch auf die Psychologie der Mitarbeiter achten. Und man muss auch mal hier eine Pflanze hinstellen und mal ein bisschen Licht auch machen und mal fragen, wie es denen geht.“ Das ist ja per se nicht falsch. Nur die Taktik dahinter war bewusst, das kann man auch nachlesen, war natürlich schon so, dass man die Arbeiterschaft ein bisschen vereinzeln wollte und dass die sich nicht zusammenrotten und irgendwie für bessere Arbeitsbedingungen sich einstellen, sondern dass man die vereinzelt und an den grundsätzlichen Strukturen nichts mehr ändert. Die Unternehmer wollten ihre Fabrik zurückhaben. Das war das Motto dahinter.

Die Scientific Management Leute haben die Mayo-Leute nicht ernst genommen. Es gibt ein Buch, wo Mayo ein Vorwort schreibt über die Psychologie. Und die Taylor-Leute haben gesagt: „Das ist jetzt aber auch nicht wirklich revolutionär, was ihr da schreibt über die Hawthorne-Experimente, das wussten wir heute auch schon.“ Mayo hat sich total darüber aufgeregt und gesagt, die sind verrückt.

Er hatte aber erstmal keine Chance, weil aus Sicht der Militärs zum Beispiel hat ja Scientific Management geliefert. Die Militärs haben ja die Waffen gekriegt oder die Fahrzeuge, die sie brauchten, um den Zweiten Weltkrieg zu gewinnen. Nach dem Zweiten Weltkrieg war der Krieg gewonnen für die Alliierten, für die Amerikaner, die hatten neue Positionen. Das heißt, die unmittelbare Notwendigkeit mehr zu produzieren war erstmal weg.

So, und in diese Lücke kann jetzt Mayo stoßen und stellt sich auf einmal als der großer Versteher der Arbeiterschaft dar und sagt hier: „Wir haben eine ganz neue PsychologieDie alten Zeiten müssen wir uns hinter uns lassen und dieses tayloristische Zerlegen der Aufgaben, das haben wir doch hinter uns.

Und aus dieser Tradition kommen jetzt die Human-Relations-Leute. Ich stelle es jetzt ein bisschen polemisch da, ich will den Leuten da nicht zu nahetreten. Aus dieser Tradition kommen wir da eben und das führt eben dazu, dass man an die Strukturen selber nicht rangeht. Und das ist aus meiner Sicht ein großer Fehler. Das heißt, wenn heute jemand Agile Coach sagt und „Ich bin systemisch“

Also ein Systemiker, der nicht an die Systeme rangeht, das widerspricht sich aus meiner Sicht. Die müssen an die Systeme rangehen. Und das sehe ich bei einigen Agile Coaches nicht. Da sage ich, dann macht ihr euch das Leben ein bisschen zu einfach. Da ist ja immer so eine Attitüde, auch den anderen zu erklären, dass sie eigentlich bestimmte Dinge nicht verstehen, dass die Führungskraft nie eine gute Führungskraft ist, dass der Mitarbeiter nie ein guter Mitarbeiter ist. Du hast immer das Gefühl, du bist nicht gut genug.

Und aus einer empirischen Sicht oder auch aus einer Scrum-Sicht, da sagen wir: „Wir wissen nicht eigentlich gesagt gar nicht, was gut ist. Aber wir wissen, ob wir das messen können. So und mess doch bitte mal selbst.“ Macht doch das jetzt nicht etwas, weil das so im Scrum Guide steht. Tut was, messt, guckt euch die Ergebnisse an, vergleicht. Wenn das gut war, macht weiter. Wenn die Ergebnisse in die richtige Richtung zeigen. Wenn sich die Ergebnisse nicht bestätigen, die Zahlen, dann macht was anderes. Auf einer anderen Basis gehen die miteinander um.

Dierk

Empirische Prozesssteuerung.

Jan Fischbach

Genau. Su siehst das im Ubongo Flow Game. Ich sag immer am Ende einer Runde: „Mit Blick auf die Zahlen, besser oder schlechter?“ Also die denken, das ist eine rhetorische Frage. Aber ich sag immer: „Nein, guck mal hier. Agilität heißt nicht, wir kopieren den Scrum Guide. Agilität heißt:  ich mach was, ich messe und mach wieder was. Und deswegen mit Blick auf die Daten, besser oder schlechter.

So, das war sicherlich auch so eine Geschichte, wo die Leute vielleicht dachten: „Naja, eigentlich hätte ich nicht gedacht, dass es besser wird. Aber wenn ich mir jetzt die Zahlen angucke…“

Dierk

Ja, ich würde auf diese Frage gehe ich auch noch mal gleich ein, wenn ich noch mal aus dem Ubongo Flow Game berichte, aus meinen Spielerlebnissen. Ich würde noch mal auf das eingehen, auch vielleicht noch ein bisschen mit meinen Worten zusammenfassen, was du über den Agile Coach gesagt hast. Und das, was du berichtet hast, da würde ich auch sagen, wenn ein Agile Coach die Strukturen nicht ändert, also wenn er nicht wirklich aktiv etwas an den Strukturen verändern möchte, wenn das nicht er seinen Auftrag sieht, dann ist er so ein zahnloser Scrum Master 2.0, also dann würde ich auch sagen, weil ich nämlich einen Unterschied sehe zwischen Agile Coach und Scrum Master, nicht in der Wertigkeit und auch nicht in einer ich sag mal hier reichigen Stellung oder wie auch immer, ich sehe einen Agile Coach, eigentlich als jemand, der von außen kommt. Also ich sehe den Mehrwert, den ich mitbringe. Also ich bin ja als Agile Coach aktiv. Ich komme von außen. Das heißt nicht, dass ich besser bin. Das heißt sogar manchmal, dass die Scrum Master quasi mehr internes Wissen haben. Aber ich kann von außen eben Impulse setzen und sehe mich als jemand, der nur ganz, ganz kurz quasi reinpiekt. Also Business Akupunktur, der von außen, also externes Wissen, eine externe Sicht mitbringt. Das ist meine Abgrenzung als Agile Coach. Also nicht, dass ich was besseres bin, sondern im Gegenteil, viele Scrum Master erlebe ich auch, was du vorhin auch sagtest, die leiden, zumindest wenn ich so an zwei, wo vor zwei, drei, vier, fünf Jahren zurückdenke, viele Scrum Master erlebt, die darunter gelitten haben, dass sie nichts verändern konnten, dass sie nicht etwas bewegen konnten und dass sie es aber gerne wollten. Also für die Menschen, fürs Unternehmen, die haben die Probleme gesehen, aber man hat sie nicht verändern lassen wollen. Also das auch als meine Ergänzung dazu.

Ja, und bei dem Ubongo Flow Game von den einzelnen Runden erlebe ich immer mehr, dass die Teilnehmenden sagen wir ruhiger werden. Also die werden ruhiger und man merkt, man hört quasi, weil es ruhiger wird, man hört, dass bei denen der Groschen fällt, dass sie eben Dinge verstehen. Und gerade wenn ich frage, was habt ihr denn erlebt? Also sonst gibt es ja eine Folie mit der Zusammenfassung, die gibt es ja nicht. Ich sage, was habt ihr erlebt?

Und dann gibt es genug Fragen, um nachzufragen, was war denn anders. Und die Zahlen, ich habe noch nicht einmal erlebt, dass die Runde zwei oder drei schlechter war als die vorherige. Das wäre ja noch mal ein Ergebnis. Ich sage auch immer wieder, es ist nicht das Ziel, euch nachzuweisen, dass das jetzt hier besser ist als das andere. Ihr sollt es selber erleben. Wenn ihr selber draufkommt, ist das ja okay. Aber auch da würde ich sagen,

Man merkt ja auch, welche Voraussetzungen dafür da sind. Du kannst ja nicht einfach schnipsen und sagen, ha, jetzt machen wir bei uns im Unternehmen Runde drei sozusagen von jetzt auf gleich. Also die merken ja auch, welche Voraussetzungen dafür entsprechend gegeben sind.

Jetzt haben wir über so viele Sachen gesprochen es hat sich für mich bewahrheitet dass ich mich auf diese Folge gefreut habe auf das was du so rüberbringst auf das was ich auch alles in den Show Notes an links weitergeben kann es gibt sicherlich ein Link der auf dein Blog allgemein verlinkt wird aber auch sicherlich Links auf die einzelnen Artikel auf die einzelnen zugrunde liegenden Artikel geben. Ich habe ja auch immer wieder darauf hingewiesen, wenn du was dazu geschrieben hast. Zum Abschluss von so einer Folge gebe ich meinen Gästen immer die Möglichkeit, nochmal so ein Schlusswort zu sprechen. Also irgendwas zusammenzufassen oder irgendwas zu sagen, was bis jetzt im Rahmen dieser Fragestunde, im Rahmen dieses Gesprächs, darüber gekommen ist, ob da irgendwas vergessen wurde. Also möchtest du noch irgendwas zum Abschluss den Hörenden mitgeben?

Jan Fischbach

Ich möchte diejenigen, die jetzt hier zuhören, ermuntern, mehr Agilität oder was hinter dieser Fassade von Agilität da steckt, auszuprobieren, im Sinne eines großen Ganzen. Ihr seht vielleicht nicht den Bereich, wo ihr wirklich. Vielleicht habt ihr den Eindruck, ihr könnt gar nichts bewegen. Aber im Kleinen bewegt ihr eben doch was. Und ich bin sehr stark von Jeff Sutherland inspiriert, weil ich auch viel mit ihm geredet habe und so.

Und dieses große Ganze dahinter zu sehen, was wir eigentlich bewegen, das sollte man sich immer wieder bewusst machen, worum es hier geht. Wir sind ein Teil von dieser agilen Bewegung, die weltweit vernetzt ist, wo sehr viele, tolle Menschen unterwegs sind, die sich austauschen.

Die sollten vielleicht sich noch mal daran erinnern, dass wir hier einiges gemeinsam bewegen können und dass wir uns gegenseitig helfen können. Die Leute, die jetzt anfangen, die sollen den Mut nicht verlieren und die Leute, die vielleicht jetzt den Zenit ihrer Karriere überschritten haben, da hoffe ich, dass die mithelfen, die nächste Generation der Führungskräfte oder agilen Leute auch auszubilden, dass man jetzt vielleicht einen Schritt zurück tritt und sagt: „Wie kann ich denen helfen, dass wir gemeinsam wieder eine gute Generation an agilen Führungskräften, agilen Coaches, an agilen Scrum Mastern, Teamleitern, an agilen Teams, dass wir die ausbilden, dass sie bereitstehen, dass wir wieder helfen können.“ In Deutschland passiert gerade ganz viel, die Industrien verändern sich.

Das hat auch viel mit Unsicherheit zu tun. Man weiß jetzt nicht so, wie man das machen kann. Und da können wir ganz toll anpacken und einem Unternehmen in der Region helfen oder einer bestimmten Branche helfen.

Das steht alles ein bisschen unserer Macht. Wenn wir uns da gegenseitig helfen, können wir doch uns einiges bewegen. So und ihr könnt euch diese Hilfe und das Schulterklopfen und das Bestärken holen, indem ihr einfach zu agilen Treffen geht oder auch zu Lean-Treffen. Es gibt die Leanbase, die eine große Vernetzungsplattform ist, die der Ralf Volkmer und seinen Kollegen von der Lean Knowledge Base betreibt. Da kann man sich austauschen. Es gibt die Lean Around the Clock, wo man sich treffen kann. Es gibt viele lokale Treffen, wo man sich austauschen kann. Nutzt das, um euch Rückenwind zu holen, damit es euch gut geht. Sorgt erstmal, wie beim Flugzeug, erstmal die eigene Maske aufsetzen, bevor man den Mitfliegenden hilft. Sorgt ein bisschen dafür, dass es euch gut geht und dann strebt wirklich Spitzenleistung an und helft euch damit. Ich habe auch ein Team, mit dem es total viel Spaß macht, mit meinen Leuten. Mein Bruder, mit meiner Schwägerin sind im Team,  Peter und Alisa, mit denen macht das Spaß. Ich habe ganz viele andere Leute, mit denen ich gerne zusammenarbeite. Die geben mir die Kraft. Und ich hoffe, dass ihr ganz viele Leute habt, die euch auch Kraft geben, damit wir das, was eigentlich jetzt ansteht, gut bewältigen können. Bitte darum.

Dierk

Sehr schön. Das sollte ja dein Schlusswort sein. Aber jetzt hast du ein paar Punkte gesagt, wo ich gerne nochmal Dinge ergänzen würde. Also vielleicht kriegst du nochmal die Chance für ein Schlusswort, damit du das letzte Schlusswort hast. Aber du hast von Rückenwind gesprochen. Ich würde auch von Rückendeckung sprechen, weil ich an vielen Stellen junge Scrum Master oder Scrum Masterinnen erlebe. Die kommen von der Uni teilweise. Die werden dann auch ins kalte Wasser geworfen. Sie kriegen wenig Rückenwind/-deckung, also insofern holt euch dieses Mandat, da haben wir vorhin von gesprochen, holt euch die Rückendeckung und holt euch auch Unterstützung. Und das hast du ja eben gerade gesagt. Sprecht, also dass man sich auch, dass man auf diese Treffen geht, dass man das auch online nutzen kann, finde ich einen ganz wichtigen Hinweis. Das unterscheidet aus meiner Sicht auch die agile Community von meinen eigentlich anderer Community, dass diese Agile Community da wirklich so gepolt ist und so aufgestellt ist, dass sie sich eben austauschen, dass man Wissen gibt und Wissen auch wieder aufnimmt von anderen und dass man eben sich dieses Wissen, diese Erfahrung holt, um einen besseren Job zu machen, wie du auch gerade gesagt hast, denn der Titel lautet ja, Agilität ist tot, lang lebe Agilität, dass wir eben genau jetzt sozusagen so eine Art Turnaround vielleicht schaffen, wenn ich mal so ein anderes Wort nehme und zu sagen, okay, wir gehen zurück zu den Wurzeln, heißt aber, wie gesagt, Rückendeckung holen, Mandat holen, sich, gerade wenn man noch nicht so viel Erfahrung hat, diese Erfahrung auch holen, weil Erfahrung ist was ganz Wichtiges. Du hast ja vorhin gesagt, Product Owner ist eigentlich der Chefkonstrukteur.

Ich würde also persönlich auch sagen, jemand der viel Lebenserfahrung hat, der viel Berufserfahrung hat, der ist auch oder der hat auch gute Voraussetzungen für Scrum Master.

Jan Fischbach

Von wem lasst ihr euch unangenehme Fragen gefallen, ohne gleich eingeschnappt zu sein? Das ist ein guter Kandidat für die Position Scrum Master. Das hilft euch, die natürliche Autorität.

Dierk

Ja, die natürliche Autorität, richtig. Okay, Jan, vielen, vielen Dank auch für die kleinen Geschichten und das Ubongo Flow Game herum. Das, glaube ich, hat uns auch so ein bisschen durch dieses Gespräch getragen. Und vielleicht haben wir ja den ein oder anderen unter den Zuhörenden, der jetzt Bock hat, dieses Spiel mal auszuprobieren. Wie gesagt, es ist sehr gut beschrieben. Der Link kommt damit rein. Und wenn jemand sagt, nee, ich brauche jemand, der das mit mir spielt, ich glaube, Jan und ich sind käuflich. Also insofern gerne auch und der Rest kommt auch in die Show Notes. Vielen Dank Jan für deine Zeit und ich würde sagen, bis irgendwann mal vielleicht wirklich in leibhaftiger Person schauen wir mal, ob wir das irgendwann mal hinkriegen. Bis dahin erstmal vielen Dank von mir. Danke, tschüss Jan.

Jan Fischbach

Danke für die Einladung und dir einen schönen Tag. Tschüss.

Logo Dierk Söllner