Easy Agile Podcast Ep.10 Kate Brodie, Direktorin für digitale KI und das CCAI-Programm bei Optus

„Tolles Gespräch mit Dave & Eric! Wichtigste Erkenntnis: Überarbeiten Sie die Darstellung der Organisationsstruktur von Easy Agile. Aufregendes Zeug!“

Nick Muldoon, Mitbegründer und Co-CEO von Easy Agile, wird von Dave West, CEO, und Eric Naiburg, COO, von Scrum.org begleitet.

In dieser Folge entpacken Nick, Dave und Eric die aktuelle agile Landschaft, erörtern die Rolle des agilen Muttersprachlers und betonen, wie wichtig es ist, vernetzte Teams aufzubauen, indem die Hierarchie umgedreht und Führungskräfte in unterstützende Rollen versetzt werden.

Sie betonen, wie wichtig es ist, die Menschen, die dem Problem am nächsten stehen, in die Lage zu versetzen, den Anruf zu tätigen, und letztendlich ein Umfeld zu schaffen, in dem Erfolg erzielt werden kann.

Wir wünschen euch viel Spaß mit der Folge!

Teile deine Gedanken und Fragen auf Twitter mit dem Hashtag #easyagilepodcast und tagge @EasyAgile.

Transkript:

Nick Muldoon:

Hallo Leute. Willkommen zum Easy Agile Podcast. Mein Name ist Nick Muldoon. Ich bin Mitbegründer und Co-CEO von Easy Agile, und heute kommen zwei wundervolle Gäste zu mir, Eric Naiburg, der Chief Operating Officer von scrum.org, und Dave West, der Chief Executive Officer von scrum.org. Bevor wir beginnen, möchte ich mich bei den traditionellen Hütern des Landes bedanken, von dem aus wir heute senden, den Menschen im Dharawal sprechenden Land. Wir erweisen den älteren, gegenwärtigen und zukünftigen Ältesten unseren Respekt und erweisen allen Aborigines, den Bewohnern der Torres Strait Islands und den Ureinwohnern der First Nations, die heute zu uns kommen, den gleichen Respekt. Also, meine Herren, vielen Dank, dass Sie sich etwas Zeit genommen haben. Wir wissen das wirklich zu schätzen.

Erik Naiburg:

Ich danke dir.

Nick Muldoon:

Ich schätze, ich würde gerne einfach reinspringen und, Dave, ich habe zuerst eine Frage an dich und eine weitere an dich, Eric. Ich würde gerne eine kurze Einschätzung der heutigen Agile-Landschaft bekommen, Dave, und ich schätze, die Veränderungen, die Sie vielleicht gesehen haben, jetzt, wo wir diese COVID-Lockdowns hinter uns haben, dieses Hin und Her, die COVID-Lockdowns.

Dave West:

Ja, es ist interessant. Also ich bin seit fast acht Jahren CEO hier bei scrum.org, und das hat sich in diesen acht Jahren ein wenig geändert. Ich denke, was wir erleben und ist, wage ich zu sagen, die Bereitstellungsphase, die Masseneinführung dieser agilen Arbeitsweisen und dieser agilen Denkweise in allen Branchen und in allen Organisationen. Es ist mehr als eine Sache der IT-Softwareentwicklung. Und ich denke, dass sich das während COVID beschleunigt hat. Interessant sind jedoch viele der Merkmale von Agile, die während COVID so wichtig wurden, insbesondere in Bezug auf befähigte Teams, insbesondere in Bezug auf Vertrauen, insbesondere in Bezug auf die Hierarchie und den Abbau von Hierarchien. Einige dieser Dinge werden in Frage gestellt, wenn wir zur neuen Normalität zurückkehren, die manche Leute lieber einfach nur normal hätten. Ich sehe also einiges davon. Im Allgemeinen ist Agile jedoch da, es ist gekommen, um zu bleiben. Ich denke, die Realität sieht so aus, dass die meisten Wissensarbeiter, insbesondere die Wissensarbeiter, die sich mit komplexen Arbeiten befassen, auf absehbare Zeit einen agilen Ansatz verwenden werden.

Nick Muldoon:

Und letzte Woche hast du... War es letzte Woche? Ich glaube, du warst zum ersten Mal von Angesicht zu Angesicht in Paris?

Dave West:

[Fremdsprache 00:02:37] Ich war und es hat tatsächlich die ganze Zeit geregnet, Nick. Also ja, ich habe viel Zeit drinnen in Paris verbracht.

Nick Muldoon:

Nun, was war die Meinung der Scrum-Trainer dort, aus den Gesprächen, die sie führen?

Dave West:

Ja, es war interessant. Wir haben viel über die Einführung in großem Maßstab, die Einführung in Unternehmen und die Herausforderungen gesprochen. Es ist lustig, dass es sich bei den Herausforderungen um Herausforderungen handelt, die Sie erwarten, und bei den meisten geht es um Menschen, veraltete Systeme, den Status der Mitarbeiter und die Machtposition. Wir haben viel über die Herausforderungen gesprochen, vor denen Teams in diesen großen, komplizierten Organisationen stehen. Das ist weiterhin das Gespräch. Es gibt offensichtlich Europa, sie stehen der Ukraine und dem dortigen Konflikt sehr nahe. Es gibt also definitiv einige Gespräche darüber. Wir haben sechs ukrainische Trainer und ungefähr die gleiche Anzahl russischer Trainer. Das ist also immer ein Gespräch. Und dann ist da noch ein allgemeiner Abschwung der Wirtschaft, über den auch gesprochen wurde.

Entlassungen finden in ganz Europa statt, insbesondere im Technologiesektor, aber ich denke, das nimmt bis zu einem gewissen Grad zu. Vodafone hat heute gerade angekündigt, dass sie entlassen werden, es sind etwa 6.000 Mitarbeiter, und sie sind zum Beispiel eines der größten Telekommunikationsunternehmen in Deutschland. Davon gab es definitiv einiges, aber wenn Sie Unternehmen hinzufügen, fügen Sie Konfliktunsicherheit hinzu, Sie fügen wirtschaftliche Unsicherheit hinzu, diese drei Dinge werden zusammenkommen. Aber was daran lustig war, ist, dass sie bei all dem unglaublich optimistisch und aufgeregt waren. Und ich denke, weil sie mit Leuten sprechen, mit denen sie noch nie zuvor gesprochen haben, sprechen sie mit Leuten darüber, dass Scrum eine natürliche Arbeitsweise ist, sie sprechen über die Herausforderungen, die sich aus starken Teams, Empirismus und kontinuierlicher Verbesserung ergeben.

Und ich hatte einige wirklich spannende Gespräche mit Trainern, die sagten: Ja, nun, wir machen das in diesem Luft- und Raumfahrtunternehmen oder diesem Elektroautozulieferer in Deutschland oder was auch immer, oder in diesem Finanzdienstleistungs-Startup, das Blockchain zum ersten Mal verwendet. Und natürlich verwenden sie Agile. Und so war es lustig. Es war fast so, als ob all diese Dinge, obwohl es den Hintergrund gab, trotzdem unglaublich positiv waren.

Nick Muldoon:

Also, das ist interessant, und ich denke, wenn ich über die Hintergründe von euch beiden nachdenke, Eric, dann sehe ich, dass ihr beide seit rationalen Tagen zusammengearbeitet habt...

Erik Naiburg:

Ein paar Mal.

Nick Muldoon:

... ein paar Mal, aber die Prävalenz der Agilen... Ich würde euch beide als agile Ureinwohner beschreiben und es hört sich an, Dave, letzte Woche hast du deinen Stamm dort in Paris, der agile Eingeborene ist. Und ich schätze, Eric, welche Einstellung haben die Menschen, mit denen Sie in diesen Unternehmen aus der Führungsperspektive interagieren, für Sie? Können Sie die Agile-Ureinwohner identifizieren? Ja, ich denke, ist es einfacher, sich zu unterhalten, wenn es in der Führungsebene agile Natives gibt?

Erik Naiburg:

Es ist definitiv ein einfacheres Gespräch, wenn sie da sind. Manchmal verstecken sie sich, manchmal sind es auch keine agilen Eingeborenen, die sich auch als agile Eingeborene ausgeben, was es immer ein bisschen schwierig macht, weil man die Zwiebel zurückschälen und herausfinden muss, wer sie sind und was ihre wahre Agenda ist. Ich habe letzte Woche mit einem CIO gesprochen, und er sprach von einer typischen Dauer von zwei bis drei Jahren. Was ist also ihre wahre Agenda? Was versuchen sie zu erreichen? Und Dave erwähnte die Menschen, die daran beteiligt sind, und Menschen sind oft der schwierigste Teil einer agilen Transformation oder agilen Arbeitens. Die Menschen wollen sich selbst schützen, sie wollen ihr Revier schützen, sie wollen die Dinge tun, die sie tun müssen, um auch erfolgreich zu sein. Sie sehen das also als Gespräche mit Führungskräften innerhalb von Organisationen, und sie wollen es besser machen, sie wollen sich verbessern, sie wollen schneller liefern, aber sie stehen immer noch unter diesem Druck. Organisationen, zumindest große Organisationen, haben sich nicht verändert. Sie haben immer noch Vorstände, und sie berichten immer noch an diese Gremien, und auch diese Gremien haben immer noch ihre eigenen Agenden.

Nick Muldoon:

Sie lassen mich an ein Gespräch erinnern, das ich vor mehreren Jahren geführt habe, aber auf einer Reise durch Europa, und es war mit dem Agile-Muttersprachler, der Agile Practice Lead war und wahrscheinlich nicht maskierte, wahrscheinlich war er legitim ein Agile-Native, aber sie sprachen über die gemischten Anreize für ihren, vielleicht nicht ihren direkten Leiter, aber den VP weiter oben. Und es war eigentlich ein, ich will nicht sagen, ein Nullsummenspiel, aber es gab eine Art Lehensache, bei der die verschiedenen VPs um Ressourcen kämpften, Leute, was auch immer, weil das weitere Boni freischalten würde. Aber am Ende des Tages ging es nicht darum, das gesamte Finanzdienstleistungsunternehmen zu optimieren. Sehen wir das heute noch?

Dave West:

Oh, sehr. Tatsächlich sagt ein Kollege von uns: „In der Wissenschaft gab es früher ein Sprichwort, Wissenschaft schreitet mit einer Beerdigung nach der anderen voran.“ Und ich denke, Agile hat definitiv einiges davon, hoffentlich keine Beerdigungen, sondern Pensionierungen.

Nick Muldoon:

Pensionierungen

Dave West:

Ruhestand.

Nick Muldoon:

Ja.

Dave West:

Ja. Die Realität ist, dass, wenn Sie die Anreize nicht aufeinander abgestimmt haben, wenn die Teams nicht auf diese Anreize ausgerichtet sind und die Führung nicht auf diese konsistenten Anreize ausgerichtet ist, Sie immer mit einigen Herausforderungen zu kämpfen haben werden. Was so frustrierend ist, ist, dass wir alle wissen, dass die industrielle Revolution und insbesondere die jüngste Revolution der Massenproduktion und des Öls, die gerade in der Einsatzphase kurz nach dem Zweiten Weltkrieg stattfand, durch veränderte Arbeitspraktiken ermöglicht wurde, die von Leuten wie Ford und Deming und all diesen Menschen geschaffen wurden. Das wissen wir alle. Die digitale Revolution findet um uns herum statt. Es könnte sogar an uns vorbeigehen, wenn Sie dem KI-Buzz glauben, der gerade passiert. Wir werden vielleicht zur Seite gestellt und Computer übernehmen vielleicht einfach die Kontrolle, aber diese Digitalisierung passiert, und Sie sind mit Führungskräften zusammen und sie sagen: „Ja, respektiere das absolut. Wir werden hundertprozentig digital sein. Wir sind eine Fluggesellschaft, aber in Wirklichkeit sind wir ein digitales Unternehmen mit Flügeln.“

Sie beschreiben sich selbst auf diese Weise, und dann wollen sie nicht die Grundlagen in Frage stellen, wie Autorität verwaltet wird, wie Werte verwaltet werden, wie Risiken transparent gemacht werden, wie Regierungsführung abläuft, wie Finanzierung und Planung usw. erfolgen. Sie wollen keine dieser Annahmen in Frage stellen. Sie mögen das so wie es ist. Aber wir werden digital. Es ist ironisch, dass es immer noch passiert. Das ist jedoch nicht ganz hundertprozentig. Die Organisationen, die das verstehen, die Organisationen mit Führungskräften, die entweder aufschlussreich oder motiviert sind oder vielleicht ein Buch schreiben wollen oder so. Vielleicht sind ihre Gründe nicht immer so klar, aber diese Führungskräfte ziehen diese Organisationen ins 21. Jahrhundert.

Tolles Beispiel. Proctor und Gamble, Gillette. Gillette, das neueste Peeling-Rasiermesser. Ich sehe, dass du es leider nicht benutzt hast, Nick, mit deinem ziemlich hübschen Bart. Also ja. Wie auch immer, ich benutze es oft, wie du siehst. Das Exfo... Wurde mit Scrum und Agile gebaut. Das ist Proctor and Gamble, eine uralte, okay nicht uralte, eine ältere Organisation, die es aber wirklich in sich hat. Sie erkennen, dass sie auf ganz andere Weise arbeiten müssen, wenn sie mit ihren Kunden, ihren Partnern, ihren Lieferanten Schritt halten wollen. Es sind also keine Rosen, aber es gibt sozusagen Rosen im Garten.

Erik Naiburg:

Und es geht noch weiter, wenn man an diese Organisation denkt, denkt man an das, was Gillette getan hat, es geht über das traditionelle agile Denken hinaus. Traditionelles agiles Denken, wir denken an Software, und das ist Technik, das ist Fertigung, das ist die Zusammenführung von Marketing, denn in solchen Organisationen bestimmt das Marketing, was das Produkt sein wird, und dann findet die Technik heraus, wie dieses Produkt geliefert wird und so weiter. Es geht also wirklich darum, die gesamte Organisation zusammenzubringen und herauszufinden, wie wir etwas liefern, und zwar gemeinsam. Ich denke, das ist eines der großen Dinge, die wir erleben. Und eine der großen Veränderungen, die Agile vorantreibt, ist das Team. Sie haben also über Anreize und Teamanreize gesprochen, das ist ein Teil davon, aber es geht um Teamverantwortung. Es ist Teamzusammenhalt.

Es ist so, dass sie sich letztendlich alle verantwortlich fühlen und diese Verantwortung als Team zusammenbringen, und ich denke sogar... Also meine Frau arbeitet in der Fertigung und es ist immer... Sie ist auf der Forschungs- und Entwicklungsseite und beschwert sich über die Marketing-Leute. Sie haben diese Gespräche über: „Nun, sie wissen nicht, was es braucht, um dieses Ding tatsächlich zu bauen. Sie haben einfach den Traum.“ Und indem sie sie in diesem Team zusammenbringen und sie wirklich ihre täglichen Drums haben, sie planen zusammen und führen sie diese harten Gespräche respektvoll, das fängt an, dieses Team aufzubauen und es so aufzubauen, dass sie tatsächlich schneller liefern können und mehr liefern können, was der Kunde will.

