Easy Agile Podcast Ep.20 Die Bedeutung der Team-Retrospektive

„Nach einer Cloud-Migration bei Splunk hat Greg einige wichtige Erkenntnisse, Herausforderungen und Chancen mit uns geteilt“ — Chloe Hall

Greg Warner ist seit 2006 im Atlassian-Ökosystem tätig und hält regelmäßig Vorträge auf Atlassian-Veranstaltungen. Greg hat als Senior Consultant für einen Lösungspartner gearbeitet, Jira und Confluence bei Amazon unterstützt und in seiner aktuellen Rolle bei Splunk eine Cloud-Migration zu Atlassian Enterprise Cloud für über 10.000 seiner Kollegen durchgeführt.

In dieser Folge sprechen Greg und Chloe über die Reise zur Cloud-Migration:

📌 Der mentale Wandel zur Cloud-Migration und wie man über die technische Seite hinausdenkt

📌 So navigierst du durch die Reise, ohne dass du einer Roadmap folgst

📌 Die vier Säulen für den Erfolg Ihrer Cloud-Migration

📌 Den richtigen Zeitpunkt für die Migration finden und über zukünftige Möglichkeiten nachdenken, die über Ihre Migration hinausgehen

📌 Der unerwartete Wert, der sich aus einer Cloud-Migration ergeben kann

+ mehr!

📲 Abonnieren/Hören Sie Ihre Lieblings-Podcasting-App.

Danke, Greg und Chloe!

Transkript

Chloé Hall:

Hallo zusammen und willkommen zurück zum Easy Agile Podcast. Also, ich bin Chloe, Marketingkoordinatorin bei Easy Agile, und ich werde Ihre Moderatorin für die heutige Folge sein. Bevor wir beginnen, möchten wir uns bei den traditionellen Hütern des Landes, von dem aus ich heute aufnehme, bedanken, dem Volk der Wodiwodi aus dem Dharawal-sprachigen Land, und den Ältesten aus Vergangenheit, Gegenwart und Entwicklung unseren Respekt erweisen. Den gleichen Respekt zollen wir allen Aborigines und den australischen Inselbewohnern, die heute zuhören.

Chloé Hall:

Wir haben heute also einen sehr aufregenden Gast im Podcast. Dieser Gast befasst sich seit 2006 mit dem Atlassian-Ökosystem und spricht häufig auf Atlassian-Veranstaltungen. Er hat als Senior Consultant für einen Lösungspartner gearbeitet, Jira und Confluence bei Amazon unterstützt und in seiner aktuellen Rolle bei Splunk eine Cloud-Migration zur Atlassian Enterprise Cloud für über 10.000 Kollegen durchgeführt. Also willkommen zum Easy Agile Podcast, Greg Warner.

Chloé Hall:

Wie geht's dir?

Greg Warner:

Gut, und danke für die Einladung.

Chloé Hall:

Keine Sorge. Es ist toll, dass du heute hier bist.

Greg Warner:

Das ist eines meiner Lieblingsthemen. Wir sprechen über Cloud-Migration und ja, ich hoffe, ich kann erklären, warum.

Chloé Hall:

Ja, genau das wollen wir für Sie, denn ich erinnere mich, als wir uns bei Team 22 getroffen haben. Sie waren einfach so begeistert von der Cloud-Migration und hatten so viele Erkenntnisse zu teilen, und ich war auch sehr fasziniert.

Greg Warner:

Um ein bisschen Hintergrundinformationen über mich zu geben.

Chloé Hall:

Ja.

Greg Warner:

Ich war nicht immer ein Wolkenmensch. Sie haben also bereits erwähnt, dass Sie seit 2006 dabei sind. Ich war in den frühen Tagen dabei, als Jira die verschiedenen Varianten Standard und Professional hatte, als du eine Unternehmenslizenz für Atlassian bestellst und man dir ein Shirt geschickt hat. Das war einer der Unterschiede zwischen einer der Lizenzen. Es basiert also viel auf den Serverversionen, über viele Jahre hinweg. Ich betrachtete die Cloud als den ärmeren Cousin, wenn du so willst.

Greg Warner:

Ich war auf mehreren Atlassian-Gipfeln und späteren Teamevents gewesen, bei denen es immer Dinge gab, die in der Cloud passierten, aber nicht unbedingt auf dem Server. Ich habe an der Erstellung von Prüfungsfragen für das Atlassian-Zertifizierungsprogramm für Server und DC teilgenommen. In den letzten 18 Monaten, also seit zwei Jahren, habe ich diesen grundlegenden Wandel vollzogen — von einem Befürworter dessen, was wir auf Servern in DC tun, hin zu absolut Cloud-First. Das ist die definitive Richtung, die wir als Unternehmen gewählt haben, und es ist sicherlich auch der Grund, warum ich so leidenschaftlich daran interessiert bin, mit anderen Unternehmenskunden über ihre Cloud-Migration zu sprechen.

Chloé Hall:

Beeindruckend. Was glaubst du war es, dass du gesagt hast, okay, lass uns in die Cloud migrieren, da du so sehr in den Server-DC-Teil involviert warst? Was hat Ihre Aufmerksamkeit erregt?

Greg Warner:

Ich bin 2019 zu Splunk gekommen und es war nicht alles rosarot, was die Wartung von Jira und Confluence angeht. Es war nicht ungewöhnlich, dass es stundenlange Ausfälle gab. Dass zwei Systeme, die für unseren Geschäftsbetrieb einfach so wichtig waren, das hatten, war ich etwas verblüfft, aber ich dachte, hey, ich war schon einmal hier. Das habe ich gesehen. Also war es ein langsamer methodischer Ansatz, um unsere Probleme zu lösen, uns zu einer Version zu bringen, die langfristig unterstützt wurde, und dann eine Verschnaufpause einzulegen.

Greg Warner:

Sobald wir an dem Punkt angelangt sind, an dem wir keine Ausfälle mehr hatten, denken wir darüber nach, wie die Zukunft aussehen würde. Und für mich war diese Zukunft genau das, was ich zuvor gemacht hatte, das, was ich bei Amazon gemacht hatte, wo wir unsere gesamte lokale Infrastruktur, Jira, Confluence und Crowd, in die Public Cloud verlagern würden, egal ob es sich um eine AWS oder GCP handeln würde, so etwas in der Art. Das hatte ich schon einmal gemacht. Ich wusste, wie wir das machen würden, insofern, als ich in meinem Team sogar Besprechungen darüber abgehalten hatte, wie wir die Infrastruktur aufbauen und wie das Design aussehen sollte.

Greg Warner:

Aber es gab wahrscheinlich ein entscheidendes Gespräch mit unserem CIO, und es war in einem von denen, als ich gerade vorbeiging, und er sagte: „Greg, ich habe die Pläne und die Finanzierungsanfragen gesehen.“ Er sagt: „Aber haben Sie über Atlassian Cloud nachgedacht?“ Die unmittelbare persönliche Reaktion auf mich war, dass wir das nicht tun werden, weil ich die Iterationen gesehen hatte. Ich hatte es im Laufe der Zeit gesehen. Ich hatte für einen Lösungspartner gearbeitet. Ich hatte mit Kunden in der Cloud zusammengearbeitet und nie wirklich gedacht, dass wir für Unternehmen gerüstet sein könnten. Meine unmittelbare Reaktion würde das also nicht bewirken. Ich sagte: „Ich werde diese Frage jetzt nicht beantworten.“ Ich sagte: „Ich weiß nicht genug, um dir eine Antwort zu geben.“

Greg Warner:

Und ich bin absolut froh, dass ich das getan habe, denn ich wäre ins Fettnäpfchen getreten, wenn ich sofort geantwortet hätte, dass... Also ja, ich habe diese Frage beantwortet, einige Analysen durchgeführt, mit unserem damaligen technischen Kundenbetreuer gesprochen und mir wirklich angesehen, was vor sich ging und wo die Cloud heute ist? Wie weit war sie ausgereift? Und das wirklich Monumentale für mich war, dass ich glaube, dass es tatsächlich fertig ist. Die Leute entschuldigen sich dafür, warum sie es nicht können, aber es gibt eine Reihe von Gründen, warum Sie das tun sollten. Und wenn wir uns als Unternehmen mit unseren eigenen Produkten betrachten, bringen wir unsere eigenen Kunden in die Cloud, und wir nutzen Cloud-Dienste wie Google Workspace und Zoom sowie eine Vielzahl von SaaS-Anwendungen. Was war so anders an dem, was wir im Bereich Engineering gemacht haben und das nicht in die Cloud gehen konnte? Und das war wie, okay, ich glaube, der CIO hat mir hier tatsächlich eine viel größere Frage gestellt.

Greg Warner:

Das Ergebnis war also: Ja, wir haben entschieden, dass es der richtige Zeitpunkt für Splunk war, umzuziehen. Und das ist eine monumentale Veränderung. Und ich weiß, dass es da draußen eine Menge Jira-Admins gibt, die sagen, wenn du das tust, gefährdest du deine eigenen Jobs. Die Antwort lautet nein, das bist du nicht. Und selbst in meinem Team, als wir das besprochen hatten, gab es eine emotionale Verbindung zur Aufrechterhaltung der Infrastruktur vor Ort. Geben wir damit unsere eigenen Jobs weg? Da sind all diese... Nein.

Greg Warner:

Und es gab tatsächlich zwei Leute in meinem Team, die durch unsere Cloud-Migration tatsächlich befördert wurden und die es sonst nicht getan hätten, weil sie die Fähigkeiten unter Beweis stellen konnten. Aber das ist quasi die Hintergrundgeschichte darüber, wie wir uns für den Umstieg auf die Cloud entschieden haben. Und ich denke, während wir darüber nachdenken, gibt es zuerst eine mentale Veränderung. Bevor Sie überhaupt den technischen Weg beschreiten und sich überlegen, wie Sie das machen würden, sollten Sie Ihre eigene Meinung ändern, sodass Sie auch dafür bereit sind.

Chloé Hall:

Ja, ich liebe das. Ja, es ist so gut. Und ich denke, allein die Tatsache, dass Sie Ihrem CIO nicht geantwortet haben, haben Sie das gesagt?

Greg Warner:

Jep.

Chloé Hall:

Dass Sie Ihrem CIO nicht sofort geantwortet haben und nicht gesagt haben: „Nein, das möchte ich nicht tun.“ Sie sind tatsächlich zurückgetreten, haben sich die Zeit für Ihre Recherchen genommen und denken, dass die Cloud vielleicht die bessere Option für Splunk ist, was einfach großartig ist und wirklich zu dieser mentalen Veränderung in Ihnen selbst geführt hat. Wenn Sie also sagen, dass Ihre Mitarbeiter, wie jeder, irgendwie das Problem haben, oh, wir werden unseren Job verlieren, wenn wir von On-Premise zur Cloud wechseln und diese Mitarbeiter am Ende befördert werden. Wie haben sich ihre Rollen verändert?

Greg Warner:

Als wir von On-Premise auf Cloud umgestiegen sind, müssen Sie die Sanitäranlagen nicht mehr warten, oder?

Chloé Hall:

Ja.

Greg Warner:

Du musst dich nicht mehr um die gesamte Installation kümmern, die Jira, Confluence, BitBucket, was auch immer gerade bewegt wird, unterstützt. Jetzt dachten wir, das ist der Teil, der dem Unternehmen tatsächlich einen Mehrwert bietet. Und erst als wir zur Cloud übergingen, wurde uns klar, dass dem nicht so war. Als ob das, was wir jetzt tun können, anders ist. Und genau das hat mein Team getan. Sie haben ein höheres Level erreicht.

Greg Warner:

In den Zeiten, in denen wir von Jira, Confluence vor Ort, zur Cloud gewechselt sind, beschäftigen wir uns jetzt viel mehr mit der Geschäftsanalyse und dem Verständnis, was unsere Projektteams wollen. Wenn also jemand aus dem Bereich Engineering etwas anfordert, das eine Integration oder einen Workflow hat, haben wir mehr Zeit, die wir dafür aufwenden können, als dass wir ein Upgrade durchführen werden? Befinden wir uns in der aktuellen Feature-Version? Gibt es einen Bug, den wir schließen müssen? Log-for J ist ein Paradebeispiel, bei dem wir das Thema behandelt haben, darin bestand, einen Anruf mit dem Atlassian Enterprise Support zu protokollieren und uns dann zu sagen: „Ja, es ist erledigt.“

