1
00:00:01,040 --> 00:00:03,920
Agile und Scrum haben einst die 
Softwareentwicklung 

2
00:00:03,920 --> 00:00:07,760
revolutioniert, mit Fokus auf 
Menschen, Prozesse, schnelle 

3
00:00:07,760 --> 00:00:10,320
Iterationen und vor allem 
funktionierende Software. 

4
00:00:10,800 --> 00:00:13,680
Doch heute drückt KI mit 
ungeahnter Geschwindigkeit aufs 

5
00:00:13,680 --> 00:00:17,480
Gas und Agenten erledigen Arbeit
blitzschnell und Sprints wirken 

6
00:00:17,480 --> 00:00:20,040
irgendwie schleppend und Tickets
verlieren immer mehr an 

7
00:00:20,040 --> 00:00:23,360
Bedeutung und menschliches 
Review wird plötzlich zum 

8
00:00:23,360 --> 00:00:25,680
Bottleneck. 
In dieser Folge stellen wir uns 

9
00:00:25,680 --> 00:00:29,200
die Frage. 
Sind Scrum und JIRA in Zeiten 

10
00:00:29,200 --> 00:00:38,760
von KI überhaupt noch zeitgemäß?
Und damit Hallo und herzlich 

11
00:00:38,760 --> 00:00:42,720
Willkommen zu einer neuen Folge 
des To do Developer Podcasts, 

12
00:00:42,720 --> 00:00:45,360
eurem deutschsprachigen 
Developer Podcast. 

13
00:00:45,360 --> 00:00:49,040
Überall, wo es Podcasts gibt und
ihr hört wieder Robin Manuel 

14
00:00:49,040 --> 00:00:52,520
Thiel gerade im Intro. 
Er ist Director AI und Cloud 

15
00:00:52,520 --> 00:00:54,800
beim E Commerce 
Softwareunternehmen Jtl und ich 

16
00:00:54,800 --> 00:00:57,600
bin malte Lantin ich bin 
Solutions Engineer bei github, 

17
00:00:57,680 --> 00:01:00,960
den Podcast machen wir aber 
privat und in unserer Freizeit 

18
00:01:01,200 --> 00:01:05,440
und sprechen einmal abwechselnd 
über ein Thema wie heute oder 

19
00:01:05,440 --> 00:01:07,840
auch in Alternativen. 
In der Reihenfolge in der 

20
00:01:07,840 --> 00:01:10,960
nächsten Woche wieder über die 
aktuellen Tag und Developer 

21
00:01:10,960 --> 00:01:12,640
News. 
Aber heute haben wir uns ein 

22
00:01:12,640 --> 00:01:15,520
ganz spannendes Thema 
rausgesucht beziehungsweise du 

23
00:01:15,520 --> 00:01:17,600
hast das mitgebracht, weil du 
einen ganz interessanten 

24
00:01:17,600 --> 00:01:21,560
Blogspot gesehen hast. 
Auch wenn du im Intro über JIRA 

25
00:01:21,560 --> 00:01:24,560
gesprochen hast. 
Die Inspiration kam von Ninea, 

26
00:01:24,560 --> 00:01:26,840
die machen aber auch Planning 
und Tracking, von daher hängt 

27
00:01:26,840 --> 00:01:30,640
das sehr eng zusammen, aber ich 
glaube, in unserer Welt ist JIRA

28
00:01:30,640 --> 00:01:34,160
immer noch das Tracking Tool der
Wahl, von daher passt der 

29
00:01:34,160 --> 00:01:37,720
Aufhänger aber bevor wir. 
Da in die Details gehen, müssen 

30
00:01:37,720 --> 00:01:40,240
wir uns natürlich auch wieder 
bei euch bedanken. 

31
00:01:40,640 --> 00:01:41,800
Ja. 
Ich bin erstmal noch ganz baff 

32
00:01:41,800 --> 00:01:44,720
von einer alternierenden 
Reihenfolge hier. 

33
00:01:45,320 --> 00:01:48,800
Man merkt, der Malta hat 
studiert, viel wichtiger als zu 

34
00:01:48,800 --> 00:01:51,360
studieren ist in der Soft 
Entwicklung aber mit Koffein 

35
00:01:51,360 --> 00:01:54,280
ausgestattet zu sein und bevor 
wir ins Thema einsteigen, sagen 

36
00:01:54,280 --> 00:01:56,480
wir noch ganz schnell danke an 
euch, die Community, ihr habt 

37
00:01:56,480 --> 00:01:59,600
uns nämlich wieder Kaffee 
ausgegeben und zwar haben wir 3 

38
00:01:59,600 --> 00:02:03,120
Kaffee von Noemi bekommen, einen
Kaffee vom Thomas bekommen und. 

39
00:02:03,480 --> 00:02:06,400
Uns 6 Kaffee von Suffian ganz, 
ganz lieben Dank. 

40
00:02:06,640 --> 00:02:09,840
Vielen Dank dafür. 
Und wenn auch ihr uns einen 

41
00:02:09,840 --> 00:02:13,440
Kaffee ausgeben wollt, findet 
ihr den Link zu bei mir 

42
00:02:13,440 --> 00:02:16,800
coffee.com in den Shownotes. 
Da freuen wir uns immer 

43
00:02:17,120 --> 00:02:20,640
tierisch, wenn wir hier unseren 
Koffeinvorrat auffüllen können. 

44
00:02:20,880 --> 00:02:23,360
Ja, steigen wir mal ein und du 
hast ja schon gesagt, so ein 

45
00:02:23,360 --> 00:02:25,840
bisschen das Thema und der 
Aufhänger war eigentlich ein 

46
00:02:25,840 --> 00:02:29,120
Blogspot von. 
Ich glaube, er heißt Carrie 

47
00:02:29,120 --> 00:02:32,040
Sarien. 
Das ist der CEO von linear und 

48
00:02:32,040 --> 00:02:33,120
der hat so ein bisschen 
geschrieben. 

49
00:02:33,120 --> 00:02:37,160
Issue tracking is that also 
issue Tracking ist tot und hat 

50
00:02:37,160 --> 00:02:39,880
gesagt, das ist eigentlich für 
eine alte Welt gebaut, das ist 

51
00:02:39,880 --> 00:02:42,800
ein eigenes Modell und wir 
hatten ja auch so ein bisschen 

52
00:02:42,800 --> 00:02:46,200
irgendwie gesagt, so agile ist 
tot und ich fand es ganz witzig,

53
00:02:46,200 --> 00:02:49,120
du hast mir so direkt direkt 
zurückgeschrieben, klingt 

54
00:02:49,120 --> 00:02:53,120
eigentlich wie eine typische 
linkedin Provokation, ich würde 

55
00:02:53,120 --> 00:02:55,040
aber sagen aber. 
Ich jetzt mal ganz ehrlich 

56
00:02:55,040 --> 00:02:58,160
irgendwie, wenn wenn KI auf 
einmal so in Stunden Dinge baut,

57
00:02:58,160 --> 00:03:03,800
die früher Teams über 23 Sprints
gebaut haben, da muss man sich 

58
00:03:03,800 --> 00:03:06,960
ja schon fragen, was ist denn 
eigentlich noch ein Sprint wert 

59
00:03:06,960 --> 00:03:09,120
und warum sollte ich denn 
vielleicht auch künstlichen KI 

60
00:03:09,120 --> 00:03:12,400
Agenten warten lassen? 
Bis der nächste Sprint anfängt, 

61
00:03:12,400 --> 00:03:14,240
weil der ja eigentlich schon 
fertig wäre, kann ich überhaupt 

62
00:03:14,240 --> 00:03:16,480
noch einschätzen, wie lange eine
KI für irgendein Sprint braucht.

63
00:03:16,800 --> 00:03:21,480
Ist also vielleicht auch das 
ganze ja strump pokern und so 

64
00:03:21,480 --> 00:03:24,000
was tot und darüber sprechen wir
diese Folge ein bisschen. 

65
00:03:24,240 --> 00:03:27,040
Ja, und das ganze auch vor dem 
Hintergrund, dass ja in der 

66
00:03:27,040 --> 00:03:29,520
Vergangenheit wir immer 
irgendwie mehr. 

67
00:03:30,000 --> 00:03:33,480
Aufgaben zu erledigen hatten. 
Als wir developer Zeit hatten, 

68
00:03:33,480 --> 00:03:36,880
weil natürlich das immer der 
limitierende Faktor war, also 

69
00:03:36,880 --> 00:03:39,520
wie viele Developer haben wir, 
die wie schnell die Dinge 

70
00:03:39,520 --> 00:03:41,440
implementieren können. 
Das heißt, wir brauchten 

71
00:03:41,440 --> 00:03:44,960
irgendwie ein Modell, wie wir 
das Ganze in eine Reihenfolge 

72
00:03:44,960 --> 00:03:47,680
bringen, wie wir das Ganze 
sinnvoll abarbeiten und 

73
00:03:47,680 --> 00:03:52,320
möglichst schnell zu sichtbaren 
Ergebnissen kommen und nicht wie

74
00:03:52,320 --> 00:03:56,080
irgendwo in. 
Grauer Vorteil in irgendwelchen 

75
00:03:56,080 --> 00:03:58,880
ewigen Planungsprozessen. 
In meinem Wasserfallmodell 

76
00:03:58,880 --> 00:04:01,120
hängen zu bleiben und dann 
vielleicht irgendwie ein Jahr 

77
00:04:01,120 --> 00:04:04,760
später völlig am Kunden vorbei 
geplant zu haben, sondern ganz 

78
00:04:04,760 --> 00:04:07,280
schnell zu etwas sichtbarem zu 
kommen. 

79
00:04:07,360 --> 00:04:10,320
Und wenn man ganz schnell zu 
etwas sichtbarem kommt, dann 

80
00:04:10,320 --> 00:04:13,520
erinnert das natürlich an die 
Dinge, die wir heute mit den KI 

81
00:04:13,520 --> 00:04:17,440
Agenten tagtäglich tun und die 
uns immer wieder vor Augen 

82
00:04:17,440 --> 00:04:20,360
führen, dass das. 
Das Schreiben von Code jetzt 

83
00:04:20,360 --> 00:04:25,360
nicht mehr so der Bottelnag ist,
sondern tatsächlich die Dinge 

84
00:04:25,520 --> 00:04:28,480
ordentlich zu erarbeiten, die 
man implementieren möchte, also 

85
00:04:28,480 --> 00:04:30,320
eigentlich die Zielsetzung der 
Software. 

86
00:04:30,800 --> 00:04:34,160
Und wir brauchen vielleicht gar 
nicht mehr dieses klassische 

87
00:04:34,960 --> 00:04:39,040
Tracking, wo wir irgendwo als pm
diesen ganz langen Backblock 

88
00:04:39,040 --> 00:04:41,280
haben und dann eigentlich 
irgendwie einen Mechanismus 

89
00:04:41,280 --> 00:04:43,960
brauchen, um diese Arbeit dann 
an die Engineers zu übergeben, 

90
00:04:43,960 --> 00:04:46,960
die dann damit weiterarbeiten. 
Sondern wir brauchen etwas, 

91
00:04:46,960 --> 00:04:50,160
vielleicht was anderes, etwas 
Neues, was jetzt in dieser 

92
00:04:50,160 --> 00:04:54,760
neuen, agentischen Arbeitsweise 
vielleicht viel besser 

93
00:04:54,760 --> 00:04:56,960
funktioniert als das, was wir in
der Vergangenheit gemacht haben.

94
00:04:56,960 --> 00:05:00,160
Du hattest ja gerade gesagt in 2
Wochen, wieso ein üblicher 

95
00:05:00,160 --> 00:05:02,880
Sprint ist. 
Da kann man natürlich heutzutage

96
00:05:02,880 --> 00:05:06,160
ungeheuer viel machen, es gibt 
ja sogar Leute, die behaupten, 

97
00:05:06,160 --> 00:05:08,760
sie hätten mal eben irgendwie 
auf einem Inlandsflug mal ein 

98
00:05:08,760 --> 00:05:10,560
komplettes Feature 
implementiert, was ich so ein 

