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.