Easy Agile Podcast Ep.30 Ausgerichtet und erfolgreich: Die Macht der Teamausrichtung

Veröffentlicht am

July 19, 2023

Mitwirkende

Hayley Rodd

Partner Manager

Hör zu

Spotify
Apple-Podcasts
Einfacher Cast

Abonnieren Sie unseren Newsletter

„Jedes Mal, wenn ich Tony treffe, bin ich immer wieder erstaunt über seine Energie und Authentizität. In diesem Gespräch kam das wirklich zum Vorschein.“

In dieser Folge wird Hayley Rodd, Head of Partnerships bei Easy Agile, von Tony Camacho, Technical Director Enterprise Agility bei Adaptavist, begleitet. Sie befassen sich mit dem viel diskutierten Thema Teamausrichtung und erörtern, was es bedeutet, synchronisierte Ziele, funktionsübergreifende Zusammenarbeit und eine gemeinsame agile Denkweise zu haben.

Sie behandeln auch die grundlegenden Bausteine, um auf Ihrem Weg zur Teamausrichtung richtig anzukommen, wie z. B. die Fähigkeit, zuzuhören und Fehler als Lernmöglichkeiten zu betrachten, und betonen, wie wichtig es ist, rückblickende Maßnahmen umzusetzen und vieles mehr.

Wir wünschen euch viel Spaß mit der Folge!

Teile deine Gedanken und Fragen auf Twitter mit dem Hashtag #easyagilepodcast und tagge @EasyAgile.

Transkript:

Hayley Rodd:

Hier bei Easy Agile möchten wir dem Land eine Anerkennung aussprechen. Dies ist Teil unseres kontinuierlichen Engagements für Versöhnung. Easy Agile möchte sich bei den traditionellen Hütern des Landes bedanken, von dem aus wir senden und Sie heute treffen. Die Menschen des Darova-Sprachenden Landes. Wir zollen den älteren, gegenwärtigen und aufstrebenden Ältesten unseren Respekt und zollen allen Aborigines, den Bewohnern der Torres State Islands und den First Nations, die heute zuhören, den gleichen Respekt. Hallo zusammen und willkommen zum Easy Agile Podcast. Mein Name ist Hayley. Hier ist ein bisschen über uns hier bei Easy Agile. Also machen wir Apps für Jira von Atlassian. Unsere Anwendungen sind auf dem Marktplatz von Atlassian verfügbar und genießen das Vertrauen von mehr als 160.000 Nutzern führender Unternehmen weltweit. Unsere Produkte helfen dabei, ein flaches Jira-Backlog von Teams in etwas zu verwandeln, das visuell aussagekräftiger und leichter zu verstehen ist.

Von der Sprint-Planung über Retrospektiven bis hin zur PI-Planung eignen sich unsere Ups hervorragend für die Teamausrichtung. Apropos Teamausrichtung, genau darum geht es in dieser Episode. Heute gesellt sich Tony Camacho zu mir. Tony ist der technische Direktor von Enterprise Agility for Aligned Agility, das Teil der Adaptivity-Gruppe ist. Ich habe Tony während meiner Zeit hier bei Easy Agile ein paar Mal getroffen und gelernt, dass er einer der großzügigsten Menschen ist. Außerdem ist er lustig und ein kluger Mensch, der sich unglaublich gut mit Jira und einer Reihe anderer agiler Themen auskennt. Es ist wirklich wunderbar, Tony heute im Podcast zu haben.

Hallo zusammen, wir haben heute den wunderbaren Tony Camacho im Podcast. Dies ist unsere erste Aufnahme aus unserem Easy Agile Büro in Sydney, was super cool ist. Tony, ich bin mir nicht sicher, ob du es weißt, aber Easy Agile hat seinen Sitz in einem Ort namens Wollongong, der etwas südlich von Sydney liegt. Aber wir haben ein Büro in Sydney, weil wir kürzlich ein paar Teammitglieder aus Sydney eingestellt haben, die einen Ort wollten, an dem sie zusammenkommen und miteinander abhängen können. Also haben wir diesen Raum geschaffen, aber es ist 7:00 Uhr morgens, also bin ich jetzt ganz allein. So sehr liebe ich dich. Also Tony, lass uns mit den Fragen beginnen. Ausrichtung des Teams. Was bedeutet es für ein Team, tatsächlich aufeinander abgestimmt zu sein?

Tony Camacho:

Für uns in einem agilen Umfeld, das wir haben, ist es also ein kollektives Verständnis, eine Synchronisation Ihrer Teammitglieder mit Zielen, Prinzipien und Ihren Praktiken, an denen Sie arbeiten. Mehr noch, ich würde sogar auf den Punkt der Schrittfrequenz heruntergehen, Sie würden diese Synchronisationen haben. Es geht also darum, mit Ihren agilen Prinzipien und Werten, Ihrer Denkweise, Ihren gemeinsamen Zielen und Visionen, Ihren synchronisierten Arbeitspraktiken, DevOps, [unhörbar 00:02:44] konsistent zu sein, wie wir das veröffentlichen werden. Funktionsübergreifende Zusammenarbeit zwischen den Teams, um Ihre teamförmigen Partner/Teamkollegen in diesem Moment zum Glänzen zu bringen, voneinander zu lernen, Rollen, Verantwortlichkeiten, Dinge dieser Art. Das bedeutet es für mich. Das heißt wirklich.

Es dreht sich alles um Menschen und an diesem Punkt, dass sich alle an unserem gemeinsamen Ziel orientieren und daran arbeiten, das Ziel, das wir für den Geschäftspartner erreichen wollen. Da ist das Gold, hinter dem wir alle als Team her sind. Macht das Sinn für euch? Wir haben die gleichen Ziele für diese Initiative und unsere Praktiken. Und schließlich, was ich weiß, normalerweise nicht der Fall ist, ist, dass wir uns darauf einigen, welche Tools wir verwenden werden und wie wir sie einsetzen werden, und wir haben einen Systemquelldatensatz, aus dem wir wissen, wo wir unsere Truppen und unsere Abhängigkeiten platzieren können, um herauszufinden, welche Teams über Kapazitäten verfügen, und von dort aus weitermachen können. Das wäre meine allgemeine Definition eines agilen Teams.

Hayley Rodd:

Beeindruckend.

Tony Camacho:

Und Teams.

Hayley Rodd:

Sie hatten im Laufe der Jahre viel Erfahrung. Ich schätze, ich denke, wenn Sie all diese wirklich wunderbaren Dinge über Teamausrichtung sagen, ist, dass meiner Erfahrung nach eine Teamausrichtung darin besteht, dass die Leute alles richtig machen, super großartig ist. Wenn die Leute etwas falsch machen, ist es wirklich schwer. Und ich denke tatsächlich, dass es ziemlich schwierig ist, die richtige Teamausrichtung zu finden. Du musst wirklich daran arbeiten. Was ist deine Erfahrung damit?

Tony Camacho:

Für mich ist es so, als ob es eine schlechte oder eine großartige Ehe sein kann, aber es braucht Arbeit. Wie wir wissen, brauchen alle Beziehungen Arbeit. Wir sind Menschen, wir sind nicht dasselbe. Jeder von uns bringt etwas in die Wertetabelle ein. Lassen Sie mich Ihnen ein Beispiel nennen, mit dem ich in einem Team gelebt habe. Ich bin von Natur aus extrovertiert, und ich bin Entwickler, Ingenieur und normalerweise sind das nicht zwei Fähigkeiten, die man zusammen hört. Ich musste also lernen, dass, wenn ich mit meinen Teamkollegen zusammenarbeite, die manchmal introvertiert sind, langsamer fahren, zuhören, warten. Sie mussten auch lernen, schneller zu antworten, denn als Extrovertierte sehe ich Sie plötzlich an, wenn ich Ihnen eine Frage stelle, und ich denke, Sie verstehen die Frage nicht. Ich formuliere die Frage neu und jetzt haben Sie ein Defizit bei zwei Fragen.

Und jetzt geht es mir noch schlechter, weil ich jetzt sage: „Hayley versteht mich nicht. Was passiert hier? Lass es mich noch einmal anders formulieren.“ Und es kann leicht auseinanderfallen. Was ich gesehen habe, wenn Teams nicht aufeinander abgestimmt sind, ist, dass das Team kein Team mehr ist. Es ist miserabel, zum Team zu gehen. Es ist miserabel, zur Arbeit zu kommen, wenn das Team wirklich aufeinander abgestimmt ist und man rockt und rollt. Es ist ein Gefühl, wie du es noch nie hattest. Es ist schwer, den Leuten zu erklären, dass, wenn man das Team sieht, weil man es weiß, wenn es funktioniert und man offensichtlich weiß, wenn es nicht funktioniert, man anfängt, Termine zu verpassen. Integrationen finden nicht rechtzeitig statt. Sie haben keine einzige Informationsquelle. Du fängst an, dass Leute dasselbe in zwei, drei verschiedenen Angelegenheiten, unterschiedlichen Prioritäten erklären. Wir arbeiten nicht nach demselben Gesangbuch. Das Ding, das ich von meinem genommen habe... Ich bin ein SPC, also als Instruktor versuche ich immer, jedem zu erklären, dass du vielleicht das Beste von allem da draußen hast, aber das heißt nicht unbedingt, dass es zusammen funktionieren wird.

Sie müssen also ein Verständnis dafür haben, wie wir zusammenarbeiten werden, was unsere Prioritäten sind, welche Tools wir haben werden und was unsere Werte als Menschen für dieses Team sind, wenn das... Ich hoffe, das hilft, einige der Dinge zu beschreiben, die ich gesehen habe und die wirklich schief gelaufen sind. Ich habe es bei gesehen, ich kann einem Kunden mitteilen, dass ich gesehen habe, dass es weg ist, aber wir haben mit guten Absichten angefangen. Es ist ein Finanzinstitut in den Vereinigten Staaten und sie haben versucht, den Sprung zu mobilen Anwendungen zu schaffen. Und zuerst waren wir als Team auf derselben Wellenlänge, aber sie entschieden, dass sie nicht der Meinung waren, dass die Trittfrequenz überall gleich sein muss. Sie glaubten nicht, dass wir dasselbe Toolset verwenden könnten, wir könnten mehrere verschiedene Toolsets verwenden.

Sie hatten überall Tabellen im Umlauf. Und was passierte, war, dass wir das Vertrauen verloren haben. Wir haben die Arbeit überarbeitet, es gab überall Unklarheiten. Wir waren falsch ausgerichtet und haben angefangen, dafür zu bezahlen, weil unsere Kunden angefangen haben, sich zu beschweren. Sie konnten es an der Qualität der Arbeit sehen. Ein Team hatte ein Schema, einen Hintergrund, eine Art von... Man konnte den Unterschied sehen, als sie integriert wurden. Es schien, als wären es zwei Anwendungen, die zusammengefügt wurden. Und wenn Sie falsch ausgerichtet sind, macht sich das bei Ihrer Arbeit sehr, sehr schnell bemerkbar. Es gibt ein Sprichwort, das wir hier haben. Es gibt eine Scrum Masterin, ich weiß, sie hieß Sophia Chaley, eine der besten, die ich je getroffen habe. Und sie wird den Leuten immer sagen, dass das, was ein Team liefert, das ist, was das Team tut, ist Lernen. Es baut Wissen auf, es wird als Code ausgedrückt. Wenn wir falsch ausgerichtet sind, lernen wir verschiedene Dinge und drücken sie im Code anders aus, falls das Sinn macht.

Hayley Rodd:

Gibt es etwas, das ein Team wirklich richtig machen muss, um bei der Abstimmung erfolgreich zu sein, beispielsweise über die grundlegenden Bausteine der Teamausrichtung nachzudenken? Und was ist das in deinem Kopf?

Tony Camacho:

Oh, das ist sicher. Das mussten sie richtig machen. Zuallererst die Größe des Teams.

Hayley Rodd:

Ja, okay.

Tony Camacho:

Menschen, und ich melde mich nicht zurück... Um noch einmal zu sagen, was unsere Scrum-Methoden angeht: Ich bin ein CSM. Ich weiß, dass sie 8 bis 13 Personen empfehlen. Meine besten Teams waren in der Regel etwas größer. Aber wir mussten uns auch auf die Größe des Teams einigen, wo es nicht zu groß wurde, wo wir uns überrannten und einander nicht zuhörten. Wir mussten unsere Ziele verstehen. Wir hatten alle die gleichen Ziele. Wir haben das geübt, indem wir, als ich bei Microsoft gearbeitet habe, das hatten, was wir früher unsere Fahrstuhlsprache nannten. Und wir haben jemanden angehalten und ich würde gehen, wir arbeiten daran. Achte diesbezüglich auf deine Rede im Aufzug. Und wenn deine Rede im Aufzug nicht wäre... Es war nicht gemeint, dass es mit den Minen synchron sein muss, aber wenn ich es nicht verstand, hatten wir ein Problem.

Oder wenn es ein anderes Ziel wäre, wo ich dich sehe, aber wir bauen einen Volkswagen, aber du beschreibst mir einen Lamborghini, dann haben wir ein Problem. Und solche Dinge mussten wir auch haben, um sicherzustellen, dass wir die richtigen... Dieselben Praktiken und Tools. Das ist der Punkt, an dem Easy Agile meiner Meinung nach übertrifft. Ich meine, es übertrifft einfach, es übertrifft den Markt. Es ist transparent und es zeigt alles, was vor dir liegt, direkt für mich. Als wir also dasselbe Tool hatten und wir den gleichen Rhythmus hatten und wir unsere Abhängigkeiten sehen konnten und wir konnten sehen, was ich für jemand anderen zu liefern hatte oder jemand es für mich liefern musste, das war die Art von Dingen, die wir hatten. Wir mussten Respekt haben. Jemand scheint immer zu vergessen, dass wir immer Respekt voreinander haben mussten.

Wir mussten uns dieselben Werte wie Zusammenarbeit, Anpassungsfähigkeit und Transparenz zu eigen machen. Die Praktiken, die wir alle kennen, aber irgendwie vergessen wir, wenn wir an einen Punkt kommen, an dem wir nicht übereinstimmen und wenn Sie meine Ideen respektieren und ich Ihre respektiere und wir zusammenarbeiten, müssen wir uns nicht einigen. Aber dieser Respekt wird uns ein gutes Stück näher bringen, um die Projektvision zu erreichen, die wir uns wünschen. Und wir versuchen, die Bedürfnisse des Kunden zu erfüllen. Und das sind die Dinge, die wir brauchten. Wir brauchten Führung. Führung, das kann ich nicht sagen, und wenn Sie merken, dass ich das Wort Management nicht verwende, ist Führung, wenn Sie sich in eine Situation begeben, in der es für Sie als Person, als diese Führungskraft, schlecht werden kann, indem Sie versuchen sicherzustellen, dass wir die richtigen Entscheidungen treffen, die Menschen stärken und ihnen klar machen, worüber sie Entscheidungen treffen können und nicht. Und es klingt so einfach, wenn ich so mit Ihnen spreche, aber jedes Mal, wenn ich irgendeine Art von Transformation durchführen musste, das Gepäck, das wir als Menschen manchmal mit sich bringen, die Ängste, der Mangel an Vertrauen, den wir haben, da kommen die Scrum Master oder Product Owner ins Spiel. Und dann brauchen Sie etwas, das sicherstellt, dass Sie diese Vision haben, um diese Vision zu vermitteln. Wie ich bereits erwähnt habe, einige der Toolsets, die wir da draußen haben. Macht das für dich überhaupt Sinn?

Hayley Rodd:

Ja, das tut es wirklich. Es findet wirklich großen Anklang bei mir. Ich denke, wenn man davon spricht, als Team zusammenzukommen und eine Reihe von Werten und eine Vision zusammenzustellen, kommt es einem wie ein „Duh“ -Moment vor. Es ist so, als würdest du das natürlich als Team machen, aber ich denke, am Ende des Tages als Teams gehen wir wie gewohnt ins Tagesgeschäft und wir denken, ich habe keine Zeit, als Team zusammenzukommen und diese Vision zu formulieren, weil ich X, Y und Z machen muss, das ist nächste Woche fällig. Aber ich denke, es ist einer dieser grundlegenden Bausteine, die Sie wirklich auf Erfolg vorbereiten, wenn Sie X, Y, Z später schneller machen. Das ist es also, was ich daraus mitgenommen habe.

Tony Camacho:

Und ich würde dir zustimmen. Und du hast dir ein perfektes Beispiel ausgedacht, weil viele Leute das tun. Ich muss nächste Woche täglich ABC erledigen. Ich habe keine Zeit. Und das Problem ist, wenn sie es plötzlich merken würden, und das wird in Ihren Praktiken offensichtlich. Wenn du dich also auf deine Übungen, deine täglichen Standups geeinigt hast, wenn du das tust, deine Rückblicke am Ende deiner Sprints und wenn die Person das Gefühl hat, dass sie diesen Respekt vor dir hat und keine Angst hat, kann sie dir das mitteilen: „Hayley, ich habe ein Problem. Ich habe viel zu viel Arbeit. Ich weiß nicht, ob ich hier von Wert sein werde. Oder brauchst du mich wirklich?“ „Ja Tony, ich brauche dich, wir werden das besprechen und lass uns deine A, B, C besprechen und sehen, wie ich dir helfen kann.“ Und plötzlich wurde ihnen klar, dass sie nicht alleine auf einer Insel sind. Da Entwickler von Natur aus introvertiert sind, müssen wir diese Angewohnheit durchbrechen. Wir müssen teilen können. Und es ist lustig, ich sage nicht, dass ich mein Mittagessen teile, gut, klar, lass uns unser Mittagessen teilen, aber teilen wir uns die Arbeitsbelastung.

Die eine Sache, die ich den Teams gegenüber immer zu erwähnen versuche, und das ist wieder... Es tut mir leid, aber ich glaube an Easy Agile und verwende dieses Tool. Das ist der Punkt, an dem Easy Agile es auch für mich deutlich macht. Eine Geschichte gehört einem Team, nicht einer Person. Und wenn du das weißt, merkst du plötzlich, dass ich nicht allein bin. Ich arbeite hier als Teil einer größeren Sache. Und die meisten Menschen wollen Teil einer größeren Sache sein. Plötzlich merkt man, dass es fast wie die Baseball-Metapher ist, die ich für Teams verwende. Und ich weiß, der Markt ist nicht Baseball, aber ich denke, das würde auch für andere Sportarten gelten, sei es Cricket oder solche Sportarten. Wenn ich schlage, trete ich gegen jeden an. Wenn ich auf dem Spielfeld bin, sind wir gegen... Ich bin lieber bei uns. Und im Allgemeinen sind solche Dinge da, lass uns das machen.

Außerdem, wenn man mit mehr Leuten als Team arbeitet, gibt es Dinge, die dort passiert sind. Sie minimieren das Projektrisiko, was ich hasse, wenn ich das Wort Projekt verwende. Es sollte Initiative sein. Es lebt lange. Normalerweise bist du viel anpassungsfähiger. Ich kenne nicht alle Antworten. Also, als ich mit dir gearbeitet habe, Hayley, und du mir dort einige Dinge gezeigt hast, warst du einer der bescheidensten Menschen, die ich je getroffen habe, und ich habe es geliebt. Aber als du durchgegangen bist, du hast mir das Tool gezeigt, es wurde sehr offensichtlich, du weißt es, du fühlst es, du liebst es, es ist ein Teil von dir. Und das ist für mich belebend. Das ist Energie. Wer würde nicht mit jemandem wie dir arbeiten wollen? Warum nicht? Lass uns das machen. Richtig?

Hayley Rodd:

Danke Tony. Ich denke, eines der Dinge, die ich ansprechen wollte, ist, wenn man in einem Team ist und als Team zusammenkommt, an etwas arbeitet. Wie geht es einer Person, die Anerkennung für das sucht, was sie tut, wie bekommt sie das? Oder wie lässt man das stehen? Wie legt man dieses Ego beiseite und sagt: „Ich mache als Team etwas zum Wohle des Teams?“ Bist du jemals darauf gestoßen oder hast du darüber nachgedacht? Ich bin an deinen Gedanken interessiert.

Tony Camacho:

Also die Leute, von denen ich dachte, dass sie das brauchen, so wie ich... Ja, das ist eine gute Frage, denn ich denke konkret nach. Es gab einen, einen Scrum Master, von dem ich dachte, dass er das auf die erstaunlichste Art und Weise gemacht hat, die es je gab. Im Grunde würde sie die Ideen herausfordern, auch wenn es nicht die dieser Person wären, ja. Ich finde, Hayley ist... Du hast keinen guten Tag, Hayley. Du hast keinen guten Tag. Und ich weiß, du gewöhnst dich nicht daran, im Scrum-Team zu arbeiten. Es ist neu für dich und alles andere. Und was sie normalerweise getan hat, war vor allen, und manchmal war es nicht einmal deine Idee. Und sie sagte einfach, und Hayley hatte diese wundervolle Idee, die uns etwas ersparen und uns voranbringen wird. Hayley hat das zu mir gesagt, es hat uns dazu gebracht, als Team zu denken. Und wir haben es umgangen, wir haben geredet und wir haben es geschafft.

Und diese Person sagte normalerweise immer: „Wow, ich habe Anerkennung für etwas bekommen. Gute Scrum-Master werden das sehen. Oder gute Produktbesitzer werden darauf hinweisen.“ Die andere Art, wie ich es gemacht habe, war so etwas wie Easy Agile zu verwenden. Es ist ein großartiges Tool, ob Sie es glauben oder nicht. Ich würde mich zurückziehen, ich bin Entwickler, aber ich habe auch jahrelang die Rolle des Scrum-Masters gespielt. Ich würde einen Schritt zurücktreten und einen meiner Teamkollegen die Leitung übernehmen lassen, ihre Stimme hören und mich gestärkt fühlen. Es ist unglaublich, wenn sich die Leute gestärkt fühlen, denn worüber Sie alle sprechen, geht es wirklich um mangelndes Vertrauen, um einen Mangel an psychologischer Sicherheit. Und es liegt an uns, ein eingespieltes Team zu sein, da muss man Vertrauen haben und man muss die Angst vor einem Urteil abbauen. Die andere Sache, die einmal mit einem Scrum Master passiert ist und die ich wunderbar fand, war, dass die Chefin wieder gegen Sophia Chaley vor ihrem Zimmer stand, als es einen schlechten Sprint gab.