99
00:05:10,560 --> 00:05:14,080
bisschen für fragwürdig halte. 
Aber ich glaube, in die Richtung

100
00:05:14,080 --> 00:05:15,920
wird ja mittlerweile viel 
argumentiert. 

101
00:05:16,320 --> 00:05:19,160
Muss der Inlandsflug aber noch 
Internet haben, weil die lokal 

102
00:05:19,160 --> 00:05:21,360
laufenden Modelle, glaube ich da
zumindest noch nicht so ganz 

103
00:05:21,360 --> 00:05:24,280
probiere sie auch immer wieder 
aus, aber richtig überzeugt beim

104
00:05:24,280 --> 00:05:26,120
Coding haben die mich noch 
nicht, aber das ist ein anderes 

105
00:05:26,120 --> 00:05:28,160
Thema. 
Wir wissen aber auch, dass das 

106
00:05:28,160 --> 00:05:29,840
ein Thema ist, was 
wahrscheinlich auch viele 

107
00:05:29,840 --> 00:05:32,240
Emotionen irgendwie hochbringen 
wird, deswegen können wir jetzt 

108
00:05:32,240 --> 00:05:34,320
ja schon mal ankündigen, wir 
sind wahnsinnig gespannt, wie 

109
00:05:34,320 --> 00:05:36,640
ihr das am Ende seht, also 
schreibt uns eure Meinung auch 

110
00:05:36,640 --> 00:05:39,040
gerne schon mal in die 
Kommentare oder auch am Ende der

111
00:05:39,040 --> 00:05:41,480
Folge, wenn ihr eine andere 
Sicht hat, das interessiert uns 

112
00:05:41,480 --> 00:05:45,120
sehr, denn. 
Agile und Scrum, das sind ja 

113
00:05:45,120 --> 00:05:48,320
quasi schon so physikalische 
Gesetze geworden, wie Software 

114
00:05:48,320 --> 00:05:51,840
gebaut wird und vor allem so 
seit dieser Dev OPS Revolution 

115
00:05:51,840 --> 00:05:56,480
so um die 2010 er Jahre rum. 
Aber nicht nur der der linear 

116
00:05:56,480 --> 00:05:59,640
CEO scheint das so zu sehen, der
hat ja also Einsatz vor allem 

117
00:05:59,640 --> 00:06:01,480
diesem blogspot irgendwie ein 
bisschen hängen geblieben, der 

118
00:06:01,480 --> 00:06:04,080
hat gesagt, hier diese 
Zeremonie, die. 

119
00:06:04,360 --> 00:06:06,480
Die man ja eigentlich auch in so
einem richtigen Scrum 

120
00:06:06,480 --> 00:06:08,920
durchläuft. 
Die kommt halt daher, dass man 

121
00:06:08,920 --> 00:06:11,200
damals echte Einschränkungen 
hatte und vor allem mal diese 

122
00:06:11,200 --> 00:06:14,280
Engineering Time, das war so ein
bisschen der limitierende Faktor

123
00:06:14,280 --> 00:06:18,320
und Teams mussten sie quasi sich
ganz vorsichtig zwischen diesen 

124
00:06:18,320 --> 00:06:21,160
Rollen und Funktionen bewegen, 
die man eben in diesem diesem 

125
00:06:21,160 --> 00:06:23,440
Scrum hat. 
Aber muss ja auch dazu sagen. 

126
00:06:23,440 --> 00:06:26,640
Auch Thomas Domke zum Beispiel, 
der ehemalige CEO von github, 

127
00:06:26,880 --> 00:06:29,520
der hat ja auch für sein neues 
Projekt irgendwie erkannt, dass 

128
00:06:29,520 --> 00:06:33,520
der Status Quo, den wir heute 
haben, nicht unbedingt der 

129
00:06:33,520 --> 00:06:36,560
Idealzustand ist. 
Wenn wir mal so Agent First, 

130
00:06:36,560 --> 00:06:38,560
würde ich das Mal nennen, 
denken. 

131
00:06:38,880 --> 00:06:42,240
Ja, und das Interessante ist ja,
dass gerade im Moment immer 

132
00:06:42,240 --> 00:06:45,280
noch. 
Ganz viele in diesen agilen 

133
00:06:45,280 --> 00:06:48,080
Prozessen arbeiten Scrum 
Zeremonien, machen aber die 

134
00:06:48,080 --> 00:06:51,440
Technologie sich ja ungeheuer 
schnell weiterentwickelt hat. 

135
00:06:51,440 --> 00:06:54,680
Das heißt, die Technologie, die 
wir einsetzen, hat sich 

136
00:06:54,680 --> 00:06:57,800
schneller weiterentwickelt als 
unsere Prozesse, das ist ja 

137
00:06:57,800 --> 00:07:00,560
häufig so. 
Und ich glaube, jetzt beginnen 

138
00:07:00,560 --> 00:07:03,040
viele Organisationen darüber 
nachzudenken, die Prozesse 

139
00:07:03,040 --> 00:07:05,920
nachzuziehen, nachdem irgendwie 
schon dreiviertel der 

140
00:07:05,920 --> 00:07:08,560
Unternehmen irgendwelche 
Software Engineering Agents 

141
00:07:08,560 --> 00:07:12,560
haben und diese auch schon aktiv
einsetzen und damit merken, dass

142
00:07:12,560 --> 00:07:16,800
sie immer mehr Code produzieren 
in immer kürzerer Zeit und jetzt

143
00:07:16,800 --> 00:07:19,640
dann darüber nachdenken, haben 
wir dafür überhaupt noch den 

144
00:07:19,640 --> 00:07:22,720
richtigen Prozess? 
Ja, malte du als zertifizierter 

145
00:07:22,720 --> 00:07:26,480
Product Owner und du kennst dich
ja mit Scrum und Ager ziemlich 

146
00:07:26,480 --> 00:07:27,720
gut aus. 
Vielleicht holst du uns alle 

147
00:07:27,720 --> 00:07:28,920
noch mal irgendwie so ein 
bisschen ab und. 

148
00:07:29,680 --> 00:07:31,440
Wofür war das denn ursprünglich 
mal gedacht? 

149
00:07:31,440 --> 00:07:34,160
Und das ist ja auch nicht genau 
das, wofür es heute genutzt 

150
00:07:34,160 --> 00:07:35,120
wird. 
Es gibt ja fast keine 

151
00:07:35,120 --> 00:07:37,920
Organisation, in dem Scrum 
wirklich nach Lehrbuch 

152
00:07:37,920 --> 00:07:40,760
eingesetzt wird, aber vielleicht
können wir das mal irgendwie 

153
00:07:40,760 --> 00:07:43,320
kurz auch halbwegs fair 
irgendwie einordnen, bevor wir 

154
00:07:43,320 --> 00:07:46,160
es kritisieren und mal irgendwie
gucken, wo kommen wir denn 

155
00:07:46,160 --> 00:07:48,440
eigentlich her und warum war das
mal das Richtige, weil dann 

156
00:07:48,440 --> 00:07:49,920
können wir eigentlich 
beleuchten, ist es denn immer 

157
00:07:49,920 --> 00:07:52,800
noch das Richtige? 
Ja, es war tatsächlich so ein 

158
00:07:52,880 --> 00:07:54,880
Gegenentwurf. 
Und Scrum ist ja jetzt eine 

159
00:07:54,880 --> 00:07:59,600
bestimmte Art von einem agilen 
Softwareentwicklungsprozess, und

160
00:07:59,840 --> 00:08:02,000
das war so der Gegenentwurf für 
diesen klassischen 

161
00:08:02,000 --> 00:08:06,040
Wasserfallprozess oder v Modell,
wo wir sehr langsam und 

162
00:08:06,040 --> 00:08:08,800
strukturiert einen Schritt nach 
dem anderen gemacht haben, 

163
00:08:09,040 --> 00:08:12,440
sondern wir haben gesagt, wir 
müssen in kurzen Iterationen 

164
00:08:12,440 --> 00:08:14,360
möglichst schnell 
funktionierende Software 

165
00:08:14,360 --> 00:08:17,280
liefern, wir brauchen schnelles 
Feedback am Ende von jedem 

166
00:08:17,280 --> 00:08:19,280
Sprint gibt es eine 
Retrospektive. 

167
00:08:19,760 --> 00:08:22,160
Die Feedback Zurückspielt, mit 
dem wir unseren Prozess 

168
00:08:22,240 --> 00:08:25,720
verbessern können und vor allen 
Dingen ging es darum, sich in 

169
00:08:25,720 --> 00:08:28,520
dem Ganzen auf die Menschen und 
die menschliche Zusammenarbeit 

170
00:08:28,520 --> 00:08:32,720
zu konzentrieren und weniger 
irgendwie statische Artefakte zu

171
00:08:32,720 --> 00:08:36,480
produzieren, also irgendwelche 
ganz umfangreichen Requirements 

172
00:08:36,480 --> 00:08:39,200
Documents. 
Und das war natürlich eine große

173
00:08:39,200 --> 00:08:43,520
Revolution, auch weil es uns 
ermöglicht hat, viel schneller 

174
00:08:43,520 --> 00:08:46,480
auch Software zu liefern und auf
dieser Software schneller zu 

175
00:08:46,480 --> 00:08:48,880
iterieren. 
Gerade jetzt in dieser ganzen 

176
00:08:48,880 --> 00:08:51,280
Sars Revolution haben wir 
natürlich auch die Möglichkeit, 

177
00:08:51,280 --> 00:08:55,440
immer neue Software Versionen 
und neue Funktionalitäten quasi 

178
00:08:55,440 --> 00:08:57,360
sofort an unsere Kunden 
auszuliefern. 

179
00:08:57,360 --> 00:09:00,480
Wir brauchen jetzt nicht mehr 
irgendwelche langen Release 

180
00:09:00,480 --> 00:09:06,960
Zyklen Zyklen und da war auch so
ein agiles Modell und das agile 

181
00:09:06,960 --> 00:09:10,480
Modell was viele gewählt haben 
war halt Scrum mit seinen festen

182
00:09:10,880 --> 00:09:13,760
Prozessen und Rollen. 
Du hast gerade gesagt Product 

183
00:09:13,760 --> 00:09:16,640
owner, aber es gibt ja auch den 
Scrum Master des Dev Team. 

184
00:09:17,120 --> 00:09:20,440
Und die entsprechenden 
Zeremonien, die da durchgeführt 

185
00:09:20,440 --> 00:09:23,040
werden. 
Und da war das natürlich etwas, 

186
00:09:23,040 --> 00:09:26,600
was super relevant war und ganz 
viel gebracht hat. 

187
00:09:26,600 --> 00:09:28,960
Und ich glaube ganz viel auch 
der Software, die in den letzten

188
00:09:28,960 --> 00:09:34,800
20 Jahren entstanden ist, wäre 
in der Form gar nicht so schnell

189
00:09:34,800 --> 00:09:37,760
entstanden und hätte sich so 
schnell weiterentwickelt, wenn 

190
00:09:37,760 --> 00:09:42,160
wir nicht diese agile Revolution
mitgegangen wären und auch so. 

191
00:09:42,520 --> 00:09:45,480
Irgendwie mit Scrum und 
Framework gehabt haben gehabt 

192
00:09:45,480 --> 00:09:48,320
hätten, an dem wir uns 
orientieren können. 

193
00:09:48,640 --> 00:09:51,360
Und eigentlich ist Scrum ja auch
so ein natürlich irgendwo ein 

194
00:09:51,360 --> 00:09:52,840
Planungsframework. 
Aber ich finde auch so ein 

195
00:09:52,840 --> 00:09:55,520
bisschen so ein 
Kommunikationsframework, das ist

196
00:09:55,520 --> 00:09:58,480
ja eigentlich diese diese klaren
Hand of Modelle, also wann gebe 

197
00:09:58,480 --> 00:10:01,280
ich was, wohin weiter, und ich 
habe schon irgendwie das Gefühl,

198
00:10:01,280 --> 00:10:05,000
das ist, das war eigentlich mal 
dafür gedacht, dass Menschen mit

