Donnerstag, 28. März 2024

Entgleiste Meeting-Moderation


Das hier ist eines der Videos, bei denen der alte Spruch stimmt: das Lachen bleibt einem im Hals stecken. Entdeckt habe ich es in den Kommentaren eines Linkedin-Posts, in dem die These aufgestellt wurde, dass Retrospektiven bestenfalls sinnlose Zeitverschwendung sind und schlimmstenfalls eine an Mobbing grenzende Zwangs-Infantilisierung erwachsener Menschen. Das Bittere daran ist, dass es viele Teams gibt, in denen genau das der Fall ist. Das Video ist verstörend nah an einer häufigen Realität.


Anzutreffen sind derartige Katastrophen-Termine immer dann, wenn der Scrum Master, Agile Coach oder Design Thinking-Facilitator den anderen gegen ihren Willen "spielerische Elemente" aufzwingt, unter denen sie eher leiden als von ihnen in irgendeiner Form zu profitieren. Alleine ich habe über die Jahre eine mittlere zweistellige Anzahl derartig entgleister Meeting-Moderationen erlebt, einige davon noch verheerender als hier zu sehen (!) - und alle aus bestem Willen heraus so durchgeführt (was das Ganze um so tragischer macht).


Das soll natürlich nicht heissen, dass Ice Breaker und Gamification per se schlecht wären, viele Teams lieben sie. Genau darin steckt aber ein entscheidender Punkt: wer solche Elemente als Moderator nutzen möchte, sollte genau darauf achten, ob die Teilnehmer sie wollen oder sich davon zumindest nicht gestört fühlen - sowohl grundsätzlich als auch im jeweiligen Einzelfall. Immer dann, wenn das nicht der Fall ist, kann man nur dringend raten, damit sofort aufzuhören. Wenn nicht, wird man das Gegenteil dessen erreichen, was eigentlich beabsichtigt ist.

Dienstag, 26. März 2024

Wie und wann man in Scrum Stakeholder einbinden kann

Bild: Pexels / Theo Decker - Lizenz

Auf die Frage nach den Rollen, bzw. Verantwortlichkeiten, in Scrum werden die meisten Kenner dieses Frameworks ohne zu Zögern mit den Entwicklern, dem Product Owner und dem Scrum Master antworten. Das ist auch grundsätzlich richtig, lässt aber eine vierte aus, die im Scrum Guide (Version von 2020) immerhin dreizehn mal an verschiedenen Stellen genannt wird: die der Stakeholder, also der (team-externen) Interessenvertreter. Wie kommt es, dass diese Gruppe so häufig übergangen wird?


Eine Antwort darauf ist, dass die Stakeholdern im Scrum (scheinbar) nicht am Sprint beteiligt sind. Bei oberflächlicher Betrachtung kann es so erscheinen, als würden sie nur als "Publikum" im Sprint Review erscheinen. Bei näherer Betrachtung können sie aber durchaus stärker eingebunden werden. Zum einen aufgrund der Vorgaben des Scrum Guide selbst, zum anderen durch verschiedene Praktiken, mit denen die bewusst offen gelassenen Lücken von Scrum gefüllt werden können.


Die Stakeholder im Sprint Planning

Um mit einer kleinen Überraschung zu starten - die mögliche Mitwirkung der Stakeholder im Planning steht im Scrum Guide. The Scrum Team may also invite other people to attend Sprint Planning to provide advice. heisst es dort. Eine Möglichkeit, von der viel zu selten Gebrauch gemacht wird.


Die Stakeholder im Daily Scrum

Es ist kein offizieller Teil von Scrum, aber eine häufige Praxis: Daily Scrum Meetings finden öffentlich statt, so dass jeder, der ein Interesse hat, als Zuschauer teilnehmen kann. Häufig reicht das bereits als ein Kommunikationsinstrument aus, ggf. ergeben sich daraus auch Themen für Folgegespräche.


Die Stakeholder im Backlog Refinement