Der Sprint endete nicht gut. Und sie stand vor allen auf und sagte im Grunde: „Manchmal gewinnst du, manchmal lernst du. Das war ein Lernsprint.“ Sie hat Easy Agile aufgerufen, das sie gleichzeitig benutzt hat, hat es hochgezogen und die Dinge gezeigt, die nicht so geklappt haben, wie sie dachten, dass sie funktionieren würden. Und sie sagte, das sind die Maßnahmen, die wir ergreifen werden, um das zu verbessern. Und dann, als jemand, der im Management war und wieder nicht den Begriff Führung verwendete, jetzt verwende ich den Begriff Management mit Absicht, Schuldzuweisungen zu machen. Ihre Antwort war, nicht zu schreien, nicht ihre Stimme zu erheben. Ihre Antwort war, wenn wir jemanden loswerden oder jemandem die Schuld geben müssen, geben Sie mir die Schuld. Aber ich bin hier, um das Problem zu lösen. Lass uns weitermachen.

Hayley Rodd:

Beeindruckend.

Tony Camacho:

Sie wollte es nicht sagen. Und das war für mich einer der herausragendsten Momente, die ich je gesehen habe. Und zu diesem Zeitpunkt nutzte sie tatsächlich Easy Agile, das kein Finanzinstitut in den Vereinigten Staaten war. Ich würde Sie wissen lassen, dass Lehrer es verwenden, finden Sie es heraus. Und im Grunde hat sie das Board gezeigt und einfach alles durchgesehen und das gemacht. Das war Führung. Das war Führung. Und in der Regel folgen Ihre Teams der Führung und plötzlich treten sie auf und Sie werden sehen, dass das die Leute sind, die sich wehren wollen. Nun, nicht jeder will das tun. Manche Leute wollen einfach nur Teammitglieder sein und das ist okay. Das ist völlig okay, aber was nicht okay ist, ist, dass, wenn sie kein Vertrauen haben, oder? Und für mich ist das das Wichtigste. Wenn du Menschen hast, die sich dem Wandel widersetzen oder in ihrer Welt isoliert sind, erkennen sie plötzlich, wenn du sie dazu bringen kannst, sich zu öffnen, sagen sie dir nur, dass ich mich nicht sicher fühle.

Ich mache das schon mein ganzes Leben lang. Ich bin großartig darin und jetzt bittest du mich darum. Und du musst sie irgendwie dazu bringen, das Gefühl zu bekommen, dass sie etwas Wertvolles mitbringen. Sie helfen dir, voranzukommen. Und du triffst sie auf halbem Weg, wenn du musst. Aber ja, das ist das größte Problem, das ich je gesehen habe und das wir immer, es kommt immer auf den Menschen an. Den Rest kannst du immer kommen, das kannst du jederzeit ändern. Aber es gibt einige Dinge, die du auch tun musst. Ich glaube, dass manche Leute Hayley über den Weg laufen, dass ich und du in unserer Welt leben, während wir aufsteigen, manchmal sind wir es, es gibt eine Unklarheit der Dinge, die wir tun müssen. Und ich habe gesehen, wie du das gemacht hast, Leute in unseren Rollen werden sie plötzlich übernehmen, auch wenn das nicht Teil unserer Rolle ist, und wir müssen lernen. Das ist alles. Aber ja.

Hayley Rodd:

Ja, ich denke, ja, es ist so wahr, dass die [unhörbare 00:19:23] psychologische Sicherheit da sein muss. Und ich denke an so viele Teams zurück, denen ich angehört habe, dass sie nicht da ist. Sie müssen also das Gefühl haben, etwas zu prägen oder Ihren Stempel aufzudrücken und Ihren Wert unter Beweis zu stellen. Denn wenn Sie Ihren Wert nicht unter Beweis stellen, werden Sie befragt. Ich denke, das ist so häufig, was ich in Teams sehe, und es entsteht tatsächlich keine Kameradschaft, sondern ein Wettbewerb zwischen Teamkollegen und es entsteht ein falsches Umfeld. Es ist also einfach wirklich interessant. Eine Sache, die ich ansprechen wollte und über die Sie vor ein paar Fragen viel gesprochen haben, war Respekt und dafür zu sorgen, dass Teams Respekt voreinander haben. Wie zeigt ein Teammitglied Respekt vor seinen Teamkollegen? Was sind einige wirklich gute Beispiele für Respekt und wie können wir ihn als Teammitglieder zeigen oder verkörpern oder entsprechend umsetzen?

Tony Camacho:

Lassen Sie mich Ihnen jetzt einen Mangel an Respekt zeigen. Ja. Hayley, wir sprechen darüber.

Hayley Rodd:

Ich schaue aus der Kamera, weiche mir aus. Ja.

Tony Camacho:

Eines der wichtigsten Dinge war, wirklich zuzuhören zu lernen. Setz dich hin, ob du es glaubst oder nicht, ich fand, dass es manchmal das Beste ist, tief durchzuatmen, zuzuhören, nicht zu reagieren, zu erkennen, was diese Person in diesem Moment fühlt und durchmacht, weil es schwer ist, was wir tun. Es ist halb Kunst und halb Wissenschaft. Lassen Sie sie lernen, dass ein Fehler kein Misserfolg ist, sondern ein Lernmoment. Führen Sie diese Diskussion dort. Nehmen Sie ihre Bedenken ernst. Es ist lustig, weil du mich gerade an etwas denken lassen hast. Das ist eine Sache, bei der ich meinen Teamkollegen Respekt entgegenbringen könnte, wenn ich als Scrum Master effektive Retros abhalten würde. Höre wirklich zu, was sie in den Retros sagen, berichte über die Dinge, von denen du gesagt hast, dass du sie in den Retros verbessern wirst. Also haben wir gesagt, das sind die drei Dinge, die wir verbessern werden, oder das sind Dinge, die mir zugewiesen werden.

Mach es real. Mach eine Geschichte draus. Zeig es an die Tafel und sag: „Hier gehen wir hin. Das ist es, was passiert. Das ist es, was mich blockiert. Kann mir jemand helfen?“ Aber ich arbeite das für dich. Schnapp sie dir, sei wirklich aufrichtig. Ich meine nicht, Pizza zu kaufen oder eine Menge mitzubringen. Scrum Master bringen Pizza und Donuts ins Büro. Nein, es macht ihr Leben wirklich besser. Sei dieser Anwalt, der sich für sie einsetzt. Und wenn Sie ein Teamkollege sind, setzen Sie sich füreinander ein und seien Sie aufrichtig. Habt den Mut, aufzustehen und zu sagen, dass das keine faire Bewertung ist. Aber das Wichtigste ist, wirklich zuzuhören. Denn oft, wenn mir jemand etwas sagt, mache ich es persönlich. Ich, das habe ich manchmal, ich weiß, ich fühle mich unwohl, aber ich kann nicht erklären warum. Und wenn du da bist, mich ansiehst und redest und durchgehst, wird mir plötzlich klar, dass es vielleicht etwas anderes war und ich möchte deine Ideen hören.

Aber ich müsste, wenn ich zeigen wollte, dass ich diesem Teamkollegen helfe, auch mich verwundbar machen. Wenn du zu mir kommst, sollte ich das mit dir teilen, aber ich sollte aktiv zuhören, oder? Und ich respektiere wirklich deine andere Sichtweise. Es ist okay. Wir haben alle unterschiedliche Perspektiven. Das Problem, das ich finde, ist, dass wir uns in unserer Welt so schnell bewegen, dass wir manchmal nicht aufhören, zuzuhören. Es fehlt uns an Geduld. Wir bewegen uns zu schnell. Also werde ich eine für Sie teilen, die ich aufrichtig ausdrücken werde. Mir ist medizinisch etwas passiert und ich ging etwas aggressiv mit dem Team um. Also habe ich endlich ein Treffen mit unserem Team einberufen und sie haben mich weinen sehen. Ich war damit einverstanden. Ich sagte: „Ich hatte keinen Grund, so zu sein. Ihr habt mir Liebe gezeigt, ihr habt mir Respekt entgegengebracht, ihr unterstützt mich, helft mir bei meiner Arbeit. Und ich war immer noch absolut schrecklich.“

Und es hat mir wehgetan. Es tat weh, dass ich das getan habe, aber sie mussten mich sehen und ich brauchte sie, um mir zuzuhören, mir diese Sekunde zu geben, um es von meiner Seele zu bekommen. Und am Ende fing ich an zu weinen. Ein 60-jähriger Mann weinte in einer Besprechung und sagte: „Das hätte ich dir nicht antun sollen. Das war falsch.“ Und es wurde nicht erfunden. Einige der Leute dort waren 20-jährige Leute in meinem Team und sie weinten. Und weil sie das Gefühl hatten, sie sagten es mir danach, sie fühlten meinen Schmerz, in dem ich war, weil ich helfen wollte. Es ist die frustrierendste Sache. Zu deinem vorherigen Punkt, wie fühle ich mich? Ich wollte helfen. Ich wollte dort sein und ich konnte nicht. Körperlich war ich nicht da. Mein Verstand war überall und ich war unhöflich, unverblümt und ich könnte ein paar andere Begriffe gebrauchen. Bitte nicht. Aber das ist wirklich die Hauptsache für mich, es ist wirklich einfach, was wir tun. Ich höre einfach zu und zeige einfach Respekt vor anderen Menschen. Und manchmal vergessen wir es.

Hayley Rodd:

Ich denke, viele der Botschaften, über die Sie sprechen, richten sich nicht nur an Entwicklerteams, sie richten sich an jedes Team, jedes Team in allen Lebensbereichen. Ich denke, sie sind einfach so grundlegend für erfolgreiche menschliche Beziehungen, egal ob es sich um persönliche oder berufliche Beziehungen handelt, ich denke schon. Ich denke, es gibt einfach so viele gute Botschaften. Eine Sache, die ich ansprechen wollte, war, dass Sie über aktives Zuhören sprechen und wenn Sie an Ihre Karriere zurückdenken, und vielleicht ist das völlig außerhalb des Drehbuchs, aber wenn Sie an Ihre Karriere zurückdenken, wie sind Sie im Laufe der Jahre ein besserer aktiver Zuhörer geworden? Wie haben Sie diese Fähigkeit verbessert? Wie du schon sagtest, du bist extrovertiert, du willst da rein, du willst das Problem lösen. Wie wirst du darin besser?

Tony Camacho:

Ich hatte einige sehr, sehr kluge Leute, die sich mit mir abgefunden haben, mir zugehört haben und dann den Mut hatten, mich danach anzusprechen und mich zu unterrichten und mich vor niemandem in Verlegenheit zu bringen. Ich habe es so gemacht, dass sie sagten: „Glaubst du, das hätte vielleicht besser sein können, Tony?“ Wie gesagt, ich bin 61 und immer noch extrovertiert und ich habe immer noch viel Energie und mache immer noch Fehler. Wie ich allen sage, mache ich jeden Tag, an dem ich aufwache, einen Fehler, ich bin einfach aufgestanden. Aber ich hätte länger im Bett bleiben können. Aber auch das, was ich gelernt habe, und es liegt einfach in der Natur des Älterwerdens, es gehört nicht zum Alter. Ich sah zu, wie Leute kamen und versuchten, das Gleiche zu tun wie ich, woran ich gescheitert bin, und ich war lange Zeit Dozent für Microsoft.

Und zu sehen wie, denn für mich ist es unglaublich zu sehen, wie der Geist einer Person funktioniert. Also was passiert ist, ich werde einfach... Weißt du, was ich versucht habe, es hat bei mir nicht funktioniert, aber ich werde sagen, nach dem Unterricht mit dir, dass du es mir noch einmal zeigst, weil du es vielleicht gelöst hast. So arrogant bin ich nicht. Und es liegt in der Natur unserer Sache, dass ich finde, dass je mehr man lernt, desto mehr merkt man, wie wenig man weiß. Das war das Größte, was mir die Augen geöffnet hat. Jetzt ist es wie, oh mein Herr. Du triffst jemanden wie John Kern, du triffst jemanden wie Sophia Chaley, die aus verschiedenen Perspektiven kommen, brillante Menschen, und du siehst plötzlich, dass sie Dinge etwas anders machen und du beobachtest sie einfach und du sagst: „Wow.“ Und das, was ich an unserem Job liebe, was Sie bestimmt lieben müssen, egal wo wir hingehen, in jedem Team, mit dem wir arbeiten, das ist anders. Es ist anders.

Jeder fragt mich immer, wie du das machst. Und ich werde ihnen sagen: „Schau, ich werde mit dir teilen, wie ich es gemacht habe. Ich habe einen vielfältigen Hintergrund. Ich habe schon immer beraten.“ Ich habe den ATM-Bereich gemacht, ich habe für weltraumgestützte Kriegsführung gearbeitet, ich habe für die Gesundheitsindustrie gearbeitet, jeder war anders. Jemand aus der staatlichen Regulierung, aber meistens andere Menschen. Ich habe ein Sprichwort, ich habe mir jede Narbe in meinem Rücken verdient, ihren Verstand. Ich habe gelernt, dass man Menschen die Chance geben muss, ihre Narben zu bekommen. Ja, es kann Schmerz sein, ich sage nicht, scheitere nicht, ich lasse sie nicht scheitern. Aber manchmal wollen die Leute etwas tun. Also so würde ich es machen. Lass sie das machen. Und ich habe einfach zugesehen und gelernt, was passiert ist, als ich reingegangen bin und je mehr ich gelernt habe, und plötzlich wurde mir klar, wie wenig ich weiß, ich dachte, ich habe mit FORTRAN angefangen, ich habe früher in den Toten gearbeitet 28.

Und dann arbeitest du dich hoch und merkst: „Wow, ich weiß nicht so viel, wie ich dachte zu wissen.“ Und ich hatte das Glück, bei Microsoft zu arbeiten und das Vergnügen zu haben, Bill Gates kennenzulernen. Nun, egal, was Sie über Bill Gates sagen, denn viele Leute sagen einige verrückte Dinge und einige davon mögen wahr sein oder auch nicht. Aber das einzige, was du ihm nicht wegnehmen kannst, ist, dass du mit ihm in einen Raum gehst und plötzlich siehst, wie er all diese Ideen zusammenfügt und zu einem größeren Bild kommt. Plötzlich merkst du: „Wow, die Leute sagen mir, dass ich wirklich schlau bin, nicht so schlau.“ Und dann lernst du, Demut ist eine gute Sache.

Hayley Rodd:

Ja, ich denke, Demut ist einfach ein so wichtiges Gut, das man haben und versuchen muss, weiterzuentwickeln, denn sein Ego an der Tür zu lassen und offen zu sein, um von anderen Menschen zu lernen und nicht zu denken, dass alles definitiv eine Lektion fürs Leben ist, die man manchmal durchmachen muss. Und manche Menschen machen das durch und nehmen ihnen trotzdem nicht die Lektion fürs Leben. Also ja, ich finde es so interessant. Ich schätze, wir haben nicht mehr viel Zeit, aber ich wollte kurz darauf eingehen, wie wir es aus Sicht des ROI betrachten. Wie wichtig ist die Ausrichtung des Teams im Hinblick auf die Kapitalrendite? Was gewinnen Sie aus geschäftlicher Sicht, wenn Sie ein aufeinander abgestimmtes Team haben?

Tony Camacho:

Also werde ich einen Begriff verwenden, den ich nicht mag, und Hayley, du kannst mich schlagen, wenn wir uns das nächste Mal treffen. Aber ich versuche es so zu verwenden, dass ich es nicht tue, weil es eine effektive Ressourcennutzung ist, oder? Aber ich beziehe mich in diesem Punkt nicht auf Menschen, weil es vielleicht Menschen sind. Das Problem ist, dass das ein großer Markt ist. Aber als agile Menschen werde ich Sie nicht als Ressource bezeichnen, ich bezeichne Sie als Mitmenschen, Sie sind ein Partner in meinem Team. Du bist mein Teamkollege. Du bist kein Stück Holz. Aber das ist leider ein Begriff, der verwendet wird. Und wir werden eine effektive Nutzung haben, wir werden in unserer gesamten Organisation gemeinsame Ziele verfolgen. Wenn Sie eine der Botschaften verwenden — weniger, schlecht, sicher — wählen Sie sie aus und Sie beginnen, sich auf Ihre Wertströme zu konzentrieren. Sie hätten die Produktqualität verbessern sollen, weil wir den gleichen Rhythmus haben. Wir veröffentlichen Dinge und wir haben da die gleichen Ansichten.

Sie werden meiner Meinung nach eine bessere Kundenzufriedenheit und Loyalität haben. Sie stellen fest, dass Ihre Produktqualität steigt, dass Sie konsistent sind, dass sie aussehen und sich anfühlen, und hoffentlich liefern Sie, was sie wollen. Wenn Sie Ihre Teams aufeinander abgestimmt haben, sind Sie viel anpassungsfähiger. Hayley, hat dein Team Kapazitäten? Hab ich nicht. Dafür sind wir nicht in der Lage. Haben Sie Kapazitäten? Ja, das tue ich. Oder wir finden jemanden oder wir brechen es gemeinsam auf und präsentieren unseren Partnern eine Idee. Das sind die Dinge, die ich mag und ich denke, am Ende haben Sie zu diesem Zeitpunkt die Risiken reduziert.

Außerdem denke ich, dass die Sache, die sie haben, ist, dass es indirekt ist, aber niemand weiß davon. Niemand spricht wirklich darüber, wenn ich in der oberen Führungsebene wäre, wenn wir damit beginnen und die Teams aufeinander abstimmen, werden Ihre Teams zuallererst sicherer, Ihre Teams fühlen sich wohler, sie arbeiten mit denselben Leuten zusammen. Sie werden sehr effektiv und fangen an, Ideen zu entwickeln. Sie sind die Wissensarbeiter. Sie wissen das besser als jeder andere und fühlen sich dann befähigt, Ideen auszutauschen. Ich dachte immer, ich hätte die besten Teams, als sie gefragt wurden... Nun, und ich habe es verstanden, ich weiß nicht wie, ich fuhr einen Zug und sie baten darum, mit dem CTO zu sprechen und alles, was sie wollten, war, mit dem CTO zu sprechen und diese Person menschlich zu machen. Sie fragten sie, was sie in einem früheren Job gemacht hat. Unglaublich. Sie arbeitete als Fabrikarbeiterin und auch im Bauwesen. Sie ist früher Auto gefahren, eines der Dinge, niemand hätte das geglaubt. Und was passierte, war, dass sie anfingen, Ideen mit ihr zu teilen und sie nahm sie an. Weißt du, was das mit dem Team gemacht hat, die Teams alle, sie sagten, jetzt ist das da draußen, das gehört uns. Sieh dir das an. Das war unseres. Ich meine Eigenverantwortung, das ist unglaublich.

Und leider arbeiten wir auf einem kapitalistischen Markt, was in Ordnung ist, das sind wir. Ich meine, wir sind in der IT tätig, das ist eine Kapitalrendite. ROI Am Ende sehen Sie eine viel effizientere Verwendung Ihres Geldes, eine viel effizientere Verwendung Ihrer Dollars. Außerdem könnte ich mir vorstellen, dass die Leute oben, die in der C-Suite sind, plötzlich erkennen, dass die Organisation in die gleiche Richtung geht. Ich denke, psychologisch gesehen haben sie das Gefühl, dass wir jetzt dieses Team hinter mir haben, das auf dasselbe Ziel hinarbeitet. Oft, jedes Mal, wenn ich eine agile Transformation durchführe, hören wir als Erstes, dass wir wissen, dass sie arbeiten. Wir wissen nicht, woran sie arbeiten. Und da überbrückt so etwas wie Easy Agile das, und dann können Sie diese Informationen verwenden, um noch weiter zu gehen. Und das ist wunderbar, denn dann sind alle auf derselben Wellenlänge. Ihr seid jetzt also von vorne bis hinten ein Team. Im Gegensatz dazu gehe ich zu meinem Team bei der Arbeit und das war's. Es geht also wirklich um die Kapitalrendite und darum, sicherzustellen, dass wir unsere Kunden mit allem, was wir haben, erreichen. Und ich meine nicht schlecht, aber wir liefern für unsere Kunden mit allem, was wir haben. Es ist jetzt Effizienz, oder? Und das war's. Das war's auch schon.

Hayley Rodd:

Ja, das ist so mächtig. Ja, ich finde, das verbindet alles gut, weil wir in der letzten halben Stunde oder so über viele Dinge gesprochen haben. Und ich denke, wenn Sie es schaffen, das Team aufeinander abzustimmen, genau wie Sie es gesagt haben, gibt es diesen ROI, der sich wirklich durchsetzen kann, und es ist eine wichtige Sache für das gesamte Unternehmen, alles richtig zu machen und die Früchte dieser Arbeit zu sehen. Also eine letzte Sache. Können Sie uns Ihre Sicht auf die PI-Planung mitteilen? Ich weiß, dass Sie Safe gerade ein bisschen erwähnt haben, weil es das erste Sprungbrett für die Teamausrichtung ist.

Tony Camacho:

Ich liebe es. Du hast alle im Raum, du lernst die Leute kennen, du fängst an, diese Verbindungen zu Leuten herzustellen. Du fängst an, sie als Menschen zu sehen, nicht als diese E-Mail oder diesen Text, den du rüberschickst, den du da durchmachst. Könnte ich also eine echte Erfahrung daraus teilen? Das ist ein PI-Planungshaus.

Hayley Rodd:

Bitte

Tony Camacho:

Tun. Also, als ich bei Microsoft gearbeitet habe, habe ich online für Produktqualität gearbeitet, was ich gerade weiß, wenn man die Probleme bedenkt, die Microsoft hat. Jetzt sagst du quasi: „Du bist zum Kotzen, Tony.“

Hayley Rodd:

Niemals.

Tony Camacho:

Nein, wir hatten unsere Leute auf der ganzen Welt verteilt. Und was passierte, war, dass, wenn ich mit meinen kleinen Teams sprach, ich sie fragte, und ich war an einem Punkt scherzhaft, weil ich einfach nicht die wahre Antwort bekommen konnte, war, dass ich ihn fragte, ob Sie die Twin Towers bis morgen bauen können? Und die Antwort würde versehentlich Ja lauten. Der nächste Tag würde kommen. Natürlich kann man die Twin Towers nicht über Nacht besichtigen. Frag sie noch einmal, bekommst du es bis nächste Woche? Die Antwort wäre ja. Und sie hatten ein Gefühl für all das. Und als wir die PI-Planung hatten, haben wir das getan.

