Kommentierte Links (CV)

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.

Emily Webber: Bridging Silos and Overcoming Collaboration Antipatterns in Multidisciplinary Organisations

Dass die Aufteilung einer Organisation in Einheiten aus gleichartigen Spezialisten (so genannte "Silos") eine schlechte Idee ist, ist keine neue Erkenntnis. Warum das so ist ist häufig wesentlich unklarer, viele Begründungen beschränken sich auf abstrakte Schlagwörter wie "Kommunikations-Overhead" oder "fehlende Systemsicht". Emily Webber wird konkreter und nennt drei verbreitete nachteilige Folgen: die Aufteilung einzelner Spezialisten auf mehrere Teams (mit Termin-, Prioritäts- und Loyalitätskonflikten als Folge), Machtkämpfe zwischen den Silos auf Kosten des Gesamtsystems und die sich daraus ergebende Macht-Ungleichgewicht zwischen den Gewinner- und Verlierer-Silos. Auch beim Aufzeigen besserer Alternativen geht sie über die abstrakte Forderung nach einem crossfunktionalen Team hinaus. Wer schon immer den Unterschied zwischen Multidisziplinär, Interdisziplinär und Transdisziplinär wissen wollte, wird bei ihr fündig.

Łukasz Korecki: OKRs? More like, R U OK?

Ich bin schon seit langem skeptisch gegenüber OKRs, und Łukasz Korecki geht in seinem Artikel auf einige Gründe ein die auch ich kritisch sehe: Mit ihrer üblicherweise quartalsweisen Ansetzung der Objectives sind sie nicht besonders agil, mit ihrem Beharren auf messbaren Key Results verleiten sie zu Output statt Outcome, da sie wie alle anderen auf Messbarkeit ausgelegten Vorgehensmodelle eine starke Anfälligkeit für Goodhart's Law haben (When a measure becomes a target, it ceases to be a good measure) und zuletzt führt diese Art der Ergebnisfixierung zu einer Vernachlässigung von Lern- und Discovery-Bemühungen. Eine Beobachtung von ihm teile ich ebenfalls: positive Äusserungen über OKRs kommen fast nie von denen die damit arbeiten müssen, sondern fast ausschliesslich von denen die sie anordnen oder durch Trainings mit ihnen Geld verdienen.

Jason Yip: Continuous Integration / Continuous Delivery

Die technische Seite von Agilität wird leider manchmal vernachlässigt, weshalb es mich immer wieder freut wenn sie irgendwo Erwähnung findet. Jason Yip macht das, indem er auf die Frequenz eingeht, in der neu entwickelter Code mit dem bestehenden zusammengeführt wird. Indem er sich von den langen zu den kurzen Zeiträumen vorarbeitet kann er aufzeigen welche Probleme es bei den ersten gibt (der Begriff "Integration Hell" sagt eigentlich alles aus) und welche Vorteile die letzten haben. Gut ist, dass er nicht nur den bestmöglichen Weg hervorhebt (jeder Entwickler integriert seien neuen Code mindestens einmal täglich) sondern auch die verschiedenen Tests die dabei durchlaufen werden: nicht nur die Pre-Merge-Tests vor der Integration, sondern auch die Post-Merge-Tests danach.

Lukas Kijauskas: How much € does a full time Scrum Master save to a company per year?

Die Frage, ob ein Scrum Master oder Agile Coach sich wirtschaftlich rechnet, ist eine die immer wieder diskutiert wird. Den Versuch von Lukas Kijauskas die Leistung tatsächlich in Geld umzurechnen kann man daher eigentlich nur gut finden. Seine Berechnungen sollte man allerdings mit einem "Beipackzettel" lesen: die von ihm genannten Gehälter für Entwickler, Scrum Master und Product Owner entsprechen denen in Litauen und sind in Deutschland nochmal andere. Und seine Beispiele für das, was ohne einen Scrum Master, langsamer, ineffizienter und teurer sein würde sind vermutlich in seinem Arbeitskontext zutreffend, aber nicht überallhin übertragbar. Mit diesen Gedanken im Hinterkopf kann man sich aber von seinen Überlegungen inspierieren lassen, um für das nächste Gespräch gerüstet zu sein, in dem gefragt wird ob diese Rolle ihr Gehalt wirklich wert ist.