In Scrum ist das Refinement nicht notwendigerweise ein Meeting sondern eine Tätigkeit, in deren Rahmen Backlog-Einträge erstellt, präzisiert und priorisiert werden. Analog zum Sprint Planning können dabei Experten und Kundenvertreter bei Bedarf einbezogen werden.


Die Stakeholder in der Sprint Review-Vorbereitung

Nirgendwo steht, dass die Stakeholder erst im Review-Meeting die Sprint-Ergebnisse sehen dürfen. Oft gilt sogar ein je früher, desto besser, da dadurch mehr Zeit bleibt die Features auszuprobieren, Feedback vorzubereiten und, falls die Zeit das zulässt, sogar noch Änderungswünsche zu platzieren.1


Die Stakeholder im Sprint Review

Nochmal zum Scrum Guide. Ihm zufolge wird den Stakeholdern im Review nicht nur das Ergebnis gezeigt und sie geben nicht nur Feedback, sie erarbeiten darüber hinaus zusammen mit dem Scrum Team nächste Schritte und passen gemeinsam die Planung an. Es ist eine aktive, mitentscheidende Rolle.2


Die Stakeholder in der Sprint Retrospektive

Der seltenste Beteiligungsfall: Retrospektiven sind im Normalfall strikt Scrum Team-intern, um dort vertraulich und in psychologischer Sicherheit auch an schwierigen Themen arbeiten zu können. Aber wenn es dabei um die Zusammenarbeit mit Anderen geht, können die auch gezielt eingeladen werden.


Spezielle Stakeholder-Termine

Über die offiziellen Scrum-Events hinaus kann es Sinn machen, weitere Stakeholder-Termine einzurichten. Welche das sind kann je nach Bedarf unterschiedlich sein, es sollten nur nicht zu viele werden. Und übrigens: auch das Scrum of Scrums ist bei näherer Betrachtung ein Stakeholder-Meeting.


Noch einmal zusammengefasst: wer in den Stakeholdern nur das Publikum für die Sprint Reviews sieht, wird nicht das volle Potential von Scrum nutzen. Sie können (und sollen) an verschiedenen Stellen ihre Expertise einbringen und in diesem Rahmen aktiv mit den drei anderen Rollen, bzw. Verantwortlichkeiten, zusammenarbeiten. Und dort wo das noch nicht passiert sollte der Scrum Master tätig werden. Zu dessen Aufgaben gehört nämlich laut Scrum Guide removing barriers between stakeholders and Scrum Teams.



1Das geht natürlich nur, wenn nicht erst alles am letzten Tag fertig wird. Nochmal eine eigene Geschichte
2Um zu zeigen wie weit das gehen kann: vor der Verschlankung von 2020 stand im Scrum Guide sogar, dass im Review Budgets neu festgelegt werden können

Donnerstag, 21. März 2024

Vollständige Tätigkeit

Bild: Pexels / Yan Krukau - Lizenz

Ein Hoch auf die Wissenschaft! Diesesmal sind es Arbeits- und Organisationspsychologen der Universität Halle, die eine verbreitete Annahme überprüft haben, so dass man diese jetzt auf der Basis valider Empirie vertreten kann. Die Rede ist von End-to-End-Verantwortung, oder "Vollständiger Tätigkeit", wie sie hier genannt wird, und von den Auswirkungen, die diese Art von ganzheitlicher Beschäftigung mit einem Thema auf Menschen haben kann.


Das Konstrukt der „vollständigen Tätigkeit“ als Ziel guter Arbeitsgestaltung heisst der Forschungsbericht, der auf Basis von 800 Betrachtungen und Interviews entstanden ist, durchgeführt mit Menschen unterschiedlichster Berufsgruppen. In dieser Forschung wurde überprüft, welche so genannten Beanspruchungsfolgen (vereinfacht gesagt Auswirkungen auf die Psyche) unterschiedliche Ausmasse der Verantwortung über die eigene Tätigkeit haben (siehe auch hier).


