Na ja, aber wenn wir es jetzt 3 Wochen machen, dann können wir das ja in Ruhe fertig machen und dann machen wir einfach 3, also 3 Wochen. Da hast du halt auch Zeit wirklich mal was abzuarbeiten. Ja, richtig, richtig hat man dann nämlich auch. Dann hat man. Deinem Podcast rund um die Softwareentwicklung und aktueller Tech News. Herzlich Willkommen.
Herzlich Willkommen zur neuen Folge vom Coding Buddies Podcast. Die Gastgeber hier sind wieder am Start, das bin ich, der Fabi und natürlich Tino und den Begrüß ich jetzt ganz herzlich Tino schön dich zu sehen, schön dich zu hören, wie geht es dir? Hi Fabi, ja mir geht's gut. Alles super. Ich habe Bock wie immer, ich bin motiviert, ich bin auch wieder sehr angetan von deiner Einleitung. Sehr schön. Sehr schön. Kurz, prägnant, wie man so schön
sagt, gefällt mir ja auch. Herzlich Willkommen an dich, Liebe zuhören, liebe Zuhörer, schön, dass du wieder eingeschaltet hast. Und ja, fabi, erzähl doch mal. Was geht denn bei dir so ab? Ist bei dir auch alles schick? Alles schick Job irgendwie, bin gut gelaunt. Können wir direkt losstarten in der Folge? Auch wenn das Thema jetzt n bisschen ernster wird. Oh, du hast n ernstes Thema mitgebracht, wie ernst auf einer Skala von 1 bis 10. 9,87 Periode.
Steamperiode krass. Also das ist ein sehr besonderes Thema. Scheinbar. Nein, also es ist, es ist jetzt kein ernstes Thema, es ist auf jeden Fall einfach. Es ist aber ein Thema, was. Mich und ich glaube dich auch schon das ein oder andere mal ein bisschen getriggert hat oder mal so weiß ich nicht. Also ich glaube man hat halt einfach so sein Paintpoint mit diesem Thema unter Umständen. Und es geht quasi genau.
Es geht um grober Kontext, agile Softwareentwicklung und es geht darum, dass man ja in agilen Softwareentwicklung, wie zum Beispiel bei Scrum. Kann man jetzt ein Framework nutzen, was man möchte? Da geht es ja darum, dass man in sogenannten Iterationen arbeitet, also Scrum nennt man zum Beispiel Sprint, und die haben ja eine definierte Länge und. Was mir mal so aufgefallen ist, was man ja auch am eigenen Leibe gerne mal erlebt ist und.
Dass diese Iteration, die der Theorie nach kurz gehalten werden sollen, gerne mal in die Länge gezogen werden, ne, damit meine ich sowas wie OK, die Theorie sagt OK, ne Iteration hat eine Woche oder 2 oder was auch immer und. Dann wird gerne, sage ich jetzt mal von den Protagonisten im Team gesagt, lass uns doch mal eine Iteration vielleicht ein bisschen länger machen. Das ist aber ganz schön kurz und so weiter und warum genau diese Theorie und die Praxis dann so
auseinander driften, also. Kurze Iteration der Theorie nach die Praxis hält es aber schon so, dass die Iteration häufig länger gehalten werden oder die Tendenz dahin geht. Und da würde ich mich gerne mal mit dir ein bisschen darüber unterhalten. Wieso das so ist, also quasi n paar Fragen klären. Also erstmal, warum ist es überhaupt sinnvoll kurzsituationen zu verwenden?
Warum wird es häufig nicht so gemacht, was kann man tun, damit es so ist oder damit es gelingt und halt auch ein bisschen gucken was unsere Erfahrung damit sind, was hältst du davon?
Ja, können wir gerne machen. Das ist ein ganz, ganz spannendes Thema, das haben wir auch in einer Twitch session ja mal schon mal ein bisschen angerissen mit der Community und da gibt es halt viele Meinung beziehungsweise wie du schon so meinst, viele haben da so ihren Pain mit und negative Erfahrungen gemacht wie ihr selbst. Ja auch deswegen können wir auch mal selbst ein bisschen berichten, was wir da so erlebt haben.
Noch mal kurz zur Eingliederung für diejenigen, die nicht wissen, was wir jetzt mit agil und Iteration meinen. Also ganz grob gesagt, wie du ja schon meintest, es geht um Zeitabschnitt, indem man quasi festlegt, was man innerhalb dieser Zeit erreichen möchte in der. Ja, bei uns jetzt in der Softwareentwicklung zum Beispiel am Produkt neue Features implementieren. Man legt sich dann darauf fest, dass man sagt, OK, wir haben das jetzt geplant, die nächsten 2 Wochen und das und das wollen
wir in der Zeit erreichen. Und ja, dann gibt es ja wie jetzt bei Scrum teilweise, sagen wir mal, noch andere Termine, die da dann noch einspielen. Da würde ich jetzt nicht drauf eingehen, aber das man mal grob weiß warum es worum es geht, weil daran kann man denn auch immer schon ganz gut. Lernen, was ist denn so eine Ursache oder ein Grund, warum dann so diese Aufruhr kommt oder beziehungsweise der Aufschrei mit. Dem sage ich mal so unterschwelligen. Na ja, aber hätten wir jetzt
noch ne Woche länger, also. 3 Tage wär schon besser. Also irgendwie ist das ja auch alles ganz schön zeitlich eng hier und dann haben wir wie gesagt noch diese randtermine wir müssen immer alle 2 Wochen planen, wenn man jetzt sagt, man hat jetzt eine Iteration von 2 Wochen, da müssen wir jetzt schon wieder planen, wir haben das alte aber noch nicht mal fertig, ach irgendwie, irgendwie kommen wir nicht wirklich, wir
arbeiten nicht effektiv. Es sind so viele Termine in dieser, in dieser Zeit. Wollen wir nicht vielleicht. Diese Zeiteinheit ein bisschen verlängern, damit man nicht
immer so viele Termine hat. Genau in die Richtung und der Ursprung da drin ist ja im Prinzip ganz einfach gesagt, man plant etwas auf, also man verwendet, denn sage ich mal dieses Framework und in der Theorie klingt das gut, in der Praxis wird es dann aber schlecht umgesetzt bzw nicht unbedingt schlecht umgesetzt, kann ja auch mangels fehlende Erfahrung sein. Es läuft aber nicht rund. Mal ganz einfach auf den Punkt gebracht.
Das heißt, es kommen Probleme auf, beispielsweise wie eben schon angeschnitten, man schafft nicht das, was man aufgeplant hat in dieser Iteration. Ganz großer Klassiker wird jeder kennen, wird jeder, auch wahrscheinlich immer noch erleben. Also ich hab die jetzt persönlich und ich glaube es geht dir auch so, es noch nicht erlebt, dass man jetzt irgendwie jede Planung die man macht komplett einhält und sagt Na ja ist klar man.
Sagen wir mal 34 Iteration läuft es nicht rund, aber danach weiß ich ganz genau, was ich planen kann und es schaff immer was ich da mir vornehme. Ne, also das ist ja n Painpoint der Real ist für alle da hab ich mich mal so weit aus dem Fenster
legt. Das ist ja glaub ich auch ne Sache, mit der man einfach generell dealen muss und aber genau aus diesen Gründen, also man ist ja nicht ohne Grund dahin gekommen, dass man sagt, der Theorie nach ist es zum Beispiel sinnvoll Kurzsituation zu haben, weil. Man ja wahrscheinlich genau aus diesem Pain, den du gerade beschrieben hast, sich gedacht hat okay, wir müssen mal irgendwie gucken, dass wir was ändern.
Das ist zumindest immer so meine Vermutung, dass solche Sachen quasi etabliert werden oder sich ausgedacht werden, weil halt irgendwas nicht so läuft, wie man sich das gerne vorstellt. Gerade auch nochmal, weil du gesagt hattest, sozusagen diese ganze agile Umgebung, Termine, die da reinfallen, da haben wir auch schon mal eine Folge gemacht. Liebe Zuhörerin, lieber Zuhörer, falls sich das interessiert, kannst du einfach noch mal ein bisschen ein paar Folgen
zurückgehen. Und da kannst du dir das auch noch mal ein bisschen genauer anhören. Genau. Aber lass uns da erstmal gucken. Tino, Wieso gibt es denn überhaupt diese Überlegung zu sagen, diese diese der Theorie nach, dass man sagt, OK, wieso wollen wir denn jetzt beispielsweise? Wie solche Iterationen nenne ich es jetzt mal. Wieso soll man die denn kürzer halten?
Ne? Also man könnte sich ja hinstellen, wir haben ja gesagt, OK, es kommt dann so kommen dann so Sachen auf wie ja gut du hast ne Iteration von ein 2 Wochen und du musst bestimmte Termine innerhalb diese dieser Iteration immer abhandeln, dann kommen halt so gibt's halt zum Beispiel so einen allgemeinen Tenor gerne mal, dass das heißt ja. Hat man ja schon wieder diese ganzen Termine. Aber wieso ist es denn interessant feedbackzyklen Feedback? Jetzt hab ich schon gesagt.
Also Iteration kurz zu halten. Um kurze Feedbackzugeben. Erklären also in der Theorie geht es natürlich darum, dass du das kurz hältst, kurz hältst. Mensch, meine Güte, damit du halt wirklich schnell n Feedback bekommst, dass du halt nicht so batch mäßig arbeitest wie in der alten Welt, dass du sagst okay, wir ziehen es jetzt erst mal durch und am Ende irgendwann. Release nah, sage ich mal. In 6 Monaten kriegen wir mal ein Feedback zu dem, was wir getan haben.
Das ist halt der worst case, weil wenn dann was nicht stimmt rollst du es halt komplett von vorne auf und das frisst enorm Zeit. Das sind so die Painpoints, weshalb das Ganze so alles auch quasi so dieses agile entstanden ist, dass man sagt okay wir wollen aber schnell wissen ob was nicht stimmt, wir wollen schnelles Feedback auch von anderen Teams von anderen. Entwicklungen, die parallel passieren, wo wir auch vielleicht Abhängigkeiten zu
haben, weil der Worst case ist. Ja 2 Teams haben 2 Entwicklungsstränge, entwickeln Monate lang parallel und da fehlen aber irgendwelche Absprachen des Partners passt am Ende gar nicht zusammen. Dann merkst du es nach 6 Monaten, weil jeder vorhersagt. Na ja, wir machen unser Ding so ne. Du bist ja auch also unter anderem. Also diese teamzusammenarbeit find ich ist n gutes Beispiel, dass man quasi sich innerhalb des Teams in kurzen Zyklen sozusagen abspricht.
Zusätzlich ist es ja auch gut, wenn man jetzt zum Beispiel sagen wir mal, du arbeitest in deinem Team vielleicht mit anderen Teams und du rollst das Produkt, was du quasi an dem du entwickelst, auch regelmäßig an User aus, dann ist es natürlich auch sinnvoll, zum Beispiel auch von den Usern Feedback zu
kriegen und. Zwar in kürzester Zeit, weil wenn du jetzt zum Beispiel sagst okay, ich finde dein Beispiel ganz gut, du arbeitest relativ lange zum Beispiel an einer App beispielsweise, und sagst dann okay und jetzt, nach einem Jahr Arbeit rollen wir diese App an die User aus und dann merkst du auf einmal, nach einem Jahr kriegst du Feedback von den Usern, dass du eigentlich an der Sache, an der du gearbeitet hast, was diese App eigentlich machen soll, komplett vorbei
gearbeitet hast. Dass du sagst, okay, das ist ja auch öfter mal sowas was also ich glaube, sowas kennt man das. Sozusagen die Intention von dem, was also sozusagen erst erstellt werden sollte, komplett von den vor an den Vorstellungen vorbeigeht, was die User sich beispielsweise vorstellen und auch zum Beispiel haben wir auch schon mal drüber. Geredet Uiux die Usability. Und so weiter.
Alles Feedback, Sachen, die man sich gerne einholen kann, die wichtig sind und die auch am besten in kürzester Zeit kommen sollen, damit man schnell weiß, in welche Richtung soll denn die
Entwicklung weitergehen? Ja, oder ob dann nur halt dynamische Projekte hast, wo sich Anforderungen noch oft ändern oder vielleicht noch gar nicht so klar sind, dann brauchst du halt die Möglichkeit schnell darauf auf Änderungen reagieren zu können und dann sind halt so kurze Zyklen einfach enorm wichtig und hilfreich, um halt auch diese Agilität im Team zu haben, darauf reagieren zu können und nicht zu sagen, wir entwickeln jetzt erstmal unseren Plan nach
Meilensteinen durch und in einem Jahr können wir noch mal sprechen und werfen dann alles weg, was wir bis dahin gemacht haben, weil du jetzt schon weißt als Stakeholder, du möchtest eigentlich. Was haben ja genau. So und da das ist, das sind so mal grob umfasst, wie gesagt, Wir haben ja schon mal ne Folge dazu gemacht, so die Punkte, warum kurze Zyklen einfach aus der Theorie her wichtig sind und jetzt ist halt die Frage, wir wissen. In der Theorie. Dass es richtig ist?
Genau. Mit wir mein ich alle Entwickler mal immer so n bisschen generalisierter wir. Wissen es alle. Und trotzdem kommt es ja immer wieder in Teams vor, dass halt wie gesagt es so n bisschen brodelt, so n bisschen Unmut kommt auf und dann ah, aber eigentlich ist das auch zu kurz, wir brauchen längere Iteration,
weil bei unserem Projekt geht. Also ich versteh die Theorie, aber bei unserem Projekt können wir das so nicht machen, weil wir haben halt einfach viel zu viel von den Seiten irgendwelche Feuer und wir haben halt ganz ganz besondere Anforderungen, weshalb wir jetzt bitte nicht 2 Wochen machen sondern 4 Wochen. Beispielsweise. Das kennt jeder, hat bestimmt jeder auch schon mal erlebt, auch immer dieses.
Bei unserem Projekt geht das halt nicht, das will ich halt auch immer geil so, dieses ja nee ich verstehe das, aber bei uns geht das nicht, tut mir leid, wir können nicht agil arbeiten. Das ist auch eine Sache. Definitiv. Wo ich immer. Mir denke so okay, ich stecke da nicht drin, das stimmt, da muss man ja auch sagen so, aber was ich mal ein bisschen schwierig finde ist, dass ich dann das Gefühl habe, dass.
Wenn solche Aussagen getätigt werden, dass nicht mal hinterfragt wird, also dieses, das geht nicht, oder wie geht es? Oder wie könnte es gehen? Weißt du das das das fehlt mir dann manchmal so dieses Umdenken von ja das geht nicht, wie sollen wir das denn? Also ne also wirklich mal zu gucken OK wie könnte man angenommen du möchtest einen Wunschzustand herstellen, wie
könnte man da hinkommen? Und dann kommt man meistens schon mal n bisschen mehr in die Richtung, in die man vielleicht doch eigentlich gerne kommen möchte.
Aber vielleicht ist der Painpoint, der auch einfach noch nicht groß genug an der Stelle. Ja, also wie gesagt, es handelt sich ja auch um nen Framework. Man kann seinen Platz da drin suchen und das auch adaptieren, du musst es ja nicht Anführungsstriche gedanklich in nach Lehrbuch machen, sondern quasi dieses Mindset nehmen und dann deinen Platz da drin finden. Das heißt du musst ja nicht alles gut finden, was jetzt das Manifest von Scrum da sagt oder
aber du kannst ja einfach diese. Techniken sage ich mal. Oder Prinzipien annehmen und dann einfach für dich adaptieren, aber nicht gleich sagen, so, ja nee, bei unseren Gegebenheiten geht das halt nicht.
Kann man ja auch noch ein bisschen differenzieren, so, wenn das gut funktioniert, sage ich jetzt mal das Projekt, das Unternehmen oder was auch immer, was dann quasi so arbeitet wie es arbeitet und zum Beispiel sagt, Ja, das funktioniert bei uns nicht, wenn es aber gut läuft, dann denke ich mir so, ja okay, ihr braucht wahrscheinlich auch nichts damit.
Damit ihr das Macht. Aber blöd ist halt, wenn man zum Beispiel auf der einen Seite sagt, ja, das und das, und hier gibt es. Probleme und da gibt es Probleme und dann wird hier gemeckert und dann wird aber gesagt, ja, aber ändern können wir nichts so das ist, das ist dann halt immer dieses Ding wo wo man dann vielleicht sich mal überlegen könnte, OK, vielleicht mal was ändern so ne. Aber also ist n fairer Punkt zu sagen okay wenn natürlich alles rund läuft, Never Change a running System.
Das verstehe ich auch und du musst ja nicht nur weil es gehypt ist oder die letzten Jahre gehyped war. Jetzt ein agiles Framework etablieren, wenn es eigentlich rund läuft, weil wie gesagt auch nicht für jedes Projekt ist das
was. Deswegen haben wir jetzt auch noch mal abgesteckt, wenn du zum Beispiel wirklich sehr dynamisch unterwegs bist, oft Änderungen hast, dann macht es halt Sinn, nach agilen Konzepten zu arbeiten und das ist ja auch unser Fokus und jetzt kommt es, so sagen wir mal, gehen wir mal von Firma XY aus mit mehreren Teams und die Stellen das um und am Anfang finden alle ziemlich motiviert.
Und dann merken Sie halt okay wir haben jetzt Iteration von 2 Wochen und die erste Iteration haben wir gerissen. Okay ja Mist haben wir überplant, haben uns zu viel vorgenommen. Das passt nicht so. N bisschen Unmut ist drin, aber die Motivation ist noch hoch. Das passiert noch mal ein 2. Iteration und ja, irgendwie wird es besser, aber auch man das nervt, ich will das fertig machen und was jetzt muss ich schon wieder planen fürs für die nächste Iteration ich hab hier aber noch 23.
Themen offen von der letzten, also was wollt ihr eigentlich von mir? Genau das ist dieses diese wie soll ich sagen, diese Entstehung bei den Mitarbeitern die oder bei den Kollegen die halt schnell auftritt. Weil dann einfach Unmut aufkommt. Und dann geht es halt so los mit. Na ja, aber wenn wir es jetzt 3 Wochen machen, dann können wir das ja in Ruhe fertig machen und dann machen wir einfach 3, also 3 Wochen, da hast du halt auch Zeit wirklich mal was
abzuarbeiten. Ja, richtig, richtig hat man dann nämlich auch. Dann hat man ja gut 3 Wochen sind super. Nein, aber das Problem ist ja Spaß. Welchen Rattenschwanz zieht das mit sich, das ist ja wirklich n Hamsterrad am Ende, das heißt? Du. Du gehst jetzt den Weg zu sagen, wir brauchen mehr Zeit, weil wir haben uns überplant.
Ja, das ist wirklich n Klassiker, lass mal diesen Klassiker nehmen, wir sind überplant gewesen, wir haben es nicht geschafft, wir haben Sachen committed auch an andere Teams, die wir nicht einhalten können, kommt nicht cool an, verstehe ich absolut in Ordnung, ist nicht cool, jetzt gehst du halt in den Modus und sagst was können wir ändern, wir müssen jetzt hier wir müssen ins Laufen kommen weil wir haben auch noch projektdruck das heißt die Obrigkeit, nein.
Zum Beispiel die Stakeholder fangen an, Druck zu machen. Auch ein ganz großer Klassiker dabei, so RA hier kommt ihr habt gesagt, ihr schafft das in der Zeit, es ist nicht fertig.
Was war das Problem, woran lag es, wenn sie wenigstens fragen, woran lag es, wäre schon Fortschritt meistens fragen sie nicht, woran lag es aber, dass dann halt Druck noch dazu kommt, so, und dann geht's los naja gut, wir machen jetzt 3 Wochen, wir machen jetzt 3 Wochen, dann haben wir mehr Zeit, wir planen so wie wir planen, aber wir haben 3 Wochen Zeit das abzuarbeiten, das heißt wir wir haben ja dann schon mal 50% bin ich jetzt richtig weniger plannings, weniger Reviews, das
müssen wir auch nicht mehr so oft ne Retro machen. Das ist halt genau der.es. Sind halt dann am Ende, sind also das das find ich ist ist immer das witzige ne es sind ja am Ende. Sind ja die Sündenböcke, diese Meetings, die aus dem Framework entstanden sind oder die mit dem Framework mit diesem agilen Framework einhergehen. Das sind auf einmal die Sündenböcke, wieso es gerade nicht richtig läuft und. Was ich so spannend an der ganzen Geschichte finde ist, du fängst an und sagst es läuft
aktuell nicht. Deswegen versuchen wir eine neue Art und Weise der Arbeitsmethode. Wir benutzen ein Framework, wir benutzen zum Beispiel Scrum oder irgendwas anderes, du kannst auch nach XP arbeiten, also Extreme Programming ist auch ein agiles Framework, ähnlich wie Scrum, aber ein bisschen anders, aber nur mal um was anderes reinzubringen. Deswegen heißt es auch anders. Wahrscheinlich. Guter Punkt, guter Punkt.
Macht man nichts vor. Also, und dann fängst du an und sagst okay lass uns mal was Neues nehmen, so wir benutzen jetzt Scrum und jetzt geht's los und auf einmal funktioniert irgendwas nicht richtig und witzigerweise auch in kürzester Zeit. Also es ist ja nicht so, als würde man sagen, ja, komm hier, lass mal scrum machen und und es läuft also keine Ahnung, du kannst ja auch irgendjemanden hinstellen, ich nehme jetzt mal wieder mein lieblingsbeispiel
Tennis spielen und sagst jemanden, guck mal hier, so funktioniert Tennis spielen, das ist die Theorie und jetzt ab dafür, dann bist du ja auch nicht auf einmal ein Roger Federer. Frage ist, so geht die Vorhand, sag es. So geht die Vorhand genau. Nee, aber weißt du, das ist das ist ja das Ding, du musst es ja auch genauso üben und lernen, aber der Unmut kommt rein, man merkt, OK, das funktioniert nicht so, es wird gerade nicht
besser. Und dann auf einmal fängt man an, das Framework, was man also was man eingesetzt hat, was man ja versucht hat um ne Besserung zu schaffen, als Sündenbock hinzustellen, dass es nicht funktioniert. Also fängt man wieder an. Schleichend oder schnell, je nachdem genauso zu arbeiten wie vorher. Und dann denkt man sich so, OK, keine Ahnung.
Also das ist ja irgendwie, das funktioniert ja auch nicht so richtig und es gibt so n schönen Leitsatz den ich mal gehört habe und zwar wenn du eine, wenn du etwas verändern möchtest, dann wird erstmal etwas langsamer bevor es schneller werden kann. Du musst ja erstmal diese Neuerungen sozusagen aufnehmen verarbeiten. Damit überhaupt sag ich mal, besser werden darin wachsen und dann kann es hinterher schneller werden, wenn du es quasi dann erlernt hast.
Mal blöd. Gesagt, also erstmal finde ich es cool, dass du dein Tennis Beispiel wieder angebracht hast. Das ist jetzt auch einfach schon so eine, so ein fester Bestandteil mittlerweile hier im Podcast. Aber ich glaube, ich habe lange nicht. Ja deswegen, es war mal wieder Zeit für das Tennisbeispiel und der Leitsatz, der gefällt mir auch sehr gut. Schön, dass du dir mal angebracht hast, weil der trifft es halt einfach so perfekt. Gerade wenn du in einem.
Etablierten Team anfängst, auf dieses Agile zu wechseln und du kommst halt so aus der alten Welt, dann braucht das richtig viel Zeit und dieses Mindset zu ändern. Weil das Spannende dabei ist, dieses Framework zum Beispiel Scrum, bietet ja feste Abläufe beziehungsweise nicht feste Abläufe, Vorschläge oder Termine. Auch mit, wie man sie gliedern könnte. Aufbauen könnte die extra dafür da sind, um aus Fehlern zu lernen, beispielsweise ne Retro. Genau.
Das heißt, du kriegst sogar schon an die Hand. Passt auf. Es wird. Am Anfang wird es ruckeln, ne und Turbulenzen geben, aber hier habt ihr nen Termin, da könnt ihr quasi analysieren und mal drüber sprechen. Was hat euch gefallen, was hat euch nicht gefallen, was müsste man besser machen, Punkte herauskristallisieren um halt einfach besser ins Laufen noch zu kommen und wie du so schön sagst oft kommt aber die Reaktion schleichend wieder in die alte Welt zurückzugehen.
Man sich denkt, so, ah nee, gar keine Lust, das jetzt wieder zu
machen. Das ist, das ist so ein innerer Kampf, du hast halt im Einerseits hast du im Kopf verdammt, ich muss noch fertig entwickeln, was ich offen habe, irgendein Feature, ich muss cohen, ich brauch wirklich Zeit zum Cohen jetzt und jetzt habe ich schon wieder einen Termin, jetzt soll ich auch noch in einer Retro sagen, dass ich gerade abgefuckt bin, weil ich eigentlich Cohen will, aber jetzt in diesen Termin rein muss, ja kannst du anbringen,
ist absolut valide das auch in der Retro anzubringen, weil man muss ja überlegen warum du als Entwickler. Hitler überhaupt in diese Situation gekommen bist. Dafür sind ja auch solche Termine dann da. Das ist ja der Witz dabei. Also man man baut ne Anti Haltung gegen die Lösung sozusagen auch n bisschen auf. Oder halt, wie du ja schon meinst, das was man halt mal versucht. Anders zu machen, weil das, was man vorher gemacht hat, ja offensichtlich nicht so
funktioniert hat. Es ist ja auch völlig valide zu sagen, nach einer gewissen Zeit Pass auf diese agile Arbeitsweise funktioniert wirklich nicht. In unserem Unternehmen. Kann sein, dass es projektabhängig klar, absolut valide, das wollen wir auch gar nicht in Frage stellen, aber dieser Fakt zu sagen, wir machen jetzt die Iteration, also wir bleiben in dem Framework, aber adaptieren ist quasi so hin, dass wir. Wieder so nahe der alten Welt kommen.
Also ich sag mal jetzt 1 eine Woche iteration, das ist diskutierbar. Ist kurz, verstehe ich. 2 Wochen finde ich persönlich ist ein gutes Maß 3 Wochen 4. Nee also so das wäre jetzt so meine persönliche Abstufung, mal ganz kurz auf den Punkt gebracht.
Wenn jetzt aber Leute anfangen diese Iteration noch größer zu machen, dann kannst du es dir halt auch echt klemmen, weil dann hast du diese Feedbackzyklen nicht mehr, wenn du sagst meine Iteration sind 8 Wochen, also grob 2 Monate und dann mache ich erst eine Retro, was vor 2 Monaten passiert ist und schief lief, das weiß ich doch alles gar nicht mehr. Also dann sind doch dann sind doch diese ganzen. Punkte auch nicht mehr, nicht mehr warm auf dem Tisch
sozusagen. Ja genau, das ist halt auf jeden Fall n wichtiger Punkt und ne ne Retro kann auch durchaus mal emotional werden, das ist ja auch OK, man sagt ja auch, es gibt ja so ne Regel. Die Las Vegas Regel so alles was ne Retro passiert bleibt doch in der Retro und ich find das an sich auch ganz gut und weil du gerade gesagt hast du magst zum Beispiel so 2 Wochen Iteration find ich an sich auch nicht
schlecht. Ich hab auch 5 Jahre ungefähr mit einwöchigen Iterationen gearbeitet und ich muss sagen es hat auch sehr gut funktioniert, die Frage ist immer wie ist es quasi abgesteckt weil das war wirklich ein Produktteam was das was wirklich zusammengearbeitet hat. Und jetzt nicht, nicht extrem Abhängigkeiten zu anderen Teams hatte. Das ist natürlich auch ein wichtiger Punkt. Das. Ist definitiv ein wichtiger Punkt. Und da waren einwöchige Iterationen auf jeden Fall
super. Also da bin ich richtig Fan von, muss ich auch sagen, wie gesagt kommt immer ein bisschen darauf
an, wie der wie der Kontext ist. Was ich aber super interessant fand war, dass auch wirklich in dieser Zeit wirklich sehr also das Mindset für agile Softwareentwicklung war auf jeden Fall schon sehr gut etabliert, muss ich sagen, nur was ich spannend fand war, dass trotzdem sowas kam wie zum Beispiel. War jetzt schon wieder ne Retro, ne also man wir haben auch wirklich dann jede Woche ne Retro gemacht und ich fand das sehr gut, da hat man immer mal
Momente wo man sich so denkt so boah ich bin gerade voll drin jetzt wieder retro gerade rausgerissen ja. Ist ja auch nur menschlich, oder?
Also genau, aber. Im Großen und Ganzen war das Halt meiner Meinung nach schon gut, weil erstens hast du auch mal ne gewisse Art von Pause, das heißt du machst mal wirklich was anderes und du kannst wirklich mal n bisschen überlegen, was ist denn eigentlich vielleicht, was ist gut gelaufen, was nicht so gut gelaufen, es geht ja auch vielleicht darum, mal wirklich Sachen zu auch rauszustellen, wo man sagt, das ist wirklich gut gelaufen, also eine Retro wird
ja oft so dargestellt, dass man immer nur sagt, Oh, das war doof, das war doof, das war doof, es ist ja kein reiner Meckertermin, es ist ja auch ein Termin, wo man auch mal sagen
kann, wir können uns feiern. Das, was wir gemacht haben und aber dann gucken, wieso ist das denn so gut geworden, so weißt du, dass man sagt, wieso sind Sachen nicht so gut und dann zu gucken, OK, warum ist das denn so und was können wir dagegen tun beziehungsweise warum ist war was war richtig gut und wieso ist es so gut geworden und was können wir beibehalten, damit es so gut bleibt, das sind ja so solche Sachen und ich finde es halt schwierig, zum Beispiel solche Retros sozusagen
abzulehnen, weil das ist eigentlich finde ich, selbst wenn du dich hinstellt und sagst, wir arbeiten nicht nach Scrum. Für unser Team nicht, finde ich sind Retros an sich eigentlich ne total Framework unabhängige Geschichte, weil ich mir denke wie gut ist das, wenn man sich regelmäßig hinsetzt, zusammen im Team und sagt was, wo gibt es
Optimierungspotenzial? Das ist einfach nur total wertvoll und natürlich muss man gucken, dass diese Termine gut laufen, sich einfach nur hinzustellen und zu sagen, das läuft blöd, ja was können wir dagegen machen? Oder du versuchst, Maßnahmen zu definieren, die am Ende nicht durchgeführt werden, die am Ende quasi nicht fruchten.
Das kann natürlich auch frustrierend sein, definitiv, und dann kommt man vielleicht irgendwann auch in diesen Modus zu sagen, warum denn jetzt schon wieder eine Retro bringt doch eh nichts, da darf es halt nicht hingehen, das ist halt, das ist halt die Schwierigkeit, aber da zum Beispiel, ich weiß nicht
man. Ein bisschen in die Lösungsrichtung gehen, weil ich finde zum Beispiel, dass gerade wenn man sagt, okay, warum kurze Iteration, warum funktioniert es oft nicht und was kann man dagegen tun? Allein schon, wenn man zum Beispiel sagt, OK, erst mal Retros machen, würde ich sagen. Ist auf jeden Fall ne wichtige Sache, aber wie ich schon meinte, einfach nur ne Retro machen. Bringt nicht so viel.
Wenn du nicht auch. Und da kommen jetzt zum Beispiel sowas wie agile Coaches oder Scrum Master oder ne, ich nenn das jetzt mal agile Coaches, weil das so n bisschen allgemeiner Begriff ist, die kommen da halt mit rein und du brauchst gute agile Coaches, weil ich hab auch so oft erlebt, dass. Leute, die halt. Also wenn du wirklich keine guten Agieren Coaches hast, dann funktioniert das Ganze auch nicht gut.
Ne die Leute die tragen das ja und ich hab manchmal auch n bisschen das Gefühl, dass es durchaus. Agile Coaches gibt die. Das selber gar nicht, wissen die selber vielleicht denken so ich mache hier nur so ein, Ich gucke ja nur, dass die Termine pünktlich anfangen und pünktlich aufhören, so weißt du und das ist es halt dann auch nicht so wie ich auch von Mitarbeitern Mitarbeiterinnen gehört habe.
Was machen die eigentlich den ganzen Tag so und das finde ich halt schwierig so, weil ich finde, dass es eine unglaublich wertvolle Rolle ist, die auch Teil der Lösung ist, um das richtig durchzusetzen. Sorry, jetzt habe ich eine Menge gequatscht, was? Sagst du dazu, ich habe dich ausreden lassen, alles gut, alles gut. Habe mir derzeit kurz einen Kaffee geholt. Nein, das waren ja wirklich viele wichtige Punkte.
Danke dafür, es ist halt, wie du schon sagst, also es ist leider auch oft so bei der Rolle agiler Coach, Scrum Master. Dass viele das auch so als Projekt oder Teamassistent sehen, so ja, sorgt halt dafür, dass sie Termine eingehalten werden, dass sie stattfinden, erinnert die Leute noch mal an irgendwelche Termine, aber das ist es ja nicht, es geht ja
darum. Diese Termine auch in die richtige Bahn zu lenken, die richtigen Denkanstöße zu geben, einfach auch mal Sachen zu Challengen und n richtig guter agiler Coach sorgt halt auch dafür, dass diese Iteration glaub ich nicht so lang werden. Also einfach nicht indem man da nen Riegel vorschiebt, das meine ich gar nicht, sondern das Mindset schärft. Warum es keine gute Idee wäre,
das jetzt zu tun? Ganz auf den Punkt gebracht, weil zum Beispiel. Also ich bin nicht die Rolle agiler Code, wir sind der Entwickler, aber wenn ich halt in diese Diskussion gerate, frage ich mich immer oder beziehungsweise mein Gegenüber, ja, was ist denn, was ist denn der Umkehrschluss dabei, wenn wir das jetzt verlängern? Also das Argument ist beispielsweise, ich möchte nicht jede Woche oder alle 2 Wochen retro machen, weil ich arbeiten muss. Dann machst du jetzt okay, dann
spielen wir es gedanklich durch. Wir machen jetzt ein 45 Wochen Sprint oder Iteration, das heißt wir. Halbierst jetzt erstmal die Anzahl der Termine aufs Jahr gerechnet grob pi mal Daumen ne. Ja genau das ist doch besser so
gut, dann kannst du aber fragen. Ja gut, nach 5 Wochen wie effektiv ist die Retro wenn du sagst ich muss jetzt die letzten 5 Wochen Revue passieren lassen und aber noch viel wichtiger wenn wir bei dem Zeitaspekt sind, wie lange wird wohl die Retro gehen wenn du 5 Wochen Revue passieren lassen musst im Vergleich zu einer Retro die nur auf 2 Wochen. Sich zurück bezieht. Allein schon du weißt nach 2 Wochen viel besser, was passiert ist.
Kannst es schneller auf den Punkt bringen und diskutieren. Ja, erstens ne und es ist. Logischerweise auch weniger Zeit vergangen. Das heißt, es kann also in 5 Wochen wird sehr wahrscheinlich viel mehr zu diskutieren sein als in 2 Wochen. Das ist ein Punkt der den ich da zum Beispiel anbringen würde oder ein anderer Punkt, der mir auch super oft schon begegnet ist. Deswegen hatten wir den auch vorhin. Thematisiert ist ja einfach dieses.
Wir schaffen unsere Aufgaben nicht, wir brauchen mehr Zeit, um sie abzuarbeiten. Dann ist ja das Kernproblem eigentlich in der Planung, dass man sich einfach über plant, dass man denkt, man schafft in 2 Wochen mehr, als eigentlich möglich ist. Statt an diesem Problem zu arbeiten, mit Hilfe von dem Review einer Retro das Kernproblem anzugehen, zu sagen, Wir haben mehr Zeit, macht es im Endeffekt nur schlimmer, weil deine Planung ist.
Nicht gedanklich. Die von 2 Wochen, die denn vielleicht reinfitted auf 3 Wochen. Sondern du fängst an, 3 Wochen zu verplanen, bist am Ende wieder übers Ziel geschossen und kannst noch ungenauer vorhersagen, was in 3 Wochen. Wer was in 3 Wochen möglich ist, ich mein das muss man sich ja gedanklich einfach nur vorstellen. Mach dir mal nen Essensplan für die nächsten 2 Monate oder oder sag mir mal was du in 4 Wochen worauf du Bock hast zu essen oder was weißt du?
Also das kannst du an sämtlichen Beispielen im Leben machen, da kommt doch ne super Ungenauigkeit rein. Ja, je weiter du in die Zukunft kommst, desto größer wird die, sozusagen die Varianz. Gern darüber sprechen, worauf du heute Abend Bock hast zu essen oder vielleicht noch morgen.
Aber nächste Woche denkst du dir so, ich weiß es nicht, ich stell mir noch nicht so einen komplizierten Fragen Mann ne, aber das ist also das ist doch ne ganz einfache Frage, wo denn eigentlich schon klar wird so ja okay also keine Ahnung okay es gibt Leute die haben festen Ernährungsplan für die nächsten 4 Wochen die Essen oder essen jeden Tag das gleiche. Die Snowfront aber ihr seid kurz da, jetzt Markus, genau ihr seid da mal kurz nicht involviert in diesem Beispiel.
Aber das Ding ist, es geht ja auch nicht. Also wenn du jetzt diese Planung nimmst, dann finde ich, je größer die Iteration werden, desto größer werden erfahrungsgemäß auch die einzelnen Aufgaben, die zu bewältigen sind. Also du sagst jetzt zum Beispiel nicht. Nur weil ich ne Iteration von 2 auf 4 Wochen Strecke, heißt das noch lange nicht, dass ich dann auf einmal 2 bis 4 Tasks habe. Mal beispielsweise, sondern halt
einfach doppelt so viele. Ne. Also man denkt sich also nicht doppelt soviel, sondern genauso viele, die aber einfach viel viel größer sind, weil man dann denkt okay was könnte ich denn schaffen? Naja, dass das und das ist so ein Topic ja dann mach doch mal dieses Topic sage ich jetzt mal in der nächsten Iteration, wie du ja schon meintest und dann über planst du dich vielleicht.
Genau, auch bei sowas finde ich, ist eine sehr wichtiger Lösungsschritt zu sagen, nimm deine Aufgaben die du hast und brich sie runter. Also wenn du jetzt und es gibt so oft die Möglichkeit, dass man das habe ich auf jeden Fall auch in der letzten Zeit in den letzten 567 Jahren gelernt, es ist oft so, dass du eine Aufgabe, die vermeintlich zusammengehört, nochmal splitten kannst.
Und wenn du dann zum Beispiel quasi nicht Aufgaben hast, die aus keine Ahnung. 10 to do s bestehen, sondern 10 Aufgaben hast, die aus einem Todes bestehen, dann macht das auch viel mehr Spaß, das abzuarbeiten. Kann man auch viel besser mit anderen Leuten über das Thema also reden, sich austauschen, weil der Kontext über diese eine Aufgabe eigentlich oder über dieses eine to do dann. Einfach viel kleiner ist. Das heißt, du kannst viel besser
den Punkt adressieren. Jeder weiß eigentlich, auch, wenn man über diesen Punkt zum Beispiel gesprochen hat, was dann da vielleicht auch zu tun ist, weil es halt einfach kleinere Dinge sind, ne. Also wenn ich dir jetzt zum Beispiel sage, Ey, Tino, Geh mal raus und keine.
Mach mal den Garten klar, das hier sind deine ganzen to dos, dann wirst du dir denken keine Ahnung, aber mach das jetzt zum Beispiel auch vielleicht Sinn irgendwie mit dem Rasenmähen anzufangen oder soll ich erstmal vielleicht die Blätter zusammenhaken oder du hast 1000 Sachen, aber wenn du jetzt zum Beispiel sagst du Pass auf. Heute hast du erstmal diese Aufgabe und diese und diese, dann siehst du alles.
Klar cool, hier erstmal Blätter jäten, dann muss ich keine Ahnung, dann muss ich mit dem Rasen mähen, dann muss ich vielleicht noch irgendwas anderes machen so und morgen mache ich was anderes so und dann hast du quasi gedanklich einen Tag, ist sozusagen jetzt mal eine Iteration und dann hast du quasi innerhalb von deinen Arbeitszeiten, also von deinem,
von deinem. Zeitlichen Umfang bestimmte Aufgaben, die du hast, die du viel besser greifen kannst, wo du auch weißt, schaffe ich das oder nicht? Ne, weil jeder weiß das ja das und das schaff ich an einem Tag so Garten machen zum Beispiel ich hab keinen aber ich sag jetzt einfach mal n Garten machen.
Das kriege ich locker heute hin, aber am Ende schaffst du es nicht, weil dann kommt noch irgendjemand anders, sagt hier dies und das kriegt vielleicht noch Besuch oder frag mich nicht auf Eis kommen Sachen rein wo du dann hinterher merkst.
Das hab ich ja gar nicht so geschafft und dann weißt du vielleicht gar nicht mehr, wo bin ich stehen geblieben und solche Sachen, aber wenn du so eine kleinen Aufgaben hast, dann kannst du sagen okay ich habe diese eine Aufgabe, die habe ich jetzt abgehakt, fertig, das passt erstmal so und selbst wenn ich dann unterbrochen werde, dann kann ich mir die nächste Aufgabe nehmen und das ist so unglaublich wichtig, weil dann
kannst du auch viel besser. Das einteilen und auch kleine Iterationen haben und du hast ein viel besseres Erfolgserlebnis am Ende. Plus dass du natürlich das Feedback geben kannst, dass der Rasen jetzt gemäht ist und andere Teams, die darauf aufbauen, die darauf warten. Zum Beispiel, dass der Rasen gemäht ist, um ihre Arbeit durchführen zu können, die Golfer. Die Golfer, die stehen da schon mit den Hufen.
Nein, aber. Kriegen natürlich dann auch schnell das Feedback zu sagen okay ich kann jetzt mit meinem. Arbeit weitermachen, weil ja, sagen wir mal, ein Blogger jetzt erledigt wurde. Und wenn diese Meldung erst nach 5 Wochen kommt, so nach dem Motto übrigens in den letzten 5 Wochen hatten wir nach einem Tag den Rasen gemäht und ihr musstet aber dann noch 4 weitere Wochen warten bis ihr das mitbekommen habt. So nach dem Motto.
Und das gehen wir auf den Rasen und sagen, Oh, der ist aber nicht richtig gemäht, wie wir es brauchen. Genau 5. Wochen melden wir uns wieder. Ja, richtig, und das ist, das ist ein exemplarisch halt die absolute Katastrophe. Und das Problem ist, was wir ja auch thematisiert haben, das würde ich jetzt gerne abschließend nochmal so ein bisschen zusammenfassen. Du fängst mit diesem agilen Mindset an und kriegst
wahrscheinlich kommt. So kommen viele Leute noch aus der alten Welt, ist oft so, dass man das vielleicht erst etabliert, also ich habe es persönlich noch nicht erlebt, dass es komplett etabliert war, als ich in diesem, sage ich mal, in diesem Team angefangen habe oder hingewechselt bin, wie auch immer, also es ist immer noch ein Prozess, so bisschen bei mir gewesen, das heißt, du musst ständig daran arbeiten, es zu verbessern. Du vorhin gut gesagt hast.
Learnings ziehen nicht nur aus dem negativen, sondern auch aus dem positiven Mal zu sehen, was lief denn gut und warum lief es gut und wie können wir das Nutzen und auf andere Bereiche übertragen, damit das auch gut läuft. Das fand ich nämlich n sehr guten Punkt von dir vorhin sehr wichtig Learnings genau, aber wirklich in beide Richtungen, weil viele neigen dazu immer nur über das Negative zu reden, gerade so ja meinetwegen in Retros oder so allgemein
austauschtermin und. Das bringt einfach nur Unmut.
Und dann entwickelt sich halt so eine Anti Haltung gegen das Framework. Dann geht's los mit naja, aber wir schaffen unsere Arbeit nicht, jetzt haben wir hier totalen Druck, die anderen Teams sagen wir blocken sie und wir sind hängen hier nur einen Termin, ich muss das fertig holen, das muss heute noch fertig werden, weil eine Auslieferung steht vor der Tür, auch so ein ganz klassischer Punkt Feedback hinten anstellen, nur ausliefern, ausliefern, ausliefern. Weil was habe ich von Feedback?
Die Software muss raus, blöd gesagt. So, und dann betrittst du halt genau dieses Hamsterrad, was wir quasi angesprochen haben, weil du gerade. Feedback gesagt hast ne Feedback schnelle Feedbackzyklen wichtig
weiter. Ja genau, also halt nicht die Iteration. Dann quasi auf Teufel komm raus verlängern, weil man denkt es verbessert das Ganze, weil dann und ich setz noch mal an bis du halt genau in diesem Hamsterrad gefangen und das fängt an sich zu drehen und du merkst halt so, ja OK wir machen jetzt 3 Wochen das Rad dreht sich los, so ja okay ja du spürst wahrscheinlich erstmal so ein bisschen Erleichterung, weil so ein bisschen Druck von dir abfällt,
aber spätestens nach dieser Iteration denkst du dir so verdammt, wir waren wieder überplant und jetzt Team A hat irgendwas fertig gemacht. Team B gar nicht so wollten. Und jetzt jetzt müssen die das komplett umbauen, die sind jetzt komplett sauer auf uns, weil wir irgendwie das falsch kommuniziert haben, das ist nach 3 Wochen erst aufgefallen so und so weiter die Retro alles alles nur noch Mist. Das Rad es dreht sich immer schneller und schneller.
Das heißt, irgendwann kommst du in diesen Modus, dass alle nur noch Frust schieben, du vielleicht die Iteration noch mal verlängerst, weil einfach es heißt, nee, wir müssen fertig werden. Ey, bitte hört auf mit den Terminen, dann kommst du in so n Task Force Modus auch so n wunderschöner Begriff und sagst nee bitte heute keine Retro.
Planning fällt auch aus. Wir haben noch genug offen und das Rad dreht sich, bis du dich irgendwann als kleiner Hamster da drin dich überschlägst und gar nicht mehr weißt, wo oben und unten ist. Und das ganze Projekt in sich zusammenfällt, dann hast du zwar die Fahrt deines Lebens wahrscheinlich, weil es richtig schnell dreht, aber das hilft dir halt auch nicht weiter am Ende. Also dagegen gegenüber Planung kurze.
Nicht kurze Komplexität reduzieren beziehungsweise Aufgaben in kleinere Teile unterteilen. So das ist zum Beispiel auch ein wichtiger Punkt. Und um das Ganze jetzt noch mal vielleicht abzuschließen, was auch noch vielleicht so ein vierter wichtiger Punkt ist, also erstmal, Learning ist wichtig und wichtig, dann kurzes Feedbackzyklus. Haben schnell Feedback, kriegen viel Feedback, kriegen wichtig, am besten auf allen Ebenen, dann Komplexität reduzieren, Aufgaben teilen, kleinere Aufgaben
verteilen, wie auch immer. Wichtig ist noch oder was auch noch ein guter Punkt ist, um dem Ganzen entgegenzuwirken.
Agiler Coach das ist eine Sache, sollte man nicht einfach unter den Tisch kehren, also drüber, drüber, so lächelnd abwinken oder was auch immer, sondern wirklich ernst nehmen und sagen okay ein agiler Coach ist ein agiler Coach und auch wenn man vielleicht eventuellen agilen Coach hat, wo man sagt okay ich bin der Meinung, der ist vielleicht nicht so gut oder sie ist nicht so gut, keine Ahnung, man kann ja auch unterstützend helfen, ist ja auch kein Problem, aber wichtig ist wenn
man wenn man sowas hat vierter Punkt. Agiler Coach freut euch darüber. Hilft ja, ich würde sogar noch ein bisschen den vierten Punkt noch ein bisschen erweitern zu sagen, also ein agiler Coach ist Gold wert, es ist aber allgemein der vierte Punkt auch. Irgendwo, dass das Mindset halt
da sein muss bei allen. Also es hilft halt nicht, wenn 20% des Teams voll hinter agiler Entwicklung stehen und die anderen 80% dagegen arbeiten, dann sollte man halt das ganze Konzept noch mal überarbeiten, vielleicht sich überlegen, ob das denn überhaupt der richtige Ansatz ist, weil wenn da nicht alle am gleichen Strang ziehen, logischerweise wird es halt auch ja einfach nicht funktionieren und. Dann sogar noch der fünfte Punkt, den wir hatten.
Gebt der ganzen Sache auch Zeit, bei sowas muss sich halt etablieren, gerade wenn das Mindset noch nicht stimmt. Schöner Abschnitt. Ja, vielen. Vielen Dank. Deswegen werde ich jetzt hier auch diese Folge beenden deswegen.
Das obligatorische Liebe zuhören, die wir Zuhörer, falls sie die Folge gefallen hat, lasst uns bitte mal ein Feedback zukommen, also gerne auf Verbesserungsvorschläge, Anmerkungen dazu, das heißt, falls du auch Punkte hast oder Erfahrungen gemacht hast, ja schreibt uns gerne über die Podcast Mail oder auf den anderen Plattformen die links findest du wie immer in den Shownotes, dort findest du auch ein kleinen Spendling. Das heißt, falls du uns
unterstützt möchtest, damit wir unser Arbeit hier noch weiter verbessern können, würden wir uns natürlich auch sehr, sehr darüber freuen. Vielen Dank schon mal dafür und ansonsten würde ich sagen. Auch von Fabi. Ansonsten würde ich sagen, hören wir uns alle beim nächsten Mal wieder. Noch n schönen Tag und bis zum nächsten Mal deine Coding. Bodys gemeinsam besser? Was? Was?