Latest / einfach gelöst / #18: Johannes Link – Extreme Programming und was danach schief lief

Transcript

#18: Johannes Link – Extreme Programming und was danach schief lief · einfach gelöst

• Stefan Roock (it-agile): Hallo und herzlich willkommen zum IT Agile Podcast Einfach Gelöst. Ich freue mich ganz besonders, dass ich Johannes Link hier habe. Hallo, Johannes. Johannes L.: Hallo Stefan! Stefan Roock (it-agile): Johannes kenne ich schon Ewigkeiten aus den ganz, ganz frühen Zeiten der Agilität. Aber vielleicht kenne ich dich nicht alle. Insofern magst du dich vielleicht kurz vorstellen. Johannes L.: Ja, ich bin Johannes jetzt ziemlich genau seit 30 Jahren im Berufsleben als Softwareentwickler, Softwarecoach und was man da alle so gleich läuft in dieser Zeit. Und fast genauso lange habe ich eigentlich auch mit dem Thema Agilität zu tun. Hieß am Anfang noch ein bisschen anders, kommen wir vielleicht ja auch noch drauf, Extreme Programming und leicht gewichtige Prozesse und sowas. Ja, mittlerweile bin ich nicht mehr freiberuflich, auch nicht mehr als Agila Coach, bei einer gemeinnützigen GmbH angestellt im Bereich Software Development, Technologie. Also alles, was so in groben in Richtung Entwicklung und Prozess geht, mache ich da. Stefan Roock (it-agile): Wann hattest du denn so deine ersten Kontakte zur Agilität oder Agile Entwicklung? Johannes L.: Also wenn wir das Wort außen vor lassen, weil das geht ja jetzt nicht länger als diese 25 Jahre zurück, da war das eigentlich auf dieser sehr technischen Seite wie automatisiert das Testen und so was schon recht früh, Mitte der 90er Jahre. Also da gab es schon bei Smalltalk, da gab es schon von Kent Beck das S-Uni, das hieß damals noch nicht so, aber er hat das in Zeitschriften veröffentlicht und solche Geschichten. Und dann ganz konkret, wo man dann auch schon wusste, wo hingeht, das war dann Ende der 90er Jahre, da gab es dann den, glaube ich, der C2 Wiki, Cunningham und Cunningham Wiki, und auf dem haben diese Pioniere aus dem C3 Projekt, ich bringe das manchmal durcheinander, das C2 Projekt, das C3 Wiki, aber es war das C3 Projekt, also Kreisler, Compensation, irgendwas, ja. Die haben ja schon aufgeschrieben, was sie dort gemacht haben. Und da ist auch schon die Begriffe Extreme Programming. Und da gab es eigentlich schon den groben Rahmen gab es da ja auch schon von Pair Programming über Continuous Integration und so weiter. Also ja, schon fast 30 Jahre, würde ich auch sagen. Stefan Roock (it-agile): Und als du von diesen Praktiken oder Techniken erfahren hast, was war deine Johannes L.: Also für mich war das schon so bisschen karrierebestimmend eigentlich von Anfang an, weil zu der Zeit war ich am Forschungszentrum eines großen europäischen Elektrokonzerns und eigentlich hatte ich gesagt, naja, Softwareentwicklung, das mache ich jetzt noch zwei, drei Jahre und dann war ich mal mindestens Architekt oder Manager oder sowas, weil dort waren alle Projekte eigentlich so. uns mit den Fachbereichen zusammengesetzt und dann haben wir lange Planungswochen gehabt und Projektpläne, dann über drei Monate war so der Anfang. Und dann hat man typischerweise, sollte es dann weitergehen. Und eigentlich nach zwei Wochen, nach zwei Tagen Entwicklung war eigentlich klar, alles, was man vorher in diesen zwei Planungswochen gemacht hat, ist Quatsch. Und das wird zu nichts führen. Dann hat man noch angefangen oder versucht am Anfang. diese Pläne irgendwie aufrechtzubehalten und zu modifizieren und das irgendwie riesige Modell, das man erstellt hat, anzupassen. Aber das hat eben nie funktioniert. Und das fand ich super frustrierend, weil ich aus, also ich kam damals aus dem Deutschen Krebsforschungszentrum, also aus dem akademischen Bereich und dachte endlich bin ich mal wo, wo man Software auch macht, in so einem größeren Konzern. Und als ich dann über Extreme Programming gelernt habe und was die Teams dort machen, dann kam so ein bisschen, hm, vielleicht Softwareentwicklung doch das, wo ich länger bleiben kann. Und tatsächlich bin ich dann auch, 1999 war das, glaube ich, bin ich dann zu einem mittelständigen Softwarehaus gegangen und habe versucht, ja, das umzusetzen. Das war dann auch tatsächlich. 1999, 2000 haben wir, ich würde sagen, sehr dicht an dem, Extreme Programming damals war, Projekte gemacht und erfolgreich gemacht, ja in kleinen Teams. Stefan Roock (it-agile): als dann 2001 das Agile Manifest veröffentlicht wurde, hast du, weißt du das noch, Krop, wann du davon erfahren hast? Johannes L.: Also ich kann dir jetzt nicht sagen, ob ich das jetzt am gleichen Tag oder in drei Wochen später. Es war aber so, war Anfang des Jahres, 2000 war ich auf dem XP Immersion Training. war damals, da gab es so von so eine Handvoll, ich, sechs waren es am Ende, glaube ich, ich war auf dem auf dem dritten. Das heißt, ich kannte ungefähr die Hälfte der der ursprünglichen Signatoren oder der Leute, die bei diesem Treffen dabei waren, kannte ich persönlich. Also die waren dort gewesen und ich hatte Kontakt zu ihnen gehabt. Insofern ist das ziemlich schnell gegangen, aber ich glaube, hat mich dieser Namenswahl hat mich wenig beeindruckt. Ich dachte, naja, die haben halt jetzt so bisschen einen größeren Rahmen das geschaffen, was man damals eigentlich schon kannte. Und das war Extreme Programming. Das waren so bisschen die Alice der Kuban Prozesse, der auch so einen Rahmen aufgespannt hat. Featured Dream Development glaube ich kannte ich damals auch schon, zumindest dem Namen nach. Insofern ja, bald, aber es hat mich nicht irgendwie verändert in meinem Blick auf das Ganze. Stefan Roock (it-agile): Und ich weiß gar nicht, ob das davor oder danach Du hast ja das, wenn ich richtig erinnere, das erste deutschsprachige Buch zu JUnit oder Unit testen geschrieben. Johannes L.: Ja, genau. Ende 2001 kam das raus. hab wahrscheinlich während dieser Zeit da schon dran geschrieben. Ich hab über das Jahr 2001 geschrieben und da kam dann noch irgendwann mein endes der Sohn zur Welt. Insofern hatte ich auch paar Monate frei und in diesem Kontext. Da war ich schon dicht mit diesem festgetriebenen Entwicklung. Ich glaube, die hieß damals noch Test-First-Programming. glaube, testgetrieben kam so ein bisschen erst danach der Begriff. Also da war ich schon super verliebt in diese ganze Art der Softwareentwicklung. Stefan Roock (it-agile): Ich meine mich noch zu erinnern, dass der Verlag oder die Christa vom D-Punkt-Verlag mal erwähnt hätte, dass du das so super strikt durchgezogen hast. Also irgendwie ein Zeitplan hattest, wann du was lieferst und das auch tatsächlich getan hast. Das fand ich immer total beeindruckend, weil unser erstes Buch haben wir, glaube ich, dreimal angefangen und neu geschrieben und überhaupt keine Zeitpläne eingehalten. Johannes L.: Ja, da weißt du mehr als ich, denn Stefan Roock (it-agile): okay. Johannes L.: ich habe es ja im Vorgespräch schon erwähnt, bin so als Zeitzeuge bin ich eigentlich, fühle ich mich total ungeeignet, weil meine konkreten Erinnerungen an Dinge, so lange zurückliegen, also wie eine Woche zurückliegen oder so, das ist echt schon schwierig. Stefan Roock (it-agile): Ich bin sehr sicher, dass Christa meint, das war so ungewöhnlich, Johannes L.: Ja. Stefan Roock (it-agile): weil normalerweise müssen sie Druck auf die Autoren ausüben und in dem Fall hättest du Druck auf sie ausgeübt, dass sie schneller mit der Lektoren-Tätigkeit werden müssen. Johannes L.: Das freut mich heute noch. Ich glaube, du Stefan Roock (it-agile): Hahaha. Johannes L.: hast mir gerade den Tag gerettet mit dieser Geschichte. Egal, ob sie stimmt oder nicht. Toll. Stefan Roock (it-agile): Ja, sehr schön. Ich bin sehr sicher, dass Sie stimmen. Johannes L.: Cool. Stefan Roock (it-agile): Okay. Und was ist dann so nach 2001 passiert? Johannes L.: Ich habe in dem Softwarehaus, in dem ich war, Antreneer Objects, die gibt es ja heute auch noch, sind viel, viel größer, als sie damals waren, hatte ich die Rolle dieses agilen, wie nennt man das heute, nicht Prophet, agiler, Stefan Roock (it-agile): Coach? Johannes L.: ja auch, aber sozusagen der, das nach außen bringt. Also so ein bisschen derjenige, der das vermittelt und der den Hut aufhakt, das auch an die Kunden zu bringen und Und das führt aber dann zwangsweise oft dazu, dass man aus dem Tun rauskommt. Ich habe dann irgendwann gesagt, ich will nicht nur noch der Prophet sein, der dafür bezahlt wird, dass er irgendwelche Dinge erzählt, aber nichts mehr tut. Und habe mich dann 2006 als Agila-Coach selbstständig gemacht. Habe das dann auch fünf Jahre, oder weniger, war ich nur auf dieser Coaching-Ebene unterwegs. Und ich glaube, mein letztes Projekt war mir da nicht zusammen bei einem großen deutschen Telekommunikationshaus in Süddeutschland. Und das war eigentlich so der Punkt, wo ich gesagt habe, nein, ich glaube, das ist nicht das, wo ich weiterbleiben will. Zum einen, weil man dann ja auch immer mehr in diese Organisationsgeschichte gezogen wurde. weg von dem Technischen Coaching und das, obwohl ich in diesem Projekt auch als einer der Technischen Coaches war und festgestellt habe, naja, man fängt jetzt an plötzlich die Leute zur Agilität zu tragen, während das vorher eher umgekehrt war. Die Leute haben einen geholt, weil sie was damit machen wollten und begeistert waren und dann war es plötzlich umgekehrt. Irgendwie das Management hat das angestoßen und das war für mich Dieses Projekt war eigentlich dann sozusagen der, wie sagt man, der Strohhalm, der das Kamel zusammenbrechen lässt, zu sagen, ich muss mal was anderes machen. hab dann anderthalb Jahre, zwei Jahre in einem Start-up Geld investiert. Also ich war einer der Mitarbeiter, wir haben aber nichts verdient. Und als ich dann zurückkam danach aus dieser Start-up-Zeit, war für mich klar, dass der Titel Agila Coach für mich nicht mehr passte. Ich habe auch viel nachgedacht darüber, was wir da gemacht haben und es hat sich so ein bisschen angefühlt, als wären wir zum einen sehr sehr nabelschaugig gewesen. sozusagen dieser Blick der Software-Community war schon sehr klein und dann hat man sich mit Agilität, das eigentlich noch mal kleiner gemacht, die Linse, unter der man war. Und man hat sich auch so ein bisschen oder wir als agile Coaches haben uns da, glaube ich, schon so bisschen missbrauchen lassen. Weil eigentlich ist ja, was ich vom Management erwarte, ist, ich bringe die richtigen Leute zusammen, ich motiviere sie, ich sorge dafür, dass die Menschen wissen, wie ihre persönlichen Ziele mit den Unternehmenszielen zusammenpassen. Also das, man zumindest Lime und Genannt hat. Und das haben die eigentlich komplett abgeschoben auf diese agilen Coaches und Consultants. Macht da mal eure Team-Dinger und wir haben unsere neue Business-Strategie und sorgt mal dafür, dass es irgendwie zusammenkommt. Macht ihr mal. Und ich habe gedacht, das passt einfach nicht. Und da ist auch dieser Aspekt, ... Agilmanifest so bisschen angedeutet wird, dieses Individuen über und Interaktion über Prozesse und irgendwas und Tools, glaube ich, heißt das. Was man vielleicht so bisschen pauschale als People-over-process auch beschreiben könnte. Das ist mir einfach zu kurz gekommen. Das war sozusagen auch dieser Punkt. Es gibt so viele gute Gründe, warum die Menschen, mit denen man da zu tun hat. vielleicht gar nicht agil werden wollen, auch gar nicht agil werden sollten, und zwar aus persönlichen Gründen, weil das System gar nicht passt, weil sie eigentlich schon in einem Unternehmen sind, das dysfunktional arbeitet. Ja, für mich hat das nicht mehr gepasst, diese agile Brille und das als Heißbringer da aufzutreten. dann habe ich mir den Titel Softwaretherapeut gegeben. Den haben dann im Nachhinein, ich weiß gar nicht, ob ich der Erste war, aber zumindest einer der frühen Leute mit diesem Titel. Und den haben danach noch viele angenommen. Und das lässt ja eigentlich alles offen. Therapiert man die Software, therapiert man die Organisation, die Menschen in irgendeiner Form. Ja, so bin ich dann eigentlich geblieben bis aus meiner Sicht, meine Nische irgendwann weggebrochen ist vor vier, fünf Jahren. ja, dann, seitdem bin ich angestellt und bin auch, naja, Agilität, das Wort taucht immer mal wieder auf und manchmal fordern das auch Menschen ein. Wir wollen agil sein und dann verwende ich das noch, aber sonst, ja, glaube ich, bin ich da auf einer viel freieren Ebene unterwegs. Stefan Roock (it-agile): Und da wo du jetzt bist, entwickelt du Software oder hast du deinen Traum wahrgemacht, Manager zu werden? Johannes L.: Also tatsächlich mein Titel, wenn du nachschaust, der heißt irgendwie Technology & Software Development Lead, aber ich liede da überhaupt gar nichts. Also nie mein Töter auf mich. Also im Sinne von ich könnte irgendwas vorgeben oder so. ich äußere meine Meinung und manchmal machen Menschen damit was und manchmal machen damit Menschen nichts. Und das heißt, ich bin da sowohl in dieser, auf dieser Prozess-Ebene unterwegs als auch ganz konkret in Projekten. Jetzt das letzte Jahr habe ich überwiegend in einem Projekt verbracht, wo wir ja, also zumindest für unsere Organisationen neue Software entwickelt haben. Also ich bin da noch sehr, sehr eng bei der Softwareentwicklung der Programmierung. Stefan Roock (it-agile): du jetzt noch mal auf diese gesamte Zeitspanne der letzten 25 oder 30 Jahre guckst, was würdest du sagen hat verändert bezüglich Agilität und der Verwendung in der Industrie? Johannes L.: So bisschen habe ich das ja vorhin schon angedeutet, dass das irgendwann von wir wollen das tun hin zu wir müssen das tun ging, also in den Teams, wenn man sich die Menschen anschaut, die tatsächlich bei der Umsetzung beteiligt sind, dann sind die Teams auch immer größer geworden, was dann eben dazu führt, es dann nicht aus einem Team wurden, dann typischerweise mehrere und das ist eigentlich immer weitergegangen. Also es wurde immer größer und der Versuch, da immer noch die agile Glocke drüber zu warfen und zumindest für mich sehe ich nicht, dass das gut skaliert. es geht da gar nicht speziell Agilität. glaube, Softwareentwicklung an sich skaliert nicht gut über ein Team hinaus. Da muss man schon sehr kämpfen und da hat man dann eben sehr, sehr viel mehr Reibung. Tatsächlich, ich aber jetzt aus dem Coaching und dem agilen Beratung schon so lange weg bin, kann ich gar nicht sagen, was sich in den letzten zehn Jahren geändert hat. Ich kriege die Stichworte mit, dann gibt es dann die ganzen größeren Frameworks, aller safe und so weiter. Ich höre selten irgendwie begeisternde Berichte darüber, so Leute die sagen, das funktioniert super. Aber das mag an der Auswahl der Menschen liegen, mit denen ich da spreche. Ich glaube, was sich nicht geändert hat, und das ist vielleicht das, was für mich auch der Kern von Agilität bleibt oder der Kern, den ich mitnehme, überall hin ist, dass wir typischerweise nicht wissen, wo wir hinwollen. Wenn wir an irgendeiner Software oder einem neuen System arbeiten, wir wissen nicht, wo hingeht. Und das war irgendwie so auch die Ausgangsposition. Wenn du nicht weißt, wo du hingehst, dann musst du eigentlich in kleineren Schritten arbeiten. Dann brauchst du Feedback-Zyklen, zu wissen, ob du in die richtige Richtung gehst und Dinge verbessern zu können. Ich glaube, das hat sich nicht geändert. Welche Feedback-Zyklen man braucht, wie viele und auf welcher Ebene. Ich glaube, das ist sehr, sehr kontextspezifisch. Das hat mit Größe der Teams zu tun, das hat mit Technologien zu tun, das hat mit Organisationsformen zu tun, woher die Menschen kommen. Aber dieser prinzipielle Mechanismus Feedback und möglichst kurze Schleifen zu haben. Und dann glaube ich, auch bleibt Softwareentwicklung ist, ist eine soziale Tätigkeit. Und wenn wir das versuchen wegzunehmen, da sehe ich eine ganze Menge Entwicklung, die versucht sozusagen, den Menschen und die Reibung zwischen den Menschen aus der Softwareentwicklung herauszudrängen, dann kommen wir eben auch zu einer Software, wo der Mensch keine Rolle mehr spielt. Und ich glaube, das ist ist eine starke Entwicklung, die wir sehen. Ich glaube oder ich hoffe, dass es sozusagen den anderen Bereich auch noch gibt. Menschen und Projekte, die sehen, dass das nötig ist für humane Softwareentwicklung, brauchen wir Menschen in diesem ganzen Konstrukt und Menschen, die sich auch aneinander reiben. Aber da sind wir schon fast bei der Wo geht's hin? Geschichte. Stefan Roock (it-agile): Genau, bevor wir dahin gehen, noch einmal ein paar Minuten zurück. Ich fand es spannend, dass du gesagt hast, Softwareentwicklung als solche skaliert nicht. Johannes L.: Ja. Stefan Roock (it-agile): Woran liegt das? Johannes L.: Vielleicht müsste ich da konkreter werden. Also ich glaube die Idee, dass man kohärente Systeme bauen könnte, die in sich in sich geschlossen funktionieren, logisch aufgebaut sind, eine Mensch-Maschine-Schnittstelle haben, die gut ist. Das, glaube ich, skaliert nicht. Das kann man in meiner Erfahrung immer nur für kleinere, kleinere Projekte, also das, was ein Team so machen kann, sicherstellen. Sobald man darüber hinauskommt, man sich eigentlich eher auf, ja, auf was bei verteilten Systemen passiert. Ich habe Dinge, die kommunizieren irgendwie miteinander, die haben irgendwelche Schnittstellen. Aber am Ende muss ich damit klarkommen, dass es in diesen Schnittstellen Fehler gibt, dass es diesen Schnittstellen Redundanzen gibt. Und das heißt eben auch in den Entwicklungssystemen. Ich habe ein smoothes, das Scrum of Scrum, was irgendwie genauso rund läuft, wie ich das in einem Team machen kann. Das habe ich nie funktioniert sehen. Und jetzt nicht nur mit Scrum of Scrum, sondern auch mit anderen Ansätzen, die irgendwie plangetriebener waren. Ich glaube, das funktioniert nicht. Einfach weil gute Software braucht diese Kohäsion. Und sobald du über eine gewisse Größe der Gruppe hinausgehst, können wir als Menschen diese Kohäsion nicht mehr gewährleisten. Ausnahmen mag es geben. In der Breite, glaube ich, ist das so. Stefan Roock (it-agile): Vielen Dank dafür. Genau, jetzt waren wir schon bei dem Punkt. Johannes L.: Du musst mir mal widersprechen, Du musst mir widersprechen und du sagen, aber ihr macht das, ihr könnt das skalieren. Ihr wisst, wie das funktioniert. Stefan Roock (it-agile): Du hast es selber schon ein bisschen eingeschränkt. Wenn man größere Systeme hat, dann bestehen die vielleicht aus miteinander kommunizierenden Komponenten, die vielleicht in sich kohärent sind. Aber übergreifend läuft es dann anders. Johannes L.: Ja, und diese Kommunikation geht dann halt oft schief. Und das ist Teil, wie das funktioniert. Das ist nichts, was man irgendwie überkommen könnte, indem man einen noch besseren Prozess irgendwie da draufsetzt. Stefan Roock (it-agile): Und ich bin nicht ganz sicher, ob ich dem zustimme. Also ich habe ja auch Fälle gesehen, die funktioniert haben mit mehr Und trotzdem ist auch in meiner Erfahrung ist Skalierung in Anzahl Leuten. Ich glaube, Martin Fauler hat das mal beschrieben als Complexity Booster. Also viermal so viele Johannes L.: Ja. Stefan Roock (it-agile): Leute zu haben, macht das Problem nicht viermal so schlimm, sondern 40 mal so schlimm. Johannes L.: Ja, dem würde ich zustimmen. Da muss man 40 Stefan Roock (it-agile): Ja, und das ist aus. Johannes L.: mal so stringent arbeiten und 40 mal bessere Regeln haben und einen kontrollierteren Prozess, das immer noch im Griff zu haben. Stefan Roock (it-agile): Da bin ich gar nicht so von überzeugt, dass Johannes L.: Okay. Stefan Roock (it-agile): mehr Struktur das Problem löst. Ich glaube, das hat eher dann mit diesem Punkt von Softwareentwicklung als soziale Tätigkeit zu tun. Also mit 40 Leuten kriegst du es halt nicht mehr hin, dass jeder ständig mit jedem redet. Johannes L.: Mhm. Stefan Roock (it-agile): Da stellt sich halt die Frage, wie strukturierst du diese soziale Tätigkeit und worüber schaffst du es noch, gemeinsames mentales Modell herzustellen, was dann nicht mehr über jedes Detail Und wie managst du den Rest so? Und besser kann ich es auch nicht in Worte schaffen. Johannes L.: Ja, also wir müssen sozusagen mit den Problemen leben in der Kommunikation und in der Interaktion. Ja, da bin ich ganz bei dir. Stefan Roock (it-agile): Oder dass man also eine Möglichkeit, das zu strukturieren, die ja auch gerne gemacht wird, ist halt, dass du irgendwie dann eine Reihe stabiler Teams mit festen Themenfeldern definierst. Im E-Business ja typischerweise in langer Customer Journey und dann hast du ein Team für die Inserate, ein Team für die Suche, ein Team für die Suchergebnisse, ein Team für den Checkout und so weiter. Und das funktioniert dann ja in sich Johannes L.: Ja. Stefan Roock (it-agile): häufig ausreichend gut. Johannes L.: Da hast du aber schon eine starke Einschränkung, Dann hast du nämlich diese Einschränkung, dass diese Bereiche halbwegs stabil sind und sein können. Und da bin ich zum Beispiel jetzt in einer Organisation, wo das gar nicht geht. Und deswegen funktioniert diese Art des Ansatzes zum Beispiel dort nicht. Stefan Roock (it-agile): Genau, und wenn du jetzt das so machst, mein Lieblingsfiktives Beispiel ist ja immer die Dating-Plattform für wo dann Hobbyzüchter von Rassekatzen sich Paarungspartner besorgen können, also Karta dann ist es im Grunde so wie Immobilienscout oder mobile.de nur, dass da Katzen statt Autos drauf sind. Da kann ich upfront wahrscheinlich sehr genau die Customer Journey definieren, dann kann ich meine Teams dahin zimmern und dann funktioniert das so. Johannes L.: Ja. Stefan Roock (it-agile): Aber wenn ich mehr Agilität und Innovation brauche, auch auf dem Gesamtprodukt und wie das gestaltet werden dann komme ich da genau in diese Probleme. Also ich Johannes L.: Ja. Stefan Roock (it-agile): habe jetzt diese acht Teams und nach drei Sprints stelle ich fest, es muss alles ganz anders sein. Also Customer Journey ergibt überhaupt keinen Sinn. Dann wird es schwierig. War das genug Widerspruch? Johannes L.: Das war genug Widerspruch. Ich bin damit einverstanden. Stefan Roock (it-agile): Gibt es aus deiner Sicht irgendeine vergessene, agile Methode, die eine zweite Chance verdient hätte? Johannes L.: ich glaube, alle Methoden, ich kenne nicht alle, aber viele dieser Methoden, die ich kennengelernt habe, die haben alle ihren Sweetspot. Und ich glaube, es geht darum, herauszufinden, wo die ihren Sweetspot haben. Aber typischerweise bräuchten wir dann noch einen viel größeren Punkt, alle diese unterschiedlichen Konstellationen, die es da draußen im Leben gibt, irgendwie abzubilden. Insofern nein. was ich vorhin schon erwähnt habe, ich glaube, Prinzip, dass es mehr den Menschen gehen müsste als Da steht Process and Tools, aber eigentlich müsste es auch mehr den Menschen gehen als die Systeme, die wir erstellen wollen. Ich glaube, das bräuchte eine sehr hohe... Ein Revival, weil ich glaube, viele der Probleme, die wir jetzt sehen, die hängen genau daran, dass wir immer noch denken, es geht die Software und nicht die Dinge, die wir mit dieser Software anrichten. im negativen Sinne oder lösen im positiven Sinne. Stefan Roock (it-agile): Jetzt nach vorne. Was kommt auf uns zu? Johannes L.: Was kommt auf uns zu? Wir erleben alle in der einen oder anderen Form den technologischen Umbruch. Ich würde behaupten, er wird uns aufgezwungen. Er ist nicht selbst gewählt in dem Sinne. Ein technologischer Umbruch kann ja auch sein. Es gibt hier etwas Neues und wir entscheiden uns, dass wir das tun wollen, weil es für alle das Richtige ist. Ich glaube, im Augenblick ist es genau umgekehrt. Es gibt hier einen technologischen Umbruch, von ganz anderen Motiven getrieben ist, also eher von kapitalistischen und noch schlechteren Prinzipien. Naja, und jetzt muss man damit irgendwie umgehen. Und man kann damit umgehen, indem man sich da reinwirft und sagt, naja, es ist unvermeidbar, die Unvermeidbarkeitsdoktrin annimmt und sagt, naja, dann tu ich halt mal das, was ich tun muss und versuche, mich möglichst gut da drin zu bewegen. Oder ich kann sagen, Ich tue alles, dafür zu sorgen, dass wir die Technologie noch so einsetzen, wie wir das wollen. Ich bin da vergleichsweise pessimistisch. Stefan Roock (it-agile): Darf ich einmal dazwischen gehen? Nur sicher zu gehen, wir reden über KI. Johannes L.: KI? Natürlich. Stefan Roock (it-agile): Weitere! Johannes L.: Also ich hasse das Wort KI, weil das einfach so viele Dinge in eine Kategorie packt, die nicht in eine Kategorie gehören. Also ich sag mal, wir reden bei der Softwareentwicklung ganz konkret generative KI auf unterschiedlicher Ebene und wir reden eigentlich über hochskalierte, überskalierte generative KI. Davon geht das. Und vielleicht machen wir dazu ja nochmal ein Podcast auf anderer Ebene. Insofern will ich da nicht so tief einsteigen in warum ich glaube, dass das der falsche Weg ist, zumindest so wie es jetzt eingesetzt wird. Ich bin relativ pessimistisch, dass wir das irgendwie in die richtige Richtung biegen, aber nicht pessimistisch genug, um nicht zu sagen, naja, ich versuche trotzdem, mich dafür einzusetzen, erstmal das Schlimmste abzuwenden. Also insofern. Wenn ich mir die Konferenzen anschaue, auf denen ich in letzter Zeit war, da gibt es so eine klare Teilung auch. Ich weiß nicht, ob ein Drittel ein Drittel stimmt, aber es gibt irgendwie in dieser Größenordnung ein Drittel der Leute, die komplett in diese Richtung abfahren und die bestimmen ungefähr zwei Drittel der Vorträge auf diesen Dingen. Dann gibt es ein Drittel der Leute, die einfach zugucken und mitmachen, weil sie denken, oh, das ist der Hype, da muss ich irgendwie, da höre ich mir das jetzt mal an und mache da mit. Und dann gibt es ein Drittel der Leute, die einfach nur den Kopf schütteln und die Welt nicht mehr verstehen. Und ich würde mich eher zu der letzten Gruppe zählen. Und das fand ich relativ überraschend, weil ich ja jetzt in den 30 Jahren eigentlich fast immer auf der Seite derer war, die gesagt haben, neue Technologien, das ist gut. Ja, die haben ihre Nachteile, aber Wenn man sich richtig einsetzt und dann kann man da eigentlich immer was Positives raus sehen. Und jetzt bin ich mal auf der anderen Seite und insofern ist es ganz spannend. Aber ich ich glaube, das wird einen riesigen Umbruch geben ich kann nicht in die Zukunft gucken, aber es wird nicht schön werden. Und das wird das Berufsleben gerade von Softwareentwicklern sehr, sehr verändern. Und wenn es nur ist, der Druck noch größer wird. Weil ich meine, das, wir ja alle sehen oder was ich nicht glaube, dass irgendjemand erwartet, ist, hier ist eine Technologie, nehmen wir mal an, sie würde funktionieren, also sie würde sozusagen die Produktivität, was wir auch immer darunter verstehen, erhöhen. Richtig wäre ja dann zu sagen, okay, jetzt können wir alle langsamer machen, jetzt können wir besser drüber nachdenken, wir können drüber nachdenken, was wir tun wollen. Wir können von 40 Stunden wieder auf 35 gehen. So habe ich angefangen in den 90er Jahren mit Vollzeitvertrag 35 Stunden. Aber das passiert ja nicht, sondern es passiert ja genau das Gegenteil. Der Druck wird dadurch größer. Also insofern glaube ich, wird es ein sehr böses Erwachen werden. In welche Richtung das dann geht. Ja, da können viele Blasen platzen, da können viele Dinge passieren. Ja, also insofern kein guter Ausblick. Aber ich habe ja nur noch zehn Jahre bis zur Rente. Das ist ja sozusagen, woran ich mich da so ein bisschen festhalten kann. Und meine ersten Rentenverträge laufen, glaube ich, fangen so irgendwann in, wie bin ich jetzt, fangen in drei Jahren an. Also da kann ich schon runterfahren. Stefan Roock (it-agile): Solange hält es noch ohne KI aus. Johannes L.: Ich komme ohne KI zurecht, ob mich dann noch jemand will, ist ja immer die Frage. Diese Angst, irgendwas zu verpassen, ja das, was ich auch bei vielen meiner Kollegen irgendwie spüre. Ja, gar nicht das Gefühl, ja, das will ich tun und das ist besser, sondern was passiert mit mir, wenn ich abgehängt habe? Stefan Roock (it-agile): Für unsere Zuhörer, wir werden diesen weiteren Podcast nicht vielleicht machen, sondern das haben wir schon verabredet. stay tuned. Wir werden was machen nur zu diesem Thema und dann eben ein bisschen abseits des Mainstreams. Keine Jubelveranstaltung, sondern wo wir auch die dunkleren Seiten genauer beleuchten. Gibt es irgendwas, womit du dich gerade so beschäftigst? Irgendwas Cooles, Neues? Johannes L.: Also ich bin tatsächlich das Projekt, von dem ich schon gesprochen habe, da geht es öffentlichen Verkehr, also Züge, öffentlichen Nahverkehr und das finde ich jetzt ein sehr spannendes Thema. Einfach weil ich feststelle, dass ich über Algorithmen und ähnliche Sachen einfach super wenig weiß, ja, trotz 30 Jahren in der Softwareentwicklung, denn da hilft einem kein Dykstra oder ähnliches, da muss man zu anderen Sachen zurückgreifen. Also insofern finde ich das thematisch sehr interessant und man kann diese Software komplett ohne KI entwickeln, wenn man will. Naja, dann arbeite ich an meiner prekären Zweitkarriere. Was macht man, wenn man dann irgendwie als Softwareentwickler nicht mehr up to date ist und als singer-songwriter? Nicht, dass ich talentiert wäre, aber es macht Spaß. Stefan Roock (it-agile): Fällt dir noch was ein? Johannes L.: Ich hab da noch so ein paar Sachen stehen, aber die passen nicht auf die Fragen, die bisher kamen. Insofern... Nee, ich glaube, ich glaube, das passt eigentlich ganz gut. Ja. Stefan Roock (it-agile): kannst die Fragen auch zurechtbiegen, damit sie auf deine Antworten passen. Johannes L.: Vielleicht interessanterweise habe ich ja schon mal einen Podcast gemacht zu dem Thema Rückblick aufs agile Manifest. Stefan Roock (it-agile): Mhm. Johannes L.: 2008 hat damals Frank Westphal in seinem Tonabnehmer nämlich auch so eine Diskussionsrunde gehabt. Ja, damals auch. Ich glaube, bis auf Frank Westphal selbst sind alle Teilnehmer auch irgendwo bei euch dann mal dabei. war Jutta, Henning, Jens. Ich glaube, Jutta, Henning, Jens und ich. waren, glaube ich, die Interviewten. Und damals, ich habe mir das nochmal angehört, es war halt eine ganz andere Sicht auf das Thema. Also manche Sachen hatten wir auch schon identifiziert, die für die Zukunft wichtig waren. Aber wir haben damals schon noch sehr an diese das Grundprinzip Agilität ist die Veränderung in der Softwareentwicklung geklaubt. Ich würde vermuten, jeder von uns ist mittlerweile auf die ein oder andere Weise da ein nüchterter Haun hat gesagt, es ist nicht so gekommen, wie wir es gehofft haben. Stefan Roock (it-agile): Und gleichzeitig hatte es trotzdem einen massiven Effekt. Johannes L.: Auf jeden Fall, Also ich kann auch nicht sagen, wir wären jetzt an einem besseren oder schlechteren Ort, wenn es das agile Manifest nicht gegeben hätte. Weil es gibt ja Leute, die sind da sehr deutlich, die sagen, das Framen als agil war eine Niederlage. Ja, das war eine Niederlage für die Leute, die mehr bei dem Extreme Programming waren, weil das den Begriff und die Konzepte aufgeweicht hat. Und es gibt ja auch die anderen, sagen, es war unbedingt nötig, dass auf diese auf so einen sehr gefälligen Begriff zu führen, sonst hätte es nie in die Breite gehen können. Und dann ist halt die Frage, es in der Breite tatsächlich, ist das agil oder ist es nur etwas, was das Label trägt heute? Stefan Roock (it-agile): Okay, dann vielen Dank für deine Zeit und deine Einsichten, Johannes. Johannes L.: Vielen Dank, dass ich da sein durfte. Stefan Roock (it-agile): und ich freue mich auf den Folge-Podcast zum Thema generative KI. Johannes L.: Sobald wie möglich.