199
00:10:05,000 --> 00:10:07,440
dieser ganzen Arbeit, die vor 
ihnen liegen, diese riesengroßen

200
00:10:07,440 --> 00:10:11,120
Anwendungen irgendwie zu bauen. 
Nicht mehr hinterher kamen und 

201
00:10:11,280 --> 00:10:12,840
ich sagen, heute ist es ja erst 
ein bisschen umgekehrt. 

202
00:10:12,840 --> 00:10:14,640
Heute kommen Menschen eigentlich
nicht mehr dahinten nicht mehr 

203
00:10:14,640 --> 00:10:19,120
damit hinterher, die Arbeit 
entweder von einem KI Agenten zu

204
00:10:19,120 --> 00:10:24,480
reviewen oder einem KI Agenten 
Zuzuschustern, der sie dann in 

205
00:10:25,040 --> 00:10:27,040
einen Bruchteil der Zeit 
wahrscheinlich einfach 

206
00:10:27,520 --> 00:10:30,400
runterrockt oder dann halt 
irgendwie wieder eine Rückfrage 

207
00:10:30,400 --> 00:10:32,400
hat und ich merke das irgendwie 
selbst. 

208
00:10:32,400 --> 00:10:35,040
Ich gebe dem Agenten eine 
Aufgabe und bin fast schon 

209
00:10:35,040 --> 00:10:37,120
gestresst, wenn die Antwort zu 
schnell kommt, weil das gar 

210
00:10:37,120 --> 00:10:38,760
nicht in diesen normalen Prozess
passt, den wir in. 

211
00:10:39,120 --> 00:10:41,120
Indem ich irgendwie noch denke 
und arbeite. 

212
00:10:41,120 --> 00:10:43,120
Ich dachte, ich würde würde 
jetzt im Hintergrund erledigt 

213
00:10:43,120 --> 00:10:45,600
werden und ich hätte jetzt Zeit,
um mich um was anderes zu 

214
00:10:45,600 --> 00:10:48,320
kümmern und auf einmal poppt da 
irgendwie eine Rückfrage auf und

215
00:10:48,480 --> 00:10:51,160
das finde ich total schwer zu 
planen, wann springe ich da 

216
00:10:51,160 --> 00:10:52,960
jetzt direkt wieder hin, 
unterbreche ich meine aktuelle 

217
00:10:52,960 --> 00:10:56,160
Arbeit oder sage ich jetzt okay 
ich gebe ihm jetzt eine Aufgabe 

218
00:10:56,160 --> 00:10:58,440
und in einer Stunde komme ich 
wieder zu dem zurück und wenn er

219
00:10:58,440 --> 00:11:00,760
nach 10 Minuten eine Frage hat, 
dann habe ich halt irgendwie 50 

220
00:11:00,760 --> 00:11:03,640
Minuten verloren, wenn der erst 
nach 45 Minuten eine Frage hat, 

221
00:11:03,640 --> 00:11:05,840
ist es besser weil da habe ich 
nur eine Viertelstunde verloren 

222
00:11:06,320 --> 00:11:08,520
und und ich merke jetzt 
irgendwie so richtig so, dass 

223
00:11:08,520 --> 00:11:11,760
mich das fast schon stresst, wie
schnell diese antworten 

224
00:11:11,760 --> 00:11:14,120
Rückfragen kommt im Stress auch,
dass es nicht planbar ist, wann 

225
00:11:14,120 --> 00:11:16,560
dieser wann das passiert. 
Deswegen gehe ich immer mehr 

226
00:11:16,560 --> 00:11:19,640
auch in diesen yolo Mode rein, 
dass ich sage okay, du versuchst

227
00:11:19,640 --> 00:11:22,720
einfach so lange eigenständig 
das Problem zu lösen, bis du 

228
00:11:22,720 --> 00:11:24,480
wirklich gar nicht mehr weiter 
kommst. 

229
00:11:24,640 --> 00:11:26,720
Und das passt gar nicht so in 
diesen diesen starren Zyklen, 

230
00:11:26,720 --> 00:11:29,720
denen man jetzt irgendwie ein 
Ticket abgibt und. 

231
00:11:29,720 --> 00:11:31,920
Und das wieso ein bisschen ist 
ja so ein bisschen das Zuweisen 

232
00:11:31,920 --> 00:11:33,960
von einem Ticket an eine andere 
Person ist ja eigentlich wieso 

233
00:11:33,960 --> 00:11:36,360
ein Haken auf so eine to do 
Liste zu setzen, man ist ja mit 

234
00:11:36,360 --> 00:11:39,160
irgendwas fertig und wenn das 
dann, aber wir kennen ja beim 

235
00:11:39,160 --> 00:11:41,200
Menschen, auch wenn es dann noch
5 Minuten direkt wieder an mich 

236
00:11:41,200 --> 00:11:46,440
zurück essigned wird, dann ist 
das frustrierend und das merke 

237
00:11:46,440 --> 00:11:47,840
ich schon auf meiner täglichen 
Arbeit. 

238
00:11:48,080 --> 00:11:50,640
Ja, und ich glaube, das ist auch
so ein bisschen dieses Gefühl, 

239
00:11:50,640 --> 00:11:55,520
dass man vorher in diesen 2 oder
4 Wochen Rhythmen gearbeitet hat

240
00:11:55,520 --> 00:11:57,200
und dann da so ein bisschen 
auch. 

241
00:11:57,600 --> 00:12:00,400
Ruhe und Fokus auf eine 
bestimmte Aufgabe hatte 

242
00:12:00,480 --> 00:12:03,520
zumindest als Developer, der 
dann bestimmte Aufgaben 

243
00:12:03,520 --> 00:12:08,320
übernommen hatte und wir jetzt 
quasi irgendwie täglich mit uns 

244
00:12:08,320 --> 00:12:11,480
selber und unseren KI Agenten 
dieses Scrum Meetings haben. 

245
00:12:11,480 --> 00:12:14,880
Das heißt, wir schauen uns 
irgendwie quasi täglich unsere 

246
00:12:14,880 --> 00:12:17,680
Anforderungen an und sagen okay,
was machen wir dann heute, was 

247
00:12:17,680 --> 00:12:20,800
geben wir heute an die in die 
Implementierung und dann? 

248
00:12:21,880 --> 00:12:24,240
Beschäftigen wir uns damit, 
diesen Code entsprechend 

249
00:12:24,240 --> 00:12:27,040
Qualitäts zu sichern und 
sicherzustellen, dass das, was 

250
00:12:27,040 --> 00:12:30,000
wir da produzieren, auch 
wirklich in Produktion 

251
00:12:30,000 --> 00:12:33,120
funktioniert? 
Ich glaube, da war in der 

252
00:12:33,120 --> 00:12:36,400
Vergangenheit mehr der Fokus 
darauf, möglichst schnell 

253
00:12:36,400 --> 00:12:39,680
funktionsfähigen Code an die 
Kunden zu liefern. 

254
00:12:40,640 --> 00:12:43,960
Wohingegen man jetzt eher sagt, 
ja, es geht vielleicht gar nicht

255
00:12:43,960 --> 00:12:46,720
mehr möglichst schnell darum, 
mit diesen KI Agenten das zu 

256
00:12:46,720 --> 00:12:49,400
liefern, weil das passiert 
teilweise oder wäre möglich 

257
00:12:49,400 --> 00:12:52,400
innerhalb von wenigen Stunden, 
sondern es geht darum, auch 

258
00:12:52,400 --> 00:12:56,320
wirklich geprüften und 
qualitätsgesicherten Code und 

259
00:12:57,120 --> 00:13:00,640
entsprechend Funktionalitäten an
die Kunden auszuliefern. 

260
00:13:00,720 --> 00:13:04,800
Also die Grundidee, glaube ich, 
ist immer noch da, aber wir 

261
00:13:04,800 --> 00:13:07,520
haben natürlich viel kleinere 
Iterations. 

262
00:13:08,880 --> 00:13:12,360
Zyklen, in denen wir arbeiten. 
Und wir haben vor allen Dingen 

263
00:13:12,360 --> 00:13:15,200
nicht mehr dieses Development 
Team, was irgendwie 

264
00:13:15,200 --> 00:13:18,120
zusammensitzt mit dem einen 
Product Owner, der dann seinen 

265
00:13:18,120 --> 00:13:20,920
langen Backlog mitbringt und 
dann schaut man da rein und sagt

266
00:13:20,920 --> 00:13:24,960
okay was verteilen wir jetzt, 
sondern wir agieren als 

267
00:13:24,960 --> 00:13:29,080
Developer glaube ich immer mehr 
selber als Product owner wenn 

268
00:13:29,080 --> 00:13:31,600
man diese Terminologie hier 
übernehmen möchte. 

269
00:13:31,960 --> 00:13:34,480
Ja, vielleicht sind das dann 
eher so ein Tagessprints. 

270
00:13:34,480 --> 00:13:36,560
Dann was du gerade beschreibst, 
wenn du sagst, irgendwie morgens

271
00:13:36,560 --> 00:13:39,080
mache ich mir Gedanken, das will
ich heute umsetzen und dann muss

272
00:13:39,080 --> 00:13:41,600
ich eigentlich nur noch genug 
Zeit einplanen, dass ich das 

273
00:13:41,600 --> 00:13:44,240
eben reviewen kann, dass ich den
Agenten halt irgendwie zuspielen

274
00:13:44,240 --> 00:13:45,280
kann. 
Also ich merke auch so ein 

275
00:13:45,280 --> 00:13:48,480
bisschen, der Engpass verschiebt
sich eigentlich weg von der 

276
00:13:48,720 --> 00:13:51,360
reinen Umsetzung, weil das ja 
das, warum ich eigentlich vorher

277
00:13:51,360 --> 00:13:53,240
Sachen in längeren Sprints 
geplant habe, auch vielleicht 

278
00:13:53,240 --> 00:13:55,600
gesagt Okay dieses backlock 
Item, das kriegen wir jetzt hier

279
00:13:55,600 --> 00:13:58,640
nicht mehr umgesetzt, hinzu 
eigentlich. 

280
00:13:59,280 --> 00:14:03,000
Ja, mehr irgendwie. 
Priorisierung, vor allem Review,

281
00:14:03,000 --> 00:14:05,840
aber du hast auch gerade schon 
gesagt, Qualitätssicherung, also

282
00:14:06,080 --> 00:14:08,600
nicht mehr das Bauen von 
Software ist der Flaschenhals, 

283
00:14:08,600 --> 00:14:10,880
sondern eigentlich das 
Bereitstellen des richtigen 

284
00:14:10,880 --> 00:14:13,600
Kontextes, das Treffen von 
Entscheidungen, das 

285
00:14:13,600 --> 00:14:16,160
priorisieren, was ich wann in 
welcher Reihenfolge mache. 

286
00:14:16,160 --> 00:14:19,640
Ich muss eigentlich meine Review
Zeit jetzt managen und. 

287
00:14:19,720 --> 00:14:21,600
Und nicht mehr die Zeit, 
irgendwas zu bauen. 

288
00:14:21,600 --> 00:14:24,240
Also eigentlich muss ich mir 
Sachen einplanen in meinen 

289
00:14:24,240 --> 00:14:26,880
Kalender oder meine to do Liste 
oder einfach ein paar Stunden am

290
00:14:26,880 --> 00:14:29,840
Tag, idealerweise sogar verteilt
über den Tag, damit in der 

291
00:14:29,840 --> 00:14:32,800
Zwischenzeit wieder Agenten im 
Hintergrund arbeiten können, 

292
00:14:33,120 --> 00:14:35,440
muss ich mir eigentlich diese 
Review Zeit einbauen, wo ich 

293
00:14:35,440 --> 00:14:38,440
sage okay jetzt muss ich wieder 
ran und dieses wenn dann immer 

294
00:14:38,440 --> 00:14:41,640
es zu so einem human in The Loop
Effekt kommt, dann auch ich muss

295
00:14:41,640 --> 00:14:44,480
eigentlich eher dem Agenten zur 
Verfügung stehen und dadurch, 

