Easy Agile Podcast Ep.4 Em Campbell-Pretty, CEO und Geschäftsführer von Pretty Agile

„Tolles Gespräch mit Dave & Eric! Wichtigste Erkenntnis: Überarbeiten Sie die Darstellung der Organisationsstruktur von Easy Agile. Aufregendes Zeug!“

Nick Muldoon, Mitbegründer und Co-CEO von Easy Agile, wird von Dave West, CEO, und Eric Naiburg, COO, von Scrum.org begleitet.

In dieser Folge entpacken Nick, Dave und Eric die aktuelle agile Landschaft, erörtern die Rolle des agilen Muttersprachlers und betonen, wie wichtig es ist, vernetzte Teams aufzubauen, indem die Hierarchie umgedreht und Führungskräfte in unterstützende Rollen versetzt werden.

Sie betonen, wie wichtig es ist, die Menschen, die dem Problem am nächsten stehen, in die Lage zu versetzen, den Anruf zu tätigen, und letztendlich ein Umfeld zu schaffen, in dem Erfolg erzielt werden kann.

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

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

Transkript:

Nick Muldoon:

Hallo Leute. Willkommen zum Easy Agile Podcast. Mein Name ist Nick Muldoon. Ich bin Mitbegründer und Co-CEO von Easy Agile, und heute kommen zwei wundervolle Gäste zu mir, Eric Naiburg, der Chief Operating Officer von scrum.org, und Dave West, der Chief Executive Officer von scrum.org. Bevor wir beginnen, möchte ich mich bei den traditionellen Hütern des Landes bedanken, von dem aus wir heute senden, den Menschen im Dharawal sprechenden Land. Wir erweisen den älteren, gegenwärtigen und zukünftigen Ältesten unseren Respekt und erweisen allen Aborigines, den Bewohnern der Torres Strait Islands und den Ureinwohnern der First Nations, die heute zu uns kommen, den gleichen Respekt. Also, meine Herren, vielen Dank, dass Sie sich etwas Zeit genommen haben. Wir wissen das wirklich zu schätzen.

Erik Naiburg:

Ich danke dir.

Nick Muldoon:

Ich schätze, ich würde gerne einfach reinspringen und, Dave, ich habe zuerst eine Frage an dich und eine weitere an dich, Eric. Ich würde gerne eine kurze Einschätzung der heutigen Agile-Landschaft bekommen, Dave, und ich schätze, die Veränderungen, die Sie vielleicht gesehen haben, jetzt, wo wir diese COVID-Lockdowns hinter uns haben, dieses Hin und Her, die COVID-Lockdowns.

Dave West:

Ja, es ist interessant. Also ich bin seit fast acht Jahren CEO hier bei scrum.org, und das hat sich in diesen acht Jahren ein wenig geändert. Ich denke, was wir erleben und ist, wage ich zu sagen, die Bereitstellungsphase, die Masseneinführung dieser agilen Arbeitsweisen und dieser agilen Denkweise in allen Branchen und in allen Organisationen. Es ist mehr als eine Sache der IT-Softwareentwicklung. Und ich denke, dass sich das während COVID beschleunigt hat. Interessant sind jedoch viele der Merkmale von Agile, die während COVID so wichtig wurden, insbesondere in Bezug auf befähigte Teams, insbesondere in Bezug auf Vertrauen, insbesondere in Bezug auf die Hierarchie und den Abbau von Hierarchien. Einige dieser Dinge werden in Frage gestellt, wenn wir zur neuen Normalität zurückkehren, die manche Leute lieber einfach nur normal hätten. Ich sehe also einiges davon. Im Allgemeinen ist Agile jedoch da, es ist gekommen, um zu bleiben. Ich denke, die Realität sieht so aus, dass die meisten Wissensarbeiter, insbesondere die Wissensarbeiter, die sich mit komplexen Arbeiten befassen, auf absehbare Zeit einen agilen Ansatz verwenden werden.

Nick Muldoon:

Und letzte Woche hast du... War es letzte Woche? Ich glaube, du warst zum ersten Mal von Angesicht zu Angesicht in Paris?

Dave West:

[Fremdsprache 00:02:37] Ich war und es hat tatsächlich die ganze Zeit geregnet, Nick. Also ja, ich habe viel Zeit drinnen in Paris verbracht.

Nick Muldoon:

Nun, was war die Meinung der Scrum-Trainer dort, aus den Gesprächen, die sie führen?

Dave West:

Ja, es war interessant. Wir haben viel über die Einführung in großem Maßstab, die Einführung in Unternehmen und die Herausforderungen gesprochen. Es ist lustig, dass es sich bei den Herausforderungen um Herausforderungen handelt, die Sie erwarten, und bei den meisten geht es um Menschen, veraltete Systeme, den Status der Mitarbeiter und die Machtposition. Wir haben viel über die Herausforderungen gesprochen, vor denen Teams in diesen großen, komplizierten Organisationen stehen. Das ist weiterhin das Gespräch. Es gibt offensichtlich Europa, sie stehen der Ukraine und dem dortigen Konflikt sehr nahe. Es gibt also definitiv einige Gespräche darüber. Wir haben sechs ukrainische Trainer und ungefähr die gleiche Anzahl russischer Trainer. Das ist also immer ein Gespräch. Und dann ist da noch ein allgemeiner Abschwung der Wirtschaft, über den auch gesprochen wurde.

Entlassungen finden in ganz Europa statt, insbesondere im Technologiesektor, aber ich denke, das nimmt bis zu einem gewissen Grad zu. Vodafone hat heute gerade angekündigt, dass sie entlassen werden, es sind etwa 6.000 Mitarbeiter, und sie sind zum Beispiel eines der größten Telekommunikationsunternehmen in Deutschland. Davon gab es definitiv einiges, aber wenn Sie Unternehmen hinzufügen, fügen Sie Konfliktunsicherheit hinzu, Sie fügen wirtschaftliche Unsicherheit hinzu, diese drei Dinge werden zusammenkommen. Aber was daran lustig war, ist, dass sie bei all dem unglaublich optimistisch und aufgeregt waren. Und ich denke, weil sie mit Leuten sprechen, mit denen sie noch nie zuvor gesprochen haben, sprechen sie mit Leuten darüber, dass Scrum eine natürliche Arbeitsweise ist, sie sprechen über die Herausforderungen, die sich aus starken Teams, Empirismus und kontinuierlicher Verbesserung ergeben.

Und ich hatte einige wirklich spannende Gespräche mit Trainern, die sagten: Ja, nun, wir machen das in diesem Luft- und Raumfahrtunternehmen oder diesem Elektroautozulieferer in Deutschland oder was auch immer, oder in diesem Finanzdienstleistungs-Startup, das Blockchain zum ersten Mal verwendet. Und natürlich verwenden sie Agile. Und so war es lustig. Es war fast so, als ob all diese Dinge, obwohl es den Hintergrund gab, trotzdem unglaublich positiv waren.

Nick Muldoon:

Also, das ist interessant, und ich denke, wenn ich über die Hintergründe von euch beiden nachdenke, Eric, dann sehe ich, dass ihr beide seit rationalen Tagen zusammengearbeitet habt...

Erik Naiburg:

Ein paar Mal.

Nick Muldoon:

... ein paar Mal, aber die Prävalenz der Agilen... Ich würde euch beide als agile Ureinwohner beschreiben und es hört sich an, Dave, letzte Woche hast du deinen Stamm dort in Paris, der agile Eingeborene ist. Und ich schätze, Eric, welche Einstellung haben die Menschen, mit denen Sie in diesen Unternehmen aus der Führungsperspektive interagieren, für Sie? Können Sie die Agile-Ureinwohner identifizieren? Ja, ich denke, ist es einfacher, sich zu unterhalten, wenn es in der Führungsebene agile Natives gibt?

Erik Naiburg:

Es ist definitiv ein einfacheres Gespräch, wenn sie da sind. Manchmal verstecken sie sich, manchmal sind es auch keine agilen Eingeborenen, die sich auch als agile Eingeborene ausgeben, was es immer ein bisschen schwierig macht, weil man die Zwiebel zurückschälen und herausfinden muss, wer sie sind und was ihre wahre Agenda ist. Ich habe letzte Woche mit einem CIO gesprochen, und er sprach von einer typischen Dauer von zwei bis drei Jahren. Was ist also ihre wahre Agenda? Was versuchen sie zu erreichen? Und Dave erwähnte die Menschen, die daran beteiligt sind, und Menschen sind oft der schwierigste Teil einer agilen Transformation oder agilen Arbeitens. Die Menschen wollen sich selbst schützen, sie wollen ihr Revier schützen, sie wollen die Dinge tun, die sie tun müssen, um auch erfolgreich zu sein. Sie sehen das also als Gespräche mit Führungskräften innerhalb von Organisationen, und sie wollen es besser machen, sie wollen sich verbessern, sie wollen schneller liefern, aber sie stehen immer noch unter diesem Druck. Organisationen, zumindest große Organisationen, haben sich nicht verändert. Sie haben immer noch Vorstände, und sie berichten immer noch an diese Gremien, und auch diese Gremien haben immer noch ihre eigenen Agenden.

Nick Muldoon:

Sie lassen mich an ein Gespräch erinnern, das ich vor mehreren Jahren geführt habe, aber auf einer Reise durch Europa, und es war mit dem Agile-Muttersprachler, der Agile Practice Lead war und wahrscheinlich nicht maskierte, wahrscheinlich war er legitim ein Agile-Native, aber sie sprachen über die gemischten Anreize für ihren, vielleicht nicht ihren direkten Leiter, aber den VP weiter oben. Und es war eigentlich ein, ich will nicht sagen, ein Nullsummenspiel, aber es gab eine Art Lehensache, bei der die verschiedenen VPs um Ressourcen kämpften, Leute, was auch immer, weil das weitere Boni freischalten würde. Aber am Ende des Tages ging es nicht darum, das gesamte Finanzdienstleistungsunternehmen zu optimieren. Sehen wir das heute noch?

Dave West:

Oh, sehr. Tatsächlich sagt ein Kollege von uns: „In der Wissenschaft gab es früher ein Sprichwort, Wissenschaft schreitet mit einer Beerdigung nach der anderen voran.“ Und ich denke, Agile hat definitiv einiges davon, hoffentlich keine Beerdigungen, sondern Pensionierungen.

Nick Muldoon:

Pensionierungen

Dave West:

Ruhestand.

Nick Muldoon:

Ja.

Dave West:

Ja. Die Realität ist, dass, wenn Sie die Anreize nicht aufeinander abgestimmt haben, wenn die Teams nicht auf diese Anreize ausgerichtet sind und die Führung nicht auf diese konsistenten Anreize ausgerichtet ist, Sie immer mit einigen Herausforderungen zu kämpfen haben werden. Was so frustrierend ist, ist, dass wir alle wissen, dass die industrielle Revolution und insbesondere die jüngste Revolution der Massenproduktion und des Öls, die gerade in der Einsatzphase kurz nach dem Zweiten Weltkrieg stattfand, durch veränderte Arbeitspraktiken ermöglicht wurde, die von Leuten wie Ford und Deming und all diesen Menschen geschaffen wurden. Das wissen wir alle. Die digitale Revolution findet um uns herum statt. Es könnte sogar an uns vorbeigehen, wenn Sie dem KI-Buzz glauben, der gerade passiert. Wir werden vielleicht zur Seite gestellt und Computer übernehmen vielleicht einfach die Kontrolle, aber diese Digitalisierung passiert, und Sie sind mit Führungskräften zusammen und sie sagen: „Ja, respektiere das absolut. Wir werden hundertprozentig digital sein. Wir sind eine Fluggesellschaft, aber in Wirklichkeit sind wir ein digitales Unternehmen mit Flügeln.“

Sie beschreiben sich selbst auf diese Weise, und dann wollen sie nicht die Grundlagen in Frage stellen, wie Autorität verwaltet wird, wie Werte verwaltet werden, wie Risiken transparent gemacht werden, wie Regierungsführung abläuft, wie Finanzierung und Planung usw. erfolgen. Sie wollen keine dieser Annahmen in Frage stellen. Sie mögen das so wie es ist. Aber wir werden digital. Es ist ironisch, dass es immer noch passiert. Das ist jedoch nicht ganz hundertprozentig. Die Organisationen, die das verstehen, die Organisationen mit Führungskräften, die entweder aufschlussreich oder motiviert sind oder vielleicht ein Buch schreiben wollen oder so. Vielleicht sind ihre Gründe nicht immer so klar, aber diese Führungskräfte ziehen diese Organisationen ins 21. Jahrhundert.

Tolles Beispiel. Proctor und Gamble, Gillette. Gillette, das neueste Peeling-Rasiermesser. Ich sehe, dass du es leider nicht benutzt hast, Nick, mit deinem ziemlich hübschen Bart. Also ja. Wie auch immer, ich benutze es oft, wie du siehst. Das Exfo... Wurde mit Scrum und Agile gebaut. Das ist Proctor and Gamble, eine uralte, okay nicht uralte, eine ältere Organisation, die es aber wirklich in sich hat. Sie erkennen, dass sie auf ganz andere Weise arbeiten müssen, wenn sie mit ihren Kunden, ihren Partnern, ihren Lieferanten Schritt halten wollen. Es sind also keine Rosen, aber es gibt sozusagen Rosen im Garten.

Erik Naiburg:

Und es geht noch weiter, wenn man an diese Organisation denkt, denkt man an das, was Gillette getan hat, es geht über das traditionelle agile Denken hinaus. Traditionelles agiles Denken, wir denken an Software, und das ist Technik, das ist Fertigung, das ist die Zusammenführung von Marketing, denn in solchen Organisationen bestimmt das Marketing, was das Produkt sein wird, und dann findet die Technik heraus, wie dieses Produkt geliefert wird und so weiter. Es geht also wirklich darum, die gesamte Organisation zusammenzubringen und herauszufinden, wie wir etwas liefern, und zwar gemeinsam. Ich denke, das ist eines der großen Dinge, die wir erleben. Und eine der großen Veränderungen, die Agile vorantreibt, ist das Team. Sie haben also über Anreize und Teamanreize gesprochen, das ist ein Teil davon, aber es geht um Teamverantwortung. Es ist Teamzusammenhalt.

