Meine Sicht der Dinge ne ist ja jetzt auch nicht in Stein gemeißelt, doch ich höre. Gut zu. Jetzt kommt die Wahrheit. Prophet lino. Podcast rund um Softwareentwicklung und aktueller Tech News. Herzlich Willkommen. Ja, herzlich Willkommen zur neuen Folge des Cowboys Podcast. Sehr schön, dass du wieder eingeschaltet hast. Wir sind heute natürlich wieder zu dritt, denn ich bin aber bei Tino und auch der fantastische Fabi. Moin Fabi, grüß dich. Morgen.
So neues Thema, neues Glück oder irgendwie sowas sagt man ja und deswegen halt doch mal raus. Was ist denn heute das Thema? Heute das Thema. Ich glaube, das ist sogar die 20. Folge, Das kann man ja mal anmerken. So ein. Mini jubiläum geil 20 folgen. Ja, voll cool. Nee, was wollen wir heute besprechen?
Wir haben aus der Community so mal den Wunsch, der wurde geäußert, dass wir, weil wir irgendwie mal so n bisschen irgendwie scrum und so erwähnt hatten, ich glaube auch in einer alten Podcast Folge, und da kam dann aus der Community zu uns der Wunsch mal n bisschen näher zu beleuchten, ne, also dass man hier so ein bisschen sieht, OK, was was, was ist scrum? Was steckt dahinter? Da wurde halt glaub ich auch so ein bisschen unter. Dem Gesichtspunkt, dass.
Aus der Frage, die an uns ran kamen dort quasi Scrum.
Gar nicht so für cool gehalten wird oder n bisschen verteufelt wird oder so ne, also dass man ja ich kenne das heutzutage gefühlt gerade in der Softwareentwicklung hört man überall Scrum, Scrum, Scrum geführt wird, überall nach Scrum gearbeitet, genau und jetzt wollen wir ein bisschen warum eigentlich und was sind die Vorteile, Nachteile, wann macht es Sinn, wann macht es keinen Sinn irgendwie so in die Richtung. Ein paar Erfahrungen von uns
noch mit reinbringen. Ich würde sagen, das könnte so der Fahrplan für diese Folge. Fahrplan sein ja OK, klingt doch cool. Genau. Möchtest du da schon mal anfangen, einfach mal kurz erklären, was die Scrum. Also nochmal kurz vorweg, die Frage wird bestimmt gekommen sein, weil wir gesagt haben, also über unseren Alltag berichtet haben und wir arbeiten nach Scrum, daher wird das wahrscheinlich gekommen sein. Was ist Scrum eigentlich? Das ist eine sehr gute Frage.
Und ich finde, es ist auch immer schwierig zu definieren. Klar ist, kannst du jetzt halt irgendwie googlen und Christa 1000 Definitionen, aber Scrum wird ja auch unterschiedlich ausgelebt, sag ich mal. Also grundsätzlich kann man sagen, ist halt ein agiles Framework fürs Projektmanagement, gerade in Bezug auf Produktentwicklung und ich weiß nicht, wo das ursprünglich herkommt, sicherlich aus der Softwareentwicklung selbst, aber
noch nicht fest. Aber grundsätzlich, wie gesagt, ist es für Projektmanagement, das heißt es hat. Nicht unbedingt was fest mit Softwareentwicklung zu tun, sondern halt in allen Bereichen eingesetzt werden. Ja, ich hab auch ja Beispiel jetzt. Eine Person, die ich kenne, arbeitet zum Beispiel im Marketing Bereich und die arbeiten ach. Ja, wirklich. So dachte OK.
Das ist ja krass. Also. Wie gesagt, weil ich selbst ja auch sehr oft mit Softwareentwicklung verknüpfe, aber es hat damit ja eigentlich grundsätzlich erstmal nichts zu tun.
Ja, was zeichnet Scrum aus? Also das ist ein agiles Framework, es gibt halt verschiedene Rollen, die eine Person, die nach Scrum arbeitet, einnehmen kann, dann hast du verschiedene Events, da können wir ja gleich nochmal alles n bisschen drauf eingehen, was es da so gibt oder auch Rituale genannt, also im Endeffekt Termine sozusagen auf Arbeit ne und genau das sind so die Punkte, die wir jetzt mal durchsprechen sollten, damit sich ein klares Bild ergibt und
da würde ich. Sagen, lasst uns doch mal mit den Rollen anfangen, damit man erstmal weiß, wer kann alles Teil in diesem Scrum Kontext sein. Also in einem Scrum Team. Man bildet ja Sogesagt sogenannte Scrum Teams. Ja, also. Erstmal steht da ganz oben. Also erstmal sind Scrum Teams an sich würde ich sagen, sind meistens relativ kleine Teams. Also es ist jetzt nicht so, dass du irgendwie ein Team aus 30
Leuten im Team hast. Also das sind du hast halt quasi du hast zum Beispiel den den oder die Scrum, also den Scrum Master, Scrum, Masterin, Product Owner oder die Product Ownerin und Entwicklungs Team und das Entwicklungs Team. Ne ist, jetzt kommt natürlich jetzt ein bisschen auf die, ich sag mal den Bereich an, weil du ja meintest, dass es nicht unbedingt ausschließlich in der Softwareentwicklung verortet ist. Aber bleiben wir natürlich jetzt mal hier in unserem Software Podcast.
Auch bei Softwareentwicklung und das heißt du hast sozusagen das Entwicklungs Team und meiner Erfahrung nach sind das sag ich jetzt mal, das Entwicklungs Team ist roundabout 6 Personen groß, also es kann natürlich mehr oder weniger sein, aber. Auch schon ein Größeres. Team dann ja. Also wie gesagt, das kann auf jeden Fall auch kleiner sein, kann auch ein bisschen größer sein, aber es ist jetzt nicht so, dass du auf einmal irgendwie 30, Leute.
Ne ne, das wäre genau der Gegensatz vom agilen Arbeiten, da können wir auch mal später darauf eingehen. Genau jetzt hast du ja gesagt, es gibt zum Beispiel in Product Owner und Scrum Master. Wir rollen, die einmal besetzt sind. Also du hast jetzt innerhalb eines Teams ja nicht mehrere Scrum Master und Product owner. Genau magst du mal kurz erklären, was zum Beispiel der Product Owner macht und wofür er steht?
Ja, also. Ich will jetzt nicht darauf festgenagelt werden und ich glaube, wir sollten jetzt nicht, wir wollen ja keine Definitionen runterballern nein. Aber sonst kann man sich schwer vorstellen, wenn jetzt noch gar keinen Bezug zu. Genau weiß ich nur den Zuhörerinnen und Zuhörern nochmal ans Herz legen möchte, lest euch auf jeden Fall, wenn euch das wirklich sehr interessiert, auch nochmal die Definition durch recherchiert.
Noch ein bisschen nach, aber im Großen und Ganzen im Product Owner oder Produktionen, die ist dafür zuständig sozusagen wirklich den Wert des Produktes zu maximieren. Das heißt genau darauf zu achten, OK, was ist jetzt wichtig, welche Schritte müssen als nächstes eingeleitet werden, damit das Produkt so wie es eben auch entstehen soll auch wirklich quasi zum Ziel kommt, das heißt es wird immer.
Auch darauf geachtet. Dass zum Beispiel eine gewisse Priorisierung für die entsprechenden Punkte, die gerade anstehen. Arbeitstechnisch auch eingehalten werden und der Product Owner die Product ohnehin, weiß halt einfach genau sag ich jetzt mal. Wie soll das Produkt aussehen, was steht dahinter?
Also die kennt sozusagen diese Person, kennt den Spirit von diesem Produkt in und auswendig und weiß ganz genau, welchen Value dieses Produkt bringt und treibt halt eben mit der Rolle dann eben entsprechend genau das voran, ne? Also hat quasi so den gesamten Fahrplan so im Kopf. Genau. Zeit weitergeht. Genau so würde ich das definieren. Kann durch das Priorisieren dann quasi agil reagieren. Genau, genau. Und dann sind wir beim Scrum
Master oder Scrum Master drin. Also diese Rolle ist im Endeffekt dafür zuständig, um diese ganzen Prozesse von von von Scrum, von diesem Framework, von diesem agilen Framework einzuhalten. Ne, also wir hatten, du hattest ja schon gesagt, es gibt bestimmte Rituale, die eingehalten werden, oder die sag ich mal, immer regelmäßig stattfinden und da dient die Rolle des Scrum Masters oder Scrum Master. Und eben dafür, diese Termine
einzuhalten. Dass auch innerhalb dieser Termine sozusagen die entsprechenden Sachen wirklich besprochen werden, dass man Fokus hält, dass man im Zeitrahmen bleibt und aber auch so ein bisschen nebenbei, also dass man auch also eine Scrum Master oder Scrum Master ist, halt eben auch zumindest, so kenne ich das, dafür zuständig, dass es, dass die Person eben auch guckt. OK, was ist, was spielt sich gerade im Team ab zwischen menschlich? Welche?
Barrieren gibt es vielleicht und da auch so ein bisschen zu intervenieren und. Ja, genau, ja, das ist halt ein guter Punkt, was wirklich wichtig an dieser Rolle ist, ist halt auf den Spirit innerhalb des Teams zu.
Achten Ja. Und dass man zum Beispiel, wenn man jetzt Teil des Entwicklungs Teams ist, also quasi der Entwickler oder Entwicklerin, dass man, wenn man Blogger hat, zum Beispiel, man hat wirklich irgendwelche Probleme und kann seine Arbeit nicht nachkommen, dann ist natürlich die Rolle des Grand Masters. Genau der richtige Ansprechpartner, um diese Probleme loszuwerden. Genau, genau magst du noch kurz sagen, dann was genau das Entwicklungs Team? Ja, das Entwicklungs Team sind
wir quasi. Also wir hatten ja davon berichtet, dass wir auch nach Scrum arbeiten und wir sind halt Teil eines Entwicklungs Teams und haben quasi auch ein Product Owner, der uns Aufgaben priorisiert und zuweist beziehungsweise nicht zuweist. Das ist ja die Besonderheit auch an Scrum, sondern Du hast ein Portfolio, ein sogenanntes Backlog, an Aufgaben und kannst dann selbstständig entscheiden, was du gerade wie abarbeiten möchtest.
Die sind natürlich priorisiert, das heißt, es gibt eine Rangordnung, was wichtiger ist und was nicht, genau durch genau, was durch den Product Owner passiert ist. Du kannst aber entscheiden, zum Beispiel welche Aufgabe du davon jetzt heute machst. Genau. Und im Endeffekt ist es ja so. Also wenn man das mal so zusammenfasst, so Entwicklungsteam ist das Team, was sozusagen die Aufgabe hat. Getting shit.
Wann genau aber aus, aber im Endeffekt kann man jetzt auch sagen, OK, wenn man jetzt n bisschen Ablauf von so einem von so einem Framework, von diesem, von diesem Scrum Framework anguckt, es ist ja nicht so, dass man irgendwie einfach so vor sich hin arbeitet und sagt, OK, wir haben jetzt irgendwie Aufgaben, die werden irgendwie priorisiert, einmal vom Product Owner von der Produktion drin und dann go for IT und dann läuft das so. Nein, genau, also da kommt ja
dieser agile Aspekt rein, ne und deswegen arbeitet man in Entwicklungszyklen, in sogenannten Sprints. Die haben halt eine definierte Länge. So gängige Werte sind beispielsweise 2 Wochen oder so 2 bis 4 Wochen. Auf jeden Fall ist das eine ein definierter Zyklus, das heißt, man entwickelt für diese gewisse Zeit, sagen wir jetzt mal beispielsweise 2 Wochen und. Dann geht es wieder von vorne los. So gesehen, und das hat diesen Zyklus, na ja, lass mich das
kurz erklären. Also du hast halt mehrere Zyklen nacheinander, aber innerhalb eines Zyklus passiert eigentlich in der Regel immer der gleiche Ablauf, das heißt du hast am Anfang einen Sprint Planning und das ist im Prinzip ja meistens ein Treffen des Teams, also wirklich vor Ort sag ich mal am besten, dass man sich in den Raum setzt und sich überlegt, was. Müssen wir denn gewährleisten, in den nächsten, im nächsten Sprint also wieder mal
beispielhaft 2 Wochen? Wir haben jetzt 2 Wochen Zeit, wir haben Anforderungen bekommen von sogenannten Stakeholdern, die einfach sagen, ja, pass auf, wäre cool wenn eure Software das und das könnte zeitnah und der Product Owner priorisiert das durch. Ja. Ne, und dann machst du einen Sprint planning und sagst OK das und das können wir schaffen in den nächsten 2 Wochen.
Und comites dich da drauf. Also kommen im Sinne von du sagst OK, nach 2 Wochen hat unser Team entschieden, sind wir in der Lage die und die Funktionalität umzusetzen oder haben sie umgesetzt? Ja, aber es kann ja durchaus trotzdem auch dazu kommen, dass man das nicht unbedingt alles schafft oder halt auch schneller ist. Ne, also das muss man halt auch sagen. Ja, genau deswegen hat das Spielräume.
Ist das Ereignis sowohl wichtig als auch ziemlich kompliziert, so nach meiner eigenen Erfahrung können wir später nochmal zu, es ist nicht trivial. Vernünftig, so n Sprint zu planen. Ja. Definitiv im Gegenteil. Das ist eine der größten und schwierigsten Aufgaben in der Scrum Welt.
Genau das persönlich. Das ist ja quasi diese Art, dass man sei diese Aufgaben, die priorisiert werden vom Product Owner, von der Produkt ordnerin, dass man quasi, dass man diese Aufgaben im Team schätzt und guckt. OK, ne, also dass man sagt, OK. Und schätzen.
In diesem Fall heißt ja nicht unbedingt, wie lange brauche ich dafür, hat was damit zu tun, zeitlichen Aspekt oder wie komplex ist diese Aufgabe und dann wird das halt eben eingeordnet, und das ist tatsächlich so ein ja wie du meintest nicht trivialer Fall oder ein nicht triviales Unterfangen, das wir da auf jeden Fall da wollen wir glaube
ich noch mal. Wenn euch interessiert, liebe Zuhörerinnen und Zuhörer, auch mal drüber quatschen, weil ich glaube, jeder hat, also ich kenne das, ich hab auch mit. Tino, Wir haben uns ja auch schon mal darüber unterhalten, über diese ganze Art von von Schätzen, von Estimation in diesem in diesem Sprint Planning, und da gibt es gefühlt bei 5 Personen 10 Meinungen für, und das ist ein sehr interessantes Thema, finde ich. Und war ganz kurz zur Erklärung,
falls das nicht ganz rüber kam. Bei Schätzen meinst du natürlich, dass schätzen wie lange so eine priorisierte Aufgabe braucht, damit sie komplett erledigt. Also dass man sie abgearbeitet hat.
Das ist die Zeit, der zeitliche Aspekt, und das ist genau der Knackpunkt, über den wir noch mal reden wollen, weil es natürlich zeitlich diesen zeitlichen Aspekt, wie lange brauchst du dafür, dass eine Sache, die wird nie also wird, kann man nie außer 8 lassen, da ist einfach das denken da, es geht aber auch nicht nur um den zeitlichen Aspekt beim. Aufbau also. Grundsätzlich geht es ja um Komplexitäten dahinter. Wie komplex ist diese Aufgabe, aber du brauchst natürlich irgendwie einen.
Etwas Messbares und deswegen fällt man immer wieder auf die Zeit zurück, weil das so gesehen messbar ist und gleichzeitig auch genau die Schwierigkeit ist, das richtig einzuschätzen. Aber das. Ist zum Beispiel ganz interessant, weil genau diese Art und Weise, wie gut man zum Beispiel denn an wirklich an die Realität schätzt, weil eine Schätzung ist ja nur eine Sache, die man natürlich nicht exakt
bestimmen kann. Deswegen heißt es schätzen und genau um zu gucken, dass man sich halt annähert, um zu sagen, EY, war das jetzt gut, war das schlecht. Dafür gibt es ja dann auch noch sogenannte Reviews über diesen Sprint, um zu sagen, OK, wie Guthaben wir es dann geschafft, unsere geschätzten Aufgaben abzuarbeiten, ne?
Genau, weil das ist nämlich ein großer Bestandteil auch von dem Scrum Framework ist, dass man am Ende eines Zyklus, also du hast den Sprint beendet, du hast quasi deine finalen Ergebnisse und dann Reviews du das im Team und sagst ja OK, haben wir erstmal alles geschafft, was wir uns vorgenommen haben. Wenn ja, Chapeau haben wir gut gemacht, weiter so.
Wenn nicht, woran lag es denn? Haben wir uns verschätzt, sind Leute ausgefallen, da gibts ja 1000 möglichkeiten was passieren kann und wir mal Real Talk, es wird passieren, dass man sich verschätzt, das ist ja wie gesagt die Schwierigkeit ne richtig und deswegen ist dieses Review auch ein sehr sehr wichtiger Termin dabei und der muss auch ernst genommen werden, auch wenn Unmut aufkommt, es war halt einfach mal auf gut Deutsch, der letzte Sprint war total Scheiße, das hat mich
alles total genervt, das lief nicht und so, dann ist das genau der Termin wo man das ansprechen kann auch ne. Obwohl. Das ja sogar noch in gewissen anderen Terminen sogar noch reinfällt. Und das ist diese. Retrospektive Etro genau, genau, ja richtig, so gesehen. Laut Framework ist das getrennt, ich habe aber auch die Erfahrung gemacht, dass das oft ein in sich überlaufender Termin ist. Halt ne das Review machst.
Du machst die Auswertung und gehst in die Retro über und sagst, OK, was lernen wir daraus, weil das ist genau das Agile dahinter. Du hast ja natürlich ein schnelles Feedback, wenn du jetzt einen Zyklus von 2 Wochen hast. Wirst du nach 2 Wochen lernen daraus was lief gut, was lief nicht gut? Genau das zeichnet ja auch agile Frameworks wie Scrum dann aus am Ende. Aber das ist ja auch wieder genau dieses Theorie und Praxis. Wir wollen ja auch nochmal
darauf eingehen. Wie sieht denn Scrum eigentlich in der Realität aus und wie was gibt es sozusagen für theoretische Termine, theoretische Rollen, diese ganze sag ich mal, das Konzept an sich und die Realität, ne, das unterscheidet sich ja, da können wir auch nochmal drauf eingehen. Aber uns noch die Termine vervollständigen. Den wollte ich, wollte wahrscheinlich auch darauf hinaus, nur noch ganz kurz. Einer fehlt natürlich noch und das wäre hau. Raus, das ist das Daily Scrum.
Genau das findet sozusagen jeden Tag immer statt, und das ist morgens. Meistens wird es morgens angesetzt, ich hab auch schon gehört, dass vielleicht auch mal am Nachmittag angesetzt wird, aber erfahrungsgemäß ist immer morgens und da wird einmal im Endeffekt kurzen Abriss gegeben, was hat man geschafft, wo hat man Schwierigkeiten gehabt und wenn man Schwierigkeiten gehabt hat, dass man dann sozusagen auch an diesem Termin sozusagen die Ansprechpartner.
Oder die Ansprechpartnerin finden kann. Wer einen denn helfen könnte? Also das sind so die groben Sachen, die da quasi geklärt werden und damit hast du im Endeffekt sozusagen den groben Rahmen, um das nochmal
zusammenzufassen. Man hat dieses diesen Sprint an sich am Anfang des Sprints sozusagen eine gewisse Art von Planung, die stattfindet, um diesen Sprint sozusagen auszuplanen am Ende des Sprints gibt es die Möglichkeit zu sagen, OK, man guckt was ist gut gelaufen, was schlecht gelaufen und halt durch diese Retrospektive kann man eben halt auch sagen, OK, wir reflektieren jetzt mal so ein bisschen und gucken, welche Verbesserungsmöglichkeiten denn
für bestimmte. Issues, die sozusagen aufgetreten sind, eben möglich sind. Ne, also dass man sich sozusagen iterativ über jeden Sprint eben sozusagen, dass man pain Points identifiziert und die dann in
Zukunft verbessern kann. Ne, also ich würde sozusagen immer weiter verbessern kann und innerhalb dieses dieses Zykluses findet halt regelmäßig jeden Tag einen Termin statt, wo man sich halt einmal sinkt, ne um das noch mal so ein bisschen grob zusammenzufassen, das ist so sag ich jetzt mal so würde ich das. Der hast du gut zusammengefasst. Auf jeden Fall.
Nochmal abbauen, genau, weil halt auch immer diese Feedback Kultur im Vordergrund steht und das finde ich halt auch für mich persönlich ein sehr wichtiger und cooler Punkt genau diesem Framework, weil schnelles Feedback ist einfach unfassbar wichtig, richtig so, aber jetzt hast du es ja zusammengefasst.
Ne so also wir haben jetzt ein Framework, du kannst super agil arbeiten, du hast jemanden der kümmert sich darum was erledigt werden muss, er priorisiert das super, du musst nur noch entwickeln als Entwicklungsteam, du kriegst deine Aufgaben, ziehst sogar noch das worauf du heute Bock hast, erledigst das nach dem Sprint erkennst du so wow.
Das lief geil. Die Software kommt voran, alles super, kannst super flexibel auf neue Anforderungen eingehen, das heißt, der Stakeholder hat ein Kunde am Ende sagt er hier Feature AB, hätte ich jetzt gerne zeitnah, das wäre echt cool und du sagst gar kein Problem in 2 Wochen haben wir nen Sprint, dann nochmal 2 Wochen spätestens Monat wirklich allerspätestens im Monat hast du es weiß keiner sein, dass du gerade den aktiven Sprint bist, der ist verplant, da ist nichts
zu machen, dann ne wie sieht die Realität aus weil? Kurz mal die Abkürzung, so läuft es in der Regel nicht. Nee, so läuft es halt meistens nicht.
Ne. Also es ist natürlich, also ich, ich kenne das meistens, wenn man jetzt zum Beispiel wirklich scrum spricht und ich muss auch ganz ehrlich sagen, ich hab noch nie richtig laut Lehrbuch nach Scrum gearbeitet, also es war meistens, es war meistens immer irgendwie eine Art von ja, wir arbeiten so nach Scrum, Scrum like so ne, also so vielleicht sowas wie ja, also es ist quasi scrum, aber n bisschen anders.
Ne und es gibt zusätzlich auch noch ein paar Abwandlungen, also zum Beispiel. Kann du hast doch ein bisschen Spielraum dazwischen, aber das ist dann immer alles irgendwie scrum like, also niemals so genau auf den Punkt hier, das ist der Plan und so wird es. Gemacht kannst du dir vorstellen, warum das so ist? Warum wird es nicht zu 100% umgesetzt? Was ist der Grund dahinter?
Weil ich hab die gleiche Erfahrung gemacht, also jetzt sowohl wir jetzt wieder zusammenarbeiten aber auch vorher, warum wird es nicht komplett umgesetzt? Also erstens hast du ja sowieso immer so eine gewisse Art von Realität. Die Praxis, die du meistens nie so richtig komplett umsetzen kannst. Das sind ja meistens immer Konzepte, die man sich überlegt und dann wirklich danach zu handeln ist teilweise auch echt
schwierig. Ne, also es muss ja, es muss ja jede Rolle genau das machen und jeder Termin muss genau so laufen, wie man sich das vorstellt und wenn du zum Beispiel einen Termin hast, wo keine Ahnung in dem Planing so viel diskutiert wird, dass du am Ende aber quasi über die doppelte Zeit diskutierst möglicherweise und dann aber am Ende sagst ja, OK, wir müssen das jetzt, wir können das jetzt gar nicht schätzen, weil das, weil die Informationen darüber vielleicht noch gar nicht da sind.
Ja was passiert dann? Ne? Also das sind halt immer Sachen da. Es können halt immer irgendwelche Impacts kommen, wo man vielleicht gar nicht so richtig weiß, OK was ist denn jetzt los, dann hast du noch. Die ja sag ich ja auch kurz reingrätschen, klar. Das Framework an sich sieht ja aber auch solche Fälle vor. Wenn ich ne wird etwas nicht schätzen kann, muss es ja refind werden, also. Ja. Ja, schon, aber also definitiv. Framework an sich hat ja Lösungen für solche Probleme.
Ja, und ich finde aber den einen Punkt, den du genannt hast. Es ist schwierig das komplett umzusetzen, das ist in meinen Augen auch wirklich das Kernproblem dahinter, weil das braucht eine gewisse Lernkurve, also es ist nicht einfach, es ist in meinen Augen ist es kein Framework was n also wie ein Prozess, sondern es ist eine Mindset frage dahinter, definitiv ja und mal böse gesagt, wenn.
Ein 2 Leute dabei sind, denen das Mindset nicht komplett vertreten, die sagen ja, nee, ich mach mit, aber eigentlich finde ich das nicht so geil. Ja dann wird es auch schon schwierig da 100% umzusetzen, weil die Rollen wie du meintest müssen genau machen was die Rolle vorsieht, ja. Aber das ist zum Beispiel auch so ein Punkt.
Manchmal wird halt in bestimmten Firmen oder Unternehmen halt eben auch gesagt, Wir arbeiten jetzt nach Scrum so und vielleicht wollen die Leute das gar nicht, vielleicht ist es irgendwie, also vielleicht gibt es da Reibereien und dann kannst du halt zum Beispiel auch dazu führen.
Dass angenommen Leute sagen, ich find das irgendwie blöd, weil neue Sachen sind ja für den Menschen normalerweise immer irgendwie etwas neues, Umstellung, er mag ich nicht, was der Bauer nicht kennt will ne und wenn du dann sowas hast, dann kommt es halt eben dazu, dass so eine Ablehnung stattfindet und selbst wenn aber am Ende nach einem Jahr oder so vielleicht doch die meisten vielleicht davon überzeugt sind, weil sie sich merken, weil sie merken, oh, das funktioniert ja
doch sehr gut so wie man danach arbeitet, hast du aber oftmals auch. In dieser Zeit die Chance, dass dadurch, dass halt so viel vielleicht auch dagegen gearbeitet wird und sich dagegen gesträubt wird, dass es dann halt eben ins Wasser fällt, dieses Konzept.
Und dann gibt es natürlich auch wieder die sagen h. Seht ihr, ich habs ja gesagt, das funktioniert nicht so und damit kann so ein Experiment natürlich auch irgendwie scheitern, wenn du halt sag ich mal Leute hast, die nicht offen dafür sind und sagen, OK, lass uns doch das mal ausprobieren, das ist immer so ein bisschen, es kann gut gehen, es kann doch nicht gut gehen, wenn man das halt so aufdrückt, das ist halt auch manchmal, da kann es halt auch scheitern.
Rein theoretisch ne. Ja das. Stimmt, und gerade dieses Rollen Thema, also meine eigene Erfahrung ist, ich habe jetzt in mehreren Scrum Teams schon gearbeitet, auch Firmenübergreifend und themenübergreifend, also in verschiedenen Branchen. Und weil du meintest, dass die Rollen komplett ausgelebt werden müssen, also verinnerlicht werden müssen, finde ich zum Beispiel, dass die Rolle Scrum Master.
Sehr gutes Beispiel ist, weil viele ne in der alten Welt, ich nenne es jetzt mal bewusst alten Welt, dieser Rolle nicht so viel Beachtung schenken oder Wertschätzung, aber sie ist unfassbar wichtig für ein Scrum Team, weil wir ja schon meinen, wenn man Probleme haben ist das genau die Person die angesprochen werden muss um diese Probleme zu lösen. Die Rolle Scrum Master ist auch dafür verantwortlich, weil wir meinten man ist ein Scrum Team. Bei vielen Produktentwicklungen
hast du ja mehrere. 9 Teams, beispielsweise Backend und Frontend Entwicklung mal jetzt so ne. Also du hast jetzt 2 Teams und dann sind Scrum Master auch dafür verantwortlich die Interkommunikation zu schaffen, ja. Definitiv.
Also ich kenne. Das zum Beispiel, weil du gerade meintest, ne, also es, ich habe es durchaus auch erlebt, dass beispielsweise wenn du jetzt über so Retrospektiven ne, also ne, das wird auch oftmals, das kenne ich zum Beispiel auch im im Entwickler Kreis es dann so, Boah jetzt wieder so retro gucken, was wir jetzt irgendwie gemacht haben ist Zeitverschwendung. So ne, das ist sozusagen also das kenne ich auch. Das ist das das das sowas dann
irgendwie abgetan wird. Also aus Entwickler Sicht was meiner Meinung nach auch nicht unbedingt gut ist, weil so eine Retrospektive durchaus wertvoll sein kann.
Aber jetzt kommt wieder genau der Punkt, wie wird diese Retrospektive aufgesetzt und das ist sozusagen wiederum da kommt die Rolle des Scrum Masters n Spiel, weil wenn zum Beispiel wenn du sagst der Scrum Master sagt, Hey wir machen jetzt ne Retro was ist gut gelaufen, was ist schlecht gelaufen, lass uns darüber reden und dann gucken wir, dass wir irgendwie n paar Aufgaben daraus herausziehen und dann wird irgendjemand auf diese Rolle gesetzt und nächstes Mal gucken mal nach ob das gemacht
wurde. Dann werden die Aufgaben 5 Wochen nicht gemacht und irgendwann heißt es ja gut, kann ja nicht so wichtig gewesen sein, es kommt weg.
So, das ist natürlich irgendwie ne Sache, wo man sich dann vielleicht OK jedes Mal das gleiche irgendwie blöd, weil ich finde also meine Ansicht auf die Dinge ist also auf diese Rolle von Scrum Master ist, dass sozusagen Scrum Master sensibel gucken muss, was, wie es gerade der das Gemüt vom Team im Allgemeinen, was gerade passiert, also ein Scrum Master. Darum machen was passiert gerade.
Was ist das Geschehen im Team? Wie spielt das Team miteinander, die einzelnen Entwickler und Entwicklerinnen, wie was passt da gerade, was passt nicht und dann wirklich sehr sensibel diese Retrospektive genau auf den entsprechenden Fall anzusetzen, auf jede Woche vielleicht was anderes, sich darüber Gedanken zu machen, nur wenn wir jetzt nur Retrospektive sind, es gibt ja noch ganz viele andere Sachen, die um die sich kümmern muss, aber da sind zum Beispiel Sachen, wo ich halt
gemerkt habe, dass Ist wirklich schwierig einen guten Scrum Master und ein gutes Grund Masterin zu finden. Ne und und und. Also da geht es schon los ne weshalb das vielleicht auch nicht immer so funktioniert wie man sich das vorstellt. Absolut. Ja. Auch mal kurz zu unserem Projekt, zumindest für mich ist das aktuelle Projekt das erste Mal. Dass wir ne Scrum Master haben,
die das Vollzeit macht. Ja, und das ist wichtig, das ist ne Vollzeit Rolle, weil ich kenne noch alte Projekte, wo das gefühlt so, ja, ich mache das nebenbei, ich mach 2 Tage Schulung, dann nenne ich mich Scrum Master und mach das so 10% meiner Arbeitszeit, aber genauso läuft es dann halt nicht, weil dann passiert das, was du gerade meintest, alles nicht möchte, deswegen bin ich wirklich froh jetzt in unserem Team Scrum mastern zu haben, die das wirklich, dass es ihr Job Profil
ja weil das ist ein eigenständiges Profil. Ja. Definitiv.
Also ich hab das ja auch, ich hab ja auch bevor ich in in dein Team gekommen bin, habe ich ja auch quasi 5 Jahre lang auch sage ich mal Scrum ähnlich gearbeitet, da hieß es aber nicht Scrum Master, sondern I Coach, also agile Coaches waren das, aber im Endeffekt ist es sehr sehr ähnlich was diese Rollen, also es ist mehr eigentlich ne n anderer Name, dafür würde ich das jetzt mal nennen, aber da war es zum Beispiel auch so, dass da hatten wir sehr sehr gute sag ich mal
Coaches die das gemacht haben. Und was mir aber aufgefallen ist, ist, dass zum Beispiel meistens hast du zu wenig davon.
Also es gibt zum Beispiel 10 Teams und 5 a Coaches oder 5 Scrum Master und im Optimalfall ist es eigentlich wichtig, dass man quasi wirklich für einen, für einen Team eine dedizierte Person dafür hat und ja genau und viele denken sich dann so wahrscheinlich aus Managementsicht ja, aber was soll ich denn jetzt so n Hans und Franz da jetzt mal blöd gesagt da hinstellen der die ganze Zeit nur.
Ein paar Termine macht und mal so ein bisschen Halli Hallo sagt und den Rest des Rest des Tages durchgeht. Und das ist halt genau nicht der Fall, finde ich.
Wie ich schon meinte, man muss sehr sehr in dieses Team geschehen, eingreifen, sich sehr viel Gedanken darum machen und das wird oftmals halt einfach irgendwie so ein bisschen abgetan, ne wie zum Beispiel jetzt auch mal so ein bisschen blöd zu sagen so ich weiß nicht, kennst du das Designer oder eine Designerin wo dann gesagt wird die malt nur Bildchen ne nur mal am Rande ist ja zum Beispiel. Genau, ist halt so ne Sache, so würde ich damit vergleichen und das ist das ist so wie wenn man
sagt, ja so ein Programmierer der keine Ahnung der Typ hat da ein bisschen rum, so schreibt ein bisschen Text, so würde ich das sagen, also das ist es ja auch nicht, ne und deswegen muss man sich da auch einfach mal überlegen, OK, das gibt die Rollen die und jeder sollte einen gewissen Respekt davor haben und auf der anderen Seite sollte diese Rolle aber auch gut ausgeführt werden, weil es gibt finde ich schon auch manchmal so, dann die auch genau auf der Seite von dieser Rolle dann eben
die Einstellung so ja ich mach ja nur, das ist ja entspannt, ganz ehrlich, ich muss mich da gar nicht drum kümmern. Ne, also ich kenne zum Beispiel n hätte Quatsch jetzt so viel,
aber mir fällt da gerade das. Ist ja genau der Punkt, weil das ist ja wirklich, wie ich meine Mindset frage ja genau, entweder ich lebe das wirklich das ganze agile Framework oder vielleicht ist es dann doch nicht die richtige Arbeitsweise für das Projekt, in dem Ich bin, genau, oder ich bin vielleicht nicht richtig in diesem Projekt, kann man ja, also kann ja auch sein, dass alle anderen das total abfeiern und gut danach arbeiten
und ich selbst. Aber das ist nicht mein Ding, ist ja, da muss man das ja auch für sich erkennen, was ich noch sagen. Wollte.
Was also ich hab da so eine Story gehört von einem Kumpel wo in der Firma der Mutter von dem Kumpel die da also die Mutter arbeitet in einer Firma und da kam sozusagen auch ne Person rein, weil in der Firma wurde dann gewünscht, ja wir wollen mal ein bisschen agil arbeiten und dann wurde eine Person eingestellt, die das Ganze ein bisschen vorgestellt hat und die Chefin dort in dieser Firma hat dann gesagt, ja, also das wurde
so schlecht rübergebracht, also ne, weil gerade dieses ja ja ich mach das mal so n bisschen du und wie du meintest dieses Mindset, du musst das richtig leben. Muss da so von überzeugt sein, dass du den Leuten erklären kannst, wieso das geil ist? Und das kam halt nicht rüber.
Das heißt, eine Person, die dafür wirklich, also wahrscheinlich auch masterin, die wirklich dafür zuständig ist, zu sagen, deshalb macht man Scrum, deshalb arbeitet man agil, hat es nicht hingekriegt, Frau zu überzeugen, weil die Chefin meinte dann so, keine Ahnung, warum machen wir denn den Quatsch so, also hat Fragen gestellt, die Fragen konnten 0 beantwortet werden und hinterher hat die Mutter von meinem Kumpel meinen Kumpel angerufen, der sozusagen halt auch sehr viele
in diesem agilen Bereich arbeitet. Und meinte dann so ja, kannst du da vielleicht mal kommen? Du kennst dich doch richtig gut dran aus. Also das ist halt so richtig. Blöd ne also.
Wenn du Leute hast, die das nicht richtig vertreten können, dann ist das halt irgendwie echt Käse und das solche Leute braucht es ne, aber da würde ich gerne noch mal auf eine letzte Sache zu sprechen kommen, weil genau das ist nämlich der.es gibt halt Unternehmen die sagen ey wir wollen jetzt agil arbeiten, wir wollen nach Scrum arbeiten ne so und dann gibt es halt zum Beispiel solche wo man sagt okay das Macht vielleicht Sinn. Oder es macht vielleicht auch
gar keinen Sinn und manche wollen einfach nur diesen Stempel. Ja, wir arbeiten agil draufgedrückt, haben aber tun es eigentlich gar nicht, das Mindset ist nicht da, die Anwendungen sicher nicht, da
dann genau. Und. Deswegen würde ich gerne nochmal sagen, es gibt ja auch Vorteile und Nachteile von beziehungsweise wann ist denn Scrum eigentlich sinnvoll einzusetzen und wann macht es keinen Sinn Scrum zu nutzen, weil ne von aus der Community kam ja auch, dass es irgendwie also das verteufelt wird. Scrum ist vielleicht nicht so gut und es kann ja durchaus sein, dass Scrum vielleicht. Überhaupt nicht sinnvoll ist. Und ich finde, das können wir auch noch mal, vielleicht ein
bisschen kurz beleuchten. Ja, sollten wir auf jeden Fall auch tun das auch, denn guter Abschluss sag ich mal. Also meine Sicht der Dinge ne ist ja jetzt auch nicht in Stein gemeißelt. Doch doch, ich hör. Zu jetzt kommt die Wahrheit. Prophet lino. Nein, also ich. Denke wenn wenn ich in einem Projekt arbeite, was den zeitlichen Rahmen hat, also meinetwegen, wir entwickeln jetzt ein Produkt ein halbes Jahr, das soll so und so aussehen und ist dann fertig
entwickelt. Das ist keine fortlaufende Entwicklung, dann ist es möglich, dass man sagen kann, ja, Pass auf die Anforderungen, klar, wir haben Zeitplan, 6 Monate kann man noch überschauen. Ja. Die wir die. Halt definieren unsere Requirements leiten davon jetzt unsere Features ab und dann werden die umgesetzt und im halben Jahr ist das Ding fertig. N kleines Projekt beispielsweise ja. Wozu soll ich?
Mir den Overhead machen und mir davon jetzt nochmal Zeit klauen für das Framework an sich, weil wir gesagt haben, es gibt mehrere Termine. Es gibt diese Feedback schleifen, das frisst ja auch Arbeitszeit, keine Frage und definitiv Kapazitäten beispielsweise Product Owner und Scrum Master. Sozusagen, weil es ist ja eigentlich klar, was zu tun ist. Ja, warum?
Vereinfacht gesagt wäre für mich ein Fall, wo man sagen könnte, herkommen brauchen wir jetzt keinen Scrum Framework aufsetzen, dafür ja. Anders. Sieht es aus, wenn du n fortlaufende Entwicklung hast. Das heißt du startest mit einer ersten Version von dem Produkt Christ, dann Feedback vom Kunden selbst, Kunden, Anforderungen und es ist eine fortlaufende Entwicklung und es ist noch gar nicht so wirklich klar, was wie wann kommt. Also. Ich würde.
Aus du halt diese agile Arbeitsweise in meinen Augen. Also dann ist es für mich so gesehen schon Pflicht, mit einer agilen Arbeitsweise an die Sache ranzugehen, um halt schnelles Feedback zu generieren. Ja, ich würde.
Auch sagen so, wenn du, wenn sich zum Beispiel wenn du Anforderungen hast und Prioritäten hast, die sich schnell ändern können, wenn es zum Beispiel wenn du mit wenn du ein Produkt entwickelst, was zum Beispiel irgendwie auf bestimmte Einflüsse schnell reagieren muss oder zum Beispiel auch. Wenn du halt ne dieses Feedback brauchst zum Beispiel.
Du entwickelst ein Produkt für einen bestimmten Kunden und der Kunde sagt dann beispielsweise EY, das find ich jetzt irgendwie blöd, dass müssen wir ändern, dann musst du schnell in der Lage sein, sozusagen um zu priorisieren, flexibel auf diese Anforderungen zu reagieren und genau in solchen Fällen macht es Sinn und ich finde es sehr gut, was du meintest, dass man sagt, so wenn starre Anforderungen da sind und man eigentlich weiß,
ey, das ist jetzt, das ist so, also wir brauchen da gar nicht großartig darüber zu diskutieren, es ist absolut in
Stein gemeißelt. Mehr oder weniger, was passieren muss, dann brauchst du keinen Scrum und genau dann ist es halt so, dass zum Beispiel ne. Vielleicht irgendwie der eine oder andere oder die eine oder andere sich denkt, ja, warum sollen wir dann das jetzt machen, weil wie du schon meintest, du hast dann diese ganzen Termine die on top kommen und musst aber eigentlich gar nicht irgendwie großartig
gucken. OK, was steht denn als nächstes an, weil die Prioritäten sind ja quasi absolut sequentiell festgesetzt, wir machen das, wir machen das, wir machen das fertig, so ganz gut, da muss nicht irgendwie flexibel rum priorisiert werden, so ne genau. Das auf jeden schließlich noch einen letzten Punkt. Sehr gerne, weil.
Dann. Die Folge ist jetzt auch schon relativ lang, da sollten wir mal langsam zum Schluss kommen, aber man merkt einfach, dass ein Thema, da könnten wir ja auch schon drüber reden, definitiv, was natürlich jetzt auch noch oder ein Argument ist für oder dagegen ist einfach auch die Projektgröße und die Team Größe, wenn nicht jetzt in einem Projekt arbeite, wo es mehrere Bereiche gibt wie beispielsweise Frontend Entwicklung, Backend Entwicklung, whatever ne je mehr
Leute dazu kommen umso mehr macht es Sinn das agil zu organisieren und den Teams zu unterteilen und dann hast du ja wie gesagt die Rolle. Was die Interkommunikation aufbaut und alles. Also dann macht es auch wieder Sinn, weil sonst wird es einfach zu viel, was überblickt werden muss. Ja was absolut statischen schwierig ist das alles im Vorfeld zu sehen sozusagen ne, da gibt es ja noch. Andere Frameworks teilweise dafür ne. Da muss man dann halt gucken,
was passiert ist. Aber wenn ich jetzt beispielsweise wirklich so n halbes Jahr ein ganz kleines Projekt, ein 2 Entwickler alleine muss man sowieso nicht. Aber weißt. Du, wenn du jetzt zu zweit, ich meine, wir haben auch kleinere Projekte zu zweit gemacht, da haben wir ja nicht angefangen und uns Scrum Master. Versucht, so weißt du das war der Fehler. Das war der. Fehler.
Deswegen ist es gescheitert. Nein. Spaß beiseite, aber im Endeffekt ist es halt einfach wichtig zu gucken, OK, was sind die Anforderungen und welche, welche Arbeitsmethode kann man denn dann wählen? Ne, also es ist immer schlecht zu sagen wir nehmen das für alles, sondern man muss halt immer und das ist ja wie meistens der Fall, man muss gucken was eignet sich und was eignet sich nicht ne sehr gut und Schlusswort beispielsweise sowas wie war gerade auf meine Freundin.
Die Entwicklung. Ich möchte jetzt überleiten. Ich bin dafür. Man sollte das nicht trennen. Full Stack ist super und ich wollte eigentlich nur sagen,
vielleicht wollten. Also da würde ich gerne auch vielleicht nochmal ne Folge drüber machen und mich würde einfach mal interessieren, ob die Zuhörerinnen und Zuhörer zum Beispiel einfach auch dafür Interesse haben zu sagen, OK Full Stack Entwicklung interessiert mich, wenn ja, schreibt es uns doch auch mal bei Instagram und schreibt uns auch Eure Erfahrungen mit mit Scrum oder mit anderen agilen Frameworks oder auch anderen Arbeitsmethoden.
Uns würde das total interessieren, Eure Erfahrungen zu hören. Mit euch in den Austausch zu kommen und wie gesagt, Wenn ihr Interesse habt an der Folge über Full Stack, dann haut mal raus. Ich hätte Lust, aber ich hätte Lust mal drüber zu quatschen. Genau, aber in diesem Sinne, wie gesagt schreibt uns, kommt auf uns zu auf Instagram.
Wir haben auch noch andere Plattformen wie zum Beispiel Twitch die wir bespielen werden, genau und aber alle Links dazu findet ihr auf jeden Fall in den Show Notes lasten Like da empfiehlt den Podcast falls ihr euch gefallen hat, euren Freunden und Freundinnen. Und in diesem Sinne hören wir uns hoffentlich nächste Woche wieder bei den Coding Buddies und in diesem Sinne wünsche ich euch noch einen. Schönen Tag. Eure Calling Babys gemeinsam besser.