Kommentierte Links (CIV)

Bild: Unsplash / Fabio Bracht - Lizenz

Das Internet ist voll von Menschen die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Johanna Rothman: How to Predict When the Team Will Complete a Specific Backlog Item (Part I, Part II, Part III)

Einmal mehr ein grosser Klassiker: ein wichtiger Stakeholder fragt, wann ein bestimmtes, sehr grosses oder im Backlog weit unten stehendes Feature fertig werden wird. Was antwortet man ihm? Johanna Rothman gibt eine sehr differenzierte und darum auch sehr lange Antwort darauf. Zum einen liefert sie Argumente für eine Erklärung, warum eine exakte Vorhersage nicht so einfach möglich ist, sie zeigt aber auch mögliche Gründe und Systemzwänge auf, die dafür sorgen, dass diese Frage immer wieder gestellt wird. Hervorzuheben ist, dass sie es sich nicht einfach macht und zum blossen "Nein sagen" aufruft (das häufig nur in Konflikte und Eskalationen führt) sondern Ideen nennt, wie man aus dieser Frage ein Gespräch auf Augenhöhe machen kann.

Enzo Avigo: The Rise of Engineering-Driven Development (EDD)

Ich gebe es zu, neue methodische und organisatorische Ansätze triggern mich. Sobald ich von einem neuen höre möchte ich ihn kennenlernen, verstehen und irgendwo selber ausprobieren. Das von Enzo Avigo vorgestellte Engineering Driven Development gehörte für mich in diese Kategorie. Mit (beabsichtigten oder versehentlichen) Parallelen zu Extreme Programming geht es in ihm darum, Verantwortlichkeiten in das Entwicklungsteam zu verlagern die in den meisten klassischen Organisationen bei einer Fachabteilung liegen und in vielen agilen Organisationen beim Product Owner oder Product Manager. Ein grundsätzlich gute (da in Richtung crossfunktionales Produktteam gehende) Idee, wenn auch mit dem Risiko hoher Cognitive Load.

Chris Combe: Organizing agile coaches

Hinter der scheinbar simplen Frage, wie man Agile Coaches organisiert (d.h. wie man sie in Aufbau- und Ablauforganisation einbindet) steht eine erstaunliche Menge von Aspekten: wie werden sie (intern oder extern) rekrutiert, wie ist ihr Karrierepfad, woher kommt das Budget für sie, bilden sie eine zentrale Einheit oder sind sie dezentral in den Produktteams verortet, haben sie einen gemeinsamen Auftrag (und wenn ja welchen?), ist der mit den Unternehmenszielen übereinstimmend, wie wird ihre Wirksamkeit gemessen (was spätestens bei den nächsten Gehaltsverhandlungen relevant wird), etc. etc. etc. Chris Combe hat nicht auf alle dieser Punkte eine Antwort, aber zumindest einige Erfahrungswerte. Und allein all diese Fragen zusammengetragen zu haben ist bereits hilfreich.

Jeff Gothelf: Who owns product discovery?

Eine weitere scheinbar einfache Frage, diesesmal eine die eher in Richtung Produktmanagement geht. Wer hat in einem agil arbeitenden Unternehmen eigentlich die Verantwortung für die Product Discovery, also dafür, die Wünsche der (potenziellen) Kunden herauszufinden und aus ihnen kommerzialisierbare Features und Services abzuleiten? Die Antwort, die Jeff Gothelf anbietet, ist zwar das übliche "kommt darauf an", allerdings verbunden mit dem richtigen Hinweis, dass es am Ende nicht zielführend sein kann, diese Tätigkeit durch einzelne Gruppen monopolisieren zu lassen. Zielführender wäre eine demokratisierung des Kundenzugangs, allerdings mit einem wichtigen Vorbehalt: allen die Product Discovery betreiben muss bewusst sein, was die übergreifende Firmenstrategie ist. Ohne dieses Bewusstsein droht Wildwuchs.

Boris Palmer: Lasst die Kommunen doch bitte machen

Boris Palmer ist (zurückhaltend gesagt) ein häufig kontrovers auftretender Politiker, bei dessen Debattenbeiträgen man nie sicher sein kann, ob sie groben Unfug oder wertvolle Impulse enthalten. Dieser hier gehört in die zweite Kategorie und ist auch auf Kontexte ausserhalb der staatlichen Verwaltung übertragbar. Die (vereinfachte) Kernaussage ist, dass es möglich sein sollte in begründeten Ausnahmefällen von Vorschriften abzuweichen, nämlich dann wenn diese zwar Aufwände erzeugen, ihren eigentlichen Zweck an einer speziellen Stelle aber nicht erfüllen. Eigentlich sollte man denken, dass das Common Sense ist, oft ist es das aber leider nicht.

Remote Working Approaches That Worked And Some That Didn’t