Es ist so, dass sie sich letztendlich alle verantwortlich fühlen und diese Verantwortung als Team zusammenbringen, und ich denke sogar... Also meine Frau arbeitet in der Fertigung und es ist immer... Sie ist auf der Forschungs- und Entwicklungsseite und beschwert sich über die Marketing-Leute. Sie haben diese Gespräche über: „Nun, sie wissen nicht, was es braucht, um dieses Ding tatsächlich zu bauen. Sie haben einfach den Traum.“ Und indem sie sie in diesem Team zusammenbringen und sie wirklich ihre täglichen Drums haben, sie planen zusammen und führen sie diese harten Gespräche respektvoll, das fängt an, dieses Team aufzubauen und es so aufzubauen, dass sie tatsächlich schneller liefern können und mehr liefern können, was der Kunde will.

Dave West:

Kann ich mich einfach anlehnen, es tut mir leid, wir haben hier gerade ein bisschen die Kontrolle übernommen, Nick, aber ich möchte mich einfach auf etwas stützen, von dem Eric gesagt hat, dass es nur um die Teams geht. Eines der grundlegenden Probleme, die wir in vielen Organisationen sehen, ist die Hierarchie. Denn wenn man diese riesigen Hierarchien hat, heißt es natürlich: „Ich muss die Kontrolle über etwas haben. Ich muss die Verantwortung für Dinge übernehmen. Ich muss für bestimmte Dinge unverantwortlich davonkommen.“ So funktionieren Hierarchien. Und das untergräbt oft die Fähigkeit eines Teams, effektiv zu funktionieren. Wir müssen das umdrehen, sodass diese Hierarchien nicht mehr an der Spitze der Teams stehen, sondern unter den Teams stehen müssen, die sie unterstützen. Stell sie dir vor wie die Stützbalken auf Brücken oder was auch immer. Sie haben einige fabelhafte Brücken in Australien und in Melbourne und an solchen Orten und in Sydney.

Stellen Sie es sich also kopfüber vor und halten Sie die Teams auf den Kopf. Aber das bedeutet, um noch einmal auf Anreize zurückzukommen, dass diese Führungskräfte verstehen müssen, wofür sie in dieser neuen Welt verantwortlich sind. Und das tun sie aus einem sehr guten Grund. Sie tun es, weil die Teams sein müssen, weil sie näher am Problem sind, sie müssen in die Lage versetzt werden, Entscheidungen in Echtzeit auf der Grundlage der Daten und der Informationen zu treffen, die sie haben, sie müssen eine klare Sichtlinie zum Kunden haben. All diese Dinge sind der Grund, warum eine Hierarchie einfach zu langsam reagiert und zu bürokratisch ist. Also müssen wir es umdrehen und diese Teams unterstützen. Und das ist eine große Herausforderung.

Nick Muldoon:

Ich liebe das. Ihr zwei habt mir etwas zum Nachdenken gegeben. In den ersten sechs Lebensjahren des Unternehmens, von Easy Agile, hatten wir also eine sehr einfache Teamseite, und Dave und ich als Co-CEOs standen ganz unten auf der Seite. Und dann hatten Sie die Anführer der Säulen. Sie hatten also, zu der Zeit war Tegan der Produktleiter, der Leiter, und sie saßen auf Dave und mir, und dann saß das Team an der Spitze. Und es ist interessant, ich versuche gerade darüber nachzudenken, dass diese Seite oder diese Visualisierung wahrscheinlich erst in den letzten 12 oder 18 Monaten, als wir 40 Leute besucht haben, umgeblättert hat. Ich habe natürlich einen Aktionspunkt, der daraus hervorgehen muss, danke, meine Herren, um ihn tatsächlich umzudrehen, weil es ein Kommunikationsmechanismus ist, aber wenn wir uns in dieser unterstützenden Rolle zur Unterstützung der Leute tatsächlich in die Grundlage stellen, gibt das, glaube ich, den Ton an, wie die Teammitglieder über sich selbst denken, und vielleicht auch diesen Beitrag zur Rechenschaftspflicht, Eric.

Erik Naiburg:

Ja. Ja. Das ist interessant, denn manchmal sind es diese kleinen Dinge, die das Denken und Fühlen der Menschen verändern. Ich verwende viele Sportanalogien, wenn ich mit Menschen spreche und mich mit ihnen treffe, und vor allem, wenn Dave davon sprach, die Menschen zu stärken, die dem Problem am nächsten stehen. Im Sport müssen wir dasselbe tun. Wenn wir darauf warten müssen, dass der Trainer uns sagt, wir sollen den Ball weitergeben, wird das niemals passieren. Wir müssen es den Leuten ermöglichen, Entscheidungen zu treffen und diese Entscheidungen auf dem Spielfeld zu treffen. Das müssen wir auch auf Unternehmen anwenden. Erlauben Sie den Menschen, die dem Problem am nächsten sind und dem, was passiert, am nächsten sind, diese Entscheidungen auch innerhalb des Unternehmens zu treffen.

Nick Muldoon:

Wenn wir also zu Proctor and Gamble zurückkehren und wir kein Kaninchenloch darauf werfen müssen, aber sie sind eines der großen, langlebigen Unternehmen, und ich weiß nicht, wie sie vor allem vorgehen, aber ich denke an GE, und GE hatte ihr internes Universitätsprogramm, und sie haben ihre Führungskräfte geschult, wie man führt. Wie geht ein Proctor and Gamble vor, um dieses Gespräch intern zu verändern, und was ist dieser Zeitrahmen? Weil Sie vermutlich mit jemandem beginnen, der in einem Team ist. Müssen Sie sie im Laufe der Zeit in der Hierarchie des Unternehmens verbessern?

Dave West:

Es ist interessant. Ich habe Glück, vielleicht weil wir beide Briten sind und in Boston leben. Ich habe das Glück, ziemlich viel Zeit damit zu verbringen, und auf unserer Website gibt es Videos dazu, übrigens, Interviews mit Dave Ingram, der R & D für Männerpflege leitet, es heißt, im Gillette-Teil von P and G. Und die Fallstudie ist da draußen. Also habe ich viel mit ihm darüber gesprochen, wie man es in einer riesigen Organisation vorantreibt, in der sie alles zu verlieren haben. Sie haben Produkte, die fantastisch sind, sie sind innovativ, diese Produkte sind die Produkte, die Sie in Ihren Einkaufswagen legen, wenn Sie den Gang entlang gehen. Sie wollen das nicht vermasseln. Seien wir ehrlich. Wenn plötzlich, aufgrund einiger Innovationen, keine Rasiermesser mehr in den Regalen stehen, dann brauche ich als Vorstandsmitglied ein Rasiermesser. Also werde ich ein alternatives Produkt kaufen, und es ist möglich, dass ich dann immer dieses Produkt kaufe.

Sie müssen also sehr, sehr vorsichtig sein. Sie haben mehr zu verlieren. Wir sprechen also viel darüber, wie Sie mit Veränderungen umgehen, und das ist alles oben Genannte. Was er sehr geschickt gemacht hat, ist, dass er die Rolle des Product Owners oder die Person, die Rolle des Klebers, gestärkt hat, ob es nun Scrum oder etwas anderes ist, und er hat wirklich in diese Change Agents in seiner Organisation investiert, und er wird definitiv davon geleitet, er war sehr ehrlich und offen darüber, dass er nicht alle Antworten hat und er nach ihnen sucht, die ihm dabei helfen, was Sie vielleicht nicht tun würden erwarten Sie von einer traditionellen Organisation, in der-

Nick Muldoon:

Der Leiter muss möglicherweise das Gefühl haben, die Antwort auf all diese Fragen zu haben.

Dave West:

Exakt. Und das hat er wirklich, wirklich gut gemacht. Und vor allem, weil er sagt: „Nun, mein Erfolg ist letztlich ihr Erfolg. Wenn ich sie also ein bisschen erfolgreicher machen kann, gibt es mehr von ihnen als mich, also lassen Sie uns dafür sorgen, dass es funktioniert.“ Was ich für eine ungewöhnlich ehrliche und sehr aufschlussreiche Sicht darauf halte. Er hat es also hauptsächlich in den Eigentumsbereichen des Produktmanagements vorangetrieben. Anschließend hat er eine entsprechende Support-Umgebung geschaffen. Dann hat er definitiv für die Erfolge geworben. Er hat viel Zeit damit verbracht, funktionsübergreifende Teams aufzubauen. Die Sache, von der Eric gesprochen hat. Und ich habe wirklich sehr vorsichtig mit ihrer Führung zusammengearbeitet. Wenn Sie Materialwissenschaft sind, gibt es eine ganze Abteilung, wenn es Marketing gibt, gibt es diese ganze Kanal-Sache, die sie haben. Im Grunde arbeiten sie mit ihren Führungskräften zusammen, um das Umfeld zu schaffen, in dem Erfolg eintreten kann. Und ich denke nicht, dass es einfach ist. Ich denke, auf dem Weg dorthin gibt es viele überraschende Hindernisse, und ich kann in dieser Hinsicht nicht für ihn sprechen, aber er hat den Ansatz des Teilens und Herrschens gewählt und sich auf diese Katalysatorrolle konzentriert.

Nick Muldoon:

Weil Sie offensichtlich eine Menge Schulungen für verschiedene, naja, ich schätze, Leute auf verschiedenen Ebenen in diesen Unternehmen anbieten. Und offensichtlich ist es weit davon entfernt, eine CST- und eine CSM- und eine CSPO-Zertifizierung zu haben, die ein Jahrzehnt, anderthalb Jahrzehnte zurückreicht. Wie hoch ist die Akzeptanz des Führungstrainings? Und wie sieht das aus, Eric? Besteht derzeit ein erneutes Interesse daran oder fordern die Leute mehr Führungskräftetraining? Ist es für die Führungskräfte von heute zweckdienlich?

Erik Naiburg:

Also ich denke, bis zu einem gewissen Punkt ist es so. Wir sehen sicherlich ein Wachstum in der Ausbildung von Führungskräften. Tatsächlich haben Dave und ich mir diese Zahlen Anfang dieser Woche oder gestern angesehen, schätze ich. Heute [unhörbar 00:21:29]

Nick Muldoon:

Gibt es Zahlen, die Sie mit uns teilen können?

Erik Naiburg:

Es ist schwierig, die genauen Zahlen zu nennen, aber wir verzeichnen einen zweistelligen Anstieg der Zahl der Schüler, die an unseren Führungskursen teilnehmen. Sowohl wie messen Sie, also unsere faktengestützten Managementkurse, als auch unser Führungstraining, aber das geht auch nur so weit, weil viele dieser Leute, je nachdem, wie weit Sie in der Organisation sind, nicht bereit sind, sich viel Zeit zu nehmen, um an solchen Schulungen teilzunehmen. Vieles davon passiert also in diesem Coaching. Sie stellen die Executive Coaches oder die Agile-Coaches ein, die da drin sind. Die Scrum Master, die da drin sind, arbeiten tatsächlich daran, diese Leute zu coachen. Und vieles davon dreht sich weniger um das Training als vielmehr um die Veränderungen der Denkweise. Wenn Sie sich also unseren Kurs zur agilen Führung ansehen, wird ein großer Teil davon darauf verwendet, die Menschen dazu zu bringen, anders zu denken. Und ein Teil davon hat dich wirklich überfordert, Aktivitäten, bei denen es wirklich hilft, diese Punkte zu vermitteln: „Wow, ich muss anders denken. Ich muss anders arbeiten. Ich muss die Menschen anders behandeln.“

Nick Muldoon:

Anders.

Erik Naiburg:

Das ist es, und wir sehen gute Erfolge damit, vor allem, wenn die Glühbirne bei den Leuten ausgeht und die Glühbirne, die ausgeht und sagt: „Wow, das ist anders.“ Wir haben einige Übungen in unseren Klassen, die dich wirklich zum Nachdenken anregen und dich anregen... Es gibt zum Beispiel eine, bei der Sie denken, Sie tun das Richtige für den Kunden, und Sie denken, dass Sie genau das Richtige tun, bis es den Kunden umbringt, weil Sie nicht unbedingt das Ganze durchdacht haben. Es heißt: „Nun, das ist es, was der Kunde wollte, also müssen wir es tun, aber vielleicht hätte ich mich mit dem Team zusammensetzen und das Team Entscheidungen treffen lassen sollen.“ Ich gehe ein bisschen extrem vor, aber...

Nick Muldoon:

Nein, ich weiß das zu schätzen.

Erik Naiburg:

... es sind solche Dinge, die wir ändern müssen. Und vieles, was wir im Kurs tun, ist, Führungskräfte darüber aufzuklären, was diese Teams gerade durchmachen und was die einzelnen Mitglieder dieser Teams benötigen und welche Art von Unterstützung sie benötigen, nicht wie man diese Teams leitet, nicht wie man mit diesen Leuten umgeht. Aber wie befähigt und befähigt man diese Menschen, erfolgreich zu sein?

Nick Muldoon:

Ich möchte nur kurz zurückspulen, tut mir leid.

Erik Naiburg:

Menschen töten.

Nick Muldoon:

Es klang, als gäbe es einen Reibungspunkt, wenn man diese Führungskräfte dazu bringt, sich die Zeit außerhalb des Büros zu nehmen, um sich weiterzubilden.

Erik Naiburg:

Das gibt es, ja.

Nick Muldoon:

Ist das richtig?

Erik Naiburg:

Ja.

Dave West:

Es ist unglaublich schwierig, wenn Sie in einer großen Organisation arbeiten, insbesondere wenn sich Ihr Terminplan ständig acht bis neun Stunden am Tag mit Besprechungen überschneidet, damit sie sich diesen Moment Zeit nehmen können, um einen Schritt zurückzutreten. Jeder, ich bin der festen Überzeugung, Nick, dass sich jeder Zeit nehmen muss, um in seine persönliche und berufliche Entwicklung zu investieren. Und diese Zeit ist keine Verschwendung. Letztlich ist es eine unglaublich gute Investition.

Nick Muldoon:

Ja.

Dave West:

Wir wissen...

Nick Muldoon:

Es ist ein großartiger ROI.

Dave West:

Vollkommen. Auch wenn es dich einfach verärgert, auch wenn du dadurch diesen Moment der Klarheit hast. Es ist keine Überraschung, dass Leute wie Bill Gates alle drei bis sechs Monate auf Exerzitien gehen und er seine große Tasche voller Bücher nimmt...

