Agile und Scrum haben einst die Softwareentwicklung
revolutioniert, mit Fokus auf Menschen, Prozesse, schnelle
Iterationen und vor allem funktionierende Software.
Doch heute drückt KI mit ungeahnter Geschwindigkeit aufs
Gas und Agenten erledigen Arbeit blitzschnell und Sprints wirken
irgendwie schleppend und Tickets verlieren immer mehr an
Bedeutung und menschliches Review wird plötzlich zum
Bottleneck. In dieser Folge stellen wir uns
die Frage. Sind Scrum und JIRA in Zeiten
von KI überhaupt noch zeitgemäß? Und damit Hallo und herzlich
Willkommen zu einer neuen Folge des To do Developer Podcasts,
eurem deutschsprachigen Developer Podcast.
Überall, wo es Podcasts gibt und ihr hört wieder Robin Manuel
Thiel gerade im Intro. Er ist Director AI und Cloud
beim E Commerce Softwareunternehmen Jtl und ich
bin malte Lantin ich bin Solutions Engineer bei github,
den Podcast machen wir aber privat und in unserer Freizeit
und sprechen einmal abwechselnd über ein Thema wie heute oder
auch in Alternativen. In der Reihenfolge in der
nächsten Woche wieder über die aktuellen Tag und Developer
News. Aber heute haben wir uns ein
ganz spannendes Thema rausgesucht beziehungsweise du
hast das mitgebracht, weil du einen ganz interessanten
Blogspot gesehen hast. Auch wenn du im Intro über JIRA
gesprochen hast. Die Inspiration kam von Ninea,
die machen aber auch Planning und Tracking, von daher hängt
das sehr eng zusammen, aber ich glaube, in unserer Welt ist JIRA
immer noch das Tracking Tool der Wahl, von daher passt der
Aufhänger aber bevor wir. Da in die Details gehen, müssen
wir uns natürlich auch wieder bei euch bedanken.
Ja. Ich bin erstmal noch ganz baff
von einer alternierenden Reihenfolge hier.
Man merkt, der Malta hat studiert, viel wichtiger als zu
studieren ist in der Soft Entwicklung aber mit Koffein
ausgestattet zu sein und bevor wir ins Thema einsteigen, sagen
wir noch ganz schnell danke an euch, die Community, ihr habt
uns nämlich wieder Kaffee ausgegeben und zwar haben wir 3
Kaffee von Noemi bekommen, einen Kaffee vom Thomas bekommen und.
Uns 6 Kaffee von Suffian ganz, ganz lieben Dank.
Vielen Dank dafür. Und wenn auch ihr uns einen
Kaffee ausgeben wollt, findet ihr den Link zu bei mir
coffee.com in den Shownotes. Da freuen wir uns immer
tierisch, wenn wir hier unseren Koffeinvorrat auffüllen können.
Ja, steigen wir mal ein und du hast ja schon gesagt, so ein
bisschen das Thema und der Aufhänger war eigentlich ein
Blogspot von. Ich glaube, er heißt Carrie
Sarien. Das ist der CEO von linear und
der hat so ein bisschen geschrieben.
Issue tracking is that also issue Tracking ist tot und hat
gesagt, das ist eigentlich für eine alte Welt gebaut, das ist
ein eigenes Modell und wir hatten ja auch so ein bisschen
irgendwie gesagt, so agile ist tot und ich fand es ganz witzig,
du hast mir so direkt direkt zurückgeschrieben, klingt
eigentlich wie eine typische linkedin Provokation, ich würde
aber sagen aber. Ich jetzt mal ganz ehrlich
irgendwie, wenn wenn KI auf einmal so in Stunden Dinge baut,
die früher Teams über 23 Sprints gebaut haben, da muss man sich
ja schon fragen, was ist denn eigentlich noch ein Sprint wert
und warum sollte ich denn vielleicht auch künstlichen KI
Agenten warten lassen? Bis der nächste Sprint anfängt,
weil der ja eigentlich schon fertig wäre, kann ich überhaupt
noch einschätzen, wie lange eine KI für irgendein Sprint braucht.
Ist also vielleicht auch das ganze ja strump pokern und so
was tot und darüber sprechen wir diese Folge ein bisschen.
Ja, und das ganze auch vor dem Hintergrund, dass ja in der
Vergangenheit wir immer irgendwie mehr.
Aufgaben zu erledigen hatten. Als wir developer Zeit hatten,
weil natürlich das immer der limitierende Faktor war, also
wie viele Developer haben wir, die wie schnell die Dinge
implementieren können. Das heißt, wir brauchten
irgendwie ein Modell, wie wir das Ganze in eine Reihenfolge
bringen, wie wir das Ganze sinnvoll abarbeiten und
möglichst schnell zu sichtbaren Ergebnissen kommen und nicht wie
irgendwo in. Grauer Vorteil in irgendwelchen
ewigen Planungsprozessen. In meinem Wasserfallmodell
hängen zu bleiben und dann vielleicht irgendwie ein Jahr
später völlig am Kunden vorbei geplant zu haben, sondern ganz
schnell zu etwas sichtbarem zu kommen.
Und wenn man ganz schnell zu etwas sichtbarem kommt, dann
erinnert das natürlich an die Dinge, die wir heute mit den KI
Agenten tagtäglich tun und die uns immer wieder vor Augen
führen, dass das. Das Schreiben von Code jetzt
nicht mehr so der Bottelnag ist, sondern tatsächlich die Dinge
ordentlich zu erarbeiten, die man implementieren möchte, also
eigentlich die Zielsetzung der Software.
Und wir brauchen vielleicht gar nicht mehr dieses klassische
Tracking, wo wir irgendwo als pm diesen ganz langen Backblock
haben und dann eigentlich irgendwie einen Mechanismus
brauchen, um diese Arbeit dann an die Engineers zu übergeben,
die dann damit weiterarbeiten. Sondern wir brauchen etwas,
vielleicht was anderes, etwas Neues, was jetzt in dieser
neuen, agentischen Arbeitsweise vielleicht viel besser
funktioniert als das, was wir in der Vergangenheit gemacht haben.
Du hattest ja gerade gesagt in 2 Wochen, wieso ein üblicher
Sprint ist. Da kann man natürlich heutzutage
ungeheuer viel machen, es gibt ja sogar Leute, die behaupten,
sie hätten mal eben irgendwie auf einem Inlandsflug mal ein
komplettes Feature implementiert, was ich so ein
bisschen für fragwürdig halte. Aber ich glaube, in die Richtung
wird ja mittlerweile viel argumentiert.
Muss der Inlandsflug aber noch Internet haben, weil die lokal
laufenden Modelle, glaube ich da zumindest noch nicht so ganz
probiere sie auch immer wieder aus, aber richtig überzeugt beim
Coding haben die mich noch nicht, aber das ist ein anderes
Thema. Wir wissen aber auch, dass das
ein Thema ist, was wahrscheinlich auch viele
Emotionen irgendwie hochbringen wird, deswegen können wir jetzt
ja schon mal ankündigen, wir sind wahnsinnig gespannt, wie
ihr das am Ende seht, also schreibt uns eure Meinung auch
gerne schon mal in die Kommentare oder auch am Ende der
Folge, wenn ihr eine andere Sicht hat, das interessiert uns
sehr, denn. Agile und Scrum, das sind ja
quasi schon so physikalische Gesetze geworden, wie Software
gebaut wird und vor allem so seit dieser Dev OPS Revolution
so um die 2010 er Jahre rum. Aber nicht nur der der linear
CEO scheint das so zu sehen, der hat ja also Einsatz vor allem
diesem blogspot irgendwie ein bisschen hängen geblieben, der
hat gesagt, hier diese Zeremonie, die.
Die man ja eigentlich auch in so einem richtigen Scrum
durchläuft. Die kommt halt daher, dass man
damals echte Einschränkungen hatte und vor allem mal diese
Engineering Time, das war so ein bisschen der limitierende Faktor
und Teams mussten sie quasi sich ganz vorsichtig zwischen diesen
Rollen und Funktionen bewegen, die man eben in diesem diesem
Scrum hat. Aber muss ja auch dazu sagen.
Auch Thomas Domke zum Beispiel, der ehemalige CEO von github,
der hat ja auch für sein neues Projekt irgendwie erkannt, dass
der Status Quo, den wir heute haben, nicht unbedingt der
Idealzustand ist. Wenn wir mal so Agent First,
würde ich das Mal nennen, denken.
Ja, und das Interessante ist ja, dass gerade im Moment immer
noch. Ganz viele in diesen agilen
Prozessen arbeiten Scrum Zeremonien, machen aber die
Technologie sich ja ungeheuer schnell weiterentwickelt hat.
Das heißt, die Technologie, die wir einsetzen, hat sich
schneller weiterentwickelt als unsere Prozesse, das ist ja
häufig so. Und ich glaube, jetzt beginnen
viele Organisationen darüber nachzudenken, die Prozesse
nachzuziehen, nachdem irgendwie schon dreiviertel der
Unternehmen irgendwelche Software Engineering Agents
haben und diese auch schon aktiv einsetzen und damit merken, dass
sie immer mehr Code produzieren in immer kürzerer Zeit und jetzt
dann darüber nachdenken, haben wir dafür überhaupt noch den
richtigen Prozess? Ja, malte du als zertifizierter
Product Owner und du kennst dich ja mit Scrum und Ager ziemlich
gut aus. Vielleicht holst du uns alle
noch mal irgendwie so ein bisschen ab und.
Wofür war das denn ursprünglich mal gedacht?
Und das ist ja auch nicht genau das, wofür es heute genutzt
wird. Es gibt ja fast keine
Organisation, in dem Scrum wirklich nach Lehrbuch
eingesetzt wird, aber vielleicht können wir das mal irgendwie
kurz auch halbwegs fair irgendwie einordnen, bevor wir
es kritisieren und mal irgendwie gucken, wo kommen wir denn
eigentlich her und warum war das mal das Richtige, weil dann
können wir eigentlich beleuchten, ist es denn immer
noch das Richtige? Ja, es war tatsächlich so ein
Gegenentwurf. Und Scrum ist ja jetzt eine
bestimmte Art von einem agilen Softwareentwicklungsprozess, und
das war so der Gegenentwurf für diesen klassischen
Wasserfallprozess oder v Modell, wo wir sehr langsam und
strukturiert einen Schritt nach dem anderen gemacht haben,
sondern wir haben gesagt, wir müssen in kurzen Iterationen
möglichst schnell funktionierende Software
liefern, wir brauchen schnelles Feedback am Ende von jedem
Sprint gibt es eine Retrospektive.
Die Feedback Zurückspielt, mit dem wir unseren Prozess
verbessern können und vor allen Dingen ging es darum, sich in
dem Ganzen auf die Menschen und die menschliche Zusammenarbeit
zu konzentrieren und weniger irgendwie statische Artefakte zu
produzieren, also irgendwelche ganz umfangreichen Requirements
Documents. Und das war natürlich eine große
Revolution, auch weil es uns ermöglicht hat, viel schneller
auch Software zu liefern und auf dieser Software schneller zu
iterieren. Gerade jetzt in dieser ganzen
Sars Revolution haben wir natürlich auch die Möglichkeit,
immer neue Software Versionen und neue Funktionalitäten quasi
sofort an unsere Kunden auszuliefern.
Wir brauchen jetzt nicht mehr irgendwelche langen Release
Zyklen Zyklen und da war auch so ein agiles Modell und das agile
Modell was viele gewählt haben war halt Scrum mit seinen festen
Prozessen und Rollen. Du hast gerade gesagt Product
owner, aber es gibt ja auch den Scrum Master des Dev Team.
Und die entsprechenden Zeremonien, die da durchgeführt
werden. Und da war das natürlich etwas,
was super relevant war und ganz viel gebracht hat.
Und ich glaube ganz viel auch der Software, die in den letzten
20 Jahren entstanden ist, wäre in der Form gar nicht so schnell
entstanden und hätte sich so schnell weiterentwickelt, wenn
wir nicht diese agile Revolution mitgegangen wären und auch so.
Irgendwie mit Scrum und Framework gehabt haben gehabt
hätten, an dem wir uns orientieren können.
Und eigentlich ist Scrum ja auch so ein natürlich irgendwo ein
Planungsframework. Aber ich finde auch so ein
bisschen so ein Kommunikationsframework, das ist
ja eigentlich diese diese klaren Hand of Modelle, also wann gebe
ich was, wohin weiter, und ich habe schon irgendwie das Gefühl,
das ist, das war eigentlich mal dafür gedacht, dass Menschen mit
dieser ganzen Arbeit, die vor ihnen liegen, diese riesengroßen
Anwendungen irgendwie zu bauen. Nicht mehr hinterher kamen und
ich sagen, heute ist es ja erst ein bisschen umgekehrt.
Heute kommen Menschen eigentlich nicht mehr dahinten nicht mehr
damit hinterher, die Arbeit entweder von einem KI Agenten zu
reviewen oder einem KI Agenten Zuzuschustern, der sie dann in
einen Bruchteil der Zeit wahrscheinlich einfach
runterrockt oder dann halt irgendwie wieder eine Rückfrage
hat und ich merke das irgendwie selbst.
Ich gebe dem Agenten eine Aufgabe und bin fast schon
gestresst, wenn die Antwort zu schnell kommt, weil das gar
nicht in diesen normalen Prozess passt, den wir in.
Indem ich irgendwie noch denke und arbeite.
Ich dachte, ich würde würde jetzt im Hintergrund erledigt
werden und ich hätte jetzt Zeit, um mich um was anderes zu
kümmern und auf einmal poppt da irgendwie eine Rückfrage auf und
das finde ich total schwer zu planen, wann springe ich da
jetzt direkt wieder hin, unterbreche ich meine aktuelle
Arbeit oder sage ich jetzt okay ich gebe ihm jetzt eine Aufgabe
und in einer Stunde komme ich wieder zu dem zurück und wenn er
nach 10 Minuten eine Frage hat, dann habe ich halt irgendwie 50
Minuten verloren, wenn der erst nach 45 Minuten eine Frage hat,
ist es besser weil da habe ich nur eine Viertelstunde verloren
und und ich merke jetzt irgendwie so richtig so, dass
mich das fast schon stresst, wie schnell diese antworten
Rückfragen kommt im Stress auch, dass es nicht planbar ist, wann
dieser wann das passiert. Deswegen gehe ich immer mehr
auch in diesen yolo Mode rein, dass ich sage okay, du versuchst
einfach so lange eigenständig das Problem zu lösen, bis du
wirklich gar nicht mehr weiter kommst.
Und das passt gar nicht so in diesen diesen starren Zyklen,
denen man jetzt irgendwie ein Ticket abgibt und.
Und das wieso ein bisschen ist ja so ein bisschen das Zuweisen
von einem Ticket an eine andere Person ist ja eigentlich wieso
ein Haken auf so eine to do Liste zu setzen, man ist ja mit
irgendwas fertig und wenn das dann, aber wir kennen ja beim
Menschen, auch wenn es dann noch 5 Minuten direkt wieder an mich
zurück essigned wird, dann ist das frustrierend und das merke
ich schon auf meiner täglichen Arbeit.
Ja, und ich glaube, das ist auch so ein bisschen dieses Gefühl,
dass man vorher in diesen 2 oder 4 Wochen Rhythmen gearbeitet hat
und dann da so ein bisschen auch.
Ruhe und Fokus auf eine bestimmte Aufgabe hatte
zumindest als Developer, der dann bestimmte Aufgaben
übernommen hatte und wir jetzt quasi irgendwie täglich mit uns
selber und unseren KI Agenten dieses Scrum Meetings haben.
Das heißt, wir schauen uns irgendwie quasi täglich unsere
Anforderungen an und sagen okay, was machen wir dann heute, was
geben wir heute an die in die Implementierung und dann?
Beschäftigen wir uns damit, diesen Code entsprechend
Qualitäts zu sichern und sicherzustellen, dass das, was
wir da produzieren, auch wirklich in Produktion
funktioniert? Ich glaube, da war in der
Vergangenheit mehr der Fokus darauf, möglichst schnell
funktionsfähigen Code an die Kunden zu liefern.
Wohingegen man jetzt eher sagt, ja, es geht vielleicht gar nicht
mehr möglichst schnell darum, mit diesen KI Agenten das zu
liefern, weil das passiert teilweise oder wäre möglich
innerhalb von wenigen Stunden, sondern es geht darum, auch
wirklich geprüften und qualitätsgesicherten Code und
entsprechend Funktionalitäten an die Kunden auszuliefern.
Also die Grundidee, glaube ich, ist immer noch da, aber wir
haben natürlich viel kleinere Iterations.
Zyklen, in denen wir arbeiten. Und wir haben vor allen Dingen
nicht mehr dieses Development Team, was irgendwie
zusammensitzt mit dem einen Product Owner, der dann seinen
langen Backlog mitbringt und dann schaut man da rein und sagt
okay was verteilen wir jetzt, sondern wir agieren als
Developer glaube ich immer mehr selber als Product owner wenn
man diese Terminologie hier übernehmen möchte.
Ja, vielleicht sind das dann eher so ein Tagessprints.
Dann was du gerade beschreibst, wenn du sagst, irgendwie morgens
mache ich mir Gedanken, das will ich heute umsetzen und dann muss
ich eigentlich nur noch genug Zeit einplanen, dass ich das
eben reviewen kann, dass ich den Agenten halt irgendwie zuspielen
kann. Also ich merke auch so ein
bisschen, der Engpass verschiebt sich eigentlich weg von der
reinen Umsetzung, weil das ja das, warum ich eigentlich vorher
Sachen in längeren Sprints geplant habe, auch vielleicht
gesagt Okay dieses backlock Item, das kriegen wir jetzt hier
nicht mehr umgesetzt, hinzu eigentlich.
Ja, mehr irgendwie. Priorisierung, vor allem Review,
aber du hast auch gerade schon gesagt, Qualitätssicherung, also
nicht mehr das Bauen von Software ist der Flaschenhals,
sondern eigentlich das Bereitstellen des richtigen
Kontextes, das Treffen von Entscheidungen, das
priorisieren, was ich wann in welcher Reihenfolge mache.
Ich muss eigentlich meine Review Zeit jetzt managen und.
Und nicht mehr die Zeit, irgendwas zu bauen.
Also eigentlich muss ich mir Sachen einplanen in meinen
Kalender oder meine to do Liste oder einfach ein paar Stunden am
Tag, idealerweise sogar verteilt über den Tag, damit in der
Zwischenzeit wieder Agenten im Hintergrund arbeiten können,
muss ich mir eigentlich diese Review Zeit einbauen, wo ich
sage okay jetzt muss ich wieder ran und dieses wenn dann immer
es zu so einem human in The Loop Effekt kommt, dann auch ich muss
eigentlich eher dem Agenten zur Verfügung stehen und dadurch,
was ja gerade schon gesagt, gehe ich ja eigentlich eher in diese
Product owner Rolle und. Und das finde ich eigentlich
ganz, ganz spannend, dass ich sage, ich bin in der Regel
langsamer als der Agent, der das dann halt irgendwie coded und
deswegen mir bringt das auch gar nicht so viel davon, wenn man
irgendwie dann immer hört, haben ja auch viele in anderen News
folgen, das Ding kann jetzt irgendwie 24 Stunden lang Code
bauen, meine Realität sieht eigentlich immer so aus, dass
das Ding eigentlich schon früher fertig ist, dass ich wieder Zeit
habe, ein Review zu machen. Ja, und ich glaube, in der
Vergangenheit konnte ich als Product Owner, der irgendwie mit
einem Deftteen gearbeitet hatte, konnte ich in so einem Sprint
ganz gemütlich für den nächsten Sprint viel mehr User Stories
bauen, als das Team im nächsten Sprint überhaupt je hätte
implementieren können, weil ich konnte mich einfach hinsetzen
und hatte dann irgendwie 2 Wochen Zeit, konnte Interviews
führen, konnte diese User Stories aufschreiben und mein
Backlog war immer länger als das, was wir hätten im nächsten
Sprint schippen können und jetzt sieht es teilweise so aus, dass
die. Wenn wir in diesen alten Rollen
noch sind, dass wir dann eher den Bottleneck am Anfang haben,
nämlich vielleicht auf der Product Manager oder Product
owner Seite, dass diese Person gar nicht so schnell Sachen
nachliefern kann in der Qualität.
Schreiben kann. Genau das ist ja der Kontext
nachher. Ja, in der Qualität, die wir
brauchen, weil vielleicht Menschen sehr gut auch mit so
ein bisschen Unsicherheit, Unklarheit umgehen können,
wohingegen KI Agenten sehr klare.
Ja, product Requirements brauchen und wenn ich diese dann
in dieser Qualität erarbeiten möchte, dann dauert das seine
Zeit und das dauert dann vielleicht länger als dann den
Coding Agenten dabei zuzuschauen oder es im Hintergrund laufen zu
lassen, wie sie dann dieses Feature zu implementieren.
Und dann habe ich wiederum diese längere Phase.
Der Qualitätssicherung, wo ich sicherstellen möchte, wir hatten
in der Vergangenheit mal in einer der News folgen erwähnt,
dass jetzt bei adable US auch wieder Menschen Senior Engineers
auf den Code draufschauen müssen, der in Production
geshippt wird, weil es da zu Problemen kam.
Mit diesem ganzen Agent Code. Das heißt wir haben jetzt wieder
an anderer Seite irgendwie eine Herausforderung, wo wir mit
Engpässen arbeiten müssen, aber dieser Engpass ist halt jetzt an
einer anderen Stelle und dementsprechend funktioniert
halt dieser klassische. Prozess mit unseren Sprints und
Sprint plannings wie in der Vergangenheit einfach nicht mehr
richtig. Ja, das ist auch der Grund,
warum dann so ticketsysteme vielleicht auch irgendwie JIRA
oder sowas heute gar nicht mehr so richtig zeitgemäß wirken.
Also irgendwie muss ich mir schon die Frage stellen,
vielleicht ist das Ticket auch einfach gar nicht mehr die
passende, ja, wie soll man das sagen, Einheit an Arbeit, die
ich dann halt irgendwie in einer KI oder vielleicht sogar auch
immer mal wieder einem anderen Menschen übergebe.
Also ich glaube das Ticket an sich ist gar nicht so falsch,
zumindest der Inhalt davon, das ist ja dann doch auch irgendwie
der Grund. Kontext und irgendwie das Planen
von Tickets in einem Sprint, der dann aber erst in n paar Wochen
stattfindet oder das Nehmen von dem Ticket aus dem Backlock.
Ich glaub das ist falsch, ne. Also früher hatten wir so n
bisschen irgendwie n Mensch setzt n Ticket um.
Und heute kann eine Person ja auch Dinge parallel anstoßen und
Arbeit wird viel weniger linearer.
Dass ich wirklich so ein Ticket nach dem anderen Abarbeite,
sondern wie gesagt, also Boddenberg ist eigentlich, dass
ich jetzt vorher mich hinsetzen muss und so viel, je mehr
Tickets ich ausformuliert bekomme, desto mehr Arbeit kann
ich parallelisieren, wenn die Arbeit sich parallelisieren
lässt. Das ist ja nicht, es ist ja
nicht immer der Fall, manche Dinge bedingen sich ja immer
noch irgendwie, aber. Aber das Ziel ist ja einfach
irgendwie nicht mehr die Arbeit zu planen.
Die Arbeit macht sich ja quasi von alleine, zumindest in einer
perfekten Welt oder vielleicht in ein paar Jahren dann, wenn
diese Karriergenten komplett autonom laufen und die Arbeit
ist es ja, also dass das ja nicht mehr das Ziel, sondern ich
muss, ja, ich muss ja irgendwie, habe ich eben gesagt, so ein
bisschen meine Review planen, und ich finde, dann steht mir
einfach so ein Prozess, auch, der vor allem ein Prozess, der
für Menschen gebaut wurde, total oft im Weg.
Immer irgendwie so als. Also ich habe in meinem Kopf
irgendwie so gehabt, so ein ampelbeispiel stell dir vor, du
bist irgendwie in der perfekten Welt, auch so wie 2 Jahre in der
Zukunft. Ki wäre vielleicht ein paar
Jahre in der Zukunft in unserer normalen Welt und was alle
selbst überall hast du selbstfahrende Autos, die
perfekt miteinander synchronisiert sind in so einer
perfekten Straßenwelt und dann warten die aber trotzdem an
einer roten Ampel, weil das halt einfach irgendwie der Prozess
ist an einer menschenleeren Kreuzung und nur weil dieses
System der Ampeln mal für Menschen gebaut wurden und.
Und so ähnlich sehe ich dann auch irgendwie so KI Agenten,
die dann darauf warten, dass der neue Sprint anfängt oder so was.
Und wenn jetzt alle Autos miteinander reden und perfekt
synchronisiert sind, dann können die auch alle mit maximaler
Geschwindigkeit fahren und das braucht eigentlich keine Ampeln
mehr und ja, wir müssen jetzt eigentlich als Menschen zurück
auf diese developer Welt eigentlich nur noch
sicherstellen, dass KI auch wirklich das richtige Business
Problem löst und sich nicht irgendwas zusammen halluziniert,
also eigentlich eher dieses Stearing.
Zu machen und immer mal wieder drauf zu gucken, ob diese ganzen
Autos noch in die richtige Richtung fahren und noch das
richtige Ziel haben, das ist jetzt eigentlich immer mehr
unsere Aufgabe und dafür braucht es glaube ich kein Ticket mehr.
Ja, das ist halt die Frage, weil Tickets haben ja verschiedene
Einsatzzwecke und du hast gerade gesagt, es dient dazu, Arbeit zu
planen, aber ich höre da schon die Einwände auch von einigen
meiner Kunden, die dann in irgendwelchen regulierten
Industrien arbeiten, die sagen ja, ich brauche aber diese
Tracability, das heißt, ich muss ganz klar nachvollziehen können,
was. Was ist die Anforderung?
Wie wurde das ganze Feature geplant und spezifiziert, an
welcher Stelle wurde es umgesetzt, wann kam es in den
Source Code rein, wie wurde es geprüft und wie und wann wurde
es entsprechend in laufende Software ausgeliefert und von
den Anwendern genutzt, damit wenn irgendwelche Fehler
auftreten. Ich rede jetzt hier über zum
Beispiel medizinische Systeme oder in der Automobilindustrie
damit halt immer ganz klar ist, wo hat wer was gemacht, wer hat
das an welcher Stelle freigegeben, was.
Damit, wenn Probleme auftreten, man auch die Ursachen ganz klar
definieren kann. Also ich glaube es gibt
weiterhin Use Cases, wo man solche Systeme braucht, aber
dann nicht mehr aus der Perspektive eines Systems, was
uns hilft irgendwie menschliche Arbeit zu koordinieren, sondern
vielleicht etwas viel einfacheres oder
leichtgewichtigeres, was einfach im Hintergrund.
Solche Logs schreibt die es uns ermöglichen halt diese Sachen
quasi End zu Ende nachzuverfolgen.
Ja, okay würde ich, würde ich mitgehen.
Dann braucht es vielleicht doch irgendwie.
Ob das ein Ticket ist oder was auch immer, aber irgendwie so
eine Tracability von einem bestimmten Prozess oder sich
zumindest von Formulierung der Anforderungen bis hin zur zum
Shipping an den Kunden das irgendwie nachvollziehen kann.
Aber ich habe mir jetzt auch in Vorbereitung der Folge immer
wieder die Frage gestellt, wie muss denn ein System aussehen,
dass Agenten und agentische Programmierung in den
Vordergrund stellt, denn wir haben ja schon so ein bisschen
satt. Das Problem verschiebt sich, wir
hatten ja eigentlich früher so ein bisschen, ich kenne das so
ein bisschen als dieses ganze def hops Ding aufkam.
Da wurde gesagt, wir haben, wir bekämpfen eine Deployment Wall,
also alles was dieses Def Hops Ding ja macht, ist dieses Works
on my Machine Problem zu lösen und heute haben wir das glaube
ich gelöst durch durch Docker Container, durch regelmäßige,
durch Continuous Deployment, durch Continuous Integration,
all diese Dinge. Und heute haben wir eher so eine
Kontextwahl. Ich glaube, das haben wir schon
schon rausgearbeitet, diese, wir nennt sich einfach mal trotzdem
weiter. Tickets müssen sehr gut
ausformuliert sein im Moment ja wirklich noch extrem gut, weil
sie ja der Hauptkontext sind für diese KI Agenten und da kommen
wir schon zu so einem Punkt. Eigentlich brauche ich ein
System was diesen Kontext in den Vordergrund stellt, also
eigentlich würde ich sagen aller relevanter Kontext.
Muss entweder in diesem System dann sein, was für Agenten
optimiert ist oder zumindest aus diesem System heraus erreichbar
sein. Also klar, dass da so Sachen
sind wie der Code, ich glaube das ist klar, ich glaube das
geht auch so ein bisschen die Richtung was der was das Thomas
Domke diese Ex git up sie oder mit seinem neuen Projekt vor
hat, das war ja auch glaube ich sehr um den Kontext herum
gebaut, aber ich finde dann es muss aber auch ein System sein
was zum Beispiel? Architecture, Decision Records
und so Strategic Direction Decisions abbildet.
Also warum haben wir wann welche Entscheidungen getroffen, weil
ein Mensch kann sich daran erinnern, dass wir die
vielleicht, also im Idealfall, dass wir die mal getroffen
haben, und Agenten muss es vielleicht wissen, die müssen
dokumentiert sein, und da muss man auch nachvollziehen können,
warum wir das mal gemacht haben. Da müssen, da müssen sowas wie
Spezifikationen für ne bestimmte Aufgabe natürlich dann auch
hinterlegt sein. Das ist ja dann eigentlich fast
das, was vielleicht auch klassischerweise in so n Ticket
geht. Wir haben mal über Specdriven
Development gesprochen in Folge 137.
Und ich glaube, da gibt es eine ganze Menge mehr Sachen, die
dann einfach wichtig für so einen Agenten sind, die in ein
System mit einfließen sollten. Also Kundenfeedback, Bug
Reports, irgendwelche internen Ideen oder Richtungen, in denen
sich das Produkt entwickeln soll.
Die Dokumentation ich habe jetzt auch gelesen documentation is
the New Source Code, also eigentlich ist der Code mir
egal, der kann ihm Zweifel wegschmeißen und neu generieren
lassen, ich muss halt nur dokumentieren lassen, was er
eigentlich mal aussagen sollte oder was mein Ziel ist.
Das heißt, statt also eigentlich ein System, was all diese Sachen
zusammenhält, die nachher in den Kontext hereinfließen, der für
so einen Agenten ist, nicht wenn man Workshops auch immer sagt,
Kontext ist King und ich glaube, dass das Ergebnis ist
substanziell besser, je besser und relevanter der Kontext für
so ein KI Agent ist. Deswegen ich habe noch gar kein
Bild vor Augen, wie das System aussehen soll, ich würde aber
sagen, ein System was sich um den Kontext herum entwickelt ist
wahrscheinlich 1, was jetzt zumindest so für diese
agentische Welt. Ja, sinnvoller erscheint.
Ich glaube, da kommen wir dann einfach aus einem Prozess oder
aus einem System, was für Menschen gebaut ist, zu einem
technischen System. Also wir haben vorher über agile
und Scrum gesprochen, was irgendwie ein System ist, um
halt Menschen zu koordinieren, die Miteinander an bestimmten
Dingen arbeiten, brauchen wir jetzt ein technisches System,
welches diese neue Implementierungswelt.
Koordiniert die entsprechende Informationen bereitstellt dort
gerade ganz viel über Kontext gesprochen und da können
natürlich auch die Software Systeme, die wir dafür in der
Vergangenheit genutzt haben, weiter eine Rolle spielen.
Als du gerade darüber gesprochen hast und gesagt hast, ja, das
ist dann jetzt nicht in einem Ticket, weil das legt man
üblicherweise vielleicht nicht in JIRA ab, aber das legt man
vielleicht in einem Confluence ab, das heißt, diese Systeme
irgendwie JIRA Confluence, die jetzt von Eblassient kommen,
oder natürlich äquivalente Systeme von anderen Herstellern.
Spielen vielleicht weiterhin eine Rolle, aber wir brauchen
jetzt dieses von dir beschriebene technische System,
welche diese Informationen just in Time zum richtigen Zeitpunkt
für diese Implementierungsagenten
verfügbar macht. Und da kommen dann natürlich
technische Themen wie MCP Server und Tools rein, um halt diese
Informationen jederzeit verfügbar zu haben.
Da kommen solche Sachen wie irgendwie eine.
Eine Constitution, die ich in meinem Projekt Ablege oder so
ein Agents md file wo bestimmte Dinge drin stehen in Spiel.
Aber das ist dann dieses technische System was wir
aufbauen und was dann vielleicht in Zukunft weit wichtiger wird
als dieses. Ja, Zwischenmenschliches System
oder dieser Prozess, den wir genutzt haben.
Ja, das stimmt. Und das muss ja auch sein, dass
das System ja trotzdem noch für Menschen funktioniert, denn es
gibt ja auch nach wie vor Aufgaben einfach, die zumindest
schon heute so ein KI Code Agent gar nicht lösen kann.
Wo also Code haben, der von einem Menschen geschrieben sein
muss, vielleicht weil ich sage, ey, da geht es um die Payment
Prozesse, die hat hier keine KI anzufassen oder die KI kommt
einfach nicht weiter, das ist ja auch schon heute immer noch in
vielen Fällen der Fall. Und ich brauche den Menschen
aber trotzdem, weil ich vielleicht Input von ihm
brauche, weil ich irgendwas eskalieren muss, weil ich mir
eine Proville für irgendwas abholen muss.
Also ich glaube, dass das System schon beide Welten abdecken
können muss, aber natürlich berücksichtigen muss, dass auch
dieser Mensch in 99% der Fälle mit einer KI Unterstützung
arbeitet und trotzdem merke ich aber auch gerade auch, dass, wie
du gesagt hast, ich eigentlich ein technisches System
beschreibe, anstatt einen Prozess, das heißt, ich glaube,
wir sind jetzt noch nicht näher daran, wie muss denn eigentlich
ein. Ja, der Prozess der Zukunft
aussehen oder brauchen wir den überhaupt noch oder reicht es
einfach zu sagen, gut, das sind die, also ich glaube so Features
von muss ich ja trotzdem definieren, vielleicht auch
mache ich trotzdem irgendwie ein paar Epics, beschreibe ich die
relevant und muss jetzt aber nicht mehr, dass irgendwelche
Tasks runterbrechen, die ich dann in Sprints zuordne, sondern
vielleicht fahren wir einfach auf einer anderen Flughöhe und
geben, ja schmeißen diese diese Starre.
Aufteilung in Sprints halt weg, sondern sagen ich kann
theoretisch nach jedem Pull Request Merch deployen.
Also ich habe dieses Continuous Deployment Prinzip weiterhin,
braucht aber diese Planungskomponente nicht mehr,
weil die menschliche Zeit geplant hat, da bin ich mir
gerade noch irgendwie unsicher, in welche Richtung sich da der
Prozess entwickeln wird. Ja, ich denke, wir brauchen
weiterhin ein agiles Modell und wir brauchen ein agileres
Modell, vielleicht noch als in der Vergangenheit, weil wir halt
in viel schnelleren Zyklen arbeiten.
Aber ich glaube, von dem, was wir auch gerade diskutiert
haben, gibt es halt ganz viele Dinge, die in diesem Scrum
Modell vielleicht so ein bisschen aus der Zeit gefallen
sind, weil dieses Scrum Modell natürlich sehr auf Menschen
zentriert ist und diese Zeremonien sehr darauf achten,
wie können wir die Arbeit zwischen Menschen koordinieren,
wie können wir auch unseren Prozess verbessern, wie können
wir das Feedback einsammeln in regelmäßigen.
Abständen und jetzt müssen wir weiterhin agil arbeiten, aber
wir können das nicht mehr in diesem starren Rahmen, den wir
im Rahmen von Scrum gelernt haben, tun.
Aber dennoch gibt es ja einige Dinge, die auch weiterhin
funktionieren, wenn wir jetzt mal über Scrum reden, wird
vielleicht die Rolle des Product Owners oder in Zukunft der
Product owner umso wichtiger, weil natürlich wir viel
schneller Code schreiben können. Und dann dementsprechend auf der
Planungsseite viel mehr Zeit und Energie investieren müssen, um
die ganzen Dinge entsprechend vorzubereiten.
Ja, ich glaube, für den Paragrawner ist das eine rosige
Zukunft. Also der muss ja, glaube ich,
heute dann viel mehr irgendwie, also der muss ja viel weniger,
sage ich mal, Tickets verwalten und mehr Richtung vorgeben,
Entscheidungen treffen, klar, der muss auch den Kontext
irgendwie sauber machen und so wie Ziele und Intention.
Viel klarer formulieren. Aber das ist ja, glaube ich, für
alle eine gute Sache. Ich kenne viele Teams, die sich
das von ihren Producern wünschen, dass sie das sauberer
oder klarer formulieren und sowas, das heißt, ich glaube, da
erinnert sich die Rolle schon auch eher so von so einem
Reinen, also was macht ein Producer heute, Anforderungen
schneiden, priorisieren, einen Backlog pflegen und sowas und
jetzt halt einfach viel, viel weniger so Ticketverwaltung,
sondern mehr so durch dieses Richtungsgebende.
Jetzt gibt es ja aber nicht nur den Product Owner, sondern auch
den Scrum Master. Das ist ja danach also ein
bisschen der Zeremonienmeister und da würde ich sagen, weiß ich
gar nicht so, ob ich das noch brauche, ob ich jetzt irgendwie
noch, weil der muss ja eigentlich diesen Prozess
einhalten und während ich sage, die die konkreten Werte hinter
Scrum und Agile, die sind vielleicht relevanter denn je,
aber diese diese starre Einhaltung eines bestimmten
Prozesses, das wird ja vielleicht ausgeweicht
aufgeweicht, also. Also da weiß ich gar nicht, ob
es so einen Scrum Master in Zukunft überhaupt noch braucht.
Ich denke mal, wir brauchen weiterhin Menschen, die sich
damit beschäftigen, wie wir im Team gut zusammenarbeiten, wie
wir uns gut abstimmen und gemeinsam in die gleiche
Richtung arbeiten. Aber ob man dann tatsächlich
diese diese Rolle des Certified Scrum Masters noch braucht, der
sehr stark einfach diesen Prozess in Forst.
Das ist halt etwas, was man, glaube ich, ganz stark
hinterfragen kann, weil sobald wir halt aus diesem Scrum
Prozess ausbrechen, aus diesen regelmäßigen Terminen, die wir
da haben, aus den regelmäßigen Scrum Zyklen, die wir alle 2
Wochen in Form der Sprints haben, dann brauchen wir
vielleicht diesen Certified Scrum Master nicht mehr, aber
wir brauchen trotzdem vielleicht jemanden mit der gleichen
Kompetenz, der den. Den Überblick über die
Organisation hat der Probleme adressiert, der Draufschaut.
Wo klemmt es gerade auch zwischenmenschlich, und dann
hilft, diese Probleme zu lösen, aber ich sehe das weniger als
Problem für die Menschen, die gerade als Scrum Master
arbeiten, sondern mehr für die Scrum Alliance, die vielleicht
auch über ihre Trainingspartner da jetzt ganz viel
Zertifizierung verteilt hat, wo ganz viel Geld mit Trainings
verdient wurde und ich glaube, dass die mehr Probleme kriegen
als die Leute selber, weil ich glaube in Zukunft haben die
Leute ja. Einen fast noch sichereren Job,
die gut mit Menschen arbeiten können als diejenigen, die nur
die Technik beherrschen. Obwohl klar, ich will jetzt
nicht sagen, dass Entwickler nur die Technik beherrschen, aber
für das Entwicklerteam ändert sich natürlich auch was, aber
eigentlich auch die Sachen, die wir eigentlich auch hier diesem
Podcast schon zu Haufe besprochen haben.
Also früher haben wir gesagt, war also die Umsetzungskapazität
knapp. Und das Wissen über die Syntax,
über das Framework und so was. Das war zentral und heute, das
haben wir schon öfter gesagt, entwickelt sich die Rolle von so
einem Software Developer viel mehr auf einen Fokus hin, auf
Reviews natürlich, aber auch auf Architektur, auf das
Systemdenken, auf eine Qualitätsbewertung, also viel
weniger auf reine Codeproduktion, sondern vielmehr
auf Verantwortung für eine Entscheidung, für eine
Architektur. Und natürlich dann am Ende auch
das Stearing und das Reviewen von den Dingen, die vielleicht
eine KI macht, mit Sicherheit auch noch zu einem großen Teil
der Zeit das selber Coden an einigen Stellen, wo er mit Dki
gar nicht ran soll oder nicht weiter kommt, aber da muss man
schon sagen, das wird wahrscheinlich mit Blick auf die
Zukunft doch eher weniger und trotzdem brauche ich aber
jemanden, der das oben drüber so ein bisschen überwacht, weil ich
glaube ist der klassische Develop Hope trotzdem extrem
viel mit Code arbeiten. Aber vielleicht auch eher so.
Diese Armee der Agents Orchestrieren und immer mal
wieder reviewen und in die richtige Richtung schubsen.
Das heißt, wir merken schon so, das Team bleibt weiterhin, was
es vielleicht auch heute irgendwie gibt, auch in diversen
Rollen und da gibt es natürlich dann auch noch den, den den
Product Manager am Ende, der haben jetzt gar nicht
beleuchtet, aber. Aber der Prozess wird sich
ändern. Ich glaube, zusammenfassend kann
man sagen, dass wir weiterhin in einem sehr agilen System agilen
Umfeld arbeiten und agile Softwareentwicklung hat die
Softwareentwicklungswelt massiv nach vorne gebracht.
Auch Scrum hat einen ganz wichtigen Beitrag dazu
geleistet. Aber ich glaube, es ist dieser
Scrum Aspekt mit seinen festen Prozessen und Zeremonien, der
sich immer mehr auflösen wird, weil wir einfach so eine
disruptive Veränderung in der Art und Weise sehen, wie wir
Software entwickeln, dass es zwar weiterhin agil sein wird,
aber nicht in dieser starren Form, wie wir es bisher gesehen
haben. Ja, und auch wichtig für das
Fazit wäre mir nochmal zu sagen, wir haben ja gemerkt so
irgendwie diese so viele von diesen alten Mechaniken, die
wirken plötzlich schwerfällig oder künstlich in so einer Welt,
wo einfach. Ja, das Bottle Neck nicht mehr
ist Zeit dafür zu planen, dass man Code schreibt und KI
verändert einfach gerade das Verhältnis.
Das finde ich glaube ich ganz gut.
Das Verhältnis von Planung, Umsetzung und nachher dann
Qualitätskontrolle so was wie wie Reviews und genau das Ziel
ist einfach nicht mehr die Arbeit zu planen, die Arbeit
macht sich von alleine, sondern halt diese Planung.
Planung vorher zu machen und das Runterschreiben von den
Requirements und nachher das Ergebnis zu kontrollieren.
Ja, und wenn du jetzt diese, ja kontroverse These noch mal quasi
hinterfragst, die wir am Anfang hatten, ist agile tot.
Dann kann man glaube ich sagen Nein, agile ist nicht tot, aber
wenn man agile gleich Scrum gesetzt hat, wie es viele in den
letzten 20 Jahren gemacht haben, dann vielleicht schon, weil es
war. Nicht tot.
Das Auge jetzt nicht existentarisch ist, das habe ich
jetzt nicht gesagt. Aber ich denke mal, scrum wird
sich entweder massiv verändern müssen oder es wird nach und
nach immer weniger relevant sein, weil immer mehr
Unternehmen natürlich ihre Softwareentwicklungsprozesse an
diese neue Welt der agentischen Softwareentwicklung anpassen und
umstellen werden. Ja, das ist doch schön.
Die Zukunft gehört auf jeden Fall nicht den Teams, die am
diszipliniertesten Tickets verwalten.
Sondern eher denen, die die einfach guten Kontext schaffen.
Das hatte ich ja gerade so ein bisschen in dieses System, was
sich ein bisschen in meinem Kopf da irgendwie schwört, es geht ja
um diesen, also guten Kontext schaffen, schnell Entscheidungen
treffen können, glaube ich trotzdem Qualität sichern, also
trotzdem dafür sorgen, dass nicht, wie Adaws jetzt gesagt
hat, oh, wir haben so viel bloatwear und so viel
Gewipecoded, ein Quatsch, da irgendwie drin, jetzt müssen wir
doch wieder Seniors alles reviewen lassen, die.
Die Verantwortung übernehmen und die vor allem auch irgendwie mit
dieser also die, die dann schneller wieder Review geben,
die sie stieren können, die einfach mit dieser neuen
Geschwindigkeit sinnvoll umgehen und am Ende des Tages, da auch
ihre Prozesse und vielleicht sogar methodiken drauf anpassen.
Also vielleicht braucht es einfach neue Prozesse, neue
Tools, neue Methodiken für diese angepasste Welt und keine ganz
ganz, ganz starre Ticketdisziplin mehr.
Sondern einfach was, was dieser neuen Geschwindigkeit, dieser
neuen Loop, dieser neuen Developer Loop, von denen man ja
wie schon mal in diesem Devox Complet spricht, diese inner und
außer Loop, die darauf angepasst ist, weil die hat sich einfach
massiv verändert und vor allem massiv beschleunigt.
Ja, und am Ende verändert sich die Welt aktuell so schnell,
dass wenn du jetzt sagst, okay, wie schnell ist so eine
Implementierung, dann kann diese Antwort in 2 Wochen anders
aussehen. Ich glaube viel wichtiger ist es
diese. Neuen Phasen, die jetzt wichtig
werden, viel besser zu planen. Also wieviel brauche ich
wirklich für diese spezifizierungsphase und wieviel
Zeit brauche ich am Ende für die Qualitätssicherung?
Und vielleicht entwickelt sich daraus am Ende ein neues agiles
Modell, wo man dann zusammensitzt und sagt, Hey, wir
haben folgende Dinge, die wir jetzt irgendwie erledigen
wollen, heute morgen in den nächsten Tagen, aber wie lange
wird dich das Kosten, um am Ende das Ganze zu reviewen, bevor wir
es shippen können, weil am Ende. Ist es für mich ja vielleicht
als Product Ordner immer noch relevant zu wissen, wann ist das
Feature bei meinen Kunden und wenn das Bottleneck am Ende dann
deine Review Zeit ist, musst du das vielleicht genauso vorkasten
wie du in der Vergangenheit deine Implementierungszeit
geplant hast. Und vorher auch die Zeit
einzuplanen, natürlich das gut zu beschreiben, auch vielleicht
in der Tiefe, in der ich einen Menschen nicht hätte beschreiben
müssen. Ich glaube, ihr seht schon hier,
wir sagen ganz, ganz viel vielleicht, das war jetzt noch
eine sehr philosophische Folge, deswegen interessiert uns
wahnsinnig, was ist denn eure Meinung dazu, ich möchte schon,
wir kommen ja auch gar nicht zu einem, wir haben jetzt auch
nicht die Weißheit mit Löffeln gefressen und kommen jetzt hier
gar nicht zu dem neuen Modell, ich glaube das wird sich noch
über die nächsten Jahre formen, aber wenn ihr schon was gefunden
habt, was sehr gut für euch funktioniert oder wo ihr gesagt
habt, ey, wir haben unsere Methodiken angepasst auf diese
neue Realität und das funktioniert für uns gut und.
Oder ihr habt vielleicht was angepasst und es war eine
Katastrophe und ihr seid wieder zurückgegangen.
Zu dem Scrum Modell. Dann lasst uns das gerne wissen.
Bei dieser Folge sind wir mehr als je zuvor darauf gespannt,
was ihr denn eigentlich dazu sagt und was eure Erfahrungen
dazu sind oder was vielleicht auch einfach die Meinung sind,
die in eure Köpfe kommen, wenn ihr uns 2 jetzt hier eine halbe
Stunde lang zugehört habt, wie ihr über das Thema
philosophieren, von daher lasst uns gerne Kommentare da, wenn
ihr uns auf Spotify oder Youtube hört, dann gibt es da eine
Kommentarsektion, wir freuen uns aber auch ganz ganz doll über e
Mails. Dann können wir das Thema
vielleicht auch in einer der kommenden Folgen noch mal
aufgreifen. Gemeinsamer mit Euren, mit eurem
Input und den einfließen lassen. Und wenn euch diese Folge
gefallen hat und es euch weiter gebracht hat, uns beim
Philosophieren zuzuhören, dann lasst uns auch gerne eine
positive Bewertung auf Apple Podcast oder Spotify da.
Das hilft uns auch von anderen gefunden zu werden.
Wir freuen uns auch immer, wenn ihr uns einen Kaffee ausgeben
wollt, dann findet ihr einen Link zu bei mir Coffee in den
Shownotes oder wenn ihr zu eurem eigenen Kaffee die perfekte
Gebrandete Nerd Tasse haben wollt, auch da.
Da gibt es die Links zu unserem kleinen Shop und ansonsten hören
wir uns nächste Woche wieder, denn der To do Cast erscheint
jeden Montag immer abwechselnd mit einer Themenfolge wie dieser
hier und einer News Folge, wo wir die Tech Developer und KI
News der letzten 2 Wochen zusammenfassen.
Hört also wieder rein abonniert, wenn ihr es noch nicht gemacht
habt und wir hören uns nächste Woche, bis dahin habt eine gute
Zeit und schreibt ganz viel Code.
Bis dahin.