Easy Agile Podcast Folge 27 Inklusive Führung
„Es war mir eine Freude, mit Ray darüber zu sprechen, Teams zu stärken und Menschen zu helfen, ihr volles Potenzial auszuschöpfen“ - Mat Lawrence
Mat Lawrence, Chief Operating Officer bei Easy Agile, wird von Ray Arell unterstützt. Ray arbeitet derzeit als Direktor für Agile Transformations bei Dell Technologies, ist der Moderator des ACN-Podcasts und Vorsitzender des Verwaltungsrates der gemeinnützigen Forest Grove Foundation Inc.
Ray hat eine Leidenschaft für kollaborative und integrative Führung und liebt es, andere zu inspirieren und zu motivieren, ihr volles Potenzial auszuschöpfen. Genau darauf tauchen Mat und Ray in dieser Episode ein.
Ray und Mat beschäftigen sich mit Konzepten wie inklusiver und situationsbezogener Führung und dem Zusammenhang mit agilen Arbeitsweisen, der Stärkung des organisatorischen Gehirns und der Förderung der Authentizität innerhalb von Teams.
Dies ist eine fantastische Episode für angehende, aufstrebende und bestehende Führungskräfte! Viele tolle Tipps und Ratschläge, die wir mit Kollegen und Freunden teilen können, um zu verstehen, wie wir uns gegenseitig stärken und befähigen können.
Wir wünschen euch viel Spaß mit der Folge!
Transkript:
Matthew Lawrence:
Hallo Leute, hier ist Mat Lawrence. Ich bin der COO bei Easy Agile und freue mich sehr, heute von Ray Arell begleitet zu werden. Bevor wir zu unserer Podcast-Folge übergehen, möchte Easy Agile den traditionellen Hütern des Landes, von dem aus wir heute senden, danken, den Menschen im Gadigalsprachigen Land. Wir erweisen den Ältesten in der Vergangenheit, Gegenwart und in der Zukunft unseren Respekt und zollen allen Ureinwohnern der Torres Strait Islander und den First Nations, die heute zu uns kommen, denselben Respekt aus. Ray, danke, dass du heute zu uns gekommen bist. Ray ist eine kollaborative und integrative Führungskraft, die es liebt, andere zu inspirieren und zu motivieren, ihr volles Potenzial auszuschöpfen. Ray verfügt über 30 Jahre Erfahrung im Aufbau und in der Leitung herausragender multinationaler Teams in Fortune-100-Unternehmen, gemeinnützigen Organisationen und Startups. Darüber hinaus ist er als führender Experte für groß angelegte agile Adoptionen, technische Verfahren sowie schlanke und komplexe adaptive Systeme anerkannt. Also Ray, willkommen, wirklich schön, dich heute im Podcast zu haben.
Ray Arell:
Ich danke dir.
Matthew Lawrence:
Ich liebe es, zunächst zu verstehen, was Ihnen an der Arbeit als integrativer Leiter und der Arbeit mit Teams am besten gefällt.
Ray Arell:
Ja, also ich bin wahrscheinlich seit etwa 15 Jahren in Führungspositionen tätig und leite Teams unterschiedlicher Größe. Wenn Sie die intimeren, kleineren Teams von vielleicht fünf oder sechs Personen haben, mehr als Teams, die aus mehreren hundert Personen bestehen, die in einer Organisation arbeiten, deren Leiter ich sein könnte. Und was mir daran am meisten Spaß macht, ist der Kontakt zu den talentierten Leuten, die die Arbeit machen. Ich meine, wenn man in die Führung geht, ist eines der Dinge, von denen man quasi abgeht, nicht die fachkundige Person im Raum zu sein, die programmiert oder Hardwareentwicklung oder etwas anderes macht. Sie haben diese Leute, die jetzt nach einer Richtung oder Vision oder anderen Dingen suchen, um ihnen einen Sinn zu geben, damit sie ihren Tag voranbringen können.
Und ich coache gerne. Ich genieße Mentoring. Ich meine, ein Großteil meiner technischen Seite ist heute mehr Nostalgie, als es bei den neuesten Technologien relevant ist. Es ist bereichernd, wenn man jemanden sieht, der, wenn man an Daniel Pinks Arbeit denkt, die von Autonomie, Meisterschaft und Zielstrebigkeit geprägt ist, plötzlich merkt, dass er sich mit dem Ziel beschäftigt, das wir als Organisation verfolgen, und dann die Autonomie hat, einfach seinen Tag zu verbringen und mit anderen zu arbeiten und zusammenzuarbeiten. Und das war schon immer aufregend für mich.
Matthew Lawrence:
Das kann ich nachvollziehen. Ja. Ich denke, in unserem heutigen Publikum werden wir eine Mischung aus aufstrebenden Führungskräften, aufstrebenden Führungskräften und erfahrenen Führungskräften haben. Ich würde gerne auf Ihre Erfahrung zurückgreifen und idealerweise ein wenig zu einem früheren Zeitpunkt Ihrer Karriere zurückspulen, als Sie in die Führungsrolle übergegangen sind. Und ich würde gerne wissen, was zu dieser Zeit einige der Erfolge waren, die Sie in Ihrem Ansatz gesehen haben und den Sie im Laufe der Jahre zu wiederholen versucht haben?
Ray Arell:
Nun, ich denke, schon früh, glaube ich, besonders wenn man in den technischen Rängen aufwächst und plötzlich zumindest in dem Unternehmen, in dem ich zu der Zeit war, eine sehr fachkundige Kultur, wenn Sie die klügste Person im Raum waren, sind das die Leute, die sie sich angesehen haben und gesagt haben: „Okay, wir werden Sie zum Leiter befördern, oder wir werden Sie zum Manager befördern oder Sie in die Führungspositionen befördern.“ Ich denke, wenn ich darauf zurückblicke, denke ich, Ray 2.0 oder Ray 3.0, egal welche Version ich zu der Zeit hatte, dass ich sehr stark von dieser fachkundigen Führungsposition geleitet wurde, was irgendwie bedeutet, dass ich weiß, was der beste Weg ist, um etwas zu liefern, und jeder sollte meinem technischen Beispiel folgen, wie auch immer dieses Produkt zusammenkommt.
Und ich glaube nicht, dass das wirklich ein guter Ansatz war. Ich denke, das hat die Leute eingeschränkt, weil man den Leuten letztendlich mehr oder weniger einfach gesagt hat, was sie tun sollen, anstatt ihnen zu erlauben, zu experimentieren und zu lernen und sich weiterzuentwickeln, um zu dem zu werden, was ich als leitende technische Person geworden war. Ich denke also, die erste Lektion, die ich gelernt habe, war, dass die Führung eines Teams aus einer Expertenperspektive wahrscheinlich nicht der beste Ansatz ist, wenn Sie gehen... vor allem, wenn Sie an agile und andere integrativere Teamwork-Projekte denken, sollten Sie den Mitarbeitern einen eher katalytischen oder katalytischen Führungsstil geben, der auf Synergien basiert, damit sie sich selbst organisieren und als Ingenieur lernen und wachsen können.
Matthew Lawrence:
Gibt es Zeiten, die für Sie besonders auffallen und in denen Sie es furchtbar falsch verstanden haben? Ich weiß, dass ich ein paar Geschichten habe, die ich auch gerne teilen kann.
Ray Arell:
Ich würde gerne ein paar von deinen hören. Ich finde furchtbar falsch, ich denke, es ist... Die Frage ist, ist etwas jemals wirklich nicht reparierbar, nicht wiederherstellbar? Und in den meisten Fällen waren die meisten Probleme, mit denen wir uns befasst haben, behebbar. Ich denke, wenn ich mir das so ansehe und wieder in diese Haltung zurückkehre, stelle ich ein Team zusammen oder stelle ich nur eine Gruppe von Personen zusammen, die einfach ihre Arbeit vom Manager nehmen und sie wie Karten verteilen... Ich denke, zu Beginn war der große Fehler wahrscheinlich, einfach zu kontrollierend zu sein, und der Fehler dieser Kontrolle bedeutete, dass ich keinen Urlaub haben konnte. Andere waren voneinander abhängig, anstatt voneinander abhängig zu sein. Und ich denke, dadurch lief die Organisation langsamer und nicht so effizient, wie sie sein könnte.
Matthew Lawrence:
Ich habe mir sicherlich schon früher in meiner Führungskarriere denselben Ansatz schuldig gemacht, als ich zum Engpass wurde, absolut.
Ray Arell:
Ja. Genau.
Matthew Lawrence:
Und um das zu erkennen, kann es ziemlich schwierig sein, es rückgängig zu machen, aber es lohnt sich auf jeden Fall, daran festzuhalten. Noch etwas, bei dem ich das Glück hatte, eine Ausbildung in situationsbezogener Führung zu erhalten, oh, wahrscheinlich vor fast 10 Jahren. Und das hat mir wirklich die Augen für einen Ansatz geöffnet, die Art und Weise, wie ich verschiedene Leute in meinem Team behandelte. Aber ich habe sie so behandelt, wie ich sie zuerst beurteilt habe. Wenn ich also [unverständlich 00:07:01] einen Experten und einen Meister sehen würde, würde ich sie als Experten und Meister in allen Dingen behandeln. Und [unverständlich 00:07:05] Wenn jemand zu diesem Zeitpunkt seiner Karriere weniger fähig wäre, würde ich das Gleiche annehmen. Und so würde ich für alles das gleiche Maß an Orientierung oder Orientierungslosigkeit auf diese Leute anwenden. Und bei der situativen Führung ist die Prämisse für diejenigen, die es zu Hause nicht wissen, die Prämisse, die man vorgibt, je nach der jeweiligen Aufgabe, die man vorgibt. Haben Sie diesen oder einen ähnlichen Ansatz verwendet, um festzulegen, wie Sie Menschen auf unterschiedliche Weise einbeziehen?
Ray Arell:
Nun, um Menschen einzubeziehen, gehört es meiner Meinung nach dazu, dass du... Wie du schon sagtest, du hast jede Person situativ betrachtet und sie so strukturiert, dass sie von einer Art, einem Ansatz, von sehr individuellem Umgang mit jemandem geprägt war. Ich denke, die Philosophie, die ich... Nicht jeder ist sehr offen oder kann sehr gut über seine Fähigkeiten und Stärken kommunizieren, oder in bestimmten Fällen sind manche Menschen vielleicht gut in etwas, üben es aber nicht aus, weil sie selbst das Gefühl haben, dass das nicht zu ihren Stärken gehört, aber in Wirklichkeit ist es so. Ich denke also, wenn Sie aus einer situativen Führungsperspektive sagen, wenn Sie jemanden daran zweifeln hören, dass er derjenige sein könnte, der etwas tun oder, sagen wir, sogar die Führung von etwas übernehmen könnte, denke ich, dass ein Teil davon einfach in das gesamte Coaching und Mentoring einfließen und es wirklich einrichten und ihnen dabei helfen, erfolgreich zu sein.
Und aus einer inklusiven Perspektive denke ich, dass es ein gewisses Maß an Ehrlichkeit gibt, das man in seine Arbeit einbringen muss, und Demut, wenn es darum geht, bescheiden zu sein, auch wenn es um das geht, was man erreicht hat. Denn gerade im Ingenieurwesen tendiert man dazu, zu beobachten, dass, wenn man Leute in einen Raum bringt, die Leute, die neu sind, sich zurücklehnen und sich demjenigen hingeben, von dem sie glauben, dass er die mehr Erfahrung hat. Und die Realität ist, dass sie, sagen wir, sagen wir, sie kommen gerade von der Uni. Sie haben vielleicht mehr Fähigkeiten in einem bestimmten Bereich, basierend auf dem, was sie gerade in ihrem Lehrplan durchgemacht haben, als wir vielleicht nicht. Also die Frage, wie wir das gesamte organisatorische Gehirn nutzen, um alle Ideen auf den Tisch zu bringen, erfordert meiner Meinung nach manchmal, dass wir in der Lage sind, effektiv zuzuhören und manchmal einfach innezuhalten und den Leuten zu erlauben, das Wort zu haben und den Stift in die Hand zu nehmen und nicht den Raum zu besetzen, wenn das Sinn macht.
Matthew Lawrence:
Das tut es wirklich, und ich glaube, ich habe das in jedem Unternehmen gesehen, in dem ich bis zu einem gewissen Grad gearbeitet habe. Es würde mich wirklich interessieren, wie Sie mit diesem Szenario umgehen. Für die Leute, die zuhören und mit dieser Situation konfrontiert werden, ist es vielleicht das erste Mal, dass sie eine Führungsrolle übernehmen und dieses Szenario sehen und beobachten. Gibt es einen Rat, den Sie ihnen geben würden, um diese Dynamik zu ändern?
Ray Arell:
Nun, erstens, ich werde mir dessen gerade bewusst. Ich kritzele oft, wenn ich in einer Gruppe von Leuten bin, und ich setze mich hin und mache Punkte auf ein Papier, wo sich die Leute im Raum befinden, und dann fange ich an, Linien zwischen diesen einzelnen Punkten zu zeichnen, wenn ich sehe, dass die Kommunikation zwischen bestimmten Spielern stattfindet. Und was interessant ist, wenn man sich das über einen Zeitraum von etwa 15 Minuten anschaut, beginnt man, dieses Muster zu erkennen, dass vielleicht jemand das Gespräch dominiert oder dass er im Mittelpunkt der Konversation steht und es nicht im ganzen Raum herumgeht. Das ist der Zeitpunkt, an dem du zum Torwächter wirst und andere zur Konversation einlädst. Und dann hilfst du denjenigen, die das Gespräch dominieren, höflich, eine Pause einzulegen, einfach Raum zu geben und den anderen Leuten zu erlauben, zu reden und das herauszuholen.
Und dann denke ich an die Frage, ob das, was die Person sagt, manchmal mit dem Gespräch kohärent ist oder nicht, oder vielleicht versucht sie immer noch, etwas über die Dynamik von allem zu lernen. Man muss nur helfen, manchmal, das aus den Leuten herauszuholen, und offene Worte verwenden, um im Grunde einen Satz zu eröffnen... Ich meine, ein paar offene Fragen, um ihnen das zu beantworten. Und ich denke, das funktioniert wirklich gut.
Matthew Lawrence:
Ich liebe das. Ich kritzele auch. Ich bin Künstler in meiner frühen Karriere, und ich habe mich vor langer Zeit daran gearbeitet, Probleme mithilfe von Technik zu lösen, aber ich kann immer noch nicht... Ich brauche diese physische Zeichnung, um meinen Geist zum Denken zu bewegen, genauso wie alles andere [unhörbar 00:12:30] als nur auf einem Block zu kritzeln.
Ray Arell:
Das Gleiche hier.
Matthew Lawrence:
Etwas, das Sie vorhin gesagt haben, wir haben ein wenig über Inklusivität gesprochen. In Ihrer LinkedIn-Biografie sprechen Sie davon, eine integrative Führungskraft zu sein, die es liebt, andere zu inspirieren und zu motivieren, ihr volles Potenzial auszuschöpfen. Etwas, das mir wirklich am Herzen liegt, ist, dass vor allem der letzte Teil darin besteht, Menschen zu helfen, ihr volles Potenzial auszuschöpfen. Deshalb liebe ich es, ein Personalleiter und COO zu sein. Das können Sie in einem ganzen Unternehmen tun. Ich würde gerne zuerst auf die Idee eingehen, eine integrative Führungskraft zu sein. Wie definierst du, was es bedeutet, eine zu sein?
Ray Arell:
Nun, inklusive Führung, es gab eine alte Tasche, die ich früher hatte, eine kleine Coaching-Tasche, die ich immer mit mir herumtrug. Und ganz oben stand: „Bring es ins Team“, war das Motto, das ganz oben drauf stand. Und ganz unten auf der Tüte stand im Grunde: „Behandle Menschen wie Erwachsene.“ Waren die beiden Kernpunkte, von denen ich glaube, dass Inklusion darin besteht, dass ich akzeptieren muss, dass, ja, ich ein kluger Mensch bin, aber treffen wir eine bessere Entscheidung, wenn wir das im Team besprechen? Sehen wir, welche anderen Ideen oder Möglichkeiten wir uns vorstellen? Im engeren Sinne, treffen Sie die Entscheidung so spät wie möglich.
Es geht eher um die östliche Kultur, also, wenn ich die Entscheidung offen lasse, finden wir vielleicht etwas, das billiger oder besser oder auch einfach aufregender für unsere Kunden ist. Ich denke, ein Teil davon ist zu wissen, dass Sie nicht derjenige sein müssen, der die Entscheidung treffen muss. Sie können das Team die Entscheidung treffen lassen. Und wir alle umarmen uns, weil wir uns damit stärken. Das dachten wir alle, nicht nur das, was Ray dachte, was ich cool finde.
Matthew Lawrence:
Zu dem Artikel, über den Sie in Ihrer Biografie gesprochen haben, gibt es einen zweiten Teil, in dem es darum geht, andere zu motivieren, ihr volles Potenzial auszuschöpfen.
Ray Arell:
Ja, ja.
Matthew Lawrence:
Ja. Lassen Sie uns darüber sprechen, woher das für Sie kam, diese Leidenschaft, und wie Sie aufstrebenden Führungskräften helfen wollen, ihr volles Potenzial auszuschöpfen?
Ray Arell:
Ja, ich meine, ich hatte das Glück, als ich zur Intel Corporation kam, dass Andy Grove die Organisation zu der Zeit noch leitete. Tatsächlich hat er meinen Welcome to Intel-Kurs abgehalten. Zu der Zeit, als ich zu Intel kam, gab es nur etwa 32.000 Mitarbeiter. Und hier ist der CEO, Gründer des Unternehmens, der den Welcome to Intel-Kurs unterrichtet, den ich unglaublich cool fand, eine großartige Erfahrung. Er strahlt diese Führungsstärke aus, egal in welchem Mojo oder was auch immer es ist, er geht in die Umwelt, während er über das Unternehmen spricht. Aber er war wirklich stark im Einzelgespräch, der Zeit, die Sie mit Ihrem Manager oder anderen innerhalb der Organisation verbringen können, weil Sie mit jedem im Unternehmen ein Einzelgespräch führen können. Und das hat er gefördert. Und ich denke, das hilft... Wenn jemand versucht, es herauszufinden, ist er ganz neu im Unternehmen, und du bekommst eine ständige Einladung vom CEO, auf der steht: „Du kannst kommen und ein Gespräch mit mir führen“. Ich denke, das legt die kulturelle Norm von Anfang an fest, dass dies ein Ort ist, der mir bei meiner Karriere helfen und helfen wird.
Und ich könnte Ihnen sagen, dass es verschiedene Zeiten gab, in denen sich daraus ein ausgewachsener Satz entwickelte: „Ich bin der Mentee und sie sind die Mentoren.“ Und in diesen Beziehungen ist es im Laufe der Zeit so, als würdest du sagen: „Nun, das werde ich weiterzahlen.“ Heute habe ich mindestens sechs oder sieben Mentees, die alle möglichen Fragen dazu haben, wie sie sich durch ihre Karriere begleiten sollen oder ob sie einen bestimmten Bereich haben, auf den sie sich konzentrieren wollten. Und es ist an der Zeit, dass sie mir den Kopf zerbrechen. Und in bestimmten Fällen, wenn ich nicht die vollständige Antwort habe, kann ich sie zu anderen Mentoren weiterleiten, die ihnen helfen können, zu wachsen.
Matthew Lawrence:
Ich liebe diesen Ansatz der Weiterleitung, den Sie dort angesprochen haben. Es ist definitiv etwas, das ich in den letzten Jahren selbst versucht habe, und ich wünschte, ich hätte früher mit dem Mentoring angefangen. Ich hatte das Privileg, in meiner Karriere mit einigen großartigen Führungskräften zusammenzuarbeiten, von denen ich viel gelernt habe. Und als ich mit dem Mentoring angefangen habe, wurde mir klar, wie viel ich als Mentor gelernt habe, weil man nachdenken muss. Du denkst wirklich darüber nach, was diese Leute durchmachen, und projizierst dich nicht einfach auf sie. Und es bestätigt die Begründung, warum Sie Dinge selbst tun, warum Sie so denken. Und es zwingt mich, mich selbst herauszufordern.
Und ich denke, wenn es irgendwas gibt... Ich spreche mit einigen der jüngeren Leute bei der Arbeit, die aufstrebende Führungskräfte sind, und sie sind auf ihre Art außergewöhnlich. Sie haben alle sehr unterschiedliche Hintergründe, aber viele von ihnen haben nicht das Gefühl, bereit zu sein, Mentor zu sein. Das sind sie wirklich. Das sind tolle Leute. Und ich frage mich, haben Sie Leute zu Beginn ihrer Karriere gesehen, die versucht haben, es irgendwie früh weiterzugeben, oder haben die Leute das Gefühl, dass sie bis [unhörbar 00:18:22] warten müssen?
Ray Arell:
Ich denke, es kommt darauf an. Erstens, ich denke, das Bildungssystem, zumindest in den Vereinigten Staaten, hat sich ein wenig verändert. Wenn die Leute ihren Bachelor-Abschluss machen, waren sie früher einfach auf sich allein gestellt, sie haben ihr Buchstudium gemacht. Für diese Studie wurde nur sehr wenig Interaktion oder Teamwork entwickelt. Ich meine, als ich meinen Abschluss in Elektrotechnik gemacht habe, war das nur ich alleine. Es mag gelegentlich Laborarbeiten und Laborprojekte geben, aber das war nicht sehr inklusiv, und es gab auch keine Leute, die so früh Führungspositionen übernahmen. Ich sehe mir jetzt meine Tochter an, die gerade an die Universität geht, und alles ist eine Kohortengruppe. Es gibt Kohorten, die sich treffen. Durch das Studium, das sie machen, müssen sie alle in gewisser Hinsicht die Führung für einen Aspekt eines Projekts übernehmen, an dem sie gerade arbeiten. Ich denke, einige der neuen Leute, die in die Belegschaft kommen, haben quasi die Fähigkeiten, um, wenn sie eine Führungsrolle übernehmen müssen, ein kleines Programm oder ein Projekt durchführen müssen, dafür gerüstet zu sein. Zumindest habe ich das gesehen.
Matthew Lawrence:
Ich liebe dieses Konzept. Etwas, das ich beobachtet habe und darüber spreche ich auch viel mit unserem Führungsteam und unseren Mentor-Führungsteams für die [unhörbar 00:19:56]. Ein Großteil der Gespräche dreht sich um Teamdynamik, Teamvertrauen, Agilität innerhalb von Teams und darum, generell zu versuchen, Teams zu stärken, sie so aufzustellen, dass sie autonom sein können. Sie sind wirklich befähigt und man vertraut darauf, dass sie großartige Entscheidungen treffen und die Arbeit vorantreiben. Sie haben viel Erfahrung mit agilen und agilen [unhörbaren 00:20:21] agilen Führungskräften. Aufgrund Ihrer Erfahrung mit der Leitung agiler Teams, diesen Adoptionen und diesen Transformationen würde ich gerne verstehen, ob Sie einen Zusammenhang zwischen Agilität als Team und den Eigenschaften sehen, die eine integrative Führungskraft haben wird. Gibt es in Ihrem Kopf einen Zusammenhang zwischen dem, was es bedeutet, agil zu sein, und einer inklusiven Führungskraft?
Ray Arell:
Ich glaube schon. Denn wenn Sie schon früh daran denken, haben sie festgestellt, dass Servant Leadership ein besserer Führungsstil für agile Teams ist. Ich denke also, wenn wir über Transformation sprechen, sind einige der größten Fehler, die auftreten, eher darauf zurückzuführen, dass sie nicht agil sind, sondern auf Vertrauensfragen und anderen organisatorischen Hindernissen, die es dort bereits gab, bevor sie gestartet wurden. Und wenn sie diese nicht angehen, ist ihre agile Reise schmerzhaft.
Ich habe Leute sagen hören, dass sie schon einmal Scrummed bekommen haben und es auf eine wirklich abwertende Art nutzen und denken, dass, nun ja, anstatt ein Team von befähigten Leuten dazu zu bringen, innerhalb des Scrum-Frameworks zu arbeiten, sie am Ende unter die Linse des Mikromanagements gestellt werden, weil sich die Kultur des Managers nicht geändert hat und der Manager sie täglich nutzt, um sicherzustellen, dass alle zu 120% arbeiten, im Vergleich zu dem, was wir sehen sollten Das Muster ist, dass das Team seinen Flow versteht. Sie bringen Arbeit in das Team. Es wird nicht geschoben. Und ich denke, diese Dynamik ist etwas, dass, wenn sich die Führung nicht verändert und die Art und Weise, wie sie arbeitet, ändert, sie in Organisationen einfach nicht funktioniert.
Matthew Lawrence:
An den vielen Orten, an denen Sie gearbeitet, Menschen gecoacht und angeleitet haben, stoßen Sie langsam auf... Es gibt einen Begriff, den wir inzwischen für agile Muttersprachler verwenden. Dabei handelt es sich um Menschen, die es wirklich nicht anders gekannt haben, weil so viele Unternehmen auf der Welt agile Transformationen durchlaufen, und das wird noch lange so bleiben. Aber da manche Unternehmen mit Agilität an vorderster Front geboren wurden, haben Sie schon erlebt, dass viele Menschen in Führungspositionen aufsteigen, die nichts anderes wissen als echte Agilität und wirklich authentische Agilität, wie Sie es gerade beschrieben haben?
Ray Arell:
Nun, ich finde es irgendwie interessant, denn als du über diesen Satz gesprochen hast, habe ich darüber nachgedacht, naja, wenn du nichts anderes wüsstest... Aber ich kann auch sagen, dass du einheimisch werden könntest, wenn du auch eine Zeit lang in der Kultur warst. Also kannst du irgendwann... Das wird deine erste Reaktion, deine erste Angewohnheit ist es, mehr aus den agilen Prinzipien herauszuholen, als du aus etwas anderem ziehen würdest. Ja, es gibt diese Leute, aber es war interessant, Unternehmen wie Spotify oder Salesforce oder Pivotal zu beobachten, und ich kann einfach die Liste der Unternehmen durchgehen, die als agile Organisation angefangen haben, sie wurden groß, und dann tauchen plötzlich die Antimuster eines großen Unternehmens in diesen Unternehmen auf. Obwohl also die Leute innerhalb des kleineren Stammes agil arbeiten, fängt das Unternehmen langsam nicht mehr an, agil zu arbeiten. Es fällt in einen größeren Kontext dessen, was wir bei den älteren Unternehmen beobachten.
Und ich denke, ein Teil davon könnte an der Unternehmenskultur liegen, dass sie jemanden von außerhalb mitbringen, der kein Muttersprachler ist, und es fällt ihnen schwer, mit der Vorstellung umzugehen, dass wir irgendwann hier drüben einen Liefertermin festlegen und wir glauben, dass wir ihn einhalten werden. Aber nein, wir haben keinen Plan, den man liebevoll zu 90% mit Zuversicht bezeichnen würde, der besagt, dass wir alle Risiken aus dem Weg geräumt haben. Und ja, es wird auf jeden Fall an diesem Tag passieren. Und einige dieser Unternehmen werden wirklich... Sie haben das Gefühl, dass sie alles auf die Straße legen müssen, und wenn sie es nicht einhalten, haben sie das schon in ein Bonusprogramm für Führungskräfte gesteckt, was leider zu schlechtem Benehmen führt
Matthew Lawrence:
Ja, ich war dort. Ich gehe davon aus, dass wir in unserem Publikum Leute haben werden, die in höhere Führungspositionen wechseln. Sie sind keine aufstrebenden Führungskräfte, sie machen das schon eine Weile, und sie haben wahrscheinlich einige erfolgreiche agile Teams auf der kleineren Ebene geleitet, wie Sie es beschrieben haben. Gibt es für die Leute, die in höhere Rollen, vielleicht in Führungspositionen, aufsteigen, eine Anleitung, die Sie ihnen geben würden, wie sie diese Veränderungen bewältigen und versuchen, sie mithilfe agiler Prinzipien und der Bedeutung von Agilität in diesen höheren Rollen aufrechtzuerhalten?
Ray Arell:
Ja, ich denke, ein Teil davon ist die Arbeit, die Sie als kleineres Team geleistet haben, alles kann immer noch skaliert werden. Und ich hasse es, das Wort Skala zu benutzen, weil ich denke, Maßstab ist irgendwie... Die Leute benutzen es irgendwie... Was wäre das richtige Wort? Es wird in unserer Branche missbraucht. Ich denke, Werte und Prinzipien sind skalenfrei. Sie können immer noch jeden Tag in Ihr Team gehen und sich immer noch an diese 12 Prinzipien halten, und Sie werden gute Arbeit leisten. Die Frage ist jedoch, wenn Sie das auf der unteren Ebene tun, sagen wir mit einem Kanban-Board, ist die Frage, wie es aussieht, wenn Sie an Ihrem Chefschreibtisch sitzen? Was ist die Methode, bei der Sie Poolbillard spielen? Wenn Sie sich die meisten skalierten Frameworks ansehen, die heute auf dem Markt sind, gibt es nur sehr wenige Hinweise darauf, was im Alltag einer agilen Führungskraft sein sollte. Wie sollte das aussehen?
Und wenn ich an das Geschäftsteam denke, arbeitet das Managementteam täglich mit den Lieferteams zusammen. Das sollten sie tun. Also, was werden Sie tun, damit das möglich wird und stattfindet? Was werden Sie tun, um... diese großen jährlichen Budgetprozesse einzustellen? Machen Sie sich Dinge wie die Budgetierung oder andere Dinge zu eigen, bei denen Sie die Organisation strategisch finanzieren und nicht versuchen, alles auf einen jährlichen Rhythmus festzulegen, aber Ihre untergeordnete Organisation arbeitet trotzdem alle zwei Wochen. Sie sollten also in der Lage sein, Ihre Wetten bei jeder Organisation auf der Grundlage der Leistung jedes Sprints erneut zu verschieben. Kannst du das machen?
Das letzte ist wahrscheinlich das wichtigste, sind Hindernisse. Und so schnell braucht es Informationen, um vom untersten Teil der Organisation zum höchsten Punkt der Organisation zu gelangen? Und wenn das bei bestimmten Organisationen drei Wochen, zwei Wochen oder manchmal sogar später dauert, optimieren Sie das. Wie optimiert man ein Hindernis, bei dessen Beseitigung Sie persönlich helfen können, für die Mitarbeiter, damit sie nicht länger gebremst werden, was auch immer das sein mag?
Matthew Lawrence:
Du berührst da etwas, was meiner Meinung nach ein grundlegender Bestandteil von Agilität ist, nämlich diese Fähigkeit zu lernen und sich anzupassen, und du kannst nur lernen, wenn du dir bewusst bist, was um dich herum passiert, du kannst es beobachten [unhörbar 00:28:39].
Ray Arell:
Nun, ich habe vor ein paar Monaten etwas gesagt und alle sagten einfach: „Warum hast du gesagt... Ich kann nicht glauben, dass du das laut gesagt hast.“ Manchmal ist es das leise Zeug, das laut ausgesprochen wird. [unhörbar 00:28:53]. Wir haben versucht, ein Treffen zu vereinbaren, um eines dieser Hindernisse zu beheben, und alle hochrangigen Führungskräfte waren beschäftigt. Sie waren beschäftigt. Und meine Frage war, wenn das momentan nicht das Wichtigste für uns ist, was machst du dann? Wirklich, tust du das in deinem Alltag, wenn das nicht die höchste Priorität ist, die du eingehst? Und die Befragung hochrangiger Führungskräfte, dass sie vielleicht nicht auf die richtigen Dinge achten, und manchmal den Machthabern diese Wahrheit zu sagen, ist etwas, das wir ab und zu tun müssen.
Matthew Lawrence:
Ich stimme zu. Dieses Maß an Offenheit ist definitiv auf allen Ebenen erforderlich und die Fähigkeit, dieses Feedback zu erhalten, damit Sie als Einzelperson lernen und sich anpassen können, wie wir bereits zuvor besprochen haben, darüber, wie Sie als Führungskraft, aber auch als Team anpassungsfähig sind. Es gibt einen Punkt, auf den ich noch eingehen möchte, bevor wir zum Abschluss kommen, nämlich wenn man die Karriereleiter hochklettert und in eine höhere Position kommt und dann für ein breiteres Spektrum von Dingen verantwortlich ist, vor allem, wenn man die Führungsebene erreicht, habe ich erlebt, wie Menschen mit dem Übergang von der Person, von der Sie gleich zu Beginn dieser Diskussion gesprochen haben, zu der Person, die alles weiß und die Regie führen kann und alle Antworten hat in jemanden, bei dem ich sehe, dass sich Ihr Job zu der Person entwickelt, die identifizieren kann, was wir wissen am wenigsten darüber, was wir als Führungsteam am wenigsten wissen, wo wir sind... haben am wenigsten Selbstvertrauen, wo wir die Hindernisse sehen und nicht wissen, was wir mit ihnen anfangen sollen.
Wie gehst du vor, um die Leute dazu zu bringen, das anzunehmen? Weil ich denke, was ich sehe, ist die Angst, die damit einhergeht, fast eine Angst davor, zu sagen: „Oh, ich gebe es Leuten gegenüber zu, dass ich nicht weiß, was ich tue.“ Und ich wurde während meiner gesamten Karriere dafür belohnt, dass ich immer mehr zum Experten wurde, und plötzlich ist es meine Aufgabe, die Person zu sein, die selbstbewusst genug ist, um auszurufen: Das ist es, was wir noch nicht verstehen. Lassen Sie uns zusammenkommen und versuchen, das Problem zu lösen. Wenn das Risiko größer ist, die Auswirkungen größer sind und Sie für mehr Dinge verantwortlich sind, wie helfen Sie Menschen beim Übergang in diese übergeordnete Rolle?
Ray Arell:
Nun, ich denke, ein Teil davon ist, dass sie diese technische Seite loslassen können, wenn sie sich ständig die Hände schmutzig machen müssen? Und ich habe bestimmte Führungskräfte gesehen, bei denen wirklich jemand zurückgehen und sagen muss: „Bist du dir wirklich sicher, dass das die Karriere ist, die du anstreben willst? Sie scheinen mehr darauf aus zu sein, sich mit den Einzelheiten befassen zu wollen, und vielleicht ist das der beste Ort für Sie, weil Sie sich in diesem Bereich wohler fühlen.“ Der andere Aspekt ist jedoch, glaube ich, wieder, dass Vertrauen entscheidend wird, wenn sie sich verändern. Vertraue den Leuten, die für dich arbeiten, dass sie nicht reinkommen und faul sind und du ihnen die ganze Zeit über die Schulter schauen musst, weil du das Gefühl hast, dass sie vielleicht nicht produktiv sind oder andere Dinge. Sie müssen sagen können, dass die Leute, die Sie eingestellt haben, talentiert sind und dass sie uns unseren Zielen näher bringen.
Ich denke, was für die Gesundheit des Unternehmens immer wichtiger wird, ist, dass man viel besser darin sein muss, tatsächlich zu sagen: „Okay, nun, hier ist unsere Vision“, sei es eine Produktvision, ob es die Vision des Unternehmens ist, was auch immer das sein mag, den Menschen zu helfen, zu verstehen, was dieser North Star ist, und das dann nicht aus Ihrer Sicht, sondern aus der Sicht des Kunden zu bekräftigen. Und ich denke, hier fangen viele Unternehmen an zu driften, weil sie anfangen, einige interne Kennzahlen zu optimieren, die, ja, die Effizienz in Ihrem Unternehmen steigern werden. Aber was denkt der Kunde? Und ständig in der Lage zu sein, sich, aus einer agilen Perspektive, als der Chief Product Owner des Unternehmens darzustellen, um das repräsentieren zu können, was die Kunden brauchen und wollen, und in der Lage zu sein, dies in der Vision und den ehrgeizigen Missionen, die für das Unternehmen aufgestellt werden, zum Ausdruck zu bringen. Machen Sie es für die Menschen real.
Und dann ist der letzte Teil davon, dass nicht alles passieren und wahr werden wird. Wenn Sie die Biografien der meisten Führungskräfte lesen, gibt es viele, viele, viele Fehler. Und ich erinnere mich an das von einem Anführer, er ging in den Ruhestand. Und ich dachte, es war nicht gerade peinlich, dass er das tatsächlich getan hat. Er ging tatsächlich auf die Bühne und sprach über seinen größten Misserfolg. Während meiner gesamten Karriere bei der Arbeit mit dieser Person habe ich mich immer gefragt, ob sie ein Mensch ist oder nicht. Und dann, am Tag des Ausscheidens dieser Person, beschlossen sie schließlich, Ihnen ein paar Geschichten über Fehler zu erzählen, die sie gemacht hat. Und ich denke, er musste diese Geschichten wirklich viel, viel früher teilen, weil ich denke, die Leute hätten wahrscheinlich herausgefunden... Sie wären etwas gestresst gewesen, um ihn herum zu arbeiten. Und es würde auch eine gewisse Verwundbarkeit für Sie als Führungskraft bedeuten, zu sagen, dass Sie nicht alles herausgefunden haben, und manchmal ist es nur eine Vermutung. Wir sind der Meinung, dass das Produkt genau dort eingesetzt werden muss.
Und sobald du es den Kunden vorstellst, werden sie dir sagen, ob... Wenn du das Cano-Modell nimmst und plötzlich triffst, das ist die aufregendste Sache seit dem Rad, werden sie es lieben oder werden sie gehen, [unhörbar 00:35:12]. Ich nehme es, wenn es kostenlos ist. Du gerätst in eine Situation, in der es ist, naja, wir können nicht so viel verlangen. Aber ich denke, diese Geschichten werden wichtig und verankern Organisationen. Ein weiterer Aspekt ist meiner Meinung nach, dass, wenn man jemanden hat, der ansprechbar ist und diese Geschichten effektiv in die Organisation weiterleiten und über diese Dinge sprechen kann, das meiner Meinung nach allen anderen die Tür öffnet, dies auch zu tun. Denn ob es Ihnen gefällt oder nicht, Menschen sind hierarchisch in der Art und Weise, wie wir über Dinge denken. Viele Leute schaffen es, also ahmen sie Führungskräfte nach. Seien Sie also der Anführer, den jemand nachahmen möchte.
Matthew Lawrence:
Ich finde, das ist ein toller Rat, Ray. Die Verbindung, die sich für mich durch dieses ganze Gespräch zieht, ist, sich authentisch mit Ihrer Arbeit auseinanderzusetzen, ob es das Team ist, das Sie zu leiten versuchen, ob es die agilen Praktiken sind, egal auf welcher Ebene und auf welcher Ebene Sie arbeiten. Und um dieses Vertrauen aufzubauen, damit das funktioniert, ist ein gewisses Maß an Authentizität erforderlich.
Ray Arell:
Ja, genau.
Matthew Lawrence:
Ich würde mich freuen, wenn Sie zum Abschluss noch letzte Tipps oder Ratschläge für aktuelle und aufstrebende Führungskräfte zu diesem Thema hinterlassen würden. Wenn es einen Weg gibt, der über das bloße Teilen Ihrer eigenen persönlichen Geschichten hinausgeht, wie würden Sie Menschen beraten? Was würdest du ihnen geben, um Vertrauen in ihre Teams aufzubauen?
Ray Arell:
Nun, ein paar Dinge. Erstens, du musst darauf achten, wer du als Person bist. Nochmals, wie ich schon sagte, dass die Leute es schaffen. Und wenn Sie um drei Uhr morgens eine E-Mail verschicken und fünf Minuten später Ihre Mitarbeiter Ihnen geantwortet haben, dann sind Sie kein wirklich gutes Vorbild für eine gute Work-Life-Balance. Viele Ihrer Tendenzen werden sich also auf das Unternehmen auswirken. Machen Sie also unabhängig davon, wie Sie sich selbst einschätzen, eine Bewertung Ihrer Führung, wo sie Ihrer Meinung nach stattfindet. Harvard Business Review hat vor langer Zeit das Niveau dessen, was sie als Führungsmodelle betrachteten, nach hinten verschoben. Und auf der untersten Ebene befinden sich Führungskräfte, die auf Experten und Leistungsträgern basieren. Und wenn Sie zu diesen gehören, sind diese für eine gute agile oder kollaborative Kultur nicht sehr förderlich. Wenn Sie sich also gerade in diese Richtung bewegen, sollten Sie nach Wegen suchen, wie Sie sich eher zu einer Führungskraft entwickeln können, die auf Katalysatoren oder Synergien basiert.
Und diese Reise ist nicht einfach, weil ich sie selbst durchgemacht habe. Es hat Jahre gedauert, bis Sie sich von einigen dieser Tendenzen, die Sie als fachkundige Führungskraft hatten, gelöst haben. Und ein Beispiel: Eine Führungskraft, die von Experten geleitet wird, neigt dazu, nur mit anderen Experten zu sprechen. Wenn sie jemanden als keinen Experten für etwas wahrnehmen, neigen sie dazu, diese Personen zu ignorieren und nicht mit ihnen in Kontakt zu treten. Und wieder ist es das gesamte organisatorische Gehirn, das das Problem lösen wird. Wie binden Sie also die gesamte Organisation ein und bringen diese Ideen zusammen?
Die andere ist, dass Sie, wenn Sie darauf eingehen, aus der Perspektive einer aufstrebenden Führungskraft, es vorhin selbst gesagt haben, und das ist nicht nur die Voreingenommenheit, weil Sie kein Experte sind, ich werde nicht mit Ihnen sprechen, sondern jede Voreingenommenheit, die Sie möglicherweise haben, kann die Art und Weise beeinflussen, wie Sie eine Person führen und beurteilen, und könnte ihre Karriere wirklich einschränken oder ausbauen, vielleicht aufgrund eines schnellen Urteils, das Sie vielleicht gehabt haben. Ich denke, Sie müssen sich Ihrer Entscheidungen bewusst sein, die Sie innerhalb der Organisation treffen, und insbesondere der Entscheidungen, die Sie über Menschen treffen. Und mit denen musst du vorsichtig sein.
Der letzte ist wahrscheinlich nur... Und das geht in den Bereich der komplexen adaptiven Systeme. Nicht alles ist zugeschnitten und trocken, schwarz und weiß oder mechanisch, was bedeutet, dass wir dasselbe Produkt nehmen und es immer wieder und wieder wiederholen können, und wir werden unterschiedliche Antworten bekommen. Wir werden unterschiedliche Anforderungen haben. Wir werden verschiedene Dinge bekommen. Es ist okay, dass das Zeug da ist. Und es ist okay, dass die Dinge, die aus unseren Produkten kommen, ab und zu anders sind, und vor allem, weil alles eine sehr komplexe Umgebung ist. Ursache-Wirkungs-Beziehungen und Komplexität sind, dass der Kunde seine Meinung ändern kann, und wir müssen uns damit wohlfühlen, wenn ein Kunde seine Meinung ändert. Unser Kunde hat möglicherweise neue Bedürfnisse, die auftauchen.
Und auch unsere Mitarbeiter ändern manchmal ihre Meinung oder ändern das, worauf sie sich freuen. Wie fördern Sie das? Wie fördert man diese Mitarbeiter, um sie im Unternehmen zu halten, nicht um sie für die Fähigkeiten einzusetzen, über die sie gerade verfügen, sondern wie geht man da langfristig vor? Und ich weiß, dass ich hier etwas langatmig werde, aber das, was ich am meisten sehe, trotz all der Entlassungsbescheide, die gerade vor sich gehen, ist, dass dieses Unternehmen nicht auf lange Sicht spielt. Ich denke, das ist ein schlechter Schachzug, denn alles, was Sie tun, indem Sie einen Mitarbeiter entlassen, ist, Ihrem Konkurrenten eine ganze Reihe von Wissen zu vermitteln, das Sie behalten sollten. Also wie dem auch sei, ich werde es da kurz machen.
Matthew Lawrence:
Richtig. Danke, dass du heute deine Weisheit mit uns geteilt hast. Es war mir ein absolutes Vergnügen. Ich habe den Chat wirklich genossen. Also ja, danke, dass Sie sich mir im Easy Agile Podcast angeschlossen haben.
Ray Arell:
Fantastisch. Danke, dass du mich eingeladen hast.
Verwandte Episoden
PodcastEasy Agile Podcast Ep.34 Henrik Kniberg on Team Productivity, Code Quality, and the Future of Software Engineering
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.
PodcastEasy Agile Podcast Folge 3 Melissa Reeve, VP Marketing bei Scaled Agile
„Ich habe es wirklich genossen, mit Melissa Reeve, VP of Marketing bei Scaled Agile, darüber zu sprechen, wie Teams, die keine Software sind, eine neue Arbeitsweise einführen.“
Es ist wichtiger denn je, kundenorientiert zu sein.
Wir sprechen über die Gefahr von „Walk-up-Work“ und darüber, wie dies durch eine angemessene Sprintplanung vermieden werden kann.
Melissa gibt auch einen Überblick darüber, wie sich Agile auf Teams ohne technische Kenntnisse ausbreitet.
Transkript
Sean Blake:
Hallo an alle zusammen. Und willkommen zum Easy Agile Podcast. Wir haben heute einen wirklich interessanten Gast bei uns. Es ist Melissa Reeve, die Vizepräsidentin für Marketing bei Scaled Agile. Wir freuen uns sehr, sie heute bei uns zu haben. Melissa Reeve ist Vizepräsidentin für Marketing bei Scaled Agile, Inc. In dieser Rolle leitet Melissa das Marketingteam und hilft den Leuten, Scaled Agile, das Scaled Agile Framework, besser zu verstehen. Mit anderen Worten, SAFe und seine Mission. Sie ist auch als Praxisleiterin für die Integration von SAF-Praktiken in Marketingumgebungen tätig. Melissa erhielt ihren Bachelor of Arts von der Washington University in St. Louis und lebt derzeit mit ihrem Mann, Hühnern und Hunden in Boulder, Colorado. Melissa, vielen Dank, dass du heute im Podcast zu uns gekommen bist.
Melissa Reeve:
Es ist so eine Freude, hier zu sein. Ich weiß das wirklich zu schätzen.
Sean Blake:
Großartig. Das ist großartig. Ich mag deine Begeisterung auf Anhieb sehr. Was mich wirklich interessiert, ist Melissa, es geht ein bisschen darum, wie du dahin gekommen bist, wo du heute bist. Was waren die Höhepunkte Ihrer bisherigen Karriere und wie haben Sie sich als Marketer im agilen Bereich wiedergefunden?
Melissa Reeve:
Nun, danke der Nachfrage. Und ich muss es dir sagen, aber kurz vor dem Podcast klopfte mein Mann an die Tür und er war ganz stolz, weil wir gerade ein neues Set Hühner bekommen haben und eines der Hühner sein erstes Ei gelegt hat. Das war also der Höhepunkt meines bisherigen Tages, nicht unbedingt der Höhepunkt meiner Karriere.
Sean Blake:
Sie werden also wahrscheinlich in den nächsten Wochen Rührei und Eier auf Toast essen.
Melissa Reeve:
Ich glaube schon. Also zurück zur Karriere, ich bin wirklich ins Marketing geraten. Mein Hintergrund lag in japanischer Literatur und Sprache. Und ich hatte diese großartige Karriere und dieses internationale Geschäft in Asien erwartet. Und dann zog ich in das Navajo-Indianerreservat und drehte einfach um. Ich habe meinen Weg ins Marketing gefunden und meinen Weg zu Agile ungefähr 2013 gefunden, als ich herausfand, dass es ein Agile-Marketing-Manifest gibt. Und das war wirklich ein Wendepunkt in Bezug auf meine Einstellung zum Thema Marketing. Denn bis zu diesem Zeitpunkt dachte ich wirklich über Marketing in einem sogenannten Wasserfall nach. Natürlich verwenden Vermarkter den Begriff Wasserfall im Allgemeinen nicht.
Melissa Reeve:
Aber dann fing ich an, anders über Marketing nachzudenken. Und als ich auf Scaled Agile stieß, brachte es so viele Elemente meiner Karriere zusammen. Das schlanke Denken, das ich während meines Studiums in Japan studiert hatte, und die schlanke Fertigung. Das war Agiles Marketing, das ich 2013 entdeckt hatte, und nur Bildung und Technologie waren schon immer Teil meiner Karriere. Ich schätze mich wirklich glücklich, Scaled Agile gefunden zu haben und mich mitten darin wiedergefunden zu haben, Agile sowohl in Unternehmen als auch in Marketingbereichen des Unternehmens zu skalieren.
Sean Blake:
Oh wow, okay. Und ich habe anhand Ihres LinkedIn-Profils festgestellt, dass Sie in der Vergangenheit an einigen Universitäten und Hochschulen gearbeitet haben. Und ich gehe davon aus, dass einige der Teams, die Marketingteams, in denen Sie gearbeitet haben, in der Vergangenheit ziemlich groß waren. In welchen Strukturen haben Sie früher gearbeitet, in diesen Marketingteams? Und vor welchen Herausforderungen standen Sie?
Melissa Reeve:
Ja, nun, das größte Unternehmen war Motorola. Und das war ziemlich früh in meiner Karriere. Ich glaube also nicht, dass ich mich genau erinnern kann, wie diese Teamstruktur aussieht. Aber ich denke, was die Hindernisse beim Marketing angeht, waren Genehmigungen schon immer ein Problem. Egal, ob Sie von einer kleineren oder einer größeren Organisation sprechen, es scheint, als müssten die Dinge die Kette hochgehen, abgesegnet werden und dann zur Ausführung wieder herunterkommen. Und damit verbunden sind Verzögerungen und Wartezeiten und im Grunde Verschwendung im System.
Sean Blake:
Richtig. Also, was ist Agiles Marketing dann und wie versucht es, einige dieser Probleme zu lösen?
Melissa Reeve:
Nun, ich freue mich, dass Sie gefragt haben, denn auf dem Markt herrscht viel Verwirrung rund um Agile-Marketing. Und ich kann Ihnen nicht sagen, wie viele Nachrichtenartikel ich gelesen habe, in denen es heißt, Marketing sollte agil sein. Und sie sprechen wirklich von Agile in Kleinbuchstaben, was bedeutet, dass Marketing flinker oder reaktionsschneller sein sollte. Aber sie sprechen nicht wirklich von Capital-A-Agile-Marketing, einer Arbeitsweise, hinter der Prinzipien und Praktiken stehen. Das ist also ein Aspekt, bei dem im Zusammenhang mit agilem Marketing Verwirrung herrscht.
Melissa Reeve:
Und dann ist noch ein weiterer Aspekt, wie groß der Kreis ist, von dem du sprichst. Was die Software angeht, wenn jemand Agile erwähnt, spricht er in Wirklichkeit von einem kleineren Team, und je nachdem, mit wem Sie sprechen, können es zwischen fünf und 11 Personen in diesem Agile-Team sein. Und Sie sprechen von einer Reihe von Teams dieser Größe. Wenn Sie also über agiles Marketing sprechen, könnten Sie von einem einzelnen Team sprechen.
Melissa Reeve:
Aber manche Leute sprechen, wenn sie über agiles Marketing sprechen, von einer Transformation und der Transformation der gesamten Marketingorganisation in eine agile Arbeitsweise. Und natürlich sprechen wir in der SAFe-Welt wirklich über die Marketingteams, die möglicherweise an eine SAFe-Implementierung angrenzen. Ich denke, das ist eine gute Frage und eine gute Frage, die Sie sich im Vorfeld stellen sollten, wenn Sie ein Gespräch über Agiles Marketing führen.
Sean Blake:
In Ordnung. Okay. Und für die Leute, die nicht viel über SAFe wissen, können Sie einfach erklären, was der Unterschied ist zwischen einem Marketingteam, das jetzt auf Capital-Agile-Art arbeitet, und was ist der Unterschied zwischen einer Organisation, die anfängt, Scaled Agile einzuführen? Was ist der Unterschied-
Melissa Reeve:
Sicher.
Sean Blake:
... zwischen denen?
Melissa Reeve:
Ja. Softwareunternehmen haben also herausgefunden, dass agile Teams, also diese Gruppen von fünf bis 11 Personen, diese Arbeitsweise wirklich gut funktioniert, wenn man eine begrenzte Anzahl von Softwareentwicklern hat, als man anfing, in die größten Organisationen der Welt zu kommen. Ich denke also, dass alle Mitglieder der Global 2000 Zehntausende von Softwareentwicklern in ihrer Organisation haben könnten. Und um die Vorteile von Agile nutzen zu können, brauchten Sie Taktfrequenz und Synchronisation, nicht nur innerhalb eines Teams, sondern auch über mehrere Teams hinweg bis hin zur Programmebene und sogar zur Portfolioebene.
Melissa Reeve:
Und das Gleiche gilt für große Marketingorganisationen. Stellen Sie sich vor, Sie sind CMO und haben 6.000 Vermarkter unter sich. Wie sollen Sie Ihre Vision, Ihre Strategien, die Sie festlegen, in Einklang bringen, wenn Sie keine Möglichkeit haben, Strategie und Umsetzung zu verbinden. Das Scaled Agile Framework ist also eine Möglichkeit, diese agilen Praktiken über mehrere Teams hinweg und bis in die höchsten Ebenen des Unternehmens zu übertragen, sodass wir uns alle in eine ähnliche Richtung bewegen.
Sean Blake:
In Ordnung. Okay, ich denke, das macht Sinn. Und aus der Sicht eines Softwareteams besteht einer der Vorteile von Agile darin, dass es Teams hilft, sich stärker auf den Kunden zu konzentrieren. Und viele würden argumentieren, nun ja, Marketing war schon immer kundenorientiert. Aber haben Sie in Ihrer Erfahrung festgestellt, dass das vielleicht nicht so stimmt? Und wenn Marketingteams beginnen, Agile einzuführen, erkennen sie, was es wirklich bedeutet, kundenorientiert zu werden.
Melissa Reeve:
Ja. Ich meine, Sie haben noch einen wichtigen Punkt angesprochen, weil ich denke, die meisten Vermarkter denken, dass sie kundenorientiert sind. Wie viele Dinge auf der Welt ist die Welt ein relativer Ort. Sie können also theoretisch in Ihrem Kopf an den Kunden denken oder Sie können tatsächlich mit dem Kunden sprechen. Also habe ich gerade das beendet, was ich die Hörsitzung nenne. Und es war während unseres Hackathons, unserer Version einer Innovation, ein paar Tage voller Innovation. Es waren also acht Stunden bei einem Zoom-Gespräch mit jemandem aus Südafrika. Ich höre mir einfach ihre Erfahrung an und höre ihr zu, wie sie einen unserer Kurse durchläuft, Folie für Folie, und erklärt, was sie bei jedem Schritt erlebt hat.
Melissa Reeve:
Wenn Sie also an jemanden denken, der in einem großen Unternehmen sitzt und den Kunden vielleicht noch nie getroffen hat, den Kunden nur theoretisch kennt, an einem Ende des Spektrums. Und wenn Sie an diese Hörsitzung am anderen Ende des Spektrums denken, beginnen Sie zu verstehen, wovon wir sprechen. Nun, Ihre Frage hat wirklich darauf hingewiesen, dass Sie in agilen Praktiken jedes Mal an den Kunden denken. Theoretisch jedes Mal, wenn Sie eine Geschichte schreiben. Wenn Sie also eine Geschichte schreiben, schreiben Sie die Geschichte aus der Sicht des Kunden. Und ich würde einfach alle Marketer da draußen ermutigen, den Kunden persönlich zu kennen. Und ich weiß, dass das in diesen großen Organisationen nicht einfach ist. Es ist manchmal schwierig, mit dem Kunden persönlich ins Gespräch zu kommen, aber wenn Sie nicht direkt mit einem Kunden sprechen, kennen Sie den Kunden wahrscheinlich nicht wirklich.
Melissa Reeve:
Finden Sie also einen Weg, sprechen Sie mit den Verkäufern und telefonieren Sie mit einigen Ihrer Kundendienstmitarbeiter. Gehen Sie auf eine Messe und finden Sie einen Weg, direkt mit dem Kunden zu sprechen, denn Sie werden einige Nuancen entdecken, die sich in Ihrer Fähigkeit, den Kunden zufrieden zu stellen, auszahlen. Und wenn Sie diese Geschichte noch einmal schreiben, wird sie noch reichhaltiger sein.
Sean Blake:
Oh, das ist ein wirklich guter Rat, Melissa. Ich erinnere mich aus eigener Erfahrung, dass wir in einigen dieser großen Unternehmen, in denen ich gearbeitet habe, gesagt haben: „Oh, das ist es, was der Kunde will.“ Aber eigentlich kannten wir keine Kunden namentlich. Einige von uns persönlich waren Kunden, aber es ist nicht wirklich dasselbe wie rauszugehen und Leuten zuzuhören und was fanden sie an der Nutzung dieser App schwierig oder was erwarten sie eigentlich von diesem Produkt? Es gibt also einen riesigen Unterschied, ob man erraten muss, was ein Kunde vielleicht will oder sollte? Und dann, wie ihr Alltag tatsächlich aussieht und mit welchen Dingen sie zu kämpfen haben? Das ist ungeheuer wichtig.
Sean Blake:
Jemand, der in einem dieser großen Unternehmen arbeitet, in einem Marketingteam, hat vielleicht nicht die Macht oder den Einfluss, um zu sagen: „Okay, jetzt machen wir Agiles Marketing.“ Was wäre Ihr Rat für jemanden wie diesen, der die Vorteile darin sieht, seine Teams in diese Richtung zu bewegen, aber nicht unbedingt weiß, wo er anfangen soll?
Melissa Reeve:
Nun, es gibt eine Philosophie, die besagt, nimm, was du kriegen kannst. Wenn Sie also nur eine Person sind, die sich für Agiles Marketing einsetzt, dann ist es vielleicht das, was Sie tun können: Sie können sich dafür einsetzen. Vielleicht können Sie anfangen, Allianzen innerhalb der Organisation aufzubauen, ungezwungen mit Ihren Kollegen zu chatten, herauszufinden, ob Sie Verbündete in anderen Teilen der Organisation haben, und damit beginnen, eine Bewegung vom Typ Groundswell aufzubauen.
Melissa Reeve:
Vielleicht können Sie Ihr eigenes persönliches Kanban-Board erstellen und damit beginnen, Ihre Arbeit über Ihr eigenes Kanban-Board zu verfolgen. Und wenn Sie Ihre Arbeit auf diese Weise visualisieren, ist es jetzt, wo wir alle remote arbeiten, etwas schwieriger, aber sollten wir wieder in die Büros gehen, könnte theoretisch jemand an Ihrer Kabine vorbeigehen, Ihr Kanban-Board sehen und danach fragen. Und jetzt haben Sie vielleicht zwei Personen, die ein Kanban-Board benutzen, drei Personen. Und fangen Sie wirklich an, durch Ihre Denkweise, Ihr Verhalten, Ihre Gespräche mit gutem Beispiel voranzugehen, um Unterstützung zu erhalten.
Sean Blake:
Oh, das ist wirklich gut. Sei also die Veränderung, die du in der Organisation sehen willst.
Melissa Reeve:
Exakt.
Sean Blake:
In Ordnung. Okay, das ist wirklich gut. Und wenn diese Unternehmen sich dieser Arbeitsweise zuwenden und dann versuchen, das nächste Level zu erreichen, nehmen wir an, es beginnt in den Softwareentwicklungsteams und dann sagen wir, Marketing ist das nächste Team, das an Bord kommt. Wie verbreitet es sich dann in der gesamten Organisation? Weil ich aus eigener Erfahrung weiß, dass es für die Agile-Teams immer noch sehr schwierig ist, etwas zu erledigen, wenn es immer noch diesen Teil der Organisation gibt, der gegen Agile arbeitet. Weil es immer noch die Blockaden und die Prozesse und Genehmigungen gibt, die Sie mit den anderen Teams durchgehen müssen. Und ich denke, SAFe ist die Antwort, oder? Aber wie fängt man an, Agile im gesamten Unternehmen einzusetzen?
Melissa Reeve:
Sicher. Und worüber Sie sprechen, ist wirklich geschäftliche Agilität, bedeutet, das gesamte Unternehmen zu nehmen und das Unternehmen agil zu machen. Und Sie haben auf etwas hingewiesen, das dafür entscheidend ist: Sobald Sie den Engpass und die Hindernisse in einem Geschäftsbereich gelöst haben, wird es in einen anderen Geschäftsbereich verlagert. Der Vorteil der geschäftlichen Flexibilität besteht also darin, dass Sie versuchen, zu verhindern, dass sich diese Engpässe bilden oder verschieben. Aber ein Engpass führt im Wesentlichen dazu, dass er eine so genannte brennende Plattform schafft. Es entsteht also ein Bedürfnis nach Veränderung. Und genau das sehen wir auf der Marketingseite: Wir haben diese IT-Organisationen, sie arbeiten viel effizienter mit dem Einsatz von Agile und mit dem Einsatz von SAFe. Und was passiert, ist, dass die Softwareteams in der Lage sind, Dinge schneller zu veröffentlichen als die Teams, die sie umgeben. Eines davon könnte das Marketing sein.
Melissa Reeve:
Und so wird das Marketing jetzt dazu angeregt, nach Möglichkeiten der Veränderung zu suchen. Sie erhalten Anreize, einen Blick darauf zu werfen und zu sagen: „Nun, vielleicht ist Agile die Antwort für uns.“ Sagen wir einfach, das Marketing springt an Bord und plötzlich dreht es sich um, und abgesehen davon bleibt alles in der Rechtsabteilung hängen. Und jetzt hat die Rechtsabteilung Argumente für Änderungen und den Druck auf die Rechtsabteilung, sie anzunehmen. Es gibt also eine Möglichkeit, es organisch verbreiten zu lassen. Die meisten Transformationstrainer werden dieses Phänomen verstehen und das Unternehmen wahrscheinlich dazu ermutigen, einfach alles auf Agile umzustellen, natürlich nicht in einer Art Urknall, sondern sich schrittweise in diese Richtung zu bewegen, sodass wir nicht einfach ständig Engpässe verschieben.
Sean Blake:
In Ordnung. Okay, das macht Sinn. Und wenn diese Unternehmen versuchen, die geschäftliche Agilität in den verschiedenen Funktionen zu verbessern, gibt es dann einige Fehler, die Sie sagen, immer wieder auftauchen? Und wie können wir diese vermeiden, wenn wir uns auf diesem Weg der geschäftlichen Agilität befinden?
Melissa Reeve:
Ja. Ich habe das Gefühl, dass der häufigste Fehler, zumindest der, den ich im Marketing am häufigsten sehe, obwohl ich ihn auch bei Software gesehen habe, darin besteht, dass die Leute denken, dass es bei der Transformation um Prozesse oder Tools geht. So könnten sie beispielsweise im Marketing ein Tool einsetzen, um „agiler zu werden“. Vielleicht ist es ein Kanban-Visualisierungstool, oder vielleicht wird ihnen vorgeschlagen, ein anderes gängiges ALM-Tool zu verwenden. Also nehmen sie dieses Tool an und lernen, wie man es benutzt, und sie fragen sich, warum sie keine großen Verbesserungen sehen.
Melissa Reeve:
Und das liegt daran, dass Agile im Kern eine menschliche Transformation ist. Wir schauen uns also wirklich an, wie wir versuchen, die Denkweise der Menschen zu ändern. Eines der Themen, über die ich spreche, ist die Geschichte der Managementtheorie. Und obwohl es ziemlich trocken klingt, öffnet es in Wirklichkeit die Augen. Weil Sie wissen, dass viele der Gewohnheiten, die wir heute haben, im 20. und 19. Jahrhundert wurzeln. Sie sind also in Montagelinien verwurzelt. Sie wurzeln in der französischen Managementtheorie, die Kommando und Kontrolle befürwortete.
Melissa Reeve:
Sie wurzeln im Klassismus. Es gab eine Managementklasse und eine Arbeiterklasse, und die Managementklasse wusste, wie man Dinge am besten macht. Es ist also mehr als ein Prozess, mehr als ein Instrument, wir sprechen davon, dieses Erbe des Managementdenkens in eine Art und Weise zu transformieren, die für die Arbeitnehmer von heute angemessen ist. Und ich glaube, das ist der größte Fehler, den Unternehmen meiner Meinung nach bei der Umstellung auf Agile, eine agile Arbeitsweise, begehen.
Sean Blake:
Mm-hmm (bejahend). In Ordnung. Ja, das ist wirklich interessant. Und es öffnet wirklich die Augen, oder? Wenn man sich anschaut, wie der Arbeitstag von neun bis fünf zustande kam, denn das ist die Zeit, in der die Fabriken geöffnet waren, und die ganze Geschichte rund um die Struktur von Organisationen. Und ich denke, es ist wirklich wichtig, einige der Dinge, die wir in der Vergangenheit getan haben und die im Industriezeitalter funktioniert haben, in Frage zu stellen. Aber jetzt bewegen wir uns in das Informationszeitalter und in diese Zeiten der digitalen Transformation. Es funktioniert wahrscheinlich nicht mehr für uns, oder, einige dieser Dinge? Oder glauben Sie, dass einige dieser Dinge immer noch wertvoll sind, jetzt, wo wir verteilte Teams haben und viele Leute remote arbeiten? Gibt es Dinge, die dir in den Sinn kommen, von denen du denkst, dass wir sie eigentlich noch nicht loswerden sollten?
Melissa Reeve:
Oh, ich bin mir sicher, dass es welche gibt. John Kotter hat in seinem Buch Accelerate das Konzept eines dualen Betriebssystems vorgestellt. Sie haben also den Netzwerkteil der Organisation, der sich schnell und flexibel wie ein Startup bewegt, und dann haben Sie den hierarchischen Teil der Organisation. Und die Hierarchie ist sehr, sehr gut darin, Dinge zu skalieren. Es ist eine gut geölte Maschine. Sie benötigen jemanden, der Ihre Spesenabrechnung genehmigt. Sie benötigen einige Richtlinien und einige Richtlinien, einige Leitplanken. Wir sagen also nicht wirklich, dass die Hierarchie abgeschafft werden soll. Und ich habe das Gefühl, dass das Teil dieses alten Systems ist. Aber was wir sagen, ist, einen Teil des Befehls und der Kontrolle abzuschaffen, diese Vorstellung, dass das Management den besten Weg kennt, weil der Wissensarbeiter oft mehr weiß als sein Manager.
Melissa Reeve:
Es ist einfach zu schwierig für einen Manager, mit allem Schritt zu halten, was in den Köpfen der Personen vor sich geht, die ihm oder ihr Bericht erstatten. Das ist also eine wirklich große Veränderung und es war eine Veränderung für mich. Und ich denke, warum mich diese Geschichte der Managementtheorie so fasziniert hat, ist, dass ich auf einige Notizen aus meiner Collegezeit gestoßen bin. Und mir wurde klar, dass mir diese historischen Managementtheorien beigebracht worden waren. Mir wurde der Taylorismus beigebracht, der aus dem Jahr 1911 stammt. Und mir wurde klar, wow, ich musste eine Menge rückgängig machen, um diese agile Arbeitsweise zu übernehmen.
Sean Blake:
Nun, das ist großartig. Ja, das ist wirklich wichtig, nicht wahr? Ich habe Sie schon einmal über das Konzept der Walk-up-Arbeit sprechen hören, besonders im Bereich Marketing. Aber ich nehme an, nun, zunächst würde ich gerne wissen, was Walk-up-Arbeit ist. Warum ist es so gefährlich, nicht nur für Marketer, sondern für alle Teams? Und wie fangen wir an, uns gegen Walk-up-Arbeit zu wehren?
Melissa Reeve:
Ja. Also, vor allem Marketer werden mit dem bombardiert, was ich gerne als Walk-up-Arbeit bezeichne. Und dann kommt buchstäblich eine Führungskraft oder sogar ein Kollege zu mir, also denken Sie noch einmal über die Cubicle-Farm nach und stellen eine Anfrage. In der virtuellen Welt sieht das also so aus, als ob es die Lücke oder die Sofortnachricht „Hey, würde es dir etwas ausmachen?“ Zum einen führt dies zu einer Menge Kontextwechsel, und bei diesem Kontextwechsel geht Zeit verloren. Und der andere Teil ist, dass diese Anfragen selten klar definiert oder sogar mit einer gewissen Frist eingehen. Im Marketing könnte das so aussehen: „Hey, kannst du diese Grafik für diese E-Mail erstellen, die ich versende?“ Jetzt haben Sie Ihrer armen Grafikdesignerin das Wissen gegeben, dass sie hier eine Grafik erstellen muss, aber sie hat nicht wirklich die Spezifikationen.
Melissa Reeve:
Es ist also sehr, sehr hilfreich, diese Dinge in Geschichten zusammenzufassen, dem Agile-Prozess zu folgen, bei dem du die Walk-up-Arbeit zum Product Owner übernimmst, wo der Product Owner mit dir zusammenarbeiten kann, um die Geschichte zu definieren, die Person, die die Arbeit macht, an der Aufgabe zu halten, sie nicht dazu zu bringen, den Kontext zu wechseln oder so. Definieren Sie die Geschichte in den Akzeptanzkriterien sehr gut und priorisieren Sie sie, bevor die Arbeit dann in die Warteschlange des Grafikdesigners kommt. Und das ist ein Anti-Muster, egal ob Sie von einer Organisation mit 50 oder 5.000 Mitarbeitern sprechen.
Melissa Reeve:
Und ich habe festgestellt, dass das Verhalten der Führungskräfte am schwierigsten zu ändern ist. Weil sie nicht nur unbeaufsichtigt arbeiten, sondern auch über positionelle Autorität verfügen. Und das impliziert, dass diese Person aufhört, an dem zu arbeiten, woran sie gerade arbeitet, und sofort zu der Walk-up-Arbeit übergeht, die von der Führungskraft definiert wird. Ich habe also das Gefühl, dass es wirklich gefährlich für das gesamte Agile-Ökosystem ist, weil es den Kontext wechselt, es unterbricht den Arbeitsfluss und führt zu Verschwendung in das System. Und an Ihren Punkten mit der höchsten Priorität wird möglicherweise nicht gearbeitet.
Sean Blake:
In Ordnung. Also, wie viele Leute haben Sie in Ihrem Marketingteam bei Scaled Agile?
Melissa Reeve:
Wir sind immer noch ziemlich klein. Wir sind ungefähr in den 20ern, 23, 25, mehr oder weniger.
Sean Blake:
Also, wie kannst du...
Melissa Reeve:
Ich denke, im Moment sind wir drei agile Teams.
Sean Blake:
Drei. In Ordnung. Also diese 20 sind in drei Agile-Teams aufgeteilt. Und haben sie jeweils einen Product Owner oder wie funktioniert die Priorisierung des Marketings in Ihren Teams?
Melissa Reeve:
Ja, das ist eine gute Frage. Wir haben also individuelle Product Owner für diese drei Produktteams. Und was faszinierend ist, ist, dass sich die Product Owner dann auch sehr regelmäßig treffen müssen, um sicherzustellen, dass die Prioritäten aufeinander abgestimmt bleiben. Denn wie viele Marketingteams verfügen auch wir nicht über spezielle Fähigkeiten in jedem dieser Teams. Für die Gruppe von 23 Personen haben wir also nur einen Texter. Für die Gruppe von 23 haben wir zwei Grafikdesigner. Es ist also nicht so, dass jedes Team seinen eigenen Grafikdesigner oder seinen eigenen Texter hat.
Sean Blake:
Ja.
Melissa Reeve:
Das heißt, die drei POs müssen sich zusammensetzen und die Prioritäten festlegen, die gemeinsamen Prioritäten für den Texter, die gemeinsamen Prioritäten für diese Grafikdesigner. Und ich denke, es funktioniert. Ich meine, es ist nicht ohne Schluckauf, aber ich denke, das ist die Rolle der PO und es ist eine wichtige Rolle.
Sean Blake:
Wie vermeidest du also die Versuchung, zu diesen Teams zu kommen und zu sagen: „Lass das, was du tust, es gibt etwas Neues, an dem wir alle arbeiten müssen?“ Finden Sie es als Führungskraft selbst eine Herausforderung, die Teams wirklich autonom und selbstorganisiert arbeiten zu lassen?
Melissa Reeve:
Ja, ich denke, der größte Gefallen, den wir den Teams getan haben, ist wirklich, ich möchte nicht sagen, verbotene Walk-up-Arbeit, aber als Erstes haben wir es definiert. Und wir sagten: „Walk-up-Arbeit ist alles, was länger als zwei Stunden dauert und das nicht Teil der Iterationsplanung war.“ Und die Iteration dauert nur zwei Wochen. Theoretisch haben Sie es also in den letzten 10 Tagen getan. Wenn es also nicht dazu gehörte und Sie es nicht auf die nächste Iterationsplanung verschieben können und ein Gefühl der Dringlichkeit entsteht, dann ist es Walk-up-Arbeit.
Melissa Reeve:
Und wir haben die Teams an einem Punkt angelangt, an dem sie die Angewohnheit haben, dann die PO anzurufen und zu sagen: „Hey, würde es dir etwas ausmachen, mit so und so zu sprechen und das zu definieren und mir zu helfen, zu verstehen, wo das in die Prioritätsreihenfolge passt.“ Und das war wirklich die größte Hürde, denn als Marketer denke ich, dass viele von uns Ja sagen wollen, wenn jemand mit Arbeit auf uns zukommt. Aber was passiert ist, ist, dass die Leute, ich eingeschlossen, aufgehört haben, sich an die Texter zu wenden, aufgehört haben, sich mit Arbeit an den Grafikdesigner zu wenden. Aber ich weiß es einfach, geh zur Polizei.
Sean Blake:
Das ist gut. Es ist also eine zusätzliche Verteidigungslinie für das Team, sodass es sich weiterhin auf seine Prioritäten und das konzentrieren kann, woran es bereits gearbeitet hat, ohne von diesen neuen Ideen und Prioritäten abgelenkt zu werden.
Melissa Reeve:
Ja. Und tatsächlich, glaube ich, haben wir in diesem letzten Fall die Arbeit vor Ort von 23% auf 11% reduziert. Wir sind also nicht bei 100% Und ich weiß nicht, ob wir jemals 100% erreichen werden, aber wir sehen sicherlich Fortschritte in dieser Richtung.
Sean Blake:
Oh, das ist wirklich gut. Wirklich gut. Und so arbeiten Ihre Marketingteams agil. Haben Sie das Gefühl, dass Agile auf breiter Front, nicht nur innerhalb Ihres Unternehmens, sondern auch ganz allgemein, von Teams ohne technischen Hintergrund, also von Marketing-, Rechts- und Finanzteams, übernommen wird? Setzen diese Teams ohne technischen Hintergrund Agile schneller ein, oder haben Sie das Gefühl, dass es immer noch einige Jahre dauern wird, bis die Botschaft verbreitet wird?
Melissa Reeve:
Ja. Und ich schätze, meine Frage an Sie wäre, schneller als was?
Sean Blake:
Gute Frage. Ich nehme an, was ich frage ist, haben Sie das Gefühl, dass dies ein Trend ist, dass Teams ohne technischen Hintergrund Agile einführen, oder ist das etwas, das wirklich noch in den Kinderschuhen steckt und sich noch nicht wirklich durchgesetzt hat, insbesondere bei Scaled Agile-Kunden oder Personen, mit denen Sie in der Agile-Branche verbunden sind?
Melissa Reeve:
Ich würde ja sagen. Ja, das ist ein Trend. Und ja, die Leute machen es. Und ja, es steckt noch in den Kinderschuhen.
Sean Blake:
Also, ja?
Melissa Reeve:
Ja. Also all das zusammen, und ich werde dir nichts vormachen, ich meine, das ist neues Zeug. Tatsächlich, als Teil der Hörsitzung, die ich erwähnt habe, und wir haben über all diese verschiedenen Bereiche des Unternehmens gesprochen. Und es wurde erwähnt, dass das Scaled Agile Framework als Leitfaden für diese Teams dient. Für die Personalabteilung, für die Rechtsabteilung und für das Marketing könnte es robuster sein. Und die Antwort ist absolut. Und der Grund ist, dass wir immer noch selbst lernen. Das ist brandneues Gebiet, auf dem wir uns die Zähne ausbeißen. Ich schätze, wir werden mehrere Jahre brauchen, ich weiß nicht, wie viele es sind, bis wir anfangen zu lernen, herauszufinden, wie das aussieht, und es wirklich umzusetzen.
Melissa Reeve:
Jetzt hoffe ich, dass wir an einen Punkt kommen, an dem Agile in der gesamten Organisation zum Einsatz kommt und dass es an die verschiedenen Umgebungen angepasst wurde. Wenn ich das gesehen habe und Dinge wie Agile HR, Agile Legal, Agile Procurement durchdacht habe, scheinen die Grundlagen solide zu sein. Wir können sogar Dinge wie die Continuous Delivery Pipeline von DevOps. Wenn ich an Marketing denke und an Automatisierung denke. Und ich denke über künstliche Intelligenz nach, ja, ich sehe das im Marketing und ich sehe die Notwendigkeit, dass sich das entfaltet, aber werden wir eine Weile brauchen, um diese Nuance herauszufinden? Absolut.
Sean Blake:
In Ordnung. Und können Sie sich weitere Trends im agilen Bereich vorstellen? Wissen Sie, wenn wir in die Zukunft schauen, sagen wir 10 Jahre, ein Jahrzehnt, wie sieht dann die Arbeitsweise aus? Sind wir alle immer noch remote oder wie werden Teams in 10 Jahren an digitale Transformationen herangehen? Was ist Ihre Perspektive auf die Zukunft?
Melissa Reeve:
Ja, ich meine, manchmal schaue ich gerne in die Vergangenheit, um in die Zukunft zu schauen. Und in diesem Fall schaue ich vielleicht 10 oder 12 Jahre in die Vergangenheit. Und vor 12 Jahren bekam ich mein allererstes iPhone. Ich erinnere mich, dass es 2007, 2008 war. Und du denkst darüber nach, was für eine seismische Veränderung das in Bezug auf unser Verhalten und die sozialen Medien war, wie wir uns verbinden und diesen Computer in unserer Hand haben. Also frage ich mich, welcher seismische Wandel liegt vor uns? Und sicherlich hat COVID einige dieser Veränderungen beschleunigt. Ich frage mich, werde ich so oft in Flugzeugen sitzen wie in der Vergangenheit? Oder haben wir uns alle so an Zoom-Meetings gewöhnt, dass wir gemerkt haben, dass dort Strom steckt. Und wir müssen nicht unbedingt in ein Flugzeug steigen, um den Wert zu nutzen.
Melissa Reeve:
Was Agile angeht, habe ich das Gefühl, dass wir es in 10 Jahren nicht mehr agil nennen werden. Ich habe das Gefühl, dass es eher nach einer Organisation mit kontinuierlichem Lernen oder einer reaktionsschnellen Organisation aussehen wird. Agile bezieht sich auf eine sehr spezifische Reihe von Praktiken. Und wenn diese neue Denkweise, nun ja, die Praktiken und die Prinzipien und die Denkweise, und wenn sich diese neue Denkweise durchsetzt und zur Norm wird, werden wir sie dann Agile nennen? Oder wird es einfach die Art und Weise sein, wie die Leute arbeiten? Ich schätze, es wird anfangen, sich dem Letzteren zuzuwenden.
Sean Blake:
Nun, hoffen wir, dass es normal wird, oder? Ich meine, es wäre toll, mehr Transparenz, mehr funktionsübergreifende Arbeit, weniger Außeneinsätze und mehr geschäftliche Agilität auf der ganzen Linie zu haben, nicht wahr? Ich denke, es wäre toll, wenn das zur neuen Normalität würde.
Melissa Reeve:
Ja, ich auch. Ja. Und ich glaube, wir rufen nicht an, wie wir mit Menschen umgehen. Wir sagen nicht: „Oh, das ist Taylorismus. Wirst du Taylorismus praktizieren? So haben wir entweder in der Schule gelernt oder von unseren Chefs gelernt, wie man mit Menschen umgeht. Und das ist meine Hoffnung für Agile, dass wir es nicht so nennen werden. So machen wir die Dinge hier einfach.
Sean Blake:
Großartig. Tja, Melissa, ich denke, wir lassen es dabei. Ich habe unser Gespräch wirklich genossen, besonders als Vermarkter. Es ist toll, Ihren Einblick in die Branche zu hören. Und alles, was wir heute besprochen haben, hat mir wirklich, wirklich die Augen geöffnet. Also vielen Dank, dass du das mit mir und unserem Publikum geteilt hast. Und wir hoffen, Sie in Zukunft wieder im Podcast zu haben.
Melissa Reeve:
Sean, es war mir eine große Freude und ich komme jederzeit gerne wieder.
Sean Blake:
Großartig. Vielen Dank.
Melissa Reeve:
Ich danke dir.
PodcastEasy Agile Podcast Ep.20 Die Bedeutung der Team-Retrospektive
„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.