Christiaan Verwijs: The Double-Edged Sword Of Diversity In Teams

Man kann Christiaan Verwijs nur loben, den er hat sich etwas Wichtiges vorgenommen: er unterzieht die vielen Glaubenssätze und Annahmen die in der agilen Community verbreitet sind einer wissenschaftlichen Validierung. Nachdem er in der Vergangenheit bereits u.a. die Effektivität von Pair Programming und den Zusammenhang von Agilität und Firmengrösse untersucht und die Arbeitsergebnisse von Scrum und SAFe verglichen hat, ist es diesesmal der Einfluss, den eine diverse Zusammensetzung auf Entwicklungsteams hat. Basierend auf Befragungen von 1.118 Menschen aus 161 Teams ist seine Antwort differenziert. Je nach Art der Diversität (Alter, Geschlecht, Kultur, Hierarchie) kann es zu positiven Effekten kommen, eine grundsätzliche Regel, dass Diversität zu besserer Zusammenarbeit oder besseren Arbeitsergebnissen führt lässt sich aber nicht belegen. Ein weit verbreiteter Glaubenssatz ist damit in Frage gestellt. Das heisst natürlich nicht, dass man Diversität nicht aus anderen Gründen anstreben sollte, die häufig vorgenommene Verknüpfung mit wirtschaftlichen Vorteilen ist aber fragwürdig.

Doch wie Spotify werden (III)

Lange wurde darüber diskutiert ob das so genannte Spotify Model mit seinen Squads, Chaptern, Gilden und Tribes überhaupt als agiles Skalierungsframework konzipiert wurde, oder ob es nur eine zufällige Momentaufnahme aus der Entwicklung dieser Firma ist. Diese Diskussion dürfte mittlerweile obsolet sein, seit dieses Modell von den grossen Strategieberatungen bei einem Konzern nach dem anderen eingeführt wird, hat es sich von seinen Ursprüngen gelöst und ist zu etwas Eigenständigem geworden.

Auch die Frage ob man es überhaupt in anderen Firmen als Spotify einführen kann ohne es zu stark zu verfremden dürfte mittlerweile beantwortet sein. Zwei seiner Urheber, die ehemaligen Spotify-Agile Coaches Joakim Sunden und Henrik Kniberg sind klar der Meinung das das durchaus möglich ist, und haben derartige Einführungen auch in anderen Firmen begleitet. Was bleibt, ist die entscheidende Zusatzfrage - unter welchen Umständen ist eine solche Einführung sinnvoll?

Eine Antwort darauf lässt sich bei einem dritten der ehemaligen Agile Coaches von Spotify finden, bei Cliff Hazell, der (u.a. in diesem Podcast) die Rahmenbedingungen erklärt hat, aus denen heraus das Spotify Model entstanden ist. Der entscheidende Punkt: es macht nicht für bestimmte Unternehmensarten, Unternehmensgrössen oder Branchen Sinn, sondern für Unternehmen in einer bestimmten Phase, nämlich in der, in der sie schnell wachsen.

Wer schon einmal die Scale Up-Phase eines Unternehmens mitgemacht hat kann nachvollziehen was er meint. Starkes Wachstum bedeutet für die einzelnen Angestellten permanente Veränderung. Teams werden neu gegründet, geteilt oder aufgelöst, Postionen neu geschaffen, besetzt und wieder abgeschafft, Value Streams bilden sich und spalten sich auf, etc. All das ist für das jeweilige Unternehmen sinnvoll und notwendig, hat für die Einzelpersonen aber zwei grosse Nachteile.

Zum einen wird der Aufbau sozialer Beziehungen zu den Arbeitskollegen schwierig, da diese ständig wechseln. Vertrauensverhältnisse, psychologische Sicherheit und kollektives Gedächtnis können sich so nur erschwert oder gar nicht bilden, was negative Effekte auf verschiedene Bereiche hat, von der Arbeits-Produktivität und -Effektivität über die Identifikation mit dem Unternehmen bis hin zur Zufriedenheit mit der eigenen Tätigkeit.