Wenn es zu Diskussionen über das Thema Remote Work kommt, bewegen sich die Diskussionen häufig in den Extremen. Viele Personen sehen seit dem Corona-Lockdown den Beweis erbracht, dass es problemlos möglich ist und nie wieder aufhören muss, andere weisen auf die zweifelslos vorhandenen Probleme hin und leiten daraus ab, dass das Konzept grundsätzlich problematisch ist. Charles Humble liefert mit diesem Vortrag dankenswerterweise eine deutlich differenzierte Betrachtung ab und setzt Vorteile, Nachteile und Rahmenbedingungen in Bezug zueinander.

Was man aus seinen Ausführungen unter anderem mitnehmen kann ist, dass sowohl Remote Work als auch Präsenzarbeit bestimmte Rahmenbedingungen brauchen wenn sie effektiv sein sollen, sei es in Form von Kommunikations- und Zusammenarbeits-Vereinbarungen, durch das Vorhandensein von Räumen in denen konzentrierte Arbeit möglich ist oder durch gutes Onboarding. Daran zu arbeiten dürfte in fast allen Fällen zielführender sein als die Grundsatzdebatten darüber welcher Arbeitsmodus im Prinzip besser ist.

The Agile Bookshelf: Actionable Gamification

Gamification gehört zu den Techniken, denen man im Umfeld agiler Teams immer wieder begegnet. Ob in der Wissensvermittlung, für Aufwandsschätzungen oder in Retrospektiven, an vielen Stellen werden spielerische Elemente eingesetzt. In den meisten Fällen sind diese Elemente von irgendwo übernommen worden ohne sie gross zu hinterfragen - warum auch, schliesslich funktionieren sie ja. Das heisst aber natürlich nicht, dass es keine dahinterliegenden Theorien gibt - sie sind nur eher unbekannt.

Ein Buch mit dem man sich den zugrundeliegenden Mechanismen nähern kann ist Actionable Gamification - beyond Points, Badges, and Leaderboards von Yu-Kai Chou. Er hat nicht nur über zwei Jahrzehnte das Thema Gamification erforscht, sondern auch ein darauf basierendes Modell entwickelt (das Octalys-Framework), das es möglich macht Ursachen, Zusammenhänge und Erfolgsfaktoren für eigene Erfindungen und Anwendungen von Gamification zu erkennen.

Actionable Gamification beginnt mit einer Definition dessen was Gamification ist: die Integration von Spass machenden, unterhaltenden und Engagement fördernden Elementen in Arbeits- und Freizeit-Aktivitäten. Da sie die Interaktion des Menschen mit seiner Tätigkeit in den Mittelpunkt stellt, und nicht nur deren Zweck, ist sie eher primär Human-zentriert als primär Funktions-zentriert (selbst wenn es in den meisten Fällen eine zugrundeliegende Funktion gibt).

Aufbauend auf dieser Grunderkenntnis ist das Octalys-Framework um acht verschiedene Motivatoren aufgebaut, durch deren Addressierung bewirkt werden kann, dass sich die Empfindung von Spass und unterhalten Sein und der Wunsch nach Engagement einstellen. Hinter ihnen stehen nochmals weiterführende Erkenntnisse und Überlegungen (z.B. die Aktivierung bestimmter Gehirnregionen und Emotionen), die im Buch weiter erläutert werden. Die Motivatoren sind die Folgenden:

Epic Meaning & Calling

Übersetzbar als das Gefühl an etwas Grossem zu arbeiten oder zu Grossem berufen zu sein. Was dieser übergreifende Zweck ist kann je nach Kontext (Benutzungs-Erfahrung, Change Management, Produkt-Entwicklung, etc.) unterschiedlich sein, gmeinsam ist das Framing als grosse (Gemeinschafts-)Aufgabe.

Development & Accomplishment

Hier geht es um die Wahrnehmung Fortschritte zu erzielen und ggf. Hindernisse zu überwinden, wodurch (bestenfalls kontinuierliche) Erfolgserlebnisse erzeugt werden. Wird häufig durch "Challenges" oder Wettbewerbe erzeugt.

Empowerment of Creativity & Feedback

Eine Verknüpfung von zwei Faktoren. Zum einen wird der eigenen Phantasie Freiraum gegeben, zum Anderen erfolgt dafür eine Belohnung indem die so erzeugten Ergebnisse gelobt oder weiterverwendet werden. Ein klassischer Anwendungsfall ist Design Thinking.

Ownership & Possession

In diesem Zusammenhang vermutlich am besten zu übersetzen mit Kontrolle und Aneignung. Es wird das Gefühl erzeugt, über etwas (was auch immer) frei entscheiden zu können und Ergebnisse (Auszeichnungen, Rekorde, o.ä.) werden mit der eigenen Person verbunden.

Social Influence & Relatedness

Diese beiden Konzepte drehen sich um Beziehungen. Zum einen um die zu anderen Menschen, mit denen man gemeinsam an einer Aufgabe arbeiten kann, zum anderen zu Objekten oder Handlungen mit denen man gute Erinnerungen verbindet. Ein Beispiel wäre eine Gruppenarbeit in Lego Serious Play.

Scarcity & Impatience

Auch eher negative Motivatoren gehören zur Gamification. Kanappheit erzeugt den Wunsch, etwas (ggf. als einziger) zu besitzen, langwierige Erwerb-Prozesse den ungeduldigen Wunsch, es endlich zu haben (und den Prozess zu beschleunigen). Sehr kraftvolle Effekte, aber mit Vorsicht einzusetzen.

Unpredictability & Curiosity

Hinter diesem Motivatoren-Paar steckt ein banaler, aber selten berücksichtigter Zusammenhang: wenn man Neugier erzeugen will, braucht man auch (als solche wahrgenommene) Ungewissheit, nur dann ist die Zukunft so offen, dass man auf neue Entwicklungen wirklich neugierig sein kann.

Loss & Avoidance

Noch einmal eher negative Motivatore. Auch die Sorge (im Rahmen von Gamification errungene) Dinge zu verlieren und der Wunsch anstrengende oder enttäuschende Situationen zu vermeiden können starke, aber mit Vorsicht einzusetzende Faktoren sein.

***

Wer Gamification-Ansätze für die eigene Arbeit entwickeln will (eine Idee die vielen Scrum Mastern, Agile Coaches und Trainern früher oder später kommt) kann mit sich Actionable Gamification, bzw. dem in ihm enthaltenen Octalysis-Framework eine Checkliste erstellen, anhand derer überprüfbar ist, wie viele Motivatoren im eigenen Ansatz adressiert werden. Das müssen natürlich nicht alle sein, aber je mehr desto besser.

Definition of Done (III)

 

Bild: Pixabay / The Real Cicero - Lizenz

Zu den am weitesten verbreiteten Missverständnissen über Scrum gehört vermutlich, dass es nur für einzelne Teams ausgerichtet wäre. Tatsächlich ist das aber falsch, der Scrum Guide ist da sehr klar: es können sich z.B. mehrere Teams einen Product Owner und ein Product Backlog teilen, ausserdem (und darum soll es hier gehen) es kann sein, dass es eine unternehmensweite Definition of Done gibt, die für alle Teams verbindlich ist.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

Scrum Guide, 2020

Aus einer Scrum-puristischen Sicht erscheint diese Regelung zunächst wie eine Zumutung, schliesslich wird durch sie massiv in die Selbstorganisation des Teams eingegriffen. Dass diese Regelung trotzdem 2013 in den Scrum Guide aufgenommen wurde und in den seitdem stattgefundenen Aktualisierungen auch beibehalten wurde, muss also gewichtige Gründe haben. Sich diese bewusst zu machen kann für Verständnis sorgen und die Akzeptanz dieser Regelung erhöhen.

Ein erster gewichtiger Grund, der vor dem Hintergrund zu sehen ist, dass Scrum bis heute vor allem in der Software-Entwicklung eingesetzt wird, ist, dass eine gemeinsame Definition of Done gemeinsame Entwicklungsstandards möglich macht. Die können aus Coding-Standards, Schnittstellen-Definitionen, Testabdeckungs-Vorgaben oder ähnlichen Regeln bestehen und dafür sorgen, dass keine Team-basierte Code-Ownership entsteht und der Code auch teamübergreifend verständlich und weiterentwickelbar ist.

Ein zweiter Grund kann sein, durch eine gemeinsame Definition of Done übergreifende Release-Prozesse zu vereinfachen. Wenn z.B. grössere Mengen an Features erst ab einem bestimmten Zeitpunkt verfügbar sein sollen (etwa dem Weihnachtsgeschäft), kann es unnötig verkomplizierend wirken, wenn diese zum Teil bereits auf Produktion verfügbar aber ausgetoggled sind und zum Teil noch in einer Staging-Umgebung warten. Das zu vereinheitlichen erleichtert Qualitätssicherung und Go Live.

Ein dritter Grund kann der sein, dass ein einheitliches Auftreten gegenüber dem Kunden sichergestellt wird. Wenn z.B. "Done" so definiert wird, dass neue Features für den Anwender benutzbar sein müssen, dann kann es sinnvoll sein, übergreifend festzulegen in welchem Ausmass auch die Aktualisierung von FAQs und Benutzer-Handbüchern dazugehört. Findet das nicht statt werden die Anwender möglicherweise unterschiedliche Beschreibungstiefen vorfinden und Frustrationserlebnisse haben.

Im Zweifel sind noch weitere Gründe vorstellbar, dass eine übergreifende Definition of Done Sinn machen kann dürfte aber klar geworden sein. Dort wo man sie einführen will sollte man sich allerdings eines Risikos bewusst sein: wenn sie alles enthält was für alle betroffenen Teams relevant ist, kann sie gross und unübersichtlich werden und ggf. dadurch noch weiter aufgebläht werden, dass in ihr beschrieben werden muss, welche ihrer Teile nur für bestimmte Teams gelten und welche nicht.

Um das zu verhindern empfiehlt es sich, den Abschnitt aus dem Scrum Guide nochmals durchzulesen. Ihm zufolge bildet die übergreifende Definition of Done nur einen Minimalteil, den die Teams individuell erweitern können. Sich auf die nur unbedingt nötigen Mindeststandards zu beschränken und alles andere den Teams zu überlassen kann daher dabei helfen, aufgeblähte Umfänge und in Einzelfällen nicht mehr überall relevante Vorgaben zu vermeiden.

Zuletzt sollte immer in Erinnerung bleiben, dass die Definition of Done eine Hilfe für die Teams bei der Erstellung ihrer Incremente ist, und nicht ein Kontroll- oder Managing-Instrument. Es macht sehr viel Sinn regelmässig nachzufragen ob das was in ihr steht von den Teams als hilfreich oder behindernd wahrgenommen wird. Und wenn letzteres der Fall ist sollte es immer möglich sein Anpassungen vorzunehmen, um erneut zu einer allgemein akzeptierten Form zu kommen.

Eine (neue) Typologie der Veränderungs-Akzeptanz

Bild: Unsplash / Brooke Cagle - Lizenz

Ein Hoch auf die Wissenschaft! In der Zeit bin ich auf "More in Common"-Sozialstudie gestossen, in der es zwar eigentlich um gesamtgesellschaftliche Zusammenhänge geht, die aber (für mich) aus einem ganz anderen Grund interessant ist: in ihrem Mittelpunkt steht ein Modell, mit dem versucht wird, anhand des Umgangs mit Veränderungen soziale Gruppierungen zu identifizieren. Und dieses Modell ist erstaunlich gut auf Change Management in Unternehmen übertragbar.

Was diese Studie von anderen unterscheidet ist genau diese Art der Gruppenzuordnung. Statt bestehende Gruppen zu nehmen und in ihnen Erhebungen durchzuführen (was in der Realität aufgrund der gruppeninternen Heterogenitäten oft zu kaum brauchbaren Ergebnissen führt) ist das in diesem Ansatz entscheidende Zuordnungskriterium die Frage, wie Veränderungen wahrgenommen werden und wie auf sie reagiert wird (um das festzustellen gibt es standardisierte Fragenkataloge).

Im More in Common-Ansatz kommen auf diese Weise sechs verschiedene Gruppen zu Stande, die sich folgendermassen anordnen lassen:

Die Involvierten

Die Involvierten sind im Grunde genommen die Personen, die man sich bei Veränderungsvorhaben wünscht. Sie haben Ressourcen-Zugriff oder sind vernetzt und engagiert (und dadurch einflussreich) und sie sind bereit sich in den Dienst der neuen Ideen zu stellen, wenn sie einen Sinn darin sehen. Wichtig ist, dass ihr Einfluss nicht zwingenderweise mit ihrer öffentlichen Wahrnehmbarkeit korreliert.

Die Etablierten

Das Gegenstück zu den Involvierten. Sie sind ebenfalls vernetzt, engagiert und einflussreich, und auch bei ihnen kann der Einfluss größer sein als die öffentliche Wahrnehmbarkeit. Sie haben es sich in den bestehenden Verhältnissen aber so gut eingerichtet, dass sie diese nach Möglichkeit beibehalten wollen (was übrigens eine durchaus legitime Haltung sein kann).

Die Offenen

Die Offenen bilden die eine der stark wahrnehmbaren Extrempositionen im sozialen Diskurs und befürworten Veränderungen stärker als alle anderen. Beeinflussen können sie diese aber nur eingeschränkt, was weniger paradox ist als es zunächst klingt. Durch ihre lautstarke Kommunikation sollen ihre Anliegen bei den Entscheidungsträgern addressiert werden, um dort umgesetzt zu werden.

Die Wütenden

Erneut das Gegenstück. Auch die Wütenden können nur eingeschränkt selbst die Dinge beeinflussen und äussern ihre Meinung daher lautstark in Richtung der Entscheidungsträger. Der Tenor ist allerdings ein anderer, nämlich der, dass Veränderungen eher als Belästigungen wahrgenommen werden, von denen man gerne verschont bleiben würde.

Die Pragmatischen

Die Pragmatischen können (und wollen) Veränderungen nicht beeinflussen und hätten oft auch gar nicht die nötigen Ressourcen und Einblicke um das zu tun, sie sind aber in der Lage (und gewillt) sich mit den meisten Neuerungen irgendwie zu arrangieren oder sogar einen kleinen Vorteil daraus zu ziehen. Sie sehen alles so wie sie heissen: pragmatisch.

Die Enttäuschten

Das letzte Gegenstück. Genau wie den Pragmatischen fehlen den Enttäuschten die Mittel, der Wille und das Systemverständnis, die für das Beeinflussen von Veränderungen nötig wären. Sich mit den Neuerungen arrangieren können oder wollen sie aber auch nicht, weshalb sie diese einfach irgendwie und passiv über sich ergehen lassen.

Wie immer bei derartigen Typologien ist es auch bei dieser so, dass sie Verständlichkeit auf Kosten von Differenziertheit erzeugt, wer bereits an grösseren Veränderungsvorhaben beteiligt war wird die sechs Typen aber direkt wiedererkennen. Change-Strategien und -Massnahmen gezielt auf sie auszurichten dürfte möglich sein und Erfolgspotential haben, alleine deshalb weil dadurch das häufige Antipattern aufgebrochen wird, alle Gruppen gleich behandeln zu wollen.

Wichtig dabei ist aber, dass die Zuordnung zu diesen Gruppen nicht auf Intuition oder "Expertenmeinung" beruht sondern auf rationalen und überprüfbaren Kriterien. Auf der More in Common-Website findet sich einiges zur Methodik, zu den Tools und zu ihrer möglichen Anwendung, hier kann man sich inspirieren lassen und bekommt einen guten Werkzeugkasten für eigene Anwendungen mitgegeben. 

Der Vorteil von SAFe (III)

Bild: Unsplash / wocintechchat - Lizenz

Mit wenig kann man sich in der agilen Community so einfach Applaus und Zustimmung abholen wie mit SAFe-Bashing. Die mit diesem Framework verbundenen Risiken und Probleme sind auch fraglos vorhanden, so dass die Ursache dieser Ablehnung häufig nachvollziehbar ist. Was dabei aber zu leicht untergehen kann: SAFe macht auch einige Sachen richtig, und das vor allem in einer Richtung: in der, in der sich das Management befindet.

Ein bisschen Kontext: die meisten klassischen agilen Frameworks (vor allem Scrum, XP und teambasiertes Kanban) konzentrieren sich mit ihren Rollen, Regeln, Meetings und Artefakten auf die Umsetzungs- und Team-Ebene. Die darüber liegenden Management-Schichten werden weitgehend ignoriert, und wenn sie thematisiert werden, dann überwiegend in dem Zusammenhang, dass sie bitte die Team-Autonomie oder die Ownership des Product Owners zu respektieren haben.

Im Rahmen von Transitions-Vorhaben führt das oft zu nicht zielführendem Umgehen mit vor allem mittleren Managern. Teilweise werden sie (ohne bösen Willen) ignoriert oder vergessen, teilweise werden sie bewusst ausgegrenzt, schlimmstenfalls wird ihnen konfrontativ der Verlust von Einfluss, Status, Budget oder Karriere in Aussicht gestellt. Dass das einen Widerstand gegen die anstehenden Veränderungen zur Folge hat, ist wenig überraschend.

Und auch wenn das Management sich bewusst darauf einlässt, den ab jetzt selbstorganisierten Teams möglichst viele Entscheidungen zu überlassen, kann das in Probleme führen: ob aufgrund fehlender Erfahrungen oder wegen nicht klar definierter Zuständigkeitsgrenzen, immer wieder wird es zu Situationen kommen, in denen doch wieder das Management um Entscheidungen gebeten werden wird - was schlimmstenfalls den Eindruck erwecken kann, "dass Selbstorganisation nicht funktioniert".

Der Weg den SAFe gefunden hat um mit diesen Risiken umzugehen ist der, dass direkt zu Beginn einer Transition (in Phase zwei der "Implementation Roadmap") explizit auch die "Executives, Managers and Leaders" trainiert werden müssen. Ganz bewusst soll diesen dabei sowohl vermittelt werden, dass an vielen Stellen ein Loslassen stattfinden muss, als auch, dass das nicht bedeutet, nicht mehr verantwortlich zu sein und sich aus den Veränderungen herausnehmen zu können.

Bei der Frage wie das zu geschenen hat bleibt zwar ausgerechnet das sonst oft sehr deskriptive SAFe erstaunlich wolkig. Auf der entsprechenden Website wird vor allem vermerkt, dass es keine Ausnahmen geben soll und dass die Vermittlung der Haltungen "Thinking Lean" und "Embracing Agility" im Mittelpunkt stehen sollen. Fairerweise muss man aber auch sagen, dass detailliertere Anleitungen den meisten Einzelfällen nicht gerecht werden würden.

Dass jemand, der eine (berechtigte oder unberechtigte) Abneigung gegen SAFe hat, auch die "SAFe Implementation Roadmap" nicht mögen wird, dürfte wenig überraschend sein - und man muss sie ja auch nicht benutzen. Alternativ sollte man dann aber eine andere Art finden, das Management von Beginn an einzubinden. Denn zur Zeit ist es ein Alleinstellungsmerkmal von SAFe, diese Einbindung verbindlich formalisiert zu haben.¹

¹Um einem von Vertretern von LeSS und der Kanban University manchmal vorgebrachten Gegenargument zuvorzukommen: das Management lediglich aufzufordern, bestimmte Bücher zu lesen und zu tun was in ihnen steht, ist keine Einbindung und verkennt wesentliche Realitäten des überfrachteten Manager-Alltags

Technische Schulden dem Management erklären

Wer dieses Video anklickt und sieht, dass es ganze zwei Stunden lang ist, braucht nicht zu sehr erschrecken. Der eigentliche Vortrag von Carola Lilienthal ist nach ca. einer Stunde vorbei, was danach kommt sind Fragen und Diskussion. Selbst die kann man sich aber gut anhören, wenn man sich dafür interessiert, wie sich die Idee (und die Konsequenzen) der technischen Schulden dem Management erklären lassen.

Was ich gut finde ist, dass gegen Ende explizit darauf eingegangen wird, dass die Erklärung für Manager nicht nur verständlich sondern auch relevant sein soll, was u.a. auch bedeutet, dass man versuchen muss, technische Schulden finanziell quantifizierbar zu machen. Das ist natürlich nicht einfach, im Sinn der Zielgruppenorientierung aber unverzichtbar. Und es gibt auch Ratschläge wie das gemacht werden kann.

Agile Coach (IV)

Bild: Pexels / Ketut Subiyanto - Lizenz

Obwohl das was wir heute als agile Software- oder Produktentwicklung kennen nach und nach entstanden ist, gab es einige im Rückblick entscheidende Momente. Den etwa, in dem sich zwei Wissenschaftler bei einer Fabrikbesichtigung an ihren Lieblingssport erinnert fühlten, den, in dem einige Software-Entwickler realisierten, dass sie um effektiver zu werden nichts Neues machen mussten, sondern nur Bestehendes häufiger wiederholen, und auch einen weiteren, dessen Anbahnung folgendermassen beschrieben wurde:

I had been working as an agile coach for a few years when a colleague said to me, “You know, there’s a whole world of professional coaching out there. Maybe you should check it out.” This was his diplomatic way of saying, “You call yourself a coach, but you’re really not one.” He was right.

Lyssa Adkins, Coaching Agile Teams, S.121

Die Passage stammt aus einem der klassischen und noch immer wärmstens zu empfehlenden "agilen Standardwerke", Coaching Agile Teams von Lyssa Adkins, und handelt von ihr selbst. Zum hier beschriebenen Zeitpunkt hatte sie bereits seit einiger Zeit agil arbeitende Teams begleitet und war auf der Suche nach einem Begriff, mit dem sich ihr Beruf beschreiben liess, irgendwie bei dem Wort Coach gelandet, das sie als Agile Coach für sich übernahm und durch ihr Buch bekannt machte.

Was sie zu Beginn nicht wusste, und was ihr der in ihrem Buch zitierte namenlose Kollege dezent sagen wollte, war, dass ihr damit ein Irrtum unterlaufen war. Sie hatte zwar einige Aspekte des Coach-Berufs richtig erkannt und zutreffenderweise in ihrem Alltag wiedergefunden, hatte aber damit den Fehlschluss verbunden, dass es sich bei allen von ihr ausgeübten Tätigkeiten um Aspekte des Coachings handeln würde. Tatsächlich hatte einiges davon aber einen ganz anderen Hintergrund.

Ein kurzer Exkurs. Um zu definieren was ein Coach ist (und was er nicht ist) wird er von ähnlichen, bei näherer Betrachtung aber unterschiedlichen Berufen abgegrenzt. Üblicherweise (wie z.B. hier bei der International Coaching Federation) sind das die Berufe des Therapeuten, Beraters, Mentors, Lehrers/Ausbilders und Sport-Trainers.¹ Sie alle haben die Unterstützung anderer Menschen zum Ziel, unterscheiden sich vom Coach aber in einem Punkt: sie haben eine eigene Agenda.

Egal ob es sich um Gesundheit, Prozess-Optimierung, Erfahrungsweitergabe, Wissensvermittlung oder körperliche Fitness handelt - allen ist gemeinsam, dass der Therapeut, Berater, Mentor, Lehrer oder Trainer ein Vorwissen hat, das er für richtig hält und weitergibt. Coaching ist grundsätzlich anders: der Coach richtet sich nach den Wünschen und Bedürfnissen des Coachees,² hift ihm diese umzusetzen und stellt die eigene Meinung in den Hintergrund.

Ende des Exkurses, zurück zu Lyssa Adkins und ihrem Kollegen. Was diesem aufgefallen war ist, dass Adkins in ihrer Beschreibung des Agile Coaches auch Aspekte einschloss, in denen die eigene Agenda explizit nicht im Hinter- sonder im Vordergrund stand, u.a. Mentoring, Beratung, Ausbildung und (Konflikt-)Moderation. Und damit kommen wir zu dem für die agile Software- und Produktentwicklung entscheidenden Moment: sie stimmte ihm zu, behielt den Begriff des Agile Coach aber bei.

A serious point of ethics for professional coaches holds that the coachee’s agenda must be the single guiding light of the coaching relationship. The coach exists solely for the coachee, not so for us. We can’t let the coachee’s agenda rule completely because we must also mix in our agenda: to influence the coachee to use agile well. Again, it’s no big deal; just know that we are coach-like.

Lyssa Adkins, Coaching Agile Teams, S.123

Was sie hier so beiläufig umschreibt liesse sich überspitzt und mit anderen Worten auch so formulieren: "Für unsere Version des Coach-Berufs entfernen wir einen Kernbestandteil dessen was ihn eigentlich ausmacht und ersetzen ihn durch sein Gegenteil. Macht aber nichts, wir machen das ja aus einem guten Grund. Wir sollten uns nur bewusst sein, dass wir keine Coaches im eigentlichen Sinn sind, sondern lediglich Coach-ähnlich." Oder noch drastischer: "Der Agile Coach ist eigentlich gar kein Coach."

Wie oben erwähnt, Coaching Agile Teams ist direkt mit seinem Erscheinen 2010 zu einem Standardwerk geworden und hat den Begriff des Agile Coaches schlagartig bekanntgemacht und popularisiert. Hätte Adkins einen anderen benutzt (in ihrem Buch spricht sie z.B. auch vom Conductor oder Facilitator) würden wir heute möglicherweise vom Agile Conductor oder Agile Facilitator sprechen. Alleine, es war wie es war, und jetzt haben wir einen Beruf der sich Coach nennt, aber eigentlich keiner ist.

Von entscheidender Bedeutung ist das deshalb, weil wir jetzt damit leben müssen, dass das Wort Coach innerhalb der "agilen Bewegung" eine andere Bedeutung hat als ausserhalb. Alleine das wäre für sich genommen schon eine Kommunikations-Herausforderung, aber an einer zentralen Stelle wird die sogar noch einmal verschärft. Viele Manager lassen sich heute selbst coachen, wissen also was damit eigentlich gemeint ist. Für sie ist der Schluss von Lyssa Adkins Kollege naheliegend: da behauptet jemand, dass er Coach ist, hat aber offensichtlich nicht verstanden was das bedeutet.

Natürlich lässt sich das aufklären, indem man die Begriffsentstehung erläutert und klar macht, dass einem Agile Coach (hoffentlich) bewusst ist, dass er zwar Coaching-Techniken anwendet, sich aber von einem eigentlichen Coach in Zielsetzung und Vorgehen bewusst unterscheidet. Und natürlich sind derartige semantische Feinheiten vielen Menschen einfach egal. Unter dem Strich bleibt aber, das wir mit dem Agile Coach einen missverständlichen Begriff zentral platziert haben und ständig erklären müssen.

Zum Ende eine Klarstellung: sowohl über Lyssa Adkins als auch über ihr Buch kann man nur Gutes sagen. Es ist und bleibt ein Klassiker und ein Meilenstein. Sie hat aber mittlerweile selbst gesagt, dass sie den Begriff des Agile Coach in ihm nicht verwendet hätte, wenn sie geahnt hätte, welche Karriere er machen würde. Aber das ist mittlerweile nicht mehr zu ändern, der Name und der Beruf haben sich etabliert und werden uns vermutlich noch lange begleiten.

¹Das Wort Trainer bedeutet im Englischen dann nochmal etwas anderes als im Deutschen, aber das nur nebenbei
²Coachee: eine Person, deren Selbsterkenntnisprozess von einem Coach unterstützt wird

Eliten-Überproduktion

Bild: Unsplash / Robert Bye - Lizenz

Um frische Impulse für das eigene Weltbild zu bekommen lohnt sich immer wieder ein Blick über den Tellerrand hinaus. Dort warten die gleichermassen interessanten wie kontroversen Ideen, unter anderem auch die von Peter Turchin, einem amerikanischen Biologen und Historiker, der in seinem neuesten Buch End Times - Elites, Counter-Elites, and the Path of Political Disintegration die These aufstellt, dass viele gesellschaftliche Konflikte auf eine zentrale Ursache zurückzuführen sind: die Überproduktion von Eliten bei einer gleichbleibenden oder schrumpfenden Menge von Ressourcen und Machtpositionen.¹

Wie bei einigen anderen Theorien der Geisteswissenschaften bin ich auch bei dieser versucht sie auf meinen eigenen Kontext, also die sich verändernde Arbeitswelt rund um die agile Produktentwicklung, anzuwenden. Ist es möglicherweise auch hier so, dass vieles von den Konflikten, die wir in diesem Umfeld erleben, mit einer Eliten-Überproduktion erklärbar ist? Es gibt zumindest einige Indikatoren, die diese Deutung wahrscheinlich machen.

Zu Beginn eine kurze Begriffsklärung: unter einer Elite versteht man in der Soziologie eine relativ kleine Teilgruppe der Gesellschaft, die im Vergleich zu den anderen Teilgruppen überdurchschnittlichen Zugang zu Informationen, Mitteln oder Führungspositionen hat. Ein gesellschaftlicher Aufstieg in die Eliten ist grundsätzlich jedem möglich, es gibt aber Faktoren die ihn begünstigen, z.B. bestimmte Bildungs-Abschlüsse, geerbte und geschenkte Vermögen oder Unterstützungs-Netzwerke.²

Aus diesen Faktoren ergibt sich auch die erste Ursache einer Eliten-Überproduktion: bewusst oder unbewusst versuchen die bereits dort angekommenen Personen ihren Nachkommen oder den Angehörigen ihrer sozialen Gruppen und Milieus den Aufstig in die Elite zu erleichtern, sei es durch Vermittlung von Bildung oder durch finanzielle und berufliche Förderung. Findet das über einen längeren Zeitraum statt, übersteigt die Zahl der potentiellen Nachrücker irgendwann die der Eliten-Positionen.³

Die zweite Ursache ist eine Folge äusserer Einflüsse. Wenn es zu gesellschaftlichen, technischen oder wirtschaftlichen Umwälzungen kommt, führt das oft zu einem plötzlichen Zuwachs von Informationen, Mitteln oder Führungspositionen bei Gruppen die bisher nicht zu einer Elite gehörten. Anders als bei der ersten Ursache der Eliten-Überproduktion erfolgt der Zuwachs in diesem Fall nicht langsam und kontinuierlich sondern Schubweise.⁴

Beide Ursachen lassen sich in der aktuellen Arbeitswelt wiederfinden. Zum einen kommen die Kinder und Enkel der Gründer und Aufsteiger der 20. Jahrhunderts auf dem Arbeitsmarkt an und sollen dort eine Karriere haben, die mit der ihrer Eltern vergleichbar ist, zum anderen führen neue Bewegungen der Arbeitswelt zum Entstehen neuer Elitengruppen. Im Bereich der agilen Produktentwicklung ist vor allem das zweite der Fall, was seinen Grund in einer verbreiteten Wahrnehmungs-Diskrepanz hat.

Für viele eher klassisch beruflich sozialisierte Menschen erscheinen die "agilen Rollen" des Product Owners und des Scrum Master/Agile Coach aufgrund ihrer fehlenden direkten Weisungsbefugnisse wenig Eliten-geeignet und werden nicht angestrebt. Gleichzeitig lernen die Inhaber dieser Rollen, dass diese eigentlich so konzipiert sind, dass sie auch ohne Weisungsbefugnis fachliche oder methodische Führung ausüben können, sich also durchaus als Eliten verstehen lassen.

Die in vielen Unternehmen ständig ausgetragenen Machtkämpfe zwischen den neuen agilen Rollen und dem seit langem im eigenen Milieu nachrekrutierten traditionellen (Mittel-)Management lassen sich also im Sinn von Peter Turchin so interpretieren, dass sie die Folge einer (versehentlichen) Überproduktion von Eliten bei einer gleichbleibenden oder schrumpfenden Menge von Ressourcen und Machtpositionen sind und nicht aufhören werden solange diese Überproduktion weitergeht.

Wie so oft bei komplexen Problemlagen ist die Theorie der Eliten-Überproduktion zwar durchaus erhellend, bietet aber keinen einfachen und schnellen Weg der Verbesserung an - einfache Lösungen für komplexe Probleme sind nun mal sehr, sehr selten. In vielen Fällen würde es aber schon viel helfen, die Eliten-Überproduktion als reales Phänomen anzuerkennen und an ihrer Eindämmung zu arbeiten. Dadurch würde zwar nicht alles besser, zumindest wäre aber eine ständig in neue Konflikte führende Dynamik beendet, so dass dorthin keine Energie mehr abfliesst.

¹Er vertritt auch noch einige andere kontroverse Thesen, aber um die soll es hier nicht gehen
²Ein bekanntes Beispiel sind die Ehemaligen-Netzwerke grosser Unternehmensberatungen
³Die Menge an Mitteln und Führungspositionen ist endlich und damit auch der Eliten-Zugang
⁴Ein Beispiel dafür wäre das Aufkommen einer Unternehmer-Elite im 19. Jahrhundert