Microsoft ging, bekam ein Hotelzimmer in Seattle, ein Hotelzimmer, ein Hotel in Seattle, rief unsere Offshore-Teams an. Und als sie mich dann persönlich sahen, wurde ihnen plötzlich klar, dass ich ihnen nicht sagen wollte, dass ich die Twin Towers bis morgen brauche. Ich wollte wirklich, dass sie mir sagen, wann sie mir die Zwillingstürme besorgen können. Und ich würde es verteidigen, weil sie mich direkt bei der Planung und Verteidigung der PIs gesehen haben und gesagt haben: „Nein, das ist nicht möglich.“ Und als sie mich dabei sahen, war es plötzlich so, als ob der Himmel offen ist, die Sonne scheint durch und jetzt bekomme ich echte Antworten. Und was passiert ist, war, dass es ihm eine Chance gab. Und mir wurde klar, Leute, ihr hört mich ständig als Predigt. Es geht immer um die Menschen, es geht um diese Verbindungen. Es geht darum, die Menschen zu sehen. Es ist schwer. Es sind zwei Tage voller Arbeit. Aber wenn du diese Arbeit erledigt hast, kommst du da raus in einer scharfen Richtung. Wir wissen jetzt, was unser Norden ist, wissen wir genau, wo unser wahrer Norden ist? Als agiles Team sollten wir das nicht tun, oder? Wir sollten es verfeinern, wenn wir dort ankommen.

Finde es genau heraus. Aber wir wissen mehr oder weniger, wo die Richtung ist. Wir wissen mehr oder weniger, dass wir alle auf derselben Wellenlänge sind. Wir alle wissen, dass das, was wir liefern müssen, damit das funktioniert, was andere Menschen für uns leisten müssen oder wir für andere Menschen liefern müssen. So fühlen wir uns plötzlich als Teil von etwas Größerem. Größer, richtig? Wir sprechen jetzt mit den, wenn Sie Entwickler oder Ingenieur oder Softwareingenieur sind, beginnen Sie, die Machthaber zu verstehen und zu verstehen, warum sie das tun. Sie haben die Möglichkeit, ihnen Fragen zu stellen. Was könnte man mehr verlangen, oder? Endlich sehe ich die Leute, die die Entscheidungen treffen, und ich kann sie fragen, warum. Und sie können mir sagen, was der Geschäftswert ist, und ich kann ihnen gegenüber das Argument vorbringen, dass ich vielleicht nicht denke, dass das so viel Geschäftswert ist oder dass wir diese Dinge zuerst korrigieren müssen, bevor wir das richtig machen und weitermachen können. Was könnte ich mehr verlangen? Ich habe die Gelegenheit, meine Argumente vorzubringen, und ich lerne die anderen Leute kennen, mit denen ich zusammenarbeite. Es wird so, wenn man es mit 125 Leuten zu tun hat und in einem Zug sitzt, wird man zur Familie.

Manchmal verbringen wir mehr Stunden mit diesen Menschen als manchmal mit unseren Familienmitgliedern. Und es gibt dir auch ein Gefühl von... Neben Vertrauen auch ein Gefühl von Sicherheit. Du weißt, es geht nicht nur um dich, es geht um uns alle. Also das Sprichwort, dass ich normalerweise sehe, dass die bessere Führungskraft sagt, ich habe gehört, dass bei einer PI-Planung Sie scheitern, ich scheitere. Ich scheitere, du scheiterst. Meine Aufgabe ist es, Sie zu beschäftigen. Ihre Aufgabe ist es, mich zu beschäftigen und diese Firma zusammenzuhalten. Es ist Synergie, oder? Es ist also unglaublich.

Hayley Rodd:

Wunderschön.

Tony Camacho:

Ja, ich weiß. Bei mir dreht sich alles um den Menschen. Es tut mir leid.

Hayley Rodd:

Nein, ich bin genau bei dir. Ich bin so froh, dass wir dieses Gespräch führen konnten. Wir haben in der letzten Zeit viel geredet und jedes Mal, wenn wir uns treffen, bin ich verblüfft über deine Energie und deine Authentizität. Und ich denke, dieses Gespräch hat sich wirklich als wahr erwiesen, also danke Tony, dass du dir die Zeit genommen hast, bei uns zu sein. Ich verabschiede mich von all unseren Zuhörern. Ich werde mich noch einmal ganz herzlich bei Tony bedanken. Tony ist also Teil von Aligned Agility und das ist Teil von The Adaptivist Group. Und ja, danke Tony, dass du hier bei uns bist und danke dir für alle, die sich diese Episode des Easy Agile Podcasts angesehen und angehört haben. Danke.

Podcast

in-app

highlight_all

Verwandte Episoden

Podcast
Easy Agile Podcast Ep.21 LIVE von Agile2022!
„Das ist ein Abschluss von Agile2022! Es war großartig, so viele von Ihnen in der Agile-Community persönlich treffen zu können!“ - Tenille Hoppo
Diese Bonus-Episode wurde LIVE bei Agile2022 in Nashville aufgenommen!
Das Easy Agile-Team hat mit so vielen großartigen Leuten aus der Agile-Community gesprochen und über die Höhepunkte der Konferenz, wichtige Erkenntnisse, agile Zeremonien und mehr nachgedacht!
Vielen Dank an alle, die am Stand vorbeigeschaut haben, um G'Day zu sagen und ein oder zwei Tim Tam genossen haben;)
Vielen Dank an alle unsere Podcast-Gäste, dass sie einige Zeit mit uns verbracht haben, um diese Episode zu erstellen!
Cody Wooten
Gil Broza
Maciek Saganowski
Lindy Quick
Carey Young
Leslie Morse
Dan Neumann
Joe Falu
Kai Zander
Avi Schneier
Doug Page
Evan Leyburn
John Kerr
Josua Seckel
Rob Duval
Andrew Thompson
Transkript
Caitlin:
Hallo zusammen. Nun, das ist ein Abschluss von Agile 2022 in Nashville. Das Easy Agile-Team ist wieder zu Hause in Australien, und wir haben den größten Teil unserer Heimreise damit verbracht, über all die großartigen Gespräche zu sprechen, die wir mit allen Mitgliedern der Agile-Community führen konnten. Es war großartig, Kunden und Partner zu treffen, alte Freunde zu sehen und viele neue zu finden. Wir haben es geschafft, einige Ausschnitte dieser großartigen Gespräche aufzunehmen, und wir freuen uns, sie mit Ihnen, unserem Easy Agile Podcast-Publikum, zu teilen. Also viel Spaß.
Maciek:
[unhörbar 00:00:26].
Tenille:
Maciek, vielen Dank, dass du dir heute Zeit für uns genommen hast.
Maciek:
Keine Sorge.
Tenille:
[unhörbar 00:00:30], kannst du uns sagen, was das Beste war, was du diese Woche gelernt hast?
Maciek:
Oh, das war definitiv bei Melissa Perris Vortrag. Als sie über... sprach Als ob sie für mich davon sprach, langsamer zu werden. Und was wir bei Agile tun, ist nicht nur Lieferung, Lieferung, Lieferung, sondern es geht auch darum, Dinge, die wir bereits entwickelt haben, zu lernen und zu ändern und herauszufinden, welchen Mehrwert wir unseren Kunden bieten können. Es geht nicht nur um Versandfunktionen, es geht vor allem um den Wert. Das habe ich gelernt.
Tenille:
Das ist großartig. Danke. Also, was denkst du wäre die geheime Zutat für ein großartiges Agile-Team?
Maciek:
Demut. Irgendwie sollte die Teamkultur Demut und Fehler beinhalten. Und die Leute sollten keine Angst davor haben, Fehler zu machen, denn ohne Fehler zu machen, lernt man nicht. Das ist was ich denke.
Tenille:
Was wäre also, glaube ich, wenn es eine Agile-Zeremonie gäbe, die jedes Team durchführen sollte, was denkst du, könnte das sein?
Maciek:
Sicher, Retro, und das kommt wieder auf die Fehler und den Lernteil zurück.
Tenille:
Ja. Fantastisch.

Maciek:
Keine Sorge.
Tenille:
Das ist großartig. Vielen Dank, dass du dir die Zeit genommen hast.
Maciek:
In Ordnung. Danke.
Tenille:
Prost.
Mädchen:
[unhörbar 00:01:42].
Caitlin:
Gil:, vielen Dank, dass du mit uns gechattet hast. Im Moment sind wir also alle auf der Agile 2022 in Nashville. Es finden viele interessante Gespräche statt.
Mädchen:
Ja.
Caitlin:
Wenn Sie einem neu entstehenden Agile-Team einen Ratschlag geben könnten, welcher wäre das?
Mädchen:
Es wäre, kleine, wertvolle Arbeiten gemeinsam zu beenden. Es hat ein schreckliches Akronym, FSVWT. Es kann also nicht auf diese Weise in Erinnerung bleiben. Erledigen Sie gemeinsam kleine, wertvolle Arbeiten. Es wird viel über Prozesse, Arbeitsvereinbarungen und Tools gesprochen. Das ist alles wichtig, aber manchmal ist es zu viel für ein Team, das gerade erst anfängt. Wenn wir also nur daran denken, kleine wertvolle Arbeiten gemeinsam zu erledigen, ist das eine großartige Geschichte.
Caitlin:
Ja, ich liebe das. Und du warst Redner auf der Konferenz?
Mädchen:
Ja.
Caitlin:
Kannst du unserem Publikum einen kleinen Einblick geben, worum es in deinem Gespräch ging?
Mädchen:

Was in vielen Situationen passiert, ist, dass Technik oder Entwicklung nicht wirklich mit dem Produkt/Unternehmen zusammenarbeiten. Und stattdessen gibt es eine Übergabebeziehung. Aber was passiert, ist, dass es ohne eine kooperative Beziehung wirklich schwierig ist, Agilität aufrechtzuerhalten. Die Leute machen viele einseitige Annahmen. Und im Laufe der Zeit führt die Art und Weise, wie Entscheidungen getroffen werden, dazu, dass die Kosten für Änderungen steigen und die Sicherheit, Änderungen vorzunehmen, sinkt. Und wenn das passiert, wird alles schwieriger und langsamer, sodass die Agilität darunter leidet. Der Kern des Vortrags war also, wie wir zusammenarbeiten können, also sowohl das Produkt als auch die Technik, auf eine Weise, die es uns ermöglicht, die Kosten von Änderungen zu kontrollieren und die Sicherheit zu erhöhen? Es geht also nicht nur um Zusammenarbeit jeglicher Art. Es gibt ganz bestimmte Prinzipien, die befolgt werden müssen. Das nennt man technische Agilität, und wenn wir das tun, können wir langfristig agil sein.
Caitlin:
Großartig. Ich liebe es. Nun, vielen Dank und ich hoffe, Sie genießen den Rest Ihrer Zeit auf der Konferenz.
Mädchen:
Ich danke dir.
Caitlin:
Großartig. Danke.
Tenille:
Hallo, Tenille hier von Easy Agile, mit Josh von Deloitte, und wir werden ein gutes Gespräch über Team-Retrospektiven führen. Also Josh, danke, dass du dir die Zeit für ein gutes Gespräch genommen hast. Sie sind also ein bisschen Experte für Team-Retrospektiven. Was sind deine Top-Tipps?
Josh:
Meine Top-Tipps für den Rückblick sind also zunächst, tatsächlich eine Änderung vorzunehmen. Machen Sie keine beobachteten Lektionen. Ich habe gesehen, dass viele von ihnen tatsächlich eine Veränderung vorgenommen haben, auch wenn es am Ende nur eine kleine ist. Die zweite und ein Teil davon ist, dass Sie Ihre Veränderung vornehmen und experimentieren. Etwas, das man messen kann, etwas, von dem man tatsächlich sagen kann, ja, wir haben dieses Ding gemacht und es hatte Wirkung. Vielleicht nicht die Wirkung, die Sie sich gewünscht haben, aber es hatte eine gewisse Wirkung. Der zweite Tipp lautet: Variieren Sie Ihre Rückblicke. Eine Retrospektive, die Sprint für Sprint nach Sprint gleich ist, funktioniert für etwa zwei Sprints, und dann werden Ihre Produktivität und Ihre Kreativität außerhalb der Retrospektive erheblich abnehmen.
Tenille:
Das ist ein ausgezeichneter Punkt. Also, wie erstellt man [unhörbar 00:05:03]?
Josh:
Ich habe viel über sie nachgedacht und recherchiert und Websites wie TastyCupcakes genutzt, aber auch meine eigenen Retrospektiven entwickelt. Ich habe eine Retrospektive gemacht, die auf dem Pixar-Pitch basiert. Es gibt sechs Sätze, die jeden Pixar-Film definieren. Nehmen Sie die Basissätze, wenden Sie sie auf Ihren Sprint oder Ihren PI an und machen Sie einen Retro, und lassen Sie dem Team diese Kreativität, um ein ganzes Filmplakat zu erstellen, wenn es möchte. Regie: [unhörbar 00:05:34], weil es passiert. Die Leute engagieren sich und engagieren sich, wenn man ihnen Alternativen gibt, verschiedene Arten, Retrospektiven zu machen.

Tenille:
Das ist richtig. Also für die Teams, die im Moment keine Retrospektiven veranstalten, was ist die eine wichtige Sache, über die sie nachdenken müssen, dass du... Was ist das Wichtigste, was du ihnen sagen könntest, um sie zum Start zu ermutigen?
Josh:
Wenn du keine Retrospektiven machst, machst du keine [unhörbar 00:05:54]. Also sollte ich das nicht sagen. Aber wenn du keine Retrospektiven machst, wenn du wirklich glaubst, dass du absolut nichts zu verbessern hast und du zu 100% zu den Besten der Besten gehörst, was bedeutet, dass du wahrscheinlich bei Google oder Amazon oder Netflix arbeitest, obwohl sie Retrospektiven machen. Wenn du also wirklich glaubst, dass du diesen Unternehmen gleichwertig bist, dann musst du sie vielleicht nicht machen, aber ich bin mir ziemlich sicher, dass jedes Team etwas hat, das es verbessern kann. Und das anzuerkennen und dann zu sagen, wie werden wir das machen? Die Retrospektive ist eine sehr schnelle und einfache Methode, um diese Verbesserungen tatsächlich vorzunehmen und sie in die Realität umzusetzen.
Tenille:
Fantastisch. Großartig. Vielen Dank, dass Sie sich die Zeit genommen haben, kurz mit uns über Rückblicke zu sprechen.
Josh:
Ich danke dir.
Caitlin:
Wir sind hier mit Leslie, der Präsidentin von Women in Agile. Leslie, am Sonntag gab es eine tolle Veranstaltung.
Leslie:
Ja.
Caitlin:
Sprich uns einfach ein bisschen darüber an. Was ist in die Planung eingeflossen? Wie war es, wieder alle zusammen zu sein?
Leslie:
Es war toll, die Frauen in der Agile-Community wieder zusammen zu haben, oder? Unser erstes Mal seit 2019, als alle zu dieser Veranstaltung in Washington DC zusammen waren. In den meisten sechs oder sieben Monaten der Planung hatten wir ungefähr 200 Personen im Raum. Zum Glück wissen wir [unhörbar 00:07:10], was diese Frauen in Agile-Sessions machen, die wir jedes Jahr im Rahmen der Agile Alliance-Konferenzen veranstalten, oder? Wir haben eine allgemeine Eröffnung. Wir haben einen großartigen Keynote, bei dem es sich immer um jemanden handelt, der direkt neben dem Agile-Bereich steht. Wir wollen nicht einfach nur mögen... Wir wollen unsere Weisheit und unser Wissen mit Leuten teilen, die noch nicht zu uns gehören, weil wir das ganze Agile-Zeug auf der großen Konferenz bekommen, wenn wir dort sind.
Leslie:
In diesem Teil bringen wir immer neue Stimmen auf den Markt, was wahrscheinlich eine meiner Lieblingsfrauen in Agile-Programmen ist. Drei Mentees, die mit erfahrenen Rednern gepaart wurden, treten zum ersten Mal auf die Bühne, um ihr Talent und ihre Sichtweise zu teilen. Das ist also wirklich großartig. Und dann eine Art interaktives Networking-Event. Dieses Muster hat uns also wirklich gute Dienste geleistet, seit wir das seit 2016 machen, was ein bisschen beängstigend ist, wenn man bedenkt, dass es schon so lange passiert. Und es ist zu einer großartigen Gelegenheit für die Community geworden, auf globalere Weise zusammenzukommen, weil die Agile Alliance so viele Menschen für ihre jährliche Veranstaltung anzieht.
Caitlin:
Ja, ganz sicher. Ja, es war eine großartige Veranstaltung. Ich weiß, dass wir alle viel Spaß hatten, dort zu sein. Was war Ihre wichtigste Erkenntnis aus der Veranstaltung?
Leslie:
Ich werde zu [unverständlich 00:08:14] interaktiven Netzwerken gehen, die sie mit uns gemacht hat, und uns wirklich herausfordern, unseren Mut in Bezug auf Grenzen und das Beenden von Gesprächen zu stärken. Wir müssen keinen Grund angeben. Wenn ein Gespräch uns nicht nützt oder aus welchem Grund auch immer nicht der Ort ist, an dem wir sein müssen, haben Sie absolut die Freiheit, dieses Gespräch zu beenden und einfach weiterzumachen. Ich liebe die Tipps und Tricks, die sie uns gegeben hat, um das gut zu machen.
Caitlin:
Ja, ja, das liebe ich auch. Das ist großartig. Nun, vielen Dank. Ich weiß es zu schätzen.
Leslie:
Ja. Danke, dass du mich eingeladen hast.
Tenille:
Hallo, Evan. Wie geht's dir?
Evan:
Sehr gut.
Tenille:
Das ist gut. Kannst du mir bitte sagen, was das Beste ist, was du heute gelernt hast?
Evan:
Das beste Zitat, das ich habe: „Politik ist die Währung menschlicher Systeme.“ Richtig?
Tenille:
Beeindruckend.
Evan:
Wenn du also ein menschliches System ändern willst, musst du die Politik spielen.
Tenille:

Fantastisch.
Evan:
Was sich beschissen anfühlt, aber...
Tenille:
Es ist so wie es ist.
Evan:
... so ist das nun mal.
Tenille:
[unhörbar 00:09:07]. Okay, nächste Frage. Ohne welche Agile-Zeremonie können Sie und Ihr Team nicht leben?
Evan:
Rückblick. Mit der Retrospektive kannst du quasi alles andere gestalten.
Tenille:
Fantastisch. Das ist wirklich gut. Und was ist Ihrer Meinung nach wahrscheinlich die wichtigste Zutat für einen guten Rückblick?
Evan:
Oh, vertraue. Vertrauen erfordert Respekt. Es erfordert Glaubwürdigkeit. Es erfordert Empathie. Vertrauen ist also genau das, was menschliche Fähigkeiten untermauert.
Tenille:
Ja. Fantastisch. Vielen Dank.
Evan:
Ich danke dir.
Tenille:
Ja.
Caitlin:
Richtig. Wir sind hier mit Cody von Adfire. Also Cody, wie hat dir die Konferenz bisher gefallen?
Cody:
Ich liebe die Konferenz wirklich. Es war großartig. Um ehrlich zu sein, als wir das erste Mal hier ankamen, schien es vielleicht ein bisschen kleiner als wir dachten, aber die Leute hier waren unglaublich, sehr engagiert, was immer großartig war. Und außerdem verwenden viele Leute Jira und Atlassian. So viele wichtige Punkte.

Caitlin:
Win-Win für beide, hm?
Cody:
Ja. Immer, immer, immer.
Caitlin:
Sehr gut.
Cody:
Ja.
Caitlin:
Es finden viele interessante Vorträge statt. Haben Sie an einem teilgenommen, der wirklich Interesse an Ihnen geweckt hat? Was ist [unhörbar 00:10:15] -
Cody:
Ja. Ich kann mich auf Anhieb an keinen der Vortragsnamen erinnern, aber sie waren alle unglaublich aufschlussreich. Tonnenweise Informationen. Es scheint, als gäbe es für alles ein Thema, was immer ein gutes Zeichen ist und solche Sachen. Also meine Notizen, ich habe Seiten und Seiten und Seiten von Notizen, was immer ein gutes Zeichen ist.
Caitlin:
Ja, das ist [unhörbar 00:10:34].
Cody:
Also muss ich zurück und [unhörbar 00:10:35] nochmal.
Caitlin:
Ja.
Cody:
Aber es war unglaublich und die Vorträge waren sehr umfangreich, also ja.
Caitlin:
Gut. Gut. Und was ist die eine wichtige Erkenntnis, auf die Sie sich freuen, zurückzubringen und mit dem Team zu teilen?
Cody:
Nun, ich denke, eine der wichtigsten Erkenntnisse für uns war, dass... Ich habe über das Engagement gesprochen, das alle haben, aber eine Sache, die unglaublich war, ist, die Geschichten aller zu hören, ihre Probleme, ihre Prozesse, all das. All diese Informationen werden also ein großartiges Aggregat sein, das wir zurücknehmen und ein besseres Erlebnis mit unserem Produkt und all den guten Dingen schaffen können. Also ja.

Caitlin:
Ganz gewiss. Ich liebe es. Ich habe jetzt noch eine letzte Frage an dich. Es macht einfach Spaß. Es ist wahr oder falsch. Wir machen Australien-Quizfragen. Bist du bereit dafür?
Cody:
In Ordnung.
Caitlin:
In Ordnung.
Cody:
Hoffentlich.
Caitlin:
Also, meine Wahrheit oder Unwahrheit ist, sind Wellensittenschmuggler eine Vogelart?
Cody:
Sind Buggy-Schmuggler...
Caitlin:
Wellensittiche Schmuggler.
Cody:
Wellensittiche Schmuggler.
Caitlin:
Eine Vogelart.
Cody:
Stimmt.
Caitlin:
Falsch. Nein.
Cody:
Was sind sie?
Caitlin:
Tachos.
Cody:

Ja. Ja, ich habe einige davon in meinem Gepäck. Also hole ich jetzt die Wellensittiche raus.
Caitlin:
Mit deinen Daisy Dukes.
Cody:
Exakt. Exakt.
Caitlin:
Ja. Und Cowboystiefel, richtig?
Cody:
Ja.
Caitlin:
Nun, vielen Dank.
Cody:
Ich danke dir.
Caitlin:
Ich weiß das sehr zu schätzen.
Cody:
Ja. Danke.
Tenille:
Doug, wie geht's dir?
Doug:
Mir geht es großartig. Ich danke dir.
Tenille:
Fantastisch. Nun, erzähl mir, was ist das Beste, was du heute gelernt hast?
Doug:
Ich finde es wirklich interessant zu erfahren, wie unsere Kunden unsere Produkte verwenden, von denen wir noch nicht einmal wussten.
Tenille:
Das ist unglaublich. Hattest du die Gelegenheit, an vielen der Sessions teilzunehmen?

Doug:
Das habe ich eigentlich nicht. Ich war an diese Kabine gebunden, oder ich nahm an Besprechungen teil, die schon geplant waren, bevor ich hierher kam.
Tenille:
[unhörbar 00:12:01].
Doug:
Ja.
Tenille:
Das ist gut. Wenn Sie also wieder auf der Arbeit sind, was ist Ihrer Meinung nach die wahrscheinlich beste Agile-Zeremonie, ohne die Sie und Ihr Team nicht leben können?
Doug:
Ich denke, was ich zurück ins Büro bringe, ist nicht so sehr eine Zeremonie. Es ist wirklich aus der Produktperspektive. Ich arbeite im Produktmanagement. Für uns geht es also darum, wie wir erklären können, wie unser Produkt unseren Kunden einen Mehrwert bietet. So viele Lektionen, die wir daraus gelernt haben, dass wir wirklich darauf bedacht sind, sie zurückzubringen und in unsere Wertebotschaft einzubauen.
Tenille:
Fantastisch.
Doug:
Ja.
Tenille:
Danke. Das ist großartig. Vielen Dank.
Caitlin:
Er war einer der Mitautoren des Agilen Manifests. Erstens, wie geht es Ihnen bisher auf der Konferenz?
Johannes:
Nun, ich arbeite hart.
Caitlin:
Ja, gutes Zeug.
Johannes:
Ich genieße Nashville.
Caitlin:

Ja. Es ist cool, nicht wahr? Es ist so anders als das [unhörbare 00:12:46], was passiert.
Johannes:
Ja. Ja, es ist gut. Ja. Es ist schön, viele Leute zu sehen, die ich seit einiger Zeit nicht mehr gesehen habe.
Caitlin:
Ja. Ja.
Johannes:
Und dreidimensional sehen.
Caitlin:
Ja. Ja, ich weiß. Ja, das ist interessant...
Johannes:
Es ist da-
Caitlin:
... [unhörbar 00:12:54] und so was passiert.
Johannes:
Ja, IRL.
Caitlin:
Es passiert viel Interessantes [unhörbar 00:13:01]. Irgendwelche wichtigen Imbissbuden für dich? Was nimmst du danach mit, um es mit dem Team zu teilen?
Johannes:
Oh, nun, das ist eine gute Frage. Ich habe hauptsächlich mit vielen Freunden gesprochen, die ich seit einiger Zeit nicht mehr gesehen habe. [unhörbar 00:13:14].
Caitlin:
Ja.
Johannes:
Und da ich erst seit ein paar Tagen hier bin, war ich nicht viel, wenn überhaupt, dort. Um ehrlich zu sein.
Caitlin:
Ich weiß. Nun, wir sind ziemlich beschäftigt mit den Stiefeln, oder?
Johannes:

Ja. Ja. Aber sicherlich sind die Arten von Gesprächen, die hier geführt werden,... Ich habe mir ein bisschen Sorgen um Agile gemacht. Ich will einfach nicht sagen... Ja, ich will es nicht sagen. Aber ich will nicht sagen, dass Agile zu einem Sprungbrett wird.
Caitlin:
Ja.
Johannes:
Aber ich denke, es gibt eine Menge Leute hier, die wirklich immer noch die Ideale annehmen und wirklich lernen, tun und üben wollen [unhörbar 00:14:00].
Caitlin:
Ja.
Johannes:
Also ich bin ehrlich gesagt überrascht und beeindruckt und glücklich. Es gibt eine Menge. Es reicht, wenn man sich mehr vom Manifest zu eigen macht und manchmal vielleicht nicht alle Vorschriften, und man kehrt zu den Grundlagen zurück. [unhörbar 00:14:22] -
Caitlin:
Ja. Also lass uns darüber sprechen, über das Agile Manifest, das du erwähnt hast. Ich nehme das an. Was heißt Umarmen? Kannst du das etwas näher erläutern? Wir wissen also, dass wir die Prinzipien haben. Gibt es eine, die Ihnen wirklich mehr auffällt als eine andere?
Johannes:
Nun, meine Welt von dem, was ich zu der Zeit gemacht habe, und ich hatte viel im Verteidigungsministerium und im Wassertransport gearbeitet und meinen eigenen, leichten Prozess entwickelt, wie wir ihn vor Agile nennen. Also für mich ist der wahre Schlüssel... Das hat nicht die volle...
Caitlin:
Vollständiges Manifest, ja.
Johannes:
Aber wenn du auf die Website gehst und oben liest, geht es darum, als würden wir Wege aufdecken, indem wir etwas tun, und ich lerne immer noch, entdecke immer noch. Und ich denke, es ist wichtig, dass die Leute erkennen, dass wir unser Ego wirklich an der Tür gelassen haben. In unserem Geschäft bescheiden zu sein ist sehr wichtig. Das steht vielleicht nirgends in den Prinzipien, aber wenn das Ganze in der Präambel ganz oben steht und die Tatsache, dass wir im Blog darüber sprechen, wie wir diese Dinge bewerten, im Vergleich zum Ganzen... Da ist ein Pendel, durch das man sehen kann, wie diese beiden Dinge kollidieren. Meiner Meinung nach ist es eine der wichtigsten Eigenschaften, die wir anwenden sollten, dass wir bescheiden sind und Dinge als Hypothese betrachten. Zum Beispiel, baut Funktionen [unhörbar 00:15:58] nicht einfach von unten nach oben, wie sucht man nach den Antworten, das möchte ich, dass die Leute das mitnehmen.
Caitlin:

Das ist großartig. Das ist ein toller Rat. Nun, vielen Dank, John. Danke, dass du dir die Zeit nimmst, mit uns zu chatten.
Johannes:
Du bist willkommen, Caitlin.
Caitlin:
Ja. Genieß, was [unhörbar 00:16:11] ist.
Johannes:
Ich danke dir.
Caitlin:
Ich danke dir.
Johannes:
[unhörbar 00:16:13] morgen.
Caitlin:
In Ordnung.
Tenille:
Abukar, danke, dass du heute zu uns gekommen bist. Kann ich Sie beide fragen, was Ihrer Meinung nach das Beste ist, was Sie heute gelernt haben?
Avi:
Das Beste, was ich gelernt habe?
Tenille:
Ja.
Avi:
Das ist wirklich interessant. Weil ich oft hier am Stand bin, werde ich an vielen Dingen teilnehmen können. Ich habe also zwei Dinge gelernt, die wirklich wichtig waren. Erstens ist das Easy Agile-Logo ein umgedrehtes A, weil es bedeutet, dass Sie aus Australien kommen. Es ist also in Down Under. Und dann war die zweitwichtigste Sache, über die ich heute gelernt habe, dass wir in einer Sitzung über Soziokratie gesprochen haben und darüber, wie man Experimente mit Experimenten besser machen kann, was sich zunächst etwas komisch anhörte, aber es ging wirklich darum, einen Mini-A3-Prozess durchzuführen. Für diejenigen unter Ihnen, die zugehört haben: Das wurde Toyota angetan. Es ist eine strukturierte Problemlösungsmethode, aber anstatt sie [unhörbar 00:17:02] zu umgehen und das Experiment durchzugehen, zwei- oder dreimal herumzulaufen und dann zu entscheiden, dass das das richtige Experiment ist, machen Sie weiter.
Tenille:

Ich danke dir. Wie stehts mit deiner Zeit?
Kai:
Ich war die meiste Zeit am Stand, aber dadurch lernt man viele Leute auf der ganzen Welt kennen. Und eines haben wir wirklich gemeinsam, nämlich den Wunsch, Menschen zu helfen. Und es war wirklich schön, in einem Raum voller Menschen zu sein, die am Anfang ihrer Reise stehen oder schon sehr erfahren sind und ihre Motivation einfach darin besteht, andere wirklich zu stärken. Es war wirklich schön, mit dieser Art von Energie zusammen zu sein.
Avi:
Wir haben wirklich gelernt, dass unsere Freunde aus Australien hier oben genauso freundlich sind wie Sie auf der anderen Seite. Ich habe das Gefühl, wenn du auf diese Seite kommst, wirst du gemein, aber es stellt sich heraus, dass du auch hier oben genauso nett bist.
Tenille:
Nun, das hängt davon ab, wie lange du schon auf dem Flug warst.
Avi:
Oh, genau.
Tenille:
[unhörbar 00:17:44], uns geht es gut.
Kai:
Ja.
Avi: Abukar:
Exakt. Gut.
Tenille:
In Ordnung. Noch eine Frage hier.
Avi:
Sicher.
Tenille:
Was ist deiner Meinung nach die geheime Zutat für ein erfolgreiches Team?
Avi:
Was halte ich für das Geheimnis? Oh, das ist eine wirklich gute Frage. Das ist ein-
Kai:
Er ist der Beste, um diese Frage zu beantworten.

Avi:
Das ist etwas länger als ein zweisekündiger Podcast, aber das sage ich dir. Das ist vielleicht keine psychologische Sicherheit, -
Tenille:
In Ordnung.
Avi:
... nur weil Google das gesagt hat und Project Aristotle das zeigt. Ich denke, um ein wirklich, wirklich erfolgreiches Team zu haben, braucht man einen wirklich erfahrenen Scrum Master. Denn zu sagen, dass das Team psychologische Sicherheit hat, ist eine Zutat, es ist nicht die einzige Zutat. Ein starker Scrum Master ist jemand, der wirklich geschickt darin ist, diese psychologische Sicherheit zu schaffen, aber auch bei all den anderen Aspekten hilft, um sich auf eine möglichst positive Zusammenarbeit und Koordination vorzubereiten. Außerdem auf der Suche nach... Ihr Name ist Cassandra. Auf Slack nennt sie sich selbst Kaizen. Kapierst du es? Das ist ein Witz. Aber das ist die ganze Sache, ein wirklich erfahrener Scrum Master hilft den Teams, die Kaizens zu finden, die sie brauchen, um wirklich leistungsstark zu werden. Psychologische Sicherheit macht das möglich, aber das heißt nicht, dass sie die Leistung steigert. Es ist eine Zutat, um das möglich zu machen.
Tenille:
Fantastisch.
Kai:
Es gibt keine bessere Antwort als diese. Lass uns einen Ausruf machen.
Tenille:
Hervorragend. Vielen Dank, dass Sie sich die Zeit genommen haben.
Avi:
Ich danke dir vielmals.
Kai:
Natürlich.
Hayley:
Wir sind hier mit Carey von Path to Agility. Carey, was hat dir an dieser Konferenz wirklich gefallen?
Carey:
Ich glaube, dass mir an dieser Konferenz bisher am meisten gefallen hat, ist die Interaktion mit all den Leuten, die hier sind. Es ist wirklich schön, sich zu treffen, verschiedene Leute kennenzulernen, Kontakte zu knüpfen und die Gelegenheit zu haben, zu sehen, was es sonst noch auf dem Markt gibt. Und dann sprechen wir natürlich über das Produkt, das wir mit Path to Agility haben. Es ist eine wundervolle Erfahrung, hierher zu kommen und alle zu sehen. Und es ist so schön, wieder persönlich unterwegs zu sein, anstatt die ganze Zeit vor einem Bildschirm zu stehen.

Tenille:
Ja, absolut. Hattest du die Gelegenheit, an vielen der Sessions teilzunehmen?
Josef:
Ich habe so viel wie möglich versucht, aber es ist auch wichtig, sich die Zeit zu nehmen, um zu dekomprimieren und alles einwirken zu lassen. Also hier haben wir Spaß.
Tenille:
Ja, absolut. Wenn Sie an die Arbeit zurückdenken, was ist Ihrer Meinung nach die eine Agile-Zeremonie, an der Sie teilnehmen und die Ihnen und Ihrem Team am meisten hilft?
Josef:
Ich denke, verschiedene Wege der Zusammenarbeit zu finden, effektive Wege der Zusammenarbeit. Und wie lösen wir in Bezug auf das Arbeitsmanagement einige der Probleme, die wir haben? Es gibt so viele Tools, die das einfacher machen, und das ist etwas ganz Besonderes. Mit Menschen sprechen und herausfinden, wie sie Probleme lösen.
Tenille:
Und was macht Ihrer Meinung nach ein wirklich gutes Agile-Team aus?
Josef:
Nun, man könnte etwas sehr Klischeehaftes sagen, wie sehr anpassungsfähig zu sein und sich zu verändern und so weiter und so fort. Aber ich denke, es kommt wirklich auf die Interaktion zwischen Menschen an. Einander verstehen, sich gegenseitig ermutigen und einfach die Art und Weise, wie man zusammenarbeitet.
Tenille:
Fantastisch. Großartig. Gut, vielen Dank, dass du dir die Zeit zum Chatten genommen hast.
Josef:
Ich danke dir. Es war nett, die ganze Woche mit euch zu chatten.
Tenille:
Prost.
Tenille:
Dan, danke, dass du dir die Zeit zum Chatten genommen hast.
Dan:
Du bist willkommen.
Tenille:
[unhörbar 00:22:54] Fragen. Was denkst du ist das Beste, was du heute gelernt hast?

Dan:
Oh, das Beste, was ich heute gelernt habe, ist, dass die Keynote zu den Morgenprodukten ausgezeichnet war. Ich habe ein paar Tipps bekommen, wie man Produktmanagement macht, verschiedene Strategien, wie man die Leute dazu bringt, sich auf das Taktische und Strategische zu konzentrieren. Also nur ein paar nette kleine Nuggets, wie das geht [unhörbar 00:23:12].
Tenille:
[unhörbar 00:23:13], danke, dass du heute zu uns gekommen bist. Kann ich zunächst fragen, was denkst du ist das Beste, was du diese Woche gelernt hast?
Sprecher 17:
Das Beste, was ich diese Woche gelernt habe, ist, dass es keinen richtigen Weg gibt, Agile anzuwenden. Es gibt viele verschiedene Möglichkeiten, dies zu tun. Es geht also wirklich darum, herauszufinden, welcher Prozess für das Unternehmen, in dem Sie tätig sind, der richtige ist, und diese Erfolgsmuster dann zu nutzen.
Tenille:
Nun, ich schätze, gibt es eine Art Agile-Zeremonie, auf die Ihr Team Ihrer Meinung nach nicht verzichten kann?
Sprecher 17:
Das tägliche Standup ist täglich. Ich denke, viele unserer Teams reden den ganzen Tag lang. Sie müssen sich nicht unbedingt so häufig synchronisieren. Ich hatte schon ein paar Teams, sie fallen etwa drei Tage die Woche aus und es scheint für sie zu funktionieren. Die andere vielleicht wichtigste Erkenntnis, die ich gesehen habe, sind Zeitboxen. Also keine Besprechungen von 10:00 bis 2:00 Uhr oder was auch immer es sein mag, und das wirklich aus einer erfolgreichen Perspektive zu steuern.
Tenille:
Ich denke in diesem Sinne, was macht Ihrer Meinung nach ein wirklich erfolgreiches Agile-Team aus?
Sprecher 17:
Die Fähigkeit, miteinander zu sprechen, diese Fähigkeit zu kommunizieren. Da all unsere Teams entweder hybrid oder remote arbeiten, ist es meiner Meinung nach entscheidend, sicherzustellen, dass wir über die Tools verfügen, mit denen sie das Gefühl haben, jederzeit jemanden abholen und mit ihm sprechen zu können. Und viele Leute haben immer noch keine Kameras, richtig, was mich verwirrt. Aber die Fähigkeit, Gesichtsausdrücke zu sehen, von Angesicht zu Angesicht zu sein, war so schön, weil wir das bekommen können. Das ist also der andere Schlüssel, die Fähigkeit, miteinander zu sprechen, als könnte ich die Hand reichen und dich berühren.
Tenille:
In Ordnung. Fantastisch. Tja, vielen Dank.
Sprecher 17:
Du bist willkommen. Danke.
Tenille:
In Ordnung. Rob und Andrew, vielen Dank, dass Sie sich ein paar Minuten Zeit für uns genommen haben. Kann ich Sie zunächst fragen, was Ihrer Meinung nach das Beste ist, was Sie diese Woche gelernt haben?

Rob:
Für mich ist es definitiv die schnelle Skalierung von Agile, von der wir heute Morgen erfahren haben. Wir werden es versuchen.
Andrew:
Mir hat die Mathe-Programmiersitzung sehr viel Spaß gemacht und ich habe verschiedene Möglichkeiten kennengelernt, Ingenieure miteinander zu verbinden und zusammenzuarbeiten.
Tenille:
Großartig. Als Nächstes, schätze ich, was macht Ihrer Meinung nach ein großartiges Agile-Team aus?
Rob:
In erster Linie, dass sie mehr als alles andere die Kontrolle darüber haben, wie sie arbeiten und woran sie arbeiten.
Andrew:
Ja. Für mich ist das natürlich eine psychologische Sicherheit und einfach eine gute Teamdynamik, in der sie unterschiedlicher Meinung sein können, aber trotzdem respektvoll sein und großartige Ideen entwickeln können.
Tenille:
Und gibt es eine Agile-Zeremonie, ohne die ein großartiges Team Ihrer Meinung nach nicht leben kann?
Rob:
Wahrscheinlich rückblickend. Ich denke, die Teams müssen sich ständig verbessern, und das ist ein guter Weg, das zu tun.
Andrew:
Einverstanden. Ja. Ja. Ja.
Tenille:
In Ordnung. Das ist großartig. Vielen Dank, dass du dir die Zeit genommen hast.
Andrew:
Vielen Dank. Ich weiß es zu schätzen.
Hör jetzt zu

Podcast
Easy Agile Podcast Ep.12 Beobachtungen zur Beobachtbarkeit
In dieser Folge von The Easy Agile Podcast hören Sie, wie die Entwickler Angad, Jared, Jess und Jordan ihre Gedanken zum Thema Observability teilen.

Wollongong hat eine blühende und unterstützende Tech-Community. In dieser Folge haben wir einige unserer lokalen Entwickler aus dem Siligong-Tal zu einem Gespräch am runden Tisch zum Thema Observability zusammengebracht.

