Easy Agile Podcast Ep.6 Chris Stone, der virtuelle Agile Coach

„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.

„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.

In this insightful episode, we dive deep into one of the most common frustrations in engineering and dev teams: retrospectives that fail to drive meaningful change. Join Jaclyn Smith, Senior Product Manager at Easy Agile, and Shane Raubenheimer, Agile Technical Consultant at Adaptavist, as they unpack why retrospectives often become checkbox exercises and share practical strategies for transforming them into powerful engines of continuous improvement.

Want to put these insights into practice? Join Jaclyn and Shane for their live, hands-on webinar on July 10th where they'll show you exactly how to transform your retrospectives with practical tools and techniques you can implement immediately.

Key topics covered:

• Common retrospective anti-patterns and why teams become disengaged
• The critical importance of treating action items as "first-class citizens"
• How to surface recurring themes and environmental issues beyond team control
• Practical strategies for breaking down overwhelming improvement initiatives
• The need for leadership buy-in and organizational support for retrospective outcomes
• Moving from "doing agile" to "being agile" through effective reflection and action

This conversation is packed with insights for making your retrospectives more impactful and driving real organizational change.

About our guests

Jaclyn Smith is a Senior Product Manager at Easy Agile, where she leads the Easy Agile TeamRhythm product that helps teams realize the full benefits of their practices. With over five years of experience as both an in-house and consulting agile coach, Jaclyn has worked across diverse industries helping teams improve their ways of working. At Easy Agile, she focuses on empowering teams to break down work effectively, estimate accurately, and most importantly, take meaningful action to continuously improve their delivery and collaboration.

Shane Raubenheimer is an Agile Technical Consultant at Adaptavist, a global family of companies that combines teamwork, technology, and processes to help businesses excel. Adaptavist specializes in agile consulting, helping organizations deliver customer value through agile health checks, coaching, assessments, and implementing agile at scale. Shane brings extensive experience working across multiple industries—from petrochemical to IT, digital television, and food industries—applying agile philosophy to solve complex organizational challenges. His expertise spans both the technical and cultural aspects of agile transformation.

Transcript

This transcript has been lightly edited for clarity and readability while maintaining the authentic conversation flow.

Opening and introductions

Jaclyn Smith: Hi everyone, and welcome back to the Easy Agile Podcast. Today I'm talking to Shane Raubenheimer, who's with us from Adaptavist. Today we're talking about why your retrospectives keep failing and how to finally fix them. Shane, you and I have spent a fair amount of time together exploring the topic of retros, haven't we? Do you want to tell us a little bit about yourself first?

Shane Raubenheimer: Yeah, hello everyone. I'm Shane Raubenheimer from Adaptavist. I am an agile coach and technical consultant, and along with Jaclyn, we've had loads of conversations around why retros don't work and how they just become tick-box exercises. Hopefully we're going to demystify some of that today.

Jaclyn Smith: Excellent. What's your background, Shane? What kind of companies have you worked with?

Shane Raubenheimer: I've been privileged enough to work across multiple industries—everything from petrochemical to IT, to digital television, food industry. All different types of applied work, but with the agile philosophy.

Jaclyn Smith: Excellent, a big broad range. I should introduce myself as well. My name is Jaclyn. I am a Senior Product Manager here at Easy Agile, and I look after our Team Rhythm product, which helps teams realize the benefits of being agile. I stumbled there because our whole purpose at Easy Agile is to enable our customers to realize the benefits of being agile.

My product focuses on team and teamwork, and teamwork happens at every level as we know. So helping our customers break down work and estimate work, reflect—which is what we're talking about today—and most importantly, take action to improve their ways of working. I am an agile coach by trade as well as a product manager, and spent about five years in a heap of different industries, both as a consultant like you Shane, and as an in-house coach as well.

The core problem: When retrospectives become checkbox exercises

Jaclyn Smith: All right, let's jump in. My first question for you Shane—I hear a lot that teams get a bit bored with retros, or they face recurring issues in their retrospectives. Is that your experience? Tell me about what you've seen.