Ein erstes Ergebnis ist, dass "unvollständige Tätigkeiten", die jeweils nur einen Teil einer Wertschöpfung umfassen, eher zu negativen als zu positiven Beanspruchungsfolgen führen. Da in diesem Vorgehen zahlreiche Abhängigkeiten zu anderen Gruppen bestehen, empfand die Mehrheit der untersuchten Personen ständigen Zeitdruck, der Versuch allen Abhängigkeiten gerecht zu werden führte ausserdem zu ständigen Kontextwechseln und Unterbrechungen. Insgesamt entstanden Ineffektivität und Ineffizienz.


Umgekehrt führten "vollständige Tätigkeiten", die grosse Teil der Wertschöpfung umfassen, eher zu positiven als zu negativen Beanspruchungsfolgen. Das in diesem Vorgehen mögliche eigenständige Zielsetzen, Planen und Kontrollieren führte bei der Mehrheit der untersuchten Personen zu mehr Engagement, Zufriedenheit und Commitment, was sich in Form von gesteigerter Kreativität und Effizienz auch auf die Arbeitsleistung auswirkte.


Eine wichtige Differenzierung ergab sich dabei durch das Ausmass der kognitiven Beanspruchung, die durch die jeweiligen Anforderungen des End-to-End-verantwortlichen Arbeitens entstand. Wurde dieses als zu hoch empfunden, konnte es auch bei "vollständigen Tätigkeiten" zu eher negativen als positiven Beanspruchungsfolgen kommen, da dann erneut negative Treiber wie Zeitdruck und Stress auftreten können (zwar aus anderen Gründen, aber mit den selben Folgen).


Übertragen auf die Gestaltung beruflicher Stellen bedeutet dass, dass sich diese idealerweise in der Mitte eines Spannungsfeldes zwischen möglichst umfassender Verantwortung und noch bewältigbarer kognitiver Belastung befinden sollten (wobei diese "Mitte" in den meisten Fällen eher ein beweglicher als ein fixer Punkt sein dürfte). "Agile Praktiken" wie das Pull-Prinzip, Inspect & Adapt und das Automatisieren repetitiver Tätigkeiten könnten bei dieser Gestaltung wesentliche Erfolgsfaktoren sein.

Montag, 18. März 2024

Ein Bild sagt mehr als 1000 Worte (XXXXI)

Grafik: Design Thinking! Comics

Den Vergleich von Produktentwicklungs-Vorhaben mit einer Acherbahnfaher kenne ich schon länger, aber noch nicht in dieser schönen Visualisierung.

Donnerstag, 14. März 2024

Confidence Meter

Grafik: Itimar Gilad - CC BY-SA 4.0

Würde man die Entwicklungsteams dieser Welt diejenigen Fragen nennen lassen, die am schwersten zu beantworten sind, würde eine mit ziemlicher Sicherheit weit oben landen: "Wie sicher seid Ihr, dass Euer Produkt am Markt erfolgreich sein wird?" Vor allem wenn etwas neu entwickelt wird (also in der IT eigentlich immer) ist eine wirklich sichere Antwort aufgrund fehlender Erfahrungswerte kaum möglich, gleichzeitig ist die Antwort "Kann man nicht sagen" natürlich auch unbefriedigend, schliesslich müssen Investitions- oder Abbruch-Entscheidungen ja irgendwann getroffen werden. Ein Dilemma.


Ein Weg um aus diesem Dilemma zu entkommen und zu realistischen Zuversichts-Werten zu kommen ist das Confidence Meter von Itimar Gilad. Mit seiner Hilfe lässt es sich die Bewertung aus verschiedenen Einfluss-Faktoren ableiten, und das nicht etwa nur auf Basis von Bauchgefühl, sondern auf der Grundlage überprüfbarer und in ihrer Gewichtung abgestufter Erkenntnisse, bzw. Ergebnisse. Dadurch ist dieser daraus summierte Wert nicht nur differenzierter, er ist auch weniger anfällig für unrealistisch optimistische Selbsttäuschungen und Manipulationen. Die (vereinfachten) Faktoren sind:


Individuelle Überzeugungen (Zuversichtswert 0,1)

Damit fängt alles an. Irgendjemand (Person oder Gruppe) hat die initiale Idee und glaubt daran, dass aus ihr etwas Grosses werden kann. Das ist wichtig und darf nicht geringgeschätzt werden, eine auch nur irgendwie geartete Erfolgswahrscheinlichkeit lässt sich aber kaum daraus ableiten.


Ein Pitch Deck (Zuversichtswert 0,1)

Sich selbst überzeugt zu haben ist ein erster Schritt, als nächstes gilt es andere zu überzeugen. Überlicherweise geschieht das mit einer Präsentation der (angenommenen) Potentiale und Vorteile. Die zu erstellen verhilft zu strukturierteren Annahmen, zu mehr aber noch nicht.


Aktuelle Trends, Moden und Buzzwords (Zuversichtswert 0,1)

Man kann hier einen beliebigen Hype einsetzen: Digital, Mobil, KI, was auch immer. Darauf aufzuspringen erscheint naheliegend und verlockend, eine auch nur irgendwie geartete Erfolgswahrscheinlichkeit lässt sich aber noch immer kaum daraus ableiten.


Unterstützende Meinungen (Zuversichtswert 0,5)

Ab hier wird es schon ein ganz kleines bisschen objektiver. Wenn auch andere Personen der Meinung sind, dass die Idee Potential haben könnte, ist das eine erste Bestätigung. Und wenn diese Personen auch noch über Budgets oder sonstige Ressourcen verfügen, um so besser.


Schätzungen und Planungen (Zuversichtswert 0,5)

Nehmen wir an, dass Budget da ist, jetzt kann überlegt werden, wie und wann es investiert wird. Das kann sehr dabei helfen, die Umsetzbarkeit zu beurteilen (ein durchaus wichtiger Punkt), ob das Produkt am Markt erfolgreich sein wird, ist aber noch immer sehr ungewiss.


Anekdotische Evidenz (Zuversichtswert 1)

An dieser Stelle gibt es zum ersten Mal eine kleine empirische Validierung. Irgendwo ist ein (angeblich) vergleichbares Vorhaben erfolgreich gewesen. Darin steckt im Zweifel noch viel Hören-Sagen, aber zumindest ist es zum ersten Mal etwas, das über Vermutungen und Hoffnungen hinausgeht.


Marktforschung (Zuversichtswert 3)

Mit Marktforschung wird Hören-Sagen durch eine erste, noch abstrakte, Bedarfsermittlung ersetzt. Ob die potentiellen Kunden und Nutzer aus diesem möglichen Bedarf eine konkrete Kaufentscheidung ableiten werden ist unklar, zumindest hat man sie jetzt aber erstmals überhaupt befragt.


Kunden-, bzw. Anwender-Wünsche (Zuversichtswert 3)

Ab hier wird es konkreter. Konfrontiert mit den ersten Entwürfen des zukünftigen Produkts können potentielle Kunden und Nutzer Wünsche, Erwartungen und Nutzungs-Absichten äussern. Noch keine Erfolgsgarantie, aber ein starker Indikator.


Ergebnisse von Kunden-, bzw. Anwender-Tests (Zuversichtswert 5)

Aus dem starken wird an dieser Stelle ein sehr starker Indikator. Test- und Focus-Gruppen bekommen Prototypen oder MVPs zur Verfügung gestellt und können Rückmeldung zur Benutzungs-Erfahrung und zum wahrgenommenen Mehrwert geben, ggf sogar schon zur Kauf-Absicht.


Echte Verkaufs- und Nutzungsdaten (Zuversichtswert 10)

