Easy Agile Podcast Ep.12 Beobachtungen zur Beobachtbarkeit
In dieser Folge von The Easy Agile Podcast hören Sie, wie die Entwickler Angad, Jared, Jess und Jordan ihre Gedanken zum Thema Observability teilen.
Wollongong hat eine blühende und unterstützende Tech-Community. In dieser Folge haben wir einige unserer lokalen Entwickler aus dem Siligong-Tal zu einem Gespräch am runden Tisch zum Thema Observability zusammengebracht.
💥 Was ist Beobachtbarkeit?
💥 Wie kann man die Beobachtbarkeit verbessern?
💥 Was ist das Endziel?

„Es war eine großartige Episode, an der man teilnehmen konnte! Jess und Jordan haben einige wirklich interessante Punkte zum neuesten technischen Schlagwort — Beobachtbarkeit — geteilt.
Abonniere unbedingt, genieße die Folge 🎧
Transkript
Jared Kells:
Willkommen alle zum Easy Agile Podcast. Mein Name ist Jared Kells und ich bin Entwickler hier bei Easy Agile. Bevor wir beginnen, möchte Easy Agile den traditionellen Hütern des Landes, von dem aus wir heute senden, unsere Anerkennung aussprechen, dem Volk der Wodiwodi aus der Dharawal-Nation, und den Ältesten in der Vergangenheit, Gegenwart und aufstrebenden Ältesten unseren Respekt erweisen. Den gleichen Respekt gilt auch allen Ureinwohnern, die uns heute zuhören.
Jared Kells:
Der heutige Podcast ist also ein bisschen technisch. In meinem Arbeitsblatt steht, dass wir hier sind, um über einige aktuelle Themen für Ingenieure im IT-Sektor zu sprechen. Wie aufregend, dass wir ein paar hauptsächlich Frontend-Ingenieure haben und Angad und ich einige technische Frontend-Dinge mit Ihnen teilen werden und Jess und Jordan ein bisschen über Observability sprechen werden. Wir beginnen also mit Einführungen. Also werde ich es an Jess weitergeben.
Jess Belliveau:
Cool. Danke Jared. Danke, dass du mir auch eins gegeben hast. Also ja, mein Name ist Jess Belliveau. Ich arbeite für Apptio als Infrastrukturingenieur. Ja, Jordan?
Jordan Simonowski:
Ich bin Jordan Simonovski. Ich arbeite als Systemingenieur im Observability-Team von Atlassian. Ich bin ein bisschen ein Alleskönner, was die Technik angeht. Aber ja, ich arbeite daran, einige ziemlich leistungsfähige Systeme aufzubauen, um all unsere Daten bei Atlassian im Moment zu verarbeiten. Also, das macht Spaß.
Angad Seth:
Hallo an alle zusammen. Ich bin Angad. Ich arbeite für Easy Agile als Softwareentwickler. Nichts ausgefallenes wie ihr.
Jared Kells:
Nichts Besonderes!
Jess Belliveau:
Verkaufe dich nicht unter.
Jared Kells:
Ja, sage ich. Ja, also mein Name ist Jared und ja, Senior Developer bei Easy Agile, der an unseren Apps arbeitet. Also arbeite ich hauptsächlich an Programmen und Roadmaps. Und ja, es sind Frontend-Apps mit viel JavaScript. Darin liegt also unsere Erfahrung. Ich habe von diesem Ding namens Observability gehört, bei dem es sich meiner Meinung nach nur um Logs und so handelt, oder?
Jess Belliveau:
Ja, ja. Das war's, wir schließen ab!
Jared Kells:
Der Podcast ist vorbei! Erzählen Sie uns etwas über Beobachtbarkeit.
Jess Belliveau:
Ja, okay, ich werde, ja. Ja, ich dachte, zuerst mache ich eine kleine Sache darüber, warum Observability, warum wir darüber reden und irgendwie für die Leute, die zuhören, wie wir hierher gekommen sind. Wir haben uns kurz unterhalten, bevor wir mit den Aufnahmen begonnen haben, um herauszufinden, was ein breiteres Publikum interessieren könnte, über das die Leute vielleicht nicht viel wissen. Und ich denke, es gibt viele Entwicklungen im breiten IT-Bereich, über die Sie sprechen könnten. Es gibt jetzt so viele verschiedene Dinge, die einfach explodieren. Beobachtbarkeit ist ein Thema, das seit ein paar Jahren ein heißes Thema ist. Und es ist etwas, das ein zentraler Bestandteil meines Jobs und auch Jordans Job ist. Es ist also etwas, worüber wir leicht sprechen können, und es ist etwas, in das Sie eine Einführung geben können, ohne zu technisch zu werden. Wir wollen also nicht untergehen. Das ist etwas, das man wirklich tief ins Unkraut eintauchen kann, also haben wir es als etwas ausgewählt, das wir euch beiden hoffentlich auf einer Ebene erklären können, die auch die Leute zu Hause interessieren könnte, zuzuhören.
Jess Belliveau:
Jordan und ich haben diese vier Stichpunkte herausgefunden, die wir behandeln wollten, und vielleicht kann ich einen kleinen Überblick darüber machen, und dann kann ich Jordan dazu bringen, den ersten Aufzählungspunkt abzudecken, ihn einfach direkt unter den Bus werfen.
Jordan Simonowski:
In Ordnung!
Jess Belliveau:
Deshalb dachten wir, wir würden versuchen, Ihnen zunächst zu beschreiben, was Beobachtbarkeit ist. Weil das hübsch ist, der Begriff gibt Ihnen nicht viel von dem, was er ist. Es gibt Ihnen einen kleinen Hinweis, aber es ist gut, als Grundlinie festzulegen, wovon wir sprechen, wenn wir sagen, was Beobachtbarkeit ist. Und warum sollte ein Entwicklungsteam dann Observability wollen? Warum sollte ein Unternehmen Observability wollen? Ein gewisses hohes Niveau, welche Vorteile Sie daraus ziehen und wer sie möglicherweise benötigt, was eine große Sache ist. Sie können sich in diese brandaktuellen Schlagworte der Branche verwickeln und sich auf Dinge festlegen, die Sie möglicherweise nicht benötigen, oder solche Dinge.
Jared Kells:
Jep.
Jordan Simonowski:
Jep.
Jess Belliveau:
Wir dachten, wir würden über einige einfache Gewinne sprechen, die man mit Observability erzielen kann. Also einige der wirklich grundlegenden Dinge, die Sie ausprobieren können, und welche Vorteile Sie daraus ziehen. Und dann dachten wir einfach, weil wir nicht versuchen werden, zu tief zu gehen, könnten wir einfach ein paar Hinweise auf einige Websites und einige YouTube-Vorträge geben, um weiter zu lesen, die die Leute machen wollen, und von dort aus weitermachen. Also ja, Jordan, du willst...
Jared Kells:
Hört sich gut an.
Jess Belliveau:
Ja. Ich hoffe, hoffentlich. Wir werden sehen, wie das läuft! Und ich denke, wenn ihr auch Fragen habt, sollten wir das tun. Wenn es Dinge gibt, von denen ihr denkt, dass wir sie nicht behandeln oder die ihr mehr wissen wollt, fragen.
Jordan Simonowski:
Ich schätze, um mit Observability zu beginnen. Es ist ein Thema, das mich wirklich begeistert, denn als jemand, der schon so lange im Bereich Dev-Ops und SRE tätig ist, ist Observability auf den Markt gekommen und verspricht, den Kreislauf oder eine Feedback-Schleife bei der Softwarebereitstellung zu schließen. Und es fühlt sich an, als wäre das etwas, was wir im Moment nicht wirklich haben. Und ich verstehe, dass Beobachtbarkeit vielleicht neu und glänzend klingt, aber ich denke, der Begriff selbst existiert, um sich vielleicht von dem abzuheben, was es derzeit gibt. Viele von uns, die in der Tech-Branche arbeiten, kennen sich mit Überwachung und dem Laden und solchen Dingen aus. Und ich denke, sie erfüllen ihren eigenen Zweck und sie sind auch in keiner Weise veraltet. Dinge wie herkömmliche Überwachungstools. Aber Observability hat sich meiner Meinung nach als eine Möglichkeit erwiesen, die überwältigend komplexen Systeme zu verstehen, die wir gerade aufbauen. Viele Unternehmen bewegen sich wahrscheinlich in Richtung einer komplizierten Architektur verteilter Systeme, Microservices oder anderer Schlagworte.
Jordan Simonowski:
Aber auch für Dinge wie einen traditionellen Monolithen. Die Beobachtbarkeit hilft uns wirklich dabei, unseren Systemen neue Fragen zu stellen. Die Art und Weise, wie es erklärt wird, ist die Überwachung von Ausgängen auf unsere bekannten Unbekannten. Mit dem Dienstalter geht die Fähigkeit einher, fast vorherzusagen, auf welche Weise Ihre Systeme ausfallen werden. Sie werden es also wissen. Je länger Sie in der Branche tätig sind, Sie wissen das, zum Beispiel ein Java-Server fällt auf X, Y, Z verschiedene Arten aus, also sollten wir wahrscheinlich unseren JVM-Heap überwachen, oder was auch immer es ist.
Jared Kells:
Das wollte ich sagen!
Jordan Simonowski:
Ich werde versuchen, nicht zu viel darauf einzugehen...
Jared Kells:
Der Speicher geht aus!
Jordan Simonowski:
Ja. Also das ist etwas, von dem du erwartest, dass es irgendwann scheitern wird. Und das ist etwas, das Sie als bekannt unbekannt betrachten können. Aber das Versprechen der Beobachtbarkeit ist, dass wir genügend Daten liefern sollten, um neue Fragen stellen zu können. Die Art und Weise, wie darüber gesprochen wird, sehen Sie, es ist eine unbekannte Unbekannte in unserem System, über die wir etwas herausfinden und neue Fragen stellen wollen. Und hier wird, glaube ich, die Beobachtbarkeit eingeführt, um diese Fragen zu beantworten. Reicht die Antwort aus? Willst du, dass ich näher auf dieses Zeug eingehe? Ich kann den ganzen Tag darüber reden.
Jared Kells:
Ist es wie ein [Crosstalk 00:08:05]. Also, um es dir noch einmal zu sagen, um zu sehen, ob ich es verstanden habe. Also, wenn ich eine, traditionell mit einer Java-App, habe, könnte ich Erinnerungen protokollieren. Das liegt daran, dass ich weiß, dass JVMs der Arbeitsspeicher ausgeht, und das ist eine Sache, die ich überwache, aber die Beobachtbarkeit ist umfassender. Sie übertreiben quasi das, was Sie überwachen und protokollieren, sodass Sie...
Jordan Simonowski:
Ja. Und ich würde nicht unbedingt sagen, dass es übertrieben ist. Ich denke, es fügt Ihren Daten vielleicht etwas mehr Kontext hinzu. Wenn also jemand von Ihnen schon einmal mit Traces gearbeitet hat, ist Observability der Funktionsweise von Traces sehr ähnlich und baut einfach auf der Prämisse von Traces auf, schätze ich. Sie erstellen also diese Ereignisse, und bei diesen Ereignissen handelt es sich um verschiedene Transaktionen, die in Ihren Anwendungen stattfinden könnten, wobei normalerweise eine Anfrage eingereicht wird. Und mit dieser Anfrage können Sie ihr eine ganze Reihe von Kontext hinzufügen. Sie können hinzufügen, auf welchem Server dies möglicherweise läuft, in welcher Zeitzone. All diese zusätzlichen und all die Aufreger. Sie können die Benutzeragentur hineinwerfen, wenn Sie möchten. Die Idee der Beobachtbarkeit besteht darin, dass Sie nicht unbedingt durch Daten mit hoher Kardinalität eingeschränkt sind. Daten mit hoher Kardinalität sind Datensätze, die sich in Bezug auf die Art der Daten, die sie repräsentieren, oder die Kombinationen von Datensätzen, die Sie haben könnten, erheblich ändern können.
Jordan Simonowski:
Wenn Sie also Versandmetriken für etwas haben möchten, auf Benutzerbasis, und Sie sich ansehen möchten, wie verschiedene Benutzer von den Dingen betroffen sind, würde das als Metrik mit hoher Kardinalität betrachtet werden. Und in den meisten Fällen können traditionelle Überwachungsunternehmen oder Anbieter von Messwerten Ihnen das nicht wirklich als Service anbieten. Das ist der Punkt, an dem Sie anfangen, wahnsinnig hohe Rechnungen für Dinge wie Datadog oder was auch immer es ist, zu bezahlen, weil sie jetzt als neue Metriken betrachtet werden. Im Gegensatz zu Observability versuchen wir, unsere Daten zu speichern und sie so abzufragen, dass wir ziemlich große Datensätze speichern und sagen können: „Cool. Wir haben Fehler, die von dieser Art von Benutzern kommen.“ Und Sie können dort anfangen, Korrelationen zu bestimmten Dingen aufzubauen. Sie können herausfinden, dass bei Benutzern aus einer bestimmten Zeitzone oder einem bestimmten Gerät nur dieser Fehler auftritt. Und von dort aus können Sie, glaube ich, bessere Methoden entwickeln, um zu verstehen, wie eine bestimmte Änderung die Dinge kaputt gemacht haben könnte. Oder bestimmte Randfälle, die Sie sonst mit etwas wie CPU- oder Speicherüberwachung nicht erkennen könnten.
Angad Seth:
Wäre es fair zu sagen...
Jared Kells:
Ja. Es ist [Crosstalk 00:11:02].
Angad Seth:
Oh, tut mir leid, Jared.
Jared Kells:
Nein, du kannst...
Angad Seth:
Wäre es fair zu sagen, dass Beobachtbarkeit also im Grunde eine Reihe von Prinzipien ist oder ein Weg, unbekannte Unbekannte zu finden?
Jordan Simonowski:
Ja.
Angad Seth:
Oh.
Jess Belliveau:
Und ich sollte Sie besser ausrüsten, um herauszufinden, dass eine Menge Leute denken, Sie denken, dass Beobachtbarkeit eine Sache ist, die Sie einsetzen und haben und ein Kästchen ankreuzen können, aber ich mag Ihre Wortwahl, wenn es um eine Reihe von Prinzipien oder Best Practices geht. Es gibt Ihnen sozusagen eine Anleitung zu diesen Themen und sorgt dafür, dass Ihre Anwendung eine gute Protokollierung hervorbringt. Also strukturierte Protokolle. Sie erhalten also immer das gleiche Protokollformat, das Sie sich ansehen können. Tracing, worüber Jordan ein bisschen gesprochen hat. So haben Sie die Möglichkeit, zu verfolgen, wie ein Benutzer mit all den verschiedenen Microservices interagiert, und möglicherweise auch zu sehen, wo etwas schief läuft, und auch Kennzahlen. Das Gute an Metriken ist also, dass wir die Dinge ein bisschen umdrehen und versuchen, eine Anwendung zu erstellen, anstatt, und ich will nicht zu technisch werden, Black-Box-Monitoring zu machen, bei dem wir draußen sind und versuchen, mit solchen Sonden und Checks reinzuschauen. Aber die Idee bei Metriken ist, dass die Anwendung diese Metriken tatsächlich ausgibt, um uns darüber zu informieren, in welchem Zustand sie sich befindet, und sie dadurch besser beobachtbar zu machen.
Jess Belliveau:
Ja, mir gefällt deine Wortwahl, Angad, dass es wie diese Praktiken ist, diese Art von Leitfaden, wohin man gehen muss, was wahrscheinlich zu dem nächsten Punkt führt, warum sollte ein Team das implementieren wollen. Wenn du noch einmal anfangen willst, Jordan?
Jordan Simonowski:
Ja, ich kann anfangen. Und ich gebe dir auch ein bisschen mehr Zeit zum Reden, Jess in diesem. Ich werde nicht so viel schimpfen.
Jess Belliveau:
Oh, dafür habe ich mich nicht angemeldet!
Jordan Simonowski:
Ich denke, die Teams würden es wollen, weil es wirklich von Ihrer Organisation und, glaube ich, von der Größe der Teams abhängt, in denen Sie arbeiten. In den meisten Fällen würde ich sagen, dass Sie Observability nicht selbst im eigenen Haus erstellen möchten. Das ist etwas, das Sie können, Observability-Funktionen selbst, Sie werden es nicht erreichen, indem Sie einfach etwas kaufen, also Sie können Dev-Ops nicht kaufen, Sie können Agile nicht kaufen, Sie können Observability auch nicht kaufen.
Jared Kells:
Warte, warte. Auf meinem Runsheet steht, dass ich für Easy Agile werben soll, das klingt also nach einem guten Übergang-
Jess Belliveau:
Es sei denn, du willst es kaufen. Wenn du Agile kaufen möchtest, dann [Crosstalk 00:13:55] im Marketplace.
Jared Kells:
Ja, tut mir leid, tut mir leid, ja! Ja, mach weiter.
Jordan Simonowski:
Sie können Tools kaufen, die Ihnen das Leben erheblich erleichtern, und es gibt bereits eine Menge Dinge da draußen, die Dinge für Menschen tun und wirklich interessante Daten an die Oberfläche bringen, die sich die Leute vielleicht ansehen möchten. Ich denke, es gibt ein paar Start-ups wie LightStep und Honeycomb, die Ihnen eine wirklich intuitive Möglichkeit bieten, Ihre Daten in der Produktion zu verstehen. Aber warum Sie solche Dinge benötigen, ist, dass Sie den Zustand Ihrer Systeme zu einem bestimmten Zeitpunkt wissen wollen, und um, glaube ich, eine gute Betriebshygiene und eine gute Produktionsexzellenz zu entwickeln, ich denke, wie Liz Fong-Jones es ausdrücken würde, müssen Sie in der Lage sein, diese Rückkopplungsschleife zu schließen. Wir haben bereits eine ganze Reihe von Tools. Wir haben also CICD-Systeme eingerichtet. Wir haben jetzt Feature-Flags, die uns, glaube ich, helfen, Deployments von Releases zu entkoppeln. Sie können Code bereitstellen, ohne tatsächlich Code zu veröffentlichen, und Sie können diese Macht jetzt Ihren PMs geben, wenn Sie möchten, mit Feature-Flags, was großartig ist.
Jordan Simonowski:
Aber jetzt können Sie diesen Kreislauf auch komplett schließen, und während Sie eine Anwendung bereitstellen, können Sie sagen: „Ich möchte diese Bereitstellung kanalisieren. Ich möchte dies für 10% meiner Benutzer bereitstellen, vielleicht für Benutzer, die sich für Beta-Versionen oder etwas aus unserer Anwendung angemeldet haben, und Sie können sich tatsächlich ansehen, wie das funktioniert, bevor Sie es einem breiteren Publikum zugänglich machen. Es macht Bereitstellungen also viel sicherer. Es gibt Ihnen auch ein besseres Verständnis dafür, wie Sie sich auch auf die Benutzer auswirken. Und es gibt eine ganze Reihe von Tools, mit denen Sie auch diese Dinge ermitteln können. Wenn Sie sich also ansehen, wie viele Unternehmen derzeit SRE durchführen, oder wenn Sie wissen, wie zuverlässig ihre Anwendungen aussehen, haben Sie auch Dinge wie SLOs im Einsatz. Und SLOs-
Jared Kells:
Was ist ein SLO?
Jordan Simonowski:
Sie sind alle mit Benutzererlebnissen verbunden. Sie sagen also: „Kann mein Benutzer diese spezielle Interaktion durchführen?“ Und wenn Sie das effektiv messen und wissen, wie sich Ihre Änderungen auf die Benutzer auswirken, können Sie ganz einfach entscheiden, ob Sie weiterhin Funktionen bereitstellen oder ob Sie alles fallen lassen und an der Zuverlässigkeit arbeiten, um sicherzustellen, dass Ihre Benutzer nicht beeinträchtigt werden. Es ist also dieser sehr nutzerorientierte Ansatz, Dinge zu tun. Ich denke, wenn es darum geht, den Kreis zu schließen, liefert uns die Beobachtbarkeit die Daten, anhand derer wir sagen können: „Ja, so sind die Nutzer betroffen. Auf diese Weise, schätze ich, geht es dem 99. Perzentil unserer Nutzer gut, aber wir haben 1%, die negative Probleme mit unserer Anwendung haben.“ Und von dort aus können Sie wirklich Dinge lokalisieren und sagen: „Cool. Benutzer mit diesem bestimmten Browser oder diesem speziellen Browser oder wo wir diese App bereitgestellt haben. „Nehmen wir an, wenn Sie eine globale Bereitstellung haben, haben Sie sie zuerst auf einer Insel bereitgestellt, weil es Ihnen eigentlich egal ist, was mit ihnen passiert. Sie können sagen: „Oh, wir haben tatsächlich Sachen für sie kaputt gemacht.“ Und Sie können es rückgängig machen, bevor Sie sich auf 100% Ihrer Nutzer auswirken.
Jared Kells:
Ja. Mir hat gefallen, was du über den Test gesagt hast. Ich habe das Akronym vergessen, aber ich teste tatsächlich das Verhalten des Endbenutzers. Das finde ich ziemlich aufregend, weil wir all diese Metriken haben, die ein bisschen nutzlos sind. Sie sind cool: „Oh, es nutzt 1% CPU, wie es immer ist, jetzt ist mir das egal“, aber kann ein Benutzer die App öffnen und ein Problem mit der Maus herumschleppen? Es ist wie...
Jess Belliveau:
Ja, das ist ein wirklich gutes Beispiel, oder?
Jared Kells:
Das ist es, was mir wirklich wichtig ist.
Jess Belliveau:
Bei der CPU-Sache mit 1% könnte man sich ein Diagramm zur CPU-Auslastung ansehen und eine Bereitstellung sehen, und die CPU-Auslastung ändert sich nicht. Ist alles gesund oder nicht? Sie wissen es nicht, aber wenn Sie tiefere Informationen über die Benutzerinteraktionen erhalten, könnten Sie 1% der CPU verwenden, um HTTP500-Fehler an 80% der Kundenbasis zu verteilen, so oder so.
Angad Seth:
Wie macht man das? Der SLO-Bit, woher weißt du, dass sich ein Benutzer anmelden und ein Problem ziehen kann?
Jordan Simonowski:
Ja. Ja, das würde mit einer guten Instrumentierung einhergehen...
Angad Seth:
Gute Frage?
Jordan Simonowski:
Ja, es kommt darauf an, die Beobachtbarkeit zu berücksichtigen, wenn Sie neue Funktionen entwickeln, genauso wie Sie darüber nachdenken würden, beim Schreiben eine bestimmte Sache in Ihrem Code zu protokollieren oder Tests für Ihren Code zu schreiben, während Sie auch Code schreiben. Sie sollten darüber nachdenken, wie Sie etwas instrumentieren können und wie Sie verstehen können, wie diese spezielle Funktion in der Produktion funktioniert. Denn ich denke, viele Agile- und Dev-Ops-Prinzipien sagen uns jetzt, dass wir unsere Anwendungen in der Produktion haben wollen. Und als Entwickler endet unsere Verantwortung nicht, wenn wir etwas bereitstellen. Unsere Verantwortung als Entwickler endet, wenn wir dem Unternehmen einen Mehrwert geboten haben. Und Sie müssen verstehen, dass Sie das tatsächlich tun. Und da müssen Sie, glaube ich, über die Beobachtbarkeit bei vielen dieser Dinge nachdenken und Ihre Erfolgskennzahlen tatsächlich messen. Wenn Sie also wissen, dass Ihre Anwendung erfolgreich ist, wenn sich Ihr Benutzer anmelden und Dinge herumziehen kann, dann ist das genau das, was Sie messen möchten.
Jared Kells:
Ich denke, wir müssen bauen...
Jordan Simonowski:
Ja?
Jared Kells:
Oh, tut mir leid, Jordan.
Jordan Simonowski:
Nein, du gehst.
Jared Kells:
Ich wollte nur sagen, dass wir unsere Apps bereits unter Berücksichtigung von Integrationstests entwickeln müssen. Also browserbasierte Tests rund um neue Funktionen. Es würde also darum gehen, Funktionen unter Berücksichtigung dieser und derselben Sache zu entwickeln, aber für Tests und Produktion.
Jess Belliveau:
Ja, und das eigentliche Wie, der eigentliche Teil zum Schreiben von Code, da ist dieses wirklich großartige Projekt, das Open Telemetrie-Projekt, das all diese Arten von APIs und SDKs bereitstellt, die Entwickler nutzen können, und es ist herstellerunabhängig. Wenn du also über das Wie sprichst, etwa: „Wie mache ich das? Wie instrumentiere ich Dinge?“ Oder: „Wie gebe ich Kennzahlen aus?“ Sie bieten all diese hilfreichen Bibliotheken und Includes, die Sie haben können, denn das Letzte, was Sie tun möchten, ist, diese benutzerdefinierte Lösung auf den Markt zu bringen, weil Sie dann nur Ihre technischen Schulden erhöhen. Sie versuchen, die Dinge einfacher zu machen, verlassen sich dann aber auf: „Nun, ich muss Jared Kells weiter beschäftigen, weil er unsere Login-Engine geschrieben hat und niemand sonst weiß, wie sie funktioniert.
Jess Belliveau:
Und dann die andere Sache, die mir auch bei so etwas wie offener Telemetrie in den Sinn kommt, und wir haben ein bisschen über Datadog gesprochen. Datadog ist also ein SaaS-Anbieter, der sich auf Observability spezialisiert hat. Und Sie würden Ihre Metriken und Ihre Logs und Ihre Traces an sie übertragen und sie bieten Ihnen eine Benutzeroberfläche zum Anzeigen. Wenn Sie sich für etwas entscheiden, das herstellerunabhängig ist, nehmen wir einfach das Beispiel von Easy Agile. Nehmen wir an, sie starten Datadog und in sechs Monaten wollen wir Datadog nicht mehr verwenden, wir wollen SignalFX oder was auch immer das Splunk-Modell jetzt ist, verwenden.
Jordan Simonowski:
Ich denke NorthX.
Jess Belliveau:
Ja. Du kannst deinen Endpunkt ändern, dieselben Metriken und all diese Dinge, vielleicht mit ein paar kleinen Anpassungen, aber die Idee ist, dass du dich nicht auf eine einzige Sache festlegen willst.
Jordan Simonowski:
Ihre Datenstrukturen bleiben gleich.
Jess Belliveau:
Ja. Damit du es fast nahtlos machen könntest, ohne dass die Entwickler es wissen. In der Vergangenheit gab es sogar Unternehmen, die meiner Meinung nach auf mehrere Anbieter umgestellt haben. Sie könnten also Anbieter A nutzen und dann mit Anbieter B einen Machbarkeitsnachweis durchführen, um zu sehen, wie die Erfahrung ist, und Sie geben Ihre Daten einfach auch dort weiter.
Jared Kells:
Ja. Ich denke, unsere Verbindung zu Datadog wird aus all den Dashboards und allem, was wir gemacht haben, bestehen. Es sind nicht so sehr die Daten.
Jess Belliveau:
Ja. Das ist quasi der große Verkaufsschlager, richtig. Das ist die Art und Weise, wie du interagierst. Das ist der Punkt, an dem sie ins Spiel kommen wollen. Es macht es Ihnen leichter, diese Daten zu interpretieren und sie so zu manipulieren, dass sie Ihren Bedürfnissen entsprechen und so weiter.
Jordan Simonowski:
Observability deutet auf Dashboards hin, oder?
Jess Belliveau:
Ja, vielleicht. Du hast diesen Begriff auch benutzt, Jordan, „Produktionsexzellenz“. Und wenn wir darüber sprechen, wer Observability braucht, habe ich ein bisschen darüber nachgedacht, während Sie gesprochen haben. Und für mich ist Production Excellence, oder in Apptio nennen wir das Produktionsbereitschaft, Betriebsbereitschaft und diese Art von Dingen ist so, als ob wir etwas in der Produktion einsetzen wollen, wie zum Beispiel welche Best Practices wollen wir haben, bevor wir das tun? Und ich denke, Observability ist eine wirklich gute Idee, weil sie Ihnen in Zukunft hilft. Sie wissen nicht, welche Probleme Sie später haben werden, aber Sie rüsten Ihre Teams so aus, dass sie problemlos auf diese Probleme reagieren können. Wir waren wahrscheinlich alle dort, wir haben den Produktionscode implementiert und wir haben keine Observability, wir haben einen riesigen Ausfall. Was ist schief gelaufen? Nun, niemand weiß es, aber wir wissen, dass das die Lösung ist, und es ist schwer, daraus zu lernen, oder man muss wohl daraus lernen und den Benutzer vor zukünftigen Dingen schützen, ja.
Jess Belliveau:
Wenn ich denke, dass einfache Beobachtbarkeit gewinnt, kommt mir als Erstes die ganze Idee der strukturierten Protokollierung in den Sinn, was eigentlich die Idee ist, dass Ihre Anwendung zuallererst Sie protokollieren. Ziemlich wichtig als Ausgangspunkt, aber dann haben Sie ein strukturiertes Protokollformat, mit dem Sie die Logs auch programmgesteuert weitergeben können. Wenn Sie in der Zeit zurückreisen, sah die Protokollierung vielleicht nur wie einfacher Text mit einer Zeile, einem Zeitstempel und einer Fehlermeldung aus. Was auch immer der Entwickler beschlossen hat, in die Standardausgabe zu schreiben, oder in die Fehlerdatei oder so ähnlich. Ich denke, es gibt einen allgemeinen Trend hin zu JSON, einem tatsächlich formatierten Blob mit dieser bekannten Struktur, damit Sie ihn sich ansehen können. Tracing ist wahrscheinlich kein einfacher Gewinn. Das ist ein bisschen schwieriger. Sie können es mit offener Telemetrie und Bibliotheken und so implementieren. Ich denke, es erfordert ein bisschen mehr Verständnis Ihrer Codebasis und darüber, wo die Ablaufverfolgung ausgelöst werden soll, und solche Dinge, das Analysieren von Kontexten, solche Dinge.
Jordan Simonowski:
Ich denke Atlassian, wenn du wahrscheinlich einfach nur wissen willst, dass alles in Ordnung ist. Auf einer ziemlich oberflächlichen Ebene. Vielleicht willst du einfach nur eine Art Uptime für einen Trend machen. Und wenn dann, glaube ich, Ihr Code komplexer wird oder Ihr Produkt etwas komplexer wird, können Sie anfangen, Dinge hinzuzufügen. Aber ich denke, die Dinge, die Sie kennen, tatsächlich zu kennen oder an die Oberfläche zu bringen, könnte kaputt gehen. Das wären wahrscheinlich deine schnellsten Siege.
Jess Belliveau:
Nun, lassen Sie uns einige Dinge zur weiteren Lektüre erwähnen. Wenn Sie sich einen Überblick über das Ganze verschaffen wollen, hat das Google SRE-Buch von vor ein paar Jahren begonnen, echte Observability stark in Bewegung zu setzen. Das Google SRE-Zeug deckt die gesamte Bandbreite ihrer Praxis im Bereich Soak Reliability Engineering ab, und Observability ist ein Teil davon, dazu gibt es einige großartige Kapitel. Ich glaube, O'Reilly hat jetzt ein Buch über Observability veröffentlicht, das sich nur der Beobachtbarkeit widmet.
Jordan Simonowski:
Ich denke, das ist noch in der frühen Version, wenn die Leute Kapitel googeln wollen.
Jess Belliveau:
Das offene Telemetrie-Zeug, wir werden einen Link dazu setzen, ich denke, das ist wirklich praktisch zu wissen.
Angad Seth:
Aus [unverständlich 00:26:12], das ist meine Sicht als Entwickler, sage ich, ich wollte Cornflake Use Datadog bei Easy Agile einführen. Nicht sehr vertraut, ich fühle mich nicht sehr wohl damit. Ich weiß, wie man navigiert, aber wie kann ich schnell mit der Einführung von Observability beginnen? Es tut mir leid, dass ich meinen direkten Job oder meinen Arbeitsplatz gesperrt habe.
Jordan Simonowski:
Ich würde sagen, ich könnte hier voreingenommen sein. Jess, korrigiere mich oder gib deine Meinung dazu ab, ich würde mich dafür stark zu SLOs neigen. Und Sie können das kurz im SRE nachlesen-
Jess Belliveau:
Wofür steht SLO, Jordan?
Jordan Simonowski:
Okay, tut mir leid. Schlagworte! SLO ist ein Service Level Objective, nicht zu verwechseln mit Service Level Agreement. Eine Vereinbarung selbst ist vertraglich und Sie können den Leuten Geld zahlen, wenn Sie gegen diese verstoßen. Ein SLO ist etwas, das Sie in Ihrem Team festlegen und Sie haben ein Zuverlässigkeitsziel, weil wir an einem Punkt angelangt sind, an dem wir verstehen, dass sich alle Systeme zu jedem Zeitpunkt in einem heruntergekommenen Zustand befinden. Und ja, Zuverlässigkeit ist nicht unbedingt binär, sie ist nicht unzuverlässig oder zuverlässig. Meistens ist es meistens zuverlässig und das gibt uns eine bessere gemeinsame Sprache, denke ich. Und Sie können das SRE-Handbuch von Google lesen, das kostenlos online verfügbar ist und Ihnen ein ziemlich gutes Verständnis von Datadog vermittelt.
Jordan Simonowski:
Ich glaube, als ich es das letzte Mal benutzt habe, gab es ein SLO-Angebot. Aber ich denke, wie ich bereits erwähnt habe, haben Sie ein SLO für bestimmte Funktionen oder Merkmale Ihrer Anwendung festgelegt. Sie sagen: „Mein Benutzer kann das in 99% der Fälle tun“, oder was auch immer Sie sich für ein anderes Zuverlässigkeitsziel setzen möchten. Ich würde eine Zuverlässigkeit von fünf Neunern nicht empfehlen. Sie werden sich wahrscheinlich selbst ausbrennen, wenn Sie versuchen, dorthin zu gelangen. Und du hast dir dieses Ziel gesetzt. Und Sie wissen genau, was Sie messen, Sie messen bestimmte Arten von Funktionen. Und Sie wissen, dass Benutzer betroffen sind, wenn Sie gegen diese Regeln verstoßen. Und hier können Sie tatsächlich anfangen, über Observability nachzudenken. Sie können darüber nachdenken: „Welche anderen Funktionen implementieren wir, mit deren Messung wir beginnen können?“ Oder: „Welche nutzerorientierten Dinge implementieren wir, mit deren Messung wir beginnen können?“
Jordan Simonowski:
Andere Dinge, die Sie sich wahrscheinlich ansehen könnten, sind, ich denke, sie sind sowieso alle in dem Buch behandelt, die Aktualität der Daten in gewisser Weise. Sie möchten sicherstellen, dass die Daten, die Benutzern angezeigt werden, relativ aktuell sind. Sie möchten nicht, dass sie sich veraltete Daten ansehen, also können Sie auch versuchen, solche Dinge zu messen. Aber Sie können es so ziemlich in die meisten Funktionen einer Website unterteilen. Es ist nicht mehr wie bei einem Ping-Check, bei dem Sie nur sagen: „Ja, HTTP, okay. Meine Bewerbung ist in Ordnung.“ Sie sagen: „Meine Benutzer sind tatsächlich von Dingen betroffen, die nicht funktionieren.“ Und von dort aus können Sie anfangen, Dinge zu messen. Und das sollte Ihnen ein besseres Verständnis oder zumindest eine bessere Vorstellung davon geben, wo Sie mit dem, was Sie messen möchten, beginnen und wie Sie es messen möchten. Das wäre meine Meinung dazu, wo Sie damit beginnen sollten, wenn Sie es einführen wollen.
Jared Kells:
Wir werden ein bisschen über den Status sprechen und wie bei einigen davon, wie bei unseren sehr Frontend-lastigen Anwendungen, die wir erstellen, sodass die Anwendungen, die wir erstellen, einfach im Browser laufen und der traditionelle Status, wie Sie sich das vorstellen würden, einfach eine sehr einfache API abruft, die einige Dinge mit einer gewissen Authentifizierung in die Datenbank schreibt und so weiter. Was die Zuverlässigkeit der Dienste angeht, so ist es wirklich zuverlässig. Diese winzigen APIs haben einfach nie Probleme, weil es einfach so einfach ist. Und nun ja, sie haben eine Menge Überwachung rund um das Thema. Aber unser gesamter Zustand ist eigentlich, wenn Sie sagen: „Beobachten Sie den Zustand des Systems“, größtenteils der Zustand in einem Browser. Und wie bringen wir Beobachtbarkeit in das hinein?
Jess Belliveau:
Eine große Sache ist wirklich, es gibt keine Sache, die auch für alle passt. Wenn wir auch über SLO-Sachen sprechen, geht es darum zu verstehen, was nicht so sehr für Ihr Unternehmen, sondern auch für Ihr Team wichtig ist. Wenn Sie dieses Produkt liefern, was ist Ihnen besonders wichtig? Also ein SLO, das für mich bei Apptio funktionieren könnte, wird wahrscheinlich nicht für Easy Agile funktionieren. Das erweitert auch mein Wissen über Frontend-Sachen wirklich, aber wenn wir sagen, dass wir auch den Staat beobachten wollen, meinen wir nicht unbedingt nur den Staat. Vielleicht möchten Sie bei jeder dieser APIs wissen, wie lang die Antwortzeit für diese API ist, wenn sie ausgelöst wird. Das könnte also eine wichtige Metrik sein. Sie können also feststellen, ob eine dieser APIs zu Latenz führt und Ihre Benutzererfahrung dadurch beeinträchtigt wird. Zum Beispiel: „Hey, als wir in der dritten Version waren und Benutzer hier mit unserem Service interagierten, reagierte er mit dieser prozentualen Latenz. Wir haben eine Version veröffentlicht und seitdem sehen wir, dass es jetzt in diesem Perzentil liegt. Haben wir die Leistung herabgesetzt?“ Die Benutzer beschweren sich vielleicht nicht, aber das könnte etwas sein, das das Team dann untersuchen und zu einem Sprint hinzufügen kann. Hey, ich verwende jetzt Agile-Begriffe. Achtung!
Jared Kells:
Das ist ein wirklich gutes Beispiel, Jess. Leistungsprobleme sind für uns in der Regel keine API, die schlecht funktioniert. Es liegt daran, dass in dieser sehr komplizierten Frontend-Anwendung nicht mehr in der gleichen Reihenfolge wie früher ausgeführt wird, oder es gibt eine komplexe Interaktion, an die wir nicht gedacht haben, sodass mehr Daten als erwartet angefordert werden. Die APIs kehren zurück. Sie sind größtenteils nie langsam, aber wir haben Leistungsrückgänge, von denen wir vielleicht nichts wissen, ohne sie zu sehen oder zu untersuchen. Die Beobachtbarkeit erfolgt wirklich auf der Browserebene des einzelnen Benutzers. Macht das Sinn? Ich möchte wissen, wie lange es gedauert hat, bis diese spezielle Interaktion stattgefunden hat.
Jess Belliveau:
Ja. Solche Dinge habe ich noch nie gemacht. Außerdem, ich schätze, Sie könnten möglicherweise betroffen sein, und dann haben Sie es auch mit Endbenutzer-Manifestationen zu tun. Sie könnten wahrnehmen...
Jared Kells:
Ja, sicher.
Jess Belliveau:
... Höhere Leistung auf ihrem Laptop oder so, oder ihrem ISP oder so. Es wäre wirklich schwierig, sicherzustellen, dass Sie von solchen Dingen nicht auch Geräusche bekommen.
Jordan Simonowski:
Ja. Es gibt wohl Tools wie Sentry, die existieren, um Ihnen ein bisschen besser zu verstehen, was an Ihrem Frontend passiert. Die Art und Weise, wie Sentry in der Regel mit JavaScript arbeitet, ist, dass Sie eine verkleinerte Map Ihres JS auf Sentry hochladen, Ihren Code bereitstellen und dann, wenn etwas kaputt geht oder auf ziemlich unerwartete Weise funktioniert, das in der Regel auftaucht, wobei Sentry Ihnen genau sagt, in welcher Zeile diese Art von Dingen passiert, und es ist ein wirklich cooles Tool für diese Firmenkram. Ich weiß nicht, ob es dir die richtigen Einblicke geben würde, glaube ich, in Bezug auf Leistung oder...
Jared Kells:
Ja, wir verwenden ein ähnliches Tool und es funktioniert bei Abstürzen und solchen Dingen. Und was die Beobachtbarkeit angeht, protokollieren wir Aktionen wie Zustandsmutationen im Frontend, nicht die tatsächliche Statusänderung, sondern nur Beschriftungen, die angeben, dass Sie eine Problemzusammenfassung aktualisiert haben oder auf diese Schaltfläche geklickt haben, so etwas, und wir senden sie mit unseren Absturzberichten. Und es ist super hilfreich, diese Art von Beobachtbarkeit zu haben. Also ich glaube, ich weiß, wovon ihr redet. Aber ich bin nur [Crosstalk 00:35:25], ja.
Jess Belliveau:
Ja, das ist, glaube ich, fast eine Art von Rückverfolgung. Wenn Jordan und ich über Tracing sprechen, denken wir vielleicht an 12 verschiedene Microservices in AWS, die alle miteinander interagieren, während Sie das eher verschieben. Das ist quasi alles, was im Browser interagiert, und nur diese Historie davon zu haben, ist das, was der Benutzer getan hat und wie es dazu kam...
Jared Kells:
In diesem Staat.
Jess Belliveau:
In diesem Staat, ja.
Jordan Simonowski:
Ich schätze, selbst wenn Sie nicht viele Microservices haben, wenn Sie über bestimmte sprechen, wie Sie sagen, sind Ihre API-Anfragen größtenteils in Ordnung, aber manchmal haben Sie besonders große Nutzlasten-
Jared Kells:
Wir müssen tatsächlich überwachen, ich weiß nicht, vielleicht können Sie dabei helfen, wir sollten eigentlich überwachen, mit wem wir zusammenarbeiten. Es ist tatsächlich viel wahrscheinlicher, dass wir ein Leistungsproblem mit einer Xero-API haben werden, als... Wir sehen es nicht, der Browser sieht es auch, was...
Jordan Simonowski:
Ja, und Tracing löst all diese Regressionen für Sie. Die meisten Tracing-Bibliotheken, z. B. wenn Sie Node-Apps oder was auch immer in Ihrem Backend ausführen. Ich kann dir nur etwas über Node erzählen, weil ich wahrscheinlich die meiste Erfahrung mit dem Schreiben von Node-Sachen habe. Du gibst quasi einfach Didi Trace ein, eine Datadog-Bibliothek für das Tracing in dein Backend und deinen Hook selbst in all die, glaube ich, gängigen Bibliotheken, mit denen du normalerweise arbeiten wirst, glaube ich. Wenn Sie zum Beispiel für Express oder nur für viele HADP-Bibliotheken sowie für ein paar AWS-Services arbeiten, wird es sich quasi von selbst einbinden. Und Sie können es tatsächlich genau bestimmen. Es wird Ihnen auf dieser ziemlich coolen Servicekarte irgendwie genau zeigen, mit welchen Diensten Sie interagieren und wo Sie möglicherweise eine Regression erleben. Und ich denke, Spuren dienen dazu, diese Informationen an die Oberfläche zu bringen, was cool ist. Das könnte also etwas sein, das es wert ist, untersucht zu werden.
Jess Belliveau:
Es ist lustig. Das hat etwas nichts mit Beobachtbarkeit zu tun, aber Sie haben mich gerade dazu gebracht, ein bisschen mehr darüber nachzudenken, warum Sie sagen, dass Sie auch von Drittanbietern abhängig sind. Und etwas, das meiner Meinung nach wirklich wichtig ist und manchmal übersehen wird, ist, dass sich so viele von uns heute auf Drittanbieter verlassen, da AWS eine große Sache ist. Viele Leute schreiben Apps, für die AWS-Services erforderlich sind. Und ich denke, die meiste Zeit gehen die Leute einfach davon aus, dass AWS oder Jira oder was auch immer zu 100% verfügbar ist und immer verfügbar ist. Und sie schreiben ihren Code nicht so, dass er mit Ausfällen umgeht. Und ich finde es super wichtig. Ich habe schon so oft Leute gesehen, die die AWS-API verwenden, und sie implementieren kein exponentielles Back-Off. Also versuchen sie im Grunde, die AWS-API zu erreichen. Sie schlägt fehl oder sie werden zum Beispiel gedrosselt, und dann gehen sie einfach in einen Fehlerzustand über und geben dem Benutzer einen Fehler. Aber Sie könnten möglicherweise die Benutzererfahrung verbessern, einen automatischen Wiederholungsmechanismus einbauen lassen und so weiter. Es hat nicht wirklich etwas mit der Beobachtbarkeit zu tun, aber es ist etwas Besonderes.
Jared Kells:
Und den Nutzern ist das egal, oder? Es interessiert niemanden, ob es sich um ein AWS-Problem handelt. Es ist dein Problem, richtig, deine App ist zu langsam.
Jess Belliveau:
Nun, sie benutzen deine App. Genau richtig. Es wirkt sich irgendwie auf Sie aus, also ist es in Ihrem Interesse, sich vor einem Upstream-Fehler zu schützen oder zumindest den Benutzer zu informieren, wenn dies der Fall ist. Ja.
Jared Kells:
Nun, ich glaube, wir müssen ihn diesen Podcast nennen, weil es eine Stunde her ist. Wir hatten maximal 45 Minuten unterrichtet.
Jess Belliveau:
Wir könnten einfach weitermachen. Wir könnten einen zweiten Teil brauchen! Vielleicht können wir [Cross Talk 00:39:21] anfragen.
Jared Kells:
Vielleicht! Ja.
Jess Belliveau:
Oder wir starten einfach unseren eigenen Podcast! Ja.
Angad Seth:
Also, was waren deine wichtigsten Erkenntnisse heute, wenn man bedenkt, dass Angad und ich gerade etwas über Beobachtbarkeit lernen, Angad, was war heute deine größte Erkenntnis über Beobachtbarkeit? Meine größte Erkenntnis war, dass Beobachtbarkeit nicht mit Datadog gleichzusetzen ist. Nein, tut mir leid! Es war einfach sehr faszinierend zu lernen, wie man die bekannten Unbekannten quantifiziert. Ich weiß nicht, ob das ein guter Imbiss ist, aber...
Jess Belliveau:
Jeder Imbiss ist ein guter Imbiss! Was ist mit dir, Jared?
Jared Kells:
Ich glaube, weil ich gerade über Zustandsmanagement sprechen wollte, und ein Teil davon war, dass wir im Moment diese Fähigkeit haben, durch die Architektur unserer Frontends den Status der App zu erfassen und einen Kunden dazu zu bringen, uns seinen Status zu senden, im Grunde genommen. Und wir können es in unsere App laden und einfach genau sehen, wie es war, genau so, wie unser Bundesstaat konzipiert ist. Aber was noch cooler sein könnte, ist vielleicht etwas Observability zur Unterstützung in das Frontend einzubauen. Ich denke, anstatt einfach zu haben, haben wir diese Schaltfläche, um uns Ihre Support-Informationen zu senden, die uns einen Haufen des Status schicken, aber anstatt die Konsole im Browserprotokoll zu protokollieren, könnten wir die Konsole protokollieren und uns irgendwo in unserem Frontend anmelden, sodass unsere Kunden uns die Aktionen senden sollten, die sie ausgeführt haben, wenn sie auf „Support-Informationen senden“ klicken.
Jared Kells:
Zum Beispiel: „Hey, da ist ein Bug, senden Sie uns Ihre Support-Informationen.“ Es muss kein Drittanbieter-Dienst sein, der diese Observability-Daten sammelt. Wir könnten einfach in unser... Darüber denke ich also nach.
Jess Belliveau:
Ja, ganz sicher. Es wird wahrscheinlich auch viel weniger aufdringlich sein, als einige der Sachen von Drittanbietern, die ich gesehen habe.
Jared Kells:
Ja. Bei einigen dieser Integrationen ist das ziemlich schwierig, insbesondere wenn Sie Apps entwickeln, die hinter einer Firewall ausgeführt werden.
Jess Belliveau:
Ja
Jared Kells:
Sie können nicht einfach mit einigen dieser Dritten sprechen. Also ja, es ist trotzdem cool. Es ist wirklich interessant.
Jess Belliveau:
Nun, ich hoffe, jemand da draußen, der zuhört, hat etwas gelernt, und Jordan und ich werden ein paar Links durchschicken, und wir können sie hoffentlich zu den Shownotes hinzufügen oder so, damit die Leute etwas mehr lesen können und...
Jared Kells:
Alles danke!
Jess Belliveau:
Danke für die Einladung, ja.
Jared Kells:
Vielen Dank für Ihre Zeit und danke allen fürs Zuhören.
Jordan Simonowski:
Danke allen.
Angad Seth:
Das war [unhörbar 00:41:55].
Jess Belliveau:
Schaltet nächste Woche ein!
Verwandte Episoden
- Podcast
Easy Agile Podcast Ep.20 Die Bedeutung der Team-Retrospektive
„Es war toll, mit Caitlin über die Bedeutung der Team-Retrospektive für die Zusammenstellung eines leistungsstarken, funktionsübergreifenden Teams zu chatten“ — Chloe Hall
In dieser Folge wurde ich von Caitlin Mackie, Content Marketing Coordinator bei Easy Agile, begleitet.
In dieser Episode haben wir darüber gesprochen;
- Wir betrachten die Team-Retrospektive als Instrument zur Risikominderung und nicht nur als eine weitere agile Zeremonie
- Die Wichtigkeit, die Retrospektive in regelmäßigen Abständen durchzuführen
- Warum solltest du die Siege feiern?
- Übernehmen Sie die Aktionspunkte aus Ihrem Team im Rückblick auf Ihre Team-Sprintplanung
- Timeboxing — Die Retrospektive
- Schaffen Sie eine psychologisch sichere Umgebung für Ihre Team-Retrospektive
Ich hoffe, euch gefällt die heutige Folge genauso gut, wie ich sie aufgenommen habe.
Transkript
Chloé Hall:
Hallo zusammen. Willkommen zum Easy Agile Podcast. Ich bin Chloe, Marketingkoordinatorin bei Easy Agile, und ich werde Ihre Moderatorin für die heutige Folge sein. Bevor wir beginnen, möchten wir den traditionellen Hütern des Landes, von dem aus ich heute aufnehme, unsere Anerkennung aussprechen, dem Volk der Wodi Wodi aus der Dharawal sprechenden Nation, und den Ältesten aus Vergangenheit, Gegenwart und Entwicklung unseren Respekt erweisen. Den gleichen Respekt zollen wir allen Aborigines und den Bewohnern der Strait Islander, die heute zuhören. Heute haben wir also eine etwas andere Episode für Sie. Ich werde mit Caitlin Mackie, der eigenen Content-Marketing-Koordinatorin von Easy Agile, sprechen. Caitlin ist die Product Owner* unseres Marken- und Konversions-Teams*. Jetzt ist dieses Team ein funktionsübergreifendes Team, das erst seit etwa sechs Monaten zusammen ist. Und in den ersten Monaten hatten sie als Team, wohlgemerkt, auch zwei brandneue Mitarbeiter, sie arbeiteten an einem Rebranding des Unternehmens.
Chloé Hall:
Ein neues Team, eine riesige Aufgabe, die Möglichkeit, dass das Team Höchstleistungen erbringt, war zu diesem Zeitpunkt unwahrscheinlich. Das Team war also zu neu, um dieses Vertrauen, die starken Beziehungen und die psychologische Sicherheit bereits aufgebaut zu haben, aber irgendwie kamen sie zusammen und schafften es, zusammenzuarbeiten, einen Fluss kontinuierlicher Verbesserungen zu schaffen und dieses Rebranding zu veröffentlichen. Deshalb habe ich heute Caitlin in den Podcast aufgenommen, um das Erfolgsgeheimnis des Teams zu besprechen. Willkommen zum Podcast, Caitlin.
Caitlin Mackie:
Danke, Chloe. Es ist etwas anders, auf dieser Seite zu sitzen. Ich bin es gewohnt, in deinen Schuhen zu stehen. Ich fühle mich [unhörbar 00:01:45]. Ich fühle mich unwohl. [unhörbar 00:01:46].
Chloé Hall:
Ja. Es ist auch mein erstes Mal, dass ich Gastgeber bin, sehr seltsam. Ist es nicht? Wie fühlst du dich heute?
Caitlin Mackie:
Ja. Gut. Ich freue mich. Ich freue mich darauf, über unsere Erfahrungen als funktionsübergreifendes Agile-Team zu sprechen und hoffentlich einige der Dinge, die für uns funktioniert haben, mit unseren Zuhörern zu teilen.
Chloé Hall:
Ja, ich weiß es selbst und ich bin mir sicher, dass unser Publikum sehr gespannt ist, was das Erfolgsgeheimnis Ihres Teams war. Wolltest du uns zunächst sagen, was dieses große Geheimnis war, das dir wirklich geholfen hat, als Team zusammenzuarbeiten?
Caitlin Mackie:
Das ist eine gute Frage, Chloe. Und das ist eine große Frage. Ich bin mir nicht sicher, ob es eine wichtige Sache gibt, ich nehme an, es ist diese ultimative geheime Quelle oder die eine Sache, die zum Erfolg geführt hat. Ich bin mir sicher, dass wir alle hören wollen, was das ist. Ich würde auch gerne wissen, ob es nur diese eine wichtige Zutat gibt, aber ich denke, etwas für uns, und wahrscheinlich eines der denkwürdigsten Dinge, die für uns wirklich funktioniert haben und von dem wir viel profitieren konnten, war, unsere Retrospektiven zu machen. Das ist wahrscheinlich das Erste, was mir in den Sinn kommt, wenn es darum geht, was zu unserem Erfolg geführt hat.
Chloé Hall:
In Ordnung. Ja. Warum hast du am Anfang mit den Retrospektiven angefangen?
Caitlin Mackie:
Wir waren also ein neu formiertes Team, wie Sie bereits erwähnt haben, und wir haben Retrospektiven als eine weitere Agile-Zeremonie gesehen, und wir haben gesehen, wie andere Teams das gemacht haben und sie hatten viel Erfolg damit, also sind wir auf diesen Zug aufgesprungen. Und ich denke, wenn wir ein neues Team bilden, kommen so viele Dinge ins Spiel. Sie versuchen also, sich gegenseitig herauszufinden, wie wir alle gerne arbeiten und miteinander kommunizieren, all das. Und wir waren das erste Team, das sich dem Besitz und der Verbesserung unserer Website verschrieben hat. Und wir wussten auch, dass wir wahrscheinlich für die Gestaltung und Einführung eines Rebrandings verantwortlich sein würden.
Caitlin Mackie:
Wenn Sie also versuchen, all das zusammenzufügen und dann all diese Elemente berücksichtigen, wussten wir, dass wir etwas Zeit einplanen mussten, um schnell iterieren und herausfinden zu können, was funktioniert und was nicht. Und was wir verstanden haben, ist, dass Retrospektiven eine großartige Gelegenheit für das gesamte Team sind, um alle problematischen Probleme aufzudecken und eine offene Diskussion zu führen, um wirklich Verbesserungspotenzial zu identifizieren oder herauszufinden, was gut funktioniert, damit wir das auch weiterhin tun können. Ich denke, Rückblicke haben es uns ermöglicht zu verstehen, wo wir die größte Wirkung erzielen können und wie wir ein wirklich effektives, funktionsübergreifendes Agile-Team bilden können.
Chloé Hall:
Beeindruckend. Das ist schon so aufschlussreich. Ja, es hört sich so an, als ob Ihnen die Retrospektiven wirklich dabei geholfen haben, herauszufinden, wer Ihr Team ist, und ein gut funktionierendes, leistungsstarkes, funktionsübergreifendes Team zu werden. Also, wie oft hast du Retro gemacht? Hast du das in einem regelmäßigen Zyklus gemacht, oder war es nur: „Okay. Wir haben ein Problem. Es sind ein paar Blocker aufgetaucht, wir müssen einen Retro machen“?
Caitlin Mackie:
Ja. Ich glaube, anfangs waren Retros für uns so etwas wie: „Oh, wir haben jetzt ein paar Sprints gemacht. Wir sollten wahrscheinlich einen Retro machen und einfach darüber nachdenken, wie diese paar Sprints gelaufen sind.“ Es war irgendwie wie dieses Ding. Es war immer im Hinterkopf. Und wir wussten, dass wir es tun mussten, waren uns aber nicht wirklich sicher, was den Rhythmus und die Art und Weise angeht, wie wir das machen sollten. Jetzt machen wir Retros an einem Freitagmorgen, dem letzten Tag unseres wöchentlichen Sprints. Und danach beginnen wir mit der Sprint-Planung. Also auch nach der Biopause, also lass das Team alles verdauen, worüber wir in Rückblicken gesprochen haben. Und dann kommen wir zur Sprint-Planung mit all den Themen, die wir besprochen haben, und wir werden eine wirklich nette, frische Perspektive haben.
Chloé Hall:
Ja.
Caitlin Mackie:
Also, ich denke, das funktioniert wirklich gut für uns, weil alles zeitnah passiert. Wir hatten gerade eine Diskussion über die besten Dinge, die im Sprint passiert sind oder was wirklich gut funktioniert hat. Sie sollten also sicherstellen, dass Sie im Folgenden dasselbe Verhalten üben können, und umgekehrt, wenn es um die Verbesserungen geht, die Sie vornehmen möchten. Also, diese Liste der Aktionspunkte, die aus einer Retrospektive hervorgegangen sind, bietet einen wirklich netten Kontakt, Kontext, tut mir leid. Und Sie haben sie alle bei der Sprint-Planung im Hinterkopf.
Caitlin Mackie:
So könnte es beispielsweise im vorherigen Sprint vorkommen, dass Sie Ihre Storypoints unterschätzt haben oder dass Ihre User Stories nicht detailliert genug waren. Bei jeder Story oder Aufgabe, die Sie in den Sprint einbringen, stellen Sie dann die Frage: Sind alle mit dem Detaillierungsgrad zufrieden? Was fehlt uns? Oder wir haben nur auf diese oder zwei Geschichten hingewiesen, ist es wahrscheinlicher, dass es eine Fünf ist? Also, alles ist wirklich frisch in deinem Kopf, und ich denke definitiv, dass das hilft, Dynamik zu erzeugen. Wenn das gesamte Team daran arbeitet, herauszufinden, wie Sie mit jedem Sprint effektiver sein können.
Chloé Hall:
Das ist so toll, dass du Caitlin gerade angesprochen hast. Und ich finde es toll, wie man nach der Team-Retrospektive diese Aktionspunkte tatsächlich nehmen und in den Sprint übergehen und sie sofort umsetzen kann. Es ist wirklich gut. Ansonsten habe ich das Gefühl, wenn du die Sprint-Retrospektive am Freitag machst und sagst: „Okay, das sind unsere Aktionspunkte“, dann gehst du zur Sprintplanung für Montag und denkst nur an das Wochenende. Das [unhörbar 00:07:20]
Caitlin Mackie:
Ja, hundertprozentig. Ja. Sie sind für jeden ein superfrischeres Gemüt. Es funktioniert vielleicht nicht für jedes Team, aber wir finden, dass es für uns wirklich gut funktioniert, weil wir bei der Sprint-Planung sehr sorgfältig vorgehen.
Chloé Hall:
Ja. Und dann konnte ich mir vorstellen, wie man das Retro macht, wie es leicht im Laufe der Zeit gehen könnte, aber dann hat Ihr Team die Sprint-Planung danach geplant. Es ist also so, als ob du die Zeit nicht verlängern kannst. Wie haben Sie es geschafft, diese Retrospektive irgendwie in eine Zeitbox zu packen?
Caitlin Mackie:
Ja, das ist eine wirklich, wirklich gute Frage. Und es ist auch beabsichtigt, dass sie eng zusammen geplant sind. Wie bereits erwähnt, gibt die Diskussion, die Sie in den Retrospektiven geführt haben, einen schönen Impuls für die Sprint-Planung, aber das bedeutet, dass wir auf die Uhr schauen müssen. Und am Anfang kann das ziemlich umständlich sein, weil Sie sicherstellen wollen, dass sich jeder gehört fühlt und dass jeder die gleiche Gelegenheit hat, etwas beizutragen. Und ich denke, diese Verantwortung liegt beim Scrum Master oder beim Product Owner oder bei wem auch immer, der die Retrospektive moderiert, um darauf hinzuweisen und sicherzustellen, dass jeder die Chance hat, gehört zu werden. Natürlich lassen Sie die Leute die längere Geschichte erzählen oder fügen viel zusätzlichen Kontext hinzu, bevor Sie zur Sache kommen. Und dann wirst du andere haben, die viel direkter sein werden. Und letzterem bin ich sehr ähnlich. Mir fällt es schwer, auf den Punkt zu kommen, was nicht gut funktioniert, wenn man versucht, eine Retrospektive mit einem Timebox zu versehen, oder?
Chloé Hall:
Und ich kann das nachvollziehen, dieselbe Persönlichkeit.
Caitlin Mackie:
Ja. Also, ich denke, es kommt wirklich darauf an, die Erwartungen und Prioritäten von Anfang an zu kommunizieren. Mit unserem Team und mit jedem Team wirst du herausfinden wollen, wen du wirklich gut abschneiden und dich kontinuierlich verbessern kannst, um die Erwartungen zu übertreffen, besser zu werden und gemeinsam zu lernen und zu wachsen. Und ich denke, wenn ihr alle die gleiche Denkweise teilt, wenn ihr in die Retrospektive geht und anerkennt, dass das sicher ist
Raum für schwierige Gespräche. Und solange Sie mit Empathie kommunizieren, weiß das Team, dass es nie um etwas Persönliches geht und dass alles im besten Interesse des Teams ist. Und das hilft dann den weniger direkten Kommunikatoren wie mir, ihren Standpunkt prägnanter anzusprechen und zwingt sie wirklich dazu, ihren Kommunikationsstil überlegter und prägnanter zu gestalten.Caitlin Mackie:
Und das ist wirklich wichtig, um diese Zeitbox einhalten zu können, denke ich. Und das erfordert Übung, denn es kommt darauf an, diese psychologische Sicherheit in Ihrem Team zu schaffen. Aber wenn das erst einmal da ist, ist es viel einfacher, zu rufen, wenn jemand eine windige Strecke hinunterfährt, und den Fokus wieder zu richten und irgendwie zu sagen: „Ich verstehe dich, was ist der Aktionspunkt?“ Und werde einfach viel bewusster.
Chloé Hall:
Beeindruckend. Ich konnte mir nicht vorstellen, wie schwer es sein würde, mit den Persönlichkeiten, die du und ich haben, zu versuchen, so direkt zu sein und all das flauschige Zeug loszuwerden. Ich meine, sieh dir an, was getan wurde, um ein so großartiges Team zu bilden, das wir haben. Also, Sie haben diesen Aspekt der psychologischen Sicherheit bereits erwähnt. Und wie denkst du, in einem neuen funktionsübergreifenden Team zu sein... Nur sechs Monate zusammen, Sie hatten diese neuen Mitarbeiter. Glauben Sie, Sie waren jederzeit in der Lage, einen psychologischen Sicherheitsraum zu schaffen?
Caitlin Mackie:
Das ist eine weitere fantastische Frage. Und ich denke, ehrlich gesagt, wäre es am besten, eine Teamdiskussion darüber zu führen. Es wäre interessant, die Meinungen aller dazu zu hören, was zu diesem Element der psychologischen Sicherheit beiträgt und ob es allen genauso geht. Ich kann also nicht für das Team sprechen, aber meine persönliche Meinung zu dieser oder meiner persönlichen Erfahrung ist, dass die Schaffung eines Umfelds psychologischer Sicherheit wirklich von gegenseitigem Vertrauen und Respekt abhängt. Und am Ende des Tages verfolgen wir alle dasselbe Ziel. Wir alle respektieren also wirklich, wirklich, was der andere mitbringt, und verstehen, wie all diese beweglichen Teile, an denen wir individuell arbeiten, zusammenkommen, um das Ziel zu erreichen. Wenn wir also diese offenen Diskussionen im Rückblick führen oder nicht einmal in Retros, sondern einfach nur allgemein kommunizieren, ist klar, dass wir Fragen im besten Interesse des Teams stellen und individuelle Motive nie ins Spiel kommen, oder die Leute äußern ihre Meinung nicht einfach, wenn sie ungerechtfertigt ist, oder geben Feedback oder sind übermäßig kritisch, wenn sie nicht darum gebeten wurden.
Caitlin Mackie:
Keines dieser toxischen Verhaltensweisen passiert also, weil wir alle respektieren, dass unabhängig von der fraglichen Arbeit oder dem Diskussionsthema die Person, der diese Arbeit gehört, am Ende des Tages der Experte ist. Und wir vertrauen ihnen und zweifeln keine Sekunde lang aneinander. Und ich denke, die andere Hälfte davon ist, dass wir auch wirklich Glück haben, dass wir alle da sind, um uns gegenseitig abzuholen und weiterzumachen, wenn etwas nicht so läuft, wie wir es geplant hatten. Das passt also ganz gut dazu, dass einer unserer Werte bei Easy Agile darin besteht, sich als Team zu engagieren. Und hier geht es darum, anzuerkennen, dass wir wachsen und erfolgreich sind, wenn wir es gemeinsam tun, aufeinander aufzupassen und uns mit Authentizität und Mut zu engagieren. Manchmal mag ich voreingenommen sein, aber ich glaube von ganzem Herzen, dass unser Team das voll und ganz akzeptiert. Und es gibt einfach eine solche Bewunderung für das, was wir alle an den Tisch bringen, und ich denke, das ist wirklich der Schlüssel zur Schaffung der psychologischen Sicherheit.
Chloé Hall:
Ich finde es toll, dass Ihr Team unseren Wert wirklich annimmt, sich als Team engagiert und ihn umsetzt, denn genau darum geht es uns bei Easy Agile, und es ist einfach großartig, das auch zu sehen. Ich denke, die andere Sache
Ich wollte ansprechen war... Also nochmal, während dieses funktionsübergreifenden Teams, und du hast Design und Entwicklung, wie hat dir Retros deiner Meinung nach geholfen, herauszufinden, was Design und Entwicklung voneinander brauchen?Caitlin Mackie:
Ganz gewiss. Also, für etwas mehr Kontext für unsere Zuhörer, also haben wir in unserem Team zwei Entwickler, Haley und David, und einen Designer, Matt und mich, der im Marketing tätig ist. Wir sind also quasi ein funktionsübergreifendes kleines Mini-Team. Wir haben also alle das gleiche Ziel und den gleichen Fokus, aber wir arbeiten auch alle an diesen kleinen Einzelkomponenten, die wir dann zusammenfügen. Also, ich denke... Wir machen regelmäßig Retros. Was wir feststellen konnten, war ein wirklich effektiver Design- und Entwicklungszyklus. Also haben wir einen Rhythmus für das gefunden, was wir an bestimmten Stellen gegenseitig brauchten. Wir haben zum Beispiel sehr früh herausgefunden, dass wir sicherstellen mussten, dass wir Design- und Entwicklungsarbeit nicht in denselben Sprint bringen. Wir brauchten eine vollständig fertige Designdatei, bevor die Entwickler mit der Arbeit daran beginnen konnten. Und das klingt vielleicht sehr offensichtlich, aber anfangs dachten wir: „Oh, nun, wenn du eine halbfertige Design-Datei hast, kann der Entwickler anfangen, daran zu arbeiten. Und wenn das erledigt ist, wird der Rest der Design-Datei fertig sein.“
Caitlin Mackie:
Was wir jedoch nicht eingestanden haben, ist, dass wir dadurch nicht genug Kapazität hatten, um zu iterieren oder Probleme zu lösen oder Feedback zum ersten Teil dieser Designdatei einzubeziehen, oder wenn der Entwickler angefangen hat, daran zu arbeiten und das Design dann gesagt wird: „Oh, dieser Teil hier, das ist nicht möglich“, sodass der Designer wieder am ersten Teil arbeitet. Und es schafft einfach eine Menge dieser Hindernisse. Im Rückblick kam das zur Sprache und wir konnten es ansprechen und verstehen, welches Design vom Entwickler benötigt wird und was der Entwickler vom Design braucht, um sicherzustellen, dass wir uns nicht gegenseitig blockieren. Und das Wichtigste an der Retro-Version ist, dass wir uns alle einig waren, dass eine Design-Datei komplett fertig sein muss, bevor der Entwickler mit der Arbeit beginnt.
Chloé Hall:
Ich finde es so toll, dass du diese Blocker schon früh identifizieren konntest. Glaubst du, dass es durch die wöchentliche Wiederholung dieser Blocker schnell zum Vorschein kommen konnte, oder glaubst du, das hätte keinen Unterschied gemacht?
Caitlin Mackie:
Nein, auf jeden Fall. Ich bin hundertprozentig der Meinung, dass Retros es uns ermöglicht haben, die Blockaden zeitnaher und effektiver anzugehen. Und das haben wir schon einmal angesprochen, aber ja, mit Retros kannst du die Blocker angehen, sie auspacken, verstehen, warum sie passieren und was wir tun müssen, um sicherzustellen, dass sie nicht wieder auftreten. Also, auf jeden Fall.
Chloé Hall:
Ja. Ja. Ich glaube, ich möchte jetzt ein bisschen über die Siege sprechen, den sehr aufregenden Teil des Retro, den Teil, den wir alle lieben. Also, wie wichtig sind deiner Meinung nach die Siege im Retro-Bereich?
Caitlin Mackie:
So wichtig. So, so, so wichtig. Also, wenn man als Team etwas Episches erreicht, muss man es herausfordern. Feiert alle Siege, ob groß oder klein. Manche Wochen werden besser sein als andere, aber genießen Sie die Mentalität, dass Glas halb voll ist. Und es gibt immer etwas, auf das man stolz sein und feiern kann, also rufen Sie es aus
einander, teile es mit dem ganzen Unternehmen, erkenne es öffentlich an. Ja, ich denke, es ist so wichtig, die Siege zu begrüßen. Es schafft einfach eine wirklich positive Atmosphäre, wenn man im Team ist. Jeder fühlt sich gehört und anerkannt für seinen wirklich positiven Beitrag, den er leistet. Und ich denke, eine große Sache hier ist auch, dass, wenn Sie als Team etwas Episches erreicht haben, es für andere Teams hilfreich ist, das auch zu hören, oder? Ihr habt einen coolen neuen Weg gefunden, etwas zu tun, teilt ihn. Wenn es dir als Team geholfen hat, wird es höchstwahrscheinlich einem anderen Team helfen.Caitlin Mackie:
Ich denke also, dass das Feiern der Siege auch nicht nur der Arbeit vorbehalten ist, oder? Wenn jemand außerhalb der Arbeit etwas Tolles tut oder ein persönliches Ziel erreicht, dann stehen Sie dahinter.
Chloé Hall:
Ja.
Caitlin Mackie:
Um immer alle Siege zu feiern.
Chloé Hall:
Ja. Und ich finde es so gut, wie du erwähnt hast, dass es wichtig ist, auch die Siege im Privatleben eines Menschen zu feiern, denn am Ende des Tages sind wir alle Menschen. Ja, wir kommen zur Arbeit, aber wir haben dieses persönliche Element. Und zu wissen, wie jemand auch außerhalb der Arbeit ist, ist ein Element, um diesen psychologischen Sicherheitsraum und die Teambindung zu schaffen, die so wichtig sind, um am Ende des Tages ein gutes Team zu haben. Ja.
Caitlin Mackie:
Ja, hundertprozentig. Ja, damit hast du den Nagel in den Kopf getroffen. Ja, wir haben schon über psychologische Sicherheit gesprochen, und ich denke definitiv, das mit einzubeziehen, anzuerkennen, dass wir bei der Arbeit wir selbst sind, aber wir haben auch ein ganz anderes Leben außerhalb davon, also achten wir einfach darauf und feuern uns die ganze Zeit gegenseitig an. Das müssen wir tun, die größten Cheerleader des anderen sein.
Chloé Hall:
Ja, genau. Das ist der wahre Schlüssel zum Erfolg. Ist es nicht?
Caitlin Mackie:
Ja, das ist es. Das ist der Schlüssel.
Chloé Hall:
Sie haben also als neues funktionsübergreifendes, leistungsstarkes Agile-Team wirklich gut gearbeitet. Wie denkst du... Wie sieht dein zukünftiger Prozess für Retros aus?
Caitlin Mackie:
Wir werden sie auf jeden Fall weiterhin wöchentlich machen. Es ist Teil des Agile-Manifests, aber wir wollen uns darauf konzentrieren, auf Veränderungen zu reagieren, und ich denke, Retros ermöglichen uns das wirklich. Es ist nützlich und wirklich wertvoll für
das Team. Und wenn Sie das Team auf Erfolgskurs bringen können, werden Sie die positiven Auswirkungen sehen, die sich auf das gesamte Unternehmen auswirken. Also ja, wir haben eine schöne Trittfrequenz und einen Rhythmus gefunden, der für uns funktioniert. Also, wenn es nicht kaputt ist, repariere es nicht.Chloé Hall:
Ja.
Caitlin Mackie:
Sagen sie das? Ist das das Sprichwort?
Chloé Hall:
Ich weiß nicht. Ich glaube schon, aber lass uns einfach weitermachen. [unhörbar 00:19:02], repariere es nicht.
Caitlin Mackie:
Da haben wir's. Ja.
Chloé Hall:
Du kannst Caitlin Mackie dazu zitieren.
Caitlin Mackie:
Zitiere mich dazu.
Chloé Hall:
Okay, Caitlin. Okay, es gibt nur noch eine letzte Sache, die ich heute ansprechen möchte. Ich dachte, Ende des Podcasts, lass uns einfach ein bisschen Spaß haben und wir werden einen kleinen Ausschnitt von Caitlins heißem Tipp machen. Also, für das Publikum, das zuhört, möchte ich, dass du dir etwas ausdenkst, das sie aus dieser Folge mitnehmen können, einen Action-Punkt, mit dem sie heute in ihren Teams beginnen können. Nimm es weg.
Caitlin Mackie:
In Ordnung. Okay. Alles klar. Ich würde sagen, mach immer die Retrospektive. Überspringe es nicht. Auch wenn es nur wenige Punkte zu besprechen gibt, werden immer neue Dinge auftauchen. Und Sie müssen dem Team regelmäßig Möglichkeiten bieten, seine Gedanken auszutauschen. Und ich überlasse es Ihnen: Fördern Sie stets einen positiven Dialog und zeigen Sie Wert und Wertschätzung für Teamideen und füreinander. Das ist mein...
Chloé Hall:
Ich liebe das.
Caitlin Mackie:
Das ist mein heißer Tipp.
Chloé Hall:
Danke, Caitlin. Danke fürs Teilen. Mir gefällt wirklich, wie Sie gesagt haben, fördern Sie immer einen positiven Dialog. Ich finde das so toll. Ja. Ja, danke, Caitlin. Danke, dass du heute auf den Podcast gekommen bist und...Caitlin Mackie:
Danke, Chloe.
Chloé Hall:
Ja. Teilen Sie die Erfahrungen Ihres Teams mit Rückblicken und einem neuen funktionsübergreifenden Team. Es war wirklich nett, von Ihnen zu hören, und es gibt so viel, was unser Publikum von dem, was Sie heute mit uns geteilt haben, mitnehmen kann. Und ich hoffe, dass wir wirklich alle Zuhörer dazu inspiriert haben, rauszugehen und die Team-Retrospektive regelmäßig durchzuführen. Also, ja, danke.
Caitlin Mackie:
Vielen Dank, Chloe. Danke, dass du mich eingeladen hast. Es hat Spaß gemacht, Spaß, auf dieser Seite zu sein. Und ich hoffe, jeder genießt diese Episode.
Chloé Hall:
Danke, Caitlin.
Caitlin Mackie:
Danke. Tschüss.
- Podcast
Easy Agile Podcast Folge 1 Dominic Price, Work Futurist bei Atlassian
„Ich hatte das Vergnügen, mich hinzusetzen, um mit Dominic Price von Atlassian zu chatten. Es hat so viel Spaß gemacht, über meine Zeit bei Atlassian nachzudenken und zu hören, wie Dom aus seiner Sicht ein großartiges Team ausmacht, wie man eine authentische Kultur aufbaut und die Dinge priorisiert, die wichtig sind.“
- Nick Muldoon, Co-CEO von Easy Agile
Transkript:
Nick Muldoon:
Was ich gerne ansprechen und was ich gerne erforschen wollte, Dom, war in Wirklichkeit diese Entwicklung des Denkens bei Atlassian. Ich erinnere mich, als wir uns das erste Mal begegnet sind, und korrigiere mich, wenn ich falsch liege, aber ich erinnere mich, dass es Ende 2014 war, glaube ich.
Dom-Preis:
Ja, war es.
Nick Muldoon:
Scrum Australia lief zu der Zeit, und du bist in den Büros in der George Street über Westpac, wo auch immer, und wir hatten Slady im Raum, da warst du. Ich glaube, Mairead könnte dort gewesen sein, ich bin mir nicht sicher.
Dom-Preis:
Nein, wahrscheinlich nicht. Ich glaube, es war das Ingenieurtreffen von JML, das Treffen mit den technischen Beziehungen.
Nick Muldoon:
Richtig.
Dom-Preis:
Involviert an der
Nick Muldoon:
Hall of Justice, richtig? Nicht die Hall of Justice.
Dom-Preis:
Nicht Hall of Justice. Avengers.
Nick Muldoon:
Avengers. Wann warst du das letzte Mal in Avengers?
Dom-Preis:
Vor langer, langer Zeit. Vor langer, langer Zeit.
Nick Muldoon:
Du arbeitest seit März Vollzeit von zu Hause aus, oder?
Dom-Preis:
Ja. Ja, aber für mich kann ich dreieinhalb Jahre von überall aus arbeiten.
Nick Muldoon:
Ja, fair genug. Okay.
Dom-Preis:
In der Schicht fehlte für mich das Arbeitselement. Mir fehlt das persönliche Arbeitselement, weil ich viel unterwegs bin und ein oder zwei Tage die Woche im Büro bin, da ist Bindegewebe, ich wusste nicht, wie wertvoll das ist. Fünf Tage von zu Hause aus zu arbeiten, ist für mich keine gute Mischung.
Nick Muldoon:
Nein, für mich auch keine gute Mischung, Kumpel. Ich war derjenige, der während des Lockdowns ins Büro kam. Ich sagte: „Oh.“ Ich schätze, es war im Grunde eine Erweiterung meines Hauses, weil ich der Einzige war, der reinkam. Aber ich könnte die Musik lauter drehen und ein bisschen Arbeit erledigen, ohne...
Nick Muldoon:
Ja. In Ordnung. Ende 2014, als sich unsere Wege zum ersten Mal kreuzten, waren wir auf dem Engineering-Meeting von JML, und das war, bevor JML zu Shopify gegangen war.
Dom-Preis:
Ja.
Nick Muldoon:
Wir haben über alle Dinge gesprochen. Ich erinnere mich, dass ich über OKRs gesprochen habe, das Objective Key Result Framework, das wir bei Twitter verwendet haben und das Atlassian meiner Meinung nach zum ersten Mal betrachtet hat.
Dom-Preis:
Ja, mit uns flirten wir schon eine Weile.
Nick Muldoon:
Eine Weile damit flirten. Was hat Atlassian zu der Zeit verwendet? Was war VTFM?
Dom-Preis:
Es gab zwei Dinge, die wir zu der Zeit hatten. VTFM, das war Vision, Schwerpunktbereiche, Themen und Maßnahmen. Das war unsere Art, unsere Strategie zu kommunizieren, unsere Strategie für fortlaufende Probleme. Aber auf der Rückseite hatten wir, was ich als KPIs der alten Schule bezeichnen würde. Richtig? Wir würden Tore auswählen, richtig, wir würden Methoden wählen, um diese Tore zu messen, aber sehr auf KPIs und sehr auf rote, gelbe und grüne Tore. Als wir klein waren, hat es gut funktioniert. Es hat sich nicht besonders gut skaliert, weil es strafend wurde. Wenn du grün warst und deinen Punktestand getroffen hast, wurdest du ignoriert, weil du immer dazu bestimmt warst, und wenn du gelb oder rot warst und etwas verpasst hast, wurdest du bestraft. Richtig? Es ist wie: „Bitte erkläre es.“ Du hast die Einladung zum Büro des Schulleiters bekommen.
Dom-Preis:
Wir wollten eine Möglichkeit haben, uns in diese Richtung zu ziehen und auch ergebnisorientierter zu sein, denn ich glaube, als wir die KPIs skaliert haben, waren wir sehr leistungsorientiert wie: „Was hast du diese Woche gemacht? Was ist das Ding, das du versendet hast?“ Eigentlich war das, was wir vergessen haben, und ich glaube, es war ein Zufall, es war keine böse Absicht, aber wir haben vergessen, welches Ergebnis oder welche Wirkung wir auf den Kunden haben wollen, denn das passiert nach dem Ereignis. OKRs waren eine Möglichkeit, das Ganze zu dehnen und die Idee von Moonshots und großen Ambitionen zu entwickeln. Aber dann konzentrieren wir uns wieder darauf, welche Wirkung wir auf den Endkunden haben wollen, und nicht nur auf das, was in der Wurstfabrik passiert?
Nick Muldoon:
Aber mit dieser Endkundenperspektive, haben Sie das mit dem VTFM verstanden?
Dom-Preis:
Nein. Tatsächlich war das im ersten Jahr, in dem wir das OKR gewürfelt haben, Teil des Problems. Wir hatten das VTFM, weil das geblieben ist, oder? Das war wie die heilige Kuh im ersten Jahr. Das blieb, und wir hatten einfach OKRs darunter. Ja, und wir sagen: „Nun...
Nick Muldoon:
Du mischst sie also zusammen.
Dom-Preis:
... welche melden wir? Die Maßnahmen im VTFM, weil das unser Atlassian-Levelplan ist, oder die OKRs, also die Dinge, die wir tatsächlich tun, und die Auswirkungen, die wir haben. Du sagst: „Nun, beide“, und du sagst: „Nun, sie treffen sich nicht. Es gibt keine Kaskade nach oben oder unten, links oder rechts, die sie richtig ausgerichtet hätte.“ Im Jahr darauf haben wir tatsächlich... das VTFM abgeschafft, und jetzt haben wir unsere fortlaufende 12-Monats-Strategie, die als OKRs formuliert ist.
Nick Muldoon:
Richtig. In Ordnung. Zu der Zeit, Dom, im Jahr 2014, als du mit OKRs flirtest, wie du schon sagtest, war das VTFM, das du ersetzen wolltest, war das Unternehmen, die Abteilung, das Team, die Einzelperson, oder hörte es einfach beim Team auf?
Dom-Preis:
Ja. Da hat es nicht wirklich skaliert, oder? Das organisatorische war sinnvoll, und auch hier gilt: Wenn Sie kleiner sind, ist es viel einfacher, die Verbindung zwischen Ihrem Team oder Ihrer Abteilung und dem Unternehmen herzustellen. Als wir skalierten, hatten wir ein VTFM auf Unternehmensebene, und dann baute jede Abteilung ihr eigenes auf. Das Seltsame ist, und wieder funktioniert das für eine Phase, und dann merkt man, dass es nicht so ist, dass wir keinen Wert innerhalb der Organisation schaffen. Wir schaffen Werte in der gesamten Organisation, und daher war der Aufbau dieser VTFMs in den Abteilungen eine Verfeinerung unseres Fachs. Aber das ging auf Kosten der Art und Weise, wie Sie teamübergreifend arbeiten.
Dom-Preis:
Ich denke, das ist eines dieser Dinge, die wir zu der Zeit nicht realisiert haben. Hätte ich eine Kristallkugel gehabt, wäre sie toll gewesen. Aber es schien das Richtige zu sein. Das Ingenieurwesen hatte einen VTFM. Das Design auch, das Produktmanagement auch, und Sie sagen: „Sie wissen, dass wir nur ein Erlebnis versenden, oder?“ Mir ist egal, ob die Technik perfekt ist und das Design nicht, weil das den Kunden wegen dieses einen Erlebnisses, das wir geliefert haben, im Stich lässt. Es gab eine ganze Art von Schiedsverfahren, bei dem wir sie vertikal gebaut und dann versucht haben, sie horizontal zusammenzukleben, aber sie wurden alle isoliert gebaut.
Dom-Preis:
Wenn es dann um Kompromisse geht, und jedes Unternehmen hat Kompromisse, ob Sie es zugeben oder nicht, wenn Sie wie die besten Pläne sind, bleiben Sie buchstäblich auf dem Papier, oder? Dort existieren sie, dann tritt die Realität einen Tag nach der Erstellung des Plans ein. Welchen Kompromiss wirst du eingehen, wenn die Realität einsetzt? Gehen Sie den Kompromiss ein, der den Kunden erfreut und Sie vielleicht kompromittiert? Richtig? Wie machst du das dann intern? Wirst du Design und Produktmanagement beim Lastenausgleich auf diese Weise unterstützen oder sagen: „Nun ja, ich bin Ingenieur und es geht uns gut. Das Design ist schuld. Es ist die Schuld des Designs, wie wir uns an alle anpassen würden.“ Wir stellten schnell fest, dass ein vertikales Modell einige unbeabsichtigte Konsequenzen und einige merkwürdige Verhaltensweisen mit sich brachte, die wir uns als Atlassian nicht wirklich gewünscht hatten.
Nick Muldoon:
Damals, Dom, in den Jahren 2014, 2015, hattest du den Dreiklang damals mit dem Produktdesign und später für jede dieser Gruppen?
Dom-Preis:
Bei physischen Menschen ja.
Nick Muldoon:
Aber in-
Dom-Preis:
... modeln, nein.
Nick Muldoon:
Nein. Okay. Wie kam das zustande, dieser Dreiklang, bei dem sie harmonisch zusammenarbeiteten, um dieses Kundenerlebnis zu bieten?
Dom-Preis:
Ich denke, im Grunde ist es einer dieser brillanten Fehler, wenn man zurückblickt. Wir sind wirklich gut darin, zu reflektieren, und man macht ein paar Überlegungen, und plötzlich sieht man das Muster und denkt: „Hey, unsere Teams, die es auf den Punkt bringen, sind diejenigen, in denen wir kognitive Vielfalt und ein ausgewogenes Verhältnis von Fähigkeiten haben.“ Nicht, wo wir einen Experten oder irgendwas Tolles haben, aber eigentlich sagst du: „Ja, eigentlich —
Nick Muldoon:
Wenn du dir einige dieser Muster ansiehst...
Dom-Preis:
Ja. Du sagst: „Hey, ich habe gerade das Design gesehen.“ Sie bringen den Produktmanager in einen Schwitzkasten und haben ein stichhaltiges Argument an einem Whiteboard. Du sagst: „Das gefällt mir wirklich. Das gefällt mir, ein Treffen, bei dem Konsens und gewaltsame Übereinstimmungen herrschen.“ Vielleicht ist das das falsche Signal, richtig, dass das richtige Signal diese kognitive Vielfalt ist, dieser respektvolle Dissens. Sie sehen das und wir sagen: „Moment mal, wir haben die Erkenntnis, dass Ingenieure großartige, nutzbare Produkte entwickeln und Produktmanager zusammen mit den Designern über die gesamte Art der Benutzerfreundlichkeit nachdenken. Viability, du sagst: „Oh, wir brauchen alle drei. Für ein großartiges Erlebnis müssen alle drei Aspekte offensichtlich sein.“ Du sagst: „Cool. Lass uns das verdoppeln.“ Richtig?
Dom-Preis:
Wir haben angefangen, viel mehr darüber nachzudenken, wie wir das Gleichgewicht zwischen diesen beiden herstellen können? Wie verstehen wir die verschiedenen Rollen? Weil wir nicht homogen werden wollten. Du willst nicht, dass sich diese drei Rollen so gut verstehen, da sind sich alle einig. Du willst auch nicht ständig heftig unterschiedlicher Meinung sein, oder? Ein bisschen unterschiedlicher Meinung ist großartig. Wenn sie immer anderer Meinung sind, dann kommt das im Produkt zum Ausdruck. Wie findest du die Dinge, für die sie stehen, und wie bringen sie ihr wahres und bestes Selbst in jeder Phase zur Geltung? Richtig? Wenn Sie an ein bestimmtes Produkt oder Projekt denken, gibt es natürliche Phasen, in denen ihre Fähigkeiten besser entwickelt werden, oder? In diesen Phasen ist für uns ein Teil des Designmanagements oft viel besser, wenn es um Mehrdeutigkeit und eine ganze Menge Dinge geht. Wenn es ums Bauen geht, werde ich wahrscheinlich mehr auf den Ingenieur hören, oder?
Nick Muldoon:
Und du übergibst es der Lieferung.
Dom-Preis:
Ja. Aber dann ist es auch so, naja, es ist nicht der... Wenn du über die Lieferzeit nachdenkst, denken wir manchmal, dass es ein Staffellauf ist. Ich denke, das ist falsch, weil sich trotzdem jeder den Staffellauf ansehen wird. Sobald ich meine Runde gelaufen bin, bin ich fertig, oder? Aber in der Produktentwicklung liegt das nicht daran, dass ich immer noch eine Rolle habe, wenn ich den Staffelstab übergebe. Auch wenn es sich in der Entwicklungsphase befindet, spielen der Produktmanager und der Designer immer noch eine wichtige Rolle. Es ist nur so, dass sie Copiloten sind und der Ingenieur der Pilot ist, oder? Du verschwindest nicht, deine Rolle ändert sich. Ich denke, das war eine der Nuancen, die wir bekamen, als wir anfingen, die richtigen Fähigkeiten, die richtige Führungsebene, das richtige Maß an Reflexion einzubringen: „Wie bringen wir das in diesen Phasen unter einen Hut und wie machen wir deutlich, welche Rolle wir in diesen verschiedenen Phasen spielen?
Nick Muldoon:
Okay, das ist interessant. Ich werde darauf zurückkommen wollen, wenn wir unsere Aufmerksamkeit auf die Kunden in der agilen Transformationslandschaft im weiteren Sinne richten. Aber eine Sache, über die ich in Bezug auf dieses Gleichgewicht nachgedacht habe, ist die Tatsache, dass Atlassian die Disziplin hatte, Mitarbeiter für eine Triade einzustellen, oder? Wenn ich darüber nachdenke, das war ungefähr 2013 bei Twitter, und in einer unserer Gruppen hatten wir eine Zahl ausgewählt, aber es wären 200 Leute gewesen, und es wären weniger als 10 Produktmanager gewesen. Ich glaube, wir hatten tatsächlich ein Verhältnis von etwa 20. Es war etwas Dummes, 26 Ingenieure für einen Produktmanager. Es war nicht einmal unbedingt ein Design-Pendant für jeden der Produktmanager. Das Gleichgewicht war völlig falsch und es war nicht sehr effektiv. Gab es eine Zeit bei Atlassian, in der es diese Reflexion gab? Weil ich gerade überlege, dass wir in meiner Zeit bei Atlassian vielleicht keine gute Balance hatten. Ich denke, es war viel schwieriger in der Technik als in Design und Produkt.
Dom-Preis:
Ja, es ist eines dieser Dinge, wenn es nicht da ist, verpasst du es nicht. Ja? Ja? Es ist komisch, oder? Es war viel davon vor meiner Zeit, aber als ich mir die Geschichte anhörte, war es, als ob sogar Design als Disziplin, als ich 2013 anfing, eine sehr kleine Disziplin war. Ich glaube, schon damals war es eine Art Hackerangriff auf die Vorstellung, wo es hieß: „Oh ja, wir haben ein paar Designer. Sie machen die Pixel, oder? Sie lassen Sachen hübsch aussehen.“.
Nick Muldoon:
Sie machen T-Shirts und sie mögen es.
Dom-Preis:
Wer weiß, oder? Aber es lässt uns hübsch aussehen, oder? Sie trinken Craft Beer und sitzen auf Milchkisten. Wir hatten diesen Archetyp eines Designers, und dann sagst du: „Oh, wenn du anfängst, die Benutzererfahrung, die Integrationspunkte, Designsprachen, Designstandards und das Erlebnis zu verstehen, sobald du deine ersten Designer hast, die sagen: „So passen unsere Produkte zusammen“, und das ist die Erfahrung aus der Kundensicht, sagst du: „Oh, ich bin mir nicht sicher, ob ich ein Fan davon bin.“ Es war nicht schlecht gestaltet, aber auch nicht besonders gut gestaltet. Sobald Sie beginnen, einige Verbesserungen vorzunehmen, dann beginnen Sie, die Kundenzufriedenheit zu messen, und wenn Sie das Erlebnis reibungsloser gestalten, erkennen Sie plötzlich den Wert.
Dom-Preis:
Ich glaube, für Atlassian haben wir als Ingenieurbüro angefangen. Wir haben das Produktmanagement hinzugefügt und dann widerwillig das Design hinzugefügt. Interessanterweise haben wir in meiner Zeit dort zuletzt die Forschung hinzugefügt.
Nick Muldoon:
Ja. Okay.
Dom-Preis:
Faszinierende Entwicklung für uns, wieder zu sagen: „Was meinst du mit Forschung? Ich bin Produktmanager. Im Wettbewerbsbereich weiß ich alles über die Branche.“ Sie sagen: „Aber wissen Sie etwas über den Kunden und die Arbeit, die bei den wichtigsten Aufgaben zu erledigen ist, oder wie sie sie erleben, und denken Sie über Dinge wie Barrierefreiheit nach, denken Sie darüber nach, wie sich unsere Produkte in andere Produkte integrieren, denken Sie nicht nur darüber nach, was die eigentliche Aufgabe ist, und wie die Leute versuchen, das zu tun, und die Abgabestellen.
Dom-Preis:
Die Forschung ist zu einem neuen Muskel geworden, mit dem wir genau die gleichen Erfahrungen gemacht haben. Wenn man es zum ersten Mal einführt, sagen die Leute: „Oh, das brauchen wir nicht. Es ist übertrieben.“ Du sagst: „Ich verstehe, es ist wirklich ziemlich gut.“ Schwer zu integrieren, weil Sie mir Erkenntnisse liefern, die ich nicht erwartet hatte, und dann gab es eine Veränderung sowohl für die Designer als auch für die Produktmanager, die sagten: „Oh, ich kann jetzt eine Ressource gebrauchen, weil Sie diese unabhängige Gruppe sind, die mir helfen kann, nicht nur mein Produkt zu verstehen und meine Produkte zu verbessern, sondern ein Level höher, was meine Produkte zu tun versuchen? Mit wem konkurriere ich und wie sieht diese Erfahrung von Anfang bis Ende aus?“ Es ist ein völlig anderes Objektiv.
Nick Muldoon:
Was du da im Grunde beschreibst, Dom, ist, dass du immer noch den Dreiklang aus Produktdesign und Leads hast. Aber jetzt hast du das. Es ist eine Art zentralisiertes Forschungsteam?
Dom-Preis:
Ja.
Nick Muldoon:
Kommen sie für bestimmte Projekte in verschiedenen Bereichen vorbei?
Dom-Preis:
Ja. Wenn du darüber nachdenkst, wenn du es auf den gesunden Menschenverstand zurückführst, glaube ich, im Laufe der Zeit wurden wir wirklich gut darin, zu erforschen und zu bauen. Aber vielleicht haben wir bei Wonder ein bisschen Muskelmasse verloren. Diese Forschungen sind großartig. Die Scheuklappen sind draußen und sie wundern sich, oder? Ich bin mir sicher, dass sie das auch physisch tun, aber mental schlendern sie, oder? Sie gehen ziemlich weit, und wenn sie mit ihren Erkenntnissen zurückkommen, denkt man: „Wow, das hat mir eine wirklich gute, breite Perspektive gegeben.“ Ich gebe Ihnen ein kurzes Beispiel, in dem wir viel arbeiten und immer auf Barrierefreiheit achten. Es ist einfach, sich Ihre aktuellen Produkte anzusehen und mit dem Hinzufügen von Füllmaterial zu beginnen. Richtig? Das ist die logische Vorgehensweise. Oder Sie schauen sich die Produkte Ihrer Konkurrenten an und wie werden Sie ein Paar oder ein Peer? Einfach.
Dom-Preis:
Unser Forschungsteam hat tatsächlich eine ganze Reihe von Menschen mit unterschiedlichen Seh- und Mobilitätsproblemen zusammengebracht und gesagt: „Wir werden Sie jetzt dazu bringen, unsere Produkte zu verwenden und einige wichtige Aufgaben zu erledigen.“ Sie verwenden es bereits, aber es ist, als ob sie vielleicht einen Screenreader verwenden, oder vielleicht können sie keine Maus benutzen, sie können nur Tastenkombinationen verwenden. Plötzlich siehst du das Erlebnis durch ihre Linse, und wir nehmen es auf, und es verfolgt mit all den Aktionen das Augenlicht und die Sichtlinie. Man hat diesen Detaillierungsgrad, bei dem man denkt: „Nun, ich weiß, wir versuchen, Empathie aufzubauen, aber diese Erfahrung aus erster Hand zu sehen, ist etwas völlig anderes, als zu versuchen, darüber nachzudenken.“
Dom-Preis:
Du siehst es nur durch die Linse dieser Person. Das Forschungsteam hat wochenlang und wochenlang mit verschiedenen Benutzern, unterschiedlichen Hintergründen, unterschiedlichen Behinderungen, verschiedenen Produkten und unterschiedlichen Aufgaben geforscht, um all unseren Teams ein Gefühl dafür zu geben, wie es als tatsächliche Person aussieht. Hier kannst du tatsächlich in den Schuhen dieser Person laufen, oder es fühlt sich so an, als ob du es bist.
Nick Muldoon:
Wenn Sie Produktmanager und Designer sind und... Weil es für mich klingt, Dom, wie die Art von Untersuchung oder Erkundung, die du dort in Bezug auf mobilitätseingeschränkte oder sehbehinderte Menschen beschreibst, ist es etwas, das für mich schwierig sein könnte, das in meine OKRs für unser Produkt aufzunehmen. Für diese Triade, wie habe ich... Ich versuche, weiterzumachen und monatlich aktive Nutzer zu verfolgen, oder Cross-Flow, oder was auch immer es ist, und das ist viel langfristiger. Es ist, als wäre es ein lang andauernder Thread, der einfach 18 Monate lang geöffnet bleibt, während wir über diese Dinge nachdenken und diese Gespräche führen. Hat diese Forschungsgruppe, haben sie tatsächlich ihre eigenen OKRs und sind diese OKRs jährlich?
Dom-Preis:
Ja. Ja und nein. Wir führen hauptsächlich OKRs in den Bereichen Design und Forschung durch. Wir haben jetzt ein Team, in dem wir arbeiten können. Es handelt sich in der Regel um gemeinsame OKRs oder eher um funktionsübergreifende OKRs, sie sind funktionsübergreifend und gemeinsam genutzt. Die funktionsübergreifenden Funktionen wie in Wir haben das gleiche Ziel, aber unterschiedliche Schlüsselergebnisse.
Nick Muldoon:
Ja, okay.
Dom-Preis:
Wenn Sie Barrierefreiheit als Ziel betrachten, das Forschungsteam, dann ist das wichtigste Ergebnis, die neuesten Forschungsergebnisse und Erkenntnisse zu haben, damit wir lernen und verstehen können. Du sagst: „Cool, das ist deine Aufgabe.“ Richtig? Das Designteam, Ihr OKR besteht darin, diese Erkenntnisse in einige Designs und Usability umzusetzen, und dann können Sie tatsächlich entlang der Wertschöpfungskette gehen, und jede einzelne Person in dieser Wertschöpfungskette hat ein anderes OKR.
Nick Muldoon:
In Ordnung. Aber noch heute gibt es keine OKRs auf individueller Ebene, oder? Es ist alles teambasiert, gruppenbasiert?
Dom-Preis:
Wir haben Widrigkeiten. Ich habe mich ein bisschen damit beschäftigt. Manchmal denke ich, ich habe immer individuelle OKRs. Die Frage ist, ob ich sie teile oder nicht. Ich denke, wenn man an die Mehrheit der Wissensarbeiter denkt, werden sie individuelle Ziele haben: „Ich möchte eine neue Fähigkeit erlernen, ich möchte eine neue erwerben“
Nick Muldoon:
Das Handwerk verfeinern.
Dom-Preis:
Ja, richtig? Ob du das aufschreibst und es dir nützt oder nicht, steht nicht zur Debatte. Wenn es darum geht, sie kollektiv aufzuschreiben, sie in einem einzigen Speicher aufzubewahren, jede Art von Leitern, dann sind die Kosten meiner Meinung nach höher als der Nutzen. Richtig?
Nick Muldoon:
In Ordnung.
Dom-Preis:
Wir sind davon abgewichen, zu sagen, dass jeder dann individuelle OKRs haben muss und dann Leiter, was auch immer, weil es am Ende sehr, sehr umständlich und tatsächlich sehr kommandierend und kontrollierbar wird. Stattdessen haben wir unseren Führungskräften gesagt, und das ist Führung nach Fähigkeiten, nicht nach Titel, sondern zu unseren Führungskräften: „Das ist Teil eines Gesprächs, das Sie regelmäßig mit Ihren Mitarbeitern über Wachstum führen sollten und darüber, wie Sie sie inspirieren und wie Sie sie motivieren. Wie entwickeln und entwickeln sie sich? Welche Experimente führen sie an sich selbst durch? Richtig? Wie sind sie mit anderen Leuten? Was sind ihre Herausforderungen und wie können Sie ihnen helfen, diese Herausforderungen niemals zu bewältigen? Was sind ihre Verstärkungspunkte, die Sie mit ihnen besprechen sollten, um das Einstellrad einzuschalten? Richtig? Was sind ihre Superkräfte, die wir wirklich nutzen sollten, oder?“ Das ist Teil eines Führungsgesprächs. Muss das aufgeschrieben und zentralisiert werden? Nein. Für mich ist es nutzlos, das zu dokumentieren.
Nick Muldoon:
Es ist interessant zu hören, dass du das beschreibst. Das ist sehr viel Lern- und Entwicklungsfokus. Wenn ich an Andy Groves High Output Management zurückdenke, mein Verständnis davon, ob es um ein Individuum geht... von OKRs und auf individueller Ebene, bezog sich immer auf Ihre Kunden. Was werde ich für meine Kunden tun? Aber Sie haben es tatsächlich formuliert. Was werde ich für mich selbst tun, um meinen Kunden einen besseren Service bieten zu können, vielleicht im nächsten Geschäftsjahr?
Dom-Preis:
Ja. Ja, es ist ein Geheimnis. Ich schätze, das wird von Atlassian geteilt, aber das ist definitiv meine Sicht der Welt, und ich habe das jetzt mit genug Leuten geteilt, sodass sie es verstehen. Du kannst kein großartiger Teamkollege sein, wenn du nicht dein wahres Ich zeigst. Du musst einen Schritt zurücktreten. Es gibt diese ganze seltsame Geschichte über die Demut, ein Teamkollege zu sein, in der du sagst: „Ich bin ein Märtyrer und ich nehme einen für das Team.“ Das ist Quatsch, denn wenn du nicht in der richtigen Zone für diese Teamaktivität bist, gibst du nicht dein Bestes, oder? Du bist eigentlich der Anker, der das Team zu Fall bringt. Du gehst davon zurück und sagst: „Nun, wie wirst du der Beste?“ Weil nicht jede Arbeit Teamarbeit ist. Es gibt viel tiefgründige Arbeit und individuelle Aufgaben und Dinge, die erledigt werden müssen. Du sagst: „Richtig, ich muss die beste Version von mir sein. Nun, was heißt das?“
Dom-Preis:
Das bedeutet, dass ich vor jedem Meeting meine Aufgaben erledigt haben muss, oder vor jedem Meeting muss ich mein Pre-Meeting erledigt haben, oder? Wenn wir uns als Team treffen und wir diese synchrone Aktivität haben, was muss ich tun, um bestmöglich darauf vorbereitet zu sein, dass diese synchrone Aktivität den größten Nutzen bringt? Wie kann ich das Beste aus dieser Teamarbeit herausholen? Wie komme ich und bin anwesend? Wie trete ich mit respektvollem Widerspruch und Herausforderung, Recht und Provokation auf? Dazu muss ich zuerst ein Individuum sein. Richtig? Ich denke, eine der Gefahren in vielen Arbeitsumgebungen besteht derzeit darin, dass die Menschen das Verständnis dafür verloren haben, was es heißt, ein Individuum zu sein, was Ihr wichtigster Führungsstil ist, Ihr Lernstil, wie Sie aufsteigen? Richtig? Wie kritisierst du? Wie nimmst du Feedback entgegen? All diese Dinge, die dich ausmachen, du musst sie kennen und dir bewusst sein, bevor du in einer Teamumgebung großartig sein kannst.
Dom-Preis:
Es sind nicht nur die Aufgaben. Du musst dich kennen. Wenn Sie ein großartiger Mensch sind und das verbessert haben, können Sie ein großartiger Teamkollege sein, und wenn Sie ein großartiger Teamkollege sind, können Sie großartige Ergebnisse für Ihre Kunden erzielen. Alles andere ist ein Unfall, oder? Wir waren alle in zufälligen Teams, was einen Kunden begeistert hat, und wir saßen da und dachten: „Ich bin mir wirklich nicht sicher, was ich mit dem Typen gemacht habe. Ich nehme es. Ich nehme das Schulterklopfen. Ich nehme das Lob und die Flasche Wein und die Glückwünsche entgegen. Ich bin mir nicht sicher, ob ich das verstärke. Ich weiß nicht. Wenn du es nicht weißt, hast du es wahrscheinlich nicht getan. Richtig? Das ist keine Demut. Du bist wahrscheinlich nur ein Passagier. Ich denke, die Gefahr in einem Wachstumsumfeld besteht darin, dass es viele Passagiere gibt, die als Passagier zu viel Erfolg haben, und nach einer Weile sagen sie: „Mir geht es unglaublich.“ Du sagst: „Das bist du nicht. Du warst einfach wiederholt zur richtigen Zeit am richtigen Ort.“
Nick Muldoon:
Das muss ich verarbeiten.
Dom-Preis:
Lass mich dir ein Beispiel geben. Richtig? Vor ein paar Jahren war ich mit einer Freundin von mir, Sophie, in New York. Inoffiziell hat sie mich betreut und mir die meiste Zeit geholfen, oder? Ich spreche mit ihr über den Versuch, mich zu skalieren, und ich war wirklich wütend über einige Dinge, und zum Glück war es später Nachmittag in New York. Sie hat mich gekauft [unhörbar 00:25:30]. Wir haben einen Drink zerschmettert und miteinander geplaudert, und sie ist eine von denen, die dich einfach als Blödsinn bezeichnen, oder? Ich jammere, jammere, jammere, jammere, jammere. Sie sagt: „Oh, cool.“ Sie ist auch Engländerin. Sie sagt: „Also ich schätze, du wirst einfach darüber jammern und hoffen, dass es verschwindet.“ Ich sage: „In Ordnung, fairer Punkt. Ein bisschen, mein Englisch kam raus. Ich hatte eigentlich gehofft, dass es vielleicht, selbst wenn ich lange genug jammere, tatsächlich verschwinden würde.“ Sie sagt: „Das passiert nie, oder? Was wirst du dagegen tun?“
Dom-Preis:
Wir haben uns unterhalten, als sie mir diese Herausforderung stellte, und sie sagte: „Du entwickelst dich nicht weiter.“ Sie sagt: „Du fügst Sachen hinzu, aber du bist voll.“ Sie sagt: „Kognitiv gesehen, Dom, du bist voll.“ Meine Herausforderung bestand darin, dass ich zu der Zeit all diese Geschäftsbücher las und eine Menge Dinge wusste, aber ich fühlte mich nicht klüger. Ich habe nichts damit gemacht, und das erzeugt diese Frustrationsspirale. Sie hat mir die Übung gegeben, und Sie haben das wahrscheinlich gesehen, die vier Ls. Sie hat ein bisschen Papier bekommen und sagt: „In Ordnung, schreib die vier Ls auf. Denke über dich als Anführer nach. Es geht egoistisch nur um Sie als Führungskraft. Was hast du in den letzten 90 Tagen geliebt? Was hast du persönlich gemacht?“
Dom-Preis:
Ich sage: „Oh, nein, nein, nein, nein.“ Sie sagt: „Nicht, weil wir hier keine Likes machen, oder? Wir sind nicht weich. Wir haben es geliebt und besitzen es. Eigentlich Superkraft, mach mehr davon.“ Das haben wir gemacht, ein paar Schlucke Wein waren mir sehr unangenehm. Dann sagt sie: „Was verabscheut du und wonach sehnst du dich?“ Ich hatte viele lange Formulare, eine lange Liste davon, aber ich habe sie nicht verabscheut. Sie sagt: „In Ordnung, hier ist das Problem. Sie sehnen sich danach, Sie streuen es in der 25. Stunde eines jeden Tages hinein. Kein Wunder, dass du nicht gut darin bist, denn du gibst ihm nie den... Du gibst dir selbst keinen Raum, keine Zeit oder Freiheit, um tatsächlich zu experimentieren. Du wächst nicht. Du wirst nicht besser. Du fügst nur Sachen hinzu.“ Ich sage: „Fairer Punkt.“
Dom-Preis:
Wir sind durchgegangen und haben Abscheu gefunden. Sie sagt: „Richtig, du wirst die entfernen. Wem wirst du diese Gewohnheiten oder Rituale oder was auch immer sagen, wem wirst du sagen, dass du sie entfernst, weil sie dich zur Rechenschaft ziehen müssen? Weil sie wirklich leicht wieder reinschlüpfen werden.“ Ich habe jemanden gefunden und ihn angepingt. Sie sagt: „Richtig, die Ersehnte.“ Sie sagt: „Ich muss dich wissen lassen, wenn du sie hinzufügst, wirst du Mist auf sie losgehen.“ Ich sagte: „Ich will bei nichts schlecht sein. Ich bin ein Anführer. Ich muss ein Superheld sein. Ich brauche einen Umhang und ich muss reinfliegen, und beim ersten Mal muss alles perfekt sein.“ Sie sagt: „Nein, wenn du zum ersten Mal eine Sehnsucht hinzufügst, stehen die Chancen gut, dass du darin falsch bist. Finden Sie jemanden, der diese Muskeln hat, und lassen Sie sich von ihm beim Training helfen, und Sie werden mit der Zeit besser darin werden.“
Dom-Preis:
Dann war das vierte L, was hast du gelernt? Welches Experiment hast du letztes Quartal selbst gelernt? Was hast du über dich selbst gelernt?“ Sie sagt: „Richtig, geh und erzähle es so vielen Leuten wie möglich. Das wird einen Ort schaffen, an dem Sie lernen und sich vernetzen können.“ Ich habe es getan, und 90 Tage später habe ich es wieder getan. Es gibt ein paar Mal, in denen die Macht der Rationalisierung zum Tragen kommt, und ich habe mich einfach auf die Probe gestellt, weil es wirklich einfach ist. Dann wieder andere Male, wo ich wirklich tief in die Materie eingedrungen bin und es mir ermöglicht hat, mich alle 90 Tage weiterzuentwickeln, oder? Nun, die Moral der Geschichte, und hier binden wir den Einzelnen an das Team, die Anzahl der Führungskräfte, die ich in großen Unternehmen kenne, die Transformationen vorantreiben, aber sie ändern sich nicht selbst. Welches Verhalten zeigen sie? Sie neigen zu dem Verhalten von: „Mir geht es gut. Sie sind es nicht. Ihr müsst euch alle ändern. „Das heißt...
Nick Muldoon:
Ja, der Status Quo als Vorbild.
Dom-Preis:
Ja.
Nick Muldoon:
Ja. Ja, das ist interessant. Ich habe sicherlich von dem Sport „Liebe versus Abscheu“ gehört. Ich mag es, dass du oder dass Sophie es auf Sehnsucht und Gelerntes ausgedehnt hat. Ich finde das wirklich wunderschön, und das nehme ich. Vor allem wegen der Abscheu, gab es Dinge auf der Liste, die Sie delegieren mussten oder für die Sie jemanden einstellen mussten? Weil es Dinge gibt, über die ich nachdenke und die ich in Bezug auf das Geschäft verabscheue, und normalerweise geht es dabei um Dinge wie Orchestrierung, Bezahlung von Lieferanten oder was auch immer es ist. Wie gehe ich damit um? Ich bringe den Buchhalter in das Geschäft, das...
Dom-Preis:
Ja. Das kleine Spiel, das wir gespielt haben, ist, dass du es nicht outsourcen darfst, bis du es fallen lässt. Richtig? Die Idee ist, du wirst zuerst einen Weg finden, es fallen zu lassen, weil es vielleicht nicht existieren muss, oder?
Nick Muldoon:
In Ordnung.
Dom-Preis:
Weil Sie in großen Unternehmen gearbeitet haben und in einem großen Unternehmen herumlaufen und sagen: „Diese Person dort, sie ist nur da, um eine Aufgabe zu erledigen, die wahrscheinlich jemand hätte automatisieren oder loswerden können“, aber sie hatte keine Zeit. Außerdem stellen sie einen warmen Körper in den Weg. Dann fügst du einen weiteren warmen Körper hinzu, einen weiteren warmen Körper, und plötzlich merkst du, dass du Tausende von warmen Körpern hast, die dieses Kartenspiel zusammenhalten, und wenn eine Karte fällt, fällt das Ganze zusammen. Ich habe Dinge entfernt, bei denen es mir wirklich unangenehm war, Dinge zu entfernen. Ich dachte: „Das ist so wichtig.“ War es nicht. Meine Scheuklappen waren einfach aus, oder? Dann sagt sie: „Wir werden damit aufhören.“ Sie sagt: „Es geht nicht um Leben oder Tod.“ Sie sagt: „Nein, danke, Dom. Nun, Sie sind kein Chirurg, also hören Sie auf, etwas zu tun, und hören Sie zu und sehen Sie, was passiert, wenn Sie damit aufhören.“ Ich sage: „Oh nein, aber die sind wirklich wichtig. Die Leute werden wütend sein. Ich bin eine sehr wichtige Person.“ Du entfernst etwas und niemand merkt es verdammt nochmal. Du sagst: „Warum habe ich das gemacht?“
Nick Muldoon:
Warum habe ich das gemacht? Yeah.
Dom-Preis:
Ja. Dann habe ich...
Nick Muldoon:
Kannst du...
Dom-Preis:
Eines der großen Beispiele für mich waren Treffen. Das war kein Delegierter oder [unhörbar 00:30:24]. Ich war einfach ein Kontrollfreak und tauchte in Besprechungen auf, bei denen ich nur für den Fall der Fälle anwesend sein wollte. Wir haben mir meine Wohnung angesehen, nur ein Meer, ich benutze Gmail, richtig, das blaue Meer all dieser Treffen, doppelt gebucht, dreimal gebucht. Sie sagt: „Richtig.“ Sie sagt: „Stell dir vor, du musst dir das Ziel setzen, 15 Stunden loszuwerden.“ Ich sage: „Was? Es wäre einfach, eine Zeitmaschine zu erstellen, die 15 Stunden pro Woche hinzufügt. Ich kann 15 Stunden an Besprechungen nicht entfernen. Ich bin eine sehr, sehr wichtige Person.“ Dann haben wir dieses Spiel namens Boomerang oder Stick gespielt. Ich lehnte jedes einzelne Meeting ab und schickte eine Nachricht mit der Aufschrift: „Das ist entweder ein Bumerang“, in dem Fall kommt er zurück, oder ob es ein Stock ist. Wenn du einen Stock wirfst, kommt er nicht zurück. Die Bumerangs, ich möchte wissen, was der Zweck des Treffens ist, was meine Rolle in dem Treffen ist und wofür Sie mich zur Rechenschaft ziehen werden.
Dom-Preis:
Zwei Drittel der Treffen kamen nicht zurück. Richtig? Diejenigen, die das getan haben, ich gebe Ihnen ehrlich zu, ich habe in praktisch allen genau die falsche Rolle gespielt. Es war lustig, weil ich diese E-Mails zurückbekommen habe und sie sagten, in einem dieser Treffen, an denen ich teilgenommen habe, sagten sie: „Deine Rolle ist der Entscheidungsträger.“ Beim nächsten Meeting sagte ich: „Ich muss mich entschuldigen. Ich dachte, ich wäre der Protagonist.“ Jedes Mal, wenn sie etwas vorschlugen, dachte ich: „Nun, du könntest das oder diese drei Dinge tun.“ Ich habe sie in eine komplette Spirale versetzt und sie sagten: „Du bist ein schrecklicher Entscheidungsträger.“ Ich sagte: „Nein, ich bin ein guter Entscheidungsträger, wenn ich weiß, dass das mein Job ist, weil das nicht dein Titel ist. Dein Titel bleibt...
Nick Muldoon:
Ah, Dom.
Dom-Preis:
... das Gleiche, oder? Ihr Titel bleibt derselbe, aber Ihre Rolle ist in jedem Umfeld, bei jedem Engagement anders, Ihre Rolle ist anders. Wir nennen es nicht, wir gehen einfach davon aus. Als wir diese Annahmen geklärt hatten und festgestellt hatten, dass ich sie alle falsch verstanden habe, war ich bei den Treffen, an denen ich teilgenommen habe, viel effektiver. Zwei Drittel von ihnen kamen nicht zurück. Entweder das Meeting [unhörbar 00:32:09], oder es brauchte mich da nicht. Wenn Sie darüber nachdenken und ich und Sie das wissen, ist unsere wertvollste Ressource Zeit.
Nick Muldoon:
Zeit. Ja.
Dom-Preis:
Warum verschenken wir es kostenlos oder zu negativen Kosten? Richtig? Ich sage: „Nein, ich baue all das Zeug wieder an.“
Nick Muldoon:
Liz und ich führen jetzt schon eine Weile dieses Gespräch darüber, dass ich statistisch gesehen wahrscheinlich noch 50 Jahre auf der Erde habe, wenn man bedenkt, wie lange ein kaukasischer australischer Mann lebt. Aber ich habe wahrscheinlich nur noch 40 gute, brauchbare Jahre übrig, denn dann magst du irgendwie Atrophie und all das.
Dom-Preis:
Ja.
Nick Muldoon:
Ja. Liz und ich haben uns gedacht: „Nun, wenn wir nur noch 40 Sommer haben, was machen wir dann mit 40 Sommern?“ Es ist eine wirklich gute Übung, um dich schnell zum Nachdenken zu bringen, womit möchtest du deine Zeit verbringen?
Dom-Preis:
Ja. Ja, absolut. Es ist dasselbe. Das können Sie lebenslang auf einer Meta- und Makroebene tun, und ich denke, Sie können das auf jährlicher, vierteljährlicher Basis tun. Bei der Arbeit gibt es so viele Dinge, von denen wir einfach annehmen, dass wir sie tun müssen, und sowohl die vier Ls als auch nur meine Einstellung haben es mir ermöglicht, sie herauszufordern und zu sagen: „Nun, ich sage gerade sehr oft warum.“ Es ist also wie: „Ich möchte, dass du zu diesem Meeting kommst.“ Ich sage: „Oh, cool. Warum?“ Sie sagen: „Ich weiß nicht. Ich hätte dich gerne dort.“ Ich sage: „Aber warum? Denn wenn du mir nicht erklären kannst, was ich tun soll, dann brauchst du mich dort wahrscheinlich nicht.“
Nick Muldoon:
Fünf Gründe, richtig? Fünf Gründe.
Dom-Preis:
Aber auch der Grund, warum ich sie oft frage, ist, dass ich sage: „Sie wissen, dass ich eine Nervensäge bin, wenn ich zu dem Meeting komme, also möchte ich nur noch einmal bei Ihnen nachfragen, ob Sie mich wirklich dort haben wollen. Denn wenn Sie auf eine Idee gestoßen sind und sie versenden möchten, laden Sie mich nicht ein. In Ordnung, ich bin die falsche Person.“ Ich fordere das einfach heraus und hole mir diese Zeit zurück und nutze sie dann für Dinge, die viel wertvoller sind. Ich habe mein Portfolio neu gewichtet, genau wie ein Finanzberater oder ein Markthändler jedes Quartal ein Finanzportfolio neu ausbalanciert, ich habe dasselbe mit mir gemacht. Wenn ich das nicht tue, dann sage ich, wenn ich das nicht tue, sage ich, dass meine Version vom letzten Quartal für sie mehr als gut genug für das nächste Quartal ist. Was ich damit sagen will ist...
Nick Muldoon:
Ja, was nie der Fall ist, oder?
Dom-Preis:
Ja, ich sage, die Welt hat sich nicht verändert. Die Welt ist flach geblieben, richtig, und alles läuft auf einer flachen Linie. Das ist nicht der Fall. Wenn ich mich nicht im gleichen Tempo weiterentwickle wie Atlassian oder unsere Kunden, bin ich standardmäßig zum Moderator geworden. Ich bin der Anker, der uns bremst.
Nick Muldoon:
Sagen Sie mir, welchen Teil Ihrer Zeit verbringen Sie heute mit Kunden? Weil ich weiß, dass ich im Laufe der Jahre in unseren Gesprächen an ein Mittagessen bei Pendolino denke, du, Dave und ich, wahrscheinlich vor zweieinhalb, drei Jahren, aber wir haben viel über agile Transformationen am großen Ende des Spektrums gesprochen. Wie viel Zeit verbringen Sie heute mit Kunden und wie sehen diese Gespräche aus?
Dom-Preis:
Ja. Ich bin momentan wahrscheinlich über der 50, 60% -Marke, aber hauptsächlich wieder eine Neugewichtung. Als COVID zuschlug, verschwand die Konferenzszene, und so dachte ich: „Cool, ich kann diese Zeit reinvestieren. Ich könnte es intern bei Atlassian reinvestieren, und ich habe es getan, als wir unsere internen Arbeitsweisen weiterentwickeln und dort einige Veränderungen vorantreiben. Ich habe mich darauf eingelassen, das machte Sinn. Aber ich sagte: „Hey, unsere Kunden haben Probleme.“ Zuallererst müssen wir verstehen, wie und warum sie Probleme haben, und wenn wir ihnen dann helfen können, einen Weg finden, ihnen zu helfen. Es ist lustig, wie sich das Gespräch von eher taktischen, ja, 18-Monatsplänen und vermeintlichen Sicherheitsniveaus zu der Aussage entwickelt hat: „Hey, die Welt hat sich verändert. Die Momente, in denen der Tisch umgedreht wurde, sind einfach passiert. Unser Geschäftsmodell wurde in Frage gestellt, unsere Mitarbeiter sind herausgefordert. Wir führen diese Gespräche über Menschen, Wohlbefinden, und eigentlich sagen wir seit Jahren, dass wir uns um unsere Mitarbeiter kümmern, aber jetzt müssen wir es tatsächlich tun. Was heißt das? All die Politiker, die nur versuchen, den Übergang von Friedenszeiten zu Kriegszeiten zu verstehen...
Nick Muldoon:
In die Kriegszeit.
Dom-Preis:
... zur Zeit der Friedenszeit. Ich finde es lustig, dass der Übergang vom Frieden zum Krieg, die gemeinsame brennende Plattform, das gemeinsame Gefühl der Dringlichkeit, ich denke, viele dieser Übergänge sind in Ordnung. Ich würde nicht sagen, dass sie großartig sind, aber sie waren nicht schrecklich, wenn man bedenkt, dass die meisten Sydney in Australien den Krieg nicht überstanden haben. Richtig? Wir hatten lange Zeit einen unglaublichen wirtschaftlichen Erfolg. Je schwieriger, desto komplexer ist es, vom Krieg zum neuen Frieden überzugehen, weil neuer Frieden nicht so aussieht wie alter Frieden. Richtig? Es ist eine ganz andere Denkweise, zu gehen...
Nick Muldoon:
Wer ist...
Dom-Preis:
... was das Management in Kriegszeiten angeht, ist, dass ich keine Genehmigungen benötige, weil es eine brennende Plattform ist. Wir treiben den Wandel einfach voran, tun es einfach, tun Sie es einfach. New Peace ist anders, weil wir sagen: „Nun, wie lange wird das andauern? Welche Prinzipien möchte ich anwenden? Wie baue ich fast aus einem leeren Blatt Papier?“ Eine ganz andere Denkweise.
Nick Muldoon:
War das Ben Horowitz mit der schwierigen Sache mit schwierigen Dingen, wo er über Krieg gegen Führer in Friedenszeiten sprach?
Dom-Preis:
Ich habe es in ein paar Dingen gelesen. Das letzte, das ich gelesen habe...
Nick Muldoon:
Höre verschiedene Orte.
Dom-Preis:
... da war General Stanley McChrystal. Er hat Team of Teams geschrieben.
Nick Muldoon:
In Ordnung.
Dom-Preis:
Er hat einen über die Entmystifizierung von Führern geschrieben und darüber, wie wir oft die falschen Führer auf ein Podest gestellt haben, und es gibt einige großartige Führungskräfte da draußen, die einfach nicht die Anerkennung bekommen haben, weil sie viel ausgeglichener waren. Aber ja, da draußen gibt es ein paar verschiedene Narrative.
Nick Muldoon:
Bei den letzten, mit denen du dich triffst, nun ja, erstens, benutzen sie so etwas wie die vier Ls, die Sophie mit dir geteilt hat?
Dom-Preis:
Ja, das ist viel beliebter geworden, ich meine, sicherlich bei der Vorstandsebene und den unteren Ebenen, sogar bei Vorstandsmitgliedern. Wenn ich das teile, gibt es diesen Moment des Nachdenkens, in dem ich sage: „Ja.“ Das liegt daran, dass ich sie mit der Ironie verstehe, zu sagen: „Frage eins, treibst du eine Transformation voran?“ Sie sagen: „Ja.“ Sie sagen: „Cool. Du verwandelst dich selbst?“ „Nein.“ Übrigens bedeutet das Lesen eines Harvard Business Review-Artikels über Agile nicht, dass Sie sich weiterentwickeln. Das bedeutet, dass Sie sich weiterbilden. Das ist subtil anders. Wir haben den Artikel alle gelesen. Das macht dich nicht zu einem Experten, also setz dich hin. Das ist der erste Moment, in dem sie gekauft werden.
Dom-Preis:
Dann sagt der zweite einfach zu ihnen: „Sei einfach ehrlich, mit welchen Dingen hast du zu kämpfen?“ Für viele Führungskräfte ist es der Wunsch, dass sie das Bedürfnis nach Empathie, Verletzlichkeit und Authentizität bekommen, sie bekommen es, weil sie es gelesen haben. Sie verstehen es, sie verstehen es, es fällt ihnen wirklich schwer, es zu tun. Richtig? Viele von ihnen gehen als Superheld, der durch Macht und Kontrolle führt. Sie haben durch Erfolge geführt, aber sie werden nicht durch einen Abschwung und eine herausfordernde Zeit geführt, und sie stellen nur ihre eigenen Fähigkeiten in Frage. Es gibt eine Menge, ich möchte es nicht einmal das Imposter-Syndrom nennen, ich glaube, es gibt eine Menge Leute, die einfach sagen: „Ich glaube, meine Rolle als Führungskraft hat sich gerade geändert, und ich weiß nicht, ob ich die neue Version verstehe.“ Das ist für viele Menschen ziemlich demoralisierend. Das ist ziemlich herausfordernd.
Dom-Preis:
Die Ironie dabei ist, dass sie in dem Moment, in dem sie sich das ansehen und darüber sprechen, Empathie, Verletzlichkeit und Authentizität gezeigt haben. Sie haben das getan, wonach sie greifen. Aber stattdessen versuchen sie, ihm dieses mutige Gesicht zu verleihen. In vielen Organisationen habe ich viel ruinöses Einfühlungsvermögen erlebt. Viele Leute, die aus ihrem Team kommen und sagen: „Nick, ich will dir nicht sagen, dass in der Firma schlimme Dinge passieren, weil ich nicht will, dass du... Ich denke, du machst dir schon Sorgen, weil ich dir das nicht sagen werde. „Ohne zu merken, dass du die Lücken füllst und viel schlimmere Dinge denkst, als ich dir jemals sagen könnte. Der Informationsfluss hat sich geändert, und bei vielen Führungskräften ist der Fehler, den ich in der Masse gesehen habe, dass sie Kommunikation und Rundfunk verwechselt haben. Richtig? Kommunikation ist das, was ich höre und wie ich mich fühle, wenn du sprichst. Rundfunk ist das, was du gesagt hast. Wegen dieser virtuellen Welt gibt es jede Menge Webstuhl, Zoom und Videos, und ja, wir werden ausstrahlen.
Nick Muldoon:
Sendet viel. Ja.
Dom-Preis:
Aber wir werden uns die Antwort anhören.
Nick Muldoon:
Das muss für eine Reihe von Führungskräften heute eine sehr herausfordernde Zeit sein, aber 2018 oder 2008 gab es damals viele Führungskräfte, die wahrscheinlich, wie ich vermute, viel Narbengewebe rund um GFC aufgenommen haben. Wie viele der Führungskräfte, mit denen Sie heute chatten, hätten durch die GFC Narbengewebe aufgenommen, und sie empfinden zumindest immer noch dieses Gefühl, als wäre es Neuland?
Dom-Preis:
Nun, und das ist, glaube ich, das Nebenprodukt. Ich wollte Problem sagen. Das Nebenprodukt des australischen Systems ist, dass wir 2008 der Kugel ausgewichen sind. Wirtschaftlich gesehen haben wir nicht den gleichen Schaden erlitten wie die anderen. Die Aktienmärkte wurden ein wenig getroffen, und eine ganze Reihe anderer Dinge fielen ein wenig, aber bei weitem nicht so groß oder gravierend wie der Rest der Welt. Sowohl durch den Bergbauboom, ja, den Bankensektor, als auch durch eine ganze Reihe anderer tertiärer Märkte rund um den Tourismus, die zu dieser Zeit gut abliefen, fühlt man sich an, als wäre es ein Ausrutscher, aber es war keine Narbe. Ich denke, da gibt es viele Länder, die auf die jüngsten Erfahrungen zurückgreifen können, etwa: „So machen wir das. Richtig? So bunkern wir. So werden wir konservativer. Hier ist das Drehbuch dazu.“ Ich denke, viele Länder haben dieses Playbook nicht, also packen sie es an, oder? Sie machen es im Handumdrehen. Ich glaube, da ist das.
Dom-Preis:
Aber ich denke auch, dass dieser einfach anders ist. Die globale Finanzkrise war ein finanzielles und marktbedingtes Problem, oder? Dies ist ein durch eine Gesundheitspandemie verursachter Marktabschwung. Ich glaube nicht, dass wir dafür ein Drehbuch haben, weil wir nicht wissen, wie lange das so bleiben wird. -
Nick Muldoon:
Wenn du...
Dom-Preis:
Mach weiter.
Nick Muldoon:
Ja. Nein, tut mir leid, Dom, ich wollte nur fragen, wenn du wieder an GFC denkst, hattest du Angst, GFC durchzugehen? Warst du dieses Jahr nervös?
Dom-Preis:
Nein. Ich war durch GFC überhaupt nicht besorgt, weil es sich anfühlte wie... Ich hatte vor langer, langer Zeit eine Rezession in Großbritannien, und so habe ich diesen Abschwung durchgemacht. Ich habe in Unternehmen gearbeitet, die Abschwünge hatten, auch wenn die allgemeine Wirtschaft in Ordnung war, und in Branchen, die geschrumpft waren, wo man am Ende jedes Quartals sagt: „Richtig, wir sprechen über die Bücher. Wen lassen wir gehen? Welche Projekte werden eingestellt?“ Es war immer das Mitnehmen, nicht das Hinzufügen. Das habe ich durchgemacht. Das, was mich im Hinblick auf 2020 beunruhigt hat, war, dass ich glaube, dies ist das erste Mal, dass wir ein solches Maß an Unsicherheit hatten. Es ist lustig, weil viele Leute über Veränderungsmüdigkeit sprechen. Ich denke tatsächlich, dass Menschen ziemlich gut darin sind, sich zu verändern. Ich denke, das machen wir eigentlich ganz gut. Aber mit Ungewissheit sind wir furchtbar.
Dom-Preis:
Es ist seltsam, wie verschiedene Menschen auf unterschiedliche Weise reagieren, wenn wir unsicher werden. Manche ziehen eine Decke voller Gewissheit auf und wickeln sie um sich herum wie: „Nun, hier ist, was ich weiß, und das wird wahr werden.“ Du sagst: „Vielleicht [unhörbar 00:42:16].“ Ich mag deine Decke, sie ist bequem. Aber es ist nicht unbedingt echt, oder? Es wird dich nicht vor den Dingen schützen, von denen wir wirklich nichts wissen. Hier ist Agilität entscheidend geworden, oder Agilität ist entscheidend geworden, denn wenn ich mir die Führungskräfte in den Unternehmen ansehe, die zuhören, sind sie tatsächlich auf ihre Kunden aufmerksam und hören zu, sie sind diejenigen, die sich sehr schnell weiterentwickeln, weil sie... nicht nur die Agilität als Muskel haben, sondern auch zuhören, um die Ursache zu korrigieren. Diejenigen, die... denken, sie haben in den letzten Jahren Agilität eingeführt, aber nie den Kundenaspekt hinzugefügt, sie haben kleine, schnelle, flinke Teams, die sich nur im Kreis drehen.
Nick Muldoon:
Sie gehen nicht in eine bestimmte Richtung. Ja.
Dom-Preis:
Ja. Ja, sie haben keine Ahnung, denn ohne diese übergeordnete Frage: „Warum machen wir das? Und dieser Kunde, um den wir uns kümmern, den wir immer noch mögen, wie hat sich die Welt dieses Kunden verändert? Richtig? Denn wenn sich dieser Kunde geändert hat, wie können wir uns dann mit ihm ändern?“ Viele Unternehmen haben das noch nicht getan, und ich glaube, einige halten den Atem an und hoffen auf das Beste. Manche sind einfach zu sehr darauf fixiert: „Aber wir haben einen Plan, und wenn wir uns an diesen Plan halten“, habe ich irgendwo ein Buch gelesen, in dem es heißt: „Wenn du dich an einen Plan hältst, wird es dir gut gehen.“ Du sagst, ja, die Welt um dich herum hat sich gerade verändert. Ihr Plan ist vielleicht nicht so relevant.
Nick Muldoon:
Es bringt mich zum Nachdenken, Dom, über die Salesforce-Transformation, die Agile-Transformation im Jahr 2006. Das war einer der Urknalle, ich glaube, es war eine der frühen agilen Urknall-Transformationen, die stattfanden. Ich weiß nicht, ob es Parker Harris war oder wie es sich tatsächlich entwickelt hat, aber die Führungskräfte von Salesforce sagten im Grunde genommen: „Sie werden zu Agile wechseln. Du wirst dieses Ding ausprobieren. Sonst ist alles verloren.“ Es gab andere Beispiele. Ich glaube, kurz darauf hat LinkedIn seinen Börsengang gemacht. Sie haben das Ende auf Abruf gezogen, sie haben alles gestoppt, um ihre Arbeitsweise zu überarbeiten. Ist 2020 eines dieser Jahre? Werden die besten Unternehmen dies als Gelegenheit nutzen, um ihre Arbeitsweise neu zu gestalten? Dann werden die anderen Unternehmen einfach verkümmern und in den nächsten fünf Jahren langsam an Wert verlieren?
Dom-Preis:
Ich denke, die besten haben wahrscheinlich schon einen Teil der Muskeln aufgebaut, diejenigen, die jetzt reagieren, oder? Ich denke, wenn Sie sich des Marktes bewusst sind, hat COVID nur die Dinge beschleunigt, die sich sowieso geändert haben. Richtig? Ja, es ist nicht ideal, aber es sind Dinge, die trotzdem passiert sind, oder? Ich glaube, wir hatten wirklich fünf oder zehn Jahre Zeit, um uns auszurüsten, und wir bekamen stattdessen drei Monate. Ich denke, eine ganze Reihe von Unternehmen, die gesehen haben, wie sich diese Muster herauskristallisiert haben und die Gewohnheiten, Technologien, Praktiken, Arbeitsweisen, Kundenanforderungen, Kundenanforderungen, die Anforderungen an das Kundenerlebnis verändert haben, wenn man all das zusammenzählt, ist das der Grund, warum die agile Transformation in den letzten drei, vier, fünf Jahren ein großer Erfolg war, oder? Diejenigen, die darauf vorbereitet waren, sind großartig. Diejenigen, die schnell reagiert haben, die sagten: „Genial, lass eine Krise nicht ungenutzt verstreichen. Was können wir tun?“ Sie werden es gut machen. Diejenigen, die auf ihrem Standpunkt beharren und stur sind und sagen, dass die Welt wieder zur Normalität zurückkehren wird und es ist nur eine Frage der Zeit, vor denen ich Angst habe, denn diese Atrophie, die vielleicht ein langsamer Rückgang war, wird, glaube ich, zu einer Klippe. Richtig? Weil bei einem Verbraucher-
Nick Muldoon:
Langsamer Rückgang, und dann fallen sie irgendwann einfach vom Rand.
Dom-Preis:
In der Konsumwelt sinken die Ausgaben der Verbraucher, die Stimmung sinkt und Relevanz wird plötzlich wirklich wichtig. Ist Ihr Produkt für Ihre Kunden relevant? Die Leute, die das verstehen und dann agil in der Umsetzung sind, das ist eine gewinnbringende Kombination. Ich finde das Interessante daran, dass ich am Wochenende mit einem Freund darüber gesprochen habe, weil sie sich gefragt haben: „Was ist der Unterschied zwischen den erfolgreichen und den nicht erfolgreichen?“ Es ist schwer, einen einzigen Grund zu nennen. Aber der, der für mich auffällt, ist, dass die agilen Transformationen, bei denen der Mensch im Mittelpunkt stand, die besten sind. Eine ganze Reihe von ihnen war werkzeug- oder prozessorientiert. Ich werde alle meine Leute auf eine Schulung schicken. Ich werde dich agil machen, ich werde dir ein paar agile Tools geben. Geh. Du sagst: „Hast du ihre Denkweise geändert? Hast du ihr Herz verändert? Hast du die Dinge geändert, für die sie bekannt sind, ihre inneren Beweggründe? Hast du diese Dinge geändert?“ Denn wenn du es nicht getan hast, ist ihr Innenleben immer noch dasselbe, oder? Du gibst ihnen nur eine neue Terminologie.
Nick Muldoon:
Ich denke, das ist ein wirklich, wirklich, wirklich gutes Argument. Wenn ich an die erste Agile-Konferenz zurückdenke, an der ich vor über einem Jahrzehnt teilgenommen habe, geht es bei dem Gespräch damals hauptsächlich um das Training der Praktiken, das Unterrichten der Praktiken an Ihre Mitarbeiter, und dann entwickelte es sich zu einem Tooling-Gespräch. Aber auch hier handelt es sich bei der Vermittlung der Methoden und der Software nur um Werkzeuge, und ich glaube, es war 2013, 2014, als die moderne Agile-Bewegung herauskam und viel über psychologische Sicherheit gesprochen wurde. Gehen Sie zurück zu dem Punkt, an dem wir das Gespräch begonnen haben, richtig?
Dom-Preis:
Ja.
Nick Muldoon:
Psychologische Sicherheit, bringen Sie Ihr ganzes Ich mit zur Arbeit, und das wird Sie befreien und es Ihnen ermöglichen, etwas Großartiges für Ihre Kunden zu tun. Geben Sie mir einen Eindruck von den Kundengesprächen, die Sie im Laufe des Jahres 2020 geführt haben. Wie viel Prozent glauben Sie, haben psychologische Sicherheit, haben wirklich diese psychologische Sicherheit?
Dom-Preis:
Ja. Ich muss mich daran erinnern, dass psychologische Sicherheit kein Alles oder Eins ist, oder? Es ist eine gleitende Skala. Ich würde sagen, es ist verbessert, wo es um Authentizität geht. Die Gefahr ist, dass es zu einem Thema wird, bei dem die Leute sagen: „Ich habe von zu Hause aus gearbeitet. Es besteht ein erhöhtes Stressrisiko, das ist eine ganze Veränderung. Die Dinge laufen schief. Oh, ich weiß was, lass uns einfach viel über psychologische Sicherheit sprechen.“ Du bist wie...
Nick Muldoon:
Das ist es nicht.
Dom-Preis:
... „Es gibt keinen Zusammenhang zwischen Reden und Tun.“ Richtig? Es wird zum Thema, richtig, die Mode, oder? So wie es Mode geworden ist, über Wellness und Achtsamkeit zu sprechen, heißt das nicht, dass wir darin besser sind. Und so dass...
Nick Muldoon:
Aber ist das nicht die Sache, Dom? Agile war in Mode, und so haben wir darüber gesprochen, aber in vielen dieser Organisationen hat sich nichts wirklich geändert.
Dom-Preis:
Ja. Das ist mit psychologischer Sicherheit nicht unähnlich. Was jedoch passiert ist, ist, dass im Laufe der Zeit die wirklich authentischen und verletzlichen Führungskräfte ein Umfeld geschaffen haben, in dem Sie Ihr Bestes geben können, und sie schätzen den respektvollen Dissens, aber sie werden immer noch, zur richtigen Zeit, anderer Meinung sein und sich verpflichten. Sie sagen: „Nick, ich habe deine Meinung gehört. Danke fürs Teilen. Unsere einzige Entscheidung im Moment ist, Pfad A zu nehmen. Ich weiß, dass du dich auf Pfad B befindest. Wir gehen Pfad A. Wenn wir diesen Raum verlassen, verpflichten wir uns zu A.“ Ich höre dich. Ihr wollt mich, wenn wir nach A kommen, und hier sind die Signale, die wir auswerten werden, um sicherzustellen, dass es der richtige Weg ist. Wenn nicht, korrigieren wir den Kurs. Diese Menschen gedeihen in diesem Umfeld, und mehr Menschen wollen mit ihnen zusammenarbeiten. Dieses Umfeld hat dazu geführt, dass es den Unterschied zwischen Managern und Führungskräften deutlich gemacht hat. Manager verwalten Prozesse und sie mögen Kontrolle. Richtig? Bei Führungskräften geht es um Einfluss und Menschen.
Nick Muldoon:
Denken Sie, dass die Tatsache, dass die Leute von zu Hause aus arbeiten und von zu Hause aus arbeiten, es einfacher gemacht hat, zu erkennen, wer die Führungskräfte sind?
Dom-Preis:
Ja, es ist ein Licht angeleuchtet...
Nick Muldoon:
Weil die Manager nur versuchen, die Zeit zu zählen.
Dom-Preis:
Ja, ich zähle die Zeit, aber sie prügeln auch bei der Arbeit herum, weil sie sagen: „Ich bin der Manager. Ich muss zeigen, dass ich etwas tue. Ich würde Aufgaben im und um das Büro erledigen und was ich von einigen Leuten erwarten wollte. Wenn wir autonom sind und sie das einfach machen, was ist dann meine Rolle?“ Plötzlich fangen Sie an, Geschäfte zu erledigen. Dieses Geräusch kommt von ihnen, was nicht heißt: „Hier ist ein Ergebnis, das ich erzielt habe, oder so steht das Team in Bezug auf den Zusammenhalt oder die Bindung im Team.“ Sie sprechen nicht über große Dinge auf Meta-Ebene. Sie teilen diese Transaktionen mit dir und du sagst: „Ich ging davon aus, dass du die Transaktionen immer durchführst. Jetzt zeigst du mir sie alle. Es ist ein bisschen komisch.“ Richtig? Es ist nur ein Verhalten, oder? Dafür müssen wir ein Verfahren haben. Nun, was ist der Prozess? Du sagst: „Was ist eigentlich mit dem Prozess des gesunden Menschenverstands?“ Richtig?
Dom-Preis:
Wenn Sie an die Zeit vor COVID denken, hatten die meisten Organisationen, die es den Mitarbeitern ermöglichen würden, ein- oder zweimal pro Woche von zu Hause aus zu arbeiten, einen riesigen Prozess und eine Richtlinie darüber, wie Sie sich an einem Tag in der Woche für die Arbeit von zu Hause aus bewerben und so, und dann sagen sie plötzlich: „Nun, das können wir tatsächlich tun. Jeder wird von zu Hause aus arbeiten gehen.“ Aber jetzt haben sich die Dinge etwas beruhigt, die Prozesspolizei und die politische Polizei kommen wieder und sagen: „Aber worüber, worüber? Wir bezahlen Nick dafür, dass er 40 Stunden pro Woche arbeitet, und was ist, wenn er 40 Stunden nicht arbeitet?“
Nick Muldoon:
40 Stunden pro Woche.
Dom-Preis:
Wen interessiert's? Nick hat seine Ergebnisse geliefert und seine Kunden sind überglücklich. Solange er nicht 80 Stunden durchhält und er nicht ausbrennt, ist das egal? Richtig? Die Idee von Montag bis Freitag von 9:00 bis 17:00 Uhr als Konstrukt wird in Frage gestellt. Die Vorstellung, dass Sie acht Stunden am Tag an einem physischen Schreibtisch sitzen müssen, um Ihre Arbeit zu erledigen, obwohl Sie tatsächlich mindestens die Hälfte Ihrer Aufgaben asynchron erledigen können, wurde in Frage gestellt. Aber Manager, die Prozesse verwalten und kontrollieren wollen, sagen: „Aber wenn Nick von überall aus arbeiten kann und wir darauf vertrauen, dass er die richtige Arbeit macht, was mache ich dann? Ich bin sein Manager. Du sagst: „Du könntest ihn inspirieren. Du könntest ihn coachen, ihn betreuen. Du kannst ihn führen, du kannst ihm helfen, zu wachsen, du kannst eine Menge Dinge tun. Erledige nur nicht seine Aufgaben für ihn. Er ist durchaus in der Lage, eine To-Do-Liste zu verwalten.“ Es stellt dieses Konstrukt erneut in Frage. Für viele Menschen ist das unangenehm, weil es ein Konzept ist, an dem wir jahrelang festhielten.
Nick Muldoon:
Das wird zu vielen Veränderungen führen. Ich glaube, ich habe in Bezug auf Fernarbeit nachgedacht, Dom, ich habe viel mehr über die Mechanik von Telearbeit und Logistik nachgedacht, rund um Gehaltsskalen, geografische Lage und Bezahlung und all diese Dinge. Aber du öffnest mir wirklich die Augen für einen ganz anderen Aspekt. In vielen großen Organisationen gibt es viele mittlere Führungskräfte, und wenn diese Rollen nicht mehr wertvoll sind, was machen dann all diese Menschen und wie helfen wir ihnen, etwas zu finden, das sie lieben und nach dem sie sich sehnen? Weil sie sich vermutlich nicht danach sehnen...
Dom-Preis:
Ja, das ist die Sache.
Nick Muldoon:
... Aufgabenmanagement.
Dom-Preis:
Ja, ja. Sie sind wahrscheinlich nicht tief darin verwurzelt, weil es etwas ist, für das sie eine Leidenschaft haben, oder? Es ist so, als hätten sie sich in dieser Rolle wiedergefunden. Das ist das Interessante. Wenn Sie sich Neuskalierung ansehen, ich betrachte Neuskalierung seit ein paar Jahren als Trend, oder? Wie beurteilen wir das Tempo der Veränderung sowohl in der Technologie als auch in der Praxis, was auch immer? Das bedeutet, dass wir alle neu skalieren müssen, oder? Die Vorstellung, dass Bildung bis zum Alter von 21 Jahren möglich ist und man dann 45 Jahre arbeitet, gibt es nicht, oder? Also lebenslanges Lernen. Du siehst dir das an und du gehst... Amazon hat letztes Jahr ein gutes Beispiel gegeben. Bezos und Amazon haben eine Milliarde Dollar zur Seite gelegt, um tausend Menschen zu entlassen, die sie entsorgen wollten. Richtig?
Nick Muldoon:
Ja, ja, ja.
Aus ihren Lagerhäusern, richtig?
Dom-Preis:
Ja, ja. Ja, sie nutzen die Automatisierung, um diese Leute zu verdrängen. Was kürzlich herauskam und besagte, dass ich glaube, es sind ungefähr 1.500 Menschen, die vertrieben werden, weil sie sich für vollständig autonome Vertriebszentren entscheiden. Sie versuchen, diese Menschen umzuschulen und sie woanders einzusetzen. Sie sagen: „Cool, wie machen wir das?“ Der Grund, warum ich das erwähnt habe, ist, dass ich denke, wir gehen davon aus, dass wir es für gering qualifizierte, umfangreiche Aufgaben verwenden, weil das das ist, was wir in der Vergangenheit mit technologischer Disruption in Verbindung gebracht haben. Aber wenn Sie darüber nachdenken, gab es, glaube ich, vor etwa anderthalb Jahren, einen Bericht von McKinsey mit dem Titel The Frozen Middle Layer. Es ging darum, wie diese gefrorene mittlere Schicht auftauen und entlarvt werden sollte, richtig, als diese mittleren Manager. Es gibt Tausende von ihnen. Dieser Satz, die mittlere Schicht, COVID hat dem nur das Sahnehäubchen aufgegossen. Richtig? [unhörbar 00:53:26]. Sie sagen alle: „Was? Ich? Nein, nein, ich habe nur noch 10 Jahre in meiner Karriere. Lass mich hier sitzen und ein paar Aufgaben erledigen. Ich nehme jedes Jahr eine inflationäre Lohnerhöhung in Kauf. Ich werde keinen Ärger machen.“ Du sagst: „Ich weiß nicht. Du kannst hier umschulen.“
Dom-Preis:
Diese Leute wurden noch nie dazu gebracht, über eine Umschulung nachzudenken. Sie wurden so konstruiert, dass sie an Komfort, Konservatismus und Sicherheit denken. Ich denke, wir müssen erkennen, dass sie am Arbeitsplatz immer noch einen Wert haben. Ich glaube einfach nicht, dass es der alte Wert ist. Für sie sind die vier Ls-
Nick Muldoon:
Das wird ein großer Schock für diese gefrorene Mittelschicht sein, wie McKinsey es nannte. Ich glaube, wir sind Wollongong, Port Kembla. Wir sind in einer Stahlstadt der Arbeiterklasse, und im Laufe von, wählen Sie eine Zahl, im Laufe von 25, 30 Jahren wurden 20.000, 22.000 Menschen aus dem Stahlwerk entlassen und ihnen wurde gesagt, sie sollen sich umschulen. Ich bin mir sicher, dass einige von ihnen das tun, aber viele von ihnen, die älter sind, Sie sprechen von jemandem, der in den Fünfzigern ist und 10 Jahre in seiner Karriere hinter sich hat, richtig, sie sind wahrscheinlich gerade in den Vorruhestand gegangen, und vielleicht haben sie in der Gemeinde etwas anderes zu tun gefunden, was auch immer es sein mag. Was sind die Strukturen, die wir für diese riesige Crew von Mitarbeitern bereitstellen, um sie in unseren Unternehmen weiterzubilden, damit wir nicht das implizite Wissen verlieren und zur nächsten Sache übergehen? Wie denkt Atlassian darüber?
Dom-Preis:
Es geht auch darum, es von vorne zu laden, oder? Wir müssen uns als Gesellschaft im Allgemeinen schämen, wie leicht wir sie verlassen. Wenn ich Geschichten über die Schließung der Stahlwerke höre und du sagst: „Warum überrascht uns das? Warum sind wir überrascht, als Holden in Australien aufhörte, Autos zu entwickeln? Wirklich? Aber wirklich, du bist überrascht?
Nick Muldoon:
Wir haben es kommen sehen.
Dom-Preis:
Ja.
Nick Muldoon:
Wir haben die Autoindustrie in Australien 35 Jahre lang unterstützt.
Dom-Preis:
Ja. Sie erheben Zölle auf jeden, der importiert, um Ihre eigene Branche gut aussehen zu lassen, und dann fallen diese Zölle weg, die Leute suchen nach billigeren. Leider haben wir uns für eine globale Wirtschaft entschieden, oder? Wir verfolgen ein grenzenloses Geschäftsmodell, und ob Sie das mögen oder nicht, dafür haben wir uns entschieden. Die Realität ist, anstatt jedes Mal zu reagieren, wenn das passiert, wenn es normalerweise zu spät ist, wie können wir reagieren? Wie können wir diese brillanten Algorithmen und das Datenmanagement nutzen, um zu sagen: „Hier sind die Zukunftskompetenzen des Weltwirtschaftsforums, hier sind große Arbeitgeber, hier sind andere Fähigkeiten über Menschen.“ Sie versuchen, das herauszugeben, und Sie sagen: „Das sind die am stärksten gefährdeten, und sie sind in den nächsten 18 Monaten gefährdet.“ Cool. Fangen Sie jetzt an, sie umzuschulen, aber nicht, wenn sie arbeitslos sind, wenn sie sagen: „Nun, jetzt habe ich meinen Job verloren. Nun, was machen wir?“ Du sagst: „Ich weiß nicht. Bestrebungen? Ich weiß nicht.“
Dom-Preis:
Wir haben viel mehr Daten und Erkenntnisse, als wir uns wahrscheinlich selbst zutrauen. Ich denke, ein Element stellt es in den Vordergrund, und das nächste sagt: „Wie können wir dieses Problem nicht noch einmal wiederholen?“ Wenn Sie sich gerade in den USA umschauen, ist der Fahrer der größte Arbeitgeber, nicht nach Unternehmen, sondern nach Art der Tätigkeit.
Nick Muldoon:
In Ordnung. Ja, nach Rolle. Ja, ja, ja.
Dom-Preis:
Nach Rolle, richtig? Also Uber-Fahrer, Lkw-Fahrer, manuelle Fahrer, Leute hinter dem Lenkrad, die ein Fahrzeug fahren. Wo fließen Investitionen im Wert von Milliarden von Dollar rein, Google, Amazon und alle anderen? Richtig? Autonome Fahrzeuge. Du sagst: „Cool.“
Nick Muldoon:
Autonome Fahrzeuge. All diese Leute loswerden?
Dom-Preis:
Wenn ich...
Nick Muldoon:
Was tun wir, um diese Leute weiterzubilden?
Dom-Preis:
Ja. Oder noch besser, was tun wir in unserem Bildungssystem, um zu sagen: „Wie helfen wir Menschen, die das Bildungssystem durchlaufen, ihre zukünftigen Fähigkeiten widerstandsfähiger zu machen? Mir gefällt die Vorstellung nicht, Menschen zukunftssicher machen zu können. Ich glaube nicht, dass wir eine Kristallkugel haben, also trennen wir sie. Aber wie machen wir die Menschen widerstandsfähiger in Bezug auf ihre Fähigkeiten, nun ja, all die Fähigkeiten, von denen wir glauben, dass sie erforderlich sein werden? Das Weltwirtschaftsforum führt alle paar Jahre großartige Forschungsarbeiten durch und veröffentlicht sie, und dann sehe ich mir das Bildungssystem an und denke mir: „Das wurde 1960 gebaut. Wir schalten das für Kinder aus, wenn du mit ihnen sprichst.
Nick Muldoon:
Hey, hey, hey, Dom, okay, okay. Ich werde im Moment nervös. Lassen Sie uns mit einem schönen Abschluss enden. Was sind Dinge, die Sie für das nächste Jahrzehnt optimistisch stimmen? Alles klar? In 10 Jahren, wie alt wirst du in 10 Jahren sein? Etwa 45 oder so?“
Dom-Preis:
52.
Nick Muldoon:
52?
Dom-Preis:
Ja.
Nick Muldoon:
In Ordnung. Oh ja.
Dom-Preis:
Alt werden.
Nick Muldoon:
Ja, okay. Ja, okay. Okay, also wenn du 52 bist, worauf freust du dich in den nächsten zehn Jahren? Was ist aufregend?
Dom-Preis:
Es gibt ein paar Dinge, die wir erkennen müssen, oder? Das allererste, was wir akzeptieren müssen, ist, dass unsere Zukunft nicht vorherbestimmt ist, nicht geschrieben ist und nicht auf uns wartet. Richtig? Wir gestalten es und definieren es jeden Tag mit unseren Handlungen und Untätigkeiten. Sobald wir diese Anerkennung haben, sitzen wir nicht mehr als Opfer hier und warten darauf, dass es uns widerfährt. Wir sagen: „Oh, oh, ja.“ Dann sagen wir: „Wir müssen über die Zukunft entscheiden. Niemand sonst tut das. Das tun wir gemeinsam.“ Das ist der erste Schritt. Du sagst: „Oh, ich habe viel mehr Mitspracherecht, als mir je bewusst war.“ Die zweite ist, wir müssen eine ganze Menge Dinge rund um Produktivität und BIP fallen lassen, und all diese Dinge, die uns beigebracht wurden, sind großartige Erfolgsmaßstäbe und wir müssen einfach glücklich und zufrieden im Leben sein. Wenn Sie noch vier Jahre haben, ich habe wahrscheinlich noch etwas mehr als 30 Jahre, ich möchte diese 30 Jahre genießen. Ich habe keine Vorstellung davon, irgendwo auf einem Grabstein begraben zu werden mit: „Dom war produktiv“.
Nick Muldoon:
Dom, das ist großartig. Was wir in den nächsten 10 Jahren für die Gesellschaft tun müssen, ist, die Gesellschaft von KPIs zu OKRs zu bewegen.
Dom-Preis:
Ja.
Nick Muldoon:
Richtig?
Dom-Preis:
Und finde ein Gleichgewicht, indem du sagst: „Wie... Das habe ich von COVID gelernt, oder? Du weißt das, ich habe letztes Jahr 100 Flüge gemacht. Ich habe Anfang des Jahres ein paar gemacht und bin mitten in COVID nach Großbritannien gereist. Aber ich bin seit Juni nicht mehr gereist. Zugegeben, die ganze Sache mit der Arbeit von zu Hause aus, ich werde ein bisschen verrückt, aber die Balance des Lebens, wie jeden Abend in meinem Bett zu schlafen, mit Freunden rumhängen, bedeutungsvolle Verbindungen, richtig, echte Gemeinschaft. Ich lebe seit drei Jahren in derselben Wohnung, und ich brauchte COVID, um einen meiner Nachbarn zu treffen, und ich brauchte COVID, um die schönen Damen im Café unten kennenzulernen. Ich sage: „Ich habe drei Jahre über dir gelebt, und erst jetzt bist du eine Person geworden.“ Richtig?
Dom-Preis:
Es gibt so viele gemeinschaftliche und gesellschaftliche Aspekte, die wir daraus herausholen können. Das leere Blatt Papier, wenn man sich das als eine Störung vorstellt, die uns passiert ist, und es gibt keine andere Wahl, und wir können dagegen kämpfen, dass die Optionen, die wir haben, um das Leben danach tatsächlich zu verbessern. Ob es nun Experimente mit viertägiger Arbeitswoche sind oder ob wir tatsächlich von überall aus arbeiten, bedeutet, dass ganz andere behinderte oder berufstätige Eltern Zugang zur Belegschaft erhalten. Lustig, wenn du mehr schaffst. Die Arbeitslosigkeit in Behinderten liegt 50% über der Arbeitslosenquote in der arbeitsfähigen Gemeinschaft, nicht wegen geistiger Fähigkeiten, sondern nur, weil es für sie schwierig ist, sich anzupassen.
Nick Muldoon:
Logistisch. Ja.
Dom-Preis:
Das hast du gerade geändert, richtig, mit diesem verrückten Experiment namens COVID. Wenn wir anfangen, diese Vorteile zu nutzen, und wir sehen darin tatsächlich eine Chance zur Innovation, richtig, und ich hasse das P-Wort von Pivot, aber vergessen wir Pivotieren, um wirklich innovativ zu sein, wie könnte die Welt aussehen, und wie können wir uns darauf stützen? Wie erreichen wir ein Gleichgewicht zwischen Profit und dem Planeten und den Menschen und dem Klima und all diesen Dingen? Wenn wir das tun, haben wir die Chance, das jetzt aufzubauen und eine Zukunft aufzubauen, die wir wollen und auf die wir wirklich stolz sind. Ich denke, es ist jetzt an der Zeit, dass wir alle aufstehen, denn das wird uns nicht passieren... Oder es wird uns passieren. Wenn wir uns dafür entscheiden, nichts zu tun, passiert es uns. Das muss es nicht. Ich freue mich wirklich, weil ich denke, dass wir einige grundlegende Änderungen vornehmen und alte Arbeitsweisen und Lebensweisen herausfordern werden, und wir werden dadurch glücklicher sein.
Nick Muldoon:
Don, ich bin total begeistert, Mann. Danke. Danke, dass du dir heute Zeit genommen hast. Das ist ein großartiger Ort, um es zu beenden.
Dom-Preis:
Ich hoffe, dass einige dieser Dinge wahr werden.
Nick Muldoon:
In Ordnung. Ich hoffe, einige dieser Dinge werden wahr, oder? Ich habe das Gefühl, dass die Dinge, die in unserer Macht stehen, die Dinge, die wir direkt beeinflussen können, Erkenntnisse für mich, ich habe die Liebe und den Abscheu in die Liebe, den Abscheu, die Sehnsucht und die ich gelernt habe, ausdehnen. Ich finde das großartig. Ich mag auch den Bumerang gegen den Stock in Bezug auf deine Zeit und das, was im Kalender steht, und einfach das Zeug über Bord werfen, das dir oder den Teams oder sonst jemandem nicht hilft. Ja.
Dom-Preis:
Du könntest es so machen wie [unhörbar 01:01:33]. Wenn es sich als wichtig herausstellt, können Sie es wieder hinzufügen.
Nick Muldoon:
Sicher.
Dom-Preis:
[unhörbar 01:01:38].
Nick Muldoon:
Die große Erkenntnis aus diesem Gespräch für mich ist, dass es in unseren Händen liegt. Die Wahl, wir treffen die Entscheidungen. Es liegt in unseren Händen. Ich denke etwa an Mark Twain, ob du glaubst, du kannst oder ob du denkst, du kannst es nicht, du hast recht.
Dom-Preis:
Ja. Ja.
Nick Muldoon:
Du könntest genauso gut denken, dass du es kannst und weitermachen.
Dom-Preis:
Ja, ja, probiere es glühend aus und schau, was passiert.
Nick Muldoon:
In Ordnung, cool. Don, vielen Dank für deine Zeit heute Morgen. Das weiß ich wirklich zu schätzen.
Dom-Preis:
Es war toll zu chatten.
- Podcast
Easy Agile Podcast Ep.32 Why Your Retrospectives Keep Failing (and How to Finally Fix Them)
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.

