Latest / einfach gelöst / #12: Sebastian Eichner - Feedback statt Frust
Transcript
- Stefan Roock (it-agile): Hallo und herzlich willkommen zum IT Agile Podcast Einfach gelöst. Heute habe ich den Sebastian Eichner hier. ein alter Bekannter. Fokus auf bekannt, nicht auf alt. Auch wenn wir zwischen alle ein bisschen gereift sind, glaube ich. Hallo Sebastian. Sebastian: Hahaha Hallo Stefan, schön hier zu sein. Stefan Roock (it-agile): Magst du dich kurz vorstellen für die, die dich noch nicht kennen? Sebastian: Ich bin Sebastian Eichner, bin jetzt tatsächlich auch ein bisschen alt, 48 inzwischen, seit fast der Anfangszeit der XP-Zeit hier in Hamburg, so in der Community, dabei und habe mein Berufsleben hier als freiberuflicher Berater und Softwareentwickler verbracht und den größten Teil der Zeit hier im Hamburger Umraum gearbeitet, bin hier also recht fest verankert. Stefan Roock (it-agile): Vielen Dank. Jetzt hast du schon erzählt, XP-Zeiten. Also das heißt, dein erster Kontakt mit Agil war Extreme Programming. Sebastian: Das stimmt tatsächlich, habe damals, also so als das Agile Manifest geschrieben wurde, war ich gerade dabei, die letzten Monate oder das letzte halbe Jahr meiner Diplomarbeit im Studium zu machen. gerade die Schlusszeit. vom Agile Manifest habe ich gar nichts mitgekriegt zu der Zeit. Und während dieses letzten halbes Jahres hat dann Frank Gewestfall bei uns an der FH mal einen Vortrag gehalten. über agile Softwareentwicklung und speziell über Extreme Programming. Und ich habe den damals gehört und habe es nicht verstanden. Es machte keinen Sinn für mich. wusste nicht, wie das funktionieren sollte. Während des Studiums haben wir noch nicht einmal über über Test getrieben Entwicklung gelernt. Wir hatten automatisierte Tests, aber das war auch nur so nebenbei. Und eigentlich hat man So viel früher gehofft, dass es funktioniert, und sich am Ende einmal durchgeklickt und gewartet, bis irgendwas kaputtgeht. Und das, was Frank erzählte, konnte ich einfach noch nie nachvollziehen. Und dann habe ich später das Buch von Ken Beck mal gelesen. Also das erste, das war relativ zeitnah, ich glaube ein, zwei Monate danach. Und dann begann das alles wahnsinnig viel Sinn zu machen. Das hat mich fasziniert. Ja genau, in der Folgezeit bin ich dann sehr schnell bei der XP User Group gelandet, der Extreme Programming Users Group hier in Hamburg. Und das war faszinierend, waren wahnsinnig viele gute Leute. Haha. Stefan Roock (it-agile): Hast du es in der Praxis irgendwann angewendet? Sebastian: Ja, haben natürlich immer nur so mit Teilen davon gearbeitet. Zeit damals war noch so die Zeit der großen, also wo man wahnsinnig viel für Agenturen hier in Hamburg gearbeitet hat. Alle Leute, die bei mir an der Uni waren und irgendwas in der Richtung gemacht haben, haben für die Hamburger Agenturen gearbeitet, also Webseiten gebaut, so die HTML-Krams damals zurecht gebastelt. Und dann kamen PAP und Java, vor allem hatte große... großen Anteil da dran. Und wenn man da an die Zeit zurückdenkt, da war das alles noch rein technisch war das einfach schwierig, dort testgetrieben zu entwickeln. Es gab so J-Unit, aber das hatte noch nicht die Verbreitung, zumindest nicht in den Agenturszenen. Die sind ja auch so konstruktionsbedingt ein bisschen kurzfristiger ausgelegt als so Produkt- Softwareentwicklung. Und da hatte ich Gefühl, war es erstmal schwierig umzusetzen. An sich war die Zeit aber interessant, weil dann gerade, ich glaube, 2002 ungefähr, ein bisschen später, 2004, 2005, kam ein Buch raus, das hat mich dann schwer geprägt, das hieß J2EE Development Without EGB. J2E ohne die Enterprise Java Beans von Rod Johnson, großartiger Autor. Und der hat beschrieben, wie Java Entwicklung eigentlich aussehen könnte jenseits der Welt, so unfassbar anstrengend war damals. Also EJBs die wir damals entwickelt hatten, die hatten diese lokalen und remote Facades und in der Theorie dachte man, man schreibt die einmal und dann ist es mir egal, wo das läuft, bei mir lokal oder irgendwo remote. Das stellte sich natürlich sofort als Unsinn raus, weil Granularität von Methoden aufrufen und so. Das ist schon ein Unterschied, wie schnell man das aufrufen muss. Und das schreibt man für lokal einfach anders als für remote. Und Rod Johnson hat all diese Widersprüche mal zusammengefasst und hat was Neues entwickelt. Der hatte damals das Spring Framework in dem Rahmen entwickelt, die allererste Version. Und damit schien es mir dann möglich zu werden, Java-Entwicklung tatsächlich in dem Umfeld, wo ich damals war, agil anzugehen, leichtgewichtig anzugehen. Das war ein Augenöffner für mich, weil es hat mir gezeigt, wie stark die Technologie da mit reinspielt in die Möglichkeiten, man hat. Und das, was Rod Johnson damals mit Spring möglich gemacht hat, das gab es vorher in der Java-Welt, die ich kannte zumindest nicht. Heute ist das völlig normal. Also J2E heute ist was völlig anderes als damals. Und ich glaube fast jeder, der mit Java arbeitet, hat mit Spring Kontakt und den ganzen Dingen, die daraus entstanden. Damals kam Hibernate auf und so. Und das war großartig. Dann wurde das möglich. Wir konnten Dinge außerhalb dieses ganzen EGB-Containers instanzieren, weil man mehr mit Podules gearbeitet hat. das wurde sehr viel flüssiger und leicht wichtiger. Das war also der Moment, wo wir so bisschen angefangen haben, die Richtung zu gehen, wo auch Testgetriebe entwickelt konnten, auch in Java. ich glaube, der eigentlich wichtigste Schritt war für mich, das war auch ein anderes Buch zu der Zeit, das hieß... From Java to Ruby. Und es war ein dünnes Buch, was erzählte, wie Ruby-Entwicklung eigentlich aussieht und mit dem Vorwissen aus Java. Und von Bruce Tate war das auch ungefähr zu der Zeit veröffentlicht. Und das hatte ich gelesen und das war dann die zweite große Erleuchtung quasi, als ich gesehen habe, wie schön Ruby-Entwicklung, wie schön Ruby-Code aussehen kann, wie schön man mit Metaprogrammierung Dinge lösen kann, für die Java damals noch keine gute. Stefan Roock (it-agile): ... Sebastian: Alternative hatte. gab so eine einfache, es gab Aspect J, hieß das glaube ich, so eine Aspect orientierte Bibliothek. Aber das ging alles weiter darüber hinaus, was in der Rubywelt möglich war. Und ich glaube, dem Punkt, ab dem habe ich Agile-Entwicklung in der Praxis gesehen, weil das in der Community auch viel verbreitet. Aber also dort war es der Weg, Software zu entwickeln. Während man in Java noch alle langwierig überzeugen musste, dass man es anders machen sollte als vorher, ist Ruby und vor allem Rails einfach dort gestartet. Seitdem wollte ich eigentlich nichts anderes mehr machen. Das war die Welt, in der ich mich bewegen wollte. Stefan Roock (it-agile): Und hat es dann auch geklappt? Sebastian: Das hat geklappt. ich würde sagen, haben wir richtiges XP-Entwurf gemacht. Ich glaube nicht, dafür waren die Kompromisse zu sehr da, die man in den Firmen immer der Realität aushandeln musste. Aber wir haben ganz viele Inspirationen daraus genommen. Ich glaube, in dieser Anfangszeit war das zum Beispiel bei QIBE hier. Das war so eine Review-Plattform. Man konnte da Restaurants und so bewerten. Hamburg trifft man manchmal noch unsere Aufkleber, die jetzt seit unfassbar langer Zeit in den Schaufenster kleben müssen. Die Plattform wurde irgendwann gekauft, die gibt es schon lange nicht mehr unter dem Label. da haben wir, glaube ich, da haben wir schon viel aus dieser testgetriebenen Ecke benutzt. Da waren gute Entwickler, die das verinnerlicht hatten und deren Denk einfach dort war. Und wir haben dann doch relativ komplexes System nach und nach aufgebaut. Man kann iOS oder Android später dazu, nachdem man Web-Apps gemacht hat. Oder nicht Web-Apps, sondern native Apps. das war vor allem der testgetriebene Aspekt. Und auf jeden Fall automatische Tests zur Absicherung zu haben bei den Leuten, die das nicht TDD-like gemacht haben, das war unersetzlich. Ich kenne auch niemanden, der in der Welt programmiert, also in der Ruby-Rails-Welt. und der keine Testschreib ist, war einfach schon vor 20 Jahren dort gang und gäbe. Genau, und ich fand damals aber eigentlich, also das ist ja der technische Track, der war für mich ganz wichtig, zu sehen, wie kann das möglich werden, mit welchen Technologien können wir das machen. Was ich genauso spannend fand, war, dass sich ⁓ diese XP-Szene so eine aktive Community formte damals. Also die Hamburger XP-User Rup hatte irrsinnig viel Know-how gesammelt und Stefan Roock (it-agile): Mhm. Sebastian: Da habe ich, glaube ich, die meisten Impulse für alles, was ich danach in Softwareentwicklung mir angeguckt habe, die gehen letzten Endes auf Impulse aus der Zeit zurück. Dann standen die ersten Konferenzen raus, also die Days hier in Deutschland, die deutschen XP Days, waren sehr lebendig und dieses Agile Coachcamp, das wir dann aufgebaut haben, was in Rückersbach jetzt ist und zu so einer eigenen, also ganz festen Konstante geworden ist in der agilen Welt. Diese Community war wahnsinnig wichtig. Stefan Roock (it-agile): ist dann so nach den Anfangsjahren passiert? Sebastian: Interessant fand ich, am Anfang mussten wir diese agilen Sachen und Scrum Sachen hier noch erklären und im Zweifel selbst diese Rollen einnehmen, das voranzubringen. wenn ich jetzt so in Firmen bin, es ist schon sehr auffällig wie normal, dass für alle geworden ist und viele kennen diese Wurzeln gar nicht mehr. Heute muss man mit niemandem mehr darüber sprechen, ob man Tests schreibt. wir haben CICD Pipelines. Es ist völlig normal, dass die Leute die benutzen. Das war damals halt gar nicht normal. Man hat den Lokal laufen lassen und hat seinen Mitprogrammierern gesagt, ja, habe ich alles gemacht, funktioniert. Und das ist ein wirklich großer Unterschied. Wir sind halt auf dieser technischen Ebene so viel weiter. Und die Entwickler, heute von den Unis kommen oder mit denen man zusammenarbeitet, die aus einer jüngeren Generation sind, die haben das verinnerlicht. Für die ist das der normale Zustand und die können sich gar nicht vorstellen, das anders zu machen. Ich habe im Studium noch diese Pflichtenheft-Lassenheft-Sache gehabt. muss ja auch mal üben, so etwas zu schreiben und danach umzusetzen. Und es ist heute völlig anachronistisch. Also kann man sich nicht mehr vorstellen, dass man glaubt, damit zu einem guten Ziel zukommt. Stefan Roock (it-agile): Hm. Sebastian: Genau, das ist beeindruckend, wie weit sich das verbreitet hat. Es ist auch beeindruckend, dass Ideen ⁓ Vollständigkeit, also von einer wirklich agilen Produktentwicklung, wie selten ich die trotzdem draußen antreffe. Alle haben so Aspekte übernommen und alle Teams machen Dailys und planen vielleicht für ein, zwei Wochen. Das ist ja alles gut und die profitieren alle davon. Ich glaube, selbst wenn man da stehen bleibt, hat man schon einen sehr viel besseren Stand, als man das vorher hatte in der Regel. Implementierung von wirklich guter agile Entwicklung sehe ich tatsächlich selten da draußen. Stefan Roock (it-agile): Was meinst du, woran liegt das? Sebastian: Ja, wo dran liegt das? Ich glaube, meine persönliche Hypothese. Ich glaube, dass es zu einem großen Teil mit den Grundstrukturen von Machtverhältnissen in Organisationen zusammenhängt. Eine Stelle, an der man das gut sieht, finde ich, in welchem Umfeld Retrospektiven gemacht Wir erwarten das heute eigentlich von allen Entwicklungsteams. Wenn man dann jetzt bisschen höher geht auf Management und Oberesmanagement, dann gibt es das nicht. Und ich glaube, das hat schon triftige Gründe. Ich glaube, nicht überall will man diese Transparenz haben. Die ist nicht immer hilfreich für die Leute, die dort arbeiten. Und letzten Endes, wenn man das ganz konsequent durchdenkt, liegt es mit daran, wie Firmen organisiert sind. Ich glaube unsere normale Art, Firmen aufzubauen. und die zu finanzieren mit Stakeholdern, mit Aktiengesellschaften und so, die sind glaube ich nicht richtig kompatibel mit dem Ansatz, wenn man den ganz durchziehen möchte. Das ist so bisschen mein Gefühl. Ich glaube, man eigentlich dort ansetzen muss und wenn man das ganz konsequent durcharbeiten möchte. Stefan Roock (it-agile): Mhm. Sebastian: und dann zu einer Stelle kommen, tatsächlich alle in diesem Produktspiel spielen. Ich habe für mich so das Bild, es gibt in dem Berufsfeld halt ein Spiel, wir spielen. wollen ein gutes Produkt entwickeln. Und gleichzeitig spielen vor allem in größeren Organisationen alle natürlich auch so ein Karriere-Spiel. Und müssen irgendwie eher persönliches Fortkommen und Karriere-Entwicklung mit planen. Und ich glaube, je größer eine Organisation ist, desto eher kommen die auch mal in Konflikt. Agilität und Agilentwicklung, die Transparenz, die sitzt genau an der Stelle, wo diese Konflikte sichtbar werden. Und da muss man sich entscheiden, wohin schlägt man jetzt aus. Geht man eher in diese Richtung, in diese Richtung? Auf jeden Fall kollidierende Interessen. Stefan Roock (it-agile): Und siehst du irgendwelche Anzeichen, dass sich da was ändert? Also du sagst, da müsste sich grundsätzlich was ändern? Sebastian: Also ich glaube... Ich glaube nicht in der... Breitenmasse. Und vielleicht muss es das auch nicht. Vielleicht profitieren wir auch genug, wenn wir Agilität auf diesen Entwicklungs- und Projektplanungsebenen einsetzen. Und in der Anfangszeit von XP, glaube ich, hatten wir oder hatte ich auf jeden Fall schon die Utopie, dass ganze Organisationen so funktionieren können. Dass da alle in eine Richtung laufen und alle ein gemeinsames Verständnis haben. Aber ich glaube, das muss nicht sein. Vielleicht bringt das auch gar nicht so viele Vorteile, wie ich mir damals erhofft habe. Es gibt ja manchmal dieses Bild, dass man versucht, so viel gemeinsames Verständnis und gemeinsame mentale Modelle aufzubauen, dass alle zu Fragen im Prinzip dieselbe Meinung haben. Also dass wir ganz viel allein mitherstellen. Und da geht manchmal verloren, dass wir auch Konflikte ... bewusst einbauen, also Rollen auch so definieren, dass sie in unterschiedliche Richtungen ziehen und wir da bewusst Konflikte erzeugen möchten, dass der Product Owner in Scrum Product Owner ist und der Scrum Master Scrum Master und Entwickler Entwickler hat ja irgendwo auch seinen Sinn. Wir wollen ja gar nicht, dass alle alles machen, weil man dann diese Konflikte nicht sichtbar machen würde, nicht austragen würde, sondern so bisschen unter den Teppich kehren. Und aus der Sicht ist es vielleicht gar nicht so blöd, dass Firmen, Agilität umsetzen, da immer in Spannung stehen und es Interessenkonflikte gibt, weil auch das, was, wenn ich sage... in dem bestehenden System oder so wie aktuell Firmen aufgebaut sind, ist es glaube ich schwierig, Agilität ganz durch die ganze Firma durchdringen zu lassen. Dann ist das ja auch ein Spannungsfeld zwischen der Realität da draußen und der Realität des Projektes und der Organisationsstruktur innen. Das ist wahrscheinlich gut, dass es Vertreter für alle Interessen dabei gibt. Also ⁓ deine Frage zu beantworten, ich glaube nicht, dass es sich so groß ändert, nicht der Aspekt, ich gerade angesprochen habe. Genau. Uns ist vielleicht nicht schlimm. Stefan Roock (it-agile): So, jetzt hast du im Grunde von agilen Unternehmen gesprochen. Das agile Manifest thematisiert das ja nicht. Das thematisiert ja Softwareentwicklung. Was bedeutet denn agiles Unternehmen für dich? Sebastian: Den Kernpunkt würde ich glaube ich auf das Lernen in Feedback-Schleifen legen. Wenn ich Leuten, die gar keine Ahnung habe, ganz knapp beschreibe, was Agilität für mich ist, dann vereinfache ich es immer auf passende Feedback-Schleifen etablieren und priorisierte Listen. Die hat sich mal ganz vereinfacht gesprochen. Diese Feedback-Schleifen zu etablieren über verschiedene Level und verschiedene Prozesse hinweg, das ist, glaube ich, ... Stefan Roock (it-agile): Mh. Sebastian: essentiell und daraus entsteht das Lernen, dass wir auf Rückmeldungen der Außenwelt, auf Rückmeldungen von inneren Akteuren reagieren können und daraus lernen. Und ich glaube, die priorisierten Listen würde ich da jetzt gar nicht so mit reinbringen, aber das ist natürlich der Aspekt. Können wir uns entscheiden, was das Wichtigste ist als Unternehmen. Und ein agiles Unternehmen wäre für mich ein, dass das darüber Klarheit schafft, dass also diese Prioritäten klar kommunizieren kann und über alle Ebenen und dass ich aktiv darum bemühe, Feedback schleifend zum Lernen und Anpassen von Verhalten aufzubehen. Mir persönlich ist es auch relativ egal, was man dafür benutzt und ob das, was man dann als Lösung für sich entdeckt, jetzt eine agile Methode unter dem Label ist oder was selbst gebastelt ist. Ich glaube, es gibt viele Möglichkeiten, wie man diese Feedback-Schleifen aufbauen kann. Und wahrscheinlich gibt es auch viele Modelle da draußen aus unterschiedlichen Richtungen, die gar nichts mit Agilität zu tun haben, die aber genau das mit reinbringen. Stefan Roock (it-agile): Was hast du denn in die Richtung erfolgreich gesehen? Sebastian: ⁓ ⁓ Was mich sehr beeindruckt hatte, war eine große Firma, die wahnsinnig routiniert darin war, ihren Nutzern in Kontakt zu sein. wenn Firmen so einen festen Rhythmus etabliert haben und einen Ablauf, sie Nutzer einladen, zu User-Tests zum Beispiel. Und ich als Entwicklungsteam weiß, wenn ich jetzt eine Idee habe, kann ich in spätestens 14 Tagen mich mit jemand hinsetzen, der zu uns ins Büro gekommen ist und wir können dort Prototypen durchspielen. Und wir können ihm Fragen stellen oder was immer uns weiterhilft, unser Konzept zu verfeinern oder die Software in die nächste Iteration zu planen. Wenn man es schafft, so zu institutionalisieren, das fand ich sehr beeindruckend. Ich habe das in einer Firma gesehen, die das sehr konsequent gemacht hat und wo einfach kein Overhead entstand daraus. Als Entwicklungsteam konnten wir das jederzeit nutzen, mussten uns nur eintragen und dann haben wir relativ schnell einen Platz gehabt, wo wir mit einem Nutzer Dinge validieren konnten. Und die Nähe zu Usern, die vermisse ich manchmal. Wir arbeiten dann doch oft mit mit Proxys oder mit Annahmen. Ich sehe aber, wie Entwickler darauf reagieren, wenn sie mit einem echten Nutzer zusammen sind oder wenn wir es schaffen, in Reviews tatsächlich die Endnutzer dabei zu haben, die wirklich diese Software einsetzen und Entwickler mitbekommen, was für Probleme entstehen aus Fehlern, die sie vielleicht gemacht haben oder aus Features, die zwar gut gedacht sind, aber nicht auf die Realität passen, auf das Einsatzfeld passen. Das direkt zu hören von einem Endnutzer meiner Software, das hat eine ganz andere Auswirkung. eine viel tiefere Wirkung und ist viel prägender, bleibt länger erhalten bei den Entwicklern. Deshalb probiere ich immer den, das ist eine Feedback-Schleife, auf die ich viel Wert lege. Also können wir die Nutzer in den direkten Kontakt mit den Entwicklern bringen. und können unsere Entwickler darüber wirklich erfahren, was es heißt, dass sie gerade ein Release rausgegeben haben, was vielleicht in bestimmten Situationen abstürzt und sie hören, dass das in der Realität wirklich so ist. haben da 15 Kunden, die stehen jetzt und die warten und wir können nichts tun, weil unsere Software nicht mehr arbeitet. So, was anderes als ein Gyro-Ticket. Stefan Roock (it-agile): für das Beispiel. Ich glaube, das hat es noch mal plastischer gemacht. Wir ja über Extreme viel gesprochen, Scrum so bisschen angerissen, da gab es ja noch mehr. Gibt es irgendeine vergesse oder wenig bekannte agile Methode, die eine zweite Chance verdient hätte? Sebastian: Eine zweite Chance. Ich glaube, ich denke nicht so sehr an Agile mit Toden in dem engeren Sinne dabei. Das, was ich mir manchmal wünsche, was vergessen ist, ist ein bisschen mehr Blick auf andere Domänen zu lenken, die diese agile Softwareentwicklung so stark mitgeprägt haben. Für mich ist ein Beispiel, was ich ganz oft verwende, sind die Bücher, die Christoph Alexander in den 70ern geschrieben hat. Ein Architekt, der zu Vordenkern von einer Prinzip agilen Architektur gehörten. Das hieß damals nicht so und es hatte auch noch keine Verbindung zu unserer Softwareentwicklung. Aber er hatte dieses Buch, Pattern Library ist es glaube ich, geschrieben, wo er Architektur Muster beschreibt, wie eine Haustür gestaltet werden muss oder wie Fenster arrangiert werden in einem Gebäude. Und ich sehe so viele Parallelen zwischen seiner Arbeit und dem, was wir nachher in Softwareentwicklung gemacht haben und dem, was wir heute tun. Das ist so bisschen eine Verbindung, die ich mir wünschen würde, wir als Community wieder stärker im Kopf haben könnten. Ich glaube, da können wir ganz viel daraus lernen. Er hat ja probiert, Architektur so zu beschreiben, dass die Menschen, in einem Gebäude wohnen, wieder daran teilhaben können. Er hat stark kritisiert, was Architektur ist, was heute Architekten in die Hand gelegt wird, die mit eigenem Vokabular, eigenen Prozessen darauf arbeiten und wir nur noch Auftraggeber sind und am Ende ein Gebäude kriegen. Ihm schwebt eigentlich vor, dass das schwebte, das war ein paar Jahre gestorben, dass man da viel partizipativer war. mit umgeht, es gibt einige ganz coole Dokumentationen, wo man das sieht und dann bauen die halt da, wo später ein Gebäude entstehen soll, da stehen halt so ein paar Stangen im Boden und dazwischen sind weiße Bahnen gespannt, so Betttücher ähnlich und damit modellieren sie das Gebäude auf dem tatsächlichen Grundstück, wo es später stehen wird. Und die benutzen also Prototypen für Sachen, wo wir sagen würden, das ist gar nicht so einfach möglich. ich jetzt mit Prototyping zu machen, aber darüber überlegen sie, wo sollen Straßen sein, wo müssen Eingänge sein, wie muss was vielleicht anders ausgerichtet sein. Und dieses Partizipative, dass Menschen direkt teilnehmen daran, das ist was, wo ich oft dran denke. Das haben die für Architektur zumindest modellweise hingekriegt. höre immer wieder, er hätte auf das Denken über Architektur großen Einfluss gehabt, weniger auf die Praxis von Architektur. Aber die haben das auf jeden Fall mal durchgespielt, wie das sein kann. Und... Ich glaube, das bindet ein bisschen an meinen Impuls vorhin, einen Endnutzer in den Kontakt mit den Entwicklern zu bringen. Das fehlt mir manchmal, diese Direktheit. Und die Arbeiten von Christopher Alexander sind so ein Punkt, den benutze ich gerne als Paralleler. Wenn wir öfter dran denken und vielleicht mehr Leute mal die BBC-Doku How Buildings Learn, die ist nicht direkt über über seine Arbeit, aber über ganz nahe damit Verwandte. Da können wir, glaube ich, noch viel mitnehmen an Impulsen dafür, wie wir agile Softwareentwicklung wieder ein bisschen beleben können oder andere Schwerpunkte setzen dabei. Das wäre ein Impuls, wenn ich im weiteren Sinne agile Methode interpretiere, dann würde ich das gerne ein bisschen mit in die Gegenwart nehmen. Stefan Roock (it-agile): Ja, das ist auf jeden Fall ein cooler Gedanke. Mein Gefühl ist auch, dass wir früher... mehr mit Transfergeschichten experimentiert haben. ja auch ganz viel mit, welche Sachen aus dem Toyota Production System lassen sich übertragen und Sebastian: Mhm. Mhm. Stefan Roock (it-agile): Alles mögliche andere, ja, glaube da. Und vielleicht ist da so ein Punkt, dass wir es früher spielerischer gehandhabt haben. Sebastian: Ja, das stimmt. Und vielleicht noch bisschen weitergedacht haben. Ich erinnere mich gerade daran, es gab ja auch immer mal Bestrebungen, diese ganze CFO-Seite, also wirklich die Art, wie planen wir die Finanzen in einer Firma und wie arbeiten wir damit, die Agile aufzustellen. Und das ist, glaube ich, auch so bisschen in Vergessenheit geraten, oder? Ich lese da auf jeden Fall nicht mehr viel über Impulse. Ich glaube, sind sehr in dem Produkt- und Softwareentwicklungsbereich unterwegs. Stefan Roock (it-agile): Wobei ja gerade diese Finanzplanung hat ja einen massiven Einfluss auf die Produktentwicklung und was da geht und nicht geht. Also wenn in Jahreszyklen budgetiert wird, dann... Sebastian: Mhm. Mhm. Stefan Roock (it-agile): dann nimmt man, wenn man Pech hat, auch wieder bei Lasten und Pflichten heften. Sebastian: Ja, genau. Das ging in der Community ein bisschen unter. Das haben wir nicht so aufgenommen. gab doch den Betacodex. Stefan Roock (it-agile): Genau, Beyond Budgeting war glaube ich die Bewegung da. Sebastian: Beyond Budgeting, so hieß es ursprünglich. Da waren wahnsinnig wertvolle Impulse drin, aber die haben es zumindest in unserer agilen Software-Ecke nicht so richtig vorwärts geschafft. Es ist immer so ein getrenntes Stream geblieben, ist mein Eindruck. Stefan Roock (it-agile): Wobei, glaube ich, auch zwischen den beiden Professionen sehr großer Abstand herrscht, so im gegenseitigen Verständnis Sebastian: Es hätte vielleicht einiges einfacher gemacht, wenn wir da mehr rein investiert hätten, das zusammenzubringen, da Brücken zu bauen. Stefan Roock (it-agile): glaubst du denn, was die Zukunft für uns bereithält? Sebastian: Also für mich ist die große Frage, wenn ich jetzt an Zukunft denke in unserem Bereich, tatsächlich wie entwickelt sich das mit KI-Integration weiter? Das finde ich auch immer mit einem der interessantesten Aspekte dabei. Das stellt glaube ich vieles in Frage, was wir die letzten 15 Jahre gedacht haben, was so richtig ist. Wenn wir auf Teamgrößen gucken, Beispiel, wird sich möglicherweise viel ändern. Das ist ja... Also so ambivalent. Ich höre von Leuten, die ich sehr schätze, die dann sagen, das ist die große Änderung und wir werden ganz stark auf KI-basiert arbeiten in der Zukunft. Und ich höre auch von Leuten, die ich auch sehr schätze, die sagen, naja, das wird sich in den nächsten Jahren alles wieder sehr normalisieren und das ist gar nicht so groß, Impact. Wo da die Wahrheit liegt, keine Ahnung, nicht genug Ahnung von dem speziellen Bereich, werden wir aber sehen. Wir müssen uns aber ein bisschen damit beschäftigen. Und etwas, was ich schon sehe, also schon die letzten zwei Jahre sehe, ist, dass die Teams tendenziell kleiner werden, dass man probiert. mit KI Domain Know-how zu ersetzen oder Domain Know-how über die KI einzubringen in dieses kleine Team. dass wir da sehr viel, ich weiß gar nicht, ob cross-funktional der richtige Ausdruck ist. wir werden unsere Fähigkeit in einem Gebiet, in dem wir keine Experten sind und vielleicht noch nicht einmal tieferes Wissen haben, trotzdem zu arbeiten, die steigt, glaube ich, deutlich. Also wenn ich so gucke, was ich an an Software für mich zu Hause hier basteln kann, die mich sonst sehr viel mehr Zeit gekostet hätte. Das ist ganz beeindruckend. Ich musste gar nicht so tief einsteigen. habe hier ein Hobbyprojekt, ein Buchhaltungstool, was genauso funktioniert, wie ich mir Buchhaltung 2026 vorstelle. Das kann ich jetzt machen und es macht wahnsinnig Spaß. Ich habe seit zehn Jahren nicht mehr so viel Spaß an. eigene Softwareentwicklung gehabt. Und das wäre sonst nicht möglich gewesen. Und ein bisschen weiter gedacht, wenn ich da wieder einen Bogen, eine Verbindung ziehe zu dem Vokabular, was ihr vorhin angesprochen hatte, dass der Architekt Christoph Alexander da sagte, Architekten haben halt ein Vokabular, ⁓ Gebäude zu beschreiben. Und wir haben das verloren als Anwender, also als Nutzer der Gebäude. Das ist jetzt auch mehr eine unreife, wilde Idee, aber vielleicht kann uns KI auch in der Richtung wieder vorwärts bringen. können wir Nutzern viel mehr Einfluss auf Software ermöglichen, weil sie jetzt nicht mehr zwingend über uns Entwickler gehen müssen, zumindest für Teilaspekte oder für Customizing. wenn das also hieße, den Endnutzern von Software irgendwann ermöglichen, ihre Software anzupassen, zu modellieren, indem sie dort mit der KI drüber sprechen und... Anpassungen selber machen können. Das wäre eine voll schöne Symmetrie zu den Ideen, die Architekten für ihre Gebäude damals hatten. Also Nutzer sollten in der Lage sein, die an ihre Anforderungen anzupassen. Und es wäre etwas, das wir in der Software lange nicht mehr hatten. Also ich kenne nicht viele Systeme, wo der Endnutzer großen Einfluss hat darauf, wie die funktioniert. Man kann manchmal so Workflows bauen, aber ansonsten muss ich mehr oder weniger mit dem auskommen, was mir geliefert wird. Und vielleicht ist das in der Zukunft gar nicht mehr so. Stefan Roock (it-agile): gibt es irgendwas, woran du gerade arbeitest Sebastian: Mich interessiert vor allem, wie sich Teams verändern in diesem neuen Setting. Ich habe immer sehr nah an Entwicklungsteams gearbeitet. speziell dieser Aspekt, wie gehen wir mit Retrospektiven zum Beispiel ⁓ Die haben uns, glaube ich, sehr viel geholfen und die haben uns wirklich sehr viel geholfen mit Teams. Wenn wir jetzt so KI-Gestütze, sehr kleine Teams haben, glaube ich, ändert sich das. vielleicht funktionieren Retros dann auch anders. Vielleicht wird es viel wichtiger in so kleinen Zweier-Teams oder zwei plus eine KI, eins plus eine KI. Diese Reflexe. und dieses Reflektieren, also die Retrospektive, auch mit der eigenen KI darüber zu machen, wie unsere Arbeitsabläufe so sind und daraus Änderungen für unsere Prozesse abzuleiten. Das, was wir jetzt, glaube ich, noch nicht systematisch machen. Wenn die Annahme stimmt, dass ein Einzelentwickler mit KI die Haupteinheit für Softwareentwicklung sein kann in der Zukunft. Dann wäre die Konsequenz eigentlich richtig, dass wir auch eine Form von Reflexion finden, die diese beiden Entitäten, den Entwickler und die KI zusammen in einen Prozess einbindet. Und dann haben wir vielleicht in längeren Rhythmen, nicht mehr alle 1, 2, 3, 4 Wochen, vielleicht alle 4 Wochen, ein Retro mit einem Gesamteam, wo viele Entwickler dabei sind, die ihre Erfahrungen zusammenbringen und ihre Learnings. Aber ich glaube nicht mehr in der Art, wir das im Moment machen. Also diese Teamarbeit wird sich glaube ich deutlich ändern und das ist für mich so der interessante Lernpunkt im Moment. Was heißt das? Was kann da funktionieren? Wie können wir diese Welt gestalten, sodass sie für die Entwickler Spaß macht, was sie da tun? Es gibt ja Leute, nur noch Code reviewn und dann schon feststellen, das ist wahnsinnig ermüdend und man verliert halt auch schnell den den Blick, mit dem man eigentlich die also sicherheitsrelevanten Bugs zum Beispiel abfangen sollte, weil die Aufmerksamkeit schlicht nachlässt. Ich kann nicht den ganzen Tag KI generierten Source Code reviewen, ohne da wirklich tief einzutauchen. Das ist, echtes Problem. Wie können wir das zu einer angenehmen Arbeitsumgebung machen? Und natürlich auch so ein ungelöstes Problem, was Wenn wir KI nutzen, wie kann das ethisch vertretbar passieren? Also im Moment haben wir mit KI ganz viele Konsequenzen, die wir ausblenden. Das sieht so nett aus, aber wir haben halt keinen, keinen klaren Einblick in die Umweltaspekte dabei, in die sozialen Aspekte, in die Leute, für das Training dieser Modelle zu extrem niedrigen Löhnen und nur arbeiten müssen. Also es viele. Nebeneffekte, die wir auslagern, ist ein bisschen so wie vielleicht auch bei unserer materiellen Welt, wo wir dann viel konsumieren, was woanders negative Effekte auslöst. Darüber reden wir momentan wenig, reflektieren da wenig drüber. Wenn wir es auf ein industrielles Maßstab, auf einen industriellen Maßstab heben wollen, dann ist das glaube ich ganz wichtig, dass wir eine Lösung dafür finden. Stefan Roock (it-agile): Ich finde zu den Teamgrößen eine interessante Frage. Eine Variante wäre zu sagen, die Teams werden kleiner. Jetzt haben wir heute ja zumindest in der Produktentwicklung selten Situationen, wo ein Team alleine einen business-relevanten Fortschritt erzielen kann. In der Regel haben wir ja abhängige Teams. Und dann finde ich eine interessante Frage, ob das nicht eigentlich viel schlauer wäre zu sagen, die Teams werden gar nicht kleiner, sondern mächtiger. Weil du dann vielleicht statt acht Teams nur noch eins brauchst. Sebastian: Hm. Ja, das ist die Frage, meinst du, wir haben da noch mehrere Teams oder haben wir dann tatsächlich nur noch ein kleines Team, was diese Arbeit abliefern kann? Stefan Roock (it-agile): Das ist, glaube ich, eine Designfrage, wie man da drauf gucken will. ich glaube, was mit neuen und radikalen Technologien ja immer passiert ist, dass man relativ lange braucht, um zu erkennen, wie radikal der Wandel wirklich sein kann. Es gibt auch so Geschichten wie die ersten Elektromotoren, die 100 Jahre in die Fabriken Einzug gehalten haben. Sebastian: Hm. Stefan Roock (it-agile): dass man erst die eine große Dampfmaschine durch einen großen Elektromotor ersetzt hat und relativ lange gebraucht hat, bis man gerafft hat, dass es viel besser ist, viele kleine Elektromotoren an jeder Maschine zu haben, weil man dann die Fabrik nicht ⁓ die Maschine drum rum bauen muss, sondern am Flow orientieren kann. Deswegen ist es glaube ich erst mal natürlich zu sagen, die Teams bleiben so wie sie sind und im Zweifel werden sie kleiner, billiger. Sebastian: Hmhmhmhmhm Stefan Roock (it-agile): Aber ich finde es ja, also die Probleme, die wir haben, sind ja meistens in-between Probleme. Also wenn Übergreifen nicht geliefert wird, liegt es ja selten daran, dass irgendeins von den Teams nicht funktioniert, sondern dass es Probleme in der Zusammenarbeit gibt. Und wenn wir dann nur noch ein Team bräuchten, in dem wieder acht Leute sind mit, keine Ahnung, 30 KI-Agenten, hätte das erst mal Scham. Und ich weiß selber nicht, was das... bezüglich der Kommunikationsbeziehungen bedeutet. Also weil klar, du hast nicht mehr soziale Beziehungen, weil ich glaube, man zu... Ich hoffe, dass man zu KI-Agenten keine sozialen Beziehungen aufbaut. Kommunikationsbeziehungen sind schon auch... sind mit denen ja irgendwie da, aber sie sind auch Sebastian: Dann würden wir wahrscheinlich ganz viel von den vor- und nachgelagerten Arbeiten in das Team mit reinziehen, sodass wir tatsächlich diese acht Personen alles abdecken von Discovery vielleicht bis inklusive Kundensupport. Stefan Roock (it-agile): Und dann wäre vielleicht auch die Chance da, es insgesamt durchlässiger wird. Also man hätte dann vielleicht direkt einen Zugang wieder zu Kunden oder in Kontakt, weil das nicht in der anderen Abteilung liegt. stellen. Sebastian: Ich frage mich, wie so eine Organisation dann mit diesen unglaublich hohen Frequenzen an Produktupdates umgeht. wenn tatsächlich diese acht Leute zusammen mit KI-Features entwickeln können und die sind ja wahnsinnig, die sind ja viel schneller als jetzt. Also wir haben viel mehr Änderungen an der Software als wir es jetzt haben. Ich weiß gar nicht, ob ich als Kunde so viele Änderungen haben möchte an meiner Software. dass sie sich ständig erneuert, ständige Updates einspielt. wir müssen natürlich auch den... Also zum einen die Entscheidungsprozesse drum herum müssen, glaube ich, deutlich besser werden. Und wahrscheinlich auch viel weniger Menschen involvieren. Ich glaube, die Managementprozesse ändern sich dann stark. Markus Andrezak hat das, glaube ich, in seinem Interview auch mit angesprochen. Das ist eine der Baustellenden. Und von der technischen Seite stolpern, glaube ich, viele Teams schnell über ihre eigenen Füße, wenn sie so schnell werden würden durch magische Zutaten. Stefan Roock (it-agile): glaube dass die Geschwindigkeit, die KI mit sich bringen kann, ⁓ wenn man irgendwas dass das auch zu diesen Problematiken im Code Review beitragen kann. Weil Entwickler, selbst wenn man sagt, habe Spaß an Code Review. ⁓ Sebastian: Hm. Stefan Roock (it-agile): dass man sich irgendwann von der Maschine so unter Druck gesetzt fühlt, weil man ja nie in dem Tempo nachkommen kann, wie das Ding neuen Code erzeugt. Das braucht, glaube ich... Sebastian: Vielleicht heißt das in dieser Konsequenz, wir müssen doch diesen Review Aspekt loswerden, weil wir das nicht halten können. Stefan Roock (it-agile): Ich glaube, glaube, ist für, bei bestimmten Anwendungen wie hardwarenahe Entwicklungen, sicherheitskritischem Kram und so weiter ist das, glaube ich, wird das bleiben. Aber ich glaube, für die 0815-Business-Anwendung ist es unrealistisch zu glauben, dass die Entwickler ernsthaft jeglichen Code lesen und verstehen werden, die die KI generiert. Ich glaube, das braucht einen anderen Ansatz, ⁓ sicherzustellen, dass da kein Scheiß drin ist. Sebastian: Mhm. Ja, vielleicht. Stefan Roock (it-agile): Und ich glaube, wir haben diesen Ansatz noch nicht. Ich glaube, es kann auch nicht darin liegen, dass man eine andere KI fragt, was sie davon hält. Sebastian: Ja, nur ein Stück weit. Vielleicht muss unsere Softwarearchitektur da wieder vieler toleranter werden. Vielleicht müssen wir in unseren Abläufen und auch in den Kundenprozessen einplanen, dass Dinge schief laufen, weil eine KI irgendwie mal Fehler einprogrammiert hat, die wir nicht durch menschlichen Review abfangen konnten. Stefan Roock (it-agile): Ja. oder dass aus dem Code andere Visualisierungen gebastelt werden, die sich leichter reviewen lassen. Sebastian: Mhm. Stefan Roock (it-agile): Und Architektur spielt da, glaube ich, auch eine Rolle. Also Architekturvisualisierung. Auch ⁓ zu verhindern, dass die KI in unglaublich hoher Geschwindigkeit Legacy Code erzeugt, den hinterher niemand mehr ändern kann. Sebastian: Ja, ja. Ja, ich glaube auch die Modularisierung von Software wird damit viel wichtiger, weil wir eine KI, die wird immer begrenzten Kontext haben, den sie anschauen kann. Und je größer unsere Software ist, je mehr verzweigte Nebeneffekte wir erzeugen können, desto schwieriger wird es sein, damit KI-Gestütze zu entwickeln. Das heißt, Firma, die es schafft, eine Software mit einer Software zu arbeiten, die sehr gut modularisiert ist, hat eigentlich einen strategischen Vorteil. Und das war bisher, glaube ich, ich meine, das ist immer der Fall gewesen, aber es hat, glaube ich, noch nie so starke Auswirkungen gehabt wie jetzt. Und wenn ich eine ganz positive Version von dieser Zukunft da so mir zusammenreime, dann kann ich mir vorstellen, dass wir durch KI-Unterstützung jetzt vielleicht agiler Software entwickeln, als wir es je getan haben und auch letzten Endes technisch in der besseren Qualität, als wir es getan haben. Das ist auch wieder eine Frage der Feedback-Schleife. Die Feedback-Schleife, was bringt oder kostet uns gutes Softwaredesign und Modularisierung, die ist drastisch verkürzt worden. Was vorher vielleicht erst nach Jahren sichtbar wird, wird jetzt innerhalb von Wochen, Tagen sichtbar. Und damit wird auch die Argumentation, warum ist das was wert, da rein zu investieren, viel einfacher. Und in dieser Wunschwelt, die ich mir ausmalen kann, da hat vielleicht, ich weiß nicht, ich gucke so bisschen in Domain Driven Design wieder verstärkt rein, wo wir diese Domänen sehr stark trennen wollen und in sehr viel kleineren Einheiten denken. Das hat vielleicht einen richtig guten Platz. weil das ermöglicht, Software so zu strukturieren, dass sie für KI einfacher verständlich ist und wir Nebeneffekte reduzieren können, weil diese Verbindungen nicht so eng gestrickt sind oder klarer definiert sind. auch die Testabdeckung, was ich so von aktuellem KI-Code sehe, ist auf einem Level, das kenne ich nur von dass sie das Ganze nicht durchhalten, weil sie ihn wirklich schön geschrieben haben. Vielleicht läuft das auf wirkliche technisch gut implementierten agilen Code raus, wenn wir gleichzeitig Architektur und automatisierte Pipeline-Prozesse zusammenbringen. und durch die verkürzten Feedbackzyklen das viel besser argumentieren und umsetzen können. Das wäre der positive Ausblick in die Zukunft. Stefan Roock (it-agile): Und wie sich die Zukunft entwickelt, das spielen wir eine Rolle. Wir können ja Einfluss nehmen. Sebastian: Ja. Ja, und das macht ja auch wahnsinnig Spaß. Also es ist nicht so, dass mein Job langweilig geworden ist in den letzten zwei Jahren. Manchmal steht man da so bisschen verängstigt vor und denkt, boah, ich werde überflüssig und wir können das alles automatisiert machen. Aber trotzdem gestalten wir diese Prozesse ja noch, in der wir die Automatisierung einsetzen. Und das finde ich im Moment eine ganz spannende Zeit, gerade im Blick auf die Teams und wie sich deren Arbeit ändert. Stefan Roock (it-agile): danke ich dir vielmals, Sebastian, für das interessante Gespräch, das gemeinsame Schwägen in alten Erinnerungen ⁓ ⁓ die Extreme Programming User Group in Hamburg und die interessanten Gedanken und den Austausch über das, die Zukunft vielleicht Sebastian: Gerne! Sehr schön, hat mir auch Spaß gemacht.