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

„Von Bier-Analogien über Gedränge in Restaurants bis hin zu neurodiversen Teams — es ist immer ein Vergnügen, mit Kit zu chatten.“

Kit befasst sich mit agilen Methoden, die über den üblichen Anwendungsfall hinausgehen, z. B. die Zusammenarbeit mit Geologen und Restaurantbesitzern bei der Anwendung von Scrum.

Das Kit unterstreicht auch die Notwendigkeit, sich auf einen Bottom-up-Ansatz zu konzentrieren, der Führungskräften einen sicheren Raum bietet, in dem sie lernen und Fragen stellen können, und zeigt, ob neurodiverse Teams der Schlüssel zur Effektivität sind.

Das war ein wirklich interessantes Gespräch!

Abonniere unbedingt, genieße die Folge 🎧

Transkript

Nick Muldoon:

Guten Tag Leute. Mein Name ist Nick Muldoon. Ich bin Mitbegründer und Co-CEO von Easy Agile und freue mich, heute Kit Friend von Accenture zu begrüßen. Kit ist Agile-Coach bei Accenture und dort auch der Atlassian-Praxisleiter. Kit, guten Morgen.

Bausatzfreund:

Guten Morgen, Nick. Leider nur der Übungsleiter für ein paar Dinge, aber ich gebe mein Bestes. Es ist mir eine Freude, mit Ihnen zusammen zu sein, zum zweiten Mal, dass wir es diese Woche auch versucht haben, in der schönen Welt der Breitband-abhängigen Telearbeit und so weiter. Aber es gibt Hoffnung, oder?

Nick Muldoon:

Es ist wunderschön, nicht wahr? Für diejenigen unter Ihnen, die zu Hause zuhören, nur damit Sie ein bisschen Kontext haben, Kit ist Vater von zwei Kindern, er lebt in London und ist jetzt seit etwas mehr als 10 Jahren bei Accenture, richtig?

Bausatzfreund:

Ja, September 2010. Zum Glück habe ich meine Frau fast im selben Sommer getroffen, also muss ich mich nur an ein Jahr erinnern, und ich kann mich an eines nach dem anderen erinnern. Es hilft also, wenn ich versuche, mich an Termine zu erinnern und Dinge zu ordnen, weil ich nicht sehr gut mit meinem Gedächtnis umgehen kann, um ehrlich zu dir zu sein.

Nick Muldoon:

Oh nun ja. Also, der Grund, warum ich Sie heute eingeladen habe, ich freue mich riesig, von der Reise zu hören, auf der Sie bei Accenture waren, und ich schätze, von der Reise, auf der Sie mit Ihren Kunden sind, und von diesen verschiedenen Engagements. Bevor wir jedoch darauf eingehen, wollte ich wissen, kannst du mir einfach sagen, was eine deiner Lieblingsbands aus den 90ern, aus den frühen 90ern ist?

Bausatzfreund:

Ja, und ich finde es wirklich toll, dass wir eine Verzögerung zwischen den Dingen hatten, weil es wie eine dieser Fragen ist, weil ich sage: „Hmm“. Und ich glaube, ich bin ein Opfer der Playlist-Kultur, in der es so ist, als würde sich die Benennung einer ganzen Band wie eine echte Verpflichtung anfühlen. Es geht jetzt nur noch um Tracks mit Dingen, oder? Aber ich habe es auf zwei für meine Lieblingsband aus den 90ern eingegrenzt und ich denke, ich werde mich danach festlegen. Also mein unbestrittener Lieblingstrack der 90er, Common People von Pulp, oder? Zweifellos, ja, es ist genau da oben. Für mich habe ich an der St Martins, der Kunsthochschule, studiert, also ist Common People für mich der Karaoke-Track meiner Studienzeit mit Dingen dort. Also Common People von Pulp, Lieblingssong.

Bausatzfreund:

Was die Bands angeht, war ich allerdings aufgeteilt zwischen... Anfangs ging ich zu Britpop und dachte: „Cool, das fühlt sich für mich wie ein glücklicher Ort an.“ Gerade im Moment in unserer seltsamen dystopischen Gesellschaft höre ich Britpop und es ist irgendwie glücklich. Blur war also für mich damals ganz oben, was Band-Commit aus den 90ern anging. Aber dann fiel mir ein, dass Placebo eigentlich eine 90er-Jahre-Band ist, obwohl ich sie mir als 13 Jahre altes Kit und so nicht angehört habe. Also ich denke, Placebo hat es für mich in Bezug auf meine Lieblingsband der 90er fast übertroffen. Aber ich muss zugeben, obwohl es nicht mein Lieblingstrack aus den 90ern ist, denke ich, dass Wonderwall vielleicht der beste Song ist, der jemals geschrieben wurde.

Nick Muldoon:

Eine Oase? Liebe es.

Bausatzfreund:

Ja, für Track Wise. Aber besonders für mich war ich vor ein paar Jahren mit einigen Kollegen auf dem Oktoberfest und ich glaube nicht, dass ein anderer Track 600 betrunkene Deutsche zusammen mit allen anderen auf die Bänke bringen könnte, von überall auf der Welt, mit einer Rock-Polka-Band, die um 11 Uhr nachts aus voller Kehle singt oder so. Also ja, dieses Sammelsurium, aber ich werde Placebo als Lieblingsband in diesem seltsamen Vorbehaltssatz festlegen.

Nick Muldoon:

Ich liebe es, danke dafür, Kit. Das ist interessant, weil du damals erwähnt hast, dass du nach St. Martins gegangen bist, was eine Kunsthochschule war. Also würde mich interessieren, was hast du studiert? Was sind Ihre formalen Qualifikationen und was hat Sie dann in diese Welt der agilen Umsetzung und kontinuierlichen Verbesserung geführt?

Bausatzfreund:

Ja. Ich meine, ich mache den Twitter-Bio-Vorbehalt, dass alle Meinungen meine eigenen sind und nicht die von Accenture, bevor wir uns auf die Reise der Dinge begeben. Obwohl gesagt werden muss, dass ich versuche, so viele meiner Kollegen und Kunden wie möglich von meiner Denkweise zu überzeugen. Aber ich habe St. Martin studiert oder am St Martins College studiert, also in Großbritannien weiß ich sicherlich nicht, wie es in Australien ist, aber wenn man Kunst und Design studiert, misstrauen sie im Grunde Ihrer Highschool-Ausbildung. Sie sagen: „Nein, alles, was du vorher gemacht hast, ist...“

Bausatzfreund:

Also lassen sie dich nehmen, was genannt wird, oder sie raten dir, ein sogenanntes Gründungsjahr zu nehmen, in dem du eine Menge Dinge ausprobierst. Also kommst du rein und denkst, du wirst Maler oder Produktdesigner oder so, und sie sagen: „Nein, nein, nein. Du hast noch nicht die ganze Bandbreite der kreativen Branchen und so erlebt.“ Also habe ich eines davon gemacht, was unglaublich war, und ich dachte, ich würde Produktdesigner werden. Am Ende spezialisierte ich mich auf Schmuck und Silberschmiedekunst und so, also habe ich gemacht wie... Ja, ich habe lange schwarze Trenchcoats und so getragen, ich habe gotische, stachelige Rüstungen und alle möglichen Dinge hergestellt und [unhörbar 00:04:24] mit Silber gearbeitet. Aus diesem Jahr habe ich einen Professional Development Award im Bereich Schweißen erhalten, das war also meine erste formelle Qualifikation in diesem Bereich. Ich bin allerdings ein wirklich schlechter Schweißer.

Bausatzfreund:

Am Ende dachte ich dann: „Ich weiß immer noch nicht wirklich, was ich tun möchte.“ So wie du es auf der Universität tust, lautet mein offizieller Titel, was meinen Trend zu sehr langen, unaussprechlichen Dingen noch verstärkt, Ba Hons Art And Design And The Environment, Artifact Pathway, und was es war, war... Dein Gesicht ist...

Nick Muldoon:

Ja, ich versuche das zu verarbeiten.

Bausatzfreund:

Ja. Ich glaube, der Kurs existierte nur drei Jahre, er fühlte sich wie ein kleines Experiment an, oder er existierte nur in diesem Format. Wir hatten also Architekturstudenten, die den ersten Teil ihrer Architekturqualifikation absolvierten, wir hatten sogenannte Raumplanungsstudenten, die, glaube ich, Räume entwarfen. Sie waren keine Innenarchitekten, sie waren ein bisschen mehr Ingenieur und dann hatten wir diesen seltsamen Studiengang namens Artifact, der der Rest von uns war und wir waren nicht ganz so streng wie Produktdesigner, wir waren keine Künstler. Wir haben Objekte und Erlebnisse und Dinge gemacht.

Bausatzfreund:

Ja, es war eine wirklich interessante Erfahrung. Ich meine, gegen Ende habe ich angefangen, mich mehr und mehr darauf zu spezialisieren, wie Gemeinschaften kommen und Dinge bauen und Dinge zusammen machen können, und es ist ein bisschen komisch, wenn man auf Dinge zurückblickt. Du sagst: „Ich kann den Weg der Dinge, die ich seitdem getan habe, direkt auf diese Art von Tendenz [Crosstalk 00:05:54] zurückverfolgen, wie ich es mag, Menschen zusammenzubringen.“

Nick Muldoon:

Also ja, glaubst du, dass der Community-Building-Aspekt eine Art Genese für das war, was du versucht hast, die Community rund um die Agile-Transformation, die du in den letzten zehn Jahren entwickelt hast, oder?

Bausatzfreund:

Ich weiß nicht. Es ist leicht, auf diese Dinge zurückzuverfolgen, nicht wahr? Aber ich glaube, ich war schon immer...

Nick Muldoon:

Du siehst es zu dem Zeitpunkt nicht.

Bausatzfreund:

... mochte es, Menschen zusammenzubringen, um Dinge zu tun. Nein. Es ist sowieso eine Theorie, oder? Eine Theorie der Entstehungsgeschichte, die wir gerade haben. Also habe ich das gemacht und dann habe ich mich viel über meinen Kurs beschwert. Ich dachte: „Das ist Quatsch. Das ist alles wirklich zufällig und so.“ Also wurde ich zum Mitglied der Studentenschaft gewählt, also weiß ich nicht, wie das in Australien funktioniert, aber im Vereinigten Königreich kann man effektiv als Vollzeit-Studentenpolitiker gewählt werden, und das kann man machen... Sie nehmen ein Sabbatical entweder während Ihres Kurses oder am Ende Ihres Kurses, wo es nicht wirklich ein Sabbatjahr ist. Also war ich beim Studentenwerk und habe nach Abschluss meines Studiums zwei Jahre lang Vollzeit gearbeitet, was eine skurrile, aber lehrreiche Erfahrung ist.

Bausatzfreund:

Auch hier geht es darum, Leute zu organisieren, zum Beispiel bei der Lösung von Problemen zu helfen und sehr flink mit... Du weißt nicht, was nächste Woche passiert, du wirst gegen unfaire Bezahlung protestieren oder du wirst jemanden haben, der seinen Abschluss aufgrund seiner persönlichen Umstände und Dinge in Schwierigkeiten gebracht hat, also ist es eine wirklich interessante Mischung. Also ja, da habe ich meine Reise in die Dinge begonnen.

Nick Muldoon:

Es ist also interessant für mich, weil Sie darüber sprechen, der erste Teil davon ist: „Wir vertrauen nichts, was Sie zuvor gelernt haben, und wir werden Ihnen ein bisschen wie ein Sammelsurium und einen Vorgeschmack auf viele verschiedene Aspekte geben.“ In welcher Beziehung steht das zu einer agilen Transformation? Denn ich habe das Gefühl, wir haben ein Jahrzehnt hinter uns, in dem eine agile Transformation buchstäblich so aussah: „Hier ist Scrum, mach zwei Wochen Scrum, Schätzungen zum Storypoint, kein Rollover. Wenn Sie den Rollover umdrehen, schlagen wir Ihnen auf die Handgelenke.“

Nick Muldoon:

Dort wurde wahrscheinlich vor 10 Jahren nicht viel mit verschiedenen Ansätzen zur Verabreichung experimentiert. Es war nur: „Wir gehen von diesem Wasserfall-Ansatz zu diesem agilen Ansatz über.“ Was damals sehr häufig Scrum war. Warum geben wir den Leuten nicht das Sammelsurium und warum geben wir ihnen nicht dreimonatige Rotationen, in denen sie ein bisschen Scrum und ein bisschen Kanban und verschiedene Herangehensweisen ausprobieren können?

Bausatzfreund:

Nun, ich denke, es ist praktisch, nicht wahr? Diese Dinge. Es ist eine Herausforderung, und es ist eine Herausforderung, es funktioniert in einem geschlossenen Raum. Ich unterrichte viele unserer Produktverpackungskurse für unsere Kunden und wir verwenden immer das David Marquet-Video von Greatness Summary. Was ist toll an der Situation mit David Marquet, er hat diese Petrischale, oder? Buchstäblich ein U-Boot, niemand stört seine U-Boot-Crew. Also kann er das tun, er kann sagen: „Nun, lass uns das Ding ausprobieren.“ Ich vereinfache es stark, weil es eine tolle Geschichte ist, oder?

Bausatzfreund:

Aber man hat diesen Raum, um etwas zu tun und etwas auszuprobieren, und wenn wir mit Kunden und Kollegen gleichermaßen über agile Transformationen sprechen, denke ich, eines der Dinge, die ich immer wieder in Bezug auf die Rolle der Führung sage, ist, dass sie einen sicheren Raum schaffen müssen, einen kleinen Ort, an dem sie schützen, und sie sagen: „In diesem Bereich machen wir Agile, wir können experimentieren, wir können diese Dinge tun. Lasst meine Leute in Ruhe. Vertrau mir darin.“

Bausatzfreund:

Ich denke, dass Agile meiner Meinung nach gut läuft, dort gibt es einen Teil dieses geschützten Raums, in dem Dinge erledigt werden können. Ich habe Kollegen, die in Unternehmen arbeiten, in denen sie tätig sind, und sagen: „Okay, wir werden es jetzt versuchen und Sie nur bitten, den Umfang Ihrer Geschichten für die nächste Woche vorherzusagen. Alles andere liegt bei Ihnen, Sie können wählen, ob Sie Scrum anwenden möchten, Sie können Crystal, DSDM, was auch immer es ist, verwenden. Alles, was Sie für uns als Unternehmen tun müssen, ist uns einen umfassenden Überblick über diese Kennzahlen zu geben oder so.“ Es gibt also Flexibilität. Ich denke, wenn ich an deine Reise als Agilist denke und an den Versuch, Dinge zu tun, sagen die Leute, versuche von allem ein bisschen, das ist ein netter Rat, aber es ist ein bisschen schwierig, es tatsächlich zu tun, weil es so ist, als ob wir immer noch Dinge machen müssen, wir müssen immer noch Dinge praktisch machen.

Bausatzfreund:

Wenn ich also mit Leuten spreche, die am Anfang ihrer Reise stehen, oder sowohl mit Kunden als auch mit Kollegen, die solche Dinge durchstehen wollen, zum Beispiel, was sie zuerst tun, sage ich immer noch, dass Scrum ein wirklich guter Anfang ist, weil ich denke, da ist dieses Zitat von irgendwo, es steht wahrscheinlich im Scrum Guide, über: „Es ist einfach zu verstehen, aber komplex, es richtig zu machen.“ Und Sie würden bei komplexen und chaotischen Situationen denken, oder? Aber ich denke, dass...

Nick Muldoon:

Und die erforderliche Disziplin ist...

Bausatzfreund:

Ja, ja. Aber Disziplin ist eine gute Sache, oder?

Nick Muldoon:

Mm-hmm (bejahend). Aber nicht jeder hat es.

Bausatzfreund:

Nein. Aber einer meiner Kollegen, Nick Wheeler, benutzt den Satz: „Zu viele Sitzsäcke, nicht genug Arbeit getan, um über Chaotic Agile zu sprechen.“ Ich denke, man muss sich darauf konzentrieren, Dinge zu erledigen, oder? Ein gutes Preis-Leistungs-Verhältnis muss vorhanden sein, ebenso wie eine angenehme Arbeitsatmosphäre und Ausgewogenheit. Es ist also ungefähr irgendwo dazwischen, und ich mag Scrum, weil es den Leuten auch etwas gibt... Es ist ein Framework, oder? Es gibt den Leuten etwas, an dem sie sich aufhalten können, um ihre Reise zu beginnen. Ich habe das Gefühl, dass Sie Monate damit verbringen könnten, darüber zu diskutieren, ob Sie einen Agile-Master haben und was er macht? Wo gehen wir hin? Haben wir eine Person, die die Vision und die Dinge in sich trägt?

Bausatzfreund:

Ich denke, wenn Leute anfangen, sage ich immer: „Warum nicht Scrum ausprobieren? Warum nicht sehen? Probiere es ein paar Sprints lang aus und schau, was für dich funktioniert, und dann schau, was in der Wäsche herauskommt.“ Ich meine, wenn sie in einem Bereich sind, in dem es einige grundlegende Widersprüche gibt, wie zum Beispiel: „Ja, ich werde einem Call Center keine Sprints aufzwingen, oder? Das ergibt keinen Sinn.“ Ich habe gestern mit jemandem gesprochen, der in einem Betrugsteam arbeitet, und es ist, als würde ich sie nicht fragen, wie viele Betrugsfälle in zwei Wochen oder als Teil von MPI begangen werden, oder? Es ist absurd.

Bausatzfreund:

Unter diesen Umständen, ja, beginnen Sie stattdessen mit Kanban-Methoden, -Prozessen und -Praktiken. Aber für Leute, die Produkte und Dinge bauen, finde ich, dass Scrum am Anfang ziemlich gut passt. Also ja, das ist meine Antwort, also beides. Warum nicht beides haben, ist die Antwort darauf, glaube ich, auf dem Weg. Ja. Es wäre interessant zu sehen, welche anderen Frameworks ihnen in den Sinn kommen. Ich meine, ich habe neulich ein skaliertes Agile-Framework namens Camelot gefunden, das viele Burgen und Dinge im YouTube-Video beinhaltete. Ich fand das wunderbar. Aber es gibt Raum für viel Planung und Nachdenken.

Nick Muldoon:

Sobald du Camelot gesehen hast, denke ich aus irgendeinem Grund an Monty Python. Ich weiß nicht genau warum. Aber wie heißt diese Variante von Scaled Agile Camelot? Kannst du mir davon erzählen? Weil ich damit nicht vertraut bin.

Bausatzfreund:

Ich habe ein YouTube-Video dazu gesehen, Nick. Für alle, die es googeln, Sie können es im Zusammenhang mit der X Scale Alliance finden. Ich glaube, es ist ein Bild des Monty Python Camelot auf der Titelseite.

Nick Muldoon:

Ist es das wirklich?

Bausatzfreund:

Ja, ja. Ja, ich bin mir ziemlich sicher, komische Dinge. Und du weißt, wie es mit Technikfreaks ist, oder? Es gibt eine Menge eingebetteter Verweise auf Hitchhikers' Guide To The Galaxy und Monty Python in Komponentennamen und so weiter. Es würde mich also nicht wundern. Was ich an so etwas wie dem Camelot-Modell mag, abgesehen davon, dass ich an Monty Python und Burgen und so denke, ist, dass es etwas in Menschen hervorruft. Ich denke, wenn wir mit Leuten über Agile sprechen, müssen wir bei ihnen ein Gefühl hervorrufen. Wir müssen die Leute dazu bringen, zu sagen: „Oh ja, ich verstehe irgendwie, wohin du gehst.“

Bausatzfreund:

Also ich mache immer gerne das kitschige, ohne das A groß zu schreiben, was bedeutet agil für dich? Ja, geht es darum, flink zu sein? Geht es darum, flexibel zu sein und solche Dinge?

Nick Muldoon:

Ich meine, ich bin mir bewusst, dass Sie an der Universität offensichtlich Lean Kanban gemacht haben, Sie haben Scrum Alliance Training and Certification, Prince2, Scaled Agile natürlich gemacht. Warum machst du all diese Dinge? Ich meine, ist es Neugier? Ich meine, erwarten Kunden, dass Sie diese Zertifizierungen haben? Und würden Sie sich in Camelot zertifizieren lassen? Oder sogar eine, die mir kürzlich vorgestellt wurde, war Flight Level Agile, Flight Level Agility. Welches ist eine andere Art von-

Bausatzfreund:

Oh, noch einer?

Nick Muldoon:

Ja, noch einer. Eine andere Art der Beschreibung. Eigentlich erinnere ich mich, ein bisschen nebenbei, tut mir leid, aber Craig Smith von... der zu der Zeit, glaube ich, bei Suncorp, einer australischen Bank, gearbeitet hat. Er hat 46 agile Methoden in 40 Minuten oder so ähnlich angewendet, und er verbrachte eine Minute damit, den Leuten all diese verschiedenen Herangehensweisen vorzustellen.

Bausatzfreund:

Ja, und Methoden im Vergleich zu Frameworks und so weiter macht Spaß, die Grenzen zu ziehen. Ich meine, ich war tatsächlich überrascht, wie oft ich nach Zertifizierungen in Bezug auf Dinge gefragt wurde. Es ändert sich ein bisschen mehr, und ich habe definitiv mehr Begeisterung von unseren Kunden gesehen, und tatsächlich sehe ich neue Leute bei Accenture, was wirklich nett ist, Zertifizierungen zu fordern und zu fördern. Ich denke nicht, dass es notwendig ist, dass der sichere Kurs dann garantiert, dass Sie Agile erfolgreich skalieren werden, oder? Aber es ist eine gute Methode, um zu beurteilen, ob die Leute ihre Hausaufgaben gemacht und sich etwas Mühe gegeben haben, um [Crosstalk 00:14:50] Wissen zu erlangen.

Nick Muldoon:

Und sie haben die grundlegenden Grundlagen.

Bausatzfreund:

Ja. Nun zu deiner Frage zu Brett, also ich denke, wenn wir versuchen, das Wort Coach mit uns selbst zu verbinden... Ich glaube, ich habe von Land zu Land unterschiedliche Trends gesehen. Wenn ich mir also meine Kollegen in den Staaten ansehe, ist der Begriff Agile Coach etwas kodifizierender. Der Arbeit von ICA Agile und Lisa Adkins und allen möglichen anderen Dingen dort drüben ist etwas Besonderes, was gut ist. Im Vereinigten Königreich und in Europa sehe ich das im Moment sicherlich als viel vielfältiger an und es ist ein Begriff, der vielen Menschen in Verbindung gebracht wird.

Bausatzfreund:

Wenn du dir Leute ansiehst, einfach jeden auf LinkedIn mit einem Lebenslauf oder einem kleinen Bio-Titel Agile Coach, kannst du eine Vielzahl von Leuten sehen, die seit etwa 20 Jahren verschiedene Agile-Frameworks machen und Dinge tun, und du kannst jemanden sehen, der seit drei Monaten Scrum Master ist und dann den Job gewechselt hat, und er wird Agile Enterprise Coach als Titel haben. Und du sagst: „Hmm, mit wie vielen Leuten hast du jemals Scrum gemacht? Und hast du etwas anderes als Scrum gemacht?“ Und meine Ansicht ist, wenn 40-

Nick Muldoon:

Aber ich meine Enterprise Agile Coach, weil ich Scrum mit meinem Team von sechs Leuten in einem gemacht habe.

Bausatzfreund:

In einer Enterprise, richtig?

Nick Muldoon:

In Enterprise.

Bausatzfreund:

Aber ich habe das Gefühl, wenn Sie einem Team, das Sie coachen, nur eine Denkweise und einen Ansatz bieten können, um Dinge zu tun, wie coachen Sie sie dann? Das, was Sie anbieten können, ist nicht umfangreich. Aber wenn alles, was Sie erlebt haben, Scrum ist und Sie dann bei einem Team landen, das Betrugsuntersuchungen durchführt, wie werden Sie es auf einen Weg führen, der Sprints und solche Dinge nicht beinhaltet? Ich meine, vielleicht tun Sie das, weil Sie Dinge von Scrum übernehmen werden, die sinnvoll werden, aber Sie brauchen dieses Spektrum.

Nick Muldoon:

Gib uns ein Gefühl, Kit, was am skurrilsten oder ungewöhnlichsten ist vielleicht eine bessere Art, es zu formulieren, was ist das ungewöhnlichste Team, das du in agile Praktiken und Lean-Prinzipien eingeführt hast?

Bausatzfreund:

Also muss ich meinen Kollegen Giles in Verlegenheit bringen, weil meins nicht das interessanteste ist. Giles wollte Geologen Scrum für Standortvermessungen und andere Dinge vorstellen, worüber ich gerne als Beispiel spreche, weil es so...

Nick Muldoon:

Beeindruckend. Ja.

Bausatzfreund:

Beim Auspacken ist es so interessant, darüber nachzudenken, was das bedeuten würde, und ich muss mit ihm sprechen, um zu sehen, wie weit sie es tatsächlich angewendet haben. Aber weil es so ist wie: „Warum würdest du das tun?“ Und dann ist es wie: „Oh, tatsächlich haben sie wahrscheinlich ein wirklich großes Gebiet zum Vermessen. Wäre es nicht besser, ein paar Feedback-Schleifen einzuführen und zu schauen, wie man das Problem aufteilt, um einen gewissen Mehrwert und Lernerfolg aus den Dingen herauszuholen?“

Nick Muldoon:

Das ist interessant.

Bausatzfreund:

Also ich mag das wirklich, wirklich. Ja. Ja, wenn wir unterrichten, sage ich immer, dass es in London ein Restaurant namens Ricardo's gibt, bei dem ich sicherstellen muss, dass es nicht pleite geht. Ich glaube, es ist immer noch im Geschäft, aber...

Nick Muldoon:

Nun, ich dachte es...

Bausatzfreund:

Nun, COVID, richtig? Ich glaube, er ist ihr Besitzer, Ricardo. Zumindest ist er die Person, die ihren Namen inspiriert hat. Er hat Scrum angewendet und es ist wunderschön, wenn man sich die Übungen ansieht, die sie durchgemacht haben, als sie es eingeführt haben. Und auf seiner Website, auf der ich dir die URL für die Shownotes anpinge, aber sie machen diese funktionsübergreifende Teamarbeit, bei der sie das gesamte Personal im Restaurant dazu bringen, sich die Rollentypen anzusehen, die sie benötigen, und dann ihre Verfügbarkeit und so weiter. Sie sagten: „Nur dieser eine Typ kann die Bar machen. Vielleicht sollten wir ein paar andere Leute schulen, damit sie an der Bar arbeiten können?“ Und ich liebe den Gedanken, diese Elemente von Dingen anzuwenden.

Bausatzfreund:

Aber zurück zu deiner Frage, wo habe ich ungewöhnliche Dinge auf meine Teams angewendet, ich habe keine wirklich skurrilen gemacht, um ehrlich zu dir zu sein. Ich meine, ich denke, dass ich einen Hintergrund in Kunst und Design habe, finde ich... Wenn ich über Iteration und all diese Bereiche spreche, denke ich sofort an Projekte zurück, in denen wir Dinge gemacht und Dinge gemacht haben und sie da haben, und besonders, wenn die Leute in einer Geschäftssituation in Panik geraten, an die ich zurückdenke... Als ich an der Universität war, habe ich mit meinem Vater als Freiberufler Spezialeffekte gemacht, weil das eine großartige Möglichkeit ist, Geld für Dinge zu verdienen. Mein Vater arbeitete für die BBC und war freiberuflich tätig. Ich denke an diese Unmittelbarkeit und Panik, wenn ich über Kanban und den Umgang mit Operationen und Zwischenfällen und so spreche, und ich sage: „Ihr braucht nicht in Panik zu geraten, es ist nicht so, als ob ihr live im Fernsehen seid.“ Und sie haben einen Countdown von drei, zwei, eins, richtig?

Bausatzfreund:

Das hat niemand in unserem Geschäft. Wir geraten manchmal in Panik, wenn etwas umfällt, aber es kommt nie zu einer Verzögerung von Sekunde zu Sekunde. Ich denke, die skurrilsten Orte, an denen ich agiles Denken angewendet habe, waren wahrscheinlich vor meiner Karriere in der Technologiebranche. Sie waren an einem Ort, an dem wir kreative Dinge und Dinge machen, und da dachte man sich: „Sie würden niemals ein Dokument mit den Anforderungen von 400 Linien für ein Produktdesign oder ein Schmuckstück erstellen, oder?“ Man hat etwas Grobes produziert und gesehen, was die Leute darüber denken, und Dinge eingebaut, damit es ein Gleichgewicht gibt.

Bausatzfreund:

Ich meine, wenn du Live-Produkte auf den Markt bringst, machst du einige seltsame Dinge, oder? Und du hast ein paar lustige Erinnerungen daran. Ich erinnere mich also an die Zeit, als wir YouView in Großbritannien eingeführt haben. Das ist ein öffentliches Zertifikat, weil es für Accenture war. In Ordnung. Aber am Tag der Markteinführung wurden ein Kollege von mir, Ed Dannon und ich, zu Ausstellungsleuten für diesen Tag, also waren wir auf dem Dach von John Lewis in der Oxford Street in London und haben das Produkt vorgeführt, und das war Teil unserer Agile-Arbeit für diese Woche, weil sie genau das brauchten. Auf diese Weise lieferten wir den Wert, indem wir die Leute physisch sagten: „Hallo, Mrs. Goggins. Möchten Sie diese YouView-Box ganz oben ausprobieren?“ Ich erinnere mich also gern an diese Tage.

Nick Muldoon:

Also war das Capture irgendwo in einem Backlog, oder?

Bausatzfreund:

Wissen Sie was? YouView ist der Ort, an dem ich meine Liebe zu Dura kennengelernt habe, also vermute ich, ja, ich glaube nicht, dass wir irgendwo offiziell einen Backlog hinzugefügt haben. Es wäre auch nett gewesen, nicht wahr? Ich würde gerne behaupten, dass meine gesamte Karriere bei Accenture aus Dura-Tickets aufgebaut werden könnte, wenn ich sie 10 Jahre lang übereinander stapeln würde. Sicherlich etwa 60% -

Nick Muldoon:

Wie viele Dura-Tickets haben Sie Ihrer Meinung nach im Laufe der Jahre gelöst?

Bausatzfreund:

Gott. Wie viele habe ich dupliziert, ist wahrscheinlich die Frage, oder? Das sind ungefähr 8.000. Es gibt immer Duplikate von Dingen. Es müssen Tausende sein, oder?

Nick Muldoon:

Sag mir, du hast, okay, über Tausende von Duplikaten gelöst. Aber du machst das schon eine Weile im Atlassian-Bereich, und natürlich mit den Agile-Transformationen im großen Maßstab. Wie haben sich diese groß angelegten Engagements in den letzten sieben oder acht Jahren entwickelt? Und wie sehen sie 2021 mit dieser komplett ferngesteuerten Betriebsart aus?

Bausatzfreund:

Ja. Ab dem Ende sehe ich Licht, ich sehe Güte in den Dingen. Aber ich schätze, ähnlich wie du es vor 15 Jahren ausgedrückt hast, vor 10 Jahren sagten alle: „Mach Scrum und habe ein paar Storypoints und so.“ Ich denke, in dieser Zeit, wenn wir etwa 10 Jahre zurückgehen, wir sind also wie die frühen 2010er oder wie auch immer wir die Teenager in den Jahrzehnten nennen, ich glaube, wir sehen viele Leute, die mit frühen Versionen von SAFE experimentieren. Sie erfinden das Rad neu und die Leute sagen gleichzeitig: „Lasst uns ein großes Meeting veranstalten, bei dem alle zusammen planen. Wie normalisieren wir Storypoints? Das solltest du nicht, vielleicht sollten wir. Wie machen wir dort Kennzahlen?“ Und solche Sachen.

Bausatzfreund:

Ich denke, ich habe sicherlich viele Leute gesehen, die diese Dinge ausprobiert haben, während wir sie durchgehen, und dann versuchen, Konzepte wie Design Thinking und Kundenorientierung miteinander zu verbinden, und es gibt all diese Dinge, die sich gut anfühlen, aber sie waren in keiner Weise sehr miteinander verbunden, dass sie wiederholbar, methodisch oder kodifiziert waren. Was mir dann sehr viel Spaß macht und auf Ihre letzte Frage zurückkomme, ist dann die Verzweigung der Herangehensweisen. Sie haben SAFE, was für jeden, der daran arbeitet, lobenswert ist, oder? Sie versuchen alles aufzuschreiben.

Bausatzfreund:

Ich sage das immer zu allen, du sagst: „Gott sei Dank hat jemand beschlossen, auf diese Website zu gehen und alles anklickbar zu machen und alles.“ Denn wenn Sie auf eines dieser Elemente verweisen müssen, ist es ein Geschenk des Himmels, immer wieder sagen zu können: „Ja, hier ist die Seite, auf der es um Lean-Budgets geht. Ich bin vielleicht nicht mit allem einverstanden, aber es ist ein wirklich guter Ausgangspunkt. Es ist ein wirklich guter Bezugspunkt.“

Bausatzfreund:

Dann haben Sie die anderen, und ich verwende SAFE an einem Ende der Details, und selbst wenn Sie SAFE richtig machen, machen Sie es nicht nach Vorschrift und Kopieren und Einfügen, oder? Und solche Dinge. Aber da gibt es viele Details und viele Optionen. Am anderen Ende der Skala gibt es Dinge wie Less, wo es bewusst um Entkalkung geht und der Schwerpunkt bewusst auf Einfachheit gelegt wurde. Schauen Sie sich die Titelseiten der Website an, und auf der SAFE-Website haben Sie alles. Auf der Less-Website sieht es so aus, als hätten wir es auf einem Whiteboard gemacht, oder? Und das ist beabsichtigt, beide sind am Ende der Skala beabsichtigt. Dann haben wir Scrum auf der Skala, was im Moment die neuen, aufstrebenden, liebenswerten Dinge zu sein scheint, und das war die andere Sache. Also was ich jetzt sehe...

Nick Muldoon:

Und sie haben alle einen Platz, nicht wahr?

Bausatzfreund:

Ja.

Nick Muldoon:

Es ist interessant, dass es ein ausreichend großes Publikum und einen Markt gibt, der groß genug ist, um erfolgreich zu sein, und es gibt viele Überschneidungen zwischen ihnen in den verschiedenen Idealen und Praktiken, mit denen Sie experimentieren sollen.

Bausatzfreund:

Ja. Ich meine, was ich in den letzten Jahren gesehen habe, ist, dass die Leute meiner Meinung nach oft lobenswert von der Skalierung begeistert sind. Sie werfen also einen Blick auf ein Wort wie Lean Portfolio Management oder ein Geschäftsproblem, das sie haben: Wie kann ich Kapazitäten verwalten? Und sie gehen direkt zu den Skalierungs-Frameworks über, ohne dabei bei den Teams Halt zu machen, und das ist definitiv eine Tendenz, die ich immer häufiger von Freunden, Kollegen, Kunden höre, richtig? Sie tätigen diese Anfangsinvestition nicht, um die Teams zum Laufen zu bringen, egal ob es sich um Scrum handelt oder ob sie etwas anderes verwenden.

Nick Muldoon:

Entschuldigung. Aber Moment mal, willst du damit sagen, Kit, dass die Leute tatsächlich eine skalierte Agile-Transformation durchlaufen und nicht die nötige Teamreife haben? Entschuldigung, verzeihen Sie mir, aber ich glaube, mein Glaube und mein Verständnis waren, dass diese skalierten agilen Transformationen größtenteils auf bestehenden erfolgreichen Teamtransformationen aufbauen.

Bausatzfreund:

Ich denke, so sollte es richtig funktionieren. Wir sollten von unten nach oben gehen, oder zumindest bis zu einem gewissen Grad. In der Roadmap für die Umsetzung von SAFE geht es darum, einen Wendepunkt zu erreichen und... Ich meine, Sie können mit Waterfall und der SAFE-Implementierungs-Roadmap beginnen, aber es geht um Ad-hoc-Agile und diese Dinge dort. Ich denke, wenn Leute in großen Unternehmen und Organisationen mit einem Problem kommen, haben sie ein großes Problem und wollen das lösen, und ja, es ist schwierig, die Botschaft zu bekommen, die: „Hallo, Sie haben ein bis zwei bis fünf Jahre Zeit, um Ihre Teams zum Laufen zu bringen, bevor Sie das schicke Portfoliomanagement-Kanban einsetzen und den richtigen Ablauf der Dinge sehen können.“ Weil die Leute nett sind. Die meisten Leute sind nett, die meisten Menschen sind begeistert, die meisten Leute wollen Dinge reparieren, und deshalb wollen sie dieses große, schuppige Ding reparieren.