Nick Muldoon:

Buecher.

Dave West:

Und er geht für ein paar Tage vom Stromnetz, nur um ihn neu zu starten. Ich denke, dass diese Zeit unglaublich effektiv ist. Interessant ist jedoch, dass wir unterlegen sind, insbesondere in Amerika, und ich bin mir sicher, dass das in Australien stimmt, es ist sicherlich wahr, dass in England, wo ich herkomme, Bewegung wichtiger ist als Ergebnisse. Es dreht sich alles um die Anträge. Wenn du beschäftigt aussiehst, wirst du nicht gefeuert. Und ich denke, bis zu einem gewissen Grad haben wir das in der Schule gelernt. Ich weiß nicht, ob deine Eltern das zu dir gesagt haben oder ob du vielleicht deinen ersten Job bekommen hast. Ich habe an einer Feinkosttheke im Coop-Supermarkt gearbeitet, und ich erinnere mich, dass dort ein alter Arbeiter war, der sich zu mir umdrehte und sagte: „Was auch immer Sie tun, wenn der Manager vorbeikommt“, Mr. Short-

Nick Muldoon:

Sieh beschäftigt aus.

Dave West:

... war sein Name. Und er war alles, was der Name impliziert. „Mr. Short kommt vorbei, sieht aus, als ob Sie etwas tun, fangen Sie an, etwas zu putzen, sonst nimmt er Sie ab und zwingt Sie, Proviant zu machen, und Sie wollen sich nicht mit der Milch herumschlagen, sie ist ranzig.“ Und daran erinnere ich mich. Sieh beschäftigt aus. Und ich denke, wir haben viel in unserer Kultur. Ich versuche mir jede Woche Zeit zu nehmen. Ich buche zum Beispiel meine Mittagspause, ich buche sie und ich versuche immer, etwas darin zu tun. Ich versuche, mir einen TED-Vortrag anzusehen, etwas zu lesen, nur um dir den Kopf freizumachen, über etwas anderes nachzudenken. Ich denke, diese Zeit ist unglaublich wichtig. Allerdings...

Nick Muldoon:

Lernen Sie eine neue Perspektive kennen, oder?

Dave West:

Exakt. Auch wenn das heißt, auch wenn das Zeug, das du dir ansiehst oder was auch immer, nicht unbedingt relevant ist. Manchmal ist dieser Mangel an Relevanz genau das, was du brauchst, weil dein Verstand etwas tut.

Nick Muldoon:

Eine mentale Pause.

Dave West:

Exakt. Und in den amerikanischen Unternehmen, und ich denke, das ist im Allgemeinen ein Unternehmen, passiert das nicht. Die Leute sind übermäßig verschuldet, sie sind unglaublich beschäftigt. Sie müssen an diesen Treffen teilnehmen, sonst wird ihr Profil geschwächt. Und ich denke, das geht zu Lasten der Organisation und des Unternehmens. Hier ist eine Frage, Nick.

Nick Muldoon:

Ja.

Dave West:

Wem hast du in letzter Zeit geholfen?

Nick Muldoon:

Wem habe ich in letzter Zeit geholfen? Ich verbringe die meiste Zeit damit, und ich ziehe den größten Teil meiner Energie aus Coaching-Gesprächen mit Einzelpersonen. In meinem [unhörbaren 00:27:35] Profil habe ich einen Futuristen ganz weit oben, und deshalb liebe ich es herauszufinden, wie dein Leben und deine Karriere in fünf Jahren aussehen werden? Das sind die Gespräche, von denen ich wirklich begeistert bin.

Dave West:

Und das ist es, was jeder... Wem du geholfen hast, ist wichtiger als das, was du getan hast.

Nick Muldoon:

Ja.

Dave West:

Und ich denke, das musst du ausbalancieren.

Nick Muldoon:

Ich habe diese Statistiken abgerufen, weil ich dachte, Sie könnten sie interessant finden. Wir haben letztes Jahr eine Umfrage unter einer Untergruppe unserer Kunden durchgeführt. Und wir hatten 423 Teams. Es ist also keine riesige Stichprobengröße, sondern 423 Teams. Und der Grund, warum ich darüber nachdenke, ist, dass es eine Menge davon gibt, wie war die Statistik hier? Nur um dir ein Gefühl zu geben, die gängigste Sprintdauer sind 14- oder zweiwöchige Sprints. Die meisten Teams haben sechs Personen, die beteiligt sind. Fibonacci steht für Story Pointer, eine Schätzung. 10% dieser Teams haben erreicht, was sie sich zu Beginn des Sprints vorgenommen hatten. Also haben die Teams, diese 10% der Teams, die Teilmenge, ihren Sprints zwar Arbeit hinzugefügt, aber Teams, die erfolglos waren, rollten die Arbeit von Sprint zu Sprint weiter.

Vielleicht deutete es uns also an, dass es Teams gibt, die sich zu sehr verpflichten und zu wenig liefern, und tatsächlich scheinen 90% von ihnen, 90% der Umfrageteams, zu viel und zu wenig zu liefern. Und dann gibt es Teams, denen vielleicht Zeit bleibt, Dave, vielleicht für eine Ausbildung oder etwas Freizeit in ihrem zweiwöchigen Sprint. Und sie nehmen tatsächlich mehr Arbeit auf sich, und das erreichen sie auch. Und ich denke nur darüber nach, versuchen 90% dieser Teams, beschäftigt zu sein, oder versuchen sie, als beschäftigt wahrgenommen zu werden? Auch wenn das auf Kosten der tatsächlichen Umsetzung geht?

Erik Naiburg:

Oder werden sie sogar dazu gedrängt? Es ist interessant, bei unserem Professional Scrum Master One, unserem PSM-Test, gibt es eine Frage, bei der die Leute oft falsch liegen. Und ich denke, es ist eine großartige Frage, ich paraphrasiere, weil ich mich nicht mehr genau daran erinnern kann, aber es geht im Wesentlichen darum, wie viel des Sprint-Backlogs gefüllt werden muss, wenn es um die Sprint-Planung geht. Und eine beträchtliche Anzahl von Leuten sagt, dass es nach Abschluss der Sprint-Planung abgeschlossen sein muss. Das widerspricht Agile und Scrum.

Dave West:

Exakt.

Erik Naiburg:

Weil wir es dort nicht wissen. Da ist diese Unsicherheit. Alles, was wir brauchen, ist genug, um loszulegen, und wenn wir einmal angefangen haben, aber ich glaube, die Leute haben Angst vor: „Nun, wir haben zwei Wochen, wir müssen in der Lage sein, diese zwei Wochen zu planen, und das ist ein Teil des Drucks von oben, über den wir gesprochen haben. „Nun, wir müssen zeigen, dass wir hier zwei Wochen Arbeit vor uns haben und dass wir nicht herumsitzen, also füllen wir sie auf.“ Und das sind einige der falschen Bezeichnungen von Agile und Scrum. „Nun, es ist ein zweiwöchiger Sprint, wir müssen zwei Wochen einplanen.“ Nun, nein, das tun wir nicht. Wir brauchen ein Ziel. Wo werden wir hinkommen? Wie wir das erreichen, wird einige Zeit in Anspruch nehmen, denn wir werden im Laufe der Zeit lernen. Tatsächlich haben wir in dem Scrum-Team, dem ich gerade angehöre, einen dreiwöchigen Sprint durchgeführt, und nach zwei Wochen haben wir unser Ziel tatsächlich erreicht. Und jetzt können wir auf diesem Ziel aufbauen. Und wir haben dieses Ziel bereits eine Woche früher erreicht, was großartig ist.

Nick Muldoon:

Glaubst du, Eric, dass Führungskräfte befürchten, dass, wenn sie nicht zwei Wochen Arbeit geleistet haben, sie einfach ihre Daumen drehen werden?

Erik Naiburg:

Ich weiß nicht, ob es eine Angst vor der Führung ist. Ich denke, es ist eine Vorstellung, die die Arbeitnehmer davon haben, was die Führung denkt. Ich denke, es ist eher das. Und ich denke, es ist das: „Nun, wir haben gesagt, wir haben zwei Wochen“, und sie werden uns fragen, das Management wird sagen: „Wann liefern Sie?“ Ich weiß nicht, ob wir jemals davon wegkommen werden, wann werden wir eine Frage stellen, obwohl wir ständig versuchen, von dieser Antwort wegzukommen. Aber sie werden es fragen. Also, wenn sie danach fragen, sollte ich besser vorbereitet sein, was bedeutet, dass ich besser einen ganzen Haufen Arbeit vorbereitet habe. Und das macht einfach alles kaputt, was wir unterrichten. Es macht alles kaputt, was wir in Agile denken.

Und alles, was ich für die Planung brauche, ist ein Ziel und eine Vorstellung davon, wie ich dorthin komme. Und im Laufe der Zeit sollten wir es uns noch einmal ansehen und weiter darauf eingehen. Aber es erstaunt mich, wie oft einige der Antworten auf diese Frage lauten: Nach Abschluss der Sprint-Planung haben Sie einen vollständigen Sprint-Backlog, Sie haben genug, um loszulegen. Ich habe vergessen, was einige der anderen sind. Aber es erstaunt mich, wie oft, wenn ich Tests durchsehe, die Leute das Sprint-Backlog mit vollem Rücken platzieren, wo es sogar direkt im Scrum-Guide heißt: „Du wirst während des gesamten Sprints überprüfen und dich anpassen.“ Nun, wie inspiziere ich und passe mich an, wenn ich bereits entschieden habe, was ich tun werde?

Nick Muldoon:

Wer trägt die Verantwortung? Wenn es nicht wirklich der Wunsch der Führung ist, dass Sie Ihre gesamte Zeit voll nutzen und zu hundert Prozent ausgelastet sind, liegt es dann in der Verantwortung des Leiters, dies bekannt zu machen, oder liegt es in der Verantwortung des Teams, sich an der Konversation zu beteiligen?

Dave West:

Es ist der Anführer.

Erik Naiburg:

Ja.

Nick Muldoon:

Ja. Ja, beide. Ja.

Dave West:

Ich denke, es ist eher die Führungskraft, weil ich denke, sie müssen ein Umfeld schaffen, in dem das Team es tatsächlich herausfordern und diese sehr klare Konversation führen kann. Was mich an deinem Stan beunruhigt, ist die Tatsache, dass ich nicht... Die ersten paar Sprints. Ja, vielleicht bist du übermäßig aufgeregt, vielleicht füllst du den Sprint, was du nicht brauchst. Vielleicht bist du einfach scharf darauf. Das ist okay. Die Sache ist, was passiert beim dritten oder vierten oder fünften Sprint, wenn sich dasselbe Muster immer und immer wieder manifestiert. Das ist besorgniserregend. Und ich denke, das spricht wirklich deutlich für den Mangel an Hilfe, den das Team hat. Egal, ob man es Agile-Coach nennt, und in Australien, ich denke, der Begriff Agile-Manager wird verwendet, oder ob es ein Agile ist oder ob es ein Scrum Master ist, was auch immer. Scrum.org hat einen Scrum Master.

Und der Grund, warum wir einen Scrum Master haben, ist nicht, dass wir Scrum nicht kennen, obwohl es an manchen Tagen fraglich sein könnte. Aber Schusterkinder, all das Zeug. Aber die Realität ist, wir kennen Scrum, wir sprechen darüber, wir atmen es ein, wir lieben es. Aber jemanden zu haben, der einen Schritt zurücktritt und sagt: „Moment, Westy, was hast du da gemacht? Hast du das Team ermuntert, den Sprint zu füllen? Hast du ihnen ein unrealistisches Ziel gesetzt? Hast du ihnen zugehört und ihnen die Fragen gestellt? Oder hast du ihnen gesagt, was du willst? Und was glaubst du, wird das bewirken?“ Ich weiß, dass ich das getan habe, weil Eric und ich sozusagen die Sprints finanzieren. Wenn wir zu einem Sprint-Review gehen und Dinge sagen, weil ein Sprint-Review letztendlich dazu da ist, dem Team Feedback zu geben, damit es es überprüfen und sich für den nächsten Sprint anpassen kann.

Sie können die Vergangenheit nicht ändern, aber Sie können die Zukunft auf der Grundlage von Feedback ändern. Wenn ich sage: „Oh, nun, das ist Quatsch und du solltest das tun, und was ist damit?“ Ja, das wird Auswirkungen haben. Letztlich müssen wir als Führungskräfte also darüber nachdenken, was wir mitbringen, und auch jemanden haben, der uns oft hilft, die Führungskraft zu sein, die wir sein müssen, weil wir begeistert und begeistert sind und sagen: „Oh, du schaffst das und das? Lass es uns machen. Das klingt großartig.“ Und manchmal kann das...

Erik Naiburg:

Und das ist einer der Gründe, warum ich sage, dass es beides ist. Deshalb habe ich ja gesagt. Das ist Sache des Anführers, aber der Anführer muss daran erinnert werden. Der Leiter muss dadurch unterstützt werden, insbesondere vom Product Owner und dem Scrum Master. Der Product Owner muss in der Lage sein, nein zu sagen. Der Product Owner muss... Ich spreche von glücklichen Ohren und die meisten CEOs und Führungskräfte sind...

Nick Muldoon:

Frohe Ohren?

Erik Naiburg:

Ja. Die meisten CEOs und Führungskräfte, mit denen ich zusammengearbeitet habe, haben, wie ich es nenne, gute Ohren. Sie kommen von einem Kunden oder sie sprechen mit einer Person und haben etwas gehört, das-

Dave West:

Mach das.

Erik Naiburg:

... das eine Person vielleicht für großartig gehalten hätte. Und als Nächstes stellen sie all diese neuen Anforderungen an das Team. Und ich habe in vielen Startups und großen Unternehmen gearbeitet, wo das sogar bei IBM passiert ist. Und der Product Owner muss in der Lage sein zu sagen: „Whoa, warte mal. Das ist eine großartige Idee. Lass uns drüber nachdenken. Und wir werden es in den Backlog aufnehmen, wir werden später darüber nachdenken. Aber lassen Sie uns das Team jetzt nicht von dem ablenken, was wir versuchen und was wir erreichen wollen.“ Und deshalb sage ich, es ist beides. Es geht nicht nur um den Anführer. Sie werden den Anführer nicht vollständig ändern. Du wirst sie nicht komplett ändern, um diese aufregenden Momente nicht zu erleben. Und das macht sie zu Unternehmern. Das macht sie zu dem, was sie sind.

Aber das Team muss in der Lage sein, zurückzuschlagen. Der Leiter muss diesen Pushback akzeptieren und der Scrum Master und der Product Owner sowie andere Teammitglieder müssen in der Lage sein, diesen Pushback hinzunehmen. Ich erinnere mich, dass ich sehr, sehr früh in meiner Karriere für eine Firma namens Logicworks gearbeitet habe. Wir hatten ein Datenmodell, ein kleines Datenmodellierungstool namens Irwin. Und ich erinnere mich, dass ich in meinem Würfel saß und der CEO gerade von einem Treffen mit einem Kunden zurückkam und vorbeikam und ich war Produktmanager-

Nick Muldoon:

Eric, tu das.

Erik Naiburg:

Und fängt an darüber zu reden, wir müssen das jetzt machen und bla, bla, bla, bla, bla. Es ist wie, naja, warte. Es ist wie, aber bla, bla, bla, sie sagten, sie würden es kaufen. Nun, erstens, hast du tatsächlich mit den Leuten gesprochen, die es benutzen? Oder hast du mit jemandem hier oben gesprochen, der keine Ahnung hat, wie er das Tool tatsächlich benutzt? Was die Antwort war, ein Gespräch zwischen den CEOs. Und nur weil sie es kaufen werden, wird das irgendjemand tun? Aber du musst in der Lage sein, diese Gespräche zu führen. Man muss dieses Vertrauen zum Teamleiter aufbauen, und vom Team zum Leiter, um Rückschläge hinnehmen zu können und sagen zu können: „Das ist eine interessante Idee. Wir werden das für die Zukunft in Betracht ziehen, aber im Moment haben wir einen Schwerpunkt. Wir haben ein Sprintziel und wir werden unser Sprintziel nicht zerstören, weil du dich auf etwas gefreut hast.“

Dave West:

Wie du siehst, Nick, fällt es mir wirklich schwer, irgendwelche meiner Ideen in unsere Organisation einzubringen, weil sie solche Dinge fragen. So nervig, Nick. Sie sagen: „Okay, das ist großartig. Ist das wichtiger als diese fünf Dinge, die derzeit unser Produktziel vorantreiben?“ Ich sage: „Pfui, was meinst du? Ich kann kein Dessert, kein Hauptgericht und keine Vorspeise haben? Ich muss eine auswählen, die einfach nicht fair ist.“ Und sie sagten: „Nun, wir könnten ein anderes Team gründen und dann erfordert das Investitionen. Es wird einige Zeit dauern.“ Und ich sage: „Oh Gott, hasst du es nicht, wenn du intelligente, kluge Teamkollegen hast?“ Es ist einfach schwer.

Nick Muldoon:

Dave und ich haben definitiv, also Dave Elkin, mein Mitbegründer, hat einen technischen Hintergrund und ich habe einen Produkthintergrund. Und wir haben definitiv in der letzten Zeit, wahrscheinlich in diesem Zeitraum, in den letzten 18 Monaten, als das Team gewachsen ist oder einen bestimmten Wendepunkt erreicht hat, festgestellt, dass wir in der Vergangenheit ganz bequem Gespräche darüber geführt haben, was ist mit dieser Idee und wie steht es damit? Und wir haben versucht, Dinge herauszupicken, und wir haben sie mit dem Team besprochen, aber es gab keine Erwartung, dass diese Dinge aufgegriffen werden würden. Und dann hatten wir ein paar Beispiele, bei denen Teams losgingen und dachten, sie müssten sich diese Dinge ansehen und wir sagten: „Oh, nein, nein, nein, nein, tut uns leid, wir sollten klarstellen, dass wir nur ein Brainstorming machen wollten oder wir wollten einen Gedanken aus unserem Kopf bekommen, und wir wollten eine Perspektive darauf, aber das sollte absolut nicht bedeuten, dass du ihm hinterherlaufen solltest.“ Und so hat sich die Sprache und die Art und Weise, wie wir solche Dinge oder Aktivitäten wie diese angehen mussten, sicherlich geändert.

Erik Naiburg:

Das habe ich in letzter Zeit oft gesehen-

Nick Muldoon:

[unhörbar 00:39:50] Wendepunkt.

Erik Naiburg:

... wahrscheinlich in den letzten zwei oder so Jahren. Und ich denke, vielleicht wegen der Fernbedienung, es hat es noch schlimmer gemacht, weil man nicht all die Emotionen und Dinge mitbekommt. Aber ich habe definitiv viel mehr davon gesehen, wie: „Nun, ich bin einfach“, mir wurde gesagt, dass das nicht übersetzt werden kann, „aber ich spucke nur herum und ich werfe einfach eine Idee raus, nur um ein Gespräch zu führen.“ Und weil der Anführer es gesagt hat, denken die Leute, dass es eine Tatsache ist und dass sie es tun wollen. Und alles, was sie getan haben, war: „Hey, ich habe dieses Ding gehört. Was denkst du?“

Nick Muldoon:

Was ist deine Perspektive?

Erik Naiburg:

Ja, genau. Und ich denke, als Führungskräfte müssen wir sehr vorsichtig sein, um die Auswirkungen dessen zu verstehen, was wir sagen, weil wir es vielleicht so sehen: „Ich werfe es einfach zur Diskussion hin.“ Jemand, der am Schreibtisch saß, hörte gerade: „Oh, sie wollen, dass wir das machen.“ Und ich habe das in letzter Zeit oft in Unternehmen gesehen, auch in unserem, wo die Art und Weise, wie etwas gesagt wird oder was gesagt wird, so übernommen wird, wie wir das tun müssen, anstatt zu sagen: „Hey, hier ist eine Idee, etwas zum Aufnehmen.“ Du bist also nicht allein, Nick.

Nick Muldoon:

Ich liebe es. Hey, Eric, Oregon, das ist ein toller Ort, um es zu nennen. Das heißt, und ihr habt mir, ihr beide habt mir viel zum Nudeln gegeben, also möchte ich mich bei unseren Zuhörern und der Crew von Easy Agile vielmals dafür bedanken, dass ihr heute zu uns gekommen seid. Das weiß ich wirklich zu schätzen. Es war wunderbar, dich im Podcast zu haben.

Dave West:

Nun, danke, dass du uns eingeladen hast. Wir sind wirklich dankbar, hier zu sein, und hoffentlich hat einiges davon Sinn gemacht, und ja, lasst uns als Gemeinschaft und als Welt, die auf diese Weise arbeitet, weiter wachsen, denn ich denke, wir haben eine Menge Probleme zu lösen. Ich denke, die Art und Weise, wie wir das tun, besteht darin, dass die Menschen effektiv und eigenverantwortlich arbeiten. Also lass uns die Welt verändern, Mann.

Nick Muldoon:

Ich liebe es. Okay, das ist großartig. Danke.

„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.

‍

‍

Transkript:

Sean Blake:

Hallo zusammen. Ich bin Sean Blake, der Moderator dieser Episode des Easy Agile Podcasts. Ich bin auch Marketingleiter bei Easy Agile, wo es unsere Mission ist, Teams auf der ganzen Welt dabei zu helfen, besser zusammenzuarbeiten. Wir haben heute einen faszinierenden Gast bei uns. Es ist John Turley von Adaptavist. John ist ein pragmatischer Agile-Manager mit 25 Jahren Erfahrung in Unternehmen auf allen Ebenen, von Teams bis hin zur C-Suite. Er bringt immer echten Mehrwert und verändert die Arbeitsweise von Organisationen. Unzufrieden mit dem Standarddiskurs über Transformation und Agilität, setzt er sich leidenschaftlich dafür ein, topaktuelles Wissen aus so unterschiedlichen Bereichen wie Soziologie und Psychologie anzuwenden. Wir freuen uns sehr, John heute im Podcast zu haben. Also John, vielen Dank, dass du am Easy Agile-Podcast teilnimmst.

John Turley:

Du bist willkommen, Sean. Freut mich, hier zu sein.

Sean Blake:

Ich danke dir vielmals. Also John, du hast viel Erfahrung im agilen Bereich, im technischen Bereich. Und ich versuche nicht, dich alt zu nennen. Aber ich würde gerne ein Gefühl dafür bekommen, was sich in den letzten 25 Jahren geändert hat. Es muss einfach Tag und Nacht sein, von dem, wo du angefangen hast, bis zu dem, was du jetzt siehst.

John Turley:

Es gibt eine Menge Veränderung. Und ich fühle mich mit alten Leuten ziemlich wohl. Ich bin jetzt 48, und es ist jetzt fast 30 Jahre her. Das sagt dir, wann ich diesen Teil in der Biografie zum ersten Mal geschrieben habe. Die Technologie hat sich also geändert. Das ist umwerfend. Ich fing im operativen Bereich an, dann Infrastruktur und Projektmanagement und so. 1999, 2000, brauchten wir drei Monate und 50.000 Pfund, um ein paar Webserver mit zwei Load Balancern und Firewalls und einer Datenbank auf der Rückseite zu bauen. Und jetzt fahren wir sie in Sekunden hoch.

John Turley:

Das ist tiefgründig. Plattformtechnologie ist tiefgreifender Slack oder ich meine Plattformtechnologien, der die Art und Weise, wie wir interagieren, massiv verändert. Skalierung ist ein großes Problem. Ich würde sagen, dass die Welt irgendwie in sehr große und ziemlich kleine Organisationen unterteilt ist. In der Mitte scheint es weniger zu geben. Es ist nur ein Bauchgefühl. Wir sehen, ich glaube, das Vertrauen ist zusammengebrochen. Wir sehen das im Edelman Trust Barometer. Wir sehen, dass die Komplexität zugenommen hat. Das ist für uns zutiefst problematisch. [unhörbar 00:02:23] hat das gemessen.

John Turley:

Und aus der Gallup World Poll geht hervor, dass das Engagement der Belegschaft auf einem Tiefstand aller Zeiten liegt. Diese Dinge sind große, große Veränderungen. Was aber dasselbe ist, sind die Menschen, die Art und Weise, wie die Menschen denken, die Art und Weise, wie wir unsere Realität konstruieren, unsere Denkweise, wenn Sie so wollen, die Art und Weise, wie wir die Welt um uns herum verstehen, sehr, sehr ähnlich ist. Obwohl wir jetzt viel mehr über Agile sprechen, sind Wasserfall und Wasserfall für viele ein Schimpfwort, nicht für mich und das Gleiche gilt für Command and Control. Die Leute haben die gleichen Denkweisen. Das ist messbar und nachweisbar. Die Leute haben die gleiche Denkweise wie in Bezug auf Wasserfall und Kommando und Kontrolle, verwenden eine andere agile Sprache und verhalten sich auf die gleiche Weise. Das hat sich nicht geändert.

Sean Blake:

Sehr interessant. Sie haben also Vertrauen angesprochen und wie wir im Grunde genommen diesen Vertrauensbruch auf der ganzen Linie erlebt haben. Und ich habe gerade einen Dokumentarfilm gesehen, der auf Netflix veröffentlicht wurde, über das soziale Dilemma und darüber, wie das Vertrauen, das wir in diese großen Social-Media-Plattformen haben, schwindet. Und wir werden etwas skeptisch, was diese großen Unternehmen uns als Kunden antun. Finden Sie, dass das ein schwieriges Gleichgewicht zwischen den Menschen ist, mit denen Sie zusammenarbeiten, um kundenorientiert zu sein und trotzdem ein profitables und wachsendes Geschäft aufzubauen?

John Turley:

Ja, das tue ich. Ja, und die Art und Weise, wie es sich manifestiert, worauf wir vielleicht noch einmal eingehen werden, auf die Art der Psychologie und Soziologie sowie der Komplexitätswissenschaft, dazu komme ich später. Aber dieser Mangel an Vertrauen zeigt sich auf ganz klare Weise. Ich bin mir nicht sicher, ob es der Mangel an Vertrauen ist, der sich manifestiert. Aber es gibt eine ganz klare Sache, die passiert, sind Menschen, es gibt wiederholte Verhaltensmuster, die ich überall in meiner Arbeit sehe, nämlich eins zu eins und mit Gruppen, dass die Leute an der Idee festhalten, dass ihre Ansicht richtig ist und alles, was dieser nicht entspricht, falsch ist.

John Turley:

Das ist eine Ansicht, die aus der vorherrschenden Denkweise stammt, die [unhörbar 00:04:33] die Art von Experten- oder Leistungsträger-Mentalität nennt, und sie wird zu einem Hindernis für uns, zusammenzuarbeiten, zu lernen und innovativ zu sein. Wenn jemand mit einer anderen Sichtweise als falsch abgetan wird, dann gibt es keine gemeinsame Grundlage, um Vertrauen aufzubauen. Das Vertrauen wird von Anfang an untergraben, und das bedeutet, dass wir nicht zusammenarbeiten können, und in einer komplexen Welt, in der wir immer enger zusammenarbeiten, gemeinsam lernen und innovativ sein müssen, ist das ein tiefgreifendes Problem.

John Turley:

Und die Reaktion scheint zu sein, dass sich die Menschen tatsächlich zurückziehen, sie ziehen sich in Gruppen zurück, wir könnten sie Cliquen oder Echokammern nennen. Die Soziologen nennen diesen Prozess Homophilie. Das ist eine Funktion, wie viele von Plattformen wie Twitter sagen. Wir ziehen uns in Gruppen zurück, die die Meinungen, die wir bereits vertreten, wiederholen, die dann diese Meinungen verstärken und uns von den Meinungen anderer trennen und die Meinungen, die wir haben, bekräftigen. Die Kluft zwischen den Cliquen wird also immer größer, und gerade in Zeiten von COVID und dem Lockdown, den wir hier hatten, und dass wir vielleicht wieder in die Isolation zu gehen scheinen, trägt vielleicht dazu bei, und wir sehen es immer mehr. In einer Zeit, in der wir unsere Cliquen zum Handeln bewegen und verständnisvoll mit anderen, die andere Ansichten haben, sprechen müssen, befinden wir uns psychologisch in einer schwierigen Position, um das zu tun. Das ist also das, was wir allgemein als mangelndes Vertrauen bezeichnen könnten, das sich in der Arbeit, die ich mache, äußert. Und so sehe ich das übrigens bei fast jedem, mit dem ich zusammenarbeite, auch bei mir selbst. Es ist nicht leicht, das zu erobern.

Sean Blake:

Also, wie sieht dein Alltag aus, John? Ich glaube, Ihre offizielle Berufsbezeichnung ist Berater für digitale Transformation. Ich würde sagen, Sie arbeiten für Adaptivist als eine der bekanntesten agilen Beratungspraktiken der Welt. Was bedeutet das für Sie im Alltag? Wie sehen deine neun bis fünf aus?

John Turley:

Wir sind also wirklich an drei Dingen beteiligt. Ich bin wirklich in drei Dinge verwickelt. Und es dreht sich alles um Lernen, kollektives Lernen, organisatorisches Lernen. Wir sind also an vielen originellen Forschungen beteiligt. Wir führen diese ursprüngliche Forschung mit einer Reihe von akademischen Partnern in einem Programm durch, das wir zusammenstellen. Wir haben einen Großteil der Forschung selbst durchgeführt. Aber wenn es größer und glaubwürdiger wird, kommen andere Partner zu uns, und das sind sehr glaubwürdige Partner.

John Turley:

Und die Forschung deckt neues Lernen auf. Und dieses neue Lernen weist uns auf neue Beratungspraktiken hin, bei denen wir das Gelernte in einen Workshop einbetten können, sagen wir, oder wie wir die Forschungsinstrumente, die wir uns von der Wissenschaft ausgeliehen haben, in der realen Welt einsetzen könnten, um soziale Netzwerke oder psychologische Komplexität oder den Grad an Autonomie in der Umwelt zu messen. Das können wir dann nutzen, um mit Teams zusammenzuarbeiten, um ihnen zu helfen, von einer Art funktionsorientierter Arbeitsweise zu einer funktionsübergreifenden Arbeitsweise überzugehen. Ob wir nun über sichere und agile Release-Chains sprechen oder ob wir über Lean-Softwaremanagement und Wertströme sprechen, ob wir auf Team- oder Organisationsebene sprechen, die Herausforderung ist im Wesentlichen dieselbe. Wir müssen uns an der Schaffung von Kundennutzen in funktionsübergreifenden Teams orientieren, die sich darauf konzentrieren, diesen Wert zu liefern und nicht nur ihre Funktion zu erfüllen. Und dieser Wechsel bringt einige tiefgreifende, komplexe, tiefgreifende psychologische Herausforderungen mit sich, für die wir einfach nicht wirklich gewappnet sind. Wir bringen also gewissermaßen das Personal- und Kulturelement, die Tools und die agile Methodik gleichzeitig in die Teams ein, um ihnen zu helfen, diesen Wandel zu vollziehen. So sieht also meine tägliche Arbeit aus, also die Forschung und die Praxis.

Sean Blake:

Okay, forschen und üben. Und wenn es um die Praxis und die Förderung dieser funktionsübergreifenden Zusammenarbeit geht, wie schwer ist es für die Leute, dieser Empfehlung zuzustimmen oder sich auf das einzulassen, was das Unternehmen zu tun versucht?

John Turley:

Für die meisten Menschen ist es wirklich schwer. Meine Erfahrung vor der Recherche, die wir wohl vor ein paar Jahren begonnen haben, auf die ich mich gerade bezog, war vor Kurzem ungefähr so. Wir hatten oft, also ich habe eine lange Zeit im Agile-Bereich gearbeitet, ich weiß nicht genau, wann ich angefangen habe, in diesem Bereich zu arbeiten, mit anderen Worten, in vollem Raum, aber sagen wir, ein oder zwei Jahrzehnte, und jetzt stoßen wir auf ein wiederholtes Problem, denken wir, an ein bestimmtes Beispiel mit einem bestimmten Kunden vor etwa drei Jahren, sehr funktionsorientiert und versuchen, diesen Übergang in funktionsübergreifende Teams zu vollziehen.. Also haben wir eine Gruppe von fünf Leuten aus verschiedenen Funktionen zusammengebracht, also Designer, Tester, Entwickler, ein paar Operationsleute, und zusammen sollten sie natürlich in der Lage sein, innerhalb von 10 Tagen oder was auch immer funktionierenden Code zu veröffentlichen. Wir haben wahrscheinlich versucht, in die reale Welt zu springen.

John Turley:

Und sie waren alle großartige Leute. Ich kannte sie alle persönlich. Ich habe Zeit damit verbracht, mit ihnen allen zu arbeiten. Sie waren sehr agil in der Art und Weise, wie sie an die Entwicklung der Software herangegangen sind, und wir haben sie zunächst virtuell in einen Raum gebracht und sie gebeten, einen Code zu erstellen, der funktionsübergreifend funktioniert, ein Stück Code zu produzieren und ihn am Ende der Woche zu veröffentlichen. Und das haben sie nicht getan. Und wir dachten, was um alles in der Welt ist dort passiert? Wir haben das nicht wirklich verstanden, also haben wir es noch einmal versucht. Wir gingen jedoch davon aus, dass das Problem daran liegt, dass wir es virtuell gemacht hatten.

John Turley:

Dieses Mal haben wir alle in Polen zusammengebracht, wie es in einem Raum passiert ist, wir haben alles eingerichtet, wir haben am Anfang mit ihnen gesprochen, dann haben Leute wie ich den Raum verlassen und sie weitermachen lassen, sind bis Ende der Woche gekommen, dasselbe Ergebnis, nichts ist passiert. Und wenn du mit ihnen sprichst, während sie sagen: „Ja, mein Telefon hat gepingt und es gab einen Support-Vorfall, und du konntest es einfach nicht. „, und sie hatten viele sehr plausible Gründe, warum sie nicht als funktionsübergreifendes Team zusammenkommen konnten. Aber die Tatsache bleibt zweimal hintereinander, dass die fähigsten Leute es nicht getan haben.

John Turley:

Also haben wir wirklich lange darüber nachgedacht, einer der führenden Führungskräfte der Branche und ich. Und uns wurde klar, dass das Einzige, was passieren könnte, das Einzige, was hier schief gehen könnte, darin besteht, dass der Dialog zwischen der Gruppe im Raum irgendwie unterbrochen sein muss. Also haben wir es durchgeführt, wir haben den Workshop geleitet, nennen wir ihn ein drittes Mal. Und dieses Mal war jemand anderes im Raum, der einfach beobachtete, was vor sich ging.

John Turley:

Und sie haben sehr früh bemerkt, dass etwas passiert ist. Einer der Leute aus dem Vereinigten Königreich sagte zu einem der polnischen Entwickler: „Schauen Sie, stellen Sie sich uns als Berater vor. Wir sind hier, um Ihnen zu helfen und Wissen an Sie weiterzugeben, sodass Sie Fähigkeiten entwickeln, mit denen Sie dies selbst tun können.“ Und in diesem Moment sagte die Person, die im Raum war, dass sich die Dynamik im Raum zu ändern schien. Die Leute haben sich verglast. Und ich glaube, es war, dass das Wort Berater, das der Engländer benutzt hatte, für einen Kollegen in Krakau eine andere Bedeutung hatte. Ich glaube, diese Bedeutung, die Bedeutung von Berater, bedeutete, dass wir nur hier sind, um Ihnen zu sagen, was zu tun ist, und um eigentlich nichts zu tun und uns für jede Arbeit in die Verantwortung zu nehmen, einfach zuzusehen, wie Sie es tun.

John Turley:

Und ich glaube, an diesem Punkt sagten sie irgendwie: „Okay, in Ordnung, ich verstehe es, genauso alt, gleich alt. Wir machen die Arbeit, über die ihr Engländer redet, weil es ein englisches Unternehmen ist. „, und dieser Zusammenbruch begann. Die Frage, die wir gestellt haben, ist also, ich habe das überall gesehen. Die Frage, mit der wir uns in unserer Recherche auseinandergesetzt haben, ist also, was passiert in den Momenten, in denen der Dialog zusammenbricht, was passiert?

John Turley:

Und was wir herausgefunden haben, ist, dass es eine Reihe von Forschungsstudien gibt, die größte betrifft etwa 10.000 Personen, die zeigen, dass etwa 50% der Menschen auf einem Niveau sind, und das sind 50% der Führungskräfte in einer Studie mit 10.000, also für das mittlere Management, das obere Management, also ist es eine schiefe Zahl. In der Realität haben in Softwareteams wahrscheinlich mehr als 50% der Mitarbeiter ein Maß an psychologischer Komplexität erreicht, das der Umgebung, wie sie war, entspricht, aber beim funktionsübergreifenden Arbeiten einige Einschränkungen aufweist.

John Turley:

Sie haben also eine Denkweise, eine Art, ihre Realität zu verwirklichen, die in einer funktionalen Umgebung gut funktioniert, in einer funktionsübergreifenden Umgebung jedoch herausgefordert wird. Und diese Denkweise, diese Denkweise, die sehr verbreitet ist, ist eine Denkweise, bei der Individuen ihr Selbstwertgefühl aus ihrem Fachwissen schöpfen, um es kurz zu sagen, einfach wie eine zu starke Vereinfachung. Und die Sache ist, wenn Sie Ihr Selbstwertgefühl aus Ihrem Fachwissen schöpfen, fühlt es sich persönlich an, wenn Ihr Fachwissen in Frage gestellt wird.

John Turley:

Wenn es sich persönlich anfühlt, werden die Leute wahrscheinlich defensiv. Und das liegt nicht daran, dass sie dämlich sind oder nicht interessiert sind oder nicht wollen, die Psychologen können zeigen, dass es ein gewisses Maß an psychologischer Komplexität ist, auf dem unser Verstand einfach so funktioniert. So funktioniert unsere Bedeutungsfindung. Nun, wenn das die Phase ist, in der Sie sich befinden, wenn wir uns vorstellen, dass ich als Entwickler mit einem Tester zusammensitze und der Tester zu mir sagt: „Schau, die Art, wie du den Code geschrieben hast, ist nicht die beste Art, das für mich zu tun, weil ich ihn nicht testen kann.“

John Turley:

Wenn ich mein Selbstwertgefühl aus meiner Erfahrung als Entwickler ziehe, lehne ich das wahrscheinlich ab und fange vielleicht sogar an, Gedanken zu denken wie: „Nun, ich denke, was hier wirklich passieren muss, ist, dass du ein besserer Tester werden musst.“ Ich denke, das ist das Problem. Und dann bekommen wir diese Trennung. Und jetzt kommt die psychologische Komplexität. Und diese Phasen befinden sich in einem Rahmen, in dem wir diese Phasen durchlaufen. Auch hier handelt es sich um eine zu starke Vereinfachung, aber sie ist beobachtbar und messbar. In einem etwas späteren Stadium der psychologischen Komplexität beginnen sich die Dinge zu ändern. Die Menschen beginnen zu erkennen, dass die Welt viel komplexer ist, dass sie nicht schwarz-weiß ist. Und tatsächlich gibt es mehrere Möglichkeiten, Dinge zu tun.

John Turley:

Um also auf mein Beispiel als Entwickler zurückzukommen, könnte der Tester zu mir sagen: „Für mich ist das nicht die beste Art, den Code zu schreiben.“ Und was ich hören werde, ist das: „Oh, soweit es mich betrifft.“ Soweit es mich betrifft, ist es vielleicht nicht fair genug. Wie können wir die Art und Weise ändern, wie ich den Code schreibe, um ihn einfacher testen zu können? Aber ich kann das nicht tun, wenn ich antworte, als wäre es eine persönliche Kritik, weißt du, was ich meine? Was wir also in der Studie entdeckt haben, ist ein Zusammenhang zwischen dem Erfolg funktionsübergreifender Teams und dem Grad der psychologischen Komplexität der Führungskräfte und der Personen in diesem Team.

Sean Blake:

Interessant. Es gibt also ein Buch namens Radical Candor, das wir kürzlich bei Easy Agile gelesen haben. Und wirklich, es geht darum, sich gegenseitig konstruktives Feedback zu geben, nicht in einer Weise, in der Sie sie persönlich angreifen, sondern Sie versuchen, ehrlich darüber zu sein, wie wir besser zusammenarbeiten können. Und wie Sie in diesem Beispiel sagten, wie kann ein Entwickler Code so schreiben, dass der QA-Tester die Tests tatsächlich daran durchführen kann? Welchen Rat hat die Forschung für jemanden, der mit funktionsübergreifenden Arbeitsweisen noch nicht vertraut ist, in Bezug auf die Vorbereitung dieser Denkweise darauf, ein gewisses Maß an radikaler Offenheit zu erhalten, um dieses Feedback auf eine Weise zu erhalten, die Sie nicht persönlich nehmen?

John Turley:

Nun, das ist eine gute Frage, du hast sie wirklich gut gestellt, denn radikale Offenheit ist in Ordnung. Das haben wir, ich arbeite in einem Team, das sehr offen ist. Wir haben einige schwierige Gespräche, und wir verschönern unsere Worte nicht einmal. Und niemand wird beleidigt. Wir wissen nur, dass es eine Abkürzung ist. Wir verstehen unsere Worte vielleicht falsch, aber es ist eine Abkürzung, um das Potenzial zu erschließen, indem wir herausfinden, wie wir zusammenarbeiten können. Aber es geht nicht um die Worte, die jeder von uns auswählt, um sie auszudrücken. Es geht darum, wie der andere auf die Landung der Worte reagiert, auch wenn das jetzt ein Dialog ist, es ist eine wechselseitige Sache, es gehören immer zwei dazu.

John Turley:

Und die Art und Weise, wie wir eine Denkweise entwickeln können, die besser für funktionsübergreifendes Arbeiten geeignet ist, ist interessant. Zuallererst müssen wir die Komfortzone verlassen. Wir müssen bereit sein, unsere Komfortzone zu verlassen, nicht unbedingt weit und nicht unbedingt für sehr lange, und nicht ohne die Unterstützung und das Verständnis der Kollegen um uns herum. Aber wir müssen unsere Komfortzone verlassen. Andernfalls kann psychologisches Wachstum nicht stattfinden. Das, womit ich jetzt spreche, ist die eigentliche Arbeit von Robert Kegan und Lisa Lahey, die viel im Dialog mit radikaler Offenheit arbeiten.

John Turley:

Also müssen wir unsere Komfortzone verlassen. Aber wir müssen auch ein komplexes Problem mit einer Gruppe von Menschen angehen, wenn wir uns außerhalb unserer Komfortzone befinden. Und dieses komplexe Problem muss bedeutsam sein, und es muss auffallen, es muss etwas sein, das uns wichtig ist, es muss etwas sein, das für unsere tägliche Arbeit relevant ist. Und wenn wir in der Umgebung, in der wir arbeiten, diese Merkmale aufweisen, dann gibt es für den Einzelnen die Möglichkeit, selbst zu entscheiden, ob er seine eigene psychologische Komplexität entwickeln möchte.

John Turley:

Also diese Umgebung, die diese Eigenschaften hat, würden wir in Kegans Worten eine bewusst entwicklungsorientierte Umgebung nennen, weil wir die Entwicklung individueller Denkweisen nicht von der Umgebung trennen können, in der diese Denkweise funktioniert. Der Grund, warum die meisten von uns die Denkweise haben, die ihr Selbstwertgefühl aus Fachwissen bezieht, liegt darin, dass die meisten Umgebungen, in denen wir arbeiten, tatsächlich genau in dieser Umgebung arbeiten oder nicht. Das funktioniert in einer funktionalen Umgebung. Da wirst du befördert, dort wirst du eingestellt. Dort bekommst du dein Scrum Master-Badge und all die anderen Dinge, die dir Status verleihen und dir ein gutes Gefühl geben.

John Turley:

Die Welt, in der wir arbeiten, ehrt für viele von uns diese fachkundige Art, Sinn zu stiften. Es schadet dem Lernen und dem Eingeständnis, dass Ihre Methode vielleicht nicht die beste Methode ist, Dinge auf die gleiche Weise zu tun. Wir müssen also das Umfeld verändern, um den Einzelnen dabei zu unterstützen, sich für diesen Entwicklungsschritt zu entscheiden, denn das kann nicht etwas sein, was ihm angetan wird. Man kann Menschen nicht dazu bringen, eine komplexere Psychologie zu entwickeln. Du kannst ihnen nicht beibringen, das zu tun. Du kannst ihnen nur ein Umfeld bieten, das diesen Schritt unterstützt, wenn sie ihn tun wollen und wenn sie das nicht tun, fair genug, ist das okay. Aber vielleicht funktionsübergreifende Teams für sie, wenn sie nicht wollen, weil es schwierig ist, zu arbeiten.

Sean Blake:

Ist es ein Problem, dass Menschen ihr Fachwissen oder ihr Selbstwertgefühl aus Fachwissen beziehen? Ermutigt ein Teil davon Männer, ihr Vertrauen in Dinge außerhalb ihrer Arbeit zu finden, oder ist Fachwissen eine ehrenvolle Beschäftigung?

John Turley:

Ich würde nicht sagen, dass es überhaupt ein Problem ist. Fachwissen und die Entwicklung von Fachwissen sind ein ehrenvolles Unterfangen. Es ist ein sehr wichtiger Teil unserer psychologischen Entwicklung, Ihr Selbstwertgefühl aus Ihrem Fachwissen zu ziehen. Es ist eine Phase, die nicht wirklich übersprungen werden kann. Ich habe Ihnen bereits gesagt, dass ich solche Dinge nicht gerne ohne die Forschungsgrundlage sage, aber die Psychologie impliziert sicherlich, dass es sich um eine Phase handelt, die nicht übersprungen werden kann. Also müssen wir es tun. Wir müssen diese Phase durchmachen. In der Phase, bevor wir unser Selbstwertgefühl aus unserem Fachwissen schöpfen, beziehen wir unser Selbstwertgefühl aus unserer Mitgliedschaft in der Gruppe.

John Turley:

Und das ist auch sehr wichtig, wenn Sie sich vorstellen, dass wir Kinder sind oder Teil einer Gruppe sind, um zu überleben. Deshalb ist es von entscheidender Bedeutung, sich in dieser Gruppe einzuschmeicheln und nicht Staub aufzuwirbeln, damit wir unsere Gruppenzugehörigkeit nicht gefährden. Aber irgendwann wird den Leuten klar, dass ich eigentlich ein bisschen Staub aufwirbeln muss, wenn wir eine Richtung haben wollen. In diesem Sinne ist es also eine Entwicklung, Ihre Bedeutungsbildung davon zu trennen, Ihr Selbstwertgefühl von der Gruppe abzuziehen und Ihr Selbstwertgefühl aus Ihrem Fachwissen zu ziehen. Wenn Sie Ihr Selbstwertgefühl aus Ihrem Fachwissen ableiten, schreiben Sie diesen Code am besten, indem Sie mich jemanden darin ausbilden lassen.

John Turley:

Es ist entscheidend. Aber wie alle Entwicklungsstadien hat es seine Grenzen. Es ist also in keiner Weise problematisch, es sei denn, das Individuum befindet sich in einer komplexen Umgebung, in der diese fachkundige Art der Sinnbildung nicht gut geeignet ist. Und dann haben Sie ein Missverhältnis zwischen psychologischer Komplexität und Umweltkomplexität. Und wenn Sie ein solches Missverhältnis haben, wird die Angst des Einzelnen wahrscheinlich zunehmen, das Engagement der Mitarbeiter sinkt, sicherlich sinkt das Wohlbefinden, die Menschen kehren zu einer früheren Art der Bedeutungsbildung zurück, die stärker in ihrem Fachwissen oder der Gruppe verankert ist, nur auf den Punkt, dass sie anspruchsvoller werden müssen.

John Turley:

Das Problem ist also das Missverhältnis zwischen psychologischer Komplexität und Umweltkomplexität. Deshalb müssen wir unterstützen, da die Welt immer komplexer wird, und deshalb müssen wir alle besser darin werden, die Entwicklung von Individuen zu einem Niveau psychologischer Komplexität zu unterstützen, das der komplexeren Umgebung gerecht wird. Das ist quasi der Kern des Problems. Es ist nichts Falsches daran, ein Experte darin zu sein, Ihr Selbstwertgefühl aus Ihrem Fachwissen zu ziehen. Die Leute haben es schon immer getan, und werden es auch weiterhin tun. Jedes Mal, wenn Sie in ein Auto steigen und sich gut fühlen, weil Sie in einem Auto sitzen, beziehen Sie Ihr Selbstwertgefühl aus dem Statussymbol, das Ihrem Fachwissen sehr ähnlich ist. Als junger Mann ziehe ich meinen scharfen Anzug an und fühle mich wie eine Million Dollar. Daran ist überhaupt nichts falsch, aber es ist begrenzt. Das ist das Problem.

Sean Blake:

Verstanden, verstanden. Sie haben also über Forschung und Messung gesprochen und über eine faktengestützte Methode, Entscheidungen zu treffen. Haben wir Beweise dafür, dass eine Arbeitsweise einer anderen überlegen ist, wenn es um diese funktionsübergreifende Arbeitsweise oder die digitale Transformation oder um Teams geht, die von der alten Arbeitsweise zu einer agilen Arbeitsweise übergehen? Und wenn Sie mit diesen oder diesen Kunden sprechen, können Sie garantieren, dass, wenn sie auf diese Weise arbeiten, dies zu besseren Ergebnissen für das Unternehmen führt? Wie gehen Sie an dieses Gespräch heran?

John Turley:

Nein, ich kann keines dieser Dinge tun. Ich würde also nie in die Nähe gehen und auch nicht recherchieren, dass eine Arbeitsweise besser ist als eine andere, oder wir können sagen, wie die Denkweise und das Umfeld, dass es Arbeitsweisen gibt, die besser funktionieren, je nachdem, welches Problem Sie zu lösen versuchen. Aber es ist sehr unwahrscheinlich, dass das eine unter allen möglichen Umständen als richtig und das andere als falsch angesehen werden kann, aber mehr noch, ich würde sagen, dass es egal ist, wie Ihre Arbeitsweise ist oder wie ein Team arbeitet. Wenn die Denkweise die Art ist, Sinn zu machen, wenn sich die Realität nicht auch ändert, dann folgt man einfach einem neuen Prozess, einer neuen Art, mit der alten Denkweise zu arbeiten, und man wird dieselben Ergebnisse erzielen, nur mit anderen Worten.

John Turley:

Für mich stimmt das also nicht ganz, ich bin ziemlich voreingenommen. Ich glaube, bei der Arbeit, die ich mache, habe ich eine ziemliche Perspektive. Wenn du deine Denkweise änderst, wird sich alles andere von selbst ergeben. Wenn du alles andere änderst, aber deine Denkweise nicht änderst, wird sich nichts anderes ergeben. Was wir jedoch sagen können, ist, dass es drei Dinge gibt, nennen wir sie die drei Elemente eines funktionsübergreifenden Teams, die den Menschen in Organisationen derzeit verborgen sind.

John Turley:

Im Allgemeinen denken wir also, wenn wir Leute mit der richtigen Erfahrung und den richtigen Fähigkeiten haben, die angemessen hart arbeiten, dann werden sie als erfolgreiches funktionsübergreifendes Team arbeiten. Und wenn nicht, arbeiten sie entweder nicht hart, sie sind nicht die richtige Art von Person oder sie haben nicht die richtigen Fähigkeiten, also feuern Sie sie und stellen Sie jemand anderen ein oder geben Sie ihnen eine Schulung oder setzen Sie sie auf eine Schulung, und das löst das Problem, was natürlich nicht der Fall ist.

John Turley:

Wir würden sagen, dass es drei weitere Elemente gibt, die nach wie vor im Verborgenen des funktionsübergreifenden Teams sind und die kritischer sind als das, und wir beginnen nachzuweisen, dass es einen Zusammenhang zwischen diesen drei Dingen gibt, von denen ich Ihnen erzählen werde, sowohl in Bezug auf das Mitarbeiterengagement als auch auf die Teamleistung.

John Turley:

Und diese drei verborgenen Elemente sind die Struktur der sozialen Netzwerke, die die Art und Weise, wie Menschen arbeiten, untermauern. Wenn wir also darüber nachdenken, wie wir uns als Gruppen von Menschen organisieren, denken wir vielleicht an Hierarchien und Hierarchiediagramme und alte Diagramme und Chefs und so. Das ist nicht wirklich wichtig für ein funktionsübergreifendes Team. Viel wichtiger ist das soziale Netzwerk, das sich in diesem Team entwickelt, wer arbeitet mit wem, wann und wie zusammen, oder? Arbeiten die Entwickler und Tester und die Tester und die Ops-Leute und die Designer und die technischen Architekten alle in einem funktionsübergreifenden Team zusammen?

John Turley:

Das ist ein soziales Netzwerk. Das ist ein Netzwerk, das durch individuelle Autonomie entsteht, weil sie die Arbeit erledigen wollen, nicht weil der Chef sagt, du musst gehen und es machen. Tatsächlich kann es nicht getan werden, weil der Chef sagt, geh und tu es. Also haben wir mit einigen Freunden aus der Wissenschaft zusammengearbeitet, bei einer australischen Firma namens Polinode, um zu messen, auf welche Weise wir an die Daten kommen und wie diese sozialen Netzwerke aussehen. Und die Struktur dieser sozialen Netzwerke ist entscheidend.

John Turley:

Wenn wir uns die Struktur der sozialen Netzwerke ansehen, können wir sehen, ob diese Teams ihrer Funktion entsprechen, sorry, hierarchisch organisiert sind oder ob sie aufgrund der Netzwerkstruktur für funktionsübergreifendes Arbeiten organisiert sind. Die Netzwerkstruktur ist also ein Element. Das andere ist die psychologische Komplexität. Wir haben also mit einem Herrn namens David Rook zusammengearbeitet, der die ursprünglichen Forschungen durchgeführt und ein psychometrisches Instrument entwickelt hat, mit dem das Stadium der psychologischen Komplexität eines Individuums gemessen werden kann, sowohl die Struktur als auch die Unterstruktur. Und diese Komplexität der Denkweise hängt zusammen mit der Netzwerkstruktur auch damit zusammen, wo die Teams funktionsübergreifend funktionieren können.

John Turley:

Die dritte Sache, die am schwierigsten war, der letzte Teil des Puzzles, das wir sozusagen in unsere Hypothese gesteckt haben, ist, dass wir ein angemessenes Maß an Autonomie benötigen. Wir mussten ein viel besseres Verständnis dafür entwickeln, was es für Teams bedeutet, autonom zu sein, als wir es hatten, und wie diese Autonomie mit Kontrolle zusammenhängt und wie Kontrolle die Autonomie untergräbt und wie wir alle dazu neigen, die Hinweise in der Umgebung entweder als Anweisungen zu verstehen, die wir befolgen müssen, oder als Aufforderung zur Autonomie. Und jetzt haben wir ein weiteres psychometrisches Instrument. Das dritte Instrument, das wir verwenden, nennen wir die Motivationsorientierungsskala, entschuldigen Sie, mit der die Wahrscheinlichkeit gemessen werden kann, mit der eine Person eingehende Informationen als Anweisung oder Aufforderung zur Autonomie interpretiert.

John Turley:

Und wenn wir das erst einmal wissen, können wir anfangen, diese allgemeine Auffassung innerhalb von Produktteams, Softwareteams, in Frage zu stellen, dass das Team autonom ist, weil jeder denkt, dass es autonom ist. Und tatsächlich ist das jeder, wie Untersuchungen zeigen, größtenteils autonom, aber wir könnten fast vollständig autonom sein, oder wir könnten zu 60% autonom sein. Das können wir messen. Und dann können wir den Teams sagen: „Schau, ihr seid als Gruppe von Individuen autonom. Aber Sie haben auch diese Kontrollfunktion, wenn Sie auf eingehende Anfragen antworten.“

John Turley:

Und wir müssen autonomer sein. Sobald wir also damit beginnen können, es zu messen, können wir beginnen, ihre Vorstellungen davon, wie autonom sie sind, in Frage zu stellen. Und wir können damit beginnen, zu untersuchen, welche Reaktionen die Teams aufgrund ihrer Kontrollorientierung oder ihrer Autonomie wählen. Es sind also die drei Dinge: Autonomie und Kontrolle, Komplexität der Denkweise und Netzwerkstruktur, gleichberechtigtes Mitarbeiterengagement und Teamleistung. Das sagt unsere Forschung. Was wir also zu Ihrer Frage am Anfang sagen können, ist, dass es eine Netzwerkstruktur, ein gewisses Maß an psychologischer Komplexität und das Maß an Autonomie gibt, das mit der erfolgreichen Arbeit als funktionsübergreifendes Team einhergeht. Und in diesem Sinne könnten wir denken, dass diese Ebenen in gewissem Sinne richtig sind.