Shane Raubenheimer: Absolutely. I think often what should be a positive rollup and action of a sequence of work turns out to normally become a checkbox exercise. There's a lot of latency in the things that get uncovered and discussed, and they just tend to perpetually roll over. It almost becomes a checkbox exercise from what I've seen, rather than the mechanism to actively change what is happening within the team—but more importantly, from influences outside the team.

I think that's where retros fail, because often the team does not have the capability to do any kind of upward or downstream problem solving. They tend to just mull about different ways to ease the issues within the team by pivoting the issues rather than solving them.

I think that's where retros fail, because often the team does not have the capability to do any kind of upward or downstream problem solving. They tend to just mull about different ways to ease the issues within the team by pivoting the issues rather than solving them.

Jaclyn Smith: Yeah, I would agree. Something that I see regularly too is because they become that checkbox, teams get really bored of them. They do them because they're part of their sprint, part of their work, but they're not engaged in them anymore. It's just this thing that they have to do.

It also can promote a tendency to just look at what's recently happened and within their sphere of influence to solve. Whereas I think a lot of the issues that sometimes pop up are things that leadership need to help teams resolve, or they need help to solve. It can end up with them really focusing on "Oh well, there's this one bit in how we do our code reviews, we've got control over that, we'll try to fix that." Or as you say, the same recurring issues come up and they don't seem to get fixed—they're just the same complaints every time.

Shane Raubenheimer: Absolutely. You find ways that you put a band-aid on them just so you can get through to the next phase. I think the problem with that is the impact that broader issues have on teams is never completely solvable within that space, and it's no one else's mandate necessarily to do it. When an issue is relatable to a team, exposing why it's not a team-specific issue and it's more environmental or potentially process-driven—that's the bit that I feel keeps getting missed.

When an issue is relatable to a team, exposing why it's not a team-specific issue and it's more environmental or potentially process-driven—that's the bit that I feel keeps getting missed.

The pressure problem and overwhelming solutions

Jaclyn Smith: Yeah, I think so too. The other thing you just sparked for me—the recurring issue—I think that also happens when the team are under pressure and they don't feel like they have the time to solve the problems. They just need to get into the next sprint, they need to get the next bit of work done. Or maybe that thing that they need to solve is actually a larger thing—it's not something small that they can just change.

They need to rethink things like testing strategies. If that's not working for you, and it's not just about fixing a few flaky tests, but you need to re-look at how you're approaching testing—it seems overwhelming and a bit too big.

Shane Raubenheimer: Absolutely. Often environmental issues are ignored in favor of what you've been mandated to do. You almost retrofit the thing as best you can because it's an environmental issue. But finding ways to expose that as a broader-based issue—I think that should be the only output, especially if it's environmental and not team-based.

The problem of forgotten action items

Jaclyn Smith: Something I've also seen recently is that teams will come up with great ideas of things that they could do. As I said before, sometimes they're under pressure and they don't feel they have the capacity to make those changes. Sometimes those actions get talked about, everyone thinks it's a wonderful idea, and then they just get forgotten about. Teams end up with this big long backlog of wonderful experiments and things that they could have tried that have just been out of sight, out of mind. Have you seen much of that yourself?

Shane Raubenheimer: Plenty. Yes, and often teams err on the side of what's expected of them rather than innovate or optimize. I think that's really where explaining the retrospective concept to people outside fully-stacked or insular teams is the point here. You need, very much like in change management, somebody outside the constructs of teams to almost champion that directive—the same way as you would do lobbying for money or transformation. It needs to be taken more seriously and incorporated into not just teams being mini-factories supporting a whole.

You transform at a company level, you change-manage at a company level. So you should action retrospective influences in the same way. Naturally you get team-level ones, and that's normally where retrospectives do go well because it's the art of the possible and what you're mandated to do. I think bridging the gap between what we can fix ourselves and who can help us expose it is a big thing.

I see so much great work going to waste because it simply isn't part of the day job, or should be but isn't.

You transform at a company level, you change-manage at a company level. So you should action retrospective influences in the same way.

Making action items first-class citizens

