Easy Agile Podcast Folge 3 Melissa Reeve, VP Marketing bei Scaled Agile

„Wir haben ausführlich über agile Skalierung, SAFe-Fellow, Disziplin, die Eigenschaften effektiver Führungskräfte und darüber gesprochen, wie Sie Ihren Mitarbeitern vertrauen können.“

Transkript

Nick Muldoon:

Guten Tag, Leute. Vielen Dank, dass Sie sich uns für einen weiteren Easy Agile Podcast angeschlossen haben. Heute Morgen gesellt sich Em Campbell-Pretty von Pretty Agile zu mir. Em ist eine von 22 SAFe-Fellows weltweit und führt seit über einem Jahrzehnt agile Transformationen in großem Maßstab durch. Sie ist auch Autorin von zwei Büchern, The Art of Avoiding a Train Wreck und Tribal Unity. Also, hier dreht sich alles um Kultur und psychologische Sicherheit, und natürlich alles über die Skalierung agiler Release-Trains, Tipps und Tricks.

Nick Muldoon:

Meine wichtigsten Erkenntnisse, von denen ich wirklich begeistert war, waren die Eigenschaften effektiver Führungskräfte, um agile Transformationen zu skalieren und eine effektive Organisation zu sein, Vertrauen, wie wenn sie ihren Mitarbeitern vertrauen, Offenheit für Lernen und Lernbereitschaft, die Fähigkeit zu experimentieren und Dinge als Misserfolge zu behandeln, wenn sie Misserfolge sind, und Disziplin. Em und ich haben heute ein wenig über Disziplin als Merkmal von Führungskräften gesprochen. Es ist eine wirklich großartige Folge und ich habe viel daraus mitgenommen. Am Ende werdet ihr meine Erkenntnisse hören und was ich nach einiger Zeit mit Em heute Morgen lernen muss. Also, lass uns anfangen. Wie viele Wochen im Jahr sind Sie normalerweise unterwegs?

In Campbell-Pretty:

Wie viele Wochen im Jahr bin ich normalerweise unterwegs? Sehr viel, die meisten. Es wäre ungewöhnlich für mich, vier Wochen zu verbringen, ohne irgendwohin zu gehen. Das wäre ungewöhnlich. Ich reise nicht jede Woche, aber ich reise die meisten Wochen, und ich reise in großen Blöcken. Richtig? Also, ich gehe und mache... Wie ich schon sagte, kurz vor dem Lockdown waren wir drei Wochen in Auckland, das war also im Februar-März.

In Campbell-Pretty:

Wir sind nach Auckland gefahren, wir hatten einen Kunden in Auckland, wir sind einfach dort geblieben. Also, drei Wochen in Auckland, bin wieder hierher gekommen und nicht nach Auckland zurückgekehrt. Ich kehrte zurück, um diesen Kunden virtuell über Teams zu unterstützen, und Zoom war die Art und Weise, wie das lief. Aber ja. Normalerweise zwischen dem Herumlaufen in Australien, Südostasien, Hongkong, Singapur, Manila, den USA, Neuseeland, ja, normalerweise nicht so oft nach Hause. Das war wirklich skurril.

Nick Muldoon:

Das ist also ein sehr ungewöhnliches Jahr für jemanden wie Sie, der herumfliegt und Kunden auf der ganzen Welt besucht.

In Campbell-Pretty:

Absolut. Absolut. Es war ein sehr seltsames Jahr. Es ist auch ein interessanter Unterschied in Bezug auf die Energie. Nicht die ganze Zeit zu fliegen, denke ich, ist gut für meinen Körper. Ich spüre den Unterschied. Ich spüre auch den Unterschied, wenn ich die ganze Zeit auf einem Stuhl sitze. Also, ich war viel unterwegs, aber an den meisten Tagen, an denen ich arbeitete, war ich auf den Beinen. Wenn ich jetzt arbeite, sitze ich viel.

Nick Muldoon:

Du setzt dich hin. Ja.

In Campbell-Pretty:

Also, das ist interessant. Aber ich vermisse den Jetlag überhaupt nicht. Ich vermisse überhaupt nicht, wie viel Zeit die Reise in Anspruch nimmt. In der Tat war es nett. Ich hatte ein bisschen Freiraum. Ich habe dieses Jahr wahrscheinlich mehr gebloggt als in ein paar Jahren, weil ich einfach etwas Freiraum hatte und nachdenken konnte. Aber ich sehe die Welt auch nicht und alle meine Ferien wurden abgesagt. Also, vergiss die Arbeit. Ich hatte Reisen nach Europa. In vier Wochen sollte ich in Kanada sein und Eisbären sehen.

Nick Muldoon:

Oh.

In Campbell-Pretty:

Erzähl mir davon!

Nick Muldoon:

Ich würde gerne Eisbären sehen. Sie sehen im Fernsehen so kuschelig aus. Ich bin mir nicht sicher, ob das tatsächlich der Fall wäre, wenn ich versuchen würde, auf einen zuzugehen und ihn zu kuscheln.

In Campbell-Pretty:

Ja. Ich glaube nicht, dass Kuscheln im Spiel war. Mir wurde gesagt, ich könne eine Kamera und ein Stativ mitbringen, was natürlich bedeutet, dass ich in einiger Entfernung von diesem Eisbären stehen und Fotos machen werde. Aber das wird auch nicht passieren. Also, keine Ferien und keine Reisen zur Arbeit, und da wir in Melbourne sind, nicht einmal dort, gehen wir einfach zu [Crosstalk 00:04:15].

Nick Muldoon:

Kaffee oder so.

In Campbell-Pretty:

Einfach nichts.

Nick Muldoon:

Nichts.

In Campbell-Pretty:

Nichts.

Nick Muldoon:

Ja, weil du einen legitimen Lockdown hattest.

In Campbell-Pretty:

Jep.

Nick Muldoon:

Erzählen Sie mir dann von der Veränderung dieser skalierten, agilen Transformationen in den letzten 10 oder 15 Jahren. Offensichtlich muss heute, wie Sie es mit diesem Kunden in Auckland beschrieben haben, alles remote ablaufen. Vermutlich nicht so effektiv. Aber ich würde gerne ein Gefühl dafür bekommen, wie sich die Entwicklung von den Veränderungen vor 10 Jahren, Bankwesen, Telekommunikationsunternehmen, diese Art von Umfeld bis hin zu den Kunden, mit denen Sie heute zusammenarbeiten, entwickelt hat. Beschreiben Sie, wie es vor 10 Jahren war.

In Campbell-Pretty:

Also, vor 10 Jahren, und es ist so interessant, jetzt darüber nachzudenken, habe ich Scaling Software Agility gelesen, ein Buch, das Dean 2007 veröffentlicht hat. Dann stellte ich fest, dass das nicht das neueste Buch war, also las ich Agile Software Requirements. Das war 2011. Ich bin dieser verrückte, wütende Firmensponsor mit diesem Arbeitsprogramm, das ich seit fünf Jahren sponsere und das nie etwas gebracht hat, und in diesem Auto...

Nick Muldoon:

Du warst der verrückte, wütende Unternehmenssponsor?

In Campbell-Pretty:

Ja. Ja, ja. Ich war der Verrückte [unhörbar 00:05:26]. Ich war sehr wütend. Du wärst auch wütend, wenn du ich wärst. Ich nenne es jetzt das Geldfeuer. Also, im Grunde ist das mein Job. Richtig? Geh zum CFO, frag nach Geld. Gib das Geld der IT. ES zündet ein Streichholz an, zündet es an. Kommt zurück und bittet mich um Geld. Ich kann zurück zum CFO gehen und sagen, dass ich mehr Geld brauche. Fünf Jahre. Fünf Jahre. Mehr habe ich nicht getan. Bitten Sie um Geld und versuchen Sie zu erklären, wohin das andere Geld gegangen ist.

In Campbell-Pretty:

Wie dem auch sei, bei der seltsamsten Umstrukturierung aller Zeiten werde ich Technologie-GM für dieselbe Gruppe, deren Unternehmenssponsor ich in den letzten fünf Jahren war. Offenbar konnten sie niemanden finden, der entsprechend qualifiziert war. Also, du schaffst es, Em. Sicher. Also, ich bin ein bisschen ein Computerfreak, also lese ich Bücher und ich lese diese Bücher von Leffingwell, weil ich einige agile Übungen gemacht habe... Also, ich habe etwas gemacht, das ich Agilität genannt hatte. Lass uns einfach damit weitermachen.

In Campbell-Pretty:

Es war interessant für mich, weil ich kleine Lichtstrahlen sehen konnte. Aber es hat immer noch nicht wirklich etwas bewirkt, daher die Lektüre. In diesen Büchern geht es um diesen agilen Release Train [unhörbar 00:06:46], der cool klingt. Wir sollten das Ding also machen. Also machte ich mich Anfang 2012 daran, diesen Zug bei einer Telstra zu starten. Es hieß nicht SAFe, oder? Es waren nur die Bücher und diese Dinge, die man einen agilen Release-Train nennt.

In Campbell-Pretty:

Nun, um vor 10 Jahren zurückzublicken, es hieß nicht SAFe. Die Leute rannten dabei nicht herum. Ich war eigentlich nicht wirklich qualifiziert für den Job, den ich ausübte. Nun, ich war beim besten Willen kein Technologieführer, und ich beschließe, dass ich einfach einen agilen Release Train auf den Markt bringen werde. Es gab also seltene und ungewöhnliche Bestien, und ich bin mir nicht sicher, ob ich das wirklich verstanden habe, als ich den Weg eingeschlagen habe.

In Campbell-Pretty:

Ich bin ein großer Fan davon, ich habe es in einem Buch gelesen, ich habe es in einem Blog gelesen, ich habe es auf einer Konferenz gehört, ich werde es einfach ausprobieren. Das war schon immer mein mentales Modell. Also habe ich es in einem Buch gelesen und es einfach ausprobiert. Dann stellen wir fest, dass das buchstäblich niemand tut, und so wird es Australiens erster agiler Release-Train und Australiens erste SAFe-Implementierung. Oh Mann, habe ich seitdem viel gelernt.

Nick Muldoon:

Nun ja. Darüber habe ich nachgedacht, weil ich die Kunst, einen Eisenbahnunfall zu vermeiden, ausgegraben habe, richtig? Das ist einer von denen, die du für Tegan unterschrieben hast. Aber offensichtlich haben Sie seitdem eine Menge gelernt, weil Sie es geschafft haben, eine Reihe von Tipps und Tricks und Dingen zusammenzustellen, die Sie vermeiden sollten, wenn Sie diese Transformationen verfolgen. Als Branche, nun ja, als Branche, denke ich, dass das viele Branchen umfasst, aber werden wir heutzutage in der Praxis tatsächlich besser bei diesen Transformationen? Gibt es heute Unternehmen da draußen, Em, die immer noch haufenweise Geld nehmen und es in Brand stecken?

In Campbell-Pretty:

Also, ich glaube, ich treffe jeden Tag Leute, die meine Geschichte hören und sagen: „Oh mein Gott. Du hast mal hier gearbeitet?“ Also, ich denke, es gibt immer noch viele, viele Organisationen, die eine Erfahrung haben, die der Erfahrung ähnelt, die ich 2010 gemacht habe, und was haben Sie? Es scheint also etwas zu sein, das bei den Menschen wirklich Anklang findet. Ich schätze, viele der Unternehmen, in die wir jetzt gehen, sind entweder überhaupt nicht agil oder, ich glaube, wie in meiner Welt, tun sie etwas, das sie agil nennen. Was wir finden, ist das, was sie agil nennen. Ich würde nicht sagen, dass es nicht agil ist. Aber es lässt viel zu wünschen übrig.

Nick Muldoon:

Sie sind auf einer Reise, oder?

In Campbell-Pretty:

Ja. Ja. Ja, ich denke schon, weil sie am Ende ein Gespräch mit uns führen. Sie verstehen also, dass das, was sie tun, nicht genug ist. Sie verstehen, dass das, was sie tun, ihnen nicht die gewünschten Ergebnisse bringt. Ich weiß nicht, ob sie verstehen warum. Es ist manchmal interessant für mich, dass sie nach SAFe suchen, weil Sie mich gefragt haben, wie sich der Kundenstamm verändert hat? Eines der Dinge, die in Australien wirklich interessant sind, ist, dass wir heute viel mehr kleine bis mittlere Unternehmen haben als große.

In Campbell-Pretty:

Es sind also Unternehmen, die sich für agil halten. Aber wie wir sie nennen, die Startups, die keine Startups mehr sind, oder? Dies sind Organisationen, bei denen es sich in der Regel um 10, 20 Jahre alte Startups handelt, die skalieren und ihr Problem als Skalierungsproblem betrachten. Das ist es also, was sie zu einem Gespräch über das skalierte agile Framework führt.

In Campbell-Pretty:

Wenn wir sie durch eine SAFe-Linse betrachten, sagen wir: „Mensch, du bist winzig. Aber okay. Ich kann mir vorstellen, dass du einen agilen Release-Train haben kannst und es wird dir nicht schaden. Tatsächlich würde es Ihnen wahrscheinlich sehr helfen, wenn es um die Planung im mittleren Bereich geht. „Da Mittelfristplanung für viele dieser Organisationen einfach nicht zu existieren scheint. Priorisierung. Viele dieser kleinen Organisationen sind sehr reflexartig, was die Art und Weise angeht, wie sie Prioritäten setzen, und springen von einer Sache zur anderen.

Nick Muldoon:

Reagieren sie auf den Markt oder reagieren sie auf die Marktführer, vielleicht auf den Mangel an Disziplin in der Führung?

In Campbell-Pretty:

Wissen Sie was? Sie würden sagen, sie reagieren auf den Markt. Ich würde sagen, sie haben ein Disziplinproblem.

Nick Muldoon:

Ja. [Crosstalk 00:11:23].

In Campbell-Pretty:

Also, ich habe natürlich gelesen, großer Leser, letzten Sommer, offensichtlich im australischen Sommer, im amerikanischen Winter, habe ich Melissa Perrys The Build Trap gelesen. Interessantes Buch und Ihr angesehener Vordenker im Produktmanagement. Kein großer Fan von SAFe. Wahrscheinlich auch kein großer Fan von Agile war das, was ich aus ihrem Buch mitgenommen habe. Aber die Sache, über die sie spricht und die ich wirklich für wertvoll hielt, war der Wahnsinn, Ihre Konkurrenten zu verfolgen. Also, Funktionen entwickeln, weil Ihre Konkurrenten...

Nick Muldoon:

Ihre Konkurrenten [Crosstalk 00:12:06].

In Campbell-Pretty:

... sie bauen oder Features bauen, um einen Auftrag zu bekommen oder einen Kunden an sich zu binden. Also, ich dachte, sie hält das alles für Wahnsinn, und ich stimme dem eher zu. Also, das war mein... Das finde ich ziemlich interessant. Aus ihrer Sicht weiß man nicht, ob der Konkurrent mit dem Ding, das er gebaut hat, tatsächlich Glück hat. Wenn Sie es also bauen, weil sie es gebaut haben, wissen Sie es nicht. Du hast keine Ahnung. Also, baue es nicht einfach, weil sie es gebaut haben. Es tut ihnen vielleicht auch keinen Gefallen.

In Campbell-Pretty:

Sobald Sie anfangen, nur zufällige Dinge für diesen großen Kunden oder diesen großen Kunden zu tun, verlieren Sie natürlich als Organisation den Überblick. Am Ende haben die Leute völlig unterschiedliche Versionen ihrer Produkte, Branchen, die sie nicht mehr integrieren können. Das ist interessant. Wenn ich mir das ansehe, denke ich: „Ich habe das Gefühl, dass es in einigen dieser Organisationen auf Führungsebene ein Disziplinproblem gibt.“

In Campbell-Pretty:

Was versuchen wir zu tun? Was ist unsere Vision? Was ist unsere Mission? Was ist unser Markt? Was tun wir, um auf diesem Markt zu testen und zu lernen, anstatt uns einfach eine Waffe zu besorgen, alles zu tun, uns alles zu schnappen? Oh, meine Güte. Das haben sie da drüben gemacht. Hör auf damit, fang damit an, hör auf damit. Wenn Sie die ganze Zeit anhalten und anfangen, liefern Sie natürlich nichts, und das scheint etwas zu sein, was wir bei diesen Organisationen häufig beobachten. Sie liefern nicht.

In Campbell-Pretty:

Ich sage nicht, dass ihr Liefermechanismus perfekt ist. Da gibt es auch Herausforderungen. Aber ein Teil des Problems ist die Unfähigkeit, einen Kurs beizubehalten. Wähle einen Kurs und bleibe bei einem Kurs. Ich sage nicht, dass du nicht umschwenken sollst, denn das ist auch dämlich. Aber vielleicht überlegter bei deinen Pivot-Entscheidungen zu sein. Ja.

Nick Muldoon:

Haben Sie das Gefühl, Em, dass es Führungsteams in verschiedenen geografischen Regionen gibt, die bei dieser und bei der langfristigen Planung effektiver sind und über diese Disziplin und diesen methodischen Ansatz für die Umsetzung über einen längeren Zeitraum verfügen?

In Campbell-Pretty:

Ich denke, Regionen, Kulturen und Nationalitäten spielen sicherlich eine Rolle bei der Führung, ich weiß nicht, der Person, der Persönlichkeit. Ich weiß nicht, ob ich sagen könnte, wenn ich in diesem Land oder in diesem Teil der Welt gearbeitet habe, dass ihre Führungskräfte besser darin sind, vorausschauend zu denken. Ich denke, einige Kulturen eignen sich besser für Lean und Agile als andere. Hierarchische Kulturen sind wirklich, wirklich herausfordernd.

In Campbell-Pretty:

Das kann sowohl eine geografische Sache sein, als auch einfach eine Branchenangelegenheit, oder? Die Regierung kann also sehr hierarchisch sein. Die Banken können sehr hierarchisch sein. Einige der asiatischen Kulturen sind sehr hierarchisch. Aber einige Unternehmen sind auch einfach sehr hierarchisch. Also, wem das Unternehmen gehört, wer das Unternehmen leitet, all das kann eine große Rolle dabei spielen, was akzeptabel ist, weil ein Großteil des Erfolgs auf dieser skalierten agilen Reise von einer Führung abhängt, die bereit ist, den Teams zu vertrauen, einer Führung, die bereit ist zu lernen, einer Führung, die bereit ist, zu experimentieren, und einer Führung, die bereit ist, diszipliniert zu sein.

Nick Muldoon:

Also Führung mit Vertrauen in die Teams, lernbereit, experimentierfreudig und diszipliniert. Das sind diese vier Dinge, die du...

In Campbell-Pretty:

Jep.

Nick Muldoon:

Ja, okay. Ja. Ich notiere mir die, Em. Ich werde auf die zurückkommen. Vertraue, lerne, experimentiere und diszipliniere. Ich schätze, dieses Jahr ist ein sehr interessantes, ein sehr einzigartiges Jahr für Transformationsarbeit, Coaching und Beratung aus der Ferne. Wie hoch war der Prozentsatz der Teammitglieder, die an verschiedenen Standorten arbeiten, vor 10 Jahren? Im Grunde genommen glaube ich, dass die großen Banken in Australien erst 2021 wieder ins Büro zurückkehren werden. Atlassian geht erst 2021 zurück ins Büro. Auf Twitter sagte Jack Dorsey, mein alter CEO, so etwas wie „Für immer von zu Hause aus arbeiten“. Was ist das Fazit für dieses Jahr und was erwartest du für 2021 und darüber hinaus?

In Campbell-Pretty:

Also, sieh mal. Dieses Jahr hat mir die Augen geöffnet, und schauen Sie, einige Dinge sind, wie ich erwartet hatte, einige Dinge waren anders. Es ist also offensichtlich, dass ganze Organisationen online gehen. Wir sehen, dass die Teams online sind, die PI-Planung online ist, alles ist online. Das hat in gewisser Weise tatsächlich neue Möglichkeiten eröffnet. Also, wo wir Kunden hatten, die in Bezug auf den Vertrieb die seltsamsten Einstellungen hatten, und man kann einen Zug zum Laufen bringen, bei dem Teams an zwei Standorten verteilt sind. Aber wir sind große Fans davon, dass das gesamte Team in Sydney ist oder das gesamte Team in Indien ist. Wir haben nicht die Hälfte der Mannschaft in Sydney und die Hälfte der Mannschaft in Indien.

In Campbell-Pretty:

Aber Organisationen haben wirklich damit zu kämpfen, weil vielleicht alle Tester in Indien sind und dann willst du einen Tester in jedem Team haben und jetzt hast du ein Problem. Wie stellt man ein komplettes Team zusammen, ohne die Zeitzonen zu überschreiten? Wenn ich also Teams finde, die nicht physisch am selben Standort, sondern zeitzonenfreundlich sind, habe ich eine etwas größere Auswahl. Ich kann also einen Zug nehmen, der zwischen, ich weiß nicht, Sydney und Indien verkehrt. Oder ich kann feststellen, dass sich ihr Tag um vier Stunden überschneidet, und ich kann darauf bestehen, dass das Team zu 100% online arbeitet.

In Campbell-Pretty:

Das Wichtigste, von dem wir abraten würden, ist, dass ich diesen Team-Hybrid nicht will. Richtig? Ich will nicht, dass drei Leute in Sydney im Büro sitzen und drei Leute in ihren Häusern in Indien. Ich will, dass alle online sind. Ich will gleiche Wettbewerbsbedingungen, und ich denke, das können wir jetzt auf eine Weise tun, die akzeptabler ist als zuvor. Weil der gleiche Rat, den ich gegeben habe, Mann, damals, als ich Tribal Unity geschrieben habe, derselbe Rat. Richtig?

In Campbell-Pretty:

Also, 2016, alle, gleiche Wettbewerbsbedingungen. Wenn Sie verteilt werden wollen, müssen alle online sein, im Gegensatz zu einigen Leuten online und einigen Leuten in einem Raum. Das ist jetzt also eine akzeptablere Antwort als vor diesem Jahr. Also, das ist gut. Das finde ich gut.

Nick Muldoon:

2021, Em, meinst du, das wird sich einfach vorwärts abspielen. Ich schätze, es wird eine Rückkehr einiger dieser Unternehmen ins Büro geben, weil sie bereits über riesige Immobilien und Arbeitsplatzinfrastruktur verfügen.

In Campbell-Pretty:

Ja. Ja, schau mal. Wir sehen, wie Kunden Büros schließen, genauso wie Sie es bei einigen Unternehmen in den USA sehen. Wir beobachten auch, dass Teile Australiens und Neuseelands, die derzeit keine besonderen Auswirkungen von COVID haben, tatsächlich zurück ins Büro gehen und das Beispiel von Teams geschaffen haben, die Zeitzonen überqueren und dann zurück ins Büro gehen und in diesen hybriden Raum zurückkehren. Also, das ist interessant und [Crosstalk 00:20:08].

Nick Muldoon:

Also, wo Sie wieder in dieser Umgebung sind, in der vielleicht einige Leute in einem Büro zusammenarbeiten, die zusammen eine Tasse Kaffee trinken können, und dann einige, die immer noch zu Hause festsitzen. Ich schätze, es gibt nicht einmal regionale Unterschiede, oder? Wenn Sie ein Teammitglied haben, das eine bestimmte gesundheitliche Situation hat, wird es sich nicht wohl fühlen, wenn es unbedingt wieder ins Büro kommt, unabhängig von der Situation, bis es einen Impfstoff oder so gibt.

In Campbell-Pretty:

Absolut.

Nick Muldoon:

Ja, okay.

In Campbell-Pretty:

Also, ja. Also, ich denke, es wird interessant. Ich würde mich nachdrücklich dafür einsetzen, dass Organisationen Teams haben, die entweder aus persönlichen Teams oder aus Online-Teams bestehen, und das Team arbeitet entweder zu 100% online oder das Team arbeitet zu 100% -

Nick Muldoon:

Im Büro.

In Campbell-Pretty:

... persönlich und im Büro, und wenn Sie einen Zug haben, der bei einer Zeremonie auf Bahnebene beides hat, gehen alle an einen Schreibtisch und...

Nick Muldoon:

Und mach es online.

In Campbell-Pretty:

... eine Videokamera und wir machen das so. Ich denke, die Sache, die an der physischen Umgebung und SAFe am schwierigsten zu sein scheint, ist die PI-Planung. Niemand muss schlagen. Richtig? Das war cool. Niemand muss zuschlagen, niemand hat seine PI-Planung durcheinander gebracht, alle sind einfach gegangen. Sie waren alle online. Also, wir planen einfach online. Es wird in Ordnung sein. Wir haben gesehen, wie die Leute jede Infrastruktur nutzten, die ihnen zur Verfügung stand.

Nick Muldoon:

Ja. [Crosstalk 00:21:30].

In Campbell-Pretty:

Also, ich bin mir sicher, dass eine Reihe von Leuten euch angerufen haben und gesagt haben: „Wir brauchen ein Tool.“ Aber einige meinten einfach: „Wir haben Google Suite, wir haben Microsoft, was auch immer es ist, wir haben dies, wir haben das. Wir sorgen einfach dafür, dass es funktioniert. „Und egal, was sie verwendet haben, sie haben dafür gesorgt, dass es funktioniert und sie haben die Veranstaltungen veranstaltet und ihre Veranstaltungen waren effektiv und sie haben die Ergebnisse erzielt. Das Wichtigste, was fehlt, ist diese Energie. Die Energie von 100, 200 Personen in einem Raum kann man nicht aus einer Online-Veranstaltung herausholen. Aber mechanisch...

Nick Muldoon:

Wir können es erreichen.

In Campbell-Pretty:

... wir können es erreichen. Wir hören also, dass jeder wieder persönlich zur PI-Planung zurückkehren möchte, wegen der sozialen Kontakte, wegen der Energie, was ich großartig finde. Ich finde das absolut großartig, und ich kann mir diese Welt vorstellen, in der die Leute viel mehr von zu Hause aus arbeiten, remote arbeiten, wie auch immer das aussieht, und dann sind die PI-Planungsveranstaltungen die Dinge, die wir tun, um uns zusammenzubringen und in diesen acht, 10, 12 Wochen wieder Kontakte zu knüpfen. Das ist mein Gefühl. Das könnte falsch sein.

Nick Muldoon:

Ich schätze, ich werde wirklich gespannt sein, wie sich das entwickelt, und ich denke, wir sollten in 12 Monaten zu diesem Gespräch zurückkehren, Em.

In Campbell-Pretty:

Ja. Oh, nein.

Nick Muldoon:

Ich denke nur, was mir durch den Kopf geht, ist einer unserer Kunden in New York, ein Finanzdienstleistungsunternehmen, und für eine ihrer Künste waren es 150.000 US-Dollar, die trainiert wurden, um ihre Leute einmal im Quartal zusammenzubringen.

In Campbell-Pretty:

Ja. Beeindruckend.

Nick Muldoon:

Ich sage jetzt, ich sage: „Okay, ja, sie machen das jetzt digital.“ Das ist in Ordnung. Sie werden Dinge verpassen. Aber wenn sie das Budget verlieren, müssen sie dann kämpfen, um das Budget zurückzubekommen? Oder ist das Budget da? Es gibt noch diese anderen unbekannten Auswirkungen dieses Wandels im Laufe des Jahres 2020, die wir wohl erst noch erleben werden.

In Campbell-Pretty:

Ich denke, Sie haben Recht, und ich denke, es wäre besonders interessant für die Züge, die aus der Ferne gestartet wurden. Also, wenn der Zug aus der Ferne gestartet wurde, können Sie

Nick Muldoon:

Also keine existierenden Züge, die seit sechs bis 12, 18 Monaten zusammenarbeiten. Aber du willst einen brandneuen Zug starten lassen. Haben Sie das dieses Jahr mit einigen Ihrer Kunden aus der Ferne gemacht?

In Campbell-Pretty:

Oh, wir sind gerade dabei, das zu tun.

Nick Muldoon:

Cool. Sag es mir.

In Campbell-Pretty:

Wir hatten jedoch buchstäblich kurz vor dem Lockdown einen. Also haben sie ihre erste PI-Planung von Angesicht zu Angesicht gemacht und sind dann sofort zur Telearbeit übergegangen und, ja, jetzt arbeiten sie daran, einen Zug aus der Ferne zu starten. Für uns haben wir ein Playbook. Es ist ein Haufen Workshops. Es ist ein Haufen Unterricht. Wir verwenden nur Tools für die Online-Zusammenarbeit. Wir haben Dinge gefunden, die die Art von Tools nachahmen, die wir in einem physischen Raum hätten, und die Freude, die Haftnotizen der Leute lesen zu können, oder? Das war für mich der absolute Höhepunkt, die Freude, die Post-it-Zettel der Leute lesen zu können.

Nick Muldoon:

Keine Hieroglyphen mehr.

In Campbell-Pretty:

Ja. Ja, absolut.

Nick Muldoon:

Was hast du geschrieben, Sally? Ja.

In Campbell-Pretty:

Jeder kann alles auf einmal sagen, oder? Du denkst also an das Klassenzimmer und den Workshop, wo eine Gruppe von Leuten um Post-its und ein Flipchart-Papier zusammengekauert ist und sie immer noch irgendwie in ihrem virtuellen Gedränge zusammengekauert sind, aber jeder kann lesen, oder? Es ist nicht so, dass ich nicht nah genug bin, ich kann nicht lesen, ich kann deine Handschrift nicht lesen. Es gibt diesen großartigen Equalizer in der Online-Welt. Also, ich finde das großartig. Ich denke, die Herausforderung bei den Zügen, die aus der Ferne gestartet werden, wird darin bestehen, jemals die Erfahrung von Angesicht zu Angesicht zu machen?

In Campbell-Pretty:

Denn wenn ich die Jahre zurückblicke, wissen wir unter anderem, dass Ihre erste PI-Planungsveranstaltung Maßstäbe setzt. Die Leute bekommen also in ihren Köpfen einen Eindruck davon, was möglich ist. Wenn du zum Beispiel bei deiner ersten PI-Planungsveranstaltung etwas überspringst, entscheidest du einfach, ich weiß nicht, die Vertrauensabstimmung oder etwas Seltsames in der Art zu überspringen, du gehst den Risiken nicht nach oder du überspringst einfach etwas, du tust es nie, weil du ohne es erfolgreich bist.

Nick Muldoon:

Es wird nie abgeholt. Ja, okay.

In Campbell-Pretty:

Ohne es bist du erfolgreich. Also, jeder Kompromiss, den Sie eingehen, und Sie gehen eine Reihe von Kompromissen ein, und dann sind Sie trotz dieser Kompromisse erfolgreich, und das wird zu einer falsch positiven Machbarkeit. Es sagt dir, ja, ich hatte recht. Ich hatte recht.

Nick Muldoon:

Das muss ich nicht tun.

In Campbell-Pretty:

Ich musste diese Dinge nicht tun, weil ich unglaublich erfolgreich war und ich diese Dinge nicht getan habe. Also, es ist das Lernen [Crosstalk 00:26:15] -

Nick Muldoon:

Das ist Bestätigungsfehler, oder?

In Campbell-Pretty:

Ja, das ist es. Ja, das ist der eine. Voreingenommenheit bei der Bestätigung. Genau das ist es. Jep. Ja, und ich denke, es wird eine Menge Bestätigungsfehler bei diesen ferngesteuerten Zügen geben, und es sei denn, sie befinden sich in Organisationen, in denen genügend Wissen über SAFe und die physische PI-Planung vorhanden ist, um zu wissen, dass es sinnvoll sein wird, sie zusammenzubringen, aber ich kann mir vorstellen, dass das eine echte Herausforderung ist. Ich denke, Züge, die online gestartet werden, werden aufgrund dieser Bestätigungsverzerrung möglicherweise nie in eine physische PI-Planungsveranstaltung aufgenommen.

Nick Muldoon:

In Ordnung.

In Campbell-Pretty:

Das macht mich wirklich traurig.

Nick Muldoon:

Ich möchte auf etwas zurückkommen, das Sie zuvor über die Führungskräfte gesagt haben, und Sie haben das Vertrauen, die Offenheit für Lernen und Experimentieren und die Disziplin erwähnt. Ich habe noch einmal Ihren Vortrag von SAFe Global 2018 über die sieben Eigenschaften hochwirksamer dienender Führungskräfte durchgesehen.

In Campbell-Pretty:

Jep.

Nick Muldoon:

Ja?

In Campbell-Pretty:

Jep.

Nick Muldoon:

Ich glaube, ich hatte einige Fragen dazu, und offensichtlich sind dies vier der Merkmale. Was sind die anderen drei Eigenschaften, die mir fehlen? Dann habe ich eine weitere Frage zu einigen der tatsächlichen Dinge, über die Sie gesprochen haben und die Sie auf Ihrer Reise entdeckt haben.

In Campbell-Pretty:

[unhörbar 00:27:29] einer der vier auf der Liste, die ich 2018 hatte.

Nick Muldoon:

Ich werde dich dazu befragen.

In Campbell-Pretty:

Wie peinlich. 2018 lautete die Antwort also: zuerst der Mensch, Respekt vor den Menschen, diese Art von Linse, schlankes Denken, Manager, Lehrer, Lernender. Also, den hatten wir. Ja. Lernender. [unhörbar 00:28:00] verrückt. Was hatte ich noch? [unhörbar 00:28:10].

Nick Muldoon:

Ja. Okay. Eigentlich wollte ich darüber sprechen. Darüber habe ich mir eine Notiz gemacht. Was ist das, und gibt es Beispiele dafür im Westen?

In Campbell-Pretty:

Viele Leute sprechen über True North.

Nick Muldoon:

[unhörbar 00:28:28]. Wahrer Norden.

In Campbell-Pretty:

Ja. Wahrer Norden. Die Übersetzung, die ich bekommen habe, habe ich von Herrn [unverständlich 00:28:39] bekommen, der mit Katie Anderson für die Lean-Studienreise zusammengearbeitet hat, die ich in, ich weiß nicht, '18, '17, '18, 2018 gemacht habe, glaube ich, also die Übersetzung, die er gab, war Richtung und Management. Es ist also Mission, oder? Es ist eine strategische Mission. Es ist so etwas.

Nick Muldoon:

Also, nur eine Randleiste für alle, die Ems Vortrag dazu nicht gesehen haben, da ist eine Frau namens Katie Anderson. Sie veranstaltet ein Jahrbuch, ich glaube, nicht dieses Jahr, aber sie veranstaltet ein jährliches...

In Campbell-Pretty:

Nein, dieses Jahr nicht. Sie ist dieses Jahr nicht gegangen.

Nick Muldoon:

... nicht dieses Jahr, veranstaltet eine jährliche Lean-, Kanban- und Kaizen-Studientour nach Japan und besucht... Wen hast du besucht, Em? Du warst bei Katie. Wie viele waren in der Crew, mit der du dort hingegangen bist?

In Campbell-Pretty:

Also, ich glaube, es war eine Gruppe von etwa 20 Personen aus dem Gedächtnis. Katie lebte zwei Jahre in Japan und kehrte dann in die USA zurück. Ich glaube, sie lebt in San Francisco. Während sie dort war, gefiel ihr die Idee, diese schlanken Studienreisen zusammenzustellen, sehr gut. Sie war bereits eine Lean-Praktikerin, die eher im Gesundheitswesen tätig war. Also hatte sie die Gelegenheit... Wir waren tatsächlich auf einer Testlauftour.

Nick Muldoon:

Oh, cool.

In Campbell-Pretty:

Also, das war ihr Experiment. Sie hatte eine Beziehung mit der Ohio State University und sie haben einige Leute an einen Tisch gebracht und sie hat einige Leute an einen Tisch gebracht und sie haben es geschafft. Sie hatte auch eine bestehende Beziehung zu Herrn [unverständlich 00:30:24], dem ersten Manager von John [unhörbar 00:30:26] bei Toyota. Er ist also ein 40-jähriger Toyota-Veteran.

Nick Muldoon:

Veteran.

In Campbell-Pretty:

Er ist für die Woche mit uns gekommen. Also sind wir natürlich zu Toyota gegangen, aber wir sind auch zu einer Reihe von Toyota-Lieferanten gegangen. Isuzu, [unhörbar 00:30:43]. Dann gingen wir auch zur Japan Post, was faszinierend war. Wir gingen in eine Stadt, deren Name mir gerade entgeht, aber sie nannten sie 5S City, weil alle Unternehmen in dieser Stadt das 5S, das herstellende 5S, praktizieren.

Nick Muldoon:

Erzähl mir davon. Es kommt mir nicht in den Sinn. Ich fühle mich nicht wohl oder vertraut.

In Campbell-Pretty:

Fühlst du dich nicht gut mit 5S?

Nick Muldoon:

Nein.

In Campbell-Pretty:

Nein. Das ist nicht gut. Also, wie würde ich... Das 5S besteht aus fünf japanischen Wörtern, auf die ich noch eingehen werde... Ja. Mein Japanisch, nichts. Aber es geht um standardisiertes Arbeiten. Wenn Sie zum Beispiel die 5S-Fabriken betreten, werden Sie sehen, dass die Stockwerke markiert sind, an denen Sie stehen müssen, um eine bestimmte Arbeit zu erledigen.

Nick Muldoon:

[Crosstalk 00:31:41] Das hat Paul Aikas für sein-

In Campbell-Pretty:

Oh nein.

Nick Muldoon:

Ich habe das Gefühl, dass ich die Videos von Paul Aikas über ihre Herstellung in den USA gesehen habe, in denen alles markiert ist.

In Campbell-Pretty:

Ja.

Nick Muldoon:

In Ordnung.

In Campbell-Pretty:

Wahrscheinlich. Das wäre meine Vermutung. Das sollten wir Teddy fragen.

Nick Muldoon:

Wir können Paul fragen, und wir können all diese Leute fragen. Wir haben Zeit.

In Campbell-Pretty:

Nun ja.

Nick Muldoon:

In Ordnung.

In Campbell-Pretty:

In Ordnung.

Nick Muldoon:

Also, diese schlanke Tour, die Japan-Studienreise, war eine super effektive und motivierende Sache für dich?

In Campbell-Pretty:

Ja. Für mich war es sehr verstärkend. Ich hatte also meine eigene Vorstellung davon, was Lean Leadership bedeutet, und ich fand, dass diese spezielle Tour das Wertekanon sehr stark verstärkte, was meiner Meinung nach Teil davon ist. Katie [unhörbar 00:32:43] hat [unhörbar 00:32:44] das entworfen wurde, um Ihnen das zu zeigen. Sie sagt also oft sehr deutlich, dass das nicht Japan ist, oder? Das ist keine Reorganisation nach Japan. Das ist nicht jeder Führer in Japan.

In Campbell-Pretty:

Das heißt, ich habe eine Reihe von Lean-Leadern ausgewählt, um Ihnen zu zeigen, wie es praktiziert wird. Aber es hat mich auf jeden Fall sehr gestärkt. In den Botschaften, die sie überbrachte, waren also sehr ähnliche Botschaften enthalten, was die Art und Weise angeht, wie ich andere zum Führen coache. Also, es war sehr cool. Es war sehr cool. Einige dieser Anführer, einfach so inspirierend, besonders Kaizen. Ich denke, das, was dir wirklich ins Gesicht trifft, wenn du mit diesen Leuten sprichst, ist Kaizen, dieser Drang, besser zu werden.

Nick Muldoon:

Die ganze Zeit.

In Campbell-Pretty:

Die ganze Zeit. Absolut. Diese Leute suchen, sie suchen nach der einen Sekunde, richtig?

Nick Muldoon:

Ja.

In Campbell-Pretty:

Die Verbesserungen von einer Sekunde. Es gibt ein Video, das herumschwirrt. Hast du das Formel-1-Video gesehen-

Nick Muldoon:

Ja.

In Campbell-Pretty:

... wo sie machen, ja, die Umstellung in 63 und sie brauchen über eine Minute und sie machen die Umstellung in etwa 90 in Melbourne und es dauert sechs Sekunden oder was auch immer es ist. Es ist so, richtig? So, wie finde ich eine weitere Sekunde, eine halbe Sekunde? Sie sind einfach so motiviert. Wenn ich einen Schritt, den jemand machen muss, entfernen kann, kann ich dann etwas näher an jemanden heranrücken?

Nick Muldoon:

Ja. In der Präsentation, die Sie gehalten haben, war ein Kommentar enthalten. Es gab eine Bemerkung dazu, dass, wenn ich weitere fünf Schritte machen muss, das zusätzliche 10 Sekunden sind. Dann sind das jedes Mal, wenn ich diese Aktivität jeden Tag mache, zusätzliche 10 Sekunden, und das alles summiert sich. Also, wie können wir diese Sekunden verkürzen und effektiver und überlegter vorgehen?

In Campbell-Pretty:

Das war einfach riesig, oder? Ich habe es in der Präsentation Kaizen Crazy genannt. Ich bin einfach so, so sehr bestrebt, mich zu verbessern, und zwar jeden Tag nur winzige, kleine Verbesserungen.

Nick Muldoon:

Also, eine der anderen Praktiken, die mir aus diesem Gespräch nicht entgangen sind, betraf die Bushaltestelle. Worum ging es bei der Bushaltestelle?

In Campbell-Pretty:

War das in dem Gespräch? Wirklich?

Nick Muldoon:

Ich zwinge dich, deinen Verstand zu erweitern [Crosstalk 00:34:57].

In Campbell-Pretty:

Du bist. Das bist du. Das bist du. Du hast völlig recht. Es war wirklich [unhörbar 00:35:01]. In Ordnung. Oh, du bist schrecklich.

Nick Muldoon:

Ja.

In Campbell-Pretty:

Ja. Ja, das bist du. Okay. Also, effektive Führungskräfte sind Menschen, lautete der Slogan dazu. Es ging wirklich darum, dass Führungskräfte bodenständig sind und eins mit den Teams sind. Also, Dinge, die ich in Japan gesehen habe, diese Fabrik, die von einer Frau geführt wird, [unhörbar 00:35:42], ich glaube, sie waren sehr ungewöhnlich. In Japan gibt es nicht viele weibliche Führungskräfte. Ihr Mann nahm ihren Namen an, weil [unhörbar 00:35:52]. Es ist ein wirklich interessanter Charakter.

In Campbell-Pretty:

Aber ihre Firma hat eine Reihe von Morgenritualen. Du sagst immer guten Morgen und danke und wie sie jeden Tag reden und jeder redet und jeder interagiert. Dann, an einem der anderen Orte, an die wir gingen, hatten sie alle ihre Uniformen, die sie in der Fabrik trugen. Aber jeder trug die Uniform, oder? Der CEO, die Büroangestellten und alle trugen die Uniform. Jeder war einer.

In Campbell-Pretty:

Dann dachte ich über meine Erfahrung in der Leitung von Teams nach, und vor einem Leben arbeitete ich mit einem Team zusammen, das sich entschied, an einem Unternehmenswettbewerb teilzunehmen. Bei diesem Wettbewerb ging es darum, Farbe zu zeigen und die Unternehmenswerte zu zeigen. Das waren Dinge wie gemeinsam besser und Mut, und dann [unhörbar 00:36:49] ein Regenbogen-Ding. Also, dieses Team entscheidet, was es tun wird, ist es eine Adresse in den Regenbogenfarben, und sie werden zusammen besser sein und ihren Mut zeigen und sie werden die Macarena machen und sie werden sie filmen und so werden sie diesen Wettbewerb gewinnen.

In Campbell-Pretty:

Ich habe an dieser Macarena nicht teilgenommen, weil jemand Fotos machen muss und so, oder? Wie werden sie sonst am Wettbewerb teilnehmen? Also musste ich meinen Beitrag leisten. Wie dem auch sei, wir hatten auch dieses Ritual, bei dem es darum ging, dass Teams die Führungskräfte vor Herausforderungen stellten, um sie zu lösen, und das taten sie am Ende jedes Frühlings. Also machen sie diese Macarena und sie filmen es und sie nehmen am Wettbewerb teil und am Ende des Frühlings stellen sie ihre Herausforderungen an die Führung.

In Campbell-Pretty:

Ihre Herausforderung ist, dass Em die Macarena nicht gemacht hat. Du bist unser Anführer, du hast die Macarena nicht gemacht. Wir fühlen uns dadurch sehr herausgefordert, und wir werden Ihnen das zur Lösung bringen. Also ging ich hin und sprach mit dem Team, das die Frage gestellt hat, und sagte: „Schau. Ich muss es dir sagen. Ich kenne die Macarena nicht. Also, tut mir leid.“ Ich erinnere mich noch so deutlich daran. Einer der Jungs sagte zu mir: „Ich habe diesen Blog darüber gelesen, wie wichtig es ist, dass Führungskräfte verwundbar sind.“ Sie wissen, wer diesen Blogbeitrag geschrieben hat, oder?

Nick Muldoon:

Oh, Em. Oh. Du hast es.

In Campbell-Pretty:

Also haben wir verhandelt. Ich sagte: „Schau. Ich denke, ich schaffe die Bushaltestelle.“ Für diejenigen, die nicht aus Australien kommen, wir wachsen damit auf, dass wir das in Highschool-Tänzen machen. Jedenfalls in meinem Teil der Welt. Also habe ich mir mein Führungsteam geschnappt und wir haben die Bushaltestelle gemacht und das war Teil des Beweises, dass auch wir genauso sind wie alle anderen, und unseren Teil dazu beizutragen und auf das Feedback des Teams zu reagieren. Also, ja. Da passt die Bushaltestelle rein. Vielen Dank dafür, Nick.

Nick Muldoon:

In Ordnung. Nein, das weiß ich zu schätzen. Nun, ich bin froh, dass ich den Kontext verstanden habe. Ich versuche, ähnliche Dinge zu tun. Normalerweise ist es eine Karaoke oder so, oder dass wir das schon eine Weile nicht mehr gemacht haben. Ja, okay. Ja, ich schätze, in diesem Gespräch ging es wirklich darum, Führungskräften zu dienen, und es ging nur darum, ihnen zu dienen. Es hört sich so an, als ob Sie von der Japan-Studienreise mitgenommen haben, dass diese Führer dort sehr viel für ihr Volk getan haben.

In Campbell-Pretty:

Absolut.

Nick Muldoon:

Sehen Sie das als ein Merkmal, das in den leistungsstärksten Unternehmen, mit denen Sie zu tun haben, vorherrscht, und wie wahrscheinlich ist es, dass sie über einen Zeitraum von fünf, zehn Jahren, was auch immer das sein mag, ihre Konkurrenten übertreffen oder auf ihrem Markt erfolgreicher sind? Oder ich schätze, wie auch immer sie Erfolg definieren?

In Campbell-Pretty:

Ich sehe sicherlich einen Zusammenhang zwischen Führungskräften, die gerne dienen und/oder sich dafür entscheiden, zu dienen, und dem Erfolg mit skalierter Agilität und Unternehmen, denn ich schätze, wir haben gesehen, es ist fast 10 Jahre her, dass diejenigen, die zusammen üben, Ihr diszipliniertes Framework Ergebnisse erzielen, und sie erzielen signifikante Ergebnisse. Sie verbessern ihre Fähigkeit, Produkte und Dienstleistungen bereitzustellen, ihre Kostenbasis sinkt, ihre Qualität steigt, ihre Mitarbeiter sind zufriedener, ihre Fluktuation sinkt. Wir sehen es jedes Mal.

In Campbell-Pretty:

Was wir auch sehen, ist, dass, wenn die Staats- und Regierungschefs ihren Worten nicht Taten folgen lassen, wenn die Staats- und Regierungschefs Lippenbekenntnisse zur Transformation ablegen, es nicht hält. Sie bekommen die Ergebnisse nicht. Die Leute finden es keinen besseren Ort zum Arbeiten. Die Leute sind nicht in die Veränderung eingedrungen. Da gibt es also definitiv einen Zusammenhang. In einer Organisation kann man sich Wunderbares aneignen.

In Campbell-Pretty:

Wir beobachten oft, dass die Organisation, deren Transformation genauso erfolgreich ist, die am meisten gekaufte Führungskraft ist. Die meisten Führungskräfte kauften sich eine Führungskraft ein. Wenn du also der Anführer eines Zuges bist und das richtige Verhalten an den Tag legst, wird dein Zug wirklich großartig sein.

Nick Muldoon:

Erfolgreich.

In Campbell-Pretty:

Aber das bedeutet nichts für die gesamte Organisation, den Lösungsweg, die Geschäftseinheit, was auch immer. Sie sehen diese Sache, die vom Anführer ausgeht. Wenn die Führungskraft das richtige Verhalten zeigt, bewegen Sie sich in diesen Bereich, Sie sehen die Verhaltensweisen, Sie bekommen die Veränderung, Sie erhalten die Ergebnisse. Aber Führungskräfte, die eine Sache sagen und eine andere tun, glauben es nicht, oder?

Nick Muldoon:

Ich denke, das gilt für jede organisatorische Veränderung, nicht wahr?

In Campbell-Pretty:

Ja.

Nick Muldoon:

Sie stoßen, wie Sie sagten, innerhalb der Organisation an die Grenzen Ihrer Tasche und dann lernen Sie die reale Welt kennen, den Rest der Organisation. Die Leute haben vielleicht nicht genug Energie oder sie haben nicht das Gefühl, dass sie das beeinflussen und ändern können, und so leben sie einfach in ihrer Blase, weil sie nicht das Gefühl haben, dass sie den Druck außerhalb dieser Blase ausüben können.

In Campbell-Pretty:

Ja. Guck mal. Ich habe sicherlich erfolgreiche Organisationen mit Blaseneinfluss gesehen. Erfolgreiche Seifenblasen können interessant werden. Chip und Dan Heaths Buch, welches war es, Switch.

Nick Muldoon:

Oh, ja. Schalter. Ja.

In Campbell-Pretty:

[unhörbar 00:42:02]. Zünde ein Licht auf einen hellen Punkt oder so. Lichtblicke inspirieren also, und wenn Sie in einer Organisation eine Blase erzeugen können, die den Rest der Organisation übertrifft, oder selbst wenn sie besser abschneidet als zuvor, dann schauen alle hin. Richtig? Wie ist die Organisation, die von schlechten Lieferungen zu großartigen Lieferungen übergeht, hier vor sich? Das inspiriert andere, sich dafür zu interessieren. Eines der wirklich interessanten Dinge, die wir in Australien gesehen haben, ist, dass wir so ziemlich jede SAFe-Implementierung in Australien auf die bei Telstra zurückverfolgen können.

Nick Muldoon:

Ja, richtig. Sie haben sich alle davon abgespalten, von den Leuten, die daran beteiligt waren.

In Campbell-Pretty:

Nun, nein. Leute, die gekommen sind und es gesehen haben. Leute, die sich davon inspirieren ließen.

Nick Muldoon:

Sie sind nicht unbedingt direkt daran beteiligt.

In Campbell-Pretty:

Nein. Die Leute kamen und ließen sich davon inspirieren, und dann gingen sie, machten ihr Ding und dann inspirierten sie jemand anderen. Ich habe es in letzter Zeit nicht versucht, aber es gab einen Zeitpunkt, an dem wir sie einfach alle miteinander verbinden konnten, weil wir sie zählen konnten, wenn wir sie sehen konnten. Aber wir können die meisten von ihnen immer noch miteinander verbinden. Es heißt, Sie haben jemanden gesehen, der jemanden gesehen hat, der tatsächlich jemanden gesehen hat, der uns 2012, 2013 bei Telstra besucht hat und sich inspirieren ließ.

In Campbell-Pretty:

Also, dieser Lichtblick kann wirklich, wirklich mächtig sein, und genau das braucht es, oder? Man fügt ein bisschen Lärm hinzu, ein bisschen Unterschied, und die Leute fangen an zu fragen, was vor sich geht. Ich würde nicht sagen, dass es narrensicher ist. Ich denke, es erfordert immer noch, also muss jemand kommen, er muss sehen, und dann muss er den Mut haben, es für seinen Teil der Organisation zu tun.

In Campbell-Pretty:

Das ist der schwierige Teil, oder? Ich kann kommen, ich kann sehen, ich kann mich inspirieren lassen. Aber bin ich bereit, mich da draußen zu zeigen? Es spricht viel für Führungskräfte, die bereit sind, Risiken einzugehen. Das war einer der...

Nick Muldoon:

Das war deine Lektion über die Bushaltestelle, oder? Du musst dich da draußen aufhalten und verwundbar sein.

In Campbell-Pretty:

Ja. Ja, absolut. Absolut. Das war eigentlich, dachte ich, das, worüber ich letztes Jahr auf dem SAFe Summit gesprochen habe: Sei sicher oder sei SAFe.

Nick Muldoon:

Sei sicher oder sei SICHER. Erzählen Sie mir davon.

In Campbell-Pretty:

Seien Sie also sicher, gehen Sie kein Risiko ein, oder seien Sie sicher, wie im skalierten agilen Framework, und machen Sie diesen Vertrauensvorschuss. Es kommt darauf zurück, dass wir heute angefangen haben, darüber zu sprechen, als ich das bei Telstra gemacht habe. Ich habe nicht wirklich verstanden, dass das kein normaler Alltag war, das ist, was alle irgendwie gemacht haben. Es war eine sehr neue Sache. Also ging ich ein Risiko ein, weil ich ein Unternehmensleiter in einem Technologiebereich war, und ich hatte wirklich das Gefühl, nichts zu verlieren zu haben.

In Campbell-Pretty:

Also schaue ich zurück und sage: „Was um alles in der Welt hat mich besessen?“ Und ich sage: „Nun, ich bin diese Geschäftsperson, die dieses Technologieteam leitet. Ich hätte sowieso keinen Erfolg haben sollen.“

Nick Muldoon:

Setz alles aufs Spiel, oder?

In Campbell-Pretty:

Später fand ich heraus, dass sie tatsächlich einen Plan hatten, wann ich keinen Erfolg hatte. Ich hätte scheitern sollen.

Nick Muldoon:

Warte. Wie viel Abfall ist das? Warum haben sie etwas geplant, bevor es... In Ordnung.

In Campbell-Pretty:

Organisatorische Richtlinien. Was kann ich dir sagen? Wie auch immer, ich habe nicht versagt. Ich hatte Erfolg, und weil ich einige verrückte, kalkulierte Risiken eingegangen bin, und ich habe es immer wieder gesehen, oder? So viele der Führungskräfte in diesen Unternehmen, die diese Änderung vornehmen, wagen einen Vertrauensvorschuss. Ich sage immer, dass ich dir nicht genau sagen kann, was passieren wird. Ich weiß nicht, ob Sie 10% oder 50% der Kosten sparen werden. Ich weiß nicht, ob Ihre Leute 10% oder 50% glücklicher sein werden. Ich weiß das nicht.

In Campbell-Pretty:

Was ich weiß, ist, wenn Sie auf das hören, was wir Ihnen sagen, die Anweisungen befolgen und sich im Einklang mit diesen schlanken und agilen Werten verhalten, werden Sie Ergebnisse erzielen. Sie werden jedes Mal Ergebnisse erzielen. Aber du musst mutig genug sein, dich einzukaufen und es ganzheitlich anzugehen und nicht diese Sache zu tun, bei der du es schaffst, dich selbst zu personalisieren, um die Sache tatsächlich zu tun...

Nick Muldoon:

Ich mache irgendwas.

In Campbell-Pretty:

... das du machen wolltest.

Nick Muldoon:

Ja. Okay. Em, das war großartig. Bevor wir fertig sind, möchte ich mir zwei Minuten Zeit nehmen. Sie haben heute oft Bücher erwähnt und mich an dieses Zitat erinnert, Verne Harnish: „Diejenigen, die lesen und nicht, sind nur geringfügig besser dran als diejenigen, die es nicht können.“ Also, heute hast du Chip und Dan Heath mit Switch erwähnt, du hast die Leffingwell-Serie aus den späten Nullerjahren erwähnt. Es könnte noch ein paar andere gegeben haben. Aber sag mir, was liest du heute? Du warst im Lockdown. Was sind die zwei oder drei besten Bücher, die Sie gelesen haben, seit Sie in Melbourne im Lockdown waren?

In Campbell-Pretty:

Oh, meine Güte. Es ist sehr peinlich. Jedes Mal, wenn mich jemand fragt: „Was hast du gerade gelesen?“ Ich sage: „Ich weiß nicht.“

Nick Muldoon:

Ich glaube nicht, dass ich mich erinnern kann.

In Campbell-Pretty:

Ich kann mich nicht erinnern. Es ist furchtbar. Was lese ich? Ich muss meinen Kindle öffnen. Ich weiß nicht, was ich lese. Geoffrey Moore, Zone to Win.

Nick Muldoon:

Zone, um zu gewinnen.

In Campbell-Pretty:

Zone, um zu gewinnen. Ich glaube, so heißt es. Es ist ein neueres Buch. Ich weiß es dieses Jahr, weil ich dieses Jahr offensichtlich The Build Trap gelesen habe.

Nick Muldoon:

Jep. Melissa Perry. Das hast du erwähnt. Ja.

In Campbell-Pretty:

Jep. Ich habe das Projekt zum Produkt gelesen, Mik Kersten.

Nick Muldoon:

Was war das, Project to Product?

In Campbell-Pretty:

Ja. Vom Projekt zum Produkt, Mik Kersten. Eines der Pressebücher von IT Revolution. Also, vor etwas mehr als einem Jahr veröffentlicht. Sehr beschäftigt mit SAFe 5.0 [Crosstalk 00:48:21]. Das andere Buch, das in der SAFe-5.0-Version enthalten ist, ist John Kotters Accelerate. Also habe ich das wieder abgeholt. Ich habe es vor einigen Jahren gelesen, als es zum ersten Mal herauskam. Aber ich schaue mir Dinge gerne noch einmal an, wenn SAFe sie in den Mittelpunkt stellt. Scheint zu diesem Zeitpunkt Sinn zu machen, das zu tun.

Nick Muldoon:

Ja, okay. Ja, es ist interessant, dass, wenn ich an Verne Harnish denke, das Scaling-Up-Framework nichts zu tun hat mit...

In Campbell-Pretty:

Nein.

Nick Muldoon:

... agil skaliert, für alle, die sich nicht auskennen. Aber ein Großteil des Frameworks zur Skalierung von Unternehmen ist, dass sie auf so viele Inhalte aus bestehenden Angeboten, bestehenden Büchern, Bezugspunkten und Erfahrungen zurückgreifen, und das ist wirklich wertvoll, und ich denke, SAFe ist da nicht anders, oder? Es stützt sich auf diese Weisheit der kollektiven Weisheit.

In Campbell-Pretty:

Absolut. Absolut. [unverständlich 00:49:14] Es hat sehr viel Spaß gemacht, in der Anfangszeit zu sagen, dass wir auf den Schultern von Riesen stehen, ein Zitat von jemand anderem, dessen Name mir entgeht.

Nick Muldoon:

Ja, okay. Ja, Em, sieh mal. Ich wollte dir vielmals für deine Zeit heute Morgen danken. Das war fantastisch.

In Campbell-Pretty:

Keine Sorge. Es ist toll, dich zu treffen.

Nick Muldoon:

Ja. Ich denke, meine Erkenntnisse daraus sind, dass ich die Regeln be safe oder be SAFe mag, also entweder sei sicher und gehe kein Risiko ein, oder sei SAFe und stelle dich tatsächlich da raus und steige in Scaled Agile ein. Ich muss auf jeden Fall auch ein bisschen über die fünf S recherchieren und ein bisschen mehr darüber lernen. Aber vielen Dank für deine Zeit. Ich weiß das wirklich zu schätzen.

In Campbell-Pretty:

Keine Sorge, Nick. Schön dich zu sehen.

„Es war toll, mit Caitlin über die Bedeutung der Team-Retrospektive für die Zusammenstellung eines leistungsstarken, funktionsübergreifenden Teams zu chatten“ — Chloe Hall

In dieser Folge wurde ich von Caitlin Mackie, Content Marketing Coordinator bei Easy Agile, begleitet.

In dieser Episode haben wir darüber gesprochen;

• Wir betrachten die Team-Retrospektive als Instrument zur Risikominderung und nicht nur als eine weitere agile Zeremonie
• Die Wichtigkeit, die Retrospektive in regelmäßigen Abständen durchzuführen
• Warum solltest du die Siege feiern?
• Übernehmen Sie die Aktionspunkte aus Ihrem Team im Rückblick auf Ihre Team-Sprintplanung
• Timeboxing — Die Retrospektive
• Schaffen Sie eine psychologisch sichere Umgebung für Ihre Team-Retrospektive

Ich hoffe, euch gefällt die heutige Folge genauso gut, wie ich sie aufgenommen habe.

Transkript

Chloé Hall:

Hallo zusammen. Willkommen zum Easy Agile Podcast. Ich bin Chloe, Marketingkoordinatorin bei Easy Agile, und ich werde Ihre Moderatorin für die heutige Folge sein. Bevor wir beginnen, möchten wir den traditionellen Hütern des Landes, von dem aus ich heute aufnehme, unsere Anerkennung aussprechen, dem Volk der Wodi Wodi aus der Dharawal sprechenden Nation, und den Ältesten aus Vergangenheit, Gegenwart und Entwicklung unseren Respekt erweisen. Den gleichen Respekt zollen wir allen Aborigines und den Bewohnern der Strait Islander, die heute zuhören. Heute haben wir also eine etwas andere Episode für Sie. Ich werde mit Caitlin Mackie, der eigenen Content-Marketing-Koordinatorin von Easy Agile, sprechen. Caitlin ist die Product Owner* unseres Marken- und Konversions-Teams*. Jetzt ist dieses Team ein funktionsübergreifendes Team, das erst seit etwa sechs Monaten zusammen ist. Und in den ersten Monaten hatten sie als Team, wohlgemerkt, auch zwei brandneue Mitarbeiter, sie arbeiteten an einem Rebranding des Unternehmens.

Chloé Hall:

Ein neues Team, eine riesige Aufgabe, die Möglichkeit, dass das Team Höchstleistungen erbringt, war zu diesem Zeitpunkt unwahrscheinlich. Das Team war also zu neu, um dieses Vertrauen, die starken Beziehungen und die psychologische Sicherheit bereits aufgebaut zu haben, aber irgendwie kamen sie zusammen und schafften es, zusammenzuarbeiten, einen Fluss kontinuierlicher Verbesserungen zu schaffen und dieses Rebranding zu veröffentlichen. Deshalb habe ich heute Caitlin in den Podcast aufgenommen, um das Erfolgsgeheimnis des Teams zu besprechen. Willkommen zum Podcast, Caitlin.

Caitlin Mackie:

Danke, Chloe. Es ist etwas anders, auf dieser Seite zu sitzen. Ich bin es gewohnt, in deinen Schuhen zu stehen. Ich fühle mich [unhörbar 00:01:45]. Ich fühle mich unwohl. [unhörbar 00:01:46].

Chloé Hall:

Ja. Es ist auch mein erstes Mal, dass ich Gastgeber bin, sehr seltsam. Ist es nicht? Wie fühlst du dich heute?

Caitlin Mackie:

Ja. Gut. Ich freue mich. Ich freue mich darauf, über unsere Erfahrungen als funktionsübergreifendes Agile-Team zu sprechen und hoffentlich einige der Dinge, die für uns funktioniert haben, mit unseren Zuhörern zu teilen.

Chloé Hall:

Ja, ich weiß es selbst und ich bin mir sicher, dass unser Publikum sehr gespannt ist, was das Erfolgsgeheimnis Ihres Teams war. Wolltest du uns zunächst sagen, was dieses große Geheimnis war, das dir wirklich geholfen hat, als Team zusammenzuarbeiten?

Caitlin Mackie:

Das ist eine gute Frage, Chloe. Und das ist eine große Frage. Ich bin mir nicht sicher, ob es eine wichtige Sache gibt, ich nehme an, es ist diese ultimative geheime Quelle oder die eine Sache, die zum Erfolg geführt hat. Ich bin mir sicher, dass wir alle hören wollen, was das ist. Ich würde auch gerne wissen, ob es nur diese eine wichtige Zutat gibt, aber ich denke, etwas für uns, und wahrscheinlich eines der denkwürdigsten Dinge, die für uns wirklich funktioniert haben und von dem wir viel profitieren konnten, war, unsere Retrospektiven zu machen. Das ist wahrscheinlich das Erste, was mir in den Sinn kommt, wenn es darum geht, was zu unserem Erfolg geführt hat.

Chloé Hall:

In Ordnung. Ja. Warum hast du am Anfang mit den Retrospektiven angefangen?

Caitlin Mackie:

Wir waren also ein neu formiertes Team, wie Sie bereits erwähnt haben, und wir haben Retrospektiven als eine weitere Agile-Zeremonie gesehen, und wir haben gesehen, wie andere Teams das gemacht haben und sie hatten viel Erfolg damit, also sind wir auf diesen Zug aufgesprungen. Und ich denke, wenn wir ein neues Team bilden, kommen so viele Dinge ins Spiel. Sie versuchen also, sich gegenseitig herauszufinden, wie wir alle gerne arbeiten und miteinander kommunizieren, all das. Und wir waren das erste Team, das sich dem Besitz und der Verbesserung unserer Website verschrieben hat. Und wir wussten auch, dass wir wahrscheinlich für die Gestaltung und Einführung eines Rebrandings verantwortlich sein würden.

