On Lean and Agility

Grafik: Pixabay / GDJ - Lizenz

Sobald irgendwo mehrere agile Teams zusammenarbeiten sollen kommen sie ins Spiel: agile Skalierungsframeworks. Mittlerweile gibt es eine ganze Reuhe von ihnen, die alle ihre Fans und Skeptiker haben. Eine Frage wird dabei aber erstaunlich selten gestellt - gibt es Strukturmerkmale, anhand derer man sie grundlegenden Mustern zuordnen kann? Für ein Buchprojekt habe ich versucht, eine entsprechende Übersicht zu erstellen, die ich auch hier teilen möchte.

Wichtig für das Verständnis ist dabei, dass die einzelnen Vorgehensmodelle hier nicht im Detail vorgestellt werden sollen. Es geht darum hervorzuheben, was sie von den anderen unterscheidet und welche ihrer Elemente wesensbestimmend sind. Detailbeschreibungen zu jedem einzelnen gibt es an verschiedenen anderen Stellen, das hier ist ein Versuch einer grundlegenden Gruppierung, die einen Einstieg in das Thema der agilen Skalierung erleichtern soll.

Scrum-Skalierungsframeworks

Beginnen wir mit den Minimalisten. Die Scrum-Skalierungsframeworks LeSS (Large Scale Scrum) und Nexus haben den Anspruch, Scrum zu skalieren ohne ihm Meetings und Rollen hinzuzufügen. Ihre Grundidee: mehrere Scrum Teams teilen sich einen Product Owner, ein Backlog und eine Definition of Done und haben gemeinsame Plannings und Reviews, führen die dazwischenliegenden Sprints aber getrennt durch. Sehr unbürokratisch, für den Product Owner aber ggf. sehr fordernd.

Hierarchische Skalierungsframeworks

Im deutlichen Kontrast dazu führen hierarchische Skalierungsframeworks wie Scaled Agile Framework (SAFe) und Scrum@Scale oberhalb der Scrum Teams neue Hierarchieebenen ein, SAFe etwa den Product Manager und den Release Train Engineer, Scrum@Scale den Chief Product Owner und den Scrum of Scrums Master [sic]. Bei grösseren Vorhaben ist das nochmal erweiterbar, für weitere Hierarchieebenen können nochmal weitere Rollen geschaffen werden.

Dynamische / Fluide Skalierungsframeworks

Dynamische Ansätze wie FAST (Fluid Agile Scaling Technology) und Unfix stellen die Idee des crossfunktionalen und autonomen Teams in den Mittelpunkt. Bei grossen oder komplexen Produkten kann es sein, dass eine solche Einheit deutlich mehr als die üblichen zehn Personen umfassen muss. Um trotz dieser Grösse agil bleiben zu können ist es vorgesehen, dass sich innerhalb dieser stabilen Einheiten Untereinheiten je nach Bedarf bilden und wieder auflösen können. Quasi ein agiles Organigramm.

Kanban-Skalierungsframeworks

Aufgrund der "Open Source-Natur" von Kanban sind die Skalierungs-Möglichkeiten in diesem Bereich sehr wenig formalisiert, bzw. sehr individuell. Die grundlegende Idee ist aber eine Optimierung des Arbeitsflusses oder Wertstroms. Skalierung bedeutet in diesem Sinn, dass Umfang oder Anfangs- und Endpunkt des Wertstroms immer weiter definiert werden, etwa durch Einbeziehung von Zulieferern oder Parallel-Fertigungen. Bestehende Rollen und Hierarchien bleiben dabei zunächst unverändert.

Kommunikationsorientierte Skalierungsframeworks

Ähnlich wie bei den Kanban-Skalierungsframeworks verzichten kommunikationsorientierte Ansätze wie Flight Levels oder Open Space Agility zunächst auf neue Rollen und Strukturen. Stattdessen werden übergreifende Abhängigkeiten für alle sichtbar visualisiert (Flight Levels) oder in Grossgruppen-Formaten regelmässig mit allen Beteiligten besprochen (Open Space Agility). Basierend darauf können dann Kommunikation und Zusammenarbeit dort stattfinden wo es Sinn macht.

Sonstige Skalierungsframeworks

Über die gerade gennten agilen Skalierungsansätze hinaus gibt es auch weitere die immer wieder genannt werden, u. a. das so genannte "Spotify Model" und organisationsweite Objectives and Key Results (OKRs). Bei ihnen handelt es sich aber nicht um agile Skalierung im eigentlichen Sinn, sondern eher um eine kreative Neubenennung klassischer Organisationsprinzipien (Spotify = Matrix-Organisation, organisationsweite OKRs = Zielkaskadierung). Auch ok, nur ein anderes Thema als das hier.

Soviel zur Übersicht - aber was kann man jetzt mit ihr machen?

Eine guter Einsatzmöglichkeit ist, vor (!) dem Beginn einer wie auch immer gearteten agilen Skalierung zu überprüfen, welche dieser Grundmuster in der eigenen Organisation vermittelbar wären. Sind beispielsweise Scrum oder Kanban auf Teamebene gesetzt? Dann machen diese Ansätze vermutlich auch in der Skalierung Sinn. Wird Wert auf Hierarchien gelegt? Dann passen SAFe und Scrum@Scale. Soll maximale Flexibilität möglich sein? Dann passen die dynamischen Skalierungsframeworks besser.

Was durch ein derartiges Vorgehen möglich wird, ist eine Lösung die zur Aufgabenstellung passt, statt einer Lösung an die die Aufgabenstellung angepasst werden muss. Denn so merkwürdig es klingt - Variante zwei ist zur Zeit noch verbreiteter als Variante eins. Das umzudrehen kann nur im Interesse aller Beteiligten sein.

Bild: Unsplash / Fabio Bracht - Lizenz

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

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

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?

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

Bild: Ideogram

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.

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.

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.

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

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.

Grafik: Dall-E / Bing Image Creator

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.