Latest / Coding Buddies | Tech & Dev-Mindset / Interview mit Felix - So schätzt du deine User Stories (Dogge oder Chihuahua)

Transcript

Interview mit Felix - So schätzt du deine User Stories (Dogge oder Chihuahua) · Coding Buddies | Tech & Dev-Mindset

0:00
Aber manchmal hat man ja doch so eine Problematik auf dem Tisch.
0:03
Und ich bitte lass mich weiterentwickeln.
0:05
Ich will jetzt. Keine Retro machen.
0:08
Coding Buddy, Dein Podcast rund um Softwareentwicklung und
0:11
aktueller Tech News herzlich Willkommen.
0:25
Ja, herzlich Willkommen zur neuen Folge des Coding Bodies
0:28
Podcast. Natürlich wieder der Gastgeber.
0:31
Einerseits meine Wenigkeit Tino und natürlich auch der Fabi Moin
0:34
Fabi. Morgen Tino, Grüß dich los.
0:38
Alles gut bei dir, los geht s bei mir, weil.
0:40
Ich merk schon, du bist voller Elan, du hast Bock.
0:43
Ja heute hier. Ist immer wieder.
0:47
Special heute Special genau, wir haben heute eine besondere Folge
0:50
wieder, und zwar um nochmal kurz einzuleiten.
0:52
Wir hatten ja das Thema Scrum schon mal besprochen, dass wir
0:55
nach diesem Modell arbeiten. Und sind ja zu dem Punkt
1:00
gekommen, dass dieses Thema Aufwands, Schätzungen ziemlich
1:03
komplex und schwierig ist und dass in vielen Teams wirklich
1:07
ein Punkt ist, der nicht so geil läuft.
1:11
Ja und Special Folge in dem Sinne, dass wir uns heute einen
1:13
Gast eingeladen haben, um dieses Thema mit ihm mal zu besprechen.
1:17
Magst du unseren Gast mal vorstellen?
1:19
Jo, also mal wieder ein Interview.
1:21
Genau ja, also wir haben hier einen Gast bei uns, der Felix
1:26
und Felix ist jetzt auch. In die IT in der IT Welt
1:31
gelandet, also auf die dunkle Seite rüber gewechselt,
1:33
sozusagen. Weil Felix kommt eigentlich
1:37
nicht aus dem IT Sektor so ursprünglich und hat jetzt aber
1:43
seinen Weg so n bisschen gefunden und zwar als Rolle
1:47
eines PM sozusagen im einem sehr agilen Umfeld, was natürlich
1:52
cool ist. Ich hatte mit Felix auch schon
1:54
paar mal gequatscht und ich finde es auf jeden Fall
1:56
spannend, wie agil ja. Da auch gearbeitet wird, genau,
2:02
und deswegen will ich jetzt begrüßen, Felix, Hi Felix.
2:06
Moin, ja vielen Dank. Vielen Dank für die Einladung.
2:09
Ich freue mich hier zu sein. Ja, sehr gerne.
2:11
Danke, dass Bock drauf hattest. Finden wir cool genau und ich
2:17
kann ja einfach mal loslegen und zwar würde mich jetzt mal kurz
2:21
interessieren, wie bist du eigentlich sozusagen zu i
2:25
gekommen, weil ich hatte ja gerade schon mal gespoilert,
2:27
dass ja eigentlich gar nicht aus dem Sektor kommt, so oder
2:30
ursprünglich. Quasi weil du bist ja jetzt Teil
2:32
davon, ne, mittlerweile kommst du daher.
2:35
Ja genau, also ich hab humanwissenschaftlichen
2:40
Studiengang im Bachelor studiert.
2:43
Der Studiengang nennt sich Kaltrina Engineering und ist
2:46
eine Mischung zwischen humanwissenschaftlichen Fächern.
2:50
Noch ein paar technische Fächer dabei gehabt und da habe ich
2:54
schon gemerkt, dass mir so Wirtschaftsinformatik Fächer
2:56
ganz gut gefallen haben. Und Maß habe ich dann
3:01
Informationswissenschaft studiert.
3:04
Auch einige IT basierte Fächer gehabt.
3:08
Und ja, dann habe ich Praktika gemacht im Bereich digitale
3:13
Transformation und bin jetzt ja im agilen It Umfeld gelandet, in
3:22
der Rolle eines Projekt Managers oder agilen Projekt Managers.
3:27
Aber wenn wir jetzt nochmal kurz zu was hast du gesagt,
3:29
Humanwissenschaften? Was richtig also, wenn ich das
3:34
jetzt so höre, würde ich mir denken, so OK human
3:36
Wissenschaften, also krass, dass es da, weil du meintest, da gab
3:40
es da auch schon so Wirtschaftsinformatik, teile da
3:42
drin. Genau, ja.
3:44
Also ich hatte so eine Mischung aus Kulturwissenschaft, war ein
3:48
großes Modul. Dann war BWL ein Modul.
3:53
Logistik war auch ein großes Modul Wissensmanagement und da
3:56
hat das Ganze schon angefangen bei Wissensmanagement das
3:59
teilweise die IT auch eine Rolle gespielt hat.
4:03
Unter anderem habe ich auch Wahl, Wahl, Fächer im Bereich
4:07
Wirtschaft und Martin belegt. Krass cool.
4:10
Das heißt, du konntest dich da so in die Richtung auch n
4:12
bisschen spezialisieren. Schon genau a cool, aber
4:15
hauptsächlich war ja, die Kulturwissenschaften standen im
4:19
Vordergrund. Alles voll interessant, weil so
4:23
ich hätte jetzt so intuitiv gedacht, so Humanwissenschaften,
4:27
also würde ich jetzt überhaupt nicht so mit mit überhaupt damit
4:30
verbinden, dass zum Beispiel Wirtschaftsinformatik, Logistik
4:33
oder so gelehrt wird. Finde ich schon interessant,
4:35
dass das irgendwie also der Name ist, so als würde man sagen, so
4:39
OK Sport, Wissenschaften bitteschön und jetzt für deine
4:43
erste OP durch sind, nach dem Motto so kommt es mir gerade,
4:47
aber geil, das ist ja cool und dann hast du dir gedacht, OK
4:49
nice so die IT Welt, sag ich jetzt mal so die was hattest du
4:54
gesagt so Datenmanagement und Analyse und so in die Richtung
4:57
fandest du dann cool und dann hast du das quasi Master n
5:00
bisschen vertieft. Genau so kann man das sagen.
5:03
Nice. Cool, du hattest jetzt gesagt,
5:06
du hast verschiedene Praktika gemacht.
5:08
Hattest du da denn auch schon Berührung mit der agilen Welt
5:12
oder ist das später dann gekommen?
5:16
Etwas beziehungsweise wenig also die agilen Praktiken, die da
5:21
gelebt wurden. In meinen ersten Praktika, die
5:24
waren. Ja, so mehr during a statt Bing
5:29
agile also das man hat so mehr das so als Konzept genommen um
5:36
sich irgendwie so ein bisschen zu profilieren und sich so ein
5:38
bisschen vom Rest des Unternehmens abzukapseln und zu
5:43
sagen, ja wir sind agil unterwegs, ja, aber so das
5:46
richtige agile Arbeiten habe ich erst später kennengelernt.
5:49
OK, das finde ich mega spannend zu sagen, doing agile und nicht
5:54
Bing a es. Auf jeden Fall eine sehr coole
5:57
Formulierung. Magst du das nochmal n bisschen
5:58
drauf eingehen, also wie unterscheidest du dazwischen?
6:04
Oder also warum explizit erwähnst du das?
6:08
Also das ist ne gute Frage. Also doing l geil ist.
6:14
Wenn man sozusagen agile Praktiken nimmt, um zu sagen,
6:20
wir arbeiten agil, aber oftmals ist es so, dass in.
6:26
Unternehmen mit einer relativ, ja konservativen
6:30
Unternehmensführung kann da Grenzen oder Riegel vorgesetzt
6:35
werden. Und bei Being Agile ist es eben
6:38
so, dass ja diese agilen Methoden und.
6:43
Ja, agilen Arbeitsweisen eben. Über alle Hierarchie stufen
6:48
hinweg akzeptiert werden und eben auch richtig gelebt werden.
6:51
Und dass man da eben keine, ja Barrieren sozusagen hat.
6:57
Ja, also das wird, da wird das sozusagen bei Bing A dial, wie
7:02
das wie der Begriff oder die Phase schon sagt, wird das halt
7:04
richtig gelebt, ohne dass man jetzt sagt, OK, wir machen das,
7:08
um irgendwie ja einen coolen Begriff zu haben, wie wir
7:12
arbeiten. Ja, sozusagen auf die Fahne.
7:14
Schreiben ja, wir sind agil und Hauptsache man, man hat
7:19
irgendwie dieses dieses Attribut an sich dran kleben ne genau ja,
7:24
also das ist wirklich ein cooler Punkt, weil das auch so ein
7:27
Fazit war aus der Scrum Folge die wir schon mal gemacht
7:31
hatten, dass diese agile Denkweise, also das ist wirklich
7:35
ne Mindset frage ist also nicht einfach nur dieses Prädikat agil
7:40
sich an die Abteilung zu schreiben, sondern dass wirklich
7:43
auch zu leben und nicht einfach sich.
7:45
Quasi in diese Struktur zwingen sie eigentlich gar nicht cool
7:47
finden, weil dann kann es am Ende auch nicht funktionieren,
7:50
ne, deswegen finde ich diese Formulierung sehr cool von dir.
7:53
Auf jeden Fall muss ich mir auf jeden Fall merken.
7:55
Ich hab das ich, ich hab das auch schon mal gehört, dass man
7:59
zum Beispiel, also ich habe meinen Satz gehört, dass wenn du
8:02
sozusagen Leute oder ein Team dazu zwingst, nach Scrum oder
8:07
anderen agilen Arbeits methoden zu arbeiten, also sozusagen
8:09
diesen diesen Stempel aufdrücken, sagt, wir machen das
8:12
jetzt so, dann funktioniert es nicht, dann ist sozusagen also.
8:15
Es war ein bisschen drastischer formuliert, das war so richtig
8:17
so. Dann ist es zum Scheitern
8:19
verurteilt, und dann dachte ich so, ja, OK, krass bisschen
8:22
überspitzt dargestellt, aber ich stelle mir auch vor, weil im
8:25
Endeffekt brauchst du dieses Mindset, das hatten wir, hatte
8:28
Tina gesagt, also glaub ich halt auch, dass man dieses Mindset
8:32
braucht und nicht nur sagt, Wir haben jetzt also Scrum
8:36
funktioniert, nach sag ich jetzt mal.
8:40
Termin 1234 und wenn wir die machen, dann sind wir, dann
8:43
arbeiten wir nach Scrum und alles ist cool ne, sondern da
8:46
musst du es halt doch oben drin sitzen im Köpfchen ne.
8:49
Aber ja, geile Formulierung mag ich auch gerne.
8:51
Genau. Also dazu ergänzen kann man
8:53
vielleicht auch sagen, dass also so, wenn sich agile Inseln im
8:58
Unternehmen bilden. Das ist natürlich auch nicht so
8:59
cool, ne, also wenn. Abteilung XY und Z Agil arbeiten
9:04
und Abteilung ABOC aber konservativ oder?
9:09
Ja, ich weiß nicht wie ich das nennen soll.
9:11
Dann wird es konservativ. Ist natürlich auch schwierig,
9:17
zwischen diesen Abteilungen irgendwie einen Konsens zu
9:20
finden und auf einen Nenner zu kommen.
9:24
Ja, ja, ich hab also, aber kann es nicht theoretisch auch sein,
9:27
dass man sagt, so OK, man hat vielleicht so eine Insel oder
9:30
mehrere Inseln, die so richtig agil arbeiten und so?
9:33
Sag ich mal Vorreiter sind und dann vielleicht den
9:37
konservativen Abteilungen eventuell Vorleben und sagen,
9:40
guck mal, wir machen es so und so und guck mal, das
9:42
funktioniert richtig gut, also vielleicht kann also frage ich
9:46
mich gerade, ob es auch in die Richtung funktionieren kann.
9:49
Ja, das funktioniert sicherlich. Also ich glaube auf jeden Fall,
9:52
dass das funktionieren kann, indem ein Unternehmen, wo ich
9:56
Praktikum gemacht habe, ich halt gesehen, dass das nicht
9:58
funktioniert, weil wir waren sozusagen die agile Insel und um
10:03
uns herum haben alle anders gearbeitet, wegen nach
10:09
Wasserfall mit Wasserfall, Projektmanagement, Methoden und
10:13
dann hat eben nicht funktioniert oder auf einen Nenner zu kommen,
10:17
es funktioniert ja ich auch. Also ich frag das nur gerade,
10:21
weil in der Abteilung, wo ich vorher gearbeitet habe, bevor
10:24
ich jetzt zu Tino ins Team gewechselt bin, war das relativ
10:28
ähnlich. Also wir hatten ne stark agile
10:31
Abteilung, wo das Mindset auch gestimmt hat.
10:34
Wo es wirklich sehr, sehr agil alles gelebt wurde, und das war,
10:38
aber wir waren halt auch so eine Art Insel, eine Art, ja, guck
10:42
mal, wir arbeiten jetzt nach Scrum und.
10:46
Mein Resümee daraus war, dass es von den anderen Abteilungen, von
10:49
den konservativen Abteilungen oder Konservativen, Ich sag
10:53
jetzt mal Leitern, leiterinnen so ein bisschen aufgefasst wurde
10:58
wie, ja, guck mal, das funktioniert richtig geil bei
11:00
denen und gleichzeitig, und das war das, sag ich mal, paradoxe
11:05
an der ganzen Geschichte oder sogar schizophrene, hieß es dann
11:08
so, ja, also. Aber eigentlich müssen wir mehr
11:13
nach Prozessen arbeiten und das, was ihr da macht, ist irgendwie
11:15
nicht so geil. Und eigentlich müssen alle nach
11:17
einem ganz bestimmten Arbeitsmodell arbeiten.
11:19
Und wenn ihr da so die Ausnahme seid, ist eigentlich blöd und
11:22
dann denk ich mir so, weil das fand ich halt krass, weil genau
11:25
das, was ich dich gerade gefragt hab, das wurde sozusagen bei uns
11:27
n bisschen versucht zu machen, aber über dieses wir überzeugen
11:33
jetzt extrem hinaus kam es halt nicht, weil ich glaube, dass
11:35
halt einfach so der Rest dieser Moloch war einfach zu groß.
11:40
Und das ist genau der Punkt. Wieder ne das.
11:44
Das wirklich ne Mindset frage am Ende ist und es ist halt
11:48
schwierig. Also ich verstehe absolut wenn
11:50
man sagt man hat so eine Insel und man es ist ein riesen
11:54
Herausforderung diese Schnittstellen aufzubauen zu
11:56
anderen Abteilungen weil das beißt sich halt extrem diese
12:00
agile Weise nicht schnell auf Änderungen reagieren zu können
12:03
oder strikt nach Prozess irgendwas abzuarbeiten und das
12:06
auf den Nenner bringen ist halt auch verdammt schwierig.
12:08
Und ja diese ganze Prozess Thematik ist halt auch wirklich
12:13
konservativ, ist es wichtig klar, je nach Projekt.
12:16
Sehr wichtig sogar, aber das muss einfach auch vereinbar
12:19
sein. Und deswegen finde ich also
12:21
gerade bei uns jetzt ein Team, versuchen wir es ja auch
12:24
bestmöglich zu vereinbaren und selbst da haben wir ja auch
12:26
Herausforderungen. Also ich kann das auf jeden Fall
12:28
nachvollziehen, dass man diese Erfahrung macht und sagt, so,
12:31
ja, nee, das hat nicht so geil funktioniert am Ende, also das
12:36
ist wirklich herausfordernd, auf jeden Fall.
12:39
Man darf ja auch nicht vergessen, dass dass es in bei
12:42
den agilen Arbeits methoden ja genauso Prozesse gibt.
12:46
Also es gibt ja genauso. Prozesse wie in anderen in
12:50
Wasserfall Modellen. Es ist nur eben nicht so, dass
12:54
also es ist nicht so, dass man sagt, wir arbeiten agil und dann
12:57
macht jeder was er will, also so ist es ja auch nicht, man hat ja
13:00
obwohl viele denken ne, ja genau das ist auch ein
13:02
Missverständnis, guter Punkt, das ist ja irgendwie, also man
13:07
hat ja trotzdem Framework, wo man sich daran orientiert und da
13:10
ist ein Unternehmen oder eine unter Abteilung Halt eingebettet
13:15
und klar, es gibt links und rechts noch ein bisschen
13:18
Spielraum. Aber du hast ja auch agile
13:21
Prozesse, sag ich mal an den du dich orientiert.
13:24
Na ja, das stimmt. Aber wie ist denn das bei dir
13:26
zum Beispiel so? Wenn also ich hatte ja auch mal
13:30
mit dir darüber gesprochen oder du hattest mir doch mal erzählt,
13:33
dass da, wo du jetzt gerade bist, das ist ja schon wirklich
13:37
stark, agil ist das Unternehmen. Funktioniert das bei euch dann
13:43
auch so gut? Ja, ich würde sagen schon.
13:47
Also dadurch, dass fast jedes Team oder eigentlich jedes Team
13:53
agil unterwegs ist, funktioniert das sehr gut und ich muss sagen,
13:59
bei uns wird das auch gelebt. Also das ist wirklich, also ich
14:03
würde sagen, das ist wirklich Wing l.
14:05
Und das funktioniert sehr gut. Da hätte ich mal eine Frage zu
14:11
hat das relativ schnell funktioniert.
14:13
Also so man hat Geschnipst und dann lief das oder war das ein
14:17
Prozess über? Also jetzt haben wir das Wort
14:19
Prozess, aber also quasi, dass es sich hin entwickeln musste,
14:22
bis das wirklich bei jedem angekommen ist.
14:24
Weil ich hab immer das Gefühl, dass es schon eine gewisse
14:26
Lernkurve dabei gibt, das richtig zu zu leben, sozusagen
14:30
ne. Ja, da stimme ich dir zu, aber
14:32
das kann ich dir sogar nicht beantworten, weil ich nichts
14:35
unternehmen gekommen bin und das war schon komplett agil.
14:38
Nicht gestellt. Und ich konnte sozusagen noch
14:41
viel von von meinen Kollegen und Kolleginnen lernen und nicht
14:45
umgekehrt. Also das war schon komplett agil
14:49
unterwegs. Also da war quasi schon alles
14:51
etabliert und konnte es dann quasi direkt spüren, wie es
14:55
funktionieren kann. Nach der deiner vorherigen
14:58
Erfahrung sag ich mal. Also auch da läuft das natürlich
15:01
nicht perfekt und ich meine in ja, agile Methoden sind auch
15:06
kein Wunder Mittel. Ja, auch da gibt es.
15:10
Die Hürden und so. Aber das hat schon alles gut
15:13
funktioniert. Es ist ja auch so, dass
15:15
bestimmte Projekte ja auch, also es gibt ja Projekte, wo man
15:19
wunderbar nach AL oder nach agilen Arbeits methoden arbeiten
15:23
kann, zum Beispiel nach, und es gibt ja auch durchaus Projekte,
15:26
das hatten wir auch in unserem Fall gemacht, dass man bei
15:30
manchen Projekten macht es halt eben keinen Sinn, nach Scrum zu
15:33
arbeiten oder nach anderen agilen Methoden, ne, also das
15:36
ist ja auch noch so ein Ding, was da sozusagen noch ein
15:38
bisschen top kommt, aber wie war denn das?
15:41
Für dich also wenn du jetzt zum Beispiel du bist, hast du
15:43
angefangen und wie lange, wie lange bist du jetzt schon in dem
15:47
Unternehmen? Knapp 2 Jahre.
15:50
Da ist er auch schon ganz schönes Stück.
15:51
Also was ich fragen wollte war, wie lange hat es für dich
15:54
gedauert sozusagen, also konntest bist du da rein
15:57
gekommen ins Unternehmen und hat gesagt, ja cool, hier bist du
16:00
sozusagen gleich mit verschmolzen oder hattest du
16:02
irgendwie n paar Punkte wo du auch angeeckt bist, gedanklich
16:05
vom Mindset was wir gesagt haben, dass du dir dachtest, so
16:09
weiß jetzt gar nicht ob das jetzt gerade so float von meiner
16:13
von meiner Ansichtsweise zu der Sache, also kann ja durchaus
16:16
sein, dass man reinkommt und so, das ist ja was ganz anderes.
16:19
Als ich gewohnt bin. Ja, also voll.
16:22
Also das muss natürlich lernen, ne.
16:24
Also es gibt auch bei Scrum gibt es ja bestimmte Scrum Events,
16:28
die auch irgendwie Iteration, also einen Sprint, irgendwie
16:32
einen Rahmen und das sind ja auch Regel Termine die du hast.
16:36
Und darin werden eben bestimmte Sachen besprochen, und das muss
16:39
man eben auch lernen, weil dazu gehört eben auch ein gewisser
16:41
Theorieteil, an denen du dich irgendwie.
16:45
Hältst jedes Unternehmen ändert das auch ab und zu mal ein
16:48
bisschen. Also das ist nicht immer Scrum
16:50
nach Lehrbuch, aber auch auch da muss man halt, muss man da am
16:55
Anfang ein bisschen lernen, es ging mir nicht anders.
16:59
Ist wirklich sehr witzig, dass du sagst nach Lehrbuch, weil ich
17:02
glaube ich habe jetzt schon in mehreren Teams nach Scrum quasi
17:05
gearbeitet, aber es war halt immer du hast ähnlich.
17:07
Also ich warte noch darauf, ist man wirklich so richtig nach
17:11
Lehrbuch zu leben, weil das halt wirklich nicht so einfach ist
17:13
und auch wirklich der Unternehmens abhängig.
17:16
Er hat irgendwelche Rand Einflüsse kommen die es dann
17:19
doch schwer machen das wirklich immer komplett so durchzuziehen.
17:22
Ne ja das ist ja, da hatten wir ja quasi auch in der Scrum Folge
17:27
vom Podcast auch mal drüber gequatscht, genau über diesen
17:30
diesen Punkt also auch noch mal. Wenn jetzt irgendwie die
17:33
Zuhörerinnen oder Zuhörer sich fragt, OK, was ist denn das für
17:36
n Termin von dem Felix gerade gesprochen hat?
17:39
Wir haben das Trump Folge, hört euch die Folge an und dann seid
17:42
ihr auf jeden Fall auch wieder genau.
17:44
Jetzt wieder ein hier genau merkt euch.
17:47
Ja, wart genau nee, aber was mich jetzt, weil du meintest du
17:52
man braucht ja zum Beispiel so n paar, man muss ein paar Sachen
17:56
lernen und ich finde da kommen wir jetzt vielleicht gerade ganz
18:00
gut auf den Punkt, weil es ja auch einen Termin ist, wo man
18:05
sozusagen das Planning macht, also beziehungsweise auch
18:08
schätzt wie viel du n Aufgaben, Aufgaben, Bruchstück und dieses
18:15
dieser Task, der muss ja im Normalfall.
18:18
Geschätzt werden also oder wird dann quasi vom Team geschätzt.
18:21
Also ne Entwickler, Entwicklerinnen sind dabei, der
18:25
PM ist dabei, der PO ist dabei, alles sind dabei, Designer,
18:30
Designerin wie auch immer ne also da sind auf jeden Fall ein
18:33
paar Rollen in diesem, so kenn ich das zumindest.
18:35
Ich also ne wie das Training stattfindet und mir zum Beispiel
18:43
persönlich als ich angefangen habe, damit ist mir das auch
18:45
richtig schwer gefallen also. Da war es zum Beispiel so.
18:49
Es gibt ja verschiedene Schätzmethoden, ne, also was
18:53
benutzt ihr denn zum Beispiel, wenn es um Schäden geht, für
18:56
Schätzmethoden beispielsweise? Ja, also wir schätzen nach Story
19:01
Points, manchmal auch nach t Shirt sizing.
19:05
Ja genau. Ich kenn nur Story Points zum
19:08
Beispiel und da gibt es ja, also ich kenn also wir haben zum
19:10
Beispiel so nach 012 und 3 Story Points geschätzt, es gibt ja
19:15
aber glaube ich auch nach Fibonacci oder linear oder?
19:20
Na ja, haben wir gemacht damals, aber das, Na ja, wir können ja
19:25
mal die Methoden so durchgehen. Würde mich mal interessieren,
19:26
vielleicht finden wir die den heiligen Gral.
19:30
Also ja, wir schätzen auch bei bei Story Points machen wir auch
19:35
nachi Folge t Shirt sizing ist SMLXL also das ist eine grobe
19:42
Schätzung. Aber das könnte man ja
19:45
vielleicht so mit den mit den Punkten, weil ich hatte ja
19:48
gesagt, 010123 sind ja quasi 4 Möglichkeiten und t Shirt
19:53
zeising, wenn du sagst SML und XL sind ja auch 4.
19:56
Also das ist ja dann vielleicht sogar, könnte man ja sagen,
20:00
vielleicht das gleiche. Genau.
20:02
Und dann gibt es noch die 3 Punkt Schätzung.
20:04
Also da hat man einen realistischen Wert, der liegt in
20:08
der Mitte und dann hat man einen pessimistischen Wert, der liegt
20:12
weiter unten und einen sehr optimistischen Wert.
20:16
Also der optimistische Wert stellt dann dar, wie schnell
20:21
können wir Aufgabe XY im Idealfall lösen.
20:27
Aber wenn du jetzt zum Beispiel sagst, dass es einen
20:29
realistischen Wert gibt und einen optimistischen,
20:32
pessimistischen, wie bestimmt man den realistischen wert, wenn
20:35
man ja gerade eigentlich dabei ist, was schätzen zu wollen?
20:38
Ja, das ist eine gute Frage. Also.
20:41
Da. Denn so Feeling oder was?
20:43
So Erfahrungswerte. Ich glaube, da spielen
20:46
Erfahrungswerte ganz viel mit rein oder vielleicht auch die
20:49
Kapazität der Kollegen und Kolleginnen oder andere stör
20:54
Faktoren, die dir vielleicht dazwischen funken können.
20:57
Die werden am Ende mit in Anführungsstrichen verrechnet.
21:01
Es ist ja OK, also sowas wie zum Beispiel wir gehen jetzt mal
21:04
davon aus, dass man an der Aufgabe arbeiten möchte, aber es
21:08
kommt zum Beispiel locker rein und man kann da vielleicht nicht
21:11
ohne weiteres daran arbeiten und hat Abhängigkeiten irgendwie
21:13
sowas in die Richtung könnt ihr pessimistischer pessimistische
21:18
Schätzung oder? Tendenz sein hab ich das so
21:21
richtig verstanden? OK, aber dann schätze ich 3
21:26
Werte mittel ich die dann noch mal oder also also das versteh
21:29
ich mit diesen 3 werten nicht, welchen nehm ich denn am Ende
21:31
davon? Das ist eine gute Frage.
21:35
Also wir haben die 3 Punkte schon im Moment auch nicht mehr
21:40
aktiv im Einsatz, aber ich glaube man man einigt sich dann
21:45
sozusagen mit dem Team. Aber OK, wird quasi nochmal.
21:48
Abgeschickt den Wert genau also das das Wichtige dabei ist
21:51
sozusagen die Diskussion und sozusagen der Prozess.
21:55
Niemand zu dieser Zahl kommt oder zu dieser Schätzung und
22:00
nicht die Zahl selber, sondern man geht irgendwie in den
22:03
Austausch und. Versucht dann herauszufinden,
22:06
wie es denn in der aktuellen Situation.
22:10
Ja, und unter den gegebenen Umständen, so die realistischste
22:16
oder die Beste. Schätzung das finde ich, ist ein
22:19
ganz cooler Punkt, weil im Prinzip meinst du damit, dass
22:23
man quasi. Erstmal was schätzt oder alles
22:27
schätzen was und dann ist aber eigentlich nachher der Austausch
22:30
entscheidend, um so nah wie möglich an die Realität
22:33
ranzukommen oder habe ich das jetzt falsch verstanden?
22:36
Ja, das kann man sagen, das ist richtig.
22:38
Ja, das ist eigentlich auch ne coole Betrachtungsweise.
22:41
Also schätzen denn alle aus dem Team für eine Aufgabe, auch wenn
22:46
sie vielleicht die selbst nicht übernehmen oder wirklich nur
22:49
die, die das auch bearbeiten sollen?
22:50
Wie ist das bei euch? Das Entwickler, also die
22:53
Entwickler, schätzen alle, also alle aus dem Team, die ja die
22:57
Rolle des Entwicklers soll Entwicklern haben, die Schätzen
23:00
die Aufgabe. Aber die arbeiten potentiell
23:03
auch schon an der Aufgabe dann. Kuenzel ja, aber es ist
23:08
natürlich dann in der Umsetzung nicht immer der Fall.
23:11
Na ja, ja ne, aber weil ich finde es interessant, weil mir
23:15
hat das also als ich angefangen hab so richtig, also richtig ne
23:18
nicht nach Lehrbuch aber richtig nach A zu arbeiten.
23:22
Ich hab ja extreme Programming gemacht, das ist ja auch eine
23:24
Art und Weise die auch auf Scrum aufsetzt oder so ähnlich ist.
23:29
Habe ich lange danach gearbeitet und als ich angefangen habe
23:33
damit zu arbeiten, ist mir das relativ schwer gefallen, diese
23:36
diese. Ausgabenschätzungen zu machen
23:37
beziehungsweise am Anfang ist mir super easy gefallen, weil da
23:41
hieß es nur so, wir schätzen 01230 heißt, die Aufgabe ist
23:46
sozusagen in n Schnipsen, dann ist die fertig, da ist quasi
23:50
nicht großartig was zu machen, nur ein bisschen 1 heißt das,
23:54
dauert so ungefähr einen Tag, 2 heißt das dauert quasi
23:58
vielleicht ein bisschen mehr als einen Tag schaffst du nicht den
24:00
ganzen Tag abzuschließen, kann auch vielleicht mal 2 oder 3
24:04
Tage im Worst case dauern, aber wenn du jetzt ne 3 schätzt, dann
24:08
muss die Aufgabe. Splittet werden also dann ist so
24:11
groß, dass man sagt, OK, da eigentlich sind da 2 Tasks in
24:14
dieser in diesem einen Task verbaut und da dachte ich mir
24:18
OK, total easy, gar keinen Stress, so können wir arbeiten
24:22
und irgendwann wenn man dann mal so das eine oder andere Team
24:24
durch hat und mit verschiedenen Menschen, Entwickler,
24:27
Entwicklerin zusammengearbeitet hat.
24:30
Hat sich das so n bisschen herauskristallisiert, dass halt
24:32
eben nicht so ist, weil oftmals wird gesagt, weil du ja auch
24:35
gerade meintest, wie schnell man ne Aufgabe schafft.
24:38
Aber eigentlich ist ja laut Lehrbuch heißt Ja glaube ich
24:42
immer Komplexität oder man schätzt die Komplexität eines
24:45
Tasks. Also wenn du jetzt mit mir
24:48
redest, dann also dann halt ist halt auslegungs Sache, ne also.
24:53
Das ist bei uns auch immer so die Frage gewesen, so wonach
24:55
schätzen wir jetzt, also schätzen wir nach Aufwand,
24:59
schätzen wir nach Komplexität, schätzen wir nach Zeit.
25:02
Ja, und das spielt ja auch alles so ein Stück weit zusammen, also
25:05
du kannst ja auch sagen, ich hab eine eine Aufgabe, die wenig
25:10
komplex ist, aber einen sehr großen Umfang hat, genau dann
25:13
geb ich, dann gebe ich den einen Story Point, oder?
25:17
Gib mir ein 5. Also das ist dann halt die
25:19
Frage, da muss man halt irgendwann einheitliches
25:22
Verständnis schaffen. Ja, ich finde es auch schwierig.
25:24
Also nur also nur Komplexität zu schätzen und die Zeit dabei
25:29
nicht zu berücksichtigen. Ich finde, das ist nahezu
25:31
unmöglich, also das ist ja nun mal der der Punkt, den man noch
25:35
halbwegs greifen kann, sag ich mal ne, also wenn ich jetzt
25:39
sage, ja, die Aufgabe hat eine Komplexität von 2 und dann
25:42
gucken die anderen an sich so alles klar was 2 genau.
25:48
Also ich finde das halt auch immer geil zu sagen, nach
25:50
Komplexität zu schätzen ist das A und o.
25:52
So nach dem Motto sehe ich auch so, dass die Komplexität sehr
25:56
entscheidend ist. Aber am Ende ist es immer Zeit,
25:59
die man dann irgendwie angibt, oder?
26:01
Oder sehe ich das verkehrt? Ja, also Personen Tagen wird das
26:04
bei uns auch so geschätzt, dass man halt sagt, OK, Aufgabe XY ja
26:10
ein Story Point meinetwegen keine Ahnung.
26:13
Oder Stunden, dass man sagt, 19 Stunden oder also wenn man immer
26:18
wieder bei der. Zeit also.
26:19
Das war auf jeden Fall mein Struggle, weil im Endeffekt
26:21
hatte ich dann ganz am Anfang ganz gutes Verständnis, aber
26:24
wenn du dann auf einmal mit wem anders arbeitest und die Person,
26:28
die dann sagt, Ja, warte mal oder eine neue Person im Team
26:31
ist und sagt, Moment, warte mal jetzt hier so nach Tagen, das
26:35
ist ja eigentlich vielleicht gar nicht sinnvoll, lass uns lieber
26:39
nach Komplexität schätzen, so weil zum Beispiel, ich versteh,
26:42
also ich bin ja total bei euch. Und sage, es macht schon Sinn,
26:46
man hat irgendwie immer. Das ist eine sehr greifbare
26:48
Einheit, zu sagen, wie lange brauche ich für eine Aufgabe,
26:51
und das kann ich abschätzen, was aber auf definitiv auch auf der
26:57
Gegenseite steht für eine Zeit Schätzung, was ich auch
27:01
verstehen kann, wenn das jemand sagt ist, dass man ja zum
27:04
Beispiel sagt, OK, ich brauche da vielleicht.
27:07
Ich sag jetzt mal 5 Stunden für und dann kommt auf einmal
27:10
irgendwas rein. Es kommt irgendeinen issue rein,
27:13
also irgendwas was einen aufhält und auf einmal werden aus 5
27:16
Stunden 15, das heißt die dreifache Zeit so und das habe
27:19
ich zum Beispiel auch persönlich öfter mal erlebt und dann ist
27:22
natürlich die Frage, wenn du dich wirklich darauf committed
27:24
und sagst, OK, 5 Stunden, dann ist das Ding durch, so dann ist
27:29
halt zeitlich vielleicht. Problem, wenn man sich da
27:32
wirklich darauf einigt, so. Aber meinst du damit?
27:35
Störfeuer von außen im Sinne von nicht zu deiner Aufgabe gehörend
27:40
oder dass die Aufgabe sich als komplexer herausstellt als
27:43
gedacht. Beides, also es kann halt beides
27:45
sein, ne. Also ich hatte auch schon mal ne
27:47
Schätzung wo ich dachte, ja gut, das ist eigentlich gar nicht so
27:49
viel und dann guckst du den Code an und dachte und hast
27:52
vielleicht dann eben nicht gedacht und dachte es dir, o
27:55
Gott, das bläht die ganze Nummer n bisschen auf so also das ist
27:59
auf jeden Fall schon mal was. Mir häufiger passiert ist und
28:03
deswegen. Ich denke immer an Zeit, wenn
28:06
ich schätze, aber gleichzeitig verstehe ich, dass es halt
28:09
eigentlich nicht das optimale Kriterium ist.
28:11
So also ich finde das macht halt nicht so n Unterschied ob ich
28:15
jetzt Komplexität, also in dem Fall ob ich Komplexität oder
28:18
Zeit schätze, weil am Ende ist es irgend ne wie du sagst issue
28:23
was ich nicht berücksichtige ich jetzt in der Zeit schätze oder
28:26
Komplexität, ich irre mich einfach und deswegen nennen wir
28:29
es ja auch Schätzungen oder also ich finde zum Beispiel es ist
28:32
auch unfassbar schwer halbwegs nah an die Realität.
28:35
Anzukommen mit dem Schätzen, und das ist halt auch ein ganz, ganz
28:39
gutes Stichwort. Wie gut schafft ihr es, die Task
28:44
zu schätzen bei euch? Bei uns ist eigentlich immer so,
28:48
dass wir häufig Tasks oder User Stories unterschätzen.
28:56
Also wir haben die Erfahrung gemacht, dass dass die der
29:01
genaue Schätzwert gar nicht so wichtig ist, sondern dass man
29:04
dieses viel wichtiger ist zu sagen, OK, ich hab irgendwie ein
29:07
Referenzwert, also eine andere User Story und im Vergleich zu
29:13
dieser User Story hat meine User Story, die ich jetzt gerade
29:16
bearbeiten will. Die Story Point Anzahl und dass
29:21
man dann sagt, im Vergleich zum Backlog oder im Vergleich zum
29:25
Sprint Backlog haben wir User Stories die.
29:30
Verschiedene Story Points haben. Und das da dann das Verhältnis
29:35
irgendwie stimmt. Also dann ist es ja egal, ob man
29:38
sagt, OK, wir haben User Story a die sehr groß ist und die hat 8
29:42
Story Points und ich habe diese Story b, die ist kleiner und hat
29:47
nur 3 Story points. Ist ja vielleicht.
29:52
Egal oder oder zweitrangig, ob ich sage, das sind 8 und 3 Story
29:57
points oder ob ich sage die erste User Story ist sehr groß
30:00
und die zweite User Story ist im Vergleich dazu relativ klein.
30:05
Ja, also noch mal um ganz kurz. Also wir hatten zum Beispiel,
30:10
damals hatte ich die Erfahrung gemacht, dass wir dann
30:12
irgendwann gesagt haben, OK, wir versuchen nicht mehr nach Zeit
30:15
zu schätzen, sondern diese Komplexität mit rein zu nehmen,
30:19
weil wir gesagt haben, beispielsweise, wenn du eine
30:23
Aufgabe hast, einen Task hast, der sich zum Beispiel, wir haben
30:26
ja entwickelt, auch durch Frontend, Backend und zum
30:29
Beispiel Datenbank Migration, also hat das erfordert, dann war
30:34
das auf jeden Fall schon mal mehr als ne 1, ne, also
30:36
sozusagen, das war dann schon ne 2, war n bisschen komplexer, da
30:39
wo muss n bisschen mehr. Werden.
30:41
Und wenn es jetzt aber zum Beispiel was war, was vielleicht
30:44
keine Datenbank Migration beinhaltet hat, sondern wirklich
30:47
ein Verhalten, was durch sich durch Frontend und Backend
30:49
zieht, aber man sozusagen die Datenbasis nicht anfassen muss,
30:53
dann mach s halt eben ne 1. Aber wir haben dann irgendwann
30:56
nicht mehr nach Zeit geschätzt. So, das war auf jeden Fall ne
31:00
ganz gute Einigung, aber. Ist mir gerade noch mal so in
31:04
den Sinn gekommen, weil wir da gerade so drüber gesprochen
31:07
hatten. Aber Apropos Einigung, Wie ist
31:09
es denn bei euch als Entwickler sozusagen ihr die Entwickler
31:13
sich die hab ich jetzt nicht. Also wie schnell einigt ihr euch
31:19
denn oder einigt ihr euch überhaupt auf auf ihr müsst euch
31:23
am Ende einer eines Planungs auch auf die ja bei den
31:27
Schätzungen einigen irgendwie. Na ja, also auf Gegenfragen,
31:30
weil ich jetzt nicht eingestellt also.
31:35
Trage bitte eine Frage, frage bitte, wenn der Nein gute Frage,
31:39
ich finde, das ist nämlich genau das Problem und deswegen fand
31:42
ich das vorhin spannend, dass du gesagt hast, es spielt erstmal
31:46
gar keine Rolle, was für Zahlen da am Anfang rauskommen, sondern
31:48
es geht darum in den Austausch zu gehen.
31:50
Ich hab da halt verschiedene Erfahrungen gemacht um ein sehr
31:54
negatives Beispiel zu bringen, war es in meinem Po ja keine
32:00
Ahnung. Vor ein paar Jahren in einem
32:01
Projekt. So dass auch mehrere Entwickler
32:05
geschätzt haben, plus der PO und der ja eigentlich gar nicht die
32:12
Task am Ende quasi entwickelt, aber mit schätzen wollte, um
32:16
einfach so quasi sein Know How mit einzubringen.
32:19
Aber das in einem Jahr doch sehr negativen Sinne, weil er einfach
32:23
quasi alles super niedrig geschätzt hat, so nach dem
32:26
Motto, dass ich schaff das in einem Tag ja schön, wenn du das
32:28
in einem Tag schaffen würdest, aber die restlichen Entwickler
32:31
sagen 3 Tage oder 4 Tage. Und dann war das irgendwie so,
32:36
nachher OK, dann treffen wir uns in der Mitte und alle so, nee,
32:41
ja doch, wird jetzt eingetragen, so gut, dann hattest du quasi
32:44
geschätzt anderthalb Tage. Was ist die Konsequenz daraus
32:48
bei der nächsten, beim nächsten Planing hat man einfach schon so
32:50
plus 50% draufgepackt, weil du wusstest, er zieht 50% ab, um
32:55
wieder halbwegs realistisch zu werden.
32:58
Ja sorry, das macht halt gar keinen Sinn, ne und deswegen das
33:02
ist so ein extrem negatives Beispiel.
33:04
Was ist, wenn jemand sagt, nee das du?
33:08
Dass das passende finde ich nicht, also ich, das dauert
33:10
einen Tag nur, also wie geht man damit um, da ne und aktuell ist
33:15
es halt so, dass es halt im kleineren Kreis geschätzt wird,
33:18
auch wirklich nur von Leuten, die daran arbeiten, obwohl es ja
33:22
wie eigentlich grundsätzlich nicht verkehrt ist, noch von
33:25
anderen Entwicklern Input zu kriegen, die ja vielleicht zum
33:28
Beispiel so ne Issues aufdecken können, die man gerade selbst
33:30
nicht im Kopf hat, aber aktuell ist es so, dass es ein kleiner
33:33
Kreis schätzt und dann meistens unterschätzt man es auch, dass
33:37
man sagt, Herr hat doch länger gedauert.
33:39
Aber das hat funktioniert, auf jeden Fall wesentlich besser,
33:42
als alle mit einzubeziehen wie damals, aber das ist halt jetzt
33:45
auch nur so meine Erfahrung dabei, ne, also ich habe zum
33:48
Beispiel die Erfahrung gemacht, dass tatsächlich das
33:52
Entwicklerteam plus zum Beispiel Designer beziehungsweise
33:56
Designerin mit dabei war, ob man jetzt quasi Designer, Designerin
34:01
mit einbezieht, sei mal dahingestellt, hat bei uns
34:03
eigentlich immer ganz gut funktioniert, aber wir hatten
34:07
keinen PO, aber wir hatten PM, aber der PM hat sich sozusagen
34:10
um die User. Gekümmert, die wir dann
34:13
geschätzt haben. Deswegen hat er halt nicht mit
34:14
geschätzt und dann war es so, dass wir zum Beispiel, wenn wir
34:19
uns einig waren, alle hatten das gleiche geschätzt, dann haben
34:22
wir eigentlich gar nicht großartig darüber diskutiert,
34:24
sondern es war so, alle haben 1 gesagt, OK passt.
34:27
Interessant wurde es dann, wenn zum Beispiel so einer oder
34:30
Hälfte Hälfte. Quasi unterschiedliche Sachen
34:35
geschätzt haben. Ne, also zum Beispiel die Hälfte
34:37
der Entwickler Entwicklerin sag ich jetzt mal ne 2 geschätzt
34:41
haben und die andere Hälfte hat ne 1 geschätzt und da wurde dann
34:46
halt einfach hat jeder mal so ein bisschen so sein Statement
34:48
dazu gegeben und gesagt wieso schätze ich ein, dass das jetzt
34:52
ne 2 ist oder eine 1 beispielsweise und dann wurde
34:56
das halt einfach von jedem mal diskutiert, manchmal haben die
34:59
Diskussionen auch relativ lange gedauert muss ich sagen, also es
35:01
kam schon mal vor, dass wir dann so IPM hieß es immer so.
35:05
Planning meeting haben wir dann sag ich mal, vor einer halben
35:08
Stunde, manchmal auch auf eineinhalb Stunden ausgedehnt.
35:11
Das war dann worst Case, aber das interessante an der ganzen
35:16
Geschichte war dadurch, dass wir halt sehr intensiv darüber
35:19
gesprochen haben und teilweise auch in eine hitzige Debatte
35:22
geführt haben darüber, ob es jetzt ne 2 ist oder eine 1, hat
35:27
sich das Verständnis darüber, diese Aufgabe, was in dieser
35:30
Aufgabe zu tun ist, unglaublich verschärft und jeder wusste
35:34
eigentlich, was zu tun ist. Und das hat da am Ende
35:38
zugeführt, dass egal wer sich dann diese user Story gegriffen
35:42
hat, jeder konnte sich eigentlich im großen Abarbeiten
35:45
und das war halt das Gute. Deswegen hab ich zum Beispiel
35:47
irgendwie auch so ein bisschen wie ihr bei dir auch schon mal
35:51
jetzt eben gerade gesagt, für mich ist auch das Wichtigste
35:54
beim Schätzen, dass man Verständnis darüber schafft, was
35:57
zu tun ist, damit das ganze Team weiß was abgeht, so und aber um
36:02
deine Frage kurz und knapp zu beantworten, Felix, es geht
36:06
manchmal schnell. Manchmal dauert das richtig
36:08
lange. Jedenfalls habe ich die
36:09
Erfahrung gemacht. Sieht bei uns ähnlich aus, also
36:12
bei uns geht es manchmal schnell, manchmal dauert es
36:15
lange und wie ich anfangs schon mal gesagt habe, also es ist
36:19
einfach wichtig in den Austausch zu gehen und vielleicht auch ja
36:24
plausible Argumente irgendwie zu diskutieren, warum jetzt eine
36:27
Story größer oder kleiner ist. Ja und dann kann man sich ja
36:31
auch irgendwie einigen, also im Team.
36:35
Ja, das kommt man im Endeffekt schon darauf auch aufeinander.
36:40
Aber du hattest im Vorfeld hattest du ja erzählt, dass du
36:43
auch, dass sich das auch manchmal so ein bisschen bewegt
36:47
hat. Diese ganze schätzt Thematik und
36:50
du da auch so n kleinen Workshop bei dir gepusht hast, im Team,
36:55
wo ihr auch relativ intensiv darüber diskutiert habt.
37:02
Wie das so also wie zum Beispiel man so schätzen, andere schätzen
37:06
rangehen kann. Und da hattest du irgendwie
37:08
coole ne, ich krieg nicht mehr ganz zusammen, aber irgendeinen
37:12
coolen Vergleich gebracht was also ich glaub ihr hattet
37:15
irgendeine Übung, wo habt ihr doch gemacht?
37:18
Genau. Falls du dich erinnerst, was ich
37:20
meine. Ja, ja, ich.
37:21
Kann ich nicht mehr ganz zusammen.
37:23
Genau. Also wir haben mal so ein
37:24
Workshop initialisiert beziehungsweise ich hab also ich
37:30
hab den nicht durchgeführt, aber ich hab das mal so ein bisschen
37:33
in die Richtung. Gepusht, weil ich irgendwie das
37:35
Gefühl hatte, bauen, es ist gar nicht so klar, was wir jetzt
37:38
eigentlich schätzen. Na dann haben wir ja einen
37:42
Workshop gemacht mit dem Team. Wo wir mit Alltags Beispielen
37:51
geschätzt haben. Also wir haben zum Beispiel
37:53
Hunderassen nach Gewicht geschätzt, also von deutsche
37:57
Dogge bis über Dackel bis Chihuahua und dazwischen Berner
38:01
Sennenhund und dann haben wir uns halt als Team
38:03
zusammengesetzt und haben uns überlegt, so OK, wir müssen
38:06
jetzt also, das ist jetzt ein absolutes Schätzen, wir schätzen
38:10
jetzt das Gewicht. Ja, und dann?
38:15
Es ist gar nicht mal so leicht, sich da zu einigen und zu sagen,
38:20
OK, die Deutsche Dogge ist auf jeden Fall in diesem Fall der
38:23
schwerste Hund und der Chihuahua ist der leichteste Hund.
38:27
Also die Reihenfolge hat schon da irgendwie so halbwegs
38:31
gepasst. Aber wenn man sich jetzt
38:32
vorstellt, dass man nicht mit so Alltags Beispielen schätzt,
38:38
sondern irgendwie komplexe. IT Aufgaben und Thematiken hat.
38:44
Ja. Das ist dann deutlich schwerer,
38:46
das zu schätzen. Oder ein anderes anderes
38:50
Beispiel war, dass wir Länder nach Flächen geschätzt haben.
38:55
Ja. Und also auch dann mit Story
38:58
Points. Und zum Beispiel China,
39:02
Südafrika und Dänemark im Vergleich oder so.
39:04
Und also wird halt relativ schnell klar, was das größte
39:08
Land ist und auch da ist wieder die Reihenfolge im, die relativ
39:12
klar, aber die die Abstufung dazwischen, also.
39:17
Wie wieviel größer ist denn Dänemark?
39:20
China als Dänemark, oder das kann man ohne das jetzt
39:23
Nachzugucken nicht mit Sicherheit sagen.
39:26
Na und? Im Endeffekt ist es ja, was
39:29
Tino, glaube ich auch jetzt schon gesagt hat, es ist ja eine
39:31
Schätzung, also es heißt ja nicht, man setzt sich zusammen
39:35
und sagt, wir machen jetzt eine präzise Bestimmung darüber,
39:38
welchen Story Point diese Aufgabe bekommt, sondern es ist
39:41
eine Schätzung, und ich finde diese diesen Vergleich finde ich
39:44
total geil zu sagen, schätz doch mal, wie schwer der Hund ist.
39:49
Oder schätz doch mal, wie hoch das Gebäude ist oder wie weit
39:52
jetzt, keine Ahnung, die nächste Ampel entfernt ist.
39:55
Da wird es dann schwierig. Es heißt sag doch mal, also man
39:59
schätzt ja ne, man sagt ja, OK, das ist ungefähr 60 Meter, keine
40:03
Ahnung 20 Kilo was auch immer, aber man sagt ja nicht, ja weiß
40:08
ich genau 20,3 Kilo und 75 Meter und 32 Zentimeter oder so ne.
40:16
Kann ich dir genau sagen, was ich an der Übung ganz cool
40:20
finde. Also ich hab das so auch noch
40:22
nicht gehört, ich ist ja einfach, dass du alle mit ins
40:26
Boot holen kannst, weil die Aufgabe klar ist.
40:29
Also was zu schätzen ist. Und da deswegen finde ich
40:32
gerade, ist das eigentlich wirklich ne sehr, sehr geile
40:34
Übungen, sogar weil du einfach dieses dieses Know How im
40:38
Vorfeld rausnimmst, dass du, dass quasi jeder weiß, worum es
40:41
geht und trotzdem versteht, wie schwer das ist jetzt zu lösen
40:45
ist diese Aufgabe, also dass man es wirklich nur schätzen kann
40:48
und das finde ich ziemlich und das müssen wir uns merken, das
40:52
will ich auch mal bei uns im Team machen, weil ich glaube,
40:54
dass das könnt ihr bei euch. Mal anbringen, weil das ich
40:57
glaube, dadurch wird einfach mal klarer, wie kompliziert so ein
41:00
Planning ist oder wie? Schwierig, das ist so
41:03
umzusetzen, ne. Aber da muss man vorher.
41:06
Im Vorfeld ist aber wichtig, dass man herausfindet, dass es
41:09
keinen Hunde Experten gibt. Ja, also ich werde sowieso alle
41:13
Rassen googeln und das Durchschnittsgewicht und dann
41:15
werde ich richtig glänzen. Bei dieser Übung.
41:18
Weil, darum geht es nämlich. Wir haben.
41:21
Auch zum Beispiel Regeln festgelegt, dass man jetzt halt
41:24
im Voraus nicht guckt, ja wie schwer es ne Dogge oder oder ein
41:29
Chihuahua und Tino gerade schon. Ich hab gesagt, hast, also das
41:33
ist halt bei diesen Aufgaben hast du ja extrem gutes Kontext,
41:39
wissen aus Alltag. Also jeder von uns kennt
41:41
irgendwie Hunde, ob man jetzt eine deutsche Dogge kennt weiß
41:45
ich nicht, aber das ist halt so, man kennt das irgendwie aus dem
41:48
Alltag und kann es irgendwie einschätzen.
41:50
Deutsche Dogge ist groß, oder? Sehr gut, ja.
41:54
Ich hab keinen Plan her. Ja, ich auch nicht.
41:58
Aber ich kann das eben, also kann man das auf jeden Fall
42:01
einschätzen, wenn man jetzt wie gesagt stattdessen Story User
42:05
Stories hat, die wo wir vielleicht nicht jeder alle
42:09
Hintergrundinformationen zu hat oder nicht so viele wie zu
42:12
Hunden, was man sich ja auch vielleicht bildlich viel besser
42:15
vorstellen kann, ne, dann dann wird da die Schatz Angelegenheit
42:21
nochmal deutlich schwieriger. Vor allem das witzige an dem
42:24
Beispiel von diesen realen Gegenständen, Tieren, was auch
42:29
immer ne, das ist ja eigentlich auch ganz geil, weil wenn du
42:32
sagst OK lass mal alle schätzen wie schwer ein Hund ist.
42:37
So und dann gibt es vielleicht wirklich den Hunde Experten, der
42:40
kann natürlich viel besser einschätzen wie schwer das ist.
42:44
Und wenn man jetzt aber sich überlegt nochmal wenn ich jetzt
42:46
nochmal ein Beispiel aufgreife Tino und du hast das
42:49
Entwicklerteam und du hast NP oder wer auch immer das jetzt.
42:54
Der oder die Person da vielleicht jetzt nicht so ne
42:57
Ahnung von hat, so wie gut ist denn das Ergebnis von der
43:00
Person, die vielleicht nicht der Experte oder Expertin ist im
43:05
Verhältnis zu zum Entwicklerteam, die vielleicht
43:08
im Normalfall sollte man ja davon ausgehen, eher die
43:11
Experten sind und dann zu sagen, wenn das Entwicklerteam sagt,
43:15
ja, das ist aber 3 Punkte und sozusagen ein außenstehender
43:20
Mensch sagt. Ne, ich sag das ist ein Punkt.
43:23
Treffen wir uns in der Mitte, dann wird es halt glaub ich
43:24
schwierig das ja, das ist ja im Prinzip die Erfahrungen die ich
43:28
am Ende gemacht hab ne ja also auf jeden Fall müssen das
43:32
natürlich Leute schätzen, die wissen also den Kontext kennen,
43:36
ich finde halt nur wenn zum Beispiel klar ist, dass das 2
43:39
Leute übernehmen, weil einfach irgendwie deren Thema ist.
43:42
Ne, ja, normalerweise sollte es ja auch AG sein und man zieht
43:45
sich dann seine Themen alles richtig, aber gehen wir mal
43:47
davon aus, dass eigentlich schon klar, dass 2 Leute das machen.
43:51
Dann können die beiden das schätzen.
43:53
Aber was ich damit meinte ist, wenn es jetzt Entwickler gibt,
43:56
die quasi auch wissen wie man das machen würde, dann ist es ja
44:00
nicht schlecht, da auch nochmal die Meinung abzuholen, ne, aber
44:03
natürlich muss der Kontext einfach gegeben sein.
44:06
Ja also, aber ich ja. Was ich halt also für mich, also
44:11
wie ich schon meinte, ist unglaublich wichtig, so dass
44:14
glaube ich und ich glaube das sollte das Hauptaugenmerk am
44:19
Ende sein oder der des der Haupt outcome.
44:22
Einer Schätzung sollte sein, dass alle, die an der Schätzung
44:25
beteiligt sind, in n am Ende groben Überblick also oder n
44:32
einen guten Überblick über das haben, was zu tun ist.
44:35
Und dann ist eigentlich, wie Felix ja auch schon meinte, ist
44:40
die Zahl an sich relativ egal, die dann wirklich am Ende
44:43
rauskommt. Nur das Problem finde ich ist ja
44:47
und also was ich mitgekriegt habe ist, dass zum Beispiel ja.
44:53
Also das Entwicklerteam oder das Produkt Team schätzt ne Aufgabe
44:56
und sagt OK wir haben jetzt das und das ist jetzt geschätzt und
45:01
man schätzt dann. Zumindest kenne ich das so, dass
45:04
man sagt, OK, ne Komplexität, Zeit, Aufwand.
45:08
Man versucht das irgendwie alles ein bisschen zusammen zu
45:10
behandeln, aber am Ende auf Projektmanagement Ebene kommt
45:14
dann halt eher sowas an wie ja, aber wie lange denn jetzt?
45:18
Ne. Und.
45:21
Das ist, finde ich immer, trifft dann wieder alte Welt auf neue
45:24
Welt. Das hatten wir ja schon genau,
45:26
aber das ist halt das schwierige an der Geschichte und wenn du
45:28
jetzt zum Beispiel so in der Rolle vom Projektmanager, sag
45:32
ich jetzt mal Felix, dich aufhältst wie, wie ist denn das
45:36
bei euch dann? Also ich meine bei euch
45:39
funktioniert das ja ganz gut, ihr seid ja ein sehr agiles
45:41
Unternehmen. Wie geht man damit um, wenn man
45:45
jetzt nicht sagt, sag ich jetzt mal, wenn jetzt nicht von oben
45:48
kommt, wie lange denn wann ist, ist die Deadline, können wir
45:50
halten, können wir nicht halten, wie läuft das dann?
45:55
Also bei uns läuft das so, dass wir sozusagen das Planning.
46:00
Als gesamtes Team machen. Also da sind auch Scrum Master
46:03
und Product dabei und. Ja, also der Sprint ist
46:09
sozusagen Entwickler Sache. Also das Entwicklerteam
46:12
entscheidet für sich. Wieviel Zeit benötigen wir dafür
46:16
und wieviel User Stories, welchen Umfang schaffen wir
46:20
dann, wenn das Entwicklerteam sagt, Wir schaffen diesen
46:24
Umfang, dann hat der ja der PO. Eigentlich.
46:30
Wenig Mitspracherecht. Ich sag jetzt bewusst wenig.
46:33
Natürlich kann man darüber diskutieren.
46:35
Aber eigentlich ist sozusagen ja der Sprint.
46:41
Entwickler Sache ausgerichtet an übergeordneten Unternehmens oder
46:48
Abteilungs ne zielen. Also da bin ich auch bei dir,
46:52
weil ich versuche, mich manchmal in die andere Seite
46:55
hineinzuversetzen. Und wenn jetzt zum Beispiel,
46:58
angenommen, ich bin jetzt irgendwie auf Management, Ebene
47:02
und Entwicklerteam, sagt das. Dauert so lange so und man sagt
47:09
dann ja, wieso schafft ihr es denn nicht schneller?
47:12
Manchmal habe ich das Gefühl, dass dann auf auf der anderen
47:15
oder auf bestimmten anderen Seiten vielleicht so die Meinung
47:18
herrscht, ja, die wollen ja jetzt zum Beispiel nur chillen,
47:22
die Entwickler, das Entwicklerteam, die wollen nur
47:24
chillen, wo ich mir denke, so na ja, aber du nimmst dir doch
47:27
Aufgaben vor und sagst natürlich, also so geht es mir,
47:29
ich kann jetzt auch nur für mich reden und ich weiß jetzt wo ich
47:32
arbeite sehr eng zusammen bei ihm weiß ich ja auch, aber dass
47:35
man sich ja nicht sagt, ja komm auch, weißt du heute.
47:38
Guck mal, wenn wir jetzt die Aufgabe große Geschäft keine
47:40
Ahnung haben, ewig Zeit. Im Endeffekt nimmt man sich ne
47:42
Aufgabe arbeitet die nächste arbeitet die nächste versucht
47:46
Probleme zu lösen die vielleicht auftreten und es ist ja nicht
47:49
so, dass man sagt, so dass man irgendwie, man arbeitet ja nach
47:53
besten und schnellsten gewissen und dann frage ich mich
47:55
manchmal, wenn man jetzt sagt, ja, aber mach doch noch
47:58
schneller, also wenn ich jetzt 100 Meter Läufer hab und der
48:00
läuft, keine Ahnung Weltrekord, ich weiß nicht wie lange läuft
48:03
man 7 Sekunden keine Ahnung ich ich schaffe es auf jeden Fall in
48:06
7, keine Ahnung. Aber du bist noch nicht
48:09
angetreten, aber. Aber, und dann heißt es aber ja,
48:14
mach doch mal schneller so. Also.
48:16
Ja, der denkt sich auch nicht. Na ja, ich mach jetzt ein
48:19
bisschen langsamer, falls wenn nämlich jemand sagt, mach mal
48:21
schneller, dann kann ich das ja so weißt du, und das
48:24
interessiert mich manchmal so oder da versuche ich mich
48:27
manchmal in die andere Seite hineinzuversetzen, also welche
48:31
Gedanken hat man, wenn man sagt, Mach mal schneller, so weißt du,
48:34
oder das macht mehr oder weiß ich nicht, also ich verstehen
48:38
könnte was ich meine. Ich weiß ganz genau, was du
48:40
meinst, aber man muss da ja so die Balance finden zwischen
48:45
Qualität und Quantität. Irgendwie also, dass man, wenn
48:48
das zu schnell arbeitest, so, dann ist dein Code oder deine
48:52
Arbeit, was auch immer irgendwie blöd.
48:56
Und wenn du s zu langsam machst, dann schaffst du es irgendwie
48:59
nicht im Sprint. Von daher basiert das ganze ja
49:01
auch irgendwie auf Erfahrungswerten, also das ja
49:04
irgendwie, du hast ja, also wir arbeiten nach 2 bis 3 Wochen
49:08
Sprints, also das sind unterschiedliche, haben einmal
49:13
einmal 2 Wochen Sprint und einmal 3 Wochen Sprint und dann
49:16
hast ja gewisse Erfahrungswerte wieviel schaffe ich?
49:19
In 2 Wochen und dann wird versucht im Sprint planning eben
49:23
so viel mit aufzunehmen, dass man diese 2 Wochen irgendwie
49:27
ausgelastet ist. Aber trotzdem die Qualität
49:30
hochhalten kann ja und falls einem langweilig wird, dann kann
49:37
man immer noch irgendwie aus dem Backlog priorisierte User
49:41
Stories nachziehen oder es tauchen immer wieder Bugs auf
49:45
oder so die du die du dann irgendwie nachziehen kannst.
49:49
Falls dir langweilig wird. Ja.
49:52
Da hätte ich noch eine Frage. Das passt gerade ganz gut,
49:56
vielleicht auch abschließend, weil mich das wirklich noch sehr
49:59
interessiert. Ich finde, das ist ein wichtiger
50:01
Punkt, weil du sagst, ihr arbeitet den Sprints und man
50:03
muss quasi erkennen, wieviel schafft man denn in einem
50:07
Sprint, wie wird denn bei euch die die Feedback Kultur gelebt,
50:12
also quasi sich hinzusetzen danach und zu sagen, OK, das
50:17
lief jetzt gut oder das lief jetzt nicht so gut und wie
50:19
können wir es besser machen, weil ich finde, das ist ein
50:21
extrem wichtiger Punkt, gerade um zu, also um es irgendwann
50:27
überhaupt mal zu schaffen, zu sagen, das und das ist
50:30
realistisch in 2 Wochen. Also wir haben eigentlich eine
50:34
sehr offene Feedback Kultur, würde ich sagen, und das
50:37
Feedback zu den Sprints erfolgt ja meistens in den
50:40
Retrospektiven, also immer am Ende eines Sprints plus und da
50:45
kommen dann halt regelmäßig Sachen auf den Tisch, am Sprint
50:50
gut gelaufen ist, was nicht so gut gelaufen ist, was man, was
50:55
man besser machen kann. Und dieser Retro sind dann immer
50:58
von den Scrum Mastern moderiert oder werden von den moderiert
51:03
und da wird dann offen über diese Sachen gesprochen und da
51:06
kommt dann auch ehrlich und konstruktiv auf den Tisch, was
51:11
ist doof. Und das funktioniert auch ganz
51:12
gut bei euch. Ja, ich würde sagen, das
51:15
funktioniert sehr gut, also da, also da ist auch.
51:19
Also es herrscht ne kollektive Verantwortung, also es wird
51:23
jetzt ne auf niemanden mit dem Finger gezeigt und gesagt, du
51:27
bist schuld, dass wir unser Ziel nicht geschafft haben.
51:30
Sondern irgendwie ist man als gesamtes Team dafür
51:33
verantwortlich, indem man sich irgendwie gegenseitig
51:37
unterstützt und zusammen am Sprint arbeitet und sich auch.
51:45
Hinblick lich oder bezüglich des Sprints irgendwie.
51:49
Ja, aber ist das wie ist denn das bei euch?
51:52
Weil ich hab zum Beispiel die Erfahrungen auch gemacht in der
51:54
Vergangenheit, dass wenn es so zu einer Retro kommt, dann kenne
51:58
ich, dass das so durchs Team raunt.
52:01
Oh, schon wieder eine Retro A müssen wieder retro machen.
52:05
Wie ist das bei euch? Also würde mich mal
52:06
interessieren was du da für Erfahrungen gemacht hast, Felix.
52:10
Ja, kenne ich, kenne ich nur zu gut.
52:16
Also die Entwickler haben eigentlich eher Bock auf diesen
52:21
Kram. Also hier entwickeln eigentlich
52:23
lieber, also die entwickeln halt lieber so und wollen in Ruhe
52:28
gelassen werden so und ist auch in Ordnung, aber trotzdem
52:32
versucht man dann in der Retro ja konstruktiv zu sein, ja.
52:37
Es witzig, dass du sagst, weil Fabio nicht leider auch öfter
52:40
mal die sind, die den Kram machen, wo ich keine Lust auf
52:44
diese Termine haben, obwohl wir eigentlich.
52:46
Wissen, wie es richtig. Sind.
52:47
Aber manchmal hat man ja doch so eine Problematik auf dem Tisch.
52:51
Und ich bitte lass mich weiterentwickeln.
52:53
Ich will jetzt. Keine.
52:54
Retro machen, das ist aber ganz oft so und nicht nur nicht nur
52:58
bei der Retro, sondern auch bei vielleicht bei Aufgaben, die
53:03
weniger technisch sind und zum Beispiel irgendwas Marketing,
53:07
mäßiges oder so oder auch irgendwas Design, technisches,
53:11
Wo irgendwie Entwickler Expertise gefragt ist und die
53:15
Entwickler. Du merkst dann so ja OK, die
53:18
machen das. Und die machen das auch gerne.
53:20
Aber noch lieber würden Sie eigentlich entwickeln das, das
53:25
spürst du halt so ein bisschen und ja.
53:29
Also das kann ich total nachvollziehen so.
53:31
Ich liebe es auch zu entwickeln und es macht Spaß und ich mache
53:34
es auch am liebsten gerne. Was mir aber auf jeden Fall auch
53:38
aufgefallen ist, ist, dass es durchaus retros gibt, die
53:41
qualitativ sehr hoch sein können und retros, die halt eigentlich
53:46
keinen großartigen Mehrwert bringen und ich finde da ist es
53:49
durchaus sehr sehr abhängig davon.
53:52
Wie gut die Person ist, die in der Rolle des Scrum Masters
53:56
agiert, das ist meine Erfahrung dabei und.
54:01
Ich hatte zum Beispiel auch Zeiten haben wir jede Woche
54:03
retro gemacht und dadurch, dass es halt so ne Regelmäßigkeit war
54:07
und das ging dann maximal eine Stunde, war das irgendwie wieder
54:11
OK. Aber wie Timo schon meinte, so,
54:13
es gibt Momente wo du gerade an dem Problem bist und denkst, oh
54:16
scheiße jetzt retro i ich bin doch Grad voll mittendrin, weil
54:19
ich hatte zum Beispiel auch mal Momente wo ich dachte, das kommt
54:21
mir gerade ganz gut gelegen, man kann den Kopf mal, ich würde
54:25
jetzt nicht sagen ausschalten, sondern umschalten, also man ist
54:29
auf einer ganz anderen Welt. Und deswegen ist für mich hat
54:34
das für und wieder aber das Wichtigste der ganzen Geschichte
54:38
meiner Meinung nach ist, ist, wie ist die Retro moderiert und
54:42
wieviel Gedanken macht sich die Person, die den Scrum Master.
54:47
Sag ich jetzt mal. Wieviel Gedanken macht die
54:51
Person sich über das Team und was da gerade so passiert?
54:54
Das ist halt ein wichtiger Punkt, so ja, aber interessant.
54:59
Aber also ich frag mich gerade bei dir was du gesagt hattest.
55:02
Jede Woche eine Retro. Also ich kenne das so, dass ein
55:07
Sprint ein Retro umfasst. Ich weiß jetzt nicht, wie es zum
55:10
Beispiel im Extreme Programming oder so ist, aber jede Woche ne
55:14
Retro ist. Ziemlich, klingt ziemlich viel
55:17
für mich wir. Hatten also ne.
55:19
Inhalation gegen eine Woche von daher hatten wir ja OK in jeder
55:21
Iteration einen Retro genau, aber das Planning war n bisschen
55:26
anders an der Stelle, da war es zwar quasi Planning und demand,
55:29
das heißt wenn du innerhalb einer Woche alles geschafft hast
55:31
und sag ich mal nach keine Ahnung, nach einer halben Woche
55:34
neue Aufgaben braucht es, dann wurde halt das Planing
55:37
vorgezogen oder halt nach 2 Wochenplanung gemacht, das war
55:40
sehr sehr variabel, aber die Retro war eigentlich relativ
55:43
fix. Ja, OK.
55:45
Aber damit hast du halt auf jeden Fall auch manchmal
55:48
schnelle Retros, weil du sagst ja gut, so viel ist jetzt nicht
55:51
alles gut, aber. Hat was für und wieder sag ich
55:58
jetzt mal, wie es bei vielen Dingen so ist.
56:01
Aber ja würde ich sagen, dann haben wir auf jeden Fall n
56:04
coolen Einblick bekommen über die Thematik schätzen und ich
56:08
glaube wir sind uns alle einig. Eine User Story zu schätzen,
56:13
Aufgaben zu schätzen ist alles andere als trivial und trotzdem
56:17
aber sehr, sehr wichtig. Und ja, uns würde es auf jeden
56:21
Fall interessieren, wie es bei euch da draußen bei den
56:24
Zuhörerinnen und Zuhörern ist, ob ihr auch die ein oder andere
56:28
Schwierigkeit oder Problematik mit dem Schätzen habt oder ob es
56:31
bei euch alles super fluffig und easy funktioniert.
56:36
Würde uns sehr interessieren. Das heißt, ihr könnt uns auf
56:38
jeden Fall gerne mal kontaktieren, auch bei Instagram
56:41
beispielsweise. Wir sind auch noch auf anderen
56:44
Plattformen unterwegs, die Links dazu findet ihr alle in den Show
56:47
Notes und in diesem Sinne würde ich sagen, beenden wir die
56:51
Folge. Es war auf jeden Fall sehr schön
56:54
Felix, danke, dass du hier warst.
56:56
Ja, vielen. Dank vielen Dank.
56:57
Danke für die Einladung hat. Spaß gemacht.
57:00
Ja, mir hat es auch sehr viel Spaß gemacht mit euch und ja, in
57:04
diesem Sinne empfiehlt den Podcast gerne weiter.
57:08
An. Auszubildende, die bei euch in
57:11
der Ausbildung sind, an eure Kommilitonen oder
57:14
Arbeitskollegen. Sag doch einfach mal, wenn ihr
57:18
euch gefallen hat, dass ihr da n neuen Podcast habt und in diesem
57:21
Sinne würde ich sagen, hoffentlich hören wir uns beim
57:24
nächsten Mal wieder und ja diesem Sinne eure Coding
57:28
Buddies. Leute gemeinsam besser.