296
00:14:44,480 --> 00:14:47,200
was ja gerade schon gesagt, gehe
ich ja eigentlich eher in diese 

297
00:14:47,200 --> 00:14:50,080
Product owner Rolle und. 
Und das finde ich eigentlich 

298
00:14:50,080 --> 00:14:52,360
ganz, ganz spannend, dass ich 
sage, ich bin in der Regel 

299
00:14:52,360 --> 00:14:56,320
langsamer als der Agent, der das
dann halt irgendwie coded und 

300
00:14:56,320 --> 00:14:59,920
deswegen mir bringt das auch gar
nicht so viel davon, wenn man 

301
00:14:59,920 --> 00:15:01,800
irgendwie dann immer hört, haben
ja auch viele in anderen News 

302
00:15:01,800 --> 00:15:03,920
folgen, das Ding kann jetzt 
irgendwie 24 Stunden lang Code 

303
00:15:03,920 --> 00:15:06,640
bauen, meine Realität sieht 
eigentlich immer so aus, dass 

304
00:15:06,640 --> 00:15:08,800
das Ding eigentlich schon früher
fertig ist, dass ich wieder Zeit

305
00:15:08,800 --> 00:15:11,480
habe, ein Review zu machen. 
Ja, und ich glaube, in der 

306
00:15:11,480 --> 00:15:14,800
Vergangenheit konnte ich als 
Product Owner, der irgendwie mit

307
00:15:14,800 --> 00:15:17,600
einem Deftteen gearbeitet hatte,
konnte ich in so einem Sprint 

308
00:15:17,840 --> 00:15:21,520
ganz gemütlich für den nächsten 
Sprint viel mehr User Stories 

309
00:15:21,520 --> 00:15:25,240
bauen, als das Team im nächsten 
Sprint überhaupt je hätte 

310
00:15:25,240 --> 00:15:27,920
implementieren können, weil ich 
konnte mich einfach hinsetzen 

311
00:15:27,920 --> 00:15:30,320
und hatte dann irgendwie 2 
Wochen Zeit, konnte Interviews 

312
00:15:30,320 --> 00:15:33,120
führen, konnte diese User 
Stories aufschreiben und mein 

313
00:15:33,120 --> 00:15:37,040
Backlog war immer länger als 
das, was wir hätten im nächsten 

314
00:15:37,120 --> 00:15:40,440
Sprint schippen können und jetzt
sieht es teilweise so aus, dass 

315
00:15:40,440 --> 00:15:43,320
die. 
Wenn wir in diesen alten Rollen 

316
00:15:43,320 --> 00:15:47,560
noch sind, dass wir dann eher 
den Bottleneck am Anfang haben, 

317
00:15:47,560 --> 00:15:50,160
nämlich vielleicht auf der 
Product Manager oder Product 

318
00:15:50,160 --> 00:15:54,200
owner Seite, dass diese Person 
gar nicht so schnell Sachen 

319
00:15:54,200 --> 00:15:56,240
nachliefern kann in der 
Qualität. 

320
00:15:56,320 --> 00:15:58,120
Schreiben kann. 
Genau das ist ja der Kontext 

321
00:15:58,120 --> 00:16:00,280
nachher. 
Ja, in der Qualität, die wir 

322
00:16:00,280 --> 00:16:04,000
brauchen, weil vielleicht 
Menschen sehr gut auch mit so 

323
00:16:04,000 --> 00:16:07,120
ein bisschen Unsicherheit, 
Unklarheit umgehen können, 

324
00:16:07,120 --> 00:16:10,080
wohingegen KI Agenten sehr 
klare. 

325
00:16:11,520 --> 00:16:14,720
Ja, product Requirements 
brauchen und wenn ich diese dann

326
00:16:14,720 --> 00:16:18,560
in dieser Qualität erarbeiten 
möchte, dann dauert das seine 

327
00:16:18,560 --> 00:16:21,520
Zeit und das dauert dann 
vielleicht länger als dann den 

328
00:16:21,520 --> 00:16:24,480
Coding Agenten dabei zuzuschauen
oder es im Hintergrund laufen zu

329
00:16:24,480 --> 00:16:27,120
lassen, wie sie dann dieses 
Feature zu implementieren. 

330
00:16:27,520 --> 00:16:29,680
Und dann habe ich wiederum diese
längere Phase. 

331
00:16:30,160 --> 00:16:32,960
Der Qualitätssicherung, wo ich 
sicherstellen möchte, wir hatten

332
00:16:32,960 --> 00:16:35,920
in der Vergangenheit mal in 
einer der News folgen erwähnt, 

333
00:16:35,920 --> 00:16:39,600
dass jetzt bei adable US auch 
wieder Menschen Senior Engineers

334
00:16:39,600 --> 00:16:41,880
auf den Code draufschauen 
müssen, der in Production 

335
00:16:41,880 --> 00:16:44,440
geshippt wird, weil es da zu 
Problemen kam. 

336
00:16:44,440 --> 00:16:47,200
Mit diesem ganzen Agent Code. 
Das heißt wir haben jetzt wieder

337
00:16:48,480 --> 00:16:52,080
an anderer Seite irgendwie eine 
Herausforderung, wo wir mit 

338
00:16:52,320 --> 00:16:55,480
Engpässen arbeiten müssen, aber 
dieser Engpass ist halt jetzt an

339
00:16:55,480 --> 00:16:57,800
einer anderen Stelle und 
dementsprechend funktioniert 

340
00:16:57,800 --> 00:17:01,200
halt dieser klassische. 
Prozess mit unseren Sprints und 

341
00:17:01,200 --> 00:17:03,600
Sprint plannings wie in der 
Vergangenheit einfach nicht mehr

342
00:17:03,600 --> 00:17:05,359
richtig. 
Ja, das ist auch der Grund, 

343
00:17:05,359 --> 00:17:07,720
warum dann so ticketsysteme 
vielleicht auch irgendwie JIRA 

344
00:17:07,720 --> 00:17:10,319
oder sowas heute gar nicht mehr 
so richtig zeitgemäß wirken. 

345
00:17:10,400 --> 00:17:12,440
Also irgendwie muss ich mir 
schon die Frage stellen, 

346
00:17:12,440 --> 00:17:14,880
vielleicht ist das Ticket auch 
einfach gar nicht mehr die 

347
00:17:14,880 --> 00:17:19,400
passende, ja, wie soll man das 
sagen, Einheit an Arbeit, die 

348
00:17:19,400 --> 00:17:21,359
ich dann halt irgendwie in einer
KI oder vielleicht sogar auch 

349
00:17:21,520 --> 00:17:23,040
immer mal wieder einem anderen 
Menschen übergebe. 

350
00:17:23,040 --> 00:17:25,760
Also ich glaube das Ticket an 
sich ist gar nicht so falsch, 

351
00:17:25,839 --> 00:17:28,560
zumindest der Inhalt davon, das 
ist ja dann doch auch irgendwie 

352
00:17:28,560 --> 00:17:31,200
der Grund. 
Kontext und irgendwie das Planen

353
00:17:31,200 --> 00:17:34,960
von Tickets in einem Sprint, der
dann aber erst in n paar Wochen 

354
00:17:34,960 --> 00:17:37,600
stattfindet oder das Nehmen von 
dem Ticket aus dem Backlock. 

355
00:17:37,600 --> 00:17:39,800
Ich glaub das ist falsch, ne. 
Also früher hatten wir so n 

356
00:17:39,800 --> 00:17:42,400
bisschen irgendwie n Mensch 
setzt n Ticket um. 

357
00:17:42,840 --> 00:17:47,120
Und heute kann eine Person ja 
auch Dinge parallel anstoßen und

358
00:17:47,120 --> 00:17:49,200
Arbeit wird viel weniger 
linearer. 

359
00:17:49,200 --> 00:17:52,320
Dass ich wirklich so ein Ticket 
nach dem anderen Abarbeite, 

360
00:17:52,560 --> 00:17:54,480
sondern wie gesagt, also 
Boddenberg ist eigentlich, dass 

361
00:17:54,480 --> 00:17:58,000
ich jetzt vorher mich hinsetzen 
muss und so viel, je mehr 

362
00:17:58,000 --> 00:18:01,280
Tickets ich ausformuliert 
bekomme, desto mehr Arbeit kann 

363
00:18:01,280 --> 00:18:04,600
ich parallelisieren, wenn die 
Arbeit sich parallelisieren 

364
00:18:04,600 --> 00:18:06,080
lässt. 
Das ist ja nicht, es ist ja 

365
00:18:06,080 --> 00:18:08,680
nicht immer der Fall, manche 
Dinge bedingen sich ja immer 

366
00:18:08,680 --> 00:18:11,280
noch irgendwie, aber. 
Aber das Ziel ist ja einfach 

367
00:18:11,280 --> 00:18:13,200
irgendwie nicht mehr die Arbeit 
zu planen. 

368
00:18:13,200 --> 00:18:17,200
Die Arbeit macht sich ja quasi 
von alleine, zumindest in einer 

369
00:18:17,200 --> 00:18:19,880
perfekten Welt oder vielleicht 
in ein paar Jahren dann, wenn 

370
00:18:19,880 --> 00:18:23,480
diese Karriergenten komplett 
autonom laufen und die Arbeit 

371
00:18:23,480 --> 00:18:26,120
ist es ja, also dass das ja 
nicht mehr das Ziel, sondern ich

372
00:18:26,120 --> 00:18:28,680
muss, ja, ich muss ja irgendwie,
habe ich eben gesagt, so ein 

373
00:18:28,680 --> 00:18:31,600
bisschen meine Review planen, 
und ich finde, dann steht mir 

374
00:18:31,600 --> 00:18:35,520
einfach so ein Prozess, auch, 
der vor allem ein Prozess, der 

375
00:18:35,520 --> 00:18:38,080
für Menschen gebaut wurde, total
oft im Weg. 

376
00:18:39,080 --> 00:18:41,000
Immer irgendwie so als. 
Also ich habe in meinem Kopf 

377
00:18:41,000 --> 00:18:44,120
irgendwie so gehabt, so ein 
ampelbeispiel stell dir vor, du 

378
00:18:44,120 --> 00:18:46,480
bist irgendwie in der perfekten 
Welt, auch so wie 2 Jahre in der

379
00:18:46,480 --> 00:18:47,960
Zukunft. 
Ki wäre vielleicht ein paar 

380
00:18:47,960 --> 00:18:51,600
Jahre in der Zukunft in unserer 
normalen Welt und was alle 

381
00:18:51,600 --> 00:18:53,800
selbst überall hast du 
selbstfahrende Autos, die 

382
00:18:53,800 --> 00:18:56,080
perfekt miteinander 
synchronisiert sind in so einer 

383
00:18:56,080 --> 00:18:59,080
perfekten Straßenwelt und dann 
warten die aber trotzdem an 

384
00:18:59,080 --> 00:19:01,120
einer roten Ampel, weil das halt
einfach irgendwie der Prozess 

385
00:19:01,120 --> 00:19:04,360
ist an einer menschenleeren 
Kreuzung und nur weil dieses 

386
00:19:04,360 --> 00:19:08,200
System der Ampeln mal für 
Menschen gebaut wurden und. 

387
00:19:08,240 --> 00:19:10,560
Und so ähnlich sehe ich dann 
auch irgendwie so KI Agenten, 

388
00:19:10,560 --> 00:19:14,240
die dann darauf warten, dass der
neue Sprint anfängt oder so was.

389
00:19:14,240 --> 00:19:16,360
Und wenn jetzt alle Autos 
miteinander reden und perfekt 

390
00:19:16,360 --> 00:19:18,720
synchronisiert sind, dann können
die auch alle mit maximaler 

391
00:19:18,720 --> 00:19:21,200
Geschwindigkeit fahren und das 
braucht eigentlich keine Ampeln 

392
00:19:21,200 --> 00:19:25,480
mehr und ja, wir müssen jetzt 
eigentlich als Menschen zurück 

