Latest / einfach gelöst / #19: Arne Roock – Wir wollten guten Flow herstellen
Transcript
- Stefan Roock (it-agile): Hallo und herzlich willkommen zum IT Agile Podcast Einfach gelöst. Ich freue mich ganz besonders, dass ich heute meinen Bruder, meinen kleinsten Bruder zu Gast habe, Arne. Hallo Arne. Arne: Freue mich, hier zu sein. Stefan Roock (it-agile): Für die, dich noch nicht kennen, magst du dich kurz vorstellen? Arne: Genau, mein Name ist Arne. Ich habe denselben Nachnamen wie du, werde dieses Jahr 50 Jahre alt. Ich habe ursprünglich mal Germanistik studiert vor sehr, sehr langer Zeit. Bin dann aber in die Softwareentwicklung abgeglitten, wobei ich niemals selbst Software entwickelt habe. Wobei auch das nicht stimmt. Ich habe mal Text Adventure auf dem C64 geschrieben, aber nie ernsthaft Software entwickelt. Aber bin dann ja Bei Edge Edge gelandet, war da neun Jahre lang. Am Anfang habe ich Marketing gemacht und Verwaltung. Dann habe ich selbst angefangen Beratung zu machen. Jimdo war einer meiner Kunden. Da habe ich dann angefangen fest zu arbeiten als Embedded Coach sozusagen. War da drei Jahre lang und danach bin ich nach Schweden gezogen, habe sieben Jahre lang bei Spotify gearbeitet, auch als Agila Coach. und habe mich jetzt vor eineinhalb Jahren selbstständig gemacht und biete im Grunde sehr ähnliche Dienstleistungen an wie vorher, alles rund Agil- und Lean- Leadership Training und habe mich jetzt in den letzten eineinhalb Jahren nochmal intensiv mit dem Thema Team Design und Team of Teams beschäftigt. Stefan Roock (it-agile): Das Agile Manifest, darum geht es ja hier im Großen und Ganzen, wurde erstellt im Februar 2001. Was hast du denn da so getrieben? Arne: Da habe ich auf jeden Fall noch studiert, wie gesagt, Germanistik. Das heißt, da hatte ich mit Softwareentwicklung gar nichts am Hut. Allerdings, wie das so ist als Student, braucht man ja Geld und ich hatte einen Aushilfsjob in der Vorgängerfirma von IT Agile, in der du ja auch gearbeitet hast und Henning und Martin und fast eigentlich alle, die zur ersten Besetzung von IT Agile gehörten. Und mein Job bestand im Wesentlichen darin, die Kaffeebohnen in die Kaffeemaschine zu füllen. und ab und zu mal auf den Entkaltenknopf zu drücken. Das war aber cool, weil es gut bezahlt war. Und ständig ganz, gab auch ein paar andere Sachen, so Daten eingeben und so was. Und da habe ich natürlich am Rande immer mitgekriegt, was ihr da macht und worüber ihr redet. Und das kam mir sehr freaky vor. Ich natürlich auch keine Ahnung von Softwareentwicklung, das war mein erster Kontakt. Und dann gleich. mit dieser Art von, wie ihr es ja gemacht habt, extreme programming, zwei Leute sitzen vor einem Rechner. Das hörte sich alles sehr skurril an für mich. Hab's auch nicht richtig durchdrungen. Und ich kann mich aber erinnern, ich war damals an der Uni in einer Arbeitsgruppe zu Ethnolingoistik. Das war von meinem Professor so sein Spezialgebiet. Und die Idee ist, man beschreibt Sprache von ethnischen Kleingruppen, wobei ethnisch jetzt nicht gemeint ist im Sinne von Amazonas-Ureinwohner, sondern er hat zum Beispiel geforscht über die Sprache von Obdachlosen, also eine Subgruppe der Gesellschaft quasi, oder Taubenzüchter oder BDSM, alles Mögliche. Und wir haben diese Arbeitsgruppe gehabt und er hat gesagt, so jeder von euch sucht sich jetzt zu einer Gruppe und forscht dann über der Sprache, deren Sprache. Und da war für mich völlig klar, ich nehm' Softwareentwickler. Die sind so freaky. Und ich hab' da jetzt ja einen Zugang zu, weil ich mit denen im Büro sitz'. Und dann kann ich die irgendwie so belauschen und interviewen und vielleicht mal Videos machen und zack, hab' ich dann super Abschlussarbeit. Das ist dann nichts geworden, aber für mich war das, das macht vielleicht ein bisschen deutlich, dass das für mich eine ganz andere Welt war. Und was Agilität nochmal dann angeht, ein bisschen strukturierter. Du hast ja mit Henning und Martin dann das deutsche XP-Buch geschrieben und ich kann mich nicht mehr ganz genau erinnern, wann das veröffentlicht wurde. Die zweite Auflage war 2005, habe ich rausgefunden, aber die erste Auflage war ja deutlich früher. Und ich weiß, dass du mir dann irgendwann so ein Exemplar in die Hand gedrückt hast und gesagt, hier, das Buch habe ich geschrieben, lief mal. Ich dachte, was ist das denn für ein Quatsch? Ich lese doch jetzt kein Buch über Softwareentwicklung, da verstehe ich ja kein Wort. Hab dann aber trotzdem mal reingelesen und war erstaunt, dass ich doch relativ viel verstehen konnte. Zumindest so im Prinzip, weil es dann ja viel auch so Prozess-Sachen ging, die gar nicht so technisch waren. Auf jeden Fall war das mein erster Kontakt zur Agilität. Das agile Manifest habe ich erst deutlich später kennengelernt. Ich meine, das war erst, als wir schon mit IT Edge Art angefangen hatten, also 2005. Stefan Roock (it-agile): bei IT-Engine hast du dann ja auch am Anfang, hast du gesagt, Verwaltung und Marketing gemacht. Hatte das da das agile Arbeiten schon in einen Einfluss? Oder kam das jetzt später? Arne: Ja, war, nee, das war ganz interessant. Ich habe da jetzt auch nochmal drüber nachgedacht. der Vorbereitung. Eine Aufgabe, die ich bei IT-Ager hatte, war, Texte zu schreiben, beziehungsweise Texte zu redigieren. Weil wir immer gesagt haben, je besser das Jahr war, umso schlechter das Deutsch. Und wir haben ja eine neue Webseite gemacht und dann auch so Broschüren und Flyer und sowas, wo wir beschrieben haben, was ist Agilität, was ist XP und so weiter. Und die Texte wurden von euch geliefert und meine Aufgabe war es dann, die lesbar zu machen. Und in dem Zusammenhang musste ich die natürlich alle durchlesen und habe deswegen schon auch mir so mein eigenes Bild gemacht, was das wohl auf sich haben könnte mit der Agilität, obwohl das ich das noch nie in der Praxis gesehen hatte so richtig. Also ich habe da am Anfang sehr theoretischen Zugang zu gehabt. Und ich kann mich aber erinnern, ich habe dann ja noch promoviert in Linguistik, also auch gar nichts eigentlich zu tun mit Agilität. Und wir hatten dann später mit meinem Doktorvater so einen Kolok für, wo verschiedene Doktoranden regelmäßig so ihre, ihre Arbeiten vorgestellt haben. Da habe ich mal ein Referat gehalten in dieser Gruppe und zwar nicht über den Inhalt meiner Arbeit, sondern wie man eine wissenschaftliche Arbeit agil schreiben kann. Ich habe das Wort agil nicht benutzt, aber im Grunde ging es da so ein iteratives Vorgehen. Stefan Roock (it-agile): Mhm. Arne: Ich habe mir gedacht, das wäre doch cool, wenn man nicht anfangen würde am Anfang und dann einfach die Arbeit Einleitung Hauptteil Schluss, sondern erst mal überlegt, was ist eigentlich das Wichtigste? Also die Kern der Arbeit aufschreiben als einen Absatz oder eine Seite. Und dann sich Feedback einholt und dann überlegt, jetzt brauche ich noch was drum rum und jetzt erweitere ich das immer weiter, sodass ich aber im Grunde immer eine lesbare Version meiner Arbeit habe. Das wäre doch total cool. Man muss aber sagen, da habe ich in leere Augen gestarrt, als ich das vorgetragen habe. Ich glaube, ich konnte das nicht so richtig vermitteln oder es war zu fremd für die akademische Welt. Und wenn ehrlich ist, habe ich meine eigene Arbeit auch nicht so geschrieben. man merkt daran vielleicht, das hat in mir schon gearbeitet, diese Ideen von Agilität. Stefan Roock (it-agile): Genau, und irgendwann hast du erzählt, bist du in die Beratung übergegangen oder gerutscht, wie es das passiert. Arne: Genau, das kam als Kanmban aufkam und jetzt verschwimmen die Jahreszahlen so ein bisschen. Aber ich glaube, die erste Schulung mit David Anderson, das muss ja so 2008, 2009 gewesen sein, den Dreh. meine Aufgabe war es ja eigentlich, diese Schulung zu organisieren. Das heißt, ich habe die Schulungsraum gebucht und dann die Teilnehmer angeschrieben und so weiter. die fand in einem Hotel statt und ich bin dann hingefahren, dafür zu sorgen, dass da alles richtig läuft und dass die Leute Kaffee haben und so weiter. Und habe dann gedacht, wenn ich so mal hier bin, setze ich mich auch einfach mal da rein und habe mir das angehört und fand das irgendwie spannend und interessant. haben dann ja noch mehrere Schulungen mit David gemacht, die ich immer organisiert habe. Ich habe mich dann immer reingesetzt und war dann ziemlich schnell Feuer und Flamme und habe gedacht, das ist ja cool und habe ganz viel darüber gelernt. Man muss sagen, damals gab es ja auch nicht so wahnsinnig viel, was man da lernen konnte. Ich kann mich noch erinnern, ich hatte ein RSS-Feed abonniert bei Twitter über den Hashtag kann-wahn und habe alle Tweets gelesen, die kann-wahn in sich hatten. Und es waren nicht viele, es waren zwei oder drei am Tag. So, und es gab damals das einzige Buch, ja Scrambahn von Corey Laddis, was ja ein sehr dünnes Büchlein ist und auch nicht viel theoretisch hält. und mehr gab es nicht, ein paar Blockpro's. Aber mich hat das so fasziniert, dass ich da mich so reingebühlt habe und hatte natürlich dann auch Glück, weil ich ja diesem direkten Drahten David Anderson quasi hatte, habe ein Interview mit ihm gemacht, was dann in dem Software Engineering Radio, glaube ich, erschienen ist. Und bin dann nach und nach da so reingerutscht, dass ich Artikel dazu geschrieben habe und Vorträge gehalten habe und dann auch meine ersten Beratungsgründen darüber gefunden habe. Was eigentlich ein bisschen skurril ist, also im Grunde ja jede, ohne jede praktische Erfahrung das gemacht. Man muss aber dazu sagen, es gab halt auf der ganzen Welt vielleicht eine Handvoll Leute, die praktische Erfahrungen damit hatten zu dem Zeitpunkt. Und irgendwo muss man ja mal anfangen. Erstmal also Kanban, was mich da so reingezogen hat. Und ich glaube, das lag auch daran, dass Scrum hatte für mich schon sowas, das ist schon vergeben. Stefan Roock (it-agile): Mhm. Arne: Und es war ja damals noch nicht, bei weitem noch nicht so groß wie heute, aber klar, wir haben da schon viel Scrum-Schulungsgeschäft gemacht und Beratung und es wurde auch gerade richtig groß in der Softwareentwicklung und mich hat das nie so interessiert, mich da reinzuarbeiten, weil ich dachte, da gibt schon genug. Aber bei Kanban, da kann ich irgendwie ganz vorne mit dabei sein und das kann ich irgendwie noch mitgestalten vielleicht. Und ich glaube, das waren so ein paar Beweggründe. Deshalb habe ich dann Kanmbarn so gepackt, dass ich selbst in die Beratung gegangen bin. Stefan Roock (it-agile): Und wie war das dann in der Beratung? Also was hast du da gemacht? Arne: Ja, ich kann mich erinnern an mein allererster Kunde. Das war erfolgreich. Das war eine kleine Agentur. Da habe ich eine Schulung gemacht und dann hinterher noch mal so bisschen Workshop, Follow-up, Retrospektiven moderiert. Und das war super, weil die das auch gleich kapiert haben und für sich adaptiert und umgesetzt. Das war gut. Ich kann mich erinnern, war danach war ein Kunde, das war wahrscheinlich mein zweiter oder dritter Kunde, es war eine absolute Katastrophe. Weil die, wie soll man das sagen, also die kamen aus so einer Prozesswelt, aus einer schwergewichtigen Welt. Und für mich war aber immer klar, das ist was Leichtgewichtiges. Aber kann man natürlich einsetzen, wie man will. Man visualisiert ja erstmal, was da ist. Und ich habe mit denen einen Workshop gemacht und gesagt, als erstes visualisieren wir jetzt mal eure Arbeitsprozesse. Und dann haben die im Grunde alle Prozesse, die sie hatten, versucht abzubilden. Und es waren wirklich in einem großen Konferenz voll alle Wände voll mit Post-its und Filen. Und es war komplett unübersichtlich. Und ich war super überfordert, weil ich nicht wusste, wie ich das jetzt wieder einfangen konnte und wie ich das reduzieren konnte. Zu dem Grunde wurde ich auch nicht nochmal eingeladen. Das war jetzt am Anfang durchaus gemischt, aber ich hatte, glaube ich, Glück, dass der allererste Kunde sehr gut läuft, sodass ich dann nicht gleich wieder ermutigt wurde. Stefan Roock (it-agile): Und du hast ja gesagt, am Anfang gab es dieses Scrum und bzw. versus Kanban Scrum schon vergeben. Insbesondere am Anfang gab es ja auch beiderseitig viele Konflikte in meiner Wahrnehmung. Arne: Ja, das war tatsächlich so im Nachhinein sehr schade und sehr albern. Ich war da selbst leider auch nicht ganz frei von zu sagen, Kanban ist besser als Scrum. Was natürlich extrem vereinfacht ist und auch nicht stimmt. Aber Kanban hat sich ja in meiner Wahrnehmung zumindest sehr stark als Gegenbewegung innerhalb der Gegenbewegung entwickelt. Also Agilität Stefan Roock (it-agile): Ja. Arne: und Scrum war ja so eine Gegenbewegung. Und dann Innerhalb dessen hat sich dann ja wieder so ein bisschen eine Gegenbewegung gebildet. Ich glaube insbesondere gegen die Timeboxes. Ich kann mich erinnern, es gab von David Anderson das Zitat The Tyranny of the Timebox, also die Tyrannie der Timebox. Weil Leute festgestellt haben, dass Scrum by the Book in einigen Kontexten nicht so gut funktioniert. Und das waren ja vor allem so Maintenance, oder interne IT Kontexte, wo Kampagne auch entstanden ist, wo man nicht kontinuierlich an einem Produkt arbeitet und dann sich vorwärts iteriert mit Zeitboxen, also Timeboxes, sondern wo man sehr viele kleine unterschiedliche Aufgaben hat, die man abarbeiten muss. Und als Unternehmen dann versucht haben, da Scrum einzuführen oder anzuwenden, die natürlich gescheitert, weil Scrum da auch wenig Sinn macht. Also da müsste man glaube ich schon sehr viel abändern, damit das noch funktioniert. Insofern ist das ja eigentlich eine super Ergänzung, zu sagen, wir haben jetzt sowas wie Scrum, Timebox und iterativ mit dem Rollenmodell, das benutzen wir für Produktentwicklung. Und wir haben für andere Kontexte so etwas flowbasiertes wie Kanban, wo wir auch kein vorgegebenes Rollenmodell haben, sondern wo wir gucken, dass unsere Arbeitspakete gut durch das System fließen, wir gute Durchlaufzeiten haben und so weiter. Es passt ja super zusammen. Leider Stefan Roock (it-agile): Mhm. Arne: wurde es am Anfang selten so gesehen. Insofern ist das tatsächlich schade und hat, glaube ich, am Anfang auch viel Verwirrung angerichtet. Zumal ja noch ein weiterer Aspekt dazu kam, weil wir am Anfang gesagt haben in der Kammercommunity, Kanban ist gar keine Methode, Software zu entwickeln, sondern ein Change-Management-Ansatz. Und die deutsche Übersetzung von dem Kanban-Buch, die Henning und ich ja übersetzt haben, die heißt ja Kanban und dann im Untertitel evolutionäres Change-Management. Und David hat am Anfang ja auch immer gesagt, man kann Scrum und Kanban gar nicht vergleichen, denn das sind unterschiedliche Abfraktionsebenen. Bei Scrum geht es daran, Software zu entwickeln, bei Kanban geht es darum, eine Veränderung einzuführen. Und man kann Kanban für jede beliebige Softwaremethode einsetzen, die zu verbessern, egal ob das Wasserfall ist oder Scrum oder irgendwas anderes. Was intellektuell und konzeptionell auch Sinn macht, das hat nur keiner kapiert. Stefan Roock (it-agile): Mhm. Arne: Und wir haben das auch nicht konsequent so erzählt, weil wir teilweise diese Geschichte erzählt haben und teilweise aber auch die Geschichte Wenn Scrub für euch nicht funktioniert, benutzt auch CarbonBahn. Und das passt überhaupt nicht zusammen. Stefan Roock (it-agile): Mhm. Ja, doch da kann ich mich auch noch dran erinnern, dass ich da zwischendurch auch ein bisschen verwirrt war, was es jetzt eigentlich ist oder sein möchte. Arne: Ja, ich habe ja zu der Zeit sehr, sehr viele Kamban-Schulungen gegeben. Und dann später, als ich aus der Beratung rausgegangen bin und erst bei Gymnon und bei Spotify gearbeitet habe, habe ich auch weniger mich mit Kamban beschäftigt. Da waren dann andere Themen, einfach anstanden. Hab dann tatsächlich auch gelernt, Scrum zu lieben. Viel, viel später. Ich habe dann viele Scrum-Schulungen gemacht und bin ab und zu dann nochmal wieder zurück zu Kanban gekommen und habe dann, ich, auch eine reifere Sicht auf Kanban entwickelt. Und eine Sache, die ich oft gemacht habe, wenn ich so interne Schulungen und Workshops gegeben habe, habe ich den Begriff Kanban versucht, sehr wenig zu verwenden oder gar nicht, sondern stattdessen Flow in den Vordergrund gestellt. weil ich der Meinung bin, dass das eigentlich klarer macht, worum es eigentlich geht. Wir wollen guten Flow herstellen und das können wir innerhalb eines Scrum Prozesses machen. Das können wir auch auf einer Portfolioebende machen. Das können wir auch machen, wenn wir einen Ad-hoc Prozess haben und darum geht es eigentlich, geht den Flow. Und ich glaube, da wird es dann auch ein bisschen klarer, wie Scrum und Kanban zusammenpassen. Also man kann den Flow innerhalb von Scrum verbessern, man kann den Flow zwischen Scrum Teams verbessern mit Kanban. Man kann aber auch sagen, wir machen gar keinen Scrum und überlegen uns, wie können wir trotzdem Flow herstellen in unserer Arbeitsumgebung. Stefan Roock (it-agile): Und wie war das denn bei Jimbo und Spotify? Haben die Scrum oder Cameraman verwendet? Arne: Ja. Und Das ist interessant, als ich bei Jimdo angefangen habe 2014, wobei ich zwei Jahre vorher schon da Beratung gemacht habe. sind die ja gerade gewachsen über so eine Schwelle, wo klar war, wir brauchen jetzt mehrere Teams. Vorher war es ein, also Start-up-artig, wir sind eine Gruppe von Leuten, wir sind ein großes Team, wir machen alles zusammen. Dann gab es irgendwie so eine Schwelle, wo sie festgestellt haben, das funktioniert nicht mehr und wir brauchen jetzt verschiedene Teams. Und ich habe denen dann am Anfang geholfen, cross- funktionale Teams aufzusetzen, zu überlegen, wie könnten die Teams geschnitten sein. Was haben die jeweils für eine Mission? Woran sollen die arbeiten? Und auch so ein bisschen zu überlegen, wie können die sehr leichtgewichtige Prozesse haben? Und die wollten auf gar keinen Fall Scrum machen, weil es nämlich vorher schon mal so einen Versuch gab, Scrum einzuführen, das war vor meiner Zeit, der wohl als sehr dogmatisch wahrgenommen wurde. So muss man das machen, die Rollen muss man haben, man muss immer diese Timeboxes haben, sonst ist das kein Scrum. und das hat einfach zu sehr starken Abwehrreaktionen bei Gymlo geführt, sodass sie auf gar keinen Fall Scrum machen wollten. Und die waren superglücklich, als sie dann von Kanban erfahren haben. So habe ich die auch erst kennengelernt. Die sind nämlich über die DevOps-Bewegung zu Kanban gekommen und so habe ich die dann kennengelernt. Und das war total cool für die zu erfahren. Wir können jetzt Teams haben. und eine strukturierte Zusammenarbeit, einen strukturierten Prozess haben, aber das muss nicht stram sein, sondern die Teams benutzen jetzt alle so etwas flowbasiertes. Und da sind dann innerhalb von kürzester Zeit Kanban Boards aus dem Boden geschossen. Und zwar nicht nur in den Produktentwicklungsteams, sondern auch in den Marketingteams, im Support, selbst in Finance, überall. Und die haben wirklich das aufgesogen, gerade diesen Visualisierungsaspekt und auch den kontinuierlichen Verbesserungsaspekt. Und es gab eine lustige Geschichte, wir hatten dann im Rahmen einer LKCE-Konferenz waren die Popendix-Kino-Speaker. Und die waren dann in Hamburg schon einen Tag vorher. Und irgendwie haben wir es geschafft, die zu belatschen, dass sie mal zu Jimdo kommen und sich das da angucken. Und die haben dann nachmittags sich die Büros zeigen lassen und so bisschen was erzählt. Und da gab es ein Zitat von Mary Poppending, was mich sehr stolz gemacht hat. Sie hat nämlich gesagt, das ist die visuellste Firma, sie jeweils gesehen hat. Stefan Roock (it-agile): Mhm. Arne: Weil alles voll mit Boards waren, aber auch verschiedene Workflows visualisiert. Deswegen alle Wände voll mit Visual Management Tools. Das heißt, dieser Aspekt hat extrem gut funktioniert, die Visualisierung und darüber Kommunikation zu triggern und dann auch dieser Kaizen kontinuierlich auf Verbesserungsaspekt. was wir nie richtig zum Fliegen gebracht haben, ist diese Work-in-Progress-Libetierung. Also in einzelnen Teams ja, aber das war schwierig. Und ich kann bis heute nicht genau sagen, woran das eigentlich lag. Aber das war, glaube ich, nicht nur bei Jimdo so, sondern diese Visualisierung. Abstimmungen, Retrospektiven machen, vielleicht noch so was wie Daily Stand-Up, das sind ja die Quick Wins, die man auch bei Scrum hat. Und bei Canman ist dieser Visualisierungsaspekt noch stärker. Aber dann kommt halt das wirklich Schwierige und das ist in Scrum ja am Ende eine Iteration, was Werthaltiges zu liefern. Und bei Canman die Work-in-Progress-Limits wirklich einzuhalten. Und das haben wir da nur begrenzt geschafft, muss man sagen. Du hattest ja noch nach Spotify auch gefragt, ohne da jetzt zu viel aus dem Nähkästchen zu plaudern, aber da war es so, dass Teams eigentlich immer, die Teams, mit denen ich gearbeitet habe, so einen Scrum-artigen Ansatz hatten. Also die haben eigentlich fast alle Teams zwei, vier, iterationen gehabt, die haben Planungsmeeting am Anfang gehabt, eine Perspektive am Ende, Daily Stand-ups und sowas. Einige Teams haben aber gesagt, ne, wir machen keinen Scrum, wir machen Kanban. Und was das bedeutet hat, war einfach, dass sie die zwei-wöchige Iteration weggelassen haben. Und das ist etwas, was mir auch vorher schon bei Kunden begegnet ist, was sehr schade ist. Wir nennen etwas Kanban, weil wir die schwierigen Teile von Scrum weglassen. Wenn wir aber keine Timeboxes haben und keine Work-in-Progress-Limits, dann fehlt ja ein essenzieller Teil von beiden Methoden. Stefan Roock (it-agile): Bezüglich Jim, hattest ja das Visualisierungsthema angesprochen. während deiner Zeit bei Spotify, ist ja Corona über uns alle hereingebrochen. Also wenn das vorher nicht schon der Fall war, müsste dann ja alles Mögliche an Visualisierung elektronisch passiert sein, oder? Arne: Ja, das stimmt. Und bei Jimdo war es auch so, da waren alle immer im Büro. Also Homeoffice gab es nur in atüden Ausnahmefällen. Allerdings habe ich das ja nicht mehr mitbekommen, wie sich das dann verändert hat. Das heißt, da kann ich im Grunde nichts zu sagen. Bei Spotify war es schon so, dass wir in ein neues Büro gezogen sind. In dem alten Büro war auch sehr viel visualisiert. Da gab es viele visuelle Kanban-Boards überall und wie sie gewaltbar sind in allen Räumen, wo Leute drauf gemalt haben. Dann sind wir in ein schickes neues Headquarter gezogen und dann war im Wesentlichen auch Schluss mit den Visualisierungen, unter anderem weil die Räume das einfach nicht mehr hergegeben haben. Was auch sehr merkwürdig war. Ich habe das nie verstanden, was da eigentlich passiert ist. Aber dann war irgendwie so Schluss. Zumindest mit dieser Low-Tech-Visualisierung, wir schreiben Posted Notes und so. Das gab es vereinzelt noch, aber nicht mehr so systematisch wie vorher. Das insofern war schon vor Corona sehr viel digital. Also mit Jira und Miro Boards und sowas. Was ich immer schade fand, was dann natürlich aber bei diesem Umstieg während Corona sehr geholfen hat. Stefan Roock (it-agile): Warum fangst Du jetzt Schale? Arne: Also ich, meine Erfahrung war immer mit Visualisierungen, vor allem wenn es so Hosteds auf einem Whiteboard waren oder auf der Wand. Es gab früher immer diesen Spruch, den ich sehr schön fand. Ein Kanban Board ist wie ein Lagerfeuer. Wir versammeln uns drumrum und erzählen uns Geschichten. nämlich Geschichten über unsere Arbeit. Wir gucken jetzt auf dieses Board gemeinsam und sagen, ach, guck mal, was ist denn hier passiert? Diese Ticket, das geht ja gar nicht voran. Ja, das liegt daran, weil wir Zuarbeit von einem anderen Team brauchen oder so. Und dieser Aspekt, den fand ich immer sehr hilfreich und den habe ich nie erlebt, dass das passiert bei digitalen Tools. Dass Leute diese Art von gemeinsamen Verständnis über ihre Arbeit entwickeln oder dann auch diese Art von Gesprächen entwickeln. Stefan Roock (it-agile): danke für den Einblick. Wie ist denn so deine Perspektive darauf, wie Agil plus Kanban die Arbeitswelt verändert hat? Arne: Es gab ja, bevor der große Hype-Plus ging mit KI, war ja ein kleinerer Hype auf LinkedIn und in Social Media, vor allem in dieser agilen Bubble, ist Agile tot. Und ist agiles Coaching tot. Angestoßen auch darum, dass es mehrere große Entlassungswellen gab, Agile Coaches, Scrum Master. rausgeflogen sind in vielen Unternehmen, unter anderem auch bei Spotify dann irgendwann. Und dann haben verschiedene Leute gesagt, Agilität ist tot, beziehungsweise Agiles Coaching ist tot. Und ich habe mich in diese Diskussion nie eingemischt, habe aber bei mir gedacht, wenn Agilität tot ist, was ist denn dann die Alternative? Und ich kenne keine. Also es kann gut sein, dass das Label Agilität tot ist. Und das ist auch in einigen Firmen so, dass es verbrannt ist, weil Leute negative Erfahrungen gemacht haben und die wollen Agilität nicht mehr bei sich haben. Also das, Sie mit Agendität verbinden. Aber wenn man das abschafft, wer will dann zurück zu Wasserfall? Also keiner. Es gibt ja gar keine Alternative dazu, in kurzen Incrementen Software zu entwickeln und zu gucken, was funktioniert, was funktioniert nicht, das anzupassen und regelmäßig seinen Plan zu korrigieren. Also das will ja, glaube ich, gar keiner mehr abschaffen. Insofern. würde ich sagen, Agilität hat im Grunde die Arbeitswelt schon sehr verändert. Nicht so radikal, wie wir uns das mal vorgestellt hatten. Also, ich glaube, wir gucken ja auf viele Unternehmen und sagen, ja, ist ganz cool, was sie machen, aber so richtig agil ist das eigentlich nicht. Aber das ist vielleicht auch okay. Also, wir wollten 100 Prozent und jetzt sind wir bei 70 und das ist ja auch schon eine ganze Menge. Stefan Roock (it-agile): Am Anfang hast du Agilität eher von außen betrachtet und hast ja auch gesagt, das wirkt dir dann manchmal so bisschen freaky, Und ich weiß gar nicht, wie weit du dich mit Dingen außerhalb von Scrum und Kanban beschäftigt hast. Von dem, was du da sonst so in diesem Kontext gesehen hast, was würdest du sagen, hörte oder fühlte sich vielleicht am seltsamsten an? Arne: Ich würde erst einmal was sagen wollen zu dem Freaking. Es war nämlich so, das ist mir auch sehr in Erinnerung geblieben. Jetzt gehen wir wieder zurück in die Anfangszeit, also tatsächlich so Agiles Manifest, also Anfang der 2000er. Im Zusammenhang mit dem XP-Buch, was ich dann da gelesen hatte, da gab es da so ein paar Sachen, die ich total cool fand. Zum Beispiel diese Gummibärchen-Geschichte. Und ich weiß bis heute nicht, ob ihr euch das ausgedacht habt oder ob das eigentlich von jemand anderes übernommen wurde. Aber die Idee war ja, abstrakte Schätzmaße einzuführen, also weg von wir schätzen in Personentagen, was man heute ja als Storypoints meistens nimmt. Und ihr habt aber damals gesagt, man kann im Grunde alles dafür nehmen, das spielt keine Rolle, ob man das Storypoint nennt oder was anderes. Und wir nehmen jetzt Gummibärchen. Wir schätzen einfach die Größe von Projekten in Gummibärchen. Und wenn es zehn ist, dann ist es doppelt so groß wie fünf und alles andere spielt erstmal keine Rolle. Das fand ich cool und ich kann mich erinnern, wir hatten auch dann auf Konferenzen immer so ein großes Glas Gummibärchen da stehen. Und wenn Leute gefragt haben, was das soll, haben wir ihnen diese Geschichte erzählt. Es gab diese Idee, weil wir ja auch per Programming pushen wollten, zum einen hatte ich immer die Idee von der Schachuhr, dass man eine Schachuhr hinstellt und sagt, man drückt die immer abwechselnd wie bei so einem Schachspiel, damit beide ungefähr gleich viel Zeit an der Tastatur verbringen. Das hat sich nicht durchgesetzt. Ich es hat irgendwelche praktischen Gründe, dass das zu laut war oder zu unpraktisch oder so. Stefan Roock (it-agile): Anscheinend, anscheinend war das so, dass man die Uhr beim Ticken hören konnte und das als störend empfunden. Arne: Und dann fiel mir noch eine dritte Sache dazu ein, die sehr freaky war, aber auf eine coole Art und Weise, nämlich auch bezüglich Pair Programming. Da gab es ja verschiedene Witze drüber. Ich weiß, dass Henning eine Zeit lang, wenn er beim Kunden so Pitches gemacht hat und den verkaufen wollte, dass wir Software jetzt anders entwickeln als andere und dass die Kunden das ja auch mal probieren könnten mit dem Extreme Programming. und mit dem Pair Programming, dann hat er erklärt, was Pair Programming ist und hat gesagt, das ist doch total super, jetzt brauchen wir nur noch die Hälfte der Rechner und die Hälfte der Monitore, was man da an Geld sparen könnte, für die IT, weil die setzen jetzt zu zweit da dran. Das hat er natürlich nicht ernst gemeint. Aber in dem Zusammenhang gab es ja auch mal den Scherz, so einen Pair Programming Stuhl zu machen. Und da haben wir mit Photoshop so einen Bürostuhl gebaut, sozusagen, der eine doppelte Sitzfläche hat, wo zwei Entwickler auf so einem Bürostuhl sitzen können. Das haben wir dann im Web als Gag hochgeladen. Und ich kann mich erinnern, für eine Konferenz haben wir uns überlegt, das wäre doch cool, wenn wir so einen Stuhl wirklich hätten. Und dann habe ich verschiedene so Möbelbauer und Tischler und Metallwerker angefragt, ob die so einen Stuhl für mich bauen können. Und die haben mich aber alle angekuckt, als wäre ich nicht ganz dicht. Und das ist dann nichts geworden. Aber ich glaube, das wäre tatsächlich cool gewesen, so einen Per-Programming-Stuhl zu haben. Stefan Roock (it-agile): Tief. Im Kino gibt es ja manchmal so Love Seats für zwei Leute. Arne: Genau. Und dann kann man in der Mitte noch so einen Knopf haben, dass einem jemand Getränke trinkt, wie früher in den Verzerrkinos. Aber du hattest ja eigentlich was anderes gefragt, nämlich nach anderen Methoden. Genau, anderen Methoden. Stefan Roock (it-agile): Genau, was war vielleicht besonders seltsam? Arne: Ja, ich glaube, Crystal war für mich immer seltsam, weil das sowas Meta-artiges hatte. Und das habe ich nie richtig durchdrogen, wahrscheinlich auch, weil ich zu dem Zeitpunkt ja Software-Entwicklung auch wenig hautnah miterlebt habe und mir deswegen weniger darunter vorstellen konnte, wie das funktioniert und dann auf so einer Metaebene noch viel weniger. Und ich meine, eine Idee von Crystal war ja, dass du dir sozusagen deine eigene Methode zusammenbaust. Das war ja so eine Art Metabaukasten auf einer Art, oder? Stefan Roock (it-agile): Es gab ein Raster mit zwei Dimensionen. Die eine war, wie viele Leute sind beteiligt. Also im Grunde das ganze Skalierungsthema schon deutlich vorweggenommen. Und das andere war, wie kritisch ist die entwickelte Software. Also geht es ein bisschen Geld, geht es richtig viel Geld, geht es Menschenleben. Und dann... hat Alistair Coburn da dann verschiedene Segmente drin differenziert und die dann mit Farben versehen. Also Crystal Clear war das Einfachste. Es geht ein bisschen Geld und es ist typische Teamgröße an Leuten notwendig. Das ist dann die einfachste Art das zu tun. Und wenn du aber nachher 1000 Leute hast und da Menschenleben dran hängen, war das Argument, brauchst du einen anderen methodischen Ansatz. das gut zu händeln. Arne: Und ich kann mich erinnern, wir haben hier sehr lange so eine Broschüre zusammen mit dem D-Punkt-Verlag rausgegeben, wo wir vier verschiedene agile Methoden vorgestellt haben. Am Anfang so bisschen was ist Agilität insgesamt und dann vier verschiedene Methoden und da gab es etliche Auflagen von, das war sehr erfolgreich, allem weil wir die auch verschenkt haben. Und da hatten wir sehr lange die vier Methoden Scrum, XP, FDD und Crystal. Und wir haben ja lange versucht, das zum Laufen zu bringen, vor allem FDD. Crystal haben wir, glaube nie so versucht, aktiv zu pushen. Aber FDD haben wir eine ganze Zeit versucht, auch bekannter zu machen und dann auch irgendwie Beratung zu verkaufen. Das hat nicht so richtig funktioniert. Und dann wurden die ja, haben wir die schrittweise auch ausgetauscht. Also Kanban kam dann relativ schnell rein und dafür ist, glaube ich, Crystal zuerst rausgeflogen und dann, ich gar nicht was danach noch kam, ob dann da wie ein Start-up oder so. Aber wie auch immer, es gab halt noch mehr Methoden und es hat sich im Grunde nur Scrum durchgesetzt und dann kann man. Aber was in dem Zusammenhang auch noch eingefallen ist, die allererste Scrum-Schulung, die wir gemacht haben und zwar als Teilnehmer, also wir kamen ja aus dieser XP-Ecke und ihr hattet ja auch ein bisschen Ahnung von Scrum. und dann aber haben wir uns überlegt, wir wollen uns jetzt mal zertifizieren lassen, dass das richtig verstehen und haben dann ja Joseph Pell Ryan engagiert, der die erste Zertifizierungsschulung gemacht hat, also nur für IT Agile Kollegen. Und ich kann mich noch erinnern, dass er Scrum erklärt hat und dann immer von The Revenge of XP gesprochen hat und gesagt, ja Moment, redet keiner mehr über XP, sondern alle wollen nur Scrum, weil das halt einfacher ist und auch Management komplett. kompatibler. Aber irgendwann werden die Leute verstehen, dass man das ohne die richtigen technischen Praktiken nicht richtig umsetzen kann, dass man dann in lauter Probleme reinläuft und zack, Revenge of XP. Und auf eine Art hat er auch recht gehabt. Also es benutzt zwar keiner das Label XP, aber viele dieser Praktiken ohne die wäre ja moderne Softwareentwicklung kaum noch denkbar. Also Continuous Integration, Continuous Delivery, diese Geschichten, das Das ist ja tatsächlich so. Also wenn man das nicht richtig drauf hat, dann braucht man im Grunde auch kein Scum machen heutzutage. Stefan Roock (it-agile): Ja, wobei auch da mein Gefühl ist, dass an vielen Stellen das bei Weitem nicht so praktiziert wird, wie das gedacht war und da auch viele Missverständnisse herrschen, was eigentlich damit gemeint war. das sehen wir bei Kunden dass denen das durchaus auch massiv auf die Füße fällt, dass sie, dass die Hardskills nicht hetig sitzen und Arne: Hm. Stefan Roock (it-agile): Das insbesondere, wenn du mehrere Teams hast, die zusammenarbeiten, das tatsächlich noch wichtiger ist, als bei einem Setting, wo nur ein Team alleine arbeitet. Arne: Ja, und ich bin da wahrscheinlich auch gebiased, weil das schon bei Jimdo, so war das, da, glaube ich, recht gut war, und dann bei Spotify sowieso, dass das für mich irgendwie so völlig klar ist, dass man so arbeitet und dass das sozusagen schon, dass das die Basis ist, worauf man überhaupt erst aufbaut. Das mag in anderen Firmen noch bisschen anders sein, tatsächlich. Mir Stefan Roock (it-agile): Okay. Arne: ist noch eine andere Sache eingefallen, weil du ja... in den vorigen Podcasts auch öfter gefragt hast, welche Methode sollte man nochmal zurückbringen? Und ich glaube, bisschen zielte jetzt auch die Frage darauf ab. Das ist keine Methode, aber mir ist nochmal was anderes eingefallen. Damals haben wir relativ viel von MMFs gesprochen. Minimal Marketable Features. Das kam, glaube ich, aus diesem Buch Software bei Numbers, Stefan Roock (it-agile): Mhm. Arne: wo ja, das waren zwei Autoren, namen, keine Ahnung. habe ich vergessen. Und da war es aber sehr stark, das ging, glaube ich, gar nicht Agilität, sondern darum, wie kann man Software möglichst schnell, möglichst profitabel machen. Also die hatten jetzt so viele Return on Investment Kurven. Also wie cool ist das, wenn man schnell eine erste Version am Start hat, kann man damit schon Geld verdienen und dann so Geschichten. Und die hatten dieses Konzept von Minimal Marketable Feature, was ich eigentlich total cool fand und das finde ich bis heute auch noch cool. Aber ich habe da seit 15 Jahren niemanden mehr darüber reden hören. Da würde mich deine Meinung auch zu interessieren. Die Idee war ja, wir bauen etwas, was möglichst klein ist, dass wir schnell in den Markt bringen, aber groß genug, dass es tatsächlich einen ernstenehmenden Kundennutzen hat. Und sie hatten so einen lustigen Test dafür, wann ist denn jetzt das groß genug? Und ich glaube, das war so der Chief Marketing Officer würde jetzt einen Blogpost darüber schreiben, so in der Art. Und wenn der sagt, ja, okay, das ist cool genug, für unsere Kunden, ich jetzt einen Blog poste oder ein Newsletter darüber schreibe, dann erfüllt es diese Kriterien. Und ich vermute, der Grund, warum da keiner mit überredet ist, weil dann irgendwann die Start-up aufkam mit dem Minimal Viable Product und Leute das durcheinander geworfen haben, aber es hat eigentlich fast nichts miteinander zu tun. Stefan Roock (it-agile): Ja, zumindest nicht in der Lean Startup Definition. Und es inzwischen herrscht nach meiner Wahrnehmung auch nicht die Lean Startup Definition vor. Also MVP, Minimum Viable Product, also brauchbar. Die Lean Startup Definition war ja, ist es brauchbar, ohne Annahme zu testen. Also eine Landing Page zu machen, ohne was dahinter, wäre eine MVP, weil ich könnte eine Annahme testen, ob Leute irgendwo drauf klicken. Aber aus Kundensicht ist das Ganze ja nicht brauchbar. Und heute hat sich halt mehr durchgesetzt, dieses brauchbar aus Kundensicht. Und das erzeugt auch immer wieder Probleme, weil da zwei unterschiedliche Definitionen von MVP unterwegs sind. Und das, was mehr dieses vorherrschende brauchbar aus Kundensicht, das korreliert stärker mit dem MMF aus meiner Sicht. Der große Unterschied ist, dass bei dem MVP Ansatz wird ja auf das erste Release hingearbeitet. Das heißt, ich definiere Upfront nur ein MVP. Also Arne: Mhm. Stefan Roock (it-agile): was soll das leisten können? Bei dem MMF-Ansatz aus dem Software bei Numbers war ja die Idee, dass ich das Gesamtvorhaben in eine Sequenz von MMFs zerlege oder erst mal eine Reihe von MMFs, die möglichst unabhängig voneinander sind und dann eine wirtschaftliche Optimierung der Reihenfolge mache. Arne: Mhm. Stefan Roock (it-agile): Was sollte ich als erstes bauen und als zweites, als drittes? Weil die Annahme war, dass so ein gieriger Ansatz, also zu sagen, ich nehme das, was jetzt am meisten die beste Kosten-Nutzen-Reallation hat, und danach nehme ich das nächste, was die beste Kosten-Nutzen-Reallation hat, nicht in jedem Fall die optimale Sequenz erzeugt, sondern Arne: Mhm. Stefan Roock (it-agile): dass es so Edge-Cases gibt. wo es anders Auch die Beispiele in dem Buch sind halt so, dass man sagt, ja, man kann da irgendwie 20 Prozent rausholen. Ist vielleicht nicht so mehrermäßig viel. Und ich glaube, in dem Buch sind halt relativ komplizierte wirtschafts- mathematische Verfahren drin, wie man diese Reihenfolge ausrechnet. Ich glaube, das würde man heute einfach mit Cost of Delay vereinfachen. Also dass man nicht mit so abgezinsen Nettowerten und Prognosen darüber, wie sich Zinsen und Geldwerte entwickeln, mehrere Jahre in die Zukunft hantiert. Ich glaube, das ist auch für die allermeisten Leute, das wäre dann eher so Product ohne Aufgabe, wahrscheinlich too much. Arne: Ja, trotzdem glaube ich, es sinnvoll, ähnliches Konzept zu haben, vielleicht eine andere Benennung, da genau was du angesprochen hast, das mal aufzuräumen, diese Unklarheit mit dem MVP. Also die Idee ist ja cool. Ich glaube, es hat insgesamt mehr Schaden angerichtet, als es geholfen hat. Und auch ein bisschen mehr drüber zu reden. über die Wirtschaftlichkeit. Also, wann ist es denn jetzt wirklich soweit, dass wir es wirklich reasen wollen und damit Geld verdienen wollen? Und natürlich wollen wir das möglichst früh. Oder geht es eigentlich darum, hier was zu lernen? Und es gibt ja diesen, das fand ich tatsächlich auch mal cool an die Seite, diesen Earn or Learn. Also man hat diesen Zyklus von Build, Measure, Learn, wo es eigentlich darum geht, was zu lernen. Und dann irgendwann sagt man, jetzt haben wir genug gelernt und jetzt gehen wir in den Earn-Zyklus. Und jetzt bauen wir was, was wir dann wirklich auch vermarkten und verkaufen. Das muss vernünftige Qualität haben. Und in meiner Erfahrung gibt es da wahnsinnig viel Unklarheit und Verwirrung ins Himd, drüber, was wir jetzt gerade machen, weil dann auch Leute alles Mögliche rein projizieren in den Begriff MVP. Stefan Roock (it-agile): jetzt haben wir viel über die Vergangenheit und die Gegenwart geredet. Was bringt denn die Zukunft? Arne: Ja, ich bin immer vorsichtig bei Vorhersagen. Man weiß ja, die sind schwierig, vor allem wenn sie die Zukunft betreffen. Und gerade was KI angeht, bin ich manchmal ein bisschen genervt, weil irgendwie alle genau wissen, was jetzt in ein, zwei, fünf Jahren passiert. Und ich glaube, richtig weiß es eigentlich keiner. Natürlich wird KI einen großen Einfluss haben auf unsere Arbeitswelt, also überhaupt keine Frage, wie genau das aussieht, das weiß ich nicht. Ich glaube, Agilität wird weiterleben, vielleicht unter anderem Namen, wird sich weiterentwickeln, aber es gibt, glaube ich, keine Alternative dazu. Eine Sache, über die ich tatsächlich nachgedacht habe im Zusammenhang mit KI auch, ich hatte gesagt, ich habe mich jetzt sehr intensiv mit dem Thema Teams beschäftigt und Teamdesign und wie man Teams unterstützen kann. Und habe dazu auch sehr, sehr, sehr viele wissenschaftliche Paper gelesen, weil mich das ein bisschen genervt hat, dass wir immer davon ausgehen, wir wissen, wie Teams funktionieren. Und dann gab es viele Sachen, irgendwie so Halbwahrheiten sind oder so Sachen, die mal weitergetragen wurden. Und ich wollte mal besser verstehen, was sagt eigentlich die Wissenschaft dazu. So, und deswegen habe ich mich jetzt viel mit dem Thema Teams beschäftigt. Und in dem Zusammenhang gibt es ja auch Leute, die sagen, durch KI braucht man keine Softwareentwicklungsteams mehr, sondern es gibt dann nur noch einen, zum Beispiel Product Owner, und der hat dann sein seine Agenten und die orchestriert er oder sie dann und die entwickeln die Software und dann ist das im Grunde ein Personenteam oder die anderen Teammitglieder sind halt keine Menschen mehr. Und ich bin da skeptisch. Ich glaube nicht, dass das passiert. Wenn ich jetzt doch nur vorher sage, treffen wir uns. Ich kann mir vorstellen, dass das natürlich viel, viel effizienter wird und dass man weniger Entwickler braucht, dieselbe Menge Code zu schreiben. Oder dass man mit derselben Menge entwickeln, viel, viel mehr Code schreiben kann. Das steht, glaube ich, außer Frage. Ich glaube aber, dass es ein sehr menschliches Bedürfnis ist, als Team zusammen zu arbeiten. Und insofern glaube ich, dass es auch in Zukunft Teams geben wird und auch Softwareentwicklungsteams, werden vielleicht anders aussehen. Also die Skills sind anders, die man dann braucht. Dann ist es vielleicht nicht mehr ein Backendentwickler, Frontendentwickler, ein Designer. Vielleicht sind die Teams kleiner. Vielleicht sind die auch weniger stabil. Das weiß man nicht. Aber ich Teams wird es auch in Zukunft geben in der Softwareentwicklung. Stefan Roock (it-agile): Dann hast du damit auch das angesprochen, womit du dich gerade beschäftigst mit den Teams und Team-of-Teams-Geschichten. Du hast ja ein paar Blogposts dazu veröffentlicht, die können wir noch in die Show Notes tun, genauso wie die Kontaktmöglichkeiten zu dir. Dann danke ich dir viermals für deine Zeit, das interessante Gespräch und die Einsichten. Arne: Vielen Dank für die Einladung.