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

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

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

Viel Spaß mit der Folge!

‍

‍

‍

‍

Transkript

Teagan Harbridge:

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

Teagan Harbridge:

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

Andrew Malak:

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

Teagan Harbridge:

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

Andrew Malak:

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

Teagan Harbridge:

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

Andrew Malak:

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

Andrew Malak:

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

Teagan Harbridge:

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

Andrew Malak:

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

Andrew Malak:

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

Andrew Malak:

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

Teagan Harbridge:

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

Andrew Malak:

Absolut.

Teagan Harbridge:

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

Andrew Malak:

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

Teagan Harbridge:

Das liebe ich.

Andrew Malak:

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

Andrew Malak:

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

Andrew Malak:

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

Andrew Malak:

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

Andrew Malak:

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

Andrew Malak:

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

Teagan Harbridge:

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

Andrew Malak:

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

Andrew Malak:

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

Andrew Malak:

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

Andrew Malak:

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

Andrew Malak:

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

Andrew Malak:

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

Andrew Malak:

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

Andrew Malak:

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

Andrew Malak:

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

Teagan Harbridge:

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

Andrew Malak:

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

Teagan Harbridge:

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

Andrew Malak:

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

Teagan Harbridge:

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

Andrew Malak:

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

Andrew Malak:

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

Andrew Malak:

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

Teagan Harbridge:

Und haben Sie WIP-Limits?

Andrew Malak:

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

Teagan Harbridge:

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

Andrew Malak:

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

Teagan Harbridge:

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

Andrew Malak:

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

Andrew Malak:

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

Andrew Malak:

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

Andrew Malak:

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

Andrew Malak:

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

Teagan Harbridge:

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

Andrew Malak:

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

Teagan Harbridge:

Fantastisch. Danke Andrew.

Andrew Malak:

Hab einen schönen Tag.

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.