393
00:19:25,480 --> 00:19:26,960
auf diese developer Welt 
eigentlich nur noch 

394
00:19:26,960 --> 00:19:30,080
sicherstellen, dass KI auch 
wirklich das richtige Business 

395
00:19:30,080 --> 00:19:32,960
Problem löst und sich nicht 
irgendwas zusammen halluziniert,

396
00:19:33,200 --> 00:19:35,120
also eigentlich eher dieses 
Stearing. 

397
00:19:35,520 --> 00:19:37,840
Zu machen und immer mal wieder 
drauf zu gucken, ob diese ganzen

398
00:19:37,840 --> 00:19:39,960
Autos noch in die richtige 
Richtung fahren und noch das 

399
00:19:39,960 --> 00:19:42,920
richtige Ziel haben, das ist 
jetzt eigentlich immer mehr 

400
00:19:42,920 --> 00:19:46,480
unsere Aufgabe und dafür braucht
es glaube ich kein Ticket mehr. 

401
00:19:46,880 --> 00:19:50,240
Ja, das ist halt die Frage, weil
Tickets haben ja verschiedene 

402
00:19:50,480 --> 00:19:54,640
Einsatzzwecke und du hast gerade
gesagt, es dient dazu, Arbeit zu

403
00:19:54,640 --> 00:19:58,800
planen, aber ich höre da schon 
die Einwände auch von einigen 

404
00:19:58,800 --> 00:20:02,240
meiner Kunden, die dann in 
irgendwelchen regulierten 

405
00:20:02,240 --> 00:20:04,400
Industrien arbeiten, die sagen 
ja, ich brauche aber diese 

406
00:20:04,400 --> 00:20:08,320
Tracability, das heißt, ich muss
ganz klar nachvollziehen können,

407
00:20:08,320 --> 00:20:10,320
was. 
Was ist die Anforderung? 

408
00:20:10,320 --> 00:20:13,840
Wie wurde das ganze Feature 
geplant und spezifiziert, an 

409
00:20:13,840 --> 00:20:16,440
welcher Stelle wurde es 
umgesetzt, wann kam es in den 

410
00:20:16,440 --> 00:20:20,560
Source Code rein, wie wurde es 
geprüft und wie und wann wurde 

411
00:20:20,560 --> 00:20:23,720
es entsprechend in laufende 
Software ausgeliefert und von 

412
00:20:23,720 --> 00:20:26,640
den Anwendern genutzt, damit 
wenn irgendwelche Fehler 

413
00:20:26,640 --> 00:20:28,760
auftreten. 
Ich rede jetzt hier über zum 

414
00:20:28,760 --> 00:20:31,920
Beispiel medizinische Systeme 
oder in der Automobilindustrie 

415
00:20:32,080 --> 00:20:36,960
damit halt immer ganz klar ist, 
wo hat wer was gemacht, wer hat 

416
00:20:36,960 --> 00:20:38,680
das an welcher Stelle 
freigegeben, was. 

417
00:20:38,880 --> 00:20:43,240
Damit, wenn Probleme auftreten, 
man auch die Ursachen ganz klar 

418
00:20:43,240 --> 00:20:45,280
definieren kann. 
Also ich glaube es gibt 

419
00:20:45,440 --> 00:20:49,840
weiterhin Use Cases, wo man 
solche Systeme braucht, aber 

420
00:20:49,840 --> 00:20:54,160
dann nicht mehr aus der 
Perspektive eines Systems, was 

421
00:20:54,160 --> 00:20:58,560
uns hilft irgendwie menschliche 
Arbeit zu koordinieren, sondern 

422
00:20:58,560 --> 00:21:01,200
vielleicht etwas viel 
einfacheres oder 

423
00:21:01,200 --> 00:21:03,680
leichtgewichtigeres, was einfach
im Hintergrund. 

424
00:21:03,960 --> 00:21:07,520
Solche Logs schreibt die es uns 
ermöglichen halt diese Sachen 

425
00:21:07,520 --> 00:21:10,720
quasi End zu Ende 
nachzuverfolgen. 

426
00:21:10,880 --> 00:21:12,520
Ja, okay würde ich, würde ich 
mitgehen. 

427
00:21:12,520 --> 00:21:14,240
Dann braucht es vielleicht doch 
irgendwie. 

428
00:21:14,400 --> 00:21:16,520
Ob das ein Ticket ist oder was 
auch immer, aber irgendwie so 

429
00:21:16,520 --> 00:21:20,960
eine Tracability von einem 
bestimmten Prozess oder sich 

430
00:21:20,960 --> 00:21:25,280
zumindest von Formulierung der 
Anforderungen bis hin zur zum 

431
00:21:25,280 --> 00:21:27,280
Shipping an den Kunden das 
irgendwie nachvollziehen kann. 

432
00:21:28,000 --> 00:21:29,640
Aber ich habe mir jetzt auch in 
Vorbereitung der Folge immer 

433
00:21:29,640 --> 00:21:32,560
wieder die Frage gestellt, wie 
muss denn ein System aussehen, 

434
00:21:32,880 --> 00:21:36,960
dass Agenten und agentische 
Programmierung in den 

435
00:21:36,960 --> 00:21:38,760
Vordergrund stellt, denn wir 
haben ja schon so ein bisschen 

436
00:21:38,760 --> 00:21:40,120
satt. 
Das Problem verschiebt sich, wir

437
00:21:40,120 --> 00:21:43,800
hatten ja eigentlich früher so 
ein bisschen, ich kenne das so 

438
00:21:43,800 --> 00:21:46,160
ein bisschen als dieses ganze 
def hops Ding aufkam. 

439
00:21:46,160 --> 00:21:49,120
Da wurde gesagt, wir haben, wir 
bekämpfen eine Deployment Wall, 

440
00:21:49,120 --> 00:21:52,800
also alles was dieses Def Hops 
Ding ja macht, ist dieses Works 

441
00:21:52,800 --> 00:21:56,240
on my Machine Problem zu lösen 
und heute haben wir das glaube 

442
00:21:56,240 --> 00:22:00,080
ich gelöst durch durch Docker 
Container, durch regelmäßige, 

443
00:22:00,080 --> 00:22:02,360
durch Continuous Deployment, 
durch Continuous Integration, 

444
00:22:02,360 --> 00:22:04,560
all diese Dinge. 
Und heute haben wir eher so eine

445
00:22:04,720 --> 00:22:06,520
Kontextwahl. 
Ich glaube, das haben wir schon 

446
00:22:06,520 --> 00:22:10,000
schon rausgearbeitet, diese, wir
nennt sich einfach mal trotzdem 

447
00:22:10,000 --> 00:22:12,480
weiter. 
Tickets müssen sehr gut 

448
00:22:12,480 --> 00:22:15,760
ausformuliert sein im Moment ja 
wirklich noch extrem gut, weil 

449
00:22:15,760 --> 00:22:20,920
sie ja der Hauptkontext sind für
diese KI Agenten und da kommen 

450
00:22:20,920 --> 00:22:23,040
wir schon zu so einem Punkt. 
Eigentlich brauche ich ein 

451
00:22:23,040 --> 00:22:25,440
System was diesen Kontext in den
Vordergrund stellt, also 

452
00:22:25,440 --> 00:22:28,560
eigentlich würde ich sagen aller
relevanter Kontext. 

453
00:22:29,600 --> 00:22:33,040
Muss entweder in diesem System 
dann sein, was für Agenten 

454
00:22:33,040 --> 00:22:36,640
optimiert ist oder zumindest aus
diesem System heraus erreichbar 

455
00:22:36,640 --> 00:22:39,640
sein. 
Also klar, dass da so Sachen 

456
00:22:39,640 --> 00:22:42,800
sind wie der Code, ich glaube 
das ist klar, ich glaube das 

457
00:22:42,800 --> 00:22:44,560
geht auch so ein bisschen die 
Richtung was der was das Thomas 

458
00:22:44,560 --> 00:22:47,600
Domke diese Ex git up sie oder 
mit seinem neuen Projekt vor 

459
00:22:47,600 --> 00:22:50,320
hat, das war ja auch glaube ich 
sehr um den Kontext herum 

460
00:22:50,560 --> 00:22:53,800
gebaut, aber ich finde dann es 
muss aber auch ein System sein 

461
00:22:53,800 --> 00:22:57,640
was zum Beispiel? 
Architecture, Decision Records 

462
00:22:57,640 --> 00:23:00,960
und so Strategic Direction 
Decisions abbildet. 

463
00:23:01,120 --> 00:23:05,120
Also warum haben wir wann welche
Entscheidungen getroffen, weil 

464
00:23:05,200 --> 00:23:07,440
ein Mensch kann sich daran 
erinnern, dass wir die 

465
00:23:07,440 --> 00:23:09,600
vielleicht, also im Idealfall, 
dass wir die mal getroffen 

466
00:23:09,600 --> 00:23:11,840
haben, und Agenten muss es 
vielleicht wissen, die müssen 

467
00:23:11,840 --> 00:23:14,360
dokumentiert sein, und da muss 
man auch nachvollziehen können, 

468
00:23:14,360 --> 00:23:17,560
warum wir das mal gemacht haben.
Da müssen, da müssen sowas wie 

469
00:23:17,560 --> 00:23:21,040
Spezifikationen für ne bestimmte
Aufgabe natürlich dann auch 

470
00:23:21,040 --> 00:23:22,560
hinterlegt sein. 
Das ist ja dann eigentlich fast 

471
00:23:22,560 --> 00:23:24,480
das, was vielleicht auch 
klassischerweise in so n Ticket 

472
00:23:24,480 --> 00:23:26,520
geht. 
Wir haben mal über Specdriven 

473
00:23:26,520 --> 00:23:29,200
Development gesprochen in Folge 
137. 

474
00:23:29,840 --> 00:23:32,080
Und ich glaube, da gibt es eine 
ganze Menge mehr Sachen, die 

475
00:23:32,080 --> 00:23:34,360
dann einfach wichtig für so 
einen Agenten sind, die in ein 

476
00:23:34,360 --> 00:23:37,360
System mit einfließen sollten. 
Also Kundenfeedback, Bug 

477
00:23:37,360 --> 00:23:41,440
Reports, irgendwelche internen 
Ideen oder Richtungen, in denen 

478
00:23:41,440 --> 00:23:42,960
sich das Produkt entwickeln 
soll. 

479
00:23:42,960 --> 00:23:46,800
Die Dokumentation ich habe jetzt
auch gelesen documentation is 

480
00:23:46,800 --> 00:23:49,240
the New Source Code, also 
eigentlich ist der Code mir 

481
00:23:49,240 --> 00:23:51,320
egal, der kann ihm Zweifel 
wegschmeißen und neu generieren 

482
00:23:51,320 --> 00:23:53,120
lassen, ich muss halt nur 
dokumentieren lassen, was er 

483
00:23:53,120 --> 00:23:56,520
eigentlich mal aussagen sollte 
oder was mein Ziel ist. 

484
00:23:57,280 --> 00:24:00,640
Das heißt, statt also eigentlich
ein System, was all diese Sachen

485
00:24:01,120 --> 00:24:05,600
zusammenhält, die nachher in den
Kontext hereinfließen, der für 

486
00:24:05,600 --> 00:24:07,520
so einen Agenten ist, nicht wenn
man Workshops auch immer sagt, 

487
00:24:07,520 --> 00:24:11,360
Kontext ist King und ich glaube,
dass das Ergebnis ist 

488
00:24:11,440 --> 00:24:14,880
substanziell besser, je besser 
und relevanter der Kontext für 

489
00:24:14,880 --> 00:24:16,800
so ein KI Agent ist. 
Deswegen ich habe noch gar kein 

490
00:24:16,800 --> 00:24:19,360
Bild vor Augen, wie das System 
aussehen soll, ich würde aber 

491
00:24:19,360 --> 00:24:23,000
sagen, ein System was sich um 
den Kontext herum entwickelt ist

492
00:24:23,000 --> 00:24:25,480
wahrscheinlich 1, was jetzt 
zumindest so für diese 