In diesem letzten Stadium hat der Verkauf bereits begonnen und die ersten Zahlen zu Absatz und Nutzung wurden bereits ermittelt. Die Indikatoren werden jetzt nach und nach durch Beweise abgelöst, die Erfolgswahrscheinlichkeit ist klar abzusehen oder sogar bereits ermittelt.


Wie oben gesagt, diese Übersicht ist etwas vereinfacht, hinter den einzelnen Faktoren stecken nochmal Bandbreiten und Gewichtungen. Die Details dazu (inclusive einer Tabelle mit Berechnungsformeln) hat Itimar Gilad freundlicherweise auf seiner Website zur Verfügung gestellt. Wichtig ist aber, dass sich am Ende aus den Ausgangswerten der einzelnen Faktoren eine Gesamtsumme bildet, die einen realistischen, kaum verfälschbaren Zuversichtswert auf einer Skala zwischen 1 und 10 abbildet.


Was bei näherer Betrachtung dieses Modells auffällt ist, dass sich hohe Zuversichtswerte erst relativ spät, bzw. kurz vor dem Markteintritt ergeben können. Das ist für alle, die möglichst früh möglichst viel Sicherheit haben wollen, natürlich ärgerlich. Auf der anderen Seite ist es aber auch die harte Wahrheit - frühe Sicherheit gibt es bei neuen Produkten nicht. Wer nicht bereit ist das zu akzeptieren, dem werden auch Tools wie dieses hier nicht helfen.

Montag, 11. März 2024

Kollabierende methodische Modelle

Wenige Innovationen der letzten Jahrzehnte dürften so mit Hoffnungen und Erwartungen überladen sein wie die generative künstliche Intelligenz (in Form von Programmen wie Chat GTP, Gemini, o.Ä.). Um so ironischer dürfte es sein, dass wir durch sie etwas lernen können, was so niemand erwartet haben dürfte: wir können anhand der Evolution dieser Technologie erkennen, warum methodische Vorgehensweisen dem starken Risiko ausgesetzt sind, mit der Zeit unbrauchbar zu werden. Aber der Reihe nach.


Im Frühling 2023 veröffentlichten britische und kanadische Forscher die Studie The Curse of Recursion: Training on Generated Data Makes Models Forget. In ihr belegten sie folgendes Phänomen: wenn eine künstliche Intelligenz (KI) nur zu Beginn auf Basis bestehender Datensätze trainiert wird, dann aber ihre auf dieser Basis generierten Ergebnisse wiederum zu dem Trainingsmaterial hinzugefügt werden, dann wird die Qualität der Ergebnisse mit zunehmender Zeit immer schlechter.


Der Grund dafür ist Folgender: die Generierung erfolgt (stark vereinfacht) durch die Ermittlung der Durchschnittswerte aus bestimmten thematisch zusammengehörigen Teilen des Trainingsmaterials. Dadurch gehen Nuancen und Kontext verloren, Trends und verbreitete Missverständnisse entwickeln dagegen ein überproportionales Gewicht. Fliessen die so erzeugten Ergebnisse wieder in das Traininingsmaterial ein, entsteht eine immer stärker werdende Verfälschungs-Dynamik.


Das Ergebnis dieser Dynamik ist der irgendwann stattfindende Modell-Kollaps (Modell steht hier stellvertretend für die KI-Programme): die generative KI hat mit der Zeit so viel fehlerhaftes Material erstellt, dass das Trainingsmaterial in einem derartigen Ausmass davon kontaminiert ist, dass die ursprünglichen, unkontaminierten Bestandteile in Relation dazu in den Hintergrund treten. Und auf Grundlage dieser fehlerhaften Basis entstehen ab jetzt im Wesentlichen falsche Ergebnisse.


Jetzt zur Übertragung auf methodische Vorgehensweisen. Auch diese beruhen zu Beginn (sofern sie seriös sind) auf empirisch erhobenen Erfahrungswerten und sind so in der Realität verankert. Auf dieser Basis entehen aber auch hier Ergebnisse (Konferenzbeiträge, Fachpublikationen, etc.), die populäre Irrtümer, Durchschnitte und Moden verstärkt abbilden. Und wenn das wieder in die Weiterentwicklung der Methodik einfliesst, droht der Kollaps dieser (mentalen) Modelle auch an dieser Stelle.