Greg Warner:

Während andere Kollegen innerhalb des Ökosystems, mit dem ich gesprochen habe, eine Woche damit verbracht haben, sich damit zu befassen, oder? Umgang mit Patches und Upgrades. Der Wert, den die Arbeit, die wir leisten, für unser Team hat sich also verändert. In dieser Zeit haben wir auch erweiterte Roadmaps für Jira erstellt. Wir waren also in der Lage, Dinge bereitzustellen, die wir nie hätten bereitstellen können, weil wir zu viel mit den Klempnern zu tun haben, und das ist jetzt so, dass wir nur noch einen sehr geringen Platzbedarf vor Ort haben, und das sind hauptsächlich FedRAMP und IO5. Es ist noch nicht ganz zertifiziert. Es wird dort ankommen. Wir haben also einen sehr kleinen Fußabdruck und ich bin derjenige, der die Upgrades durchführen muss, und jetzt schauen Sie sich das an, oh mein Gott, das werden diese paar wöchentlichen Aufgaben sein, die wir erledigen werden, bei denen ich all die andere bessere Arbeit erledigen könnte, die in der Cloud auf uns wartet. Sie merken es erst, wenn Sie es entfernt haben, wie viel Sie früher getan haben.

Greg Warner:

Deshalb haben wir früher zwei Upgrades von Jira pro Jahr und zwei Upgrades von Confluence pro Jahr durchgeführt. Wir haben das auf jeweils etwa einen Monat Arbeit zurückgeführt. Bis du all deine Tests durchführst und die Inszenierung durchführst und dann das machst. Sie rechnen also wirklich mit vier Monaten des Jahres, in dem Sie Upgrades durchgeführt haben. Das haben wir nicht mehr. Das ist komplett weg. Deshalb stellen wir jetzt sicher, dass wir die Dinge zuerst mit der Cloud erledigen. Wir übertragen Verhaltensweisen, die wir vor Ort angewendet haben, nicht in die Cloud. Das ist wahrscheinlich eine Sache, die wir gelernt haben, war, dass Server-DC nicht in der Cloud implementiert wird.

Chloé Hall:

Ja, das ist so toll. Es scheint, als hätte es dir auch viel mehr Möglichkeiten eröffnet. Ich denke, etwas, das ich etwas genauer untersuchen und verstehen möchte, ist, dass sich die Leute stark auf den technischen Aspekt der Cloud-Migration konzentrieren. Welche anderen Aspekte müssen Ihrer Meinung nach berücksichtigt werden?

Greg Warner:

Sicherlich Leute. Ich habe hier ganz vorne die mentale Denkweise erwähnt und das begann wirklich bei meinem Team, um sie dazu zu bringen, wie wir diese Cloud-Migration durchführen werden. Es gibt noch nicht unbedingt eine Roadmap, die besagt, dass dies alle Schritte sind, die Sie unternehmen müssen, um sich auf Ihre Cloud-Migration vorzubereiten. Also mussten wir einige davon erfinden und eine dieser beiden war, was wollten wir aus der Cloud-Migration herausholen?

Greg Warner:

Ich spreche mit anderen Atlassian-Kunden. Du sprichst davon, dass sie ein Projekt durchführen, das Projekt ist die Cloud-Migration, der Anfang und das Ende ist der Cloud-Migrationstag. Nein, völlig falsch. Die Cloud-Migration hat tatsächlich einen Anfang, eine Mitte und ein Ende. Worüber Sie hier sprechen, über diese ersten Änderungen, ist am Anfang, und das sollte sein, dass wir zur Cloud wechseln, weil sie grundlegend besser sein sollte als das, was wir heute haben.

Greg Warner:

Wenn es nicht besser ist, hat es keinen Sinn, die Aktivität durchzuführen. Also begannen wir mit einer Vision und diese Vision war, dass alle wichtigen Dinge vom ersten Tag an funktionieren mussten und dass sie besser funktionieren mussten. Also Ausgabe erstellen, Ausgabe bearbeiten, bis zur Ausgabe, das muss einfach funktionieren. Es sollte keinen Streit darüber geben, ob dies der Fall ist oder nicht. Das muss funktionieren und besser funktionieren. Erstelle eine Seite, bearbeite eine Seite, teile eine Seite. Das Zeug muss in Confluence problemlos funktionieren. Wir müssen auch sicherstellen, dass es Mitarbeiter in der Organisation gibt, für die dies eine grundlegende Änderung ihrer Arbeitsweise bedeuten könnte, je nachdem, wie viel sie mit Jira und Confluence arbeiten. Wir sind uns also bewusst, dass während der Cloud-Migration ein gewisses Maß an Change Management und Kommunikation erforderlich sind, um sicherzustellen, dass Ihre Vision funktioniert, aber wir müssen uns auch darüber im Klaren sein, dass Sie einige Dinge kaputt machen werden. Sie werden nicht in der Lage sein, eine Cloud-Migration durchzuführen und sich ohne irgendetwas von A nach B zu verlagern.

Greg Warner:

Es wird schief gehen. Das war uns bewusst, und deswegen habe ich den Leuten immer gesagt, dass wir fest auf die Vision fixiert sind, sicherzustellen, dass es besser ist als heute, aber flexibel, was die Details angeht, wie wir sie erreichen. Wir werden im Laufe der Zeit wahrscheinlich andere Wege finden, weil sich die Dinge ändern werden. Die Cloud verändert sich von selbst. Sie werden Dinge entdecken, die Sie vorher nicht wussten. Es gab einen Jira-Admin, der vor 10 Jahren eine Entscheidung getroffen hat, das hast du jetzt herausgefunden. Also ja, wir waren an dem ersten Tag sehr, sehr fest auf diese Vision fixiert, dass wir dieses Unboxing-Erlebnis haben mussten. Als die Leute Jira und Conference Cloud zum ersten Mal nutzten, konnten sie verstehen, warum wir so viel Mühe darauf verwendet hatten, sicherzustellen, dass alles auf den neuesten Stand gebracht wurde und die Dinge einfach funktionierten. Und wenn du ein bisschen weiter gegangen bist, gibt es vielleicht Dinge, die mit Apps zu tun haben, die vielleicht nicht ganz dieselben sind.

Greg Warner:

Das ist okay. Und weiter draußen Dinge, die du letztlich einfach nicht kontrollieren kannst. Und dafür hatten wir 76 Integrationen von Teams, die Automatisierungen aus dem gesamten Unternehmen geschrieben hatten. Wir werden nie herausfinden, was sie tun, aber wir wussten, dass einige davon wahrscheinlich kaputt gehen würden. Wir müssen uns also nur mit einer gewissen Änderungskontrolle befassen und diesen Leuten sagen, dass das kommt, was die restlichen Endpunkte sein werden und wie sie ihre API-Schlüssel einrichten. Wir haben eine Menge davon gemacht, aber wir hatten eine Integration, die kaputt ging, und diese Integration ging kaputt, weil das gesamte Team in dieser Woche auf PTO war oder gegangen war. Das können wir nicht vermeiden. Aber es war schön zu sehen, dass andere Teams tatsächlich eingesprungen sind, weil sie an der Aktualisierung ihres Teams beteiligt waren, um das Problem zu beheben. Das war also okay. Wir hatten eine Integration, bei der wir wirklich alles gegeben haben, und das war für... Wir haben eine Salesforce-Jira-Integration, die eine umsatzgenerierende Integration ist.

Greg Warner:

Wir haben dem viel Aufmerksamkeit geschenkt, um sicherzustellen, dass das einfach funktioniert. Aber den 76 anderen haben wir ein Runbook zur Verfügung gestellt. Das Runbook bestand im Wesentlichen aus Teams, man macht solche Dinge. Sie wussten also, wie man das neue System ändert und auf das neue System aktualisiert. Aber ja, sicherlich der Anfang, die Mitte und das Ende. Der Anfang sind all die Veränderungen, die Sie ändern müssen, und wahrscheinlich ein bisschen Geschichte über Designentscheidungen. Die Mitte ist in der Tat Ihre Cloud-Migration und das Ende, die Mitte bis zum Ende, ist alles, was Sie danach damit machen. Daraus ergibt sich also der wahre Wert Ihrer Cloud-Migration. Was können wir damit machen, wenn Sie einmal drin sind?

Greg Warner:

Und wir sind jetzt kurz vor dem Ende. Es gab Dinge, die ich nicht hätte planen können und die Leute getan haben. Wir haben Ihre fortschrittlichen Roadmaps erstellt, um den Wald dort zu retten, aber wir ermutigen auch unsere Mitarbeiter, die Plattform zu erweitern. Das war früher wirklich schwierig und wir haben mit Atlassian zusammengearbeitet, um zu verstehen, wie das aussehen sollte? Und wir haben uns dafür entschieden, Atlassian Forge zu verwenden. Und jetzt haben wir diese Woche unsere erste App, in UAT, in Atlassian Cloud, um Geschäftsprobleme zu lösen, die wir haben. Das ist eine benutzerdefinierte Atlassian Forge-App. Und wir ermutigen unsere Techniker, diese zu entwickeln, damit sie sie erweitern und durch die Cloud-Migration echten Nutzen daraus ziehen können.

Chloé Hall:

Ja, wow. Ja, du bist so weit gekommen und es ist schön zu hören, dass du dich dem Ende näherst und all die Möglichkeiten damit einhergehen und du den ganzen Wert siehst. Es zahlt sich auch alles aus. Ich denke, ich möchte nur zu dem Moment zurückkehren, in dem Sie davon sprechen, dass es im Wesentlichen keinen Roadmap-Aufwand gibt. Es gibt niemanden oder etwas, dem man folgen könnte, wo es heißt, dass Sie hier beginnen müssen. Dies sind die Schritte zur Cloud-Migration. Und ich denke, viele Menschen fürchten sich davor. Sie sagen, wir wissen nicht genau, wo wir anfangen sollen. Wir sind uns nicht sicher, welcher Roadmap wir folgen werden. Wie gehst du damit gewissermaßen um?

Greg Warner:

Also komme ich darauf zurück, als ich über die Vision gesprochen habe. Wir sagten, wir fixieren die Vision in flexiblen Details. Schon früh, als wir die Cloud-Migration unterschrieben haben, es war in der ersten Woche, nachdem wir dafür unterschrieben hatten, fragte mich derselbe CIO: „Greg, was ist unser Datum? Wann ziehen wir um? Weil du mir verkauft hast, dass das so viel besser ist. Wo ist die Action? Wann bekommen wir das?“ Und nach der Unterzeichnung haben wir gut sechs Wochen gebraucht, um uns ein Bild von den verfügbaren Tools zu machen. Für Jira gibt es also wirklich zwei Optionen. Es gibt den Jira-Site-Import und den Jira Cloud-Migrationsassistenten. Und auf der Confluence-Seite gibt es einen, der Confluence Cloud-Migrationsassistent genannt wird. Es ist besser zu verstehen, wie diese Technologien funktionieren. Und ein paar Wochen lang überlegte mein Team tatsächlich, wenn wir die Migration selbst durchführen würden, könnten wir dem Unternehmen wahrscheinlich eine Menge Geld sparen und es würde uns gehören.

Greg Warner:

Wir wüssten, wie das Ding funktioniert. Wir hatten ungefähr vier Wochen Zeit und entschieden, dass das eine schreckliche Idee war. Tu das nicht. Alle Unternehmenskunden, über die ich spreche, sagen, dass wir das selbst machen werden, tun Sie das nicht. Tun Sie das nicht. Und ein Grund dafür ist, dass es wirklich vier Säulen für den Erfolg Ihrer Cloud-Migration gibt. Jira-Migration, Confluence-Migration, Apps und Benutzer. Und wir wussten nicht, wie man Apps und Benutzer macht, und wir hätten wahrscheinlich mit Confluence und Jira durchkommen können. Aber wir sagten, schauen Sie, das ist etwas, bei dem wir tatsächlich einen Partner einbeziehen müssen. Deshalb haben wir Partner gebeten, uns mitzuteilen, wie sie das machen, da sie wussten, was sie über uns wussten. Und wir haben so viele Details wie möglich zur Verfügung gestellt. Wir hatten zwei Partner, die tatsächlich völlig unterschiedliche Methoden zur Verfügung gestellt haben, um dorthin zu gelangen.