493
00:24:25,480 --> 00:24:29,840
agentische Welt. 
Ja, sinnvoller erscheint. 

494
00:24:29,960 --> 00:24:34,640
Ich glaube, da kommen wir dann 
einfach aus einem Prozess oder 

495
00:24:34,640 --> 00:24:37,680
aus einem System, was für 
Menschen gebaut ist, zu einem 

496
00:24:37,680 --> 00:24:40,800
technischen System. 
Also wir haben vorher über agile

497
00:24:40,800 --> 00:24:44,720
und Scrum gesprochen, was 
irgendwie ein System ist, um 

498
00:24:44,720 --> 00:24:47,920
halt Menschen zu koordinieren, 
die Miteinander an bestimmten 

499
00:24:47,920 --> 00:24:51,040
Dingen arbeiten, brauchen wir 
jetzt ein technisches System, 

500
00:24:51,200 --> 00:24:53,760
welches diese neue 
Implementierungswelt. 

501
00:24:54,360 --> 00:24:57,320
Koordiniert die entsprechende 
Informationen bereitstellt dort 

502
00:24:57,320 --> 00:24:59,880
gerade ganz viel über Kontext 
gesprochen und da können 

503
00:24:59,880 --> 00:25:03,600
natürlich auch die Software 
Systeme, die wir dafür in der 

504
00:25:03,600 --> 00:25:05,600
Vergangenheit genutzt haben, 
weiter eine Rolle spielen. 

505
00:25:05,600 --> 00:25:08,280
Als du gerade darüber gesprochen
hast und gesagt hast, ja, das 

506
00:25:08,280 --> 00:25:11,320
ist dann jetzt nicht in einem 
Ticket, weil das legt man 

507
00:25:11,320 --> 00:25:13,480
üblicherweise vielleicht nicht 
in JIRA ab, aber das legt man 

508
00:25:13,480 --> 00:25:16,520
vielleicht in einem Confluence 
ab, das heißt, diese Systeme 

509
00:25:16,520 --> 00:25:19,120
irgendwie JIRA Confluence, die 
jetzt von Eblassient kommen, 

510
00:25:19,120 --> 00:25:22,080
oder natürlich äquivalente 
Systeme von anderen Herstellern.

511
00:25:22,560 --> 00:25:26,000
Spielen vielleicht weiterhin 
eine Rolle, aber wir brauchen 

512
00:25:26,000 --> 00:25:29,200
jetzt dieses von dir 
beschriebene technische System, 

513
00:25:29,200 --> 00:25:33,280
welche diese Informationen just 
in Time zum richtigen Zeitpunkt 

514
00:25:33,280 --> 00:25:35,920
für diese 
Implementierungsagenten 

515
00:25:35,920 --> 00:25:38,240
verfügbar macht. 
Und da kommen dann natürlich 

516
00:25:38,240 --> 00:25:42,240
technische Themen wie MCP Server
und Tools rein, um halt diese 

517
00:25:42,240 --> 00:25:44,880
Informationen jederzeit 
verfügbar zu haben. 

518
00:25:44,880 --> 00:25:47,000
Da kommen solche Sachen wie 
irgendwie eine. 

519
00:25:47,400 --> 00:25:50,600
Eine Constitution, die ich in 
meinem Projekt Ablege oder so 

520
00:25:50,600 --> 00:25:55,280
ein Agents md file wo bestimmte 
Dinge drin stehen in Spiel. 

521
00:25:55,360 --> 00:25:58,200
Aber das ist dann dieses 
technische System was wir 

522
00:25:58,200 --> 00:26:03,120
aufbauen und was dann vielleicht
in Zukunft weit wichtiger wird 

523
00:26:03,360 --> 00:26:06,480
als dieses. 
Ja, Zwischenmenschliches System 

524
00:26:06,480 --> 00:26:08,320
oder dieser Prozess, den wir 
genutzt haben. 

525
00:26:08,720 --> 00:26:10,560
Ja, das stimmt. 
Und das muss ja auch sein, dass 

526
00:26:10,560 --> 00:26:13,840
das System ja trotzdem noch für 
Menschen funktioniert, denn es 

527
00:26:13,840 --> 00:26:16,480
gibt ja auch nach wie vor 
Aufgaben einfach, die zumindest 

528
00:26:16,480 --> 00:26:19,200
schon heute so ein KI Code Agent
gar nicht lösen kann. 

529
00:26:19,320 --> 00:26:22,000
Wo also Code haben, der von 
einem Menschen geschrieben sein 

530
00:26:22,000 --> 00:26:25,520
muss, vielleicht weil ich sage, 
ey, da geht es um die Payment 

531
00:26:25,520 --> 00:26:28,200
Prozesse, die hat hier keine KI 
anzufassen oder die KI kommt 

532
00:26:28,200 --> 00:26:30,880
einfach nicht weiter, das ist ja
auch schon heute immer noch in 

533
00:26:30,960 --> 00:26:33,520
vielen Fällen der Fall. 
Und ich brauche den Menschen 

534
00:26:33,520 --> 00:26:35,560
aber trotzdem, weil ich 
vielleicht Input von ihm 

535
00:26:35,560 --> 00:26:37,680
brauche, weil ich irgendwas 
eskalieren muss, weil ich mir 

536
00:26:37,680 --> 00:26:39,600
eine Proville für irgendwas 
abholen muss. 

537
00:26:40,000 --> 00:26:43,680
Also ich glaube, dass das System
schon beide Welten abdecken 

538
00:26:43,680 --> 00:26:45,760
können muss, aber natürlich 
berücksichtigen muss, dass auch 

539
00:26:45,760 --> 00:26:48,720
dieser Mensch in 99% der Fälle 
mit einer KI Unterstützung 

540
00:26:49,120 --> 00:26:52,480
arbeitet und trotzdem merke ich 
aber auch gerade auch, dass, wie

541
00:26:52,480 --> 00:26:54,400
du gesagt hast, ich eigentlich 
ein technisches System 

542
00:26:54,400 --> 00:26:56,880
beschreibe, anstatt einen 
Prozess, das heißt, ich glaube, 

543
00:26:56,880 --> 00:26:59,680
wir sind jetzt noch nicht näher 
daran, wie muss denn eigentlich 

544
00:26:59,680 --> 00:27:01,920
ein. 
Ja, der Prozess der Zukunft 

545
00:27:01,920 --> 00:27:03,760
aussehen oder brauchen wir den 
überhaupt noch oder reicht es 

546
00:27:03,760 --> 00:27:07,040
einfach zu sagen, gut, das sind 
die, also ich glaube so Features

547
00:27:07,200 --> 00:27:09,280
von muss ich ja trotzdem 
definieren, vielleicht auch 

548
00:27:09,280 --> 00:27:11,600
mache ich trotzdem irgendwie ein
paar Epics, beschreibe ich die 

549
00:27:11,600 --> 00:27:14,240
relevant und muss jetzt aber 
nicht mehr, dass irgendwelche 

550
00:27:14,240 --> 00:27:18,040
Tasks runterbrechen, die ich 
dann in Sprints zuordne, sondern

551
00:27:18,040 --> 00:27:22,160
vielleicht fahren wir einfach 
auf einer anderen Flughöhe und 

552
00:27:22,480 --> 00:27:26,160
geben, ja schmeißen diese diese 
Starre. 

553
00:27:26,880 --> 00:27:29,680
Aufteilung in Sprints halt weg, 
sondern sagen ich kann 

554
00:27:29,680 --> 00:27:32,800
theoretisch nach jedem Pull 
Request Merch deployen. 

555
00:27:32,800 --> 00:27:36,560
Also ich habe dieses Continuous 
Deployment Prinzip weiterhin, 

556
00:27:37,040 --> 00:27:39,560
braucht aber diese 
Planungskomponente nicht mehr, 

557
00:27:39,560 --> 00:27:41,560
weil die menschliche Zeit 
geplant hat, da bin ich mir 

558
00:27:41,560 --> 00:27:44,720
gerade noch irgendwie unsicher, 
in welche Richtung sich da der 

559
00:27:44,720 --> 00:27:47,280
Prozess entwickeln wird. 
Ja, ich denke, wir brauchen 

560
00:27:47,280 --> 00:27:51,200
weiterhin ein agiles Modell und 
wir brauchen ein agileres 

561
00:27:51,200 --> 00:27:53,680
Modell, vielleicht noch als in 
der Vergangenheit, weil wir halt

562
00:27:53,680 --> 00:27:55,840
in viel schnelleren Zyklen 
arbeiten. 

563
00:27:56,400 --> 00:27:59,120
Aber ich glaube, von dem, was 
wir auch gerade diskutiert 

564
00:27:59,120 --> 00:28:02,560
haben, gibt es halt ganz viele 
Dinge, die in diesem Scrum 

565
00:28:02,560 --> 00:28:05,280
Modell vielleicht so ein 
bisschen aus der Zeit gefallen 

566
00:28:05,280 --> 00:28:08,880
sind, weil dieses Scrum Modell 
natürlich sehr auf Menschen 

567
00:28:08,880 --> 00:28:12,800
zentriert ist und diese 
Zeremonien sehr darauf achten, 

568
00:28:12,880 --> 00:28:15,600
wie können wir die Arbeit 
zwischen Menschen koordinieren, 

569
00:28:15,600 --> 00:28:18,520
wie können wir auch unseren 
Prozess verbessern, wie können 

570
00:28:18,520 --> 00:28:21,440
wir das Feedback einsammeln in 
regelmäßigen. 

571
00:28:21,920 --> 00:28:26,320
Abständen und jetzt müssen wir 
weiterhin agil arbeiten, aber 

572
00:28:26,320 --> 00:28:29,520
wir können das nicht mehr in 
diesem starren Rahmen, den wir 

573
00:28:29,520 --> 00:28:32,400
im Rahmen von Scrum gelernt 
haben, tun. 

574
00:28:32,720 --> 00:28:35,760
Aber dennoch gibt es ja einige 
Dinge, die auch weiterhin 

575
00:28:35,760 --> 00:28:39,040
funktionieren, wenn wir jetzt 
mal über Scrum reden, wird 

576
00:28:39,040 --> 00:28:43,360
vielleicht die Rolle des Product
Owners oder in Zukunft der 

577
00:28:43,360 --> 00:28:48,480
Product owner umso wichtiger, 
weil natürlich wir viel 

578
00:28:48,480 --> 00:28:52,480
schneller Code schreiben können.
Und dann dementsprechend auf der

579
00:28:53,120 --> 00:28:58,320
Planungsseite viel mehr Zeit und
Energie investieren müssen, um 

580
00:28:58,560 --> 00:29:00,640
die ganzen Dinge entsprechend 
vorzubereiten. 

581
00:29:01,040 --> 00:29:02,680
Ja, ich glaube, für den 
Paragrawner ist das eine rosige 

582
00:29:02,680 --> 00:29:05,040
Zukunft. 
Also der muss ja, glaube ich, 

583
00:29:05,040 --> 00:29:07,360
heute dann viel mehr irgendwie, 
also der muss ja viel weniger, 

584
00:29:07,360 --> 00:29:10,920
sage ich mal, Tickets verwalten 
und mehr Richtung vorgeben, 

585
00:29:10,920 --> 00:29:13,840
Entscheidungen treffen, klar, 
der muss auch den Kontext 

586
00:29:13,840 --> 00:29:18,000
irgendwie sauber machen und so 
wie Ziele und Intention. 

587
00:29:18,480 --> 00:29:20,560
Viel klarer formulieren. 
Aber das ist ja, glaube ich, für

588
00:29:20,560 --> 00:29:22,680
alle eine gute Sache. 
Ich kenne viele Teams, die sich 

589
00:29:22,680 --> 00:29:25,800
das von ihren Producern 
wünschen, dass sie das sauberer 

590
00:29:25,800 --> 00:29:29,360
oder klarer formulieren und 
sowas, das heißt, ich glaube, da

591
00:29:29,360 --> 00:29:31,440
erinnert sich die Rolle schon 
auch eher so von so einem 

592
00:29:31,680 --> 00:29:35,280
Reinen, also was macht ein 
Producer heute, Anforderungen 