💥 Was ist Beobachtbarkeit?
💥 Wie kann man die Beobachtbarkeit verbessern?
💥 Was ist das Endziel?
‍
‍
‍
„Es war eine großartige Episode, an der man teilnehmen konnte! Jess und Jordan haben einige wirklich interessante Punkte zum neuesten technischen Schlagwort — Beobachtbarkeit — geteilt.
Abonniere unbedingt, genieße die Folge 🎧
‍
‍
‍
Transkript
Jared Kells:
Willkommen alle zum Easy Agile Podcast. Mein Name ist Jared Kells und ich bin Entwickler hier bei Easy Agile. Bevor wir beginnen, möchte Easy Agile den traditionellen Hütern des Landes, von dem aus wir heute senden, unsere Anerkennung aussprechen, dem Volk der Wodiwodi aus der Dharawal-Nation, und den Ältesten in der Vergangenheit, Gegenwart und aufstrebenden Ältesten unseren Respekt erweisen. Den gleichen Respekt gilt auch allen Ureinwohnern, die uns heute zuhören.
Jared Kells:
Der heutige Podcast ist also ein bisschen technisch. In meinem Arbeitsblatt steht, dass wir hier sind, um über einige aktuelle Themen für Ingenieure im IT-Sektor zu sprechen. Wie aufregend, dass wir ein paar hauptsächlich Frontend-Ingenieure haben und Angad und ich einige technische Frontend-Dinge mit Ihnen teilen werden und Jess und Jordan ein bisschen über Observability sprechen werden. Wir beginnen also mit Einführungen. Also werde ich es an Jess weitergeben.
Jess Belliveau:
Cool. Danke Jared. Danke, dass du mir auch eins gegeben hast. Also ja, mein Name ist Jess Belliveau. Ich arbeite für Apptio als Infrastrukturingenieur. Ja, Jordan?
Jordan Simonowski:
Ich bin Jordan Simonovski. Ich arbeite als Systemingenieur im Observability-Team von Atlassian. Ich bin ein bisschen ein Alleskönner, was die Technik angeht. Aber ja, ich arbeite daran, einige ziemlich leistungsfähige Systeme aufzubauen, um all unsere Daten bei Atlassian im Moment zu verarbeiten. Also, das macht Spaß.
Angad Seth:
Hallo an alle zusammen. Ich bin Angad. Ich arbeite für Easy Agile als Softwareentwickler. Nichts ausgefallenes wie ihr.
Jared Kells:
Nichts Besonderes!
Jess Belliveau:
Verkaufe dich nicht unter.
Jared Kells:
Ja, sage ich. Ja, also mein Name ist Jared und ja, Senior Developer bei Easy Agile, der an unseren Apps arbeitet. Also arbeite ich hauptsächlich an Programmen und Roadmaps. Und ja, es sind Frontend-Apps mit viel JavaScript. Darin liegt also unsere Erfahrung. Ich habe von diesem Ding namens Observability gehört, bei dem es sich meiner Meinung nach nur um Logs und so handelt, oder?
Jess Belliveau:
Ja, ja. Das war's, wir schließen ab!
Jared Kells:
Der Podcast ist vorbei! Erzählen Sie uns etwas über Beobachtbarkeit.
Jess Belliveau:
Ja, okay, ich werde, ja. Ja, ich dachte, zuerst mache ich eine kleine Sache darüber, warum Observability, warum wir darüber reden und irgendwie für die Leute, die zuhören, wie wir hierher gekommen sind. Wir haben uns kurz unterhalten, bevor wir mit den Aufnahmen begonnen haben, um herauszufinden, was ein breiteres Publikum interessieren könnte, über das die Leute vielleicht nicht viel wissen. Und ich denke, es gibt viele Entwicklungen im breiten IT-Bereich, über die Sie sprechen könnten. Es gibt jetzt so viele verschiedene Dinge, die einfach explodieren. Beobachtbarkeit ist ein Thema, das seit ein paar Jahren ein heißes Thema ist. Und es ist etwas, das ein zentraler Bestandteil meines Jobs und auch Jordans Job ist. Es ist also etwas, worüber wir leicht sprechen können, und es ist etwas, in das Sie eine Einführung geben können, ohne zu technisch zu werden. Wir wollen also nicht untergehen. Das ist etwas, das man wirklich tief ins Unkraut eintauchen kann, also haben wir es als etwas ausgewählt, das wir euch beiden hoffentlich auf einer Ebene erklären können, die auch die Leute zu Hause interessieren könnte, zuzuhören.
Jess Belliveau:
Jordan und ich haben diese vier Stichpunkte herausgefunden, die wir behandeln wollten, und vielleicht kann ich einen kleinen Überblick darüber machen, und dann kann ich Jordan dazu bringen, den ersten Aufzählungspunkt abzudecken, ihn einfach direkt unter den Bus werfen.
Jordan Simonowski:
In Ordnung!
Jess Belliveau:
Deshalb dachten wir, wir würden versuchen, Ihnen zunächst zu beschreiben, was Beobachtbarkeit ist. Weil das hübsch ist, der Begriff gibt Ihnen nicht viel von dem, was er ist. Es gibt Ihnen einen kleinen Hinweis, aber es ist gut, als Grundlinie festzulegen, wovon wir sprechen, wenn wir sagen, was Beobachtbarkeit ist. Und warum sollte ein Entwicklungsteam dann Observability wollen? Warum sollte ein Unternehmen Observability wollen? Ein gewisses hohes Niveau, welche Vorteile Sie daraus ziehen und wer sie möglicherweise benötigt, was eine große Sache ist. Sie können sich in diese brandaktuellen Schlagworte der Branche verwickeln und sich auf Dinge festlegen, die Sie möglicherweise nicht benötigen, oder solche Dinge.
Jared Kells:
Jep.
Jordan Simonowski:
Jep.
Jess Belliveau:
Wir dachten, wir würden über einige einfache Gewinne sprechen, die man mit Observability erzielen kann. Also einige der wirklich grundlegenden Dinge, die Sie ausprobieren können, und welche Vorteile Sie daraus ziehen. Und dann dachten wir einfach, weil wir nicht versuchen werden, zu tief zu gehen, könnten wir einfach ein paar Hinweise auf einige Websites und einige YouTube-Vorträge geben, um weiter zu lesen, die die Leute machen wollen, und von dort aus weitermachen. Also ja, Jordan, du willst...
Jared Kells:
Hört sich gut an.
Jess Belliveau:
Ja. Ich hoffe, hoffentlich. Wir werden sehen, wie das läuft! Und ich denke, wenn ihr auch Fragen habt, sollten wir das tun. Wenn es Dinge gibt, von denen ihr denkt, dass wir sie nicht behandeln oder die ihr mehr wissen wollt, fragen.
Jordan Simonowski:
Ich schätze, um mit Observability zu beginnen. Es ist ein Thema, das mich wirklich begeistert, denn als jemand, der schon so lange im Bereich Dev-Ops und SRE tätig ist, ist Observability auf den Markt gekommen und verspricht, den Kreislauf oder eine Feedback-Schleife bei der Softwarebereitstellung zu schließen. Und es fühlt sich an, als wäre das etwas, was wir im Moment nicht wirklich haben. Und ich verstehe, dass Beobachtbarkeit vielleicht neu und glänzend klingt, aber ich denke, der Begriff selbst existiert, um sich vielleicht von dem abzuheben, was es derzeit gibt. Viele von uns, die in der Tech-Branche arbeiten, kennen sich mit Überwachung und dem Laden und solchen Dingen aus. Und ich denke, sie erfüllen ihren eigenen Zweck und sie sind auch in keiner Weise veraltet. Dinge wie herkömmliche Überwachungstools. Aber Observability hat sich meiner Meinung nach als eine Möglichkeit erwiesen, die überwältigend komplexen Systeme zu verstehen, die wir gerade aufbauen. Viele Unternehmen bewegen sich wahrscheinlich in Richtung einer komplizierten Architektur verteilter Systeme, Microservices oder anderer Schlagworte.
Jordan Simonowski:
Aber auch für Dinge wie einen traditionellen Monolithen. Die Beobachtbarkeit hilft uns wirklich dabei, unseren Systemen neue Fragen zu stellen. Die Art und Weise, wie es erklärt wird, ist die Überwachung von Ausgängen auf unsere bekannten Unbekannten. Mit dem Dienstalter geht die Fähigkeit einher, fast vorherzusagen, auf welche Weise Ihre Systeme ausfallen werden. Sie werden es also wissen. Je länger Sie in der Branche tätig sind, Sie wissen das, zum Beispiel ein Java-Server fällt auf X, Y, Z verschiedene Arten aus, also sollten wir wahrscheinlich unseren JVM-Heap überwachen, oder was auch immer es ist.
Jared Kells:
Das wollte ich sagen!
Jordan Simonowski:
Ich werde versuchen, nicht zu viel darauf einzugehen...
Jared Kells:
Der Speicher geht aus!
Jordan Simonowski:
Ja. Also das ist etwas, von dem du erwartest, dass es irgendwann scheitern wird. Und das ist etwas, das Sie als bekannt unbekannt betrachten können. Aber das Versprechen der Beobachtbarkeit ist, dass wir genügend Daten liefern sollten, um neue Fragen stellen zu können. Die Art und Weise, wie darüber gesprochen wird, sehen Sie, es ist eine unbekannte Unbekannte in unserem System, über die wir etwas herausfinden und neue Fragen stellen wollen. Und hier wird, glaube ich, die Beobachtbarkeit eingeführt, um diese Fragen zu beantworten. Reicht die Antwort aus? Willst du, dass ich näher auf dieses Zeug eingehe? Ich kann den ganzen Tag darüber reden.
Jared Kells:
Ist es wie ein [Crosstalk 00:08:05]. Also, um es dir noch einmal zu sagen, um zu sehen, ob ich es verstanden habe. Also, wenn ich eine, traditionell mit einer Java-App, habe, könnte ich Erinnerungen protokollieren. Das liegt daran, dass ich weiß, dass JVMs der Arbeitsspeicher ausgeht, und das ist eine Sache, die ich überwache, aber die Beobachtbarkeit ist umfassender. Sie übertreiben quasi das, was Sie überwachen und protokollieren, sodass Sie...
Jordan Simonowski:
Ja. Und ich würde nicht unbedingt sagen, dass es übertrieben ist. Ich denke, es fügt Ihren Daten vielleicht etwas mehr Kontext hinzu. Wenn also jemand von Ihnen schon einmal mit Traces gearbeitet hat, ist Observability der Funktionsweise von Traces sehr ähnlich und baut einfach auf der Prämisse von Traces auf, schätze ich. Sie erstellen also diese Ereignisse, und bei diesen Ereignissen handelt es sich um verschiedene Transaktionen, die in Ihren Anwendungen stattfinden könnten, wobei normalerweise eine Anfrage eingereicht wird. Und mit dieser Anfrage können Sie ihr eine ganze Reihe von Kontext hinzufügen. Sie können hinzufügen, auf welchem Server dies möglicherweise läuft, in welcher Zeitzone. All diese zusätzlichen und all die Aufreger. Sie können die Benutzeragentur hineinwerfen, wenn Sie möchten. Die Idee der Beobachtbarkeit besteht darin, dass Sie nicht unbedingt durch Daten mit hoher Kardinalität eingeschränkt sind. Daten mit hoher Kardinalität sind Datensätze, die sich in Bezug auf die Art der Daten, die sie repräsentieren, oder die Kombinationen von Datensätzen, die Sie haben könnten, erheblich ändern können.
Jordan Simonowski:
Wenn Sie also Versandmetriken für etwas haben möchten, auf Benutzerbasis, und Sie sich ansehen möchten, wie verschiedene Benutzer von den Dingen betroffen sind, würde das als Metrik mit hoher Kardinalität betrachtet werden. Und in den meisten Fällen können traditionelle Überwachungsunternehmen oder Anbieter von Messwerten Ihnen das nicht wirklich als Service anbieten. Das ist der Punkt, an dem Sie anfangen, wahnsinnig hohe Rechnungen für Dinge wie Datadog oder was auch immer es ist, zu bezahlen, weil sie jetzt als neue Metriken betrachtet werden. Im Gegensatz zu Observability versuchen wir, unsere Daten zu speichern und sie so abzufragen, dass wir ziemlich große Datensätze speichern und sagen können: „Cool. Wir haben Fehler, die von dieser Art von Benutzern kommen.“ Und Sie können dort anfangen, Korrelationen zu bestimmten Dingen aufzubauen. Sie können herausfinden, dass bei Benutzern aus einer bestimmten Zeitzone oder einem bestimmten Gerät nur dieser Fehler auftritt. Und von dort aus können Sie, glaube ich, bessere Methoden entwickeln, um zu verstehen, wie eine bestimmte Änderung die Dinge kaputt gemacht haben könnte. Oder bestimmte Randfälle, die Sie sonst mit etwas wie CPU- oder Speicherüberwachung nicht erkennen könnten.
Angad Seth:
Wäre es fair zu sagen...
Jared Kells:
Ja. Es ist [Crosstalk 00:11:02].
Angad Seth:
Oh, tut mir leid, Jared.
Jared Kells:
Nein, du kannst...
Angad Seth:
Wäre es fair zu sagen, dass Beobachtbarkeit also im Grunde eine Reihe von Prinzipien ist oder ein Weg, unbekannte Unbekannte zu finden?
Jordan Simonowski:
Ja.
Angad Seth:
Oh.
Jess Belliveau:
Und ich sollte Sie besser ausrüsten, um herauszufinden, dass eine Menge Leute denken, Sie denken, dass Beobachtbarkeit eine Sache ist, die Sie einsetzen und haben und ein Kästchen ankreuzen können, aber ich mag Ihre Wortwahl, wenn es um eine Reihe von Prinzipien oder Best Practices geht. Es gibt Ihnen sozusagen eine Anleitung zu diesen Themen und sorgt dafür, dass Ihre Anwendung eine gute Protokollierung hervorbringt. Also strukturierte Protokolle. Sie erhalten also immer das gleiche Protokollformat, das Sie sich ansehen können. Tracing, worüber Jordan ein bisschen gesprochen hat. So haben Sie die Möglichkeit, zu verfolgen, wie ein Benutzer mit all den verschiedenen Microservices interagiert, und möglicherweise auch zu sehen, wo etwas schief läuft, und auch Kennzahlen. Das Gute an Metriken ist also, dass wir die Dinge ein bisschen umdrehen und versuchen, eine Anwendung zu erstellen, anstatt, und ich will nicht zu technisch werden, Black-Box-Monitoring zu machen, bei dem wir draußen sind und versuchen, mit solchen Sonden und Checks reinzuschauen. Aber die Idee bei Metriken ist, dass die Anwendung diese Metriken tatsächlich ausgibt, um uns darüber zu informieren, in welchem Zustand sie sich befindet, und sie dadurch besser beobachtbar zu machen.
Jess Belliveau:
Ja, mir gefällt deine Wortwahl, Angad, dass es wie diese Praktiken ist, diese Art von Leitfaden, wohin man gehen muss, was wahrscheinlich zu dem nächsten Punkt führt, warum sollte ein Team das implementieren wollen. Wenn du noch einmal anfangen willst, Jordan?
Jordan Simonowski:
Ja, ich kann anfangen. Und ich gebe dir auch ein bisschen mehr Zeit zum Reden, Jess in diesem. Ich werde nicht so viel schimpfen.
Jess Belliveau:
Oh, dafür habe ich mich nicht angemeldet!
Jordan Simonowski:
Ich denke, die Teams würden es wollen, weil es wirklich von Ihrer Organisation und, glaube ich, von der Größe der Teams abhängt, in denen Sie arbeiten. In den meisten Fällen würde ich sagen, dass Sie Observability nicht selbst im eigenen Haus erstellen möchten. Das ist etwas, das Sie können, Observability-Funktionen selbst, Sie werden es nicht erreichen, indem Sie einfach etwas kaufen, also Sie können Dev-Ops nicht kaufen, Sie können Agile nicht kaufen, Sie können Observability auch nicht kaufen.
Jared Kells:
Warte, warte. Auf meinem Runsheet steht, dass ich für Easy Agile werben soll, das klingt also nach einem guten Übergang-
Jess Belliveau:
Es sei denn, du willst es kaufen. Wenn du Agile kaufen möchtest, dann [Crosstalk 00:13:55] im Marketplace.
Jared Kells:
Ja, tut mir leid, tut mir leid, ja! Ja, mach weiter.
Jordan Simonowski:
Sie können Tools kaufen, die Ihnen das Leben erheblich erleichtern, und es gibt bereits eine Menge Dinge da draußen, die Dinge für Menschen tun und wirklich interessante Daten an die Oberfläche bringen, die sich die Leute vielleicht ansehen möchten. Ich denke, es gibt ein paar Start-ups wie LightStep und Honeycomb, die Ihnen eine wirklich intuitive Möglichkeit bieten, Ihre Daten in der Produktion zu verstehen. Aber warum Sie solche Dinge benötigen, ist, dass Sie den Zustand Ihrer Systeme zu einem bestimmten Zeitpunkt wissen wollen, und um, glaube ich, eine gute Betriebshygiene und eine gute Produktionsexzellenz zu entwickeln, ich denke, wie Liz Fong-Jones es ausdrücken würde, müssen Sie in der Lage sein, diese Rückkopplungsschleife zu schließen. Wir haben bereits eine ganze Reihe von Tools. Wir haben also CICD-Systeme eingerichtet. Wir haben jetzt Feature-Flags, die uns, glaube ich, helfen, Deployments von Releases zu entkoppeln. Sie können Code bereitstellen, ohne tatsächlich Code zu veröffentlichen, und Sie können diese Macht jetzt Ihren PMs geben, wenn Sie möchten, mit Feature-Flags, was großartig ist.
Jordan Simonowski:
Aber jetzt können Sie diesen Kreislauf auch komplett schließen, und während Sie eine Anwendung bereitstellen, können Sie sagen: „Ich möchte diese Bereitstellung kanalisieren. Ich möchte dies für 10% meiner Benutzer bereitstellen, vielleicht für Benutzer, die sich für Beta-Versionen oder etwas aus unserer Anwendung angemeldet haben, und Sie können sich tatsächlich ansehen, wie das funktioniert, bevor Sie es einem breiteren Publikum zugänglich machen. Es macht Bereitstellungen also viel sicherer. Es gibt Ihnen auch ein besseres Verständnis dafür, wie Sie sich auch auf die Benutzer auswirken. Und es gibt eine ganze Reihe von Tools, mit denen Sie auch diese Dinge ermitteln können. Wenn Sie sich also ansehen, wie viele Unternehmen derzeit SRE durchführen, oder wenn Sie wissen, wie zuverlässig ihre Anwendungen aussehen, haben Sie auch Dinge wie SLOs im Einsatz. Und SLOs-
Jared Kells:
Was ist ein SLO?
Jordan Simonowski:
Sie sind alle mit Benutzererlebnissen verbunden. Sie sagen also: „Kann mein Benutzer diese spezielle Interaktion durchführen?“ Und wenn Sie das effektiv messen und wissen, wie sich Ihre Änderungen auf die Benutzer auswirken, können Sie ganz einfach entscheiden, ob Sie weiterhin Funktionen bereitstellen oder ob Sie alles fallen lassen und an der Zuverlässigkeit arbeiten, um sicherzustellen, dass Ihre Benutzer nicht beeinträchtigt werden. Es ist also dieser sehr nutzerorientierte Ansatz, Dinge zu tun. Ich denke, wenn es darum geht, den Kreis zu schließen, liefert uns die Beobachtbarkeit die Daten, anhand derer wir sagen können: „Ja, so sind die Nutzer betroffen. Auf diese Weise, schätze ich, geht es dem 99. Perzentil unserer Nutzer gut, aber wir haben 1%, die negative Probleme mit unserer Anwendung haben.“ Und von dort aus können Sie wirklich Dinge lokalisieren und sagen: „Cool. Benutzer mit diesem bestimmten Browser oder diesem speziellen Browser oder wo wir diese App bereitgestellt haben. „Nehmen wir an, wenn Sie eine globale Bereitstellung haben, haben Sie sie zuerst auf einer Insel bereitgestellt, weil es Ihnen eigentlich egal ist, was mit ihnen passiert. Sie können sagen: „Oh, wir haben tatsächlich Sachen für sie kaputt gemacht.“ Und Sie können es rückgängig machen, bevor Sie sich auf 100% Ihrer Nutzer auswirken.
Jared Kells:
Ja. Mir hat gefallen, was du über den Test gesagt hast. Ich habe das Akronym vergessen, aber ich teste tatsächlich das Verhalten des Endbenutzers. Das finde ich ziemlich aufregend, weil wir all diese Metriken haben, die ein bisschen nutzlos sind. Sie sind cool: „Oh, es nutzt 1% CPU, wie es immer ist, jetzt ist mir das egal“, aber kann ein Benutzer die App öffnen und ein Problem mit der Maus herumschleppen? Es ist wie...
Jess Belliveau:
Ja, das ist ein wirklich gutes Beispiel, oder?
Jared Kells:
Das ist es, was mir wirklich wichtig ist.
Jess Belliveau:
Bei der CPU-Sache mit 1% könnte man sich ein Diagramm zur CPU-Auslastung ansehen und eine Bereitstellung sehen, und die CPU-Auslastung ändert sich nicht. Ist alles gesund oder nicht? Sie wissen es nicht, aber wenn Sie tiefere Informationen über die Benutzerinteraktionen erhalten, könnten Sie 1% der CPU verwenden, um HTTP500-Fehler an 80% der Kundenbasis zu verteilen, so oder so.
Angad Seth:
Wie macht man das? Der SLO-Bit, woher weißt du, dass sich ein Benutzer anmelden und ein Problem ziehen kann?
Jordan Simonowski:
Ja. Ja, das würde mit einer guten Instrumentierung einhergehen...
Angad Seth:
Gute Frage?
Jordan Simonowski:
Ja, es kommt darauf an, die Beobachtbarkeit zu berücksichtigen, wenn Sie neue Funktionen entwickeln, genauso wie Sie darüber nachdenken würden, beim Schreiben eine bestimmte Sache in Ihrem Code zu protokollieren oder Tests für Ihren Code zu schreiben, während Sie auch Code schreiben. Sie sollten darüber nachdenken, wie Sie etwas instrumentieren können und wie Sie verstehen können, wie diese spezielle Funktion in der Produktion funktioniert. Denn ich denke, viele Agile- und Dev-Ops-Prinzipien sagen uns jetzt, dass wir unsere Anwendungen in der Produktion haben wollen. Und als Entwickler endet unsere Verantwortung nicht, wenn wir etwas bereitstellen. Unsere Verantwortung als Entwickler endet, wenn wir dem Unternehmen einen Mehrwert geboten haben. Und Sie müssen verstehen, dass Sie das tatsächlich tun. Und da müssen Sie, glaube ich, über die Beobachtbarkeit bei vielen dieser Dinge nachdenken und Ihre Erfolgskennzahlen tatsächlich messen. Wenn Sie also wissen, dass Ihre Anwendung erfolgreich ist, wenn sich Ihr Benutzer anmelden und Dinge herumziehen kann, dann ist das genau das, was Sie messen möchten.
Jared Kells:
Ich denke, wir müssen bauen...
Jordan Simonowski:
Ja?
Jared Kells:
Oh, tut mir leid, Jordan.
Jordan Simonowski:
Nein, du gehst.
Jared Kells:
Ich wollte nur sagen, dass wir unsere Apps bereits unter Berücksichtigung von Integrationstests entwickeln müssen. Also browserbasierte Tests rund um neue Funktionen. Es würde also darum gehen, Funktionen unter Berücksichtigung dieser und derselben Sache zu entwickeln, aber für Tests und Produktion.
Jess Belliveau:
Ja, und das eigentliche Wie, der eigentliche Teil zum Schreiben von Code, da ist dieses wirklich großartige Projekt, das Open Telemetrie-Projekt, das all diese Arten von APIs und SDKs bereitstellt, die Entwickler nutzen können, und es ist herstellerunabhängig. Wenn du also über das Wie sprichst, etwa: „Wie mache ich das? Wie instrumentiere ich Dinge?“ Oder: „Wie gebe ich Kennzahlen aus?“ Sie bieten all diese hilfreichen Bibliotheken und Includes, die Sie haben können, denn das Letzte, was Sie tun möchten, ist, diese benutzerdefinierte Lösung auf den Markt zu bringen, weil Sie dann nur Ihre technischen Schulden erhöhen. Sie versuchen, die Dinge einfacher zu machen, verlassen sich dann aber auf: „Nun, ich muss Jared Kells weiter beschäftigen, weil er unsere Login-Engine geschrieben hat und niemand sonst weiß, wie sie funktioniert.
Jess Belliveau:
Und dann die andere Sache, die mir auch bei so etwas wie offener Telemetrie in den Sinn kommt, und wir haben ein bisschen über Datadog gesprochen. Datadog ist also ein SaaS-Anbieter, der sich auf Observability spezialisiert hat. Und Sie würden Ihre Metriken und Ihre Logs und Ihre Traces an sie übertragen und sie bieten Ihnen eine Benutzeroberfläche zum Anzeigen. Wenn Sie sich für etwas entscheiden, das herstellerunabhängig ist, nehmen wir einfach das Beispiel von Easy Agile. Nehmen wir an, sie starten Datadog und in sechs Monaten wollen wir Datadog nicht mehr verwenden, wir wollen SignalFX oder was auch immer das Splunk-Modell jetzt ist, verwenden.
Jordan Simonowski:
Ich denke NorthX.
Jess Belliveau:
Ja. Du kannst deinen Endpunkt ändern, dieselben Metriken und all diese Dinge, vielleicht mit ein paar kleinen Anpassungen, aber die Idee ist, dass du dich nicht auf eine einzige Sache festlegen willst.
Jordan Simonowski:
Ihre Datenstrukturen bleiben gleich.
Jess Belliveau:
Ja. Damit du es fast nahtlos machen könntest, ohne dass die Entwickler es wissen. In der Vergangenheit gab es sogar Unternehmen, die meiner Meinung nach auf mehrere Anbieter umgestellt haben. Sie könnten also Anbieter A nutzen und dann mit Anbieter B einen Machbarkeitsnachweis durchführen, um zu sehen, wie die Erfahrung ist, und Sie geben Ihre Daten einfach auch dort weiter.
Jared Kells:
Ja. Ich denke, unsere Verbindung zu Datadog wird aus all den Dashboards und allem, was wir gemacht haben, bestehen. Es sind nicht so sehr die Daten.
Jess Belliveau:
Ja. Das ist quasi der große Verkaufsschlager, richtig. Das ist die Art und Weise, wie du interagierst. Das ist der Punkt, an dem sie ins Spiel kommen wollen. Es macht es Ihnen leichter, diese Daten zu interpretieren und sie so zu manipulieren, dass sie Ihren Bedürfnissen entsprechen und so weiter.
Jordan Simonowski:
Observability deutet auf Dashboards hin, oder?
Jess Belliveau:
Ja, vielleicht. Du hast diesen Begriff auch benutzt, Jordan, „Produktionsexzellenz“. Und wenn wir darüber sprechen, wer Observability braucht, habe ich ein bisschen darüber nachgedacht, während Sie gesprochen haben. Und für mich ist Production Excellence, oder in Apptio nennen wir das Produktionsbereitschaft, Betriebsbereitschaft und diese Art von Dingen ist so, als ob wir etwas in der Produktion einsetzen wollen, wie zum Beispiel welche Best Practices wollen wir haben, bevor wir das tun? Und ich denke, Observability ist eine wirklich gute Idee, weil sie Ihnen in Zukunft hilft. Sie wissen nicht, welche Probleme Sie später haben werden, aber Sie rüsten Ihre Teams so aus, dass sie problemlos auf diese Probleme reagieren können. Wir waren wahrscheinlich alle dort, wir haben den Produktionscode implementiert und wir haben keine Observability, wir haben einen riesigen Ausfall. Was ist schief gelaufen? Nun, niemand weiß es, aber wir wissen, dass das die Lösung ist, und es ist schwer, daraus zu lernen, oder man muss wohl daraus lernen und den Benutzer vor zukünftigen Dingen schützen, ja.
Jess Belliveau:
Wenn ich denke, dass einfache Beobachtbarkeit gewinnt, kommt mir als Erstes die ganze Idee der strukturierten Protokollierung in den Sinn, was eigentlich die Idee ist, dass Ihre Anwendung zuallererst Sie protokollieren. Ziemlich wichtig als Ausgangspunkt, aber dann haben Sie ein strukturiertes Protokollformat, mit dem Sie die Logs auch programmgesteuert weitergeben können. Wenn Sie in der Zeit zurückreisen, sah die Protokollierung vielleicht nur wie einfacher Text mit einer Zeile, einem Zeitstempel und einer Fehlermeldung aus. Was auch immer der Entwickler beschlossen hat, in die Standardausgabe zu schreiben, oder in die Fehlerdatei oder so ähnlich. Ich denke, es gibt einen allgemeinen Trend hin zu JSON, einem tatsächlich formatierten Blob mit dieser bekannten Struktur, damit Sie ihn sich ansehen können. Tracing ist wahrscheinlich kein einfacher Gewinn. Das ist ein bisschen schwieriger. Sie können es mit offener Telemetrie und Bibliotheken und so implementieren. Ich denke, es erfordert ein bisschen mehr Verständnis Ihrer Codebasis und darüber, wo die Ablaufverfolgung ausgelöst werden soll, und solche Dinge, das Analysieren von Kontexten, solche Dinge.
Jordan Simonowski:
Ich denke Atlassian, wenn du wahrscheinlich einfach nur wissen willst, dass alles in Ordnung ist. Auf einer ziemlich oberflächlichen Ebene. Vielleicht willst du einfach nur eine Art Uptime für einen Trend machen. Und wenn dann, glaube ich, Ihr Code komplexer wird oder Ihr Produkt etwas komplexer wird, können Sie anfangen, Dinge hinzuzufügen. Aber ich denke, die Dinge, die Sie kennen, tatsächlich zu kennen oder an die Oberfläche zu bringen, könnte kaputt gehen. Das wären wahrscheinlich deine schnellsten Siege.
Jess Belliveau:
Nun, lassen Sie uns einige Dinge zur weiteren Lektüre erwähnen. Wenn Sie sich einen Überblick über das Ganze verschaffen wollen, hat das Google SRE-Buch von vor ein paar Jahren begonnen, echte Observability stark in Bewegung zu setzen. Das Google SRE-Zeug deckt die gesamte Bandbreite ihrer Praxis im Bereich Soak Reliability Engineering ab, und Observability ist ein Teil davon, dazu gibt es einige großartige Kapitel. Ich glaube, O'Reilly hat jetzt ein Buch über Observability veröffentlicht, das sich nur der Beobachtbarkeit widmet.
Jordan Simonowski:
Ich denke, das ist noch in der frühen Version, wenn die Leute Kapitel googeln wollen.
Jess Belliveau:
Das offene Telemetrie-Zeug, wir werden einen Link dazu setzen, ich denke, das ist wirklich praktisch zu wissen.
Angad Seth:
Aus [unverständlich 00:26:12], das ist meine Sicht als Entwickler, sage ich, ich wollte Cornflake Use Datadog bei Easy Agile einführen. Nicht sehr vertraut, ich fühle mich nicht sehr wohl damit. Ich weiß, wie man navigiert, aber wie kann ich schnell mit der Einführung von Observability beginnen? Es tut mir leid, dass ich meinen direkten Job oder meinen Arbeitsplatz gesperrt habe.
Jordan Simonowski:
Ich würde sagen, ich könnte hier voreingenommen sein. Jess, korrigiere mich oder gib deine Meinung dazu ab, ich würde mich dafür stark zu SLOs neigen. Und Sie können das kurz im SRE nachlesen-
Jess Belliveau:
Wofür steht SLO, Jordan?
Jordan Simonowski:
Okay, tut mir leid. Schlagworte! SLO ist ein Service Level Objective, nicht zu verwechseln mit Service Level Agreement. Eine Vereinbarung selbst ist vertraglich und Sie können den Leuten Geld zahlen, wenn Sie gegen diese verstoßen. Ein SLO ist etwas, das Sie in Ihrem Team festlegen und Sie haben ein Zuverlässigkeitsziel, weil wir an einem Punkt angelangt sind, an dem wir verstehen, dass sich alle Systeme zu jedem Zeitpunkt in einem heruntergekommenen Zustand befinden. Und ja, Zuverlässigkeit ist nicht unbedingt binär, sie ist nicht unzuverlässig oder zuverlässig. Meistens ist es meistens zuverlässig und das gibt uns eine bessere gemeinsame Sprache, denke ich. Und Sie können das SRE-Handbuch von Google lesen, das kostenlos online verfügbar ist und Ihnen ein ziemlich gutes Verständnis von Datadog vermittelt.
Jordan Simonowski:
Ich glaube, als ich es das letzte Mal benutzt habe, gab es ein SLO-Angebot. Aber ich denke, wie ich bereits erwähnt habe, haben Sie ein SLO für bestimmte Funktionen oder Merkmale Ihrer Anwendung festgelegt. Sie sagen: „Mein Benutzer kann das in 99% der Fälle tun“, oder was auch immer Sie sich für ein anderes Zuverlässigkeitsziel setzen möchten. Ich würde eine Zuverlässigkeit von fünf Neunern nicht empfehlen. Sie werden sich wahrscheinlich selbst ausbrennen, wenn Sie versuchen, dorthin zu gelangen. Und du hast dir dieses Ziel gesetzt. Und Sie wissen genau, was Sie messen, Sie messen bestimmte Arten von Funktionen. Und Sie wissen, dass Benutzer betroffen sind, wenn Sie gegen diese Regeln verstoßen. Und hier können Sie tatsächlich anfangen, über Observability nachzudenken. Sie können darüber nachdenken: „Welche anderen Funktionen implementieren wir, mit deren Messung wir beginnen können?“ Oder: „Welche nutzerorientierten Dinge implementieren wir, mit deren Messung wir beginnen können?“
Jordan Simonowski:
Andere Dinge, die Sie sich wahrscheinlich ansehen könnten, sind, ich denke, sie sind sowieso alle in dem Buch behandelt, die Aktualität der Daten in gewisser Weise. Sie möchten sicherstellen, dass die Daten, die Benutzern angezeigt werden, relativ aktuell sind. Sie möchten nicht, dass sie sich veraltete Daten ansehen, also können Sie auch versuchen, solche Dinge zu messen. Aber Sie können es so ziemlich in die meisten Funktionen einer Website unterteilen. Es ist nicht mehr wie bei einem Ping-Check, bei dem Sie nur sagen: „Ja, HTTP, okay. Meine Bewerbung ist in Ordnung.“ Sie sagen: „Meine Benutzer sind tatsächlich von Dingen betroffen, die nicht funktionieren.“ Und von dort aus können Sie anfangen, Dinge zu messen. Und das sollte Ihnen ein besseres Verständnis oder zumindest eine bessere Vorstellung davon geben, wo Sie mit dem, was Sie messen möchten, beginnen und wie Sie es messen möchten. Das wäre meine Meinung dazu, wo Sie damit beginnen sollten, wenn Sie es einführen wollen.
Jared Kells:
Wir werden ein bisschen über den Status sprechen und wie bei einigen davon, wie bei unseren sehr Frontend-lastigen Anwendungen, die wir erstellen, sodass die Anwendungen, die wir erstellen, einfach im Browser laufen und der traditionelle Status, wie Sie sich das vorstellen würden, einfach eine sehr einfache API abruft, die einige Dinge mit einer gewissen Authentifizierung in die Datenbank schreibt und so weiter. Was die Zuverlässigkeit der Dienste angeht, so ist es wirklich zuverlässig. Diese winzigen APIs haben einfach nie Probleme, weil es einfach so einfach ist. Und nun ja, sie haben eine Menge Überwachung rund um das Thema. Aber unser gesamter Zustand ist eigentlich, wenn Sie sagen: „Beobachten Sie den Zustand des Systems“, größtenteils der Zustand in einem Browser. Und wie bringen wir Beobachtbarkeit in das hinein?
Jess Belliveau:
Eine große Sache ist wirklich, es gibt keine Sache, die auch für alle passt. Wenn wir auch über SLO-Sachen sprechen, geht es darum zu verstehen, was nicht so sehr für Ihr Unternehmen, sondern auch für Ihr Team wichtig ist. Wenn Sie dieses Produkt liefern, was ist Ihnen besonders wichtig? Also ein SLO, das für mich bei Apptio funktionieren könnte, wird wahrscheinlich nicht für Easy Agile funktionieren. Das erweitert auch mein Wissen über Frontend-Sachen wirklich, aber wenn wir sagen, dass wir auch den Staat beobachten wollen, meinen wir nicht unbedingt nur den Staat. Vielleicht möchten Sie bei jeder dieser APIs wissen, wie lang die Antwortzeit für diese API ist, wenn sie ausgelöst wird. Das könnte also eine wichtige Metrik sein. Sie können also feststellen, ob eine dieser APIs zu Latenz führt und Ihre Benutzererfahrung dadurch beeinträchtigt wird. Zum Beispiel: „Hey, als wir in der dritten Version waren und Benutzer hier mit unserem Service interagierten, reagierte er mit dieser prozentualen Latenz. Wir haben eine Version veröffentlicht und seitdem sehen wir, dass es jetzt in diesem Perzentil liegt. Haben wir die Leistung herabgesetzt?“ Die Benutzer beschweren sich vielleicht nicht, aber das könnte etwas sein, das das Team dann untersuchen und zu einem Sprint hinzufügen kann. Hey, ich verwende jetzt Agile-Begriffe. Achtung!
Jared Kells:
Das ist ein wirklich gutes Beispiel, Jess. Leistungsprobleme sind für uns in der Regel keine API, die schlecht funktioniert. Es liegt daran, dass in dieser sehr komplizierten Frontend-Anwendung nicht mehr in der gleichen Reihenfolge wie früher ausgeführt wird, oder es gibt eine komplexe Interaktion, an die wir nicht gedacht haben, sodass mehr Daten als erwartet angefordert werden. Die APIs kehren zurück. Sie sind größtenteils nie langsam, aber wir haben Leistungsrückgänge, von denen wir vielleicht nichts wissen, ohne sie zu sehen oder zu untersuchen. Die Beobachtbarkeit erfolgt wirklich auf der Browserebene des einzelnen Benutzers. Macht das Sinn? Ich möchte wissen, wie lange es gedauert hat, bis diese spezielle Interaktion stattgefunden hat.
Jess Belliveau:
Ja. Solche Dinge habe ich noch nie gemacht. Außerdem, ich schätze, Sie könnten möglicherweise betroffen sein, und dann haben Sie es auch mit Endbenutzer-Manifestationen zu tun. Sie könnten wahrnehmen...
Jared Kells:
Ja, sicher.
Jess Belliveau:
... Höhere Leistung auf ihrem Laptop oder so, oder ihrem ISP oder so. Es wäre wirklich schwierig, sicherzustellen, dass Sie von solchen Dingen nicht auch Geräusche bekommen.
Jordan Simonowski:
Ja. Es gibt wohl Tools wie Sentry, die existieren, um Ihnen ein bisschen besser zu verstehen, was an Ihrem Frontend passiert. Die Art und Weise, wie Sentry in der Regel mit JavaScript arbeitet, ist, dass Sie eine verkleinerte Map Ihres JS auf Sentry hochladen, Ihren Code bereitstellen und dann, wenn etwas kaputt geht oder auf ziemlich unerwartete Weise funktioniert, das in der Regel auftaucht, wobei Sentry Ihnen genau sagt, in welcher Zeile diese Art von Dingen passiert, und es ist ein wirklich cooles Tool für diese Firmenkram. Ich weiß nicht, ob es dir die richtigen Einblicke geben würde, glaube ich, in Bezug auf Leistung oder...
Jared Kells:
Ja, wir verwenden ein ähnliches Tool und es funktioniert bei Abstürzen und solchen Dingen. Und was die Beobachtbarkeit angeht, protokollieren wir Aktionen wie Zustandsmutationen im Frontend, nicht die tatsächliche Statusänderung, sondern nur Beschriftungen, die angeben, dass Sie eine Problemzusammenfassung aktualisiert haben oder auf diese Schaltfläche geklickt haben, so etwas, und wir senden sie mit unseren Absturzberichten. Und es ist super hilfreich, diese Art von Beobachtbarkeit zu haben. Also ich glaube, ich weiß, wovon ihr redet. Aber ich bin nur [Crosstalk 00:35:25], ja.
Jess Belliveau:
Ja, das ist, glaube ich, fast eine Art von Rückverfolgung. Wenn Jordan und ich über Tracing sprechen, denken wir vielleicht an 12 verschiedene Microservices in AWS, die alle miteinander interagieren, während Sie das eher verschieben. Das ist quasi alles, was im Browser interagiert, und nur diese Historie davon zu haben, ist das, was der Benutzer getan hat und wie es dazu kam...
Jared Kells:
In diesem Staat.
Jess Belliveau:
In diesem Staat, ja.
Jordan Simonowski:
Ich schätze, selbst wenn Sie nicht viele Microservices haben, wenn Sie über bestimmte sprechen, wie Sie sagen, sind Ihre API-Anfragen größtenteils in Ordnung, aber manchmal haben Sie besonders große Nutzlasten-
Jared Kells:
Wir müssen tatsächlich überwachen, ich weiß nicht, vielleicht können Sie dabei helfen, wir sollten eigentlich überwachen, mit wem wir zusammenarbeiten. Es ist tatsächlich viel wahrscheinlicher, dass wir ein Leistungsproblem mit einer Xero-API haben werden, als... Wir sehen es nicht, der Browser sieht es auch, was...
Jordan Simonowski:
Ja, und Tracing löst all diese Regressionen für Sie. Die meisten Tracing-Bibliotheken, z. B. wenn Sie Node-Apps oder was auch immer in Ihrem Backend ausführen. Ich kann dir nur etwas über Node erzählen, weil ich wahrscheinlich die meiste Erfahrung mit dem Schreiben von Node-Sachen habe. Du gibst quasi einfach Didi Trace ein, eine Datadog-Bibliothek für das Tracing in dein Backend und deinen Hook selbst in all die, glaube ich, gängigen Bibliotheken, mit denen du normalerweise arbeiten wirst, glaube ich. Wenn Sie zum Beispiel für Express oder nur für viele HADP-Bibliotheken sowie für ein paar AWS-Services arbeiten, wird es sich quasi von selbst einbinden. Und Sie können es tatsächlich genau bestimmen. Es wird Ihnen auf dieser ziemlich coolen Servicekarte irgendwie genau zeigen, mit welchen Diensten Sie interagieren und wo Sie möglicherweise eine Regression erleben. Und ich denke, Spuren dienen dazu, diese Informationen an die Oberfläche zu bringen, was cool ist. Das könnte also etwas sein, das es wert ist, untersucht zu werden.
Jess Belliveau:
Es ist lustig. Das hat etwas nichts mit Beobachtbarkeit zu tun, aber Sie haben mich gerade dazu gebracht, ein bisschen mehr darüber nachzudenken, warum Sie sagen, dass Sie auch von Drittanbietern abhängig sind. Und etwas, das meiner Meinung nach wirklich wichtig ist und manchmal übersehen wird, ist, dass sich so viele von uns heute auf Drittanbieter verlassen, da AWS eine große Sache ist. Viele Leute schreiben Apps, für die AWS-Services erforderlich sind. Und ich denke, die meiste Zeit gehen die Leute einfach davon aus, dass AWS oder Jira oder was auch immer zu 100% verfügbar ist und immer verfügbar ist. Und sie schreiben ihren Code nicht so, dass er mit Ausfällen umgeht. Und ich finde es super wichtig. Ich habe schon so oft Leute gesehen, die die AWS-API verwenden, und sie implementieren kein exponentielles Back-Off. Also versuchen sie im Grunde, die AWS-API zu erreichen. Sie schlägt fehl oder sie werden zum Beispiel gedrosselt, und dann gehen sie einfach in einen Fehlerzustand über und geben dem Benutzer einen Fehler. Aber Sie könnten möglicherweise die Benutzererfahrung verbessern, einen automatischen Wiederholungsmechanismus einbauen lassen und so weiter. Es hat nicht wirklich etwas mit der Beobachtbarkeit zu tun, aber es ist etwas Besonderes.
Jared Kells:
Und den Nutzern ist das egal, oder? Es interessiert niemanden, ob es sich um ein AWS-Problem handelt. Es ist dein Problem, richtig, deine App ist zu langsam.
Jess Belliveau:
Nun, sie benutzen deine App. Genau richtig. Es wirkt sich irgendwie auf Sie aus, also ist es in Ihrem Interesse, sich vor einem Upstream-Fehler zu schützen oder zumindest den Benutzer zu informieren, wenn dies der Fall ist. Ja.
Jared Kells:
Nun, ich glaube, wir müssen ihn diesen Podcast nennen, weil es eine Stunde her ist. Wir hatten maximal 45 Minuten unterrichtet.
Jess Belliveau:
Wir könnten einfach weitermachen. Wir könnten einen zweiten Teil brauchen! Vielleicht können wir [Cross Talk 00:39:21] anfragen.
Jared Kells:
Vielleicht! Ja.
Jess Belliveau:
Oder wir starten einfach unseren eigenen Podcast! Ja.
Angad Seth:
Also, was waren deine wichtigsten Erkenntnisse heute, wenn man bedenkt, dass Angad und ich gerade etwas über Beobachtbarkeit lernen, Angad, was war heute deine größte Erkenntnis über Beobachtbarkeit? Meine größte Erkenntnis war, dass Beobachtbarkeit nicht mit Datadog gleichzusetzen ist. Nein, tut mir leid! Es war einfach sehr faszinierend zu lernen, wie man die bekannten Unbekannten quantifiziert. Ich weiß nicht, ob das ein guter Imbiss ist, aber...
Jess Belliveau:
Jeder Imbiss ist ein guter Imbiss! Was ist mit dir, Jared?
Jared Kells:
Ich glaube, weil ich gerade über Zustandsmanagement sprechen wollte, und ein Teil davon war, dass wir im Moment diese Fähigkeit haben, durch die Architektur unserer Frontends den Status der App zu erfassen und einen Kunden dazu zu bringen, uns seinen Status zu senden, im Grunde genommen. Und wir können es in unsere App laden und einfach genau sehen, wie es war, genau so, wie unser Bundesstaat konzipiert ist. Aber was noch cooler sein könnte, ist vielleicht etwas Observability zur Unterstützung in das Frontend einzubauen. Ich denke, anstatt einfach zu haben, haben wir diese Schaltfläche, um uns Ihre Support-Informationen zu senden, die uns einen Haufen des Status schicken, aber anstatt die Konsole im Browserprotokoll zu protokollieren, könnten wir die Konsole protokollieren und uns irgendwo in unserem Frontend anmelden, sodass unsere Kunden uns die Aktionen senden sollten, die sie ausgeführt haben, wenn sie auf „Support-Informationen senden“ klicken.
Jared Kells:
Zum Beispiel: „Hey, da ist ein Bug, senden Sie uns Ihre Support-Informationen.“ Es muss kein Drittanbieter-Dienst sein, der diese Observability-Daten sammelt. Wir könnten einfach in unser... Darüber denke ich also nach.
Jess Belliveau:
Ja, ganz sicher. Es wird wahrscheinlich auch viel weniger aufdringlich sein, als einige der Sachen von Drittanbietern, die ich gesehen habe.
Jared Kells:
Ja. Bei einigen dieser Integrationen ist das ziemlich schwierig, insbesondere wenn Sie Apps entwickeln, die hinter einer Firewall ausgeführt werden.
Jess Belliveau:
Ja
Jared Kells:
Sie können nicht einfach mit einigen dieser Dritten sprechen. Also ja, es ist trotzdem cool. Es ist wirklich interessant.
Jess Belliveau:
Nun, ich hoffe, jemand da draußen, der zuhört, hat etwas gelernt, und Jordan und ich werden ein paar Links durchschicken, und wir können sie hoffentlich zu den Shownotes hinzufügen oder so, damit die Leute etwas mehr lesen können und...
Jared Kells:
Alles danke!
Jess Belliveau:
Danke für die Einladung, ja.
Jared Kells:
Vielen Dank für Ihre Zeit und danke allen fürs Zuhören.
Jordan Simonowski:
Danke allen.
Angad Seth:
Das war [unhörbar 00:41:55].
Jess Belliveau:
Schaltet nächste Woche ein!
Hör jetzt zu

