Schreist du dann auch los oder ich setz mich kurz ins Auto und fahre dann los und dann schreie ich wieder. Coding Buddies Dein Podcast rund um Softwareentwicklung und aktueller Tech News herzlich Willkommen.
Halli Hallo und herzlich Willkommen zur neuen Folge des Goding Madis Podcasts. Schön, dass du wieder eingeschaltet hast, dass wir uns hier wieder versammelt haben, deine Gastgeber, wie soll es anders sein, meine Wenigkeit, der Tino und natürlich auch der fantastische Fabi der Spieler grinst wegen dieser Anmoderation Fabi, was geht ab herzlich willkommen Hallo Hallo. Was geht, was geht, wie geht's? Wie steht's? Bist du jetzt hart am Reim heute? Die ganze Folge so.
War das gerade Reim? Ich weiß es, ich glaube, es hat sich so, als hat sich sehr reimend angehört, ich habe immer jedes Wort zweimal gesagt, das reimt sich dann auf jeden Fall, weißt du ja, das ist ein richtig sicherer reimen, dann einfach, ja, was geht ab, alles gut soweit und bei dir. Ja, auch alles gut. Ich bin letztens mal wieder so ein bisschen Auto gefahren, cool also ich ich fahre nicht mehr ganz so viel Auto wie früher so und da habe ich irgendwie mal
drüber nachgedacht. Also ich habe zum Beispiel so eine komische Angewohnheit im Auto, manchmal ganz manchmal. Und dann dachte ich mir in dem Moment eigentlich so, ich weiß gar nicht, hast du eigentlich auch eine Angewohnheit, so bei dir, wo du sagst, ist komisch, so weißt du so, die du teilen magst, wo du sagst, so, ja, das ist eine komische Angewohnheit, aber es ist nicht so schlimm, dass ich es nicht teilen kann.
Beim Auto fahren oder allgemein? Generell also ich hab irgendwie drüber nachgedacht und ich glaube jeder hat ja so seine komischen Eigenschaften. Weißt du wo man sich so denkt, so ist schon komisch, aber es ist halt so. Ja, auf jeden Fall hab ich da welche. Ich hab zum Beispiel wenn ich code ich ich hoffe das haben mehrere und nicht mehr ich nicht, dass ich jetzt hier der
komische bin der. Wenn ich Code aber alleine bin, also jetzt nicht zusammen mit dir zum Beispiel arbeite ne, dann bin ich mittlerweile im Modus, dass ich trotzdem mit mir selbst rede und als wenn ich als wenn ich so n per Programming mit mir selbst betreibe und mir dann sage, so, ah, jetzt brauchen wir das noch und hier und oh jetzt müssen wir aber hier drauf achten. Und irgendwie habe ich das Gefühl, es macht mich auch produktiver, dass es so ein
Drive gibt. Weißt du, das ist halt nur ein bisschen komisch, wahrscheinlich für Außenstehende, wenn da so ein Typ alleine vor dem PC sitzt und mit sich selbst redet, das finde ich sehr gut, ja, das finde ich gut, ja, also ein bisschen Selbstgespräche macht ja glaube ich jeder mal ne, also aber ich habe es unter Kontrolle, ich glaube ich mache
es nur, wenn keiner im Raum ist. Also es geht noch, Leute die es unter nicht unter Kontrolle haben, sagen immer sie haben es unter Kontrolle. Ich hab's nicht auf der Kontrolle, ja, aber find ich find ich lustig. Und was ist deine die du gemerkt hast oder warum du aufs Thema gekommen bist? Das ist also das ist schon so ein bisschen, ich weiß nicht, also. Ich weiß gar nicht, ob ich das sagen will, aber manchmal, wenn ich nicht immer Auto fahre, musst du mal ausprobieren.
Also wirklich nur wenn ich alleine bin, jetzt nicht, wenn ich irgendwie jemanden dabei hab oder so ne. Ich schreie. Einfach manchmal los. Einfach mal einfach mal schreien im Auto okay also du brüllst also wenn du dich über den Verkehr aufregst oder weil du einfach mal so so eine Energie rauslassen willst. Ja, einfach. Nur so, so einfach okay, also weißt du fahren und dann einfach mal bei, wo schreit man denn mal einfach mal eine Runde rum, weißt du wie ich meine?
Ja, ja, ja. Ich fühle mich selbst dabei auch ziemlich dumm. Also landet sich schnell. Ja, also sagen wir mal so. Viele sagen ja, das schreien ja auch befreit, ne, also es befreit einen ja das mal rauszulassen. Also ich bin wär dir aber trotzdem sehr dankbar, wenn du jetzt hier nicht im Podcast oder so. Rumschreien würdest und alles sich erschrecken. Im Auto kannst du das aber gerne machen, vielleicht muss ich das mal ausprobieren und dann sag
ich dir, wie ich es fand. Ja und deine Mitfahrgelegenheit denkt sich was soll genau einfach im Zug oder so. Da muss man auch mal ausprobieren, ne, aber weiß nicht, da musste ich irgendwie dran denken, weil ich mir ist in dem Moment klar geworden okay, du machst es manchmal so einfach so, weil ich mir dann denke, so ey, du bist halt komplett unbeobachtet und keine kann nicht. Mehr fahren Autos an dir vorbei, so weißt du, kann man wieder da
drin rumschreien. Aber nicht in der Stadt, sondern auf der Autobahn. Weißt du, jaja, so weißt du, wo dich eigentlich da hört dich wirklich keiner, am besten noch Musik an oder so, weißt du, da hört man sich ja selbst sogar nur noch leise. Aber eigentlich auch n ganz witziges Thema. Also liebe zuhören, liebe Zuhörer, falls du ne coole Angewohnheit hast, wo du denkst, es ist n bisschen crazy, aber auch eigentlich nicht schlimm, das ist einfach so dein Ding, schreib uns was würde uns
interessieren. Ja, das ist bestimmt sehr sehr lustig. Das wäre richtig. Witzig genau. Ansonsten, wenn wir schon bei dem Thema sind, liebe Zuhörer, lieber Zuhörer natürlich, und wie immer jetzt in letzter Zeit, ne wollen wir noch mal an das Glöckchen. Appellieren und an den Follow oder das Abonnieren des Podcasts.
Also wenn es dir gefällt, dir unseren Smalltalk hier anzuhören, immer bevor die eigentliche Folge losgeht, dann lass doch gerne like da ne Bewertung Abonnier den Podcast und drück aufs Knöpfchen, aufs Knöpfchen, aufs Glöckchen, knöpfchen so Glöckchen Knöpfchen, genau das würde uns mega freuen, vielen Dank dafür. Und Tino und?
Wir gehen gleich ins Thema. Ich möchte mich aber noch in unserem Namen für eine kleine Spende bedanken, vor jetzt Anne und von Alexander, also vielen, vielen, vielen Lieben dank Leute, das bedeutet uns sehr viel und das ist einfach eine sehr, sehr nette Geste und wir nehmen die jetzt mal so an, dass Euch der Podcast und Coding Bunnys gefällt. Vielen, vielen dank Leute, vielen Dank genau.
Ja, wenn jetzt zum Beispiel ne Liebe zuhören über zuhören du dir sagst, ja OK, Mensch, hier ist ganz lustig, die Coding Buddies sind cool, geben mir mal guten Input und ich möchte auch mal ne kleine Spende da lassen. Den Link dazu gibt es in den Shownotes, ansonsten hör dir einfach ganz entspannt den Podcast an, man soll es ja auch nur machen wenn es gerade passt und ansonsten würde ich einfach mal sagen Tino lass uns doch mal ins Thema starten. Falls du nichts weiteres hast,
NÖ, das hast du gut gemacht. Also ich hab n gutes Gefühl bei der Folge, du bist gut drauf, solange du jetzt nicht rumschreist muss ich sagen bist du gut drauf, aber die Folge wird die Folge wird hart ja die wird ja die wird es wird sehr viel Diskussion geben denk ich, denn wir haben heute mal wieder so ne klassische 5 Gründe folge. Ja, find ich immer geil, wenn
wir sowas machen. Wenn man sich wirklich mal überlegt, was sind so 5 Gründe, dass etwas passiert oder nicht passiert und hauen wir das Thema für diese 5 Gründe folge raus genau also es geht um mal wieder also wir hatten das schon n paar mal so generell das Thema an sich aber das Thema agile und agile Arbeitsweisen wie zum Beispiel Scrum ne und ich.
Ich weiß nicht, wie es dir geht, Tino, aber man kriegt ja immer mal wieder irgendwie in seinem Weg durch die Softwareentwicklung, durch die Projektentwicklung, Projektarbeit und so weiter kriegt man ja immer mal wieder mit, dass es durchaus viele Stimmen gibt, die auch irgendwie sagen, so, Boah, jetzt mal ohne Scheiß Scrum oder andere agile Arbeitsweisen bringt nichts, das ist richtig blöd, das macht gar keinen Spaß und es. Funktioniert ja, ich.
Finde und genau darum geht es heute, zu gucken, welche Gründe also wir haben jetzt einfach mal 5 Gründe rausgesucht. Unserer Meinung nach auch, wieso das halt so oft, sagen wir mal nicht so läuft, wie es eigentlich laufen soll, weil ich persönlich und du ja auch Dino, also wir beide finden ja, dass es schon richtig geil ist, also agil zu arbeiten in der Softwareentwicklung ist ne geile Sache, aber halt eben nur wenn man es auch irgendwie richtig macht oder auch richtig machen
kann. Ne so möchte ich das jetzt mal gern hinstellen. Ja, also im Prinzip.
Das wär eigentlich auch so, der direkt der erste Grund der der mir da einfällt, den hast du jetzt eigentlich schon so ziemlich gut eingeleitet, Agilität so wie wir oder so wie man es kennt und leben kann ist ne geile Sache, das Problem ist einfach nur und das ist der erste Grund, dass es oft n falsches Verständnis von Agilität gibt beziehungsweise ne. Ne falsche Erwartungshaltung auch an diese Frameworks, heißt der erste Punkt, der mir dabei
einfällt, was ich auch immer, also wir haben ja auch schon in verschiedenen Teams gearbeitet, in verschiedenen agilen Teams und es sind halt auch sehr oft immer die gleichen Probleme, deswegen bin ich wirklich gespannt, diese 5 Punkte hier zu besprechen, weil. Es es.
Es dreht sich immer wieder im Kreis, so finde ich, das kann man noch so vorweg sagen und wie gesagt, dieses falsche Verständnis ist eigentlich immer so der Top Punkt gleich direkt am Anfang, weil wie gesagt es ist n Framework, das heißt es ist n Rahmen den man schafft wie man agil arbeiten kann ne also es gibt Methodik, es gibt rollen. Das ist alles definiert. Also das ist im Prinzip n Rahmen, der geschaffen wird, den man jetzt annehmen kann und umsetzen kann, um Agilität zu leben.
Aber das heißt auch nicht, dass es so n striktes, wie soll ich sagen, Regelwerk ist oder so ne, also man darf das nicht verwechseln mit so und so musst du es machen und dann bist du voll agil und dann läuft das, sondern es ist ja irgendwo wie gesagt n Rahmen wie man das Leben kann und man muss als Team ja immer das Verständnis aufbauen für. Dieses Framework sag ich mal. Und wie kann man es als Team
persönlich umsetzen? Die Umsetzung sieht ja auch immer anders aus und da fängt für mich auch Agilität im Kopf auch schon an, ne. Also wirklich mal das richtige Verständnis zu haben. Was versuchen wir denn hier eigentlich gerade zu etablieren im Team?
Ich glaub es gibt doch keinen 0 815 Fahrplan wo man sagt so wenn du jetzt das machst, wenn du jetzt das machst, wenn du jetzt das machst, dann bist du auf einmal agil unterwegs und die ganze Sache geht los, alles cool und das ist n Selbstläufer ne
das ist halt. Glaube ich auch oftmals so n bisschen das Problem. Also da fehlt dann also ich glaube, dass es durchaus sinnvoll ist, einfach mal sich hinzustellen und zu sagen, Pass mal auf Leute, es ist nicht so, dass wir ab morgen agile machen, sondern erstmal überhaupt das Mindset dafür zu entwickeln, zu sagen was was wäre denn ne coole Sache um überhaupt sozusagen diesen Schritt zu einer agilen Entwicklung hinzu machen, weil ich weiß nicht wie es bei dir
ist. So gerade zum Beispiel als Kind, wenn man dir sagt, sowas wie. Ja, du musst jetzt dein Zimmer
aufräumen. So ich glaub das einzige was ich gemacht hab an diesem Tag ist definitiv nicht mein Zimmer aufzuräumen, weil ich gesagt hab so ich mach jetzt gerne alles andere, ich bleib lieber hier irgendwo anders 5 Stunden lang sitzen und mach gar nichts dümpel vor mich hin oder so richtig Zeitverschwendung aber Hauptsache ich mach nicht das was ich machen muss so weißt du. Und das ist halt glaub ich immer das Lachen. Wenn du, wenn du irgendwo
dieses, dieses du musst das jetzt machen so ne sondern zu sagen vielleicht so, weil wenn du der Meinung bist ne zum Beispiel heute seh ich das anders, wenn alles super unordentlich ist, krieg ich irgendwann n Rappel und denk mir so alter ich will jetzt unbedingt aufräumen also ich. Schmeiße dann auch los oder ich setz mich kurz ins Auto und fahr dann los und dann schrei ich und dann komm ich wieder, so mach ich es ja, aber das ist genau das Thema, also bei.
Agilität oder agile Frameworks versprechen ja gewissen Benefit und der ist auch durchaus gegeben. Wenn du es richtig umsetzt. Ja, und ich meine Beobachtung ist immer, dass sich dann Teams oder auch vielleicht die nächst höhere. Chefetage sich denkt, so, ja, das klingt gut, wir sind dann völlig flexibel, ich kann jederzeit irgendwelche Änderungen in die Projektphasen reinstreuen und wir sind so richtig agil.
Ne das Problem ist, es bedeutet nicht nur weil wir jetzt keine langfristigen Pläne mehr haben, sondern in Iteration denken, dass alles super chaotisch, flexibel sein darf, so ja was machen wir heute? Jetzt werden wir schon wissen wie es weitergeht, ne das das können wir ja so reinzollen wir sind ja jetzt agil unterwegs. Hör auf dein Herz und ich glaub, du hattest das mal gesagt und das find ich halt auch ziemlich passend, dass man sag ich mal Agilität nicht mit planlos
verwechseln darf. Ja, also man hat keinen langfristigen Plan in dem Sinne OK ist richtig, aber deswegen darfst du ja nicht chaotisch planlos unterwegs sein, sondern du musst ja sag ich mal deine Iteration trotzdem richtig leben dahinter ne ich muss halt schnell, also in kleinen Zyklen denken, aber nicht planlos. Ich denk mir halt so ne Vision
gibt es auf jeden Fall so genau. Also du hast schon irgendwo ich sag mal ne Art Ziel am Horizont, auf das man hinarbeitet, ne aber nur weil du sagst OK ich hab n Ziel, heißt es nicht, dass das was dein Ziel ist auch zu 100% definiert ist und du davon nicht mehr abweichen darfst. Ne, sondern du darfst halt eben den agilen Weg gehen und sagen Pass auf, das ist unsere Vision, aber nur weil das unsere Vision ist, heißt es noch lange nicht. Dass wir da nichts mehr dran schrauben können.
Also angenommen du willst jetzt zum Beispiel blödes Beispiel,
eine Vision hast. Du hast eine Vision, dass du sagst, du willst jetzt zum Beispiel von A nach B kommen, wenn deine wenn aber das Ziel ist einen Teleporter zu bauen, ja dann viel Spaß, das wird echt lange dauern und vielleicht wird es nicht funktionieren, aber man kann ja vielleicht auch erstmal anfangen zu sagen, ey ich baue mir ein Fahrrad und aus einem Fahrrad kann ja gerne noch mal irgendwann Motorrad werden, so weißt du ist ist halt immer die Frage, wie dann auch der Kunde
sich damit wohlfühlt. Ne, also für die entsprechende Zielgruppe, für die es entwickelt wird und ich find es so lustig, dass irgendwo hab ich das auch mal gehört, da ging es auch so. Also du, du musst dir vorstellen so wir haben hatten so n Entwicklerteam und dann kam so also dann dann wurde so salopp reingeworfen so nach dem Motto. Also ich glaube, es ging im Kern darum, dass die Anforderungen nicht klar waren von einer Aufgabe.
Und dann haben wir halt gechallenged, dass das blöd ist, dass diese Anforderungen nicht klar waren und dann wurde halt so. Irgendwann. Ich nenn es jetzt mal n bisschen übertrieben so. Die Person wurde so in die Ecke gedrängt, weil da war halt keine Luft mehr für irgendeine Argumentation und dann so ja wir sind ja aber hier, wir sind ja agil, wir können ja hier dann immer noch gucken, was wir machen.
Und dann denkst du dir so, nee, also das ist halt das Problem und du hast es auch schon gesagt, agil ist das eine, sich aber permanent im Kreis zu drehen irgendwo durchzuschlängeln ist vielleicht flexibel, dass man irgendwie flexibel ist, aber flexibel ist ungleich agil so, das muss man halt wissen, weil gerade wenn du an einem Ticket dran bist oder an irgendeiner Aufgabe, dann sollte diese Aufgabe, wenn sie jetzt nicht irgendwo super weit in der Zukunft liegt.
Sollte sie halt irgendwie schon definiert sein.
Man muss dann irgendwie schon wissen, wo es hingeht mit dem kleinen Hintergedanken oder mit diesem Mindset zu sagen, angenommen, wir machen das jetzt so und das wird, das kommt dann am Ende doch nicht so gut an, oder wir müssen daran noch etwas ändern, dann kann man es ändern, aber in dem Moment, wo du dieses Ticket vor der Brust hast beispielsweise, da machst du das so, da muss klar sein, wie dieses Ticket formuliert ist und nicht hier, du kannst es, also wir haben ne Aufgabe.
Roundabout Pi mal Daumen, denkt euch was aus und wenn es dann doch nicht stimmt, dann beende ich es noch 5 mal um so nach dem Motto ne ja. Das ist genau das Ding, dass man oft oder verschiedene Personen sich oft dann hinter diesen.
HI Framework, verstecken und sagen, Na ja, ich muss das ja jetzt noch nicht so genau machen, aber genau das ist ja schon der falsche Ansatz, weil in deinen Iterationen musst du sehr präzise und genau arbeiten, denn dein Ziel ist ja, kontinuierlich besser zu werden, zum Beispiel mit der Software und Kundenwert zu generieren und schnelles Feedback zu bekommen, deswegen machst du das ja in kleinen Zyklen ne um so den
Progress und die. Sag ich mal den Speed aufzunehmen, den du am Ende auch wirklich kriegen kannst, damit ne, aber dann muss das halt einfach klar definiert sein.
Was wollen wir denn jetzt zum Beispiel in den nächsten 2 Wochen erreichen, welchen Mehrwert generieren wir und wie können wir evaluieren, dass am Ende dieser Mehrwert gegeben war und ob das erfolgreich war und das sind klar, das sind alles irgendwo Methoden die dahin führen, aber das am Ende ist ja auch das Mindset dahinter, was du haben musst. Ja also ich find agil, ist halt hauptsächlich n Mindset, du
musst halt wollen. Schnell Mehrwert zu schaffen für den Kunden ne und auch sag ich mal ja genau in diesen kleinen Zyklen zu denken find ich also sich zu denken OK was kann ich denn jetzt in ein 2 Wochen zum Beispiel schaffen und nicht immer dran denken was in n paar Monaten ist. Dafür gibt es ja andere Leute die die Gesamtvision wie du so schön gesagt hast im Blick haben.
Also jetzt gerade so als aus der Developerrolle heraus ne ja definitiv und da kommen wir eigentlich auch schon zum zweiten Punkt. Den ich mal reinwerfen würde, denn ganz oft ist es so, dass so alte Strukturen, die existiert haben, wie jetzt beispielsweise so klassische Wasserfall Modelle von früher, ne, dass du jetzt sagst, ey nein, jetzt sind wir agil, jetzt fangen wir an, zum Beispiel nach Scrum zu arbeiten, aber unter der Haube hast du eigentlich kein Umdenken und
kein Änderung, keine Änderung der Strukturen oder der Prozesse dahinter. Das heißt, du setzt jetzt ganz on top da noch mal so ein agiles Framework drauf. Drauf aber unten drunter Projektmanager was auch immer, haben immer noch ihre Wasserfall Modelle im Kopf und sagen Nein, aber das sind hier die Meilensteine.
Also ihr könnt ja gerne agil arbeiten, aber bis dahin will ich das haben und hier und da und da und Plan quasi schon die nächsten 3 Jahre auf so weißt du und das ist halt auch n Riesen Pain Point dabei. Ja, also ich find immer man man muss ja auch gucken so. Oftmals wird er dann auch
gesagt, so ja okay. Also du arbeitest jetzt agil, du hast jetzt vielleicht keine Deadlines mehr, so, ja dann bist du ja aber irgendwann an einem Punkt, wo du auf jeden Fall, also wie willst du das noch irgendwie planen, wie willst du denn irgendwann deinem Kunden zum Beispiel noch verkaufen, dann und dann bekommst du das, was du haben möchtest. Und natürlich ist das eine Sache, wo man sagt, kann man ja
auch verstehen und. Es ist ja auch nicht so, dass du nicht in der Lage bist, das irgendwie komplett gar nicht einzuschätzen, ne, aber das ist halt wieder auch n wichtiger.es ist halt immer ne Schätzung und du kannst nie genau planen und wenn mir jetzt irgendjemand erzählen möchte, ja doch man muss aber planen, damit es auch wirklich richtig fertig wird, dann denk ich mir so ja aber ne Planung wo du vielleicht zum Beispiel aus Managementebene Dich hinstellst und sagst wir
schaffen das. In 2 Jahren so komplett, die sage ich mal, Realität verloren zum zur wirklichen Entwicklung gar keine Ahnung davon und dann einfach irgendwas vorzugeben wo du sagst das wird schon passen. Ja das ist ja echt super geplant, so dass du am Ende quasi sagst, OK wir fangen mal ein bisschen an, das und das muss irgendwie fertig werden, dann war die Planung wohl. Ich weiß nicht. Gibt es irgendwelche Beispiele dafür?
Ich glaube so 90% aller Planungen sind halt einfach gefühlt viel viel, viel zu optimistisch, sodass du eigentlich schon ab dem zweiten Meilenstein, sage ich mal, anfängst, deine deine Ziele zu reißen so.
Genau. Und da denke ich mir so, du kannst dich ja hinstellen und sagen, ja, wow, wir planen irgendwas, aber es bringt keinem was, wenn du sagst, wir sind in 2 Jahren damit fertig, dann kannst du deine Sache haben, aber am Ende. Kommst du an diesem Punkt wo du sagst, jetzt sind 2 Jahre rum, jetzt will der Kunde das haben, dann denkst du dir so ja wow, es funktioniert ja nicht, der Kunde ist unzufrieden, das Management ist unzufrieden, weil es nicht
geschafft wurde und alle Mitarbeiter und Mitarbeiterinnen sind unzufrieden, weil sie die ganze Zeit Druck bekommen haben, weil sie seit dem zweiten Mal schon hinterherhinken, das ist ja richtig geil, aber wenn du zum Beispiel mal sagst, ja OK und was macht jetzt agil anders, dieser agile Prozess, diese ne, wir sind ja gerade bei Strukturen und Prozesse, die dann eben nicht verändert werden.
Aber wenn du sie veränderst und mal sagst, OK, wie wäre es denn, wenn man zum Beispiel das, was der Kunde haben will, nicht erst in 2 Jahren zur Deadline zur Verfügung stellt, sondern schon mal vorzeitig dem Kunden zur Verfügung stellt, dann hast du eine absolute. Du kannst dem Kunden zeigen, guck mal bitte hier so und so weit sind wir, probiere es aus, hast du ein Feedback, können wir vielleicht irgendwas machen, was in die Richtung geht so und ich finde es auch immer.
Jetzt fange ich hier schon an, Monolog zu halten. Tino, Es tut mir leid, aber ich ich find ich find es dann immer so so schwierig sich hinzustellen zu sagen ha wir schaffen es nicht weil die sind ah die arbeiten ja alle zu langsam wo ich mir denke ne Deadline ist kannst du ja hinstellen und die Frage ist wie gut planst du sie aber Fakt ist ist dass die Leute zumindest meiner Erfahrung nach sich niemals hinstellen und sagen ich chill jetzt mal richtig hart ab.
Bis ich ne Deadline einreiße, sondern die Leute arbeiten so schnell es geht. Ne, das heißt du kannst jetzt so mich in dich hinstellen, ich könnt dich jetzt fragen, Tino, wie lange dauert das und du sagst ich glaub mal so ne Woche ne so und wenn ich dann hinterher dich frage und sag und ist nach einer Woche fertig und du sagst nee das hab ich noch nicht geschafft was willst du denn dann jetzt machen?
So also willst du dich dann hinstellen und sagen ja kacke dann mach es jetzt heute fertig also es wird ja nicht sein, dass dass man nur weil man sagt, bis da und da muss es jetzt fertig sein, heißt das ja nicht, dass nur wenn du diese Deadline setzt, die Leute auch anfangen, schnell zu arbeiten, meiner Erfahrung nacharbeiten alle so schnell wie sie können, immer weißt du. Ja, der Punkt, da muss ich noch
mal kurz drauf eingehen. Wenn du sagst, der Kunde ist nach 2 Jahren unzufrieden, ne und man lieber ihm. Teilergebnisse liefern sollte, um dann schnelles Feedback zu
kriegen. Ist ja wie gesagt auch der agile Ansatz und da kommt halt auch oft ein Stolperstein zustande, wenn zum Beispiel der Stakeholder beziehungsweise jetzt der Kunde ne, aber gehen wir jetzt mal wirklich von der Rolle Stakeholder aus, auch nicht die Agilität verstanden hat ja also im Prinzip, wenn wenn ich sage ich entwickel etwas für einen Kunden und der möchte eine neue Software haben, irgendein Projekt. Und erwartet aber, dass er das
kriegt, so wie er das gerne hätte und kann es dann im Gesamtheitlichen ausprobieren, dann ist das halt nicht agil und dann ist das auch kein Arbeitsmodell was funktionieren wird und nur zu Frust führen wird. Fakt ist doch er muss er sich auch drauf einstellen in einem agilen Umfeld zu sein, das heißt er kriegt Halt von Woche zu Woche am besten oder alle 2 Wochen sagen wir mal Teilergebnisse die er ausprobieren kann wo er ein
Feedback geben kann. Und dann kommst du halt in diesen geilen Workflow, der auf jeden Fall funktioniert und alle auch irgendwo happy sind, weil du kriegst als Entwickler das Feedback Mensch. Ja, das ist cool umgesetzt, so lassen wir das oder ey, ganz ehrlich, hab ich mir n bisschen
anders vorgestellt, sorry. Geht in die falsche Richtung, aber du reagierst und hast nicht nach 2 Jahre ein, ist cool oder ist total Scheiße. Die Software weißt du und da müssen ja auch beide sich hin entwickeln und da sind wir auch wieder bei der Mindset frage ne also der Kunde muss ja genauso bereit sein zu sagen ich guck mir alle 2 Wochen zum Beispiel Ergebnisse an und wenn es nur kleine Features sind, das geht ja nicht darum, dass er da komplett ne ganze Software
hingeworfen bekommt sondern nur n Teil und das. Entwickelt sich Iterativ. Ja, und das finde ich, hast du halt ganz oft bei allen Strukturen nicht gegeben, dass Leute dafür bereit sind, für die Du das zum Beispiel entwickelst. Ja, und um noch mal ganz kurz den Bogen zum Punkt 1 zu schließen, es ist ja nun mal so, dass.
Wenn du jetzt zum Beispiel sagst oder wenn du dir denkst, ja OK, aber angenommen zum Beispiel, es hilft ja auch, einfach mal erstmal NMVP zu machen, ne und vielleicht siehst du ja auf dem Weg zur zu dem was gewünscht ist, dass bestimmte Sachen vielleicht gar nicht so angenommen werden, wie du sie
gedacht hast. Und zum anderen vielleicht auch du. Du siehst ja relativ gut, wie sozusagen der Fortschritt ist, dass du vielleicht siehst, OK, wir können noch n bisschen mehr hinzufügen, oder wir müssen n bisschen was weglassen, aber wir wollen ja gerne. Zumindest so eine gewisse erste Version schon mal da haben.
Und wenn jetzt zum Beispiel jemand sich denkt, ja, aber dann ist es ja gar nicht fertig, so ne, also dieses das und das ist gewünscht und das und das muss jetzt da sein, ist halt auch wieder ne Punkt 1. Mindset heutzutage wird ein wenig anders gearbeitet und da wird geguckt was kann man schaffen, wie kriegt man das hin, wie weit kommt man und natürlich willst du etwas haben was funktioniert auf jeden Fall. Aber genau in diesen kleineren Iteration kannst du auch viel,
viel besser abschätzen. Wie weit kommen wir, was funktioniert so und da muss halt einfach dann umgedacht werden, ne? Ja, absolut.
Also man muss halt dann auch bereit sein, in diese neue Denkweise zu gehen und ich glaube, da scheitert es halt bei vielen, die dann sagen, OK, ich mach mit oder vielleicht das auch aufgezwungen bekommen, das hast du halt auch oft, dann ist es sowieso zum Scheitern verurteilt, um das Ganze so in Punkt 1 und 2 noch mal einzubetten, wenn du eine agile Arbeitsmethode aufzwingst und die Mitarbeiter gar keine Lust da drauf haben und sich denken nach sowas neumodernes.
Gerade wenn es vielleicht schon 2 dreimal nicht geklappt hat. Ne und du deine Meinung immer mehr verhärtest und dich verschließt gegenüber funktionierende agile Arbeitsmethoden, also wirklich ein funktionierendes Umfeld zu schaffen, dann ist das Ding eh schon. Also wie sagt man so schön das Kind im Brunnen gefallen, weil
dann wird das eh nicht klappen. Ja und ein dritter Punkt den ich gerne ansprechen würde, weil das gefühlt jedes Mal so lange es halt noch nicht rund lief, sagen wir mal so. Jedes Mal n Grund, warum es auch nicht rund lief und was es auf jeden Fall zu fixen galt, sind unklare Rollen und Verantwortlichkeiten. Das ist n Thema, das Triggert mich richtig, weil du hast gehen wir jetzt mal zum Beispiel von Scrum aus, Du hast ja verschiedene Rollen, die du in einem Scrum Team einnehmen kannst.
Wir haben da mal ne Folge zugemacht. Liebe zuhören, Liebe zuhören, da müsstest du ne Weile runter scrollen, das ist schon ne Weile her, aber es ist auf jeden Fall sehr informativ gewesen. Also falls du dich mit den Rollen nicht so wirklich auskennst, dann hör da gerne mal rein und komm dann jetzt hier wieder zurück. Deswegen möchte ich sie auch nur kurz nennen. Also wir haben ja sowas wie Scrum Master, Wir haben ne
Product owner. Ja, teilweise gibt es auch noch PMS und wir haben halt vor allem Developer die Rolle, die wir halt meistens eingenommen haben, Fabi ne. Special Design oder sowas gibt es ja auch manchmal noch. Ne genau. Also das heißt, du hast jetzt in dem Manifest rollen, die klare Aufgaben haben, ne die eine eine Funktion in einem Scrum Team übernehmen und. Fakt Nummer 1 oder Punkt Nummer 1? Warum es scheitert ist das nicht klar ist, was ist meine Rolle?
Ich habe sehr oft erlebt, dass manche sich dachten, oh ja, ich mach product owner, Product owner klingt irgendwie so, als hätte ich mehr Verantwortung, als wär ich so, ich bin ja so n halber ja so n halber Chef, so ne das ist also ich glaub product owner, da seh ich mich, vielleicht gibt es auch noch ne Gehaltserhöhung ich weiß ja nicht ich formulier das mal jetzt bewusst provokativ. Fakt ist jedoch, dass einem Scrum Team alle auf einer Ebene sind. Du hast nur ne andere Rolle im Team.
Du hast quasi ne andere Funktionalität am Ende, aber du bist nicht der Teamleiter, Du bist nicht der Chef der anderen, das muss ich sagen, dieses Mindset hab ich bei anderen schon erlebt und die sich dann dachten na ja, ich Manager das jetzt n bisschen haben aber eigentlich die PO rolle überhaupt nicht gelebt oder ausgeführt am Ende so was.
Quasi passieren muss als PO und das war auch schon mal der Anfang vom Ende in so einem Scrum Team, weil dann fällt das bricht das Kartenhaus halt einfach zusammen, wenn eine gewisse Rolle nicht erledigt wird im Team, weil es führt natürlich auch immer zur Diskussion, das darf man ja auch nicht vergessen, wenn du n unterschiedliches Rollenverständnis hast und Person a sagt, Person B muss, muss eigentlich das und das machen, tut sie aber nicht und
umgedreht. Dann hast du natürlich auch direkt Spannung und es wird wieder direkt in Frage gestellt, ob dieses Framework diese agile Arbeitsweise überhaupt funktionieren kann. Ja richtig, also ich hatte auch vor einigen Jahren, ist jetzt echt auch schon wieder n bisschen länger her, die ja auch NPO der halt genau das was du gerade gesagt hast beschrieben hast. Ne und NPO ist meiner Meinung da dafür da also. Nicht nur meiner Meinung nach, aber es ist halt auch so.
Es ist ja der Product Owner, das ist der Mensch, der die Vision darüber hat, was mit dem Produkt passiert. Und jemand, der die Vision darüber hat, muss einfach
wissen, wo es hingeht. Also er muss halt einfach wissen, was sind die nächsten, die nächsten gewünschten Aufgaben, die jetzt auf diese, ich sag mal auf dieses Produkt zukommen und dann muss das reingebracht werden ins Team, also in in zu den Developern ne zu oder zu den Leuten, die das halt sag ich mal entwickeln, entwickeln dann ne genau und.
Sich aber hinzustellen zu sagen, ja, ich bin jetzt hier, der Leader sozusagen, und kann jetzt sagen, du machst das und du machst das und du machst das bringt halt einfach gar nichts ne, sondern in Team arbeitet für sich selber, bestimmt für sich selber und es ist sozusagen Balance Team. Jeder hat seine eigene Rolle und ist aber vom Stimmrecht sozusagen genau gleichberechtigt und gleich beteiligt. So ne, und das ist halt irgendwie schwierig und zum
Beispiel was ich. Weil du jetzt zum Beispiel Product ohne angesprochen hat, hast. Scrum Master ist zum Beispiel, oder nennen wir es mal agile Coach. Es kann unterschiedliche Namen haben und auch für unterschiedliche Frameworks, aber ich find zum Beispiel spannend, dass es Leute gibt, hab ich erlebt, die sich sagen n Scrum Master, Boah das ist so ne richtige pillepalle Rolle ne, da musst du eigentlich gar nichts
machen, nur mal so n bisschen. Meeting starten und ansonsten mal so. Fragen, ob alles bringt okay. Zu mitbringen genau so. Und dann denke ich mir so okay wenn du da, wenn du glaubst, dass das der Scrum Master ist, dann ist es halt leider falsch dann. Kommt, ging schon verloren, ja. Genau dann kommt die andere Seite, wo ich mir denke, was ich auch schon erlebt habe, wo man
sich dann denkt, Scheiße okay. Ich verstehe vielleicht, warum manche Leute denken, dass ein Scrum Master das ist, weil es nämlich Scrum Master gibt. Die diese Rolle einnehmen, die genau selbst von sich denken, dass das das ist, was sie machen müssen oder sich denken, Oh, wenn ich scrum Master bin, dann muss ich ja nur n paar Kekse mitbringen und n paar Meetings also starten, das ist ja richtig easy peasy ist ja ne geile Arbeit so ne und das ist halt das halt kacke.
Ich hab aber zum Beispiel auch schon gute Menschen, Leute in dieser Rolle erlebt ne weil wenn du es eigentlich richtig annimmst und dieses Mindset wieder hast und sagst ey ich bin jetzt aber AJR Coach, ich bin scrum Master ne. Ich kümmer mich darum. Wie geht es denn gerade dem Team, in welche Richtung entwickelt sich das Team? Sind die vielleicht gerade richtig gut drauf, haben die vielleicht Probleme? Da muss ich dann noch mal n bisschen auch in der Retro nachhaken.
Ich muss ich also das ist ja ne, ist ja n Vollzeitjob, wie zum Beispiel wie ist gerade das Team drauf dementsprechend richtig meine Retro darauf aus ne wenn du immer nur ne Retro machst und sagst OK wir machen jetzt mal wieder ne Retro. Was ist gut gelaufen, was ist schlecht gelaufen, was müssen wir verändern? Let's Go, Leute so, wir haben eine Stunde Zeit, macht mal macht mal schnell alles okay jetzt besprechen wir das super Dankeschön bis zum nächsten Mal.
Das das ist es nicht, du musst wirklich dein Team kennen, du musst da richtig viel Zeit investieren, darüber nachdenken was braucht das Team gerade, wie geht es, wie machen wir weiter und so weiter das Macht einen richtigen Scrum Master, einen agile Coach oder was auch immer aus.
Und aber da hast du genau die Abwärtsspirale, dass wenn dieses Mindset aufkommt und auch quasi vielleicht jetzt nicht nur in deinem agilen Team, sondern projektübergreifend Firmenübergreifend. Herrscht dieses Mindset ne, dass dann die Leute anfangen? Ja, aber warum brauch ich denn
jetzt nen Scrum Master zu 100%? Also so viel ist es ja nicht, reicht ja wenn er 2030% seiner Arbeitszeit nimmt und ansonsten noch ne andere Rolle hat er noch weiterentwickelt ja also n Entwickler kann ja auch einfach nebenbei noch Scrum Master sein PO 50% das und 50% entwickelt da noch mit und das sind genau die Sachen diese Doppelbelegung die das ganze Projekt oder die.
Die der Ganzen, den ganzen agilen Ansatz zum Scheitern bringen, weil ein PO, der sag ich mal, ich mit Anführungszeichen noch Zeit hat, nebenbei zu entwickeln, der lebt seine Rolle nicht richtig aus, ganz klar.
Also da bin ich mittlerweile fest der Meinung, weil ich sehr viele POS auch schon erlebt hab, also sowohl gute als auch schlechte ja, aber also schlecht im Sinne von nicht persönlich, sondern dass sie einfach die Rolle nicht gut gelebt haben ne, also hier kein persönlicher Angriff ja, aber wenn ich. Nicht zu 100% das mache fällt sehr viel hinten runter und das äußert sich ganz oft in der Vision wie du meintest ne, dass
keine klare Vision vorherrscht. Was ist in den nächsten Wochen zu erreichen, was trage ich in mein Team, was kommuniziere ich in das Team hinein zu den Entwicklern, was braucht der Kunde, was möchte er die nächsten Wochen haben, was ist wichtig, wie priorisiere ich Riesenthema. Wie was für Tickets hab ich? Also habe ich niedergeschrieben,
was erledigt werden muss. Ja das ist n riesen Punkt, da können wir auch gleich noch mal kommen wenn wir vielleicht so n bisschen übers Tooling reden ne aber das sind die Punkte wo es immer scheitert weil am Ende denn keiner mehr weiß was er eigentlich machen soll und du wieder in dieses planlose Verfällst und da ist der PO eine ganz ganz zentrale Rolle ne gerade wenn du auch mehrere agile Teams hast.
Ja also. Wenn es denn, sag ich mal, größer wird und man sagt, ich hab jetzt 23 agile Teams, die aber in ein Gesamtprojekt einzahlen mit ihrer Arbeit. Umso wichtiger wird diese PO rolle und man muss sich gut überlegen, möchte man das, hat man verstanden was ein PO ist und nicht dieses wie ich es auch schon erlebt hab, klingt irgendwie wie Chef ich hab Bock Chef zu sein so weißt du und dann völligst unzufrieden zu sein mit der Rolle die man da
eigentlich eingenommen hat. Ja richtig, das ist das hast du ganz gut zusammengefasst. Und du hast ja schon Tools n
bisschen angesprochen. Das ist finde ich auch so n so n vierter Punkt. Ich würde jetzt einfach mal weitergehen, außer du hast und zwar also der vierte Punkt für mich ist, dass man zum Beispiel sagt, OK, wir arbeiten jetzt agil, ne Let's go, hier sind alle Tools die ihr braucht und dann fokussierst du dich am Ende auf diese ganzen Tools die du hast, die du nutzen musst anstatt wirklich echte
Zusammenarbeit zu haben, ne? Das heißt, du sagst dann sowas wie ja guck mal hier, das ist unser Board, das sind unsere Tickets so und Fokus darauf. Anstatt aber zu sagen Ey lass mal miteinander kommunizieren, lass darüber reden ne, also sowas wie zum Beispiel, also es bringt ja nichts wenn du sagst wir haben jetzt, wir haben jetzt hier so n so n JIRA Board oder wir haben jetzt so n so n cambam Board ne also das eine ist n Tool, das andere ist n methodiker so ne.
Wir haben jetzt irgendein Board wo die Tickets drauf kommen. So und damit da wir sind jetzt agil, jetzt geht es los ne activated ja ich mein gut wir haben jetzt schon ne Menge übers Mindset geredet so wenn du nicht weißt was es ist oder wofür es da ist, ist es natürlich schwierig. Das heißt du hast halt dieses Mindset was du dann am Ende brauchst ne aber du entwickelst ja trotzdem nur weil du diesen
ganzen Kram da hast. Ne entwickelst du ja kein gemeinsames Verständnis darüber, wenn jeder sich einfach nur irgendwie. Mit diesen Tools aufhält aber man nicht wirklich mal zusammen. Das bespricht worum es geht, ne ja sind das sind halt auch ganz oft Sachen, dass du so n Tooling Etablierst, so innerhalb von wie soll ich sagen Sekunden ja wir machen jetzt. Wir machen jetzt Scrum.
Alles klar. Hier sind die Daily Termine, hier ist die Retro, hier das Planning Review machen wir dann und dann und dann hast du halt, dann wirst du halt bombardiert mit Terminen, dann heißt es das sind alles pflichttermine, weil wir sind richtig agil und ihr habt da zu sein und immer dieses Aufzwingen von Sachen ne ohne wirklich sag ich mal die Leute, dass die Leute bereit sind dafür das zu machen weil ich finde zum Beispiel wenn jemand sagt Ey übrigens.
Ja, hier planning und Retro, das ist Pflicht. Wehe ihr kommt nicht, ihr wart letzten mal alle nicht da, wehe ihr kommt nicht, dann bin ich schon an einem ganzfalschen.es muss einfach von der inneren Einstellung klar sein, dass ich in die Retro gehe, weil ich das innere Bestreben hab zu sagen, ey, wir haben Sachen zu besprechen, wir haben Sachen zu verbessern und das möchte ich angehen, das Thema. Und ich möchte vielleicht sich n paar tolle Sachen anmerken.
Ne genau also es muss ja nicht immer nur negativ sein, sondern auch mal feiern was man erreicht hat, auch das ist agil und
gehört fest dazu. Guter Punkt aber das da fängt es dann immer an schon innerlich zu kribbeln bei mir und da bin ich genervt davon wenn man wenn man sowas gesagt bekommt, also gerade wenn man zum Beispiel in einem Team also wenn n Team erst anfängt damit, dann ist gerade so n Retro das allerwichtigste am Ende ja also wirklich zu sagen, wie können wir jetzt in die richtige Arbeitsmethodik kommen und dann muss doch dieses innere Interesse da sein, an diesen Terminen teilzunehmen und
aber. Das ist ja Tino, das ist ja schon so, das geht ja schon so in die Richtung, also auch wieder logischerweise Mindset ne, weil wenn du sagst ihr müsst jetzt diese Termin lassen, Pflichttermin, ihr müsst da reinkommen so und Leute denken ja boah retro Alter. Ich wollte gerade irgendwie entwickeln. Jetzt muss ich wieder irgendwie quatschen. Ich weiß gar nicht, was jetzt großartig gut gelaufen ist, was
schlecht gelaufen ist. So als Beispiel ne Planning, oh jetzt muss ich wieder eine Stunde 2 Stunden, je nachdem wie lange das dauert muss ich jetzt irgendwie wieder über irgendwie mir Tickets durchlesen so ne und ich finde genau das ist ja also da ist wieder das fehlende Mindset oder du lebst es halt nicht richtig, du hast nicht verstanden wofür das eigentlich da ist, weil wie du meintest Retro, genau dafür ist es da
was. Was du meintest ne wichtige Dinge, aber du musst ja das Mindset entwickeln, nicht zu sagen, Boah, jetzt gehen wir wieder durch und ich weiß gar nicht was ich da jetzt zu sagen soll, sondern wenn du merkst ey hier retro, da ist es wichtig offen zu sein, da kann man was verändern und das ist ja das wichtige am Ende.
Da ist es ja, dass dass du, dass du automatisch da während der Zeit bis zur nächsten Retro aktiv schon wieder Sachen merkst und dir denkst, so, Oh, warte mal, das war echt gerade richtig cool, oder? Boah, das war heute ein richtig richtig krasser Paint Punkt und den hatte ich jetzt auch schon zweimal in dieser Woche, das heißt, es ist jetzt schon das dritte Mal. Das muss ich unbedingt bei der Retro ansprechen, weißt du, du sensibilisierst dich darauf so
was halt einfach. Zu merken weißt du genauso wie beim Planning. Wenn du jetzt beim Planning sagst, ja, jetzt besprechen wir wieder irgendwelche Tickets, wenn das das Gefühl ist, was beim Planning aufkommt, dann ist es halt nicht das richtige Planning was du machst.
Weil Planning finde ich ist ja wichtig, dass man einfach darüber redet okay welche Tickets haben wir, was ist das auch das, was ist das Kundenverständnis, was gebraucht wird, was ist das Teamverständnis, was wir schaffen können, was ist das Teamverständnis. Auch zum Beispiel über diese entsprechenden Wünsche, weil man muss natürlich auch immer gucken, dass es natürlich auch gerne mal n wünsch dir was gibt bei Kunden, ne, also da muss man natürlich auch hart differenzieren, oder?
Nein, nicht hart, sagen wir mal sensibel differenzieren zwischen was wird gewollt und was entspricht wirklich der Vision am Ende ne. So also du brauchst ja zum Beispiel keine Ahnung an deinem Handy brauchst du jetzt nicht noch n Kartoffelschäler dran zu machen, so auch wenn vielleicht manche Leute Kartoffeln schälen abends aber weißt du was ich meine ne blödes Beispiel, aber wenn du irgendwann dahin kommst zu sagen EY das sind unsere Tickets, die sind wichtig,
darüber haben wir gesprochen und wir wissen jetzt auch, wir haben einheitliches Verständnis über diese Tickets, dann ist es gut, dann kommst du ja richtig mit einem, da hast du richtig Bock auf dieses Planning, weil du dir denkst boah ey, ich werd jetzt mal wieder richtig wissen, wie es weitergeht. Jetzt gucken wir mal was sind die Tickets?
Ich hab schon richtig richtig Bock sozusagen in in die nächste Iteration, beispielsweise nach dem Planning zu starten um zu sagen so ey geil ich ich ich hab wieder Aufgaben wo ich genau weiß was zu tun ist. Ne und nicht dass du am Ende aus dem Planning rauskommst. Eigentlich ist noch alles offen und du denkst dir so boah ich hab jetzt hier n Ticket. Ich weiß gar nicht richtig, was ich damit.
Machen soll. Ehrlich gesagt, so weißt du ja, ich finde planning ist auch ein gutes Beispiel, weil du meintest, dass oft eine, dass du viel Tooling hast, aber wenig Kommunikation und echte Zusammenarbeit da ist Planning auch so ein geiles Beispiel, wenn es nämlich auch Richtung schätzen geht, also was glaubt ihr wie wie komplex? Und ich sage bewusst, wie komplex dieses Ticket ist. Also diese Teilaufgabe, die wir erledigen sollen.
Zu 90% fangen die Leute an zu sagen, ich denke, ich brauche eine Woche. Das wird mich so und so viel Stunden kosten und du fällst immer und das ist nicht mal unbedingt geschuldet den Entwicklern also oder Entwicklerinnen aus dem Scrum Team, sondern da haben wir wieder die alte Strukturen, die dann auch wieder reingreifen. Ja, aber ich muss wissen bis wann du das alles fertig hast.
Ich muss Meilenstein aufplanen ja bis wann hast du das alles fertig, sag mir wann hast du es fertig so weißt du und da finde ich, ist es halt auch einfach geil, wenn du zum Beispiel sagst, ey, wir machen, wir schätzen, wir müssen Tickets schätzen, das ist n fester Bestandteil, der ist wichtig, bin ich ganz dabei ne, aber lasst uns doch mal nicht alles auf Zeit Münzen, am Ende sagst du immer es gibt Story Points so ne das ist der Klassiker weil das Framework sagt Es gibt Story
Points ja und am besten nach Fibonacci ja das ist ganz wichtig aber du Maps es auf Zeit. Du mapst es zu 90% in Teams auf Zeit.
Nach meinen Erfahrungen und das ist schade, lass doch sagen, nee, wir haben keine Zeit mehr, wir schätzen keine Ahnung, irgendwas Absurdes nach Bananen ja, also eine Banane, 2 Bananen oder 3 Bananen die 3 Sachen hab ich jetzt an Komplexität zum Beispiel klingt jetzt n bisschen absurd, aber versucht es doch mal, weil dann ist ja die Kommunikation auch entscheidend und die Zusammenarbeit im Team. Lasst uns n Ticket planen, lasst es refined, lasst uns zusammen drüber sprechen.
Was beinhaltet das Ticket, hat jeder das Verständnis über dieses Ticket, wie du ja auch meintest. Ja kann jeder sagen, ich weiß was zu tun ist und dann ist doch am Ende nur entscheidend sagen alle eine Banane, 2 Bananen oder 3 Bananen oder sagt die Hälfte des Teams 3 Bananen und die andere Hälfte eine Banane, dann hab ich ja ne Diskrepanz da drin, dass es scheinbar nicht klar ist. Richtig, weil deine Ding ja, das geht übelst.
Easy und jemand anders sagt ja, das hat aber echt ne Menge was da irgendwie mit reinfließt so und dann denkst du dir so OK, aber was stimmt denn jetzt? Ne weil stell dir mal vor und und das ist ja das interessante, du hast also einheitlich im Team nicht das gleiche Verständnis darüber, aber zum Beispiel die
eine Person würde sagen. Also wenn ne ich sag jetzt mal es ist nicht so komplex, ich schaffe es vielleicht schneller ne wir gehen jetzt wieder sozusagen in diesen in diese Zeit, die irgendwo dann wiederum gefordert wird und dann hast du vielleicht von der einen Seite, die sagt ja es geht recht schnell, die anderen sagen es dauert n bisschen länger, weil es ist echt nicht so easy, da muss n bisschen was gemacht werden, so und dann ist ja auf einmal der Punkt, dass egal wen,
also es ist nicht egal wen du fragst, sondern es ist abhängig davon, wen du fragst, wie schnell es passiert. Also ne wenn jetzt jemand wirklich wieder an diesem Punkt ist und sagt ich brauche schnell, muss schnell sein wann. Wann hab ich das ich brauch meinen ne meinen Meilenstein jetzt so. Genau.
Und dann kommst du an den Punkt, dass du nach jeder Iteration, und da können wir auch gleich zum letzten Punkt kommen, wenn es um Retros und Transparenz geht, dass du dann halt sagst, passt auf wir als Team mit unserer, mit unserer Leistungsfähigkeit, die wir haben können. 20 Bananen liefern ja, so weißt du, und die Leute denken sich so. Was hä, gerade wenn denn so alte Strukturen wieder reinkicken ja wat 20 Bananen. Ich will wissen wann die das
hier fertig ist. Nein, aber wir schätzen die Tickets, wir sagen wie komplex die sind und wir können sagen, wieviel Komplexität schaffen wir in einer Iteration und das musst du ja und dafür ist auch ne Retro da was lief gut, was lief schlecht, haben wir uns übernommen, müssen wir gucken ob wir vielleicht besser schätzen, warum haben manche gesagt 3 Bananen, manche eine Banane. Wo war jetzt die goldene Mitte?
Ja, also feedbackzyklen, du musst ja einfach immer dieses Feedback generieren, um dran zu wachsen und besser zu werden und irgendwann sagen alle ganz genau, wieviel Bananen das sind und du kannst ermitteln wieviel du schaffen kannst und kannst. Super Aufplanen deine Iteration und die Vision verfolgen durch den PO beispielsweise und das sind genau die Sachen, die am Ende Agilität erfolgreich machen und da kommt jetzt der fünfte Punkt rein, Widerstand gegen Transparenz.
Und gegen Retros und Konsequenzen daraus super oft erlebt, wie du ja auch meintest, Oh schon wieder ne Retro. Ja hier was lief gut, was lief schlecht, was müssen wir weitermachen, was können wir verändern und wie verändern wir das? Viele haben dieses Framework gelesen, haben verstanden was es eigentlich machen soll, leben es aber nicht richtig und da kommt der Scrum Master auch wieder rein, der Scrum Master wie du meintest muss ja.
Abhängig von der aktuellen Situation, die Retroform ja, gehen wir vielleicht mehr in die Mindset Richtung, haben wir vielleicht mehr störende Faktoren von außerhalb des Teams. Vielleicht läuft ja im Team alles runter, aber es kommt sehr viel, also Störung von draußen, dann kannst du ja die Retro auch in die Richtung lenken, wie können wir uns mehr schützen davon, wie können wir besser nach draußen kommunizieren, das was nicht richtig läuft.
Und deswegen kann eigentlich keine Retro immer gleich sein, wenn man sie richtig lebt, sage ich mal. Also ich hatte zum Beispiel mal eine Zeit in meinem Arbeitsleben, da hatte ich auch Retros, die waren nie gleich, die waren immer irgendwie anders, waren immer anders aufgebaut und waren dann aber auch zum einen Halt eine willkommene Abwechslung. Es war immer, es hat immer Spaß gemacht, diese Retro zu machen, weil einfach der AJ Coach an dieser Stelle genau den richtigen Job gemacht hat.
Und du auch gemerkt hast, da wird nicht gechillt. Die sind also wirklich die ganze Zeit während ihrer Arbeitszeit damit beschäftigt, AGI Coach zu sein und nicht 10% AGI, Coach, 20% PM und dann noch vielleicht n bisschen. Developer oder so? Keine Ahnung. Ne so, sondern da wurde sich darauf fokussiert und das gemacht. Und gerade bei Retros zum Beispiel das Problem finde ich bei retros warum viele Leute glaube ich auch der Meinung sind Retros sind Quatsch und die
bringen nichts ist. Ganz einfach, weil wenn du so an so an ne Retro rangehst und sagst ja OK das ist der Pain Point, das ist n Pain Point ja gut, OK dann lass mal gucken was können wir dagegen machen weiß ich nicht, vielleicht mal drüber sprechen ja OK wann wollen wir das machen, ja dann und dann wer denkt dran ja lass mal alle dran denken und dann denkst du dir so ja OK das ist so schwammig, da passiert halt gar nichts also wenn du ne retro machst wo du Pain Points festlegst und keine
Konsequenzen daraus ziehst. Ne, also nichts tust um dagegen zu steuern. Ja gut, dann bleibt es halt auch so, dann kannst du tatsächlich ne retro einfach lassen, dann bringt es nichts so aber wenn du sagst du machst ne retro und kriegst dann im Endeffekt wirklich Konsequenzen daraus die du einleitest am Ende auch ne, dann ist es gut, dann kannst also ne dann dann kannst du damit arbeiten, dann funktionieren Retros und so sollten Retros auch sein.
Oftmals ist es ja auch so, dass dann irgendwie gesagt wird, ja, hier das und das ist nicht so gut gelaufen, dann kommt jemand, sagt, warum ist das nicht so gut gelaufen, ihr arbeitet schlecht, ne also ich übertreib jetzt ne, aber das ist halt eher nicht so NOK schön, wir haben was gelernt ist sondern so n wir haben es ja nicht richtig gemacht, ihr seid blöd ne so Peitsche drauf anstatt zu sagen Wow cool, wir haben was gelernt so ne aber und
ich finde das ist auch n kleines Problem, dass oftmals hast du ja n Punkt zumindest ist das mein Verständnis. Du kommst irgendwo in irgendwelchen Projekten an Punkt, wo es heißt, scheiße, Wir schaffen das nicht, wir, wir kriegen es nicht hin. Das gehört dazu.
Was müssen wir jetzt tun? Ja, wir machen jetzt, lass uns agile nehmen, weil mit agile schaffen wir es so und dann drückst du von jetzt auf gleichen agiles Framework auf ein Projekt, was einen unglaublich hohen Zeitdruck von, ich sag mal verschissenem Projektmanagement hat. So, und jetzt hast du Zeitdruck plus ja, jetzt sind wir aber agil und damit schaffen wir das ja easy peasy und genau das ist das, was richtig richtig schlecht ist.
Wenn du nicht denkst, dass eine Änderung erstmal vielleicht Zeit braucht um sie anzunehmen so, sondern sagst es muss morgen fertig sein und heute machen wir, damit wir morgen fertig sind und. Das funktioniert halt nicht, ne, also das ist halt n Punkt, was definitiv hundertprozentig kaputt geht. So ja du hast halt einfach ne Zeit die du brauchst um sowas zu etablieren und das wächst halt.
Also ich habe noch kein agile Team erlebt, was von Anfang an richtig gut funktioniert hat, vielleicht weil ich einfach noch nie in einem Team war oder reingekommen bin, sagen wir es mal so. Die jetzt vielleicht jahrelang in agilen Teams gearbeitet haben, die erfolgreich waren.
Ne, also dass du wirklich reinkommst und alles sofort geil ist, weil das das ist auch gar nicht das Ziel, oder oder, oder die Erwartungshaltung, sondern wie gesagt, weil wir ja beim Thema Retros sind, zu sagen, wie können wir uns verbessern, ja,
also auch. Die agile Arbeitsweise hat Feedbackzyklen und es ist wichtig zu merken, wären wir besser, ey, guck mal, vor ein paar Monaten hatten wir das und das Problem, das machen wir viel besser mittlerweile ne, das ist ja auch Agilität am Ende und ein wichtiger Punkt, woran es auch oft scheitert, den möchte ich noch ansprechen bevor wir dann denke ich mal durch sind. Mit der Folge ist einfach, dass man sage ich mal offen kommuniziert und sich traut zu
kommunizieren. Gerade eine Retro im Team ist n Space, was da gesagt wird, sollte auch in diesem Space bleiben. Ja, also ich kann vertrauensvoll innerhalb meines Teams kommunizieren, was mir nicht schmeckt oder wo ich Probleme sehen, dass es mir nicht gut geht damit und ich kann im Team dann Maßnahmen treffen, wie können wir uns beispielsweise nach außen hin schützen, wenn sehr sehr viel Druck von außen kommt?
Alle Sonne Themen und deswegen man muss ein Umfeld schaffen wo sich jeder aus dem Team sag ich mal bereit fühlt offen die Punkte anzusprechen und keine Angst davor hat, das ist ganz wichtig und das ist auch ganz oft ein Knackpunkt, dass sich Leute denken, ich sag jetzt eh nichts, das gibt nur Ärger oder ich sag eh nichts, weil es ändert sich nichts, dass diese beiden Punkte sind halt so Hauptgrund warum so was scheitert oder eine Retro schlecht angesehen wird.
Und das gilt es halt einfach zu verhindern. Also man darf da auch wirklich mal Tacheles reden. Ja und nicht weich gespielt, sondern sagen, Ey Pass auf, ich find das Scheiße jetzt hier wie das gerade läuft, das find ich nicht geil so weißt du und das ist n Punkt, gerade wenn man selbst merkt so ich hab keinen Bock auf die Retro sich mal selbst zu challengen und zu sagen.
Mach ich das also? Was ist meine Erwartung von der Retro und arbeite ich aktiv dran mit, dass die Retro erfolgreich wird oder oder funktioniert oder wo also und selbst wenn ich das Gefühl hab, dass die Retro nicht sinnvoll ist, ist die Retro der richtige Punkt um das anzusprechen. Ja richtig, das auf jeden Fall. Und ich finde, weil du meintest so OK, du warst noch vielleicht noch nie in einem Team, wo es von Anfang an richtig gut funktioniert hat.
Wenn man die Erwartung hat, dass es vielleicht irgendwie ein Team gibt, wo es einfach nur komplett flutscht. Ich glaube, es gibt vielleicht Teams, die haben das Mindset schon weit, also schon deutlicher etabliert oder weniger, aber Fakt ist es, dass du immer wieder in der Retro an Punkte kommst, wo du sagst, das müssen wir ändern und es heißt auch nicht, dass wenn du sagst, lass uns das mal so probieren.
Dass es dann heißt, das muss jetzt die Lösung sein, sondern man guckt in der nächsten Reto drauf, hat es denn jetzt
wirklich funktioniert? Wir haben ne Maßnahme getroffen, bringt uns diese Maßnahme in die richtige Richtung, wenn nicht, wir können es ja auch anders probieren, aber wir müssen es probieren, wir müssen daraus lernen, es wird immer irgendwelche Punkte geben, die es zu verbessern gibt, vielleicht sind die Punkte, die du gestern verbessern wolltest und die du weiß, nicht heute gelöst hast morgen Probleme, man weiß es nicht genau, es kommt halt drauf an, es ist halt immer
wieder etwas was. Sag ich mal wieso ne wabernde masse ne und du du wirst halt nicht sagen jetzt ist es perfekt und jetzt bleibt es perfekt so und das muss man halt glaub ich einfach auch verinnerlichen, dass es halt permanent ein Wandel ist und eine etwas woran man arbeitet. Ne, wie vielleicht auch an sich selber beispielsweise.
Ansonsten Tino, Danke fürs Gespräch, war auf jeden Fall super spannend, ich find das Thema ist heftig und ich glaub das ne knappe Stunde reicht da gar nicht das zu covern aber liebe Zürer lieber zürer uns interessiert auch mal mega was du zum Beispiel so für vielleicht tolle Seiten an Agile erlebt hast oder vielleicht auch welche Schattenseiten du erlebt hast. Welche Paint points du eigentlich auch immer wieder identifizierst. Wenn es mal wieder um agile geht.
Und vielleicht kann es ja auch sein, dass du sagst, ey, ich würd niemals nach agile arbeiten, soll es ja auch geben, aber dann schreib uns doch mal. Wieso eigentlich?
Also ich denk mir dann so, vielleicht könnte man da auch irgendwie ne fehlerhafte Erfahrung gemacht haben und man muss dazu aber auch sagen, Agile ist ja auch nicht immer das Heilmittel, es kommt drauf an in welchem Scope man arbeitet, ob es denn überhaupt sinnvoll ist oder nicht muss man ja auch dazu sagen, es ist nicht immer sinnvoll so ne. Aber, und die Mail ist in den in den Shownotes. Genau, Mail in den Shownotes Discord, wo auch immer.
Schreibt uns auf den Plattformen eurer Wahl alles in den Shownotes drin und ansonsten Tino würde ich sagen, das war es für heute macht es gut, wir hören uns in der nächsten Folge deine Calling Buddies gemeinsam besser.