593
00:29:35,280 --> 00:29:38,880
schneiden, priorisieren, einen 
Backlog pflegen und sowas und 

594
00:29:38,880 --> 00:29:41,680
jetzt halt einfach viel, viel 
weniger so Ticketverwaltung, 

595
00:29:41,680 --> 00:29:43,760
sondern mehr so durch dieses 
Richtungsgebende. 

596
00:29:45,480 --> 00:29:47,680
Jetzt gibt es ja aber nicht nur 
den Product Owner, sondern auch 

597
00:29:47,680 --> 00:29:49,560
den Scrum Master. 
Das ist ja danach also ein 

598
00:29:49,560 --> 00:29:54,240
bisschen der Zeremonienmeister 
und da würde ich sagen, weiß ich

599
00:29:54,240 --> 00:29:56,480
gar nicht so, ob ich das noch 
brauche, ob ich jetzt irgendwie 

600
00:29:56,480 --> 00:29:58,400
noch, weil der muss ja 
eigentlich diesen Prozess 

601
00:29:58,400 --> 00:30:03,280
einhalten und während ich sage, 
die die konkreten Werte hinter 

602
00:30:03,280 --> 00:30:05,920
Scrum und Agile, die sind 
vielleicht relevanter denn je, 

603
00:30:06,320 --> 00:30:09,760
aber diese diese starre 
Einhaltung eines bestimmten 

604
00:30:09,760 --> 00:30:13,360
Prozesses, das wird ja 
vielleicht ausgeweicht 

605
00:30:13,360 --> 00:30:16,760
aufgeweicht, also. 
Also da weiß ich gar nicht, ob 

606
00:30:16,760 --> 00:30:19,320
es so einen Scrum Master in 
Zukunft überhaupt noch braucht. 

607
00:30:19,680 --> 00:30:23,120
Ich denke mal, wir brauchen 
weiterhin Menschen, die sich 

608
00:30:23,120 --> 00:30:27,840
damit beschäftigen, wie wir im 
Team gut zusammenarbeiten, wie 

609
00:30:27,840 --> 00:30:30,720
wir uns gut abstimmen und 
gemeinsam in die gleiche 

610
00:30:30,720 --> 00:30:33,440
Richtung arbeiten. 
Aber ob man dann tatsächlich 

611
00:30:33,440 --> 00:30:38,000
diese diese Rolle des Certified 
Scrum Masters noch braucht, der 

612
00:30:38,000 --> 00:30:41,440
sehr stark einfach diesen 
Prozess in Forst. 

613
00:30:42,000 --> 00:30:44,360
Das ist halt etwas, was man, 
glaube ich, ganz stark 

614
00:30:44,360 --> 00:30:47,360
hinterfragen kann, weil sobald 
wir halt aus diesem Scrum 

615
00:30:47,360 --> 00:30:51,600
Prozess ausbrechen, aus diesen 
regelmäßigen Terminen, die wir 

616
00:30:51,600 --> 00:30:56,120
da haben, aus den regelmäßigen 
Scrum Zyklen, die wir alle 2 

617
00:30:56,120 --> 00:30:59,040
Wochen in Form der Sprints 
haben, dann brauchen wir 

618
00:30:59,040 --> 00:31:02,040
vielleicht diesen Certified 
Scrum Master nicht mehr, aber 

619
00:31:02,040 --> 00:31:04,200
wir brauchen trotzdem vielleicht
jemanden mit der gleichen 

620
00:31:04,200 --> 00:31:07,200
Kompetenz, der den. 
Den Überblick über die 

621
00:31:07,200 --> 00:31:10,640
Organisation hat der Probleme 
adressiert, der Draufschaut. 

622
00:31:10,640 --> 00:31:13,520
Wo klemmt es gerade auch 
zwischenmenschlich, und dann 

623
00:31:13,680 --> 00:31:17,760
hilft, diese Probleme zu lösen, 
aber ich sehe das weniger als 

624
00:31:17,760 --> 00:31:20,880
Problem für die Menschen, die 
gerade als Scrum Master 

625
00:31:20,880 --> 00:31:23,800
arbeiten, sondern mehr für die 
Scrum Alliance, die vielleicht 

626
00:31:23,800 --> 00:31:25,680
auch über ihre Trainingspartner 
da jetzt ganz viel 

627
00:31:25,680 --> 00:31:28,960
Zertifizierung verteilt hat, wo 
ganz viel Geld mit Trainings 

628
00:31:28,960 --> 00:31:32,520
verdient wurde und ich glaube, 
dass die mehr Probleme kriegen 

629
00:31:32,520 --> 00:31:35,920
als die Leute selber, weil ich 
glaube in Zukunft haben die 

630
00:31:35,920 --> 00:31:38,640
Leute ja. 
Einen fast noch sichereren Job, 

631
00:31:38,640 --> 00:31:42,000
die gut mit Menschen arbeiten 
können als diejenigen, die nur 

632
00:31:42,000 --> 00:31:44,960
die Technik beherrschen. 
Obwohl klar, ich will jetzt 

633
00:31:44,960 --> 00:31:47,920
nicht sagen, dass Entwickler nur
die Technik beherrschen, aber 

634
00:31:47,920 --> 00:31:51,840
für das Entwicklerteam ändert 
sich natürlich auch was, aber 

635
00:31:51,840 --> 00:31:53,840
eigentlich auch die Sachen, die 
wir eigentlich auch hier diesem 

636
00:31:53,840 --> 00:31:56,000
Podcast schon zu Haufe 
besprochen haben. 

637
00:31:56,080 --> 00:32:00,160
Also früher haben wir gesagt, 
war also die Umsetzungskapazität

638
00:32:00,240 --> 00:32:03,760
knapp. 
Und das Wissen über die Syntax, 

639
00:32:03,760 --> 00:32:07,560
über das Framework und so was. 
Das war zentral und heute, das 

640
00:32:07,560 --> 00:32:09,680
haben wir schon öfter gesagt, 
entwickelt sich die Rolle von so

641
00:32:09,680 --> 00:32:13,280
einem Software Developer viel 
mehr auf einen Fokus hin, auf 

642
00:32:13,280 --> 00:32:16,800
Reviews natürlich, aber auch auf
Architektur, auf das 

643
00:32:16,800 --> 00:32:20,560
Systemdenken, auf eine 
Qualitätsbewertung, also viel 

644
00:32:20,720 --> 00:32:23,400
weniger auf reine 
Codeproduktion, sondern vielmehr

645
00:32:23,400 --> 00:32:27,000
auf Verantwortung für eine 
Entscheidung, für eine 

646
00:32:27,000 --> 00:32:29,680
Architektur. 
Und natürlich dann am Ende auch 

647
00:32:29,680 --> 00:32:33,280
das Stearing und das Reviewen 
von den Dingen, die vielleicht 

648
00:32:33,280 --> 00:32:37,040
eine KI macht, mit Sicherheit 
auch noch zu einem großen Teil 

649
00:32:37,040 --> 00:32:41,040
der Zeit das selber Coden an 
einigen Stellen, wo er mit Dki 

650
00:32:41,040 --> 00:32:44,320
gar nicht ran soll oder nicht 
weiter kommt, aber da muss man 

651
00:32:44,320 --> 00:32:45,880
schon sagen, das wird 
wahrscheinlich mit Blick auf die

652
00:32:45,880 --> 00:32:48,080
Zukunft doch eher weniger und 
trotzdem brauche ich aber 

653
00:32:48,080 --> 00:32:50,400
jemanden, der das oben drüber so
ein bisschen überwacht, weil ich

654
00:32:50,400 --> 00:32:54,240
glaube ist der klassische 
Develop Hope trotzdem extrem 

655
00:32:54,240 --> 00:32:57,600
viel mit Code arbeiten. 
Aber vielleicht auch eher so. 

656
00:32:57,600 --> 00:33:01,680
Diese Armee der Agents 
Orchestrieren und immer mal 

657
00:33:01,680 --> 00:33:04,720
wieder reviewen und in die 
richtige Richtung schubsen. 

658
00:33:05,200 --> 00:33:08,600
Das heißt, wir merken schon so, 
das Team bleibt weiterhin, was 

659
00:33:08,600 --> 00:33:11,440
es vielleicht auch heute 
irgendwie gibt, auch in diversen

660
00:33:11,440 --> 00:33:14,560
Rollen und da gibt es natürlich 
dann auch noch den, den den 

661
00:33:14,560 --> 00:33:17,520
Product Manager am Ende, der 
haben jetzt gar nicht 

662
00:33:17,520 --> 00:33:20,560
beleuchtet, aber. 
Aber der Prozess wird sich 

663
00:33:20,560 --> 00:33:23,120
ändern. 
Ich glaube, zusammenfassend kann

664
00:33:23,120 --> 00:33:27,680
man sagen, dass wir weiterhin in
einem sehr agilen System agilen 

665
00:33:27,680 --> 00:33:31,120
Umfeld arbeiten und agile 
Softwareentwicklung hat die 

666
00:33:31,120 --> 00:33:33,680
Softwareentwicklungswelt massiv 
nach vorne gebracht. 

667
00:33:33,680 --> 00:33:36,640
Auch Scrum hat einen ganz 
wichtigen Beitrag dazu 

668
00:33:36,640 --> 00:33:39,440
geleistet. 
Aber ich glaube, es ist dieser 

669
00:33:39,440 --> 00:33:44,240
Scrum Aspekt mit seinen festen 
Prozessen und Zeremonien, der 

670
00:33:44,240 --> 00:33:47,360
sich immer mehr auflösen wird, 
weil wir einfach so eine 

671
00:33:47,360 --> 00:33:50,440
disruptive Veränderung in der 
Art und Weise sehen, wie wir 

672
00:33:50,440 --> 00:33:54,480
Software entwickeln, dass es 
zwar weiterhin agil sein wird, 

673
00:33:54,480 --> 00:33:57,520
aber nicht in dieser starren 
Form, wie wir es bisher gesehen 

674
00:33:57,520 --> 00:33:58,960
haben. 
Ja, und auch wichtig für das 

675
00:33:58,960 --> 00:34:00,840
Fazit wäre mir nochmal zu sagen,
wir haben ja gemerkt so 

676
00:34:00,840 --> 00:34:03,600
irgendwie diese so viele von 
diesen alten Mechaniken, die 

677
00:34:03,600 --> 00:34:06,320
wirken plötzlich schwerfällig 
oder künstlich in so einer Welt,

678
00:34:06,320 --> 00:34:09,360
wo einfach. 
Ja, das Bottle Neck nicht mehr 

679
00:34:09,360 --> 00:34:13,600
ist Zeit dafür zu planen, dass 
man Code schreibt und KI 

680
00:34:13,600 --> 00:34:15,400
verändert einfach gerade das 
Verhältnis. 

681
00:34:15,400 --> 00:34:16,360
Das finde ich glaube ich ganz 
gut. 

682
00:34:16,360 --> 00:34:21,199
Das Verhältnis von Planung, 
Umsetzung und nachher dann 

683
00:34:21,199 --> 00:34:26,800
Qualitätskontrolle so was wie 
wie Reviews und genau das Ziel 

684
00:34:26,800 --> 00:34:29,360
ist einfach nicht mehr die 
Arbeit zu planen, die Arbeit 

685
00:34:29,360 --> 00:34:31,920
macht sich von alleine, sondern 
halt diese Planung. 

686
00:34:32,520 --> 00:34:36,400
Planung vorher zu machen und das
Runterschreiben von den 

687
00:34:36,400 --> 00:34:38,960
Requirements und nachher das 
Ergebnis zu kontrollieren. 

688
00:34:39,199 --> 00:34:43,760
Ja, und wenn du jetzt diese, ja 
kontroverse These noch mal quasi

689
00:34:43,760 --> 00:34:47,440
hinterfragst, die wir am Anfang 
hatten, ist agile tot. 

690
00:34:47,679 --> 00:34:51,199
Dann kann man glaube ich sagen 
Nein, agile ist nicht tot, aber 

