Latest / Coding Buddies | Tech & Dev-Mindset / Scrum - Revolution oder Illusion?

Transcript

Scrum - Revolution oder Illusion? · Coding Buddies | Tech & Dev-Mindset

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