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