Die Folge dieser kollabierenden methodische Modelle sind deren zunehmende Entkoppelungen von der Realität, oft in Form von immer trivialer und esoterischer werdenden Frameworks und Methoden. Transaktionale Führung, Selbstorganisation, Purpose oder ähnlich generische Konzepte werden undifferenziert und kontextbefreit zu Universallösungen erhoben, Management-Moden wie das "Spotify Model" oder OKRs werden mit unrealistischen Erfolgsversprechen verbunden, etc, etc.


Ein Weg, der aus dieser Situation herausführen kann, lässt sich übrigens erneut aus den Trainings der generativen KIs extrahieren. Diese führen nämlich dann wieder zu besseren Ergebnissen, wenn die selbsterzeugten Inhalte bewusst nicht in das Ausgangsmaterial weiterer Trainings aufgenommen werden (bzw. dort wo das bereits passiert ist wieder aus ihm entfernt werden), um so die sich selbst verstärkenden Verfälschungs-Kreisläufe gar nicht erst entstehen zu lassen.


Auf die Methodenwelt übertragen würde das bedeuten, Management-Moden, generische oder vereinfachte Ideen und stark kontextspezifische Fallstudien bewusst nicht in die Weiterentwicklung von Vorgehensmodellen einfliessen zu lassen und sich stattdessen auf empirische Validierung und wissenschaftliche Evidenz zu stützen. Inwiefern Organisationen wie das Project Management Institute oder Scaled Agile Inc. wohl dazu bereit wären, kann jeder für sich selbst zu bewerten versuchen.

Donnerstag, 7. März 2024

Reed Hastings on the Netflix Culture

Dass Netflix eine agile Vorzeigefirma mit einer ganz besonderen Unternehmenskultur ist, weiss man spätestens seit No Rules Rules, dem Buch seines CEO Reed Hastings. In diesem Interview in der Stanford Graduate School of Business erzählt er, wie sich sein Unternehmen und seine Kultur in den letzten Jahren weiterentwickelt haben und geht dabei auch auf einige Aspekte ein, die in seinem Buch noch nicht vorgekommen sind (z.B. den Einsatz künstlicher Intelligenz).



Für alle denen das noch nicht reicht, gibt es noch einen weiteren Einblick in die Netflix-Kultur, der aus einem etwas anderen Blickwinkel stattfindet. Kathryn Koehler hat in dieser Firma den bemerkenswerten Titel eines "Director of Productivity Engineering" und kann einiges zu ihrer Leistungskultur und deren Wandel in den letzten Jahren sagen. Zum Interview mit ihr geht es hier.

Montag, 4. März 2024

Conway's Coaching

Bild: Freerangestock / Rawpixel - License

Wenn sich Unternehmen einmal darauf eingelassen haben, ihren Mitarbeitern Coaches zur Seite zu stellen, kommt es immer wieder in der Folgezeit zu Ausdifferenzierungen dieser Rolle. In der Regel durch ein Präfix gekennzeichnet, entwickeln sich "Spezialisten-Coaches" für bestimmte Themengebiete, vom Quality Coach über den DevOps Coach bis zum Leadership Coach kann alles Mögliche dabei sein. Das ist auch erstmal ok, wie so oft kann man bei näherer Betrachtung aber Erstaunliches erkennen.


Viele der verschiedenen ausdifferenzierten Coach-Rollen werden weniger aufgrund von Nachfrage, Unternehmensstrategie oder sonstigen übergreifenden Notwendigkeiten und Zielen definiert, sondern aufgrund eines ganz anderen Kriteriums: der Organisationsstruktur. Sie werden innerhalb der vorhandenen Bereiche oder Abteilungen aufgebaut, deren Themengebiet dadurch auch zu ihrem Coaching-Gebiet wird. Zum Beispiel ist der Quality Coach in der Regel Teil einer Quality Assurance-Einheit.