691
00:34:51,199 --> 00:34:54,840
wenn man agile gleich Scrum 
gesetzt hat, wie es viele in den

692
00:34:54,840 --> 00:34:59,680
letzten 20 Jahren gemacht haben,
dann vielleicht schon, weil es 

693
00:34:59,680 --> 00:35:00,720
war. 
Nicht tot. 

694
00:35:02,640 --> 00:35:04,760
Das Auge jetzt nicht 
existentarisch ist, das habe ich

695
00:35:04,760 --> 00:35:08,760
jetzt nicht gesagt. 
Aber ich denke mal, scrum wird 

696
00:35:08,760 --> 00:35:13,160
sich entweder massiv verändern 
müssen oder es wird nach und 

697
00:35:13,160 --> 00:35:15,920
nach immer weniger relevant 
sein, weil immer mehr 

698
00:35:15,920 --> 00:35:19,280
Unternehmen natürlich ihre 
Softwareentwicklungsprozesse an 

699
00:35:19,280 --> 00:35:23,320
diese neue Welt der agentischen 
Softwareentwicklung anpassen und

700
00:35:23,320 --> 00:35:24,960
umstellen werden. 
Ja, das ist doch schön. 

701
00:35:24,960 --> 00:35:26,960
Die Zukunft gehört auf jeden 
Fall nicht den Teams, die am 

702
00:35:26,960 --> 00:35:29,200
diszipliniertesten Tickets 
verwalten. 

703
00:35:29,560 --> 00:35:32,200
Sondern eher denen, die die 
einfach guten Kontext schaffen. 

704
00:35:32,200 --> 00:35:33,920
Das hatte ich ja gerade so ein 
bisschen in dieses System, was 

705
00:35:33,920 --> 00:35:35,760
sich ein bisschen in meinem Kopf
da irgendwie schwört, es geht ja

706
00:35:35,760 --> 00:35:38,680
um diesen, also guten Kontext 
schaffen, schnell Entscheidungen

707
00:35:38,680 --> 00:35:42,480
treffen können, glaube ich 
trotzdem Qualität sichern, also 

708
00:35:42,480 --> 00:35:45,120
trotzdem dafür sorgen, dass 
nicht, wie Adaws jetzt gesagt 

709
00:35:45,120 --> 00:35:48,960
hat, oh, wir haben so viel 
bloatwear und so viel 

710
00:35:48,960 --> 00:35:51,120
Gewipecoded, ein Quatsch, da 
irgendwie drin, jetzt müssen wir

711
00:35:51,360 --> 00:35:53,720
doch wieder Seniors alles 
reviewen lassen, die. 

712
00:35:53,720 --> 00:35:56,120
Die Verantwortung übernehmen und
die vor allem auch irgendwie mit

713
00:35:56,120 --> 00:35:58,480
dieser also die, die dann 
schneller wieder Review geben, 

714
00:35:58,480 --> 00:36:00,160
die sie stieren können, die 
einfach mit dieser neuen 

715
00:36:00,160 --> 00:36:04,080
Geschwindigkeit sinnvoll umgehen
und am Ende des Tages, da auch 

716
00:36:04,320 --> 00:36:07,120
ihre Prozesse und vielleicht 
sogar methodiken drauf anpassen.

717
00:36:07,120 --> 00:36:10,360
Also vielleicht braucht es 
einfach neue Prozesse, neue 

718
00:36:10,360 --> 00:36:15,360
Tools, neue Methodiken für diese
angepasste Welt und keine ganz 

719
00:36:15,360 --> 00:36:17,920
ganz, ganz starre 
Ticketdisziplin mehr. 

720
00:36:18,360 --> 00:36:21,120
Sondern einfach was, was dieser 
neuen Geschwindigkeit, dieser 

721
00:36:21,120 --> 00:36:24,480
neuen Loop, dieser neuen 
Developer Loop, von denen man ja

722
00:36:24,480 --> 00:36:26,560
wie schon mal in diesem Devox 
Complet spricht, diese inner und

723
00:36:26,560 --> 00:36:29,440
außer Loop, die darauf angepasst
ist, weil die hat sich einfach 

724
00:36:29,440 --> 00:36:31,760
massiv verändert und vor allem 
massiv beschleunigt. 

725
00:36:31,920 --> 00:36:35,120
Ja, und am Ende verändert sich 
die Welt aktuell so schnell, 

726
00:36:35,120 --> 00:36:39,280
dass wenn du jetzt sagst, okay, 
wie schnell ist so eine 

727
00:36:39,280 --> 00:36:42,640
Implementierung, dann kann diese
Antwort in 2 Wochen anders 

728
00:36:42,640 --> 00:36:44,920
aussehen. 
Ich glaube viel wichtiger ist es

729
00:36:44,920 --> 00:36:48,160
diese. 
Neuen Phasen, die jetzt wichtig 

730
00:36:48,160 --> 00:36:51,200
werden, viel besser zu planen. 
Also wieviel brauche ich 

731
00:36:51,200 --> 00:36:53,920
wirklich für diese 
spezifizierungsphase und wieviel

732
00:36:53,920 --> 00:36:56,320
Zeit brauche ich am Ende für die
Qualitätssicherung? 

733
00:36:56,560 --> 00:37:00,320
Und vielleicht entwickelt sich 
daraus am Ende ein neues agiles 

734
00:37:00,320 --> 00:37:03,400
Modell, wo man dann 
zusammensitzt und sagt, Hey, wir

735
00:37:03,400 --> 00:37:05,920
haben folgende Dinge, die wir 
jetzt irgendwie erledigen 

736
00:37:05,920 --> 00:37:09,240
wollen, heute morgen in den 
nächsten Tagen, aber wie lange 

737
00:37:09,240 --> 00:37:13,600
wird dich das Kosten, um am Ende
das Ganze zu reviewen, bevor wir

738
00:37:13,600 --> 00:37:16,960
es shippen können, weil am Ende.
Ist es für mich ja vielleicht 

739
00:37:16,960 --> 00:37:20,000
als Product Ordner immer noch 
relevant zu wissen, wann ist das

740
00:37:20,000 --> 00:37:23,120
Feature bei meinen Kunden und 
wenn das Bottleneck am Ende dann

741
00:37:23,120 --> 00:37:26,280
deine Review Zeit ist, musst du 
das vielleicht genauso vorkasten

742
00:37:26,280 --> 00:37:28,560
wie du in der Vergangenheit 
deine Implementierungszeit 

743
00:37:28,560 --> 00:37:30,720
geplant hast. 
Und vorher auch die Zeit 

744
00:37:30,720 --> 00:37:33,160
einzuplanen, natürlich das gut 
zu beschreiben, auch vielleicht 

745
00:37:33,160 --> 00:37:35,080
in der Tiefe, in der ich einen 
Menschen nicht hätte beschreiben

746
00:37:35,080 --> 00:37:37,760
müssen. 
Ich glaube, ihr seht schon hier,

747
00:37:37,760 --> 00:37:39,400
wir sagen ganz, ganz viel 
vielleicht, das war jetzt noch 

748
00:37:39,400 --> 00:37:42,080
eine sehr philosophische Folge, 
deswegen interessiert uns 

749
00:37:42,080 --> 00:37:45,080
wahnsinnig, was ist denn eure 
Meinung dazu, ich möchte schon, 

750
00:37:45,080 --> 00:37:47,320
wir kommen ja auch gar nicht zu 
einem, wir haben jetzt auch 

751
00:37:47,320 --> 00:37:49,800
nicht die Weißheit mit Löffeln 
gefressen und kommen jetzt hier 

752
00:37:49,800 --> 00:37:51,920
gar nicht zu dem neuen Modell, 
ich glaube das wird sich noch 

753
00:37:51,920 --> 00:37:55,520
über die nächsten Jahre formen, 
aber wenn ihr schon was gefunden

754
00:37:55,520 --> 00:37:57,880
habt, was sehr gut für euch 
funktioniert oder wo ihr gesagt 

755
00:37:57,880 --> 00:38:01,280
habt, ey, wir haben unsere 
Methodiken angepasst auf diese 

756
00:38:01,280 --> 00:38:04,040
neue Realität und das 
funktioniert für uns gut und. 

757
00:38:04,040 --> 00:38:05,840
Oder ihr habt vielleicht was 
angepasst und es war eine 

758
00:38:05,840 --> 00:38:07,560
Katastrophe und ihr seid wieder 
zurückgegangen. 

759
00:38:07,560 --> 00:38:10,000
Zu dem Scrum Modell. 
Dann lasst uns das gerne wissen.

760
00:38:10,000 --> 00:38:13,440
Bei dieser Folge sind wir mehr 
als je zuvor darauf gespannt, 

761
00:38:13,600 --> 00:38:16,400
was ihr denn eigentlich dazu 
sagt und was eure Erfahrungen 

762
00:38:16,400 --> 00:38:18,000
dazu sind oder was vielleicht 
auch einfach die Meinung sind, 

763
00:38:18,000 --> 00:38:20,480
die in eure Köpfe kommen, wenn 
ihr uns 2 jetzt hier eine halbe 

764
00:38:20,480 --> 00:38:22,080
Stunde lang zugehört habt, wie 
ihr über das Thema 

765
00:38:22,080 --> 00:38:26,360
philosophieren, von daher lasst 
uns gerne Kommentare da, wenn 

766
00:38:26,360 --> 00:38:29,200
ihr uns auf Spotify oder Youtube
hört, dann gibt es da eine 

767
00:38:29,200 --> 00:38:32,480
Kommentarsektion, wir freuen uns
aber auch ganz ganz doll über e 

768
00:38:32,480 --> 00:38:34,080
Mails. 
Dann können wir das Thema 

769
00:38:34,080 --> 00:38:35,640
vielleicht auch in einer der 
kommenden Folgen noch mal 

770
00:38:35,640 --> 00:38:38,560
aufgreifen. 
Gemeinsamer mit Euren, mit eurem

771
00:38:38,560 --> 00:38:41,440
Input und den einfließen lassen.
Und wenn euch diese Folge 

772
00:38:41,440 --> 00:38:44,600
gefallen hat und es euch weiter 
gebracht hat, uns beim 

773
00:38:44,600 --> 00:38:47,440
Philosophieren zuzuhören, dann 
lasst uns auch gerne eine 

774
00:38:47,440 --> 00:38:51,360
positive Bewertung auf Apple 
Podcast oder Spotify da. 

775
00:38:51,600 --> 00:38:54,400
Das hilft uns auch von anderen 
gefunden zu werden. 

776
00:38:54,480 --> 00:38:56,320
Wir freuen uns auch immer, wenn 
ihr uns einen Kaffee ausgeben 

777
00:38:56,320 --> 00:38:58,160
wollt, dann findet ihr einen 
Link zu bei mir Coffee in den 

778
00:38:58,160 --> 00:39:00,640
Shownotes oder wenn ihr zu eurem
eigenen Kaffee die perfekte 

779
00:39:00,800 --> 00:39:03,240
Gebrandete Nerd Tasse haben 
wollt, auch da. 

780
00:39:03,320 --> 00:39:06,320
Da gibt es die Links zu unserem 
kleinen Shop und ansonsten hören

781
00:39:06,320 --> 00:39:08,920
wir uns nächste Woche wieder, 
denn der To do Cast erscheint 

782
00:39:08,920 --> 00:39:12,160
jeden Montag immer abwechselnd 
mit einer Themenfolge wie dieser

783
00:39:12,160 --> 00:39:15,040
hier und einer News Folge, wo 
wir die Tech Developer und KI 

784
00:39:15,040 --> 00:39:16,880
News der letzten 2 Wochen 
zusammenfassen. 

785
00:39:17,200 --> 00:39:19,120
Hört also wieder rein abonniert,
wenn ihr es noch nicht gemacht 

786
00:39:19,120 --> 00:39:22,640
habt und wir hören uns nächste 
Woche, bis dahin habt eine gute 

787
00:39:22,640 --> 00:39:24,640
Zeit und schreibt ganz viel 
Code. 

788
00:39:25,200 --> 00:39:25,680
Bis dahin.