Caitlin Mackie:

Wenn Sie also versuchen, all das zusammenzufügen und dann all diese Elemente berücksichtigen, wussten wir, dass wir etwas Zeit einplanen mussten, um schnell iterieren und herausfinden zu können, was funktioniert und was nicht. Und was wir verstanden haben, ist, dass Retrospektiven eine großartige Gelegenheit für das gesamte Team sind, um alle problematischen Probleme aufzudecken und eine offene Diskussion zu führen, um wirklich Verbesserungspotenzial zu identifizieren oder herauszufinden, was gut funktioniert, damit wir das auch weiterhin tun können. Ich denke, Rückblicke haben es uns ermöglicht zu verstehen, wo wir die größte Wirkung erzielen können und wie wir ein wirklich effektives, funktionsübergreifendes Agile-Team bilden können.

Chloé Hall:

Beeindruckend. Das ist schon so aufschlussreich. Ja, es hört sich so an, als ob Ihnen die Retrospektiven wirklich dabei geholfen haben, herauszufinden, wer Ihr Team ist, und ein gut funktionierendes, leistungsstarkes, funktionsübergreifendes Team zu werden. Also, wie oft hast du Retro gemacht? Hast du das in einem regelmäßigen Zyklus gemacht, oder war es nur: „Okay. Wir haben ein Problem. Es sind ein paar Blocker aufgetaucht, wir müssen einen Retro machen“?

Caitlin Mackie:

Ja. Ich glaube, anfangs waren Retros für uns so etwas wie: „Oh, wir haben jetzt ein paar Sprints gemacht. Wir sollten wahrscheinlich einen Retro machen und einfach darüber nachdenken, wie diese paar Sprints gelaufen sind.“ Es war irgendwie wie dieses Ding. Es war immer im Hinterkopf. Und wir wussten, dass wir es tun mussten, waren uns aber nicht wirklich sicher, was den Rhythmus und die Art und Weise angeht, wie wir das machen sollten. Jetzt machen wir Retros an einem Freitagmorgen, dem letzten Tag unseres wöchentlichen Sprints. Und danach beginnen wir mit der Sprint-Planung. Also auch nach der Biopause, also lass das Team alles verdauen, worüber wir in Rückblicken gesprochen haben. Und dann kommen wir zur Sprint-Planung mit all den Themen, die wir besprochen haben, und wir werden eine wirklich nette, frische Perspektive haben.

Chloé Hall:

Ja.

Caitlin Mackie:

Also, ich denke, das funktioniert wirklich gut für uns, weil alles zeitnah passiert. Wir hatten gerade eine Diskussion über die besten Dinge, die im Sprint passiert sind oder was wirklich gut funktioniert hat. Sie sollten also sicherstellen, dass Sie im Folgenden dasselbe Verhalten üben können, und umgekehrt, wenn es um die Verbesserungen geht, die Sie vornehmen möchten. Also, diese Liste der Aktionspunkte, die aus einer Retrospektive hervorgegangen sind, bietet einen wirklich netten Kontakt, Kontext, tut mir leid. Und Sie haben sie alle bei der Sprint-Planung im Hinterkopf.

Caitlin Mackie:

So könnte es beispielsweise im vorherigen Sprint vorkommen, dass Sie Ihre Storypoints unterschätzt haben oder dass Ihre User Stories nicht detailliert genug waren. Bei jeder Story oder Aufgabe, die Sie in den Sprint einbringen, stellen Sie dann die Frage: Sind alle mit dem Detaillierungsgrad zufrieden? Was fehlt uns? Oder wir haben nur auf diese oder zwei Geschichten hingewiesen, ist es wahrscheinlicher, dass es eine Fünf ist? Also, alles ist wirklich frisch in deinem Kopf, und ich denke definitiv, dass das hilft, Dynamik zu erzeugen. Wenn das gesamte Team daran arbeitet, herauszufinden, wie Sie mit jedem Sprint effektiver sein können.

Chloé Hall:

Das ist so toll, dass du Caitlin gerade angesprochen hast. Und ich finde es toll, wie man nach der Team-Retrospektive diese Aktionspunkte tatsächlich nehmen und in den Sprint übergehen und sie sofort umsetzen kann. Es ist wirklich gut. Ansonsten habe ich das Gefühl, wenn du die Sprint-Retrospektive am Freitag machst und sagst: „Okay, das sind unsere Aktionspunkte“, dann gehst du zur Sprintplanung für Montag und denkst nur an das Wochenende. Das [unhörbar 00:07:20]

Caitlin Mackie:

Ja, hundertprozentig. Ja. Sie sind für jeden ein superfrischeres Gemüt. Es funktioniert vielleicht nicht für jedes Team, aber wir finden, dass es für uns wirklich gut funktioniert, weil wir bei der Sprint-Planung sehr sorgfältig vorgehen.

Chloé Hall:

Ja. Und dann konnte ich mir vorstellen, wie man das Retro macht, wie es leicht im Laufe der Zeit gehen könnte, aber dann hat Ihr Team die Sprint-Planung danach geplant. Es ist also so, als ob du die Zeit nicht verlängern kannst. Wie haben Sie es geschafft, diese Retrospektive irgendwie in eine Zeitbox zu packen?

Caitlin Mackie:

Ja, das ist eine wirklich, wirklich gute Frage. Und es ist auch beabsichtigt, dass sie eng zusammen geplant sind. Wie bereits erwähnt, gibt die Diskussion, die Sie in den Retrospektiven geführt haben, einen schönen Impuls für die Sprint-Planung, aber das bedeutet, dass wir auf die Uhr schauen müssen. Und am Anfang kann das ziemlich umständlich sein, weil Sie sicherstellen wollen, dass sich jeder gehört fühlt und dass jeder die gleiche Gelegenheit hat, etwas beizutragen. Und ich denke, diese Verantwortung liegt beim Scrum Master oder beim Product Owner oder bei wem auch immer, der die Retrospektive moderiert, um darauf hinzuweisen und sicherzustellen, dass jeder die Chance hat, gehört zu werden. Natürlich lassen Sie die Leute die längere Geschichte erzählen oder fügen viel zusätzlichen Kontext hinzu, bevor Sie zur Sache kommen. Und dann wirst du andere haben, die viel direkter sein werden. Und letzterem bin ich sehr ähnlich. Mir fällt es schwer, auf den Punkt zu kommen, was nicht gut funktioniert, wenn man versucht, eine Retrospektive mit einem Timebox zu versehen, oder?

Chloé Hall:

Und ich kann das nachvollziehen, dieselbe Persönlichkeit.

Caitlin Mackie:

Ja. Also, ich denke, es kommt wirklich darauf an, die Erwartungen und Prioritäten von Anfang an zu kommunizieren. Mit unserem Team und mit jedem Team wirst du herausfinden wollen, wen du wirklich gut abschneiden und dich kontinuierlich verbessern kannst, um die Erwartungen zu übertreffen, besser zu werden und gemeinsam zu lernen und zu wachsen. Und ich denke, wenn ihr alle die gleiche Denkweise teilt, wenn ihr in die Retrospektive geht und anerkennt, dass das sicher ist

Raum für schwierige Gespräche. Und solange Sie mit Empathie kommunizieren, weiß das Team, dass es nie um etwas Persönliches geht und dass alles im besten Interesse des Teams ist. Und das hilft dann den weniger direkten Kommunikatoren wie mir, ihren Standpunkt prägnanter anzusprechen und zwingt sie wirklich dazu, ihren Kommunikationsstil überlegter und prägnanter zu gestalten.

Caitlin Mackie:

Und das ist wirklich wichtig, um diese Zeitbox einhalten zu können, denke ich. Und das erfordert Übung, denn es kommt darauf an, diese psychologische Sicherheit in Ihrem Team zu schaffen. Aber wenn das erst einmal da ist, ist es viel einfacher, zu rufen, wenn jemand eine windige Strecke hinunterfährt, und den Fokus wieder zu richten und irgendwie zu sagen: „Ich verstehe dich, was ist der Aktionspunkt?“ Und werde einfach viel bewusster.

Chloé Hall:

Beeindruckend. Ich konnte mir nicht vorstellen, wie schwer es sein würde, mit den Persönlichkeiten, die du und ich haben, zu versuchen, so direkt zu sein und all das flauschige Zeug loszuwerden. Ich meine, sieh dir an, was getan wurde, um ein so großartiges Team zu bilden, das wir haben. Also, Sie haben diesen Aspekt der psychologischen Sicherheit bereits erwähnt. Und wie denkst du, in einem neuen funktionsübergreifenden Team zu sein... Nur sechs Monate zusammen, Sie hatten diese neuen Mitarbeiter. Glauben Sie, Sie waren jederzeit in der Lage, einen psychologischen Sicherheitsraum zu schaffen?

Caitlin Mackie:

Das ist eine weitere fantastische Frage. Und ich denke, ehrlich gesagt, wäre es am besten, eine Teamdiskussion darüber zu führen. Es wäre interessant, die Meinungen aller dazu zu hören, was zu diesem Element der psychologischen Sicherheit beiträgt und ob es allen genauso geht. Ich kann also nicht für das Team sprechen, aber meine persönliche Meinung zu dieser oder meiner persönlichen Erfahrung ist, dass die Schaffung eines Umfelds psychologischer Sicherheit wirklich von gegenseitigem Vertrauen und Respekt abhängt. Und am Ende des Tages verfolgen wir alle dasselbe Ziel. Wir alle respektieren also wirklich, wirklich, was der andere mitbringt, und verstehen, wie all diese beweglichen Teile, an denen wir individuell arbeiten, zusammenkommen, um das Ziel zu erreichen. Wenn wir also diese offenen Diskussionen im Rückblick führen oder nicht einmal in Retros, sondern einfach nur allgemein kommunizieren, ist klar, dass wir Fragen im besten Interesse des Teams stellen und individuelle Motive nie ins Spiel kommen, oder die Leute äußern ihre Meinung nicht einfach, wenn sie ungerechtfertigt ist, oder geben Feedback oder sind übermäßig kritisch, wenn sie nicht darum gebeten wurden.

Caitlin Mackie:

Keines dieser toxischen Verhaltensweisen passiert also, weil wir alle respektieren, dass unabhängig von der fraglichen Arbeit oder dem Diskussionsthema die Person, der diese Arbeit gehört, am Ende des Tages der Experte ist. Und wir vertrauen ihnen und zweifeln keine Sekunde lang aneinander. Und ich denke, die andere Hälfte davon ist, dass wir auch wirklich Glück haben, dass wir alle da sind, um uns gegenseitig abzuholen und weiterzumachen, wenn etwas nicht so läuft, wie wir es geplant hatten. Das passt also ganz gut dazu, dass einer unserer Werte bei Easy Agile darin besteht, sich als Team zu engagieren. Und hier geht es darum, anzuerkennen, dass wir wachsen und erfolgreich sind, wenn wir es gemeinsam tun, aufeinander aufzupassen und uns mit Authentizität und Mut zu engagieren. Manchmal mag ich voreingenommen sein, aber ich glaube von ganzem Herzen, dass unser Team das voll und ganz akzeptiert. Und es gibt einfach eine solche Bewunderung für das, was wir alle an den Tisch bringen, und ich denke, das ist wirklich der Schlüssel zur Schaffung der psychologischen Sicherheit.

Chloé Hall:

Ich finde es toll, dass Ihr Team unseren Wert wirklich annimmt, sich als Team engagiert und ihn umsetzt, denn genau darum geht es uns bei Easy Agile, und es ist einfach großartig, das auch zu sehen. Ich denke, die andere Sache

Ich wollte ansprechen war... Also nochmal, während dieses funktionsübergreifenden Teams, und du hast Design und Entwicklung, wie hat dir Retros deiner Meinung nach geholfen, herauszufinden, was Design und Entwicklung voneinander brauchen?

Caitlin Mackie:

Ganz gewiss. Also, für etwas mehr Kontext für unsere Zuhörer, also haben wir in unserem Team zwei Entwickler, Haley und David, und einen Designer, Matt und mich, der im Marketing tätig ist. Wir sind also quasi ein funktionsübergreifendes kleines Mini-Team. Wir haben also alle das gleiche Ziel und den gleichen Fokus, aber wir arbeiten auch alle an diesen kleinen Einzelkomponenten, die wir dann zusammenfügen. Also, ich denke... Wir machen regelmäßig Retros. Was wir feststellen konnten, war ein wirklich effektiver Design- und Entwicklungszyklus. Also haben wir einen Rhythmus für das gefunden, was wir an bestimmten Stellen gegenseitig brauchten. Wir haben zum Beispiel sehr früh herausgefunden, dass wir sicherstellen mussten, dass wir Design- und Entwicklungsarbeit nicht in denselben Sprint bringen. Wir brauchten eine vollständig fertige Designdatei, bevor die Entwickler mit der Arbeit daran beginnen konnten. Und das klingt vielleicht sehr offensichtlich, aber anfangs dachten wir: „Oh, nun, wenn du eine halbfertige Design-Datei hast, kann der Entwickler anfangen, daran zu arbeiten. Und wenn das erledigt ist, wird der Rest der Design-Datei fertig sein.“

Caitlin Mackie:

Was wir jedoch nicht eingestanden haben, ist, dass wir dadurch nicht genug Kapazität hatten, um zu iterieren oder Probleme zu lösen oder Feedback zum ersten Teil dieser Designdatei einzubeziehen, oder wenn der Entwickler angefangen hat, daran zu arbeiten und das Design dann gesagt wird: „Oh, dieser Teil hier, das ist nicht möglich“, sodass der Designer wieder am ersten Teil arbeitet. Und es schafft einfach eine Menge dieser Hindernisse. Im Rückblick kam das zur Sprache und wir konnten es ansprechen und verstehen, welches Design vom Entwickler benötigt wird und was der Entwickler vom Design braucht, um sicherzustellen, dass wir uns nicht gegenseitig blockieren. Und das Wichtigste an der Retro-Version ist, dass wir uns alle einig waren, dass eine Design-Datei komplett fertig sein muss, bevor der Entwickler mit der Arbeit beginnt.

Chloé Hall:

Ich finde es so toll, dass du diese Blocker schon früh identifizieren konntest. Glaubst du, dass es durch die wöchentliche Wiederholung dieser Blocker schnell zum Vorschein kommen konnte, oder glaubst du, das hätte keinen Unterschied gemacht?

Caitlin Mackie:

Nein, auf jeden Fall. Ich bin hundertprozentig der Meinung, dass Retros es uns ermöglicht haben, die Blockaden zeitnaher und effektiver anzugehen. Und das haben wir schon einmal angesprochen, aber ja, mit Retros kannst du die Blocker angehen, sie auspacken, verstehen, warum sie passieren und was wir tun müssen, um sicherzustellen, dass sie nicht wieder auftreten. Also, auf jeden Fall.

Chloé Hall:

Ja. Ja. Ich glaube, ich möchte jetzt ein bisschen über die Siege sprechen, den sehr aufregenden Teil des Retro, den Teil, den wir alle lieben. Also, wie wichtig sind deiner Meinung nach die Siege im Retro-Bereich?

Caitlin Mackie:

So wichtig. So, so, so wichtig. Also, wenn man als Team etwas Episches erreicht, muss man es herausfordern. Feiert alle Siege, ob groß oder klein. Manche Wochen werden besser sein als andere, aber genießen Sie die Mentalität, dass Glas halb voll ist. Und es gibt immer etwas, auf das man stolz sein und feiern kann, also rufen Sie es aus

einander, teile es mit dem ganzen Unternehmen, erkenne es öffentlich an. Ja, ich denke, es ist so wichtig, die Siege zu begrüßen. Es schafft einfach eine wirklich positive Atmosphäre, wenn man im Team ist. Jeder fühlt sich gehört und anerkannt für seinen wirklich positiven Beitrag, den er leistet. Und ich denke, eine große Sache hier ist auch, dass, wenn Sie als Team etwas Episches erreicht haben, es für andere Teams hilfreich ist, das auch zu hören, oder? Ihr habt einen coolen neuen Weg gefunden, etwas zu tun, teilt ihn. Wenn es dir als Team geholfen hat, wird es höchstwahrscheinlich einem anderen Team helfen.

Caitlin Mackie:

Ich denke also, dass das Feiern der Siege auch nicht nur der Arbeit vorbehalten ist, oder? Wenn jemand außerhalb der Arbeit etwas Tolles tut oder ein persönliches Ziel erreicht, dann stehen Sie dahinter.

Chloé Hall:

Ja.

Caitlin Mackie:

Um immer alle Siege zu feiern.

Chloé Hall:

Ja. Und ich finde es so gut, wie du erwähnt hast, dass es wichtig ist, auch die Siege im Privatleben eines Menschen zu feiern, denn am Ende des Tages sind wir alle Menschen. Ja, wir kommen zur Arbeit, aber wir haben dieses persönliche Element. Und zu wissen, wie jemand auch außerhalb der Arbeit ist, ist ein Element, um diesen psychologischen Sicherheitsraum und die Teambindung zu schaffen, die so wichtig sind, um am Ende des Tages ein gutes Team zu haben. Ja.

Caitlin Mackie:

Ja, hundertprozentig. Ja, damit hast du den Nagel in den Kopf getroffen. Ja, wir haben schon über psychologische Sicherheit gesprochen, und ich denke definitiv, das mit einzubeziehen, anzuerkennen, dass wir bei der Arbeit wir selbst sind, aber wir haben auch ein ganz anderes Leben außerhalb davon, also achten wir einfach darauf und feuern uns die ganze Zeit gegenseitig an. Das müssen wir tun, die größten Cheerleader des anderen sein.

Chloé Hall:

Ja, genau. Das ist der wahre Schlüssel zum Erfolg. Ist es nicht?

Caitlin Mackie:

Ja, das ist es. Das ist der Schlüssel.

Chloé Hall:

Sie haben also als neues funktionsübergreifendes, leistungsstarkes Agile-Team wirklich gut gearbeitet. Wie denkst du... Wie sieht dein zukünftiger Prozess für Retros aus?

Caitlin Mackie:

Wir werden sie auf jeden Fall weiterhin wöchentlich machen. Es ist Teil des Agile-Manifests, aber wir wollen uns darauf konzentrieren, auf Veränderungen zu reagieren, und ich denke, Retros ermöglichen uns das wirklich. Es ist nützlich und wirklich wertvoll für

das Team. Und wenn Sie das Team auf Erfolgskurs bringen können, werden Sie die positiven Auswirkungen sehen, die sich auf das gesamte Unternehmen auswirken. Also ja, wir haben eine schöne Trittfrequenz und einen Rhythmus gefunden, der für uns funktioniert. Also, wenn es nicht kaputt ist, repariere es nicht.

Chloé Hall:

Ja.

Caitlin Mackie:

Sagen sie das? Ist das das Sprichwort?

Chloé Hall:

Ich weiß nicht. Ich glaube schon, aber lass uns einfach weitermachen. [unhörbar 00:19:02], repariere es nicht.

Caitlin Mackie:

Da haben wir's. Ja.

Chloé Hall:

Du kannst Caitlin Mackie dazu zitieren.

Caitlin Mackie:

Zitiere mich dazu.

Chloé Hall:

Okay, Caitlin. Okay, es gibt nur noch eine letzte Sache, die ich heute ansprechen möchte. Ich dachte, Ende des Podcasts, lass uns einfach ein bisschen Spaß haben und wir werden einen kleinen Ausschnitt von Caitlins heißem Tipp machen. Also, für das Publikum, das zuhört, möchte ich, dass du dir etwas ausdenkst, das sie aus dieser Folge mitnehmen können, einen Action-Punkt, mit dem sie heute in ihren Teams beginnen können. Nimm es weg.

Caitlin Mackie:

In Ordnung. Okay. Alles klar. Ich würde sagen, mach immer die Retrospektive. Überspringe es nicht. Auch wenn es nur wenige Punkte zu besprechen gibt, werden immer neue Dinge auftauchen. Und Sie müssen dem Team regelmäßig Möglichkeiten bieten, seine Gedanken auszutauschen. Und ich überlasse es Ihnen: Fördern Sie stets einen positiven Dialog und zeigen Sie Wert und Wertschätzung für Teamideen und füreinander. Das ist mein...

Chloé Hall:

Ich liebe das.

Caitlin Mackie:

Das ist mein heißer Tipp.

Chloé Hall:

Danke, Caitlin. Danke fürs Teilen. Mir gefällt wirklich, wie Sie gesagt haben, fördern Sie immer einen positiven Dialog. Ich finde das so toll. Ja. Ja, danke, Caitlin. Danke, dass du heute auf den Podcast gekommen bist und...

Caitlin Mackie:

Danke, Chloe.

Chloé Hall:

Ja. Teilen Sie die Erfahrungen Ihres Teams mit Rückblicken und einem neuen funktionsübergreifenden Team. Es war wirklich nett, von Ihnen zu hören, und es gibt so viel, was unser Publikum von dem, was Sie heute mit uns geteilt haben, mitnehmen kann. Und ich hoffe, dass wir wirklich alle Zuhörer dazu inspiriert haben, rauszugehen und die Team-Retrospektive regelmäßig durchzuführen. Also, ja, danke.

Caitlin Mackie:

Vielen Dank, Chloe. Danke, dass du mich eingeladen hast. Es hat Spaß gemacht, Spaß, auf dieser Seite zu sein. Und ich hoffe, jeder genießt diese Episode.

Chloé Hall:

Danke, Caitlin.

Caitlin Mackie:

Danke. Tschüss.

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!