Das ist zunächst einmal weder gut noch schlecht, und auch nicht ungewöhnlich. Die Tendenz, dass Organisationen ihre Organisationsstruktur auf alles mögliche übertragen ist so verbreitet, dass dieses Phänomen sogar als "Gesetzmässigkeit" formuliert wurde, Conways Law. Ihm zufolge ist diese Übertragung sogar zwangläufig und findet praktisch jedes mal statt, wenn neue Systeme (vor allem technischer, aber auch sozialer Art) erschaffen werden.


Was diese "Gesetzmässigkeit" problematisch macht, ist, dass eine anhand der Organisationsstruktur vorgemommene Aufteilung nicht immer den gegebenen Notwendigkeiten entspricht, und ihnen mitunter sogar zuwiederläuft. Statt zusammengehörende Aspekte gemeinsam zu betrachten und basierend darauf zu entscheiden, welcher von ihnen den grössten Handlungsbedarf (bzw. in diesem Fall Coaching-Bedarf) hat, verengt sich der (Coaching-)Fokus unverhältnismässig stark auf einen Teilbereich.


Wer solche Konstellationen erlebt hat, wird es vermutlich kennen: der Product Coach hilft den Product Ownern bei Roadmaps und Kunden-Interaktionen, lenkt die Aufmerksamkeit seiner Coachees aber selten auf technische Probleme. Der Agile Coach dringt auf regelmässige Auslieferung, selbst wenn der Release-Zyklus durch eine jährliche Leitmesse vorgegeben ist, der QA Coach fördert durch seine ausschliessliche Arbeit mit den Testern unbewusst deren Separierung von den Entwicklern, etc. etc.


Wird diese Entwicklung erkannt, ist es ein häufiger Reflex, alle Coaches in zentralen Einheiten, oft "Coach Pool" genannt, zusammenzuziehen, die z.B. in HR oder Change Management verortet sind. Das scheint zunächst sinnvoll, da Gesamtsicht und Gesamtzuständigkeit entstehen, kann aber auch wieder in Conway's Law enden, da die jetzt übergeordnete zentrale Einheit ebenfalls Partikularinteressen hat, die den übergreifenden Unternehmenszielen ggf. nicht entsprechen.1


Ebenfalls zu beachten ist, dass es auch sinnvolle Erwägungen gibt, die dazu führen, dass Conway's Law auch bei der Definition spezialisierter Coaching-Rollen stattfindet. In Fach- oder Spezialisten-Abteilungen verortete Coaches können bei ihrer Ausbildung und Weiterentwicklung von der hier vorhandenen Expertise profitieren, die in einer zentralen, organisationsübergreifenden Einheit naturgemäss nur schwach ausgeprägt sein kann.


Aus meiner Erfahrung ist ein anderer Weg besser: die "Spezialisten-Coaches" verbleiben zwar zum Zweck des Expertise-Aufbaus in ihren ursprünglichen Einheiten, sie bilden aber organisationsübergreifend eine Querschnittsorganisation, in der Einsatzplanung, Austausch, Abstimmung und das Setzen von gemeinsamen Standards stattfinden können, mit dem Ziel, dass trotz Spezialisierung eine Einheits-übergreifende Sicht auf die Gesamtorganisation und ihre Bedürfnisse und Notwendigkeiten möglich ist.


Wichtig dabei: wir sprechen immer noch von ausdifferenzierten Rollen, wie Quality Coach, DevOps Coach, etc. Bei Team Coaches mit fester Teambindung kann eine stärkere lokale Verankerung Sinn machen, das wäre aber nochmal ein eigenes Thema.


1Ein häufiges Phänomen ist z.B. der Versuch einer "Optimierung" der Einsatzplanung, wodurch Coaching-Quantität auf Kosten von Coachin-Qualität gewonnen wird.