Eine kurze Typologie der agilen Skalierungsframeworks

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.

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)

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.

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

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.

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.

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?

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

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

Grafik: Wikimedia Commons / Disertel - CC BY-SA 4.0

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

Kommentierte Links (CIII)

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.

Thomas Michl: Agile Skalierung mit Kanban | Ein Überblick über die drei Skalierungsdimensionen

Nachdem der "Agile Michl" regelmässig in seinem Blog auf mich verweist, freut es mich, das es heute auch mal in die andere Richtung gehen kann. Das Thema mit dem er sich befasst ist eines, das gleichermassen selten wie wichtig ist: die Skalierung von Kanban. Diese kann auf drei Arten stattfinden: durch Verlängerung des Kanban-Systems entlang des Wertstroms, durch Koppelung mehrerer Systeme oder durch Verbindung verschiedener Flughöhen (Granularitäts-Ebenen) miteinander. Während ich diese Unterscheidung schon kannte, ist die griffige Benennung für mich neu - Skalierung in die Breite, in die Tiefe und in die Höhe. Diese Begriffe werde ich von jetzt an auch benutzen.

Jason Yip: Thoughts on role expectations on empowered product teams

"Schlecht definierte Rollen erhöhen die Notwendigkeit von Kommunikation und führen zu mehr Zeit in Meetings." Mit diesem direkt zu Beginn angeführten Zitat macht Jason Yip sehr deutlich, warum Rollenklärung für agil arbeitende Teams wichtig ist. Gleichzeitig ist ihm aber auch bewusst, dass er sich damit in einem Spannungsfeld befindet, denn zu detailliert festgelegte Rollen nehmen Flexibilität weg und können für Bürokratie sorgen. Den richtigen Punkt in der Mitte zu finden (und ununterbochen neu auszuhandeln) gehört zu den wesentlichen Erfolgsfaktoren. Yip fügt dem Ganzen noch eine weitere Dimension hinzu, indem er zwischen individuellen und kollektiven Verantwortlichkeiten und Erwartungen differenziert. Auch das ist in agil arbeitenden Teams immer wieder ein Thema.

Tendayi Viki: It’s more fun to be a pirate in the Navy

Von Tendayi Vikis gibt es das Buch Pirates in the Navy, das ich sehr empfehlen kann (und zu dem ich vor einiger Zeit eine Rezension geschrieben habe). Die titelgebende Kernaussage ist die, dass überzeugte Freigeister (→ Piraten) sich immer schwer tun werden, wenn sie in klar strukturierten Organisationen (→ der Marine) arbeiten sollen. Nicht nur deshalb weil sie gegen deren Regeln verstossen, sondern auch weil sie durch das Umgehen offizieller Prozesse für die anderen, die nur im Rahmen dieser Prozesse arbeiten, unsichtbar werden. In diesem Blogpost baut Viki die Piraten-Analogie weiter aus und empfiehlt, sich eher an den Freibeutern zu orientieren, die zwar autonom agierten, das aber durch eine offizielle Lizenz erlaubt bekommen hatten, wodurch sie legal und sichtbar vorgehen konnten.

Michael Küsters: Leading by Absence

Wer schon einmal dabei war, wenn bisher von einem Manager geführte Teams plötzlich selbstorganisiert sein sollten, wird vermutlich diese Situation kennen: obwohl er weder führen soll noch will orientieren sich die Teammitglieder weiterhin an ihm, berichten was sie tun und fragen um Erlaubnisse oder Freigaben. Dort wo derartige Phänomene auftreten kann es sinnvoll sein, dass die bisherige Führungskraft sich eine gewisse Zeit lang vom Team fernhält, so dass dieses gar nicht anders kann als sich an eigene Verantwortung und eigene Entscheidungen zu gewöhnen. Die von Michael Küsters definierte Begrifflichkeit Leading by Absence trifft diese leicht paradoxe Situation recht gut. Dadurch, dass man fernbleibt führt man die bisherigen Untergebenen in die Selbstorganisation.

Mike Cohn: Top 7 Ways to Engage Stakeholders in Sprint Reviews

Zuletzt ein eher "handwerkliches" Thema. Die Klagen über Stakeholder, die sich nicht dafür interessieren was ihre Scrum Teams im letzten Sprint fertiggestellt haben, ist vermutlich schon so alt wie die Idee der Sprint Reviews selbst. Sinnvoller als sich zu beschweren ist es aber, die Termine so zu gestalten, dass die Stakeholder von sich aus gerne kommen. Einige Ideen dazu wie das gehen kann hat Mike Cohn hier aufgeschrieben. Sie erscheinen banal, würden aber in vielen Fällen zu deutlichen Verbesserungen führen.