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.