Jaclyn Smith: Yeah, absolutely. I know particularly in the pre-Covid times when we were doing a lot of retros in person, or mostly in person with stickies on walls, I also found even if we took a snapshot of the action column, it would still end up on a Confluence board or something somewhere and get forgotten about. Then the next retro comes around and you sort of feel like you're starting fresh and just looking at the last sprint again. You're like, "Oh yeah, someone raised that last retro, but we still didn't do anything about that."

Shane Raubenheimer: I think Product Owners, Scrum Masters, or any versions of those kinds of roles need to treat environmental change or anti-pattern change as seriously as they treat grooming work—the actual work itself. Because it doesn't matter how good you are if the impediments that are outside of your control are not managed or treated with the same kind of importance as the actual work you're doing. That'll never change, it'll just perpetuate. Sooner or later you hit critical mass. There's no scenario where your predictability or velocity gets better if these things are inherent to an environment you can't control.

Product Owners, Scrum Masters, or any versions of those kinds of roles need to treat environmental change or anti-pattern change as seriously as they treat grooming work—the actual work itself.

Jaclyn Smith: Yeah, that's true. We've talked about action items being first-class citizens and how we help teams do that for that exact reason. Because a retro is helpful to build relationships and empathy amongst the team for what's happening for each of them and feel a sense of community within their team. But the real change comes from these incremental changes that are made—the conversations that spark the important things to do to make those changes to improve how the team works.

That action component is really the critical part, or maybe one of two critical parts of a retro. I feel like sometimes it's the forgotten child of the retro. Everyone focuses a lot on engaging people in getting their ideas out, and there's not as much time spent on the action items and what's going to be done or changed as a result.

Beyond team-level retrospectives

Shane Raubenheimer: Absolutely, consistently. I think it's symptomatic potentially of how retros are perceived. They're perceived as an inward-facing, insular reevaluation of what a team is doing. But I've always thought, in the same way you have the concept of team of teams, or if you're in a scaled environment like PI planning, I feel retrospectives need the same treatment or need to be invited to the VIP section to become part of that.

Because retrospectives—yes, they're insular or introspective—but they need to be exposed at the same kind of level as things like managing your releases or training or QA, and they're not.

Jaclyn Smith: Yeah, I think like a lot of things, they've fallen foul of the sometimes contentious "agile" word. People tend to think, "Oh retros, it's just one of those agile ceremonies or agile things that you do." The purpose of them can get really lost in that, and how useful they can be in creating change. At the end of the day, it's about improving the business outcomes. That's why all of these things are in place—you want to improve how well you work together so that you can get to the outcome quicker.

At the end of the day, it's about improving the business outcomes. That's why all of these things are in place—you want to improve how well you work together so that you can get to the outcome quicker.

Shane Raubenheimer: Absolutely. Outcome being the operative word, not successfully deploying code or...

Jaclyn Smith: Or ticking the retro box, successfully having a retro.

Shane Raubenheimer: Yeah, exactly. Being doing agile instead of being agile, right?

Expanding the scope of retrospectives

Jaclyn Smith: One hundred percent. It also strikes me that there is still a tendency for retros to be only at a team level and only a reflection of the most recent period of time. So particularly if a team are doing Scrum or some version of Scrum with sprints, to look back over just the most recent period. I think sometimes the two things—the intent of a retro but also the prime directive of the retro—gets lost.

In terms of intent, you can run a retro about anything. Think about a post-mortem when you have an incident and everyone gets together to discuss what happened and how we prevent that in the future. I think people forget that you can have a retro and look at your system of work, and even hone in on something like "How are we estimating? Are we doing that well? Do we need to improve how we're doing that?" Take one portion of what you're working on and interrogate it.

You can run a retro about anything. I think people forget that you can have a retro and look at your system of work, and even hone in on something like "How are we estimating? Are we doing that well? Do we need to improve how we're doing that?" Take one portion of what you're working on and interrogate it.

Understanding anti-patterns