Zum anderen wird die Förderung und Entwicklung der einzelnen beruflichen Karrieren schwieriger. Wer ständig in neue Teams versetzt wird, und damit ständig neue Arbeitsthemen und Vorgesetzte bekommt, wird es schwer haben, sich gezielt und langfristig in eine bestimmte fachliche Richtung weiterzuentwickeln, ausserdem wird den Vorgesetzten aufgrund der kurzfristigen Zuordnungen nur schwer beurteilen können, ob Gehaltserhöhungen, Beförderungen, o.Ä. gerechtfertigt wären.

Das Spotify Model hat diese Nachteile einer Wachstumsphase kompensieren können. Die ständigen Umorganisationen fanden im Rahmen der Squads (Entwicklungsteams) statt. Da aber jeweils mehrere Squads einem Tribe (einer Art Abteilung) angehörten, und die Einzelpersonen vor allem zwischen den Squads eines Tribes wechselten, konnten sie ihre sozialen Beziehungen in dieser grösseren Einheit aufbauen und dort ihre organisatorische Heimat finden.

Gleichzeitig existierten innerhalb dieser Tribes nicht nur die produktorientierten Squads, sondern auch so genannte Chapter, Querschnittsorganisationen für Spezialisten (Frontend, QA, etc), aus denen die Einzelpersonen in die Squads entsandt wurden, und in denen sie auch ihren Vorgesetzten hatten (den Chapter Lead), der sie langfristig begleiten und zusammen mit ihnen ihre Karriere entwickeln konnte. Vor diesem Hintergrund machte das Spotify Model in dieser Wachstumsphase Sinn.

Springen wir in die Gegenwart. Wie Spotifys CTO Gustav Soderström in einem anderen Podcast erklärt hat, ist die Wachstumsphase seines Unternehmens mittlerweile vorbei und die Teams haben sich stabilisiert. Ohne die zu kompensierenden Auswirkungen des Wachstums ist die alte Struktur der sich überlappenden Einheiten nicht mehr nötig und wurde abgeschafft, heute hat die Firma einen eher klassischen Abteilungs-Aufbau, der einfacher und effizienter ist.

Was wir daraus lernen können: wenn die Umstände stimmen (und Phasen des Wachstum oder einer sonstigen Umorganisation sind derartige Umstände), kann das so genannte Spotify Model für eine Zeit lang eine gute Idee sein um die eigene Firma zu organisieren, es sollte aber regelmässig darauf überprüft werden, ob das noch immer der Fall ist. Wenn das nicht mehr so ist machen andere Strukturen mehr Sinn, je nachdem in welchen Umständen die Organisation sich jetzt befindet.

Und falls sich jetzt jemand fragt, was das für die zu Beginn genannten Konzerne und Strategieberatungen bedeutet, die gerade flächendeckend Squads, Chapter, Gilden und Tribes ausrollen - nun ja, decken wir darüber den Mantel des Schweigens. Das ist eher ein Thema für die Ethnologie.

The Agile Bookshelf: Agile Missions Impossible

Ich gestehe es - diese Buchbesprechung hier ist nicht völlig uneigennützig. In Agile Missions Impossible, dem zweiten Band der Agile Short Stories, befinden sich nicht nur 49 Kurzgeschichten über das Möglichmachen von Agilität in schwierigen Umständen, eine dieser Geschichten ist auch von mir. Von jetzt an kann ich mich auf Parties also auch als Autor vorstellen, falls mal wieder die Situation eintreten sollte, dass keiner mit dem Begriff Agile Coach etwas anfangen kann.

Zur Grundidee: alle Autoren, einschliesslich der Herausgeberin Miriam Sasse, sind in irgendeiner Form als agile Methodenmenschen unterwegs, vom freiberuflichen Scrum Master bis zum Konzern-Manager ist alles Mögliche dabei. Bei einem Grossteil der Geschichten handelt es sich daher um Erfahrungsberichte, es sind aber auch andere Formate dabei, von der Satire bis hin zum Theaterstück. Im Kombination mit den verschiedenen Schreibstilen ist es daher ein sehr abwechselungsreiches Buch geworden.