Podcast
Easy Agile Podcast Folge 27 Inklusive Führung
„Es war mir eine Freude, mit Ray darüber zu sprechen, Teams zu stärken und Menschen zu helfen, ihr volles Potenzial auszuschöpfen“ - Mat Lawrence
Mat Lawrence, Chief Operating Officer bei Easy Agile, wird von Ray Arell unterstützt. Ray arbeitet derzeit als Direktor für Agile Transformations bei Dell Technologies, ist der Moderator des ACN-Podcasts und Vorsitzender des Verwaltungsrates der gemeinnützigen Forest Grove Foundation Inc.
Ray hat eine Leidenschaft für kollaborative und integrative Führung und liebt es, andere zu inspirieren und zu motivieren, ihr volles Potenzial auszuschöpfen. Genau darauf tauchen Mat und Ray in dieser Episode ein.
Ray und Mat beschäftigen sich mit Konzepten wie inklusiver und situationsbezogener Führung und dem Zusammenhang mit agilen Arbeitsweisen, der Stärkung des organisatorischen Gehirns und der Förderung der Authentizität innerhalb von Teams.
Dies ist eine fantastische Episode für angehende, aufstrebende und bestehende Führungskräfte! Viele tolle Tipps und Ratschläge, die wir mit Kollegen und Freunden teilen können, um zu verstehen, wie wir uns gegenseitig stärken und befähigen können.
Wir wünschen euch viel Spaß mit der Folge!
Transkript:
Matthew Lawrence:
Hallo Leute, hier ist Mat Lawrence. Ich bin der COO bei Easy Agile und freue mich sehr, heute von Ray Arell begleitet zu werden. Bevor wir zu unserer Podcast-Folge übergehen, möchte Easy Agile den traditionellen Hütern des Landes, von dem aus wir heute senden, danken, den Menschen im Gadigalsprachigen Land. Wir erweisen den Ältesten in der Vergangenheit, Gegenwart und in der Zukunft unseren Respekt und zollen allen Ureinwohnern der Torres Strait Islander und den First Nations, die heute zu uns kommen, denselben Respekt aus. Ray, danke, dass du heute zu uns gekommen bist. Ray ist eine kollaborative und integrative Führungskraft, die es liebt, andere zu inspirieren und zu motivieren, ihr volles Potenzial auszuschöpfen. Ray verfügt über 30 Jahre Erfahrung im Aufbau und in der Leitung herausragender multinationaler Teams in Fortune-100-Unternehmen, gemeinnützigen Organisationen und Startups. Darüber hinaus ist er als führender Experte für groß angelegte agile Adoptionen, technische Verfahren sowie schlanke und komplexe adaptive Systeme anerkannt. Also Ray, willkommen, wirklich schön, dich heute im Podcast zu haben.
Ray Arell:
Ich danke dir.
Matthew Lawrence:
Ich liebe es, zunächst zu verstehen, was Ihnen an der Arbeit als integrativer Leiter und der Arbeit mit Teams am besten gefällt.
Ray Arell:
Ja, also ich bin wahrscheinlich seit etwa 15 Jahren in Führungspositionen tätig und leite Teams unterschiedlicher Größe. Wenn Sie die intimeren, kleineren Teams von vielleicht fünf oder sechs Personen haben, mehr als Teams, die aus mehreren hundert Personen bestehen, die in einer Organisation arbeiten, deren Leiter ich sein könnte. Und was mir daran am meisten Spaß macht, ist der Kontakt zu den talentierten Leuten, die die Arbeit machen. Ich meine, wenn man in die Führung geht, ist eines der Dinge, von denen man quasi abgeht, nicht die fachkundige Person im Raum zu sein, die programmiert oder Hardwareentwicklung oder etwas anderes macht. Sie haben diese Leute, die jetzt nach einer Richtung oder Vision oder anderen Dingen suchen, um ihnen einen Sinn zu geben, damit sie ihren Tag voranbringen können.
Und ich coache gerne. Ich genieße Mentoring. Ich meine, ein Großteil meiner technischen Seite ist heute mehr Nostalgie, als es bei den neuesten Technologien relevant ist. Es ist bereichernd, wenn man jemanden sieht, der, wenn man an Daniel Pinks Arbeit denkt, die von Autonomie, Meisterschaft und Zielstrebigkeit geprägt ist, plötzlich merkt, dass er sich mit dem Ziel beschäftigt, das wir als Organisation verfolgen, und dann die Autonomie hat, einfach seinen Tag zu verbringen und mit anderen zu arbeiten und zusammenzuarbeiten. Und das war schon immer aufregend für mich.
Matthew Lawrence:
Das kann ich nachvollziehen. Ja. Ich denke, in unserem heutigen Publikum werden wir eine Mischung aus aufstrebenden Führungskräften, aufstrebenden Führungskräften und erfahrenen Führungskräften haben. Ich würde gerne auf Ihre Erfahrung zurückgreifen und idealerweise ein wenig zu einem früheren Zeitpunkt Ihrer Karriere zurückspulen, als Sie in die Führungsrolle übergegangen sind. Und ich würde gerne wissen, was zu dieser Zeit einige der Erfolge waren, die Sie in Ihrem Ansatz gesehen haben und den Sie im Laufe der Jahre zu wiederholen versucht haben?
Ray Arell:
Nun, ich denke, schon früh, glaube ich, besonders wenn man in den technischen Rängen aufwächst und plötzlich zumindest in dem Unternehmen, in dem ich zu der Zeit war, eine sehr fachkundige Kultur, wenn Sie die klügste Person im Raum waren, sind das die Leute, die sie sich angesehen haben und gesagt haben: „Okay, wir werden Sie zum Leiter befördern, oder wir werden Sie zum Manager befördern oder Sie in die Führungspositionen befördern.“ Ich denke, wenn ich darauf zurückblicke, denke ich, Ray 2.0 oder Ray 3.0, egal welche Version ich zu der Zeit hatte, dass ich sehr stark von dieser fachkundigen Führungsposition geleitet wurde, was irgendwie bedeutet, dass ich weiß, was der beste Weg ist, um etwas zu liefern, und jeder sollte meinem technischen Beispiel folgen, wie auch immer dieses Produkt zusammenkommt.
Und ich glaube nicht, dass das wirklich ein guter Ansatz war. Ich denke, das hat die Leute eingeschränkt, weil man den Leuten letztendlich mehr oder weniger einfach gesagt hat, was sie tun sollen, anstatt ihnen zu erlauben, zu experimentieren und zu lernen und sich weiterzuentwickeln, um zu dem zu werden, was ich als leitende technische Person geworden war. Ich denke also, die erste Lektion, die ich gelernt habe, war, dass die Führung eines Teams aus einer Expertenperspektive wahrscheinlich nicht der beste Ansatz ist, wenn Sie gehen... vor allem, wenn Sie an agile und andere integrativere Teamwork-Projekte denken, sollten Sie den Mitarbeitern einen eher katalytischen oder katalytischen Führungsstil geben, der auf Synergien basiert, damit sie sich selbst organisieren und als Ingenieur lernen und wachsen können.
Matthew Lawrence:
Gibt es Zeiten, die für Sie besonders auffallen und in denen Sie es furchtbar falsch verstanden haben? Ich weiß, dass ich ein paar Geschichten habe, die ich auch gerne teilen kann.
Ray Arell:
Ich würde gerne ein paar von deinen hören. Ich finde furchtbar falsch, ich denke, es ist... Die Frage ist, ist etwas jemals wirklich nicht reparierbar, nicht wiederherstellbar? Und in den meisten Fällen waren die meisten Probleme, mit denen wir uns befasst haben, behebbar. Ich denke, wenn ich mir das so ansehe und wieder in diese Haltung zurückkehre, stelle ich ein Team zusammen oder stelle ich nur eine Gruppe von Personen zusammen, die einfach ihre Arbeit vom Manager nehmen und sie wie Karten verteilen... Ich denke, zu Beginn war der große Fehler wahrscheinlich, einfach zu kontrollierend zu sein, und der Fehler dieser Kontrolle bedeutete, dass ich keinen Urlaub haben konnte. Andere waren voneinander abhängig, anstatt voneinander abhängig zu sein. Und ich denke, dadurch lief die Organisation langsamer und nicht so effizient, wie sie sein könnte.
Matthew Lawrence:
Ich habe mir sicherlich schon früher in meiner Führungskarriere denselben Ansatz schuldig gemacht, als ich zum Engpass wurde, absolut.
Ray Arell:
Ja. Genau.
Matthew Lawrence:
Und um das zu erkennen, kann es ziemlich schwierig sein, es rückgängig zu machen, aber es lohnt sich auf jeden Fall, daran festzuhalten. Noch etwas, bei dem ich das Glück hatte, eine Ausbildung in situationsbezogener Führung zu erhalten, oh, wahrscheinlich vor fast 10 Jahren. Und das hat mir wirklich die Augen für einen Ansatz geöffnet, die Art und Weise, wie ich verschiedene Leute in meinem Team behandelte. Aber ich habe sie so behandelt, wie ich sie zuerst beurteilt habe. Wenn ich also [unverständlich 00:07:01] einen Experten und einen Meister sehen würde, würde ich sie als Experten und Meister in allen Dingen behandeln. Und [unverständlich 00:07:05] Wenn jemand zu diesem Zeitpunkt seiner Karriere weniger fähig wäre, würde ich das Gleiche annehmen. Und so würde ich für alles das gleiche Maß an Orientierung oder Orientierungslosigkeit auf diese Leute anwenden. Und bei der situativen Führung ist die Prämisse für diejenigen, die es zu Hause nicht wissen, die Prämisse, die man vorgibt, je nach der jeweiligen Aufgabe, die man vorgibt. Haben Sie diesen oder einen ähnlichen Ansatz verwendet, um festzulegen, wie Sie Menschen auf unterschiedliche Weise einbeziehen?
Ray Arell:
Nun, um Menschen einzubeziehen, gehört es meiner Meinung nach dazu, dass du... Wie du schon sagtest, du hast jede Person situativ betrachtet und sie so strukturiert, dass sie von einer Art, einem Ansatz, von sehr individuellem Umgang mit jemandem geprägt war. Ich denke, die Philosophie, die ich... Nicht jeder ist sehr offen oder kann sehr gut über seine Fähigkeiten und Stärken kommunizieren, oder in bestimmten Fällen sind manche Menschen vielleicht gut in etwas, üben es aber nicht aus, weil sie selbst das Gefühl haben, dass das nicht zu ihren Stärken gehört, aber in Wirklichkeit ist es so. Ich denke also, wenn Sie aus einer situativen Führungsperspektive sagen, wenn Sie jemanden daran zweifeln hören, dass er derjenige sein könnte, der etwas tun oder, sagen wir, sogar die Führung von etwas übernehmen könnte, denke ich, dass ein Teil davon einfach in das gesamte Coaching und Mentoring einfließen und es wirklich einrichten und ihnen dabei helfen, erfolgreich zu sein.
Und aus einer inklusiven Perspektive denke ich, dass es ein gewisses Maß an Ehrlichkeit gibt, das man in seine Arbeit einbringen muss, und Demut, wenn es darum geht, bescheiden zu sein, auch wenn es um das geht, was man erreicht hat. Denn gerade im Ingenieurwesen tendiert man dazu, zu beobachten, dass, wenn man Leute in einen Raum bringt, die Leute, die neu sind, sich zurücklehnen und sich demjenigen hingeben, von dem sie glauben, dass er die mehr Erfahrung hat. Und die Realität ist, dass sie, sagen wir, sagen wir, sie kommen gerade von der Uni. Sie haben vielleicht mehr Fähigkeiten in einem bestimmten Bereich, basierend auf dem, was sie gerade in ihrem Lehrplan durchgemacht haben, als wir vielleicht nicht. Also die Frage, wie wir das gesamte organisatorische Gehirn nutzen, um alle Ideen auf den Tisch zu bringen, erfordert meiner Meinung nach manchmal, dass wir in der Lage sind, effektiv zuzuhören und manchmal einfach innezuhalten und den Leuten zu erlauben, das Wort zu haben und den Stift in die Hand zu nehmen und nicht den Raum zu besetzen, wenn das Sinn macht.
Matthew Lawrence:
Das tut es wirklich, und ich glaube, ich habe das in jedem Unternehmen gesehen, in dem ich bis zu einem gewissen Grad gearbeitet habe. Es würde mich wirklich interessieren, wie Sie mit diesem Szenario umgehen. Für die Leute, die zuhören und mit dieser Situation konfrontiert werden, ist es vielleicht das erste Mal, dass sie eine Führungsrolle übernehmen und dieses Szenario sehen und beobachten. Gibt es einen Rat, den Sie ihnen geben würden, um diese Dynamik zu ändern?
Ray Arell:
Nun, erstens, ich werde mir dessen gerade bewusst. Ich kritzele oft, wenn ich in einer Gruppe von Leuten bin, und ich setze mich hin und mache Punkte auf ein Papier, wo sich die Leute im Raum befinden, und dann fange ich an, Linien zwischen diesen einzelnen Punkten zu zeichnen, wenn ich sehe, dass die Kommunikation zwischen bestimmten Spielern stattfindet. Und was interessant ist, wenn man sich das über einen Zeitraum von etwa 15 Minuten anschaut, beginnt man, dieses Muster zu erkennen, dass vielleicht jemand das Gespräch dominiert oder dass er im Mittelpunkt der Konversation steht und es nicht im ganzen Raum herumgeht. Das ist der Zeitpunkt, an dem du zum Torwächter wirst und andere zur Konversation einlädst. Und dann hilfst du denjenigen, die das Gespräch dominieren, höflich, eine Pause einzulegen, einfach Raum zu geben und den anderen Leuten zu erlauben, zu reden und das herauszuholen.
Und dann denke ich an die Frage, ob das, was die Person sagt, manchmal mit dem Gespräch kohärent ist oder nicht, oder vielleicht versucht sie immer noch, etwas über die Dynamik von allem zu lernen. Man muss nur helfen, manchmal, das aus den Leuten herauszuholen, und offene Worte verwenden, um im Grunde einen Satz zu eröffnen... Ich meine, ein paar offene Fragen, um ihnen das zu beantworten. Und ich denke, das funktioniert wirklich gut.