Greg Warner:

Das ist also so flexibel, was die Details angeht, aber wir mussten wirklich eine Entscheidung treffen, was für uns funktioniert hat. Wenn es also wirklich um Jira ging, würden wir einen Big-Bang-Ansatz wählen und ihn einfach im Laufe eines Wochenendes umstellen, oder wollten wir im Laufe der Zeit Kohorte für Kohorte durchführen? Und wir haben uns für uns entschieden, weil wir ein Unternehmen sind, das unsere Kunden rund um die Uhr unterstützt und den Big Bang Switchover durchführt. Das war der beste Weg, das zu bewerkstelligen. Das ist also einer der Gründe, warum wir uns für den Partner entschieden haben, den wir gewählt haben. Dieser Partner hatte jedoch nicht unbedingt eine Roadmap, in der festgelegt war, wohin er gehen wollte. Aber dann haben wir erklärt, was wir daraus herausholen wollen. Das war das Erste, es ging darum, dass es an einem Wochenende passieren muss. Das filtert dann heraus, was Ihre Auswahlmöglichkeiten sind. Der Teil mit den Ökosystem-Apps ist wirklich wichtig, um sicherzugehen, dass auf Ihrem System möglicherweise Apps installiert sind, die es schon seit 10 Jahren gibt, und Sie sind sich nicht sicher, warum sie noch da sind, weil es vor vier Jira-Admins war.

Greg Warner:

Niemand weiß, was da ist. Aber wenn sie keinen Cloud-Migrationspfad haben, sollten Sie wirklich bedenken, dass sie wahrscheinlich an ihr Ende stoßen werden, da es kein Äquivalent gibt. Sie können sie also ausschließen. Identifizieren Sie diejenigen, mit denen ein Geschäftsprozess verknüpft ist. Und dafür, für uns Salesforce, mussten wir eine Cloud-First-Verbindung finden, die funktionieren würde. Das bedeutete also, dass wir wussten, dass das in Zukunft passieren würde. Aber ich denke wirklich, das Wichtigste, was wir erfunden haben und von dem wir nichts wussten, war, dass wir dieses Ding namens App Burn Down entwickelt haben. Und da haben wir uns all die Apps angesehen, die wir hatten. Wir hatten ungefähr 40 Apps. Wir sagten, okay, welche werden nicht in die Cloud gehen? Welche haben keinen Migrationspfad? Welche werden etwas anderes ersetzen? Und so haben wir im Laufe von etwa drei Monaten damit begonnen, Apps zu entfernen.

Greg Warner:

Die Leute würden also sehen, dass wir allmählich von Designentscheidungen vor Ort und alten Vorgehensweisen wegkommen. Aber wir haben auch gesagt, aber sobald wir zur Cloud kommen, ist das der Ausweg. Also sagten wir, schauen Sie, wir schalten diese App aus, aber Sie erhalten stattdessen diese, die Cloud-First-App. Damit die Leute sehen können, wie wir den Sprung über den Fluss schaffen, um dorthin zu gelangen. Aber das bedeutete, dass wir im Laufe der Zeit Apps identifizieren würden, die nicht verwendet wurden. Wenn wir sie ausgeschaltet haben und nichts passiert ist, ist das in Ordnung. Wir sind aber auch auf einige gestoßen, bei denen sie für eine geschäftliche Nutzung von entscheidender Bedeutung waren. Und wenn wir darauf noch keine Antwort hatten, gab uns das Zeit, eine zu finden. Und mit Ihrer Nutzerbasis, in der Regel sind es Ihre Kollegen, werden das Ihre wichtigsten Kunden sein. Sie werden fragen, okay, du schaltest es aus. Wann erhalte ich die Funktionalität zurück?

Greg Warner:

Und wenn Sie diesen App-Burndown im Laufe der Zeit durchführen, verschafft Ihnen das Zeit, um dann diese Antwort zu haben. Es ist also eine viel einfachere Konversation, als einfach die Funktionen auszuschalten. Ich habe noch keine Antwort für Sie. Es gibt solche Dinge. Es war nicht unbedingt eine Roadmap, aber die Zusammenarbeit mit einem Lösungspartner ist absolut der richtige Weg. Versuchen Sie nicht, es selbst zu tun. Sie arbeiten auch mit Atlassian zusammen und haben eine weitaus bessere Reichweite, um einige dieser Antworten zu erhalten, als Sie es jemals haben könnten. Und ich habe bei mindestens drei verschiedenen Gelegenheiten, bei denen unser Lösungspartner direkt mit einem Ökosystempartner gesprochen hat, um herauszufinden, wie es weitergehen soll. Wie können wir dafür sorgen, dass das funktioniert? Also ist es gut. Die Migration ist eigentlich eine dreiseitige Zusammenarbeit zwischen dir, deinem Lösungspartner und Atlassian. Und ihr habt alle die gleichen Ziele. Sie möchten in die Cloud wechseln und sie funktioniert wirklich gut.

Chloé Hall:

Beeindruckend. Ja. Klingt nach Hoffnung, dass jeder diesen Rat bekommen hat. Nimm das auf keinen Fall alleine. Wenden Sie sich an den Lösungspartner. Und mir gefällt wirklich, wie Sie gesagt haben, dass Sie zu zwei verschiedenen Lösungspartnern gegangen sind und herausgefunden haben, welche Ideen sie haben, in welche Richtung sie Sie führen wollen, sodass Sie Ihre Optionen erkunden und herausfinden konnten, was die beste Route für Splunk ist. Und bei dir hat es auch sehr gut funktioniert. Mit dieser Unterstützung denke ich auch. Ja. Entschuldigung, du gehst.

Greg Warner:

Die Wahl des Partners ist wirklich wichtig und wahrscheinlich eine der frühesten Entscheidungen, die wir getroffen haben, um das richtig zu machen. Und ich erinnere mich, dass ich mehrmals darüber nachgedacht habe, ob wir die richtigen Leute an Bord haben? Haben wir mit... gesprochen Und es war insofern ein Interviewprozess, als wir unseren letzten Tag hatten, nachdem wir sechs Monate lang mit Atlassian und unserem Partner zusammengearbeitet hatten, einen Monat, nachdem unsere Migration abgeschlossen war und wir alle fertig waren, hatten wir ein letztes Zoom-Gespräch mit uns allen, machten ein Foto und machten das. Aber um ehrlich zu sein, fühlte es sich irgendwie wie eine Trennung an, weil wir uns sechs Monate lang ins Gesicht gesehen hatten und gearbeitet hatten. Wir verabschieden uns jetzt alle. Wir sehen uns vielleicht nicht. Es war wie das seltsamste Gefühl. Aber es hat funktioniert. Also ja, es ist eine wirklich grundlegende Entscheidung.

Greg Warner:

Nehmen Sie sich einfach die Zeit, stellen Sie sicher, dass sie verstehen, was wir tun wollen, stellen Sie sicher, dass Sie verstehen, wie sie es machen werden. Aber ja, wenn wir es selbst gemacht hätten, wären wir alle in Knoten geraten, es wäre keine erfolgreiche Migration gewesen oder so. Ich bin ein Techniker. Ich will es lösen. Ich möchte so sein wie... Aber ich denke, die eigentlich richtige Antwort war nein, du musst nicht zu 100% wissen, wie das funktioniert, weil du das hoffentlich nur einmal machen wirst. Konzentrieren Sie sich also auf den wahren Geschäftswert — Dinge wie den Umgang mit Stakeholdern und die Veränderung und das Treffen von Designentscheidungen, die für Sie wirklich wichtig sind, weil Sie diese wahrscheinlich im nächsten Jahrzehnt übernehmen werden, anstatt sich Gedanken darüber zu machen, wie ich meine Daten von A bis Z bekomme?

Chloé Hall:

Ja. Es hätte sich definitiv wie eine Trennung für dich angefühlt, weil du so lange Seite an Seite gearbeitet und mit so viel zu tun gehabt hättest. Hast du immer noch Kontakt zu ihnen oder...

Greg Warner:

Ja, wir hatten eine grundlegende Sache, von der wir immer gesagt haben, dass wir, wenn es ein Problem gibt, immer vorsichtig optimistisch sind, wir werden es lösen. Wir hatten technische Herausforderungen, die wir durchgemacht haben, aber ich habe schon früh gesagt, dass das Ökosystem nur groß ist und wir uns alle irgendwann begegnen werden. Also ja, stellen wir sicher, dass wir am Ende immer noch Freunde sind. Und ich wusste erst, wie wichtig das war, als ich zu Weihnachten in New York war und ein Treffen mit dem Projektmanager vereinbart habe, der für uns gearbeitet hat. Sie lebt in New York, also wie wäre es, wenn ich dich treffe, also... Wir haben uns im Hotel getroffen und sie sagte: „Ich habe noch nie einen Kunden außerhalb der Arbeit getroffen, um das zu tun.“ Ja, ich habe erzählt, dass sich die Geschichte wie eine Trennung anfühlt, aber sie hat gesagt, dass du am Anfang gesagt hast, dass wir danach Freunde sein werden.

Greg Warner:

Ja, das liegt daran, dass es wirklich schwierig sein kann. Ich war auf der Beraterseite, wo man einige harte Gespräche führen musste und manchmal... Du willst sichergehen, dass jeder das Problem versteht. Du versuchst, es besser zu machen, damit du am Ende immer noch solche Freunde sein kannst. Das ist die Sache. Es wird wahrscheinlich später Engagements geben, bei denen Sie sie möglicherweise erneut benötigen. Sie möchten also sicherstellen, dass Sie den besten Zuchtpartner zur Auswahl haben. Sie haben diese Beziehungen. Sie verstehen, was Sie wählen möchten. Also ja, es ist wirklich wichtig, den richtigen Partner zu wählen. Basieren Sie nicht unbedingt auf dem Preis, sondern wählen Sie den Partner, der für Sie arbeiten wird, versteht, was Sie aus Ihrer Cloud-Migration herausholen möchten, und er wird Ihnen in Zukunft zur Verfügung stehen, wenn Sie ihn für eine weitere Cloud-Migration oder ein viel schwierigeres Projekt benötigen. Versuchen Sie, am Ende Freunde zu sein.

Chloé Hall:

Und auf jeden Fall ist es gut, dass Sie jetzt diese Freundschaft haben, weil sie dieses Verständnis für Ihr Unternehmen haben und was Sie wollen und welchen Wert es hat. Wenn Sie also wieder Hilfe benötigen, ist es viel einfacher, sie sofort mit ins Boot zu holen. Sehen Sie den Prozess jetzt, da Sie eine Cloud-Migration durchgeführt haben und sich dem Ende nähern, anders als ganz am Anfang?

Greg Warner:

Ja, ich dachte, wir würden nur eine Datenmigration durchführen, nur ja, vor Ort in die Cloud.

Chloé Hall:

Ja.

Greg Warner:

Ziemlich einfach, nichts Großes. Ich war angenehm überrascht, als wir im Laufe der Zeit einige dieser Entscheidungen trafen, dass es mehr als das war. Es gab Geschäftsprozesse, die wir verbessern konnten. Es gab den Anfang, die Mitte und das Ende. Das habe ich erst nach dem Ende gemerkt. Als wir also unsere Cloud-Migration durchführten, war es tatsächlich die Woche vor Thanksgiving in den USA. Es war der 19. November. Und selbst diese Entscheidung wurde getroffen, indem ich mittags einfach spazieren ging. Wann sollten wir das wirklich tun? Und ich kam wieder runter, sprach mit meinem Projektmanager und sagte: „Wie wäre es, wenn wir das in der Woche vor Thanksgiving in der Cloud-Migration machen?“ Weil 50% unserer Belegschaft in den USA ansässig sind und ein großer Teil davon zuvor beurlaubt oder arbeitsfrei sein wird.