Shane Raubenheimer: Absolutely. You just default to "what looks good, what can we change, what did we do, what should we stop or start doing?" That's great and all, but without some kind of trended analysis over a period of time, you might just be resurfacing issues that have been there all along. I think that's where the concept or the lack of understanding of anti-patterns comes in, because you're measuring something that's happened again rather than measuring or quantifying why is it happening at all.

I think that's the big mistake of retros—it's almost like an iterative band-aid.

I think that's the big mistake of retros—it's almost like an iterative band-aid.

Jaclyn Smith: Yeah. Tell me a little bit more about some of the anti-patterns that you have seen or how they come into play.

Shane Raubenheimer: One of them we've just touched on—I think the buzzword for it is the cargo cult culture for agile. That's just cookie-cutting agile, doing agile because you have to instead of being agile. Literally making things like your stand-up or your review or even planning just becomes "okay, well we've got to do this, so we've ticked the box and we're following through."

Not understanding the boundaries of what your method is—whether you like playing "wagile" or whether you're waterfall sometimes, agile at other times, and you mistake that variability as your agility. But instead, you don't actually have an identity. You're course-correcting blindly based on what's proportionate to what kind of fire you've got in your way.

Another big anti-pattern is not understanding the concept of what a team culture means and why it's important to have a team goal or a working agreement for your team. Almost your internal contracting. We do it as employees, right?

I think a lot of other anti-patterns come in where something's exposed within a team process, and because it's not interrogated or cross-referenced across your broader base of teams, it's not even recognized as a symptom. It is just a static issue. For me, that's a real anti-pattern in a lot of ways—lack of directive around what to do with retrospectives externally as well as internally. That's simply not a thing.

A lot of other anti-patterns come in where something's exposed within a team process, and because it's not interrogated or cross-referenced across your broader base of teams, it's not even recognized as a symptom. It is just a static issue. For me, that's a real anti-pattern in a lot of ways—lack of directive around what to do with retrospectives externally as well as internally.

Jaclyn Smith: Yeah, I think that's a good call-out for anyone watching or listening. If you're not familiar with anti-patterns, they're common but ineffective responses to recurring problems. They may seem helpful initially to solve an immediate problem, but they ultimately lead to negative outcomes.

Shane, what you just spoke about there with retrospectives—an example of that is that the team feel disengaged with retrospectives and they're not getting anything useful out of it, or change isn't resulting from the retrospectives. So the solution is to not hold them as frequently, or to stop doing them, or not do them at different levels or at different times. That's a really good example of an anti-pattern. It does appear to fix the problem, but longer term it causes more problems than it solves.

Another one that I see is with breaking down work. The idea that spending time together to understand and gain a shared understanding of the work and the outcome that you need takes a lot of time, and breaking down that work and getting aligned on how that work is going to break down on paper can look like quite an investment. But it's also saving time at the other end, reducing risk, reducing duplication and rework to get a better outcome quicker. You shift the time spent—development contracts because you've spent a little bit more time discovering and understanding what you're doing.

A common anti-pattern that I see there is "we spent way too long looking at this, so we're going to not do discovery in the same way anymore," or "one person's going to look at that and break it down."

The budget analogy

Shane Raubenheimer: I always liken it to your budget. The retrospective is always the nice shiny holiday—it's always the first to go.

I always liken it to your budget. The retrospective is always the nice shiny holiday—it's always the first to go.

Jaclyn Smith: It's the contractor.

Shane Raubenheimer: Yeah. It's almost like exposing stuff that everybody allegedly knows to each other is almost seen as counterintuitive because "we're just talking about stuff we all know." It often gets conflated into "okay, we'll just do that in planning." But the reality is the concept of planning and how you amend what you've done in the retrospective—that's a huge anti-pattern because flattening those structures from a ceremonies perspective is what teams tend to do because of your point of "well, we're running out of daylight for doing actual development."

But it's hitting your head against the wall repeatedly and hoping for a different outcome without actually implying a different outcome. Use a different wall even. I think it's because people are so disillusioned with retrospectives. I firmly believe it's not an internal issue. I believe if the voices are being heard at a budgeting level or at a management level, it will change the whole concept of the retrospective.

Solution 1: Getting leadership buy-in

Jaclyn Smith: I like it, and that's a good thread to move on to. So what do we do about it? How do we help change this? What are some of the practical tips that people can deploy?

Shane Raubenheimer: A big practical tip—and this is going to sound like an obvious one—is actual and sincere buy-in. What I mean by that is, as a shareholder, if I am basing your performance and your effectiveness on the quality and output of the work that you're promising me, then I should be taking the issues that you're having that are repeating more seriously.

Because if you're course-correcting for five, six, or seven sprints and you're still not getting this increasing, predictable velocity, and if it's not your team size or your attitude, it's got to be something else. I often relate that to it being environmental.

Buying into the outputs for change the same way as you would into keeping everyone honest, managing budgets, and chasing deadlines—it should all be part of the same thing. They should all be sitting at the VIP table, and I think that's a big one.

Buying into the outputs for change the same way as you would into keeping everyone honest, managing budgets, and chasing deadlines—it should all be part of the same thing. They should all be sitting at the VIP table.

Solution 2: Making patterns visible

Jaclyn Smith: I think so too. Something that occurs to me, and it goes back to what we were talking about right at the beginning, is sometimes identifying that there's a pattern there and that the same thing keeps coming up isn't actually visible, and that's part of the problem, right?

I know some things we've been doing in Easy Agile TeamRhythm around that recently, attempting to help teams with this. We've recently started surfacing all incomplete action items in retrospectives so people can see that big long list. Because they can convert their action items to Jira items or work items, they can also see where they've just been sitting and languishing in the backlog forever and a day and never been planned for anything to be done about them.

We've recently started surfacing all incomplete action items in retrospectives so people can see that big long list. Because they can convert their action items to Jira items or work items, they can also see where they've just been sitting and languishing in the backlog forever and a day and never been planned for anything to be done about them.

We've added a few features to sort and that kind of thing. Coming in the future—and we've been asked about this a lot—is "what about themes? What about things that are bubbling up?" So that's definitely on our radar that will be helpful.

I think that understanding that something has been raised—a problem getting support from another team, or with a broken tool or an outdated tool that needs to be replaced in the dev tooling or something like that—if that's been popping up time and time again and you don't know about it, then even as the leader of that team, you don't have the ammunition to then say "Look, this is how much it's slowed us down."

I think we live in such a data world now. If those actions are also where the evidence is that this is what needs to change and this is where the barriers are...

Solution 3: The power of trend analysis

Shane Raubenheimer: Certainly. I agree. Touching on the trend analytics approach—we do trend analysis on everything except what isn't happening or what is actually going wrong, because we just track the fallout of said lack of application. We don't actually trend or theme, to your point.

We do trend analysis on everything except what isn't happening or what is actually going wrong, because we just track the fallout of said lack of application.

We theme everything when we plan, yet somehow we don't categorize performance issues as an example. If everybody's having a performance issue, that's the theme. We almost need to categorize or expose themes that are outward-facing, not just inward-facing. Because it's well and good saying "well, our automated testing system doesn't work"—what does that mean? Why doesn't it work?

I think it should inspire external investigation. When you do a master data cleanup, you don't just say "well, most of it looks good, let's just put it all in the new space." You literally interrogate it at its most definitive and lowest level. So why not do the same with theming and trending environmental issues that you could actually investigate, and that could become a new initiative that would be driven by a new team that didn't even know it was a thing?

Jaclyn Smith: Yeah, and you're also gathering data at that point to evidence the problem rather than "oh, it's a pain point that keeps coming up." It is, but it gives you the opportunity to quantify that pain point a little bit as well. I think that is sometimes really hard to do when you're talking about developer experience or team member experience. Even outside of product engineering teams, there are things in the employee experience that affect the ability for that delivery—whatever you're delivering—to run smoothly. You want to make that as slick as possible, and that's how you get the faster outcomes.

Solution 4: The human factor

Shane Raubenheimer: Absolutely. You can never underestimate the human factor as well. If everything I'm doing and every member of my team is doing is to the best of not just their capability, but to the best of the ability in what they have available to them, you become jaded, you become frustrated. Because if you're hitting your head against the same issue regardless of how often you're pivoting, that can be very disillusioning, especially if it's not been taken as seriously as your work output.