Sean Blake:

In Ordnung. Also, wie sieht ein zu 100% autonomes Team aus? Und haben sie immer noch täglich Interaktion mit, sagen wir, dem Führungsteam? Oder sind sie uneins, diese beiden Konzepte?

John Turley:

Nein, sie sind nicht uneins. Sie haben, sie haben vielleicht von Tag zu Tag, ich nehme an, sie werden entweder direkt oder indirekt Interaktionen mit dem Führungsteam haben. Das Erste, was wir hier berücksichtigen müssen, ist, dass es sich bei der Forschung, auf die wir uns stützen, um eine sogenannte Selbstbestimmungstheorie handelt, bei der es sich um eine Motivationstheorie handelt. Und sie hat eine ziemlich spezifische Definition von Autonomie, was wir normalerweise nicht denken würden. Oft wird unter Autonomie eine Art allgemeiner Gebrauch von Unabhängigkeit verstanden. Wenn wir also ein Unternehmen kaufen, lassen wir es vielleicht autonom laufen, was bedeuten würde, dass wir es einfach für eine Weile in Ruhe lassen würden. Und Autonomie bedeutet in diesem Zusammenhang nicht das. Es bedeutet, dass Individuen aus eigenem Willen handeln, Individuen entscheiden, wie sie sich für ein gemeinsames Ziel verhalten wollen. Das Team muss also eine Vision haben, nach der es sich selbst organisieren kann. Ohne Autonomie kann man sich nicht selbst organisieren. Wenn du keine Autonomie hast, musst du warten, bis dir gesagt wird, was zu tun ist. Und dann ist es keine Selbstorganisation.

John Turley:

Autonomie führt also zu Selbstorganisation, und Selbstorganisation kann auf einer gemeinsamen Vision oder einer Reihe von Zielen basieren, oder ein OKR ist eine ziemlich ausgeklügelte Methode, anstatt zielgerichtet zu managen. Dann können wir uns selbst so organisieren, dass die Notwendigkeit, Teil einer Organisation zu sein und koordinierte Arbeit zu erledigen, berücksichtigt wird, aber das hängt nicht davon ab, dass ein Manager dem Einzelnen sagt, was zu tun ist.

John Turley:

So sieht ein autonomes Team aus. Ein autonomes Team, man braucht die Autonomie ist in Wirklichkeit ein sich selbst organisierendes Team. Und das sich selbst organisierende Team entscheidet, was das Team tun soll, um ein umfassenderes Ziel zu erreichen, das die Integration mit anderen sich selbst organisierenden Teams sein könnte. Und natürlich wird die Richtung oft von der Exekutive vorgegeben. Also kommen all diese Dinge irgendwie ins Spiel. Es geht nicht um Kontrolle auf der einen Seite oder Autonomie auf der anderen Seite oder Agile auf der einen Seite oder Wasserfall auf der anderen Seite.

John Turley:

Also werden wir die beiden vermischen. Wir werden sie ausbalancieren. Und dieses Gleichgewicht muss sich nicht nur zwischen den Teams verschieben, sondern auch je nachdem, auf welcher Ebene sich die Organisation befindet, ob das Team in der Organisation arbeitet. Und was ich damit meine, ist, dass der Bedarf an Kontrolle und Messung in vielerlei Hinsicht zunimmt, je höher man in der Organisation aufsteigt. Wir wollen also ein hohes Maß an Autonomie auf Teamebene, wo wir Kundennutzen schaffen. Aber wir müssen erkennen, dass dieses sich selbst organisierende Team die legitime Anforderung hat, einige Elemente der Unternehmenssteuerung zu integrieren, denn wenn wir einige Kontrollelemente haben, können wir nicht die Buchhaltung übernehmen und dafür verantwortlich sein, wofür wir das Geld von Investoren oder Aktionären ausgeben, wissen Sie, was ich meine? Es ist also viel komplexer in der Art von dichotomisierter Welt, die die Leute eher betrachten und die sehr schwarz-weiß ist. Ist es agil oder ist es ein Wasserfall? Sind wir autonom oder sind wir steuerungsorientiert, wo Sie beide sind und welche Mischung sich je nach Umgebung hier ändern muss.

Sean Blake:

Okay, okay. Zusätzlich zur Autonomie ist also immer ein bisschen Kontrolle erforderlich.

John Turley:

Es ist ein Gleichgewicht, oder? Wir fühlen uns alle wohl mit Kontrolle, nicht wahr? Wir alle halten uns zum Beispiel an Geschwindigkeitsbegrenzungen. Wir sind damit vollkommen einverstanden. Kontrolle ist kein Schimpfwort. Manche tun Dinge, die uns manchmal gesagt werden, und wir tun es gerne. Manchmal tun wir es widerwillig. Wir machen das nicht gerne. Manchmal lehnen wir es ab. An der Kontrolle an sich ist nichts falsch. Es ist der übermäßige Gebrauch von Kontrolle, um Menschen dazu zu zwingen, Dinge zu tun, die sie nicht tun wollen. Dann wird es problematisch, weil es die Autonomie eines Individuums untergräbt, die ein grundlegendes, universelles psychologisches Bedürfnis ist. Wir alle brauchen ein ausreichendes Maß an Autonomie, um uns wohl zu fühlen.

Sean Blake:

In Ordnung. Okay. Wir wissen also, dass Agile einen guten Lauf hatte, es ist jetzt Jahrzehnte her. Stellen Sie also immer noch fest, dass Sie auf dieselben Einwände stoßen, wenn Sie mit diesen Führungsteams oder diesen Unternehmen, vielleicht aus traditionelleren Branchen, sprechen? Haben sie immer noch dieselben Einwände gegen Veränderungen wie in der Vergangenheit? Und wie versucht man, sie zu überwinden?

John Turley:

Ja, das tun sie. Eine meiner seltsamen Erfahrungen als junger Projekt- oder Programmmanager, was auch immer ich war, ist, dass, wenn ich in einem Raum voller agiler Softwareentwickler landete, wahrscheinlich in der Sprache, die sie zu der Zeit benutzt hätten, und einer Gruppe von Infrastrukturingenieuren, die dem Wasserfall folgten, und die Abneigung von einer Gruppe gegen die andere, das war fast instinktiv, und man konnte es in ihnen sehen. Ich weiß nicht, ein Haufen Linux-T-Shirts und -Jeans, und dann würden die Leute vom Infrastruktur-Wasserfall wahrscheinlich Anzüge tragen.

John Turley:

Ich meine, es war wirklich offensichtlich und es war schwierig, diese Gruppen zusammenzubringen. Das war meine Erfahrung, sagen wir, gegen 2000, als ich gestern mit einem Kunden zusammensaß, der genau das Gleiche sagte. Sie sagten, dass sie in ihrer Organisation, die derzeit eine sehr große, agile Transformation durchläuft, sagten: „Das sind ihre Methoden. Bei uns gibt es Leute mit zwei Extremen. Wir können es quasi unterschreiben. Wir haben die Waterfall-Leute, die denken, dass ihr Weg der beste ist, und wir haben die Agile-Leute, die mit der Agile-Transformation voll und ganz einverstanden sind.“

John Turley:

Und was ich gehört habe, als die Person das sagte, sind ziemlich hochrangige Führungskräfte. Die Agile-Mitarbeiter sind mit den Klammern der agilen Transformation einverstanden, weil sie denken, dass ihre Arbeitsweise die beste ist. Und was ich versucht habe, dem Senior Manager klarzumachen, war, dass das eine Gruppe war, es gab sowieso Wahrnehmungen, dass eine Gruppe Agile mochte und funktionsübergreifend arbeitete, all das wurde funktionsübergreifend und die andere Gruppe nicht, eigentlich arbeiteten die beiden Gruppen auf die gleiche Weise.

John Turley:

Beide dachten, ihre Arbeitsweise sei richtig, und der eine vertrat die Vorzüge des Wasserfalls und der andere Agile, aber Tatsache war, dass sie beide dachten, sie hätten Recht, und der andere war falsch. Und darin lagen sie beide falsch. Waterfall funktioniert in vielen Szenarien sehr, sehr gut. Und voll auf Agile funktioniert in einigen Umgebungen sehr, sehr gut. In einigen Umgebungen ist es meiner Meinung nach übrigens ziemlich eingeschränkt.

John Turley:

Mein Freund und Kollege John Kern, der 2001 oder 2004 Mitautor des Agilen Manifests war, was auch immer es war, ich kann mich nicht erinnern. Er sagt: „Ich liebe Wasserfälle. Ich mache viele Wasserfälle, ich mache es nur in sehr kleinen Stücken.“ Und weil Tatsache ist, dass wir die Arbeit auf irgendeine Weise sequentiell erledigen müssen. Ich kann nicht an unendlich vielen Dingen parallel arbeiten. Es muss eine Reihenfolge geben.

John Turley:

Und als ich ihn das sagen hörte, erfüllte es mein Herz in gewisser Weise mit Freude, denn für jemanden mit einem Wasserfall-Hintergrund sagte ich immer: „Schau, ich verstehe das nicht. Beim Wasserfall-Projektmanagement sprechen wir von Etappen. Und in Agile sprechen wir von Sprints.“ Und beide haben ein Ende. Man hat eine Definition von fertig. Und einer hat einige Akzeptanzkriterien, und beide haben einen Anfang. Der einzige Unterschied ist die Sprache und die Dauer.

John Turley:

Was ist, wenn wir Sprints machen, tut mir leid, Etappen, die 10 Tage lang sind? Was ist jetzt der Unterschied? Und doch würden die Leute sagen: „Nun, wir sind agil und wir machen Sprints, und das wäre immer noch eine Phase.“ Komm schon, wir müssen einige Gemeinsamkeiten finden, um eine gemeinsame Bedeutungsbildung zwischen großen Gruppen von Menschen aufzubauen. Andernfalls können nur die Agile-Zuhörer unter uns für agile Organisationen arbeiten, und alle anderen sind dem Untergang geweiht. Und das stimmt nicht, oder? Das ist Unsinn, oder? Also müssen wir zusammenkommen und diese Arbeitsweisen finden, wie mein Freund John Kern so eloquent betont.

Sean Blake:

Okay, das ist ein guter Rat. Also für diese, einige Leute, die du triffst, gibt es immer noch diesen Widerstand, den es schon seit vielen Jahren gibt. Wie geht man vor, um die Leute zu ermutigen, ihre Komfortzone zu verlassen, um diese funktionsübergreifende Arbeitsweise auszuprobieren und transparenter zu sein, ich schätze, indem sie zum Team beitragen und nicht unbedingt darauf drängen, nur ein einzelner Mitarbeiter zu sein?

John Turley:

Noch eine gute Frage, Sean. Es gibt also ein paar Möglichkeiten, wie wir das tun können. Das psychometrische Instrument, das ich bereits erwähnt habe, das irgendwie messen kann, ich setze das irgendwie immer in Anführungszeichen, weil es nichts wirklich misst, es bewertet, glaube ich, ist ein wirklich, wirklich mächtiges Instrument. Auf der Grundlage dieser Messung können die Psychologen, mit denen wir zusammenarbeiten, einen Bericht erstellen, der dem Einzelnen viele dieser bedeutungsvollen Dinge, die Entwicklungspsychologie für Erwachsene, erklärt. Und es neigt dazu, überwältigend zu sein. Es verändert wirklich die Perspektive der Menschen darüber, was sie sind und wie sie in der Welt agieren.

John Turley:

Sobald die Menschen anfangen zu verstehen, dass es diese Entwicklungsstadien gibt und wir alle sie möglicherweise bis in die letzten Tage unseres Lebens durchlaufen, können wir beginnen, die Meinungsverschiedenheiten zu erkennen. Sie fangen einfach an, wegzufallen. Meinungsverschiedenheiten fallen allmählich weg, weil sie nicht mehr als gegensätzliche Ansichten angesehen werden, die nicht miteinander in Einklang gebracht werden können, weil ich diese Art von Person bin und sie diese Art von Person sind.

John Turley:

Und sie werden allmählich als Inkompatibilitäten bei der Bedeutungsfindung angesehen. Also fangen die Leute an zu sagen: „Okay, nun, ich denke das und du denkst das. Wie verstehen wir beide das, was bedeutet, dass wir die Perspektive anderer sehen können?“ Und sofort haben Sie begonnen, einen Mechanismus zu finden, um Gemeinsamkeiten zu finden.

John Turley:

Der Profilbericht zur Führungskräfteentwicklung, also der Bericht, der aus dem psychometrischen Instrument stammt, wirft also wirklich viel Licht darauf, wie der Einzelne arbeitet und wie Entwicklung aussieht, wie die psychologische Entwicklung für ihn aussieht. Das ist also ein mächtiges Tool. Wir haben einen weiteren Service, den wir Dialogpartnerschaft nennen und den wir als Pilotprojekt testen. Das ist quasi ein acht- oder zehnwöchiges Programm, es ist eine gemeinsame Einzeluntersuchung darüber, wie eine Person ihre Bedeutung formuliert und was die Stärken ihrer Bedeutungsbildung und die Grenzen ihrer Bedeutungsbildung sind.

John Turley:

Und sobald die Leute anfangen, das zu erkennen, fühlen sie sich defensiv, weil die Art und Weise, wie sie programmieren, gerade kritisiert wurde, weil sie ihre Bedeutung daraus ziehen, der beste Programmierer der Welt zu sein. Aber es gibt einen Entwicklungspfad, der das hinter sich lässt, und genau da kommen viele, viele Menschen hin. Es ist wie ein Aha-Moment, die Leute erkennen einfach, dass die Realität anders ist, als sie dachten, und sie kann angepasst werden.

John Turley:

Das LDP, die Leadership Development Profile-Berichte, Dialogpartnerschaften und die Zusammenarbeit mit der Geschäftsleitung, um ein bewusst entwicklungsorientiertes Umfeld zu schaffen, das die Dinge tut, die ich zuvor erwähnt habe, sind die entscheidenden Instrumente, mit denen wir Einzelpersonen dabei helfen, ihre eigene psychologische Entwicklung voranzutreiben. Und die Frage ist natürlich, warum sollten sie dazu motiviert sein? Warum sollte es sie interessieren? Und sie kümmern sich darum, weil 80% der Menschen ein sehr niedriges Maß an Engagement bei ihrer Arbeit zeigen. Die meisten Menschen treten auf Wasser und schlagen die Zeit totschlagen. Es ist kein Ort, an dem man sich wohlfühlt. Sobald die Leute anfangen, in funktionsübergreifenden Teams zu arbeiten und gemeinsam mit ihren Kollegen Freude daran haben, Dinge zu schaffen, die sie nicht schaffen könnten, was ein grundlegender menschlicher Instinkt ist, das ist ein Hype, dann kommt man zur Arbeit und hat Spaß.

John Turley:

Das habe ich dir zu Beginn des Telefonats gesagt, oder? Ich amüsiere mich großartig, ich arbeite mit einigen brillanten Leuten zusammen, die neues Wissen erschließen, von dem wir glauben, dass es die Menschheit nicht hat. Das ist ein Summen. In meiner Rolle trete ich nicht ins Wasser, weißt du, was ich meine? Und das gilt nicht nur für mich. Meiner Ansicht nach könnte die ganze Welt so sein. Wir könnten alle in solchen Rollen arbeiten, vielleicht ist das ein bisschen weit. Aber sicherlich könnten davon derzeit noch viel mehr getan werden, um mit der psychologischen Entwicklung Schritt zu halten und mehr Spaß an Ihrer Rolle zu haben, Spaß an Ihrer Arbeit zu haben. Es gibt eine Menge Zeit.

Sean Blake:

Ja, ich stimme dem, was du über den Buzz gesagt hast, wirklich zu. Und ich habe gesehen, wie das passiert, wenn bei Menschen die Glühbirne angeht, und es ist nicht mehr so, dass diese Werksarbeit an Sie weitergegeben wird. Aber du merkst, dass du jetzt Teil eines Teams bist, jeder ist da, um dich zu unterstützen, du arbeitest auf ein gemeinsames Ziel hin. Und es ist transparent, Sie können sehen, woran andere Leute arbeiten, und Sie helfen sich gegenseitig, gemeinsam etwas aufzubauen. Es macht wirklich Spaß. Zum ersten Mal in der Karriere vieler Menschen macht es Spaß und Vergnügen, zur Arbeit zu kommen. Das muss dir also ein gutes Gefühl geben, wenn du tust, was du tust.

John Turley:

Ja, tut es. Deshalb stehe ich auf und darum versuche ich seit 20 Jahren, das zu lösen, anderen Menschen wirklich zu helfen, das zu lösen. Ich erhielt neulich einen Anruf von einem Kollegen, der sagte, sie würden etwas Sport treiben und über ihre neue Rolle nachdenken. Und sie dachten sich, so fühlt es sich an, mit Freude zu arbeiten.

John Turley:

Ich meine, dieser [unhörbare 00:42:51] Job ist erledigt, denn das ist eine sehr fähige Person. Sobald sie sich so fühlen, weißt du, dass sie großartige Dinge tun werden. Wenn sie das Gefühl haben, andere Menschen zu sein, dass die Leute Gerinnsel beobachten, oder es gibt diese Kultur der Beschäftigtheit, in der wir nicht zugeben können, dass wir Dinge nicht wissen. Und dann müssen wir in einer Besprechung sein und etwas tun, in der transparenten Welt, von der du gerade sprichst. Wenn ich etwas zu tun habe, kann ich mich einfach hinsetzen und sagen: „Ich gehe heute zur Arbeit, ich warte darauf, dass mehr Sachen geschrieben werden.“ Und das ist keine schlechte Sache. Es ist wie, großartig, du arbeitest in einem nachhaltigen Tempo. Das ist eine gute Sache. Ich habe jahrelang für eine Schweizer Bank gearbeitet und in einem nachhaltigen Tempo gearbeitet, aber niemand war daran interessiert. Man muss mit einem Tempo arbeiten, das nicht nachhaltig ist. Und wenn du ausgebrannt bist, kannst du gehen und wir lassen jemand anderen reinkommen und das machen. Und so funktioniert das. Das ist miserabel.

Sean Blake:

Es ist nicht das, was wir wollen, Sean, oder? Es ist nicht das, was wir wollen. Und leider waren viele Leute schon einmal dort und haben es erlebt. Und wenn sie das Licht einmal gesehen haben, wollen sie nie wieder zu ihm zurückkehren, was meiner Meinung nach eine gute Sache ist, wenn man erkennt, dass es einen besseren Weg gibt.

John Turley:

Ja, einverstanden.

Sean Blake:

Ja. Okay, nun, ich denke, wir werden bald fertig sein. Ich habe noch zwei Fragen an dich, bevor wir Schluss machen.

John Turley:

Ich werde versuchen, die Antworten kurz zu halten.

Sean Blake:

Nein, das ist in Ordnung. Ich genieße es wirklich. Ich könnte vielleicht noch eine Stunde gehen, aber ich weiß, dass wir andere Dinge zu tun haben. Im Rahmen der Recherche habe ich einige Ihrer Blogbeiträge gelesen und mir einige Ihrer Vorträge und Ereignisse in der Vergangenheit angesehen, und Sie sprechen über das Konzept der versteckten Verpflichtungen. Und ich möchte einfach ein bisschen mehr erfahren. Was ist eine versteckte Verpflichtung? Und was ist die Implikation?

John Turley:

Gute Frage. Also schrieben Robert Kegan und Lisa Lahey, Entwicklungspsychologen, ein Buch mit dem Titel Immunity to Change. Dies ist ein Buch, das ich vor ein paar Jahren hier gelesen habe. Und da drin sprechen Bob und Lisa über versteckte Verpflichtungen. Und so weisen sie zunächst darauf hin, dass wir alle Neujahrsvorsätze fassen und sie alle scheitern. Wir meinen sie wirklich ernst, wenn wir sie machen. Und als ich in meinen späten Teenagern war, meinte ich sie vielleicht wirklich ernst, als ich sie gemacht habe. Aber ich konnte sie niemals behalten.

John Turley:

In einem anderen Buch, betont Kegan, ist es meiner Meinung nach in dem Buch The Evolving Self enthalten. Er weist darauf hin, dass die große Mehrheit der Männer nach einem Herzinfarkt meiner Meinung nach eine Studie in Amerika ist. Aber es ist eine Weile her, seit ich sie gelesen habe, ich glaube, es sind sechs von sieben, die nach einem Herzinfarkt weder ihre Ernährung noch ihr Trainingsprogramm ändern. Und der Grund, warum er das als Fallstudie in dem Buch verwendet, ist, dass er darauf hinweist, dass es nicht so ist, dass diese Leute nicht wissen, was sie tun sollen, man braucht weniger Kalorien rein, mehr raus. Und es ist nicht so, dass sie nicht motiviert wären, das zu tun. Sie hatten eine Nahtoderfahrung. Sie würden gerne am Leben bleiben, nehmen wir an.

John Turley:

Dennoch nehmen sie keine nennenswerten Änderungen an ihrer Ernährung und ihrem Trainingsprogramm vor, warum nicht? Und was Bob und Lisa in dem Buch aus ihren Recherchen sagen, ist, dass es auf versteckte Verpflichtungen zurückzuführen ist. Wir alle haben unsere Art, Sinn zu machen. Wir haben unsere Werte und Annahmen, die wir wie durch Osmose von der Gesellschaft aufnehmen. Und wir stellen sie nicht in Frage. Wir können nicht alle Annahmen in Frage stellen, die wir im Laufe unseres Erwachsenwerdens annehmen. Es ist einfach nicht möglich. Wir haben also diese versteckten Annahmen, dass wir versteckten Verpflichtungen verpflichtet sind. Und manchmal stehen diese versteckten Verpflichtungen im Widerspruch zu unseren erklärten Zielen. Und wenn die versteckte Verpflichtung unserem erklärten Ziel widerspricht, ist das Ergebnis, dass wir sehr verwirrt darüber sind, dass das erklärte Ziel irgendwie auf der Strecke bleibt, und wir verstehen nicht wirklich, warum. Wir denken vielleicht, ich würde einen gemeinsamen Ausweg finden, weil ich mich einfach mehr anstrengen muss, ich brauche einfach mehr Willenskraft. Ich muss einfach den Kurs beibehalten. Und das stimmt nicht sehr oft. Es gibt noch etwas anderes in Ihrer Bedeutung, was das im Widerspruch zu unserem erklärten Ziel stehen lässt. Und sobald Sie es ans Licht gebracht haben, können Sie damit beginnen, diese versteckte Verpflichtung zu untersuchen, und Sie können damit herumspielen.

John Turley:

Und wenn du damit herumspielen kannst, passt du deine Bedeutungsbildung an. Und die Technik, die wir bei der Dialogpartnerschaft anwenden, stammt aus dem Buch von Bob und Lisa, in dem wir im Wesentlichen diese versteckten Verpflichtungen aufdecken und sehen, wie sie mit Engagement kollidieren. Das ist sozusagen, und wenn du es dann siehst und du damit experimentieren kannst, kannst du beginnen, Veränderungen in dir selbst freizusetzen. Peter Senge, ich glaube, er ist Innovationsdirektor. Er ist sehr berühmt, Innovationsdirektor am MIT. Und er hat ein wunderschönes kleines Zitat, etwa: „Was für eine Torheit ist es, daran zu denken, unsere Organisationen zu transformieren, ohne uns selbst zu verändern?“

John Turley:

Wir müssen unser Verhältnis zur Macht ändern, um die Art und Weise zu ändern, wie Macht in unseren Organisationen verteilt wird. Und das ist ein Beispiel für eine versteckte Verpflichtung, über die wir normalerweise nicht nachdenken. Wir glauben einfach, dass wir Menschen auf magische Weise stärken können, während wir die gesamte Macht für den Senior Manager behalten. Und das funktioniert einfach nicht. Es gibt eine versteckte Verpflichtung, die der Idee widerspricht, dass wir unsere Teams stärken wollen, was eine ziemlich fehlerhafte Idee ist.

Sean Blake:

Beeindruckend. Okay. Nun, ich mag die Herangehensweise an die Arbeit und die Betrachtung der sozialen Struktur, der sozialen Netzwerke und der Psychologie, die dahinter steckt, wirklich. Das ist wirklich faszinierend und ich bin noch nie wirklich darauf gestoßen, besonders nicht im agilen Bereich. Das ist also wirklich einzigartig. Danke, dass du das geteilt hast, John. Letzte Frage an dich. 2020 war gelinde gesagt interessant. Wir haben über einige Dinge gesprochen, die im Laufe Ihrer Karriere gleich geblieben sind, einige Dinge, die sich geändert haben. Was denkst du wird als Nächstes kommen, freust du dich auf die nächsten fünf, zehn Jahre? Was sind einige dieser Trends, von denen Sie glauben, dass sie wirklich auffallen und vielleicht die Art und Weise, wie Sie arbeiten, verändern werden, wie Ihre Mitarbeiter von neun bis fünf aussehen, oder die Art und Weise, wie Sie mit Ihren Kunden interagieren?

John Turley:

Ich denke, das wird nicht nur das Aussehen von Nine to Five verändern. Es wird sich ändern, so wie alle neun bis fünf aussehen. Ich denke, die Welt befindet sich in einer schwierigen Lage. Viele von uns sind verärgert und es sieht nach einem ziemlichen Chaos aus, und ich glaube, wir sind alle besorgt. Viele von uns sind besorgt. Aber wie ein Freund zu mir sagte, zitierte er jemand anderen, lass niemals eine gute Krise ungenutzt verstreichen. Die Menge an Veränderungen, viel Energie im System, die Menge an Veränderungen im System verändert die Dinge spürbar.

John Turley:

Viele von uns erkennen, dass es einen besseren Weg geben muss, Dinge zu tun, weil unsere Art, uns als Gesellschaft zu organisieren, einschließlich unserer Organisationen, zusammenbricht. Es funktioniert nicht mehr. Die Leute erkennen durch die Arbeit, dass Menschen die Namen mögen, die ich genannt habe, und durch unsere ursprünglichen Forschungen hoffe ich, dass sie irgendwie auf originelle Weise dazu beitragen werden, dass es eine bessere Art gibt, uns zu organisieren, dass die Menschheit das Wissen und die Erfahrung hat, das zu tun, was wir tun müssen.

John Turley:

Es ist einfach nicht in der IT. Wir müssen von außen auf das schauen, was die Psychologen über Mindset sagen, und nicht darauf, was die Agile-Leute über Mindset sagen. Das ist eine radikale Idee. Und wenn wir dieses Lernen und dieses Wissen importieren, haben wir einen Rahmen, der uns hilft, besser zu verstehen, was wirklich vor sich geht und wie wir echte Veränderungen bewirken können. Also alles, worüber ich heute gesprochen habe, ist nur sehr wenig originell. Wir haben einige Originalarbeiten, über die ich nicht wirklich sprechen kann. Spielt es eine Rolle? Das Wissen ist da draußen. Wenn wir die Menschen und die Kultur und die Tools und die Methodik zusammen erledigen, dann skaliert das, dann ändern wir die Art und Weise, wie Organisationen arbeiten, was sich ändern wird, dass jeder von neun vor fünf ist.

Sean Blake:

Das ist großartig. Das bringt es zurück zu den Grundlagen, nicht wahr? Was wir über Menschen wissen, und das wenden wir nun auf das an, was wir über Arbeit wissen. Das ist wirklich ein Augenöffner. Und ich habe viel aus unserem Gespräch gelernt, John. Ich habe ein paar Bücher und ein paar Forschungsarbeiten, die ich mir danach ansehen muss. Vielen Dank, dass Sie im Easy Agile-Podcast erschienen sind, und wir schätzen Ihre Zeit sehr.

John Turley:

Klar, es ist mir ein Vergnügen. Ich meine, ich liebe es und wir bei Adaptavist lieben es, mit anderen zu teilen, was wir tun. Damit wir alle mit mehr Freude arbeiten können, Mann. Also danke, dass du uns hilfst, die Botschaft zu verbreiten.

‍