Greg Warner:

Indem wir es an einem Wochenende davor machen, stellen wir sicher, dass... Wie wenn du ein neues Restaurant eröffnest. Sie möchten nicht, dass am ersten Abend alle Tische voll sind. Wir wussten, dass am ersten Tag nach einer Migration jeder Jira und Confluence verwenden würde, weil wir einige Dinge kaputt machen würden. Sie haben sich tatsächlich als wirklich außergewöhnlich gute Idee herausgestellt. Und ich ermutigte die Leute zu finden... Schauen Sie sich Ihre Daten an und finden Sie heraus, wann die niedrigste Zeit dafür ist? Ich beschäftige mich schon lange mit Jira und Confluence und dachte einfach, es ist Task-Tracker und es ist ein Wiki. Da gibt es nichts, wovon ich nicht wirklich weiß. Aber eine der Entscheidungen, die wir getroffen haben, war, dass ich, als wir die Datenmigration abgeschlossen hatten und alles startklar war, immer gesagt habe, wenn wir warten, bekommen wir dann ein besseres Ergebnis? Und die Antwort lautete nein.

Greg Warner:

Wir sollten das jetzt den Menschen zur Verfügung stellen. Deshalb haben wir es an einem Sonntagmorgen in den USA eröffnet, als in Australien die Geschäftszeiten anfingen. Wir haben begonnen, Teams darauf aufmerksam zu machen, dass sie jetzt Jira und Confluence verwenden können. Und es war das Feedback, das wir sofort von den Teams erhielten, die anfingen, Jira Service Management zum ersten Mal in der Cloud zu verwenden, etwa: „Wow, das ist so viel besser als vor Ort.“ Und die Leute sagten: „Ich kann tatsächlich die Liebe zum Detail sehen, die Sie bei Feldern und Beschreibungen vorgenommen haben, und die Änderungen, die Sie vorgenommen haben.“ Und es begann sich auf den Arbeitsalltag der Menschen auszuwirken, dass das besser war als es war. Ich hatte nicht erwartet, dass das zurückkommen würde. Deshalb habe ich eine Zusammenstellung all dieser Slack-Nachrichten von Leuten, die sagen: „Das ist wirklich gut, wir teilen sie mit dem Team. Das ist viel besser als zuvor.“

Greg Warner:

Was mir auch nicht bewusst war, ist, dass mit dem Umstieg von On-Premise auf die Cloud die Daten nutzbarer und zugänglicher geworden sind. Das hatte ich nicht geplant. Das scheint jetzt offensichtlich, aber wenn wir es in die Cloud stellen und es mit allen Sicherheitskontrollen ausgestattet ist und jetzt nicht mehr die Anforderungen von Dingen wie VPN erfüllt, um darauf zuzugreifen, könnten die Leute neue Dinge entwickeln, um es zu nutzen, um mit Ihren Problemen zu interagieren, mit Seiten zu interagieren. Also haben wir mit 76 Integrationen angefangen und innerhalb von drei Monaten hatten wir in den ersten drei Monaten diesen großen Sprung auf etwa einhundert und jetzt gehen wir zu Forge. Und das bedeutet, dass Leute, die dieses Bedürfnis hatten, auf die Daten zugreifen zu können, jetzt darauf zugreifen können. Das habe ich nicht kommen sehen. Ich dachte nur, wir wären nur Server-Cloud. Aber ja, eine besser zugängliche Version hat zu Verbesserungen in der Art und Weise geführt, wie unsere Teams arbeiten, aber auch zu Verbesserungen in der Art und Weise, wie sie sie in anderen Anwendungen verwenden, die vorher einfach nicht verfügbar waren.

Chloé Hall:

Ja. Beeindruckend. Das ist großartig. Und es ist gut, dass du dieses Feedback von den Teams, die du in Australien hattest, sofort erhalten konntest. Ich finde das wirklich gut und es hört sich so an, als ob es auch für Sie bei Splunk eine so gute Gelegenheit geschaffen hat, jetzt, wo Sie in der Cloud sind.

Greg Warner:

Ja, es ist sicherlich ein Unternehmensleiter, der Sie voranbringen kann, und ich komme jetzt eifrig rein und sehe mir an, was andere Teams damit machen werden. Und als wir das erste Team hatten, das sagte, sie wollen eine Forge-App entwickeln, dachte ich, klar. Davon sollten wir überhaupt nicht abraten. Erweitere die Plattform. Deshalb haben wir das Geld und die Zeit dafür ausgegeben. Was kannst du jetzt damit machen? Und wir haben Atlassian auf der Produktseite auf jeden Fall darauf aufmerksam gemacht, wie wir es verwenden und wo wir uns Verbesserungen wünschen. Wenn du dir den Server-DC-Vergleich ansiehst, war ich früher die Person, die sich die neuen Funktionen in der Cloud angesehen und die Frage gestellt hat, wann diese neue Funktion vor Ort verfügbar sein wird. Um der Kunde zu sein, der diese Funktion jetzt hat, habe ich diese Funktion heute, richtig? Und ich benutze es, weil wir nicht darauf warten.

Greg Warner:

Sie haben also Dinge erwähnt, die Sie in der Roadmap nicht geplant hatten. Es gibt Designentscheidungen, über die ich mit Unternehmenskunden spreche und auf die ich achten muss. Eine davon hat mit Release-Tracks zu tun. In der Enterprise Cloud können Sie wählen, ob Sie die Änderungen in der Cloud bündeln möchten, und dann werden sie regelmäßig alle zwei Wochen, jeden Monat, veröffentlicht. Als ich mir das ansah und zu einem unserer Prinzipien zurückkam, nämlich Server nicht in der Cloud zu implementieren, warum sollten wir das tun? Atlassian hat weitaus mehr Daten darüber, ob dies für Kunden in großem Maßstab funktioniert, als wir. Warum sollten wir uns also mit der Funktionalität zurückhalten? Aus diesem Grund veröffentlichen wir keine Tracks. Wir lassen uns alle neuen Funktionen so bereitstellen, wie es Atlassian für richtig hält. Und das Ergebnis davon ist, dass unsere eigenen Techniker, unsere eigenen Support-Mitarbeiter, die Jira verwenden, Benachrichtigungen über neue Produkte und Funktionen erhalten, und das ist fantastisch.

Greg Warner:

Nochmals, warum sollten wir den Server implementieren, auf dem Sie all Ihre Änderungen zusammenfassen und dann weitermachen würden? Die andere Sache an unserer Reise zur Cloud-Migration ist auch, dass Sie nicht blinzeln lassen, dass Sie heute nur eine Cloud-Migration durchführen und dann endet das Projekt. Es gibt Dinge, über die Sie im Laufe der Zeit nachdenken müssen, aber was sind die Auswirkungen in der Zukunft? Für uns haben wir also mehrere Websites. Unternehmenskunden haben mehrere Standorte. Es gibt also Designentscheidungen, die wir getroffen haben, damit wir in Zukunft eine Migration von Cloud zu Cloud durchführen können. Sie werden Websites verschieben. Ihre Organisation könnte gekauft werden oder könnte Unternehmen kaufen. Sie führen also Fusionen und Übernahmen durch. Als Teil davon haben wir jetzt einige Runbooks, in denen es um die Verwendung von Cloud-to-Cloud-Tools geht, sodass wir ein Jira-Projekt von einer Site hier auf eine Site dort verschieben können, wie wir Benutzer hierher und Benutzer dorthin verschieben würden.

Greg Warner:

Und das kam tatsächlich durch die Unterstützung unseres TAM zustande, wobei wir uns nicht nur immer auf das Datum der Cloud-Migration konzentrierten, sondern auch darauf, wie das sechs Monate später aussieht? Wie sieht es 12 Monate später aus? Damit Sie Ihre Cloud-Migration nicht durchführen und sich dann in eine Ecke sperren, in der ich später etwas abwickeln muss. Ich hatte die Gelegenheit, das Problem zu beheben. Also ja, ich ermutige Migrationskunden, auch sechs Monate, 12 Monate über ihre Cloud-Migration hinaus zu denken. Aber was könnte auch passieren und dann mit Ihrem Lösungspartner heute über Designentscheidungen sprechen, die Sie in Zukunft betreffen könnten.

Chloé Hall:

Ja. Sie müssen also auf jeden Fall zukunftsorientiert denken, wenn Sie diese Cloud-Migration durchführen. Ich weiß, dass Sie viele der Möglichkeiten, die sich aus der Cloud-Migration ergaben, angesprochen haben. Gab es noch etwas anderes, das einen unerwarteten Wert hatte und das Sie mit uns teilen wollten?

Greg Warner:

Der andere Wert ist, es zugänglicher zu machen. Wir haben gesehen, dass Leute es an verschiedenen Orten benutzt haben, an die wir nicht gedacht hatten. Bei einigen der Dinge, die wir zuvor gemacht haben, mussten wir über eine firmeneigene Ressource verfügen, um das VPN nutzen zu können, und einfach solche Dinge. Das schränkte die Leute tatsächlich ein, wo sie arbeiten konnten. Aber jetzt können Sie, solange Sie einen Computer oder ein Mobilgerät haben, das mit dem Internet verbunden ist, absolut die Unterstützung für mobile Geräte nutzen, Sie können darauf zugreifen. Genehmigungen, die früher auf einem Computer vorgenommen wurden, werden jetzt auf einem Mobilgerät vorgenommen. Diese Dinge. Aber ich denke, die Integrationen waren wahrscheinlich die eine Sache, die ich am meisten mag... Wir sind nicht der Katalysator. Wir haben es irgendwie vorangetrieben, aber gesehen, wie die Leute es wirklich nutzen und die Daten für andere Zwecke verwenden. Wir haben gesehen, wie Leute einige Microservices entwickelt haben, die die Daten von Jira verwenden, was wir vorher nicht konnten. Auch hier setzen Sie dieses Potenzial nur frei, indem Sie es nutzbarer und zugänglicher machen.

Chloé Hall:

Nachdem du die gesamte Migrationsreise durchgemacht hast und, wie du schon sagtest, dich dem Ende näherst, was waren die Dinge, die dir aufgefallen sind, dass du denkst, okay, sie sind nicht so gut gelaufen? Wenn ich das noch einmal machen würde, wie würde ich es vielleicht beim nächsten Mal besser machen?

Greg Warner:

Also kehre ich zu diesem Unboxing-Erlebnis vom ersten Tag zurück. Du weißt, dass du ihm das beste Erlebnis bieten willst. Und wir haben das für die Leute in Australien und APAC bereitgestellt, als wir es geöffnet haben und sie Jira zum ersten Mal benutzen durften und es hat gut funktioniert. Und das ist hauptsächlich das Ergebnis der großen Betonung des Jira-Artikels, weil wir gesagt haben, wir wissen, dass das schwierig sein wird. Es hat Workflows, Problemschemata, Benachrichtigungsschemata. Das wird schwer werden.

Greg Warner:

Also haben wir sehr früh damit angefangen und dann, wahrscheinlich zu 60%, nach unserer Migration, haben wir mit Confluence angefangen. Wir dachten, wie schwer Confluence sein kann. Es ist ein Haufen von Leerzeichen und Seiten. Es kann nicht so schwer sein. Bei den Engineering-Tools von Confluence stießen wir tatsächlich auf einige Herausforderungen bei der Migration, was dazu führte, dass die Confluence UAT verzögert wurde. Das Jira UAT war fantastisch. Läuft einen Monat lang. Wir haben einige Probleme gefunden, wurden behoben, haben Antworten bekommen. Wir waren wirklich zuversichtlich, dass das gut werden würde.

Greg Warner:

Und dann sind wir auf dieses Confluence-Stück gestoßen. Wir sagen, wow, das wird eine Herausforderung. Und es gab mindestens ein Mal, an das ich denken konnte. Es war ein Samstagmorgen beim Frühstück, als mir unser Lösungspartner eine Slack-Nachricht schickte, in der es hieß, ich glaube, wir haben hier ein Problem mit einigen Tools. Was werden wir tun? Gegen Mitte des Tages kratzte ich mir irgendwie am Kopf. Das könnte ein echter Blocker sein. Wir haben tatsächlich mit Atlassian zusammengearbeitet, die technische Lösung entwickelt und das geklärt. Das war gut zu sehen, denn innerhalb von 12 bis 24 Stunden gab es eine Lösung. Aber das bedeutete, dass es das Confluence UAT verzögerte und es eine Woche dauerte. Und Ende der Woche fanden wir etwas heraus, das mit dem neuen Confluence-Editor und Apps von Drittanbietern zu tun hatte. Und wir mussten wirklich mit unseren Stakeholdern verhandeln, um das in die Tat umzusetzen.

Greg Warner:

Denn auch hier gilt: Wenn wir gewartet hätten, hätten wir ein besseres Ergebnis erzielt. Nein, wir sollten wirklich gehen. Wir wissen, dass es dieses Problem gibt. Es ist nicht systemweit, aber es betrifft eine kleine Gruppe von Menschen. Also haben wir es gemacht. Aber für ungefähr hundert Leute haben sie wegen dieser Sache diese wirklich schlechte Confluence-Erfahrung gemacht. Deshalb konnte ich das, was ich versprochen hatte, nicht einhalten, was ein Erlebnis vom ersten Tag an war, das besser sein würde als das, was es zuvor hatte.

Greg Warner:

Jetzt haben wir mit Atlassian und App-Anbietern zusammengearbeitet, um Abhilfe zu schaffen, sodass es am fünften Tag nicht so schlimm war. Es war nicht Tag eins, aber es war nicht perfekt. Aber ich würde die Leute auf jeden Fall ermutigen, dafür zu sorgen, dass ihr Jira und Confluence genauso wichtig behandelt wie einander. Sie gehören zusammen. Als ich unsere Cloud-Migration durchführte, haben wir das an einem Wochenende gemacht und ich erinnere mich, dass ich zurückkam, nachdem ich meine Kinder am Dienstag in der Schule abgesetzt und auf dem Parkplatz gesessen hatte. Ich dachte, wow, das haben wir tatsächlich geschafft.

Greg Warner:

Wenn wir dem Unternehmen vorschlagen würden, Ihr Unternehmens-E-Mail-System und Ihr Finanzsystem an ein Wochenende zu verlagern, wäre die Antwort nein, weil das ein zu großer Hut ist. Aber was wir gesagt haben, ist, dass wir unseren gesamten Atlassian-Stack an einem Wochenende verschieben werden, was eigentlich aus zwei großen Systemen besteht, Jira und Confluence. Wenn ich also noch einmal die Zeit gehabt hätte, hätten wir Confluence viel, viel früher gestartet und dann hätten wir es am Ende nicht überstürzen müssen. Und das hat wirklich zu einer schlechten Erfahrung für diese Leute vom ersten Tag an geführt. Seitdem arbeiten wir mit Atlassian zusammen. Wir sind dabei, das zu lösen. Wir wissen, dass andere Atlassian-Leute das gleiche Problem haben. Ich würde früh anfangen und die Komplexität, die passieren könnte, nicht unterschätzen. Es wird einige Dinge geben, auf die Sie keinen Einfluss haben.

Greg Warner:

Ich spreche über dieses Confluence-Problem und die Migrationstools, die tatsächlich in großem Maßstab durchgeführt werden. Nicht jeder Kunde wird es sehen. Wir haben es gesehen. Ich habe Kundeninterviews geführt, als wir unsere Entscheidung über unseren Lösungspartner getroffen haben, und der Kunde hat mir das tatsächlich erzählt. Als ob ich Confluence hätte starten sollen, weil wir dieses Problem hatten, wir haben etwas Zeit verschwendet und es geschafft. Ich habe sogar meine Notizen. Aber erst später, dasselbe Problem, du hattest sogar die Antwort und sie haben es dir gesagt und du wartest immer noch. Also verbringe ich ein paar Minuten in diesem Podcast damit, darüber zu sprechen, weil es mir passiert ist. Es wird wahrscheinlich der nächsten Person passieren. Also, wenn ich eine Sache tun könnte und das ist, dich zu ermutigen, früher damit zu beginnen. Sie werden am Ende eine viel, viel bessere Migration haben und hoffentlich vom ersten Tag an eine Erfahrung bieten können, die ich nicht machen konnte.

Chloé Hall:

Ja, nein, ich freue mich sehr, dass Sie das auch mit dem Easy Agile-Publikum geteilt haben, denn jetzt wissen sie es und hoffentlich wiederholt sich derselbe Fehler nicht immer wieder. Nun, Greg, meine letzte Frage heute an dich, und ich weiß nicht, ob du willst, dass das deine Antwort ist, aber ich denke, es ist wirklich gut für das Publikum, wenn es eine wichtige Erkenntnis gibt, die sie heute aus dem Podcast mitnehmen können, was wäre dieser eine Ratschlag für alle Zuhörer, um ihre Migrationsreise zu beginnen?

Greg Warner:

Das erste, was zu tun ist, ist, Prioritäten zu setzen. Wenn du also ein Atlassian-Kunde bist, der Jira oder Confluence vor Ort nutzt und du keinen Zeitplan hast und keine Priorität für deine Cloud-Migration hast, dann fang dort an. Öffne die Aufgabe, die darin besteht, Atlassian Cloud zu untersuchen, und wähle ein Datum aus. Denn ja, irgendwann wird es eine Situation geben, in der du vielleicht von deinem CIO gefragt wirst. Deshalb ist es besser, bereits eine Antwort vorbereitet zu haben. Ich würde die Leute ermutigen, sich damit zu befassen, weil es die Zukunft ist. Wenn Sie sich die Branche ansehen, wechseln die Leute zu SaaS. Es ist wirklich eine Frage. Möchten Sie diese Funktion pflegen und der Kunde sein, der sich fragt, wann diese Funktion in die Cloud kommt, oder möchten Sie der Kunde in der Cloud sein, der sie heute hat? Als wir auf die Cloud umgestellt haben, haben wir in Bezug auf Funktionalität, Verfügbarkeit und all die guten Dinge, die die Cloud bietet, einen monumentalen Wandel erlebt. Und es ist einer der größten Promoter... Die Person, die früher Prüfungsfragen für Server geschrieben hat, sagt jetzt, geh zur Cloud.

Greg Warner:

Absolut. Als ich mit anderen Unternehmenskunden gesprochen habe, insbesondere bei Team, habe ich gesagt, wann planen Sie Ihre Cloud-Migration? Ich dachte mir, wow, wir werden in drei Jahren damit beginnen. Ich bin ungefähr drei Jahre? Du musst nächste Woche wieder ins Büro gehen und in etwa 12 Monaten anfangen, denn ja, du wirst... Es ist absolut ein Wettbewerbsvorteil, dies zu tun. Und nicht nur ich bin jetzt der größte Cloud-Gegner. Wir sehen es, wir sehen es jeden Tag und für mich ist dies eines der einflussreichsten Projekte, an denen ich seit 2006 mit Atlassian beteiligt war. Dieses hier wird bei Splunk noch lange eine lang anhaltende Wirkung haben und ich freue mich, mit Ihnen bei Easy Agile und anderen darüber und hier auf ihrer Cloud-Reise zu sprechen, weil ich nächstes Jahr ins Team gehen möchte. Ich möchte sichergehen, dass wir diese Gespräche bis ins Detail führen, ich habe eine Sache verstanden. Entweder habe ich meine Confluence-Migration früher begonnen oder ich habe tatsächlich einen Zeitplan eingegeben, wann wir mit unseren Cloud-Migrationen beginnen sollten.

Chloé Hall:

Ja, wunderschön. Ja, das ist ein toller Ratschlag zum Mitnehmen, Greg. Und ehrlich gesagt, vielen Dank, dass Sie heute zum Podcast gekommen sind. Sie haben einige brillante Einblicke und Erkenntnisse geliefert, und auch weil es keine Roadmap gibt, finde ich, dass Ihre Anleitung für diejenigen, die mit ihrer Cloud-Migration beginnen möchten, so gut ist. Ja. Wir wissen es wirklich zu schätzen, dass Sie Ihr Wissen teilen.

Greg Warner:

In Ordnung. Danke, dass du mich eingeladen hast. Danke fürs Zuhören.

Chloé Hall:

Keine Sorge.

„Ich habe mein Gespräch mit Andrew Malak wirklich genossen. Wir sprechen über die Integration agiler Techniken und geben Tipps, wie eine Kultur der Rechenschaftspflicht erreicht werden kann.“

Andrew ist fest davon überzeugt, dass der Kunde Ihrem Unternehmen vertraut, wenn er Mitglied wird, und Sie sind verpflichtet, dieses Vertrauen zurückzuzahlen, indem Sie ihm helfen, seine Ergebnisse zu erzielen.

Viel Spaß mit der Folge!

‍

‍

‍

‍

Transkript

Teagan Harbridge:

Willkommen zu einer weiteren Folge des Easy Agile Podcasts. Ich bin Teagan, Produktleiter hier bei Easy Agile. Und wir haben heute einen wirklich aufregenden Gast in der Show, Andrew Malak von Spaceship. Er ist der Chief Product Officer. Andrew glaubt fest daran, Produkte und Erlebnisse zu entwickeln, die Kundenprobleme lösen. Er glaubt, dass der Kunde Ihrem Unternehmen vertraut, wenn er Mitglied wird, und Sie sind verpflichtet, dieses Vertrauen zurückzuzahlen, indem Sie ihm helfen, seine Ergebnisse zu erzielen. In seiner aktuellen Position möchte Andrew Menschen dabei helfen, schon in jungen Jahren die Kontrolle über ihr Vermögen zu übernehmen. Er vermittelt ihnen gute Geldgewohnheiten und hilft Menschen dabei, dort zu investieren, wo sich die Welt bewegt. Andrew ist ein Familienvater, der seine Zeit mit seiner Frau und seinen Kindern liebt. Und ob Sie es glauben oder nicht, er verwendet agile Techniken in seinem Privat- und Berufsleben. Andrew ist ein Wirtschaftsfreak. Er spielt und trainiert Fußball, Fußball. Er ist ein großer Fan von Liverpool, liebt es zu reisen, liebt tolle Architektur und liebt es, mit Kindern zu arbeiten.

Teagan Harbridge:

Aus meinem Chat mit Andrew gab es so viele Erkenntnisse, dass ich wirklich Schwierigkeiten hatte, sie auf drei zu reduzieren. Aber wenn du bereit bist, hier sind einige der Dinge, die du aus unserem Chat mit Andrew lernen wirst. Warum wir aufhören sollten, den Begriff agile Transformation zu verwenden und ihn als agile Evolution bezeichnen sollten. Warum es wichtig ist, offen für unsere eigenen Grenzen zu sein, um die alte Denkweise zu durchbrechen, den ursprünglichen Umfang zu schützen. Und Tipps, wie Sie eine Kultur der Rechenschaftspflicht erreichen können. Also ich hoffe es gefällt euch. Andrew, kannst du mir ein bisschen über Spaceship erzählen?

Andrew Malak:

Oh, fantastisch. Oh, vielen Dank, dass du mich zuallererst eingeladen hast, Teagan. Spaceship ist ein Unternehmen, das auf dem Weg ist, gute Geldgewohnheiten und Investitionen für alle Menschen zugänglich zu machen. Wir suchen also nach Trends, die sich auf Branchen oder Unternehmen beziehen, die die Zukunft sowohl der Industrie als auch der Volkswirtschaften gestalten. Wir investieren langfristig in sie, wir bauen Markteintrittsbarrieren für Menschen ab, wir bieten ihnen ein gebührenfreies Produkt unter 5.000 USD, ohne Mindestinvestitionen. Es ist wirklich einfach, sich anzumelden. Sie laden einfach eine App herunter und melden sich an und treffen eine Produktauswahlentscheidung, und fertig. Sie können mit dem Autopiloten beginnen, zu investieren. Wir ermöglichen es Ihnen, Ihre Rentenkassenbeiträge auch auf nicht allzu unterschiedliche Weise zu investieren.

Teagan Harbridge:

Erzählen Sie mir dann ein wenig darüber, wer Ihr Zielkunde ist. Weil es so aussieht, als ob Sie versuchen, etwas ziemlich Kompliziertes für vielleicht Erstinvestoren zugänglich zu machen.

Andrew Malak:

Nun, du hast absolut recht. Im Moment gibt es da draußen ein Nischensegment von Leuten, Millennials oder sogar Generation Z, von dem wir einfach nicht glauben, dass es von den etablierten Unternehmen gut bedient wurde. Und was wir versuchen, ist, bei diesen jungen Leuten so viel Resonanz wie möglich zu finden. Wir versuchen, den Branchenjargon zu reduzieren und ihnen die Dinge wirklich einfach zu machen, denn Investitionen müssen nicht komplex sein. Es geht wirklich um viel Disziplin. Wenn ich meine persönliche Gewinn- und Verlustrechnung verwalten kann, oder Geld rein, Geld raus, dann kann ich einen Liquiditätspuffer schaffen, der in meine Vermögensspalte in meiner Bilanz aufgenommen wird. Das ist wirklich das, was wir versuchen zu tun. Und diese Art von Sprache kann, wenn wir sie richtig machen, Dinge, die normalerweise in den Händen von Finanzberatern und Buchhaltern lagen, wirklich vereinfachen und sie alltäglichen Australiern zurückgeben, die ihre Investitionsreise beginnen.

Teagan Harbridge:

Ja, großartig. Und du warst auf einer ziemlichen Reise, bevor du als Spaceship CPO im FinTech-Bereich gelandet bist. Kannst du mir und unserem Publikum ein bisschen darüber erzählen, wie diese Reise ausgesehen hat?

Andrew Malak:

Oh, wo fange ich an? Wenn Sie einen Absolventen Andrew Malak gefragt hätten, was er jetzt machen würde, glaube ich nicht, dass ich darüber gesprochen hätte, denn zu diesem Zeitpunkt in meiner Karriere wusste ich nicht, dass es diesen Raum tatsächlich geben würde, falls das Sinn macht. Also gehe ich zurück in meine jüngeren Jahre, und ich dachte immer, ich würde Architekt werden. Ich hatte diese Faszination für Brücken und ich wollte Dinge entwerfen und sehen, wie sie zum Leben erweckt werden. Sagen wir einfach, dass ich das im Moment auf unterschiedliche Weise mache, aber ich habe angefangen, bei CommSec auf dem Parkett zu arbeiten. Ich habe dann als Business Analyst gearbeitet, und dort begann ich, kritisch darüber nachzudenken, wie Unternehmen funktionieren und wie Dinge effizienter gestaltet werden können.

Andrew Malak:

Ich habe mich ein bisschen mit dem Unterrichten versucht, ich habe ein bisschen Wirtschaft und Religion an der High School unterrichtet. Und dann landete ich schließlich vor der Fusion mit Westpac in einer Produktposition bei der St. George Bank. Zu diesem Zeitpunkt ging die Glühbirne wirklich an. Mir wurde klar: „Hey, ich mag es, Dinge zu kreieren. Ich ändere gerne Dinge. Ich mag es nicht, Dinge einfach zu tun „, wenn das Sinn macht. Und dieser verwunderte Geist, der die Konformität nicht mag, wurde endlich losgelassen, falls das Sinn macht. Und ich habe nicht aufgehört, es zu genießen. Ich habe meine Zeit bei Westpac geliebt, viele Freunde gefunden, an wirklich coolen, erfolgreichen Projekten gearbeitet und viele Dinge umgesetzt, die großartige Ergebnisse gebracht haben. Ich habe an vielen Dingen gearbeitet, die kläglich gescheitert sind, und daraus viel gelernt. Und als sich Ende letzten Jahres die Gelegenheit bei Spaceship bot, war das einfach eine zu gute Gelegenheit, um nicht wirklich reinzukommen und es auszuprobieren. Also ja, es war eine ziemliche Reise.

Teagan Harbridge:

Ja, wow. Und ich liebe gute Misserfolgsgeschichten. Und du sagtest, du hattest viele. Kannst du dir spontan vorstellen, was einer dieser großen Misserfolge war?

Andrew Malak:

Wo fange ich an? Ich denke, unser erster Versuch, ein digitales Erlebnis zu nutzen, um es Kunden zu ermöglichen, ein Produkt online zu erwerben, war ein ziemlicher Misserfolg, der uns viel gelehrt hat. Wir haben im Grunde genommen die Systeme genommen, die unsere Backoffice-Mitarbeiter verwendeten, und sie einfach den Kunden zur Verfügung gestellt. Und die wirklich gute Erkenntnis daraus ist, dass es viel Verkehr und eine große Nachfrage gab, aber nie genug fertiggestellt wurde. Und das Beste, was daraus gelernt wurde... Das war 2006, also fingen die Internetgeschwindigkeiten gerade an zu steigen. Breitband wurde langsam zum Mainstream und das Vertrauen der Kunden, mehr Transaktionen mit personenbezogenen Daten abzuwickeln, begann sich zu diesem Zeitpunkt zu normalisieren. Bis dahin dachten die Leute ziemlich zurückhaltend: „Ich werde meine persönlichen Daten verlieren“ usw. Als wir uns dazu entschlossen, stellten wir fest, dass es eine große Nachfrage gab, aber wir stellten schnell fest, dass wir die Mitarbeiter vier bis sechs Wochen lang in der Verwendung der Systeme geschult haben, bevor sie wussten, wie sie die Kunden, die sie nutzen, bedient werden sollten.

Andrew Malak:

Aber dann haben wir es in der Produktion für Kunden zur Selbstbedienung eingesetzt und ziemlich schnell festgestellt, dass das Erlebnis für Kunden viel besser geleitet werden muss als das Erlebnis für einen Mitarbeiter. An dieser Stelle begann die Entwicklung von Usability oder Design Thinking ins Spiel. Wir fingen an, darüber nachzudenken: „Nun, wie machen wir diese Dinge so einfach, dass ein Erstanwender ohne Probleme von einem Ende zum anderen gehen kann?“ Und hier wird unser Verständnis von Designprinzipien und Kundentests mit Wortlaut und einer Sprache, die bei Erstbenutzern Anklang findet, entscheidend für die Ausführung. Es geht nicht nur um gute Systeme, sondern auch um eine gute Benutzererfahrung, die auf Systemen liegt.

Andrew Malak:

Das ist wahrscheinlich das, was mich am meisten anspricht, weil ich das während meiner gesamten Karriere sehr geschätzt habe. Jetzt denke ich bei allem, was ich tue, an: „Wo ist die Reibung? Wie stellen wir sicher, dass es keine Reibung gibt? Wie wird sich der Kunde während dieser Erfahrung fühlen? Wie sorgen wir dafür, dass der Kunde bei diesem Erlebnis unnötig verunsichert wird, und wie können wir das vermeiden? Wie werden wir transparenter und sind trotzdem einfach?“ Und ja, das ist wahrscheinlich derjenige, der am meisten Anklang findet.

Teagan Harbridge:

Scheint früh genug in diesem Projekt eine enorme Lernmöglichkeit zu sein und etwas, das dir seitdem im Gedächtnis geblieben ist, so eine großartige Lernmöglichkeit.

Andrew Malak:

Absolut.

Teagan Harbridge:

Wir haben eine Menge Kunden, die sich in allen Phasen ihrer agilen Transformation befinden, und ich weiß, dass Sie damit Erfahrung gemacht haben, wenn wir zu Ihren Tagen in St. George, Westpac, zurückkehren. Können Sie unserem Publikum irgendwelche Tipps oder Geschichten geben, denen Sie begegnet sind, als Sie diese agilen Transformationen durchgemacht haben? Welche Lektionen können Sie mit unserem Publikum teilen?

Andrew Malak:

Oh, ich habe tatsächlich viele Lektionen zu teilen.

Teagan Harbridge:

Das liebe ich.

Andrew Malak:

Schauen Sie, ich positioniere es eher als agile Evolution als als agile Transformation, denn egal, was Sie versuchen, Sie werden nicht einfach einen Wasserfall fallen lassen und am nächsten Morgen agil werden. Ehrlich gesagt habe ich so viele Versuche gesehen und jedes Mal stelle ich fest, dass die Gradualität der Änderung eine bessere Vorhersagbarkeit des Endergebnisses bedeutet, das Sie erzielen werden. Letztlich ist der Heilige Gral, den jeder anstrebt, dass Sie als Führungskraft zu einem Team aufstehen können, unerwartet aufstehen und dann, ohne dass Ihnen gesagt wird, wer in welcher Rolle ist, wer der Product Owner ist, wer der Ingenieur ist, wer die Qualitätskontrolle ist, wer der Designer ist, wird es für Sie als Führungskraft schwierig, herauszufinden, wer wer ist, weil das Team zu diesem Zeitpunkt so gut auf die Kundenergebnisse abgestimmt ist, dass sie organisiert sich selbst in Bezug auf das, was jede Person tun muss.

Andrew Malak:

Und die meiste Sprache, die verwendet wird, dreht sich wirklich darum. Was versuchen wir, den Kunden zu definieren? Was können wir im Rahmen der uns zur Verfügung stehenden Kapazitäten am besten tun, um diese Funktion so schnell wie möglich auf den Markt zu bringen und so viel Wert wie möglich für den Kunden und das Unternehmen zu erzielen? Es dauert lange, bis Sie damit beginnen können, sich auf standardisierte, gemeinsame Ziele, einen gemeinsamen Rhythmus und gemeinsame Arbeitsweisen zu konzentrieren. Und ich denke, es geht letztlich darum, wie viel Ermächtigung man den Leuten geben kann und wie sehr man sich als Führungskraft in den Hintergrund drängen kann, damit sie es selbst herausfinden können, solange man reinkommt und dabei Dinge anstupst und den Leuten hilft, den Kurs zu korrigieren. Die gute Nachricht ist also, dass ich glaube, dass wir bei Spaceship ziemlich nah dran sind, dieses Ziel zu erreichen.

Andrew Malak:

Wir führen Scrum durch und wir führen Sprints schon lange durch, aber es waren hauptsächlich Zeremonien. Aber im letzten Quartal haben wir wirklich gute Arbeit geleistet, um mehr funktionsübergreifende Mitarbeiter in diese Teams einzubinden. Aber das Ziel für uns ist, dass wir jetzt das Gefühl haben, dass unser Durchsatz tatsächlich gestiegen ist und dass der konstante Informationsfluss zwischen den Teams natürlicher wird und es tatsächlich weniger Unklarheiten zwischen den Teams gibt: „In Ordnung, wir haben es so aufgebaut. Die API ist nicht mehr nutzbar. Es passt nicht zu dem, was wir von unserem Frontend aus zu tun versuchen, und es gibt weniger Hin und Her.“ Wir können also wirklich sehen, dass die Reibung zwischen den Personen im Team wirklich dramatisch abnimmt und wir sehen, dass der Durchsatz wirklich steigt. Nichtsdestotrotz ist der beste Weg für eine agile Transformation, einfach anzufangen.

Andrew Malak:

Du kannst dich hinsetzen und Dinge planen und in Richtung Utopie planen, so viel du willst, oder du kannst einfach loslegen. Wenn ich also sage, indem ich loslegen will, sage ich, dass Sie damit beginnen müssen, die Zustimmung aller Führungskräfte der verschiedenen funktionsübergreifenden Teams einzuholen, denn wenn Sie diese Zustimmung auf Führungsebene nicht haben, wird es einfach nicht funktionieren, weil es Blockaden geben wird, es wird Eskalationen geben. Und wenn all diese Dinge zu Diskussionen führen, in denen es um die Frage geht: „Sollen wir so weitermachen?“ Oder: „Hey, vielleicht ist das nicht das Richtige.“ Das muss sehr früh vom Tisch sein und es muss ein uneingeschränktes Engagement auf Führungsebene sein, dass wir dafür sorgen werden, dass das funktioniert und was auch immer uns begegnet, wir werden es einfach korrigieren. Sobald Sie dieses Engagement auf der Führungsebene erreicht haben, müssen Sie die Werte, mit denen das Team arbeiten soll, sehr klar definieren, denn Agile selbst ist kein Prozess, es ist eine Reihe von Werten, die das Team einfach annehmen und mit denen es anfangen muss zu arbeiten.