If everything I'm doing and every member of my team is doing is to the best of not just their capability, but to the best of the ability in what they have available to them, you become jaded, you become frustrated.

We run a week late for a customer delivery or a customer project, and we start complaining about things like money, budget overspend, over-utilization. But identifying systematic or environmental issues that you can actually quantify should be treated in exactly the same way. I feel very strongly about this.

Solution 5: Breaking down overwhelming action items

Jaclyn Smith: We tend to nerd out about this stuff, Shane, and you're in good company. You've also reminded me—we've put together a bit of a workshop to help teams and people understand how to get the most out of their retrospectives, not just in terms of making them engaging, but fundamentally how to leverage actions to make them meaningful and impactful.

We've spoken a lot about the incremental change that is the critical factor when it is something that's within the team's control or closely to the team's control. That's how you get that expansion of impact—the slow incremental change. We've talked about sometimes those action items seem overwhelming and too big. What's your advice if that's the scenario for a team? What do you see happen and what can they do?

Shane Raubenheimer: I would suggest following the mantra of "if a story is too big, you don't understand enough about it yet, or it's not broken down far enough." Incremental change should be treated in exactly the same way. The "eat the elephant one bite at a time" analogy. If it's insurmountable, identify a portion of it that will make it a degree less insurmountable next time, and so on and so forth.

If we're iterating work delivery, problem-solving should be done in rapid iteration as well. That's my view.

Jaclyn Smith: I like it.

The "eat the elephant one bite at a time" analogy. If it's insurmountable, identify a portion of it that will make it a degree less insurmountable next time, and so on and so forth. If we're iterating work delivery, problem-solving should be done in rapid iteration as well.

Wrapping up: What's next?

Jaclyn Smith: I think we're almost wrapping up in terms of time. What can people expect from us if they join our webinar on July 10th, I believe it is, where we dive and nerd out even more about this topic, Shane?

Shane Raubenheimer: I think the benefit of the webinar is going to be a practical showing of what we're waxing lyrical about. It's easy to speak and evangelize, but I think from the webinar we'll show turning our concepts into actual actions that you can eyeball and see the results of.

With our approach that we took to our workshop, I think people will very quickly get the feeling of "this is dealing with cause and effect in a cause and effect way." So practical—to put that in one sentence, an active showing or demonstration of how to quantify and actually do what we've been waxing lyrical about.

the benefit of the webinar is going to be a practical showing of what we're waxing lyrical about. It's easy to speak and evangelize, but I think from the webinar we'll show turning our concepts into actual actions that you can eyeball and see the results of.

‍Jaclyn Smith: Excellent. That was a lovely summation, Shane. If anyone is interested in joining, we urge you to do so. You can hear us talking more about that but get some practical help as well. There is a link to the registration page in the description below.

I think that's about all we have time for today. But Shane, as always, it's been amazing and lovely to chat to you and hear your thoughts on a pocket of the agile world and helping teams.

Shane Raubenheimer: Yeah, it's always great engaging with you. I always enjoy our times together, and it's been my pleasure. I live for this kind of thing.

Jaclyn Smith: It's wonderful! Excellent. Well, I will see you on the 10th, and hopefully we'll see everyone else as well.

Shane Raubenheimer: Perfect. Yeah, looking forward to it.

Jaclyn Smith: Thanks.

Ready to end the frustration of ineffective retrospectives?

Join Jaclyn Smith and Shane Raubenheimer on July 10th for a live, hands-on webinar designed to turn your retrospectives into powerful engines for continuous improvement.

In this highly interactive session, you will:

• Uncover why retrospectives get stuck in repetitive cycles
• Learn how to clearly capture and assign actionable insights
• Identify and avoid common retrospective pitfalls and anti-patterns
• Get hands-on experience with Easy Agile TeamRhythm to streamline retrospective actions

Walk away equipped with practical tools, techniques, and clear next steps to immediately enhance your retrospectives and drive meaningful team improvements.

👉 Register now and transform your retrospectives.