Matthew Lawrence:
Ich liebe das. Ich kritzele auch. Ich bin Künstler in meiner frühen Karriere, und ich habe mich vor langer Zeit daran gearbeitet, Probleme mithilfe von Technik zu lösen, aber ich kann immer noch nicht... Ich brauche diese physische Zeichnung, um meinen Geist zum Denken zu bewegen, genauso wie alles andere [unhörbar 00:12:30] als nur auf einem Block zu kritzeln.
Ray Arell:
Das Gleiche hier.
Matthew Lawrence:
Etwas, das Sie vorhin gesagt haben, wir haben ein wenig über Inklusivität gesprochen. In Ihrer LinkedIn-Biografie sprechen Sie davon, eine integrative Führungskraft zu sein, die es liebt, andere zu inspirieren und zu motivieren, ihr volles Potenzial auszuschöpfen. Etwas, das mir wirklich am Herzen liegt, ist, dass vor allem der letzte Teil darin besteht, Menschen zu helfen, ihr volles Potenzial auszuschöpfen. Deshalb liebe ich es, ein Personalleiter und COO zu sein. Das können Sie in einem ganzen Unternehmen tun. Ich würde gerne zuerst auf die Idee eingehen, eine integrative Führungskraft zu sein. Wie definierst du, was es bedeutet, eine zu sein?
Ray Arell:
Nun, inklusive Führung, es gab eine alte Tasche, die ich früher hatte, eine kleine Coaching-Tasche, die ich immer mit mir herumtrug. Und ganz oben stand: „Bring es ins Team“, war das Motto, das ganz oben drauf stand. Und ganz unten auf der Tüte stand im Grunde: „Behandle Menschen wie Erwachsene.“ Waren die beiden Kernpunkte, von denen ich glaube, dass Inklusion darin besteht, dass ich akzeptieren muss, dass, ja, ich ein kluger Mensch bin, aber treffen wir eine bessere Entscheidung, wenn wir das im Team besprechen? Sehen wir, welche anderen Ideen oder Möglichkeiten wir uns vorstellen? Im engeren Sinne, treffen Sie die Entscheidung so spät wie möglich.
Es geht eher um die östliche Kultur, also, wenn ich die Entscheidung offen lasse, finden wir vielleicht etwas, das billiger oder besser oder auch einfach aufregender für unsere Kunden ist. Ich denke, ein Teil davon ist zu wissen, dass Sie nicht derjenige sein müssen, der die Entscheidung treffen muss. Sie können das Team die Entscheidung treffen lassen. Und wir alle umarmen uns, weil wir uns damit stärken. Das dachten wir alle, nicht nur das, was Ray dachte, was ich cool finde.
Matthew Lawrence:
Zu dem Artikel, über den Sie in Ihrer Biografie gesprochen haben, gibt es einen zweiten Teil, in dem es darum geht, andere zu motivieren, ihr volles Potenzial auszuschöpfen.
Ray Arell:
Ja, ja.
Matthew Lawrence:
Ja. Lassen Sie uns darüber sprechen, woher das für Sie kam, diese Leidenschaft, und wie Sie aufstrebenden Führungskräften helfen wollen, ihr volles Potenzial auszuschöpfen?
Ray Arell:
Ja, ich meine, ich hatte das Glück, als ich zur Intel Corporation kam, dass Andy Grove die Organisation zu der Zeit noch leitete. Tatsächlich hat er meinen Welcome to Intel-Kurs abgehalten. Zu der Zeit, als ich zu Intel kam, gab es nur etwa 32.000 Mitarbeiter. Und hier ist der CEO, Gründer des Unternehmens, der den Welcome to Intel-Kurs unterrichtet, den ich unglaublich cool fand, eine großartige Erfahrung. Er strahlt diese Führungsstärke aus, egal in welchem Mojo oder was auch immer es ist, er geht in die Umwelt, während er über das Unternehmen spricht. Aber er war wirklich stark im Einzelgespräch, der Zeit, die Sie mit Ihrem Manager oder anderen innerhalb der Organisation verbringen können, weil Sie mit jedem im Unternehmen ein Einzelgespräch führen können. Und das hat er gefördert. Und ich denke, das hilft... Wenn jemand versucht, es herauszufinden, ist er ganz neu im Unternehmen, und du bekommst eine ständige Einladung vom CEO, auf der steht: „Du kannst kommen und ein Gespräch mit mir führen“. Ich denke, das legt die kulturelle Norm von Anfang an fest, dass dies ein Ort ist, der mir bei meiner Karriere helfen und helfen wird.
Und ich könnte Ihnen sagen, dass es verschiedene Zeiten gab, in denen sich daraus ein ausgewachsener Satz entwickelte: „Ich bin der Mentee und sie sind die Mentoren.“ Und in diesen Beziehungen ist es im Laufe der Zeit so, als würdest du sagen: „Nun, das werde ich weiterzahlen.“ Heute habe ich mindestens sechs oder sieben Mentees, die alle möglichen Fragen dazu haben, wie sie sich durch ihre Karriere begleiten sollen oder ob sie einen bestimmten Bereich haben, auf den sie sich konzentrieren wollten. Und es ist an der Zeit, dass sie mir den Kopf zerbrechen. Und in bestimmten Fällen, wenn ich nicht die vollständige Antwort habe, kann ich sie zu anderen Mentoren weiterleiten, die ihnen helfen können, zu wachsen.
Matthew Lawrence:
Ich liebe diesen Ansatz der Weiterleitung, den Sie dort angesprochen haben. Es ist definitiv etwas, das ich in den letzten Jahren selbst versucht habe, und ich wünschte, ich hätte früher mit dem Mentoring angefangen. Ich hatte das Privileg, in meiner Karriere mit einigen großartigen Führungskräften zusammenzuarbeiten, von denen ich viel gelernt habe. Und als ich mit dem Mentoring angefangen habe, wurde mir klar, wie viel ich als Mentor gelernt habe, weil man nachdenken muss. Du denkst wirklich darüber nach, was diese Leute durchmachen, und projizierst dich nicht einfach auf sie. Und es bestätigt die Begründung, warum Sie Dinge selbst tun, warum Sie so denken. Und es zwingt mich, mich selbst herauszufordern.
Und ich denke, wenn es irgendwas gibt... Ich spreche mit einigen der jüngeren Leute bei der Arbeit, die aufstrebende Führungskräfte sind, und sie sind auf ihre Art außergewöhnlich. Sie haben alle sehr unterschiedliche Hintergründe, aber viele von ihnen haben nicht das Gefühl, bereit zu sein, Mentor zu sein. Das sind sie wirklich. Das sind tolle Leute. Und ich frage mich, haben Sie Leute zu Beginn ihrer Karriere gesehen, die versucht haben, es irgendwie früh weiterzugeben, oder haben die Leute das Gefühl, dass sie bis [unhörbar 00:18:22] warten müssen?
Ray Arell:
Ich denke, es kommt darauf an. Erstens, ich denke, das Bildungssystem, zumindest in den Vereinigten Staaten, hat sich ein wenig verändert. Wenn die Leute ihren Bachelor-Abschluss machen, waren sie früher einfach auf sich allein gestellt, sie haben ihr Buchstudium gemacht. Für diese Studie wurde nur sehr wenig Interaktion oder Teamwork entwickelt. Ich meine, als ich meinen Abschluss in Elektrotechnik gemacht habe, war das nur ich alleine. Es mag gelegentlich Laborarbeiten und Laborprojekte geben, aber das war nicht sehr inklusiv, und es gab auch keine Leute, die so früh Führungspositionen übernahmen. Ich sehe mir jetzt meine Tochter an, die gerade an die Universität geht, und alles ist eine Kohortengruppe. Es gibt Kohorten, die sich treffen. Durch das Studium, das sie machen, müssen sie alle in gewisser Hinsicht die Führung für einen Aspekt eines Projekts übernehmen, an dem sie gerade arbeiten. Ich denke, einige der neuen Leute, die in die Belegschaft kommen, haben quasi die Fähigkeiten, um, wenn sie eine Führungsrolle übernehmen müssen, ein kleines Programm oder ein Projekt durchführen müssen, dafür gerüstet zu sein. Zumindest habe ich das gesehen.
Matthew Lawrence:
Ich liebe dieses Konzept. Etwas, das ich beobachtet habe und darüber spreche ich auch viel mit unserem Führungsteam und unseren Mentor-Führungsteams für die [unhörbar 00:19:56]. Ein Großteil der Gespräche dreht sich um Teamdynamik, Teamvertrauen, Agilität innerhalb von Teams und darum, generell zu versuchen, Teams zu stärken, sie so aufzustellen, dass sie autonom sein können. Sie sind wirklich befähigt und man vertraut darauf, dass sie großartige Entscheidungen treffen und die Arbeit vorantreiben. Sie haben viel Erfahrung mit agilen und agilen [unhörbaren 00:20:21] agilen Führungskräften. Aufgrund Ihrer Erfahrung mit der Leitung agiler Teams, diesen Adoptionen und diesen Transformationen würde ich gerne verstehen, ob Sie einen Zusammenhang zwischen Agilität als Team und den Eigenschaften sehen, die eine integrative Führungskraft haben wird. Gibt es in Ihrem Kopf einen Zusammenhang zwischen dem, was es bedeutet, agil zu sein, und einer inklusiven Führungskraft?
Ray Arell:
Ich glaube schon. Denn wenn Sie schon früh daran denken, haben sie festgestellt, dass Servant Leadership ein besserer Führungsstil für agile Teams ist. Ich denke also, wenn wir über Transformation sprechen, sind einige der größten Fehler, die auftreten, eher darauf zurückzuführen, dass sie nicht agil sind, sondern auf Vertrauensfragen und anderen organisatorischen Hindernissen, die es dort bereits gab, bevor sie gestartet wurden. Und wenn sie diese nicht angehen, ist ihre agile Reise schmerzhaft.
Ich habe Leute sagen hören, dass sie schon einmal Scrummed bekommen haben und es auf eine wirklich abwertende Art nutzen und denken, dass, nun ja, anstatt ein Team von befähigten Leuten dazu zu bringen, innerhalb des Scrum-Frameworks zu arbeiten, sie am Ende unter die Linse des Mikromanagements gestellt werden, weil sich die Kultur des Managers nicht geändert hat und der Manager sie täglich nutzt, um sicherzustellen, dass alle zu 120% arbeiten, im Vergleich zu dem, was wir sehen sollten Das Muster ist, dass das Team seinen Flow versteht. Sie bringen Arbeit in das Team. Es wird nicht geschoben. Und ich denke, diese Dynamik ist etwas, dass, wenn sich die Führung nicht verändert und die Art und Weise, wie sie arbeitet, ändert, sie in Organisationen einfach nicht funktioniert.
Matthew Lawrence:
An den vielen Orten, an denen Sie gearbeitet, Menschen gecoacht und angeleitet haben, stoßen Sie langsam auf... Es gibt einen Begriff, den wir inzwischen für agile Muttersprachler verwenden. Dabei handelt es sich um Menschen, die es wirklich nicht anders gekannt haben, weil so viele Unternehmen auf der Welt agile Transformationen durchlaufen, und das wird noch lange so bleiben. Aber da manche Unternehmen mit Agilität an vorderster Front geboren wurden, haben Sie schon erlebt, dass viele Menschen in Führungspositionen aufsteigen, die nichts anderes wissen als echte Agilität und wirklich authentische Agilität, wie Sie es gerade beschrieben haben?
Ray Arell:
Nun, ich finde es irgendwie interessant, denn als du über diesen Satz gesprochen hast, habe ich darüber nachgedacht, naja, wenn du nichts anderes wüsstest... Aber ich kann auch sagen, dass du einheimisch werden könntest, wenn du auch eine Zeit lang in der Kultur warst. Also kannst du irgendwann... Das wird deine erste Reaktion, deine erste Angewohnheit ist es, mehr aus den agilen Prinzipien herauszuholen, als du aus etwas anderem ziehen würdest. Ja, es gibt diese Leute, aber es war interessant, Unternehmen wie Spotify oder Salesforce oder Pivotal zu beobachten, und ich kann einfach die Liste der Unternehmen durchgehen, die als agile Organisation angefangen haben, sie wurden groß, und dann tauchen plötzlich die Antimuster eines großen Unternehmens in diesen Unternehmen auf. Obwohl also die Leute innerhalb des kleineren Stammes agil arbeiten, fängt das Unternehmen langsam nicht mehr an, agil zu arbeiten. Es fällt in einen größeren Kontext dessen, was wir bei den älteren Unternehmen beobachten.
Und ich denke, ein Teil davon könnte an der Unternehmenskultur liegen, dass sie jemanden von außerhalb mitbringen, der kein Muttersprachler ist, und es fällt ihnen schwer, mit der Vorstellung umzugehen, dass wir irgendwann hier drüben einen Liefertermin festlegen und wir glauben, dass wir ihn einhalten werden. Aber nein, wir haben keinen Plan, den man liebevoll zu 90% mit Zuversicht bezeichnen würde, der besagt, dass wir alle Risiken aus dem Weg geräumt haben. Und ja, es wird auf jeden Fall an diesem Tag passieren. Und einige dieser Unternehmen werden wirklich... Sie haben das Gefühl, dass sie alles auf die Straße legen müssen, und wenn sie es nicht einhalten, haben sie das schon in ein Bonusprogramm für Führungskräfte gesteckt, was leider zu schlechtem Benehmen führt
Matthew Lawrence:
Ja, ich war dort. Ich gehe davon aus, dass wir in unserem Publikum Leute haben werden, die in höhere Führungspositionen wechseln. Sie sind keine aufstrebenden Führungskräfte, sie machen das schon eine Weile, und sie haben wahrscheinlich einige erfolgreiche agile Teams auf der kleineren Ebene geleitet, wie Sie es beschrieben haben. Gibt es für die Leute, die in höhere Rollen, vielleicht in Führungspositionen, aufsteigen, eine Anleitung, die Sie ihnen geben würden, wie sie diese Veränderungen bewältigen und versuchen, sie mithilfe agiler Prinzipien und der Bedeutung von Agilität in diesen höheren Rollen aufrechtzuerhalten?
Ray Arell:
Ja, ich denke, ein Teil davon ist die Arbeit, die Sie als kleineres Team geleistet haben, alles kann immer noch skaliert werden. Und ich hasse es, das Wort Skala zu benutzen, weil ich denke, Maßstab ist irgendwie... Die Leute benutzen es irgendwie... Was wäre das richtige Wort? Es wird in unserer Branche missbraucht. Ich denke, Werte und Prinzipien sind skalenfrei. Sie können immer noch jeden Tag in Ihr Team gehen und sich immer noch an diese 12 Prinzipien halten, und Sie werden gute Arbeit leisten. Die Frage ist jedoch, wenn Sie das auf der unteren Ebene tun, sagen wir mit einem Kanban-Board, ist die Frage, wie es aussieht, wenn Sie an Ihrem Chefschreibtisch sitzen? Was ist die Methode, bei der Sie Poolbillard spielen? Wenn Sie sich die meisten skalierten Frameworks ansehen, die heute auf dem Markt sind, gibt es nur sehr wenige Hinweise darauf, was im Alltag einer agilen Führungskraft sein sollte. Wie sollte das aussehen?
Und wenn ich an das Geschäftsteam denke, arbeitet das Managementteam täglich mit den Lieferteams zusammen. Das sollten sie tun. Also, was werden Sie tun, damit das möglich wird und stattfindet? Was werden Sie tun, um... diese großen jährlichen Budgetprozesse einzustellen? Machen Sie sich Dinge wie die Budgetierung oder andere Dinge zu eigen, bei denen Sie die Organisation strategisch finanzieren und nicht versuchen, alles auf einen jährlichen Rhythmus festzulegen, aber Ihre untergeordnete Organisation arbeitet trotzdem alle zwei Wochen. Sie sollten also in der Lage sein, Ihre Wetten bei jeder Organisation auf der Grundlage der Leistung jedes Sprints erneut zu verschieben. Kannst du das machen?
Das letzte ist wahrscheinlich das wichtigste, sind Hindernisse. Und so schnell braucht es Informationen, um vom untersten Teil der Organisation zum höchsten Punkt der Organisation zu gelangen? Und wenn das bei bestimmten Organisationen drei Wochen, zwei Wochen oder manchmal sogar später dauert, optimieren Sie das. Wie optimiert man ein Hindernis, bei dessen Beseitigung Sie persönlich helfen können, für die Mitarbeiter, damit sie nicht länger gebremst werden, was auch immer das sein mag?
Matthew Lawrence:
Du berührst da etwas, was meiner Meinung nach ein grundlegender Bestandteil von Agilität ist, nämlich diese Fähigkeit zu lernen und sich anzupassen, und du kannst nur lernen, wenn du dir bewusst bist, was um dich herum passiert, du kannst es beobachten [unhörbar 00:28:39].
Ray Arell:
Nun, ich habe vor ein paar Monaten etwas gesagt und alle sagten einfach: „Warum hast du gesagt... Ich kann nicht glauben, dass du das laut gesagt hast.“ Manchmal ist es das leise Zeug, das laut ausgesprochen wird. [unhörbar 00:28:53]. Wir haben versucht, ein Treffen zu vereinbaren, um eines dieser Hindernisse zu beheben, und alle hochrangigen Führungskräfte waren beschäftigt. Sie waren beschäftigt. Und meine Frage war, wenn das momentan nicht das Wichtigste für uns ist, was machst du dann? Wirklich, tust du das in deinem Alltag, wenn das nicht die höchste Priorität ist, die du eingehst? Und die Befragung hochrangiger Führungskräfte, dass sie vielleicht nicht auf die richtigen Dinge achten, und manchmal den Machthabern diese Wahrheit zu sagen, ist etwas, das wir ab und zu tun müssen.
Matthew Lawrence:
Ich stimme zu. Dieses Maß an Offenheit ist definitiv auf allen Ebenen erforderlich und die Fähigkeit, dieses Feedback zu erhalten, damit Sie als Einzelperson lernen und sich anpassen können, wie wir bereits zuvor besprochen haben, darüber, wie Sie als Führungskraft, aber auch als Team anpassungsfähig sind. Es gibt einen Punkt, auf den ich noch eingehen möchte, bevor wir zum Abschluss kommen, nämlich wenn man die Karriereleiter hochklettert und in eine höhere Position kommt und dann für ein breiteres Spektrum von Dingen verantwortlich ist, vor allem, wenn man die Führungsebene erreicht, habe ich erlebt, wie Menschen mit dem Übergang von der Person, von der Sie gleich zu Beginn dieser Diskussion gesprochen haben, zu der Person, die alles weiß und die Regie führen kann und alle Antworten hat in jemanden, bei dem ich sehe, dass sich Ihr Job zu der Person entwickelt, die identifizieren kann, was wir wissen am wenigsten darüber, was wir als Führungsteam am wenigsten wissen, wo wir sind... haben am wenigsten Selbstvertrauen, wo wir die Hindernisse sehen und nicht wissen, was wir mit ihnen anfangen sollen.
Wie gehst du vor, um die Leute dazu zu bringen, das anzunehmen? Weil ich denke, was ich sehe, ist die Angst, die damit einhergeht, fast eine Angst davor, zu sagen: „Oh, ich gebe es Leuten gegenüber zu, dass ich nicht weiß, was ich tue.“ Und ich wurde während meiner gesamten Karriere dafür belohnt, dass ich immer mehr zum Experten wurde, und plötzlich ist es meine Aufgabe, die Person zu sein, die selbstbewusst genug ist, um auszurufen: Das ist es, was wir noch nicht verstehen. Lassen Sie uns zusammenkommen und versuchen, das Problem zu lösen. Wenn das Risiko größer ist, die Auswirkungen größer sind und Sie für mehr Dinge verantwortlich sind, wie helfen Sie Menschen beim Übergang in diese übergeordnete Rolle?
Ray Arell:
Nun, ich denke, ein Teil davon ist, dass sie diese technische Seite loslassen können, wenn sie sich ständig die Hände schmutzig machen müssen? Und ich habe bestimmte Führungskräfte gesehen, bei denen wirklich jemand zurückgehen und sagen muss: „Bist du dir wirklich sicher, dass das die Karriere ist, die du anstreben willst? Sie scheinen mehr darauf aus zu sein, sich mit den Einzelheiten befassen zu wollen, und vielleicht ist das der beste Ort für Sie, weil Sie sich in diesem Bereich wohler fühlen.“ Der andere Aspekt ist jedoch, glaube ich, wieder, dass Vertrauen entscheidend wird, wenn sie sich verändern. Vertraue den Leuten, die für dich arbeiten, dass sie nicht reinkommen und faul sind und du ihnen die ganze Zeit über die Schulter schauen musst, weil du das Gefühl hast, dass sie vielleicht nicht produktiv sind oder andere Dinge. Sie müssen sagen können, dass die Leute, die Sie eingestellt haben, talentiert sind und dass sie uns unseren Zielen näher bringen.
Ich denke, was für die Gesundheit des Unternehmens immer wichtiger wird, ist, dass man viel besser darin sein muss, tatsächlich zu sagen: „Okay, nun, hier ist unsere Vision“, sei es eine Produktvision, ob es die Vision des Unternehmens ist, was auch immer das sein mag, den Menschen zu helfen, zu verstehen, was dieser North Star ist, und das dann nicht aus Ihrer Sicht, sondern aus der Sicht des Kunden zu bekräftigen. Und ich denke, hier fangen viele Unternehmen an zu driften, weil sie anfangen, einige interne Kennzahlen zu optimieren, die, ja, die Effizienz in Ihrem Unternehmen steigern werden. Aber was denkt der Kunde? Und ständig in der Lage zu sein, sich, aus einer agilen Perspektive, als der Chief Product Owner des Unternehmens darzustellen, um das repräsentieren zu können, was die Kunden brauchen und wollen, und in der Lage zu sein, dies in der Vision und den ehrgeizigen Missionen, die für das Unternehmen aufgestellt werden, zum Ausdruck zu bringen. Machen Sie es für die Menschen real.
Und dann ist der letzte Teil davon, dass nicht alles passieren und wahr werden wird. Wenn Sie die Biografien der meisten Führungskräfte lesen, gibt es viele, viele, viele Fehler. Und ich erinnere mich an das von einem Anführer, er ging in den Ruhestand. Und ich dachte, es war nicht gerade peinlich, dass er das tatsächlich getan hat. Er ging tatsächlich auf die Bühne und sprach über seinen größten Misserfolg. Während meiner gesamten Karriere bei der Arbeit mit dieser Person habe ich mich immer gefragt, ob sie ein Mensch ist oder nicht. Und dann, am Tag des Ausscheidens dieser Person, beschlossen sie schließlich, Ihnen ein paar Geschichten über Fehler zu erzählen, die sie gemacht hat. Und ich denke, er musste diese Geschichten wirklich viel, viel früher teilen, weil ich denke, die Leute hätten wahrscheinlich herausgefunden... Sie wären etwas gestresst gewesen, um ihn herum zu arbeiten. Und es würde auch eine gewisse Verwundbarkeit für Sie als Führungskraft bedeuten, zu sagen, dass Sie nicht alles herausgefunden haben, und manchmal ist es nur eine Vermutung. Wir sind der Meinung, dass das Produkt genau dort eingesetzt werden muss.
Und sobald du es den Kunden vorstellst, werden sie dir sagen, ob... Wenn du das Cano-Modell nimmst und plötzlich triffst, das ist die aufregendste Sache seit dem Rad, werden sie es lieben oder werden sie gehen, [unhörbar 00:35:12]. Ich nehme es, wenn es kostenlos ist. Du gerätst in eine Situation, in der es ist, naja, wir können nicht so viel verlangen. Aber ich denke, diese Geschichten werden wichtig und verankern Organisationen. Ein weiterer Aspekt ist meiner Meinung nach, dass, wenn man jemanden hat, der ansprechbar ist und diese Geschichten effektiv in die Organisation weiterleiten und über diese Dinge sprechen kann, das meiner Meinung nach allen anderen die Tür öffnet, dies auch zu tun. Denn ob es Ihnen gefällt oder nicht, Menschen sind hierarchisch in der Art und Weise, wie wir über Dinge denken. Viele Leute schaffen es, also ahmen sie Führungskräfte nach. Seien Sie also der Anführer, den jemand nachahmen möchte.
Matthew Lawrence:
Ich finde, das ist ein toller Rat, Ray. Die Verbindung, die sich für mich durch dieses ganze Gespräch zieht, ist, sich authentisch mit Ihrer Arbeit auseinanderzusetzen, ob es das Team ist, das Sie zu leiten versuchen, ob es die agilen Praktiken sind, egal auf welcher Ebene und auf welcher Ebene Sie arbeiten. Und um dieses Vertrauen aufzubauen, damit das funktioniert, ist ein gewisses Maß an Authentizität erforderlich.
Ray Arell:
Ja, genau.
Matthew Lawrence:
Ich würde mich freuen, wenn Sie zum Abschluss noch letzte Tipps oder Ratschläge für aktuelle und aufstrebende Führungskräfte zu diesem Thema hinterlassen würden. Wenn es einen Weg gibt, der über das bloße Teilen Ihrer eigenen persönlichen Geschichten hinausgeht, wie würden Sie Menschen beraten? Was würdest du ihnen geben, um Vertrauen in ihre Teams aufzubauen?
Ray Arell:
Nun, ein paar Dinge. Erstens, du musst darauf achten, wer du als Person bist. Nochmals, wie ich schon sagte, dass die Leute es schaffen. Und wenn Sie um drei Uhr morgens eine E-Mail verschicken und fünf Minuten später Ihre Mitarbeiter Ihnen geantwortet haben, dann sind Sie kein wirklich gutes Vorbild für eine gute Work-Life-Balance. Viele Ihrer Tendenzen werden sich also auf das Unternehmen auswirken. Machen Sie also unabhängig davon, wie Sie sich selbst einschätzen, eine Bewertung Ihrer Führung, wo sie Ihrer Meinung nach stattfindet. Harvard Business Review hat vor langer Zeit das Niveau dessen, was sie als Führungsmodelle betrachteten, nach hinten verschoben. Und auf der untersten Ebene befinden sich Führungskräfte, die auf Experten und Leistungsträgern basieren. Und wenn Sie zu diesen gehören, sind diese für eine gute agile oder kollaborative Kultur nicht sehr förderlich. Wenn Sie sich also gerade in diese Richtung bewegen, sollten Sie nach Wegen suchen, wie Sie sich eher zu einer Führungskraft entwickeln können, die auf Katalysatoren oder Synergien basiert.
Und diese Reise ist nicht einfach, weil ich sie selbst durchgemacht habe. Es hat Jahre gedauert, bis Sie sich von einigen dieser Tendenzen, die Sie als fachkundige Führungskraft hatten, gelöst haben. Und ein Beispiel: Eine Führungskraft, die von Experten geleitet wird, neigt dazu, nur mit anderen Experten zu sprechen. Wenn sie jemanden als keinen Experten für etwas wahrnehmen, neigen sie dazu, diese Personen zu ignorieren und nicht mit ihnen in Kontakt zu treten. Und wieder ist es das gesamte organisatorische Gehirn, das das Problem lösen wird. Wie binden Sie also die gesamte Organisation ein und bringen diese Ideen zusammen?
Die andere ist, dass Sie, wenn Sie darauf eingehen, aus der Perspektive einer aufstrebenden Führungskraft, es vorhin selbst gesagt haben, und das ist nicht nur die Voreingenommenheit, weil Sie kein Experte sind, ich werde nicht mit Ihnen sprechen, sondern jede Voreingenommenheit, die Sie möglicherweise haben, kann die Art und Weise beeinflussen, wie Sie eine Person führen und beurteilen, und könnte ihre Karriere wirklich einschränken oder ausbauen, vielleicht aufgrund eines schnellen Urteils, das Sie vielleicht gehabt haben. Ich denke, Sie müssen sich Ihrer Entscheidungen bewusst sein, die Sie innerhalb der Organisation treffen, und insbesondere der Entscheidungen, die Sie über Menschen treffen. Und mit denen musst du vorsichtig sein.
Der letzte ist wahrscheinlich nur... Und das geht in den Bereich der komplexen adaptiven Systeme. Nicht alles ist zugeschnitten und trocken, schwarz und weiß oder mechanisch, was bedeutet, dass wir dasselbe Produkt nehmen und es immer wieder und wieder wiederholen können, und wir werden unterschiedliche Antworten bekommen. Wir werden unterschiedliche Anforderungen haben. Wir werden verschiedene Dinge bekommen. Es ist okay, dass das Zeug da ist. Und es ist okay, dass die Dinge, die aus unseren Produkten kommen, ab und zu anders sind, und vor allem, weil alles eine sehr komplexe Umgebung ist. Ursache-Wirkungs-Beziehungen und Komplexität sind, dass der Kunde seine Meinung ändern kann, und wir müssen uns damit wohlfühlen, wenn ein Kunde seine Meinung ändert. Unser Kunde hat möglicherweise neue Bedürfnisse, die auftauchen.
Und auch unsere Mitarbeiter ändern manchmal ihre Meinung oder ändern das, worauf sie sich freuen. Wie fördern Sie das? Wie fördert man diese Mitarbeiter, um sie im Unternehmen zu halten, nicht um sie für die Fähigkeiten einzusetzen, über die sie gerade verfügen, sondern wie geht man da langfristig vor? Und ich weiß, dass ich hier etwas langatmig werde, aber das, was ich am meisten sehe, trotz all der Entlassungsbescheide, die gerade vor sich gehen, ist, dass dieses Unternehmen nicht auf lange Sicht spielt. Ich denke, das ist ein schlechter Schachzug, denn alles, was Sie tun, indem Sie einen Mitarbeiter entlassen, ist, Ihrem Konkurrenten eine ganze Reihe von Wissen zu vermitteln, das Sie behalten sollten. Also wie dem auch sei, ich werde es da kurz machen.
Matthew Lawrence:
Richtig. Danke, dass du heute deine Weisheit mit uns geteilt hast. Es war mir ein absolutes Vergnügen. Ich habe den Chat wirklich genossen. Also ja, danke, dass Sie sich mir im Easy Agile Podcast angeschlossen haben.
Ray Arell:
Fantastisch. Danke, dass du mich eingeladen hast.
Hör jetzt zu

Easy Agile Podcast Ep.30 Ausgerichtet und erfolgreich: Die Macht der Teamausrichtung

Transkript:

Verwandte Episoden

Easy Agile Podcast Ep.21 LIVE von Agile2022!

Transkript

Easy Agile Podcast Ep.12 Beobachtungen zur Beobachtbarkeit

Transkript

Easy Agile Podcast Folge 27 Inklusive Führung

Transkript: