Alex: [00:00:07.85] Hallo und herzlich willkommen zur eine neue Folge der „Macht der Craft“. Ich bin der Alex

Matthias: [00:00:12.95] Und ich bin der Matthias. Heute wollen wir dir etwas von Popcorn erzählen, aber leider nicht das das man essen kann.

Alex: [00:00:19.13] Auf jeden Fall ist es eine coole Methode, dass dir helfen kann, Änderungen einzuführen und dich und deinen Team zu verbessern.

Matthias: [00:00:26.90] Nach der heutigen Folge wirst du diese Methode kennen und wirst in der Lage sein, sie zu verwenden.

Alex: [00:00:31.97] Wir wünschen dir viel Spaß.

off: [00:00:37.63] Die Macht der Craft arbeitet für dich.

Alex: [00:00:44.93] Unsere Arbeit ist von vielen Sachen geprägt, aber eine der für mich zentrale Themen, die wir immer wieder finden, die dauernd unser Begleiter ist, ist Veränderung – sind Änderungen. Und die Frage, die ich mir öfter stelle ist, warum oder wozu Veränderung notwendig ist. Und ich habe für mich in meinen komischen Kopf mal zwei Sachen, wo ich der Meinung bin, die uns dazu zwingen, uns zu verändern oder Änderungen herbeizuführen. Die erste ist Änderung als Reaktion auf unsere Umgebung. Unsere Umgebung verändert sich, alles ändert sich und das passiert relativ schnell. Passiert ruckizucki, dass sich was geändert hat. Es kann von gesetzliche Änderungen, wo wir dann Sachen anpassen müssen, neue Erkenntnisse, neue Methoden, Programmiersprachen, die Kundenwünsche verändern sich, wir müssen auf den Wettbewerb achten, was sie machen oder nicht machen und so weiter und so fort. Dadurch, dass all diese Sachen sich verändern, müssen wir uns auch ändern, um kompetitiv und im Geschäft bleiben zu können. Das ist für mich eine der Sachen und die andere ist für mich Veränderung aus dem Wunsch heraus, besser werden zu wollen, sich zu verbessern. Weil Verbesserung hat sehr viel zu tun mit Veränderung. Das passiert sehr selten, oder? Mir zumindest passiert es sehr selten, dass wenn ich immer wieder das gleiche mache, die Sachen besser werden, sondern dass es eben eine gewisse Veränderung an die Art und Weise, wie ich Sachen machen, wie ich denke, wie ich mich verhalte, notwendig ist, damit eine Verbesserung eintreten kann. Sei es im Code oder sei es in die Art und Weise, wie man irgendwas tut oder wie man lebt. Also grundsätzlich wäre das für mich der Punkt. Wenn ich besser werden will, muss ich sehr oft – weiß net, vielleicht sogar immer irgendeine Art der Veränderungen oder der Veränderung durchlaufen. Was würdest dazu sagen? Warum brauchen wir Veränderung?

Matthias: [00:03:10.31] Matthias Ich würde dir erst mal im Großen und Ganzen zustimmen. Also ich sehe das ganz ähnlich. Also wir leben halt einfach in sehr schnellen Zeiten. Also es ändert sich alles laufend. Und wenn wir in so einem Umfeld arbeiten, agieren, müssen wir eben darauf reagieren können. Und allein aus der Gesetzmäßigkeit, dass sich die ganze Umgebung verändert. Müssen wir uns verändern. Und genauso wie du sehe ich das auch so, dass man das unterscheiden muss zwischen Dingen, die eben von außen sich ändern und uns dazu zwingen, uns anzupassen. Und die Veränderung, die wir von innen heraus, von uns selbst aus getrieben anstreben, um besser, effizienter, stressfreier arbeiten zu können.

Alex: [00:04:05.21] Intrinsisch motiviert, wie man so sagt.

Matthias: [00:04:08.21] Genau.

[00:04:11.49] Ja, sehr, sehr gut. Das Problem mit Veränderung ist hatten wir auch schon mal, in anderen Folgen ist es ja nicht ohne Weiteres passiert. Das bedeutet Arbeit natürlich. Und wir Menschen haben oft Angst vor Veränderung. Für mich einer der Große oder die eine der großen Problemen, die es mit Veränderungen gibt, ist, dass man einfach zu viel auf einmal will. Das muss von heute auf morgen einfach alles anders werden und das tut natürlicherweise weh. In meinen Augen wäre es wahrscheinlich besser, wenn dir diese Veränderung in kleinen Schritten durchführen könnten. Die Methode, worüber wir heute sprechen, kommt von Claudio Perone und der selber sagt „If change is hard make it continuous“ heißt für mich eine der wichtige Punkte, die er immer anspricht, ist. Anstatt große Änderungen auf einmal zu machen, sollten wir danach streben, kleine Änderungen, die wir kontinuierlich nacheinander vornehmen.

Matthias: [00:05:26.86] Ja, macht auf jeden Fall Sinn, weil letztendlich je kleiner eine Änderung ist, desto kleiner ist auch das Risiko dieser Änderungen. Und deswegen macht es total Sinn, öfters kleine Änderungen zu machen, statt einmal riesige.

Alex: [00:05:41.74] Genau. Ist auch ein wichtiger Punkt. Sehr gut. Danke dir. Aber was ist diese Popcorn-Flow? Wo kommt das her, Matthias?

Matthias: [00:05:51.06] Na ja, letztendlich eben von dem von dir gerade eben schon erwähnten Claudio Perone, der sich da eben eine Methode überlegt hat, wie man so eine kontinuierliche Verbesserung. Ja, wie soll man sagen handelbar managebar machen kann. Mithilfe des sogenannten Popcorn Flows Popcorn Boards, den man eher dem Popcorn Flow letztendlich, den man auf einem Board abbilden kann, genau mit mehreren Spalten, auf die wir jetzt dann auch wahrscheinlich näher eingehen werden.

Alex: [00:06:22.90] Claudio hat ja erzählt immer, dass diese Popcorn Flow auf bestimmte Prinzipien basiert. Wir gehen jetzt mal kurz diese Prinzipien durch und reden mal ein bisschen darüber. Der erste Prinzip der man – ist wichtig im Kopf zu behalten ist Wenn Veränderung schwierig ist, sollte sie kontinuierlich erfolgen. Wir haben mal in anderen Worten „If change is hard make it continue“. Was bedeutet das für dich?