Meine eigene Kurzgeschichte dreht sich um einen schon etwas zurückliegenden (und hinreichend anonymisierten) Einsatz in einem zu großen Projekt eines zu grossen Konzerns, damals noch in der Rolle eines Testmanagers. Die Sandwich-Position zwischen halb verstandenem Scrum auf Teamebene und halb verstandener Business-Agilität auf Programmebene hätte gennug Stoff für eine zweite und eine dritte Kurzgeschichte ergeben, mal sehen ob die auch noch kommen.

Noch ein wichtiger Punkt: die Erlöse aus dem Verkauf dieses Buchs gehen nicht an mich und die anderen Autoren, sondern an Flying Hope, einen gemeinnützigen Verein, der seit 2010 schwerkranke, schwerbehinderte und seit dem Ukraine-Krieg auch verletzte Kinder zu den jeweils bestgeeigneten Kliniken, Hospizen oder Pflegeeinrichtungen zur entsprechenden Diagnostik oder Therapie fliegt. Ein Grund mehr, sich eines der Bücher zu kaufen.

Die Agilen Missions Impossible gibt es bei:

• ISBN.de (mit Verbindung zum lokalen Buchhandel)
  
• Book on Demand
  
• Amazon
  
• Thalia
• Hugendubel
  
• und überall wo es sonst noch Bücher gibt
  

Als Ebook sind sie leider noch nicht verfügbar, sobald sich das ändert trage ich es nach.

From the agile revolution to the agile religion

Ein wirklich schön gemachtes Video, das eine weit verbreitete Meinung gut zusammenfasst: die, dass das agile Arbeiten sich von seinen Ursprüngen entfernt hat und zunehmend in Ritualen erstarrt. Leicht überspitzt, aber mit einem wahren Kern.

Etwas verwirrend ist der Titel, ein "Agile Paradoxon" wäre ein (wie auch immer gearteter) Widerspruch in sich, nicht eine Entwicklung in eine merkwürdige Richtung. Aber das nur am Rand.

Conway's Law, inversed

Bild: Unsplash / Paymo - Lizenz

Noch einmal zum Thema Conway's Law, jener von Melvin Conway definierten Gesetzmässigkeit, derzufolge Organisationen dazu tendieren, in ihrer IT-Systemlandschaft ihre Kommunikations- (oder Organisations-)struktur abzubilden. Da das problematisch (weil aus Softwarearchitektur-Sicht dysfunktional) ist, gibt es immer wieder Versuche, dieser Entwicklung gegenzusteuern. Der bekannteste derartige Ansatz trägt den Namen "Inverse Conway Maneuver", oder "Inverse Conway".

Erstmals formuliert 2010 von Jonhy Leroy und Matt Simons beruht Inverse Conway auf der Erkenntnis, dass Conway's Law in der Realität kaum zu vermeiden ist. Statt sich beim Versuch es zu verhindern aufzureiben wird stattdessen versucht es zu nutzen. Indem die Kommunikations- und Organisations-Strukturen bewusst so gestaltet werden, dass diese der gewünschten Software-Architektur entsprechen, wird diese herbeigeführt, bzw. gibt es keine Tendenz mehr, von ihr abzuweichen.

An einem Beispiel erklärt: würde ein Web-Shop von einem grossen Frontend-Team und einem grossen Backend-Team gebaut werden, wären laut Conways Law schwer weiterentwickelbare Frontend- und Backend-Monolithen die Folge. Kleine Teams, die in fachlichen Bereichen (Produkt-Suche, Produkt-Auswahl, Produkt-Bezahlung, etc.) jeweils Frontend und Backend verantworten, würden dagegen zu einer Struktur eigenständiger und vergleichsweise einfach weiterzuentwickelnder Module führen.

Aus Sicht einer agilen Produktentwicklung wäre eine derartige Konstellation grundsätzlich erstrebenswert, da sie die Aufwände für Planung, Abstimmung, Integration und Qualitätssicherung deutlich reduziert, wodurch für die eigentliche Weiterentwicklung mehr Kapazität zur Verfügung steht, die dazu auch noch früher, bzw. schneller genutzt werden kann. Das Ziel einer Liefer- und Reaktionsfähigkeit in kurzen Zyklen wäre damit einfacher erreichbar.