Dave West:

Kann ich mich einfach anlehnen, es tut mir leid, wir haben hier gerade ein bisschen die Kontrolle übernommen, Nick, aber ich möchte mich einfach auf etwas stützen, von dem Eric gesagt hat, dass es nur um die Teams geht. Eines der grundlegenden Probleme, die wir in vielen Organisationen sehen, ist die Hierarchie. Denn wenn man diese riesigen Hierarchien hat, heißt es natürlich: „Ich muss die Kontrolle über etwas haben. Ich muss die Verantwortung für Dinge übernehmen. Ich muss für bestimmte Dinge unverantwortlich davonkommen.“ So funktionieren Hierarchien. Und das untergräbt oft die Fähigkeit eines Teams, effektiv zu funktionieren. Wir müssen das umdrehen, sodass diese Hierarchien nicht mehr an der Spitze der Teams stehen, sondern unter den Teams stehen müssen, die sie unterstützen. Stell sie dir vor wie die Stützbalken auf Brücken oder was auch immer. Sie haben einige fabelhafte Brücken in Australien und in Melbourne und an solchen Orten und in Sydney.

Stellen Sie es sich also kopfüber vor und halten Sie die Teams auf den Kopf. Aber das bedeutet, um noch einmal auf Anreize zurückzukommen, dass diese Führungskräfte verstehen müssen, wofür sie in dieser neuen Welt verantwortlich sind. Und das tun sie aus einem sehr guten Grund. Sie tun es, weil die Teams sein müssen, weil sie näher am Problem sind, sie müssen in die Lage versetzt werden, Entscheidungen in Echtzeit auf der Grundlage der Daten und der Informationen zu treffen, die sie haben, sie müssen eine klare Sichtlinie zum Kunden haben. All diese Dinge sind der Grund, warum eine Hierarchie einfach zu langsam reagiert und zu bürokratisch ist. Also müssen wir es umdrehen und diese Teams unterstützen. Und das ist eine große Herausforderung.

Nick Muldoon:

Ich liebe das. Ihr zwei habt mir etwas zum Nachdenken gegeben. In den ersten sechs Lebensjahren des Unternehmens, von Easy Agile, hatten wir also eine sehr einfache Teamseite, und Dave und ich als Co-CEOs standen ganz unten auf der Seite. Und dann hatten Sie die Anführer der Säulen. Sie hatten also, zu der Zeit war Tegan der Produktleiter, der Leiter, und sie saßen auf Dave und mir, und dann saß das Team an der Spitze. Und es ist interessant, ich versuche gerade darüber nachzudenken, dass diese Seite oder diese Visualisierung wahrscheinlich erst in den letzten 12 oder 18 Monaten, als wir 40 Leute besucht haben, umgeblättert hat. Ich habe natürlich einen Aktionspunkt, der daraus hervorgehen muss, danke, meine Herren, um ihn tatsächlich umzudrehen, weil es ein Kommunikationsmechanismus ist, aber wenn wir uns in dieser unterstützenden Rolle zur Unterstützung der Leute tatsächlich in die Grundlage stellen, gibt das, glaube ich, den Ton an, wie die Teammitglieder über sich selbst denken, und vielleicht auch diesen Beitrag zur Rechenschaftspflicht, Eric.

Erik Naiburg:

Ja. Ja. Das ist interessant, denn manchmal sind es diese kleinen Dinge, die das Denken und Fühlen der Menschen verändern. Ich verwende viele Sportanalogien, wenn ich mit Menschen spreche und mich mit ihnen treffe, und vor allem, wenn Dave davon sprach, die Menschen zu stärken, die dem Problem am nächsten stehen. Im Sport müssen wir dasselbe tun. Wenn wir darauf warten müssen, dass der Trainer uns sagt, wir sollen den Ball weitergeben, wird das niemals passieren. Wir müssen es den Leuten ermöglichen, Entscheidungen zu treffen und diese Entscheidungen auf dem Spielfeld zu treffen. Das müssen wir auch auf Unternehmen anwenden. Erlauben Sie den Menschen, die dem Problem am nächsten sind und dem, was passiert, am nächsten sind, diese Entscheidungen auch innerhalb des Unternehmens zu treffen.

Nick Muldoon:

Wenn wir also zu Proctor and Gamble zurückkehren und wir kein Kaninchenloch darauf werfen müssen, aber sie sind eines der großen, langlebigen Unternehmen, und ich weiß nicht, wie sie vor allem vorgehen, aber ich denke an GE, und GE hatte ihr internes Universitätsprogramm, und sie haben ihre Führungskräfte geschult, wie man führt. Wie geht ein Proctor and Gamble vor, um dieses Gespräch intern zu verändern, und was ist dieser Zeitrahmen? Weil Sie vermutlich mit jemandem beginnen, der in einem Team ist. Müssen Sie sie im Laufe der Zeit in der Hierarchie des Unternehmens verbessern?

Dave West:

Es ist interessant. Ich habe Glück, vielleicht weil wir beide Briten sind und in Boston leben. Ich habe das Glück, ziemlich viel Zeit damit zu verbringen, und auf unserer Website gibt es Videos dazu, übrigens, Interviews mit Dave Ingram, der R & D für Männerpflege leitet, es heißt, im Gillette-Teil von P and G. Und die Fallstudie ist da draußen. Also habe ich viel mit ihm darüber gesprochen, wie man es in einer riesigen Organisation vorantreibt, in der sie alles zu verlieren haben. Sie haben Produkte, die fantastisch sind, sie sind innovativ, diese Produkte sind die Produkte, die Sie in Ihren Einkaufswagen legen, wenn Sie den Gang entlang gehen. Sie wollen das nicht vermasseln. Seien wir ehrlich. Wenn plötzlich, aufgrund einiger Innovationen, keine Rasiermesser mehr in den Regalen stehen, dann brauche ich als Vorstandsmitglied ein Rasiermesser. Also werde ich ein alternatives Produkt kaufen, und es ist möglich, dass ich dann immer dieses Produkt kaufe.

Sie müssen also sehr, sehr vorsichtig sein. Sie haben mehr zu verlieren. Wir sprechen also viel darüber, wie Sie mit Veränderungen umgehen, und das ist alles oben Genannte. Was er sehr geschickt gemacht hat, ist, dass er die Rolle des Product Owners oder die Person, die Rolle des Klebers, gestärkt hat, ob es nun Scrum oder etwas anderes ist, und er hat wirklich in diese Change Agents in seiner Organisation investiert, und er wird definitiv davon geleitet, er war sehr ehrlich und offen darüber, dass er nicht alle Antworten hat und er nach ihnen sucht, die ihm dabei helfen, was Sie vielleicht nicht tun würden erwarten Sie von einer traditionellen Organisation, in der-

Nick Muldoon:

Der Leiter muss möglicherweise das Gefühl haben, die Antwort auf all diese Fragen zu haben.

Dave West:

Exakt. Und das hat er wirklich, wirklich gut gemacht. Und vor allem, weil er sagt: „Nun, mein Erfolg ist letztlich ihr Erfolg. Wenn ich sie also ein bisschen erfolgreicher machen kann, gibt es mehr von ihnen als mich, also lassen Sie uns dafür sorgen, dass es funktioniert.“ Was ich für eine ungewöhnlich ehrliche und sehr aufschlussreiche Sicht darauf halte. Er hat es also hauptsächlich in den Eigentumsbereichen des Produktmanagements vorangetrieben. Anschließend hat er eine entsprechende Support-Umgebung geschaffen. Dann hat er definitiv für die Erfolge geworben. Er hat viel Zeit damit verbracht, funktionsübergreifende Teams aufzubauen. Die Sache, von der Eric gesprochen hat. Und ich habe wirklich sehr vorsichtig mit ihrer Führung zusammengearbeitet. Wenn Sie Materialwissenschaft sind, gibt es eine ganze Abteilung, wenn es Marketing gibt, gibt es diese ganze Kanal-Sache, die sie haben. Im Grunde arbeiten sie mit ihren Führungskräften zusammen, um das Umfeld zu schaffen, in dem Erfolg eintreten kann. Und ich denke nicht, dass es einfach ist. Ich denke, auf dem Weg dorthin gibt es viele überraschende Hindernisse, und ich kann in dieser Hinsicht nicht für ihn sprechen, aber er hat den Ansatz des Teilens und Herrschens gewählt und sich auf diese Katalysatorrolle konzentriert.

Nick Muldoon:

Weil Sie offensichtlich eine Menge Schulungen für verschiedene, naja, ich schätze, Leute auf verschiedenen Ebenen in diesen Unternehmen anbieten. Und offensichtlich ist es weit davon entfernt, eine CST- und eine CSM- und eine CSPO-Zertifizierung zu haben, die ein Jahrzehnt, anderthalb Jahrzehnte zurückreicht. Wie hoch ist die Akzeptanz des Führungstrainings? Und wie sieht das aus, Eric? Besteht derzeit ein erneutes Interesse daran oder fordern die Leute mehr Führungskräftetraining? Ist es für die Führungskräfte von heute zweckdienlich?

Erik Naiburg:

Also ich denke, bis zu einem gewissen Punkt ist es so. Wir sehen sicherlich ein Wachstum in der Ausbildung von Führungskräften. Tatsächlich haben Dave und ich mir diese Zahlen Anfang dieser Woche oder gestern angesehen, schätze ich. Heute [unhörbar 00:21:29]

Nick Muldoon:

Gibt es Zahlen, die Sie mit uns teilen können?

Erik Naiburg:

Es ist schwierig, die genauen Zahlen zu nennen, aber wir verzeichnen einen zweistelligen Anstieg der Zahl der Schüler, die an unseren Führungskursen teilnehmen. Sowohl wie messen Sie, also unsere faktengestützten Managementkurse, als auch unser Führungstraining, aber das geht auch nur so weit, weil viele dieser Leute, je nachdem, wie weit Sie in der Organisation sind, nicht bereit sind, sich viel Zeit zu nehmen, um an solchen Schulungen teilzunehmen. Vieles davon passiert also in diesem Coaching. Sie stellen die Executive Coaches oder die Agile-Coaches ein, die da drin sind. Die Scrum Master, die da drin sind, arbeiten tatsächlich daran, diese Leute zu coachen. Und vieles davon dreht sich weniger um das Training als vielmehr um die Veränderungen der Denkweise. Wenn Sie sich also unseren Kurs zur agilen Führung ansehen, wird ein großer Teil davon darauf verwendet, die Menschen dazu zu bringen, anders zu denken. Und ein Teil davon hat dich wirklich überfordert, Aktivitäten, bei denen es wirklich hilft, diese Punkte zu vermitteln: „Wow, ich muss anders denken. Ich muss anders arbeiten. Ich muss die Menschen anders behandeln.“

Nick Muldoon:

Anders.

Erik Naiburg:

Das ist es, und wir sehen gute Erfolge damit, vor allem, wenn die Glühbirne bei den Leuten ausgeht und die Glühbirne, die ausgeht und sagt: „Wow, das ist anders.“ Wir haben einige Übungen in unseren Klassen, die dich wirklich zum Nachdenken anregen und dich anregen... Es gibt zum Beispiel eine, bei der Sie denken, Sie tun das Richtige für den Kunden, und Sie denken, dass Sie genau das Richtige tun, bis es den Kunden umbringt, weil Sie nicht unbedingt das Ganze durchdacht haben. Es heißt: „Nun, das ist es, was der Kunde wollte, also müssen wir es tun, aber vielleicht hätte ich mich mit dem Team zusammensetzen und das Team Entscheidungen treffen lassen sollen.“ Ich gehe ein bisschen extrem vor, aber...

Nick Muldoon:

Nein, ich weiß das zu schätzen.

Erik Naiburg:

... es sind solche Dinge, die wir ändern müssen. Und vieles, was wir im Kurs tun, ist, Führungskräfte darüber aufzuklären, was diese Teams gerade durchmachen und was die einzelnen Mitglieder dieser Teams benötigen und welche Art von Unterstützung sie benötigen, nicht wie man diese Teams leitet, nicht wie man mit diesen Leuten umgeht. Aber wie befähigt und befähigt man diese Menschen, erfolgreich zu sein?

Nick Muldoon:

Ich möchte nur kurz zurückspulen, tut mir leid.

Erik Naiburg:

Menschen töten.

Nick Muldoon:

Es klang, als gäbe es einen Reibungspunkt, wenn man diese Führungskräfte dazu bringt, sich die Zeit außerhalb des Büros zu nehmen, um sich weiterzubilden.

Erik Naiburg:

Das gibt es, ja.

Nick Muldoon:

Ist das richtig?

Erik Naiburg:

Ja.

Dave West:

Es ist unglaublich schwierig, wenn Sie in einer großen Organisation arbeiten, insbesondere wenn sich Ihr Terminplan ständig acht bis neun Stunden am Tag mit Besprechungen überschneidet, damit sie sich diesen Moment Zeit nehmen können, um einen Schritt zurückzutreten. Jeder, ich bin der festen Überzeugung, Nick, dass sich jeder Zeit nehmen muss, um in seine persönliche und berufliche Entwicklung zu investieren. Und diese Zeit ist keine Verschwendung. Letztlich ist es eine unglaublich gute Investition.

Nick Muldoon:

Ja.

Dave West:

Wir wissen...

Nick Muldoon:

Es ist ein großartiger ROI.

Dave West:

Vollkommen. Auch wenn es dich einfach verärgert, auch wenn du dadurch diesen Moment der Klarheit hast. Es ist keine Überraschung, dass Leute wie Bill Gates alle drei bis sechs Monate auf Exerzitien gehen und er seine große Tasche voller Bücher nimmt...

Nick Muldoon:

Buecher.

Dave West:

Und er geht für ein paar Tage vom Stromnetz, nur um ihn neu zu starten. Ich denke, dass diese Zeit unglaublich effektiv ist. Interessant ist jedoch, dass wir unterlegen sind, insbesondere in Amerika, und ich bin mir sicher, dass das in Australien stimmt, es ist sicherlich wahr, dass in England, wo ich herkomme, Bewegung wichtiger ist als Ergebnisse. Es dreht sich alles um die Anträge. Wenn du beschäftigt aussiehst, wirst du nicht gefeuert. Und ich denke, bis zu einem gewissen Grad haben wir das in der Schule gelernt. Ich weiß nicht, ob deine Eltern das zu dir gesagt haben oder ob du vielleicht deinen ersten Job bekommen hast. Ich habe an einer Feinkosttheke im Coop-Supermarkt gearbeitet, und ich erinnere mich, dass dort ein alter Arbeiter war, der sich zu mir umdrehte und sagte: „Was auch immer Sie tun, wenn der Manager vorbeikommt“, Mr. Short-

Nick Muldoon:

Sieh beschäftigt aus.

Dave West:

... war sein Name. Und er war alles, was der Name impliziert. „Mr. Short kommt vorbei, sieht aus, als ob Sie etwas tun, fangen Sie an, etwas zu putzen, sonst nimmt er Sie ab und zwingt Sie, Proviant zu machen, und Sie wollen sich nicht mit der Milch herumschlagen, sie ist ranzig.“ Und daran erinnere ich mich. Sieh beschäftigt aus. Und ich denke, wir haben viel in unserer Kultur. Ich versuche mir jede Woche Zeit zu nehmen. Ich buche zum Beispiel meine Mittagspause, ich buche sie und ich versuche immer, etwas darin zu tun. Ich versuche, mir einen TED-Vortrag anzusehen, etwas zu lesen, nur um dir den Kopf freizumachen, über etwas anderes nachzudenken. Ich denke, diese Zeit ist unglaublich wichtig. Allerdings...

Nick Muldoon:

Lernen Sie eine neue Perspektive kennen, oder?

Dave West:

Exakt. Auch wenn das heißt, auch wenn das Zeug, das du dir ansiehst oder was auch immer, nicht unbedingt relevant ist. Manchmal ist dieser Mangel an Relevanz genau das, was du brauchst, weil dein Verstand etwas tut.

Nick Muldoon:

Eine mentale Pause.

Dave West:

Exakt. Und in den amerikanischen Unternehmen, und ich denke, das ist im Allgemeinen ein Unternehmen, passiert das nicht. Die Leute sind übermäßig verschuldet, sie sind unglaublich beschäftigt. Sie müssen an diesen Treffen teilnehmen, sonst wird ihr Profil geschwächt. Und ich denke, das geht zu Lasten der Organisation und des Unternehmens. Hier ist eine Frage, Nick.

Nick Muldoon:

Ja.

Dave West:

Wem hast du in letzter Zeit geholfen?

Nick Muldoon:

Wem habe ich in letzter Zeit geholfen? Ich verbringe die meiste Zeit damit, und ich ziehe den größten Teil meiner Energie aus Coaching-Gesprächen mit Einzelpersonen. In meinem [unhörbaren 00:27:35] Profil habe ich einen Futuristen ganz weit oben, und deshalb liebe ich es herauszufinden, wie dein Leben und deine Karriere in fünf Jahren aussehen werden? Das sind die Gespräche, von denen ich wirklich begeistert bin.

Dave West:

Und das ist es, was jeder... Wem du geholfen hast, ist wichtiger als das, was du getan hast.

Nick Muldoon:

Ja.

Dave West:

Und ich denke, das musst du ausbalancieren.

Nick Muldoon:

Ich habe diese Statistiken abgerufen, weil ich dachte, Sie könnten sie interessant finden. Wir haben letztes Jahr eine Umfrage unter einer Untergruppe unserer Kunden durchgeführt. Und wir hatten 423 Teams. Es ist also keine riesige Stichprobengröße, sondern 423 Teams. Und der Grund, warum ich darüber nachdenke, ist, dass es eine Menge davon gibt, wie war die Statistik hier? Nur um dir ein Gefühl zu geben, die gängigste Sprintdauer sind 14- oder zweiwöchige Sprints. Die meisten Teams haben sechs Personen, die beteiligt sind. Fibonacci steht für Story Pointer, eine Schätzung. 10% dieser Teams haben erreicht, was sie sich zu Beginn des Sprints vorgenommen hatten. Also haben die Teams, diese 10% der Teams, die Teilmenge, ihren Sprints zwar Arbeit hinzugefügt, aber Teams, die erfolglos waren, rollten die Arbeit von Sprint zu Sprint weiter.

Vielleicht deutete es uns also an, dass es Teams gibt, die sich zu sehr verpflichten und zu wenig liefern, und tatsächlich scheinen 90% von ihnen, 90% der Umfrageteams, zu viel und zu wenig zu liefern. Und dann gibt es Teams, denen vielleicht Zeit bleibt, Dave, vielleicht für eine Ausbildung oder etwas Freizeit in ihrem zweiwöchigen Sprint. Und sie nehmen tatsächlich mehr Arbeit auf sich, und das erreichen sie auch. Und ich denke nur darüber nach, versuchen 90% dieser Teams, beschäftigt zu sein, oder versuchen sie, als beschäftigt wahrgenommen zu werden? Auch wenn das auf Kosten der tatsächlichen Umsetzung geht?

Erik Naiburg:

Oder werden sie sogar dazu gedrängt? Es ist interessant, bei unserem Professional Scrum Master One, unserem PSM-Test, gibt es eine Frage, bei der die Leute oft falsch liegen. Und ich denke, es ist eine großartige Frage, ich paraphrasiere, weil ich mich nicht mehr genau daran erinnern kann, aber es geht im Wesentlichen darum, wie viel des Sprint-Backlogs gefüllt werden muss, wenn es um die Sprint-Planung geht. Und eine beträchtliche Anzahl von Leuten sagt, dass es nach Abschluss der Sprint-Planung abgeschlossen sein muss. Das widerspricht Agile und Scrum.

Dave West:

Exakt.

Erik Naiburg:

Weil wir es dort nicht wissen. Da ist diese Unsicherheit. Alles, was wir brauchen, ist genug, um loszulegen, und wenn wir einmal angefangen haben, aber ich glaube, die Leute haben Angst vor: „Nun, wir haben zwei Wochen, wir müssen in der Lage sein, diese zwei Wochen zu planen, und das ist ein Teil des Drucks von oben, über den wir gesprochen haben. „Nun, wir müssen zeigen, dass wir hier zwei Wochen Arbeit vor uns haben und dass wir nicht herumsitzen, also füllen wir sie auf.“ Und das sind einige der falschen Bezeichnungen von Agile und Scrum. „Nun, es ist ein zweiwöchiger Sprint, wir müssen zwei Wochen einplanen.“ Nun, nein, das tun wir nicht. Wir brauchen ein Ziel. Wo werden wir hinkommen? Wie wir das erreichen, wird einige Zeit in Anspruch nehmen, denn wir werden im Laufe der Zeit lernen. Tatsächlich haben wir in dem Scrum-Team, dem ich gerade angehöre, einen dreiwöchigen Sprint durchgeführt, und nach zwei Wochen haben wir unser Ziel tatsächlich erreicht. Und jetzt können wir auf diesem Ziel aufbauen. Und wir haben dieses Ziel bereits eine Woche früher erreicht, was großartig ist.

Nick Muldoon:

Glaubst du, Eric, dass Führungskräfte befürchten, dass, wenn sie nicht zwei Wochen Arbeit geleistet haben, sie einfach ihre Daumen drehen werden?

Erik Naiburg:

Ich weiß nicht, ob es eine Angst vor der Führung ist. Ich denke, es ist eine Vorstellung, die die Arbeitnehmer davon haben, was die Führung denkt. Ich denke, es ist eher das. Und ich denke, es ist das: „Nun, wir haben gesagt, wir haben zwei Wochen“, und sie werden uns fragen, das Management wird sagen: „Wann liefern Sie?“ Ich weiß nicht, ob wir jemals davon wegkommen werden, wann werden wir eine Frage stellen, obwohl wir ständig versuchen, von dieser Antwort wegzukommen. Aber sie werden es fragen. Also, wenn sie danach fragen, sollte ich besser vorbereitet sein, was bedeutet, dass ich besser einen ganzen Haufen Arbeit vorbereitet habe. Und das macht einfach alles kaputt, was wir unterrichten. Es macht alles kaputt, was wir in Agile denken.

Und alles, was ich für die Planung brauche, ist ein Ziel und eine Vorstellung davon, wie ich dorthin komme. Und im Laufe der Zeit sollten wir es uns noch einmal ansehen und weiter darauf eingehen. Aber es erstaunt mich, wie oft einige der Antworten auf diese Frage lauten: Nach Abschluss der Sprint-Planung haben Sie einen vollständigen Sprint-Backlog, Sie haben genug, um loszulegen. Ich habe vergessen, was einige der anderen sind. Aber es erstaunt mich, wie oft, wenn ich Tests durchsehe, die Leute das Sprint-Backlog mit vollem Rücken platzieren, wo es sogar direkt im Scrum-Guide heißt: „Du wirst während des gesamten Sprints überprüfen und dich anpassen.“ Nun, wie inspiziere ich und passe mich an, wenn ich bereits entschieden habe, was ich tun werde?

Nick Muldoon:

Wer trägt die Verantwortung? Wenn es nicht wirklich der Wunsch der Führung ist, dass Sie Ihre gesamte Zeit voll nutzen und zu hundert Prozent ausgelastet sind, liegt es dann in der Verantwortung des Leiters, dies bekannt zu machen, oder liegt es in der Verantwortung des Teams, sich an der Konversation zu beteiligen?

Dave West:

Es ist der Anführer.

Erik Naiburg:

Ja.

Nick Muldoon:

Ja. Ja, beide. Ja.

Dave West:

Ich denke, es ist eher die Führungskraft, weil ich denke, sie müssen ein Umfeld schaffen, in dem das Team es tatsächlich herausfordern und diese sehr klare Konversation führen kann. Was mich an deinem Stan beunruhigt, ist die Tatsache, dass ich nicht... Die ersten paar Sprints. Ja, vielleicht bist du übermäßig aufgeregt, vielleicht füllst du den Sprint, was du nicht brauchst. Vielleicht bist du einfach scharf darauf. Das ist okay. Die Sache ist, was passiert beim dritten oder vierten oder fünften Sprint, wenn sich dasselbe Muster immer und immer wieder manifestiert. Das ist besorgniserregend. Und ich denke, das spricht wirklich deutlich für den Mangel an Hilfe, den das Team hat. Egal, ob man es Agile-Coach nennt, und in Australien, ich denke, der Begriff Agile-Manager wird verwendet, oder ob es ein Agile ist oder ob es ein Scrum Master ist, was auch immer. Scrum.org hat einen Scrum Master.

Und der Grund, warum wir einen Scrum Master haben, ist nicht, dass wir Scrum nicht kennen, obwohl es an manchen Tagen fraglich sein könnte. Aber Schusterkinder, all das Zeug. Aber die Realität ist, wir kennen Scrum, wir sprechen darüber, wir atmen es ein, wir lieben es. Aber jemanden zu haben, der einen Schritt zurücktritt und sagt: „Moment, Westy, was hast du da gemacht? Hast du das Team ermuntert, den Sprint zu füllen? Hast du ihnen ein unrealistisches Ziel gesetzt? Hast du ihnen zugehört und ihnen die Fragen gestellt? Oder hast du ihnen gesagt, was du willst? Und was glaubst du, wird das bewirken?“ Ich weiß, dass ich das getan habe, weil Eric und ich sozusagen die Sprints finanzieren. Wenn wir zu einem Sprint-Review gehen und Dinge sagen, weil ein Sprint-Review letztendlich dazu da ist, dem Team Feedback zu geben, damit es es überprüfen und sich für den nächsten Sprint anpassen kann.

Sie können die Vergangenheit nicht ändern, aber Sie können die Zukunft auf der Grundlage von Feedback ändern. Wenn ich sage: „Oh, nun, das ist Quatsch und du solltest das tun, und was ist damit?“ Ja, das wird Auswirkungen haben. Letztlich müssen wir als Führungskräfte also darüber nachdenken, was wir mitbringen, und auch jemanden haben, der uns oft hilft, die Führungskraft zu sein, die wir sein müssen, weil wir begeistert und begeistert sind und sagen: „Oh, du schaffst das und das? Lass es uns machen. Das klingt großartig.“ Und manchmal kann das...

Erik Naiburg:

Und das ist einer der Gründe, warum ich sage, dass es beides ist. Deshalb habe ich ja gesagt. Das ist Sache des Anführers, aber der Anführer muss daran erinnert werden. Der Leiter muss dadurch unterstützt werden, insbesondere vom Product Owner und dem Scrum Master. Der Product Owner muss in der Lage sein, nein zu sagen. Der Product Owner muss... Ich spreche von glücklichen Ohren und die meisten CEOs und Führungskräfte sind...

Nick Muldoon:

Frohe Ohren?

Erik Naiburg:

Ja. Die meisten CEOs und Führungskräfte, mit denen ich zusammengearbeitet habe, haben, wie ich es nenne, gute Ohren. Sie kommen von einem Kunden oder sie sprechen mit einer Person und haben etwas gehört, das-

Dave West:

Mach das.

Erik Naiburg:

... das eine Person vielleicht für großartig gehalten hätte. Und als Nächstes stellen sie all diese neuen Anforderungen an das Team. Und ich habe in vielen Startups und großen Unternehmen gearbeitet, wo das sogar bei IBM passiert ist. Und der Product Owner muss in der Lage sein zu sagen: „Whoa, warte mal. Das ist eine großartige Idee. Lass uns drüber nachdenken. Und wir werden es in den Backlog aufnehmen, wir werden später darüber nachdenken. Aber lassen Sie uns das Team jetzt nicht von dem ablenken, was wir versuchen und was wir erreichen wollen.“ Und deshalb sage ich, es ist beides. Es geht nicht nur um den Anführer. Sie werden den Anführer nicht vollständig ändern. Du wirst sie nicht komplett ändern, um diese aufregenden Momente nicht zu erleben. Und das macht sie zu Unternehmern. Das macht sie zu dem, was sie sind.

Aber das Team muss in der Lage sein, zurückzuschlagen. Der Leiter muss diesen Pushback akzeptieren und der Scrum Master und der Product Owner sowie andere Teammitglieder müssen in der Lage sein, diesen Pushback hinzunehmen. Ich erinnere mich, dass ich sehr, sehr früh in meiner Karriere für eine Firma namens Logicworks gearbeitet habe. Wir hatten ein Datenmodell, ein kleines Datenmodellierungstool namens Irwin. Und ich erinnere mich, dass ich in meinem Würfel saß und der CEO gerade von einem Treffen mit einem Kunden zurückkam und vorbeikam und ich war Produktmanager-

Nick Muldoon:

Eric, tu das.

Erik Naiburg:

Und fängt an darüber zu reden, wir müssen das jetzt machen und bla, bla, bla, bla, bla. Es ist wie, naja, warte. Es ist wie, aber bla, bla, bla, sie sagten, sie würden es kaufen. Nun, erstens, hast du tatsächlich mit den Leuten gesprochen, die es benutzen? Oder hast du mit jemandem hier oben gesprochen, der keine Ahnung hat, wie er das Tool tatsächlich benutzt? Was die Antwort war, ein Gespräch zwischen den CEOs. Und nur weil sie es kaufen werden, wird das irgendjemand tun? Aber du musst in der Lage sein, diese Gespräche zu führen. Man muss dieses Vertrauen zum Teamleiter aufbauen, und vom Team zum Leiter, um Rückschläge hinnehmen zu können und sagen zu können: „Das ist eine interessante Idee. Wir werden das für die Zukunft in Betracht ziehen, aber im Moment haben wir einen Schwerpunkt. Wir haben ein Sprintziel und wir werden unser Sprintziel nicht zerstören, weil du dich auf etwas gefreut hast.“

Dave West:

Wie du siehst, Nick, fällt es mir wirklich schwer, irgendwelche meiner Ideen in unsere Organisation einzubringen, weil sie solche Dinge fragen. So nervig, Nick. Sie sagen: „Okay, das ist großartig. Ist das wichtiger als diese fünf Dinge, die derzeit unser Produktziel vorantreiben?“ Ich sage: „Pfui, was meinst du? Ich kann kein Dessert, kein Hauptgericht und keine Vorspeise haben? Ich muss eine auswählen, die einfach nicht fair ist.“ Und sie sagten: „Nun, wir könnten ein anderes Team gründen und dann erfordert das Investitionen. Es wird einige Zeit dauern.“ Und ich sage: „Oh Gott, hasst du es nicht, wenn du intelligente, kluge Teamkollegen hast?“ Es ist einfach schwer.

Nick Muldoon:

Dave und ich haben definitiv, also Dave Elkin, mein Mitbegründer, hat einen technischen Hintergrund und ich habe einen Produkthintergrund. Und wir haben definitiv in der letzten Zeit, wahrscheinlich in diesem Zeitraum, in den letzten 18 Monaten, als das Team gewachsen ist oder einen bestimmten Wendepunkt erreicht hat, festgestellt, dass wir in der Vergangenheit ganz bequem Gespräche darüber geführt haben, was ist mit dieser Idee und wie steht es damit? Und wir haben versucht, Dinge herauszupicken, und wir haben sie mit dem Team besprochen, aber es gab keine Erwartung, dass diese Dinge aufgegriffen werden würden. Und dann hatten wir ein paar Beispiele, bei denen Teams losgingen und dachten, sie müssten sich diese Dinge ansehen und wir sagten: „Oh, nein, nein, nein, nein, tut uns leid, wir sollten klarstellen, dass wir nur ein Brainstorming machen wollten oder wir wollten einen Gedanken aus unserem Kopf bekommen, und wir wollten eine Perspektive darauf, aber das sollte absolut nicht bedeuten, dass du ihm hinterherlaufen solltest.“ Und so hat sich die Sprache und die Art und Weise, wie wir solche Dinge oder Aktivitäten wie diese angehen mussten, sicherlich geändert.

Erik Naiburg:

Das habe ich in letzter Zeit oft gesehen-

Nick Muldoon:

[unhörbar 00:39:50] Wendepunkt.

Erik Naiburg:

... wahrscheinlich in den letzten zwei oder so Jahren. Und ich denke, vielleicht wegen der Fernbedienung, es hat es noch schlimmer gemacht, weil man nicht all die Emotionen und Dinge mitbekommt. Aber ich habe definitiv viel mehr davon gesehen, wie: „Nun, ich bin einfach“, mir wurde gesagt, dass das nicht übersetzt werden kann, „aber ich spucke nur herum und ich werfe einfach eine Idee raus, nur um ein Gespräch zu führen.“ Und weil der Anführer es gesagt hat, denken die Leute, dass es eine Tatsache ist und dass sie es tun wollen. Und alles, was sie getan haben, war: „Hey, ich habe dieses Ding gehört. Was denkst du?“

Nick Muldoon:

Was ist deine Perspektive?

Erik Naiburg:

Ja, genau. Und ich denke, als Führungskräfte müssen wir sehr vorsichtig sein, um die Auswirkungen dessen zu verstehen, was wir sagen, weil wir es vielleicht so sehen: „Ich werfe es einfach zur Diskussion hin.“ Jemand, der am Schreibtisch saß, hörte gerade: „Oh, sie wollen, dass wir das machen.“ Und ich habe das in letzter Zeit oft in Unternehmen gesehen, auch in unserem, wo die Art und Weise, wie etwas gesagt wird oder was gesagt wird, so übernommen wird, wie wir das tun müssen, anstatt zu sagen: „Hey, hier ist eine Idee, etwas zum Aufnehmen.“ Du bist also nicht allein, Nick.

Nick Muldoon:

Ich liebe es. Hey, Eric, Oregon, das ist ein toller Ort, um es zu nennen. Das heißt, und ihr habt mir, ihr beide habt mir viel zum Nudeln gegeben, also möchte ich mich bei unseren Zuhörern und der Crew von Easy Agile vielmals dafür bedanken, dass ihr heute zu uns gekommen seid. Das weiß ich wirklich zu schätzen. Es war wunderbar, dich im Podcast zu haben.

Dave West:

Nun, danke, dass du uns eingeladen hast. Wir sind wirklich dankbar, hier zu sein, und hoffentlich hat einiges davon Sinn gemacht, und ja, lasst uns als Gemeinschaft und als Welt, die auf diese Weise arbeitet, weiter wachsen, denn ich denke, wir haben eine Menge Probleme zu lösen. Ich denke, die Art und Weise, wie wir das tun, besteht darin, dass die Menschen effektiv und eigenverantwortlich arbeiten. Also lass uns die Welt verändern, Mann.

Nick Muldoon:

Ich liebe es. Okay, das ist großartig. Danke.

TL;DR

Henrik Kniberg, the agile coach behind Spotify's model, discusses how AI is fundamentally transforming software development. Key takeaways: AI tools like Cursor and Claude are enabling 10x productivity gains; teams should give developers access to paid AI tools and encourage experimentation; coding will largely disappear as a manual task within 3–4 years; teams will shrink to 2 people plus AI; sprints will become obsolete in favour of continuous delivery; product owners can now write code via AI, creating pull requests instead of user stories; the key is treating AI like a brilliant intern – when it fails, the problem is usually your prompt or code structure, not the AI. Bottom line: Learn to use AI now, or risk being left behind in a rapidly changing landscape.

Introduction

Artificial intelligence is fundamentally reshaping how software teams work, collaborate, and deliver value. But with this transformation comes questions: How do we maintain team morale when people fear being replaced? What happens to code quality when AI writes most of the code? Do traditional agile practices like sprints still make sense?

In this episode, I sit down with Henrik Kniberg to tackle these questions head-on. Henrik is uniquely positioned to guide us through this transition – he's the agile coach and entrepreneur who pioneered the famous Spotify model and helped transform how Lego approached agile development. Now, as co-founder of Abundly AI, he's at the forefront of helping teams integrate AI into their product development workflows.

This conversation goes deep into the practical realities of AI-powered development: from maintaining code review processes when productivity increases 10x, to ethical considerations around AI usage, to what cross-functional teams will look like in just a few years. Henrik doesn't just theorise – he shares real examples from his own team, where their CEO (a non-coder) regularly submits pull requests, and where features that once took a sprint can now be built during a 7-minute subway ride.

Whether you're a developer wondering if AI will replace you, a product owner looking to leverage these tools, or a leader trying to navigate this transformation, this episode offers concrete, actionable insights for thriving in the AI era.

About Our Guest

Henrik Kniberg is an agile coach, author, and entrepreneur whose work has shaped how thousands of organisations approach software development. He's best known for creating the Spotify model – the squad-based organisational structure that revolutionised how large tech companies scale agile practices. His work at Spotify and later at Lego helped demonstrate how agile methodologies could work at enterprise scale whilst maintaining team autonomy and innovation.

Henrik's educational videos have become legendary in the agile community. His "Agile Product Ownership in a Nutshell" video, created over a decade ago, remains one of the most-watched and shared resources for understanding product ownership, with millions of views. His ability to distil complex concepts into simple, visual explanations has made him one of the most accessible voices in agile education.

More recently, Henrik has turned his attention to the intersection of AI and product development. As co-founder of Abundly AI, he's moved from teaching about agile transformation to leading AI transformation – helping companies and teams understand how to effectively integrate generative AI tools into their development workflows. His approach combines his deep understanding of team dynamics and agile principles with hands-on experience using cutting-edge AI tools like Claude, Cursor, and GitHub Copilot.

Henrik codes daily using AI and has been doing so for over two and a half years, giving him practical, lived experience with these tools that goes beyond theoretical understanding. He creates educational content about AI, trains teams on effective AI usage, and consults with organisations navigating their own AI transformations. His perspective is particularly valuable because he views AI through the lens of organisational change management – recognising that successful AI adoption isn't just about the technology, it's about people, culture, and process.

Based in Stockholm, Sweden, Henrik continues to push the boundaries of what's possible when human creativity and AI capabilities combine, whilst maintaining a pragmatic, human-centred approach to technological change.

Transcript

Note: This transcript has been lightly edited for clarity and readability.

Maintaining Team Morale and Motivation in the AI Era

Tenille Hoppo: Hi there, team, and welcome to this new episode of the Easy Agile Podcast. My name is Tenille Hoppo, and I'm feeling really quite lucky to have an opportunity to chat today with our guest, Henrik Kniberg.

Henrik is an agile coach, author, and entrepreneur known for pioneering agile practices at companies like Spotify and Lego, and more recently for his thought leadership in applying AI to product development. Henrik co-founded Abundly AI, and when he isn't making excellent videos to help us all understand AI, he is focused on the practical application of generative AI in product development and training teams to use these technologies effectively.

Drawing on his extensive experience in agile methodologies and team coaching, Henrik seems the perfect person to learn from when thinking about the intersection of AI, product development, and effective team dynamics. So a very warm welcome to you, Henrik.

Henrik Kniberg: Thank you very much. It's good to be here.

Tenille: I think most people would agree that motivated people do better work. So I'd like to start today by touching on the very human element of this discussion and helping people maintain momentum and motivation when they may be feeling some concern or uncertainty about the upheaval that AI might represent for them in their role.

What would you suggest that leaders do to encourage the use of AI in ways that increase team morale and creativity rather than risking people feeling quite concerned or even potentially replaced?

Henrik: There are kind of two sides to the coin. There's one side that says, "Oh, AI is gonna take my job, and I'm gonna get fired." And the other side says, "Oh, AI is going to give me superpowers and give us all superpowers, and thereby give us better job security than we had before."

I think it's important to press on the second point from a leader's perspective. Pitch it as this is a tool, and we are entering a world where this tool is a crucial tool to understand how to use – in a similar way that everyone uses the Internet. We consider it obvious that you need to know how to use the Internet. If you don't know how to use the Internet, it's going to be hard.

"I encourage people to experiment, give them access to the tools to do so, and encourage sharing. And don't start firing people because they get productive."

I also find that people tend to get a little bit less scared once they learn to use it. It becomes less scary. It's like if you're worried there's a monster under your bed, maybe look under your bed and turn on the lights. Maybe there wasn't a monster there, or maybe it was there but it was kind of cute and just wanted a hug.

Creating a Culture of Safe Experimentation

Tenille: I've read that you encourage experimentation with AI through learning – I agree it's the best way to learn. What would you encourage leaders and team leaders to do to create a strong culture where teams feel safe to experiment?

Henrik: There are some things. One is pretty basic: just give people access to good AI tools. And that's quite hard in some large organisations because there are all kinds of resistance – compliance issues, data security issues. Are we allowed to use ChatGPT or Claude? Where is our data going? There are all these scary things that make companies either hesitate or outright try to stop people.

Start at that hygiene level. Address those impediments and solve them. When the Internet came, it was really scary to connect your computer to the Internet. But now we all do it, and you kind of have to, or you don't get any work done. We're at this similar moment now.

"Ironically, when companies are too strict about restricting people, then what people tend to do is just use shadow AI – they use it on their own in private or in secret, and then you have no control at all."

Start there. Once people have access to really good AI tools, then it's just a matter of encouraging and creating forums. Encourage people to experiment, create knowledge-sharing forums, share your own experiments. Try to role-model this yourself. Say, "I tried using AI for these different things, and here's what I learned." Also provide paths for support, like training courses.

The Right Mindset for Working with AI

Tenille: What would you encourage in team members as far as their mindset or skills go? Certainly a nature of curiosity and a willingness to learn and experiment. Is there anything beyond that that you think would be really key?

Henrik: It is a bit of a weird technology that's never really existed before. We're used to humans and code. Humans are intelligent and kind of unpredictable. We hallucinate sometimes, but we can do amazing things. Code is dumb – it executes exactly what you told it to do, and it does so every time exactly the same way. But it can't reason, it can't think.

Now we have AI and AI agents which are somewhere in the middle. They're not quite as predictable as code, but they're a lot more predictable than humans typically. They're a lot smarter than code, but maybe not quite as smart as humans – except for some tasks when they're a million times smarter than humans. So it's weird.

You need a kind of humble attitude where you come at it with a mindset of curiosity. Part of it is also to realise that a lot of the limitation is in you as a user. If you try to use AI for coding and it wrote something that didn't work, it's probably not the model itself. It's probably your skills or lack of skills because you have to learn how to use these tools. You need to have this attitude of "Oh, it failed. What can I do differently next time?" until you really learn how to use it.

"There can be some aspect of pride with developers. Like, 'I've been coding for 30 years. Of course this machine can't code better than me.' But if you think of it like 'I want this thing to be good, I want to bring out the best in this tool' – not because it's going to replace me, but because it's going to save me a tonne of time by doing all the boring parts of the coding so I can do the more interesting parts – that kind of mindset really helps."

Maintaining Code Quality and Shared Understanding

Tenille: Our team at Easy Agile is taking our steps and trying to figure out how AI is gonna work best for us. I put the question out to some of our teams, and there were various questions around people taking their first steps in using AI as a co-pilot and producing code. There are question marks around consistency of code, maintaining code quality and clean architecture, and even things like maintaining that shared understanding of the code base. What advice do you have for people in that situation?

Henrik: My first piece of advice when it comes to coding – and this is something I do every day with AI, I've been doing for about two and a half years now – is that the models now, especially Claude, have gotten to the level where it's basically never the AI's fault anymore. If it does anything wrong, it's on you.

You need to think about: okay, am I using the wrong tool maybe? Or am I not using the tool correctly?

For example, the current market leader in terms of productivity tools with AI is Cursor. There are other tools that are getting close like GitHub Copilot, but Cursor is way ahead of anything else I've seen. With Cursor, it basically digs through your code base and looks for what it needs.

But if it fails to find what it needs, you need to think about why. It probably failed for the same reason a human might have failed. Maybe your code structure was very unstructured. Maybe you need to explain to the AI what the high-level structure of your code is.

"Think of it kind of like a really smart intern who just joined your team. They're brilliant at coding, but now they got confused about something, and it's probably your code – something in it that made it confused. And now you need to clarify that."

There are ways to do that. In Cursor, for example, you can create something called cursor rules, which are like standing documents that describe certain aspects of your system. In my team, we're always tweaking those rules. Whenever we find that the AI model did something wrong, we're always analysing why. Usually it's our prompt – I just phrased it badly – or I just need to add a cursor rule, or I need to break the problem down a little bit.

It's exactly the same thing as if you go to a team and give them this massive user story that includes all these assumptions – they'll probably get some things wrong. But if you take that big problem and sit down together and analyse it and split it into smaller steps where each step is verifiable and testable, now your team can do really good work. It's exactly the same thing with AI.

Addressing the Code Review Bottleneck

Tenille: One of our senior developers found that he was outputting code at a much greater volume and faster speed, but the handbrake he found was actually their code review processes. They were keeping the same processes they had previously, and that was a bit of a handbrake for them. What kind of advice would you have there?