Bausatzfreund:

Aber es ist schwierig zu landen, dann: „Nein, du musst diese Dinge unten reparieren.“ Letzte Woche habe ich einer Kollegin, Lucy, beschrieben, und ich sagte: „Wenn Sie eine Antwort auf die Frage haben wollen, wie ich Kapazitäten verwalte und wie ich die Nachfrage in einem großen Unternehmen ausbalanciere, sollten Sie sich jedes Ihrer... vorstellen.“ Lassen Sie uns so tun, als wären sie Scrum-Teams, ohne es für einen Moment zu erniedrigen. Stellen wir uns vor, Ihr Scrum-Team ist wie eine Bar mit einer Reihe verschiedener Glaswaren darauf, und jedes Mal ist die Box ein anders großes Pintglas oder ein Schoner oder was auch immer Sie haben. Mein Kapazitätsmanagement für ein einzelnes Team besteht nun darin, dass ich einen großen Krug Bier trinke und in diesem Bier die ganze Arbeit habe, die ich machen will. Mein ganzer Rückstand an Dingen. Mein Kapazitätsmanagement für ein Team schüttet alles ein und hoffentlich schätze ich es richtig ein. Das tue ich wahrscheinlich nicht und ich verschütte etwas Bier in die ersten, während wir durchgehen. Aber mit der Zeit versuche ich zu erraten, wie viel Bier ich in jede Zeitkiste mit Dingen gießen kann und wir gehen durch.

Bausatzfreund:

Jetzt weiß ich nur, wie viel ich in die Zukunft hineinpassen kann, wenn ich sehe, was ich in der Vergangenheit hatte, zum Beispiel, wie es gelaufen ist und kann ich die Größe des Glases vorhersagen, und im Laufe der Zeit kann ich das, und wir stabilisieren uns. Nach einer Weile ist also alles ein Pintglas, nachdem wir mit allem dort experimentiert haben. Nun, wenn wir nicht in der Lage sind, Prognosen und Messungen durchzuführen und die tatsächlichen Daten mithilfe einiger Tools auf Teamebene zurückzuholen, wie können wir dann teamübergreifend arbeiten? Richtig? Das kannst du nicht. Sie können keine große Roadmap von oben nach unten haben, bei der Sie sagen: „Ja, wir wollen die einfache Agile-Bank für all diese Bereiche auf den Markt bringen und in die Teams einsteigen.“ Es sei denn, Sie haben die Mathematik auf Teamebene, auf die Sie sich verlassen können.

Bausatzfreund:

Es spielt keine Rolle, ob das Story Points sind oder ob Sie keine Schätzungen machen und nur den Flow messen oder Monte Carlo verwenden, was auch immer es ist. Sie benötigen eine mathematische Methode, um den Leuten zu helfen, den Arbeitsfluss und das, was dort passiert, zu verstehen und ihn idealerweise anhand einiger Daten wieder in Werte umzuwandeln. Überlegen Sie, ob Ihre einfache Agile-Bank tatsächlich eine gute Idee ist oder sollten wir uns auf etwas anderes konzentrieren? Ja, liefert es das, was sich die Kunden wünschen, wenn wir ihnen zu Beginn der Dinge eine einfache Agile Bank-Betaversion gegeben haben?

Nick Muldoon:

Wie gut sind Ihrer Meinung nach Kunden heutzutage? Also hier ist die Sache, ich schätze, du sprichst über frühe Transformationen und es war: „Hey, wir gehen zu Scrum.“ Aber jetzt gibt es das Design Thinking, ich meine, es gibt DevOps, es gibt DevSecOps, es gibt jetzt so viele verschiedene Aspekte, die die Leute erforschen und gleichzeitig erforschen. Wie helfen Sie dem Kunden dabei, sich zurechtzufinden? Weil sie es aus verschiedenen Blickwinkeln und aus verschiedenen Aspekten des Geschäfts betrachten, und ehrlich gesagt muss es einfach überwältigend sein.

Bausatzfreund:

Nun, es ist überwältigend für uns, zu helfen, oder? Leute wie Sie, ich meine, Sie sagen: „Wie gehen wir mit dieser seltsamen spezifischen Konfiguration um, die sie in einfache Agile-Programme einfließen lassen wollen?“ Ich glaube, das Licht am Ende des Tunnels, auf das ich bereits hingewiesen habe, ist, dass ich viel mehr Leute kommen sehe, die sie bitten, ihnen zu helfen, die Dinge von unten nach oben richtig zu machen, damit sie verstehen, dass es eine Zange gibt. Wir können nicht ignorieren-

Nick Muldoon:

Hol dir das Fundament.

Bausatzfreund:

Ja. Aber wir können nicht ignorieren, dass es das große Geschäft gibt, oder? Da sind die Leute, die große Dinge erwarten und sie haben das Agile Kool-Aid getrunken, sie haben den Artikel gelesen und wollen dabei sein. Es gibt also diesen Druck von oben nach unten, aber ich sehe, dass immer mehr um Rat und Hilfe gebeten werden, um die Dinge von unten zu erledigen. In letzter Zeit zu einigen Bereichen, zu meiner aktuellen Theorie des Tages, und ich habe etwa alle sechs Monate eine Lieblingstheorie, sodass das später im Jahr nicht mehr dasselbe sein wird, aber ich liebe es wirklich, wirklich, wirklich, wirklich, zuerst die Product Owner auszubilden, damit sie bei dieser Transformation helfen. Meine aktuelle Theorie ist, dass das so ist, weil sie wie ein Rammbock sind, der dem Unternehmen hilft, zu verstehen, was mit diesen Lieferteams passiert, und die Brücke und Verbindung zwischen den Dingen zu bauen und das zu formen.

Bausatzfreund:

Denn wenn die Product Owner nicht der Kanal und die Stimme des Unternehmens sind und der Kunde und die Stimme des Teams, das die Dinge erledigt, fällt meiner Meinung nach der Rest zusammen. Meine Theorie im Moment ist also, dass, wenn man damit beginnt, die Product Owner zu schulen, das die beste Art ist, Dinge anzufangen, und das hilft bei der Skalierung der Körperskalierung, der Konzentration auf die Teamebene, um die Dinge zu erledigen.

Bausatzfreund:

Um ehrlich zu sein, auch wenn sie kein Scrum machen, denke ich, dass die Rolle eines Product Owners, die dem, was der Scrum-Experte sagt, relativ nahe kommt, wenn wir die Sprint-Referenzen und so herausnehmen, meiner Meinung nach eine vernünftige Sache ist, die in jedem funktionsübergreifenden Agile-Team zu haben ist, unabhängig davon, was Sie tun. Und es ist ein ausgeprägter Persönlichkeitstyp, oder?

Bausatzfreund:

Ich spreche oft, wenn die Leute an unserem Kurs Agile Foundations teilnehmen, wo wir sagen: „Hier ist alles. Finde deinen Platz.“ Ich denke, dass die meisten Menschen, oder sicherlich die meisten Menschen, die ich ausbilde, eindeutig einem Persönlichkeitstyp im Stil eines Product Owners oder Scrum Masters zuzuordnen sind. Ich würde sagen, bei etwa 80% merkt man das, zum Beispiel: „Du bist ein produktiver Mensch. Sie sind ein Mensch vom Typ Scrum Mastery. Oder wenn Sie nicht Scrum machen, ein Coach, ein Moderator, ein Teambuilder.“ Vielleicht können etwa 20% zwischen den beiden hin- und herwechseln, und es sind besondere Menschen. Die Einhörner, wie wir sie in jeder Branche und jedem Typ haben, aber die meisten Menschen passen in eines davon. Ich denke, es ist gut, darüber nachzudenken, wie diese Persönlichkeitstypen in Ihrem Unternehmen funktionieren.

Bausatzfreund:

Die andere Sache, die ich daran liebe, zuerst die Produktbesitzer zu schulen, zeigt ihnen wirklich, sagen wir, wir sind jetzt bei... „Hallo, Nick. Gestern warst du der Geschäftsinhaber für diesen Prozess und hast Dinge getan. Du bist jetzt ein Product Owner, geh. Und du hast nur bis Montag Zeit.“ Wenn wir dich schulen, sagst du: „Oh mein Gott, ich wusste nicht, dass ich jetzt für den Wert der Leistung des gesamten Teams verantwortlich bin. Ist es mein Problem, sicherzustellen, dass sie gute Dinge liefern? Das wusste ich nicht.“ Wenn wir diese Schulung also gleich zu Beginn durchführen, wird meiner Meinung nach eine Grundlage für die Erwartungen an das, was wir von diesen Leuten erwarten, und an die Verantwortung, die ihnen auferlegt wird, gelegt. Ja.

Nick Muldoon:

Wenn du diesen Agile Foundations-Kurs machst, den du für Leute durchführst, machst du als Teil davon ein DISK-Profil? Nochmals, um ihren Persönlichkeitstyp zu beurteilen.

Bausatzfreund:

Nein, nein. Das wäre wirklich gut. Was für ein toller Vorschlag. Das kann ich mit einbeziehen.

Nick Muldoon:

Nun, ich erkundige mich nur, weil ich mich das frage. Ich denke gerade darüber nach, ich frage mich, gibt es Persönlichkeitstypen, bei denen die Wahrscheinlichkeit höher ist, dass sie der Product Owner sind? Ist ein Product Owner eher ein CS und ist ein... Ja, ich weiß nicht.

Bausatzfreund:

Ich weiß nicht. Ich meine, es ist eines dieser Dinge, nicht wahr? Ich vergesse die Anzahl der Persönlichkeitstypen und Rollen, die mir in verschiedenen Teilen meiner Karriere zugewiesen wurden. Ich kann mich nicht erinnern. Damals, als ich Mitglied der Studentenschaft war, muss ich den Namen nachschlagen, aber wir hatten die, in denen: „Bist du ein kompletterer Finisher oder ein Shaper?“ Und all diese Dinge waren da, und dann war DiSK relativ beliebt. Wir haben einen Gallup Strengths Test im Accenture Performance Management Tool, der wirklich interessant ist.

Bausatzfreund:

Was mir an Accenture gefällt, ist, dass du, wenn du einem neuen Team beitrittst, dich im Tool zusammensetzen und sehen kannst, welche Stärken und Persönlichkeitsmerkmale die Leute haben, sodass du sagen kannst: „Dieses Team ist sehr stark im Wirbel. Oder du bist ein Team, das voller Energie oder Ideen steckt, und das ist auch ziemlich interessant.“ Ich meine, es ist schön, die Stärke zu sehen, aber es ist auch interessant zu erkennen, wo du vielleicht Lücken hast und du denkst: „Ich muss sicherstellen, dass jemand die Qualität im Auge behält, weil wir alle sehr aufgeregt sind und schnell laufen.“

Nick Muldoon:

Erinnern Sie sich, das müsste jetzt ein Jahrzehnt her sein, da bin ich mir sicher, aber ich glaube, sein Name war Larry Macaroni oder Larry Macayoni, und er arbeitete zu der Zeit für Rally Software und er hat eine sehr umfassende Studie über die Effektivität von Agile-Teams durchgeführt? Und ich denke gerade daran zurück, weil er sich Dinge wie Fehlerraten, entkommene Bugs versus gefangene Bugs und alle möglichen anderen Kleinigkeiten angesehen hat. Aber ich glaube nicht, dass er die Persönlichkeitsmerkmale dieser Teams angesprochen hat und ob sogar Dave, der Mitbegründer hier bei Easy Agile, mein Geschäftspartner, gesprochen hat. Er hat heute Morgen einen Blogartikel über neurodiverse Teams veröffentlicht und ich versuche nur zu überlegen, ob wir wissen, ob es ein Muster der DISK-Profilverteilung, der Neurodiversität, gibt, das zu einem effektiveren Team führt?

Bausatzfreund:

Ich weiß nicht. Ich habe nicht gelesen. Ja, es ist Larry Maccherone, aber es ist nicht so buchstabiert, wie ich es ursprünglich vermutet hatte. Ich füge Makkaroni hinzu, basierend auf deiner Nudelaussprache. Es sieht also so aus, als ob es die Quantifizierung der... Wie heißt es? Quantifizierung der Auswirkungen von Agile auf Teams, was wirklich interessant ist.

Nick Muldoon:

Aber ich weiß nicht, ob diese Art von Studie durchgeführt wurde, seit er sie damals gemacht hat.

Bausatzfreund:

Vor allem die Persönlichkeitstypen sind interessant, und Neurodiversität ist ein weiteres interessantes Element. Also ich habe Legasthenie und Dyskalkulie, und eines der Teile, die ich gefunden habe...

Nick Muldoon:

Was ist Dyskalkulie?

Bausatzfreund:

Nun, genau wie bei Legasthenie gibt es ein ganzes Spektrum, das von einem Begriff abgedeckt wird, also ist er groß. Aber bei meiner speziellen Diagnose habe ich Probleme mit der Verarbeitung von Zahlenfolgen. Sie können mir also eine Zahlenfolge vorlesen und wenn es genau das ist, komme ich normal damit zurecht, weil ich visuelle Verarbeitung kann, denn das ist mein Hintergrund in der Kreativbranche, das machen wir, oder? Wir verarbeiten visuell. Aber ich kann sie dir nicht rückwärts wiederholen, ich kann sie nicht als Einheiten von Dingen mit Dingen neu verarbeiten. Meine Frau sagt...

Nick Muldoon:

Wie bist du überhaupt darauf gestoßen?

Bausatzfreund:

Also nochmal ein Rückblick, also bei meiner Schwester wurde in der Schule Legasthenie diagnostiziert, und sie hat eine traditionellere Legasthenie-Diagnose. Also, wenn man Legasthenie hört, verbinden die Leute das normalerweise damit, dass man nicht lesen kann und Rechtschreibung und Grammatik und solche Dinge. Legasthenie, wie Sie vielleicht aus [unhörbar 00:35:00] wissen, ist eigentlich... Ich warte darauf, dass sie es teilen, um ehrlich zu dir zu sein, weil es so breit gefächert ist. Aber bei meiner Diagnose Legasthenie geht es mehr um die Verarbeitung meines Kurzzeitgedächtnisses, also um die Fähigkeit zur Verarbeitung. Ich kann gut lesen und schreiben.

Bausatzfreund:

Meine Schwester bekam in der Schule eine Diagnose, hatte eine blaue Brille und all die konventionellen grammatikalischen und rechtschreibenden Elemente der Legasthenie. Mein Vater bekam damals, Mitte 50, die Diagnose, glaube ich zu der Zeit. Also fing er an, an der University Arts London, meiner Kunsthochschule, zu arbeiten. Mein Vater betreibt immer noch die Holzwerkstatt im Zentrum von St. Martins auf ihrem schönen neuen Campus in King's Cross in London. Bei ihm wurden Dinge diagnostiziert und ich sagte: „Hmm. Ich weiß, dass es erblich ist, ich sollte mich wahrscheinlich untersuchen lassen.“ Ich glaube, ich war 25 oder 26, und ich war einer von den schönen... Ich meine, es gibt viele schöne Dinge an der Arbeit bei Accenture, aber ein großes Unternehmen hat wirklich, wirklich gute Support-Netzwerke und so.

Bausatzfreund:

Also habe ich die richtigen Leute angepingt und sie sagten: „Ja, natürlich können wir Sie dabei unterstützen, eine Bewertung zu erhalten. Wir würden gerne sicherstellen, dass Sie funktionieren können.“ Also ließ ich eine Untersuchung durchführen und sie sagten: „Ja, du bist Legastheniker und dyskalkuliker in diesem Bereich.“ Aber das Interessantere war, dass sie meinten: „Hier sind die Bewältigungsmechanismen, die Sie entwickelt haben.“ Und die Bewältigungsmechanismen waren eine Liste meiner Karriere, meiner Entscheidungen und meiner Ausbildung. Es war wie: „Du wirst Dinge wählen, bei denen du abstrakt denken und zeichnen kannst.“ Es war wirklich lustig, weil ich nie das Gefühl hatte, dass mich das in der Schule blockiert hat, ich habe Prüfungen und so viel Spaß gehabt.

Bausatzfreund:

Aber ich war schrecklich beim Überarbeiten, oder? Ich kann meine Notizen nicht durchgehen und Dinge dort erledigen. Als ich mir meine Diagnose ansah, dachte ich: „Das liegt daran, dass ich die Dinge nicht auf diese Weise verarbeite.“ Ich muss Dinge visuell verarbeiten, ich muss zeichnen, ich muss Dinge aufteilen. Jetzt schaue ich mir an, wie ich mit Agile-Teams arbeite und Teams coache, und ich stelle abstrakte Bezüge zu Dingen her, richtig? Ich unterrichte Product Owner- und Scrum Master-Kurse auf Mural, in denen wir Dinge bewegen und Objekte erstellen.

Nick Muldoon:

Oder das Beispiel, das du zuvor benutzt hast, Kit, mit den Biergläsern an der Bar.

Bausatzfreund:

Ja. Ich kann mit Zahlen nicht abstrakt umgehen, oder? Ich muss mit ihnen in einer Analogie umgehen oder ich muss sie visualisieren können. Ich bin hoffnungslos im Programmieren, ich kann Konzepte nicht wie Variablen in meinem Kopf speichern. Sie fallen einfach auseinander, es ist, als würde man mit Sand vor mir bauen und alles ist trocken und bröckelig. Und ich glaube, als ich mir die Diagnose ansah und immer noch da war, was? Ich wäre ungefähr drei oder vier Jahre in meiner Karriere bei Accenture. Ich sah mir an, wie ich langsam süchtig nach Tools wie Atlassian und Dura wurde, und ich dachte mir: „Ah, ich kompensiere die Tatsache, dass ich praktisch nicht in der Lage bin, mir Dinge kurzfristig einzuprägen.“ Ich helfe dabei, Dinge zu visualisieren, indem ich Teams helfe und Aufgaben und Dinge zusammenstelle. Das bedeutet, dass ich mein Kurzzeitgedächtnis an dieses schöne Tool auslagere, mit dem wir dort Dinge erledigen.

Bausatzfreund:

Ja. Ja, ich liebe es. Ich glaube, du musst richtig damit arbeiten. Ich spreche mit einigen meiner Kollegen, ich unterrichte im Moment mit einer Agile-Trainerin namens Lucy Sudderby und einer anderen namens Charlotte Blake, und ich sage: „Danke, Leute, dass ihr meine Legasthenie kompensiert habt. Ich weiß es zu schätzen, dass Sie meine Unfähigkeit, etwas auswendig zu lernen, irgendwie ausgleichen.“ Ja, hoffentlich haben sie das Gefühl, dass sie von einigen der skurrilen Stärken profitieren, wenn wir es durchgehen, aber es ist ein Balanceakt, oder?

Nick Muldoon:

Das ist sehr cool. Danke, dass du das geteilt hast.

Bausatzfreund:

Keine Sorge.

Nick Muldoon:

Ich denke gerade darüber nach, wie du das Coaching mit Lucy und Charlotte erwähnt hast, und komme zurück zu etwas, das du vorhin gesagt hast, Kit, in Bezug auf... Ich weiß nicht, ob du die Anführer sagtest, aber im Grunde die Leute an der Spitze, die das Kool-Aid trinken. Ich würde gerne wissen, wie man etwas kreiert, wenn ich auf diesen anderen Gedanken zurückgehe, den du hattest, ich versuche, Punkte zu verbinden, zurück zu dem anderen Gedanken, den du ganz oben hattest, über die psychologische Sicherheit, richtig? Und das Gefühl, sicher zu sein. Wie bieten Sie diesen Führungskräften, die CEOs von Geschäftsbereichen oder Führungskräfte sein können, einen sicheren Ort, an dem sie, was auch immer sie sein mögen, einen sicheren Ort bieten, an dem sie tatsächlich Fragen stellen, Fragen stellen und Fragen stellen und lernen können, ohne sich dabei zu fühlen?

Bausatzfreund:

Ja. Weil wir vergessen, dass es auch Menschen sind, oder?

Nick Muldoon:

Ja.

Bausatzfreund:

Es gibt diese Vorstellung, dass diese Führer irgendwie unüberwindbar sind, sie haben keine Angst. Aber wir müssen einen sicheren Raum für alle rund um Dinge schaffen, ich denke, du hast recht. Ich denke, wir bekommen die gleiche Art von Fragen, wenn Leute mit mir darüber sprechen, wie sie Menschen zu Agile überführen können oder sich für Dinge in einer Organisation einsetzen können, sich aber nicht sicher sind. Ich denke, die Antwort ist relativ gesagt, darin, dass wir ihnen einige Daten, einige Fakten geben müssen. Ich bin also der Meinung, dass es nicht gut ist, zu den Leuten zu kommen und über...

Bausatzfreund:

Ich kritisiere etwas zynisch, wenn Leute über agile Arbeitsweisen sprechen, und sie kürzen es oft auch mit WAW oder so ab. Ich denke, wenn wir zu abstrakt über Agilität sprechen, und ich sage den Ausdruck zu oft winkende Hände, aber wenn wir innerhalb von Einzelheiten zu viel darüber sprechen, weckt das ein Gefühl der Angst und es ist eine nebulöse, wischige, verwaschene Art von Sache, also bringe ich den Leuten gerne ein paar Daten zur Verfügung. Meine Lieblingsberichte, und ich brauche aktuelle Statistiken, aber die Sandish Chaos Reports sind ein großartiges Projektmanagement-Journal, in dem sie über Erfolg und Misserfolg von Waterfall- und Agile-Projekten sprechen.

Bausatzfreund:

Nun, es gibt eine Reihe von Fragen, die Sie dazu führen, wie sie Agile und alle möglichen Dinge klassifizieren. Aber unbestreitbar sagt es Ihnen, dass die traditionelle Art, Dinge zu tun, von der uns gesagt wird, sicher und geschützt ist, wenn ich zu einem Einkaufsteam oder einem Finanzteam gehe und sage: „Ich würde dieses Ding gerne bauen, Leute.“ Sie sagen: „Großartig, nenne mir die Meilensteine, gib mir den Plan.“ Und da ist die grundlegende Annahme, dass dies eine sichere, verantwortungsvolle und bewährte Methode ist, Dinge zu tun.

Bausatzfreund:

Die Sandish Chaos Reports sagen dir, dass es eine schreckliche Art ist, Dinge zu tun, oder? Sie sagen: „Statistisch gesehen ist es egal, was Sie bauen, welche Branche, was Sie tun, es ist eine schreckliche Idee, den Umfang von Anfang an festzulegen, Ihrem Plan zu vertrauen und ein System zu haben, das versagt, wenn Sie Änderungen vornehmen.“ Und wenn Sie es auspacken, wenn wir zum Beispiel über Agilität insgesamt sprechen, was sagen wir dann? Wir sagen, dass es keine gute Idee ist, etwas zu beginnen und dass es nur innerhalb ziemlich enger Grenzen erfolgreich sein kann, wo niemand seine Meinung für die Dauer der Sache ändert, alles genau so läuft, wie Sie es planen, und wann passiert das jemals mit Technologie? Und die Welt verändert sich für die Dauer deiner Sache nicht.

Bausatzfreund:

Die meiste Zeit, wenn wir über diese Projektsachen sprechen, zum Beispiel, wie lang sind sie? Drei Monate bis drei Jahre sind das Zeitfenster, das ich normalerweise gebe. Drei Monate sehe ich heutzutage in keiner Branche mehr, oder? Diese großen Anstrengungen, bei denen die Leute versuchen, diese Dinge in großem Maßstab zu tun, Sie sprechen von mehreren Jahren. Wie hoch ist die Wahrscheinlichkeit, dass der Geltungsbereich für diesen Zeitraum eingefroren wird? Ziemlich gering, und wie hoch ist auch die Wahrscheinlichkeit, dass die Leute, die Sie zu Beginn nach den Anforderungen gefragt haben, sie wirklich alle kannten? Normalerweise sind alle sehr nett, sie geben ihr Bestes.

Nick Muldoon:

Die Möglichkeit, dass die Leute, die du am Anfang fragst, da sind, wenn du tatsächlich zum nächsten kommst-

Bausatzfreund:

Ja. Damit gibt es eine ganze Reihe grundlegender Probleme. Deshalb stelle ich unseren Führungskräften diese Art von Daten gerne zur Verfügung, wenn sie nach den Argumenten für Agilität fragen. Es geht also nicht darum: „Möchten Sie sich anmelden, um ein Framework zu verwenden?“

Nick Muldoon:

Aber sagen wir, Kit, sie haben sich für Agilität ausgesprochen, sie sind da, sie tun es. Welchen Platz stellst du ihnen zur Verfügung? Haben Sie einen CEO-Rundtisch, an den sie gehen können, und sie haben eine Schulter, auf der sie sich ausweinen können und sagen: „Diese agile Transformation wird schwieriger, als ich dachte“?

Bausatzfreund:

Anonyme Agilisten, Firma [Crosstalk 00:42:19]. Ja. Ich denke, es ist eine gute Idee, sie zu paaren, daher erhalte ich im Moment viele Anfragen, dass wir Coaches direkt zur Unterstützung von Führungskräften zur Verfügung stellen sollen. Ich habe auch einen Trend zum Reverse-Mentoring gesehen, bei dem es sich um separate große Unternehmen handelt. Aber diese Art von Vorstellung von, okay, Sie haben diese Leute, die wirklich erfahren sind, und ihre Erfahrung ist relevant, oder? Wir sagen nicht, dass die 30-, 40-, 50-jährige Karriere eines CEOs in einer Branche jetzt ungültig ist und wir wissen es besser als sie. Aber sie versuchen, das mit denen in Einklang zu bringen, ohne dass es dazu kommt, oder? Weil das Agile Manifest jetzt 20 Jahre alt ist. Aber sie versuchen, diese mit diesen fremden, neuen Praktiken und Dingen, die sie haben, in Einklang zu bringen, und das erfordert ein bisschen Handhaltung. Also ja, da gibt es einen persönlichen Blickwinkel. Ich denke nicht, dass ein runder Tisch per se der richtige Weg dafür ist, aber ihnen jemanden zu geben, mit dem sie auch chatten können, und, ja, die Fähigkeit, Beziehungen aufzubauen und zu fragen: „Was ist das für ein Ding?“ Und das Joggen zu dekodieren, finde ich wirklich nützlich.

Bausatzfreund:

Daten über Erfolgsraten sind also wichtig, oder? Aber bei den anderen Daten, die meiner Meinung nach wirklich wichtig sind, um dieses Gefühl der Sicherheit zu vermitteln, geht es um die Wertschöpfung, und hier haben die meisten Menschen meiner Meinung nach immer noch Probleme. Wir sind gerade an einem Punkt angelangt, an dem die Menschen beginnen können, ein Konzept von Nutzen und Wert an den Anfang der Dinge zu stellen. Nun, oft ist das immer noch zu groß. Wir sprechen über den Wert des gesamten Projekts. Kannst du jedem Epos und jeder Geschichte in deinem Backlog oder welchen Einheiten auch immer du gerade arbeitest, einen Wert beimessen?“ Wahrscheinlich nicht, oder? Können Sie das in einem Pfund, Dollar oder Euro tun oder was auch immer Ihre Landeswährung ist? Wahrscheinlich nicht. Aber kannst du sie überhaupt von eins bis zehn einstufen? Vielleicht mit Dingen.

Bausatzfreund:

Ich denke also, die bevorstehende Entwicklung von OKRs und KPIs, und die Leute, die beginnen, das immer mehr zu verinnerlichen, gibt etwas Hoffnung. In den meisten Organisationen ist es noch relativ unausgereift und du bist immer noch auf dem Weg dorthin. Ich habe das Gefühl, dass es bei jeder Art von Praxis und Dingen wahrscheinlich zu Fehlinterpretationen, enthusiastischen und wohlmeinenden Interpretationen kommen wird, aber Sie werden einige Leute dazu bringen, es irgendwie zu nutzen, um Dinge zu überspringen, wahrscheinlich in einigen Bereichen. Aber diese Daten zu bringen, die ihnen eine Art Feedback-Schleife geben, die für die Leute in diesen Führungspositionen Sinn macht, finde ich wirklich hilfreich. Im Gegenteil erwarten sie, RAG-Status und Meilensteine zu sehen, und das sind die einzigen Daten, die sie von ihren Teams erhalten, oder?

Bausatzfreund:

Ich habe mich vor ein paar Jahren mit einer Führungskraft einer Organisation getroffen und mir gesagt: „Bitte investieren Sie in Ihre Werkzeuge. Bitte tun Sie es.“ Und er sagt: „Warum sollte ich das brauchen? Ich habe diese Folien, auf denen mir Grün angezeigt wird und die Daten sind da.“ Und ich sagte: „Ich finde es toll, dass du vertraust, und ich vertraue gerne.“ Das Vertrauen in die Teams war wirklich, wirklich gut. Aber ich kannte die Teams und wusste, dass sie keine Tools hatten. Es waren die Projektmanager, die gestresst waren und herumliefen, und dann wusste ich, dass alle RAG-Status lauten würden: „Grün, grün, grün, grün. Rot.“ Es war der Wassermelonen-Effekt, der passieren sollte, oder?

Bausatzfreund:

Wenn ich also sehe, dass solche Gespräche stattfinden, möchte ich sie stärken. Ich möchte ihnen Daten zur Verfügung stellen und diese Dinge zusammenbringen. Ich denke, dass Daten darüber, warum Agile wirklich wichtig ist, Daten darüber, wie es in Ihren Teams wirklich läuft und die Fähigkeit, auf dieser Grundlage Entscheidungen zu treffen, wirklich wichtig sind. Da ist die Scrumming-Fallstudie über den Saab Gripen sehr schön, weil sie in einer der Artikulationen die Reihenfolge der morgendlichen Standups machen und angeblich, laut Fallstudie, bin ich mir ziemlich sicher, dass es stimmt, sie machen 7:30 Uhr morgens, was Wahnsinn ist. Ich weiß nicht, warum sie in Schweden um 7:30 Uhr morgens beginnen, aber anscheinend fangen sie um 7:30 Uhr morgens an. Aber sie machen eine Abfolge von Standups und die Idee ist, dass am Ende der Stunde die Kaskade von Standups bedeutet, dass jedes Hindernis innerhalb einer Stunde die Führungskräfte erreichen und sie es beheben können.

Bausatzfreund:

Dieses Gefühl der Verbundenheit, dieses Vertrauen in Teams und diese Demonstration von Fortschritten. Wirklich funktionierende Dinge sind die Art und Weise, wie wir kommunizieren, dass wir Fortschritte machen. Ich denke, auf diese Weise bauen wir ein gewisses Maß an Sicherheit auf und helfen unseren Führungskräften, Dinge zu tun. Nicht RAG-Status und -Meilensteine und Gantt-Diagramme. Hoffentlich müssen sie diese Realität mit den Dingen umgehen können.

Nick Muldoon:

Es ist interessant. Es macht mich nachdenklich, wir haben vor Kurzem eine Werksbesichtigung gemacht und es ist eine Fabrik, die Klimaanlagenverteiler für Geschäftsgebäude herstellt, und sie sind tatsächlich...

Bausatzfreund:

Was? Warum hast du eine Klimaanlagenfabrik besichtigt? Hast du eine Klimaanlage gekauft?

Nick Muldoon:

Nein, nein, nein. Lean-Prinzipien, richtig? Sie möchten die Anwendung des Prinzips sehen.

Bausatzfreund:

Wow, du lebst es, du lebst es. Es ist wundervoll.

Nick Muldoon:

Ja. Also frühstücken sie von 6:15 bis 6:45 oder 6:30 Uhr, so ähnlich, und dann machen sie sich auf den Weg. Ich glaube, sie machen ihr Standup um 7:45 Uhr, nachdem sie tatsächlich im Flow sind, sie kommen zusammen und sagen: „Okay, wo stehen wir heute? Woran arbeiten wir?“ Dann wird das an das Operationsteam weitergeleitet und dann an das Führungsteam, und am Ende des Tages machen sie ihre abschließende Besprechung für den Tag: „Hey, haben wir alle unsere Tools? Sind wir zurück? Womit haben wir morgen früh zu tun?“ Es war also wie der Anfang und das Ende des Tages und es ist wirklich interessant.

Nick Muldoon:

Ich denke nur darüber nach, dass wir in COVID, als wir alle die ganze Zeit auf Zoom waren, ein Huddle am Ende des Tages eingeführt haben, und ich denke, das war sehr nützlich. Aber wenn wir dann wieder ins Büro kommen, fällt es natürlich weg. Es ist interessant, wie sich die Dinge entwickelt haben, oder?

Bausatzfreund:

Ja. Und du bist der Big Head Honcho, oder, Nick? Ich mache mir Sorgen, wenn es um Besprechungen am Ende des Tages geht, ob sie für das Team sind. Sie sollen dafür sorgen, dass die Leute das Gefühl haben, dass sie über Dinge hinweg sind, und ich finde das interessant, weil ich die Leute durch das Üben für Scrum Master-Prüfungen und so führen muss, im Moment viel, und ich spreche wirklich gerne darüber, wie Standups für das Team sind. Sie sind für die Entwickler, sie sind nicht einmal für den Product Owner, sie sind sicherlich nicht für die Stakeholder. Bei vielen dieser Agile-Zeremonien denke ich mir immer wieder: „Wer profitiert von diesem Meeting? Bekommt jemand einen Status-Check oder bekommt ihn das Team?“

Bausatzfreund:

Und wenn das Team Spaß daran hat, wenn das Team am Ende des Tages etwas mitbekommt und so, bin ich damit einverstanden. Aber manchmal sehe ich Dinge und die beiden Anti-Muster, die ich sehe, wenn Führungskräfte, egal auf welcher Ebene, an der Besprechung teilnehmen, also das erste ist, dass sie es als Belüftungsplattform nutzen. Das Team ist bereit, mit ihrem Standup loszulegen und dann kommt der Anführer, egal auf welchem Level, und er sagt: „Team, ich habe dieses Update für euch.“ Und dann sind es etwa 10 Minuten ihres tollen Updates und ihrer Mini-Vision für den Tag, und am Ende sagen die Leute: „Ja, jetzt mach dein Standup. Jetzt mach so etwas wie Scrum.“ Und dann ist die andere Sache, wo es wie ein Status-Check für Dinge wird und ich sage: „Dafür ist es nicht da, Leute. Wir sollten uns auf [Crosstalk 00:48:57] konzentrieren -“

Nick Muldoon:

Das tun wir. Also können wir mit 22 Leuten in sechs bis acht Minuten fertig werden.

Bausatzfreund:

Das ist schlau.

Nick Muldoon:

Es hat einige Zeit gedauert, bis wir hierher gekommen sind, aber worum wir eigentlich gebeten haben, war eine gute Sache, und das ist in der Regel eine Familien-, Gemeinschaftssache. Was haben Sie heute vor, haben Sie irgendwelche Blockaden? Und jetzt, wo wir diesen Chat führen, ist es interessant, Kit, ich sehe nicht, dass Blocker sehr oft auftauchen, also frage ich mich, warum das so ist.

Nick Muldoon:

Ja, jedenfalls. Hey, Kit, ich bin mir der Zeit bewusst. Ich habe eine letzte Frage an dich.

Bausatzfreund:

Ja, mach es.

Nick Muldoon:

Was liest du gerade? Welche Bücher liest du oder hast du in letzter Zeit gelesen, die du dem Publikum empfehlen würdest?

Bausatzfreund:

Ja, ich stehe zwischen Geschäftsbüchern. Ja, ich muss einen nächsten finden. Ein Merkmal, und es ist wahrscheinlich nicht meine Legasthenie, ich glaube, es liegt nur daran, dass ich faul bin. Ich kann wirklich schlecht Geschäftsbücher lesen, wie seriöse Bücher mit Dingen. Deshalb verlasse ich mich sehr auf Hörbücher, um aussagekräftige Daten zu konsumieren. Ich habe es wirklich, wirklich genossen, das Hörbuch von Lisa Adkins Coaching Agile Teams zu hören, als sie es veröffentlichte, weil ich wusste, dass ich das Buch nicht durchlesen würde und so-

Nick Muldoon:

Hat sie es erzählt?

Bausatzfreund:

Ja, was ist noch besser, oder?

Nick Muldoon:

Cool, ja.

Bausatzfreund:

Es ist so schön, von den Stimmen der Autoren zu hören, wenn sie Dinge tun. Also ich würde das wirklich empfehlen und es dann danach begleiten... Ich meine, so oder so, hören Sie sich die Women In Agile Podcast-Serie über das Coaching agiler Teams an, denn sie sprechen übereinander und es gibt eine ganze Episode über Sprache, und sie spricht darüber, dass es zwischen dem Schreiben des Buches und dem Erzählen des Buches, dem Lesen, Sprachabschnitte gab, in denen sie einfach zusammenzuckte und sie sagte: „Ich kann nicht glauben, dass ich das geschrieben habe.“ Und es stimmt mich wirklich gut, wenn ich über meine Agile-Reise nachdenke und wie ich vor dem, was ich vor fünf, sechs Jahren mit Teams gemacht habe, zusammenzucken würde. So wie wir es alle tun, oder? Im Nachhinein blickst du zurück.

Bausatzfreund:

Das Coaching agiler Teams ist also wirklich, wirklich gut, und ich würde es empfehlen. Wann [Crosstalk 00:50:54] -

Nick Muldoon:

Ist das nicht wunderschön, oder? Denn wenn du zurückschaust und zusammenzuckst, zeigt das, dass du dich weiterentwickelt und angepasst hast und gelernt hast und dich verbessert hast?

Bausatzfreund:

Oh ja, wenn du zurückschaust und nicht zuckst, warst du auch perfekt, was unwahrscheinlich ist, oder?

Nick Muldoon:

Unwahrscheinlich. Unwahrscheinlich.

Bausatzfreund:

[Crosstalk 00:51:07] Dinge, oder du ahnst es nicht, was wahrscheinlicher ist. Ich meine dich nicht persönlich, Nick. Agile Teams zu coachen ist wirklich gut. Ich empfehle trotzdem Whole Time, wenn die Leute versuchen, sich ein Bild davon zu machen, wie es ist, in Agile zu arbeiten, was ist da drin. Früher habe ich The Phoenix Project empfohlen, und dann hat mir The Unicorn Project wirklich mehr Spaß gemacht, um ein Team aufzubauen. Ihr Gerede über die Klimaanlagenfabrik hat mich nur an all die Lean-Dinge erinnert. Ich mag das wirklich, und ich habe Probleme, wenn ich es den Leuten erkläre, weil ich so denke: „Es ist nicht trocken, es ist ein Roman über eine agile Transformation, aber das ist es nicht [Crosstalk 00:51:42]

Nick Muldoon:

Ist es nicht. Das liebe ich. Ich steh auf und lese die Zeitung, oder?

Bausatzfreund:

Ja.

Nick Muldoon:

Das ist morgens mein Ding und abends würde ich niemals ein Geschäftsbuch lesen. Aber The Phoenix Project und The Unicorn Project, ich habe sie mehrmals als Gutenachtbücher gelesen.

Bausatzfreund:

Ja. Zu deinen Kindern, Nick? Sitzst du da [Crosstalk 00:52:01]

Nick Muldoon:

Das werde ich. Ich werde dort hingehen. Ich fange an, ihnen die Lean-Prinzipien beizubringen und Qualität einzubauen. Ja.

Bausatzfreund:

Ja. Falls Sie es noch nicht getan haben, ist es wirklich amüsant, Ihre Kinder zum Storypoint Lego zu bringen, und es hat mir sehr viel Spaß gemacht. Ich weiß, es ist wie Zeit-Gym, aber ich mache es gerne mit meinem Sohn Ethan, weil du weißt, wie schwierig es ist, Erwachsene dazu zu bringen, relative Größen in Einheiten zu bekommen, und Kinder verstehen es einfach. Es ist wunderbar, dass sie sich einfach nicht von der Tatsache ablenken lassen, dass man eine abstrakte Einheit hat, und sagen: „Ich verstehe die Idee.“ Ich habe Ethan in fünf Minuten auf die Geschichte hingewiesen, ich hatte Mühe, die Geschichte einiger Erwachsener in etwa fünf Tagen zu bekommen, und sie streiten sich: „Meinen Sie, es sind Tage, ideale Tage, Stunden?“ Dinge.

Bausatzfreund:

Also ja, Unicorn Project finde ich wirklich gut. Ich habe eigentlich noch nicht alles gelesen, aber ich will es lesen und ich empfehle es die ganze Zeit wegen eines wirklich guten Podcasts, 99 [unhörbar 00:52:51] Invisible Women von Caroline Criado Perez. Wenn wir also davon sprechen, kundenorientiert zu sein und wirklich zu wissen, für wen wir unsere Produkte anbieten, gibt es meiner Meinung nach eine wirklich wichtige Geschichte darüber, sicherzustellen, dass wir die Daten verstehen und wann wir sie durchgehen, und Invisible Women hat einige erstaunliche, schreckliche, aber erstaunliche Geschichten und kleine Daten und Erzählungen dazu. Ich denke, das wären im Moment meine drei, drei sind eine gute Zahl, um die Leute zu fragen, nicht wahr?

Nick Muldoon:

Okay, cool. Kit, das war wunderbar. Mein Fazit ist, dass ich Die unsichtbare Frau lesen muss, weil ich das Buch nicht gehört habe.

Bausatzfreund:

Unsichtbare Frauen, es gibt viele von ihnen ist das Problem, Nick.

Nick Muldoon:

Unsichtbare Frauen, okay. Danke. Das ist mein Imbiss, den ich lesen muss. Kit, das war wunderschön, ich habe unser Gespräch heute Morgen wirklich genossen.

Bausatzfreund:

Es war auch ein Vergnügen. Vielen Dank, dass du mich eingeladen hast, Nick.

Nick Muldoon:

Ich wünsche Ihnen einen schönen Tag und freue mich darauf, wieder über diese Reise zu sprechen. Ich möchte zurückkommen und das noch einmal überdenken.

Bausatzfreund:

Ja. Lass uns einchecken. Wir sollten vielleicht unsere DISK-Profile für das nächste erstellen, und wir können herausfinden, ob ich vielleicht als Product Owner bestimmt bin und du, ich weiß nicht, du wirst so etwas wie Testleiter sein oder so, was da steht. Ich weiß nicht. Wir werden es herausfinden.

Nick Muldoon:

Es ist wunderschön. In Ordnung, vielen Dank, Kit. Hab einen wundervollen Tag.

Bausatzfreund:

Und du. Tschüss jetzt.

‍

„Mein Gespräch mit William und Riz hat mir sehr gut gefallen. Ich freue mich darauf, ihre Empfehlungen mit unserem Team umzusetzen“ - Angad Sethi

In dieser Folge sprach ich mit William Rojas und Rizwan Hasan von Adaptavist über die Möglichkeiten, wie wir leistungsstarke agile Teams unterstützen können:

• Die Bedeutung der Teamausrichtung
• Wann und wo sollten Sie Tools verwenden, um Ihre Teamziele zu erreichen
• Priorisieren Sie, an welchen Gesprächen Sie teilnehmen müssen
• Beratung für Remote-Teams

Abonnieren/Hören Sie auf Ihrer Lieblings-Podcasting-App.

Danke William & Rizwan!

Transkript

Angad Seth:

Guten Tag/Abend/Morgen an alle. Wie geht's euch?

Rizwan Hasan:

Oh, gut. Danke Angad.

William Rojas:

Ja. Wie geht's dir?

Angad Seth:

Ja, wirklich gut. Ja, ich freue mich sehr, mit euch zu plaudern. Sollen wir uns zunächst vorstellen? Riz, möchtest du es nehmen?

Rizwan Hasan:

Sicher. Mein Name ist Riz Hasan, ich lebe in Brüssel, Belgien. Ganz neu hier ansässig, war eigentlich früher in New York ansässig, nicht weit von William entfernt. Wir haben normalerweise zusammen im selben Team gearbeitet. Meine Rolle hier bei Adaptavist ist, dass ich Teamleiter für unsere Beratungsgruppe in EMEA bin. Also in der europäischen Region und im Vereinigten Königreich. Mein Alltag ist also viel internes Management, aber ich arbeite auch mit Kunden und meinen Beratern daran, wie unsere Kunden agil skalieren und ihnen bei Toolproblemen, Prozessproblemen, Personalproblemen und all dem oben genannten helfen.

Angad Seth:

Ja. Ja. Hört sich toll an.

William Rojas:

Was mich betrifft, William Rojas. Eigentlich wohne ich in einer kleinen Vorstadt namens Trumble in Connecticut, die ungefähr eine Stunde und mehr nordöstlich von New York liegt. Und wie Rez schon erwähnt hat, ja, wir haben mehrere Jahre zusammengearbeitet, wir haben ein agiles Transformations- und Skalierungsteam für Adaptavist geleitet. Meine neue Rolle besteht jetzt darin, dass ich das Prinzip des Vorverkaufs übernommen habe, heutzutage quasi ein Berater für den Vorverkauf. Es ist tatsächlich eine neue Rolle bei Adaptavist, und was wir tun, ist, eigentlich haben wir alle, ich glaube, die meisten von uns sind alle wie ehemalige Berater, die den Pre-Sales-Prozess unterstützen und zwischen dem Vertriebsteam und dem Lieferteam und all den anderen Teams arbeiten, die unsere Kunden bei Adaptavist unterstützen.

Angad Seth:

Fantastisch, großartig.

William Rojas:

Ich helfe dabei, Lösungen für Kunden zu finden, Vorschläge zu unterbreiten und sie bei der Umsetzung zu unterstützen.

Angad Seth:

Ich bin Angad, ich bin Softwareentwickler und arbeite an Easy Agile-Programmen und Easy Agile-Roadmaps, zwei der Produkte, die wir für den Atlassian-Marktplatz anbieten. Wir freuen uns riesig, mit euch darüber zu sprechen, wie eure Teams arbeiten, zum Beispiel darüber, was alltäglich ist. Riz, möchtest du das beantworten?

Rizwan Hasan:

Sicher. Ja. Also, abgesehen von den internen Management-Kram, denke ich, das Besondere an dieser Konversation ist, wie wir Kunden erklären, wie sie mit der Planung im großen Maßstab umgehen können, oder?

Angad Seth:

Ja.

Rizwan Hasan:

Ich arbeite gerade mit einem Kunden zusammen, der in den USA ansässig ist, aber er übernimmt links und rechts andere Softwareunternehmen. Was meiner Meinung nach auch ein Trend ist, der in diesem SaaS-Ökosystem stattfindet. Und wenn das passiert, versuchen sie, all diese Arbeit unter einen Hut zu bringen. Wir besprechen also, wie wir all das auf einfache Weise visualisieren können, ohne dass es im Vorfeld darum geht, Anforderungen zu identifizieren oder zu verstehen, welche Systeme wir einbeziehen wollen, sondern vor allem, was möchten Sie einbeziehen? Im Moment, in dieser Phase der Daten, in der ich mit diesem Kunden arbeite, sind es wirklich nur die ersten Gespräche darüber, was Sie planen? Was machst du? Was ist dir wichtig? Es sind also viele dieser Gespräche darüber.

Angad Seth:

Sie haben also erwähnt, dass es viel internes Management gibt. Sind einige Ihrer Kunden Arbeitskollegen oder sind es externe Kunden?

Rizwan Hasan:

Sie sind hauptsächlich intern, weil ich ein Team leite. Ich habe also verschiedene Leute, die an verschiedenen Arten von Projekten arbeiten, in denen sie möglicherweise Cloud-Migrationen durchführen. Sie machen vielleicht ein bisschen Skriptarbeit. In Bezug auf Services decken wir alles ab, was innerhalb des Atlassian-Ökosystems zu finden ist, egal ob es um geschäftliche, prozessbezogene oder toolbezogene Inhalte geht. Es ist also zu jeder Zeit eine große Mischung aus Dingen.

Angad Seth:

Cool. Und ist es normalerweise so, als ob du mit allen Teamleitern sprichst und ihnen Ratschläge zu agilen Zeremonien gibst und die Arbeit durch Pipelines und so?

Rizwan Hasan:

Ja, eigentlich, also eine Geschichte darüber, als ich zum ersten Mal nach Brüssel gezogen bin, weil wir... Also, Professional Services begannen bei Adaptavist in Großbritannien, und das war vielleicht vor sieben bis acht Jahren, und es hat sich erweitert und ich und William waren Teil der ersten Gruppe von Beratern, die in Nordamerika waren. Das hat sich sehr schnell ausgeweitet, und jetzt, wo wir in der EMEA-Region sind, ist es fast wie eine andere Einheit. Es ist eine andere Art zu arbeiten, und viele Führungskräfte sind nach Nordamerika verlagert, also gibt es neue Systeme, Prozesse und Zeremonien und dann passiert all das. Aber wegen der Zeitzonen gibt es einen Konflikt.

Als wir hier ankamen, fing ich an, einige dieser Gewohnheiten und konsistenten Gespräche wieder einzuführen, um wirklich viel mehr in einem besseren Planungsrhythmus zu sein. Also mit Leuten zu interagieren, die zum Beispiel die Arbeit bis zur Auslieferung im Vorverkauf bringen würden. Also Leute, die ähnlich arbeiten wie William hier in dieser Region, und dann auch Projektmanager, die für die Verwaltung dieser Arbeit verantwortlich wären. Richtig? Also das Äquivalent wie ein Scrum Master bei einem Engagement oder wie ein RTE bei einem großen Engagement. Richtig?

Angad Seth:

Jep. Jep. Das ist großartig. Nur eine Sache, die mir sehr gut gefallen hat, war Ihre Terminologie. Du hast Gespräche statt Zeremonien benutzt oder über agile Denkweise gesprochen, in dem Sinne, dass du nicht nur Zeremonien in Teams vorantreibst, wo du tatsächlich Agilität verkörperst. Nun, ich gehe davon aus, dass Sie aus Ihrem Gespräch stammen, aber ich schätze, wir packen das aus. Was ist mit dir, William? Was ist dein [Crosstalk 00:06:32]

William Rojas:

Ich wollte sagen, das ist eine interessante Herausforderung, vor der wir stehen, weil Adaptavist eine ganze Niederlassung hat, die Produktentwicklung durchführt, und es gibt Produktentwickler und Produktmanager und Produktmarketing und all diese Dinge. Und sie legen Pläne fest und konzentrieren sich, liefern und so weiter, wie man es von einer normalen Produktorganisation erwarten würde. Was die Beratung angeht, ist eines der Dinge, die sehr interessant sind, dass viele von uns quasi vor zwei Chefs Rechenschaft ablegen müssen, oder? Zum Beispiel kommen unsere Kunden rein und sagen: „Hey, das brauchen wir“, und wir müssen sie unterstützen. In der Zwischenzeit haben wir viele interne Projekte, interne Verfahren und Prozesse und Dinge, die wir als Unternehmen, als Praxis, erledigen wollen, aber gleichzeitig müssen wir unseren Kunden immer noch antworten.

Angad Seth:

Ich verstehe.

William Rojas:

Das ist also tatsächlich eine der interessanten Herausforderungen, mit denen wir aus agiler Sicht ständig konfrontiert sind, indem wir manchmal widersprüchliche Prioritäten ausbalancieren müssen. Und das ist definitiv etwas, und obwohl Beratungsteams auf verschiedenen Ebenen vor dieser Herausforderung stehen. Richtig?

Angad Seth:

Ja.

William Rojas:

Wie Riz schon erwähnt hat, bringen wir ständig mehr Arbeit rein und sagen: „Okay, du musst dich jetzt anpassen und neu planen, um etwas anderes zu machen, und dann managen.“ Ja. Es ist ein andauerndes Problem, das einfach Teil dieses Teils dieser Welt ist.

Angad Seth:

Ja. Okay. Ich verstehe. Also, wenn ich das richtig gehört habe, dann ist es, ich schätze, du empfiehlst ständig agile Prozesse, aber du wirst sie vielleicht nicht unbedingt üben können?

William Rojas:

Aber mehr noch, wir üben sowohl für uns selbst als auch versuchen, unseren Kunden zu sagen, dass sie es üben sollen oder versuchen, uns anzupassen.

Angad Seth:

Ich verstehe, ja.

William Rojas:

Wissen Sie, ein Kunde kommt mit Bedürfnissen und sagt: „Okay, jetzt müssen wir neu planen oder ihnen beibringen, wie das geht, oder auch ihre neu entstehenden Prioritäten neu berücksichtigen.“ Am Ende müssen wir also Agile mit und für unsere Kunden sowie für uns selbst üben. Es ist diese ständige Neugewichtung, bei der Kundenbedürfnisse mit internen Bedürfnissen verknüpft werden müssen, und dann die ständige Neupriorisierung, die sich daraus ergeben kann.

Angad Seth:

Ja.

William Rojas:

Und dann suchen wir ständig nach Fragen wie wir dieses Ding effizienter, effektiver machen können? Wie können wir wirklich schlank sein, wenn es darum geht, wie wir die Arbeit machen und so weiter? Das ist definitiv eine Sache, die wir praktizieren. Wir versuchen, das täglich zu praktizieren.

Angad Seth:

Ja. Und ich schätze, das ist ein sehr, sehr kniffliger Bereich... kein kniffliger Bereich. Es kann knifflig sein, denke ich, aber die Schwierigkeit wird durch Telearbeit noch verstärkt. Habt ihr viele Kunden, die auf Telearbeit umgestiegen sind? Und ich weiß nicht, hat es Probleme ans Licht gebracht, was eine gute Sache sein kann, oder wie war Ihre Erfahrung?

William Rojas:

Das ist interessant, weil ich seit über ein paar Jahrzehnten in der Beratung tätig bin, und traditionell, also habe ich viel davon gemacht, dieser Reisekrieger, jede Woche reist du zum Kunden, um deine Arbeit zu erledigen, reist du zurück und das machst du nächste Woche wieder, und das machst du Monat für Monat. Adaptavist kam zu Adaptavist und war in der Vergangenheit immer ein Unternehmen für Fernberatung. Vor fünf Jahren war es so, wow, wir gingen zu Kunden und sagten: „Okay, du musst das machen.“ Und wir sagten: „Ja, das können wir liefern. Und nein, das müssen wir nicht, weißt du. Wir kommen vielleicht rein und machen einen Besuch vor Ort, um uns vorzustellen, aber wir können all diese Arbeiten aus der Ferne erledigen.“ Diese Geschichte hatten wir also schon immer.

Angad Seth:

In Ordnung.

William Rojas:

Aber als COVID zuschlug und alle remote arbeiteten, erlebten wir definitiv, dass eine ganze Reihe von Unternehmen plötzlich aus der Ferne arbeiten mussten und neue Prozesse und Praktiken einführen mussten, die sie im Grunde dazu zwangen, remote zu arbeiten. Und ich denke, wir hatten gewissermaßen das Glück, dass wir schon immer...

Angad Seth:

Ja, Fernstart.

William Rojas:

... S8s.

Angad Seth:

Ja.

William Rojas:

Ich weiß, wann immer wir Leute in das Unternehmen holen, insbesondere in die Beratung, ist das eines der Dinge, auf die wir immer hinweisen. Telearbeit ist nicht dasselbe wie im Büro zu sein. Es hat seine Höhen und Tiefen. Aber diesen Vorteil hatten wir schon immer. Ich denke, wir waren in der Lage, einigen unserer Kunden zu helfen, zum Beispiel: So wird es gemacht, so machen wir es.“ Wir waren also in der Lage, einigen Kunden anhand von Beispielen etwas beizubringen.

Angad Seth:

Da hast du's.

William Rojas:

Ja.

Angad Seth:

Fantastisch. Das sollte eigentlich meine nächste Frage sein. Wie sieht die Arbeitsstruktur bei Adaptavist aus und welche Art von Prozessen? Ich bin mir sicher, dass es ein großes Unternehmen ist und es daher spezielle Tools und Prozesse für Teams an sich geben würde. Nur aus Ihrer Erfahrung, welche Prozesse oder Tools verwenden Sie?

Rizwan Hasan:

Also, was Planung und Arbeitsmanagement angeht, weil wir als Remote-First-Unternehmen angefangen haben, und seit COVID läuft das Geschäft gut. Ich bin ehrlich, es war gut für uns, weil wir uns auf diesen Markt spezialisiert haben. Wir hatten einen riesigen Einstellungsschub in all diesen verschiedenen Bereichen, und eine Sache ist mir intern aufgefallen, sowie Probleme, die... Ich würde nicht von Problemen sprechen, aber ein Trend, den wir bei vielen anderen Kunden beobachten, ist, dass aufgrund dieses Remote-Push und der Notwendigkeit, dass ein Unternehmen in der Lage sein muss, den Teams die Tools zur Verfügung zu stellen, die sie für ihre Arbeit benötigen, viel flexibler ist, was Vor- und Nachteile hat.

Auf der positiven Seite gibt es Flexibilität, die Teams können so arbeiten, wie sie wollen. Auf der anderen Seite könnte die Verwaltung schwierig sein, die Abstimmung könnte schwierig sein. Das erleben wir also häufig bei unseren und unseren Kunden. Wir gehen also fast auf diese Reise mit Kunden, während wir uns selbst skalieren und lernen, wie wir mit dieser neuen Realität des Arbeitens in einer hybriden Umgebung umgehen können.

William Rojas:

Ich denke, in Bezug auf einige der Werkzeuge usw., die wir tun können. Intern haben wir also, wir sind ziemlich, ziemlich genau bei Atlassian. Atlassian Stack, genau so arbeiten wir jeden Tag. Bei all unserer Arbeit verwenden wir Atlassian-Tools. Unsere gesamte Arbeit wird getrackt, die gesamte Arbeit unserer Kunden wird in JIRA verfolgt, unsere gesamte Vertriebsarbeit, im Grunde alles, was wir tun, wir verwenden JIRA und Confluence, wir sind wirklich begeistert von Confluence. Wir haben im Laufe der Jahre viele Anpassungen an unserer Instanz vorgenommen, Dinge, die wir gerade entwickelt haben, und das ist intern.

Ich denke, der andere Aspekt ist oft, dass je nach dem Kunden, der zu uns kommt, und der Art der Arbeit, die wir für diesen Kunden erledigen, die Arten von Tools, die wir verwenden, so ziemlich die gesamte Bandbreite abdecken können. Wir haben viele Atlassianer, wir arbeiten viel in JIRA mit unseren Kunden, zum Beispiel in Confluence. Manchmal arbeiten wir daran, ihnen bei der Skalierung zu helfen, also bringen wir einen Teil des Add-ons mit, um einige der Skalierungspraktiken zur Unterstützung von JIRA zu unterstützen. Wir werden viel JSM-Arbeit machen. Wir arbeiten oft an DevOps, und dann bringen wir viele der DevOps-Toolsets hinzu, die Sie erwarten würden, also Dinge zur Unterstützung von Bereitstellungspipelines.

Es hängt also wirklich ziemlich stark vom Kunden ab. Wir führen sogar einige agile Transformationsarbeiten durch. Und dann machen wir eine Menge maßgeschneiderter Dinge, Praktiken und so weiter. Und wir bieten Umfragen und Tools an, die wir im Laufe der Jahre entwickelt haben, um dies besonders zu unterstützen. Viele der Tools werden daher oft von den Anforderungen des Kunden und des spezifischen Engagements bestimmt.

Angad Seth:

Nach meiner persönlichen Erfahrung mit COVID in letzter Zeit nehme ich an vielen Besprechungen teil, mit denen wir experimentieren, mit der asynchronen Entscheidungsfindung. Haben Sie schon mit asynchronen Entscheidungsprozessen experimentiert?

Rizwan Hasan:

Ich fange damit an, dass ich Treffen hasse. Ich denke, die meisten Besprechungen sind Zeitverschwendung, und das sage ich meinem Team. Und ich sage: „Wenn wir uns nicht treffen müssen, werden wir uns quasi nicht treffen.“

Angad Seth:

Ja. Fantastisch.

Rizwan Hasan:

Und ich denke, das kommt wirklich. Ja, großartig, auf jeden Fall. Fantastisch.

Angad Seth:

Ich liebe es.

Rizwan Hasan:

Aber es kommt wirklich darauf an, wann Sie sich treffen, führen Sie das richtige Gespräch? Und ich denke, eine Schlüsselkomponente in einem agilen Team, ohne Zitat, ist, dass man ein Verständnis dafür hat, was wir alle gemeinsam tun und was die Prioritäten sind. Was eigentlich schwer zu bekommen ist. Wenn wir also über asynchrone Entscheidungsfindung mit einem Team sprechen, das ein gewisses Maß an Verständnis dafür hat, was Prioritäten und Ziele sind, wird es einfacher. Und Sie können mehr Interaktionen mit Menschen mit geringer Auswirkung haben.

Wir verwenden Slack also viel und wir haben viele interne Bots in unserem Slack, um zu asynchronen Zeiten Informationen präsentieren und Feedback sammeln zu können, weil es Abstimmungsfunktionen gibt, es gibt Orte, an denen du Kommentare abgeben kannst. Und ich denke, wenn wir über Teams sprechen, die auf der ganzen Welt wachsen, und auch über Zeitzonen und flexibles Arbeiten, ist das jetzt Realität. Es gibt eine praktische Methode, wie das geht. Wir fangen an, uns damit zu beschäftigen, wie das aussieht?

Angad Seth:

Befindest du dich in einer Million Slack-Gruppen?

Rizwan Hasan:

Jep.

Angad Seth:

Jep. Das tust du. Siehst du irgendwelche zusätzlichen Hürden, die du deswegen überspringen musst? Weil du vielleicht, springst du von Konversation zu Konversation, während es einfach einfacher wäre, wenn alle an derselben Konversation teilnehmen würden? Passiert das ein bisschen?

Rizwan Hasan:

Ja. Ja. Die ganze Zeit.

Angad Seth:

Ich verstehe dich, ja, da hast du's. In Ordnung. Cool.

William Rojas:

Aber ich würde sagen, wir haben viel Spontanes. Ich denke, wir haben viele spontane Treffen. Und manchmal tippen wir vielleicht in einem Slack. Da steht, weißt du was? [Crosstalk 00:17:29]

Angad Seth:

Spring einfach in eine Gruppe.

William Rojas:

In Zoom und dann lass uns chatten oder eine Slack-Konversation führen, und dann einfach von Angesicht zu Angesicht, und dann sprechen wir es einfach ab und zu an an an. Aber ich glaube, wir haben, es ist fast so, als ob ich denke, ein Gleichgewicht zwischen der für das Meeting aufgewendeten Zeit und der Anzahl der Personen, die an dem Meeting teilnehmen müssen, und dem Nutzen und Wert, der sich aus dem Meeting ergibt, gesucht. Und bei einem täglichen Meeting, bei dem es um Arbeit ging, nahmen die Leute die Arbeit oder den Support aus Vertriebssicht wieder auf. Und das war sehr, sehr notwendig, da ein Teil der Arbeit, die in die Beratungspipeline aufgenommen wurde. Aber es fühlte sich sehr ineffizient an.

Das ist zum Beispiel eines der Mittel, auf das wir verzichtet haben, und es ist jetzt ein völlig asynchroner Prozess, bei dem Arbeit reinkommt und sie zugewiesen wird, die Leute sie abholen, die Leute sie unterstützen, wir liefern Dinge, wir verfolgen, wo sich die Dinge befinden und so weiter. Und jetzt nutzen wir all das, was im Grunde alles über Slack erledigt wird. Also haben wir die ganzen Besprechungen abgeschafft, in denen es um „Hey, wer kann mir dabei helfen?“ Aber in der Zwischenzeit haben wir ein weiteres Meeting, bei dem wir versuchen, Leute für Projekte zu gewinnen. Und das ist sehr wichtig, darüber müssen wir oft verhandeln. Das ist also ein Treffen, das immer noch sehr abgeschlossen ist.

Angad Seth:

Jep.

William Rojas:

Jeder kommt rein, wir reden alle, wir entscheiden, was wir erledigen müssen. Die Leute balancieren hin und her. Ich denke, dieser Kompromiss ist wirklich wichtig, um wirklich zu verstehen, was das ist. Es gibt Treffen, die notwendig und sehr wertvoll sind, und sie sollten auch so bleiben. Und es gibt solche, bei denen Slack wirklich ein viel besserer Mechanismus ist, um solche Entscheidungen treffen zu können

Angad Seth:

Ja. Ja, stimmt. Ja. Und macht es gut, tut mir leid, erstens entschuldigen Sie den Ortswechsel. Ich sitze jetzt direkt neben dem Router, also hoffentlich hält das iPhone. Über was für eine Skala sprechen wir hier in deinem Slack? Der Grund, warum ich frage, ist, dass es bei größeren Organisationen schwieriger sein kann, zu skalieren. Deshalb versuche ich nur, einen Eindruck davon zu bekommen, in welcher Größenordnung sich Ihr Slack befindet.

Rizwan Hasan:

Also haben wir gerade erreicht, wir sind knapp über der 500-Marke, das wäre in Bezug auf die Mitarbeiter. Im Grunde genommen unser General, der, glaube ich, nicht universell zu sein scheint, aber der Standard in jeder Organisation, bei der Slack allgemein der beste Indikator dafür ist, wie viele Personen Sie angemeldet haben. Wir sind also gerade bei der 500er-Marke, was meiner Meinung nach wahrscheinlich ungefähr mittelgroß ist, aber es kommt definitiv zu dem Punkt, an dem wir anfangen zu sehen, es ist fast ein bisschen zu viel, um Informationen zu verbreiten, ihre Informationen zu finden usw.

Wir sind tatsächlich auch Partner von Slack. Deshalb arbeiten wir bei einigen Gelegenheiten ziemlich eng mit ihnen zusammen. [Crosstalk 00:20:39] Ja, genau. Und wir beginnen, mit Kunden auch über dasselbe Problem zu sprechen, darüber, wie viel zu viel ist, und wann beginnt man, Gemeinschaften um Menschen herum zu bilden, die den gleichen Mehrwert bieten. Diese Konversationen sind also besser aufeinander abgestimmt und es gibt nicht einfach eine Menge Geschwätz und die Leute sind verwirrt, etwa wenn sie Slack lesen und sagen: „Oh, ist das jetzt die Priorität? Oder soll ich das machen oder mich im Prozess ändern?“ Diese Kommunikation ist jetzt, glaube ich, wirklich schwieriger. Und ich glaube, hier haben viele Leute, die in diese abgelegene Umgebung ziehen, Probleme mit der Kommunikation, die Abstimmung.

Angad Seth:

Ja. Ja, stimmt.

William Rojas:

Und es ist, ich würde sagen, ziemlich organisch, wie unsere Kanalverbreitung. Ich denke, selbst für Unternehmen unserer Größe sind wir ziemlich unentschlossen, was die Verbreitung von Kanälen angeht, wer sie erstellen darf, wofür sie sind und so weiter. Aber dann gibt es die Flexibilität, je nach deinen Interessen oder dem Kontext dessen, worüber du kommunizieren möchtest, zu entscheiden, ob du entweder einem Kanal beitreten kannst, der ihn unterstützt, oder einen Kanal einrichten, falls nötig, um ihn zu unterstützen. In diesem Sinne ist es also ziemlich organisch. Aber es stimmt, dass es Hunderte, wenn nicht Tausende von Slack-Kanälen gibt, die wir haben, und es ist definitiv eine unserer größten Herausforderungen, zu wissen, auf welchem du sein solltest.

Angad Seth:

Ja. Ja, das ist einfach umwerfend, nur weil 500 Leute auf einem Slack sind. Unsere gesamte Firma besteht aus 35 Leuten und ich raufe mir die Haare, wenn ich in zu vielen Slacks bin. Also, A, das ist umwerfend.

William Rojas:

Es ermöglicht uns beispielsweise, kundenspezifische Slack-Kanäle zu haben. Also für jeden, wenn du darüber sprechen musst, ob du an einem bestimmten Account arbeitest, dass du für einen Kunden arbeitest, dann gibt es dafür einen Kanal. Und wenn du für einen anderen Kunden arbeitest, gibt es einen anderen Kanal. Das, was ich daran hilfreich finde, ist, dass es dir den Kontext gibt, wenn ich mit so oder so kommunizieren möchte, wenn ich mit Riz über einen bestimmten Account kommuniziere, gehe ich zum Account-Channel. Wenn ich persönlich mit Riz sprechen möchte, gehe ich zu einem Einzelchat.

Angad Seth:

Ich verstehe, ja, die Flexibilität.

William Rojas:

Wir haben also den Vorteil, wo die Informationen platziert werden sollen. Aber das bedeutet, dass ich wahrscheinlich über hundert Kanäle in meiner Liste von Dingen habe, denen ich folge, und ich hinke immer hinterher.

Angad Seth:

Ja.

William Rojas:

Nun ja. Also, die nächste Stufe ist, dann beginnen Sie zu priorisieren, über welche Kanäle ich wirklich informiert werden sollte und welche am wichtigsten sind. Ich möchte diese verfolgen. Und ich versuche, diese Liste auf ein Minimum zu beschränken, was ungelesene Nachrichten und die Dinge angeht, an die ich rankomme, und mir ist langweilig und ich habe nichts anderes zu tun, aber ja.

Rizwan Hasan:

Ich habe auch viele Kanäle verlassen. Ich habe gerade bei einigen Kanälen wirklich das Kabel durchtrennt. Weißt du, ich hatte eine gewisse Motivation, hier wirklich zu helfen, aber ich kann einfach nicht und es ist einfach zu laut. Und ich muss nur das Kabel durchtrennen und sagen, wenn es leer ist, findet kein Gespräch statt oder wenn es langsam ist, dann mach weiter.

Angad Seth:

Jep.

William Rojas:

Wir haben auch die Möglichkeit, Sie können wieder hinzugefügt werden. Manchmal gehst du und dann setzt dich jemand wieder rein und sagt: „Du musst darüber reden.“ Aber es ist ziemlich organisch. Ich weiß, dass wir es dem Einzelnen überlassen, zu entscheiden, wie wir das am besten handhaben.

Rizwan Hasan:

Ja.

Angad Seth:

Das ist großartig.

Rizwan Hasan:

Wir hatten heute tatsächlich einen Fall, in dem es eine alte gab, es war im Grunde eine Verkaufschance, ein Kunde, der sich wegen einer bestimmten Anfrage an uns gewandt hatte, und wir hatten monatelang nichts von ihm gehört, etwa acht bis neun Monate. Und jemand hat gepostet, jemand, mit dem ich in unserem Vertriebsteam ziemlich eng befreundet bin, hat gepostet: „Hey, das geht wieder los, aber ich habe nicht die Kapazität.“ Und ich bin sofort gegangen, als ich die Nachricht gesehen habe. Ich sagte: „Ich kann nicht helfen. Es tut mir leid.“

Angad Seth:

Ja. Der alte So und so, der die Gruppe verlassen hat, ist ein bisschen wie ein Stich ins Herz, aber ja.

Rizwan Hasan:

Ja.

Angad Seth:

Wir werden darüber hinwegkommen. Um auf einen Punkt zurückzukommen, den du erwähnt hast, Riz. Du sagtest, du hast die Worte Ausrichtung und Kommunikation benutzt. Sie beide, wenn Sie mit Kunden beraten, sind das die beiden Hauptthemen, auf die Sie Ihre Empfehlungen gerne stützen?

Rizwan Hasan:

Ich gebe Ihnen eine sehr beratende Antwort und sage, es kommt darauf an.

Angad Seth:

Ja.

Rizwan Hasan:

Aber wenn wir mit einem Kunden in Kontakt treten, ist es eine der schwierigsten Aufgaben unserer Arbeit, zu verstehen, ob die Gruppe der Personen, mit denen wir sprechen, überhaupt übereinstimmt, denn bei der Größenordnung der Projekte, mit denen wir manchmal zusammenarbeiten, haben wir etwa 20 bis 25 Personen, die an einem Telefongespräch teilnehmen. Und von all diesen Menschen haben möglicherweise unterschiedliche Motivationen oder Ziele, was sie mit ihrer Zusammenarbeit mit uns erreichen wollen. Ich würde also sagen, das ist in erster Linie der Grund für das, was wir herausfinden wollen, was wir mit ihnen zu tun versuchen, ist eine gewisse Übereinstimmung zwischen der Gruppe und uns selbst herzustellen, und das zu kommunizieren ist nicht immer einfach.

Angad Seth:

Ja.

William Rojas:

Nehmen wir an, Riz hinzuzufügen, das hängt auch ziemlich stark von der spezifischen Interaktion mit diesem Kunden ab. Also insbesondere, wenn es um das Engagement geht, denn wenn ein Engagement wie „Bring mich in die Cloud“ lautet. In Ordnung. Weißt du, komm rein. Oft gibt es für so etwas eine viel bessere Abstimmung. Wenn es bei den Engagements eher darum geht: „Hey, hilf uns, agil zu skalieren, hilf uns, unsere Ergebnisse besser zu machen.“ Dann ist die Notwendigkeit der Abstimmung, die Notwendigkeit, sicherzustellen, dass wir alle richtig kommunizieren, wir alle verstehen, dass wir alle mit den gleichen Zielen zu dem Meeting kommen und so weiter, viel wichtiger.

Angad Seth:

Ja.

William Rojas:

Bei solchen Engagements richten wir uns also ständig neu aus. Weil es nicht einmal so ist, als hätten wir die Abstimmung gehabt. Es ist wie ja. In Ordnung. Wir haben es, nächste Woche ist es weg. Wir müssen zurückgehen und es uns wieder holen. Das Festhalten, Sicherstellen, dass alle auf die gleichen Ziele zusteuern, diese Ziele definieren, sie sich entsprechend weiterentwickeln lassen und so weiter, all das wird um so viel wichtiger.

Angad Seth:

Ja.

William Rojas:

Und da sind die Tools, da sind Dinge wie JIRA und dann wieder, wie skalieren wir? Wie zeigen wir, was alle tun? Und so weiter, das ist der Punkt, an dem es um so viel wichtiger wird. Und bei solchen Einsätzen werden die Werkzeuge unverzichtbar. Nicht, dass die Tools diese Frage beantworten würden, aber die Werkzeuge werden zu einer Art und Weise, wie sie uns bei der Kommunikation helfen, ja. Wir sind uns alle einig, dass wir das tun werden. In Ordnung. Das Tool sagt das, weil das die Entscheidung ist, die wir getroffen haben.

Angad Seth:

Ja.

Rizwan Hasan:

Es ist wirklich interessant, dass du Cloud-Migration sagst, William, wenn du sagst: „Okay, ich gehe zur Cloud, wir wissen, wie die Ausrichtung ist“, aber selbst dann stelle ich fest, dass, besonders innerhalb des Atlassian-Ökosystems, dem wir ständig ausgesetzt sind, aber wenn wir Daten von einer komplett alten Infrastruktur auf etwas ganz Neues verschieben, wird das nicht dasselbe sein. Und es gibt Leute, die denken: „Oh, wir nehmen einfach all das Zeug von hier und stellen es da drüben hin.“ Aber was normalerweise nicht damit einhergeht, ist, dass Sie auch Ihre Arbeitsweise leicht ändern müssen. Es wird Änderungen geben, die Sie nicht berücksichtigen.

Und hier ist das Gespräch über die Ausrichtung wirklich wichtig, denn wir arbeiten mit kleinen Unternehmen zusammen, die verstehen, okay, der Umstieg auf die Cloud wird völlig anders sein. Wir arbeiten auch mit älteren Organisationen wie Finanzinstituten zusammen, die eine Menge Bürokratie, Prozess- und Sicherheitsbedenken haben, und zuerst diese Abstimmung und das Verständnis dafür zu bekommen, was es bedeutet, zu einer völlig anderen Arbeitsweise überzugehen, ist ebenfalls Teil dieses Gesprächs. Es ist also ein ständiges Hin und Her damit.

Angad Seth:

Ja, ja. Es ist wirklich herzerwärmend zu hören, dass Sie beide sich mit der JCMA befassen, dem Geo-Cloud-Migrationssystem.

Rizwan Hasan:

Ziemlich viel, ja.

Angad Seth:

Das ist großartig, denn ja, daran arbeiten wir derzeit auch. Also werde ich mit einer superschwierigen Frage enden und ich fordere euch auf, das Wort hängt da drin nicht zu benutzen. Und die Frage ist der wichtigste Ratschlag für Remote-Teams, die Agile praktizieren. Fangen Sie mit Ihnen an, Riz.

Rizwan Hasan:

Lernen Sie sich kennen.

Angad Seth:

Ja, okay.

Rizwan Hasan:

Halte es persönlich. Ich denke, eines der schwierigsten Dinge an dieser neuen Realität ist, diese Verbindung zu jemandem herzustellen, und wenn man das hat, baut das Vertrauen auf, und wenn man Vertrauen hat, ist alles viel einfacher. Also ich würde das sagen. Die Leute sind wirklich nicht... Der Feind. Das ist nicht das richtige Wort, aber Arbeit sollte kein Konflikt sein. Es sollte eher wie eine Verhandlung sein, und wenn Sie sich gegenseitig vertrauen, ist das viel einfacher.

Angad Seth:

Ja.

Rizwan Hasan:

Also ja.

Angad Seth:

Das ist großartig.

William Rojas:

Das ist es wirklich.

Angad Seth:

Das werde ich auf jeden Fall wieder mitnehmen.

William Rojas:

Ja. Und nur, wenn ich das schnell ergänzen könnte. Das ist, als würde man nach Wegen suchen, wie man das Herumstehen neben dem, das Trinken einer Tasse Kaffee ersetzen kann. Wie ersetzt man das in einer Remote-Umgebung?

Rizwan Hasan:

Ja.

Angad Seth:

Ja.

William Rojas:

Wie kann man immer noch diese persönliche Interaktion haben, dass vielleicht ein elektronisches Medium dazwischen liegt, aber es gibt immer noch eine Art persönliche Umgebung. Ich denke, das ist eines der Dinge, nach denen du suchst. Denn ja, es geht vor allem um Vertrauen. Und ich denke, dazu würde ich auch noch hinzufügen, zurück zur Ausrichtung. Richtig? Denn in gewisser Weise hilft diese starke Interaktion dabei, die Ausrichtung aufzubauen und aufrechtzuerhalten, denn oft geht es nicht so sehr darum, dass man sich ausrichtet, sondern dass man ausgerichtet bleibt.

Es ist also diese Konstante, und diese Interaktionen, dieses Vertrauen usw. zu haben, ermöglicht es uns gewissermaßen, auf dem Laufenden zu bleiben. Weil wir uns kennen, wir wissen, wie wir uns gegenseitig helfen können, wir unterstützen uns gegenseitig, sodass wir in Einklang bleiben. Das Vertrauen und so weiter sind also eine gute Möglichkeit, um die Ausrichtung selbst aufzubauen und aufrechtzuerhalten, nach der Sie suchen. Das ist absolut. In einer abgelegenen Welt hat man nicht den Vorteil, sich zu sehen, auf dem Whiteboard, all diese Dinge sind nicht gleich.

Angad Seth:

Sehr wahr. Eine Tasse Kaffee holen, ja.

William Rojas:

Aber wir müssen immer noch auf dem Laufenden bleiben, was getan werden muss. Das ist so wichtig.

Angad Seth:

Sehr wahr. Würdet ihr also irgendwelche Namen von Tools, die ihr verwendet, um das Vertrauen zwischen Teammitgliedern in einer Remote-Umgebung zu stärken, veröffentlichen wollen?

William Rojas:

Ich würde also sagen, wie ich in meiner Rolle bereits erwähnt habe, dass wir unter anderem im Presales-Bereich tätig sind. Wir betreuen einige unserer größeren Kunden, fast so etwas wie ein Solution Account Manager an sich. Also kommen wir rein und helfen sicherzustellen, dass der Kunde die Lösung erhält, die geliefert werden soll. Wir arbeiten also mit den Lieferteams zusammen, wir arbeiten mit dem Kunden zusammen, wir sitzen dazwischen.

Es gibt einen großen Kunden, an dem wir seit Jahren arbeiten, und wir sind im Grunde genommen so weit, dass sie sich in Richtung eines sicheren Zustands bewegen. Das würde ich nicht als absolut sicher bezeichnen, aber sie haben eine Menge sicherer Praktiken, aber sie machen PI-Planung, und so kommen wir rein und nehmen an der PI-Planung teil. Das ist eigentlich eine der Fragen, wie ich schon sagte, wie bleibt man am Leben?

Angad Seth:

Dieser Kreis. Ja. [Crosstalk 00:33:15]

William Rojas:

Sie rufen Ihre Programmdefinition auf, schauen sich an, welche Funktionen Sie im PI bereitstellen möchten, wer diese Funktion im PI bereitstellen wird, und dann gehen Sie in Ihrer Anzeige zurück zum Tool und sagen: „Schau, darauf haben wir uns geeinigt.“ Andere können Fragen stellen und so weiter und kommen ständig zurück zu... Zum Beispiel haben wir gerade letzte Woche den Sprint geplant und gesagt: „Okay, dieses Feature wird einen weiteren Sprint in die Länge ziehen. Lassen Sie mich zurückgehen und mich neu anpassen. „Dieser Kunde verwendet die Easy Agile-Programme. Der ursprüngliche Plan, diese Funktionen nicht einzuführen, sieht zum Beispiel nicht zwei Sprints vor, sondern stattdessen die drei Sprints.

Also diese Angewohnheit, das Tool zu verwenden, um mitzuteilen, was wir beschlossen haben und woran wir nur Änderungen vornehmen mussten. Es wird also zu einem Kommunikationsmittel, es ist wirklich wichtig. Ja, sie verwenden Programme, sie verwenden die Roadmap-Programme, um ihnen bei der PI-Planung zu helfen und auf dem Laufenden zu bleiben, was letztendlich am Ende von PI kommuniziert wird. Und dann während der Sprints des PI selbst, und das ist sehr hilfreich für sie. Auch hier gibt es, glaube ich, sieben Schulungen, und sie alle nutzen das, um synchron zu bleiben, aufeinander abgestimmt zu bleiben.

Angad Seth:

Fantastisch. Fantastisch.

William Rojas:

Eine weitere schnelle Sache, die ich sagen möchte, ist, ich denke, es wird einiges von dem, was wir gegangen sind, jetzt zum Status Quo, zum Dauerzustand werden. Ich denke, das war ein Wandel auf dem Markt, in der gesamten Branche, im gesamten Unternehmen, in der Art und Weise, wie Menschen arbeiten. Also die Idee der Telearbeit, die Idee, Tools zu verwenden, um die Kommunikation wirklich aufzubauen und die Kommunikation zu erleichtern, all das, obwohl es das schon gab, denke ich, der große Unterschied liegt jetzt bei allen, als ob man keine Wahl hat. Jeder muss es tun.

Angad Seth:

Muss. Ja.

William Rojas:

Und ich denke, wir haben aus diesem Grund definitiv einen großen Wandel in der gesamten Branche erlebt. Das wird sich jetzt verfestigen und mal sehen, was das nächste Level bringt. Aber ich denke auf jeden Fall, dass wir auf globaler Ebene ein neues Reifegrad erreicht haben und so weiter, was ziemlich cool ist.

Angad Seth:

Ja.

Rizwan Hasan:

Ja.

Angad Seth:

Ja, ist es. Danke Leute. Ich werde dich nicht zu lange behalten. Ich glaube, ist die Sonne dort untergegangen, Riz? Ich sehe, wie das Spiegelbild dunkel wird.

Rizwan Hasan:

Ja. Es ist auf dem Weg dorthin. Ja, ganz sicher.

Angad Seth:

Ja. Ja. Ich werde euch nicht zu lange festhalten.

Rizwan Hasan:

Alles gut.

Angad Seth:

Aber vielen Dank für das Gespräch. Ehrlich gesagt habe ich viel davon mitgenommen. Und ja, ich hoffe, ich kann euch zu meinem LinkedIn hinzufügen. Ich würde immer noch gerne in Kontakt bleiben.

William Rojas:

Auf jeden Fall.

Rizwan Hasan:

Ja, sicher.

Angad Seth:

Ja. Ich versuche einen Ansprechpartner zu finden, nicht um einen deiner Slack-Kanäle hinzuzufügen, aber ja. Nur damit wir über das Produkt sprechen und es verbessern können.

Rizwan Hasan:

Ja, sicher. Und wir haben einen Partnermanagement-Kanal. Ich weiß, wir haben ein bisschen mit Haley gesprochen.

Angad Seth:

Fantastisch.

Rizwan Hasan:

Sie hat Kontakt aufgenommen, es geht um ein paar andere Dinge.

Angad Seth:

Wunderschön.

Rizwan Hasan:

Ja, gerne. Wir beschäftigen uns mit Ihrem Produkt und es steht auch in unseren Whitepapers, und wir werden dieses Jahr ein weiteres Whitepaper veröffentlichen, in dem wir auch über Easy Agile sprechen werden. Also ja. Wir bleiben in Kontakt.

Angad Seth:

Cool.

William Rojas:

Ich habe es dir gerade gegeben, also ist mein LinkedIn unter einem anderen, mein LinkedIn ist nicht mit meiner Arbeits-E-Mail. Weil ich auf diese Weise das gleiche Konto von Ort zu Ort behalten kann.

Angad Seth:

Hört sich gut an.

William Rojas:

Ja. Damit kannst du mich auf LinkedIn nachschlagen.

Angad Seth:

Verdammt geil. Danke Leute.

William Rojas:

Fantastisch. Alles klar.

Angad Seth:

Hab einen schönen Tag.

In this insightful episode, we dive deep into one of the most common frustrations in engineering and dev teams: retrospectives that fail to drive meaningful change. Join Jaclyn Smith, Senior Product Manager at Easy Agile, and Shane Raubenheimer, Agile Technical Consultant at Adaptavist, as they unpack why retrospectives often become checkbox exercises and share practical strategies for transforming them into powerful engines of continuous improvement.

Want to put these insights into practice? Join Jaclyn and Shane for their live, hands-on webinar on July 10th where they'll show you exactly how to transform your retrospectives with practical tools and techniques you can implement immediately.

Key topics covered:

• Common retrospective anti-patterns and why teams become disengaged
• The critical importance of treating action items as "first-class citizens"
• How to surface recurring themes and environmental issues beyond team control
• Practical strategies for breaking down overwhelming improvement initiatives
• The need for leadership buy-in and organizational support for retrospective outcomes
• Moving from "doing agile" to "being agile" through effective reflection and action

This conversation is packed with insights for making your retrospectives more impactful and driving real organizational change.

About our guests

Jaclyn Smith is a Senior Product Manager at Easy Agile, where she leads the Easy Agile TeamRhythm product that helps teams realize the full benefits of their practices. With over five years of experience as both an in-house and consulting agile coach, Jaclyn has worked across diverse industries helping teams improve their ways of working. At Easy Agile, she focuses on empowering teams to break down work effectively, estimate accurately, and most importantly, take meaningful action to continuously improve their delivery and collaboration.

Shane Raubenheimer is an Agile Technical Consultant at Adaptavist, a global family of companies that combines teamwork, technology, and processes to help businesses excel. Adaptavist specializes in agile consulting, helping organizations deliver customer value through agile health checks, coaching, assessments, and implementing agile at scale. Shane brings extensive experience working across multiple industries—from petrochemical to IT, digital television, and food industries—applying agile philosophy to solve complex organizational challenges. His expertise spans both the technical and cultural aspects of agile transformation.

Transcript

This transcript has been lightly edited for clarity and readability while maintaining the authentic conversation flow.

Opening and introductions

Jaclyn Smith: Hi everyone, and welcome back to the Easy Agile Podcast. Today I'm talking to Shane Raubenheimer, who's with us from Adaptavist. Today we're talking about why your retrospectives keep failing and how to finally fix them. Shane, you and I have spent a fair amount of time together exploring the topic of retros, haven't we? Do you want to tell us a little bit about yourself first?

Shane Raubenheimer: Yeah, hello everyone. I'm Shane Raubenheimer from Adaptavist. I am an agile coach and technical consultant, and along with Jaclyn, we've had loads of conversations around why retros don't work and how they just become tick-box exercises. Hopefully we're going to demystify some of that today.

Jaclyn Smith: Excellent. What's your background, Shane? What kind of companies have you worked with?

Shane Raubenheimer: I've been privileged enough to work across multiple industries—everything from petrochemical to IT, to digital television, food industry. All different types of applied work, but with the agile philosophy.

Jaclyn Smith: Excellent, a big broad range. I should introduce myself as well. My name is Jaclyn. I am a Senior Product Manager here at Easy Agile, and I look after our Team Rhythm product, which helps teams realize the benefits of being agile. I stumbled there because our whole purpose at Easy Agile is to enable our customers to realize the benefits of being agile.

My product focuses on team and teamwork, and teamwork happens at every level as we know. So helping our customers break down work and estimate work, reflect—which is what we're talking about today—and most importantly, take action to improve their ways of working. I am an agile coach by trade as well as a product manager, and spent about five years in a heap of different industries, both as a consultant like you Shane, and as an in-house coach as well.

The core problem: When retrospectives become checkbox exercises

Jaclyn Smith: All right, let's jump in. My first question for you Shane—I hear a lot that teams get a bit bored with retros, or they face recurring issues in their retrospectives. Is that your experience? Tell me about what you've seen.

Shane Raubenheimer: Absolutely. I think often what should be a positive rollup and action of a sequence of work turns out to normally become a checkbox exercise. There's a lot of latency in the things that get uncovered and discussed, and they just tend to perpetually roll over. It almost becomes a checkbox exercise from what I've seen, rather than the mechanism to actively change what is happening within the team—but more importantly, from influences outside the team.

I think that's where retros fail, because often the team does not have the capability to do any kind of upward or downstream problem solving. They tend to just mull about different ways to ease the issues within the team by pivoting the issues rather than solving them.

I think that's where retros fail, because often the team does not have the capability to do any kind of upward or downstream problem solving. They tend to just mull about different ways to ease the issues within the team by pivoting the issues rather than solving them.

Jaclyn Smith: Yeah, I would agree. Something that I see regularly too is because they become that checkbox, teams get really bored of them. They do them because they're part of their sprint, part of their work, but they're not engaged in them anymore. It's just this thing that they have to do.

It also can promote a tendency to just look at what's recently happened and within their sphere of influence to solve. Whereas I think a lot of the issues that sometimes pop up are things that leadership need to help teams resolve, or they need help to solve. It can end up with them really focusing on "Oh well, there's this one bit in how we do our code reviews, we've got control over that, we'll try to fix that." Or as you say, the same recurring issues come up and they don't seem to get fixed—they're just the same complaints every time.

Shane Raubenheimer: Absolutely. You find ways that you put a band-aid on them just so you can get through to the next phase. I think the problem with that is the impact that broader issues have on teams is never completely solvable within that space, and it's no one else's mandate necessarily to do it. When an issue is relatable to a team, exposing why it's not a team-specific issue and it's more environmental or potentially process-driven—that's the bit that I feel keeps getting missed.

When an issue is relatable to a team, exposing why it's not a team-specific issue and it's more environmental or potentially process-driven—that's the bit that I feel keeps getting missed.

The pressure problem and overwhelming solutions

Jaclyn Smith: Yeah, I think so too. The other thing you just sparked for me—the recurring issue—I think that also happens when the team are under pressure and they don't feel like they have the time to solve the problems. They just need to get into the next sprint, they need to get the next bit of work done. Or maybe that thing that they need to solve is actually a larger thing—it's not something small that they can just change.

They need to rethink things like testing strategies. If that's not working for you, and it's not just about fixing a few flaky tests, but you need to re-look at how you're approaching testing—it seems overwhelming and a bit too big.

Shane Raubenheimer: Absolutely. Often environmental issues are ignored in favor of what you've been mandated to do. You almost retrofit the thing as best you can because it's an environmental issue. But finding ways to expose that as a broader-based issue—I think that should be the only output, especially if it's environmental and not team-based.

The problem of forgotten action items

Jaclyn Smith: Something I've also seen recently is that teams will come up with great ideas of things that they could do. As I said before, sometimes they're under pressure and they don't feel they have the capacity to make those changes. Sometimes those actions get talked about, everyone thinks it's a wonderful idea, and then they just get forgotten about. Teams end up with this big long backlog of wonderful experiments and things that they could have tried that have just been out of sight, out of mind. Have you seen much of that yourself?

Shane Raubenheimer: Plenty. Yes, and often teams err on the side of what's expected of them rather than innovate or optimize. I think that's really where explaining the retrospective concept to people outside fully-stacked or insular teams is the point here. You need, very much like in change management, somebody outside the constructs of teams to almost champion that directive—the same way as you would do lobbying for money or transformation. It needs to be taken more seriously and incorporated into not just teams being mini-factories supporting a whole.

You transform at a company level, you change-manage at a company level. So you should action retrospective influences in the same way. Naturally you get team-level ones, and that's normally where retrospectives do go well because it's the art of the possible and what you're mandated to do. I think bridging the gap between what we can fix ourselves and who can help us expose it is a big thing.

I see so much great work going to waste because it simply isn't part of the day job, or should be but isn't.

You transform at a company level, you change-manage at a company level. So you should action retrospective influences in the same way.

Making action items first-class citizens

Jaclyn Smith: Yeah, absolutely. I know particularly in the pre-Covid times when we were doing a lot of retros in person, or mostly in person with stickies on walls, I also found even if we took a snapshot of the action column, it would still end up on a Confluence board or something somewhere and get forgotten about. Then the next retro comes around and you sort of feel like you're starting fresh and just looking at the last sprint again. You're like, "Oh yeah, someone raised that last retro, but we still didn't do anything about that."

Shane Raubenheimer: I think Product Owners, Scrum Masters, or any versions of those kinds of roles need to treat environmental change or anti-pattern change as seriously as they treat grooming work—the actual work itself. Because it doesn't matter how good you are if the impediments that are outside of your control are not managed or treated with the same kind of importance as the actual work you're doing. That'll never change, it'll just perpetuate. Sooner or later you hit critical mass. There's no scenario where your predictability or velocity gets better if these things are inherent to an environment you can't control.

Product Owners, Scrum Masters, or any versions of those kinds of roles need to treat environmental change or anti-pattern change as seriously as they treat grooming work—the actual work itself.

Jaclyn Smith: Yeah, that's true. We've talked about action items being first-class citizens and how we help teams do that for that exact reason. Because a retro is helpful to build relationships and empathy amongst the team for what's happening for each of them and feel a sense of community within their team. But the real change comes from these incremental changes that are made—the conversations that spark the important things to do to make those changes to improve how the team works.

That action component is really the critical part, or maybe one of two critical parts of a retro. I feel like sometimes it's the forgotten child of the retro. Everyone focuses a lot on engaging people in getting their ideas out, and there's not as much time spent on the action items and what's going to be done or changed as a result.

Beyond team-level retrospectives

Shane Raubenheimer: Absolutely, consistently. I think it's symptomatic potentially of how retros are perceived. They're perceived as an inward-facing, insular reevaluation of what a team is doing. But I've always thought, in the same way you have the concept of team of teams, or if you're in a scaled environment like PI planning, I feel retrospectives need the same treatment or need to be invited to the VIP section to become part of that.

Because retrospectives—yes, they're insular or introspective—but they need to be exposed at the same kind of level as things like managing your releases or training or QA, and they're not.

Jaclyn Smith: Yeah, I think like a lot of things, they've fallen foul of the sometimes contentious "agile" word. People tend to think, "Oh retros, it's just one of those agile ceremonies or agile things that you do." The purpose of them can get really lost in that, and how useful they can be in creating change. At the end of the day, it's about improving the business outcomes. That's why all of these things are in place—you want to improve how well you work together so that you can get to the outcome quicker.

At the end of the day, it's about improving the business outcomes. That's why all of these things are in place—you want to improve how well you work together so that you can get to the outcome quicker.

Shane Raubenheimer: Absolutely. Outcome being the operative word, not successfully deploying code or...

Jaclyn Smith: Or ticking the retro box, successfully having a retro.

Shane Raubenheimer: Yeah, exactly. Being doing agile instead of being agile, right?

Expanding the scope of retrospectives

Jaclyn Smith: One hundred percent. It also strikes me that there is still a tendency for retros to be only at a team level and only a reflection of the most recent period of time. So particularly if a team are doing Scrum or some version of Scrum with sprints, to look back over just the most recent period. I think sometimes the two things—the intent of a retro but also the prime directive of the retro—gets lost.

In terms of intent, you can run a retro about anything. Think about a post-mortem when you have an incident and everyone gets together to discuss what happened and how we prevent that in the future. I think people forget that you can have a retro and look at your system of work, and even hone in on something like "How are we estimating? Are we doing that well? Do we need to improve how we're doing that?" Take one portion of what you're working on and interrogate it.

You can run a retro about anything. I think people forget that you can have a retro and look at your system of work, and even hone in on something like "How are we estimating? Are we doing that well? Do we need to improve how we're doing that?" Take one portion of what you're working on and interrogate it.

Understanding anti-patterns

Shane Raubenheimer: Absolutely. You just default to "what looks good, what can we change, what did we do, what should we stop or start doing?" That's great and all, but without some kind of trended analysis over a period of time, you might just be resurfacing issues that have been there all along. I think that's where the concept or the lack of understanding of anti-patterns comes in, because you're measuring something that's happened again rather than measuring or quantifying why is it happening at all.

I think that's the big mistake of retros—it's almost like an iterative band-aid.

I think that's the big mistake of retros—it's almost like an iterative band-aid.

Jaclyn Smith: Yeah. Tell me a little bit more about some of the anti-patterns that you have seen or how they come into play.

Shane Raubenheimer: One of them we've just touched on—I think the buzzword for it is the cargo cult culture for agile. That's just cookie-cutting agile, doing agile because you have to instead of being agile. Literally making things like your stand-up or your review or even planning just becomes "okay, well we've got to do this, so we've ticked the box and we're following through."

Not understanding the boundaries of what your method is—whether you like playing "wagile" or whether you're waterfall sometimes, agile at other times, and you mistake that variability as your agility. But instead, you don't actually have an identity. You're course-correcting blindly based on what's proportionate to what kind of fire you've got in your way.

Another big anti-pattern is not understanding the concept of what a team culture means and why it's important to have a team goal or a working agreement for your team. Almost your internal contracting. We do it as employees, right?

I think a lot of other anti-patterns come in where something's exposed within a team process, and because it's not interrogated or cross-referenced across your broader base of teams, it's not even recognized as a symptom. It is just a static issue. For me, that's a real anti-pattern in a lot of ways—lack of directive around what to do with retrospectives externally as well as internally. That's simply not a thing.

A lot of other anti-patterns come in where something's exposed within a team process, and because it's not interrogated or cross-referenced across your broader base of teams, it's not even recognized as a symptom. It is just a static issue. For me, that's a real anti-pattern in a lot of ways—lack of directive around what to do with retrospectives externally as well as internally.

Jaclyn Smith: Yeah, I think that's a good call-out for anyone watching or listening. If you're not familiar with anti-patterns, they're common but ineffective responses to recurring problems. They may seem helpful initially to solve an immediate problem, but they ultimately lead to negative outcomes.

Shane, what you just spoke about there with retrospectives—an example of that is that the team feel disengaged with retrospectives and they're not getting anything useful out of it, or change isn't resulting from the retrospectives. So the solution is to not hold them as frequently, or to stop doing them, or not do them at different levels or at different times. That's a really good example of an anti-pattern. It does appear to fix the problem, but longer term it causes more problems than it solves.

Another one that I see is with breaking down work. The idea that spending time together to understand and gain a shared understanding of the work and the outcome that you need takes a lot of time, and breaking down that work and getting aligned on how that work is going to break down on paper can look like quite an investment. But it's also saving time at the other end, reducing risk, reducing duplication and rework to get a better outcome quicker. You shift the time spent—development contracts because you've spent a little bit more time discovering and understanding what you're doing.

A common anti-pattern that I see there is "we spent way too long looking at this, so we're going to not do discovery in the same way anymore," or "one person's going to look at that and break it down."

The budget analogy

Shane Raubenheimer: I always liken it to your budget. The retrospective is always the nice shiny holiday—it's always the first to go.

I always liken it to your budget. The retrospective is always the nice shiny holiday—it's always the first to go.

Jaclyn Smith: It's the contractor.

Shane Raubenheimer: Yeah. It's almost like exposing stuff that everybody allegedly knows to each other is almost seen as counterintuitive because "we're just talking about stuff we all know." It often gets conflated into "okay, we'll just do that in planning." But the reality is the concept of planning and how you amend what you've done in the retrospective—that's a huge anti-pattern because flattening those structures from a ceremonies perspective is what teams tend to do because of your point of "well, we're running out of daylight for doing actual development."

But it's hitting your head against the wall repeatedly and hoping for a different outcome without actually implying a different outcome. Use a different wall even. I think it's because people are so disillusioned with retrospectives. I firmly believe it's not an internal issue. I believe if the voices are being heard at a budgeting level or at a management level, it will change the whole concept of the retrospective.

Solution 1: Getting leadership buy-in

Jaclyn Smith: I like it, and that's a good thread to move on to. So what do we do about it? How do we help change this? What are some of the practical tips that people can deploy?

Shane Raubenheimer: A big practical tip—and this is going to sound like an obvious one—is actual and sincere buy-in. What I mean by that is, as a shareholder, if I am basing your performance and your effectiveness on the quality and output of the work that you're promising me, then I should be taking the issues that you're having that are repeating more seriously.

Because if you're course-correcting for five, six, or seven sprints and you're still not getting this increasing, predictable velocity, and if it's not your team size or your attitude, it's got to be something else. I often relate that to it being environmental.

Buying into the outputs for change the same way as you would into keeping everyone honest, managing budgets, and chasing deadlines—it should all be part of the same thing. They should all be sitting at the VIP table, and I think that's a big one.

Buying into the outputs for change the same way as you would into keeping everyone honest, managing budgets, and chasing deadlines—it should all be part of the same thing. They should all be sitting at the VIP table.

Solution 2: Making patterns visible

Jaclyn Smith: I think so too. Something that occurs to me, and it goes back to what we were talking about right at the beginning, is sometimes identifying that there's a pattern there and that the same thing keeps coming up isn't actually visible, and that's part of the problem, right?

I know some things we've been doing in Easy Agile TeamRhythm around that recently, attempting to help teams with this. We've recently started surfacing all incomplete action items in retrospectives so people can see that big long list. Because they can convert their action items to Jira items or work items, they can also see where they've just been sitting and languishing in the backlog forever and a day and never been planned for anything to be done about them.

We've recently started surfacing all incomplete action items in retrospectives so people can see that big long list. Because they can convert their action items to Jira items or work items, they can also see where they've just been sitting and languishing in the backlog forever and a day and never been planned for anything to be done about them.

We've added a few features to sort and that kind of thing. Coming in the future—and we've been asked about this a lot—is "what about themes? What about things that are bubbling up?" So that's definitely on our radar that will be helpful.

I think that understanding that something has been raised—a problem getting support from another team, or with a broken tool or an outdated tool that needs to be replaced in the dev tooling or something like that—if that's been popping up time and time again and you don't know about it, then even as the leader of that team, you don't have the ammunition to then say "Look, this is how much it's slowed us down."

I think we live in such a data world now. If those actions are also where the evidence is that this is what needs to change and this is where the barriers are...

Solution 3: The power of trend analysis

Shane Raubenheimer: Certainly. I agree. Touching on the trend analytics approach—we do trend analysis on everything except what isn't happening or what is actually going wrong, because we just track the fallout of said lack of application. We don't actually trend or theme, to your point.

We do trend analysis on everything except what isn't happening or what is actually going wrong, because we just track the fallout of said lack of application.

We theme everything when we plan, yet somehow we don't categorize performance issues as an example. If everybody's having a performance issue, that's the theme. We almost need to categorize or expose themes that are outward-facing, not just inward-facing. Because it's well and good saying "well, our automated testing system doesn't work"—what does that mean? Why doesn't it work?

I think it should inspire external investigation. When you do a master data cleanup, you don't just say "well, most of it looks good, let's just put it all in the new space." You literally interrogate it at its most definitive and lowest level. So why not do the same with theming and trending environmental issues that you could actually investigate, and that could become a new initiative that would be driven by a new team that didn't even know it was a thing?

Jaclyn Smith: Yeah, and you're also gathering data at that point to evidence the problem rather than "oh, it's a pain point that keeps coming up." It is, but it gives you the opportunity to quantify that pain point a little bit as well. I think that is sometimes really hard to do when you're talking about developer experience or team member experience. Even outside of product engineering teams, there are things in the employee experience that affect the ability for that delivery—whatever you're delivering—to run smoothly. You want to make that as slick as possible, and that's how you get the faster outcomes.

Solution 4: The human factor

Shane Raubenheimer: Absolutely. You can never underestimate the human factor as well. If everything I'm doing and every member of my team is doing is to the best of not just their capability, but to the best of the ability in what they have available to them, you become jaded, you become frustrated. Because if you're hitting your head against the same issue regardless of how often you're pivoting, that can be very disillusioning, especially if it's not been taken as seriously as your work output.

If everything I'm doing and every member of my team is doing is to the best of not just their capability, but to the best of the ability in what they have available to them, you become jaded, you become frustrated.

We run a week late for a customer delivery or a customer project, and we start complaining about things like money, budget overspend, over-utilization. But identifying systematic or environmental issues that you can actually quantify should be treated in exactly the same way. I feel very strongly about this.

Solution 5: Breaking down overwhelming action items

Jaclyn Smith: We tend to nerd out about this stuff, Shane, and you're in good company. You've also reminded me—we've put together a bit of a workshop to help teams and people understand how to get the most out of their retrospectives, not just in terms of making them engaging, but fundamentally how to leverage actions to make them meaningful and impactful.

We've spoken a lot about the incremental change that is the critical factor when it is something that's within the team's control or closely to the team's control. That's how you get that expansion of impact—the slow incremental change. We've talked about sometimes those action items seem overwhelming and too big. What's your advice if that's the scenario for a team? What do you see happen and what can they do?

Shane Raubenheimer: I would suggest following the mantra of "if a story is too big, you don't understand enough about it yet, or it's not broken down far enough." Incremental change should be treated in exactly the same way. The "eat the elephant one bite at a time" analogy. If it's insurmountable, identify a portion of it that will make it a degree less insurmountable next time, and so on and so forth.

If we're iterating work delivery, problem-solving should be done in rapid iteration as well. That's my view.

Jaclyn Smith: I like it.

The "eat the elephant one bite at a time" analogy. If it's insurmountable, identify a portion of it that will make it a degree less insurmountable next time, and so on and so forth. If we're iterating work delivery, problem-solving should be done in rapid iteration as well.

Wrapping up: What's next?

Jaclyn Smith: I think we're almost wrapping up in terms of time. What can people expect from us if they join our webinar on July 10th, I believe it is, where we dive and nerd out even more about this topic, Shane?

Shane Raubenheimer: I think the benefit of the webinar is going to be a practical showing of what we're waxing lyrical about. It's easy to speak and evangelize, but I think from the webinar we'll show turning our concepts into actual actions that you can eyeball and see the results of.

With our approach that we took to our workshop, I think people will very quickly get the feeling of "this is dealing with cause and effect in a cause and effect way." So practical—to put that in one sentence, an active showing or demonstration of how to quantify and actually do what we've been waxing lyrical about.

the benefit of the webinar is going to be a practical showing of what we're waxing lyrical about. It's easy to speak and evangelize, but I think from the webinar we'll show turning our concepts into actual actions that you can eyeball and see the results of.

‍Jaclyn Smith: Excellent. That was a lovely summation, Shane. If anyone is interested in joining, we urge you to do so. You can hear us talking more about that but get some practical help as well. There is a link to the registration page in the description below.

I think that's about all we have time for today. But Shane, as always, it's been amazing and lovely to chat to you and hear your thoughts on a pocket of the agile world and helping teams.

Shane Raubenheimer: Yeah, it's always great engaging with you. I always enjoy our times together, and it's been my pleasure. I live for this kind of thing.

Jaclyn Smith: It's wonderful! Excellent. Well, I will see you on the 10th, and hopefully we'll see everyone else as well.

Shane Raubenheimer: Perfect. Yeah, looking forward to it.

Jaclyn Smith: Thanks.

Ready to end the frustration of ineffective retrospectives?

Join Jaclyn Smith and Shane Raubenheimer on July 10th for a live, hands-on webinar designed to turn your retrospectives into powerful engines for continuous improvement.

In this highly interactive session, you will:

• Uncover why retrospectives get stuck in repetitive cycles
• Learn how to clearly capture and assign actionable insights
• Identify and avoid common retrospective pitfalls and anti-patterns
• Get hands-on experience with Easy Agile TeamRhythm to streamline retrospective actions

Walk away equipped with practical tools, techniques, and clear next steps to immediately enhance your retrospectives and drive meaningful team improvements.

👉 Register now and transform your retrospectives.