Matthias: [00:06:59.44] Na ja, also wenn ich jetzt zum Beispiel auf meine tägliche Arbeit und Softwareentwicklung beziehe, also das kann man mit Sicherheit auch auf andere Sachen beziehen, dann wäre das zum Beispiel ein könnte man es auf CI anwenden, auf Continuous Integration. Also verfolgt, glaube ich, das ähnliche Prinzip, dass man laufend kleine Änderungen zurück merged, anstatt am Ende vom Sprint einmal alle Feature Branches zusammen wirft und hofft, dass alles funktioniert.

Alex: [00:07:31.21] Ja, CI ist ein gutes Beispiel. Ich glaube, der verwendet Claudio auch sehr oft, um das Prinzip zu veranschaulichen. Aber mir fällt zum Beispiel auch eine andere Sache. Wir haben ja, wenn du dich erinnerst, vor ein paar Monate über Refactoring gesprochen. Ich finde, es ist auch ein Thema, die gut dazu passt. Ja, Veränderung ist schwierig. Also unser Code zu verändern, auf welchem Grund auch immer, ist eine schwierige Aufgabe. Deswegen kann es durchaus vorteilhaft sein, anstatt eine Neuausschreibung zu machen durch kleine Refactorings uns unser Ziel anzunähern. Das wäre für mich auch eine feine Sache, die zu diesem Prinzip passt. In meinen Augen

Matthias: [00:08:21.79] Genauso. Zum Veranschaulichen des Prinzips ist das auf jeden Fall auch ein gutes Beispiel.

Alex: [00:08:28.78] Dann nehmen wir uns das zweite Prinzip und das ist für mich eine der sehr wichtigen Ideen, die da mitschwingen. Es kommt nicht nur darauf an, was man tut, sondern auch darauf, was man dabei lernt. Sag Matthias, was weckt das in dir?

Matthias: [00:08:53.38] Na ja, in erster Linie mal schließt das für mich ein, dass auch Fehlschläge okay sind und es halt wichtig daraus ist, dass ich aus diesen Fehlschlägen lerne, wenn sie denn passieren. Das würde ich jetzt mal so spontan da rein interpretieren.

Alex: [00:09:10.63] Aber gut, was ich damit verbinde, auch ist nicht nur das Fehlschläge okay ist ich bin da voll bei dir, sondern lass das wichtige ist wir experimentieren, wenn wir irgendwas ausprobieren, wenn wir versuchen kleine Änderungen in unsere tägliche Arbeit mit einzubinden. Das eben, was wir tun, ist wichtig. Wie wir es tun, ist auch wichtig. Aber was wir dabei lernen, ist eigentlich der Kern der Sache. Und deswegen eben sind Fehlschläge völlig in Ordnung. Nicht gut wäre es, wenn wir Fehler machen und nix dabei lernen, wenn wir dabei aber irgendwas lernen. Das funktioniert bei uns nicht und so wollen wir das nicht machen, weil es uns mehr Aufwand verursacht als Wirkung erzielt. Das sind alles Erkenntnisse, die uns schlauer machen, die uns helfen, eben auch besser zu werden. Okay, dann guck mal uns der dritte Prinzip. Den finde ich durchaus interessant und vielleicht ein bisschen schwer zu verstehen, aber ich bin mir sicher, dass du es uns perfekt erklären willst – wirst. Jeder hat ein Recht auf seine eigene Meinung, aber eine gemeinsame Meinung ist eine Tatsache. Hm. Was sagt dir das?

Matthias: [00:10:37.94] Es spiegelt meine persönliche Meinung glaube ich ganz gut wider. Also ich habe auch diese persönliche Meinung, die Nähe. Also grundsätzlich, wenn ich jetzt wieder von dem Team in dem ich arbeite spreche, finde ich sollte jedes Teammitglied a) schon mal die gleiche Stimmkraft haben, also niemand sollte irgendwie doppelt voten können oder Veto. Also so grundsätzliche Vetos oder sowas einnehmen können. Aber wenn das Team sich dann auf etwas einigt, dann ist das Konsens. Egal ob jetzt alle zugestimmt haben oder eben nur Entfernung 5 und 6 oder so oder 4 von 6 Mehrheitsentscheidung sozusagen.

Alex: [00:11:22.24] Na klar, ich sehe das ein bisschen anders, aber ähnlich. Im Grunde genommen bedeutet das für mich also der erste Teil ist für mich klar Jeder hat das Recht, seine eigene Meinung zu haben. Das ist doch einfach eine Tatsache. Ja, wir können alle unterschiedlich denken und ich bin jetzt nicht in den Lösungs Raum, sondern um dem Problem Raum. Und vielleicht ist es damit gemeint, weil wir werden jetzt danach sehen, eine Sache, die wir im Popcorn machen, ist uns transparent zu machen, welche Probleme wir haben. Und das ist eben so, dass weil ich sage, dass X ein Problem ist, bedeutet das erst einmal, dass es ein Problem für mich ist. Das bedeutet aber nicht zwingend, dass es ein Problem für den den Team ist. Und wenn wir dann im Team darüber reden okay, Alex findet, das ist ein Problem. Reden wir darüber, eruieren wir, ob wir das auch so sehen, was er sich dabei gedacht. Wenn am Ende diese Diskussion wir gemeinsam im Team der Meinung sind, das ist ein Problem, dann ist es auch eine ein Problem fürs Team. Und darum geht es meiner Meinung nach hier. Es geht nicht darum, dass Person A oder Person B sagt, dass es ein Problem oder wir müssen auf X achten oder Y machen das seine Meinung erst mal. Und wenn das gesamte Team zu der Erkenntnis kommt Ja, das ist so. Das erkennen wir als ein Problem, oder wir sind alle gemeinsam der Meinung, dass das uns hindert oder dass wir da irgendwas verbessern können. Dann es ist tatsächlich ein Punkt, die wir berücksichtigen müssen, die wir ja vertiefen müssen. Verstehst du, was ich meine?

Matthias: [00:13:32.13] Ja, ich sehe das jetzt gar nicht so inkompatibel zu meiner Aussage.

Alex: [00:13:38.01] Inkompatibel nicht, keine Frage.

Matthias: [00:13:39.52] Oder würde jetzt in deinem Fall. Würde jetzt aber auch nicht, wenn einer sagt oder eine sagt Ja, für mich ist das es aber gar kein Problem, dann würde das Problem ja nicht weg sein, sondern es wäre immer noch für das Team da. Ein Mitglied würde es halt anders sehen.

Alex: [00:13:56.88] Ja, es kann durchaus vorkommen, dass du ein Problem einbringt und ich sehe es zwar nicht als Problem, aber wir als Team gemeinsam entscheiden, da es Verbesserungspotenzial. Das wollen wir angehen.

Matthias: [00:14:09.96] Genau. Also ja klar

Alex: [00:14:11.67] Und völlig in Ordnung. Also ich sehe da kein Problem oder auch keine Contradiction wie du sagst. Es muss ja nicht alle der Meinung, die persönliche Meinung darf weiter bestehen. Das Ziel wäre es aber für mich eine Team-Meinung.

Matthias: [00:14:29.28] Genau dass man sich halt zum Team commitet sozusagen. Und wenn das Team entscheidet, es will an dem Problem etwas ändern, dass man da trotzdem auch mitziehen kann.

Alex: [00:14:39.81] Ja genau. Der vierte Prinzip ist auch interessant. Es heißt nicht „fail fast fail often“, sondern „learn fast learn often“. Es ist irgendwas, das ich in der agilen Welt so in Anführungszeichen auch sehr oft gehört habe. Es geht darum, „fail fast fail often“. Je schneller du was wegschmeißen kannst, desto weniger Schaden verursacht sozusagen und desto mehr kannst du lernen. Je mehr wir experimentieren oder Sachen ausprobieren, desto mehr können wir dabei lernen. Wenn dir diese Änderungen oder diese Experimente klein sind abgeschlossen, dann es ist nicht so wichtig, ob sie zu einem Erfolg führen oder nicht. Obwohl eigentlich das Ziel sein sollten, dass so oft wie möglich ein Erfolg wird, sondern eben, dass wir schnell in kürzere Zeitspannen irgendwas dabei lernen und dann entscheiden. Passt, passt nicht. Wegschmeißen, weitermachen, wie auch immer.

Matthias: [00:15:46.95] Ja, für mich ist es tatsächlich in erster Linie ein Rephrasing. Also man sagt das gleiche einfach ein bisschen anders, damit es positiver beladen ist. Also weil letztendlich man also das Handeln an sich bleibt das gleiche. Man macht etwas häufig und lernt dabei aus Fehlschlägen, wenn es schief läuft. Also vielleicht, was man dem Learn fast learn offen noch zuschreiben könnte, wäre, dass da impliziert ist, dass man auch aus, wenn etwas gut läuft, natürlich lernt und nicht nur, wenn etwas schiefläuft. Also eventuell ist es dann sogar ein bisschen weit fassender, finde ich.

Alex: [00:16:28.86] Und ich finde es treffender.

Matthias: [00:16:29.43] Ja.

Alex: [00:16:29.43] weil ich will nicht Fehlschläge produzieren.

Matthias: [00:16:34.86] Ja, ja, klar – nee

Alex: [00:16:35.16] Das ist ja nicht mein Ziel. Deswegen ist es fast zwar gut und wichtig, aber das ist nicht mein Ziel. Mein Ziel ist, nicht so zu failen, sondern eben lernen.

Matthias: [00:16:48.00] Aber also ich weiß jetzt nicht, ob das nur mir so geht, aber ich kenne ja „fail fast fail often“ eigentlich eher auch aus einer anderen Welt. Also eher so, wenn ich mein jetzt auch mal wieder an CI denke, dass ich halt zum Beispiel zuerst mal eine Unit Tests ausführt, bevor ich irgendwelche landläufigen Tests und da hier dieses „fail fast“, aber er ist halt jetzt komplett anderes Thema

Alex: [00:17:12.39] Natürlich seine Tests schlagen fehl und deswegen brauchst du die längerläufigen Geschichten nicht machen. Aber für mich ist das eine gehört mit dem anderen zusammen. Ich lerne was von meinem Code dadurch, dass ich diese Tests ausführe, bevor ich was anderes mache.

Matthias: [00:17:30.39] Stimmt, es schließt ja das „Fail fast“ nicht aus das „learn fast“ hast vollkommen Recht

Alex: [00:17:36.15] aber interessant. Und der fünfte, da haben wir auch schon darüber gesprochen. Ist kleine Einsätze wagen, um große Gewinne zu erzielen. Es soll unser unser Ziel sein bei diesem Prozess sein. Also klein Einsatz, großer Gewinn.

Matthias: [00:17:56.57] Na, das ist ja jetzt im Prinzip auch schon wieder das, was wir vorhin eben schon mal gesagt haben. Wie du schon erwähnt hast, also öfters kleine Änderungen mit kleinem Risiko, mit potenziell größerem Erfolg.

Alex: [00:18:11.60] Auch dadurch, dass die Einsätze, die wir wagen, oder die Änderungen, die wir einführen, die Experimente, die wir machen klein sind, klein in Menge, klein in Zeit ist der Aufwand, die wir investieren, gering. Und deswegen tut es nicht so weh, wenn wir verlieren. Das erlaubt uns sehr viel mehr auszuprobieren, wenn wir es in kleinere Einheiten machen. Am besten orthogonal Experimente mal durchführen, die sich nicht beeinflussen. Da kannst du halt ja sehr viel mehr rausbekommen als ein große Experiment oder mehrere Wochen oder Monaten. Wenn du kleine Experimente, die nur ein, zwei Tage vielleicht dauern oder weniger, dann kannst du, hast du schnell Ergebnisse und kannst du schnell merken Geht, geht nicht. Ja, so kannst du bessere mehr Gewinn rausholen.

Matthias: [00:19:17.48] Das fasst die Prinzipien, das glaube ich ganz gut zusammen.

Alex: [00:19:21.08] Du hast ja vorher erwähnt Popcorn Flow Popcorn Board was ist diese Board? Was machen wir damit?

Matthias: [00:19:31.40] Also ja, das Popcorn Board, also das Popcorn Board ist kann man sich vorstellen, wie ein Kanban-Board? Das ist in sieben Spalten aufgeteilt und wir wollen uns jetzt mal der Reihe nach die Spalten anschauen. Wir fangen einfach mal ganz links an. Dort gibt es eine Spalte, die nennen wir „Problems and Observations“. Hier würden im Prinzip alle Probleme erst mal gesammelt werden. Also jeder der an diesem Popcorn Board beteiligt ist, der mitarbeitet, darf da zu jeder Zeit irgendetwas, was ihm auffällt wäre eben eine Observation. Oder wenn einer wirklich einfach ein Problem feststellt, dann eben ein Problem dorthin hängen. Und im Team wird dann letztendlich in einem regelmäßigen Termin zum Beispiel diese Spalte erst mal betrachtet.

Alex: [00:20:25.04] Hast du im Beispiel schon ein Problem oder eine Observation oder so was?

Matthias: [00:20:29.11] Naja, also so ein Problem, weil wir es vorhin schon mit Continuous Integration mal hatten, könnten wir ja mal so ein Problem aufmachen, das wir aktuell nicht in der Lage sind, schnell genug zu releasen. Also wir, unser Team, unser fiktives das macht noch keinen CI. Also das hat einfach das Problem, dass wenn es Ihren aktuellen Stand releasen möchte, dann ist es, sagen wir mal einen Tag Arbeit für eine Person. Und das ist, stellt das Team fest, dass das ein Problem ist, weil sie wollen gern öfters releasen, weil sie zum Beispiel in Stakeholdern den Stand regelmäßig zeigen wollen. Und dann ist es natürlich blöd, wenn die ganze Zeit eine Person den ganzen Tag blockiert ist.

Alex: [00:21:18.69] Zu der Spalte würde ich auch noch sagen, mehrere Sachen. Die eine habe ich schon erwähnt, ich wiederhole sie nochmal kurz. Probleme sind tatsächlich ein Problem, wenn das Team der Meinung ist, dass es ein Problem ist und nicht weil ich ein Zettel hänge, bedeutet, dass wir uns das auch sofort annehmen müssen oder irgendwas. Ich stelle irgendwas fest. Ich häng einen Zettel in diese Spalte, weil ich der Meinung bin, dass das ein Problem ist oder irgendwas, wo wir uns verbessern können ist. Und wenn wir uns diese Spalte dann annehmen im Team gemeinsam, können wir da aussortieren und sagen Okay, du hast das angebracht. Warum? Was meinst du dazu? Und dann das Gemeinsame oder das Team gemeinsam entscheidet. Ja, das ist ein Thema, die wir uns vornehmen können, vornehmen wollen oder nicht. Es ist für mich eine der Punkte, die wichtig sind in diesem, in dieser Spalte. Die zweite Sache, die ich beobachtet habe, ist Da kommen manchmal Zetteln wie „Wir können nicht arbeiten, weil Team Y das und das nicht gemacht“. Das finde ich nicht so gut. Wir sollten Probleme und Observations, was auch immer da in dieser Spalte machen, so sehen und zu formulieren, dass wir irgendwas dagegen machen können. Sachen, die unter unserer Kontrolle sind, die wir selber verbessern können. Mir geht es eher darum, nicht was andere machen können, damit wir besser werden, sondern was können wir dann machen, um die Situation zu verändern und zu verbessern? Was würde uns helfen, damit wir dieses Problem nicht haben, so dass wir in der Lage sind, dieses Problem zu lösen und nicht einfach den schwarzen Peter auf irgendjemand anders schieben, sozusagen. Findest du das auch so, oder?

Matthias: [00:23:22.23] Ja, absolut. Ich finde in dem Prozess machen eh nur Sachen Sinn, wo man selbst drauf Einfluss hat, weil dadurch, dass man sich ja auch im Prinzip dann in späteren Phasen, wo wir dann nachher noch draufkommen, mir auch gewisse Time Boxen und sowas setzt. Willst du nicht sagen wir sagen keinen Einfluss drauf haben können, dass dieses Experiment auch funktioniert, dass man sich dann eventuell aussucht und deswegen also da machen dann irgendwie auch nur Sachen sind, wo man selbst drauf Einfluss hat, sonst sind sie schon halb zum Scheitern verurteilt.

Alex: [00:23:57.18] Probleme und Observations okay, jeder darf hängen was er will. Team entscheidet, was tatsächlich ein Problem ist, was das Team sich vornehmen möchte. Und am besten nehmen wir Sachen, die eben in unser Einflussbereich liegen

Matthias: [00:24:14.76] Die zweite Spalte auf dem Board. Die hat den Namen Options und hier sammeln wir dann quasi als Team Optionen um diese Probleme, die wir in der ersten Spalte gesammelt haben und dem wir uns als Team darauf geeinigt haben, dass die tatsächlich ein Problem sind. Sammeln wir dann in der zweiten Spalte eben die Optionen, um diese Probleme möglicherweise lösen zu können? Genau. Und wenn wir jetzt Beispiele an das Beispiel mit dem Release denken, das ich jetzt vorhin mal so aufgemacht habe, dann könnten da jetzt eben so Optionen stehen wie Keine Ahnung, wir könnten versuchen, CI einzuführen. Oder wir könnten „trukbased development“ ausprobieren. Weil was man zu der fiktiven Geschichte vielleicht noch dazu hinzufügen sollte, ist, dass das so lange dauert, weil an diesem einen Tag muss die eine Person alle Feature Branches, die in dem Sprint eben passiert sind, mergen, Merge-Konflikte lösen. Hat ganz viel manuelle Arbeit und genau deswegen. Die dritte Option ist dann eben auch auf mehrere Quests umstellen. Was im Prinzip also der Unterschied für mich zwischen Option 2 und Option 3 ist, dass bei Option 2 zu den Trunk Base Development ja alle auf dem Hauptbranch sozusagen arbeiten und es somit eigentlich kein. Code Review mehr gäbe und wenn man auf Merge-Requests umstellt, dann hätte man sozusagen dann noch diese diese Qualitätskontrolle von einem zweiten und deswegen das wären so drei Optionen, die mir zu spontan zu diesem fiktiven Beispiel einfallen würden.

Alex: [00:25:57.75] Du hast jetzt drei Optionen eingebracht, die gibt es einen Grund dazu? Oder es ist einfach nur das, was dir jetzt einfach so eingefallen ist.

Matthias: [00:26:06.03] Also als ich beim Popcorn ist es halt so, dass man bei den Optionen eigentlich auf jeden Fall eigentlich mehr wie 2 will, weil sonst ist es halt im Prinzip keine, wie soll man sagen. Ich weiß nicht wie formuliert. Claudio Ich bin mir nicht sicher. Ich muss nachgucken, aber ich glaube es. Es sollten mindestens zwei Optionen sein.

Alex: [00:26:32.86] Ja, also was soll er sagt? Ich finde, er hat recht dabei ist, wenn du nur eine Option reinschreibt, es keine Option, wenn du nur eins hast. Es ist keine mögliche Option, sondern es gibt ja nur das eine. Also ist es wichtig, dass du mehrere Optionen einfügst. Er redet immer von mindestens drei. Wichtig ist, dass man mehrere Optionen zur Verfügung hat. Wie gesagt, eine Option ist keine Option, sondern wir wollen aus ein Strauß an Möglichkeiten mehrere auswählen können.

Matthias: [00:27:11.73] Genau das meinte ich. Ja, ich weiß, dass er darüber redet, dass es eben auf jeden Fall mehr sein soll. Und es macht auch Sinn, weil wenn ich wirklich nur eine Option habe, dann ja dann brauche ich schon fast nicht weiter diskutieren. Also deswegen zwei mindestens würde ich sagen und drei sind auf jeden Fall da hat man dann eine gute Auswahl an Optionen

Alex: [00:27:37.98] Und vier und fünf sind auch nicht verboten.

Matthias: [00:27:40.11] Absolut ja, aber mehr, also mehr als die drei, sind mir spontan nicht eingefallen.

Alex: [00:27:44.49] Ja, das ist ja auch okay.

Matthias: [00:27:45.96] Aber fällt dir noch eine vierte ein?

Alex: [00:27:48.72] Nö, grad nicht. Okay, aber das ist eine wichtige Sache. Und das ist nicht einfach oder nicht immer einfach, weil öfters, wenn ich ein Problem rein poste, habe ich schon die Lösung im Kopf herum und das ist nicht so gut. Ich soll offen bleiben für unterschiedliche Möglichkeiten. Und deswegen machen wir das im Team, weil da die unterschiedliche Meinungen und Köpfe halt die Sachen manchmal anders sehen und andere Möglichkeiten und Ideen entwickeln. Aber wichtig eben, wie gesagt, bitte immer mehrere Optionen benennen. Die müssen wir jetzt nicht ausarbeiten, aber unterschiedliche Optionen benennen, die wir dann weiter verfeinern können.

Matthias: [00:28:35.04] Genau. Und diese Verfeinerung, die macht man dann letztlich in der dritten Spalte, wo es dann an die Possible Experiments geht, also die möglichen Experimente, um diese Optionen auszuloten. Würde ich mal sagen.

Alex: [00:28:54.49] Ja, also basierend auf die Optionen, die wir definiert haben, ein Problem oder eine Observation halt zu bearbeiten. Definieren wir tatsächliche Aktionen Experimente, die wir durchführen können, mit dem Ziel, eine Verbesserung herbeizuführen. Wir möchten Jenkins ausprobieren und wir möchten gitlab-ci ausprobieren. Es sind zwei Experimente, die wir für diese Option der CI-Einführung machen können. Und die lass ma da stehen. Die sind okay. Unterschiedliche Optionen generieren wir, unterschiedliche Experimente, die wir machen können. Das bedeutet nicht, dass wir sie machen müssen. Aber es geht darum, jetzt ein bisschen in die Breite zu gehen. Welche mögliche Experimenten fallen uns ein, wo wir eine Verbesserung in dem Problem durch die Optionen herbeiführen könnten? Wichtig ist für mich Ich erwähne jetzt noch mal, dass diese Experimenten mit weniger Kosten verbunden sein sollen zeitlich, personell, materiell, wie auch immer. Soll irgendwas, die uns erlaubt, fehlzuschlagen, ohne dass das ganze Projekt dann eine Challenge wird, besteht was meine?

Matthias: [00:30:20.42] Ja klar.

Alex: [00:30:22.22] Okay, dann machen wir weiter.

Matthias: [00:30:25.46] Ja und in der nächsten Spalte würde man sich dann letztendlich – des ist die „Commited“ Spalte und da würde man sich dann letztendlich die Sachen reinziehen, auf die sich das, also auf die Experimente, auf die sich das Team letztendlich comitted hat. Also Sachen, die das Team ausprobieren möchte, um an einem Problem was zu ändern. Die würde man dann dort vorfinden. Also das wär dann im Prinzip auch eine Wanderung dieses Tickets. Also wenn ich jetzt in meine Spalte Possible Experiments ein Beispiel dieses Experiment habe, eben gitlab-ci einführen und ausprobieren, dann würde und das Team Commit sich darauf, dann würde dieses Ticket eben in die nächste Spalte das Commited wandern.

Alex: [00:31:08.86] Also zum Beispiel eine der Sachen, die ich immer empfehle ist wenn du die jetzt auf committed schiebst, setzt dir ein Zeitrahmen. Ja, ja, also bitte noch mal, ich will jetzt gitlab-ci ausprobieren. Okay, wir arbeiten eben mit gitlab, sagen wir mal. Dann sagen wir, wir probieren das jetzt zwei, drei Tage, probieren wir mal da was zu machen und gucken, welche Ergebnisse wir dabei erzielen. Aber auch wichtig müssen alle Experimente, die wir definiert haben, in die Commit Spalte kommen, Matthias?

Matthias: [00:31:45.92] Ob alle Experimente, die wir definiert haben, da rein müssen? Nein, die können auch erst mal in den Possible Experiments bleiben. Nur die, zu denen wir uns halt wirklich im Team sagen. Ja, das wollen wir ausprobieren. Die wandern nach Committed, alle anderen bleiben erst mal im Pool der möglichen Experimente.

Alex: [00:32:06.44] Meine Frage zielte ja, aber eher kann es passieren, dass wir mögliche Experimente definiert haben, die wir dann nie machen?

Matthias: [00:32:14.96] In meinen Augen ist das durchaus möglich.

Alex: [00:32:17.96] Und was passiert dann mit diesem Experiment?

Matthias: [00:32:20.45] Also ich würde sagen, entweder wenn das Problem gelöst wird und somit das Problem von Bord verschwindet, würden auch die Possible Experiments verschwinden. Aber solange es Probleme auf dem Board ist, würde ich auch die dazugehörigen Optionen und Experimente dort sehen.

Alex: [00:32:40.01] Es kann sein, dass wir sagen, wir haben drei Optionen, wir haben fünf, sechs possible Experiments. Wir commiten uns erst einmal auf zwei, um bei der Durchführung der zweite sagen Okay, das hilft uns, das übernehmen wir und jetzt machen wir keine Experimente mehr für diese, für dieses Thema. Dann betrachten die das Thema als erledigt. Er kann natürlich wiederkommen, aber erst mal kann man die vom Bord entfernen, wenn man so will. Nicht alle Experimente, die wir uns da ausgedacht haben, müssen ausgeführt werden auf Teufel komm raus, sondern wenn wir der Meinung sind, wir haben erst einmal genug, wenn es ist auch völlig legitim, die einfach nicht durchzuführen.

Matthias: [00:33:23.48] Ja, also wenn wir uns jetzt quasi auf ein Experiment committed haben und dem einen Zeitrahmen gegeben haben, also wann fangen wir an, wann hören wir damit auf? Dann kommt es eben zum Startzeitpunkt in die nächste Spalte, nämlich in die „Ongoing“ Spalte dort, wie der Name im Prinzip sagt Wir werden eben alle Experimente, die gerade laufen, also die wirklich aktuell ausgeführt werden, werden dort gesammelt.

Alex: [00:33:51.38] Ja, auch da sind ein paar Sachen, die ich mit der Zeit gelernt habe, die meiner Meinung nach wichtig sind und ich möchte sie mal schnell erwähnen, und zwar während des „Ongoing“-Prozesses, also es ist ja der Zeitraum, in dem du ein Experiment durchführst. Wichtig ist für mich, es muss nicht das ganze Team am Experiment beteiligt sein. Es kann, aber es muss nicht. Ich kann mir im gleichen Zeitraum mehrere Experimente vornehmen, um unser Team in unterschiedliche kleinere Teams machen, die diese Experimente durchführen und dann berichten. Und dann auch diese Experimente. Wichtig der Zeitraum bitte kleinere Zeiträume, nicht Zeiträume, die über mehrere Wochen oder gar Monate hingehen, dann ist es vielleicht ein Experiment zu groß. Vielleicht kann man da kleinere Experimente daraus ableiten. Denkt daran, sie klein zu machen, so dass wir nicht allzu viel Investitionen haben. Wenn wir mal zu den Prinzipien, die nicht zu viel investieren, sondern nur kleine Einsätze machen.

Matthias: [00:34:58.96] Ja, kann ich bestätigen. Also zu lange Experimente sind auf jeden Fall nicht sinnvoll.

Alex: [00:35:06.14] Okay, dann nehmen wir uns das Ende.

Matthias: [00:35:09.80] Das Ende des Experiments nähert sich

Alex: [00:35:14.48] Das Ende des Boards eigentlich.

Matthias: [00:35:14.99] Ja, aber wenn jetzt in unserem Beispiel das Experiment dann zu Ende geht, ja und einen Abschluss gefunden hat, dann wandert es wieder in die nächste Spalte. Und das ist die „Review“-Spalte, in der man sich dann quasi im Team das Ganze nochmal anschaut. Was ist passiert? Was hat es uns gebracht? Sind unsere Erwartungen, die wir formuliert haben in unserem Experiment? Sind die eingetroffen? Wenn nicht, was können wir daraus lernen?

Alex: [00:35:42.05] Ja genau. Nach dem Experiment durch ist, muss man es bewerten und eben klarstellen. Haben wir das erreicht, was wir hoffen zu erreichen? Was haben wir dabei gelernt? Und es ist klar zu machen für uns alle, fürs Team.

Matthias: [00:35:57.71] Genau. Und am Ende von dem Review Prozess kann man dann im Prinzip eben auch noch nächste Schritte definieren. Also was man als nächstes gern machen würde. Und wenn da etwas bei rauskommt, würde das in der letzten Spalte des Popcorn-Boards landen, nämlich der „Next“-Spalte.

Alex: [00:36:19.93] Ich ich habe es verstanden. Nach dem Review Spalte kommt dann die nächste Spalte. Aber was landet in der „Next“?

Matthias: [00:36:25.61] Na ja, also wenn ich jetzt eben am Ende des Reviews bin, also von meinem, von meinem Experiment, dann kann ich ja möglicherweise weitere Schritte ableiten. Also wenn wir jetzt wieder beim CI-Beispiel bleiben, da hat sich jetzt jemand in dem Experiment eben damit beschäftigt, gitlab-ci überhaupt mal anzubinden, zum Laufen zu bringen und eventuell das auch mal das Projekt gebaut wird oder so was. Aber es ist halt vielleicht noch kein Deployment oder so dabei und dann könnte ja nächster Schritt sein. Hey, wir versuchen jetzt hat sie das soweit zu bringen, dass wir wirklich auch bei jedem Mal wenn es läuft auch deployt wird.

Alex: [00:37:06.77] Also weiterführende Experimente sozusagen. Wir sagen Experiment, die wir hier durchgeführt, des sieht gut aus. Das scheint in die Richtung zu gehen, reicht aber noch nicht. Dann müssen wir noch eins drauflegen und das machen wir. Das packen wir in die „Next“-Spalte. Ok, weitere Experimente,

Matthias: [00:37:24.95] Weil es muss jetzt natürlich auch nicht sein, dass ein Experiment reicht, um ein Problem von den Boards verschwinden zu lassen, sondern wie wir ja auch die ganze Zeit schon gesagt haben, wollen wir ja möglichst kleine Schritte machen. Also das heißt, wir wollen vielleicht mit einem Experiment gar nicht das ganze Problem gleich erschlagen, sondern erst mal gucken, ob die Richtung die richtige ist. Und dafür eben dann diese Next Step sozusagen.

Alex: [00:37:51.94] Und was ich öfters festgestellt habe ist, wenn ich in der Review-Phase bin und den anderen Teammitglieder erkläre, was in dem Experiment passiert ist oder was wir mit dem anderen Kollegen gemacht haben. Da entstehen manchmal neue Ideen, neue Sachen die man versuchen kann, neue possible Experiments. Ja und die sind auch es wert, dass wir entweder direkt in „Possible Experiments“ die hängen oder dass wir in die „Next“-Spalte festhalten, dass da noch andere Sachen andere Möglichkeiten haben. Oder auch der Ergebnis war so gut, dass wir entschieden haben, ab sofort oder ab XYZ wollen wir das für alle im Team freigeben, sozusagen. Das wir des offiziell übernehmen und in dem Team nutzen. Das sind Sachen, die für mich in die „Next“-Spalte dann gehören.

Matthias: [00:38:50.73] Genau sind wir durch. Und wenn man sich jetzt das ganze Board mal so bildlich vorstellt mit den sieben Spalten, dann sieht man auch, warum der Flow oder das Board Popcorn heißt, denn die Anfangsbuchstaben aller Spalten ergeben einfach das Wort Popcorn. Wäre dieses Mysterium auch gelöst.

Alex: [00:39:11.69] Jawoll! Noch mal kurz die Spalten anfangen von links nach rechts „Problems and Observations“ dann „Options“, „Possible Experiments“, „Commited“, „Ongoing“, „Review“ und „Next“. So kurz zusammenfassen Popcorn Flow. Welche Erfahrungen hast du damit gemacht? Hast du Erfahrungen damit gemacht?

Matthias: [00:39:35.00] Ja, so ist es ja. Also ich habe das ja auch in einer der letzten Folgen erwähnt, dass ich das in dem Team, in dem ich aktuell arbeite, setzen wir das ein und wir haben damit quasi unsere teaminternen Retros ersetzt. Also wir haben nicht einmal am Sprint Ende irgendwie so ein Retro, so eine Retro, wo wir uns dann zusammensetzen und uns sagen, was uns die letzten zwei Wochen irgendwie nicht gepasst hat, sondern wir haben das quasi eben durch das Popcorn Board ersetzt. Und ja, ich muss sagen, wir machen das jetzt seit knapp zwei Jahren, würde ich sagen fast ja, kommt hin, glaube ich und hat sich echt bewährt bei uns. Also gerade wenn man jetzt die letzten zwei Jahre eben mit Pandemie und allem betrachtet, haben wir da durchaus einige Verbesserungen mit dem Popcorn Board erreicht, wie jetzt zum Beispiel. Also Wir hatten zum Beispiel Team intern das Problem, dass die Issues, die im GitLab waren, die waren nicht besonders gut gepflegt. Also da waren dann irgendwie nur Titel drinnen und niemand wusste so genau, was zu tun war, wenn man nicht sehr spezielle Personen gefragt hatte. Und das war dann so eines der ersten Themen, die wir auf dem Popcorn Board mal hatten, dass das eben besser gehen muss. Und dann haben wir da eben Experimente gehabt, wie zum Beispiel Wir werden jetzt einen Sprint lang in dem Planning gemeinsam als Team diese Issues erstellen, befüllen mit Informationen alle, die wir haben und hatten einfach so die Erwartung. Dann würde es quasi leichter fallen, gerade eben durch die Remote Arbeit, wo du nicht mehr im selben Büro sitzt, unabhängig voneinander arbeiten zu können. Also das auch, wenn mal jemand außerhalb der normalen Arbeitszeiten vielleicht gerade online ist und irgendwie ne Stunde arbeitet, dass der auch weiß, was zu tun ist. Und das war zum Beispiel ein sehr erfolgreiches Experiment, das dann auch eben letztlich das Problem irgendwo gelöst hat also und auch beibehalten wurde. Also das funktioniert ganz gut, finde ich.

Alex: [00:41:52.22] Ein tolles Experiment, eine gute Sache. Das einzige, was mir nicht gefällt, ist, dass du gesagt hast, dass der zeitliche Rahmen, in den der Experiment gesteckt war. Das finde ich ein bisschen lang für ein Experiment

Matthias: [00:42:08.00] Ein Sprint jetzt, meinst du?

Alex: [00:42:08.30] Ja auf zwei, drei, vier Wochen finde ich, wie lange der Sprint ist. Aber vielleicht ja kürzer ist manchmal besser.

Matthias: [00:42:17.99] Ja, okay, aber sich gerade bei so einem speziellen Experiment, wie das halt gemeinsam in einem Planing etwas machst, ist halt ja. Also klar, man hätte jetzt sagen können, man macht es einmal im Planning und macht dann direkt eine halbe Woche später oder so das Review, ob das jetzt schon gepasst hat oder nicht. Das wäre eventuell dann noch was gewesen, wo man die Zeit hätte verkürzen können, nehme ich mal mit so. In unseren nächsten Popcorn-Boards. Ich lerne ja auch gerne dazu. Gut, genau. Und ansonsten was haben wir noch so Sachen gemacht? Also hat zum Beispiel auch grundsätzlich allgemein diese ganze digitale Arbeit mit GitLab, was alles, was man vorher halt am physischen Board hatte. Und auf einmal, wenn man im Homeoffice sitzt, hat man dieses physische Board nicht mehr. Also da haben wir ganz viel über den Popcorn Prozess dann letztendlich ins GitLab migriert, also dass auch dort wirklich ersichtlich ist wer hat welches Ticket zu welcher Zeit, damit man einfach auch nicht doppelt an Sachen arbeitet und solche Geschichten. Und das hat zum Beispiel wunderbar funktioniert bei uns mit dem Popcorn Prozess diese ganzen Sachen ja zu verbessern.

Alex: [00:43:33.63] Na super, dann zeig ich noch was dazu. Und zwar zusammenfassend sozusagen. Was ist für mich im Popcorn wichtig, abgesehen von viele andere Sachen und war eine der für mich wichtigeren Sachen ist viele Experimente durchführen, die wenig kosten, wenig kosten in Zeit, wenig Kosten und Ressourcen, wenig Kosten im Allgemeinen, weil viele Experimente mit wenig Kosten bedeutet einerseits Fehlschläge sind nicht teuer und zweitens, je kleiner die Experimente sind, desto mehr kann ich durchführen und desto mehr Experimente ich durchführe, desto größer ist die Möglichkeit, dass ich irgendwas entdecke, das mir hilft. Das zweite ist in Teams, in denen ich das Popcorn-Board mit eingeführt habe. Das ist nicht ganz einfach, sich da einzulassen und sich da einzuarbeiten. Ja, ich habe festgestellt, am Anfang, es ist vielleicht ein schwieriger, ein bisschen schwierig, ordentliche Probleme auf die Reihe zu bekommen oder mehr als nur eine oder höchstens zwei Optionen zu finden. Aber mit der Zeit wird das besser. Mit der Zeit lernen wir auch selber in dem Prozess zu leben. Zum Beispiel irgendwas, was sehr oft passiert oder mir ist ja oft passiert. Ist es das, Probleme werden ausschließlich eingetippt an den Tag, wo wir uns das Pocornboard anschauen. Und die Verbesserung, die da die Zeit mit einschleift, ist, dass man sich daran gewöhnt, mit der Zeit eben Probleme und Anmerkungen in Sachen einfach sobald man dran denkt, einfach in dem Popcorn Board reinzugehen mit Titeln, ein bisschen was ich mir dabei gedacht habe und einfach sofort das rein zu tun, weil zumindest ich habe das Problem, wenn ich es nicht sofort habe, dann habe ich es am Tag danach vergessen, dass ich das machen wollte.

Alex: [00:45:44.95] Und dieses Problem fällt vielleicht runter und wir adressieren es nicht, weil keiner mehr daran denkt das Problem einzuführen. Also ist es auch eine schöne Sache, die ich – Am Anfang ist vielleicht ein bisschen holprig, ein bisschen schwierig, aber mit der Zeit sind wir bis jetzt mit allen Teams, wo ich das mal ausprobiert habe, sind wir gut zurechtgekommen und haben uns deutlich verbessert. Als Beispiel würde ich vielleicht noch ein kleine Experiment bzw. eine kleine Geschichte erzählen. In einem Scrum Team, in dem ich mitgewirkt habe, hatten wir das Problem, dass die Planings ewig lang gedauert haben. Also die 2-4 Stunden Planings haben nicht gereicht, um da ordentlich ein ordentlichem Planning rauszubekommen. Nicht immer, aber sehr oft. Und dabei haben wir drüber diskutiert, unterschiedliche Optionen und Experimente gewagt und einer der Sachen, die mir gesagt haben ist ok. Anstatt dass wir nur diese Planings machen von Scrum wir machen jeden Tag nach dem Daily machen wir eine Viertelstunde 20 Minuten Refinement.

Alex: [00:47:02.68] Das heißt, wir nehmen uns ein Ticket und versuchen in 15 Minuten höchstens 20 Minuten den so weit zu bekommen, dass wir den ziehen könnten in den nächsten Sprint. Es hat dazu geführt, dass – Also das Experiment war ein Erfolg und hat dazu geführt, dass unser Planning dann in etwa 10, 15 halbe Stunde durch war, weil wir dadurch, dass wir jeden Tag ein bisschen Refinement gemacht haben und sein Ticket gemacht haben und das Ticket ein bisschen verfeinert. Am Tag danach haben wir noch weiter verfeinert, dass, wenn der Planning kam, hatten wir tatsächlich in der Liste der Aufgaben in unsere Backlog hatten wir eine Menge an Tickets, die so weit waren, die jeder verstanden hatte, wo wir alle ein gemeinsames Verständnis hatten, was es zu tun ist, um die wir dann ruckzuck einfach sagen könnten Ok, bis Sie den nächsten Sprint aus. Wie viel Leute ist da? Wie können wir arbeiten? Der PO hat die schon fertige im Sinne von geklärt, alle Tickets schon sortiert? Und dann nehmen wir so weit, so viele, wie wir uns committen können, dass wir in den nächsten Sprint machen können. Es hat in meinen Augen sehr gut funktioniert.

Matthias: [00:48:18.55] Ja, vielleicht klau ich, die Idee klingt echt gut. Ich meine, letztendlich machen wir das, was ich jetzt vorhinb erwähnt hab, mit einmal im Planning quasi. Das macht natürlich das Planning dementsprechend länger. Des ist genau das Problem ist gerade geschildert, dass wir haben es zwar nicht in dem Maße. Wir reden jetzt nicht über zwei, drei, vier Stunden, sondern halt eher eine Stunde. Aber wenn man die Zeit noch mal reduzieren kann und danach trotzdem vielleicht sogar noch bessere Issues hat, weil man kürzer drüber nach. Also kürzere Zeit aber nur ein Issue sich immer anguckt, im Zweifel in der Viertelstunde, dann kann es durchaus cool sein. Gefällt mir die Idee.

Alex: [00:49:05.66] Also wir haben an Refinement Zeit haben mir nichts gespart, wenn wir ein oder eine halbe Stunde die Woche hatten und wir jetzt jeden Tag für eine Stunde oder 20 Minuten machen. Zeit spar ma nicht?

Matthias: [00:49:16.36] Ja, aber du, man darf ja jetzt auch nicht unterschätzen, wie die Aufmerksamkeit nachlässt, wenn man in eine 4 Stunden Termin sitzt.

Alex: [00:49:26.70] Was fürs Team cool war, es – das Gefühl schneller voranzukommen war da. Ich weiß – ich habe es nicht gemessen. Ich weiß nicht, ob es tatsächlich schneller waren oder nicht waren, aber zumindest hatten wir das Gefühl, dass wir schneller sind.

Matthias: [00:49:43.88] Klar, wie gesagt, ich kann mir durchaus vorstellen, dass auch einfach dadurch, dass du halt öfters, aber dafür nicht so lang dich mit sowas beschäftigen muss, das einfach auch vielleicht nicht so anstrengend ist. Also vielleicht sogar erholsamer

Alex: [00:49:55.74] Und vor allem die unsere Planing-Zeiten haben sich total krass reduziert. Im schlimmsten Fall könnten wir in 5 bis 10 Minuten Tickets für den nächsten Sprint bereit haben, sodass wir loslegen können.

Matthias: [00:50:09.96] Das glaube ich.

Alex: [00:50:11.58] Des wurde als so ein Mehrwert empfunden, dass ein bisschen mehr Zeit, die wir für die Refinements vielleicht angewendet haben, einfach total gut investiert war.

Matthias: [00:50:23.25] Und hiermit sind wir nicht nur am Ende des Popcorn Flows und Alex seiner Geschichte angekommen,

Alex: [00:50:28.77] Sondern auch am Ende unsere Folge.

Matthias: [00:50:31.65] Wenn die Methode für dich und dein Team interessant klingt, kannst du ja für den Anfang ihnen einfach mal diese Folge empfehlen,

Alex: [00:50:38.61] Damit auch ihr euch immer weiter verbessern könnt.

Matthias: [00:50:42.78] Und um in Zukunft keine Folge zu verpassen, abonniere einfach unseren Podcast.

Alex: [00:50:47.88] Jawoll. Beim nächsten Mal werden wir über Retrospektiven reden. Wir freuen uns auf dich. Ciao

Matthias: [00:50:55.20] Ciao.

off: [00:50:59.80] Die Macht der Kraft arbeitet für dich.