Henrik: This reminds me of the general issue with any kind of productivity improvement. If you have a value stream, a process where you do different parts – you do some development, some testing, you have some design – whenever you take one part of the process and make it super optimised, the bottleneck moves to somewhere else.

If testing is no longer the bottleneck, maybe coding is. And when coding is instant, then maybe customer feedback – or lack of customer feedback – is the bottleneck. The bottleneck just keeps moving. In that particular case, the bottleneck became code review. So I would just start optimising that. That's not an AI problem. It's a process problem.

Look at it: what exactly are we trying to do when we review? Maybe we could think about changing the way we review things. For example, does all code need to be reviewed? Would it be enough that the human who wrote it and the AI, together with the human, agree that this is fine? Or maybe depending on the criticality of that change, in some cases you might just let it pass or use AI to help in the reviewing process also.

"I think there's value in code review in terms of knowledge sharing in a large organisation. But maybe the review doesn't necessarily need to be a blocking process either. It could be something you go back and look at – don't let it stop you from shipping, but maybe go back once per week and say, 'Let's look at some highlights of some changes we've made.'"

We produce 10 times more code than in the past, so reviewing every line is not feasible. But maybe we can at least identify which code is most interesting to look at.

Ethical Considerations: Balancing Innovation with Responsibility

Tenille: Agile emphasises people over process and delivering value to customers. Now with AI in the mix, there's potential for raising some ethical considerations. I'm interested in your thoughts on how teams should approach these ethical considerations that come along with AI – things like balancing rapid experimentation against concerns around bias, potential data privacy concerns.

Henrik: I would treat each ethical question on its own merits. Let me give you an example. When you use AI – let's say facial recognition technology that can process and recognise faces a lot better than any human – I kind of put that in the bucket of: any tool that is really useful can also be used for bad things. A hammer, fire, electricity.

That doesn't have so much to do with the tool itself. It has much more to do with the rules and regulations and processes around the tool. I can't really separate AI in that sense. Treat it like any other system. Whenever you install a camera somewhere, with or without AI, that camera is going to see stuff. What are you allowed to do with that information? That's an important question. But I don't think it's different for AI really, in that sense, other than that AI is extremely powerful. So you need to really take that seriously, especially when it comes to things like autonomous weapons and the risk of fraud and fake news.

"An important part of it is just to make it part of the agenda. Let's say you're a recruitment company and you're now going to add some AI help in screening. At least raise the question: we could do this. Do we want to do this? What is the responsible way to do it?"

It's not that hard to come up with reasonable guidelines. Obviously, we shouldn't let the AI decide who we're going to hire or not. That's a bad idea. But maybe it can look at the pile of candidates that we plan to reject and identify some that we should take a second look at. There's nothing to lose from that because that AI did some extra research and found that this person who had a pretty weak CV actually has done amazing things before.

We're actually working with a company now where we're helping them build some AI agents. Our AI agents help them classify CVs – not by "should we hire them or not," but more like which region in Sweden is this, which type of job are we talking about here. Just classifying to make it more likely that this job application reaches the right person. That's work that humans did before with pretty bad accuracy.

The conclusion was that AI, despite having biases like we humans do, seemed to have less biases than the human. Mainly things like it's never going to be in a bad mood because it hasn't had its coffee today. It'll process everybody on the same merits.

I think of it like a peer-to-peer thing. Imagine going to a doctor – ideally, I want to have both a human doctor and an AI doctor side by side, just because they both have biases, but now they can complement each other. It's like having a second opinion. If the AI says we should do this and the doctor says, "No, wait a second," or vice versa, having those two different opinions is super useful.

Parallels Between Agile and AI Transformations

Tenille: You're recognised as one of the leading voices in agile software development. I can see, and I'm interested if you do see, some parallels between the agile transformations that you led at Spotify and Lego with the AI transformations that many businesses are looking at now.

Henrik: I agree. I find that when we help companies transition towards becoming AI native, a lot of the thinking is similar to agile. But I think we can generalise that agile transformations are not really very special either – it's organisational change.

There are some patterns involved regardless of whether you're transitioning towards an agile way of working or towards AI. Some general patterns such as: you've got to get buy-in, it's useful to do the change in an incremental way, balance bottom-up with top-down. There are all these techniques that are useful regardless. But as an agilist, if you have some skills and competence in leading and supporting a change process, then that's going to be really useful also when helping companies understand how to use AI.

Tenille: Are you seeing more top-down or bottom-up when it comes to AI transformations?

Henrik: So far it's quite new still. The jury's not in yet. But so far it looks very familiar to me. I'm seeing both. I'm seeing situations where it's pure top-down where managers are like "we got to go full-out AI," and they push it out with mixed results. And sometimes just completely bottom-up, also with mixed results.

Sometimes something can start completely organically and then totally take hold, or it starts organically and then gets squashed because there was no buy-in higher up. I saw all of that with agile as well. My guess is in most cases the most successful will be when you have a bit of both – support and guidance from the top, but maybe driven from the bottom.

"I think the bottom-up is maybe more important than ever because this technology is so weird and so fast-moving. As a leader, you don't really have a chance if you try to control it – you're going to slow things down to an unacceptable level. People will be learning things that you can't keep up with yourself. So it's better to just enable people to experiment a lot, but then of course provide guidance."

AI for Product Owners: From Ideation to Pull Requests

Tenille: You're very well known for your guidance and for your ability to explain quite complex concepts very simply and clearly. I was looking at your video on YouTube today, the Agile Product Ownership in a Nutshell video, which was uploaded about 12 years ago now. Thinking about product owners, there's a big opportunity now with AI for generating ideas, analysing data, and even suggesting new features. What's your advice for product owners and product managers in using AI most effectively?

Henrik: Use it for everything. Overuse it so you can find the limits. The second thing is: make sure you have access to a good AI model. Don't use the free ones. The difference is really large – like 10x, 100x difference – just in paying like $20 per month or something. At the moment, I can particularly strongly recommend Claude. It's in its own category of awesomeness right now. But that of course changes as they leapfrog each other. But mainly: pay up, use a paid model, and then experiment.

For product owners, typical things are what you already mentioned – ideation, creating good backlog items, splitting a story – but also writing code. I would say as a PO, there is this traditional view, for example in Scrum, that POs should not be coding. There's a reason for that: because coding takes time, and then as PO you get stuck in details and you lose the big picture.

Well, that's not true anymore. There are very many things that used to be time-consuming coding that is basically a five-minute job with a good prompt.

"Instead of wasting the team's time by trying to phrase that as a story, just phrase it as a pull request instead and go to the team and demonstrate your running feature."

That happened actually today. Just now, our CEO, who's not a coder, came to me with a pull request. In fact, quite often he just pushes directly to a branch because it's small changes. He wants to add some new visualisation for a graph or something in our platform – typically admin stuff that users won't see, so it's quite harmless if he gets it wrong.

He's vibe coding, just making little changes to the admin, which means he never goes to my team and says, "Hey, can you guys generate this report or this graph for how users use our product?" No, he just puts it in himself if it's simple.

Today we wanted to make a change with how we handle payments for enterprise customers. Getting that wrong is a little more serious, and the change wasn't that hard, but he just didn't feel completely comfortable pushing it himself. So he just made a PR instead, and then we spent 15 minutes reviewing it. I said it was fine, so we pushed it.

It's so refreshing that now anybody can code. You just need to learn the basic prompting and these tools. And then that saves time for the developers to do the more heavyweight coding.

Tenille: It's an interesting world where we can have things set up where anyone could just jump in and with the right guardrails create something. It makes Friday demos quite probably a lot more interesting than maybe they used to be in the past.

Henrik: I would like to challenge any development team to let their stakeholders push code, and then find out whatever's stopping you from doing that and fix that. Then you get to a very interesting space.

Closing the Gap Between Makers and Users

Tenille: A key insight from your work with agile teams in the past has been to really focus on minimising that gap between maker and user. Do you think that AI helps to close that gap, or do you think it potentially risks widening it if teams are focusing too much on AI predictions and stop talking to their customers effectively?

Henrik: I think that of course depends a lot on the team. But from what I've seen so far, it massively reduces the gap. Because if I don't have to spend a week getting a feature to work, I can spend an hour instead. Then I have so much more time to talk to my users and my customers.

If the time to make a clickable prototype or something is a few seconds, then I can do it live in real time with my customers, and we can co-create. There are all these opportunities.

I find that – myself, my teams, and the people I work with – we work a lot more closely with our users and customers because of this fast turnaround time.

"Just yesterday I was teaching a course, and I was going home sitting on the subway. It was a 15-minute subway ride. I finally got a seat, so I had only 7 minutes left. There's this feature that I wanted to build that involved both front-end and back-end and a database schema change. Well, 5 minutes later it was done and I got off the subway and just pushed it. That's crazy."

Of course, our system is set up optimised to enable it to be that fast. And of course not everything will work that well. But every time it does, I've been coding for 30 years, and I feel like I wake up in some weird fantasy every day, wondering, "Can I really be this productive?" I never would have thought that was possible.

Looking Ahead: The Future of Agile Teams

Tenille: I'd like you to put your futurist hat on for a moment. How do you see the future of agile teamwork in, say, 10 to 15 years time? If we would have this conversation again in 2035, given the exponential growth of AI and improvements over the last two to three years, what do you think would be the biggest change for software development teams in how they operate?

Henrik: I can't even imagine 10 years. Even 5 years is just beyond imagination. That's like asking someone in the 1920s to imagine smartphones and the Internet. I think that's the level of change we're looking at.

I would shorten the time a little bit and say maybe 3 or 4 years. My guess there – and I'm already seeing this transfer happen – is that coding will just go away. It just won't be stuff that we humans do because we're too slow and we hallucinate way too much.

But I think engineering and the developer role will still be there, just that we don't type lines of code – in the same way that we no longer make punch cards or we no longer write machine code and poke values into registers using assembly language. That used to be a big part of it, but no longer.

"In the future, as developers, a lot of the work will still be the same. You're still designing stuff, you're thinking about architecture, you're interacting with customers, and you're doing all the other stuff. But typing lines of code is something that we're gonna be telling our kids about, and they're not gonna believe that we used to do that."

The other thing is smaller teams, which I'm already seeing now. I think the idea of a cross-functional team of 5 to 7 people – traditionally that was considered quite necessary in order to have all the different skills needed to deliver a feature in a product. But that's not the case anymore. If you skip ahead 2 or 3 years when this knowledge has spread, I think most teams will be 2 people and an AI, because then you have all the domain knowledge you need, probably.

As a consequence of that, we'll just have more teams. More and smaller teams. Of course, then you need to collaborate between the teams, so cross-team synchronisation is still going to be an issue.

Also, I'm already seeing this now, but this concept of sprints – the whole point is to give a team some peace of mind to build something complex, because typically you would need a week or two to build something complex. But now, when it takes a day and some good prompting to do the same thing that would have taken a whole sprint, then the sprint is a day instead. If the sprint is a day, is there any difference between a sprint planning meeting and a daily standup? Not really.

I think sprints will just kind of shrink into oblivion. What's going to be left instead is something a little bit similar – some kind of synchronisation point or follow-up point. Instead of a sprint where every 2 weeks we sit down and try to make a plan, I think it'll be very much continuous delivery on a day-to-day basis. But then maybe every week or two we take a step back and just reflect a little bit and say, "Okay, what have we been delivering the past couple of weeks? What have we been learning? What's our high-level focus for the next couple of weeks?" A very, very lightweight equivalent of a sprint.

I feel pretty confident about that guess because personally, we are already there with my team, and I think it'll become a bit of a norm.

Final Thoughts: Preparing for the Future

Henrik: No one knows what's gonna happen in the future, and those who say they do are kidding themselves. But there's one fairly safe bet though: no matter what happens in the future with AI, if you understand how to use it, you'll be in a better position to deal with whatever that is. That's why I encourage people to get comfortable with it, get used to using it.

Tenille: I have a teenage daughter who I'm actually trying to encourage to learn how to use AI, because I feel like when I was her age, the Internet was the thing that was sort of coming mainstream. It completely changed the way we live. Everything is online now. And I feel like AI is that piece for her.

Henrik: Isn't it weird that the generation of small children growing up now are going to consider this to be normal and obvious? They'll be the AI natives. They'll be like, "Of course I have my AI agent buddy. There's nothing weird about that at all."

Tenille: I'll still keep being nice to my coffee machine.

Henrik: Yeah, that's good. Just in case, you know.

---

Thank you to Henrik Kniberg for joining us on this episode of the Easy Agile Podcast. To learn more about Henrik's work, visit Abundly AI or check out his educational videos on AI and agile practices.

Subscribe to the Easy Agile Podcast on your favourite platform, and join us for more conversations about agile, product development, and the future of work.

„Mein Gespräch mit Jon hat mir sehr gut gefallen. Er teilte einige großartige Perspektiven auf die Auswirkungen des Agile-Manifests mit“ - Amaar Iftikhar

Zu Amaar Iftikhar, Produktmanager bei Easy Agile, gesellt sich Jon Kern, Mitautor des Agilen Manifests für Softwareentwicklung und leitender Transformationsberater bei Adaptavist.

Amaar und Jon nahmen sich etwas Zeit, um über das Agile Manifest zu sprechen. Es wurde alles behandelt, von den Anfängen über die Ideenfindung, den Prozess und die ersten Reaktionen bis hin zu den Auswirkungen auf die heutige Welt des agilen Arbeitens.

Sie gehen auf den Idealzustand eines agilen Teams ein und darauf, was das Manifest für verteilte, hybride und am selben Standort ansässige Teams bedeutet.

Wir wünschen euch viel Spaß mit der Folge!

Transkript

Amaar Iftikhar:

Hallo zusammen. Willkommen zum Easy Agile Podcast. Mein Name ist Amaar Iftikhar. Ich bin Produktmanager hier bei Easy Agile. Und bevor wir beginnen, möchte Easy Agile den traditionellen Hütern des Landes, von dem aus wir heute senden, danken, den Menschen im Dharawal sprechenden Land. Wir erweisen den Ältesten in Vergangenheit, Gegenwart und Entwicklung unseren Respekt. Und gilt allen Aborigines, den Bewohnern der Torres-Strait-Inseln und den Ureinwohnern, die heute zu uns kommen, denselben Respekt.

Heute haben wir im Podcast Jon Kern zu hören, der Mitautor des Agilen Manifests für Softwareentwicklung und Agile-Berater ist. Wenn Sie sich das fragen, haben Sie Recht. Ich habe das Agile Manifest für Softwareentwicklung erwähnt. Das Agile Manifest. Also Jon, willkommen, dass du hier bist und danke, dass du zu uns gekommen bist.

John Kern:

Oh, das freut mich, Amaar. Oh, danke.

Amaar Iftikhar:

Ja, ich freue mich sehr, dich dabei zu haben. Fangen wir einfach mit den absoluten Grundlagen an. Erzählen Sie dem Publikum, was ist das Agile-Manifest?

John Kern:

Nun, es ist etwas, das, wenn Sie nicht da wären, und ich weiß, dass Sie jung sind, also vor 21 Jahren noch nicht da waren, ich schätze jetzt, um vielleicht zu verstehen, mit welchen Softwareentwicklungsprozessen und Tools und mit was die meisten von uns damals konfrontiert waren, es wie eine wirklich offensichtliche Reihe von wirklich einfachen Werten erscheinen könnte. Wer könnte denken, dass an dem, was wir in das Manifest aufgenommen haben, etwas falsch ist? Aber damals gab es Dinge, unter denen ich als... Ich bin Luft- und Raumfahrtingenieur, also habe ich im Verteidigungsministerium gearbeitet und Dinge wie Jagdflugsimulationen, F-14-Flachdrehungen und die Arbeit mit einer Zentrifuge und so coolen Sachen gemacht. Und es unterliegt einer Werksstandardspezifikation, was wahrscheinlich für Waffensysteme, den Flugzeugbau und alle möglichen anderen Dinge Sinn macht. Aber sie hatten eine, und siehe da, für die Softwareentwicklung. Also gab es in Bezug auf den Softwareentwicklungsprozess eine sehr große, was ich als Schwerfälligkeit bezeichnen würde. Wir nennen ihn einen schwergewichtigen Prozess. Wasserfall war damals der gebräuchliche Begriff und wird wahrscheinlich auch heute noch verwendet.

Und es gab viele, ich würde sagen, der Marketing-Moloch des Tages, einheitliche Prozesse von IBM und Rational, diese großen, die Safe sehr ähnlich waren. Wo es ein wirklich großes Werk ist, eine unglaubliche Menge an Informationen darin, aber ein sehr schwerer Prozess, obwohl alles, sagen wir, Sie würden es anpassen, es könnte sein, was Sie wollen. Ich habe zum Beispiel meinen eigenen, einfachen Prozess in REP abgebildet. Sicher. Aber die Realität war, dass wir es mit einer Art Schwergewicht wie dem Marktführer zu tun hatten, der einfach die Seele zermalmte und aus meiner Sicht das Geld der Steuerzahler verschwendete. Das war quasi mein Standpunkt, nun ja, ich bin Steuerzahler, ich werde dieses dumme Verfahren nicht einfach um des Prozesses willen durchführen. Das muss einen gewissen Wert haben, muss pragmatisch sein. Und siehe da, es gab eine Handvoll von uns, 17, die dort gelandet sind, aber es gibt eine Handvoll von uns, die leichtere Methoden praktizierten. Das Manifest war also wirklich eine Gelegenheit, zusammenzukommen und einige der Dinge zu entdecken, die man als Gemeinsamkeiten zwischen vielen verschiedenen leichten Praktiken bezeichnen könnte. Da war das XP-Kontingent. Ich habe dort zum Beispiel zum ersten Mal etwas über Scrum gelernt. Arie van Bennekum, ein guter Freund, hat uns etwas über DSDM beigebracht. Ich kann mich nicht einmal mehr erinnern, wofür es steht. Es war eine europäische Sache.

Alistair und Jim Highsmith hatten, ich vergesse, quasi kristalline Methoden. Es gab also eine ganze Reihe anderer Verfahren, bei denen der Marketingzweig nicht ausgebrochen war, oder bei denen es nicht um den Produktionsstandard ging. Es ging also wirklich nur darum, was wir unter uns finden konnten, was ein gemeinsames Thema über all diese leichten Verfahren war. Es ging also wirklich darum, das herauszufinden.

Amaar Iftikhar:

Ihr kommt alle zusammen, die Prinzipien kommen irgendwie zum Tragen, und lasst uns ein bisschen vorspulen. Was war die erste Reaktion auf das ursprüngliche Manifest?

John Kern:

Ja, es war sogar lustig, dass die vier Werte, die vier Kugeln so einfach sind wie früher. Die Prinzipien kamen etwas später. Ich möchte sagen, wir haben beim Award-Wiki zusammengearbeitet, aber das Original... Wenn du zu Agile Uprising gehst, kannst du sehen, dass ich ein paar Artefakte hochgeladen habe, weil ich anscheinend eine Rudelratte bin. Und ich hatte die Originaldokumente, die Alistair wahrscheinlich ausgedruckt hat, weil er derjenige war... Er und Jim lebten dort in der Nähe von Salt Lake City. Es war also wie: „Hey, lass uns herkommen.“ Und wir gehen gerne Skifahren, also machen wir es hier. Also arrangierte er das Zimmer und alles. Also gibt es ein paar lustige Artefakte, die du finden kannst. Und die Art und Weise, wie es tatsächlich zustande kam, war eine erste Einführung in jeden von uns in unsere Methoden. Und ich glaube wirklich, ein Schlüssel, wir haben unser Ego an der Tür gelassen. Ich meine, ich war jünger. Onkel Bob, einige davon, er war bei Luminar, ich weiß, ich habe immer noch Zeitschriften in der Scheune, von denen er entweder Herausgeber war oder von denen er Autor war, für Leute, die sich nicht erinnern können, was Zeitschriften sind. Kleine Heftchen, die herauskamen. Onkel Bob sagte also, Oh, wow, das ist ziemlich cool.

Und ich war nicht schüchtern, weil ich viel Erfahrung mit Schwergewichtsmethoden hatte. Also wollte ich unbedingt etwas dazu sagen... Weil ich ein paar Jahre zuvor meine eigene Lightweight-Methode veröffentlicht hatte. Ich hatte also viele Meinungen dazu, wie man den Herausforderungen eines großen Schwergewichtsprozesses aus dem Weg gehen kann. Der Höhepunkt, als wir aus der Tür gingen und nachdem wir uns die vier Werte ausgedacht hatten, war, glaube ich, dass Ward sagte: „Sir, möchten Sie, dass ich das ins Internet stelle?“ Und noch einmal, das ist 2001, also Punkt com und das Web ist sozusagen noch ziemlich neu. Und wir sagen alle, ja, klar, warum nicht? Was zur Hölle, kann nicht schaden. Wir haben etwas, wir können es genauso gut veröffentlichen. Ich glaube nicht, dass jemand zu einer Person gesagt hat: „Oh ja, das wird die Welt aus den Angeln heben, weil wir so großartig sind.“ Und wir wollten die Welt mit all dieser wunderbaren Weisheit salben. Ich glaube also nicht, dass irgendjemand dachte, dass so viel passieren würde.

Amaar Iftikhar:

Ja. Also, was hast du zu der Zeit gedacht? Also, wie wären die Prinzipien, die ihr gemeinsam ausgedacht habt, vielleicht nur für das Team zum Mitnehmen? Jeder, der da war? Was war der Plan zu der Zeit?

John Kern:

Ich denke, es war eine gängige Praxis. Wie ich schon sagte, es gab andere Gruppen, die sich oft trafen und kleine Konsortien oder kleine Zusammenkünfte veranstalteten und dann etwas veröffentlichten. Also ich denke, es war einfach, oh ja, das ist normal, dass man einige Zeit miteinander verbracht hat und Dinge aufgeschrieben hat, man könnte sie genauso gut veröffentlichen. Also ich denke, es war nicht tiefer als das, außer Bob, ich glaube, Bob könnte sagen, dass er eine Art Manifest oder irgendein Dokument herausbringen wollte, denn ich denke, das ist, was diese Art von... Ich war nie auf einer dieser Zusammenkünfte, aber weißt du, du konntest sehen, dass sie Dinge veröffentlicht haben. Ich habe das Gefühl, es war einfach etwas so Unschuldiges wie, nun, wir haben geredet, einige Dinge aufgeschrieben, könnten es genauso gut teilen.

Und dann die Prinzipien, es gab viele verschiedene Praktiken im Raum. Also, ich würde sagen, das Schöne an der Werte-Seite ist, dass Demut an oberster Stelle steht, dass sie immer noch aktiv ist. Wir decken nichts auf, ihr alle Bauern, wir haben alles herausgefunden. Nein, wir decken es immer noch auf. Und die andere Sache ist, indem ich es tue, weil ich immer noch ein aktiver Programmierer bin. Und außerdem schätzen wir das auf der linken Seite mehr als auf der rechten Seite. Manche Leute mögen sagen, es ist ein bisschen zweideutig oder etwas verschwommen, aber das ist auch ein Zeichen von Demut und dass es nicht A oder B ist. Und es ist wirklich verschwommen, und Sie müssen Ihren Kontext genug verstehen, um diese Dinge anwenden zu können. Aus der Sicht der Auftragsvergabe durch das Verteidigungsministerium waren mir sicherlich drei der vier Kugeln wirklich wichtig, weil ich gelernt habe... Klar, wir haben das Verteidigungsministerium beauftragt. Aber es ist viel wichtiger, eine Beziehung zum Kunden aufzubauen, als es ist... Denn wenn Sie den Vertrag abgeschlossen haben, haben Sie bereits verloren, was mit dem Aufbau einer Beziehung zum Kunden, dem Einzelnen einhergeht.

Und einer von Peter Codes, als wir mit Kunden und so weiter gearbeitet haben, war eines unserer Mantras, häufig greifbare Arbeitsergebnisse, auch bekannt als funktionierende Software. Man kann viel zeichnen und neun Monate lang Anwendungsfälle durchführen, aber wenn nichts läuft, ist das hübsch. Ich schätze, es ist riskant, dass man nichts, noch keine funktionierende Software hat. Es war also wirklich, glaube ich, eine Gelegenheit, die Tatsache mit anderen zu teilen, dass einige Leute zwei Wochen und andere einen Monat lang nachgedacht haben. Sogar einige der Druckprinzipien wiesen sozusagen eine ziemlich große Flexibilität auf. Ich denke, es ist wirklich wichtig, das zu beachten.

Amaar Iftikhar:

Ja, nein, absolut. Und es macht Sinn. Haben Sie oder jemand anderes, der zu dieser Zeit im Raum war, sich jemals vorgestellt, welche Auswirkungen die dort geleistete Arbeit flussabwärts haben würde?

John Kern:

Nicht dass ich wüsste. Das wusste ich bestimmt nicht. Ich erinnere mich, dass ich in meiner Karriere ein paar Mal reingekommen bin und ein paar Diagramme gesehen habe, als ich für die Firma Together Soft gearbeitet habe, und wir haben coole Sachen gebaut und ich habe gesehen, dass die Leute einige der... Oh ja, ich erinnere mich, dass ich ein Diagramm an ihrer Wand gemacht habe. Das ist irgendwie cool. Aber bei weitem nicht, wie demütigend und irgendwie befriedigend es ist. Vor allem würde ich sagen, wenn ich in Indien, Kolumbien oder Griechenland bin, scheint es fast so, als ob sie eher bereit sind, emotional damit umzugehen. Aber die Menschen sind es, es ist fast so, als wären sie durch dieses Dokument befreit worden. Und in gewissem Sinne ist das wirklich, wirklich winzig, wenn man es mit der größtmöglichen Demut sagt. Ein bisschen wie die Unabhängigkeitserklärung und die Tatsache, dass eine Handvoll Menschen... Und die Verfassung der Vereinigten Staaten. Eine Handvoll Menschen trafen sich in einem Moment, was sich nie wieder wiederholen sollte, und schufen etwas, das sozusagen auf die Welt geworfen wurde, das ein enormes Maß an individueller Freiheit und Zuversicht entfesselte, entfesselte, entfesselte, entfesselte, entfesselte, entfesselte, entfesselte, entfesselte, entfesselte, Dinge zu tun. Und ich glaube, auf sehr kleine, ähnliche Weise hat das Manifest genau das bewirkt.

Amaar Iftikhar:

Wie Sie bereits erwähnt haben, gab es einen Zeitpunkt, an dem das Manifest entwickelt wurde, und das ist fast 20 Jahre her. Jetzt haben sich die Arbeitsweise und die Arbeitswelt drastisch verändert. Also, was sind deine Gedanken dazu? Siehst du eine weitere Version kommen? Denken Sie, dass bestimmte Aktualisierungen vorgenommen werden müssen? Denken Sie, es ist ein zeitloses Dokument? Ich würde gerne deine Gedanken dazu hören.

John Kern:

Ja, das ist eine gute Frage. Ich persönlich finde es zeitlos und ich freue mich über andere Leute, die andere Dokumente erstellen. Und das haben sie. Alistair hat The Heart of Agile, Josh Kerievsky hat Modern Agile.

Es gibt ein paar Variationen eines Themas und verschiedene Dinge, über die man nachdenken kann, was ich großartig finde. Denn ich glaube, im Gegensatz zur US-Verfassung, die einen Mechanismus zur Selbständerung vorsah, brauchten wir das nicht. Und ich glaube, es hat die Essenz dessen erfasst, wie Menschen zusammenarbeiten, um etwas Wertvolles zu produzieren. Hauptsächlich Software, denn das ist es, woraus wir zum Üben gekommen sind, ist die Softwareerfahrung. Aber es braucht nicht viel Fantasie, um das Wort Software durch Produkt oder so zu ersetzen und trotzdem viele der vorhandenen Werte anzuwenden, mit sehr, sehr geringfügigen Anpassungen vielleicht, weil sich häufig greifbare Arbeitsergebnisse ergeben.

Es muss vielleicht Modelle geben, denn du wirst keinen Wolkenkratzer bauen und ihn abreißen und sagen: „Oh, das war nicht ganz richtig“ und ihn dann wieder bauen. Nichtsdestotrotz gibt es Variationen, wie Sie häufig Ergebnisse anzeigen können. Ich denke also, dass es im Großen und Ganzen zeitlos ist. Und ich würde jeden herausfordern. Was stimmt nicht damit? Weisen Sie 20 Jahre später auf etwas hin, das irgendwie nicht stimmt. Und ich glaube, das ist das Genie dahinter, über das wir gestolpert sind... Und wahrscheinlich, weil die meisten von uns Objektmodellierer waren, ist das eines der Dinge, in denen wir wirklich gut sind, nämlich die Essenz eines Systems in die kritischsten Teile zu zerlegen. Genau darum geht es beim Modellieren. Ich denke also, wir sind irgendwie von Natur aus zu den Kernbereichen vorgedrungen, die das ausmachen, was es heißt, Software mit Menschen, Prozessen und Werkzeugen zu produzieren. Und wir haben es aufgeschrieben. Deshalb finde ich es zeitlos.

Amaar Iftikhar:

Ja, absolut nicht. Ich denke, das war eine wirklich gute Erklärung dafür, warum es zeitlos ist. Ich denke, eines der Prinzipien, die mir bei einer Art moderner hybrider oder flexibler Arbeitsgestaltung in den Sinn kommen, ist eines der Prinzipien, in denen über die Bedeutung von persönlichen Gesprächen gesprochen wird. Und in einer heutigen Welt, in der viele Gespräche nicht physisch von Angesicht zu Angesicht stattfinden, finden sie möglicherweise auf Zoom statt. Denken Sie, dass das immer noch gilt?

John Kern:

Ja, ich denke, was wir herausfinden werden mit... Remote war sozusagen ferngesteuert, vor 20 Jahren. Ich habe mit einem Team von Entwicklern in Russland zusammengearbeitet und wir hatten genug Vertrauen und physische... Ich würde jeden Monat dorthin reisen. Das Team war so aufgebaut, dass wir genug Vertrauen in die Kommunikation hatten, sodass wir aufgrund der unterschiedlichen Zeitzonen letztendlich asynchron arbeiten konnten. Und ich war an der Ostküste. 7:00 Uhr in den USA war vielleicht 15:00 Uhr in Russland, wenn ich mich erinnere. St. Petersburg. Wir konnten die Distanz also überwinden, aber das echte Leben ist kaum zu übertreffen. Und oft habe ich manchmal sogar ein bisschen mit Ron Jeffries gestritten, sodass man auf der einen Seite sagen könnte, dass das Beste, was man tun kann, persönlich ist. Aber auf der anderen Seite könnte ich argumentieren, dass ein bisschen Abgeschiedenheit die Dinge ausmacht... Du musst etwas ausführlicher sein, möglicherweise etwas präziser, aber auch ein bisschen ausführlicher. Etwas entspannter mit... Du könntest ein paar Pässe nehmen, um etwas zu bekommen, nur weil, ich meine, in der Nacht vergehen zwei Zeitzonen. Aber das beruhte auf einigen oft ersten persönlichen Treffen, und dann konnte man aus der Ferne gehen und trotzdem erfolgreich und hocheffektiv sein.

Deshalb finde ich es wichtig, dass Teams nicht einfach sagen, dass sie immer noch alles können. Und Zoom ist zugegebenermaßen viel besser als vor 20 Jahren. Zoom bekommt, zumindest kann man ein Gesicht sehen. Aber nichts ersetzt den menschlichen Kontakt. Und ich denke, auch für das Wohlbefinden ist menschlicher Kontakt wichtig. Deshalb würde ich immer noch sagen, dass der Aspekt der Interaktion im Manifest immer noch am besten mit einer gesunden Dosis persönlicher Präsenz erfüllt wird. Und das ist quasi der Schlüssel zu den meisten Dingen in Agile. Für mich geht es um Pragmatismus und nicht nur darum, dogmatisch zu sein, sondern eher darum, was für uns besser funktionieren könnte? Und sogar damit zu experimentieren, etwas ein bisschen auszuprobieren und zu sehen, wie das funktioniert. Also, auch wenn Sie das Manifest behandeln, sollten Sie es sozusagen agil behandeln.

Amaar Iftikhar:

Ja, absolut nicht. Das ist ein gutes Argument. In diesem Sinne: Was sind für Sie als Agile-Berater oder Agile-Experte die besten Praktiken oder was funktioniert, was funktioniert nicht für verteilte Teams?

John Kern:

Nun, ich denke, die Dinge, die mir in großen und noch kleineren Unternehmen begegnet sind, sind die, dass... Ich weiß nicht, ob das natürlich ist, Gott bewahre, wenn es natürlich ist, aber Tendenzen, die ich in einigen Unternehmen gesehen habe, Silos einzurichten, in denen Sie die Qualitätskontrolle, das UX, das Frontend, Sie das Backend sind, lassen meinen Kopf explodieren. Denn das bedeutet, Verzögerungen einzubauen und Kommunikationshindernisse einzubauen und eine Zusammenarbeit aufzubauen, die von Silo zu Silo weitergegeben wird, und nicht Zusammenarbeit. Davon habe ich also mehr gesehen. Und ich verstehe es, Sie möchten vielleicht eine Spezialität haben, aber dem Kunden ist das egal. Der Kunde will etwas vor der Tür haben. Wenn ich auftauche und ein Feature vom Stapel nehme, was meinst du damit, dass ich nur einen Teil davon machen kann? Das verstehe ich nicht. Und ja, ich weiß, ich bin kein Experte für alles, aber wir haben wahrscheinlich einen Experten, der herausfinden kann, was das Muster ist. Also ich finde diese Art von Trend, ich weiß nicht, ob es ein Trend ist, aber ich finde, das ist meiner Meinung nach ein Rückschritt. Und es ist besser zu versuchen, funktionsübergreifender und kollaborativer zu sein. Jeder versucht, daran zu arbeiten, das Feature auf den Markt zu bringen, und nicht nur zu versuchen, seinen kleinen Teil dazu beizutragen.

Amaar Iftikhar:

Ja, hundertprozentig. Ich denke, an Silos zu stoßen, ist ein großer Teil davon, agil zu sein, oder sogar digital zu sein. Und oft gibt es auch Abhilfemaßnahmen dafür, aber es ist viel schwieriger, praktisch damit umzugehen, es tatsächlich in einer Organisation umzusetzen, einem lebendigen Unternehmen, in dem es echte Menschen und Dynamiken gibt, mit denen man umgehen muss, und es gibt Richtlinien und Prozesse, die befolgt werden müssen. Ich denke, so allgemein Sie auch sein können, was ist Ihre Meinung als Agile-Berater für ein Unternehmen, das mit diesem Problem konfrontiert ist?

John Kern:

Eines der Dinge, die... Adaptiv ist das, wofür mein Kollege John Turley mir wirklich die Augen geöffnet hat. Ich nenne es eher die geheime Sauce oder das fehlende Stück in meiner Praxis. Und es hat mit der Denkweise des Einzelnen zu tun und mit dem, was wir vertikale Entwicklung nennen. Es klingt vielleicht wie komisches, flauschiges Zeug, aber es ist wirklich extrem wichtig. Und ich habe immer gesagt, Leute, Prozesse und Tools für, ich möchte sagen, seit Ende der Neunziger, wahrscheinlich für eine lange Zeit. Und in der ersten Phase konnte ich verstehen, warum ich manchmal einfach spektakuläre, extrem leistungsstarke Teams hatte und manchmal waren es einfach wirklich, wirklich gut, aber nicht immer der Funke und manchmal war es irgendwie, eh, das war ein bisschen meh. Und vieles davon hängt davon ab, worauf die Menschen in Bezug darauf liegen, wie sie ihre Bedeutung ausdrücken und welche Motivationsorientierung sie haben, Kommando und Kontrolle versus Autonomie.

Was wir also tun, ist, dass wir gelernt haben, dass wir Menschen zunächst helfen können, zu erkennen, dass dies existiert, und Menschen mit so genannten Entwicklungspraktiken helfen können. Etwas, das, selbst der Satz, Sie haben ihn wahrscheinlich gehört, wie sichere Experimente. Scheitern oder etwas versuchen und scheitern. Nun, wenn du jemandem dafür den Kopf abhackst, weißt du was? Sie werden wahrscheinlich einfach ziemlich still bleiben und nur tun, was ihnen gesagt wird, nicht versuchen... Ich habe ein extrem hohes Maß an Autonomie in mir, also habe ich lange daran gelebt, besser um Vergebung zu bitten als um Erlaubnis zu bitten, und ich hatte immer das Gefühl, solange ich versuche, das Richtige zu tun, um erfolgreich zu sein und das Beste für das Unternehmen zu tun, werden sie mich wahrscheinlich nicht entlassen, wenn ich einen Fehler mache. Aber nicht jeder hat so viel Freiheit in der Art und Weise, wie er arbeitet. Sie müssen also als Management helfen, das zu etablieren, und das ist eine große Sache, mit der wir zusammenarbeiten, mit Teams.

Und dann fangen wir auch mit dem Unterricht an. Falls Sie schon einmal Büroräume gesehen haben und wenn nicht, sollten Sie das tun, aber was machen Sie hier? Also, die Berater Bob und Bob kommen rein, die Effizienzberater, „Also Amaar, was machst du hier?“ Aber das ist wortwörtlich etwas, ob wir Teams dabei helfen, ein neues Produkt zu entwickeln, ist okay, was ist der Zweck? Was ist der Geschäftszweck dieses Produkts? Was machst du hier? Was willst du mit diesem Produkt machen? Welchen Wert bietet es? Das Gleiche gilt für alles, mit dem Sie als Team arbeiten. Und das ist der Grund, egal ob es sich um Software handelt, die eine Funktion hervorbringt, deren Ergebnis dem Kunden einen Mehrwert bietet, oder um ein Produkt. Aber der Punkt ist, wenn Sie das nicht verstehen, wird es dem Team jetzt wirklich schwer fallen, Entscheidungen zu treffen, die uns weiterbringen.

Wenn du also allen hilfst zu verstehen, wofür wir hier sind, und dann versuchst, die Leute zu finden, die vielleicht all die verschiedenen Silos widerspiegeln, wenn du isoliert bist, aber all die verschiedenen Elemente. Wie kommen wir sozusagen von einer Idee zum Geld oder von der Idee zum Wert in der Hand des Kunden? Und schauen Sie sich das genau an. Weil es so viele Dinge gibt, die einfach irgendwie... Technische Daten schleichen sich oft in Softwarecodebasen ein. Und das Gleiche, wir sagen sozusagen die organisatorischen Schulden, das Gleiche kann passieren. Ihre Prozessverschuldung. Am Ende kannst du einfach sagen, alles klar, wir wollen, dass das Entwicklungsteam schneller wird, John und Co., kannst du reinkommen und uns helfen, uns zu coachen? Wir wollen agil werden. Sicher, okay, ja. In Ordnung. Wir krempeln die Ärmel hoch, schauen uns um und nach einer ersten Art von Wertstromansicht sagen wir, warte, es tut mir leid, aber da ist ein kleiner Keil, es sind ungefähr 15%, das ist die Entwicklung. Und dann haben Sie die 85% damit verbracht, darüber nachzudenken.

Tun wir so, als könnten wir die Geschwindigkeit der Entwicklung verdoppeln. Welches war ursprünglich der... Ja, wir brauchen die Entwickler, um schneller zu programmieren oder so. Das ist ein Klassiker. Und nein, tust du nicht, du musst aufhören, diesen ganzen Blödsinn von vorne zu machen, der einfach verrückte, arschgroße Wasserfallprojekte mit mehreren Absprachen ist. Und tatsächlich, eine der Abmeldungen, oh mein Gott, sie findet nur einmal pro Woche statt, und wenn Sie dann einen Tippfehler haben, werden Sie abgelehnt. Du kommst nicht für einen anderen zurück... Bist du verrückt? Du hast acht Monate damit verbracht, dich für acht Wochen zu entscheiden. Entschuldigung, es sind nicht die acht Wochen. Also Dinge wie diese, was ich jedem empfehle, sich selbst zu überprüfen, ist zu versuchen... Wenn Sie sich Sorgen um Ihr Team machen, können Sie es besser machen, indem Sie einfach versuchen, aufzuschreiben, wie Ihr Prozessschritt aussieht und was ein typischer Zeitrahmen ist?

Wie viel Zeit investieren Sie in die... Weil Leute oft Dinge in Sprints zusammenfassen. Das ist ein Stapel, warum legst du Dinge in einen Stapel? Oder sie haben riesige Probleme. Nun, das ist die große Menge. Es gibt also viele, oft tief hängende Früchte. Aber was Sie sagen, es ist oft eingedrungen, so arbeiten wir und niemand fühlt sich in der Lage, uns zu ändern oder sogar innezuhalten und zu schauen, wie wir arbeiten. Also ich denke, das ist der Punkt, an dem wir normalerweise beginnen. Schauen wir uns an, wie Sie heute tatsächlich arbeiten. Und während wir das machen, kannst du dein Bauchgefühl ausplaudern, du kannst uns all die Dinge sagen, die weh tun und die schmerzhaft sind, und dann werden wir versuchen, einen besseren Weg zu finden, auf den wir hinarbeiten können, im Sinne einer effektiveren Arbeit. Denn unser Ziel ist es, Teams dabei zu helfen, Wege zu finden, um sinnvollere und unterhaltsamere Arbeit zu leisten. Weil es viel Spaß macht, wenn es klickt und wenn Sie in einem guten Team sind und den Kunden ein Lächeln ins Gesicht zaubern, ist es schwer, sich fast von der Arbeit fernzuhalten, weil sie so viel Spaß macht. Aber wenn es das nicht ist, wenn es Plackerei ist und Sie nur ein Rädchen im Getriebe sind und Dinge Monate brauchen, um aus der Tür zu kommen, ist es ein Job. Es macht nicht so viel Spaß.

Amaar Iftikhar:

Ja. Viele der Punkte, die Sie dort erwähnt haben, haben bei mir großen Anklang gefunden, und die häufigsten Schmerzpunkte. Es klingt, als hättest du irgendwie alles gesehen. Übrigens, wenn Sie noch keine Büroräume gesehen haben, müssen Sie sie sich unbedingt ansehen. Es ist ein wirklich guter. Sie haben jetzt viel über die Herausforderungen gesprochen, mit denen ein verteiltes Team konfrontiert ist. Jetzt möchte ich es umdrehen und Sie fragen, wie das perfekte verteilte Team heute aussieht, das agile Werte lebt und atmet?

John Kern:

Ja. Ich weiß nicht, ob du jemals so etwas haben kannst, ein perfektes Team. Ich würde sagen, ich greife auf die Typen von verteilten Teams zurück, mit denen ich gearbeitet habe, und das geht auf die späten Neunziger zurück. Also ich mache das schon sehr, sehr lange. Ich habe es wirklich nur remote gemacht, egal ob mit Entwicklern in Russland oder unten in North Carolina oder an ähnlichen Orten. Und ich glaube, das Geheimnis war eine Kombination aus persönlichen... Wenn Sie als Gruppe irgendwohin gehen möchten, gibt es Dinge, die Sie tun können, um das Eis zu brechen, um einige, was Sie als Teambuilding-Aktivitäten bezeichnen könnten, zu organisieren.

Und nicht nur, hey, lass uns einen Hochseilgarten machen und uns gemeinsam zu Tode erschrecken lassen. Sondern auch Dinge, die sich darauf beziehen, warum wir hier sind, was versuchen wir zu erreichen? Und lassen Sie uns darüber sprechen, ob es das Produkt ist, das wir herstellen wollen, und das als Gelegenheit nutzen, uns um etwas zu verbinden und genug Fleisch an den Knochen zu bekommen, genug Skelette davon, wie es aussehen könnte. Weil es gute Möglichkeiten gibt, anzufangen und eine gute Grundlage zu haben. Und das ist Teil dessen, was ich seit Jahrzehnten praktiziere. Wenn Sie die Dinge richtig einrichten und verstehen, dass gerade genug Anforderungen vorliegen, verstehen Sie... Und ich mache viel Domänenmodellierung mit UML und solche Dinge. Ich verstehe einfach, was der Problembereich ist, den wir zu lösen versuchen, um die angestrebten Ziele zu erreichen, und ein Gefühl für die Architektur zu bekommen, die wir wollen. All diese Dinge sind also gemeinsame Anstrengungen.

Wenn Sie also genug von einem Ausgangspunkt haben, an dem Sie zusammengearbeitet haben, kommen Sie rein und, sagen wir, Sie mussten sogar irgendwo eine Wohnung mieten, weil niemand in der Nähe des Büros wohnte, also sind Sie alle irgendwohin geflogen. Ich meine, das ist meiner Meinung nach gut angelegtes Geld. Weil damit das Fundament beginnt. Wenn Sie sozusagen Brot gebrochen oder ein paar Bier getrunken haben oder zusammen programmiert und Dinge gemacht haben und dann zu Ihren entfernten Büros zurückkehren, um die nächsten Schritte zu unternehmen und dann zu erkennen, wann Sie sich vielleicht wiedersehen müssen. Es ist also wirklich wichtig, zu verstehen, wie wichtig es ist, diese Beziehungen frühzeitig aufzubauen, damit Sie unverblümt sprechen können. Und ich habe ein paar gute Leute, die seit etwa 2006 eine Produktions-App für Feuerwehrleute betreiben.

Amaar Iftikhar:

Ja, sehr cool.

John Kern:

Und dieser Freund, mit dem ich gearbeitet habe, wir stehen uns so nahe, dass wir... Das macht unsere Gespräche aus, wir müssen nicht um den heißen Brei herumreden, wir müssen uns keine Sorgen machen, jemanden zu beleidigen, wir kommen einfach, bumm, auf den Punkt. Weil wir wissen, dass wir die Kinder des anderen nicht als hässlich bezeichnen. Wir versuchen nur, schnell etwas zu erledigen.

Und der Aufbau einer solchen Beziehung erfordert Zeit und Mühe und Zusammenarbeit. Und das ist meiner Meinung nach ein gutes, erfolgreiches, verteiltes Team. Man muss von Zeit zu Zeit zusammenkommen und diese Beziehungen aufbauen und wissen, wann man vielleicht wieder zusammenkommen muss, wenn etwas ein Problem ist. Aber ich denke, der Schlüssel zum Erfolg ist, dass es die Zeit verkürzt. Weil Sie vielleicht von Dingen wie den Gruppenformen gehört haben, wenn das die Leistung auf der Y-Achse ist, die sie bilden und sie sich auf einem bestimmten Leistungsniveau befinden, dann müssen sie stürmen, bevor sie wieder normal werden und bevor sie anfangen, Höchstleistungen zu erbringen. Es ist also diese Form, Storm. Du wirst schlimmer, wenn du stürmst. Und stürmen bedeutet, wirklich zu verstehen, wo wir stehen. Und wenn wir darüber streiten, sollte das meiner Meinung nach nicht Erbschaft sein, Amaar. Und dann sagst du: „Oh Bullshit, es ist wirklich...“

Und noch einmal, wir sind nicht persönlich, aber wir lernen die Sichtweisen des anderen kennen und wir lernen, respektvolle Debatten zu führen und sozusagen einige Argumente vorzubringen, um an den besseren Ort zu kommen. Und ich habe in einigen Unternehmen gearbeitet, die Angst vor Stürmen haben, und es fühlt sich an, als ob man nie leistungsstark ist.

Jeder ist zu höflich. Es ist wie, komm schon. Und ich liebe es, mit meinen russischen Kollegen zusammenzuarbeiten. Es war ihnen scheißegal, ob ich einer der Gründer war. Und ich bin froh, denn ich will kein Privileg, ich will so etwas nicht. Nein, lass uns das ausfechten. Mögen die besten Ideen gewinnen. Dorthin willst du kommen. Und wenn du nicht dorthin kommst, weil du nicht genug von einer Beziehung hast und du dazu neigst, die Dinge, die gesagt werden mussten, nicht zu sagen, weil du höflich bist, dann wird es wirklich lange dauern, bis du erfolgreich bist. Und das ist eine Menge Geld und das ist eine Menge Erfolg, und die Leute könnten gehen.

Ich denke, das Wichtigste ist, wenn man remote ist, ist das okay, aber die schiere Abgeschiedenheit ist eine echte Herausforderung. Und du musst irgendwie herausfinden, wenn du nicht zusammenkommen kannst, um zu lernen, wie man sich formt und stürmt und diese Bindungen von Angesicht zu Angesicht aufbaut, dann musst du über Zoom herausfinden, wie das geht. Weil du es tun musst, denn wenn du es nicht tust, wenn du nie Worte hast, dann glaub mir, du bist immer noch nicht leistungsstark.

Amaar Iftikhar:

Ja, ich habe irgendwie das Gefühl, dass es den Kandidaten auf dem Markt jetzt fast ein Wettbewerbsvorteil ist, völlig remote zu sein, weil es ein Kampf um Talente ist. Aber wenn ich das richtig verstehe, sagen Sie, dass das persönliche Element so wichtig ist, um wirklich gute Leistungen zu erbringen, und diese Ideen widersprechen sich meiner Meinung nach irgendwie.

John Kern:

Ja. Und nochmal, da ich seit Ende der Neunziger abgelegen war, mache ich das schon lange. Und nach Russland zu pendeln ist der längste Weg, den ich je gemacht habe, seit drei Jahren. Ich meine, das ist ein verdammt langer Flug, um mehr als sieben Mal dorthin zu pendeln, oder was auch immer zur Hölle es war. Wie dem auch sei, ich habe immer gesagt, dass Fernsein nicht jedermanns Sache ist, denn das ist es wirklich nicht. Ich meine, du musst wissen, wie man arbeitet, ohne dass jemand in der Nähe ist, und arbeiten kann. Ich meine, es hat seine eigenen Herausforderungen. Und ja, es mag ein Vorteil sein, aber ich denke, Sie müssen sich die möglichen Vorteile ansehen und auch herausfinden, kann ich sie zusammenfassen in... Es muss nicht alles oder nichts sein. Und ich denke, das kann ein leichter Fehler sein, vielleicht ist es, alles klar, cool, wir müssen keine Büroräume haben. Das sind eine Menge Einsparungen für das Unternehmen. Ja, aber vielleicht bedeutet das, dass Sie einige Remote-Arbeitsplätze für gelegentliche Zusammenkünfte benötigen, oder finden Sie es heraus.

Aber ja, ich denke sogar... Und bestimmte Unternehmen könnten anders funktionieren. Zu Beginn der Entwicklung eines Produkts wünsche ich mir eine intensive Zusammenarbeit und ich möchte an einen Punkt kommen, an dem es fast so weit ist, ich habe das Gefühl, dass das Produkt so läuft, dass, wenn man die Dinge erst einmal ins Rollen gebracht hat und irgendwie aufgestanden ist, etwas Schwung bekommt, es jetzt am schwierigsten ist, vor einem agilen Team zu stehen, egal ob persönlich oder remote. Sobald die Dinge rollen und schaukeln und es so ist, als würde alles klicken, kannst du einfach die verbleibenden Funktionen wie Bum, Bum, Bum, Bum herausschlagen. Ja, okay, dann müssen wir wahrscheinlich...

Es sei denn, wir haben Möglichkeiten, uns zu paaren oder solche Dinge. Ich sage, wenn wir zusammen sind, ist Mobbing einfacher. Ich bin sicher, es gibt Möglichkeiten, das aus der Ferne zu machen, aber in einem Raum zu sein, ich weiß nicht, es ist viel einfacher, als sich über Zoom zu koordinieren. Du, hey, da ist dieses Problem, lass uns nach dem Standup alle hier rumhängen, weil wir einfach darüber moben werden. Es braucht also nicht viel gegen alles, was weit entfernt ist, es gibt ein bisschen mehr, okay, wir müssen uns abstimmen, und sogar verschiedene Zeitzonen werden noch schlimmer. Also ja, lassen Sie sich nicht davon mitreißen, dass Fernzugriff das Ende aller Dinge ist. Weil ich das Gefühl habe, dass es einen geben wird... Ich wette, es wird eine Gegenreaktion geben.

Amaar Iftikhar:

Und ich nehme das zurück, weil ich von Agile komme, der Person, die das täglich tut und Teams hilft, agil zu werden. Ich glaube Ihnen auf jeden Fall beim Wort. Und aufgrund meiner Erfahrung habe ich auch gesehen, dass nichts wirklich besser ist als eine gute Whiteboarding-Sitzung. Das ist wirklich schwer online zu replizieren. Ich meine, wir haben diese tollen Tools, aber nichts ahmt die reale Erfahrung nach, nur ein einfaches Whiteboard und einen Marker in der Hand zu haben. Diese Kommunikation ist so mächtig.

John Kern:

Toller Punkt. Stimmt, denn ich hatte gerade bei der einen Firma, bei der ich fünf Jahre lang gearbeitet habe, wir haben ein hochentwickeltes, auf Bestellung entwickeltes Verkaufswerkzeug für die Pumpenherstellung gemacht für... Es war also meine Lieblingswelt, weil sie meine Strömungsdynamik als Luft- und Raumfahrtingenieur mit meiner Liebe zur Entwicklung von SaaS-Produkten und der Entwicklung neuer Software und ähnlichem verband. Und selbst wenn wir noch ein Kind hatten, interviewten wir an der Lehigh University und wir hatten einige junge Absolventen, die mit uns arbeiteten und sie mit einbeziehen konnten, und da war ein Raum hinter meinem Laufband, und wir gingen hinein, wir veranstalteten Jam-Sessions zum Modeln und Entwickeln neuer Features. Und Mann, du hast recht. Nur diese viszerale dreidimensionale Erfahrung. Ja, Miro geht es großartig. Oder irgendein anderes Werkzeug, aber ja, es ist nicht dasselbe. Du hast absolut recht. Das ist ein gutes Argument. Das bringt mich fast dazu, mich nach den guten alten Zeiten zu sehnen. [unhörbar 00:42:04]

Amaar Iftikhar:

Ich denke, die guten alten Zeiten gibt es immer noch. Ich denke, selbst jetzt war es eine erfrischende Zeit für mich, bei Easy Agile zu sein. Ich bin jetzt erst seit knapp zwei Monaten hier. Und es gibt eine starke persönliche Dynamik. Und auch hier ist es optional. Wenn die Leute aus der Ferne oder hybride Menschen sind oder ab und zu pendeln müssen, ist das eine sehr verständnisvolle Umgebung. Aber wenn Sie einmal im Büro oder persönlich sind, spüren Sie gewissermaßen den Effekt, den Sie beschrieben haben, und Sie sind motiviert, für den Endkunden etwas zu liefern. Du willst einfach nur zurückkommen. Es ist ein süchtig machendes Gefühl, ich möchte wieder persönlich sein und in Echtzeit persönlich zusammenarbeiten.

John Kern:

Das ist wunderbar gesagt, denn das ist... Eines der Unternehmen, mit dem wir in Südafrika zu kooperieren beginnen, sie stehen an einem Scheideweg, mit dem wir zu kämpfen haben, alle waren abgelegen, aber Mann, die paar Male, als wir zusammen waren, haben wir so viel erreicht. Und du beschreibst die Flamme, die Wärme, die entsteht, wenn man die Motten zur Flamme kommen lässt. Ich meine, es zu pflegen und dann die Flammen des Guten zu entfachen und die Leute dazu zu bringen, sich daran zu beteiligen und es zu genießen. Und manchmal, ja, ich muss zu Hause sagen, ich habe die Kinder oder den Hund, das ist auch okay. Aber die Option zu geben, glaube ich, ist unser Ziel. Und ich glaube den Unternehmen, die in der Lage sind, diese hybride Kultur aufzubauen, in der beide akzeptiert werden und weder das eine noch das andere vorgeschrieben wird, sondern ein so leistungsstarkes Team aufgebaut wird, das die Leute im Grunde dazu ermutigt, sich für die Dinge zu entscheiden, die zu diesem Zeitpunkt am sinnvollsten sind. Und ich denke, dass diese Unternehmen sozusagen das Sagen haben werden.

Amaar Iftikhar:

Ja, absolut. Es war so nett, mit dir zu chatten, John, und das hat mir wirklich Spaß gemacht. Ich möchte das Publikum mit einem Ratschlag für verteilte agile Teams von Ihnen abschalten. Wir haben viel über die Bedeutung der persönlichen Zusammenarbeit gesprochen. Wir haben über die Prinzipien des agilen Manifests gesprochen. Nun, was wäre der eine Ratschlag, wenn Sie an beide denken? Wenn Sie möchten, dass die Agile-Manifeste in verteilten agilen Teams lebendig und lebendig sind, welchen Ratschlag können Sie Unternehmen geben, die gerade die gleichen Probleme durchmachen? Was kannst du ihnen als letzten Ratschlag geben?

John Kern:

Nun, ich denke, ein Satz, den ich gerne verwende, um das Manifest festzuhalten, ist: „Kümmere dich um die Lücke“. In meiner Art von Wortspiel meine ich die Zeitlücke zwischen dem Ergreifen einer Handlung und dem Erhalt einer Antwort. Ob es darum geht, was machen wir mit dem Büro, was machen wir mit der Fernbedienung, was machen wir mit dieser Funktion, was machen wir mit dieser Codezeile? Der Zeitunterschied ist, es ist eine Art Metapher dafür, bescheiden genug zu sein, Dinge als Hypothese zu behandeln. Seien Sie sich Ihrer selbst also nicht so verdammt sicher, was das Büro angeht, ob es um das Büro geht, ob es um ein entferntes oder verteiltes Büro geht. Behandeln Sie die Dinge stattdessen als Hypothese. Seien Sie neugierig und experimentieren Sie sicher mit verschiedenen Methoden und sehen Sie, was funktioniert. Und hab keine Angst vor Veränderungen. Es ist auch keine lebenslange Haftstrafe, Sie müssen Ihr Unternehmen, Ihr Projekt oder Ihr Team für den Rest Ihres Lebens in eine Richtung führen. Nein. Sag es nicht dem Chef, aber Arbeit ist subventioniertes Lernen. Ich habe nie Leute verstanden, die immer wieder das Gleiche tun, weil sie keine Erlaubnis bekommen haben. Versuch es einfach. Das wäre also mein Abschiedssatz, wenn es darum geht, diese Entscheidungen zu treffen. Achten Sie auf die Lücke und seien Sie wirklich bescheiden, wenn es darum geht, Annahmen zu treffen, Ihre Hypothesen zu testen und die Zeitspanne zwischen dem Ergreifen von Maßnahmen und dem Erleben einer Reaktion zu verkürzen.

Amaar Iftikhar:

Oh, das ist großartig. Oh, danke. Ich wünschte wirklich, wir könnten das Band laufen lassen und einfach noch ein paar Stunden darüber reden, aber wir beenden es genau dort mit dem wirklich guten Ratschlag, mit dem du das Publikum verlassen hast. Jon, danke nochmal, dass du im Podcast warst. Und es hat uns wirklich sehr viel Spaß gemacht, Ihnen zuzuhören und aus Ihren Erfahrungen zu lernen.

John Kern:

Oh, es war mir ein Vergnügen. Jederzeit. Freue mich, noch ein paar Stunden zu reden, aber vielleicht nach ein paar Bieren.

Amaar Iftikhar:

Ja.

John Kern:

Außer dass es dein Morgen ist, mein Abend. Daran werde ich arbeiten müssen.

Amaar Iftikhar:

Ja.

John Kern:

Das freut mich, Amaar.