Latest / Coding Buddies | Tech & Dev-Mindset / Warum agile Frameworks oft scheitern

Transcript

Warum agile Frameworks oft scheitern · Coding Buddies | Tech & Dev-Mindset

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