Ausfallzeiten: 28. FEBRUAR 2026/23:00 UTC bis 01. MÄRZ 2026/01:00 UTC

Easy Agile Podcast Ep.14 Rocking the Docs

Hör zu
Abonnieren Sie unseren Newsletter
  • website.easyagile.com/blog/rss.xml

„Ich fand es toll, den Raum zu haben, um über gemeinsame Interessen zu sprechen — alles rund um technische Dokumentation und Informationsarchitektur“ — Henri Seymour

In dieser Folge von The Easy Agile Podcast hören Sie Henri Seymour, Entwickler bei Easy Agile, mit Matt Reiner, Customer Advocate bei K15t, sprechen.

Henri & Matt sprechen über alles, was mit technischer Dokumentation zu tun hat (wir versprechen, dass diese Episode viel interessanter ist, als sie sich anhört! 😉)


✏️ Technische Dokumentation als Produkt betrachten
✏️ Der Wert einer gut geschriebenen Dokumentation
✏️ Warum du oft digital entrümpeln solltest
✏️ Informationsarchitektur

So viele Goldnuggets in dieser Folge!

Abonniere unbedingt, genieße die Folge 🎧

Transkript

Henri Seymour:

Hallo zusammen. Das ist der Easy Agile Podcast. Wir haben heute eine Folge mit Matt Reiner. Ich bin dein Gastgeber für heute, Henri Seymour, Entwickler bei Easy Agile. Und kurz bevor wir mit dem Podcast beginnen, möchte ich den traditionellen Australiern des Landes, in dem ich heute aufnehme, meine Anerkennung aussprechen, dem Volk der Watiwati aus der Dharawal-Nation. Respektieren Sie die Ältesten in der Vergangenheit, Gegenwart und in der Zukunft, und erweisen Sie diesen Respekt allen Aborigines oder Bewohnern der Torres Strait Islander, die sich diese Episode anhören.

Matt ist ein erfahrener Content-Stratege mit langjähriger Erfahrung in der Computersoftwarebranche. Er kennt sich mit agilen Scrum-Frameworks, verwandten Tools, Kommunikation, technischem Schreiben, Videoproduktion, Kundeninteraktion und strategischer Planung aus. Und er ist heute hier, um mit uns über das Schreiben und insbesondere über technisches Schreiben und Dokumentation zu sprechen. Hallo, Matt.

Matt Reiner:

Hallo. Es ist toll, hier zu sein. Ja, ich bin Matt. Ich mag alle möglichen inhaltlichen Dinge. Und eines davon ist technisches Schreiben, was, wie ich finde, interessanter ist, als es klingt. Ich schätze, du musst dich bis zum Ende des Podcasts entscheiden, wenn du das glaubst.

Henri Seymour:

Experten für technische Dokumentation. Wenn Sie also speziell über technische Dokumentation sprechen, was meinen Sie damit?

Matt Reiner:

Nun, ich habe das Gefühl, dass sich dieser Begriff gerade mitten in einer großen Veränderung befindet. In der Vergangenheit hieß es in der technischen Dokumentation sehr strikt: „Okay, wir sind ein Team, wir machen etwas, ein Produkt.“ Vielleicht ist es eine App, vielleicht ist es, ich weiß nicht, ein Gokart und dafür brauchen wir eine Bedienungsanleitung. In der technischen Dokumentation hat sich jemand hingesetzt und aufgeschrieben: „Okay, hier sind alle Knöpfe und Schalter und hier ist, was sie tun. Hier sind alle Funktionen. Hier ist vielleicht der Grund, warum du sie verwenden würdest.“

Also die Zusammenstellung der Bedienungsanleitung, bei der es sich traditionell um gedrucktes Material handelte, das Sie mit dem Produkt erhalten würden. Aber im Laufe der Zeit ist es viel mehr geworden, teilweise mit dem Internet, weil wir einfach ständig an Inhalten arbeiten können, wie es viele von uns mit den Produkten tun, die unsere Teams herstellen. Und dann sehen wir es auch in neuen Formen. Vielleicht ist es kein gedrucktes Stück, tatsächlich wollen die meisten Leute keine gedruckte technische Dokumentation mehr, sie wollen sie online. Oder noch besser, sie wollen es direkt im Kontext Ihrer App haben, wenn sie sie verwenden. Sie können einfach die Informationen abrufen, die sie benötigen, und dann weitermachen.

Das ist technische Dokumentation. Sie sollte da sein, um dir zu helfen, das zu tun, was dir wirklich wichtig ist, und dann aus dem Weg zu gehen, damit du es tun kannst.

Henri Seymour:

Haben Sie eine Beschreibung, warum gute technische Dokumentation? Für Produktbenutzer ist es so wichtig, sie nicht nur zu haben, sondern sie in einer guten Qualität zu haben, sodass Ihre Benutzer wirklich davon profitieren.

Matt Reiner:

Nun, ich nehme an, wir alle finden in unserem Tag oder auf unserer Reise die Punkte, an denen wir uns befinden, an denen wir etwas erreichen wollen, aber wir wissen nicht, wie wir es machen sollen. Viele von uns haben sich also wirklich sehr daran gewöhnt, auf Google zu springen und zu sagen: „Okay, hier ist diese Sache, die ich machen möchte, wie mache ich das?“ Und es gibt eine gute technische Dokumentation mit der Antwort, die Sie benötigen, der Erklärung, die Sie benötigen. Denn letztlich sind wir alle kluge Menschen, die befähigt werden sollten, das zu tun, wofür wir eine Leidenschaft haben.

Und technische Redakteure und Kommunikatoren, die eigentlich alle Mitglieder unseres Teams sind. Leute, die sich hinsetzen, um eine gute technische Dokumentation zu erstellen, verwenden so wenig Worte wie möglich, um eine Person auf den richtigen Weg zu bringen. Und wenn es passiert, ist es einfach wie „herrlich“, nicht für den Benutzer. Sie wissen nicht einmal, dass es passiert ist, sie wussten nicht einmal, dass sie deine Texte gelesen haben. Aber für den Autor ist es wie: „Ja, ich habe es geschafft, ich habe es getan. Es ist ihnen egal, was ich getan habe, aber ich habe es getan.“ Und jetzt tun sie das, was wirklich wichtig ist.

Henri Seymour:

Das ist großartig, einen der Hauptunterschiede zu verstehen, wenn ich etwas geschrieben habe und nicht möchte, dass mein Benutzer Zeit damit verbringt. Ich möchte so wenig Zeit wie möglich damit verbringen, dies zu lesen.

Matt Reiner:

Ja, ja, ja. Sie können sehr stolz auf Ihre Arbeit sein, aber eine dieser Kennzahlen, die sich viele Leute bei Websites ansehen, ist die Zeit, die Sie auf einer Seite verbringen. Manchmal können Sie sich also etwas vormachen und denken: „Oh wow, sie haben 10 Minuten auf meiner Seite verbracht. Das heißt, meine Dokumentation ist wirklich gut.“ Aber das könnte auch bedeuten, dass es nicht sehr gut ist und sie es immer wieder lesen müssen. Die wahre Metrik ist also, sind sie zu dem gekommen, was ihnen wirklich wichtig war? Und leider ist es schwer zu messen.

Henri Seymour:

Sie haben das jetzt mit dem Aufkommen des Internets erwähnt und Ihnen die Möglichkeit gegeben, diese Dokumente auf eine Weise zu wiederholen, die Sie mit gedruckter Dokumentation nicht könnten. Diese iterative Sache bringt den agilen Prozess mit sich, etwas, das Sie bereits veröffentlicht haben, zu wiederholen und es auf die gleiche Weise zu verbessern, wie ich es als Entwickler für Produkte tue. Kannst du uns mehr über diesen iterativen agilen Prozess erzählen?

Matt Reiner:

Oh ja. Ja, es ist so wahr. Früher war die Dokumentation wieder im Wasserfall-Standard, eher in der Zeit des Produktprojektmanagements, die Dokumentation war ein wichtiger Teil davon. Sie würden dieses Projekt damit beginnen, diese riesigen Dokumente zu schreiben, in denen es heißt: „Folgendes werden wir tun. Und hier sind alle Überlegungen, und hier erfahren Sie, wie alles zusammenhängt.“ Und das hat für eine Menge Hardware wirklich gut funktioniert. Das war das Ding, das wir lange gemacht haben. Einfach alles, was die Menschheit gemacht hat, war oft Hardware, zumindest als Gruppe.

Und dann kommt plötzlich diese ganze Software-Sache und wir versuchen, sie so zu bauen, als wäre es eine physische Sache. Und wir kommen zum Ende dieses zweijährigen Softwareprojekts und die Leute sagen: „Ja, das ist nicht das, was ich wollte.“ Aber wir sagen: „Oh, aber wir gehen zurück zum Anfang und schauen uns die Dokumentation an, und das haben Sie gesagt, Sie wollten es.“ Aber jetzt, mit dem Internet und nur mit agiler Entwicklung, müssen wir wirklich weg von diesem Ort, an dem wir mit einem Stapel von Dokumenten beginnen. Und dann entwickeln wir einen weiteren Stapel von Dokumenten als unsere, ich weiß nicht, Entwicklungsrichtlinien.

Und dann unsere Testpläne, und dann endlich haben wir die Benutzerdokumentation. Stattdessen sollte die Dokumentation heutzutage eigentlich nur von einem sehr kleinen Teil des Inhalts während des gesamten agilen Entwicklungszyklus zur endgültigen Benutzerdokumentation heranwachsen. Denn es spielt keine Rolle, was wir uns vorgenommen haben, es kommt darauf an, was wir machen. Niemand, er will darüber lesen, was wir zu tun dachten, das ist reine Fiktion. Und es ist wahrscheinlich keine interessante Lektüre. Es ist wirklich das endgültige Benutzerhandbuch, das aus dem agilen Prozess hervorgeht, aber das ist eine große Änderung, aber sie ist gut.

Henri Seymour:

Ich liebe diese Vorstellung von einfach so, das wächst allmählich. Es gibt keinen bestimmten Startblock und Endblock. Es ist ein Prozess. Und Sie haben die Möglichkeit erwähnt, diese Dokumente zu wiederholen. Haben Sie irgendwelche Tipps für die Zeit, nachdem Sie Ihre technische Dokumentation digital veröffentlicht haben, indem Sie das, was Sie bereits haben, wiederholen und im Laufe der Zeit verbessern?

Matt Reiner:

Oh ja. Ich weiß, dass jedes agile Framework anders ist, aber sie alle haben diese Feedback-Phase, in der... Und das ist wirklich während des gesamten Prozesses so, aber wir müssen etwas Zeit investieren. Es gibt also viele verschiedene Dinge, die wir uns ansehen können. Ich möchte zum Beispiel nicht einfach sagen, ein Standardprogramm, das wir uns ansehen sollten, ist, Sie sollten ein Hilfecenter haben, in dem Sie etwas wie Google Analytics implementieren können, damit Sie sehen können, was sich die Leute ansehen? Wie lange schauen sie sich das an?

Eine weitere wirklich gute ist, dass Sie es separat in Google Analytics einrichten müssen. Wonach suchen die Leute auf Ihrer Website? Du kannst auch Google verwenden... das waren früher Webmaster-Tools. Ich glaube, es heißt jetzt Site Tools, aber du kannst sehen, wonach die Leute bei Google gesucht haben, bevor sie auf deine Seiten kamen. Das ist alles wirklich, wirklich wertvolles Zeug. Dann kannst du weiter fortgeschritten sein. Du kannst dir Pointer-Tracking ansehen, Apps, die du dort einbetten kannst und bei denen du ziemlich verrückte Sachen bekommst.

Aber dann solltest du auch erwägen, am Ende jeder Seite ein Forum zu haben wie: „War das hilfreich? War es nicht hilfreich? Oh, es war nicht hilfreich? Sag mir warum. Oh, es war hilfreich? Sag mir warum.“ Genau wie ein YouTube-Ersteller suchen sie nach diesem Feedback. Dieses Feedback ist wichtig, Daumen hoch. Tatsächlich ist es sehr umstritten, YouTube hat gerade angekündigt, die Zahlen mit dem Daumen nach unten zu verbergen, aber viele YouTuber sagen: „Nein, nein, nein, tu das nicht, denn das vermittelt den Wert dieses Videos, das da draußen ist.“

Es gibt also viele dieser Signale. Und dann gibt es einfach wirklich sanfte Signale, bei denen es schwer ist zu wissen, ob die Leute den Inhalt nutzen oder nicht. Weil du es vielleicht nie hören wirst. Vor allem, wenn es eines dieser Dinge ist, dass sie einfach rein und raus gehen, wirst du nichts davon hören. Aber die Feedback-Phase, es ist wirklich toll,... Jedes Mal, wenn Sie Feedback zu Ihrem Produkt erhalten, das Sie herstellen, versuchen Sie, auch Ihre Dokumentation zu veröffentlichen. Denn das ist die Zeit, in der die Leute offen dafür sind, Ihr Produkt zu erkunden und Feedback zu geben.

Warum also nicht dieselbe Dokumentation untersuchen, die dazugehörige Dokumentation, um zu sehen: „Okay, hilft das diesen Leuten tatsächlich dabei, das zu tun, was sie tun wollen? Oder sollten wir es genauso verbessern, wie wir es mit dem Produkt tun?“

Henri Seymour:

Nein, das ist wirklich gut, wenn man das vergleicht, wir haben gerade ein Produkt veröffentlicht. Geben Sie uns Feedback, wenn Sie dasselbe mit der Dokumentation tun. Denn dann wird es seinen Höhepunkt erreichen, bevor jeder den Dreh raus hat. Wir haben gerade diese Feature-Version veröffentlicht, teilen Sie uns mit, wie Sie sie verwenden, und die Dokumentation ist gewissermaßen Teil davon, insbesondere für komplexere Produkte.

Matt Reiner:


Exakt.

Henri Seymour:

Haben Sie irgendeinen Hintergrund in der Kundenbetreuung? Wir führen den Kundensupport sowie deren Dokumentation intern durch. Deshalb versuchen wir, die Dokumentation zu verbessern, um die Supportbelastung unseres Teams zu verringern. Hast du irgendeinen Hintergrund in dem... Kannst du es lösen?

Matt Reiner:

Ja. Ja und nein. Es ist interessant. Ich arbeite jetzt bei K15t, ich war früher Kunde von K15t, also habe ich das Team so kennengelernt. Und so habe ich auch die Dokumentation überhaupt erst kennengelernt. Bei meinem letzten Job haben sie mich beauftragt, dieses System namens Jira zu verwalten. Und ich sagte: „Ich weiß nicht, was das ist.“ Ich sagte ihnen: „Ich dachte, ich könnte es schaffen.“ Und ich habe es herausgefunden, es war dieses kleine Ding namens Jira On-Demand, das jetzt Jira Cloud ist. Und ich habe dem Unternehmen auch Confluence On-Demand vorgestellt. Und wow, ich habe Jira oft kaputt gemacht.

Zum Glück war es zu der Zeit nicht unternehmenskritisch, wir waren immer noch dabei, es wirklich herauszufinden. Aber erst durch die Dokumentation von Atlassian zu Jira habe ich wirklich gelernt: „Wow, diese Inhalte haben hier einen enormen Wert.“ Und dann entdeckte ich: „Okay, wie erstellt Atlassian ihre Dokumentation? Oh, sie machen das in Confluence. Sie schreiben es in Confluence. Sie verwenden diese Apps von K15t.“ Also fing ich an, diese Apps zu verwenden, und dann habe ich viel mit dem K15t-Kundensupport gesprochen, nur Fragen und wie fange ich damit an?

Und wir bieten unseren Support auch intern an, also ist es wirklich großartig. Also vielleicht habe ich es als Kunde zu oft genutzt, ich weiß nicht. Ich sollte einige meiner Kollegen fragen, ob sie genug von mir haben. Aber der Vorteil lag auf der Hand, denn sie sagten mir: „Oh, hier ist die Dokumentation dazu. Und hier ist die Antwort auf diese Frage oder hier sind die Überlegungen, die Sie berücksichtigen sollten.“ Und tatsächlich schauen wir uns jetzt einige unserer Teams wirklich an, vor allem nach den Funktionen, die sehr robust sind, und die Leute haben Fragen.

Es ist also wie, wie können wir ihnen helfen, sich selbst zu helfen? Und diese Ressourcen bereitzustellen ist eine Sache, sicherzustellen, dass Google sie finden kann, nun ja, eine andere. Aber das ist eine wirklich wichtige Sache, vor allem, weil als Produktteam, wenn Ihre Nutzerbasis wächst, auch Ihr Bedarf an Unterstützung steigt. Es ist nur... Ich will nicht sagen, dass es exponentiell ist, aber es entspricht einander. Eine der Möglichkeiten, dem entgegenzuwirken, besteht darin, sicherzustellen, dass Sie ein gutes Design haben, damit Ihr Produkt einfach zu bedienen ist. Und zum anderen benötigen Sie gute Inhalte rund um das gesamte Erlebnis, damit Sie nicht immer mehr Support-Mitarbeiter einstellen müssen.

Oder Ihre Support-Mitarbeiter können sich spezialisieren und sich wirklich auf diese tief verwurzelten Probleme konzentrieren, und dann sollte die Dokumentation beim Rest helfen. Aber das Geheimrezept ist knifflig. Es ist schwierig, den perfekten Inhalt zu schreiben, um die Fälle abzuwehren. Das ist jedermanns Traum.

Henri Seymour:

Auch wenn es einfach nicht alle sind, aber einige der häufigsten Anwendungsfälle werden langsam vom Support abgelenkt, weil die Leute Self-Service machen können. Das macht einen Unterschied. Und ich verstehe auch die Idee der Jira-Dokumentation wirklich. Easy Agile funktioniert auf Jira und es ist... Jira ist derzeit ein unglaublich kompliziertes Produkt, und ich kann mir vorstellen, dass es wahrscheinlich auch kompliziert war, als es Jira On-Demand war. Weil es so kompliziert und detailliert ist, gibt es keine Möglichkeit, es einem Benutzer ohne diese Dokumentation leicht verständlich zu machen. Daran führt kein Weg vorbei.


Matt Reiner:

Ja. Ich denke, es sollte einen Club für die Leute geben, die in Jira zu oft Workflows kaputt gemacht haben. Aber ja, ich meine, die Dokumentation hat mich viele Male gerettet und ich müsste eine... Nun, zu der Zeit war es eine HipChat-Nachricht. Möge es in Frieden ruhen und ich müsste sagen: „Ich habe Jira kaputt gemacht, gib mir eine Minute. Ich muss etwas lesen gehen.“ Nicht so, wie du Jira lernen möchtest, aber es ist eine Option.

Henri Seymour:

Ist es. Manchmal lernt man Dinge, indem man Dinge kaputt macht. Das ist...

Matt Reiner:

Das ist richtig.

Henri Seymour:

Scheint wirklich meine bisherige Erfahrung mit Software zu sein. Du versuchst, die Dinge kaputt zu machen, die die Leute gerade nicht benutzen, und das ist ungefähr alles, was du tun kannst.

Matt Reiner:

Exakt.

Henri Seymour:

Also hat K15t kürzlich Rock the Docs veröffentlicht. Kannst du uns etwas mehr über dieses Projekt erzählen?

Matt Reiner:

Ja. Rock the Docs, eigentlich ging das aus einer Menge Informationen hervor, die ich von K15t bekommen habe. Kundensupport, die ich von der K15t-Dokumentation erhalten habe, habe ich von der Atlassian-Dokumentation erhalten. Und dann einige Dinge, die ich selbst herausgefunden habe, oder einige meiner Kollegen bei K15t haben es getan. Im Grunde genommen, was sind die besten Methoden, um wirklich gute Inhalte in Confluence zu erstellen? Und es begann wirklich mit einer Sammlung von Anleitungen zur Erstellung von Inhalten zur technischen Dokumentation. Es ist darauf ausgerichtet, ein öffentliches Hilfecenter einzurichten, aber in Wirklichkeit ist es für alle Arten von Inhalten, die Sie möchten, wie immergrüne, langjährige Inhalte, um Menschen helfen zu können.

Wir haben also zunächst über alle möglichen Dinge gesprochen, wie die Strukturierung deiner Inhalte, die Wiederverwendung von Inhalten und die Verwaltung mehrerer Sprachen, was in Confluence schwierig sein kann. Zusammenarbeit, Veröffentlichung deiner Inhalte auf die eine oder andere Weise außerhalb von Confluence, Verwaltung von Versionen dieser Inhalte. Das ist also der Anfang. Und dann bekamen wir eine Menge positiver Reaktionen und hatten allgemeinere Fragen wie: „Okay, aber was sind die besten Möglichkeiten, Feedback in Confluence zu erhalten?“ Oder: „Wie erstelle ich eine Vorlage oder eine gute Vorlage oder wie erstelle ich ein gutes Diagramm in Confluence?“

Deshalb haben wir diesen Inhalt erweitert, sodass er sich auf alle möglichen allgemeinen Confluence-Dinge konzentriert. Weil wir festgestellt haben, dass es da draußen eine Menge Informationen darüber gibt, wie man etwas macht. Die Atlassian-Dokumentation war wirklich hilfreich, aber es gab nicht so viele. Ich frage mich: „Warum würdest du das tun? Und warum würdest du das auf diese spezielle Art machen?“ Und wir arbeiten jetzt seit über 10 Jahren mit Confluence zusammen. Wie ich schon sagte, ich bin seit den ersten Tagen mit den krassen Wolken bei Confluence. Es ist so schnell gewachsen, es ist wunderschön.


Aber wir wissen einfach, dass wir eine Menge Dinge mit Confluence gemacht haben, also war es ein echtes Privileg, das beide in Form dieser schriftlichen Anleitungen zu teilen. Und dann haben wir vor Kurzem auch damit begonnen, eine Serie auf unserem YouTube-Kanal zu veröffentlichen, in der es um die Best Practices von Confluence geht.

Henri Seymour:

Das ist großartig. Es ist wirklich interessant zu hören, dass das als kleineres Projekt begann, als es sich herausstellte, weil man den Wert und den Nutzen darin sehen konnte. Wir haben jetzt ein paar Mal über Confluence gesprochen und K15t entwickelt Apps, die Confluence als Dokumentationsquelle verwenden. Kannst du uns mehr darüber erzählen, warum Confluence für die Erstellung technischer Dokumentationen nützlich ist? Welche Tools und Herangehensweisen machen es in diesem Zusammenhang nützlich?

Matt Reiner:

Ja. Confluence ist von Natur aus offen, und so werden technische Schreibwerkzeuge nicht gebaut. Tatsächlich erinnere ich mich an das erste Mal, als ich zu einer Konferenz für technisches Schreiben ging und mich jemand fragte: „Oh, welches Tool verwendest du?“ Das ist quasi das, worüber die Leute in der technischen Kommunikation sprechen, weil wir in dieser Hinsicht alle Nerds sind. Und ich dachte: „Oh, ich mache das in Confluence.“ Und danach wollten sie nicht wirklich mit mir sprechen, weil sie nicht dachten, dass ich ein ernsthafter Tech-Autor bin. Und ich sagte: „Oh nein, nein, nein, nein, das passiert alles.“

Zu diesem Zeitpunkt existierte Rock the Docs noch nicht. Also konnte ich nicht sagen: „Geh rüber und sieh, wie es funktioniert.“ Aber der größte Unterschied ist, dass die meisten technischen Schreibwerkzeuge einfach komplett gesperrt sind. Sie haben zwei Lizenzen für Ihre beiden Personen, die ausgebildete professionelle technische Korrektoren sind, und dann für alle anderen, es gibt keinen Zugriff. Du berührst es nicht. Vielleicht schicken Ihnen Ihre technischen Redakteure ein PDF und Sie müssen den gottschrecklichen Prozess durchlaufen, ein PDF zu markieren, um ihnen mitzuteilen, was sie korrigieren müssen. Oder ich habe von Teams gehört, die den Inhalt ausdrucken und Leute angeben, was geändert werden muss.

Die Überprüfungsverfahren sind einfach nicht von dieser Welt verrückt. Und diese Tools passen nicht besonders gut zu agilen Prozessen, weil es so ist, du baust das Ding hier drüben und dann sind hier die beiden technischen Autoren in ihrem separaten Tool. Und irgendwann werden wir sagen: „Okay, das Ding ist fertig. Würdest du darüber schreiben?“ Bei Confluence besteht der Vorteil der Verwendung von Confluence also darin, dass es für jeden im Team und sogar für Personen außerhalb des Teams zugänglich ist. Und das ist unglaublich von einem Beamten, weil wir bei Agile gesehen haben, aber wir sehen auch in diesem Bereich der technischen Kommunikation und des Informationsdesigns, dass Teams immer weniger nach Fachkräften suchen, die ausgebildete technische Redakteure sind.

Was ein Oxymoron ist, weil die Hälfte von uns, wir haben keinen Abschluss in technischem Schreiben, wir sind aus dem einen oder anderen Grund darauf reingefallen. Aber jetzt beginnen die Teams zu erkennen: „Hey, ich kann Codeentwickler und Informationsentwickler werden. Ich schreibe vielleicht nicht den letzten schriftlichen Inhalt, der von unseren Kunden gesehen wird, aber vielleicht schreibe ich den ersten Entwurf.“ Confluence macht das wirklich allen zugänglich. Und gerade bei Erwähnungen und Inline-Kommentaren sind die Überprüfungsprozesse einfach so schnell.

Eigentlich war der Grund, warum ich bei meinem letzten Job zu Confluence gewechselt bin, dass mein Produktmanager mir drohte und sagte: „Ich werde kein weiteres PDF mit Markups versehen. Geh und finde ein gutes Tool, mit dem wir alle arbeiten wollen.“ Und dort sind wir auf Confluence gelandet. Es geht darum, das gesamte Team in den Schreibprozess einzubeziehen, anstatt dass es sich um eine separate Sache handelt. Denn wenn es eine separate Sache ist, verlieren wir den Überblick. Und beim Inhalt vergessen wir, wie wichtig er für unser Produkt ist, für den Kundenlebenszyklus, für... Gott segne den Kundensupport, der diese Inhalte wirklich, wirklich braucht, um gut und korrekt zu sein.

Und es muss von den echten Experten gesehen werden, die bestätigen: „Ja, okay, das ist richtig. Das wird den Leuten tatsächlich zeigen, wie unser Produkt funktioniert.“ Und Confluence ist quasi das Herzstück davon.


Henri Seymour:

Nein, es ist toll zu hören, wie das alles zusammenkommt, um die Dokumentation als Team zu erstellen. Können Sie näher auf die verschiedenen Rollen eingehen, insbesondere in der Softwareentwicklung, und auf die verschiedenen Rollen, in denen Sie sich an Ihrem Dokumentationsprozess beteiligen möchten? Wir arbeiten hier bei Easy Agile daran, unsere spezifischen App-Teams aufzubauen, da wir derzeit wachsen.

Matt Reiner:

Ja. Das ist so eine gute Frage. Nun, was...

Henri Seymour:

Und wie integriert man... Entschuldigung, das bezieht sich eher auf meine Frage. Wie integrieren Sie diesen technischen Schreibprozess in die Arbeit eines agilen Softwareentwicklungsteams?

Matt Reiner:

Nun, zunächst müssen die Prioritäten überdacht werden, weil die meisten Teams sagen: „Dokumentation hier unten, Testen und dann alles andere oben“. Im Allgemeinen sollten diese beiden Dinge also nach oben verschoben werden. Und eigentlich ist der Inhalt rund um unser Produkt... Ich möchte nicht traumatisch klingen, aber wenn wir keine Informationen haben, haben wir kein Produkt. Mir ist egal, wie viel Code du schreibst. Wenn wir es den Leuten nicht erklären, wenn wir keinen guten UI-Text haben, wenn wir keine gute In-App-Hilfe haben, existiert er nicht. Es ist kein nützliches Tool, es ist nur eine Reihe von mathematischen Methoden, mit denen Menschen nicht interagieren können.

Inhalte sind also unerlässlich, daher ist es wirklich wichtig, dass wir sie so weit bringen, dass jeder im Team erkennt, dass das Inhaltserlebnis, das unsere Nutzer haben, das Produkterlebnis ist, das sie haben. Es muss also Teil des Produktentwicklungsprozesses sein. Also dann der nächste Schritt, von dem ich weiß, dass Sie über Teamstruktur sprechen, aber der nächste Schritt ist, dass wirklich jeder im Team wissen muss, dass er ein Autor ist, und zwar ein guter Autor. Und das ist wichtig, weil viele Leute das noch nie gehört haben. Sie haben nie gehört, dass sie ein guter Schriftsteller sind, und sie haben wahrscheinlich nie gehört, dass sie Schriftsteller sind.

Ich erinnere mich an die Universität, mein Schreibunterricht waren die Dinge, auf die ich nicht geachtet habe. Ich habe Mathematik und Java-Programmierung und Statistik gemacht. Sogar das schien mir wichtiger zu sein, nicht der Schreibunterricht. Und dann stellt sich heraus, dass tatsächlich jeder schreiben muss. Wir schreiben alle. Es ist also wirklich wichtig zu wissen, dass das eine Rolle ist, die jeder ausfüllt. Und wenn es dann um die eigentliche Teamstruktur geht, braucht man Leute, die sozusagen bereit sind, die Streams zu überqueren. Wenn Sie jemanden hinzuziehen, der sich auf Testtechnik konzentriert, muss dieser erkennen, dass die Testpläne, die er schreibt, einer Menge Benutzerdokumentationen, die geschrieben werden müssen, sehr ähnlich sind.

Sie schreiben Aufgabenthemen oder Aufgabenanweisungen, tun Sie dies, tun Sie dies, tun Sie das immer und immer wieder. Das ist Dokumentation. Sie könnten auf diese Weise beitragen. Ingenieure könnten, wie ich bereits erwähnt habe, die erste Kopie vieler sogenannter Konzeptthemen verfassen. Also Bereiche der Dokumentation, in denen Sie Konzepte erklären, weil sie bereits wissen, was diese Konzepte sind. Wenn Sie sich in der Tat die Wurzeln vieler agiler Entwicklungsteams ansehen, verwenden sie Epen, User Stories und Akzeptanzkriterien. Und all diese lassen sich perfekt in die Dokumentation integrieren, die Sie für das neue Feature, an dem Sie arbeiten, oder das Sie verbessern, erstellen mussten.

Es ist also wirklich wichtig, dass jeder erkennt, dass wir alle bereits Dokumentationen erstellen, damit wir einen Beitrag leisten können. Und dann möchten Sie natürlich wirklich mindestens einen englischen Muttersprachler haben. Vielleicht kein Muttersprachler, aber jemand, der sich in seinem Englisch oder in der Sprache, in der Sie schreiben, sicher fühlt. Englisch lässt sich in der Regel am billigsten in andere Sprachen übersetzen, also ist es das, wofür sich die Leute oft entscheiden. Aber diese Person ist die Person, die alles, was jeder geschrieben hat, nimmt und es auf den richtigen Stil und Ton bringt. Und dann bringt er es raus. Das ist es, was wir als erfolgreich ansehen.

Wie unsere Teams im Moment haben wir keine seriösen Tech-Autoren. Wir haben Produktmanager, die schreiben. Wir haben Produktvermarkter, die schreiben. Wir haben Ingenieure, die schreiben. Einige der besten Dokumentationen, die ich je gelesen habe, stammen von einem unserer deutschsprachigen Ingenieure. Ich dachte: „Peter, das ist eine tolle Anleitung. Du musst dieses Java verlassen und Englisch lernen, Mann. Es ist großartig. Es ist großartig.“ Also hat er ein paar gemacht, was ich wirklich liebe. Aber ja, es geht darum, aus den typischen Rollen herauszuspringen und zu erkennen, dass wir das alles sowieso alle dokumentieren.

Henri Seymour:

Ich liebe den Fokus, besonders mit Ihrem deutschsprachigen Kollegen. Der Fokus liegt nicht nur darauf, dass Sie die Dokumentation schreiben müssen, weil Sie wissen, wie das Produkt funktioniert, und das brauchen wir schriftlich. Es ist, Sie sind in der Lage, die Dokumentation zu schreiben, Sie können das tun. Sie haben diese zusätzliche Sicherheitsbarriere gegenüber jemandem, der die Sprachkenntnisse hat, dass er es am Ende massieren und bearbeiten wird.

Also, bevor es irgendwohin kommt, wird alles, was Sie tun, herausgefiltert, wenn es nicht funktioniert. Sie benötigen jedoch keinen speziellen technischen Hintergrund, um die Dokumente zu schreiben.

Matt Reiner:

Nein, absolut nicht. Tatsächlich gibt es eine ganze Gemeinschaft von was... Sie nennen sich selbst Dokumentarfilmer und heißen Write the Docs. Und diese ganze Community, diese ganze Gruppe konzentriert sich darauf, es spielt keine Rolle, was Sie tun, es ist wichtig, dass es Ihnen wichtig ist, die Dokumente zu schreiben und zum Inhalt beizutragen. Und das war, glaube ich, ein großer Wandel in der Branche, wo die Leute dachten, wir wären getrennt. Aber jetzt ist es so: „Nein, nein, nein, wir sind alle in der Lage, das zu tun.“ Und sobald wir die Beiträge respektieren können, die jeder von uns leisten kann.

Und dann habe ich auch den Schutz, dass jemand anderes seine Augen darauf richten wird, was selbst in meinem Schreiben, ich sage: „Ich schicke es nicht gerne raus, bis es jemand anderes gesehen hat.“ Weil ich ständig Rechtschreib- und Tippfehler mache. Ich möchte wirklich, dass sich ein anderer Kollege das ansieht. Auch wenn sie kein Englisch als Muttersprache haben, weil sie meine Tippfehler ziemlich oft erwischen. Dieses Gefühl der Zusammengehörigkeit ist genauso, wie wir uns fühlen, wenn wir ein Projekt oder ein Produkt versenden.

Egal, ob Sie die Tests dafür durchgeführt haben, oder ob Sie den Code dafür geschrieben haben oder ob Sie das Produktmarketing dafür gemacht haben. Es ist wie: „Es ist unser Baby. Lass es uns rausschicken und sehen, was passiert.“ Der Inhalt ist genauso.

Henri Seymour:

Ja, Teil meiner täglichen Rolle und [unhörbar 00:28:03]... Wir haben kein QA-Team, das von den Entwicklern getrennt ist. Unsere Entwickler überprüfen auch unseren Code und es entsteht das Gefühl: „Ich habe dieses Ding geschrieben, aber ich habe ein oder zwei andere Leute, die es verfeinert haben und dafür gesorgt haben, dass die Qualität gut genug ist. Sie haben diesen frischen Blick, also werden sie die Rechtschreibfehler sehen, sie werden die kleinen kleinen Fehler erkennen, die ich mir einfach zu lange angesehen habe, um sie noch zu bemerken.“

Ich habe festgestellt, dass der Prozess des Schreibens von Dokumentationen einige Parallelen hat, wie zum Beispiel: „Hier ist mein Ding. Ich hätte gerne Feedback dazu, bevor es in die reale Welt geht.“

Matt Reiner:

Ja.

Henri Seymour:

Das ist großartig.

Matt Reiner:

Ja, absolut. Ja.

Henri Seymour:

In Ordnung. Können Sie etwas über den Unterschied zwischen der kundenorientierten Dokumentation, die wir bisher hauptsächlich besprochen haben, und der internen Dokumentation sprechen?

Matt Reiner:

Ja. Es gibt einige Unterschiede und es gibt einige große Ähnlichkeiten. Also das ist sehr... Das klingt sehr technisch und hässlich. Der Begriff Informationsarchitektur ist wirklich wichtig für jede Art von Inhalten, intern und extern. Und das ist wirklich so, wenn Sie ein Entwickler sind, kennen Sie sich mit XML aus, Sie sind damit vertraut, Dinge auf diese Weise zu strukturieren. Unsere Inhalte müssen auf die gleiche Weise funktionieren. Und das gilt für die interne und externe Dokumentation. Also, viele der Dinge, die sie als Autoren verwenden, wenn sie eine Seite oder einen Artikel in der Zeitung schreiben, verwenden sie den Pyramidenansatz, bei dem sie die großen Informationen an die Spitze stellen. Und dann konzentrieren sie sich langsam auf das Thema und geben immer mehr Informationen darüber.

Sie sollten jedoch sicherstellen, dass jemand, der nur den ersten Absatz liest, eine ungefähre Vorstellung davon bekommt, um welche Informationen es sich handelt. Und das ist wirklich wichtig für erfolgreiche Confluence-Seiten und -Bereiche. Die Leute sollten in der Lage sein, auf der obersten Ebene des Bereichs zu beginnen, zu verstehen, worum es in dem Bereich geht, und dann in der Lage sein, auf der Seite selbst zu dem zu navigieren, worüber sie wirklich lernen möchten. Was dann aus Überschriften, Unterüberschriften und Aufzählungspunkten bestehen sollte, um diese Informationen einfach zu verbreiten und aufzuschlüsseln. Weil jeder überfliegt.

Wir brauchen, dass unsere Inhalte überflogen werden können, unsere Räume müssen überflogen werden können. Und diese Art von Inhalten macht auch die Confluence-Suche glücklich, insbesondere die neue Confluence Cloud-Suche, die stark verbessert wurde. Dazu gibt es eine ganz neue elastische Suchbasis, die gerade optimiert wird. Aber es ist glücklich, es ist genau wie bei Google, wenn wir unsere Inhalte so strukturieren. Wenn Sie also eine Seite haben, die nur aus Text besteht, ohne Überschriften, die Sie nicht in Seiten oder gar Leerzeichen aufteilen, wird niemand damit zufrieden sein.

Die Bots werden damit nicht zufrieden sein, die Leute, die lesen, werden damit nicht zufrieden sein. Es erfordert also ein bisschen Arbeit, die Struktur unserer Inhalte zu strukturieren und aufzubrechen. Es ist wahrscheinlich alles in Ordnung, solange es aktuell ist, aber es ist wirklich wichtig, dass wir darüber nachdenken, wie wir das in Confluence strukturieren, damit die Leute es finden und die Leute es überfliegen können. Und genau das scheint viele interne Confluence-Instanzen zu plagen, denn viele... Vielleicht konzentriert sich das Team nicht so sehr darauf.

Es ist wie: „Oh, unser externes Hilfecenter, das aus diesem Bereich hier kommt, das ist in Ordnung. Unser Teamraum, großes Durcheinander, totaler Reifenbrand.“ Und niemand kümmert sich darum, weil sie glauben zu wissen, wo alles ist. Aber dann fängst du an, darüber nachzudenken: „Okay, aber was ist mit dem neuen Teammitglied? Wie finden sie etwas?“ Oder: „Was ist mit dem Teammitglied, das seit sechs Wochen wegen Vaterschaftsurlaubs weg ist? Werden sie sich daran erinnern, wo alles ist, oder wissen sie, wo all die neuen Sachen sind?


Was ist mit Menschen mit Behinderungen? Wird es für sie viel schwieriger sein, zu den Informationen zu navigieren, die sie benötigen? Weil sie mit einem Screenreader arbeiten und versuchen, durch eine Textwand zu gehen. Sie benötigen Überschriften, ein Screenreader verlässt sich auf diese Überschriften und Titel.“ Es gibt also einfach so viele Überlegungen, die die Unternehmensführung wirklich verstehen muss. Nur weil Sie einen Prozess haben, um etwas zu tun, oder die Informationen irgendwo sind, heißt das nicht, dass Sie kein großes Informationsproblem haben. Und all deine Inhalte in Confluence zu pflegen und dann gut zu pflegen.

Dies ermöglicht es den Menschen, die Frustration zu vermeiden, nach Informationen zu suchen, Informationen zu verlieren, Informationen neu lernen oder neu schreiben zu müssen. Ich habe in zu vielen Unternehmen gearbeitet, in denen Informationen einfach überall gesiebt werden. Ich möchte sie nicht einmal Silos nennen, weil auch niemand mehr weiß, wo sich die Dinge befinden. Das ist es, was Confluence ausmacht, und darauf kommt es sowohl bei internen als auch bei externen Inhalten an.

Henri Seymour:

Das ist eine großartige Perspektive. Und ich kann die Silos sehen, es ist wirklich mehr... Nur ein großer Stapel, du kannst nichts finden. Ich war...

Matt Reiner:

Exakt.

Henri Seymour:

... seit mehr als der Hälfte seines Lebens bei Easy Agile und ich habe das Gefühl: „Oh, ich weiß, ich habe das irgendwo aufgeschrieben. Ich weiß, dass ich das irgendwo aufgeschrieben gesehen habe.“ Und wir machen es uns zur Gewohnheit, vor allem, weil wir immer mehr Leute einstellen. Jedes Mal, wenn jemand ein Onboarding durchläuft, wird er sich die gesamte Dokumentation ohne vorherige Hintergrundinformationen ansehen. Und wir möchten speziell ihr Feedback dazu hören. Denn wenn es für sie funktioniert, dann ist das die Dokumentation, die wir für sie und für alle nach ihnen brauchen, und für alle, die schon hier sind.

Vor allem bin ich jetzt seit fast drei Jahren bei Easy Agile und ich habe gesehen, wie es von acht Mitarbeitern auf jetzt, glaube ich, über 20 Jahre gewachsen ist. Ende des Jahres werden wir in die 30er Jahre übergehen.

Matt Reiner:

Beeindruckend.

Henri Seymour:

Das Wachstum der Informationen, die wir in unserer internen Dokumentation haben, und ich bin mir sicher, dass dies mit dem Wachstum der Produktdokumentation für ein Produkt einhergehen würde, das seit drei bis fünf Jahren expandiert. Wie verwaltest du die Dokumentation und die Confluence-Bereiche, wenn das Team und das Unternehmen wachsen und du einfach immer mehr Seiten daraus entwickelst?

Matt Reiner:

Das ist die Frage seit den Anfängen des Universums oder zumindest seit den Anfängen von Confluence, was ist der Unterschied? Die größte Sache ist die Teamverantwortung, also zu wissen, dass dies unser Raum ist, das ist unser Inhalt. Und zwar nicht auf territoriale Weise, aber das liegt in unserer Verantwortung. So wie wir über unseren Planeten nachdenken sollten, sollten wir auch über unsere Inhalte nachdenken und dafür sorgen, dass sie gepflegt und gepflegt, aktuell und korrekt sind. Und dann, wenn sich die Dinge ändern.

Wir haben zum Beispiel ein Produkt namens Scroll Viewport, mit dem du Inhalte von Confluence in einem öffentlichen Gesundheitszentrum veröffentlichen kannst, was wirklich, wirklich cool ist. Damit hatten wir also eine Server- und Rechenzentrumsversion. Das haben wir schon seit geraumer Zeit. Das war es, was ich genutzt habe. Und dann haben wir uns auf den Weg gemacht, eine Cloud-Version zu entwickeln, und die Cloud erfordert eine ganze Reihe neuer Infrastrukturen, was viel Spaß macht und sehr herausfordernd ist, aber es ist eine ganz andere Sache.

Es ist nicht so, dass man einfach den Servercode hochziehen und ihn einfach in die Cloud ziehen kann, worum ich sie als Benutzer jahrelang gebeten habe: „Warum ist das nicht in der Cloud?“ Jetzt weiß ich warum. Also haben wir ein neues Team zusammengestellt, das mit Scroll Viewport on Cloud begann. Und anfangs war es nur ein sehr schlampiges Projekt. Und ich erinnere mich an die erste Seite, auf der wir da oben waren wie: „Whoa, sieh dir diese Seite an, die wir veröffentlicht haben.“ Und von da an ging es weiter. Aber irgendwann mussten wir die beiden Teams wieder zusammenbringen. Und was wir einfach hätten sagen können: „Oh, dieser alte Viewport-Raum, was auch immer. Wir lassen es einfach da und machen dann einfach mit dem neuen weiter.“

Aber stattdessen nahm sich das Team Zeit und brachte die beiden Bereiche zusammen und ging die alten Inhalte im Viewport Server- und Rechenzentrumsbereich wirklich durch, um zu sagen: „Ist das alles noch relevant? Brauchen wir das immer noch?“ Es wurde also auf so erstaunliche Weise neu angeordnet. Einige unserer Teams sind wirklich gut darin geworden, diese Räume so einzurichten, dass ich reinkommen kann. Weil ich mit all unseren Teams zusammenarbeite, geh einfach rein und finde, was ich brauche, auch wenn ich nicht täglich in ihnen arbeite. Ich bin einfach so froh, ich bin so stolz auf das Team, dass es diesen Raum nicht einfach irgendwo schwinden lässt oder Angst hat, Inhalte zu löschen oder zu archivieren, was bei vielen Leuten der Fall ist.

Es ist wie: „Nein, was ist, wenn wir etwas verlieren?“ Es ist wie: „Nein, nein, nein, das haben wir hinter uns gelassen. Wir müssen es wirklich löschen.“ Das ist die Art von Einstellung, die wir brauchen: Unsere Teams teilen sich auf, erweitern und wachsen, und wir müssen uns dieser Inhalte bewusst sein. Denn auch hier gilt: Denkt an die neue Person, denkt an die Person, die etwas Neues lernt. Denke an die Person, die vielleicht eine Behinderung hat und versucht, die Inhalte zu bekommen, die sie braucht. Sie haben einfach nicht den Hintergrund, den Sie haben. Sie sind die Hälfte ihres Lebens in der Firma und wissen, wie man den Gedankenstapel durchwühlt, um genau das herauszuholen, was man will, aber sie nicht.

Henri Seymour:

Ja, und ich möchte nicht die Person sein, die sie jedes Mal fragen müssen, wenn sie Informationen benötigen: „Hey, kannst du das für mich finden?“ Nein, nein. Ich möchte ein System aufbauen, das bedeutet, dass ich nicht ständig dieselben Fragen beantworten muss. Das ist einer der Gründe, warum ich seitdem so viel interne Dokumentation mache [unhörbar 00:37:36]. Ich habe diese Frage einmal beantwortet, das reicht.

Matt Reiner:

Ja. Das ist eine wirklich gute Möglichkeit, alle Mitwirkenden an der Dokumentation zu motivieren. „Hey, weißt du, wie du diesen Teil unserer App einmal geschrieben hast und dann haben dich alle gefragt, wie er seitdem funktioniert? Dokumentiere es einfach einmal und ich verspreche, dass du es nie wieder beantworten kannst.“ Genau das ist eine gute Motivation.

Henri Seymour:

Ist es. Außerdem haben wir ein Team für Support-Modelle, also arbeite ich an den Storemaps und Personas, dem Produktentwicklungsteam. Und das ist dasselbe Team, das alle Support-Anfragen zu Storymaps und Personas erhält. Also ja, je besser wir das Produkt machen, desto besser machen wir die Dokumentation, desto weniger Zeit verbringen wir jeden Morgen damit. Und je mehr wir zu unseren regulären Jobs zurückkehren können.

Matt Reiner:

Exakt.

Henri Seymour:

Es war großartig, um uns dabei zu helfen, mit den Kunden in Kontakt zu bleiben und zu erfahren, was sie tun und welche Informationen sie benötigen, wenn sie unser Produkt verwenden. Du hast erwähnt, dass es zwar notwendig, aber wertvoll ist, von Zeit zu Zeit archivbasierte Dinge, Seiten in Confluence, zu löschen. Wenn du dir eine Seite ansiehst und dich fragst, ob es Zeit ist, sie zu öffnen, welche Art von Fragen stellst du dir?

Matt Reiner:

Nun, eine tolle Idee ist wie, sieh dir das Datum der letzten Änderung auf dieser Seite an. Das ist im Allgemeinen ein ziemlich gutes Zeichen für so etwas wie: „Schauen die Leute es sich überhaupt an?“ Wenn Sie Cloud Premium und höher nutzen, können Sie sich sogar auf jeder Seite einige großartige Kennzahlen ansehen, um zu sehen, wer sich das Ding ansieht? Ist das wertvoll? Wie sind die Aussichten? Genauso, wie Sie sich Ihre externe Website ansehen würden, um zu sehen, ob Ihre Inhalte wertvoll oder effektiv sind. Aber in der Regel haben wir eine Menge Trümmer übrig, die von der Produktentwicklung oder Teamaktivitäten übrig geblieben sind.

Wenn Sie beispielsweise im Marketing tätig sind und eine Kampagne von vor drei Jahren haben, benötigen Sie dann wirklich all diese detaillierten Seiten? Vielleicht behalten Sie die gesamte Kampagnenseite bei, vielleicht ist das nützlich, aber brauchen Sie wirklich alles? Wenn du gerne testest, brauchst du wirklich jeden Testplan, den du jemals erstellt hast? Wenn Sie im Rechtsteam sind, möchten Sie wirklich Ihre rechtlichen Bedingungen von vor 10 Jahren? Vielleicht, vielleicht, bin ich nicht in der Rechtsabteilung. Aber oft haben wir diese Angst vor, es ist wie Angst vor fehlenden Inhalten.

Es ist wie: „Oh nein, wenn ich das loswerde, werde ich es nicht haben.“ Aber Informationen, genau wie Sprache, genau wie die Art und Weise, wie wir denken, genau wie die Art und Weise, wie unsere Teams wachsen, sie ändern sich. Und deshalb müssen wir uns dessen bewusst sein. Da wir uns als Team verändern, sollten Sie damit rechnen, dass sich unsere Inhalte ändern. Und ein Teil davon ist, das alte Zeug loszuwerden. Es lohnt sich also immer. Wenn du es in Frage stellst, frag einen anderen Fachexperten und sage: „Hey, ich bin mir ziemlich sicher, dass wir das nicht mehr brauchen, oder wir sollten es überarbeiten. Was denkst du?“ Aber wenn niemand Bedenken hat, solltest du es wahrscheinlich löschen.

Henri Seymour:

Nein, das ist großartig. Ich bin ein großer Fan von Entrümpeln, auch von digitalem Entrümpeln. Es ist, ich möchte, dass die Leute Sachen finden und je weniger Stapel es gibt, desto einfacher wird es sein.

Matt Reiner:

Ja. Weil schlechte Informationen irgendwie weniger hilfreich sind als keine Informationen.

Henri Seymour:

Ja. Es ist, als würden sie auf eine Frage stoßen und sie sagen: „Oh, ich habe es auf diese Weise versucht.“ Ich sage: „Oh, dieser Weg funktioniert nicht mehr. Du wirst tun müssen... Wo hast du das aufgeschrieben gefunden? Ich werde auf dem Laufenden bleiben.“ Es ist...

Matt Reiner:

Ja.

Henri Seymour:

... neue Leute, die Sachen machen. Der beste Weg, um zu verstehen, wo Ihre Dokumentation ins Stocken gerät. Es ist genauso, als ob Sie nie verstehen werden, wie Ihre Produktdokumentation und Ihr Produkt selbst Ihre Benutzer im Stich lassen, bis sie zu Ihnen kommen und Ihnen sagen: „Warum kann ich das nicht tun?“

Matt Reiner:

Ja. Ja. Ja, diese Fähigkeit, jemanden neu in Ihr Team zu holen, ist so unglaublich. Und es ist fast schwierig, am ersten Tag des Onboardings zu sagen: „Du hast frische Augen, bitte nutze sie. Das wird als Inline-Kommentar bezeichnet, bitte platzieren Sie ihn überall.“ Ich erinnere mich, dass ich unser Mitarbeiterhandbuch für die Personalabteilung durchgesehen habe, das wir kurz vor meinem Beitritt gerade erstellt hatten. Und ich erinnere mich, dass sie mir sagten: „Falls es irgendwelche Fragen gibt, hat uns at erwähnt.“ Und ich hatte wirklich Angst davor. Aber wir haben viele Dinge korrigiert.

Zum Beispiel haben wir erwähnt, dass Sie diese Dinge tun auf... Wie wurde es nach HipChat genannt? Das Produkt, das so schnell lebte und starb.

Henri Seymour:

Ich glaube, den habe ich verpasst.

Matt Reiner:

Oh, die, die Atlassian gemacht und dann an Slack verkauft hat.

Henri Seymour:

Nun, wo fange ich überhaupt damit an?

Matt Reiner:

Wie geht es mir... Es war eine tolle App, sie hat mir sehr gut gefallen. Aber wir haben im Mitarbeiterhandbuch erwähnt, dass wir das verwenden sollten. Und ich sage: „Oh, ich glaube, wir verwenden jetzt Slack, wir sollten diesen Inhalt aktualisieren.“ Das sind Dinge, die die Personalabteilung niemals durchgehen und auffangen wird, aber deine neuen Mitarbeiter können das tun. Neue Mitarbeiter sind der beste Weg, um Ihnen zu sagen, ob Ihre Prozesse schlecht sind oder ob Ihre Inhalte besser sind. Vielleicht nicht schlecht, aber sie bringen etwas Neues ein. Deshalb haben wir sie ins Team aufgenommen. Und sie sollten vom ersten Tag an keine Angst haben, Fragen zu stellen oder Löcher in unseren bereits verkorksten oder gescheiterten Prozess zu bohren.

Henri Seymour:

Ja. Und ich kann den Vorteil der Tools in Confluence wirklich erkennen, wie dieser Inline-Kommentar. Auch wenn du nicht weißt, wie du diese Seite aktualisieren musst oder wie die neue Version aussehen soll. Es kommt gerade neu rein, du kannst sagen: „Oh, das ist komisch oder unvollständig, oder es könnte falsch sein.“ Es ist nur ein kleiner Kommentar. Du musst es nicht selbst ändern, sag einfach etwas. Hier ist eine Möglichkeit, sich zu äußern, ohne es selbst zu ändern. Und jemand, der es weiß, wird in der Lage sein, es für Sie zu ändern.

Ich habe mich gefreut, Sie über Informationsarchitektur sprechen zu hören. Das habe ich auch erst letztes Jahr kennengelernt. Haben Sie eine allgemeine Erklärung, was Informationsarchitektur ist und warum sie für die Dokumentation relevant ist?

Matt Reiner:

Oh, Informationsarchitektur ist, es gibt ganze Leute, Profis, deren gesamte Karriere reinkommt und einem hilft. Also ich gehöre nicht zu diesen Profis, ich spiele nur einen im Fernsehen. Im Wesentlichen zerlegt die Informationsarchitektur etwas, das eine Textwand wäre, in ein Informationsmuster, mit dem sich jeder Geist verbinden kann. Das ist das eigentliche und ultimative Ziel, und das beginnt damit, logische Teile aufzubrechen. Tatsächlich zerlegt man beim Schreiben rein technischer Texte den Inhalt in winzige, winzige Teile, oder einige technische Kommunikatoren sprechen von Informationatomen, wirklich winzigen Teilen.

Und wenn Sie das dann aufgeschlüsselt und gesagt haben: „Das sind separate Teile“, setzen Sie sie in einer Reihenfolge zusammen, die Sinn macht. Tatsächlich kannst du mit der Wiederverwendung von Inhalten in Confluence auch wirklich coole Sachen machen, indem du Include-Makros verwendest. Das neue Excerpt Include Macro ist in der Cloud sehr cool, weil du damit neue Sachen machen kannst. Aber es geht wirklich darum, all deine Inhalte auseinanderzunehmen und herauszufinden, in welcher Reihenfolge das alles abläuft? Was ist am wichtigsten? Was ist spezifischer? Was ist wichtig für alle? Was ist wichtig für nur wenige Menschen?

Und dann gehen Sie einfach nach unten, wie Sie es mit einer XML-Struktur oder einer anderen Art von Hierarchie tun würden, und ordnen Sie diese Informationen mithilfe Ihrer Leerzeichen, Ihrer Seiten, Ihrer Überschriften an. Und dann endlich Aufzählungszeichen und Absätze und so weiter.

Henri Seymour:

Danke, dass du das allgemein erklärt hast. Gibt es im Moment etwas, das Sie in Ihrer Arbeit erwähnen möchten, für das Sie die Leser interessieren würden?

Matt Reiner:

Ja, absolut. Ein großer neuer Aufwand für mich, weil ich wohl nur dieser Content Explorer bin. Ich mochte technische Inhalte, ich habe einige Marketinginhalte geschrieben. Ich habe angefangen zu sprechen, was mir Spaß macht. Ich durfte vor einem Live-Publikum sprechen, bevor... Nein, ich schätze ein paar, und dann ist die Welt aus gutem Grund zum Erliegen gekommen. Denn wenn man eine Menge Leute angreift, möchte man sichergehen, dass man sie nicht potenziell einem Risiko aussetzt. Ich habe also viel virtuell gesprochen.

Aber vor Kurzem habe ich erwähnt, dass wir an all diesen Best Practices für Rock the Docs gearbeitet haben. Deshalb haben wir diese Videoserie über die Best Practices von Confluence gestartet und es war sehr aufregend herauszufinden: „Okay, ich weiß also, wie man in Confluence ziemlich gute Inhalte erstellt, wie man diese Inhalte strukturiert. Können wir jetzt ein gutes Video machen?“ Und es stellt sich heraus, nein, zuerst nicht. Habe ein paar ziemlich schlechte gemacht oder solche, für deren Herstellung einfach viel zu viel Zeit in Anspruch genommen wurde. Und schließlich, wie Sie es bei jeder Art von Inhalten tun, haben wir endlich eine gute Struktur, einen guten Rhythmus. Und wir haben auch herausgefunden, über welche Dinge die Leute wirklich hören wollen?

Deshalb haben wir jetzt 16 davon auf unserem YouTube-Kanal entwickelt, die nur für Administratoren da sind, um sie mit deinen Nutzern zu teilen, die diese Fragen stellen. Oder vielleicht richten sie sich direkt an Nutzer, die einfach nur abonnieren und diese Dinge erhalten möchten. Aber es sind ungefähr acht Minuten mit genau so vielen Informationen, wie wir einpacken können und trotzdem gut lesbares Englisch sprechen. Und dann zeige einfach, wie macht man das in Confluence? Warum würdest du das in Confluence machen? Was sind die Dinge, die du in Confluence beachten solltest? Was sind die besten Möglichkeiten, Dinge in Confluence zu erledigen?


Wir haben auch gerade eine Reihe von Livestreams gestartet, bei denen wir versuchen, uns diese genauer anzusehen und dann die Leute live zuzuhören, Fragen zu stellen und Regie zu führen. Bisher waren diese wirklich großartig und wir planen, mehr davon zu tun. Je mehr Leute sich also darauf einlassen, desto mehr Richtung habt ihr alle, diesen Inhalten zu geben. Aber es waren neue Arten von Inhalten, und es ist aufregend zu sehen, okay, unsere gut geschriebenen Inhalte in Confluence kommen in einem neuen Format in die reale Welt. Das war cool und herausfordernd und lustig und gruselig zugleich.

Henri Seymour:

Ja. Das klingt nach einem wirklich aufregenden Projekt. Rock the Docs wird audiovisuell. Und ich kann...

Matt Reiner:

Das ist richtig.

Henri Seymour:

... stell dir vor was... Bringen Sie die Nutzer dazu, Ihnen das iterative Feedback zu geben, über das wir am Anfang gesprochen haben. Also ist das den Daumen hoch wert? Haben Sie Kommentare? Was können wir noch tun? Und besonders bei dieser Art von Live-Stream-Webinaren erhalten Sie den direkten Kontakt zu Ihren Benutzern, sodass Sie herausfinden können, was sie benötigen. Das ist fantastisch. Mal sehen, ob ich die mitbringen kann. Easy Agile begann speziell Anfang dieses Jahres, Scroll Viewport für die Cloud zu verwenden.

Matt Reiner:

Oh, cool. Oh, cool.

Henri Seymour:

Das war also tatsächlich eine große Verbesserung für uns.

Matt Reiner:

Oh, gut. Ja. Mir gefällt einfach, was das Cloud-Team herausbringt. Es ist so aufregend und so ausgefeilt und es ist, als ob jedes Team diesen Dokumentationsbereich hat, und Viewport, damit kannst du es veröffentlichen und du denkst: „Ah, sieht so toll aus. Wir sind so stolz darauf.“ Du kannst es auf jedem Gerät lesen. Es ist einfach so, als ob es die Magie ist, die jeder will, aber kein Team hat Zeit. Unsere sehr wenigen Teams haben Zeit, es so gut aussehen zu lassen, also ist es schön, dass Viewport einfach die Schwerarbeit erledigt.

Henri Seymour:

Wir haben den Confluence-Bereich, wir haben die Dokumentation. Wir müssen keine Website darüber erstellen. Es ist nur: „Mach weiter, bitte lass diese Website Wirklichkeit werden. Hier ist, was wir darauf brauchen. Hier ist die Struktur.“ Und meine Güte, es sieht jetzt viel besser aus, auch nur ästhetisch, es sieht im Haus sehr gut aus.

Matt Reiner:

Ja. Und es ist schön zu wissen, dass ein Designer den Abstand zwischen den Navigationselementen überschaut hat, um zu entscheiden, wie weit sie voneinander entfernt sein sollten. Und als Autor kann ich einfach sagen, es muss mir egal sein. Mir muss das egal sein. Ich kann Confluence-Makros und so reinwerfen, und sie sehen einfach toll aus, wenn sie veröffentlicht werden. Und ich weiß nicht wie oder warum, aber ich bin glücklich. Ich kann einfach weiterschreiben. Ja.

Henri Seymour:

Ja.

Matt Reiner:

Es wäre toll, jemanden von Easy Agile bei einem dieser Livestreams dabei zu haben. Denn worauf wir uns wirklich konzentrieren, ist einfach eine großartige Möglichkeit, Dinge in Confluence zu erledigen. Wir sind noch nicht in Jira eingestiegen. Ich bin nicht so ein Experte für Jira, aber ich habe darüber nachgedacht, weil dieser Inhalt noch nicht wirklich existiert. Aber es ist nicht unbedingt auf Apps oder K15t auf Apps ausgerichtet. Es ist einfach eine der besten Möglichkeiten, die du gefunden hast, um bestimmte Dinge in Confluence zu tun, und wir teilen sie einfach mit lebenden Menschen, und es macht eine Menge Spaß.

Henri Seymour:

Ja, das klingt toll. Ich habe die Parallele zwischen dem Einstieg in Jira und der Entwicklung von Jira-Apps und Confluence: „Ja, wir haben ein Wiki. Hier schreiben wir Sachen auf.“ Und es ist toll, Dinge wie „Da ist das Bildmaterial auf unserer Dokumentseite“ zu haben. Aber die mache ich nicht. Ich bin damit beschäftigt, Grafiken in einer Jira-App zu erstellen. Ich möchte nicht über diesen Abstand nachdenken. Ich muss meinen eigenen Abstand machen.

Matt Reiner:

Ja. Ja.

Henri Seymour:

Und es ist wirklich so, ich kann einfach schreiben, ich kann einfach das Produkt machen. Ich kann meinen Job besser machen, weil ich mich um diese anderen Dinge gekümmert habe, weil die Experten von K15t das möglich gemacht haben. Und ich hoffe, dass unsere Apps etwas Ähnliches für ihre Nutzer tun können. Das ist das, was wir brauchen, wir müssen nicht darüber nachdenken. Bringen Sie diese App mit und sie wird ein Problem für uns lösen. Sie hilft uns dabei, zu sehen, was wir brauchen, und unsere Informationen in Jira zu organisieren. Was wiederum eine andere Art von Information ist, aber.

Matt Reiner:

Ja, ja. Ja, es ist lustig. Ich habe mit einigen Leuten gesprochen, die den ganzen App-Teil von Confluence in Jira tatsächlich als App Hell beschrieben haben. Das ist ein Begriff, den ich gesehen habe, und ich kann nicht anders, als die Community zu lieben, weil wir uns alle diese Dinge einfallen lassen. Aber die Hölle ist die App, sie entsteht wirklich dadurch, dass man teilweise nicht versteht, was eine Plattform ist. Wenn Sie beispielsweise die Salesforce-Plattform verwenden, ja, das wird zur App-Hölle, wenn Sie wirklich wollen, dass Salesforce eine Marketingplattform ist. Weil Salesforce eine Vertriebsplattform ist. Aber dann gibt es Apps, und Salesforce verkauft sich zufällig sehr. Und dann ist es plötzlich eine Marketingplattform.

Das ist also ein wirklich interessanter Perspektivenwechsel für Leute, die an ein Tool gewöhnt sind, das nur eine Sache tut. Jeder denkt, Excel macht alles. Das tut es nicht, wir sollten es wirklich nur für Tabellenkalkulationen verwenden, Leute. Es ist keine Plattform für andere Dinge. Confluence ist wirklich gut in diesen Kerndingen, Jira ist wirklich gut in diesen Kerndingen. Und dann kommen diese Apps, um die Fragen zu beantworten, für die es keine Antworten gibt, und um die Dinge zu tun, die nicht getan werden können. Und das ist der Grund. Also ist es App Hell oder ist es App Heaven? Das ist die eigentliche Frage. Oder vielleicht ist es vielleicht App Purgatory, ich weiß es nicht. Ich denke, die Zuhörer entscheiden.

Henri Seymour:

Der ständige Strom von, und noch eine weitere App muss aktualisiert werden. Um fair zu sein, denke ich, dass dies derzeit kein Problem in der Cloud ist. Das ist ein ausschließlich vor Ort auftretendes Problem, der ständige Aktualisierungszyklus der Apps. Aber vielleicht nähern wir uns dem Ende des Fegefeuers.

Matt Reiner:

Ja. Ja. Ich glaube, wir steigen alle zusammen auf. Wir erreichen gerade gleichzeitig neue Höhen.

Henri Seymour:

Gibt es noch etwas, das du ansprechen möchtest, während wir über technische Dokumente sprechen?

Matt Reiner:

Ich schätze, ich gehe in die Zeit zurück, als ich an der Universität war. Ich hatte dort einen Manager, der uns in diesem Job auf dem Campus, den ich hatte, sagte: „Unsere Aufgabe ist es, Menschen mit den Ressourcen zu verbinden, die sie bereits umgeben. Du bist kein Lehrer, du bist nur hier, um Menschen miteinander zu verbinden.“ Und das ist mir wirklich im Gedächtnis geblieben. Und das ist im Grunde das, was wir alle tun. Egal, ob wir ein Produkt entwickeln, das Menschen mit Ressourcen verbindet, oder ob das die Ressource ist oder ob wir zur Dokumentation oder zu irgendwelchen Inhalten beitragen.

Wir versuchen wirklich, es den Leuten zu ermöglichen, etwas Größeres zu tun, etwas Höheres, das über unseren Inhalten, über unserem Produkt liegt. Es ist diese Sache, die ihnen wirklich wichtig ist, und jede Rolle, die wir spielen dürfen, und diese größere Sache, diese bessere Sache. Das ist es, worum es geht.

Henri Seymour:

Ja, das ist eine wirklich tolle Perspektive. Das ist wahrscheinlich auch eine wirklich tolle Sache, um das Ende des Podcasts abzurunden.

Matt Reiner:

Ich schätze schon.

Henri Seymour:

Ja. Vielen Dank, dass du zu uns gekommen bist, Matt, und dass du mit uns im Easy Agile Podcast über alles rund um technische Dokumentation gesprochen hast.

Verwandte Episoden

  • Podcast

    Easy Agile Podcast Ep.25 Das Agile Manifest mit Jon Kern

    „Mein Gespräch mit Jon hat mir sehr gut gefallen. Er teilte einige großartige Perspektiven auf die Auswirkungen des Agile-Manifests mit“ - Amaar Iftikhar

    Zu Amaar Iftikhar, Produktmanager bei Easy Agile, gesellt sich Jon Kern, Mitautor des Agilen Manifests für Softwareentwicklung und leitender Transformationsberater bei Adaptavist.

    Amaar und Jon nahmen sich etwas Zeit, um über das Agile Manifest zu sprechen. Es wurde alles behandelt, von den Anfängen über die Ideenfindung, den Prozess und die ersten Reaktionen bis hin zu den Auswirkungen auf die heutige Welt des agilen Arbeitens.

    Sie gehen auf den Idealzustand eines agilen Teams ein und darauf, was das Manifest für verteilte, hybride und am selben Standort ansässige Teams bedeutet.

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

    Transkript

    Amaar Iftikhar:

    Hallo zusammen. Willkommen zum Easy Agile Podcast. Mein Name ist Amaar Iftikhar. Ich bin Produktmanager hier bei Easy Agile. Und bevor wir beginnen, möchte Easy Agile den traditionellen Hütern des Landes, von dem aus wir heute senden, danken, den Menschen im Dharawal sprechenden Land. Wir erweisen den Ältesten in Vergangenheit, Gegenwart und Entwicklung unseren Respekt. Und gilt allen Aborigines, den Bewohnern der Torres-Strait-Inseln und den Ureinwohnern, die heute zu uns kommen, denselben Respekt.

    Heute haben wir im Podcast Jon Kern zu hören, der Mitautor des Agilen Manifests für Softwareentwicklung und Agile-Berater ist. Wenn Sie sich das fragen, haben Sie Recht. Ich habe das Agile Manifest für Softwareentwicklung erwähnt. Das Agile Manifest. Also Jon, willkommen, dass du hier bist und danke, dass du zu uns gekommen bist.

    John Kern:

    Oh, das freut mich, Amaar. Oh, danke.

    Amaar Iftikhar:

    Ja, ich freue mich sehr, dich dabei zu haben. Fangen wir einfach mit den absoluten Grundlagen an. Erzählen Sie dem Publikum, was ist das Agile-Manifest?

    John Kern:

    Nun, es ist etwas, das, wenn Sie nicht da wären, und ich weiß, dass Sie jung sind, also vor 21 Jahren noch nicht da waren, ich schätze jetzt, um vielleicht zu verstehen, mit welchen Softwareentwicklungsprozessen und Tools und mit was die meisten von uns damals konfrontiert waren, es wie eine wirklich offensichtliche Reihe von wirklich einfachen Werten erscheinen könnte. Wer könnte denken, dass an dem, was wir in das Manifest aufgenommen haben, etwas falsch ist? Aber damals gab es Dinge, unter denen ich als... Ich bin Luft- und Raumfahrtingenieur, also habe ich im Verteidigungsministerium gearbeitet und Dinge wie Jagdflugsimulationen, F-14-Flachdrehungen und die Arbeit mit einer Zentrifuge und so coolen Sachen gemacht. Und es unterliegt einer Werksstandardspezifikation, was wahrscheinlich für Waffensysteme, den Flugzeugbau und alle möglichen anderen Dinge Sinn macht. Aber sie hatten eine, und siehe da, für die Softwareentwicklung. Also gab es in Bezug auf den Softwareentwicklungsprozess eine sehr große, was ich als Schwerfälligkeit bezeichnen würde. Wir nennen ihn einen schwergewichtigen Prozess. Wasserfall war damals der gebräuchliche Begriff und wird wahrscheinlich auch heute noch verwendet.

    Und es gab viele, ich würde sagen, der Marketing-Moloch des Tages, einheitliche Prozesse von IBM und Rational, diese großen, die Safe sehr ähnlich waren. Wo es ein wirklich großes Werk ist, eine unglaubliche Menge an Informationen darin, aber ein sehr schwerer Prozess, obwohl alles, sagen wir, Sie würden es anpassen, es könnte sein, was Sie wollen. Ich habe zum Beispiel meinen eigenen, einfachen Prozess in REP abgebildet. Sicher. Aber die Realität war, dass wir es mit einer Art Schwergewicht wie dem Marktführer zu tun hatten, der einfach die Seele zermalmte und aus meiner Sicht das Geld der Steuerzahler verschwendete. Das war quasi mein Standpunkt, nun ja, ich bin Steuerzahler, ich werde dieses dumme Verfahren nicht einfach um des Prozesses willen durchführen. Das muss einen gewissen Wert haben, muss pragmatisch sein. Und siehe da, es gab eine Handvoll von uns, 17, die dort gelandet sind, aber es gibt eine Handvoll von uns, die leichtere Methoden praktizierten. Das Manifest war also wirklich eine Gelegenheit, zusammenzukommen und einige der Dinge zu entdecken, die man als Gemeinsamkeiten zwischen vielen verschiedenen leichten Praktiken bezeichnen könnte. Da war das XP-Kontingent. Ich habe dort zum Beispiel zum ersten Mal etwas über Scrum gelernt. Arie van Bennekum, ein guter Freund, hat uns etwas über DSDM beigebracht. Ich kann mich nicht einmal mehr erinnern, wofür es steht. Es war eine europäische Sache.

    Alistair und Jim Highsmith hatten, ich vergesse, quasi kristalline Methoden. Es gab also eine ganze Reihe anderer Verfahren, bei denen der Marketingzweig nicht ausgebrochen war, oder bei denen es nicht um den Produktionsstandard ging. Es ging also wirklich nur darum, was wir unter uns finden konnten, was ein gemeinsames Thema über all diese leichten Verfahren war. Es ging also wirklich darum, das herauszufinden.

    Amaar Iftikhar:

    Ihr kommt alle zusammen, die Prinzipien kommen irgendwie zum Tragen, und lasst uns ein bisschen vorspulen. Was war die erste Reaktion auf das ursprüngliche Manifest?

    John Kern:

    Ja, es war sogar lustig, dass die vier Werte, die vier Kugeln so einfach sind wie früher. Die Prinzipien kamen etwas später. Ich möchte sagen, wir haben beim Award-Wiki zusammengearbeitet, aber das Original... Wenn du zu Agile Uprising gehst, kannst du sehen, dass ich ein paar Artefakte hochgeladen habe, weil ich anscheinend eine Rudelratte bin. Und ich hatte die Originaldokumente, die Alistair wahrscheinlich ausgedruckt hat, weil er derjenige war... Er und Jim lebten dort in der Nähe von Salt Lake City. Es war also wie: „Hey, lass uns herkommen.“ Und wir gehen gerne Skifahren, also machen wir es hier. Also arrangierte er das Zimmer und alles. Also gibt es ein paar lustige Artefakte, die du finden kannst. Und die Art und Weise, wie es tatsächlich zustande kam, war eine erste Einführung in jeden von uns in unsere Methoden. Und ich glaube wirklich, ein Schlüssel, wir haben unser Ego an der Tür gelassen. Ich meine, ich war jünger. Onkel Bob, einige davon, er war bei Luminar, ich weiß, ich habe immer noch Zeitschriften in der Scheune, von denen er entweder Herausgeber war oder von denen er Autor war, für Leute, die sich nicht erinnern können, was Zeitschriften sind. Kleine Heftchen, die herauskamen. Onkel Bob sagte also, Oh, wow, das ist ziemlich cool.

    Und ich war nicht schüchtern, weil ich viel Erfahrung mit Schwergewichtsmethoden hatte. Also wollte ich unbedingt etwas dazu sagen... Weil ich ein paar Jahre zuvor meine eigene Lightweight-Methode veröffentlicht hatte. Ich hatte also viele Meinungen dazu, wie man den Herausforderungen eines großen Schwergewichtsprozesses aus dem Weg gehen kann. Der Höhepunkt, als wir aus der Tür gingen und nachdem wir uns die vier Werte ausgedacht hatten, war, glaube ich, dass Ward sagte: „Sir, möchten Sie, dass ich das ins Internet stelle?“ Und noch einmal, das ist 2001, also Punkt com und das Web ist sozusagen noch ziemlich neu. Und wir sagen alle, ja, klar, warum nicht? Was zur Hölle, kann nicht schaden. Wir haben etwas, wir können es genauso gut veröffentlichen. Ich glaube nicht, dass jemand zu einer Person gesagt hat: „Oh ja, das wird die Welt aus den Angeln heben, weil wir so großartig sind.“ Und wir wollten die Welt mit all dieser wunderbaren Weisheit salben. Ich glaube also nicht, dass irgendjemand dachte, dass so viel passieren würde.

    Amaar Iftikhar:

    Ja. Also, was hast du zu der Zeit gedacht? Also, wie wären die Prinzipien, die ihr gemeinsam ausgedacht habt, vielleicht nur für das Team zum Mitnehmen? Jeder, der da war? Was war der Plan zu der Zeit?

    John Kern:

    Ich denke, es war eine gängige Praxis. Wie ich schon sagte, es gab andere Gruppen, die sich oft trafen und kleine Konsortien oder kleine Zusammenkünfte veranstalteten und dann etwas veröffentlichten. Also ich denke, es war einfach, oh ja, das ist normal, dass man einige Zeit miteinander verbracht hat und Dinge aufgeschrieben hat, man könnte sie genauso gut veröffentlichen. Also ich denke, es war nicht tiefer als das, außer Bob, ich glaube, Bob könnte sagen, dass er eine Art Manifest oder irgendein Dokument herausbringen wollte, denn ich denke, das ist, was diese Art von... Ich war nie auf einer dieser Zusammenkünfte, aber weißt du, du konntest sehen, dass sie Dinge veröffentlicht haben. Ich habe das Gefühl, es war einfach etwas so Unschuldiges wie, nun, wir haben geredet, einige Dinge aufgeschrieben, könnten es genauso gut teilen.

    Und dann die Prinzipien, es gab viele verschiedene Praktiken im Raum. Also, ich würde sagen, das Schöne an der Werte-Seite ist, dass Demut an oberster Stelle steht, dass sie immer noch aktiv ist. Wir decken nichts auf, ihr alle Bauern, wir haben alles herausgefunden. Nein, wir decken es immer noch auf. Und die andere Sache ist, indem ich es tue, weil ich immer noch ein aktiver Programmierer bin. Und außerdem schätzen wir das auf der linken Seite mehr als auf der rechten Seite. Manche Leute mögen sagen, es ist ein bisschen zweideutig oder etwas verschwommen, aber das ist auch ein Zeichen von Demut und dass es nicht A oder B ist. Und es ist wirklich verschwommen, und Sie müssen Ihren Kontext genug verstehen, um diese Dinge anwenden zu können. Aus der Sicht der Auftragsvergabe durch das Verteidigungsministerium waren mir sicherlich drei der vier Kugeln wirklich wichtig, weil ich gelernt habe... Klar, wir haben das Verteidigungsministerium beauftragt. Aber es ist viel wichtiger, eine Beziehung zum Kunden aufzubauen, als es ist... Denn wenn Sie den Vertrag abgeschlossen haben, haben Sie bereits verloren, was mit dem Aufbau einer Beziehung zum Kunden, dem Einzelnen einhergeht.

    Und einer von Peter Codes, als wir mit Kunden und so weiter gearbeitet haben, war eines unserer Mantras, häufig greifbare Arbeitsergebnisse, auch bekannt als funktionierende Software. Man kann viel zeichnen und neun Monate lang Anwendungsfälle durchführen, aber wenn nichts läuft, ist das hübsch. Ich schätze, es ist riskant, dass man nichts, noch keine funktionierende Software hat. Es war also wirklich, glaube ich, eine Gelegenheit, die Tatsache mit anderen zu teilen, dass einige Leute zwei Wochen und andere einen Monat lang nachgedacht haben. Sogar einige der Druckprinzipien wiesen sozusagen eine ziemlich große Flexibilität auf. Ich denke, es ist wirklich wichtig, das zu beachten.

    Amaar Iftikhar:

    Ja, nein, absolut. Und es macht Sinn. Haben Sie oder jemand anderes, der zu dieser Zeit im Raum war, sich jemals vorgestellt, welche Auswirkungen die dort geleistete Arbeit flussabwärts haben würde?

    John Kern:

    Nicht dass ich wüsste. Das wusste ich bestimmt nicht. Ich erinnere mich, dass ich in meiner Karriere ein paar Mal reingekommen bin und ein paar Diagramme gesehen habe, als ich für die Firma Together Soft gearbeitet habe, und wir haben coole Sachen gebaut und ich habe gesehen, dass die Leute einige der... Oh ja, ich erinnere mich, dass ich ein Diagramm an ihrer Wand gemacht habe. Das ist irgendwie cool. Aber bei weitem nicht, wie demütigend und irgendwie befriedigend es ist. Vor allem würde ich sagen, wenn ich in Indien, Kolumbien oder Griechenland bin, scheint es fast so, als ob sie eher bereit sind, emotional damit umzugehen. Aber die Menschen sind es, es ist fast so, als wären sie durch dieses Dokument befreit worden. Und in gewissem Sinne ist das wirklich, wirklich winzig, wenn man es mit der größtmöglichen Demut sagt. Ein bisschen wie die Unabhängigkeitserklärung und die Tatsache, dass eine Handvoll Menschen... Und die Verfassung der Vereinigten Staaten. Eine Handvoll Menschen trafen sich in einem Moment, was sich nie wieder wiederholen sollte, und schufen etwas, das sozusagen auf die Welt geworfen wurde, das ein enormes Maß an individueller Freiheit und Zuversicht entfesselte, entfesselte, entfesselte, entfesselte, entfesselte, entfesselte, entfesselte, entfesselte, entfesselte, Dinge zu tun. Und ich glaube, auf sehr kleine, ähnliche Weise hat das Manifest genau das bewirkt.

    Amaar Iftikhar:

    Wie Sie bereits erwähnt haben, gab es einen Zeitpunkt, an dem das Manifest entwickelt wurde, und das ist fast 20 Jahre her. Jetzt haben sich die Arbeitsweise und die Arbeitswelt drastisch verändert. Also, was sind deine Gedanken dazu? Siehst du eine weitere Version kommen? Denken Sie, dass bestimmte Aktualisierungen vorgenommen werden müssen? Denken Sie, es ist ein zeitloses Dokument? Ich würde gerne deine Gedanken dazu hören.

    John Kern:

    Ja, das ist eine gute Frage. Ich persönlich finde es zeitlos und ich freue mich über andere Leute, die andere Dokumente erstellen. Und das haben sie. Alistair hat The Heart of Agile, Josh Kerievsky hat Modern Agile.

    Es gibt ein paar Variationen eines Themas und verschiedene Dinge, über die man nachdenken kann, was ich großartig finde. Denn ich glaube, im Gegensatz zur US-Verfassung, die einen Mechanismus zur Selbständerung vorsah, brauchten wir das nicht. Und ich glaube, es hat die Essenz dessen erfasst, wie Menschen zusammenarbeiten, um etwas Wertvolles zu produzieren. Hauptsächlich Software, denn das ist es, woraus wir zum Üben gekommen sind, ist die Softwareerfahrung. Aber es braucht nicht viel Fantasie, um das Wort Software durch Produkt oder so zu ersetzen und trotzdem viele der vorhandenen Werte anzuwenden, mit sehr, sehr geringfügigen Anpassungen vielleicht, weil sich häufig greifbare Arbeitsergebnisse ergeben.

    Es muss vielleicht Modelle geben, denn du wirst keinen Wolkenkratzer bauen und ihn abreißen und sagen: „Oh, das war nicht ganz richtig“ und ihn dann wieder bauen. Nichtsdestotrotz gibt es Variationen, wie Sie häufig Ergebnisse anzeigen können. Ich denke also, dass es im Großen und Ganzen zeitlos ist. Und ich würde jeden herausfordern. Was stimmt nicht damit? Weisen Sie 20 Jahre später auf etwas hin, das irgendwie nicht stimmt. Und ich glaube, das ist das Genie dahinter, über das wir gestolpert sind... Und wahrscheinlich, weil die meisten von uns Objektmodellierer waren, ist das eines der Dinge, in denen wir wirklich gut sind, nämlich die Essenz eines Systems in die kritischsten Teile zu zerlegen. Genau darum geht es beim Modellieren. Ich denke also, wir sind irgendwie von Natur aus zu den Kernbereichen vorgedrungen, die das ausmachen, was es heißt, Software mit Menschen, Prozessen und Werkzeugen zu produzieren. Und wir haben es aufgeschrieben. Deshalb finde ich es zeitlos.

    Amaar Iftikhar:

    Ja, absolut nicht. Ich denke, das war eine wirklich gute Erklärung dafür, warum es zeitlos ist. Ich denke, eines der Prinzipien, die mir bei einer Art moderner hybrider oder flexibler Arbeitsgestaltung in den Sinn kommen, ist eines der Prinzipien, in denen über die Bedeutung von persönlichen Gesprächen gesprochen wird. Und in einer heutigen Welt, in der viele Gespräche nicht physisch von Angesicht zu Angesicht stattfinden, finden sie möglicherweise auf Zoom statt. Denken Sie, dass das immer noch gilt?

    John Kern:

    Ja, ich denke, was wir herausfinden werden mit... Remote war sozusagen ferngesteuert, vor 20 Jahren. Ich habe mit einem Team von Entwicklern in Russland zusammengearbeitet und wir hatten genug Vertrauen und physische... Ich würde jeden Monat dorthin reisen. Das Team war so aufgebaut, dass wir genug Vertrauen in die Kommunikation hatten, sodass wir aufgrund der unterschiedlichen Zeitzonen letztendlich asynchron arbeiten konnten. Und ich war an der Ostküste. 7:00 Uhr in den USA war vielleicht 15:00 Uhr in Russland, wenn ich mich erinnere. St. Petersburg. Wir konnten die Distanz also überwinden, aber das echte Leben ist kaum zu übertreffen. Und oft habe ich manchmal sogar ein bisschen mit Ron Jeffries gestritten, sodass man auf der einen Seite sagen könnte, dass das Beste, was man tun kann, persönlich ist. Aber auf der anderen Seite könnte ich argumentieren, dass ein bisschen Abgeschiedenheit die Dinge ausmacht... Du musst etwas ausführlicher sein, möglicherweise etwas präziser, aber auch ein bisschen ausführlicher. Etwas entspannter mit... Du könntest ein paar Pässe nehmen, um etwas zu bekommen, nur weil, ich meine, in der Nacht vergehen zwei Zeitzonen. Aber das beruhte auf einigen oft ersten persönlichen Treffen, und dann konnte man aus der Ferne gehen und trotzdem erfolgreich und hocheffektiv sein.

    Deshalb finde ich es wichtig, dass Teams nicht einfach sagen, dass sie immer noch alles können. Und Zoom ist zugegebenermaßen viel besser als vor 20 Jahren. Zoom bekommt, zumindest kann man ein Gesicht sehen. Aber nichts ersetzt den menschlichen Kontakt. Und ich denke, auch für das Wohlbefinden ist menschlicher Kontakt wichtig. Deshalb würde ich immer noch sagen, dass der Aspekt der Interaktion im Manifest immer noch am besten mit einer gesunden Dosis persönlicher Präsenz erfüllt wird. Und das ist quasi der Schlüssel zu den meisten Dingen in Agile. Für mich geht es um Pragmatismus und nicht nur darum, dogmatisch zu sein, sondern eher darum, was für uns besser funktionieren könnte? Und sogar damit zu experimentieren, etwas ein bisschen auszuprobieren und zu sehen, wie das funktioniert. Also, auch wenn Sie das Manifest behandeln, sollten Sie es sozusagen agil behandeln.

    Amaar Iftikhar:

    Ja, absolut nicht. Das ist ein gutes Argument. In diesem Sinne: Was sind für Sie als Agile-Berater oder Agile-Experte die besten Praktiken oder was funktioniert, was funktioniert nicht für verteilte Teams?

    John Kern:

    Nun, ich denke, die Dinge, die mir in großen und noch kleineren Unternehmen begegnet sind, sind die, dass... Ich weiß nicht, ob das natürlich ist, Gott bewahre, wenn es natürlich ist, aber Tendenzen, die ich in einigen Unternehmen gesehen habe, Silos einzurichten, in denen Sie die Qualitätskontrolle, das UX, das Frontend, Sie das Backend sind, lassen meinen Kopf explodieren. Denn das bedeutet, Verzögerungen einzubauen und Kommunikationshindernisse einzubauen und eine Zusammenarbeit aufzubauen, die von Silo zu Silo weitergegeben wird, und nicht Zusammenarbeit. Davon habe ich also mehr gesehen. Und ich verstehe es, Sie möchten vielleicht eine Spezialität haben, aber dem Kunden ist das egal. Der Kunde will etwas vor der Tür haben. Wenn ich auftauche und ein Feature vom Stapel nehme, was meinst du damit, dass ich nur einen Teil davon machen kann? Das verstehe ich nicht. Und ja, ich weiß, ich bin kein Experte für alles, aber wir haben wahrscheinlich einen Experten, der herausfinden kann, was das Muster ist. Also ich finde diese Art von Trend, ich weiß nicht, ob es ein Trend ist, aber ich finde, das ist meiner Meinung nach ein Rückschritt. Und es ist besser zu versuchen, funktionsübergreifender und kollaborativer zu sein. Jeder versucht, daran zu arbeiten, das Feature auf den Markt zu bringen, und nicht nur zu versuchen, seinen kleinen Teil dazu beizutragen.

    Amaar Iftikhar:

    Ja, hundertprozentig. Ich denke, an Silos zu stoßen, ist ein großer Teil davon, agil zu sein, oder sogar digital zu sein. Und oft gibt es auch Abhilfemaßnahmen dafür, aber es ist viel schwieriger, praktisch damit umzugehen, es tatsächlich in einer Organisation umzusetzen, einem lebendigen Unternehmen, in dem es echte Menschen und Dynamiken gibt, mit denen man umgehen muss, und es gibt Richtlinien und Prozesse, die befolgt werden müssen. Ich denke, so allgemein Sie auch sein können, was ist Ihre Meinung als Agile-Berater für ein Unternehmen, das mit diesem Problem konfrontiert ist?

    John Kern:

    Eines der Dinge, die... Adaptiv ist das, wofür mein Kollege John Turley mir wirklich die Augen geöffnet hat. Ich nenne es eher die geheime Sauce oder das fehlende Stück in meiner Praxis. Und es hat mit der Denkweise des Einzelnen zu tun und mit dem, was wir vertikale Entwicklung nennen. Es klingt vielleicht wie komisches, flauschiges Zeug, aber es ist wirklich extrem wichtig. Und ich habe immer gesagt, Leute, Prozesse und Tools für, ich möchte sagen, seit Ende der Neunziger, wahrscheinlich für eine lange Zeit. Und in der ersten Phase konnte ich verstehen, warum ich manchmal einfach spektakuläre, extrem leistungsstarke Teams hatte und manchmal waren es einfach wirklich, wirklich gut, aber nicht immer der Funke und manchmal war es irgendwie, eh, das war ein bisschen meh. Und vieles davon hängt davon ab, worauf die Menschen in Bezug darauf liegen, wie sie ihre Bedeutung ausdrücken und welche Motivationsorientierung sie haben, Kommando und Kontrolle versus Autonomie.

    Was wir also tun, ist, dass wir gelernt haben, dass wir Menschen zunächst helfen können, zu erkennen, dass dies existiert, und Menschen mit so genannten Entwicklungspraktiken helfen können. Etwas, das, selbst der Satz, Sie haben ihn wahrscheinlich gehört, wie sichere Experimente. Scheitern oder etwas versuchen und scheitern. Nun, wenn du jemandem dafür den Kopf abhackst, weißt du was? Sie werden wahrscheinlich einfach ziemlich still bleiben und nur tun, was ihnen gesagt wird, nicht versuchen... Ich habe ein extrem hohes Maß an Autonomie in mir, also habe ich lange daran gelebt, besser um Vergebung zu bitten als um Erlaubnis zu bitten, und ich hatte immer das Gefühl, solange ich versuche, das Richtige zu tun, um erfolgreich zu sein und das Beste für das Unternehmen zu tun, werden sie mich wahrscheinlich nicht entlassen, wenn ich einen Fehler mache. Aber nicht jeder hat so viel Freiheit in der Art und Weise, wie er arbeitet. Sie müssen also als Management helfen, das zu etablieren, und das ist eine große Sache, mit der wir zusammenarbeiten, mit Teams.

    Und dann fangen wir auch mit dem Unterricht an. Falls Sie schon einmal Büroräume gesehen haben und wenn nicht, sollten Sie das tun, aber was machen Sie hier? Also, die Berater Bob und Bob kommen rein, die Effizienzberater, „Also Amaar, was machst du hier?“ Aber das ist wortwörtlich etwas, ob wir Teams dabei helfen, ein neues Produkt zu entwickeln, ist okay, was ist der Zweck? Was ist der Geschäftszweck dieses Produkts? Was machst du hier? Was willst du mit diesem Produkt machen? Welchen Wert bietet es? Das Gleiche gilt für alles, mit dem Sie als Team arbeiten. Und das ist der Grund, egal ob es sich um Software handelt, die eine Funktion hervorbringt, deren Ergebnis dem Kunden einen Mehrwert bietet, oder um ein Produkt. Aber der Punkt ist, wenn Sie das nicht verstehen, wird es dem Team jetzt wirklich schwer fallen, Entscheidungen zu treffen, die uns weiterbringen.

    Wenn du also allen hilfst zu verstehen, wofür wir hier sind, und dann versuchst, die Leute zu finden, die vielleicht all die verschiedenen Silos widerspiegeln, wenn du isoliert bist, aber all die verschiedenen Elemente. Wie kommen wir sozusagen von einer Idee zum Geld oder von der Idee zum Wert in der Hand des Kunden? Und schauen Sie sich das genau an. Weil es so viele Dinge gibt, die einfach irgendwie... Technische Daten schleichen sich oft in Softwarecodebasen ein. Und das Gleiche, wir sagen sozusagen die organisatorischen Schulden, das Gleiche kann passieren. Ihre Prozessverschuldung. Am Ende kannst du einfach sagen, alles klar, wir wollen, dass das Entwicklungsteam schneller wird, John und Co., kannst du reinkommen und uns helfen, uns zu coachen? Wir wollen agil werden. Sicher, okay, ja. In Ordnung. Wir krempeln die Ärmel hoch, schauen uns um und nach einer ersten Art von Wertstromansicht sagen wir, warte, es tut mir leid, aber da ist ein kleiner Keil, es sind ungefähr 15%, das ist die Entwicklung. Und dann haben Sie die 85% damit verbracht, darüber nachzudenken.

    Tun wir so, als könnten wir die Geschwindigkeit der Entwicklung verdoppeln. Welches war ursprünglich der... Ja, wir brauchen die Entwickler, um schneller zu programmieren oder so. Das ist ein Klassiker. Und nein, tust du nicht, du musst aufhören, diesen ganzen Blödsinn von vorne zu machen, der einfach verrückte, arschgroße Wasserfallprojekte mit mehreren Absprachen ist. Und tatsächlich, eine der Abmeldungen, oh mein Gott, sie findet nur einmal pro Woche statt, und wenn Sie dann einen Tippfehler haben, werden Sie abgelehnt. Du kommst nicht für einen anderen zurück... Bist du verrückt? Du hast acht Monate damit verbracht, dich für acht Wochen zu entscheiden. Entschuldigung, es sind nicht die acht Wochen. Also Dinge wie diese, was ich jedem empfehle, sich selbst zu überprüfen, ist zu versuchen... Wenn Sie sich Sorgen um Ihr Team machen, können Sie es besser machen, indem Sie einfach versuchen, aufzuschreiben, wie Ihr Prozessschritt aussieht und was ein typischer Zeitrahmen ist?

    Wie viel Zeit investieren Sie in die... Weil Leute oft Dinge in Sprints zusammenfassen. Das ist ein Stapel, warum legst du Dinge in einen Stapel? Oder sie haben riesige Probleme. Nun, das ist die große Menge. Es gibt also viele, oft tief hängende Früchte. Aber was Sie sagen, es ist oft eingedrungen, so arbeiten wir und niemand fühlt sich in der Lage, uns zu ändern oder sogar innezuhalten und zu schauen, wie wir arbeiten. Also ich denke, das ist der Punkt, an dem wir normalerweise beginnen. Schauen wir uns an, wie Sie heute tatsächlich arbeiten. Und während wir das machen, kannst du dein Bauchgefühl ausplaudern, du kannst uns all die Dinge sagen, die weh tun und die schmerzhaft sind, und dann werden wir versuchen, einen besseren Weg zu finden, auf den wir hinarbeiten können, im Sinne einer effektiveren Arbeit. Denn unser Ziel ist es, Teams dabei zu helfen, Wege zu finden, um sinnvollere und unterhaltsamere Arbeit zu leisten. Weil es viel Spaß macht, wenn es klickt und wenn Sie in einem guten Team sind und den Kunden ein Lächeln ins Gesicht zaubern, ist es schwer, sich fast von der Arbeit fernzuhalten, weil sie so viel Spaß macht. Aber wenn es das nicht ist, wenn es Plackerei ist und Sie nur ein Rädchen im Getriebe sind und Dinge Monate brauchen, um aus der Tür zu kommen, ist es ein Job. Es macht nicht so viel Spaß.

    Amaar Iftikhar:

    Ja. Viele der Punkte, die Sie dort erwähnt haben, haben bei mir großen Anklang gefunden, und die häufigsten Schmerzpunkte. Es klingt, als hättest du irgendwie alles gesehen. Übrigens, wenn Sie noch keine Büroräume gesehen haben, müssen Sie sie sich unbedingt ansehen. Es ist ein wirklich guter. Sie haben jetzt viel über die Herausforderungen gesprochen, mit denen ein verteiltes Team konfrontiert ist. Jetzt möchte ich es umdrehen und Sie fragen, wie das perfekte verteilte Team heute aussieht, das agile Werte lebt und atmet?

    John Kern:

    Ja. Ich weiß nicht, ob du jemals so etwas haben kannst, ein perfektes Team. Ich würde sagen, ich greife auf die Typen von verteilten Teams zurück, mit denen ich gearbeitet habe, und das geht auf die späten Neunziger zurück. Also ich mache das schon sehr, sehr lange. Ich habe es wirklich nur remote gemacht, egal ob mit Entwicklern in Russland oder unten in North Carolina oder an ähnlichen Orten. Und ich glaube, das Geheimnis war eine Kombination aus persönlichen... Wenn Sie als Gruppe irgendwohin gehen möchten, gibt es Dinge, die Sie tun können, um das Eis zu brechen, um einige, was Sie als Teambuilding-Aktivitäten bezeichnen könnten, zu organisieren.

    Und nicht nur, hey, lass uns einen Hochseilgarten machen und uns gemeinsam zu Tode erschrecken lassen. Sondern auch Dinge, die sich darauf beziehen, warum wir hier sind, was versuchen wir zu erreichen? Und lassen Sie uns darüber sprechen, ob es das Produkt ist, das wir herstellen wollen, und das als Gelegenheit nutzen, uns um etwas zu verbinden und genug Fleisch an den Knochen zu bekommen, genug Skelette davon, wie es aussehen könnte. Weil es gute Möglichkeiten gibt, anzufangen und eine gute Grundlage zu haben. Und das ist Teil dessen, was ich seit Jahrzehnten praktiziere. Wenn Sie die Dinge richtig einrichten und verstehen, dass gerade genug Anforderungen vorliegen, verstehen Sie... Und ich mache viel Domänenmodellierung mit UML und solche Dinge. Ich verstehe einfach, was der Problembereich ist, den wir zu lösen versuchen, um die angestrebten Ziele zu erreichen, und ein Gefühl für die Architektur zu bekommen, die wir wollen. All diese Dinge sind also gemeinsame Anstrengungen.

    Wenn Sie also genug von einem Ausgangspunkt haben, an dem Sie zusammengearbeitet haben, kommen Sie rein und, sagen wir, Sie mussten sogar irgendwo eine Wohnung mieten, weil niemand in der Nähe des Büros wohnte, also sind Sie alle irgendwohin geflogen. Ich meine, das ist meiner Meinung nach gut angelegtes Geld. Weil damit das Fundament beginnt. Wenn Sie sozusagen Brot gebrochen oder ein paar Bier getrunken haben oder zusammen programmiert und Dinge gemacht haben und dann zu Ihren entfernten Büros zurückkehren, um die nächsten Schritte zu unternehmen und dann zu erkennen, wann Sie sich vielleicht wiedersehen müssen. Es ist also wirklich wichtig, zu verstehen, wie wichtig es ist, diese Beziehungen frühzeitig aufzubauen, damit Sie unverblümt sprechen können. Und ich habe ein paar gute Leute, die seit etwa 2006 eine Produktions-App für Feuerwehrleute betreiben.

    Amaar Iftikhar:

    Ja, sehr cool.

    John Kern:

    Und dieser Freund, mit dem ich gearbeitet habe, wir stehen uns so nahe, dass wir... Das macht unsere Gespräche aus, wir müssen nicht um den heißen Brei herumreden, wir müssen uns keine Sorgen machen, jemanden zu beleidigen, wir kommen einfach, bumm, auf den Punkt. Weil wir wissen, dass wir die Kinder des anderen nicht als hässlich bezeichnen. Wir versuchen nur, schnell etwas zu erledigen.

    Und der Aufbau einer solchen Beziehung erfordert Zeit und Mühe und Zusammenarbeit. Und das ist meiner Meinung nach ein gutes, erfolgreiches, verteiltes Team. Man muss von Zeit zu Zeit zusammenkommen und diese Beziehungen aufbauen und wissen, wann man vielleicht wieder zusammenkommen muss, wenn etwas ein Problem ist. Aber ich denke, der Schlüssel zum Erfolg ist, dass es die Zeit verkürzt. Weil Sie vielleicht von Dingen wie den Gruppenformen gehört haben, wenn das die Leistung auf der Y-Achse ist, die sie bilden und sie sich auf einem bestimmten Leistungsniveau befinden, dann müssen sie stürmen, bevor sie wieder normal werden und bevor sie anfangen, Höchstleistungen zu erbringen. Es ist also diese Form, Storm. Du wirst schlimmer, wenn du stürmst. Und stürmen bedeutet, wirklich zu verstehen, wo wir stehen. Und wenn wir darüber streiten, sollte das meiner Meinung nach nicht Erbschaft sein, Amaar. Und dann sagst du: „Oh Bullshit, es ist wirklich...“

    Und noch einmal, wir sind nicht persönlich, aber wir lernen die Sichtweisen des anderen kennen und wir lernen, respektvolle Debatten zu führen und sozusagen einige Argumente vorzubringen, um an den besseren Ort zu kommen. Und ich habe in einigen Unternehmen gearbeitet, die Angst vor Stürmen haben, und es fühlt sich an, als ob man nie leistungsstark ist.

    Jeder ist zu höflich. Es ist wie, komm schon. Und ich liebe es, mit meinen russischen Kollegen zusammenzuarbeiten. Es war ihnen scheißegal, ob ich einer der Gründer war. Und ich bin froh, denn ich will kein Privileg, ich will so etwas nicht. Nein, lass uns das ausfechten. Mögen die besten Ideen gewinnen. Dorthin willst du kommen. Und wenn du nicht dorthin kommst, weil du nicht genug von einer Beziehung hast und du dazu neigst, die Dinge, die gesagt werden mussten, nicht zu sagen, weil du höflich bist, dann wird es wirklich lange dauern, bis du erfolgreich bist. Und das ist eine Menge Geld und das ist eine Menge Erfolg, und die Leute könnten gehen.

    Ich denke, das Wichtigste ist, wenn man remote ist, ist das okay, aber die schiere Abgeschiedenheit ist eine echte Herausforderung. Und du musst irgendwie herausfinden, wenn du nicht zusammenkommen kannst, um zu lernen, wie man sich formt und stürmt und diese Bindungen von Angesicht zu Angesicht aufbaut, dann musst du über Zoom herausfinden, wie das geht. Weil du es tun musst, denn wenn du es nicht tust, wenn du nie Worte hast, dann glaub mir, du bist immer noch nicht leistungsstark.

    Amaar Iftikhar:

    Ja, ich habe irgendwie das Gefühl, dass es den Kandidaten auf dem Markt jetzt fast ein Wettbewerbsvorteil ist, völlig remote zu sein, weil es ein Kampf um Talente ist. Aber wenn ich das richtig verstehe, sagen Sie, dass das persönliche Element so wichtig ist, um wirklich gute Leistungen zu erbringen, und diese Ideen widersprechen sich meiner Meinung nach irgendwie.

    John Kern:

    Ja. Und nochmal, da ich seit Ende der Neunziger abgelegen war, mache ich das schon lange. Und nach Russland zu pendeln ist der längste Weg, den ich je gemacht habe, seit drei Jahren. Ich meine, das ist ein verdammt langer Flug, um mehr als sieben Mal dorthin zu pendeln, oder was auch immer zur Hölle es war. Wie dem auch sei, ich habe immer gesagt, dass Fernsein nicht jedermanns Sache ist, denn das ist es wirklich nicht. Ich meine, du musst wissen, wie man arbeitet, ohne dass jemand in der Nähe ist, und arbeiten kann. Ich meine, es hat seine eigenen Herausforderungen. Und ja, es mag ein Vorteil sein, aber ich denke, Sie müssen sich die möglichen Vorteile ansehen und auch herausfinden, kann ich sie zusammenfassen in... Es muss nicht alles oder nichts sein. Und ich denke, das kann ein leichter Fehler sein, vielleicht ist es, alles klar, cool, wir müssen keine Büroräume haben. Das sind eine Menge Einsparungen für das Unternehmen. Ja, aber vielleicht bedeutet das, dass Sie einige Remote-Arbeitsplätze für gelegentliche Zusammenkünfte benötigen, oder finden Sie es heraus.

    Aber ja, ich denke sogar... Und bestimmte Unternehmen könnten anders funktionieren. Zu Beginn der Entwicklung eines Produkts wünsche ich mir eine intensive Zusammenarbeit und ich möchte an einen Punkt kommen, an dem es fast so weit ist, ich habe das Gefühl, dass das Produkt so läuft, dass, wenn man die Dinge erst einmal ins Rollen gebracht hat und irgendwie aufgestanden ist, etwas Schwung bekommt, es jetzt am schwierigsten ist, vor einem agilen Team zu stehen, egal ob persönlich oder remote. Sobald die Dinge rollen und schaukeln und es so ist, als würde alles klicken, kannst du einfach die verbleibenden Funktionen wie Bum, Bum, Bum, Bum herausschlagen. Ja, okay, dann müssen wir wahrscheinlich...

    Es sei denn, wir haben Möglichkeiten, uns zu paaren oder solche Dinge. Ich sage, wenn wir zusammen sind, ist Mobbing einfacher. Ich bin sicher, es gibt Möglichkeiten, das aus der Ferne zu machen, aber in einem Raum zu sein, ich weiß nicht, es ist viel einfacher, als sich über Zoom zu koordinieren. Du, hey, da ist dieses Problem, lass uns nach dem Standup alle hier rumhängen, weil wir einfach darüber moben werden. Es braucht also nicht viel gegen alles, was weit entfernt ist, es gibt ein bisschen mehr, okay, wir müssen uns abstimmen, und sogar verschiedene Zeitzonen werden noch schlimmer. Also ja, lassen Sie sich nicht davon mitreißen, dass Fernzugriff das Ende aller Dinge ist. Weil ich das Gefühl habe, dass es einen geben wird... Ich wette, es wird eine Gegenreaktion geben.

    Amaar Iftikhar:

    Und ich nehme das zurück, weil ich von Agile komme, der Person, die das täglich tut und Teams hilft, agil zu werden. Ich glaube Ihnen auf jeden Fall beim Wort. Und aufgrund meiner Erfahrung habe ich auch gesehen, dass nichts wirklich besser ist als eine gute Whiteboarding-Sitzung. Das ist wirklich schwer online zu replizieren. Ich meine, wir haben diese tollen Tools, aber nichts ahmt die reale Erfahrung nach, nur ein einfaches Whiteboard und einen Marker in der Hand zu haben. Diese Kommunikation ist so mächtig.

    John Kern:

    Toller Punkt. Stimmt, denn ich hatte gerade bei der einen Firma, bei der ich fünf Jahre lang gearbeitet habe, wir haben ein hochentwickeltes, auf Bestellung entwickeltes Verkaufswerkzeug für die Pumpenherstellung gemacht für... Es war also meine Lieblingswelt, weil sie meine Strömungsdynamik als Luft- und Raumfahrtingenieur mit meiner Liebe zur Entwicklung von SaaS-Produkten und der Entwicklung neuer Software und ähnlichem verband. Und selbst wenn wir noch ein Kind hatten, interviewten wir an der Lehigh University und wir hatten einige junge Absolventen, die mit uns arbeiteten und sie mit einbeziehen konnten, und da war ein Raum hinter meinem Laufband, und wir gingen hinein, wir veranstalteten Jam-Sessions zum Modeln und Entwickeln neuer Features. Und Mann, du hast recht. Nur diese viszerale dreidimensionale Erfahrung. Ja, Miro geht es großartig. Oder irgendein anderes Werkzeug, aber ja, es ist nicht dasselbe. Du hast absolut recht. Das ist ein gutes Argument. Das bringt mich fast dazu, mich nach den guten alten Zeiten zu sehnen. [unhörbar 00:42:04]

    Amaar Iftikhar:

    Ich denke, die guten alten Zeiten gibt es immer noch. Ich denke, selbst jetzt war es eine erfrischende Zeit für mich, bei Easy Agile zu sein. Ich bin jetzt erst seit knapp zwei Monaten hier. Und es gibt eine starke persönliche Dynamik. Und auch hier ist es optional. Wenn die Leute aus der Ferne oder hybride Menschen sind oder ab und zu pendeln müssen, ist das eine sehr verständnisvolle Umgebung. Aber wenn Sie einmal im Büro oder persönlich sind, spüren Sie gewissermaßen den Effekt, den Sie beschrieben haben, und Sie sind motiviert, für den Endkunden etwas zu liefern. Du willst einfach nur zurückkommen. Es ist ein süchtig machendes Gefühl, ich möchte wieder persönlich sein und in Echtzeit persönlich zusammenarbeiten.

    John Kern:

    Das ist wunderbar gesagt, denn das ist... Eines der Unternehmen, mit dem wir in Südafrika zu kooperieren beginnen, sie stehen an einem Scheideweg, mit dem wir zu kämpfen haben, alle waren abgelegen, aber Mann, die paar Male, als wir zusammen waren, haben wir so viel erreicht. Und du beschreibst die Flamme, die Wärme, die entsteht, wenn man die Motten zur Flamme kommen lässt. Ich meine, es zu pflegen und dann die Flammen des Guten zu entfachen und die Leute dazu zu bringen, sich daran zu beteiligen und es zu genießen. Und manchmal, ja, ich muss zu Hause sagen, ich habe die Kinder oder den Hund, das ist auch okay. Aber die Option zu geben, glaube ich, ist unser Ziel. Und ich glaube den Unternehmen, die in der Lage sind, diese hybride Kultur aufzubauen, in der beide akzeptiert werden und weder das eine noch das andere vorgeschrieben wird, sondern ein so leistungsstarkes Team aufgebaut wird, das die Leute im Grunde dazu ermutigt, sich für die Dinge zu entscheiden, die zu diesem Zeitpunkt am sinnvollsten sind. Und ich denke, dass diese Unternehmen sozusagen das Sagen haben werden.

    Amaar Iftikhar:

    Ja, absolut. Es war so nett, mit dir zu chatten, John, und das hat mir wirklich Spaß gemacht. Ich möchte das Publikum mit einem Ratschlag für verteilte agile Teams von Ihnen abschalten. Wir haben viel über die Bedeutung der persönlichen Zusammenarbeit gesprochen. Wir haben über die Prinzipien des agilen Manifests gesprochen. Nun, was wäre der eine Ratschlag, wenn Sie an beide denken? Wenn Sie möchten, dass die Agile-Manifeste in verteilten agilen Teams lebendig und lebendig sind, welchen Ratschlag können Sie Unternehmen geben, die gerade die gleichen Probleme durchmachen? Was kannst du ihnen als letzten Ratschlag geben?

    John Kern:

    Nun, ich denke, ein Satz, den ich gerne verwende, um das Manifest festzuhalten, ist: „Kümmere dich um die Lücke“. In meiner Art von Wortspiel meine ich die Zeitlücke zwischen dem Ergreifen einer Handlung und dem Erhalt einer Antwort. Ob es darum geht, was machen wir mit dem Büro, was machen wir mit der Fernbedienung, was machen wir mit dieser Funktion, was machen wir mit dieser Codezeile? Der Zeitunterschied ist, es ist eine Art Metapher dafür, bescheiden genug zu sein, Dinge als Hypothese zu behandeln. Seien Sie sich Ihrer selbst also nicht so verdammt sicher, was das Büro angeht, ob es um das Büro geht, ob es um ein entferntes oder verteiltes Büro geht. Behandeln Sie die Dinge stattdessen als Hypothese. Seien Sie neugierig und experimentieren Sie sicher mit verschiedenen Methoden und sehen Sie, was funktioniert. Und hab keine Angst vor Veränderungen. Es ist auch keine lebenslange Haftstrafe, Sie müssen Ihr Unternehmen, Ihr Projekt oder Ihr Team für den Rest Ihres Lebens in eine Richtung führen. Nein. Sag es nicht dem Chef, aber Arbeit ist subventioniertes Lernen. Ich habe nie Leute verstanden, die immer wieder das Gleiche tun, weil sie keine Erlaubnis bekommen haben. Versuch es einfach. Das wäre also mein Abschiedssatz, wenn es darum geht, diese Entscheidungen zu treffen. Achten Sie auf die Lücke und seien Sie wirklich bescheiden, wenn es darum geht, Annahmen zu treffen, Ihre Hypothesen zu testen und die Zeitspanne zwischen dem Ergreifen von Maßnahmen und dem Erleben einer Reaktion zu verkürzen.

    Amaar Iftikhar:

    Oh, das ist großartig. Oh, danke. Ich wünschte wirklich, wir könnten das Band laufen lassen und einfach noch ein paar Stunden darüber reden, aber wir beenden es genau dort mit dem wirklich guten Ratschlag, mit dem du das Publikum verlassen hast. Jon, danke nochmal, dass du im Podcast warst. Und es hat uns wirklich sehr viel Spaß gemacht, Ihnen zuzuhören und aus Ihren Erfahrungen zu lernen.

    John Kern:

    Oh, es war mir ein Vergnügen. Jederzeit. Freue mich, noch ein paar Stunden zu reden, aber vielleicht nach ein paar Bieren.

    Amaar Iftikhar:

    Ja.

    John Kern:

    Außer dass es dein Morgen ist, mein Abend. Daran werde ich arbeiten müssen.

    Amaar Iftikhar:

    Ja.

    John Kern:

    Das freut mich, Amaar.

  • Podcast

    Easy Agile Podcast Ep.8 Gerald Cadden Strategischer Berater und SAFe-Programmberater bei Scaled Agile Inc.

    Sean Blake

    Gerald erzählte, dass Unternehmen bei der Implementierung agiler Methoden oft immer wieder vor den gleichen Herausforderungen stehen, aber die eigentliche und wichtigste Herausforderung ist die Überwindung einer festen Denkweise.

    „Gerald hilft großen Unternehmen dabei, besser zusammenzuarbeiten und gleichzeitig dafür zu sorgen, dass sich die Teams auf die Menschen und den Kunden konzentrieren. Ich werde mir diese Episode noch einmal ansehen.“

    Gerald hebt auch den Unterschied zwischen Beratern und Coaches hervor und wie wichtig es ist, gute Mentoren zu haben + mehr

    Ich habe diese Folge geliebt und ich weiß, dass du es auch tun wirst!

    Abonniere unbedingt, genieße die Folge 🎧

    Transkript

    Sean Blake:

    Hallo und willkommen zu dieser Episode des Easy Agile Podcasts. Sean Blake ist heute hier bei dir. Und wir haben einen großartigen Gast für Sie, es ist Gerald Cadden, strategischer Berater und Trainer für SAFe-Programmberater bei Scaled Agile, Inc. Gerald ist ein erfahrenes Unternehmen, IT-Experte, strategischer Berater und Trainer für Scaled Agile Program Consultant (SPCT) bei Scaled Agile. Danke, Gerald. Willkommen zum Easy Agile Podcast. Es ist wirklich toll, Sie heute als Gast zu haben, und vielen Dank, dass Sie ein wenig Zeit mit uns verbracht und Ihr Fachwissen im Easy Agile Podcast mit unserem Publikum geteilt haben.

    Sean Blake:

    Also ich bin wirklich interessiert und ich interessiere mich für diese Geschichte, die... Für all die Gäste, die wir beim Podcast haben, aber kannst du mir ein bisschen über deine heutige Karriere erzählen? Ich finde, dass die Leute ihren Weg zu diesen agilen Rollen oder in die Agile-Branche durch so viele verschiedene Arten von Jobs in der Vergangenheit gefunden haben. Manche Leute waren früher Klempner oder Handwerker, oder sie arbeiteten im Finanzwesen oder im Bankwesen. Wie haben Sie Ihren Weg gefunden, bei einem Unternehmen wie Scaled Agile zu arbeiten?

    Gerald Cadden:

    Guten Morgen, Sean. Danke, dass ich hier sein durfte, Leute. Ich freue mich sehr, heute hier bei euch zu sein. Karrieresachen sind immer eine interessante Frage. Ich bin 53 Jahre alt und wenn ich zurückblicke, frage ich mich, wie ich dahin komme, wo ich bin? Und oft kann man sich nur eine Reihe glücklicher Ereignisse ansehen. Und ich habe in Schuhgeschäften gearbeitet und dann habe ich beschlossen, etwas in meinem Leben zu tun. Ich habe ein IT-Diplom gemacht, dann einen Abschluss gemacht und angefangen, in der IT-Seite zu arbeiten. Ich habe quasi als Entwickler angefangen, weil dort das Geld war und du da hin wolltest. Ich bin nicht lange als Entwickler geblieben. In Ordnung. Alles klar. Ich war ein schrecklicher Entwickler, also war ich nicht gut darin. Es war frustrierend.

    Gerald Cadden:

    Ich habe vor dem Verkauf angefangen und das hat mich dazu gebracht, Geschäftsanalysen zu machen. Die BA-Arbeit hat mir sehr gut gefallen, weil ich mit Leuten arbeiten und Veränderungen sehen konnte. Ich konnte mit den Entwicklern arbeiten, konnte aber trotzdem direkt mit dem Kunden zusammenarbeiten, was für mich viel interessanter war. Also verbrachte ich viel Zeit in BA mit der Entwicklungsarbeit und der Neugestaltung von Geschäftsprozessen, meinem Übergang zu einem rationalen, einheitlichen Prozess. Als es das noch gab, habe ich unzählige Stunden damit verbracht, Anwendungsfälle für Ihre E-Mail-Diagramme zu schreiben und die Leute davon zu überzeugen, wie die Änderungen an diesen vorgenommen werden können. Und dann kam Agile und ich musste einen kompletten Gehirnwechsel vornehmen. All diese Dinge, die ich als BA gelernt hatte und von denen ich abhängig war, verschwanden plötzlich, weil Agile das nicht als direkte Arbeitsweise verlangte. Das musste im Hintergrund ablaufen, wenn man es wollte, und es war eher eine Zusammenarbeit.

    Gerald Cadden:

    Ungefähr 2004, 2005 fing ich an, viel mehr mit Agile zu arbeiten, bis ich in den USA lebte. Dort sammelte ich meine agilen Erfahrungen und blieb dort für eine lange Zeit. Ich habe großartige Erfahrungen gesammelt und bin dann etwa 2011 zur Arbeit mit SAFe übergegangen. Der Auslöser dafür war, dass ich für das große Finanzunternehmen in New York mit einem Team dort gearbeitet habe. Und wir waren dabei, eine umfangreiche Methode für sie neu zu entwickeln, um Agile in großem Maßstab zu implementieren. Als wir 2011 auf einer Agile-Konferenz an einem Seminar teilnahmen, sah Dean Leffingwell eine Präsentation über SAFe und schaute einfach auf und sagte: „Nun, wir können aufhören, an unserer Methodik zu arbeiten. Es ist erledigt.“

    Gerald Cadden:

    Also kaum nach diesem Treffen rannte ich nach draußen und ging mit Dean Leffingwell los, weil ich wollte, dass er sich meine Diagramme und alles ansieht und mir eine Bestätigung gibt, dass ich das Richtige tue. Dean hat ein sehr offenes Gesicht und er zog sein offenes Gesicht und sah mich an und sagte einfach: „Weißt du was? Einfach SAFe benutzen?“ Und ich sage: „Ja, das werden wir.“ Und so begann ich meine SAFe-Reise zu dieser Zeit und wir haben dieses Finanzunternehmen gegründet und seitdem bin ich auf dieser Reise.

    Sean Blake:

    Bringen Sie uns also zurück vor 10 Jahren ins Jahr 2011. Und Sie arbeiten bei diesem Finanzunternehmen, Sie haben von diesem Konzept von SAFe gehört, und zwar zum ersten Mal, als Sie damit begonnen haben, es umzusetzen. Wie haben die Mitarbeiter dieses Unternehmens darauf reagiert, dass Sie diese neue Denkweise in diesen neuen Rahmen eingeführt haben? Es hörte sich an, dass Sie die Diagramme zu den Frameworks und den Konzepten, die sich in Ihrem Kopf herausbildeten, bereits hatten. Fanden Sie das für einen einfachen Prozess? Ich glaube, ich kenne die Antwort bereits, aber wie komplex war es, SAFe zum ersten Mal in einer Organisation dieser Größenordnung einzuführen?

    Gerald Cadden:

    Ja, das ist ein sehr großes Finanzunternehmen, ein sehr altes Finanzunternehmen, also eine sehr traditionelle Arbeitsweise. Interessant sind also die gleichen Herausforderungen, vor denen SAFe heute steht, schon vor der Gründung von SAFe. Es gab also immer noch dieselben Herausforderungen wie bei früheren Managementansätzen, die versuchten, zu schnelleren Arbeitsweisen überzugehen. Während wir also wie wild in Visio Diagramme zeichneten und versuchten, Modelle zu erstellen, die die Menschen verstehen, war es schwierig, ein Kontinuum an Wissen und Bildung zu schaffen, das die Menschen dazu brachte, von ihrer Denkweise zu der Denkweise überzugehen, die wir uns für sie wünschten. Und für mich und das Team, mit dem ich gearbeitet habe, war es eine Reise, die sich ständig weiterentwickelt hat. Ich arbeite mit einem wirklich großartigen Mann zusammen und sein Name ist Algona, ein sehr, sehr kluger Mann.

    Gerald Cadden:

    Und so kratzen wir uns beide ständig am Kopf, wie wir das Management dazu bringen können, seine Meinung zu ändern. Und wir haben uns auf Bildung konzentriert, aber es war immer noch eine große Herausforderung. Ich habe das Projekt abgeschlossen, so wie sie mit SAFe angefangen haben. Ich wechselte in das Unternehmen in eine andere Managementposition, sodass wir die Arbeit dort fortgesetzt haben. Michael Stump, er hat früher für Scaled Agile gearbeitet. Ich glaube, er arbeitet jetzt in einem anderen Unternehmen, aber er hat einen Großteil dieser Arbeit fortgesetzt und wirklich gute Arbeit geleistet und sie haben SAFe implementiert. Sie haben Änderungen vorgenommen, aber sie standen vor den gleichen Herausforderungen. Die Denkweise des Managements überwand die Abkehr von den Silos hin zu einer stärker netzwerkstrukturierten Organisation. Nur die Tools, nur die einfachen Dinge waren immer noch eine Herausforderung, und es gibt auch heute noch eine Herausforderung. Die Art der Organisation entwickelt sich also auch in der modernen agilen Welt immer noch weiter.

    Sean Blake:

    Sie haben dort erwähnt, dass ein Teil der Herausforderung in den Bereichen Denkweise und Bildung liegt. Haben Sie irgendwelche Abkürzungen gefunden, um die Denkweise eines Teams zu ändern? Die Art und Weise, wie sie an ihre Arbeit herangehen, wie sie die Zusammenarbeit mit anderen Teams in dieser Organisation angehen? Ich gehe davon aus, dass der Erfolgsfaktor viel damit zu tun hat, ob das Team seine Denkweise in Bezug auf die Art und Weise, wie es zuvor gearbeitet hat, geändert hat und sich nun dieser neuen Arbeitsweise verschrieben hat? Und können Sie mit uns ein wenig darüber sprechen, wie Sie die Denkweise eines Teams ändern können?

    Gerald Cadden:

    Vielleicht ändere ich hier die Richtung Ihrer Frage, denn was ich herausgefunden habe, ist, dass Sie normalerweise nicht zu hart arbeiten müssen, um die Denkweise eines Teams zu ändern. Die meisten Teams sind wirklich begierig darauf, neue Dinge auszuprobieren und innovativ zu sein. In Teams begegnet man nur einigen Leuten, deren Karriereweg sie vielleicht an einen bestimmten Punkt gebracht hat, an dem sie mit der Welt zufrieden sind und sich nicht ändern wollen. Die Denkweise, die Sie wirklich ändern müssen, bezieht sich auf diesen Führungsbereich, und das gilt auch heute noch. Die Teams werden sich also schnell anpassen, wenn das Management das Umfeld schaffen kann, das es ihnen ermöglicht, und wenn sie dazu befähigt werden können. Aber es ist wirklich... Wenn Sie das Team befähigen wollen, müssen Sie die Führungskräfte um sie herum dazu bringen, ihre Denkweise zu ändern, die Strukturen zu ändern, die die Teams daran hindern, die bestmögliche Arbeit zu leisten.

    Gerald Cadden:

    Und das war für mich die große Entdeckung, während du mitgemacht hast, und das gilt auch heute noch. Während sich Agile weiterentwickelt hat, ist mir aufgefallen, dass Führungskräfte nicht immer ganz oben auf der Liste der Herausforderungen stehen, aber für mich stand sie immer ganz oben auf der Liste. Viele Menschen wollen sich Führung ansehen und Dinge über sie sagen, die wenig schmeichelhaft sind, aber man muss bedenken, dass es sich um Menschen handelt. Und der beste Weg, um Führung zu erlangen, besteht darin, wirklich mit einem Gespräch zu beginnen und ihnen zu helfen, es zu verstehen. Sie kennen die Herausforderungen, aber wir müssen ihnen helfen, zu verstehen, was die Probleme verursacht, die zu diesen Herausforderungen führen.

    Gerald Cadden:

    Wenn du mit ihnen zusammenarbeitest und sie erziehst, kannst du ihren Geist ein bisschen mehr öffnen. Bedeutet das, dass sie sich tatsächlich ändern werden? Nicht unbedingt. Politische Beweggründe, Ideologien und andere Dinge hinderten die Führung daran, sich zu bewegen. Aber Gespräche und Bildung sind meiner Meinung nach der richtige Weg, um Führung wirklich anzugehen. Und sie als Person kennenzulernen, sich für ihre Herausforderungen zu interessieren, sich für sie als Individuum zu interessieren. Es ist also wichtig, diese soziale Bindung herzustellen. Als Berater war das immer schwierig, denn als Berater wird man immer als externe Kraft gesehen und es ist schwierig, eine gewisse soziale Beziehung zu dieser Führung aufzubauen und dieses Vertrauen aufzubauen.

    Sean Blake:

    Ja, das ist so wahr. Ja, ist es nicht. Ich erinnere mich an eine Agile-Transformation, an der ich zuvor teilgenommen habe, wie der Agile-Coach wirklich genauso viel Zeit mit dem Führungsteam verbrachte wie mit uns, dem Agile-Team. Und es scheint seltsam, dass der Coach so viel Zeit damit verbracht hat, das Führungsteam wirklich darin zu coachen, wie es über diese neue Arbeitsweise denken sollte, aber wenn man es in den richtigen Kontext stellt, ist es so wichtig, dass sie dieses Umfeld schaffen, in dem sich ihre Mitarbeiter und ihre Teams sicher fühlen, wenn sie etwas Neues ausprobieren. Ja, das ist wirklich wichtig.

    Gerald Cadden:

    Ich denke, wenn Sie sich ansehen, wie sich Agile entwickelt, wenn Sie sich die Erstellung des Agile-Manifests und seiner Prinzipien und dann der folgenden Frameworks wie ScrumXP usw. ansehen, hat es sich aus der Teamperspektive entwickelt. Also gingen alle davon aus, dass wir diese Dinge entwickeln müssten, damit die Teams ihnen folgen, aber als die Leute mit Teams arbeiteten, stellten sie fest, dass es überhaupt nicht die Teams waren, die Teams passen sich an, sondern das Management und die Strukturen der Organisationen passen sich nicht an. Und genau da ist es hingegangen.

    Gerald Cadden:

    Ich kann mich nicht an die Anzahl der unzähligen Scrum-Implementierungen erinnern, an denen Sie gearbeitet haben, und Sie haben gerade die Obergrenze der organisatorischen Herausforderungen erreicht. Und es war immer sehr frustrierend für die Teams. Ich denke, es gibt auch eine andere Seite dazu: Zu viele in der agilen Welt betrachten die Teams einfach als den Mittelpunkt der Welt und man kann es auch nicht von dieser Art aus angehen. Die Teams sind sehr wichtig, um den Kunden einen Mehrwert zu bieten, aber es ist das Unternehmen als Ganzes, das Wert liefert. Und ich denke, man muss sich wirklich zurücklehnen und einfach sagen: „Die Teams sind Teil davon, wie ändern wir die Organisation einschließlich der Teams?“

    Sean Blake:

    In Ordnung. Das ist wirklich interessant. Gerald, du hast ein bisschen über Teams und Denkweisen gesprochen. Wenn du in eine Organisation gehst, einen großen Autohersteller oder eine große Fluggesellschaft oder ein Finanzdienstleistungsunternehmen und sie dich um Hilfe bitten oder um deine Ausbildung bitten, wie beurteilst du dann, wo die Organisation steht? Wie hoch ist ihr Reifegrad aus agiler Sicht? Kommen Unternehmen zu Ihnen, die im Kopf haben, dass sie bereit sind, SAFe zu machen, und dann tauchen Sie am ersten Tag auf und es stellt sich heraus, dass niemand eine wirkliche Vorstellung davon hat, wie diese Art von Engagement aussieht?

    Gerald Cadden:

    Ja, das ist eine gute Frage. Denn ich denke, wenn ich auf die Geschichte zurückblicke, 2011, 2012, als SAFe wirklich in Gang kam, als Sie vorankamen, ich meine, es gab keine Vorstellung, wo ich anfangen sollte. Die Berater fanden es einfach selbst heraus und wie bei den meisten Beratungen oder den meisten Methoden beschäftigten sie sich in einem IT-Bereich und auf Teamebene. Und die Leute würden versuchen, von der Teamebene an zu wachsen. Und irgendwann müssen wir wissen, dass ich viel damit zu kämpfen hatte, weil ich nur versucht habe herauszufinden, wo das ist. Mein Beraterhut war also immer auf, um mich hinzusetzen, mit den Leuten über ihre Herausforderungen zu sprechen und einen Weg zu finden, herauszufinden, wie die Herausforderungen gelöst werden können, ob es nun Scrum oder SAFe sein würde oder was auch immer richtig sein würde.

    Gerald Cadden:

    Das sind nur Werkzeuge in der Toolbox. Aber als ich Agile skalierte, mit dem ich gearbeitet habe... Entschuldigung, als ich mit SAFe gearbeitet habe, hat Scaled Agile die Implementierungs-Roadmap herausgebracht. Es hat so viel mehr Klarheit gebracht, als ich später bei SAFe gearbeitet habe, und ich wünschte, es wäre früher gekommen, weil es mir wirklich geholfen hat, die anfängliche Sache zu klären, die wir als Überwindung des Kipppunkts bezeichnen. Wie man mit der Organisation zusammenarbeitet, mit der man spricht, mit den richtigen Leuten zusammenarbeitet, ihre Herausforderungen versteht, ihnen hilft zu verstehen, was diese Probleme verursacht, was die traditionellere Arbeitsweise der traditionellen Management-Mentalität ist, ihnen hilft, SAFe zu verbinden, um diese Herausforderungen zu bewältigen und ihnen zu zeigen, wie sie beginnen können. Wenn Sie sich die Roadmap ansehen, handelt es sich um eine zusammenhängende, schrittweise Angelegenheit, aber in Wirklichkeit stellen Sie fest, dass zwischen diesen Schritten Lücken bestehen, und in diesen Lücken führen Sie als Übergangsteam viele Gespräche mit dem Management.

    Gerald Cadden:

    Wenn du sie durch eine Schulung bringst, werden sie nicht aus dem Kurs kommen und sagen: „Oh, wow, das war's. Wir wissen, was zu tun ist.“ Es bedarf eines Folgegesprächs. Sie müssen in vielen Gesprächen eins zu eins führen und Themen behandeln, bei denen Sie Vorteile haben, damit Sie die Annahmen ausräumen oder die Missannahmen bereuen können. Es ist also ein großer Teil dieser Art von Arbeit, dass die Roadmap da ist, für diejenigen, die SAFe heute implementieren, sie verwenden. Es ist eines der hilfreichsten Tools, die Sie haben werden.

    Sean Blake:

    Fantastisch. Ja. Ich denke, wenn man nur den Unterschied zwischen den Tools in der Toolbox anerkennt und dann die andere Tatsache, dass man es mit Menschen zu tun hat und mit Einstellungen und Motivationen und Verhaltensweisen und Gewohnheiten, gibt es wirklich zwei sehr unterschiedliche Dinge. Es hört sich an, dass du sie alle zusammen auf diese Reise mitnehmen musst.

    Gerald Cadden:

    Ja. Außerdem bilden wir so viele SPCs wie SAFe-Programmberater aus. Wir bilden sie aus und bilden sie ständig außerhalb des Unterrichts bei uns und unseren Partnern aus. Was du kannst, du kannst ihnen das Framework beibringen, aber du kannst ihnen nicht unbedingt beibringen, wie man ein guter Berater oder ein guter... Ich möchte sagen, dass ich den Begriff Berater und Coach verwende, oder?

    Sean Blake:

    Ja.

    Gerald Cadden:

    Manchmal sage ich gerne, dass ein guter Berater ein guter Coach sein kann, aber ein guter Coach muss nicht unbedingt ein guter Berater sein, weil es noch eine andere Wissenswelt gibt, die man haben muss, wie setzt man sich hin und spricht mit Führungskräften? Wie lernt man die Patienten kennen und welche Art von Fragen man stellen muss, wie lernt man, diese Beziehungen aufzubauen und zu verstehen, wie man mit politischen Maßnahmen umgeht? Es gibt also Dinge, die außerhalb des Fachwissens eines SPC liegen und die sie sich aneignen müssen. Also junge Leute, die kommen und rennen, um diesen SPC-Kurs zu machen. Ich möchte euch auf alles vorbereiten, aber er gibt euch die Grundlagen.

    Sean Blake:

    Wenn Sie also in einer Organisation sind oder Menschen coachen, um zu ihrer Organisation zurückzukehren, wie bringen Sie ihnen diese Coaching-Fähigkeiten bei, damit sie, wenn sie reinkommen und die Politik lernen müssen, die roten Fahnen erkennen müssen, sie müssen die Abhängigkeiten bewältigen, sie müssen neue Teams in den Zug bringen? Wie geht man wirklich vor, um den menschlichen und kommunikativen Werkzeugkasten auszustatten?

    Gerald Cadden:

    Ich denke, Sie können die Grundlagen des Frameworks natürlich vermitteln, indem Sie die Schulungen durchgehen. Aber Mentoring ist für mich der richtige Weg. Jedes Mal, wenn ich eine Schulung gebe, mache ich den Leuten ganz klar, wenn sie zurückgehen und eine Transformation beginnen, sollten sie das nicht alleine machen. Finden Sie erfahrene Leute, die das gemacht haben, und die Erfahrung sollte nicht nur mit SAFe sein. Sie sollten bei Bedarf Erfahrung mit großen Organisationen gesammelt haben, die Erfahrung mit der Portfolioebene haben. Ganz einfach, weil es Fähigkeiten gibt, die Menschen im Laufe der Jahre ihrer Karriere entwickeln, wenn sie sie zu Beginn nicht hatten.

    Gerald Cadden:

    Ich meine, wenn ich auf einige der schrecklichen Dinge zurückblicke, die ich in Besprechungen und vor Führungskräften gesagt hatte, würde mein Chef seine Hände vor sein Gesicht legen, weil ich jung und impulsiv und unreif war, und das sehe ich heute. Als ich das erste Mal in die USA kam, arbeitete ich mit einigen jüngeren BAs zusammen und sie sagten Dinge in Besprechungen und man musste schnell um einige Dinge herumtanzen, bis man sagte: „Das wollten wir gerade nicht wirklich sagen.“ Deshalb denke ich, dass Mentoring die richtige Fähigkeit ist. Wir können dir die taktischen Fähigkeiten beibringen, aber dir die politischen Fähigkeiten, die menschlichen Fähigkeiten beizubringen, erfordert Mentoring und Zeit.

    Sean Blake:

    Mentoring ist in diesem Zusammenhang so wichtig. Ist es nicht?

    Gerald Cadden:

    Ja.

    Sean Blake:

    In Ordnung. Lassen Sie uns also vor 12 Monaten auf März 2020 zurückspulen. Ein Monat, der sich wahrscheinlich in den Köpfen vieler Menschen eingebrannt hat, ist der Monat, in dem COVID unser Leben auf absehbare Zeit verändert hat. Ich weiß, dass Easy Agile viele Inhalte hatte, Artikel darüber, wie man PI-Planung aus der Ferne durchführt, wie Sie Ihren virtuellen Teams helfen können, besser zusammenzuarbeiten, und wir wussten nicht, dass COVID kommen würde. Wir haben gerade diesen Trend in der Belegschaft gesehen und wir hatten diese Inhalte verfügbar.

    Sean Blake:

    Und dann habe ich mir unsere Website-Analysen angesehen und wir hatten einen riesigen Anstieg bei dem, was ich vermute, waren die Leute in diesen Unternehmen, die zum ersten Mal versuchten, herauszufinden, wie man PI-Planung virtuell durchführt, wie man ihre Freigabezüge buchstäblich auf den Gleisen hält, in einer Zeit, in der die Leute entweder den Staat verließen, zum ersten Mal von zu Hause aus arbeiteten, es ist wirklich so, als ob jemand die Bombe mitten in diesen Auslasszügen abgeworfen hat und die Leute darauf herumkraxeln, wie wir sind machen wir das jetzt virtuell? Hatten Sie zu der Zeit viele Fragen dazu, wie wir das machen werden? Und wie haben Unternehmen Ihrer Meinung nach auf diese Herausforderungen reagiert?

    Gerald Cadden:

    Ja. Ich erinnere mich, dass ich im Januar 2020 in Boulder, Colorado, war und gerade aus dem Urlaub in Australien zurückgekommen bin. Zu diesem Zeitpunkt kam COVID auf und Sie haben im Januar 2020 von Dingen gehört. Ich habe mit meinen Kollegen gesprochen und wir haben uns gefragt, wie schlimm das sein wird. Innerhalb von zwei Monaten fällt die Welt auseinander. Und ich denke, für uns ist es eine gute Möglichkeit, diese Geschichte zu erzählen, wenn wir uns ansehen, was Scaled Agile getan hat. Wir wussten, dass unser Geschäft sehr stark vom Erfolg unserer Partner abhängt, und das ist es auch heute noch. Und als wir anfingen, die physische Welt der PI-Planung und -Schulung zu verstehen, wurde uns klar, dass das Unternehmen, wenn es völlig auseinanderfiel, sich schnell anpassen musste.

    Gerald Cadden:

    Wir hatten bereits eine Reihe von Prioritäten für den PI festgelegt und implementieren Scaled Agile intern im Unternehmen. Zu der Zeit leiten wir das Unternehmen als Zug selbst, weil es 170 Personen sind. Also mussten sie die verschiedenen Epen neu priorisieren, wir haben neue Funktionen veröffentlicht und es ging nur darum, was wir jetzt ändern müssen, um unsere Partner über Wasser zu halten, indem wir sie online bringen, und ein wirklich gutes Team von Scaled Agile, das sich wirklich unternehmensübergreifend darum bemüht, kurzfristige Online-Materialien zu erstellen, um die Partner auf dem Laufenden zu halten, damit sie weiter unterrichten konnten. Sie könnten Wege finden, dies zu tun, PI-Planung durchzuführen, sie überprüfen Anpassungen alles online. Deshalb haben wir eine Menge Material einfach in Form von PowerPoint-Folien herausgebracht, die sie dann in Tools wie Mural, Al Tool integrieren konnten. SAFe Collaboration — wir haben das entwickelt, und das ist im Laufe der Zeit immer reifer geworden.

    Gerald Cadden:

    Und jetzt sind wir in einer Welt, in der wir viel mehr Stabilität haben. Wir haben einen großen Einbruch erlebt, wie jeder andere auch, aber die Frage ist, werden Sie aus diesem Einbruch herauskommen? Also, was wir wahrscheinlich sogar im zweiten Quartal dieses Jahres bemerkt haben, als wir am Ende sahen, dass es wieder auftauchte, was unsere Partner anfingen, mehr online zu unterrichten. Die Zahlen sagten uns also, dass die Materialien, die wir produzieren, funktionierten. Für uns war es einfach eine großartige Bestätigung, dass es uns gerettet hat, sich so zu organisieren, wie wir uns organisiert haben, die schnelle Art und Weise, wie wir uns anpassen konnten. Scaled Agile hätte also den Weg vieler Unternehmen gehen können und nicht überleben können, weil unsere Partner nicht überlebt hätten. Wir hatten die Fähigkeit, uns anzupassen. Aus meiner Sicht ist es also eine großartige Erfolgsgeschichte.

    Sean Blake:

    Nun, das ist großartig. Wir freuen uns alle, dass du immer noch da bist, um die Geschichte zu erzählen.

    Gerald Cadden:

    Ja, das sind wir.

    Sean Blake:

    Und Gerald, ob Sie nun über Unternehmen nachdenken, mit denen Sie in der Vergangenheit zusammengearbeitet haben, oder vielleicht sogar über das interne Scaled Agile-Beispiel, das Sie gerade angesprochen haben. Gibt es bestimmte Treffen, Zeremonien oder Kontrollpunkte, die im Rahmen des Agile Release Train-Prozesses wirklich wichtig sind? Was sind die Dinge, die für Sie wirklich verpflichtend sind, oder die wichtigsten Elemente, an denen sich das Unternehmen während der eigentlichen Einrichtungsphase, in der es versucht, den Scaled Agile-Ansatz zu verwirklichen, wirklich festhalten sollte?

    Gerald Cadden:

    Also interpretiere ich deine Frage richtig. Ich denke, wenn Sie die wirklich wichtigen Dinge umsetzen, auf die Sie sich als Team konzentrieren müssen, ist für mich zuallererst die PI-Planung. Das ist die wichtigste Sache. Es ist das erste, was die Leute ändern wollen, weil es zwei Tage dauert und jeder kommen muss und es Unternehmen eine beträchtliche Summe an Geld kosten kann, das alle 10 bis 12 Wochen durchzuführen. Sie werden also sehr schnell davonlaufen, wie ich es in der Vergangenheit in der Autofirma getan habe. Sie treffen sehr schnell auf den Finanzkontrolleur, der verstehen will, warum Sie 40.000$ pro Quartal für ein großes zweitägiges Meeting ausgeben. Und so lügen sie, sie fangen an, jeden Punkt auf der Rechnung in Frage zu stellen, aber das ist der wichtigste.

    Gerald Cadden:

    PI-Planung ist wichtig. Das Prüfen und Anpassen ist das andere, einfach weil wir am Ende keine Verbesserungsmöglichkeiten haben, wenn Sie diesen Feedback-Zyklus entfernen, was wir als Schließen des Kreislaufs bezeichnen, wenn Sie ihn entfernen. Diese beiden Ereignisse selbst bilden also die Grundlage dafür, womit wir beginnen und wie wir den Kreislauf schließen, aber es gibt kleinere Ereignisse, die zwischen den Teamevents stattfinden, die natürlich alle wichtig sind. Aber wichtiger für mich ist die Konstante, das Ereignis für das Produktmanagement-Team oder das Programmmanagement-Team, wie werden Sie sie filtern, entschuldigen Sie.

    Gerald Cadden:

    Wer muss sich regelmäßig treffen, um das sicherzustellen, dann nennen wir das den Sync. Das ist also der ART Sync oder der POPM Sync. Sie müssen sicherstellen, dass diese eingehalten werden, da es sich dabei um dynamischere Feedback-Schleifen handelt und sicherstellen, dass gute architektonische Anforderungen oder gute Funktionen umgesetzt werden, sodass die Teams, wenn Sie zu PI Planning kommen, wichtige Dinge zu erledigen haben. Wenn Sie mir also meine drei wichtigsten Ereignisse nennen müssten: PI Planning, Inspect and Adapt und ART Sync und das Produkt POPM Sync.

    Sean Blake:

    Fantastisch. Ich weiß, dass es für Teams immer die Versuchung gibt, Abkürzungen zu finden und die Problemumgehungen zu definieren, bei denen sie bestimmte Besprechungen oder bestimmte Check-Ins nicht durchführen müssen, aber in Bezug auf die Kommunikation muss es für diese Teams sehr wichtig sein, sicherzustellen, dass sie immer noch kommunizieren und das Framework nicht als Ausrede benutzen, um die Besprechungen zu beenden und die Zusammenarbeit einzustellen.

    Gerald Cadden:

    Ja. Ja, das habe ich durchgemacht, als ich bei der großen Autofirma in den USA angefangen habe, habe ich beschlossen, das Pflaster abzuzocken. Sie hatten mehrere Teams, die an Projekten arbeiteten, und es ging ihnen nicht gut. Als ich mir die Herausforderungen ansah und beschloss, SAFe zu implementieren, sagten einige vom Management: „Bist du verrückt? Warum würdest du das tun?“ Aber sie haben mir vertraut. Also haben wir das Pflaster abgerissen und sie alle zu einem Knoten geformt. Wir haben die Einrichtung gestartet. Und ich erinnere mich, dass einige Mitglieder des Managements am Ende der PIs viele Zweifel hatten, die kamen, nachdem sie die PI durchgesehen hatten und sagten, sie könnten einfach nicht glauben, wie toll das war.

    Gerald Cadden:

    Obwohl der erste PI etwas chaotisch war, verstanden sie die Arbeit und die Zusammenarbeit, die Ausrichtung, nur die Diskussionen, die stattfanden, waren für sie viel aussagekräftiger. Und die Teams waren glücklicher, sie gingen in eine andere Umgebung. Es hat also die Stimmung stark verändert. Also ich denke, dass die Teams ihre Fähigkeit haben, an einer der wichtigsten Stellen gehört zu werden, während der PI-Planung, sie bekommen die Chance, gehört zu werden. Sie erhalten die Chance, mitzumachen, anstatt erst am Ende zu sein, wo ihnen gesagt wird, was zu tun ist.

    Sean Blake:

    Mm-hmm (bejahend). Es stärkt das Team also wirklich.

    Gerald Cadden:

    Ja. Ja, absolut.

    Sean Blake:

    Das ist großartig. Wenn ein Unternehmen also die Implementierungsphase hinter sich lässt und sich ein bisschen mehr an die Art und Weise gewöhnt, die Dinge zu erledigen, was ist der beste Weg für es, diese Fortschritte der gesamten Organisation mitzuteilen und dann diese Arbeitsweise wirklich zu evangelisieren, um zu versuchen, mehr Teams an Bord zu holen und mehr Agile Release Trains einzurichten, sodass es wirklich ein Ansatz für das gesamte Unternehmen ist.

    Gerald Cadden:

    Ja. Eine gute Frage. Also ich denke zuallererst an die Systemdemo, die wir machen. Also die regelmäßigen Systemdemos, die stattfinden, das ist eine Veranstaltung, zu der man Leute einladen kann. Wenn Sie also das Ende der Programminkremente erreichen, die 10, 12 oder die acht, 10 oder 12 Wochen, und Sie machen Ihre PI-System-Demo, ist das eine Gelegenheit für Sie, Leute einzuladen, die vielleicht in der Organisation stehen und die das tun werden, oder sie sind neugierig, oder wenn Sie externe Lieferanten haben, die Sie im Rahmen der Schulung mit ins Boot holen möchten, lassen Sie sie kommen. Lassen Sie sie zu diesen Veranstaltungen kommen, damit sie einfach teilnehmen können. Sie können sehen, was vor sich geht, und das nimmt einem Teil der Angst vor dem, was das Zeug ist. Es gibt ihnen viel Arbeit.

    Gerald Cadden:

    Also die Systemdemo, ob du es während der PI machst, aber auf jeden Fall die PI-Systemdemo und du willst die. Also eher spontane Dinge und eines der Dinge, bei denen Organisationen, die ich gesehen habe, wirklich nicht tun, ist, wenn sie Erfolg haben, die Führung rund um den Zug gehen muss, und ich hasse den Begriff „evangelisieren“, aber gehen Sie raus und zeigen Sie die Erfolge. Gehen Sie raus und sprechen Sie bei der nächsten Firmentagung darüber, wo sie waren und wo sie jetzt sind. Teilen Sie in diesem Zusammenhang aber nicht nur die Kennzahlen mit, die auf eine höhere Wertschöpfung hindeuten, zeigen Sie die menschlichen Kennzahlen, zeigen Sie, wie das Team von einem gewissen Grad der Verärgerung zu einem vielleicht glücklicheren Gefühl und besserem Feedback übergegangen ist, sondern zeigen Sie, wie Unternehmen und Technologie näher zusammengekommen sind, weil sie in der Lage sind, zusammenzuarbeiten und gemeinsam Wert zu schaffen, anstatt uneins zu sein, weil das System sie uneins macht.

    Sean Blake:

    Fantastisch. Gerald, gibt es noch etwas, das du unserem Publikum mitteilen möchtest, bevor wir die Folge beenden? Irgendwelche Tipps oder ermutigenden Worte oder vielleicht ein paar Ratschläge für diejenigen, die erwägen, ihre Agile-Teams zu erweitern.

    Gerald Cadden:

    Ich denke, der eine Ratschlag, den ich noch einmal wiederhole, ist, während Sie den Implementierungsprozess durchlaufen und damit beginnen, Ihren Zug zu starten und Ihre Teams zu schulen, herauszufinden, wie Sie sie beim Start unterstützen werden. Wenn die Leute einen SPC-Kurs oder all die anderen Klassen absolvieren, werden sie nicht als sichere Genies herauskommen. Sie werden Wissen haben und sie werden den Enthusiasmus haben und auch etwas Angst haben, aber du brauchst gutes Coaching. Finden Sie also heraus, wenn Sie mit dem Implementierungsmuster beginnen, bei dem Sie die Teams usw. entwerfen, und finden Sie heraus, wie Ihr Coaching-Muster aussehen wird. Stellen Sie die Leute ein, die über das Wissen und die Erfahrung verfügen, und arbeiten Sie mit einem Partner zusammen, der das Wissen und die Erfahrung sammelt. Sie sollten nicht für immer dort bleiben, wenn Sie mit Beratern zusammenarbeiten.

    Gerald Cadden:

    Ihre Aufgabe sollte es sein, Sie zu befähigen, nicht dauerhaft dort zu bleiben, aber ohne dieses Coaching und das Coaching über ein paar PIs neigen Ihre Teams dazu, auf Probleme zu stoßen und rückwärts zu gehen. Um diese Dynamik aufrechtzuerhalten, geht es für mich darum, das Coaching-Muster herauszufinden. Die einzige andere, die ich auch sagen würde, ist eine gute Zusammenarbeit zwischen dem Produkt und den Personen, die die Rolle des Produktmanagements in der Architektur übernehmen werden, sicherzustellen, die Beschwerden zu beseitigen und sie zusammenarbeiten zu lassen, weil sie einen ersticken können. Steigen Sie ein und sprechen Sie vor der Markteinführung über die Umgebungen. Sie wollen keine komischen Probleme haben, wenn Sie sagen: „Oh, die Architektur ist schrecklich.“ Okay. Lass uns darüber sprechen, bevor wir starten.“ Also nur ein paar Dinge, die ich für wirklich wichtig halte, auf die Sie sich konzentrieren sollten, bevor Sie den Zug starten.

    Sean Blake:

    Fantastisch. Das weiß ich wirklich zu schätzen, Gerald. Ich habe in unserem Chat tatsächlich viel gelernt. Es sind dieselben Herausforderungen, die Sie vor 10 Jahren hatten, es sind dieselben Herausforderungen, vor denen wir heute stehen. Das eigentliche Problem von COVID ist die Herausforderung, wie Sie sich auf die Änderung der Denkweise konzentrieren können. Wir haben darüber gesprochen, dass die Teams bestrebt sind, sich zu ändern. Es mag ein paar murrende Stimmen geben, aber in Wirklichkeit geht es darum, dass Führung ein einladendes und sicheres Umfeld bietet, um diesen Wandel zu fördern, und um den Unterschied zwischen Coach und Berater, die Bedeutung von Mentoring. Wow, wir haben tatsächlich eine Menge Boden zurückgelegt, nicht wahr?

    Gerald Cadden:

    Ich kriege vielleicht Hasspost für diesen Kommentar, aber...

    Sean Blake:

    Oh, wir werden sehen. Die Zeit wird es zeigen. Vielen Dank, Gerald, dass Sie sich uns im Easy Agile Podcast angeschlossen haben. Und wir freuen uns, dass Sie Ihr Fachwissen mit uns und dem Publikum für den Podcast teilen. Danke, dass du gekommen bist.

    Gerald Cadden:

    Ich mache es jederzeit gerne. Danke, dass ich heute hier bin.

    Sean Blake:

    Danke Gerald.

  • Podcast

    Easy Agile Podcast Ep.21 LIVE von Agile2022!

    „Das ist ein Abschluss von Agile2022! Es war großartig, so viele von Ihnen in der Agile-Community persönlich treffen zu können!“ - Tenille Hoppo

    Diese Bonus-Episode wurde LIVE bei Agile2022 in Nashville aufgenommen!

    Das Easy Agile-Team hat mit so vielen großartigen Leuten aus der Agile-Community gesprochen und über die Höhepunkte der Konferenz, wichtige Erkenntnisse, agile Zeremonien und mehr nachgedacht!

    Vielen Dank an alle, die am Stand vorbeigeschaut haben, um G'Day zu sagen und ein oder zwei Tim Tam genossen haben;)

    Vielen Dank an alle unsere Podcast-Gäste, dass sie einige Zeit mit uns verbracht haben, um diese Episode zu erstellen!

    • Cody Wooten
    • Gil Broza
    • Maciek Saganowski
    • Lindy Quick
    • Carey Young
    • Leslie Morse
    • Dan Neumann
    • Joe Falu
    • Kai Zander
    • Avi Schneier
    • Doug Page
    • Evan Leyburn
    • John Kerr
    • Josua Seckel
    • Rob Duval
    • Andrew Thompson

    Transkript

    Caitlin:

    Hallo zusammen. Nun, das ist ein Abschluss von Agile 2022 in Nashville. Das Easy Agile-Team ist wieder zu Hause in Australien, und wir haben den größten Teil unserer Heimreise damit verbracht, über all die großartigen Gespräche zu sprechen, die wir mit allen Mitgliedern der Agile-Community führen konnten. Es war großartig, Kunden und Partner zu treffen, alte Freunde zu sehen und viele neue zu finden. Wir haben es geschafft, einige Ausschnitte dieser großartigen Gespräche aufzunehmen, und wir freuen uns, sie mit Ihnen, unserem Easy Agile Podcast-Publikum, zu teilen. Also viel Spaß.

    Maciek:

    [unhörbar 00:00:26].

    Tenille:

    Maciek, vielen Dank, dass du dir heute Zeit für uns genommen hast.

    Maciek:

    Keine Sorge.

    Tenille:

    [unhörbar 00:00:30], kannst du uns sagen, was das Beste war, was du diese Woche gelernt hast?

    Maciek:

    Oh, das war definitiv bei Melissa Perris Vortrag. Als sie über... sprach Als ob sie für mich davon sprach, langsamer zu werden. Und was wir bei Agile tun, ist nicht nur Lieferung, Lieferung, Lieferung, sondern es geht auch darum, Dinge, die wir bereits entwickelt haben, zu lernen und zu ändern und herauszufinden, welchen Mehrwert wir unseren Kunden bieten können. Es geht nicht nur um Versandfunktionen, es geht vor allem um den Wert. Das habe ich gelernt.

    Tenille:

    Das ist großartig. Danke. Also, was denkst du wäre die geheime Zutat für ein großartiges Agile-Team?

    Maciek:

    Demut. Irgendwie sollte die Teamkultur Demut und Fehler beinhalten. Und die Leute sollten keine Angst davor haben, Fehler zu machen, denn ohne Fehler zu machen, lernt man nicht. Das ist was ich denke.

    Tenille:

    Was wäre also, glaube ich, wenn es eine Agile-Zeremonie gäbe, die jedes Team durchführen sollte, was denkst du, könnte das sein?

    Maciek:

    Sicher, Retro, und das kommt wieder auf die Fehler und den Lernteil zurück.

    Tenille:

    Ja. Fantastisch.


    Maciek:

    Keine Sorge.

    Tenille:

    Das ist großartig. Vielen Dank, dass du dir die Zeit genommen hast.

    Maciek:

    In Ordnung. Danke.

    Tenille:

    Prost.

    Mädchen:

    [unhörbar 00:01:42].

    Caitlin:

    Gil:, vielen Dank, dass du mit uns gechattet hast. Im Moment sind wir also alle auf der Agile 2022 in Nashville. Es finden viele interessante Gespräche statt.

    Mädchen:

    Ja.

    Caitlin:

    Wenn Sie einem neu entstehenden Agile-Team einen Ratschlag geben könnten, welcher wäre das?

    Mädchen:

    Es wäre, kleine, wertvolle Arbeiten gemeinsam zu beenden. Es hat ein schreckliches Akronym, FSVWT. Es kann also nicht auf diese Weise in Erinnerung bleiben. Erledigen Sie gemeinsam kleine, wertvolle Arbeiten. Es wird viel über Prozesse, Arbeitsvereinbarungen und Tools gesprochen. Das ist alles wichtig, aber manchmal ist es zu viel für ein Team, das gerade erst anfängt. Wenn wir also nur daran denken, kleine wertvolle Arbeiten gemeinsam zu erledigen, ist das eine großartige Geschichte.

    Caitlin:

    Ja, ich liebe das. Und du warst Redner auf der Konferenz?

    Mädchen:

    Ja.

    Caitlin:

    Kannst du unserem Publikum einen kleinen Einblick geben, worum es in deinem Gespräch ging?

    Mädchen:


    Was in vielen Situationen passiert, ist, dass Technik oder Entwicklung nicht wirklich mit dem Produkt/Unternehmen zusammenarbeiten. Und stattdessen gibt es eine Übergabebeziehung. Aber was passiert, ist, dass es ohne eine kooperative Beziehung wirklich schwierig ist, Agilität aufrechtzuerhalten. Die Leute machen viele einseitige Annahmen. Und im Laufe der Zeit führt die Art und Weise, wie Entscheidungen getroffen werden, dazu, dass die Kosten für Änderungen steigen und die Sicherheit, Änderungen vorzunehmen, sinkt. Und wenn das passiert, wird alles schwieriger und langsamer, sodass die Agilität darunter leidet. Der Kern des Vortrags war also, wie wir zusammenarbeiten können, also sowohl das Produkt als auch die Technik, auf eine Weise, die es uns ermöglicht, die Kosten von Änderungen zu kontrollieren und die Sicherheit zu erhöhen? Es geht also nicht nur um Zusammenarbeit jeglicher Art. Es gibt ganz bestimmte Prinzipien, die befolgt werden müssen. Das nennt man technische Agilität, und wenn wir das tun, können wir langfristig agil sein.

    Caitlin:

    Großartig. Ich liebe es. Nun, vielen Dank und ich hoffe, Sie genießen den Rest Ihrer Zeit auf der Konferenz.

    Mädchen:

    Ich danke dir.

    Caitlin:

    Großartig. Danke.

    Tenille:

    Hallo, Tenille hier von Easy Agile, mit Josh von Deloitte, und wir werden ein gutes Gespräch über Team-Retrospektiven führen. Also Josh, danke, dass du dir die Zeit für ein gutes Gespräch genommen hast. Sie sind also ein bisschen Experte für Team-Retrospektiven. Was sind deine Top-Tipps?

    Josh:

    Meine Top-Tipps für den Rückblick sind also zunächst, tatsächlich eine Änderung vorzunehmen. Machen Sie keine beobachteten Lektionen. Ich habe gesehen, dass viele von ihnen tatsächlich eine Veränderung vorgenommen haben, auch wenn es am Ende nur eine kleine ist. Die zweite und ein Teil davon ist, dass Sie Ihre Veränderung vornehmen und experimentieren. Etwas, das man messen kann, etwas, von dem man tatsächlich sagen kann, ja, wir haben dieses Ding gemacht und es hatte Wirkung. Vielleicht nicht die Wirkung, die Sie sich gewünscht haben, aber es hatte eine gewisse Wirkung. Der zweite Tipp lautet: Variieren Sie Ihre Rückblicke. Eine Retrospektive, die Sprint für Sprint nach Sprint gleich ist, funktioniert für etwa zwei Sprints, und dann werden Ihre Produktivität und Ihre Kreativität außerhalb der Retrospektive erheblich abnehmen.

    Tenille:

    Das ist ein ausgezeichneter Punkt. Also, wie erstellt man [unhörbar 00:05:03]?

    Josh:

    Ich habe viel über sie nachgedacht und recherchiert und Websites wie TastyCupcakes genutzt, aber auch meine eigenen Retrospektiven entwickelt. Ich habe eine Retrospektive gemacht, die auf dem Pixar-Pitch basiert. Es gibt sechs Sätze, die jeden Pixar-Film definieren. Nehmen Sie die Basissätze, wenden Sie sie auf Ihren Sprint oder Ihren PI an und machen Sie einen Retro, und lassen Sie dem Team diese Kreativität, um ein ganzes Filmplakat zu erstellen, wenn es möchte. Regie: [unhörbar 00:05:34], weil es passiert. Die Leute engagieren sich und engagieren sich, wenn man ihnen Alternativen gibt, verschiedene Arten, Retrospektiven zu machen.


    Tenille:

    Das ist richtig. Also für die Teams, die im Moment keine Retrospektiven veranstalten, was ist die eine wichtige Sache, über die sie nachdenken müssen, dass du... Was ist das Wichtigste, was du ihnen sagen könntest, um sie zum Start zu ermutigen?

    Josh:

    Wenn du keine Retrospektiven machst, machst du keine [unhörbar 00:05:54]. Also sollte ich das nicht sagen. Aber wenn du keine Retrospektiven machst, wenn du wirklich glaubst, dass du absolut nichts zu verbessern hast und du zu 100% zu den Besten der Besten gehörst, was bedeutet, dass du wahrscheinlich bei Google oder Amazon oder Netflix arbeitest, obwohl sie Retrospektiven machen. Wenn du also wirklich glaubst, dass du diesen Unternehmen gleichwertig bist, dann musst du sie vielleicht nicht machen, aber ich bin mir ziemlich sicher, dass jedes Team etwas hat, das es verbessern kann. Und das anzuerkennen und dann zu sagen, wie werden wir das machen? Die Retrospektive ist eine sehr schnelle und einfache Methode, um diese Verbesserungen tatsächlich vorzunehmen und sie in die Realität umzusetzen.

    Tenille:

    Fantastisch. Großartig. Vielen Dank, dass Sie sich die Zeit genommen haben, kurz mit uns über Rückblicke zu sprechen.

    Josh:

    Ich danke dir.

    Caitlin:

    Wir sind hier mit Leslie, der Präsidentin von Women in Agile. Leslie, am Sonntag gab es eine tolle Veranstaltung.

    Leslie:

    Ja.

    Caitlin:

    Sprich uns einfach ein bisschen darüber an. Was ist in die Planung eingeflossen? Wie war es, wieder alle zusammen zu sein?

    Leslie:

    Es war toll, die Frauen in der Agile-Community wieder zusammen zu haben, oder? Unser erstes Mal seit 2019, als alle zu dieser Veranstaltung in Washington DC zusammen waren. In den meisten sechs oder sieben Monaten der Planung hatten wir ungefähr 200 Personen im Raum. Zum Glück wissen wir [unhörbar 00:07:10], was diese Frauen in Agile-Sessions machen, die wir jedes Jahr im Rahmen der Agile Alliance-Konferenzen veranstalten, oder? Wir haben eine allgemeine Eröffnung. Wir haben einen großartigen Keynote, bei dem es sich immer um jemanden handelt, der direkt neben dem Agile-Bereich steht. Wir wollen nicht einfach nur mögen... Wir wollen unsere Weisheit und unser Wissen mit Leuten teilen, die noch nicht zu uns gehören, weil wir das ganze Agile-Zeug auf der großen Konferenz bekommen, wenn wir dort sind.

    Leslie:

    In diesem Teil bringen wir immer neue Stimmen auf den Markt, was wahrscheinlich eine meiner Lieblingsfrauen in Agile-Programmen ist. Drei Mentees, die mit erfahrenen Rednern gepaart wurden, treten zum ersten Mal auf die Bühne, um ihr Talent und ihre Sichtweise zu teilen. Das ist also wirklich großartig. Und dann eine Art interaktives Networking-Event. Dieses Muster hat uns also wirklich gute Dienste geleistet, seit wir das seit 2016 machen, was ein bisschen beängstigend ist, wenn man bedenkt, dass es schon so lange passiert. Und es ist zu einer großartigen Gelegenheit für die Community geworden, auf globalere Weise zusammenzukommen, weil die Agile Alliance so viele Menschen für ihre jährliche Veranstaltung anzieht.

    Caitlin:

    Ja, ganz sicher. Ja, es war eine großartige Veranstaltung. Ich weiß, dass wir alle viel Spaß hatten, dort zu sein. Was war Ihre wichtigste Erkenntnis aus der Veranstaltung?

    Leslie:

    Ich werde zu [unverständlich 00:08:14] interaktiven Netzwerken gehen, die sie mit uns gemacht hat, und uns wirklich herausfordern, unseren Mut in Bezug auf Grenzen und das Beenden von Gesprächen zu stärken. Wir müssen keinen Grund angeben. Wenn ein Gespräch uns nicht nützt oder aus welchem Grund auch immer nicht der Ort ist, an dem wir sein müssen, haben Sie absolut die Freiheit, dieses Gespräch zu beenden und einfach weiterzumachen. Ich liebe die Tipps und Tricks, die sie uns gegeben hat, um das gut zu machen.

    Caitlin:

    Ja, ja, das liebe ich auch. Das ist großartig. Nun, vielen Dank. Ich weiß es zu schätzen.

    Leslie:

    Ja. Danke, dass du mich eingeladen hast.

    Tenille:

    Hallo, Evan. Wie geht's dir?

    Evan:

    Sehr gut.

    Tenille:

    Das ist gut. Kannst du mir bitte sagen, was das Beste ist, was du heute gelernt hast?

    Evan:

    Das beste Zitat, das ich habe: „Politik ist die Währung menschlicher Systeme.“ Richtig?

    Tenille:

    Beeindruckend.

    Evan:

    Wenn du also ein menschliches System ändern willst, musst du die Politik spielen.

    Tenille:


    Fantastisch.

    Evan:

    Was sich beschissen anfühlt, aber...

    Tenille:

    Es ist so wie es ist.

    Evan:

    ... so ist das nun mal.

    Tenille:

    [unhörbar 00:09:07]. Okay, nächste Frage. Ohne welche Agile-Zeremonie können Sie und Ihr Team nicht leben?

    Evan:

    Rückblick. Mit der Retrospektive kannst du quasi alles andere gestalten.

    Tenille:

    Fantastisch. Das ist wirklich gut. Und was ist Ihrer Meinung nach wahrscheinlich die wichtigste Zutat für einen guten Rückblick?

    Evan:

    Oh, vertraue. Vertrauen erfordert Respekt. Es erfordert Glaubwürdigkeit. Es erfordert Empathie. Vertrauen ist also genau das, was menschliche Fähigkeiten untermauert.

    Tenille:

    Ja. Fantastisch. Vielen Dank.

    Evan:

    Ich danke dir.

    Tenille:

    Ja.

    Caitlin:

    Richtig. Wir sind hier mit Cody von Adfire. Also Cody, wie hat dir die Konferenz bisher gefallen?

    Cody:

    Ich liebe die Konferenz wirklich. Es war großartig. Um ehrlich zu sein, als wir das erste Mal hier ankamen, schien es vielleicht ein bisschen kleiner als wir dachten, aber die Leute hier waren unglaublich, sehr engagiert, was immer großartig war. Und außerdem verwenden viele Leute Jira und Atlassian. So viele wichtige Punkte.


    Caitlin:

    Win-Win für beide, hm?

    Cody:

    Ja. Immer, immer, immer.

    Caitlin:

    Sehr gut.

    Cody:

    Ja.

    Caitlin:

    Es finden viele interessante Vorträge statt. Haben Sie an einem teilgenommen, der wirklich Interesse an Ihnen geweckt hat? Was ist [unhörbar 00:10:15] -

    Cody:

    Ja. Ich kann mich auf Anhieb an keinen der Vortragsnamen erinnern, aber sie waren alle unglaublich aufschlussreich. Tonnenweise Informationen. Es scheint, als gäbe es für alles ein Thema, was immer ein gutes Zeichen ist und solche Sachen. Also meine Notizen, ich habe Seiten und Seiten und Seiten von Notizen, was immer ein gutes Zeichen ist.

    Caitlin:

    Ja, das ist [unhörbar 00:10:34].

    Cody:

    Also muss ich zurück und [unhörbar 00:10:35] nochmal.

    Caitlin:

    Ja.

    Cody:

    Aber es war unglaublich und die Vorträge waren sehr umfangreich, also ja.

    Caitlin:

    Gut. Gut. Und was ist die eine wichtige Erkenntnis, auf die Sie sich freuen, zurückzubringen und mit dem Team zu teilen?

    Cody:

    Nun, ich denke, eine der wichtigsten Erkenntnisse für uns war, dass... Ich habe über das Engagement gesprochen, das alle haben, aber eine Sache, die unglaublich war, ist, die Geschichten aller zu hören, ihre Probleme, ihre Prozesse, all das. All diese Informationen werden also ein großartiges Aggregat sein, das wir zurücknehmen und ein besseres Erlebnis mit unserem Produkt und all den guten Dingen schaffen können. Also ja.


    Caitlin:

    Ganz gewiss. Ich liebe es. Ich habe jetzt noch eine letzte Frage an dich. Es macht einfach Spaß. Es ist wahr oder falsch. Wir machen Australien-Quizfragen. Bist du bereit dafür?

    Cody:

    In Ordnung.

    Caitlin:

    In Ordnung.

    Cody:

    Hoffentlich.

    Caitlin:

    Also, meine Wahrheit oder Unwahrheit ist, sind Wellensittenschmuggler eine Vogelart?

    Cody:

    Sind Buggy-Schmuggler...

    Caitlin:

    Wellensittiche Schmuggler.

    Cody:

    Wellensittiche Schmuggler.

    Caitlin:

    Eine Vogelart.

    Cody:

    Stimmt.

    Caitlin:

    Falsch. Nein.

    Cody:

    Was sind sie?

    Caitlin:

    Tachos.

    Cody:


    Ja. Ja, ich habe einige davon in meinem Gepäck. Also hole ich jetzt die Wellensittiche raus.

    Caitlin:

    Mit deinen Daisy Dukes.

    Cody:

    Exakt. Exakt.

    Caitlin:

    Ja. Und Cowboystiefel, richtig?

    Cody:

    Ja.

    Caitlin:

    Nun, vielen Dank.

    Cody:

    Ich danke dir.

    Caitlin:

    Ich weiß das sehr zu schätzen.

    Cody:

    Ja. Danke.

    Tenille:

    Doug, wie geht's dir?

    Doug:

    Mir geht es großartig. Ich danke dir.

    Tenille:

    Fantastisch. Nun, erzähl mir, was ist das Beste, was du heute gelernt hast?

    Doug:

    Ich finde es wirklich interessant zu erfahren, wie unsere Kunden unsere Produkte verwenden, von denen wir noch nicht einmal wussten.

    Tenille:

    Das ist unglaublich. Hattest du die Gelegenheit, an vielen der Sessions teilzunehmen?


    Doug:

    Das habe ich eigentlich nicht. Ich war an diese Kabine gebunden, oder ich nahm an Besprechungen teil, die schon geplant waren, bevor ich hierher kam.

    Tenille:

    [unhörbar 00:12:01].

    Doug:

    Ja.

    Tenille:

    Das ist gut. Wenn Sie also wieder auf der Arbeit sind, was ist Ihrer Meinung nach die wahrscheinlich beste Agile-Zeremonie, ohne die Sie und Ihr Team nicht leben können?

    Doug:

    Ich denke, was ich zurück ins Büro bringe, ist nicht so sehr eine Zeremonie. Es ist wirklich aus der Produktperspektive. Ich arbeite im Produktmanagement. Für uns geht es also darum, wie wir erklären können, wie unser Produkt unseren Kunden einen Mehrwert bietet. So viele Lektionen, die wir daraus gelernt haben, dass wir wirklich darauf bedacht sind, sie zurückzubringen und in unsere Wertebotschaft einzubauen.

    Tenille:

    Fantastisch.

    Doug:

    Ja.

    Tenille:

    Danke. Das ist großartig. Vielen Dank.

    Caitlin:

    Er war einer der Mitautoren des Agilen Manifests. Erstens, wie geht es Ihnen bisher auf der Konferenz?

    Johannes:

    Nun, ich arbeite hart.

    Caitlin:

    Ja, gutes Zeug.

    Johannes:

    Ich genieße Nashville.

    Caitlin:


    Ja. Es ist cool, nicht wahr? Es ist so anders als das [unhörbare 00:12:46], was passiert.

    Johannes:

    Ja. Ja, es ist gut. Ja. Es ist schön, viele Leute zu sehen, die ich seit einiger Zeit nicht mehr gesehen habe.

    Caitlin:

    Ja. Ja.

    Johannes:

    Und dreidimensional sehen.

    Caitlin:

    Ja. Ja, ich weiß. Ja, das ist interessant...

    Johannes:

    Es ist da-

    Caitlin:

    ... [unhörbar 00:12:54] und so was passiert.

    Johannes:

    Ja, IRL.

    Caitlin:

    Es passiert viel Interessantes [unhörbar 00:13:01]. Irgendwelche wichtigen Imbissbuden für dich? Was nimmst du danach mit, um es mit dem Team zu teilen?

    Johannes:

    Oh, nun, das ist eine gute Frage. Ich habe hauptsächlich mit vielen Freunden gesprochen, die ich seit einiger Zeit nicht mehr gesehen habe. [unhörbar 00:13:14].

    Caitlin:

    Ja.

    Johannes:

    Und da ich erst seit ein paar Tagen hier bin, war ich nicht viel, wenn überhaupt, dort. Um ehrlich zu sein.

    Caitlin:

    Ich weiß. Nun, wir sind ziemlich beschäftigt mit den Stiefeln, oder?

    Johannes:


    Ja. Ja. Aber sicherlich sind die Arten von Gesprächen, die hier geführt werden,... Ich habe mir ein bisschen Sorgen um Agile gemacht. Ich will einfach nicht sagen... Ja, ich will es nicht sagen. Aber ich will nicht sagen, dass Agile zu einem Sprungbrett wird.

    Caitlin:

    Ja.

    Johannes:

    Aber ich denke, es gibt eine Menge Leute hier, die wirklich immer noch die Ideale annehmen und wirklich lernen, tun und üben wollen [unhörbar 00:14:00].

    Caitlin:

    Ja.

    Johannes:

    Also ich bin ehrlich gesagt überrascht und beeindruckt und glücklich. Es gibt eine Menge. Es reicht, wenn man sich mehr vom Manifest zu eigen macht und manchmal vielleicht nicht alle Vorschriften, und man kehrt zu den Grundlagen zurück. [unhörbar 00:14:22] -

    Caitlin:

    Ja. Also lass uns darüber sprechen, über das Agile Manifest, das du erwähnt hast. Ich nehme das an. Was heißt Umarmen? Kannst du das etwas näher erläutern? Wir wissen also, dass wir die Prinzipien haben. Gibt es eine, die Ihnen wirklich mehr auffällt als eine andere?

    Johannes:

    Nun, meine Welt von dem, was ich zu der Zeit gemacht habe, und ich hatte viel im Verteidigungsministerium und im Wassertransport gearbeitet und meinen eigenen, leichten Prozess entwickelt, wie wir ihn vor Agile nennen. Also für mich ist der wahre Schlüssel... Das hat nicht die volle...

    Caitlin:

    Vollständiges Manifest, ja.

    Johannes:

    Aber wenn du auf die Website gehst und oben liest, geht es darum, als würden wir Wege aufdecken, indem wir etwas tun, und ich lerne immer noch, entdecke immer noch. Und ich denke, es ist wichtig, dass die Leute erkennen, dass wir unser Ego wirklich an der Tür gelassen haben. In unserem Geschäft bescheiden zu sein ist sehr wichtig. Das steht vielleicht nirgends in den Prinzipien, aber wenn das Ganze in der Präambel ganz oben steht und die Tatsache, dass wir im Blog darüber sprechen, wie wir diese Dinge bewerten, im Vergleich zum Ganzen... Da ist ein Pendel, durch das man sehen kann, wie diese beiden Dinge kollidieren. Meiner Meinung nach ist es eine der wichtigsten Eigenschaften, die wir anwenden sollten, dass wir bescheiden sind und Dinge als Hypothese betrachten. Zum Beispiel, baut Funktionen [unhörbar 00:15:58] nicht einfach von unten nach oben, wie sucht man nach den Antworten, das möchte ich, dass die Leute das mitnehmen.

    Caitlin:


    Das ist großartig. Das ist ein toller Rat. Nun, vielen Dank, John. Danke, dass du dir die Zeit nimmst, mit uns zu chatten.

    Johannes:

    Du bist willkommen, Caitlin.

    Caitlin:

    Ja. Genieß, was [unhörbar 00:16:11] ist.

    Johannes:

    Ich danke dir.

    Caitlin:

    Ich danke dir.

    Johannes:

    [unhörbar 00:16:13] morgen.

    Caitlin:

    In Ordnung.

    Tenille:

    Abukar, danke, dass du heute zu uns gekommen bist. Kann ich Sie beide fragen, was Ihrer Meinung nach das Beste ist, was Sie heute gelernt haben?

    Avi:

    Das Beste, was ich gelernt habe?

    Tenille:

    Ja.

    Avi:

    Das ist wirklich interessant. Weil ich oft hier am Stand bin, werde ich an vielen Dingen teilnehmen können. Ich habe also zwei Dinge gelernt, die wirklich wichtig waren. Erstens ist das Easy Agile-Logo ein umgedrehtes A, weil es bedeutet, dass Sie aus Australien kommen. Es ist also in Down Under. Und dann war die zweitwichtigste Sache, über die ich heute gelernt habe, dass wir in einer Sitzung über Soziokratie gesprochen haben und darüber, wie man Experimente mit Experimenten besser machen kann, was sich zunächst etwas komisch anhörte, aber es ging wirklich darum, einen Mini-A3-Prozess durchzuführen. Für diejenigen unter Ihnen, die zugehört haben: Das wurde Toyota angetan. Es ist eine strukturierte Problemlösungsmethode, aber anstatt sie [unhörbar 00:17:02] zu umgehen und das Experiment durchzugehen, zwei- oder dreimal herumzulaufen und dann zu entscheiden, dass das das richtige Experiment ist, machen Sie weiter.

    Tenille:


    Ich danke dir. Wie stehts mit deiner Zeit?

    Kai:

    Ich war die meiste Zeit am Stand, aber dadurch lernt man viele Leute auf der ganzen Welt kennen. Und eines haben wir wirklich gemeinsam, nämlich den Wunsch, Menschen zu helfen. Und es war wirklich schön, in einem Raum voller Menschen zu sein, die am Anfang ihrer Reise stehen oder schon sehr erfahren sind und ihre Motivation einfach darin besteht, andere wirklich zu stärken. Es war wirklich schön, mit dieser Art von Energie zusammen zu sein.

    Avi:

    Wir haben wirklich gelernt, dass unsere Freunde aus Australien hier oben genauso freundlich sind wie Sie auf der anderen Seite. Ich habe das Gefühl, wenn du auf diese Seite kommst, wirst du gemein, aber es stellt sich heraus, dass du auch hier oben genauso nett bist.

    Tenille:

    Nun, das hängt davon ab, wie lange du schon auf dem Flug warst.

    Avi:

    Oh, genau.

    Tenille:

    [unhörbar 00:17:44], uns geht es gut.

    Kai:

    Ja.

    Avi: Abukar:

    Exakt. Gut.

    Tenille:

    In Ordnung. Noch eine Frage hier.

    Avi:

    Sicher.

    Tenille:

    Was ist deiner Meinung nach die geheime Zutat für ein erfolgreiches Team?

    Avi:

    Was halte ich für das Geheimnis? Oh, das ist eine wirklich gute Frage. Das ist ein-

    Kai:

    Er ist der Beste, um diese Frage zu beantworten.


    Avi:

    Das ist etwas länger als ein zweisekündiger Podcast, aber das sage ich dir. Das ist vielleicht keine psychologische Sicherheit, -

    Tenille:

    In Ordnung.

    Avi:

    ... nur weil Google das gesagt hat und Project Aristotle das zeigt. Ich denke, um ein wirklich, wirklich erfolgreiches Team zu haben, braucht man einen wirklich erfahrenen Scrum Master. Denn zu sagen, dass das Team psychologische Sicherheit hat, ist eine Zutat, es ist nicht die einzige Zutat. Ein starker Scrum Master ist jemand, der wirklich geschickt darin ist, diese psychologische Sicherheit zu schaffen, aber auch bei all den anderen Aspekten hilft, um sich auf eine möglichst positive Zusammenarbeit und Koordination vorzubereiten. Außerdem auf der Suche nach... Ihr Name ist Cassandra. Auf Slack nennt sie sich selbst Kaizen. Kapierst du es? Das ist ein Witz. Aber das ist die ganze Sache, ein wirklich erfahrener Scrum Master hilft den Teams, die Kaizens zu finden, die sie brauchen, um wirklich leistungsstark zu werden. Psychologische Sicherheit macht das möglich, aber das heißt nicht, dass sie die Leistung steigert. Es ist eine Zutat, um das möglich zu machen.

    Tenille:

    Fantastisch.

    Kai:

    Es gibt keine bessere Antwort als diese. Lass uns einen Ausruf machen.

    Tenille:

    Hervorragend. Vielen Dank, dass Sie sich die Zeit genommen haben.

    Avi:

    Ich danke dir vielmals.

    Kai:

    Natürlich.

    Hayley:

    Wir sind hier mit Carey von Path to Agility. Carey, was hat dir an dieser Konferenz wirklich gefallen?

    Carey:

    Ich glaube, dass mir an dieser Konferenz bisher am meisten gefallen hat, ist die Interaktion mit all den Leuten, die hier sind. Es ist wirklich schön, sich zu treffen, verschiedene Leute kennenzulernen, Kontakte zu knüpfen und die Gelegenheit zu haben, zu sehen, was es sonst noch auf dem Markt gibt. Und dann sprechen wir natürlich über das Produkt, das wir mit Path to Agility haben. Es ist eine wundervolle Erfahrung, hierher zu kommen und alle zu sehen. Und es ist so schön, wieder persönlich unterwegs zu sein, anstatt die ganze Zeit vor einem Bildschirm zu stehen.


    Tenille:

    Ja, absolut. Hattest du die Gelegenheit, an vielen der Sessions teilzunehmen?

    Josef:

    Ich habe so viel wie möglich versucht, aber es ist auch wichtig, sich die Zeit zu nehmen, um zu dekomprimieren und alles einwirken zu lassen. Also hier haben wir Spaß.

    Tenille:

    Ja, absolut. Wenn Sie an die Arbeit zurückdenken, was ist Ihrer Meinung nach die eine Agile-Zeremonie, an der Sie teilnehmen und die Ihnen und Ihrem Team am meisten hilft?

    Josef:

    Ich denke, verschiedene Wege der Zusammenarbeit zu finden, effektive Wege der Zusammenarbeit. Und wie lösen wir in Bezug auf das Arbeitsmanagement einige der Probleme, die wir haben? Es gibt so viele Tools, die das einfacher machen, und das ist etwas ganz Besonderes. Mit Menschen sprechen und herausfinden, wie sie Probleme lösen.

    Tenille:

    Und was macht Ihrer Meinung nach ein wirklich gutes Agile-Team aus?

    Josef:

    Nun, man könnte etwas sehr Klischeehaftes sagen, wie sehr anpassungsfähig zu sein und sich zu verändern und so weiter und so fort. Aber ich denke, es kommt wirklich auf die Interaktion zwischen Menschen an. Einander verstehen, sich gegenseitig ermutigen und einfach die Art und Weise, wie man zusammenarbeitet.

    Tenille:

    Fantastisch. Großartig. Gut, vielen Dank, dass du dir die Zeit zum Chatten genommen hast.

    Josef:

    Ich danke dir. Es war nett, die ganze Woche mit euch zu chatten.

    Tenille:

    Prost.

    Tenille:

    Dan, danke, dass du dir die Zeit zum Chatten genommen hast.

    Dan:

    Du bist willkommen.

    Tenille:

    [unhörbar 00:22:54] Fragen. Was denkst du ist das Beste, was du heute gelernt hast?


    Dan:

    Oh, das Beste, was ich heute gelernt habe, ist, dass die Keynote zu den Morgenprodukten ausgezeichnet war. Ich habe ein paar Tipps bekommen, wie man Produktmanagement macht, verschiedene Strategien, wie man die Leute dazu bringt, sich auf das Taktische und Strategische zu konzentrieren. Also nur ein paar nette kleine Nuggets, wie das geht [unhörbar 00:23:12].

    Tenille:

    [unhörbar 00:23:13], danke, dass du heute zu uns gekommen bist. Kann ich zunächst fragen, was denkst du ist das Beste, was du diese Woche gelernt hast?

    Sprecher 17:

    Das Beste, was ich diese Woche gelernt habe, ist, dass es keinen richtigen Weg gibt, Agile anzuwenden. Es gibt viele verschiedene Möglichkeiten, dies zu tun. Es geht also wirklich darum, herauszufinden, welcher Prozess für das Unternehmen, in dem Sie tätig sind, der richtige ist, und diese Erfolgsmuster dann zu nutzen.

    Tenille:

    Nun, ich schätze, gibt es eine Art Agile-Zeremonie, auf die Ihr Team Ihrer Meinung nach nicht verzichten kann?

    Sprecher 17:

    Das tägliche Standup ist täglich. Ich denke, viele unserer Teams reden den ganzen Tag lang. Sie müssen sich nicht unbedingt so häufig synchronisieren. Ich hatte schon ein paar Teams, sie fallen etwa drei Tage die Woche aus und es scheint für sie zu funktionieren. Die andere vielleicht wichtigste Erkenntnis, die ich gesehen habe, sind Zeitboxen. Also keine Besprechungen von 10:00 bis 2:00 Uhr oder was auch immer es sein mag, und das wirklich aus einer erfolgreichen Perspektive zu steuern.

    Tenille:

    Ich denke in diesem Sinne, was macht Ihrer Meinung nach ein wirklich erfolgreiches Agile-Team aus?

    Sprecher 17:

    Die Fähigkeit, miteinander zu sprechen, diese Fähigkeit zu kommunizieren. Da all unsere Teams entweder hybrid oder remote arbeiten, ist es meiner Meinung nach entscheidend, sicherzustellen, dass wir über die Tools verfügen, mit denen sie das Gefühl haben, jederzeit jemanden abholen und mit ihm sprechen zu können. Und viele Leute haben immer noch keine Kameras, richtig, was mich verwirrt. Aber die Fähigkeit, Gesichtsausdrücke zu sehen, von Angesicht zu Angesicht zu sein, war so schön, weil wir das bekommen können. Das ist also der andere Schlüssel, die Fähigkeit, miteinander zu sprechen, als könnte ich die Hand reichen und dich berühren.

    Tenille:

    In Ordnung. Fantastisch. Tja, vielen Dank.

    Sprecher 17:

    Du bist willkommen. Danke.

    Tenille:

    In Ordnung. Rob und Andrew, vielen Dank, dass Sie sich ein paar Minuten Zeit für uns genommen haben. Kann ich Sie zunächst fragen, was Ihrer Meinung nach das Beste ist, was Sie diese Woche gelernt haben?


    Rob:

    Für mich ist es definitiv die schnelle Skalierung von Agile, von der wir heute Morgen erfahren haben. Wir werden es versuchen.

    Andrew:

    Mir hat die Mathe-Programmiersitzung sehr viel Spaß gemacht und ich habe verschiedene Möglichkeiten kennengelernt, Ingenieure miteinander zu verbinden und zusammenzuarbeiten.

    Tenille:

    Großartig. Als Nächstes, schätze ich, was macht Ihrer Meinung nach ein großartiges Agile-Team aus?

    Rob:

    In erster Linie, dass sie mehr als alles andere die Kontrolle darüber haben, wie sie arbeiten und woran sie arbeiten.

    Andrew:

    Ja. Für mich ist das natürlich eine psychologische Sicherheit und einfach eine gute Teamdynamik, in der sie unterschiedlicher Meinung sein können, aber trotzdem respektvoll sein und großartige Ideen entwickeln können.

    Tenille:

    Und gibt es eine Agile-Zeremonie, ohne die ein großartiges Team Ihrer Meinung nach nicht leben kann?

    Rob:

    Wahrscheinlich rückblickend. Ich denke, die Teams müssen sich ständig verbessern, und das ist ein guter Weg, das zu tun.

    Andrew:

    Einverstanden. Ja. Ja. Ja.

    Tenille:

    In Ordnung. Das ist großartig. Vielen Dank, dass du dir die Zeit genommen hast.

    Andrew:

    Vielen Dank. Ich weiß es zu schätzen.