Easy Agile Podcast Ep.18 Die besten Eigenschaften eines agilen Leiters und Teams

Folgen Sie in dieser Folge von The Easy Agile Podcast Nick Muldoon und Dave Elkan, den Co-CEOs und Mitbegründern von Easy Agile. Da sie sich auf die nächste Wachstumsphase des Unternehmens freuen, wollten sie diese Gelegenheit nutzen, um über ihren bisherigen Werdegang nachzudenken.

Nick und Dave sprechen über das Wachstum eines Start-ups in der Region Australien, die Suche nach den richtigen Leuten, die Aufrechterhaltung einer positiven Teamkultur und die Bedeutung werteorientierter Teams.

„Unser Ziel ist es, Teams dabei zu helfen, agil zu sein, und dabei tun wir das für uns selbst. Wir versuchen ständig, zu lernen, uns anzupassen und mit neuen Dingen zu experimentieren. Ich hoffe, das war ein nützlicher kleiner Leckerbissen und eine Reise von Dave und mir darüber, wie wir Easy Agile zu diesem Punkt gebracht haben.“

- Nick Muldoon, Co-CEO von Easy Agile

„Es gibt diese lustigen kleinen Hacks und Analogien und ich denke, das ist eine Sache mit langfristiger Vision. Wenn Sie ein Unternehmen führen, das diese langfristige Vision und dieses Ziel nicht verfolgt, dann können Sie tatsächlich in mehrere Richtungen gleichzeitig gehen, und Sie werden keine Fortschritte machen.“

- Dave Elkan, Co-CEO von Easy Agile

Abonniere unbedingt, genieße die Folge 🎧

Transkript

Nick Muldoon:

Guten Tag, Leute. Nick Muldoon mit Dave Elkan, Mitbegründer und Co-CEO von Easy Agile. Bevor wir beginnen, möchten wir den traditionellen Hütern des Landes, auf dem wir heute senden und aufnehmen, unsere Anerkennung aussprechen, dem Volk der Wodiwodi der Dharawal Nation. Wir erweisen den Ältesten in Vergangenheit und Gegenwart unseren Respekt und erweisen allen unseren Ureinwohnern, die heute zuhören, den gleichen Respekt.

Nick Muldoon:

Dave, nur ein kleiner Rückblick auf fünfeinhalb Geschäftsjahre?

Dave Elkan:

Geschäft? Ja, eine Achterbahn. Es hat großen Spaß gemacht.

Nick Muldoon:

Es ist eine Achterbahn, nicht wahr? Ich schätze, wo fängt man am besten an? Der beste Ort, um anzufangen, ist am Anfang.

Dave Elkan:

Ja, ich meine, wir können vor dem Start gehen. Es gibt immer ein gutes Prequel. Ich schätze, wir können später eine Prequel-Episode machen. Aber ich glaube, ich erinnere mich frühestens an die Zusammenarbeit mit dir, Nick, war auf Level 15 in der Kent Street, bei Atlassian. Da war dieser rothaarige Typ am einen Ende des Gebäudes, der an Atlassian GreenHopper arbeitete, und ich war zu der Zeit damit beschäftigt, im Kick-Ass-Team zu arbeiten und 2011 den neuen Issue Navigator zu entwickeln, der jetzt der alte Issue Navigator ist. Und dann hast du dich nach San Francisco verschissen und ich bin ihm schließlich gefolgt, und dann haben wir eine Weile da rumgehangen, nicht wahr?

Nick Muldoon:

Ja, ich erinnere mich daran, weil wir uns hingesetzt haben, ich war zurück, um zu heiraten, und wir haben uns hingesetzt und einen Kaffee getrunken und darüber geredet, dass du und Rin nach San Francisco gezogen sind und wie es für Liz und mich gewesen war und wie der Prozess war und all diese Dinge.

Dave Elkan:

Das ist eine großartige Gelegenheit, auch unser Leben auf dieser großartigen Reise zu würdigen, und wenn sie nicht gewesen wären, wären wir wahrscheinlich gar nicht nach San Francisco gegangen, weil ein großer Teil der Werbung darin besteht, ins Ausland zu gehen und das sowieso für mich und für Sie selbst zu tun, da bin ich mir ziemlich sicher.

Nick Muldoon:

Ja. Ja, Liz war dieses große Gespräch darüber, nach Übersee zu gehen und etwas Neues zu erleben. Ich fühlte mich in Sydney ziemlich wohl und genoss meine Rolle im Produktmanagement bei Atlassian, aber es war wirklich ein Anstoß, etwas anderes zu erleben und zu machen.

Dave Elkan:

Absolut, hier genauso. Und du warst über vier Jahre dort, in San Francisco, und ich war drei Jahre dort. Aber du bist nach Hause gekommen, du hast geheiratet und ich habe dich gerade auf einen Kaffee geholt und wir saßen da im Martin Place und unterhielten uns und du sagtest: „Ja, es ist großartig. Komm vorbei, du kannst zwei Wochen bei mir bleiben.“ Und ich sage: „Oh, ich kenne dich kaum.“

Nick Muldoon:

Ja, aber es war so viel. Ja, auch wenn ich Liz oder mich nicht kannte, war es viel besser als die Alternative. Also für die Leute, die zuhörten, befand sich das Atlassian-Apartment zu der Zeit in einem ziemlich rauen Teil von The Tenderloin in San Francisco, und es war wahrscheinlich nicht die beste Einführung, wenn jemand nach San Francisco ziehen würde.

Dave Elkan:

Nein. Aber um es kurz zu machen, es gibt eine Menge guter Geschichten, ich bin mir sicher, dass wir sie eines Tages erzählen können, aber irgendwann hatten wir beide Töchter in San Francisco und wir wollten zu Hause und näher bei der Familie sein. Dann kamen wir nach Sydney und stellten fest, dass der Verkehr 20% oder 50% schlimmer ist als zu dem Zeitpunkt, als wir losfuhren und wir entwurzelt wurden. Also, wenn man einmal entwurzelt ist, muss man sich irgendwo wieder hinsetzen und es ist ziemlich einfach, an diesem Punkt umzusteigen, und man hat sich dafür entschieden, Sydney zu verlassen.

Nick Muldoon:

Ja, dieser regionale Lebensstil in Wollongong.

Dave Elkan:

Ja, wo Sie einen ganzen Block Land für sich haben können, ohne das Budget zu sprengen, und Sie können, relativ gesehen, als hätten sich die Zeiten in diesem Bereich ein bisschen geändert, aber seitdem haben wir das verfolgt, nicht wahr? Und wir haben uns Newcastle angesehen und...

Nick Muldoon:

Wir haben uns Newcastle angesehen, Brisbane und Adelaide angeschaut, wir sind sogar durch Wagga Wagga gegangen. Wir hatten das tollste indische Essen in Wagga Wagga, wir dachten fast: „Das ist der richtige Ort. Wenn wir in Wagga so etwas essen können, sind wir süß.“ Etwas zu kalt, aber am Ende haben wir uns für Wollongong entschieden, was zum großen Teil auf die Nähe zum Strand und zum Early Start Discovery Space für die Kinder zurückzuführen ist und einfach ein ziemlich cooler, chilliger Ort, um eine Familie zu gründen. Ich glaube, es gibt auch Aspekte, die Liz und mich wirklich an San Francisco erinnert haben. Wir gingen an einem Samstagmorgen oft auf den Bauernmarkt unten am Ferry Building, und wir fanden den Bauernmarkt an einem Freitag in Wollongong an der Crown Street North, also gab es diese Ähnlichkeiten, die es uns irgendwie ermöglichten, ziemlich einfach von einer Stadt in die andere zu wechseln.

Dave Elkan:

Ja. Es ist ein ziemlich einfacher Ort zum Leben und Verweilen. So wie ich es gerne drehe, ist es gerade weit genug von Sydney entfernt.

Nick Muldoon:

Ja, dazwischen ein netter kleiner Nationalpark.

Dave Elkan:

Stimmt, es kann nicht wirklich auf uns einwirken, es ist nicht erlaubt. Da kannst du nicht bauen, also hast du immer diesen Puffer. Aber ich erinnere mich, dass ich zum Geburtstag einer Nichte nach Sydney zurückkehrte und mir 9$ pro Stunde für das Parken am Strand berechnet wurden, wenn man bedenkt, dass du nicht einmal mehr eine Parkplakette hast, weil ich kein Anwohner war, und ich dachte: „Wow, das ist wirklich teuer.“ Aber für alle, die nach Wollongong oder in die andere Richtung kommen, können Sie kostenlos am Strand parken. Das ist quasi ein guter Lackmustest für den Unterschied, über den wir hier sprechen.

Nick Muldoon:

Mm-hmm (bejahend). Ja, ich schätze, dieses regionale Leben, als ob wir hier nicht wirklich eine Technologiebranche hätten. Wir kommen aus Sydney, wo es vor 10 Jahren diese aufstrebende Tech-Szene und SyDJs, SydCSS und andere Meetups gab, und in San Francisco wurden wir mittendrin gedrängt. Ich erinnere mich, wir haben letzte Woche über ein Treffen gechattet, bei dem wir uns getroffen haben, den Ruby Creator bei einem Heroku-Treffen, glaube ich, und eine Sitzung über [detrace 00:06:17] in der Firma, die jetzt pleite ist und an deren Namen ich mich nicht einmal erinnern kann, aber wir waren mittendrin bei all den Meetups in San Francisco. Dann gab es in Wollongong nichts davon, und so war es wie eine Frage, was wir tun könnten, um auch hier eine Gemeinschaft aufzubauen, zu versuchen, andere Gleichgesinnte zu treffen?

Dave Elkan:

Ja, es war definitiv dieser Wunsch, nicht wahr? Und wir haben uns vorgenommen, das zu tun, und ich glaube, es war Rin, der es Siligong genannt hat. Ich erinnere mich, dass wir vor unserer Abreise tatsächlich über das Siligong-Tal gesprochen haben, und wir haben einfach beschlossen, das zum Namen der Gemeinde zu machen. Ich habe neulich auf meine alten E-Mails zurückgeschaut und dachte: „Oh, wir haben tatsächlich über Siligong gesprochen, bevor wir in Wollongong waren“, also das ist ziemlich cool.

Nick Muldoon:

Ich erinnere mich an die frühen Tage, weil ich glaube, du und Rin seid mit [Umi 00:07:08] auf dem Flug zurückgekehrt, und Umi war sechs oder acht Wochen alt.

Dave Elkan:

Ja, Oktober.

Nick Muldoon:

Wenn ich mich nicht irre, habe ich dich bei deiner Mutter abgesetzt, damit du deine Mutter und Ken treffen kannst und das war quasi die Heimatbasis. Und danach waren es ein paar Monate oder so, bis wir dich endlich hier unten hatten. Und ich glaube, du warst bei Liz und mir, als du hergekommen bist...

Dave Elkan:

Ja, wieder für zwei Wochen.

Nick Muldoon:

... noch ein paar Wochen, und wir haben wirklich über die Entstehung dessen gesprochen, was zu der Zeit als Arijea Products bezeichnet wurde, und einer Marke, bei der wir nie geblieben sind. Woran erinnern Sie sich an diese frühen Tage und an den Versuch, das Geschäft auf die Beine zu stellen?

Dave Elkan:

Wenn ich darüber nachdenke, du warst in Coniston, nicht in Coniston, [Carmila 00:07:59], es waren tatsächlich weniger als zwei Wochen, weil wir alle kleine Kinder hatten und es war einfach ein bisschen verrückt. Also ich glaube, Rin und ich haben uns organisiert... wir sind runtergekommen und haben Inspektionen gemacht und wir sind bei dir geblieben, während wir das machen, und dann konnten wir uns einen Platz in Fairy Meadow sichern und sind runtergezogen, also sind wir zu diesem Zeitpunkt ein bisschen hin und her gegangen. Und dann waren es diese sechs Monate, in denen buchstäblich... Ich hatte kein Fahrrad, ich bin einfach zu Fuß zur Arbeit gegangen, was für mich super neu ist. Ich habe immer den Bus genommen oder bin mit dem Fahrrad gefahren.

Dave Elkan:

Einige von Ihnen wissen vielleicht, dass ich nie zur Arbeit gependelt bin und das hoffentlich nie tun muss, und wir haben unser Leben nach einem solchen Konzept gestaltet. Aber ich finde es wirklich toll, ich lebte nur zwei Kilometer zu Fuß von der Arbeit entfernt, und das war mindestens die ersten sechs Monate, bis ich nach Balgownie gezogen bin, aber es war eine großartige Zeit meines Lebens und wir hatten ein brandneues Baby und konzentrierten uns einfach auf das Geschäft und versuchten [Crosstalk 00:09:00] -

Nick Muldoon:

Ich erinnere mich, dass wir in den frühen Tagen wirklich keine Ahnung hatten, was wir gemacht haben. Wir haben einen Bereich durchsucht und gesagt: „Nein, das ist nicht angemessen“, und dann haben wir unsere Aufmerksamkeit etwas anderem zugewandt.

Dave Elkan:

Ja. Wir sind uns ein bisschen im Kreis gejagt. Wir hatten einmal fünf Produkte mit zwei Personen.

Nick Muldoon:

Das ist richtig.

Dave Elkan:

Ich denke, das ist zu viel, aber dank der guten Gespräche mit den Kollegen um uns herum bei IXI, die wir führen konnten... als hätten sie gute Fragen gestellt und ich erinnere mich, dass Rob und Nathan uns fragten: „Worin bist du gut?“ Und ich glaube, es war Rin, der meinte: „Okay, du hast diese App-Idee, an wen wirst du sie vermarkten? Schau dir deine Netzwerke an.“ Und das war es, all diese Pfeile begannen in Richtung Agile zu zeigen.

Nick Muldoon:

Ja, ich glaube, es war diese Idee, die Rin hatte: „Du kannst es bauen und sie werden kommen, oder du kannst herausfinden, welchen Markt und welchen Vertrieb du hast, und was ist das Publikum, das du bereits hast, und wie nutzt du das Publikum, das du bereits in der agilen Softwareentwicklung hast, um dieses Publikum zu gründen und etwas Schwung zu bekommen?“ Und das hat uns wirklich umgehauen und in Schwung gebracht. Wenn ich mich nicht irre, denke ich, dass wir eigentlich... nicht viele Ausgaben gehabt hätten, aber ich glaube, wir hatten im Juni 2016 tatsächlich die Gewinnschwelle erreicht, und es war irgendwie dieser „Hurra“ -Moment, weil wir nicht in den Zug steigen und nach Sydney pendeln mussten, um bei Atlassian zu arbeiten oder so. Wir hatten das Produkt für markttauglich befunden und konnten es irgendwie weiterverfolgen und zur nächsten Phase übergehen.

Dave Elkan:

Das stimmt, ja. In dieser Geschichte steckt auch viel, zum Beispiel, wie wir festgestellt haben, dass das Produkt zum Markt passt und die Schritte dahin und auch viele Erkenntnisse aus dieser Zeit, die ich irgendwann teilen kann, denke ich, aber wir könnten in ein Kaninchenloch gehen, wenn wir uns darauf einlassen. Aber ich erinnere mich sicherlich an gut durchdachte Gespräche, die bei Lamingtons und Tee im Mike Codd-Gebäude auf dem Innovation Campus der University of Wollongong geführt wurden, wo wir angefangen haben. Und das war wirklich nur eine Zeit, um... es fühlte sich anders an als meine vorherige, zu der Zeit 15 Jahre Erfahrung, in der man eigentlich, es okay ist, innezuhalten und zu reden und darüber nachzudenken, was man tut, während es in der Vergangenheit einfach hieß: „Geh, geh, baue dieses Ding.“ Und es ist wie: „Oh, okay“, das war wirklich erfrischend für mich und ich denke, das war ein wirklich guter Schritt, um das zu öffnen, was zur Storymap wurde, was unser erstes wirklich erfolgreiches Produkt war.

Nick Muldoon:

Mm-hmm (bejahend). Sie haben die Lamingtons und Tee erwähnt, es waren wahrscheinlich mindestens 50% unserer Zeit, das Geschäft auf die Beine zu stellen, waren Lamingtons und Tee. Es ging darum, über Dinge zu chatten, keinen Code zu schreiben, wir hatten keine nennenswerten Kunden. Es ging wirklich darum herauszufinden, welche Art von Markt wir verfolgen wollten, welche Lösungen wir anbieten wollten und welche Art von Geschäft wir aufbauen wollten? Das war ein großer Teil unserer Zeit, um es auf die Beine zu stellen.

Dave Elkan:

Absolut. Und für die Zuhörer da draußen, die nicht wissen, was ein Lamington ist, es ist eigentlich ein köstliches Stück Biskuitkuchen, getaucht in Schokoladensauce und dann Kokosnuss, Kokosraspeln, also ich weiß, dass man sie in den USA kaufen kann. Das haben wir bei Atlassian gemacht und sie waren ein großer Erfolg, vor allem, weil sie auch Sahne drin hatten, also wirklich gut für eine Tasse Tee oder Kaffee, was auch immer man nimmt. Aber die Sache ist, dass es eine gute Idee ist, sich mit einem Mitbegründer zusammenzusetzen und viel mehr zu reden, als Sie tippen, das ist die Art von Regel, die ich daraus gezogen habe.

Nick Muldoon:

Es ist interessant, weil es so etwas wie diese Art des Sprechens statt Tippens war, das quasi die Entstehung eines unserer Werte war, auch dieses engagierte System. Und ich glaube nicht, dass Sie Kahnemans Buch zu dieser Zeit gelesen haben, und das kam später, sondern sogar nur diese Idee von: „Nehmen wir uns jetzt einfach die Zeit, um über solche Dinge nachzudenken und sie zu verarbeiten“, und der Kontext [Crosstalk 00:13:09] -

Dave Elkan:

Nein, ich erinnere mich. Entschuldigung, ja. Ich habe 2017 auf dem Lansing Summit auch einen Vortrag über Engaged System gehalten.

Nick Muldoon:

16 oder 17?

Dave Elkan:

16 oder 17, ich kann mich nicht erinnern, welcher es ist.

Nick Muldoon:

'16, weil du '16 nach Barcelona gegangen bist.

Dave Elkan:

Barcelona, und das habe ich dort gemacht, nicht wahr? Ja, also das war früh, als ich Thinking, Fast and Slow gelesen habe, was ich sehr empfehlen kann.

Nick Muldoon:

Und der Kontext dazu, für die Leute, die zuhören: Mitte 2016 hatte Dave eine neun Monate alte Tochter. Meine Tochter war zwei Jahre alt und ich hatte ein Neugeborenes und du solltest... deine Nummer zwei bekommen, oder? Also bauten wir ein Unternehmen auf, als wir gründeten und auch unsere Familien gründeten, also hieß es: „Lass uns alles machen“, in einer neuen Stadt. Wie: „Lass uns alles auf einmal machen.“

Dave Elkan:

Ja, das könntest du genauso gut, oder? Beiß einfach alles ab und reiß das Pflaster ab und fertig. Ich meine, meine Töchter waren nur 18 Monate voneinander entfernt, also diese Art von... Bring es einfach hinter dich. Mach den schwierigen Teil und dann kannst du gehen und dich danach amüsieren, nur ein Scherz. Es ist toll, in jungen Jahren viele Kinder zu haben, ich vermisse diese Zeit wirklich. Aber ja, wir waren ziemlich verrückt, aber wir haben es geschafft.

Nick Muldoon:

Es gab uns auch eine Einschränkung, nicht wahr? Weil wir das Mitternachtsöl nicht verbrennen konnten, konnten wir uns nicht von 05:00 Uhr bis Mitternacht auspeitschen, weil wir einfach nicht die Energie hatten und wir die Kinder ernähren und baden und ab ins Bett und all diese Dinge. Es gab also einen Rhythmus, und jetzt, wo ich darüber nachdenke, ergab sich daraus ein weiterer Wert, der unser Gleichgewicht betraf und die Herstellung von Gleichgewicht in unserem Leben betraf.

Dave Elkan:

Ja, ich erinnere mich, tut mir leid, dass ich unterbreche, eine Tweet-Idee, ich kann sie wahrscheinlich ausgraben, an der ich Stoffwindeln oder Windeln aufgehängt habe... es muss gewesen sein, es war in Balgownie, also muss das nach sechs Monaten gewesen sein. Aber ich habe Windeln rumgehangen und ich muss an dem Tag von zu Hause aus gearbeitet haben oder so, aber das war einfach so, als würde ich mein Leben mit der Arbeit in Einklang bringen. Und ich glaube, es kam zurück mit Arbeit, Privatleben, Familienbalance oder so. Wir würden das auf Arbeitsleben, Familie und soziale Ausgewogenheit ausdehnen, das versuchen wir zu verfolgen.

Nick Muldoon:

Mm-hmm (bejahend). Wie sind wir auf diese Reise rund um die Werte und die Art der Etablierung der Werte gekommen? Wann war das im Leben des Unternehmens?

Dave Elkan:

Ich kann mich an den Ort erinnern, an dem wir waren, wir waren tatsächlich in unserem Büro in der Crown Street, als wir uns wirklich hingesetzt und uns darin zusammenkauerten, also das wäre 2018 gewesen.

Nick Muldoon:

Ich glaube, im November 2018 haben wir unser erstes Easy Agile für Fortgeschrittene abgehalten, und dort haben Sie die Sitzung abgehalten: „Was uns hierher gebracht hat, bringt uns nicht dorthin.“ Zu diesem Zeitpunkt hatten wir also die beiden Produkte, Easy Agile User Story Maps und Easy Agile Roadmaps, und wir hatten unsere Marke von Arijea Products auf Easy Agile umgestellt, um unsere Energie sozusagen auf den Agile-Bereich zu konzentrieren. Wir haben die anderen drei Produkte, die nicht auf Agile ausgerichtet waren, veräußert, also haben wir sie an einen anderen Atlassian Solution Marketplace-Partner verkauft. Ich glaube, da haben wir angefangen, diese Gespräche über die nächste Entwicklung des Unternehmenswachstums zu führen. Dann war es 2019, als wir wieder in der Crown Street waren, zurück im Büro, wo wir dieses Gespräch über die Kodifizierung, Etablierung und Niederschrift unserer Werte führten.

Dave Elkan:

Das ist richtig, und es ist ein sehr wertvoller Prozess, den man durchmachen muss, um wirklich im Alltag innezuhalten und sich wirklich darauf zu konzentrieren. Damit hatte ich immer Probleme, ich habe immer Dinge zu tun, aber wenn du dich einmal aus diesem Prozess herausziehst und herauszoomst und dir das Unternehmen ansiehst und dir das angesehen hast und was dir am Herzen liegt, dann kannst du wirklich anfangen, diese Gespräche zu führen, aber sie zu einer tatsächlichen Sache zu machen. Ich denke, man kann es nicht einfach nebenbei machen, man kann es nicht einfach so gut machen wie andere Dinge, es muss wirklich Priorität haben, wie ich gerne sage. Priorität ist kein Plural, es macht keinen Sinn, wenn es pluralisiert ist, aber das sollte die eine Sache sein, die man unter idealen Umständen tut, als ob man es einfach tut und sich wirklich darauf konzentriert, weil es wirklich schwierig ist.

Dave Elkan:

Und es sollte nicht, ich glaube nicht in einer Sitzung, aber zumindest wenn du es tust, es zu einer ernsten Sache machen, denn wenn es echte Werte sind und du sie lebst, als ob sie einfach ziemlich unveränderlich sind, gehen sie einfach mit dir weiter. Wenn du feststellst, dass du sie nicht lebst, dann solltest du sie dir unbedingt noch einmal ansehen, aber wir hatten das Glück, dass die Werte, die wir vertreten, wahr geblieben sind, und ich habe wirklich das Gefühl, dass ich von all den Unternehmen, in denen ich gearbeitet habe, sogar Atlassian, diese jeden Tag auf ganz unterschiedliche Weise gelebt habe.

Nick Muldoon:

Mm-hmm (bejahend). Also, was sind die Werte, die wir haben? Wir haben über bessere Ausgewogenheit gesprochen, und darüber haben wir ein bisschen gesprochen. Wir haben auch über ein engagiertes System 2 gesprochen, wie dieses System-2-Denken. Was sind unsere Werte?

Dave Elkan:

Sei der Kunde, gib etwas zurück und [Crosstalk 00:18:30] -

Nick Muldoon:

[Crosstalk 00:18:30] war ein großes Thema und verpflichte dich zum Team. Also besser mit Ausgewogenheit, etwas zurückgeben, Kunde sein, über unser Gewicht hinausgehen, Engaged System 2 nutzen und sich als Team engagieren. Kehren Sie zu dem Gespräch zurück, das wir 2017 über das Thema „Geben“ geführt haben. Das war etwas, das wirklich System 2 war. Wie haben wir darüber nachgedacht, der Community etwas zurückzugeben, und was bedeutete das für uns als Unternehmen?

Dave Elkan:

Ich denke, es geht auf das zurück, was Sie zuvor über die Community in San Francisco gesagt haben, die wir erlebt haben, und was wir hier mit Silicon gemacht haben, und das einfach zu einem Schwerpunkt gemacht haben, um der Community etwas zurückzugeben. Es baut sich nicht von selbst auf, also muss die Community aktiv aufgebaut werden, indem jemand seine Hand hochlegen und sie starten muss, und ich denke, das haben wir getan. Seitdem haben wir es vielen anderen Leuten ermöglicht, auf wirklich einfache Weise etwas zurückzugeben, wie zum Beispiel: „Lass uns ein Meetup veranstalten“, „Das ist in Ordnung, hier ist unser Framework, auf dem wir das aufbauen können.“ Und auch einfach die tägliche Kommunikation, die wir untereinander auf unserem Silicon Slack haben, was einfach super wertvoll ist.

Nick Muldoon:

Auch super aktiv.

Dave Elkan:

Oh, super aktiv, besonders im Lockdown, da sind viele Leute, die über alle möglichen Dinge reden.

Nick Muldoon:

Ich denke, vielleicht eines der anderen Dinge, also haben Dave und ich das bei Atlassian erlebt, das war diese Idee des Pledge 1%, aber in unserem ersten oder zweiten Jahr mit Easy Agile kamen Atlassian zusammen mit Salesforce und einer Reihe anderer Unternehmen zusammen, um das Fundament für Pledge 1% zu kodifizieren und aufzubauen und andere Unternehmen zu bitten, sich dazu zu verpflichten. Und 2017 haben wir uns verpflichtet, wenn ich mich nicht irre, 1% zu spenden, und jetzt, wo ich schätze, wir spenden quasi 2%, aber was war der Antrieb hinter unserem Versprechen von 1% to Room to Read?

Dave Elkan:

Es ist zum Teil Faulheit, weil ich wirklich ein System für solche Dinge haben möchte und leider ist es schwierig, wenn man ein Unternehmen gründet, die Zeit zu investieren und darüber nachzudenken. Also entschied ich mich für die einfache System-1-Option, die zu dem passt, was wir bei Atlassian erlebt haben, nämlich Room to Read zu unterstützen, was eine großartige Initiative ist, um sicherzustellen, dass junge Frauen, insbesondere in Ländern der Dritten Welt, mindestens eine höhere Ausbildung erhalten, die Grundschule verlassen, in die High School gehen und wenn sie diesen Punkt erreicht haben, ist es viel wahrscheinlicher, dass sie unabhängig sind. Und mit solchen Dingen, wie diesen Investitionen, ist es, als würde man am Anfang neu beginnen und Ländern und Menschen ermöglichen, sich selbst zu helfen. Wenn sie gebildet sind, ist das ein großer Schritt in die richtige Richtung, um sowohl die Überbevölkerung als auch den Klimawandel und all diese Dinge zu bekämpfen, die davon profitieren, dass es diesen Menschen im Leben gut geht.

Nick Muldoon:

Mm-hmm (bejahend). Ja, sie verbessern ständig ihr Schicksal im Leben, richtig? Wie die Erhöhung des Lebensstandards durch Bildung.

Dave Elkan:

Das ist richtig.

Nick Muldoon:

Und wenn wir darüber nachdenken, dass es eines dieser anderen Dinge ist, über unser Gewicht zu schlagen, ich meine, ich erinnere mich, dass wir darüber gesprochen haben, bevor wir unsere Werte aufgeschrieben haben, darauf haben wir wirklich viel Energie konzentriert. Wie Sie bereits erwähnt haben, waren wir zu zweit und wir hatten fünf Produkte auf dem Markt. Ich bin mir nicht ganz sicher, ob das ein gutes Beispiel dafür war, dass wir über unser Gewicht hinaus geschlagen haben, weil wir vielleicht ein bisschen Probleme hatten, aber was sind einige Beispiele dafür, dass wir als kleines Team aus der Region Australien über unser Gewicht geschlagen haben?

Dave Elkan:

Eines unserer Produkte, das wir ursprünglich gebaut haben, war mir wirklich ein Dorn im Auge, es ging ständig kaputt und es spielte nicht meine Stärken aus, was traditionell die Frontend-Entwicklung ist. Danach habe ich mich davon verbrannt und musste die ganze Nacht wach bleiben und das Problem beheben. Ich entschied mich für Apps, die stärker auf das Frontend ausgerichtet sind. Deshalb haben wir Easy Agile User Story Maps und Easy Agile-Programme und Easy Agile Roadmaps hauptsächlich als Frontend-Apps entwickelt. Tatsächlich hatten Easy Agile Roadmaps in den ersten zwei Jahren nicht einmal einen Server, es war nur eine statische Datei in einem Bucket in CloudFront. So funktioniert Atlassian Connect, es ermöglicht dir, Apps auf diese Weise zu hosten, und das kann wirklich nicht kaputt gehen, es bietet im Wesentlichen nur eine andere Sicht auf Jira, aber architektonisch ist es ziemlich einfach. Also konnten wir einfach... das war eine Art, unser Gewicht zu übertreffen, was auch eine bessere Balance ermöglicht, also ergänzen sie sich in dieser Hinsicht irgendwie. Welche anderen Ideen [Crosstalk 00:23:24] -

Nick Muldoon:

Ja, wenn nicht viel schief gehen kann, dann müssen Sie nicht auf Abruf sein und Sie müssen die Dinge nicht außerhalb der Geschäftszeiten reparieren, damit Sie nicht mit verschwommenen Augen und dickem Finger aufwachen und am nächsten Tag einen Bug haben, der das Problem verschlimmert.

Dave Elkan:

Und wenn du die Analogie zu weit treibst, du könntest denken, dass ein Schlag über deinem Gewicht so ist, als ob du jemanden richtig hart schlagen und ihn dann umwerfen kannst, aber das ist eher so, dass du definitiv um den großen [Pelz 00:23:44] rennst. Du lässt dich nicht einmal auf ein Geschwätz ein, du gehst dem nur aus dem Weg. Deshalb haben wir diese Produkte verwendet, und bis vor Kurzem hatten wir tatsächlich Server für sie, und auch hier ist es immer noch sehr einfach, aber sie werden sehr gut überwacht. Wenn also etwas schief geht, haben wir alles im Griff.

Nick Muldoon:

Ich denke, einer der anderen Aspekte in Bezug auf die Technologie, die über unserem Gewicht liegt, ist, dass wir ziemlich oft... Ich denke, vielleicht hast du schon einmal in Bezug auf Room to Read und das Zurückgeben die Faulheit erwähnt, aber wir sind in gewisser Hinsicht faul und wollen einfach Dinge automatisieren. Und ich erinnere mich an den XKCD-Comic, den du teilst, mit dem, wann ist der richtige Zeitpunkt, um etwas zu automatisieren, und wann automatisierst du es, um die Rendite zu erzielen, die du dir wünschst? Aber ich habe das Gefühl, dass wir einige ziemlich gute Entscheidungen darüber getroffen haben, wann Dinge automatisiert werden sollen und sogar darüber, wie wir Kundensupport anbieten oder die alten Tests und Bereitstellungen durchführen, mit Produkten herumgespielt haben, wir haben diese Dinge zu ziemlich guten Zeiten gemacht, sodass wir Produkte an ein globales Publikum von ein paar tausend Kunden liefern können, von Wollongong aus außerhalb der Zeitzone mit diesen Kunden.

Dave Elkan:

Ja. Es ist auch der Zeit voraus, also ich denke, in der Inception Week, was wir jetzt alle fünf Wochen machen, geben wir eine Woche auf, um dem Team den Raum zu geben, neue Dinge zu entdecken. Dabei sind erstaunliche Dinge herausgekommen, die Sie sonst, wenn Sie nur Woche für Woche, Woche für Woche, Woche für Woche, nie wirklich erkennen würden, aber wenn es mir in den Sinn kommt, fällt mir unser Dev-Container ein, der ein Docket-Container ist, der alle Teile enthält, die für die Entwicklung unserer Apps benötigt werden. Sie checken also einfach dieses eine Repository aus, führen ein Skript aus und es richtet Ihre gesamte Entwicklungsumgebung ein. Es ist eine großartige Möglichkeit für das Team, die Tools zu teilen, die ihnen helfen, ihr Gewicht zu übertreffen. Es ist also ein großer Schlag über unserem Gewicht und das kam aus der Inception Week. Ich denke also, dass die Inception Week mehr bietet als alles andere, und auch der Dev-Container ist ein echter Hingucker.

Dave Elkan:

Früher hatten wir so viele Probleme mit einzelnen Versionen dieses oder jenes auf jedem Computer, und jetzt ist das einfach alles weg, es passiert nie wieder, es hat uns seitdem nie wieder getroffen, und ich denke, es ist ein überwältigender Erfolg. Sicher, es braucht einen brandneuen RAM und eine ganz neue CPU, aber das tut es... wir werden es schaffen, als würde es besser werden.

Nick Muldoon:

RAM und CPU sind billig, es ist okay.

Dave Elkan:

Du kannst die Zeit nie zurückbekommen, oder?

Nick Muldoon:

Ja, absolut. Ja, wenn wir über diese Dinge nachdenken, wie bewusst waren wir Ihrer Meinung nach in Bezug auf die Werte in unserem Ansatz beim Aufbau und der Skalierung eines Unternehmens im Vergleich zu Dingen, die einfach passiert sind?

Dave Elkan:

Während eines großen Teils der Unternehmensgründung gab es eine Menge Mentalitätskram: „Mach es einfach“, was passieren muss. Ich möchte jedoch zu der Zeit zurückkehren, als wir angefangen haben, alles war Chaos. Ich erinnere mich daran, Anfang 2018, Mitte 2018, wir kamen am Montag rein und fragten uns: „Was machen wir heute? Was ist diese Woche? Schauen wir uns den Backlog an und schauen wir uns das an.“ Und es gab keinerlei Voraussicht.

Nick Muldoon:

Und wir haben ein paar Dinge aus dem Backlog gestrichen und an diesem Wochenende einfach abgearbeitet. Das war es, richtig?

Dave Elkan:

Ja, so ziemlich. Ja, also hast du die Idee vorgeschlagen, es war Anfang des Jahres, es muss 2018 gewesen sein. War es 2019? Wie dem auch sei, lassen Sie uns einfach eine Woche lang Klarheit schaffen, was im Wesentlichen unser interner CI-Raum ist, und einfach eine Reihe von Produkten und Problemen aus dem Weg räumen. Das war das erste Mal, dass wir angefangen haben, uns wirklich zu konzentrieren, denn da wir so viele Produkte hatten, denke ich, dass wir sie zu diesem Zeitpunkt tatsächlich verkauft haben könnten. Ja, ich glaube, das hatten wir auf jeden Fall. Aber [Crosstalk 00:27:28] -

Nick Muldoon:

Aber wir hatten immer noch Roadmaps, Story Maps, Clarity Week, EACS, als ob wir andere interne Systeme hatten, die wir verwendeten, und das Team wuchs tatsächlich über Dave und mich hinaus, und es wuchs. Da waren Jared, Satvik und Rob, und so wuchs auch das Team zu diesem Zeitpunkt. Es gab uns also die Möglichkeit, eine Reihe von Leuten für einen bestimmten Zeitraum, etwa eine Woche, mit einem Problem zu befassen.

Dave Elkan:

Stimmt, und daraus entstand die Idee des Fokus, und wir fingen an, fokussierte Sprints zu machen, also Produktfokus-Sprints, bei denen ein weiteres schreckliches Problem des Überfahrens hervorgehoben wurde. Wenn Sie Ihre Schätzungen überfahren haben, dann müssten Sie in neun Wochen oder so zurückkommen und es war einfach [diabolisch 00:28:12].

Nick Muldoon:

Das ist richtig.

Dave Elkan:

Also haben wir [Crosstalk 00:28:14] fallen lassen -

Nick Muldoon:

Was haben wir gemacht? Wir haben zwei Wochen mit Story Maps gearbeitet, zwei Wochen mit Roadmaps, zwei Wochen mit internen Systemen, zwei Wochen mit irgendwas und dann eine Woche mit Inception Week?

Dave Elkan:

Anfangswoche. Ja, ich denke [Crosstalk 00:28:26] -

Nick Muldoon:

Ich kann mich jetzt nicht einmal mehr erinnern, was das andere Ding war.

Dave Elkan:

Insgesamt waren es neun Wochen, nicht wahr?

Nick Muldoon:

Ja.

Dave Elkan:

[Crosstalk 00:28:31] Straßenkarten-

Nick Muldoon:

Wenn Sie es verpasst und nicht versendet haben, sind wir zum nächsten Produkt übergegangen und haben es weiterentwickelt, und dann kamen wir darauf zurück.

Dave Elkan:

In Ewigkeiten entfernt. Und es war super stressig für das Team und das haben wir schnell zunichte gemacht, in der Woche, in der wir flexibler an die Sache herangegangen sind, wo wir das harte Mandat fallen ließen, dass du jetzt Produkte austauschen musst, wir haben sie ein bisschen übergehen lassen und dann haben wir die Storypoints auf die nächsten angepasst, bla, bla, bla. Und dann kratze ich irgendwann an meinem Gedächtnis, aber im Grunde sind wir an einem Punkt angelangt, an dem wir Möglichkeiten eingeführt haben, die lose auf Shape Up von Basecamp basierten, und wir haben eine Menge Dinge daraus übernommen, aber die meisten davon passten nicht wirklich zu unserer Arbeitsweise und unseren Werten.

Nick Muldoon:

Ich meine, dieser ganze Opportunitätszyklus, wir haben uns jetzt drei- oder viermal weiterentwickelt.

Dave Elkan:

Und im Idealfall waren es nur zwei oder vier Wochen Arbeit, und dann machten wir die Inception Week und die Tech Debt Week, und wir haben eine spezielle Tech Debt Week als Mandat. Das haben wir seitdem fallen lassen, und jetzt haben wir vier Wochen Arbeit, einschließlich Tech Debt, und dann haben wir die Inception Week, und das ist irgendwie cool, oder? Als ob wir immer noch das Mandat der Inception Week haben, nicht der Tech Debt Week. Das ist das Letzte; ich denke, die Mandate... weil es wie ein Kickstart für dein Motorrad ist, du musst wirklich einen guten Kick geben und das ist im Grunde das, was wir in den letzten drei Jahren versucht haben, ist, dieses Ding zum Laufen zu bringen. Ich glaube, wir haben...

Nick Muldoon:

Aufgebauter Schwung.

Dave Elkan:

Der Motor läuft jetzt... ja. Der Motor läuft jetzt und wir ziehen die Kupplung heraus. Es ist nur so, dass die Mandate langsam wegfallen und das Team seinen eigenen Weg findet, aber ich habe immer noch das Gefühl, dass dieser Zyklus das Wichtigste ist, dass fünf Wochen, in denen wir aufhören, jeder weiß, was passiert. Denn wenn es einfach für immer in die Zukunft hinausläuft, kannst du das nicht in deinem Kopf berechnen, aber du kannst fünf Wochen vorausschauen und sagen: „Ich werde diese Arbeit planen, sie wird nicht bis zu einem N-ten Grad erledigt werden, weil das irgendwie komisch ist“, es ist einfach so: „Lass uns versuchen, das zu erreichen und lass uns ein Stück nach dem anderen abbeißen.“ Dann machen wir eine Pause mit der Inception Week, lassen unserer Kreativität freien Lauf und dann kommen wir in der nächsten Runde darauf zurück.

Nick Muldoon:

Richtig, also muss ich hier Timeout anrufen. Also das ist eine Seitenleiste für alle, die zu Hause zuhören; Dave hat gerade diese Analogie benutzt, wie man das Motorrad anwirft und dann die Kupplung herauszieht. Eines der Dinge, die Dave unglaublich gut kann, ist, dass er sich diese Analogien schnappt und diese Analogien verwendet, um Konzepte zu vereinfachen, die ich sonst für ziemlich komplex halte, und sie zu vereinfachen und wirklich gut zu kommunizieren. Das habe ich noch nie gehört, aber es gibt ein neues, das wir dem Repertoire hinzufügen können, Dave. Ich liebe es.

Dave Elkan:

Danke, Kumpel.

Nick Muldoon:

Was für andere Dinge? Weil ich schätze, wir planen diese Reise über fünfeinhalb Jahre, von Dave und Nick und der Hinzunahme von Satvik und Teagan und Jared und Rob und Brad und ein paar Leute im Laufe der Zeit bis zu dem Punkt, an dem wir heute 27, 28 Leute sind. Was sind einige der anderen Wegmarken, die wir irgendwie durchgemacht haben, die unsere Arbeitsweise verändert oder weiterentwickelt haben? Wie das Easy Agile-Betriebssystem, über das wir in der Vergangenheit gesprochen haben.

Dave Elkan:

Nun, es ist etwas, das wir gerade in der Hinrichtungsebene besprochen haben. Offensichtlich explodiert alles alle sechs Monate und man muss es reparieren, als ob alle sechs Monate eine wichtige Sache passiert, und ich finde, das ist gut und gesund, und das läuft immer wieder auf diese Dinge hinaus. Entweder sind sie intern oder extern und ich habe das Gefühl, dass wir es gerade mit einer externen zu tun haben, auf die ich in diesem Podcast nicht wirklich eingehen möchte, aber ich denke, dass es für das Unternehmen gesund ist, sich an sie anzupassen. Aber sicher, ich denke, in dieser Zeit wirklich zu verstehen, dass es die Menschen sind, die zählen, oder?

Dave Elkan:

Das Geschäft ist da drin, als wäre es eine Sache, aber es ist nichts ohne die Leute, die dafür gearbeitet haben, und es dient den Leuten, die hier arbeiten, sowie den Kunden. Und das ist etwas, woraus wir hervorgegangen sind. Was denkst du, Nick? Wie die kulturellen Aspekte dessen, was wir gebaut haben, was fällt Ihnen auf?

Nick Muldoon:

Ich denke auf jeden Fall, dass es diese Wendepunkte gibt. Ich meine, ich erinnere mich an ein Gespräch mit Jared, als wir in der Crown Street Mall waren, und es war 2019 und wir haben mit dem Team am Küchentisch dort gesprochen, und wir konnten acht Leute an diesen Küchentisch bekommen und wir haben darüber gesprochen, das Team zu vergrößern, um die Gelegenheit zu nutzen und auf Kundenanfragen und all diese Dinge zu antworten. Ich glaube, Jared sagte: „Nun, ich mag es so, wie es ist.“

Nick Muldoon:

Und dann spalte ich zu einem Interview mit Jared vor, das in das fünfjährige Video eingeflossen ist, das wir kurz vor Weihnachten gesehen haben und in dem es um seinen Werdegang ging und wie er sich beruflich und persönlich zusammen mit dem Unternehmen weiterentwickelt und angepasst hat. Ich denke, das ist die Geschichte für uns alle als Teammitglieder, wir waren alle irgendwie zusammen auf einer Reise und wir lernen und passen uns alle zusammen an. Wir leben in vielerlei Hinsicht diesen agilen Ansatz, bei dem wir nachdenken und uns die Zeit nehmen und nachdenken und mit neuen Ansätzen experimentieren, um unsere Arbeit zu erledigen.

Nick Muldoon:

Ich glaube sogar... und wir haben in letzter Zeit darüber gesprochen, was Pace angeht, die erste Version unseres Lern- und Entwicklungsprogramms, in dem wir die Leute finanziell unterstützen wollten, damit sie etwas verfolgen können, worüber sie lernen wollten. Aber wir haben das rausgebracht: „Hey, das war Arbeit für einen Morgen“, wir haben ein L&D herausgebracht, die Leute haben angefangen, das L&D-Programm zu benutzen, und wir nannten es unsere erste Version unseres L&D-Programms, und heute sind wir bei Version, ich weiß nicht, 1.4 oder was auch immer es ist, unseres L&D-Programms. Es gibt viele Dinge, die herausgekommen sind und wir optimieren und verbessern sie im Laufe der Zeit, um sie immer besser und besser an den aktuellen Spielstand innerhalb des Teams anzupassen. Ist das fair?

Dave Elkan:

Ja, ist es. Ja, und ich glaube das; A, ich habe noch nie in einem Unternehmen gearbeitet, das so etwas hat und wo man aktiv dazu ermutigt wird, es zu nutzen, das Geld auszugeben und sich selbst zu verbessern. Wenn Sie sich selbst verbessern, wird das Team besser, wenn das Team besser wird, die Kunden bessere Ergebnisse erzielen und das Unternehmen sich weiter verbessert, und es wird wahrscheinlich ein besserer Ort für Sie sein, um in Zukunft zu arbeiten. Es ist also wirklich eine ganzheitliche Perspektive und nicht engstirnig, sondern kurzsichtig oder konzentriert sich nur auf den Output. Es geht um Output-Ergebnisse und ich denke, das könnte ein weiterer unserer Werte sein. Wenn wir sieben hätten, wären es Ergebnisse über Output. Also wirklich aufzuhören, die Erlaubnis zu haben, innezuhalten und nachzudenken und sich darauf einzustellen und darüber nachzudenken, was Sie erreichen wollen, anstatt einfach blindlings Dinge zu tun.

Dave Elkan:

Aus der Sicht eines Entwicklers ist der schnellste Code also der Code, der nicht existiert. Wenn Sie also etwas anders machen können, was nicht 100 Schritte erfordert, oder einfach entscheiden: „Hey, das ist gerade wirklich schwierig, dieser Teil des Codes, an dem wir arbeiten, oder diese Funktion ist wirklich schwierig. Können wir das Feature einfach löschen?“ Und wir haben es sofort gemacht, ich weiß, das klingt ziemlich gewagt, aber ganz ehrlich, diese Art von Diskussion ist wirklich gesund. Ich möchte das Team ermutigen, so zu denken, und ich denke, dass Lernentwicklung auch etwas ist, was man tun kann, um die Leute dazu zu bringen, ihren Werdegang zu betrachten, um ihre Fähigkeiten zu messen und ihnen zu geben, in dieser Hinsicht wirklich... Öl ins Feuer zu gießen und zu sehen, wie sie ihre Fähigkeiten verbessern und ihren Mitmenschen helfen.

Nick Muldoon:

Ja, also führen Sie uns das durch, denn das ist etwas, worüber wir definitiv ein paar Mal gesprochen haben, zum Beispiel, als wir uns Kandidaten angesehen haben und in einem Einstellungsgedränge um Kandidaten über diejenigen gesprochen haben, die sich auf einem bestimmten Weg befinden und von denen wir glauben, dass wir diesen Weg beschleunigen können. Woher kam das?

Dave Elkan:

Woher kommen Gedanken? Ich bin mir nicht sicher, das ist eine gute Frage. Ich könnte es dir nicht sagen, aber ich denke, es ist ziemlich offensichtlich, wenn du dir den Lebenslauf von jemandem ansiehst und du siehst... nun, es ist nichts falsch an Leuten, die lange angestellt sind, aber wenn du mit jemandem sprichst und er nicht wirklich sagen kann, was er in den letzten 10 Jahren gemacht hat und er hat diese eine Position 10 Jahre lang besetzt und er hat nichts wirklich Auffallendes, er kann darüber erzählen, wie er das verbessert hat, das sagt irgendwie viel über diese Person. Vielleicht würden sie reinkommen und einfach an die Küste fahren... sie sind eine Achterbahn, oder? Wenn sie an der Küste fahren, ist das in Ordnung, es ist ihre Entscheidung, aber gleichzeitig suchen wir nach Menschen, die aktiv versuchen, ihre Wirkung durch ihre Arbeit zu vergrößern und ihren Mitmenschen zu helfen. Und das kannst du sehen, du kannst sehen: „Oh, schau. Sie waren in derselben Firma, das ist in Ordnung, aber sie haben diese verschiedenen Rollen übernommen oder sie haben diese Art von Verbesserung in ihrem Ansatz gesehen.“

Nick Muldoon:

Das geht auf diesen Artikel zurück, diesen Financial Review-Artikel, die Rente in der Mitte der Karriere. Das war also ein Artikel, den wir 2016, 2017 veröffentlicht haben müssen, und es ging um eine japanische Bezeichnung, die Rente während der Karriere. Du könntest 20 Jahre Erfahrung in einer Rolle haben oder du könntest 20 erste Jahre Erfahrung haben, und ich denke, schon früh, und vielleicht passiert es heutzutage immer noch, ich denke, das tut es wahrscheinlich, aber es fühlte sich an, als hätten wir 20 Viertel Erfahrung gesammelt. In diesen fünf Jahren gab es immer eine große, neue Herausforderung, die wir in den ersten fünf Jahren lernen und anpassen und in das Unternehmen integrieren mussten. Wir haben also ständig gelernt und uns angepasst, und wir wollten Leute, die sich auf einer ähnlichen Reise befinden und lernen und sich integrieren, sich anpassen und experimentieren.

Dave Elkan:

Ja, das ist definitiv etwas, das man lernen kann, und ich denke, wenn man neue Stars hervorbringt, können sie das einfach bekommen, das tun sie standardmäßig, weil man sie in diese Umgebung gebracht hat. Aber einige Umgebungen, insbesondere ältere Unternehmen, können ziemlich stagnieren und statisch sein, sodass sich das nur in den Lebensläufen der Menschen widerspiegelt. Entweder gibt es irgendeinen Grund, warum das Unternehmen sie nicht befördert oder ihnen die Möglichkeit gibt, ihnen zu folgen, weil wir einen anderen Ansatz verfolgen, bei dem wir den Leuten zu viele Möglichkeiten bieten, glaube ich manchmal, und ich habe gesehen, dass Leute ihre L&D so oft nutzen, dass es sich tatsächlich auf ihren besseren Gleichgewichtswert auswirkt. Ich sage: „Wow, das ist fantastisch, aber vergiss nicht, dass du Kinder hast und helfen musst, auf sie aufzupassen“ und [Crosstalk 00:39:41] -

Nick Muldoon:

Mildere deinen Enthusiasmus, ja.

Dave Elkan:

Ja. Also das ist etwas, nach dem man Ausschau halten sollte.

Nick Muldoon:

Halten Sie inne und denken Sie über fünfeinhalb Jahre nach. Was ist der Zweck des Unternehmens, was ist das Ziel für die nächsten paar Jahre?

Dave Elkan:

Hab Spaß, lerne, was ist mit dir?

Nick Muldoon:

Definitiv lernen.

Dave Elkan:

Bleib im Geschäft.

Nick Muldoon:

Oh, ja. Bleiben Sie im Geschäft, nachhaltiges Wachstum ist immer gut. Ich denke, das ist wichtig. Ja, ich weiß nicht, es ist interessant. Ich habe das Gefühl, an manchen Tagen kann es wirklich Spaß machen und an anderen Tagen macht es überhaupt keinen Spaß. Das liegt wahrscheinlich zum großen Teil daran, als wir damit angefangen haben, waren wir nur für uns selbst und füreinander da, und jetzt habe ich das Gefühl, dass wir in den Diensten eines Teams von Leuten stehen, die selbst für den Kunden da sind, weil wir ein paar Tausend von ihnen haben. Die Verantwortung und die Rechenschaftspflicht haben sich geändert, und die Art und Weise, wie Spaß entsteht, ist heutzutage... es hat Spaß gemacht, Lamingtons zu haben und zu chatten, und heutzutage organisiert normalerweise jemand anderes in der Crew das Event, der oft daran teilnimmt, dass ich mit dem Rest des Teams Spaß und Vergnügen finde, anstatt mir die Zeit nehmen zu können und das zu tun.

Nick Muldoon:

Ich erinnere mich, als wir ein paar Leute von iAccelerate angerufen haben und in die Stadt gefahren sind und in die Stadt gegangen sind und wir haben uns in der Stadt einen Laksa geholt und wir haben eine Schüssel Laksa bekommen. In den letzten 12 Monaten war es schwieriger, das zu tun, angesichts des globalen Umfelds und all dieser Dinge, also hoffen wir, dass wir 2022 ein bisschen mehr davon finden können.

Dave Elkan:

Und vielleicht Ramen. Jetzt gibt es Ramen.

Nick Muldoon:

Oh, und es ist großartig, das weißt du.

Dave Elkan:

Ja. Ich denke, wenn wir das, was wir tun, verfeinern und weiter darüber nachdenken, speziell mit den Ingenieuren, verwende ich gerne eine zielorientierte... Ziele sind bei Easy Agile groß, ich denke, Sie sollten ein bisschen über Ziele sprechen, aber wir verwenden sie, um Menschen dabei zu helfen, Dinge zu verfolgen, die sie erreichen wollen, und wir können diese Dinge bis zu einem gewissen Grad an dem ausrichten, was das Unternehmen tut. Dann können Sie tatsächlich gehen und Ihre beruflichen Ziele durch das Unternehmen erreichen, und das Unternehmen ist das Mittel, um dies zu tun, anstatt es draußen tun zu müssen. Das ist wirklich cool, diese Harmonie zu finden, damit sowohl Easy Agile erfolgreich sein kann als auch die Leute, die hier arbeiten, erfolgreich sein können.

Dave Elkan:

Ich denke, es ist tatsächlich ziemlich schwierig, wenn Sie sagen: „Hey, treten Sie einen Schritt zurück, denken Sie darüber nach, was Sie erreichen möchten, geben Sie mir das, und dann werde ich sehen, was ich tun kann, um den Geschäftsverlauf zu ändern und Ihnen dabei zu helfen, das zu erreichen. Was können wir tun? Vielleicht gibt es einen Mittelweg, den wir gemeinsam verfolgen können.“ Und das ist etwas Neues für mich und ich verwende es quasi anstelle von Leistungsbeurteilungen, also stellt sicher, dass ihr eure Ziele erreicht, Leute. [Crosstalk 00:42:44]

Dave Elkan:

Aber ja, du hast auch dafür gesorgt, dass du in der Zeit zurückblicken und dich selbst in der Zukunft sehen willst, um mit dem Team nachzudenken. Wenn sie gegangen sind und weitergemacht haben, [Crosstalk 00:42:56] -

Nick Muldoon:

Oh, ja. Absolut. Ich habe diese Woche sogar mit Elizabeth Cranston gechattet und gesagt: „Ich kann mir vorstellen, dass du in der Zukunft unten in Narooma an der Küste lebst und ich kann runterkommen und mit den Familien Käse und Biccies essen und du schaust über die Bucht auf Narooma oder so, und wir erinnern uns an diese Zeit bei Easy Agile.“ Das kann ich mir absolut vorstellen. Ja, ich finde es großartig und ich denke, nur was die Ziele angeht, die Ziele sind persönlich wichtig, und wir haben in der Vergangenheit viel über Ziele gesprochen, in Bezug auf die langfristige Vision für die Familien und solche Dinge.

Nick Muldoon:

Aber es ist auch für das Unternehmen, ich erinnere mich, dass wir gute Stunden hatten, als wir das Unternehmen auf die Beine gestellt hatten, wir haben sie jedes Jahr überarbeitet, wir haben in den letzten Jahren viel gelernt und uns daran angepasst, wie wir über unsere Ziele und unsere wichtigsten Ergebnisse denken. Und die Tatsache, dass wir sie vierteljährlich verfassen und sie vierteljährlich überprüfen, aber wir haben diese Ziele, die mit einem Geschäftsziel übereinstimmen, das in drei Jahren liegt und das alles irgendwie abläuft. Ich meine, ich denke, wir sind viel reifer in Bezug auf diesen Aspekt unserer... Ich weiß nicht, würde ich strategische Planung sagen? Vision, Zielsetzung über einen längeren Zeitraum? In dieser Hinsicht sind wir heute viel reifer als vor zwei oder drei Jahren. Das ist auch wirklich aufregend. [Crosstalk 00:44:33]

Nick Muldoon:

Kommen Sie zurück zu dem, was Sie zuvor über den Backlog gesagt haben. Wir kamen an einem Montagmorgen rein und fragten uns: „Woran werden wir diese Woche arbeiten?“ Und wir haben über ein paar Jahre gearbeitet, wir haben es so ausgearbeitet, dass „Ah, hier ist die Vision für das Produkt.“ Es war eine längerfristige Sache, und wir haben das erhöht und es heißt nicht: „Hey, was machen wir diesen Monat für das Unternehmen?“ Es heißt jetzt: „Hier ist unsere langfristige Entwicklung für das Unternehmen.“ Wir haben das angehoben, das ist ziemlich aufregend, finde ich.

Dave Elkan:

Und gleichzeitig versuchen wir, das Team dazu zu bringen, auch ihre Sichtlinie zu erhöhen.

Nick Muldoon:

mm-hmm (bejahend), mm-hmm (bejahend).

Dave Elkan:

Und schauen Sie weiter weg, aber nicht zu weit. Sie möchten, dass sie sich ansehen, was nächste Woche und auch nächsten Monat passiert, aber auch, was das Ziel ist, was verfolgen wir? Was ist das Gesamtbild? Und ich glaube, das fängt an zu passieren.

Nick Muldoon:

Was ist die Analogie zum Thema Golf, Dave?

Dave Elkan:

Oh. Nein, kannst du es mir sagen? Ich kann mich nicht erinnern.

Nick Muldoon:

Es war diese Analogie zum Golf, also du musst schauen, wo du den Ball schlagen wirst und du musst nach oben schauen. Du willst nicht auf den Abschlag schauen, du willst hinter den Abschlag schauen, damit du... nicht hinter den Abschlag, hinter das Loch, tut mir leid. Du willst hinter das Loch schauen.

Dave Elkan:

Das war nicht meine Analogie, deshalb kann ich mich nicht erinnern, aber ich erinnere mich, dass uns jemand das erzählt hat. Aber es ist gut, als ob es nicht einmal eine Analogie wäre, ist das nicht die wörtliche Sache, die der Golflehrer tun würde? Es ist wie: „Wo schaust du hin?“ Und dann sagen sie: „Oh, ich schaue mir das Loch an.“ „Nein, nein, du musst weiter als das Loch schauen. Schau nach oben, wo der Ball hingehen soll, und dann geht er weg.“

Nick Muldoon:

Ja, erhebe dein Visier.

Dave Elkan:

Erhöhen Sie Ihre Sicht, ja. Und wenn du auf deine Füße schaust, wirst du wahrscheinlich nicht weit kommen, aber wenn du nach oben schaust und Bilanz ziehst, kannst du wahrscheinlich... das ist eigentlich eine Fußball-Analogie, die ich dir geben kann, wie von meinem Fußballtrainer, als ob du mit dem Zeh zeigen musst, wohin der Ball gehen soll. Und das ist einfach das Magische, es funktioniert einfach. Du stellst einfach deinen Fuß neben den Ball und zeigst auf die Ecke des Tores, du willst, dass er reingeht und du trittst ihn, und dann passiert es einfach.

Dave Elkan:

Es gibt solche lustigen kleinen Hacks und ich denke, das ist eine Sache mit langfristiger Vision. Wenn Sie ein Unternehmen führen, das diese langfristige Vision und dieses Ziel nicht verfolgt, dann können Sie tatsächlich in mehrere Richtungen gleichzeitig gehen, und Sie werden keine Fortschritte machen. Ich denke, eine gute Analogie, die ich gelesen habe, war wie bei einem Team, wenn man sich vorstellt, dass alle Teammitglieder mit einem Gummiband an einer Stange festgebunden sind und sie alle in verschiedene Richtungen gehen, die Stange wird sich nicht bewegen, weil alle einfach... und das Unternehmen wird statisch und still bleiben. Aber wenn alle einfach in die gleiche Richtung gehen, dann wird es weitergehen.

Nick Muldoon:

Verschiebe es, ja.

Dave Elkan:

Ja. Und das ist etwas, das wir in letzter Zeit abgebissen haben, ist unser Ziel.

Nick Muldoon:

MM-HMM (bejahend), um Teams dabei zu helfen, agil zu sein.

Dave Elkan:

Ja. Das ist einer dieser lustigen Momente, in denen wir darüber reden, und wir haben darüber gesprochen, wir haben uns eine Frist gesetzt, um ein besseres Wort zu sagen, als ob unsere Planungssitzung in ein paar Wochen ansteht, also haben wir uns hingesetzt und darüber gesprochen. Und wir haben uns im Kreis gedreht und versucht herauszufinden, was es heißt, nicht agil zu sein, sondern einfach, was Agile ist? Und wir wissen [unverständlich 00:47:45], aber wir haben versucht, das in Worten zu kodifizieren. Und als du das sagtest, als ob es agil ist, war das irgendwie so... so wie ich es gerne beschreibe, ein umgedrehter A-Moment, was unser Logo ist, wie du es auf Nicks Jacke dort sehen kannst.

Dave Elkan:

Als mir das vorgeschlagen wurde, sagte ich: „Nein, das ist so albern.“ Aber ich sagte: „Oh, aber ich liebe es.“ Und ich sage nicht, dass es albern ist, agil zu sein, aber die Tatsache, dass es so einfach ist, das gefällt mir daran, es ist einfach, es ist einfach, und es gibt eine Menge davon, wenn man sich darauf einlässt.

Nick Muldoon:

Mm-hmm (bejahend). Ja. Ja, warum packen wir es nicht dort ein? Ich denke, das ist ein guter Ort, um zu enden.

Dave Elkan:

Ja.

Nick Muldoon:

Unser Ziel ist es, Teams dabei zu helfen, agil zu sein, und das tun wir für uns selbst, wir versuchen ständig zu lernen und uns anzupassen und mit neuen Dingen zu experimentieren, da wir Easy Agile sind und als unsere Teammitglieder hier sind. Ich hoffe, das war ein nützlicher kleiner Leckerbissen und eine Reise von Dave und mir darüber, wie wir Easy Agile zu diesem Punkt gebracht haben, und über einige der Dinge, die uns beschäftigt haben.

Dave Elkan:

Ja.

Nick Muldoon:

Danke, Dave.

Dave Elkan:

Danke, Nick. Das hat Spaß gemacht.

Nick Muldoon:

Das hat Spaß gemacht. Oh, gut.

‍

‍

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.

„Es war toll, mit Caitlin über die Bedeutung der Team-Retrospektive für die Zusammenstellung eines leistungsstarken, funktionsübergreifenden Teams zu chatten“ — Chloe Hall

In dieser Folge wurde ich von Caitlin Mackie, Content Marketing Coordinator bei Easy Agile, begleitet.

In dieser Episode haben wir darüber gesprochen;

• Wir betrachten die Team-Retrospektive als Instrument zur Risikominderung und nicht nur als eine weitere agile Zeremonie
• Die Wichtigkeit, die Retrospektive in regelmäßigen Abständen durchzuführen
• Warum solltest du die Siege feiern?
• Übernehmen Sie die Aktionspunkte aus Ihrem Team im Rückblick auf Ihre Team-Sprintplanung
• Timeboxing — Die Retrospektive
• Schaffen Sie eine psychologisch sichere Umgebung für Ihre Team-Retrospektive

Ich hoffe, euch gefällt die heutige Folge genauso gut, wie ich sie aufgenommen habe.

Transkript

Chloé Hall:

Hallo zusammen. Willkommen zum Easy Agile Podcast. Ich bin Chloe, Marketingkoordinatorin bei Easy Agile, und ich werde Ihre Moderatorin für die heutige Folge sein. Bevor wir beginnen, möchten wir den traditionellen Hütern des Landes, von dem aus ich heute aufnehme, unsere Anerkennung aussprechen, dem Volk der Wodi Wodi aus der Dharawal sprechenden Nation, und den Ältesten aus Vergangenheit, Gegenwart und Entwicklung unseren Respekt erweisen. Den gleichen Respekt zollen wir allen Aborigines und den Bewohnern der Strait Islander, die heute zuhören. Heute haben wir also eine etwas andere Episode für Sie. Ich werde mit Caitlin Mackie, der eigenen Content-Marketing-Koordinatorin von Easy Agile, sprechen. Caitlin ist die Product Owner* unseres Marken- und Konversions-Teams*. Jetzt ist dieses Team ein funktionsübergreifendes Team, das erst seit etwa sechs Monaten zusammen ist. Und in den ersten Monaten hatten sie als Team, wohlgemerkt, auch zwei brandneue Mitarbeiter, sie arbeiteten an einem Rebranding des Unternehmens.

Chloé Hall:

Ein neues Team, eine riesige Aufgabe, die Möglichkeit, dass das Team Höchstleistungen erbringt, war zu diesem Zeitpunkt unwahrscheinlich. Das Team war also zu neu, um dieses Vertrauen, die starken Beziehungen und die psychologische Sicherheit bereits aufgebaut zu haben, aber irgendwie kamen sie zusammen und schafften es, zusammenzuarbeiten, einen Fluss kontinuierlicher Verbesserungen zu schaffen und dieses Rebranding zu veröffentlichen. Deshalb habe ich heute Caitlin in den Podcast aufgenommen, um das Erfolgsgeheimnis des Teams zu besprechen. Willkommen zum Podcast, Caitlin.

Caitlin Mackie:

Danke, Chloe. Es ist etwas anders, auf dieser Seite zu sitzen. Ich bin es gewohnt, in deinen Schuhen zu stehen. Ich fühle mich [unhörbar 00:01:45]. Ich fühle mich unwohl. [unhörbar 00:01:46].

Chloé Hall:

Ja. Es ist auch mein erstes Mal, dass ich Gastgeber bin, sehr seltsam. Ist es nicht? Wie fühlst du dich heute?

Caitlin Mackie:

Ja. Gut. Ich freue mich. Ich freue mich darauf, über unsere Erfahrungen als funktionsübergreifendes Agile-Team zu sprechen und hoffentlich einige der Dinge, die für uns funktioniert haben, mit unseren Zuhörern zu teilen.

Chloé Hall:

Ja, ich weiß es selbst und ich bin mir sicher, dass unser Publikum sehr gespannt ist, was das Erfolgsgeheimnis Ihres Teams war. Wolltest du uns zunächst sagen, was dieses große Geheimnis war, das dir wirklich geholfen hat, als Team zusammenzuarbeiten?

Caitlin Mackie:

Das ist eine gute Frage, Chloe. Und das ist eine große Frage. Ich bin mir nicht sicher, ob es eine wichtige Sache gibt, ich nehme an, es ist diese ultimative geheime Quelle oder die eine Sache, die zum Erfolg geführt hat. Ich bin mir sicher, dass wir alle hören wollen, was das ist. Ich würde auch gerne wissen, ob es nur diese eine wichtige Zutat gibt, aber ich denke, etwas für uns, und wahrscheinlich eines der denkwürdigsten Dinge, die für uns wirklich funktioniert haben und von dem wir viel profitieren konnten, war, unsere Retrospektiven zu machen. Das ist wahrscheinlich das Erste, was mir in den Sinn kommt, wenn es darum geht, was zu unserem Erfolg geführt hat.

Chloé Hall:

In Ordnung. Ja. Warum hast du am Anfang mit den Retrospektiven angefangen?

Caitlin Mackie:

Wir waren also ein neu formiertes Team, wie Sie bereits erwähnt haben, und wir haben Retrospektiven als eine weitere Agile-Zeremonie gesehen, und wir haben gesehen, wie andere Teams das gemacht haben und sie hatten viel Erfolg damit, also sind wir auf diesen Zug aufgesprungen. Und ich denke, wenn wir ein neues Team bilden, kommen so viele Dinge ins Spiel. Sie versuchen also, sich gegenseitig herauszufinden, wie wir alle gerne arbeiten und miteinander kommunizieren, all das. Und wir waren das erste Team, das sich dem Besitz und der Verbesserung unserer Website verschrieben hat. Und wir wussten auch, dass wir wahrscheinlich für die Gestaltung und Einführung eines Rebrandings verantwortlich sein würden.

Caitlin Mackie:

Wenn Sie also versuchen, all das zusammenzufügen und dann all diese Elemente berücksichtigen, wussten wir, dass wir etwas Zeit einplanen mussten, um schnell iterieren und herausfinden zu können, was funktioniert und was nicht. Und was wir verstanden haben, ist, dass Retrospektiven eine großartige Gelegenheit für das gesamte Team sind, um alle problematischen Probleme aufzudecken und eine offene Diskussion zu führen, um wirklich Verbesserungspotenzial zu identifizieren oder herauszufinden, was gut funktioniert, damit wir das auch weiterhin tun können. Ich denke, Rückblicke haben es uns ermöglicht zu verstehen, wo wir die größte Wirkung erzielen können und wie wir ein wirklich effektives, funktionsübergreifendes Agile-Team bilden können.

Chloé Hall:

Beeindruckend. Das ist schon so aufschlussreich. Ja, es hört sich so an, als ob Ihnen die Retrospektiven wirklich dabei geholfen haben, herauszufinden, wer Ihr Team ist, und ein gut funktionierendes, leistungsstarkes, funktionsübergreifendes Team zu werden. Also, wie oft hast du Retro gemacht? Hast du das in einem regelmäßigen Zyklus gemacht, oder war es nur: „Okay. Wir haben ein Problem. Es sind ein paar Blocker aufgetaucht, wir müssen einen Retro machen“?

Caitlin Mackie:

Ja. Ich glaube, anfangs waren Retros für uns so etwas wie: „Oh, wir haben jetzt ein paar Sprints gemacht. Wir sollten wahrscheinlich einen Retro machen und einfach darüber nachdenken, wie diese paar Sprints gelaufen sind.“ Es war irgendwie wie dieses Ding. Es war immer im Hinterkopf. Und wir wussten, dass wir es tun mussten, waren uns aber nicht wirklich sicher, was den Rhythmus und die Art und Weise angeht, wie wir das machen sollten. Jetzt machen wir Retros an einem Freitagmorgen, dem letzten Tag unseres wöchentlichen Sprints. Und danach beginnen wir mit der Sprint-Planung. Also auch nach der Biopause, also lass das Team alles verdauen, worüber wir in Rückblicken gesprochen haben. Und dann kommen wir zur Sprint-Planung mit all den Themen, die wir besprochen haben, und wir werden eine wirklich nette, frische Perspektive haben.

Chloé Hall:

Ja.

Caitlin Mackie:

Also, ich denke, das funktioniert wirklich gut für uns, weil alles zeitnah passiert. Wir hatten gerade eine Diskussion über die besten Dinge, die im Sprint passiert sind oder was wirklich gut funktioniert hat. Sie sollten also sicherstellen, dass Sie im Folgenden dasselbe Verhalten üben können, und umgekehrt, wenn es um die Verbesserungen geht, die Sie vornehmen möchten. Also, diese Liste der Aktionspunkte, die aus einer Retrospektive hervorgegangen sind, bietet einen wirklich netten Kontakt, Kontext, tut mir leid. Und Sie haben sie alle bei der Sprint-Planung im Hinterkopf.

Caitlin Mackie:

So könnte es beispielsweise im vorherigen Sprint vorkommen, dass Sie Ihre Storypoints unterschätzt haben oder dass Ihre User Stories nicht detailliert genug waren. Bei jeder Story oder Aufgabe, die Sie in den Sprint einbringen, stellen Sie dann die Frage: Sind alle mit dem Detaillierungsgrad zufrieden? Was fehlt uns? Oder wir haben nur auf diese oder zwei Geschichten hingewiesen, ist es wahrscheinlicher, dass es eine Fünf ist? Also, alles ist wirklich frisch in deinem Kopf, und ich denke definitiv, dass das hilft, Dynamik zu erzeugen. Wenn das gesamte Team daran arbeitet, herauszufinden, wie Sie mit jedem Sprint effektiver sein können.

Chloé Hall:

Das ist so toll, dass du Caitlin gerade angesprochen hast. Und ich finde es toll, wie man nach der Team-Retrospektive diese Aktionspunkte tatsächlich nehmen und in den Sprint übergehen und sie sofort umsetzen kann. Es ist wirklich gut. Ansonsten habe ich das Gefühl, wenn du die Sprint-Retrospektive am Freitag machst und sagst: „Okay, das sind unsere Aktionspunkte“, dann gehst du zur Sprintplanung für Montag und denkst nur an das Wochenende. Das [unhörbar 00:07:20]

Caitlin Mackie:

Ja, hundertprozentig. Ja. Sie sind für jeden ein superfrischeres Gemüt. Es funktioniert vielleicht nicht für jedes Team, aber wir finden, dass es für uns wirklich gut funktioniert, weil wir bei der Sprint-Planung sehr sorgfältig vorgehen.

Chloé Hall:

Ja. Und dann konnte ich mir vorstellen, wie man das Retro macht, wie es leicht im Laufe der Zeit gehen könnte, aber dann hat Ihr Team die Sprint-Planung danach geplant. Es ist also so, als ob du die Zeit nicht verlängern kannst. Wie haben Sie es geschafft, diese Retrospektive irgendwie in eine Zeitbox zu packen?

Caitlin Mackie:

Ja, das ist eine wirklich, wirklich gute Frage. Und es ist auch beabsichtigt, dass sie eng zusammen geplant sind. Wie bereits erwähnt, gibt die Diskussion, die Sie in den Retrospektiven geführt haben, einen schönen Impuls für die Sprint-Planung, aber das bedeutet, dass wir auf die Uhr schauen müssen. Und am Anfang kann das ziemlich umständlich sein, weil Sie sicherstellen wollen, dass sich jeder gehört fühlt und dass jeder die gleiche Gelegenheit hat, etwas beizutragen. Und ich denke, diese Verantwortung liegt beim Scrum Master oder beim Product Owner oder bei wem auch immer, der die Retrospektive moderiert, um darauf hinzuweisen und sicherzustellen, dass jeder die Chance hat, gehört zu werden. Natürlich lassen Sie die Leute die längere Geschichte erzählen oder fügen viel zusätzlichen Kontext hinzu, bevor Sie zur Sache kommen. Und dann wirst du andere haben, die viel direkter sein werden. Und letzterem bin ich sehr ähnlich. Mir fällt es schwer, auf den Punkt zu kommen, was nicht gut funktioniert, wenn man versucht, eine Retrospektive mit einem Timebox zu versehen, oder?

Chloé Hall:

Und ich kann das nachvollziehen, dieselbe Persönlichkeit.

Caitlin Mackie:

Ja. Also, ich denke, es kommt wirklich darauf an, die Erwartungen und Prioritäten von Anfang an zu kommunizieren. Mit unserem Team und mit jedem Team wirst du herausfinden wollen, wen du wirklich gut abschneiden und dich kontinuierlich verbessern kannst, um die Erwartungen zu übertreffen, besser zu werden und gemeinsam zu lernen und zu wachsen. Und ich denke, wenn ihr alle die gleiche Denkweise teilt, wenn ihr in die Retrospektive geht und anerkennt, dass das sicher ist

Raum für schwierige Gespräche. Und solange Sie mit Empathie kommunizieren, weiß das Team, dass es nie um etwas Persönliches geht und dass alles im besten Interesse des Teams ist. Und das hilft dann den weniger direkten Kommunikatoren wie mir, ihren Standpunkt prägnanter anzusprechen und zwingt sie wirklich dazu, ihren Kommunikationsstil überlegter und prägnanter zu gestalten.

Caitlin Mackie:

Und das ist wirklich wichtig, um diese Zeitbox einhalten zu können, denke ich. Und das erfordert Übung, denn es kommt darauf an, diese psychologische Sicherheit in Ihrem Team zu schaffen. Aber wenn das erst einmal da ist, ist es viel einfacher, zu rufen, wenn jemand eine windige Strecke hinunterfährt, und den Fokus wieder zu richten und irgendwie zu sagen: „Ich verstehe dich, was ist der Aktionspunkt?“ Und werde einfach viel bewusster.

Chloé Hall:

Beeindruckend. Ich konnte mir nicht vorstellen, wie schwer es sein würde, mit den Persönlichkeiten, die du und ich haben, zu versuchen, so direkt zu sein und all das flauschige Zeug loszuwerden. Ich meine, sieh dir an, was getan wurde, um ein so großartiges Team zu bilden, das wir haben. Also, Sie haben diesen Aspekt der psychologischen Sicherheit bereits erwähnt. Und wie denkst du, in einem neuen funktionsübergreifenden Team zu sein... Nur sechs Monate zusammen, Sie hatten diese neuen Mitarbeiter. Glauben Sie, Sie waren jederzeit in der Lage, einen psychologischen Sicherheitsraum zu schaffen?

Caitlin Mackie:

Das ist eine weitere fantastische Frage. Und ich denke, ehrlich gesagt, wäre es am besten, eine Teamdiskussion darüber zu führen. Es wäre interessant, die Meinungen aller dazu zu hören, was zu diesem Element der psychologischen Sicherheit beiträgt und ob es allen genauso geht. Ich kann also nicht für das Team sprechen, aber meine persönliche Meinung zu dieser oder meiner persönlichen Erfahrung ist, dass die Schaffung eines Umfelds psychologischer Sicherheit wirklich von gegenseitigem Vertrauen und Respekt abhängt. Und am Ende des Tages verfolgen wir alle dasselbe Ziel. Wir alle respektieren also wirklich, wirklich, was der andere mitbringt, und verstehen, wie all diese beweglichen Teile, an denen wir individuell arbeiten, zusammenkommen, um das Ziel zu erreichen. Wenn wir also diese offenen Diskussionen im Rückblick führen oder nicht einmal in Retros, sondern einfach nur allgemein kommunizieren, ist klar, dass wir Fragen im besten Interesse des Teams stellen und individuelle Motive nie ins Spiel kommen, oder die Leute äußern ihre Meinung nicht einfach, wenn sie ungerechtfertigt ist, oder geben Feedback oder sind übermäßig kritisch, wenn sie nicht darum gebeten wurden.

Caitlin Mackie:

Keines dieser toxischen Verhaltensweisen passiert also, weil wir alle respektieren, dass unabhängig von der fraglichen Arbeit oder dem Diskussionsthema die Person, der diese Arbeit gehört, am Ende des Tages der Experte ist. Und wir vertrauen ihnen und zweifeln keine Sekunde lang aneinander. Und ich denke, die andere Hälfte davon ist, dass wir auch wirklich Glück haben, dass wir alle da sind, um uns gegenseitig abzuholen und weiterzumachen, wenn etwas nicht so läuft, wie wir es geplant hatten. Das passt also ganz gut dazu, dass einer unserer Werte bei Easy Agile darin besteht, sich als Team zu engagieren. Und hier geht es darum, anzuerkennen, dass wir wachsen und erfolgreich sind, wenn wir es gemeinsam tun, aufeinander aufzupassen und uns mit Authentizität und Mut zu engagieren. Manchmal mag ich voreingenommen sein, aber ich glaube von ganzem Herzen, dass unser Team das voll und ganz akzeptiert. Und es gibt einfach eine solche Bewunderung für das, was wir alle an den Tisch bringen, und ich denke, das ist wirklich der Schlüssel zur Schaffung der psychologischen Sicherheit.

Chloé Hall:

Ich finde es toll, dass Ihr Team unseren Wert wirklich annimmt, sich als Team engagiert und ihn umsetzt, denn genau darum geht es uns bei Easy Agile, und es ist einfach großartig, das auch zu sehen. Ich denke, die andere Sache

Ich wollte ansprechen war... Also nochmal, während dieses funktionsübergreifenden Teams, und du hast Design und Entwicklung, wie hat dir Retros deiner Meinung nach geholfen, herauszufinden, was Design und Entwicklung voneinander brauchen?

Caitlin Mackie:

Ganz gewiss. Also, für etwas mehr Kontext für unsere Zuhörer, also haben wir in unserem Team zwei Entwickler, Haley und David, und einen Designer, Matt und mich, der im Marketing tätig ist. Wir sind also quasi ein funktionsübergreifendes kleines Mini-Team. Wir haben also alle das gleiche Ziel und den gleichen Fokus, aber wir arbeiten auch alle an diesen kleinen Einzelkomponenten, die wir dann zusammenfügen. Also, ich denke... Wir machen regelmäßig Retros. Was wir feststellen konnten, war ein wirklich effektiver Design- und Entwicklungszyklus. Also haben wir einen Rhythmus für das gefunden, was wir an bestimmten Stellen gegenseitig brauchten. Wir haben zum Beispiel sehr früh herausgefunden, dass wir sicherstellen mussten, dass wir Design- und Entwicklungsarbeit nicht in denselben Sprint bringen. Wir brauchten eine vollständig fertige Designdatei, bevor die Entwickler mit der Arbeit daran beginnen konnten. Und das klingt vielleicht sehr offensichtlich, aber anfangs dachten wir: „Oh, nun, wenn du eine halbfertige Design-Datei hast, kann der Entwickler anfangen, daran zu arbeiten. Und wenn das erledigt ist, wird der Rest der Design-Datei fertig sein.“

Caitlin Mackie:

Was wir jedoch nicht eingestanden haben, ist, dass wir dadurch nicht genug Kapazität hatten, um zu iterieren oder Probleme zu lösen oder Feedback zum ersten Teil dieser Designdatei einzubeziehen, oder wenn der Entwickler angefangen hat, daran zu arbeiten und das Design dann gesagt wird: „Oh, dieser Teil hier, das ist nicht möglich“, sodass der Designer wieder am ersten Teil arbeitet. Und es schafft einfach eine Menge dieser Hindernisse. Im Rückblick kam das zur Sprache und wir konnten es ansprechen und verstehen, welches Design vom Entwickler benötigt wird und was der Entwickler vom Design braucht, um sicherzustellen, dass wir uns nicht gegenseitig blockieren. Und das Wichtigste an der Retro-Version ist, dass wir uns alle einig waren, dass eine Design-Datei komplett fertig sein muss, bevor der Entwickler mit der Arbeit beginnt.

Chloé Hall:

Ich finde es so toll, dass du diese Blocker schon früh identifizieren konntest. Glaubst du, dass es durch die wöchentliche Wiederholung dieser Blocker schnell zum Vorschein kommen konnte, oder glaubst du, das hätte keinen Unterschied gemacht?

Caitlin Mackie:

Nein, auf jeden Fall. Ich bin hundertprozentig der Meinung, dass Retros es uns ermöglicht haben, die Blockaden zeitnaher und effektiver anzugehen. Und das haben wir schon einmal angesprochen, aber ja, mit Retros kannst du die Blocker angehen, sie auspacken, verstehen, warum sie passieren und was wir tun müssen, um sicherzustellen, dass sie nicht wieder auftreten. Also, auf jeden Fall.

Chloé Hall:

Ja. Ja. Ich glaube, ich möchte jetzt ein bisschen über die Siege sprechen, den sehr aufregenden Teil des Retro, den Teil, den wir alle lieben. Also, wie wichtig sind deiner Meinung nach die Siege im Retro-Bereich?

Caitlin Mackie:

So wichtig. So, so, so wichtig. Also, wenn man als Team etwas Episches erreicht, muss man es herausfordern. Feiert alle Siege, ob groß oder klein. Manche Wochen werden besser sein als andere, aber genießen Sie die Mentalität, dass Glas halb voll ist. Und es gibt immer etwas, auf das man stolz sein und feiern kann, also rufen Sie es aus

einander, teile es mit dem ganzen Unternehmen, erkenne es öffentlich an. Ja, ich denke, es ist so wichtig, die Siege zu begrüßen. Es schafft einfach eine wirklich positive Atmosphäre, wenn man im Team ist. Jeder fühlt sich gehört und anerkannt für seinen wirklich positiven Beitrag, den er leistet. Und ich denke, eine große Sache hier ist auch, dass, wenn Sie als Team etwas Episches erreicht haben, es für andere Teams hilfreich ist, das auch zu hören, oder? Ihr habt einen coolen neuen Weg gefunden, etwas zu tun, teilt ihn. Wenn es dir als Team geholfen hat, wird es höchstwahrscheinlich einem anderen Team helfen.

Caitlin Mackie:

Ich denke also, dass das Feiern der Siege auch nicht nur der Arbeit vorbehalten ist, oder? Wenn jemand außerhalb der Arbeit etwas Tolles tut oder ein persönliches Ziel erreicht, dann stehen Sie dahinter.

Chloé Hall:

Ja.

Caitlin Mackie:

Um immer alle Siege zu feiern.

Chloé Hall:

Ja. Und ich finde es so gut, wie du erwähnt hast, dass es wichtig ist, auch die Siege im Privatleben eines Menschen zu feiern, denn am Ende des Tages sind wir alle Menschen. Ja, wir kommen zur Arbeit, aber wir haben dieses persönliche Element. Und zu wissen, wie jemand auch außerhalb der Arbeit ist, ist ein Element, um diesen psychologischen Sicherheitsraum und die Teambindung zu schaffen, die so wichtig sind, um am Ende des Tages ein gutes Team zu haben. Ja.

Caitlin Mackie:

Ja, hundertprozentig. Ja, damit hast du den Nagel in den Kopf getroffen. Ja, wir haben schon über psychologische Sicherheit gesprochen, und ich denke definitiv, das mit einzubeziehen, anzuerkennen, dass wir bei der Arbeit wir selbst sind, aber wir haben auch ein ganz anderes Leben außerhalb davon, also achten wir einfach darauf und feuern uns die ganze Zeit gegenseitig an. Das müssen wir tun, die größten Cheerleader des anderen sein.

Chloé Hall:

Ja, genau. Das ist der wahre Schlüssel zum Erfolg. Ist es nicht?

Caitlin Mackie:

Ja, das ist es. Das ist der Schlüssel.

Chloé Hall:

Sie haben also als neues funktionsübergreifendes, leistungsstarkes Agile-Team wirklich gut gearbeitet. Wie denkst du... Wie sieht dein zukünftiger Prozess für Retros aus?

Caitlin Mackie:

Wir werden sie auf jeden Fall weiterhin wöchentlich machen. Es ist Teil des Agile-Manifests, aber wir wollen uns darauf konzentrieren, auf Veränderungen zu reagieren, und ich denke, Retros ermöglichen uns das wirklich. Es ist nützlich und wirklich wertvoll für

das Team. Und wenn Sie das Team auf Erfolgskurs bringen können, werden Sie die positiven Auswirkungen sehen, die sich auf das gesamte Unternehmen auswirken. Also ja, wir haben eine schöne Trittfrequenz und einen Rhythmus gefunden, der für uns funktioniert. Also, wenn es nicht kaputt ist, repariere es nicht.

Chloé Hall:

Ja.

Caitlin Mackie:

Sagen sie das? Ist das das Sprichwort?

Chloé Hall:

Ich weiß nicht. Ich glaube schon, aber lass uns einfach weitermachen. [unhörbar 00:19:02], repariere es nicht.

Caitlin Mackie:

Da haben wir's. Ja.

Chloé Hall:

Du kannst Caitlin Mackie dazu zitieren.

Caitlin Mackie:

Zitiere mich dazu.

Chloé Hall:

Okay, Caitlin. Okay, es gibt nur noch eine letzte Sache, die ich heute ansprechen möchte. Ich dachte, Ende des Podcasts, lass uns einfach ein bisschen Spaß haben und wir werden einen kleinen Ausschnitt von Caitlins heißem Tipp machen. Also, für das Publikum, das zuhört, möchte ich, dass du dir etwas ausdenkst, das sie aus dieser Folge mitnehmen können, einen Action-Punkt, mit dem sie heute in ihren Teams beginnen können. Nimm es weg.

Caitlin Mackie:

In Ordnung. Okay. Alles klar. Ich würde sagen, mach immer die Retrospektive. Überspringe es nicht. Auch wenn es nur wenige Punkte zu besprechen gibt, werden immer neue Dinge auftauchen. Und Sie müssen dem Team regelmäßig Möglichkeiten bieten, seine Gedanken auszutauschen. Und ich überlasse es Ihnen: Fördern Sie stets einen positiven Dialog und zeigen Sie Wert und Wertschätzung für Teamideen und füreinander. Das ist mein...

Chloé Hall:

Ich liebe das.

Caitlin Mackie:

Das ist mein heißer Tipp.

Chloé Hall:

Danke, Caitlin. Danke fürs Teilen. Mir gefällt wirklich, wie Sie gesagt haben, fördern Sie immer einen positiven Dialog. Ich finde das so toll. Ja. Ja, danke, Caitlin. Danke, dass du heute auf den Podcast gekommen bist und...

Caitlin Mackie:

Danke, Chloe.

Chloé Hall:

Ja. Teilen Sie die Erfahrungen Ihres Teams mit Rückblicken und einem neuen funktionsübergreifenden Team. Es war wirklich nett, von Ihnen zu hören, und es gibt so viel, was unser Publikum von dem, was Sie heute mit uns geteilt haben, mitnehmen kann. Und ich hoffe, dass wir wirklich alle Zuhörer dazu inspiriert haben, rauszugehen und die Team-Retrospektive regelmäßig durchzuführen. Also, ja, danke.

Caitlin Mackie:

Vielen Dank, Chloe. Danke, dass du mich eingeladen hast. Es hat Spaß gemacht, Spaß, auf dieser Seite zu sein. Und ich hoffe, jeder genießt diese Episode.

Chloé Hall:

Danke, Caitlin.

Caitlin Mackie:

Danke. Tschüss.