Transkript
Matthias: [00:00:02.55] Grüße ich Das sind wir wieder, der Matthias
Alex: [00:00:05.01] Und der Alex mit einer neue Folge der „Macht der Craft“
Matthias: [00:00:08.61] Agile und agile Softwareentwicklung sind seit einigen Jahren in aller Munde. Du hast wahrscheinlich auch schon dafür gehört oder arbeitest vielleicht sogar agil.
Alex: [00:00:16.74] Heute hörst du einiges über Agilität in die Softwareentwicklung und woher das kommt und was sie bezweckt.
Matthias: [00:00:23.04] Etwas, was man immer wieder hört, ist, dass agil dogmatisch sei.
Alex: [00:00:27.54] Ist das tatsächlich so? Oder vielleicht auch nicht nur fast heute unsere Meinung dazu?
Matthias: [00:00:33.06] Und kannst du natürlich auch deine eigene bilden. Du wirst außerdem erfahren, was „Shu-Ha-Ri“ ist und was es damit zu tun hat.
Alex: [00:00:39.57] Lass uns anfangen.
off: [00:00:42.86] Die Macht der Craft arbeitet für dich.
Alex: [00:00:49.24] So als erstes würde ich mal kurz zum Thema „Was ist eigentlich agil und das agile Manifesto um die agile Prinzipien“ mal eingehen? Wo kommen diese Agil und diese agile Manifesto her? Haben sich Anfang 2001 glaube ich, wars einige Leute mit Softwareentwicklung zu tun hatten zusammengetroffen und darüber geredet. Wie könnte man die Probleme so was deren Meinung war, wie man die Probleme, die sie in der Softwareentwicklung in jener Zeit gab, mal einfach so wegzuräumen oder einfach zu minimieren. Ja, da waren Leute, die seit vielen, vielen Jahren entwickelt und mit Softwareentwicklung zu tun hatten. Und dabei ist diese Manifesto für agile Softwareentwicklung entstanden. Um was meiner Meinung nach da drin steckt, ist nicht, wie wir zu arbeiten haben, sondern auf was wir Wert legen sollen. Bei der Arbeit. Die plädieren zum Beispiel für ein interaktives Vorgehen der Entwickelung wo man – heißt nicht man muss vorher nicht planen, aber man muss nicht alles von vornherein planen, weil es wird sich Änderungen ergeben, während man arbeitet. Wir wissen zu der Zeit, wo wir anfangen, auch nicht alles, was wir brauchen oder brauchen werden. Deswegen planen ja, aber nur so viel, wie wir brauchen, um anfangen zu können. Und da sind viele andere Ideen, sind da in diese agile Manifesto und diese agile Prinzipien alles mit einbezogen und mit formuliert. Also was meiner Meinung nach dieses agile Bewegung, diese agile Manifesto, diese agile Prinzipien, nenn ma wie man es will. Die reden darüber, über eine Geisteshaltung, wie wir die Arbeit empfinden und auf was wir bei der Arbeit achten sollen, womit wir uns mehr oder weniger beschäftigen sollen während der Arbeit, um was für mich ganz wichtig ist. Und diese ganzen Dokumente und Ideen und Mindset Geschichten steht nirgendwo, wie es zu tun ist, wie es gemacht werden soll, sondern einfach nur wie diese Mindset zusammengestellt ist. Was da wichtige Sachen sind, immer mit dem Vermerk Diese Sachen sind wichtig, aber das bedeutet nicht, dass die anderen Sachen, die wir vorher gemacht haben, gar nicht mehr wichtig sind, sondern die haben auch seine Daseinsberechtigung. Nur in einem ganz anderen Maße eventuell. Also noch mal für mich ist das Thema Agil und agile Manifest und Prinzipien und was auch immer eine Sache des Mindset bilden. Es geht darum, den Menschen eine Art und Weise, wie man entwickeln kann, näher zu bringen und dass sie diese Modell, nennen wir es einfach mal, verwenden können, um die tägliche Arbeit zu lösen. Das wäre für mich das, was mit agil zu tun hat, was wirklich Agilität bedeutet. Ne, des sind diese Grundsatz an Ideen. Man redet auch die ganze Zeit und ich wiederhole mich auch gerne Mindset, wie man entwickeln kann. Und wie gesagt keine Regeln. Es wird nur gesagt, was auf was man Gewicht legen sollte und nicht wie. Aber auch ganz wichtig für mich ist Wie kommt man als Team zu Agilität? Matthias könnte uns und uns mal erzählen, wie es in deinem Fall war oder in deinem Team. Wie ist es dazu gekommen, dass Sie das ihr, diese diese Agilität eingenommen habt und agil arbeiten wolltet?
Matthias: [00:04:29.14] Kann ich gerne machen. Also ich habe ja in einer der letzten Folgen so ein bisschen auch aus meiner Vergangenheit schon erzählt, wie sich so über die Jahre meine Arbeitsweise verändert hat. Aber ich bin da natürlich nie auf die Details eingegangen, wqann oder wo hätten wir jetzt agil gearbeitet oder sonst irgendwas? Und deswegen kann ich das jetzt gern nachholen. Und dass es dann tatsächlich so, als wenn man sich zurückerinnert, relativ kleine Firma, die relativ schnell gewachsen ist und über einen relativ kurzen Zeitraum relativ viele neue Teammitglieder bekommen hat. Und auch da war dann natürlich irgendwann die Notwendigkeit, dass man nicht mehr so chaotisch arbeitet wie am Anfang. Also da war es noch legitim, dass man jeden Tag mit seinem Kollegen, weil ich hatte nur einen oder zwei die meiste Zeit am Anfang einfach mal abspricht, was man an heute eben macht und was gemacht werden muss. Aber dass je mehr Leute es werden, desto unpraktikabel wird so was natürlich. Und da haben wir uns natürlich überlegt, was kann man machen? Und unser Chef hat quasi Scrum für sich entdeckt. Und dann haben wir eben im Prinzip angefangen in einer gewissen Zeit. Ich glaube, da waren wir dann zu 5-6 Leute, haben wir dann mit Scrum angefangen.
Alex: [00:05:51.98] Na ja, also was ich öfters gesehen habe ist, dass agil, wie du gesagt hast, von irgendjemand entdeckt wird, irgendwie weiter oben in die Nahrungskette sitzt und dann auf einmal wird der Team zu ein Meeting gebeten und dir gesagt Leute, zack! Wir arbeiten jetzt agil hier, habt ein Board, dass ihr ein paar Zettel macht.
Matthias: [00:06:14.54] Ja, so kann man sich das in etwa vorstellen. Genau so kann ich mir das durchaus vorstellen, dass das an vielen Stellen passiert. Und Hauptproblem ist in meinen Augen dann, wenn sich niemand wirklich auskennt. Also wenn es einfach nur heißt Wir machen das, weil macht halt grad jeder und aber niemand weiß genau, was man eigentlich macht.
Alex: [00:06:35.33] Genau das ist das Problem, weil mit dieser Agilität werden Erwartungen verknüpft. Denn nicht nur die Entwickler haben Erwartungen an das Thema, auch das Management hat gewisse Erwartungen an die ganze Thematik. Und ich meine, wenn du jetzt 5 bis 10 Leute in ein Team zusammen wirfst, die gar keine Ahnung haben von den agilen Mindset, die sich mit die Methode, die sie verwenden sollen, gar nicht auskennen. Also die Wahrscheinlichkeit, dass alles gut läuft und dass die Erwartungen erfüllt sind, sind leider Gottes meine Erfahrung nach eher gering. Da muss sehr viel Lernen passieren, bevor man das alles funktioniert und nicht nur Lernen von Methoden, sondern auch Änderungen an die Mentalität der Menschen. Die Art und Weise, wie sie arbeiten. Findest du das auch so?
Matthias: [00:07:30.50] Ja, absolut. Und ich kann auch offen sagen, die ersten Gehversuche, die wir gemacht haben, die sind sehr, sehr schief gelaufen, also weil man hat dann natürlich alles, was so theoretisch auf dem Zettel stand, hat man halt gemacht. Also mal angefangen zu schätzen mit Scrum Poker und ja, das hat einfach eine Zeit gedauert, bis man überhaupt versteht, was man da tut. Und die ersten Sprints, die wir so hatten, die sind phänomenal gescheitert. Wir haben überhaupt nicht das geschafft, was wir auf was wir uns committed haben, obwohl wir extra Arbeit reingesteckt haben und keine Ahnung. Also der Anfang war für uns unglaublich schwer. Definitiv. Vor allem, wenn halt überhaupt keine Guidance da ist. Also wenn wirklich eigentlich das mehr so ein ja, ein blinder Versuch ist da.
Alex: [00:08:23.88] Learning by Doing?
[00:08:24.77] Ja, so ungefähr. Genau.
Alex: [00:08:27.10] Und was hat euch da geholfen?
Matthias: [00:08:29.30] Im Prinzip aus den Fehlern natürlich lernen. Also wenn man halt man wird, dann zum Beispiel beim Schätzen automatisch erst mal passiver, wenn man merkt, dass man halt sich vollkommen überschätzt. Weil das ist ja eigentlich nichts anderes. Wenn man das, was man auf was man sich in einem Sprint commited, nicht schafft, dann hat man sich überschätzt. Und da lernt man dann letztlich draus, versucht, diese Einschätzung besser hinzubekommen. Aber das dauert halt natürlich eine Zeit und da muss man, glaube ich, selbst die Geduld mitbringen. Aber halt eben auch zum Beispiel etwaige Vorgesetzte müssen natürlich auch mit diesem Lernprozess rechnen, weil der also nichts kann, einfach funktionieren, weil man sagt, man macht das halt jetzt
Alex: [00:09:17.66] Und auch gerne mal selber was lernen.
Matthias: [00:09:20.45] Genau.
Alex: [00:09:20.84] Nicht nur, dass die was lernen, sondern auch im Management. Also es gibt kein ungeschriebenes Gesetz, der sagen würde, wenn man im Management ist, darf man nicht mehr lernen. Es ist nicht so und ich kenne viele Manager, die total begeistert sind, sehr viel und andauernd lernen. Ich kenne aber auch manche, die nicht so sind, aber was nicht ist, kann ja noch werden. Gut, also legen wir fest, dass der Wechsel von was es vorher gab zu „wir arbeiten jetzt agil“ keine Selbstverständlichkeit ist, dass da gewisse Prozesse, Lernprozesse, Mindset, Veränderungsprozesse stattfinden mussen. Und damit die Sache tatsächlich gut funktioniert.
Matthias: [00:10:02.84] Ja, absolut. Da stimme ich dir vollkommen zu.
Alex: [00:10:06.14] Ja, ja, nun nur, dass wir uns mal einig sind. Wobei wir sind uns meistens eher einig.
Matthias: [00:10:13.07] Wir uns schon häufig einig, das stimmt.
Alex: [00:10:17.00] Das Thema Änderung ist halt eine schwierige Sache. Also wenn man gewöhnt ist, auf eine gewisse Art und Weise zu arbeiten, egal welche jetzt und auf einmal mit irgendwas völlig anders konfrontiert wird, das ist nicht leicht.
Matthias: [00:10:35.33] Ja, ich finde, es kommt ein bisschen auf die Dauer an, wie lange man etwas gewöhnt ist. Also weil wenn man sich permanent schaut, was man ändern kann, also in regelmäßigen Abständen, dann ist es vielleicht gar nicht mehr so schlimm.
Alex: [00:10:48.08] Aber das ist ja total agil Matthias.
Matthias: [00:10:52.16] Ja, aber genau,
Alex: [00:10:54.10] Ja, aber ich gehe jetzt mal einfach von ein Software-Entwickler, die ich seit 20, 25 Jahre eine bestimmte Methode verwendet. Sagen wir jetzt einfach mal „Wasserfall“. Ich will Wasserfall nicht verteufeln, um Gottes Willen, aber sagen wir einfach mal Wasserfall. Und jetzt kommt irgendeine und sagt Wir arbeiten jetzt agil. Und das ist jetzt auf einmal alles anders. Ich kann da verstehen, dass es Schwierigkeiten gibt, dass es – es gibt Menschen, die das sehr offen für diese Veränderungen sind und Bock dazu haben und es auch mitmachen. Es gibt andere Menschen, die weniger Lust dazu haben. Das ist verständlich, das ist natürlich und das ist auch okay, weil jede Veränderung Prozess hat auch irgendwas mit Angst zu tun. Weil wenn ich das, was ich jetzt mache, kann und das, was neu dazu kommen, nicht, kann ich dann verstehen, dass da eine gewisse Angst herrscht.
Matthias: [00:11:50.89] Das ist die berühmte Komfortzone, würde ich mal sagen.
Alex: [00:11:53.98] Ja, sehr gut. Kannst du das ein bisschen?
Matthias: [00:11:57.22] Na ja, also ich sage mal, die Komfortzone kennt jeder, glaube ich. Das ist also für mich das, wo ich mich wohlfühle, wo ich weiß, da bin ich mir ziemlich sicher, was ich mache. Ich bin mir ziemlich sicher, dass ich keine Fehler mache, dass ich nicht scheitern werde. Das ist so meine Komfortzone. Und Änderung bedeutet häufig, dass ich mich aus dieser Komfortzone raus bewegen muss und ich für mich persönlich versuche, mich immer ein bisschen aus meiner Komfortzone raus zu bewegen, damit es nicht so schlimm ist, sozusagen. Aber dass sich die Komfortzone vielleicht ein bisschen verbreitern kann. So würde ich jetzt mal Komfortzone für mich umschreiben. Ja.
Alex: [00:12:36.07] Ja, und das ist was für mich, die die ganze Geschichte schwer macht. Dieser Veränderungsprozess ist eben mit Ängste behaftet, mit eine ganze Menge an Sachen, die neu zu lernen sind, die anders gemacht werden sollen und so weiter und so fort. Und das ist ein Prozess und man ist nie zu Ende agil. Es gibt immer irgendwas, was man noch machen kann, um sich in diese Agilität in diesem Mindset mehr einzubringen, besser zu verstehen und so weiter. Also ein Thema ist auch Ich bin nicht nach sechs Monate, wo ich agil arbeite oder mit agilen Methoden arbeite, ein agile Mensch, sondern das dauert deutlich länger. Und es gibt immer was Neues zu lernen, um was, wo man sich weiterbilden kann. Das ist nie ein abgeschlossene Prozess. Das ist wie das Thema Perfektion. Perfektion ist eine Asymptote. Ich kann immer so nah wie möglich an Perfektion kommen, wie wie möglich. Aber erreichen werde ich sie nicht. Fertig mit agil werden werde ich auch nicht. Hm. Verstehst du, was ich meine?
Matthias: [00:13:41.65] Ja, es war sehr treffend formuliert. Also finde ich gut.
Alex: [00:13:47.25] Wir haben ja gesagt, es haben sich schon in die Vergangenheit, auch in die Gegenwart Stimmen, Gehör verschafft oder raus geschrieen in die Welt. Dieses Ganze ist agiles Gedöns, ist einfach nur ein Dogma. Die Aussage ist da im Raum und damit wir versuchen, das ein bisschen zu verstehen, würde ich Mathias dich bitten, ein bisschen darüber zu reden, was deine Meinung nach ein Dogma ist.
Matthias: [00:14:15.96] Also ich würde jetzt zuallererst mal Wikipedia zitieren. Da findet man die Beschreibung vor, dass man unter einem Dogma versteht, wenn eine feststehende Definition oder eine grundlegende normative Lehraussage, deren Wahrheitsanspruch als unumstößlich festgestellt wird. Also quasi etwas daran kannst du nicht rütteln. Das ist so und also ich persönlich habe tatsächlich das in meiner Arbeit so in agilen Prozessen nicht erlebt. Also wir hatten tatsächlich eher das Problem, dass wir etwas zu planlos waren tatsächlich und haben dann eher pragmatisch gehandelt als dogmatisch. Also soll heißen, wir haben für uns halt das adaptiert, was wir für sinnvoll hielten, das Rausgeworfenes für nicht sinnvoll hielten. Und zack, wären wir für manche Leute wahrscheinlich nicht mehr agil in dem Sinne „Die machen jetzt Scrum“ gewesen, sondern die machen da halt irgendwas. Aber Scrum ist das mit Sicherheit nicht. Und es ist dann so irgendwo der Bogen von diese Definition des Dogmas hin zu „Was ist Dogma in der vielen Welt?“ Also wenn quasi jemand behauptet, Team A arbeitet nicht agil, weil und das halt einfach so als gegeben darstellt. Wie findest du das?
Alex: [00:15:42.90] Mir fehtl jetzt die Begründung Du hast weil gesagt, weil was?
Matthias: [00:15:46.83] Die Begründung?
Alex: [00:15:48.27] Ja du hast gesagt: Irgendjemand sagt Team A arbeitet nicht agil, weil
Matthias: [00:15:53.48] Ja, ja, weil Gründe. Also das kann ja viel sein. Zum Beispiel eben, die machen keine Retrospektiven. Jetzt mal ganz blöd gesagt, na ja, sondern die haben vielleicht irgendeinen anderen Prozess gefunden, wie sie reflektieren.
Alex: [00:16:06.69] Ich könnte ja aber auch sagen Team arbeitet nicht agil, weil sie die komplette Planung des Projekts mit alles pipapo alles schön vorher gemacht haben.
Matthias: [00:16:19.77] Das stimmt natürlich, das könnte man auch sagen, aber es ist ja mein Beispiel, bezieht sich das natürlich auf ok anders. Also ich erweitere mein Beispiel. Team A ist halt nicht einfach nur ein Team, das irgendwie arbeitet, sondern die haben für sich einfach einen Modus gefunden, wie sie schnell auf Änderungen reagieren können. Aber die Art und Weise, wie sie arbeiten passt eben in kein Rahmenwerk. Also jeder soll sagen Scrum Coach. Er würde also nicht jeder wahrscheinlich, aber so manche würden die Augen verdrehen und würden sagen Nee, nee, das ist agil, was die da machen.
Alex: [00:17:01.02] Okay, also ich finde das schon krass. Mehr so unumstößlich. Ja, die Wahrheit. Des macht mich irgendwie fertig.
Matthias: [00:17:09.78] Das ist eine sehr starke Aussage.
Alex: [00:17:11.73] Ja, ich war ja irgendwie ziemlich fertig und was meine Meinung über die Sache ist ist agil, kann nicht dogmatisch sein, das geht nicht. Agil ist oder Agilität oder die agile Bewegung ist, wie ich vorher gesagt habe, eine Menge an Ideen, an Mindset, wie man vorgehen kann oder auf was man achten muss, auf welche Sachen man mehr Wert legen sollte. Da steht nirgendwo Du musst das und das machen dafür. Also ich würde das kein Dogma nennen. Nirgendwo in den agilen Gedanken steht drin: Du bräuchtest keine Dokumentation. Es steht drin, dass es wichtigere Sachen gibt als Dokumentation, wenn man nicht das Dokumentation völlig unwichtig oder völlig unnötig wäre. Das ist, was ich mit das kann überhaupt nicht in diese Dogma Definition reinpassen, Meine Meinung nach. Und – Was ich aber an vielen Stellen festgestellt habe ist, dass Menschen das agil sein gleichsetzen mit irgendeine bestimmte agile Methode zu verwenden. Und wie gesagt, diese Gleichung agil sein, gleich bestimmte agile Methode verwenden ist für mich Unfug. Es kann nicht so sein. Es ist nicht so in meinem Auge. Agil sein ist wie gesagt eine Sache der Mentalität, der Vorgehensweise, wie ich Software Entwicklungsprojekte im Ganzen sehe und im Detail angehen, aber nicht Methode XYZ verwenden oder Methode ABC verwenden. In der Tat, wenn man sich der Agile Manifesto mal anschaut, gibt es irgendwann ein Teil die dagt „Individuals and Interactions over Processes and Tools“. Also heißt so viel wie Individuen und Interaktionen zwischen diesen Individuen mehr als Prozesse und Werkzeuge. Das heißt, eine Methode, die mir ein Prozess diktiert, ist nicht das Wichtige in der agile Vorgehensweise oder in der agile Mentalität, sondern die Menschen, die daran teilnehmen, wie sie miteinander arbeiten. Das ist wichtiger, als welche Prozesse wir nutzen, als welche Methode wir verwenden. Oder zumindest sehe ich das so oder ist meine Interpretation von dem. Von dem, was ich da gelesen habe, wie siehst du das?
Matthias: [00:19:38.39] Ja, also auch wieder sehr schön gesagt, trifft es auf den Punkt in meinen Augen.
Alex: [00:19:44.87] In deinen Worte kann agil ein Dogma sein,
Matthias: [00:19:48.68] Es kann dogmatisch ausgelegt werden. Aber soll heißen Nein, ich stimme dir zu. Der agile Gedanke hat letztendlich nichts mit Dogmatismus zu tun. Und ich sehe es tatsächlich auch so. In meiner persönlichen Erfahrung, dass es für mich um einiges wichtiger ist, wie ich mit meinen Teammitgliedern zusammenarbeiten kann, mich auf Verbesserungen einigen kann, dass es das ist um einiges wichtiger als wie der Prozess heißt, den wir da jetzt gerade betreiben.
Alex: [00:20:20.27] Ich finde, du hast eine ganz wichtige Sache gesagt und es ist Agilität an sich kann nicht dogmatisch sein. Was aber passieren kann, ist, dass man agile Methoden oder agile Strukturen dogmatisch auslegt. Und das habe ich tatsächlich erlebt. Ja, also
Matthias: [00:20:41.90] Wie hat sich das geäußert?
Alex: [00:20:43.85] Relativ einfachen Beispiel ist: Wenn du Scrum machst, musst du das, das, das und das machen. Wenn du eins weglässt, dann machst du kein Scrum mehr. Es ist grundsätzlich nichts Negatives oder nichts Schlechtes. Aber dass ich Scrum nach Buch nicht mache – Ja, dass ich von Scrum, mir die Teile ausgesucht habe, die für unser Team funktionieren. Da werden wir schon noch draufkommen. Das soll man nicht einfach ohne Weiteres machen. Aber wenn ich mir so was trauen und sowas machen kann, dann die Tatsache, dass ich kein Scrum verwende oder kein Kanban verwende oder keine Methode X, Y und Z, die von den agilen Gurus hoch gepriesen wird, verwende, bedeutet nicht, dass ich nicht agil arbeite. Das ist für mich die sehr wichtige Aussage, die du gerade eben getroffen hast. Einfach nur so im Vorbeilaufen.
Matthias: [00:21:38.39] Ja, wie gesagt, also das ist meine persönliche Erfahrung tatsächlich damit. Und ja, ich lebe gut damit. Was ich vielleicht an der Stelle auch noch sagen kann. Also ich bin nach wie vor oder tatsächlich eher der pragmatische Typ, was agile Methoden angeht. Ich glaube, das hat man so ein bisschen auch gerade eben herausgehört, als ich von der Art und Weise, wie ich mit meinem Team damit umgehe.
Alex: [00:22:03.26] Also mal kurz zusammenfassen. Meiner Meinung nach kann Agilität nicht dogmatisch sein, kann nur dogmatisch ausgelegt werden. Und es ist kein Problem der Agilität an sich, sondern von dem Menschen, die sie einsetzen sollen. Deine Zusammenfassung?
Matthias: [00:22:20.33] trifft es nach wie vor ganz gut. Also ich kann nach wie vor sagen, ich halte es für falsch irgendwie auf Prozesse zu bestehen, weil es irgendwo steht, dass man es so machen muss, sondern man soll in meinen Augen das machen, was eben funktioniert und was nicht funktioniert. Soll man versuchen zu verbessern oder im Zweifel weglassen? Vor allem wenn es im Team eine Mehrheit dafür gibt. Es ist halt tatsächlich dann auch immer noch meine Meinung. Also ich kann mich auch dem Team unterordnen, wenn es Mehrstimmig dafür ist, etwas beizubehalten, was ich jetzt vielleicht für nicht so gut erachte.
Alex: [00:23:02.12] Ich vielleicht als letzten Satz Der Weg zur Agilität ist für jedes Unternehmen oder für jeden jedes Team anders. Es gibt viele Ähnlichkeiten, leugne ich gar nicht. Aber es gibt auch keine fertige Lösung, die für alle funktioniert. Da muss man abwägen. So, das ist für mich die Quintessenz der Sache. Also der Weg zur Agilität ist für jedes Team, für jedes Unternehmen anders. Was wir aber heute auch schon mehrfach erwähnt haben, ist diese Diese Weg zu Agilität dieser Weg zu agil ist mit sehr viel Lernen verbunden. Und ich habe mal mir die Frage gestellt wie lernt man eigentlich? Wie kann man irgendwas lernen? Und habe ich eine sehr interessante Theorie oder eine sehr interessante Methode von Alistair Cookburn gelesen in mehrere von seinen Blogs, die beschreibt, wie man lernt. Des ist halt abgehlhehnt aus dem Aikido der macht seit vielen Jahren Aikido und hat aus diese Philosophie, diese Mentalität des Lernens bestimmte Ideen mit rausgenommen. Es ist das sogenannte „Shu-Ha-Ri“ Prozess und wir gucken uns das mal kurz mal an, was das bedeutet was das ist so das „Shu-Ha-Ri“ Prozess ist eben wie gesagt ein Prozess, der in drei verschiedene Phasen stattfindet, sodass das Lernprozess findet in drei Phasen statt. Die erste heißt Shu, die zweite heißt Ha und die dritte heißt Ri. Shu – Die erste Stufe bedeutet so viel wie Folgen. Ja, und das bedeutet, in der erste Phase des Lernens konzentrieren wir uns auf einen einzigen Lösungsweg. Wir lernen von einem Lehrer oder eine bestimmte Methode oder einen bestimmten Weg, irgendwas zu tun. Und wir lernen nur diese einen Weg, das zu tun. Wir wollen das Problem lösen. Wir wollen, dass die Sache funktioniert. Es geht nicht darum, alle mögliche Lösungsansätze zu eruieren, sondern einen zu finden der geht. Zum Beispiel, um Agilität einzubringen verwenden wir jetzt Scrum und dann lernen wir, wie Scrum funktioniert und verwenden wir Scrum, so wie es definiert ist. Wir wollen begreifen, wie diese einen Weg funktioniert. Alles andere ist nicht so wichtig. Der einen Weg muss man beherrschen. Ist das verkehrt? Weil das klingt für mich sehr dogmatisch.
Matthias: [00:25:50.41] Ja, gebe ich dir recht. Ich würde halt dazusagen, dass man letztendlich ja auch nur über etwas urteilen kann, was man komplett erfahren hat. Also wenn ich nie den kompletten Scrum Prozess gelernt habe, ohne das gemacht zu haben, kann ich natürlich nicht entscheiden, dass Teile davon vielleicht für mich nicht funktionieren, sondern dann ist es erst mal einfach nur Vorurteil behaftet, wenn ich sage das kann nicht funktionieren und deswegen: Ja – mit diesem Zusatz
Alex: [00:26:25.00] Ja, und für mich ist auch nicht so schlecht wie es klingt. Also es wäre schlecht, wenn man auch da bleiben würde,
Matthias: [00:26:31.72] Wenn es keine anderen Formen gäbe.
Alex: [00:26:34.12] Also wenn man da bleibt, dann ist es schlecht, dann kann es zu rein dogmatische Auslegungsweise bleiben. Aber Shu oder die erste Phase des Lernens ist eben die erste Phase, ist nicht das Ende, des Lernwegs. Da begeben wir uns halt in die zweite Phase. Ha – Zweite Stufe heißt so viel wie „Trennen“. Die Übersetzungen sind nicht ganz genau, aber so sinngemäß versuche ich mal so. Ich kann kein Japanisch und ist nicht so mein Ding. In Ha versuchen wir uns zu befreien von diese einen Weg, die wir gelernt haben. Es geht jetzt darum, das Verständnis, die wir in die erste Phase uns erarbeitet haben, wie die Sachen funktionieren, mal anders auszulegen. Wenn wir den einen Weg, die wir gelernt haben, verstanden haben, verinnerlicht haben, dann sind wir in der Lage Grenzen zu sehen. In welchem Fällen funktioniert das nicht so gut oder funktioniert für uns das nicht? Wir fangen an und wir sind dann in der Lage, auch Probleme anders anzugehen, neue Möglichkeiten zu eruieren, Experimente zu wagen und der Lösungsweg, die wir bekommen hatte diese einen, diese eine Methode einfach anzupassen auf das, was unsere neue Herausforderungen halt mit sich bringen. Mit diesem Verständnis, das wir bis jetzt hatten, haben wir eben die Prinzipien zu begreifen, die hinter der Methode stecken.
Alex: [00:28:14.54] Und wenn wir das gemacht haben, wenn wir diese Prinzipien verstanden haben, können wir uns auch erlauben, andere Lösungswege auszuprobieren, andere Experimente zu wagen. Die dritte Stufe. Ri. Ri bedeutet so viel wie „Fließen“ in diese Phase hat das Lernen eigentlich eine andere Bedeutung. Wir lernen jetzt nicht mehr eine Methode. Wir haben die Prinzipien und die Ideen, die dahinter stecken, verstanden. Wir sind in der Lage, anhand von unsere Erfahrungen, anhand von unsere Kenntnisse einfach ich sage es jetzt einfach mal so frei Schnauze einen Weg zu finden, die zur Lösung führt. Ob es dieses Weg bereits gibt oder wir es neu erfinden, ist völlig egal. Das ist überhaupt nicht wichtig. Fließen. Es fließt einfach. Wir sind in der Lage, weil wir eben Schu durchgemacht haben und Ha durchgemacht haben. Diese abstrakte Ideen, die hinter die Prinzipien und hinten hinter die unterschiedliche Wege stecken, zu abstrahieren und einfach unser eigenen Weg zu gehen. Was ich da für mich sehr wichtig ist: Diese „Shu-Ha-Ri“ Prozess ist keine Sache von zwei Monate und eine Schulung. Es bedarf in vielen Fällen Jahre, bis man in Ri angekommen ist. Nicht falsch verstehen, „Shu-Ha-Ri“ ist nicht ein Prozess, wo ich eine Woche in Shu bin, zwei Wochen in Ha und dann bin ich die Obermacker.
Matthias: [00:29:49.47] Schön wäre es ja.
Alex: [00:29:51.42] Nein, so funktioniert das leider Gottes nicht. Man braucht sehr lange Zeit, um wirklich ein, sagen wir mal Meister in der Agilität zu werden. Deine Gedanken dazu würde das ganze Prozess um die drei Phasen und so.
Matthias: [00:30:10.38] Ja, also ich kann es „Shu-Ha-Ri“ Prinzip so ein bisschen aus dem Bereich Katas und so. Und ich kann das jetzt sehr gut verstehen und nachvollziehen. Ich finde, es passt sehr gut, was du erzählt hast. Zu Shu habe ich ja meinen Senf quasi schon dazugegeben, also in Bezug auf Dogmatik. Ja, in Shu vorhanden. Aber wie gesagt, zu einem gewissen Grad auch notwendig und eben ganz wichtig, dass man eben auch aus dieser Phase auch wieder rausgeht. Wenn man jetzt natürlich ein Team ist, für den alles was in Shu praktiziert wurde, perfekt funktioniert. Herzlichen Glückwunsch! Ich halte es ein bisschen für unwahrscheinlich, aber nichts ist ausgeschlossen. Wenn ich so drüber nachdenke ich persönlich würde mich so ein bisschen bei Ha einordnen. Wir befinden uns in einem regelmäßigen Prozess, wo wir schauen, was wir anders machen können, wie wir was verbessern können. Und da kann ich jetzt zum Beispiel vielleicht auch mal ganz blöd als Beispiel sagen Wir haben für uns im Team beschlossen, dass wir Retrospektiven Team intern ersetzen wollen durch einen anderen Mechanismus, sogenannte Popcorn Board. Und das hat überraschend gut funktioniert. Dieses Experiment, und das machen wir mittlerweile glaube ich seit einem Jahr. So Retrospektiven machen wir dann im Prinzip immer wieder mit Stakeholdern und ähnlichen. Und das wirst du halt in keinem Lehrbuch finden. Das was wir da praktizieren.
Alex: [00:31:45.66] Nicht nach jedem Sprint. Oder wie? Wie meinst du das? Man findet in der Retrospektiven statt.
Matthias: [00:31:51.00] Die Retrospektiven mit dem Stakeholder und ich finden, glaube ich persönlich alle drei Sprints statt und die teaminternen Geschichten sind ein wöchentlicher Termin, wo wir quasi. Also es würde jetzt zu weit führen, wenn wir jetzt wirklich auf das Popcorn Board an sich eingehen. Aber das ist im Prinzip ein Prozess, wo wir einen stetigen und stetigen Verbesserungs Prozess anstrebt. Teamintern
Alex: [00:32:17.76] Kontinuierliche Verbesserung.
Matthias: [00:32:19.72] Genau und das haben wir für uns eben beschlossen, dass das für uns sinnvoller erscheint, als starre Retrospektiven zu machen, die irgendwie immer nach ähnlichen Mustern ablaufen und vielleicht Sachen gar nicht angesprochen werden, die weil sie jetzt zum Beispiel, weil das hatte ich ganz häufig in Retrospektiven, halt wenn man jetzt noch an früher denkt, wo ich mehr in diesem Scrum Prozess drin war, da wars in Retrospektiven häufig so, dass einfach nur Probleme, die jetzt gerade in den letzten zwei Wochen irgendwie die Entwicklung behindert haben, so angesprochen worden sind. Aber so häufig sind Dinge einfach vergessen worden. Und den Prozess, den wir da jetzt implementiert haben, der ermöglicht einfach, das früher festzuhalten. Wenn mich irgendwas hindert, dann kann ich direkt dahin und es da aufschreiben. Aber wie gesagt, es wird jetzt alles zu weit führen. Das werden wir uns bestimmt mal in Folge vielleicht anschauen. Genau und Ri ja, also das sehe ich mich – Also Ri würde ich tatsächlich schon fast so sehen, wie das ich in der Lage bin, ein anderes Team durch die Schu-Phase zu bringen und sinnvoll auf eine Ha-Phase vorzubereiten, das wäre es für mich dann die Ri-Phase, in der ich mich persönlich aber jetzt so noch nicht seh glaube tatsächlich
Alex: [00:33:40.22] Ich, ich bin mir da nicht so sicher, ob das für Ri reicht.
Matthias: [00:33:43.18] Ja, ich auch nicht. Also es war alles nur meine Gedanken. Also sicher bin ich mir dabei nicht. Das ist jetzt. Ich habe halt jetzt gerade mal ein bisschen drüber nachgedacht und es ist mal so das, was mir dazu einfällt.
Alex: [00:33:55.13] Ja gut, lass man so stehen. Wie viel Dogma brauchen wir, Matthias? Brauchen wir überhaupt Dogma? Und wenn ja, wie viel?
Matthias: [00:34:04.07] So wenig wie möglich? So viel wie nötig? Kann man das so zusammenfassen? Also –
Alex: [00:34:10.53] Kann man, ja.
Matthias: [00:34:11.51] Also im Idealfall bräuchts es net, aber ich kann mir schon vorstellen, dass gerade in einer Anfangsphase, also wenn jetzt ein Team neu zusammenkommt und für sich beschließt, agil arbeiten zu wollen, dass es halt eh eine Zeit braucht, bis das Team einen gemeinsamen Nenner findet. Und da macht glaube ich halt ein gewisser Dogmatismus also bzw. ein gewisser Rahmen, in dem man sich bewegt Sinn, weil sonst endet es eventuell in puren Chaos. Aber wenn das Team nun zusammengewachsen ist und ein gemeinsames Mindset, wo wir wieder bei der Geschichte mit dem agilen Mindset sind, entwickelt hat für sich, dann kann es meiner Meinung nach mehr in diese pragmatische Richtung gehen. Also wirklich das sagen wir machen das, was für uns funktioniert und nicht das, was in irgendeinem Lehrbuch steht.
Alex: [00:35:04.76] Okay, ich würde mal kurz so sagen Ein gewisses Maß an Dogma brauchen wir, und zwar während dieser Shu-Phase. Ja, weil das ist eben der erste Impuls. Das was uns erlaubt, uns auf den Weg zu machen, irgendwas zu lernen. Und dann ist es gut, wenn wir einen bekannten Weg verfolgen, die gewisse Regeln haben, die wir einhalten müssen, okay. Aber ohne diese erste Methode oder dieser erste Weg, dieser erste Lösungsweg können wir uns gar nicht auf den Weg machen. Und deswegen ist auch wichtig, diese gewisse Maß an Dogma beizubehalten, wenn du willst. Wir fangen einfach so an, dass wir kopieren das, was es gibt. Wir nehmen das, was es gibt und kopieren eins, eins zu eins. Wir verwenden die Methode so, wie sie sind. Erst später sind wir in der Lage, andere Wege oder andere Methoden oder andere Möglichkeiten zu verstehen. Und ganz am Ende des Weges steht uns dann offen die Möglichkeit, unsere eigene Wege zu kreieren. In meinen Augen auch voll im Sinne von der Agile Bewegung. Einfach „inspect and adapt“.
Matthias: [00:36:27.90] Na, das finde ich einen sehr guten Satz. Also weil das ist ja im Prinzip die Definition von Agilität, dass man sich anpassen kann, an Gegebenheiten.
Alex: [00:36:37.22] Gut, dann Schlusswort des Tages In der Softwareentwicklung kommen öfters mal vor, dass Teams einfach gesagt bekommen Ihr seid jetzt agil, du bist Scrum-Master, der da ist PO ja,
Matthias: [00:36:50.09] ich bin Chef
Alex: [00:36:52.25] Und Chaka. Agiles Team ist da. Das hat für mich keinen Sinn. Es funktioniert nicht, oder nicht gut. Es geht eher darum, diesen Lernprozess anzustoßen und mit so wenig Dogma wie möglich diesen Weg zu beschreiten. Wie du vorher gesagt hast so viel wie nötig, so wenig wie möglich. Es ist für mich ein gutes Maß.
Matthias: [00:37:20.02] Das ist häufig ein gutes Maß tatsächlich.
Alex: [00:37:23.03] Also Dogma am Anfang des Lernprozesses kann hilfreich sein, wenn nicht sogar notwendig. Aber es muss sich um eine Phase des Lernens sein. Irgendwann einmal sind wir von dieser Phase weg und können wir uns weiterentwickeln. Soweit zu meiner Meinung. Letzte Worte von dir.
Matthias: [00:37:43.01] Ja, nee, ich glaube, ich habe so, dass im Großen und Ganzen eigentlich alles gesagt. Wir fallen jetzt keine großartigen letzten Worte mehr ein.
Alex: [00:37:53.72] Okay. Nun ja, das ist der Ende der Folge. Schön, dass du durchgehalten hast.
Matthias: [00:38:00.89] Du hast heut viel über Agilität, Dogmatismus, Veränderung und Lernen gehört? Und kannst dir jetzt hoffentlich deine eigene Meinung bilden.
Alex: [00:38:09.08] Wieviel Dogma braucht es wirklich und ist agil, dogmatisch oder nicht? Was denkst du?
Matthias: [00:38:14.93] Wie immer würden wir uns freuen, wenn du den Podcast abonnierst und auch mit anderen drüber redest.
Alex: [00:38:19.76] Vielen Dank fürs Zuhören. Wir sind in drei Wochen wieder da mit neuen Themen.
Matthias: [00:38:25.43] In unserer nächsten Folge geht es um „The Blame Game“ oder das merkwürdige Bedürfnis Schuldige zu finden.
Alex: [00:38:31.75] Wir sehen uns bis dann.
off: [00:38:38.53] Die Macht der Craft arbeitet für dich.