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.