Wie alle scheinbar einfachen Lösungen ist aber auch das Inverse Conway Maneuver mit Vorsicht zu betrachten. In vielen Fällen kann das Ausmass technischer Komplexität in einem fachlich geschnittenen Modul so hoch sein, dass es für sein Team nur noch schwer zu beherrschen ist. Gleichzeitig würde eine dogmatische Befolgung von Inverse Conway die Nutzung der Effizienz- und Konsistenz-Vorteile verhindern, die durch Querschnitssysteme (z.B. gemeinsame Benutzerverwaltung) möglich werden.

Wie immer gilt also: es kommt darauf an. Das Inverse Conway Maneuver kann grossen Mehrwert stiften, wenn es mit Sinn und Verstand an der richtigen Stelle durchgeführt wird. Undifferenziert auf alles ausgerollt kann es zu Problemen führen, die schlimmstenfalls so schwerwiegend sind, dass sie die Vorteile wieder aufwiegen. Eine gute Idee wäre daher zu Beginn eine Umsetzung und Erprobung in nur einem Teil der Organisation, um so zu lernen, ob es auch in den anderen Teilen Sinn macht.

Ganz nebenbei: Mel Conway mag den Begriff Inverse Conway nicht. Das ändert zwar nichts am Konzept, es führt aber dazu, dass man sich bei seiner Einführung nicht zu offensiv auf ihn berufen sollte.

Should we call flying an "inverse gravity manoeuver"? https://t.co/mErFO5gK3d

— Mel Conway (@conways_law) April 7, 2021

'Wir haben es mit dem agilen Mindset versucht, aber es funktioniert nicht!'

Bild: Pexels / DS Stories - Lizenz

Man hört ja in letzter Zeit immer wieder, dass es so toll wäre, ein agiles Mindset zu haben. Ist es aber nicht. Wir haben es ausprobiert und es hat überhaupt nicht geklappt!

Dabei waren wir echt offen. Unmittelbar nachdem unser Personalvorstand auf seinem Yoga-Retreat gelernt hat, dass man nur die richtige geistige Haltung braucht, damit sofort alles besser läuft, haben wir die Tat ergriffen und alle unsere HR-Führungskräfte in Weiterbildungen zu Achtsamkeit, Spiral Dynamics und Emotionscoaching geschickt. Das lief auch wirklich total super, einige haben sich sogar ein Enneagram tätowieren lassen.

Wir haben es auch geschafft Fehlentwicklungen einzufangen. Statt sich auf Meditation und NLP einzulassen wollte unsere IT alles auf ihre technische Ebene herunterziehen und uns erzählen, dass Implementierungsdetails wie Clean Code, Build Pipelines und Testpyramiden etwas mit Agilität zu tun hätten (was soll das mit geistiger Haltung zu tun haben?). Zum Glück konnten wir klarmachen, dass wir es sind, die entscheiden was agil ist und was nicht, schliesslich sind wir zertifizierte Agile Mindsetter.

Auch weitere gefährliche Missverständnisse haben wir in dem Zusammenhang korrigieren können. Stellen Sie sich vor, die wollten unser agiles Budget nehmen um ihre Leute in Mob-Programming zu trainieren. Mobbing, das geht doch gar nicht. Wir haben das sofort untersagt und stattdessen alle auf verpflichtende Kurse zu gewaltfreier Kommunikation geschickt. War auch höchste Zeit, denn einige Entwickler sind ausfällig geworden als sie das gehört haben. Die mussten direkt nochmal teilnehmen.

Einen Volltreffer gelandet haben wir bei der Besetzung der Stelle des Agile Coach. Den alten, den die IT irgendwoher besorgt hatte, haben wir weggeschickt, der hatte nur ganz merkwürdige Ideen. Beyond Budgeting und Lean Governance zum Beispiel, wir glauben, der hat nur mit dem Zufallsgenerator Wörter zusammengewürfelt. Sein Nachfolger dagegen hat verstanden worum es geht: er hat allen Mitarbeitern eine Spiral Dynamics-Farbe zugeordnet. Endlich Klarheit, wer das richtige Mindset hat und wer nicht!