Andrew Malak:

Wir könnten also losgehen und Einzelpersonen und Interaktionen über Prozesse und Tools oder funktionierende Software über eine umfassende Dokumentation verwirren. Nun, geben Sie diese dem Team und sie werden am ersten Tag zu Ihnen sagen: „Wir können das alles nicht sofort erledigen.“ Sie könnten also am ersten Tag tatsächlich sagen: „Wir werden immer noch einige Unterlagen benötigen, weil wir uns noch nicht wohl fühlen. Wir verstehen die Sprache der anderen Leute im Scrum-Team nicht gut genug, um direkt nach einer Konversation loslegen und programmieren zu können.“ Aber ab dem 10. Sprint, dem 20. Sprint, setzt sich dieses Missverständnis darüber, was der Product Owner will oder was der Designer mit einer Erfahrung zu erreichen versucht, im Kopf des Ingenieurs fest.

Andrew Malak:

Der Techniker versteht den Kunden viel besser, und dann können Sie mit weniger Prozessen und weniger Dokumentation sowie weniger Verhandlungsergebnissen und mehr Gemeinsamkeiten im gesamten Team auskommen. Die andere Sache, die dann in dieser Phase einsetzt, ist die Fähigkeit des Teams, auf eine Änderung zu reagieren und dies nicht als Bedrohung für das anzusehen, was es zu erreichen versucht. Die alte Arbeitsweise war, diesen Umfang zu definieren, diesen Umfang zu schützen und diesen Umfang nicht durch Dinge stören zu lassen, wohingegen, wenn Sie ein Projekt zur Hälfte abgeschlossen haben und einige wirklich gute Informationen erhalten, die Ihnen sagen, dass Sie vielleicht nicht auf dem richtigen Weg sind, ein gutes Ergebnis zu erzielen, sollten Sie das begrüßen. Und das Team selbst wird das am Anfang als lästig empfinden, aber mit der Zeit werden sie sich wohler fühlen, wenn es um neue Informationen geht.

Teagan Harbridge:

Ja. Es ist eine große Änderung der Denkweise. Ich hatte heute gerade eine Diskussion darüber, wo ist Agilität und Reaktivität, wo ist die Grenze in der Mitte. Und wann ist es, Informationen zu nehmen und zu wechseln, weil Sie glauben, dass etwas besser sein wird, wann können wir diese Denkweise durchbrechen: „Oh, wir sind nur reaktiv?“ Nein, wir reagieren darauf.

Andrew Malak:

Ja, ja. Und schauen Sie, ich denke, das Wort reaktiv selbst hat natürlich eine negative Konnotation, aber Agilität in der Denkweise ermöglicht es Ihnen, das auf den Kopf zu stellen und zu sagen, dass niemand die Dinge zu 100% von dem lösen kann, was möglich ist. Wenn wir also offen für unsere eigenen Grenzen sind, können wir in erster Linie anerkennen, dass wir die Lösung nicht zu 100% durchdacht haben, aber lassen Sie uns auch damit einverstanden sein, weil niemand kann. Ich denke, es dreht sich um und bestätigt es im Voraus und sagt, dass dies passieren wird, aber wenn es soweit ist, werden wir die Informationen, die wir haben, mit den Kapazitäten, die wir haben, bewerten, wie fortschrittlich wir sind, und eine Entscheidung treffen, die für uns, für den Kunden und für das, was möglich ist, richtig ist.

Andrew Malak:

Ich gehe also davon aus, dass je mehr Informationen Sie unterwegs erhalten, desto mehr Verstärkung darüber, ob Sie tun, was richtig ist, oder sollten Sie zu diesem Zeitpunkt einen Kurswechsel vornehmen und ändern? Die andere Sache, die sehr früh passiert, ist, dass, wenn Sie als Führungskraft eine wirklich klare Vision in Bezug auf die Kundenergebnisse entwickeln und Ihr erstes funktionsübergreifendes Team bilden und diese Vision an das Team weitergeben, sie zu deren gehört. Übergeben Sie den Backlog nicht an das Team. Geben Sie ihnen kein fertiges Backlog, sondern geben Sie ihnen einfach die Vision und sagen Sie ihnen dann: „Ihr findet heraus, wie Ihr Backlog aussieht.“ Wenn sie sich ihren eigenen Backlog einfallen lassen, solange du als Führungskraft nicht siehst, dass es nur eine Liste von Ave Marys darin ist und da ein bisschen drin ist, das gut verteilt ist zwischen hygienischen Dingen, strategischen Dingen und ein paar Moonshots und die Balance stimmt, wenn das Team seinen eigenen Backlog erstellt hat, geht die Motivation, die es hat, seine eigenen Ideen zu entwickeln, einfach durch die Decke.

Andrew Malak:

Und das ist es, was du erreichen willst. Sie möchten Klarheit darüber schaffen, dass die Arbeit zur Vision passt, und die Motivation, die Sie aus dem Backlog schöpfen, der vom Team selbst geschaffen wird, bringt Ihnen diese Verbesserung des Durchsatzes. Die andere Sache, mit der Sie sehr früh zu kämpfen haben werden, ist, die Dinge so zu zerlegen, dass sie sich an den Sprint-Rhythmus anpassen. Ich denke, das war oft meine größte Herausforderung, wenn ich schon früh zu agilen Praktiken übergegangen bin. Normalerweise gibt es in den ersten Sprints immer Überläufe und Dinge werden im Sprint nicht abgeschlossen, weil wir am Ende denken, dass wir mehr tun können, als wir können, und es dauert eine Weile, bis wir das herausgefunden haben. Wenn Sie etwas fertigstellen, das in einem Sprint versandfähig wird, nehmen Sie in diesem Sprint wahrscheinlich etwas weniger mit, weil Sie es testen müssen oder Sie müssen in diesem Sprint ein Release machen, oder Sie werden einen PIR machen. Sprint, oder du wirst in diesem Sprint viele Retros machen. Fangen Sie an, gewissermaßen zu formulieren, was Sie im nächsten Planungszyklus durchmachen werden.

Andrew Malak:

Sie müssen also diese Kapazität einhalten, und ich werde feststellen, dass die Teams das Ausmaß dieser Arbeit unterschätzen. Also sei damit einverstanden. Überläufe in den ersten paar Sprints bedeuten nicht, dass du durchgefallen bist, es bedeutet, dass du lernst, besser zu planen. Und stellen Sie dann sicher, dass Ihre Rückblicke und Ihr Pivot davon in Ihre nächsten Planungssitzungen Informationen aufnehmen, die für Sie jetzt neu sind, und stellen Sie sicher, dass Sie damit arbeiten. Ich denke jedoch, dass Sie als Führungskraft die Erwartungen wecken müssen, dass Teams Fehler machen können und dass es eine sichere Umgebung ist.

Andrew Malak:

Und ich habe viele agile gesehen... Ich wollte gerade das Wort Transformation benutzen, obwohl ich gerade gesagt habe, dass ich nicht an Transformation glaube. Alle Teams, die agile Prinzipien anwenden und erwarten, dass sie in ihren ersten Sprints keinen Schluckauf haben und dass, wenn der Durchsatz in den ersten Sprints sinkt, ein bisschen wie „Oh, nun, du hast mir gesagt, dass dieses Ding unseren Durchsatz erhöhen würde.“ Ja, aber nicht sofort. Ja, ich denke, nur realistisch mit sich selbst zu sein und mit dem, was möglich ist, und diese Veränderung an sich, bis sie sich normalisiert, ist etwas gewöhnungsbedürftig. Die Teams müssen wissen, dass es in einer sicheren Umgebung ist, dass alles in Ordnung ist, wenn ihre Produktivität darunter leidet, wenn sie Fehler machen oder Dinge kaputt machen. Wir reparieren es nach vorne.

Andrew Malak:

Aber dann kommt auch ein Punkt, an dem wir uns über die Kultur der Rechenschaftspflicht im Zusammenhang mit der richtigen Nutzung dieser Kapazitäten im Klaren sein müssen. Ich habe also festgestellt, dass die beste Nutzung davon das Showcase ist. Und was wir bei Spaceship gemacht haben, weil wir versuchen, die Anzahl der Zeremonien zu reduzieren, haben wir sowohl das Playback der Planung in einem Sprint als auch das Showcase zu einer Zeremonie zusammengefasst. Wir spielen also ab, was wir in der letzten Sitzung erstellt haben, indem wir eine Demonstration der funktionierenden Software verwenden und den Umfang der ausgeführten Arbeit mit dem vergleichen, was im vorherigen Sprint geplant war. Wir sagen, dass wir zu 80%, zu 90% mit der Arbeit fertig sind, und so sieht es aus und so fühlt es sich an, und so stellen wir es dem Kunden zur Verfügung. Dann zeigen wir tatsächlich, was wir im nächsten Sprint vorhaben.

Andrew Malak:

Und das ist Teil des Showcases, unser persönliches Bekenntnis zu dem Motto: „Dafür setzen wir uns als Team im nächsten Sprint ein.“ Und dann wird diese Rechenschaftspflicht gegenüber der Organisation zu etwas, das uns während des gesamten Sprints auf Kurs hält. Wenn Ablenkungen oder Dinge, die im Sprint nicht festgelegt wurden, auf uns zukommen, denken wir schnell darüber nach, okay, können wir diese Dinge berücksichtigen? Müssen sie erledigt werden? Werden sie uns von dem, was geplant ist, abbringen? Sind sie wichtig genug? Handelt es sich um einen schwerwiegenden Produktionsfehler und können Kunden nicht mehr auf unsere App zugreifen? Nun, lassen Sie das, was Sie tun, fallen und kümmern Sie sich darum. Andernfalls, wenn es nicht wesentlich ist, konzentrieren Sie sich weiterhin auf die Arbeit, zu der Sie sich vor der Organisation verpflichtet haben.

Andrew Malak:

Danach werden Sie zunehmend Probleme haben, und die zunehmenden Schmerzen sind gut, denn das bedeutet, dass Agile funktioniert und mehr Teams oder mehr Funktionschancen für das Unternehmen möglich werden. Es wird noch viel mehr Hype um die Umstellung auf Agile geben. Andere Teams werden rüberkommen und sagen: „Oh, wie machen wir Huckepack auf das, was Sie tun?“ Und so weiter. Das ist gut. Das ist gut, aber es bedeutet jetzt, dass einige neue Risiken tatsächlich eingeführt werden. Die Arbeit mit gemeinsamem Code, gemeinsamen Abhängigkeiten oder sogar die Tatsache, dass normale Leute mehrere Dinge tun müssen, bedeutet nur, dass Sie jetzt mehr Koordination benötigen. Ich würde jedem, der diesen Zeitpunkt erreicht, sagen, dass sich die Leute jetzt gezwungen fühlen, einige neue Rollen einzuführen, Koordinationsrollen. Und ich würde nur sagen, seien Sie vorsichtig, denn das kann Ihren Aufwand sehr schnell erhöhen.

Andrew Malak:

Ich finde, der beste Weg, um sicherzustellen, dass Teams weiterhin synchron sind, ist der richtige Dialog auf der richtigen Ebene im richtigen Rhythmus. Und hier funktioniert es meiner Meinung nach sehr gut, es einfach zu halten, nur das Gedränge von Scrums zu verwenden. Ich mag es, wenn das Gedränge von Scrums zwischen dem Product Owner und dem technischen Leiter jedes Teams, die anwesend sind, ausgewogen ist, und ein- bis zweimal pro Woche funktioniert wirklich gut. Und solange die Product Owner in den Teams und die technischen Leiter in den Teams wissen, woran die anderen Teams arbeiten, wissen, was ihre eigene Arbeit aus Sicht der Veröffentlichung, des Zeitplans oder der Umgebung beeinflussen könnte, funktioniert das meiner Meinung nach auch sehr gut.

Teagan Harbridge:

Ja, wow. Da sind viele Kleinigkeiten drin und sicherlich Dinge, die mit unserer Erfahrung hier bei Easy Agile übereinstimmen, als kleines Unternehmen, das sehr schnell gewachsen ist. Ich kann das also definitiv nachvollziehen. Wir haben uns darüber unterhalten, ob wir neue Rollen in diesem Unternehmen einführen werden. Wir haben erst in den letzten Monaten einen neuen Rhythmus von Besprechungsrhythmen eingeführt, also gehen wir auch diese Dinge durch.

Andrew Malak:

Absolut. Absolut. Was waren Ihre bisher größten Erkenntnisse?

Teagan Harbridge:

Ich denke, dass man die Kommunikation nicht unterschätzen darf, und es kommt wirklich auf diesen Rhythmus und diesen Rhythmus mit dem Team zurück. Und wir experimentieren gerade mit einem täglichen Huddle, bei dem wir darüber sprechen, wie wir Showcases regelmäßiger in unsere Zyklen einbetten können. Am Ende des Zyklus haben wir eine große Demo. Wie können wir das zu einem tief verwurzelten Teil unserer Kultur machen? Und es kommt auch wirklich auf diese Kultur der Rechenschaftspflicht zurück. Also ja, das alles findet Resonanz.

Andrew Malak:

Ja, absolut. Ja, du kannst in jede Branche gehen, die du willst, aber die Probleme sind meistens ähnlich. Und das Tolle ist, dass es sehr wichtig ist, diese Gespräche zu führen, um schnell voranzukommen, da Ihr Problem nicht nur auf Sie beschränkt ist. Jemand anderes hat es gesehen, jemand anderes hat einen Weg gefunden. Und ich denke, was ich an der FinTech-Branche mag, ist, dass wir um Produkte und Dienstleistungen konkurrieren, aber es gibt viel voneinander zu lernen. Und selbst wenn Sie die FinTech-Branche einfach verlassen, können Sie viel von anderen Branchen lernen, die agile Methoden eingeführt haben.

Teagan Harbridge:

Wenn wir einen kleinen Umschwung machen, sind wir von Ihrer beruflichen Karriere und Ihrer Erfahrung auf eine persönlichere Ebene übergegangen. Sie haben erwähnt, dass Sie agile Techniken außerhalb der Arbeit anwenden. Ich bin mir also nicht sicher, ob viele andere im selben Boot sitzen, aber können Sie das näher erläutern? Was heißt das? Wonach sieht das aus?

Andrew Malak:

Okay, ich hoffe, du findest mich nicht extrem komisch. Wir haben sogar eine Familienkampagne. Also ich denke, wenn ich darauf zurückkomme, wie wir dazu gekommen sind, das tatsächlich zu machen. Wenn wir Eltern werden, schauen wir uns unsere Kinder an und sehen so viele Dinge, in denen wir wollen, dass sie besser werden. Und indem wir versuchten, ihnen ständig Feedback zu geben, was sich anfühlte, als wäre das Feedback so umfangreich, dass alles übertönt wird, weil es so viel davon gibt. Tatsächlich gab mir mein ältester Sohn dieses Feedback. Er sagt: „Papa, warum konzentrieren wir uns nicht auf eine Sache nach der anderen?“

Andrew Malak:

Und ich sagte: „Wow, okay.“ Dass mir ein Zehnjähriger das erzählt hat, war unglaublich. Also wurde uns klar, dass wir uns eingrenzen und uns auf einen Verbesserungsbereich nach dem anderen konzentrieren mussten, und wir gehen nicht zum nächsten über, bis wir den ersten abgeschlossen haben. Zum Beispiel mein ältester Sohn, ein sehr kluger Junge. Wir versuchen, uns bei ihm auf die Prozessdisziplin zu konzentrieren, anstatt nur die richtige Antwort zu finden, weil er schlau ist und in den meisten Fällen, wenn man ihm eine Frage stellt, hat er die Antwort und er will sie einfach sagen.

Andrew Malak:

Aber wir haben begonnen, die Frage aufzuschlüsseln und mit ihm mehr an dem Prozess zu arbeiten, damit wir, wenn wir den Prozess verfolgen, gepaart mit seinen natürlichen Fähigkeiten, öfter richtig antworten. Und das ist es, woran wir gerade arbeiten. Auf der Gedränge unserer Familie ist im Moment also eine Mischung aus Dingen zu sehen. Jeder hat seine eigene Schwimmbahn, und in jeder Schwimmbahn gibt es ein paar Aufgaben, einige beziehen sich auf Arbeit oder Studium, andere beziehen sich auf Hausarbeit, andere beziehen sich auf Gesundheit oder Bewegung und wieder andere beziehen sich auf freundliche Handlungen. Und wir wollen sicherstellen, dass wir jeden Tag Dinge in allen vier Kategorien erledigen. Also ja, du kannst Agilität einsetzen, wo immer du willst, aber ich denke, diese Denkweise im Allgemeinen, dass, wenn ich jeden Tag aufwache und Dinge tue, die mich besser machen als gestern, ich sowohl in meinem Privatleben als auch in meinem Berufsleben weiter vorankommen kann.

Teagan Harbridge:

Und haben Sie WIP-Limits?

Andrew Malak:

Das tun wir im Moment nicht und wir veranstalten im Moment keine Showcases. Wir werden sehen, wie wir sie in Zukunft einführen können.

Teagan Harbridge:

Und wie war die Einführung eines Kanban-Boards zu Hause? Wie wurde das von der Familie aufgenommen? Hat es ihnen gefallen, gab es Feedback?

Andrew Malak:

Nun, es war eigentlich nicht geplant. Es fing damit an, dass ich einfach ein paar Post-its auf den Kühlschrank klebte, um uns an Dinge zu erinnern. Und dann sagte ich eines Tages zu meiner Frau: „Weißt du was? Das erinnert mich an das, was wir bei der Arbeit machen. Warum formalisieren wir es nicht?“ Sie kicherte ein bisschen, aber eines Tages kam sie zurück und dann fand sie es dort. Also ja, es war nicht wirklich geplant.

Teagan Harbridge:

Fantastisch. Und du warst schon sehr großzügig mit deiner Zeit, also schließe ich es mit einer letzten Frage ab. Welchen Rat hätte Ihnen Ihrer Meinung nach jemand gegeben, als Sie den Sprung vom Produktmanagement zur Produktleitung gewagt haben?

Andrew Malak:

Ja, das ist eine wirklich gute Frage. Ich denke in erster Linie, dass Sie sicherstellen müssen, dass Sie Ihr Bedürfnis nach Perfektionismus loswerden, denn in erster Linie waren Sie vielleicht selbst der beste Produktmanager. Du warst vielleicht unglaublich. Und ich sage nicht, dass ich das war, aber wenn Sie eine Führungsrolle übernehmen würden, würden Menschen mit unterschiedlichen Fähigkeiten für Sie arbeiten. Und was Sie verstehen müssen, ist, dass sie einige Zeit brauchen werden, um ihre Rolle und ihr Handwerk zu erlernen. Und behindern Sie sie einfach nicht beim Lernen. So könnten Sie beispielsweise jemanden sehen, der etwas tut, das diese Kapazität in diesem Sprint möglicherweise nicht optimal oder optimal nutzt. Möglicherweise verspüren Sie den Drang, einzusteigen und den Kurs zu korrigieren. Aber wenn Sie sie gehen lassen und ihr Feedback nur im Rückblick hören, haben sie das vielleicht selbst gelernt, und eine Erkenntnis, die sie selbst erhalten, anstatt von ihrem Leiter darüber informiert zu werden, wird für sie viel nützlicher sein.

Andrew Malak:

Sie müssen Ihr Bedürfnis, Entscheidungen zu treffen und die Kontrolle zu haben, fallen lassen, denn je mehr Sie sich in eine dienende Führungsrolle verbannen und das Team Entscheidungen treffen lassen können, wenn es Entscheidungen trifft und diese Entscheidung nun mit der Ausführung untermauern muss, ist es wahrscheinlicher, dass es sein Herzblut hineinsteckt. Je mehr sie das Gefühl haben, dass Sie die Entscheidungen treffen werden, desto weniger neigen sie dazu, Probleme selbst zu durchdenken, und dann werden sie die Probleme immer wieder zu Ihnen zurückbringen. Jedes Mal, wenn Ihnen jemand eine Frage stellt, auf die es eine schwarz-weiße Antwort gibt, werfen Sie sie ihm zurück und fragen Sie ihn, was er denkt, denn auf diese Weise coachen Sie ihn, es selbst zu lösen. Und dann ist das Letzte, was wirklich wichtig ist, meiner Meinung nach, dass es wirklich wichtig ist, darüber nachzudenken, wie Ihr Unternehmen es Ihnen ermöglicht, anders zu sein und diese Differenzierung zu nutzen.

Andrew Malak:

Zum Beispiel hier bei Spaceship, weil wir klein sind, wir sind kein großes Unternehmen, unsere Kunden sind etwas nachsichtiger. Sie haben also eine begrenzte Kapazität, um Erlebnisse zu erstellen, und Sie können nicht alle Dinge gleichzeitig tun. Verstehen Sie das und nutzen Sie es, damit Ihr Team das auch lernt. Denn wenn Sie versuchen, alle Randfälle zu zeigen, wird es viel länger dauern, bis etwas auf den Markt gebracht wird, und Sie könnten einen Großteil der Teamkapazitäten nutzen, um Randfälle zu entwickeln. Und das können Sie sich nicht wirklich leisten, wenn Sie in einem Start-up sind.

Andrew Malak:

So haben wir beispielsweise gestern ein neues Anlageportfolio lanciert. Wir haben das Spaceship Earth-Portfolio lanciert, unser erstes nachhaltiges Anlageportfolio, und das ist ein Zeichen dafür, dass hoffentlich noch mehr Dinge im Bereich Nachhaltigkeit auf uns zukommen werden. Aber als wir es auf den Markt brachten, war uns bewusst, dass unsere Erfahrung oder unser Produktangebot heute eine Einschränkung haben, sodass jeder Kunde nur ein Portfolio haben kann. Wir wussten, dass Bestandskunden in nachhaltiges Investieren investieren möchten, aber wir verpflichten uns ihnen gegenüber, dass es in unserem Backlog steht und es eigentlich das nächste Feature ist, das wir tatsächlich auf den Markt bringen werden.

Andrew Malak:

Und als wir unseren Kunden das erklärt haben, waren sie sehr verständnisvoll, dass sie wissen, dass unser Durchsatz begrenzt ist, aber sie wissen auch, dass ihre Stimme gehört wird und wir die Dinge entwickeln, von denen sie uns erzählen. Ich würde also sagen, dass der beste Ratschlag, den ich meinem jungen Ich geben kann, darin besteht, sicherzustellen, dass Sie die richtige Balance zwischen der Stimme des Kunden finden. Das wird Ihnen all die hygienischen Dinge sagen, die Ihrem Produkt in Bezug auf Erfahrung oder Lücken fehlen. Und dann finden Sie das Gleichgewicht zwischen neuen strategischen Dingen, die Sie verfolgen können, und neuen Dingen, die Sie auf den Markt bringen können, sowie ab und zu ein paar Ave Marias. Wir nennen sie Moonshots. Sie können funktionieren oder auch nicht, aber es ist aufregend, und wenn es funktioniert, können Sie Ihre Lautstärke um das Zehnfache erhöhen. Und das sind die Dinge, die sich wahrscheinlich viral verbreiten werden. Daher ist es sehr wichtig, das richtige Gleichgewicht zu finden.

Teagan Harbridge:

Es war wunderbar, Andrew. Ich habe definitiv viel aus unserem heutigen Chat mitgenommen, und ich bin sicher, unser Publikum wird es auch tun. Nochmals vielen Dank für Ihre Zeit und viel Glück.

Andrew Malak:

Nein, Teagan, hör zu, vielen Dank. Und es war mir eine Freude, mit Ihnen und Easy Agile zu sprechen, und ich wünsche Ihnen auch alles Gute.

Teagan Harbridge:

Fantastisch. Danke Andrew.

Andrew Malak:

Hab einen schönen Tag.

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.