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
PodcastEasy Agile Podcast Ep.21 LIVE von Agile2022!
„Das ist ein Abschluss von Agile2022! Es war großartig, so viele von Ihnen in der Agile-Community persönlich treffen zu können!“ - Tenille Hoppo
Diese Bonus-Episode wurde LIVE bei Agile2022 in Nashville aufgenommen!
Das Easy Agile-Team hat mit so vielen großartigen Leuten aus der Agile-Community gesprochen und über die Höhepunkte der Konferenz, wichtige Erkenntnisse, agile Zeremonien und mehr nachgedacht!
Vielen Dank an alle, die am Stand vorbeigeschaut haben, um G'Day zu sagen und ein oder zwei Tim Tam genossen haben;)
Vielen Dank an alle unsere Podcast-Gäste, dass sie einige Zeit mit uns verbracht haben, um diese Episode zu erstellen!
- Cody Wooten
- Gil Broza
- Maciek Saganowski
- Lindy Quick
- Carey Young
- Leslie Morse
- Dan Neumann
- Joe Falu
- Kai Zander
- Avi Schneier
- Doug Page
- Evan Leyburn
- John Kerr
- Josua Seckel
- Rob Duval
- Andrew Thompson
Transkript
Caitlin:
Hallo zusammen. Nun, das ist ein Abschluss von Agile 2022 in Nashville. Das Easy Agile-Team ist wieder zu Hause in Australien, und wir haben den größten Teil unserer Heimreise damit verbracht, über all die großartigen Gespräche zu sprechen, die wir mit allen Mitgliedern der Agile-Community führen konnten. Es war großartig, Kunden und Partner zu treffen, alte Freunde zu sehen und viele neue zu finden. Wir haben es geschafft, einige Ausschnitte dieser großartigen Gespräche aufzunehmen, und wir freuen uns, sie mit Ihnen, unserem Easy Agile Podcast-Publikum, zu teilen. Also viel Spaß.
Maciek:
[unhörbar 00:00:26].
Tenille:
Maciek, vielen Dank, dass du dir heute Zeit für uns genommen hast.
Maciek:
Keine Sorge.
Tenille:
[unhörbar 00:00:30], kannst du uns sagen, was das Beste war, was du diese Woche gelernt hast?
Maciek:
Oh, das war definitiv bei Melissa Perris Vortrag. Als sie über... sprach Als ob sie für mich davon sprach, langsamer zu werden. Und was wir bei Agile tun, ist nicht nur Lieferung, Lieferung, Lieferung, sondern es geht auch darum, Dinge, die wir bereits entwickelt haben, zu lernen und zu ändern und herauszufinden, welchen Mehrwert wir unseren Kunden bieten können. Es geht nicht nur um Versandfunktionen, es geht vor allem um den Wert. Das habe ich gelernt.
Tenille:
Das ist großartig. Danke. Also, was denkst du wäre die geheime Zutat für ein großartiges Agile-Team?
Maciek:
Demut. Irgendwie sollte die Teamkultur Demut und Fehler beinhalten. Und die Leute sollten keine Angst davor haben, Fehler zu machen, denn ohne Fehler zu machen, lernt man nicht. Das ist was ich denke.
Tenille:
Was wäre also, glaube ich, wenn es eine Agile-Zeremonie gäbe, die jedes Team durchführen sollte, was denkst du, könnte das sein?
Maciek:
Sicher, Retro, und das kommt wieder auf die Fehler und den Lernteil zurück.
Tenille:
Ja. Fantastisch.
Maciek:Keine Sorge.
Tenille:
Das ist großartig. Vielen Dank, dass du dir die Zeit genommen hast.
Maciek:
In Ordnung. Danke.
Tenille:
Prost.
Mädchen:
[unhörbar 00:01:42].
Caitlin:
Gil:, vielen Dank, dass du mit uns gechattet hast. Im Moment sind wir also alle auf der Agile 2022 in Nashville. Es finden viele interessante Gespräche statt.
Mädchen:
Ja.
Caitlin:
Wenn Sie einem neu entstehenden Agile-Team einen Ratschlag geben könnten, welcher wäre das?
Mädchen:
Es wäre, kleine, wertvolle Arbeiten gemeinsam zu beenden. Es hat ein schreckliches Akronym, FSVWT. Es kann also nicht auf diese Weise in Erinnerung bleiben. Erledigen Sie gemeinsam kleine, wertvolle Arbeiten. Es wird viel über Prozesse, Arbeitsvereinbarungen und Tools gesprochen. Das ist alles wichtig, aber manchmal ist es zu viel für ein Team, das gerade erst anfängt. Wenn wir also nur daran denken, kleine wertvolle Arbeiten gemeinsam zu erledigen, ist das eine großartige Geschichte.
Caitlin:
Ja, ich liebe das. Und du warst Redner auf der Konferenz?
Mädchen:
Ja.
Caitlin:
Kannst du unserem Publikum einen kleinen Einblick geben, worum es in deinem Gespräch ging?
Mädchen:
Was in vielen Situationen passiert, ist, dass Technik oder Entwicklung nicht wirklich mit dem Produkt/Unternehmen zusammenarbeiten. Und stattdessen gibt es eine Übergabebeziehung. Aber was passiert, ist, dass es ohne eine kooperative Beziehung wirklich schwierig ist, Agilität aufrechtzuerhalten. Die Leute machen viele einseitige Annahmen. Und im Laufe der Zeit führt die Art und Weise, wie Entscheidungen getroffen werden, dazu, dass die Kosten für Änderungen steigen und die Sicherheit, Änderungen vorzunehmen, sinkt. Und wenn das passiert, wird alles schwieriger und langsamer, sodass die Agilität darunter leidet. Der Kern des Vortrags war also, wie wir zusammenarbeiten können, also sowohl das Produkt als auch die Technik, auf eine Weise, die es uns ermöglicht, die Kosten von Änderungen zu kontrollieren und die Sicherheit zu erhöhen? Es geht also nicht nur um Zusammenarbeit jeglicher Art. Es gibt ganz bestimmte Prinzipien, die befolgt werden müssen. Das nennt man technische Agilität, und wenn wir das tun, können wir langfristig agil sein.Caitlin:
Großartig. Ich liebe es. Nun, vielen Dank und ich hoffe, Sie genießen den Rest Ihrer Zeit auf der Konferenz.
Mädchen:
Ich danke dir.
Caitlin:
Großartig. Danke.
Tenille:
Hallo, Tenille hier von Easy Agile, mit Josh von Deloitte, und wir werden ein gutes Gespräch über Team-Retrospektiven führen. Also Josh, danke, dass du dir die Zeit für ein gutes Gespräch genommen hast. Sie sind also ein bisschen Experte für Team-Retrospektiven. Was sind deine Top-Tipps?
Josh:
Meine Top-Tipps für den Rückblick sind also zunächst, tatsächlich eine Änderung vorzunehmen. Machen Sie keine beobachteten Lektionen. Ich habe gesehen, dass viele von ihnen tatsächlich eine Veränderung vorgenommen haben, auch wenn es am Ende nur eine kleine ist. Die zweite und ein Teil davon ist, dass Sie Ihre Veränderung vornehmen und experimentieren. Etwas, das man messen kann, etwas, von dem man tatsächlich sagen kann, ja, wir haben dieses Ding gemacht und es hatte Wirkung. Vielleicht nicht die Wirkung, die Sie sich gewünscht haben, aber es hatte eine gewisse Wirkung. Der zweite Tipp lautet: Variieren Sie Ihre Rückblicke. Eine Retrospektive, die Sprint für Sprint nach Sprint gleich ist, funktioniert für etwa zwei Sprints, und dann werden Ihre Produktivität und Ihre Kreativität außerhalb der Retrospektive erheblich abnehmen.
Tenille:
Das ist ein ausgezeichneter Punkt. Also, wie erstellt man [unhörbar 00:05:03]?
Josh:
Ich habe viel über sie nachgedacht und recherchiert und Websites wie TastyCupcakes genutzt, aber auch meine eigenen Retrospektiven entwickelt. Ich habe eine Retrospektive gemacht, die auf dem Pixar-Pitch basiert. Es gibt sechs Sätze, die jeden Pixar-Film definieren. Nehmen Sie die Basissätze, wenden Sie sie auf Ihren Sprint oder Ihren PI an und machen Sie einen Retro, und lassen Sie dem Team diese Kreativität, um ein ganzes Filmplakat zu erstellen, wenn es möchte. Regie: [unhörbar 00:05:34], weil es passiert. Die Leute engagieren sich und engagieren sich, wenn man ihnen Alternativen gibt, verschiedene Arten, Retrospektiven zu machen.
Tenille:Das ist richtig. Also für die Teams, die im Moment keine Retrospektiven veranstalten, was ist die eine wichtige Sache, über die sie nachdenken müssen, dass du... Was ist das Wichtigste, was du ihnen sagen könntest, um sie zum Start zu ermutigen?
Josh:
Wenn du keine Retrospektiven machst, machst du keine [unhörbar 00:05:54]. Also sollte ich das nicht sagen. Aber wenn du keine Retrospektiven machst, wenn du wirklich glaubst, dass du absolut nichts zu verbessern hast und du zu 100% zu den Besten der Besten gehörst, was bedeutet, dass du wahrscheinlich bei Google oder Amazon oder Netflix arbeitest, obwohl sie Retrospektiven machen. Wenn du also wirklich glaubst, dass du diesen Unternehmen gleichwertig bist, dann musst du sie vielleicht nicht machen, aber ich bin mir ziemlich sicher, dass jedes Team etwas hat, das es verbessern kann. Und das anzuerkennen und dann zu sagen, wie werden wir das machen? Die Retrospektive ist eine sehr schnelle und einfache Methode, um diese Verbesserungen tatsächlich vorzunehmen und sie in die Realität umzusetzen.
Tenille:
Fantastisch. Großartig. Vielen Dank, dass Sie sich die Zeit genommen haben, kurz mit uns über Rückblicke zu sprechen.
Josh:
Ich danke dir.
Caitlin:
Wir sind hier mit Leslie, der Präsidentin von Women in Agile. Leslie, am Sonntag gab es eine tolle Veranstaltung.
Leslie:
Ja.
Caitlin:
Sprich uns einfach ein bisschen darüber an. Was ist in die Planung eingeflossen? Wie war es, wieder alle zusammen zu sein?
Leslie:
Es war toll, die Frauen in der Agile-Community wieder zusammen zu haben, oder? Unser erstes Mal seit 2019, als alle zu dieser Veranstaltung in Washington DC zusammen waren. In den meisten sechs oder sieben Monaten der Planung hatten wir ungefähr 200 Personen im Raum. Zum Glück wissen wir [unhörbar 00:07:10], was diese Frauen in Agile-Sessions machen, die wir jedes Jahr im Rahmen der Agile Alliance-Konferenzen veranstalten, oder? Wir haben eine allgemeine Eröffnung. Wir haben einen großartigen Keynote, bei dem es sich immer um jemanden handelt, der direkt neben dem Agile-Bereich steht. Wir wollen nicht einfach nur mögen... Wir wollen unsere Weisheit und unser Wissen mit Leuten teilen, die noch nicht zu uns gehören, weil wir das ganze Agile-Zeug auf der großen Konferenz bekommen, wenn wir dort sind.
Leslie:
In diesem Teil bringen wir immer neue Stimmen auf den Markt, was wahrscheinlich eine meiner Lieblingsfrauen in Agile-Programmen ist. Drei Mentees, die mit erfahrenen Rednern gepaart wurden, treten zum ersten Mal auf die Bühne, um ihr Talent und ihre Sichtweise zu teilen. Das ist also wirklich großartig. Und dann eine Art interaktives Networking-Event. Dieses Muster hat uns also wirklich gute Dienste geleistet, seit wir das seit 2016 machen, was ein bisschen beängstigend ist, wenn man bedenkt, dass es schon so lange passiert. Und es ist zu einer großartigen Gelegenheit für die Community geworden, auf globalere Weise zusammenzukommen, weil die Agile Alliance so viele Menschen für ihre jährliche Veranstaltung anzieht.
Caitlin:
Ja, ganz sicher. Ja, es war eine großartige Veranstaltung. Ich weiß, dass wir alle viel Spaß hatten, dort zu sein. Was war Ihre wichtigste Erkenntnis aus der Veranstaltung?
Leslie:
Ich werde zu [unverständlich 00:08:14] interaktiven Netzwerken gehen, die sie mit uns gemacht hat, und uns wirklich herausfordern, unseren Mut in Bezug auf Grenzen und das Beenden von Gesprächen zu stärken. Wir müssen keinen Grund angeben. Wenn ein Gespräch uns nicht nützt oder aus welchem Grund auch immer nicht der Ort ist, an dem wir sein müssen, haben Sie absolut die Freiheit, dieses Gespräch zu beenden und einfach weiterzumachen. Ich liebe die Tipps und Tricks, die sie uns gegeben hat, um das gut zu machen.
Caitlin:
Ja, ja, das liebe ich auch. Das ist großartig. Nun, vielen Dank. Ich weiß es zu schätzen.
Leslie:
Ja. Danke, dass du mich eingeladen hast.
Tenille:
Hallo, Evan. Wie geht's dir?
Evan:
Sehr gut.
Tenille:
Das ist gut. Kannst du mir bitte sagen, was das Beste ist, was du heute gelernt hast?
Evan:
Das beste Zitat, das ich habe: „Politik ist die Währung menschlicher Systeme.“ Richtig?
Tenille:
Beeindruckend.
Evan:
Wenn du also ein menschliches System ändern willst, musst du die Politik spielen.
Tenille:
Fantastisch.Evan:
Was sich beschissen anfühlt, aber...
Tenille:
Es ist so wie es ist.
Evan:
... so ist das nun mal.
Tenille:
[unhörbar 00:09:07]. Okay, nächste Frage. Ohne welche Agile-Zeremonie können Sie und Ihr Team nicht leben?
Evan:
Rückblick. Mit der Retrospektive kannst du quasi alles andere gestalten.
Tenille:
Fantastisch. Das ist wirklich gut. Und was ist Ihrer Meinung nach wahrscheinlich die wichtigste Zutat für einen guten Rückblick?
Evan:
Oh, vertraue. Vertrauen erfordert Respekt. Es erfordert Glaubwürdigkeit. Es erfordert Empathie. Vertrauen ist also genau das, was menschliche Fähigkeiten untermauert.
Tenille:
Ja. Fantastisch. Vielen Dank.
Evan:
Ich danke dir.
Tenille:
Ja.
Caitlin:
Richtig. Wir sind hier mit Cody von Adfire. Also Cody, wie hat dir die Konferenz bisher gefallen?
Cody:
Ich liebe die Konferenz wirklich. Es war großartig. Um ehrlich zu sein, als wir das erste Mal hier ankamen, schien es vielleicht ein bisschen kleiner als wir dachten, aber die Leute hier waren unglaublich, sehr engagiert, was immer großartig war. Und außerdem verwenden viele Leute Jira und Atlassian. So viele wichtige Punkte.
Caitlin:Win-Win für beide, hm?
Cody:
Ja. Immer, immer, immer.
Caitlin:
Sehr gut.
Cody:
Ja.
Caitlin:
Es finden viele interessante Vorträge statt. Haben Sie an einem teilgenommen, der wirklich Interesse an Ihnen geweckt hat? Was ist [unhörbar 00:10:15] -
Cody:
Ja. Ich kann mich auf Anhieb an keinen der Vortragsnamen erinnern, aber sie waren alle unglaublich aufschlussreich. Tonnenweise Informationen. Es scheint, als gäbe es für alles ein Thema, was immer ein gutes Zeichen ist und solche Sachen. Also meine Notizen, ich habe Seiten und Seiten und Seiten von Notizen, was immer ein gutes Zeichen ist.
Caitlin:
Ja, das ist [unhörbar 00:10:34].
Cody:
Also muss ich zurück und [unhörbar 00:10:35] nochmal.
Caitlin:
Ja.
Cody:
Aber es war unglaublich und die Vorträge waren sehr umfangreich, also ja.
Caitlin:
Gut. Gut. Und was ist die eine wichtige Erkenntnis, auf die Sie sich freuen, zurückzubringen und mit dem Team zu teilen?
Cody:
Nun, ich denke, eine der wichtigsten Erkenntnisse für uns war, dass... Ich habe über das Engagement gesprochen, das alle haben, aber eine Sache, die unglaublich war, ist, die Geschichten aller zu hören, ihre Probleme, ihre Prozesse, all das. All diese Informationen werden also ein großartiges Aggregat sein, das wir zurücknehmen und ein besseres Erlebnis mit unserem Produkt und all den guten Dingen schaffen können. Also ja.
Caitlin:Ganz gewiss. Ich liebe es. Ich habe jetzt noch eine letzte Frage an dich. Es macht einfach Spaß. Es ist wahr oder falsch. Wir machen Australien-Quizfragen. Bist du bereit dafür?
Cody:
In Ordnung.
Caitlin:
In Ordnung.
Cody:
Hoffentlich.
Caitlin:
Also, meine Wahrheit oder Unwahrheit ist, sind Wellensittenschmuggler eine Vogelart?
Cody:
Sind Buggy-Schmuggler...
Caitlin:
Wellensittiche Schmuggler.
Cody:
Wellensittiche Schmuggler.
Caitlin:
Eine Vogelart.
Cody:
Stimmt.
Caitlin:
Falsch. Nein.
Cody:
Was sind sie?
Caitlin:
Tachos.
Cody:
Ja. Ja, ich habe einige davon in meinem Gepäck. Also hole ich jetzt die Wellensittiche raus.Caitlin:
Mit deinen Daisy Dukes.
Cody:
Exakt. Exakt.
Caitlin:
Ja. Und Cowboystiefel, richtig?
Cody:
Ja.
Caitlin:
Nun, vielen Dank.
Cody:
Ich danke dir.
Caitlin:
Ich weiß das sehr zu schätzen.
Cody:
Ja. Danke.
Tenille:
Doug, wie geht's dir?
Doug:
Mir geht es großartig. Ich danke dir.
Tenille:
Fantastisch. Nun, erzähl mir, was ist das Beste, was du heute gelernt hast?
Doug:
Ich finde es wirklich interessant zu erfahren, wie unsere Kunden unsere Produkte verwenden, von denen wir noch nicht einmal wussten.
Tenille:
Das ist unglaublich. Hattest du die Gelegenheit, an vielen der Sessions teilzunehmen?
Doug:Das habe ich eigentlich nicht. Ich war an diese Kabine gebunden, oder ich nahm an Besprechungen teil, die schon geplant waren, bevor ich hierher kam.
Tenille:
[unhörbar 00:12:01].
Doug:
Ja.
Tenille:
Das ist gut. Wenn Sie also wieder auf der Arbeit sind, was ist Ihrer Meinung nach die wahrscheinlich beste Agile-Zeremonie, ohne die Sie und Ihr Team nicht leben können?
Doug:
Ich denke, was ich zurück ins Büro bringe, ist nicht so sehr eine Zeremonie. Es ist wirklich aus der Produktperspektive. Ich arbeite im Produktmanagement. Für uns geht es also darum, wie wir erklären können, wie unser Produkt unseren Kunden einen Mehrwert bietet. So viele Lektionen, die wir daraus gelernt haben, dass wir wirklich darauf bedacht sind, sie zurückzubringen und in unsere Wertebotschaft einzubauen.
Tenille:
Fantastisch.
Doug:
Ja.
Tenille:
Danke. Das ist großartig. Vielen Dank.
Caitlin:
Er war einer der Mitautoren des Agilen Manifests. Erstens, wie geht es Ihnen bisher auf der Konferenz?
Johannes:
Nun, ich arbeite hart.
Caitlin:
Ja, gutes Zeug.
Johannes:
Ich genieße Nashville.
Caitlin:
Ja. Es ist cool, nicht wahr? Es ist so anders als das [unhörbare 00:12:46], was passiert.Johannes:
Ja. Ja, es ist gut. Ja. Es ist schön, viele Leute zu sehen, die ich seit einiger Zeit nicht mehr gesehen habe.
Caitlin:
Ja. Ja.
Johannes:
Und dreidimensional sehen.
Caitlin:
Ja. Ja, ich weiß. Ja, das ist interessant...
Johannes:
Es ist da-
Caitlin:
... [unhörbar 00:12:54] und so was passiert.
Johannes:
Ja, IRL.
Caitlin:
Es passiert viel Interessantes [unhörbar 00:13:01]. Irgendwelche wichtigen Imbissbuden für dich? Was nimmst du danach mit, um es mit dem Team zu teilen?
Johannes:
Oh, nun, das ist eine gute Frage. Ich habe hauptsächlich mit vielen Freunden gesprochen, die ich seit einiger Zeit nicht mehr gesehen habe. [unhörbar 00:13:14].
Caitlin:
Ja.
Johannes:
Und da ich erst seit ein paar Tagen hier bin, war ich nicht viel, wenn überhaupt, dort. Um ehrlich zu sein.
Caitlin:
Ich weiß. Nun, wir sind ziemlich beschäftigt mit den Stiefeln, oder?
Johannes:
Ja. Ja. Aber sicherlich sind die Arten von Gesprächen, die hier geführt werden,... Ich habe mir ein bisschen Sorgen um Agile gemacht. Ich will einfach nicht sagen... Ja, ich will es nicht sagen. Aber ich will nicht sagen, dass Agile zu einem Sprungbrett wird.Caitlin:
Ja.
Johannes:
Aber ich denke, es gibt eine Menge Leute hier, die wirklich immer noch die Ideale annehmen und wirklich lernen, tun und üben wollen [unhörbar 00:14:00].
Caitlin:
Ja.
Johannes:
Also ich bin ehrlich gesagt überrascht und beeindruckt und glücklich. Es gibt eine Menge. Es reicht, wenn man sich mehr vom Manifest zu eigen macht und manchmal vielleicht nicht alle Vorschriften, und man kehrt zu den Grundlagen zurück. [unhörbar 00:14:22] -
Caitlin:
Ja. Also lass uns darüber sprechen, über das Agile Manifest, das du erwähnt hast. Ich nehme das an. Was heißt Umarmen? Kannst du das etwas näher erläutern? Wir wissen also, dass wir die Prinzipien haben. Gibt es eine, die Ihnen wirklich mehr auffällt als eine andere?
Johannes:
Nun, meine Welt von dem, was ich zu der Zeit gemacht habe, und ich hatte viel im Verteidigungsministerium und im Wassertransport gearbeitet und meinen eigenen, leichten Prozess entwickelt, wie wir ihn vor Agile nennen. Also für mich ist der wahre Schlüssel... Das hat nicht die volle...
Caitlin:
Vollständiges Manifest, ja.
Johannes:
Aber wenn du auf die Website gehst und oben liest, geht es darum, als würden wir Wege aufdecken, indem wir etwas tun, und ich lerne immer noch, entdecke immer noch. Und ich denke, es ist wichtig, dass die Leute erkennen, dass wir unser Ego wirklich an der Tür gelassen haben. In unserem Geschäft bescheiden zu sein ist sehr wichtig. Das steht vielleicht nirgends in den Prinzipien, aber wenn das Ganze in der Präambel ganz oben steht und die Tatsache, dass wir im Blog darüber sprechen, wie wir diese Dinge bewerten, im Vergleich zum Ganzen... Da ist ein Pendel, durch das man sehen kann, wie diese beiden Dinge kollidieren. Meiner Meinung nach ist es eine der wichtigsten Eigenschaften, die wir anwenden sollten, dass wir bescheiden sind und Dinge als Hypothese betrachten. Zum Beispiel, baut Funktionen [unhörbar 00:15:58] nicht einfach von unten nach oben, wie sucht man nach den Antworten, das möchte ich, dass die Leute das mitnehmen.
Caitlin:
Das ist großartig. Das ist ein toller Rat. Nun, vielen Dank, John. Danke, dass du dir die Zeit nimmst, mit uns zu chatten.Johannes:
Du bist willkommen, Caitlin.
Caitlin:
Ja. Genieß, was [unhörbar 00:16:11] ist.
Johannes:
Ich danke dir.
Caitlin:
Ich danke dir.
Johannes:
[unhörbar 00:16:13] morgen.
Caitlin:
In Ordnung.
Tenille:
Abukar, danke, dass du heute zu uns gekommen bist. Kann ich Sie beide fragen, was Ihrer Meinung nach das Beste ist, was Sie heute gelernt haben?
Avi:
Das Beste, was ich gelernt habe?
Tenille:
Ja.
Avi:
Das ist wirklich interessant. Weil ich oft hier am Stand bin, werde ich an vielen Dingen teilnehmen können. Ich habe also zwei Dinge gelernt, die wirklich wichtig waren. Erstens ist das Easy Agile-Logo ein umgedrehtes A, weil es bedeutet, dass Sie aus Australien kommen. Es ist also in Down Under. Und dann war die zweitwichtigste Sache, über die ich heute gelernt habe, dass wir in einer Sitzung über Soziokratie gesprochen haben und darüber, wie man Experimente mit Experimenten besser machen kann, was sich zunächst etwas komisch anhörte, aber es ging wirklich darum, einen Mini-A3-Prozess durchzuführen. Für diejenigen unter Ihnen, die zugehört haben: Das wurde Toyota angetan. Es ist eine strukturierte Problemlösungsmethode, aber anstatt sie [unhörbar 00:17:02] zu umgehen und das Experiment durchzugehen, zwei- oder dreimal herumzulaufen und dann zu entscheiden, dass das das richtige Experiment ist, machen Sie weiter.
Tenille:
Ich danke dir. Wie stehts mit deiner Zeit?Kai:
Ich war die meiste Zeit am Stand, aber dadurch lernt man viele Leute auf der ganzen Welt kennen. Und eines haben wir wirklich gemeinsam, nämlich den Wunsch, Menschen zu helfen. Und es war wirklich schön, in einem Raum voller Menschen zu sein, die am Anfang ihrer Reise stehen oder schon sehr erfahren sind und ihre Motivation einfach darin besteht, andere wirklich zu stärken. Es war wirklich schön, mit dieser Art von Energie zusammen zu sein.
Avi:
Wir haben wirklich gelernt, dass unsere Freunde aus Australien hier oben genauso freundlich sind wie Sie auf der anderen Seite. Ich habe das Gefühl, wenn du auf diese Seite kommst, wirst du gemein, aber es stellt sich heraus, dass du auch hier oben genauso nett bist.
Tenille:
Nun, das hängt davon ab, wie lange du schon auf dem Flug warst.
Avi:
Oh, genau.
Tenille:
[unhörbar 00:17:44], uns geht es gut.
Kai:
Ja.
Avi: Abukar:
Exakt. Gut.
Tenille:
In Ordnung. Noch eine Frage hier.
Avi:
Sicher.
Tenille:
Was ist deiner Meinung nach die geheime Zutat für ein erfolgreiches Team?
Avi:
Was halte ich für das Geheimnis? Oh, das ist eine wirklich gute Frage. Das ist ein-
Kai:
Er ist der Beste, um diese Frage zu beantworten.
Avi:Das ist etwas länger als ein zweisekündiger Podcast, aber das sage ich dir. Das ist vielleicht keine psychologische Sicherheit, -
Tenille:
In Ordnung.
Avi:
... nur weil Google das gesagt hat und Project Aristotle das zeigt. Ich denke, um ein wirklich, wirklich erfolgreiches Team zu haben, braucht man einen wirklich erfahrenen Scrum Master. Denn zu sagen, dass das Team psychologische Sicherheit hat, ist eine Zutat, es ist nicht die einzige Zutat. Ein starker Scrum Master ist jemand, der wirklich geschickt darin ist, diese psychologische Sicherheit zu schaffen, aber auch bei all den anderen Aspekten hilft, um sich auf eine möglichst positive Zusammenarbeit und Koordination vorzubereiten. Außerdem auf der Suche nach... Ihr Name ist Cassandra. Auf Slack nennt sie sich selbst Kaizen. Kapierst du es? Das ist ein Witz. Aber das ist die ganze Sache, ein wirklich erfahrener Scrum Master hilft den Teams, die Kaizens zu finden, die sie brauchen, um wirklich leistungsstark zu werden. Psychologische Sicherheit macht das möglich, aber das heißt nicht, dass sie die Leistung steigert. Es ist eine Zutat, um das möglich zu machen.
Tenille:
Fantastisch.
Kai:
Es gibt keine bessere Antwort als diese. Lass uns einen Ausruf machen.
Tenille:
Hervorragend. Vielen Dank, dass Sie sich die Zeit genommen haben.
Avi:
Ich danke dir vielmals.
Kai:
Natürlich.
Hayley:
Wir sind hier mit Carey von Path to Agility. Carey, was hat dir an dieser Konferenz wirklich gefallen?
Carey:
Ich glaube, dass mir an dieser Konferenz bisher am meisten gefallen hat, ist die Interaktion mit all den Leuten, die hier sind. Es ist wirklich schön, sich zu treffen, verschiedene Leute kennenzulernen, Kontakte zu knüpfen und die Gelegenheit zu haben, zu sehen, was es sonst noch auf dem Markt gibt. Und dann sprechen wir natürlich über das Produkt, das wir mit Path to Agility haben. Es ist eine wundervolle Erfahrung, hierher zu kommen und alle zu sehen. Und es ist so schön, wieder persönlich unterwegs zu sein, anstatt die ganze Zeit vor einem Bildschirm zu stehen.
Tenille:Ja, absolut. Hattest du die Gelegenheit, an vielen der Sessions teilzunehmen?
Josef:
Ich habe so viel wie möglich versucht, aber es ist auch wichtig, sich die Zeit zu nehmen, um zu dekomprimieren und alles einwirken zu lassen. Also hier haben wir Spaß.
Tenille:
Ja, absolut. Wenn Sie an die Arbeit zurückdenken, was ist Ihrer Meinung nach die eine Agile-Zeremonie, an der Sie teilnehmen und die Ihnen und Ihrem Team am meisten hilft?
Josef:
Ich denke, verschiedene Wege der Zusammenarbeit zu finden, effektive Wege der Zusammenarbeit. Und wie lösen wir in Bezug auf das Arbeitsmanagement einige der Probleme, die wir haben? Es gibt so viele Tools, die das einfacher machen, und das ist etwas ganz Besonderes. Mit Menschen sprechen und herausfinden, wie sie Probleme lösen.
Tenille:
Und was macht Ihrer Meinung nach ein wirklich gutes Agile-Team aus?
Josef:
Nun, man könnte etwas sehr Klischeehaftes sagen, wie sehr anpassungsfähig zu sein und sich zu verändern und so weiter und so fort. Aber ich denke, es kommt wirklich auf die Interaktion zwischen Menschen an. Einander verstehen, sich gegenseitig ermutigen und einfach die Art und Weise, wie man zusammenarbeitet.
Tenille:
Fantastisch. Großartig. Gut, vielen Dank, dass du dir die Zeit zum Chatten genommen hast.
Josef:
Ich danke dir. Es war nett, die ganze Woche mit euch zu chatten.
Tenille:
Prost.
Tenille:
Dan, danke, dass du dir die Zeit zum Chatten genommen hast.
Dan:
Du bist willkommen.
Tenille:
[unhörbar 00:22:54] Fragen. Was denkst du ist das Beste, was du heute gelernt hast?
Dan:Oh, das Beste, was ich heute gelernt habe, ist, dass die Keynote zu den Morgenprodukten ausgezeichnet war. Ich habe ein paar Tipps bekommen, wie man Produktmanagement macht, verschiedene Strategien, wie man die Leute dazu bringt, sich auf das Taktische und Strategische zu konzentrieren. Also nur ein paar nette kleine Nuggets, wie das geht [unhörbar 00:23:12].
Tenille:
[unhörbar 00:23:13], danke, dass du heute zu uns gekommen bist. Kann ich zunächst fragen, was denkst du ist das Beste, was du diese Woche gelernt hast?
Sprecher 17:
Das Beste, was ich diese Woche gelernt habe, ist, dass es keinen richtigen Weg gibt, Agile anzuwenden. Es gibt viele verschiedene Möglichkeiten, dies zu tun. Es geht also wirklich darum, herauszufinden, welcher Prozess für das Unternehmen, in dem Sie tätig sind, der richtige ist, und diese Erfolgsmuster dann zu nutzen.
Tenille:
Nun, ich schätze, gibt es eine Art Agile-Zeremonie, auf die Ihr Team Ihrer Meinung nach nicht verzichten kann?
Sprecher 17:
Das tägliche Standup ist täglich. Ich denke, viele unserer Teams reden den ganzen Tag lang. Sie müssen sich nicht unbedingt so häufig synchronisieren. Ich hatte schon ein paar Teams, sie fallen etwa drei Tage die Woche aus und es scheint für sie zu funktionieren. Die andere vielleicht wichtigste Erkenntnis, die ich gesehen habe, sind Zeitboxen. Also keine Besprechungen von 10:00 bis 2:00 Uhr oder was auch immer es sein mag, und das wirklich aus einer erfolgreichen Perspektive zu steuern.
Tenille:
Ich denke in diesem Sinne, was macht Ihrer Meinung nach ein wirklich erfolgreiches Agile-Team aus?
Sprecher 17:
Die Fähigkeit, miteinander zu sprechen, diese Fähigkeit zu kommunizieren. Da all unsere Teams entweder hybrid oder remote arbeiten, ist es meiner Meinung nach entscheidend, sicherzustellen, dass wir über die Tools verfügen, mit denen sie das Gefühl haben, jederzeit jemanden abholen und mit ihm sprechen zu können. Und viele Leute haben immer noch keine Kameras, richtig, was mich verwirrt. Aber die Fähigkeit, Gesichtsausdrücke zu sehen, von Angesicht zu Angesicht zu sein, war so schön, weil wir das bekommen können. Das ist also der andere Schlüssel, die Fähigkeit, miteinander zu sprechen, als könnte ich die Hand reichen und dich berühren.
Tenille:
In Ordnung. Fantastisch. Tja, vielen Dank.
Sprecher 17:
Du bist willkommen. Danke.
Tenille:
In Ordnung. Rob und Andrew, vielen Dank, dass Sie sich ein paar Minuten Zeit für uns genommen haben. Kann ich Sie zunächst fragen, was Ihrer Meinung nach das Beste ist, was Sie diese Woche gelernt haben?
Rob:Für mich ist es definitiv die schnelle Skalierung von Agile, von der wir heute Morgen erfahren haben. Wir werden es versuchen.
Andrew:
Mir hat die Mathe-Programmiersitzung sehr viel Spaß gemacht und ich habe verschiedene Möglichkeiten kennengelernt, Ingenieure miteinander zu verbinden und zusammenzuarbeiten.
Tenille:
Großartig. Als Nächstes, schätze ich, was macht Ihrer Meinung nach ein großartiges Agile-Team aus?
Rob:
In erster Linie, dass sie mehr als alles andere die Kontrolle darüber haben, wie sie arbeiten und woran sie arbeiten.
Andrew:
Ja. Für mich ist das natürlich eine psychologische Sicherheit und einfach eine gute Teamdynamik, in der sie unterschiedlicher Meinung sein können, aber trotzdem respektvoll sein und großartige Ideen entwickeln können.
Tenille:
Und gibt es eine Agile-Zeremonie, ohne die ein großartiges Team Ihrer Meinung nach nicht leben kann?
Rob:
Wahrscheinlich rückblickend. Ich denke, die Teams müssen sich ständig verbessern, und das ist ein guter Weg, das zu tun.
Andrew:
Einverstanden. Ja. Ja. Ja.
Tenille:
In Ordnung. Das ist großartig. Vielen Dank, dass du dir die Zeit genommen hast.
Andrew:
Vielen Dank. Ich weiß es zu schätzen.
PodcastEasy 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.
PodcastEasy Agile Podcast Ep.17 Definition eines Produktmanagers: Die Idee eines gemeinsamen Gehirns
In dieser Folge wurde ich von Sherif Mansour, Distinguished Product Manager bei Atlassian, begleitet.
Wir haben über die Stile des Produktmanagements und die Eigenschaften gesprochen, die einen großartigen Produktmanager ausmachen. Bevor wir die Idee eines gemeinsamen Gehirns und die Rolle eines Produktingenieurs erforschten.
Sherif ist seit über 15 Jahren in der Softwareentwicklung tätig. Während seiner Zeit bei Atlassian war er für Confluence verantwortlich, ein beliebtes Tool für die Zusammenarbeit von Inhalten für Teams.
In letzter Zeit verbringt Sherif die meiste Zeit damit, Probleme mit allen Cloud-Produkten von Atlassian zu lösen. Sherif spielte auch eine Schlüsselrolle bei der Entwicklung neuer Produkte wie Stride, Team Calendars und Confluence Questions bei Atlassian. Sherif ist der Meinung, dass es schwierig ist, einfache Produkte zu entwickeln, und das gilt auch für das Schreiben einer einfachen, kurzen Biographie.
Hoffe dir gefällt die Folge genauso gut wie mir. Danke für ein tolles Gespräch, Sherif.