Basierend darauf haben wir dann die agile Transition in der Belegschaft durchgeführt, mit dem Ziel ein einheitliches agiles Mindset zu bekommen. Allen Kollegen bei denen die Farben Beige, Purpur, Rot, Blau und Orange diagnostiziert wurden, haben wir Tetralemma-Aufstellungen und AQAL-Coachings als Entwicklungsziele gesetzt, damit sie sich aus ihren eigenen geistigen Beschränkungen befreien können. Und glauben Sie uns, die Coaches die wir dafür geholt haben waren nicht billig.

Das Ergebnis war dann auch erstmal überragend. Jedem Mitarbeiter konnte man die Worte "agil ist ..." zurufen und sie wurden wie aus der Pistole geschossen mit "... ein Mindset" beantwortet. Bei Problemen jeglicher Art wurde immer zuerst über die Einstellung der Beteiligten geredet. Und die Querulanten, die das alles bis zum Schluss nicht mitmachen wollten, haben dann irgendwann gekündigt und machen jetzt ihr DevOps, CI, TDD, XP oder was die sonst noch fälschlicherweise für agil halten woanders.

Sie sehen also, wir haben nicht nur alles dafür getan um ein agiles Mindset zu bekommen, wir haben es sogar erfolgreich geschafft, die Agile Mindsetter-Zertifikate sind der Beweis. Aber jetzt kommts: trotzdem sind Arbeitsgeschwindigkeit, Produktqualität, Reaktionsfähigkeit oder Kundenzufriedenheit nicht nach oben gegangen sondern nach unten. Wir müssen deshalb die unbequeme Wahrheit aussprechen: Wir haben es mit dem agilen Mindset versucht, aber es funktioniert nicht. Untertanenkultur war doch besser.

[/ironie off]

Bevor sich jemand aufregt - natürlich ist alles was weiter oben steht populistisch, polemisch und überspitzt. Aber: alles was ich dort aufgeschrieben habe, habe ich irgendwann mal im Rahmen verschiedener agiler Transition erlebt, sogar die Enneagram-Tätowierung und den zertifizierten Agile Mindsetter. Ein Grossteil des angeblichen Veränderungswiderstands in Belegschaften lässt sich damit erklären, dass ihnen derartige Esoterik als Bestandteil von Agilität verkauft wird.

Institutionelles Gedächtnis

Manchmal hilft es, Dinge mit einem gewissen Abstand zu betrachten. In diesem Sinn wirft die britische Zeitung The Guardian gerade einen Blick zurück auf die Regierungszeit der ehemaligen Premierministerin Liz Truss, die nur 49 Tage dauerte. Eine der interessanteren Diagnosen aus diesem Text ist, dass Truss unter anderem deshalb scheiterte, weil sie durch zu viele Stellen-Neubesetzungen das institutionelle Gedächtnis der eigenen Verwaltung zerstörte. Was hat es damit auf sich?

Das institutionelle Gedächtnis ist eine Unter- und Sonderform des kollektiven Gedächtnisses und bezeichnet das gesammelte Wissen und die Summe der Erfahrungen einer organisierten Gruppe von Menschen, insbesondere in einer formalisierten Institution wie z. B. einer Behörde oder Firma. Es ist vor allem im Zusammenhang mit informellen Strukturen und Prozessen wichtig, also solchen, die nicht offiziell festgelegt und schriftlich festgehalten wurden.

Zu den typischen Informationen aus dem institutionellen Gedächtnis gehört, welche Inhalte wo abgelegt sind, welche Vorhaben in der Vergangenheit unternommen wurden (und wie), welche Mitarbeiter mit welchen anderen bekannt und vernetzt sind, wer bereits mit welchem Themengebiet zu tun hatte und wer besser oder schlechter mit bestimmten Rahmenbedingungen klarkommt (z.B. mit Stress, nicht-muttersprachlicher Kommunikation oder besonders hoher, bzw. niedriger Formalisierung).

Dieses Wissen kann für das Funktionieren einer Organisation entscheidend sein, da seine Träger in der Lage sind zu erkennen, an welcher Stelle welche Vorhaben mit geringen Reibungsverlusten umgesetzt werden können und an welchen Stellen mit Missverständnissen, Zusatzaufwänden, Ineffektivität oder Widerständen zu rechnen wäre. Wichtig dabei ist, dass bei einer rein formalen Betrachtung diese Unterschiede nicht wahrnehmbar wären, da sie sich nur aus der "Organisationsgeschichte" ergeben.

Vor allem nach Management- oder Regierungswechseln kann ein fehlendes institutionelles Gedächtnis von neuen Mitarbeitern dazu führen, dass die Ideen der neuen Führungsebene nur unter grossen Schwierigkeiten umgesetzt werden können, weshalb fast immer versucht wird, einen Teil der bisherigen Mitarbeiter zu übernehmen und einzubinden, selbst dann wenn man sich deren Loyalität nicht vollkommen sicher sein kann (ein bekanntes und besonders kontoverses Beispiel wäre dieses hier).

Für das, was passieren kann, wenn man nach einem Management-Wechsel versucht weitgehend ohne die bisherigen Mitarbeiter (und damit auch ohne deren nicht-verschriftlichtes Wissen) zu arbeiten, kann die zu Beginn erwähnte kurze Regierungszeit von Liz Truss als (abschreckendes) Beispiel gelten: dem von ihr mitgebrachten neue Regierungsteam fehlte das institutionelles Gedächtnis in einem derartigen Ausmass, dass es in vielen Bereichen handlungsunfähig war.

An overwhelming number of the senior figures brought into the administration had limited experience running a Whitehall department, let alone the country. The entire legislative affairs team – in charge of drafting and timetabling bills – was replaced too. “It was like she’d stripped off all the wallpaper, then the paint and floorboards too. There was basically zero institutional memory left,” one Truss-era cabinet minister said.

The Guardian, The inside story of the unravelling of Liz Truss’s premiership

Wie immer gilt natürlich auch hier, dass es nicht nur einen Weg gibt, mit derartigen Situationen umzugehen. Statt Teile des bisherigen Teams zu übernehmen kann man z.B. auch Mitarbeiter-Interviews, Unterlagen-Recherche und andere Arten der "Geschichtsforschung" durchführen um ein neues institutionelles Gedächtnis aufzubauen. Wenn das geplant ist sollte man allerdings ausreichend Zeit einplanen und nicht erwarten sofort uneingeschränkt handlungsfähig zu sein.

Podcasting (II)

Bild: Unsplash / Jonathan Farber - Lizenz

Wer wissen möchte was ich denke und wie ich schreibe, kann das auf dieser Zeite in ausreichendem Ausmass erfahren. Mehrere hundert Texte sind über die Jahre zusammengekommen, das sollte für einen halbwegs soliden Eindruck reichen. Auch wie ich aussehe ist mittlerweile klar, auf mehrfachen Wunsch habe ich auch ein Bild hochgeladen. Zuletzt kann man mich auch hören, ich bin über die Jahre in dem einen oder anderen Podcast zu Gast gewesen. Hier sind die beiden neuesten.

Bei den Produktwerkern war ich bereits vor einigen Monaten zu Gast, und das sogar schon zum zweiten mal. Das Thema war Product Operations, also der Ansatz, der Produktmanagern und Product Ownern den Zugang zu bereits im Unternehmen vorhandenem Prozess- und Kundenwissen erleichtern und ihnen Routinetätigkeiten abnehmen soll. Meiner Meinung nach immer noch der  Trend, dessen Überschwappen nach Deutschlang nicht schnell genug gehen kann.

Anhören bei: Apple Podcasts, Google Podcasts, Spotify

Ein anderes, eher klassisches Thema habe ich vor kurzem mit Harald Wild im Agile Focal Point Podcast besprochen. Scrum ist (mit unterschiedlich guter Umsetzung) bis heute das dominante agile Framework. Wer sich über Agilität unterhalten will kommt daher nicht daran vorbei auch regelmässig über Scrum zu reden. Das Bemerkenswerte daran: auch nach über 30 Jahren ist es noch nicht so, dass das Thema erledigt wäre. Ein Dauerbrenner.

Episode #7: Felix Stein – Scrum oder Scream?

Anhören bei: Apple Podcasts, Google Podcasts, Spotify

Die nächsten Podcasts sind übrigens bereits in der Pipeline, mehr dazu bei Gelegenheit.