Freitag, 14. Februar 2025

Flooding the Zone

Wer die politischen Ereignisse in den Vereinigten Staaten von Amerika verfolgt, wird mit hoher Wahrscheinlichkeit früher oder später an einem merkwürdigen Slogan vorbeikommen: Flooding the Zone (with Shit). Dahinter verbirgt sich ein Vorgehen, das genauso obszön ist, wie es sich anhört, das man aber auch in vielen Veränderungsvorhaben beobachten kann. Sobald man es sich bewusst gemacht hat, erkennt man es an vielen Stellen wieder.


Popularisiert worden ist das Flooding the Zone von Steve Bannon, dem ehemaligen Chief Strategist (obersten Berater) von Donald Trump. Angelehnt an eine Taktik aus Mannschaftssportarten, in denen darunter Überzahlspiel verstanden wird, erklärte er es zum Ziel, eine Diskussion derartig mit Themen zu überladen, dass es der Gegenseite nicht mehr möglich ist, sich auf eines davon zu konzentrieren um es auszudiskutieren oder zu widerlegen.


Da das Change Management in grossen Organisationen wesentlich aus dem Erklären, Hinterfragen und Ausdiskutieren von Veränderungsmassnahmen besteht, sind die Einsatzmöglichkeiten des Flooding the Zone in diesem Bereich offensichtlich. Differenziert betrachtet treten dabei verschiedene Dimensionen auf. Zum einen ist es von Bedeutung, mit welchem Ziel die Flutung stattfindet, des Weiteren womit und zuletzt ob es sich dabei um eine taktische oder eine strategische Massnahme handelt.


Das Ziel des Floodings kann sowohl das Vorantreiben als auch das Behindern von Veränderungen sein. Im ersten Fall findet es statt indem immer neue Ideen und Initiativen angekündigt oder thematisiert werden, im zweiten indem immer neue Bedenken, Argumente und Fragen gegen laufende oder kommende Vorhaben aufgeworfen werden. Die Absicht in beiden Fällen: die andere Seite soll aus dem Konzept gebracht werden, ständig reagieren müssen und dadurch sprunghaft und konfus erscheinen.


Bei der Frage womit die Überflutung stattfindet gibt es erneut zwei Möglichkeiten. Entweder mit realen (ggf. aber kleinteiligen oder redundanten) Bedenken, beliebt sind dabei solche, die einen (angeblich) drohenden Verlust von Qualität, Verlässlichkeit oder Rechtssicherheit zum Gegenstand haben. Alternativ kann man das tun, was Bannon Flooding the Zone with Shit nannte - absurd überspitzte, unsinnige oder falsche Argumente vorbringen, nur mit dem Ziel, der anderen Seite die Lust an dem Thema zu nehmen.


Ob ein Flooding taktischer oder strategischer Natur ist, entscheidet sich schliesslich am jeweiligen Zeit-Horizont. Eine taktische Überflutung findet kurzfristig im Rahmen eines Gesprächs, Meetings oder Mail-Verkehrs statt und hat das Ziel, sie ohne Ergebnis enden zu lassen. Eine strategische Überflutung findet langfristig und kontinuierlich statt und meistens auch gleichzeitig auf verschiedenen Hierarchie- oder Granularitätsebenen und in verschiedenen Organisationseinheiten. Ziel ist eine allgemeine Konfusion.


Gegenmassnahmen gegen das Flooding the Zone sind anstrengend aber möglich. Naheliegend ist es, dieses Verhalten anzusprechen (und damit wahrnehmbar zu machen), auf seine Destruktivität hinzuweisen und darum bitten, es zu unterlassen. Findet es dann trotzdem weiter statt greift die alte Weisheit, dass die Kultur eines Unternehmens vom schlechtesten Verhalten definiert wird, das vom Management zugelassen wird. Mit anderen Worten - es wird zu einem Führungs- oder Disziplinar-Thema.


Soll das Thema Team- oder Gruppen-intern gelöst werden, sind gemeinsame Vereinbarungen der beste Weg. Die können zum Beispiel darin bestehen, für Bedenken oder Änderungs-Anträge eigene Termine oder Agenda-Punkte zu schaffen und die anderen davon freizuhalten, oder zu Beginn eines Meetings die Agenda gemeinsam zu priorisieren (z.B. durch Dot-Voting), wodurch destruktive Agendapunkte gar nicht erst diskutiert werden, oder erst dann wenn die konstruktiven bereits geklärt sind.


Bei all diesen Überlegungen sollte man aber eine weitere nicht vergessen - nicht jeder, der regelmässig eine andere Meinung hat, betreibt gerade Flooding the Zone. Es kann auch sein, dass sich mit der Zeit quer durch eine gesamte  Organisation so viel dysfunktionales Verhalten herausgebildet hat, dass alle anderen mittlerweile abgestumpft sind und es nicht mehr wahrnehmen. Herauszufinden zu können was davon gerade der Fall ist, ist dann die entscheidende Kunst, an deren Beherrschung man arbeiten sollte.

Dienstag, 11. Februar 2025

10 Jahre

Das hier ist das zweite sich surreal anfühlende Jubiläum, das ich in relativ kurzer Zeit feiern darf. Vor etwa einem halben Jahr habe ich auf lean-agility.de den tausendsten Eintrag veröffentlicht, und ich war leicht erschlagen von dieser Menge. Heute geht es weiter - vor genau zehn Jahren habe ich mit Hallo Welt den ersten dieser Einträge veröffentlicht, und wieder fühle ich mich erschlagen, diesesmal von der Länge der seitdem vergangenen Zeit - ein Jahrzehnt!


"Jedem Anfang wohnt ein Zauber inne, so auch diesem hier. Mal sehen wieviel Zeit ich für diese kleine Internetpräsenz hier aufbringen werde." waren meine ersten Worte die ich hier geschrieben habe, und tatsächlich hatte ich Zweifel daran, dass ich ein Jahr lang in der Lage sein würde, regelmässig etwas zu veröffentlichen. Jetzt sind zehn Jahre vorbei, und ich habe im Schnitt zwei mal pro Woche auf den Publish-Button gdrückt. Wie gesagt, insgesamt mehr als tausend mal.


Im tausedsten Artikel habe ich geschrieben, dass mich im Rückblick fast am meisten erstaunt, dass mir nicht irgendwann die Themen ausgegangen sind, mittlerweile kann ich sagen, wie ich das geschafft habe. Sobald ich ein Thema interessant oder amüsant finde (was oft genug vorkommt) speichere ich es bewusst oder unbewusst im Kopf ab und mache bei Gelegenheit einen ersten, stichpunktartigen Entwurf. Von denen fliegen im CMS dieser Seite erstaunlich viele herum - zur Zeit sind es ca. 80.


Und sobald ich irgendwann etwas Leerlauf habe, Zeit totschlagen oder mich ablenken will, habe ich etwas zu tun - ich schaue, was alles da ist, und wenn mir zu einem Thema etwas einfällt schreibe ich einige Sätze dazu. Aus diesen kurzen Kreativ-Phasen (die manchmal nur wenige Minuten lang sind) entsteht dann nach und nach mein Content (natürlich gibt es auch Momente, in denen ich spontan einen ganzen Text herunterschreibe, aber das ist im Vergleich seltener der Fall).


Es gibt in der Psychologie die Theorie, dass das Aufschreiben von Gedanken dazu führt, dass man diese besser strukturieren, einordnen, verarbeiten und verinnerlichen kann. Wenn das stimmen sollte, habe ich mir seit 2015 mit dieser Website ein Werkzeug geschaffen, dass mir zu einem differenzierten und reflektierten Blick auf meine Arbeitswelt verhilft. Nicht das schlechteste für jemaden, zu dessen beruflichem Alltag es gehört, in technischen und sozialen Systemen Muster und Dynamiken zu erkennen.


In gewisser Weise ist der Zauber des Anfangs geblieben. Mal sehen wie lange noch (zur Zeit ist aber noch kein Ende absehbar).

Donnerstag, 6. Februar 2025

The Cult of the agile Amateur

Von Zeit zu Zeit lohnt es sich, Bücher heranzuziehen die zwar zu Zeiten des Aufschwungs der agilen Methoden verfasst wurden, sich aber nicht mit ihnen im engeren Sinn befassen, sondern breitere gesellschaftliche Trends zum Gegenstand haben. Da die agile Bewegung Teil der Gesellschaft ist, bietet diese Art der Betrachtung einen interessanten Blickwinkel: ist auch sie von diesen Trends beeinflusst worden, und wenn ja wie? Ein Buch mit dem man derartig vorgehen kann ist The Cult of the Amateur.


Verfasst wurde es im Jahr 2007 vom britisch-amerikanischen Unternehmer und Schriftsteller Andrew Keen. Vordergründig richtete es sich gegen das in dieser Zeit aufkommende partizipative Internet, damals Web 2.0 genannt (heute würde man von User generated Content sprechen). Auf einer grösseren Ebene handelte es sich aber gleichzeitig um eine harte Kritik an der zu dieser Zeit häufigen Verklärung unwissenschaftlicher und autodidaktischer, dafür aber meinungsstarker Diskussionsteilnehmer.


Zum Kontext: im ersten Jahrzehnt des dritten Jahrtausends ist es zu einer nie zuvor dagewesenen Demokratisierung des Zugangs einzelner Personen zur Öffentlichkeit gekommen. Services wie Wordpress, Youtube, Twitter, Facebook und Wikipedia erlaubten es jedem Menschen, Beiträge zu jedem beliebigen Thema zu veröffentlichen und damit potentiell den allgemeinen Diskurs zu diesem Thema mitzugestalten. Aus demokratietheoretischer Sicht eine grossartige Entwicklung.


Was Keen an dieser Entwicklung kritisierte, war, dass durch den Wegfall der bisherigen Verlags- und Sender-Oligopole nicht nur die Zugangsbarrieren wegfielen, sondern auch die mit ihnen verbundenen Qualitätssicherungs-Mechanismen. Während vorher vorwiegend Inhalte eine grosse Öffentlichkeit erreichten, die gut begründet, in sich konsistent und überprüfbar waren, verschob sich das plötzlich zu solchen, die auf starken Einzelmeinungen zu aktuellen Themen basierten.


Und an dieser Stelle kommen wir zurück zur agilen Bewegung. Selbst wenn viele der damals noch neuen agilen Frameworks basierend auf Praxiserfahrungen entstanden waren, waren die jeweiligen Entstehungsbedingungen so überschaubar und einzelfallspezifisch, dass sich nicht klar sagen liess, was Kausalität war und was Korrelation. Um ein bekanntes Beispiel zu nennen - Extreme Programming (XP) basierte ursprünglich auf den Erfahrungen eines einzigen Teams, das nur wenige Jahre lang bestand.1


Dass dieser anfangs eher überschaubare Anwendungsfall es zeitweise schaffte, zum populärsten agilen Famework zu werden,2 lag wesentlich an den zuvor erwähnten demokratisierten Zugängen zur Öffentlichkeit, im Fall von XP in Form von Wikis wie wiki.c2.com oder wiki.org, in denen Praktiker und Enthusiasten in selbst gewähltem Umfang und Detailgrad Inhalte veröffentlichen konnten, die weltweit von jedem Inhaber eines internetfähigen Computers gelesen werden konnten.3


In diesem Fall hat die Geschichte zwar ein Happy End, da sich XP mit der Zeit in der Praxis bewährte, in anderen Fällen war der Ausgang aber nicht ganz so gut - dass viele Versuche agile Arbeitsweisen einzuführen kläglich gescheitert sind, liegt ganz wesentlich daran, dass das dafür gewählte Vorgehen lediglich auf starken Meinungen und anekdotischer Evidenz beruhten, verfälscht durch Survivor Biases, Hindsight Biases und ähnliche Phänomene.


Zu den klassischen, immer wieder auftretenden Fehlern gehören dabei Über-Simplifizierung ("man muss nur alle Mitarbeiter schulen"), Personalisierung ("die Personen X, Y und Z wollen sich nicht ändern"), Blaupausen-Gläubigkeit ("Spotify hat das auch so gemacht"), Confirmation Bias ("ich habe schon immer gesagt: einfach machen! Endlich sehen das jetzt alle so.") und Ausblendung von Zusammenhängen ("warum reden wir hier über Budgetierung, wir wollten doch über die agile Transformation sprechen").


Dabei ist keiner dieser Fehler unvermeidbar, in der psychologischen und betriebswirtschaftlichen Forschung und Literatur werden sie seit über hundert Jahren behandelt, einschliesslich der Möglichkeiten sie zu erkennen und zu verhindern. Wer eine wissenschaftliche oder praktische Ausbildung im Produkt- oder Projektmanagement durchlaufen hat, wird sie mit grosser Wahrscheinlichkeit vermeiden oder abschwächen können.4


Dass eine Kenntnis dieser Forschungsergebnisse und Fachliteraturen in agilen Transitionenzu selten erwartet wird, liegt schliesslich an etwas, das man in Anlehnung an Keen als "Cult of the agile Amateur" bezeichnen könnte: der Verklärung unwissenschaftlicher und autodidaktischer, dafür aber meinungsstarker Scrum Master und Agile Coaches als "Organisationsrebellen" oder Inhaber eines "agilen Mindsets", deren Expertise keiner Valisierung bedarf.


Um Missverständnisse zu vermeiden: dieser Cult of the agile Amateur ist nicht in den verschiedenen agilen Frameworks selbst verankert, sondern ist eher aus den oben erwähnten Besonderheiten der Entstehungszeit zu erklären. Und überall dort wo agile Transitionen langfristig erfolgreich gewesen sind, ist er entweder von Anfang an vermieden worden oder er wurde mit der Zeit erkannt und nach und nach eingedämmt und beseitigt.


Wie eine solche Gegenbewegung vor sich gehen kann ist dann wieder von Einzelfall zu Einzelfall unterschiedlich, so dass es dafür kein Patentrezept gibt (ein empirisch-analytisches Vorgehen ist aber ein guter Startpunkt). Lediglich eines lässt sich mit Sicherheit sagen: was nur in den allerseltensten Fällen helfen wird sind agile Zertifizierungen.



1Zur Klarstellung: XP ist grossartig, aber das wissen wir heute, damals liess sich das noch nicht absehen
2Um das Jahr 2000, es wurde erst später von Scrum überholt
3Wir können uns heute nicht mehr vorstellen, wie revolutionär das damals war
4Natürlich treten dafür andere Risiken auf, z.B. Methodismus

Montag, 3. Februar 2025

Larman's Law (V)

Bild: Pexels / Tara Winstead - Lizenz

Mit der Zeit haben sich viele Menschen Gedanken über die ungeschriebenen Gesetze der Organisationsentwicklung gemacht und versucht sie (auf manchmal seriöse, manchmal aber auch eher zynische Art) auf Papier zu bringen. Besonders produktiv war dabei Craig Larman, der Erfinder von LeSS, der insgesamt fünf Gesetze verfasst hat, die er Larman's Laws of Organizational Behavior genannt hat. Heute soll es hier um das Fünfte von ihnen gehen. Es lautet:


In large established orgs culture follows structure. And in tiny young orgs, structure follows culture.


Zum Hintergrund: Larman verfasste dieses Gesetz als Reaktion auf die in der agilen Community verbreitete Ansicht, dass Veränderungsvorhaben grundsätzlich  damit beginnen müssten, die Kultur zu verändern. Da diese bestimmend für alles weitere wäre, würden alle weiteren Veränderungen mehr oder weniger von selbst folgen. Diese Ansicht hält er (zumindest in grösseren Organisationen) für nicht zutreffend und realitätsfern.


Die von Larman (und vielen Anderen) beobachtete Realität ist eine andere. In ihr ist die Unternehmenskultur (also die Summe aller informellen Erwartungen, Glaubenssätze, Deutungsmuster, etc.) stark von der Formalstruktur beeinfusst, bzw. eine Reaktion auf sie (zur Formalstruktur gehören Regel, Hierarchien, Anweisungen, o.A.). Ein einfaches Beispiel: in einem Unternehmen in dem alles zentral und geheim entschieden wird, wird es kaum zu einer partizipativen Mitmach-Kultur kommen.


In einem derartigen Umfeld haben Veränderungsvorhaben daher eine höhere Erfolgswahrscheinlichkeit, wenn sie mit strukturellen Veränderungen beginnen, z.B. mit der Delegation von Entscheidungen auf untere Hierarchieebenen, wodurch eine passive Gehorsams-Kultur dort nicht mehr möglich ist. Ob die dadurch herbeigeführten Kulturveränderungen die erhofften sind oder ob und wie nachgesteuert werden muss, ist dann nochmal ein separates Thema, das weit in das Change Management hineinführt.


Nun zum umgekehrten Fall: es gibt einige Firmen in denen es doch so ist, dass die Unternehmenskultur die Unternehmensstruktur definiert. Wie kann das sein? Larman gibt die Antwort, indem er darauf verweist, dass das vor allem in kleinen und jungen Organisationen gegeben ist. In derartigen Umgebungen sind Strukturen meistens nur rudimentär vorhanden (da noch nicht nötig) und verfestigen sich erst mit der Zeit. Diese Verfestigung bildet dann in der Regel die Kultur ab.


Diese Unterscheidung lohnt es, im Hinterkopf behalten zu werden: in grossen und alten Unternehmen überschreibt die Struktur die Kultur, in kleinen und jungen Unternehmen überschreibt die Kultur die Struktur. Wie immer mit Abstufungen und Ausnahmen, aber eine brauchbare Fausregel, auf die man den Beginn eines Veränderungsvorhaben aufsetzten kann. Und umgekehrt gibt sie einem eine klare Idee mit, wie man es besser nicht versuchen sollte.

Freitag, 31. Januar 2025

Kommentierte Links (CXXIII)

Grafik: Pixabay / Brian Penny - 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.

David Pereira: The Refactoring Guide for PMs Tired of Endless Tech Discussions

Eine der klassischen Herausforderungen, an denen (nicht nur agile) Entwicklungsteams scheitern, ist die Erklärung von Refactoring für Menschen ohne IT-Hintergrund. Wer mal wieder in dieser Situation ist, kann sich an diesen Artikel von David Pereira halten. In ihm wird nicht nur das Konzept erklärt, sondern auch warum es wichtig ist, wie mayn es falsch machen kann, wie man es richtig machen kann, wann man es machen sollte und was typische Formen von Refactoring sind.

Jeff Gothelf: OKRs for Organizational Agility

Auf die Gefahr hin, versehentlich in die Falle von Maslows Hammer zu laufen - man kann Objectives und Key Results (OKRs) eigentlich für so gut wie alles benutzen. Jeff Gothelf zeigt hier ein eher selten verwandtes Einsatzgebiet auf: die Verwendung von OKRs für agile Transitionen (oder wie er es nennt, organisatorische Agilität). Im Wesentlichen geht es dabei darum, Reaktions- und Durchlaufzeiten messbar zu verkürzen. Schlicht, aber wirkungsvoll.

Erik de Bos: Using the Flow Channel to Measure Team Effectiveness

Neben dem Durchfluss von zu erledigenden Aufgaben durch ein Verarbeitungssystem hat der Begriff Flow im Arbeitskontext eine zweite Bedeutung: den idealen Zustand, in dem eine Person oder ein Team werder überfordert noch unterfordert ist, und daher hochmotiviert und leistungsbereit. Erik de Bos differenziert das mit Hilfe des so genannten Flow Channel aus, in dem ein Team versuchen kann, dauerhaft zu bleiben, um optimale Ergebnisse erbringen zu können.

Marty Cagan: The Product Model and Agile

Dieser Blogpost hier ist durchaus erstaunlich, da sein Verfasser, Produktmanagement-Thought Leader Marty Cagan, über lange Zeit dafür bekannt war, öffentlich schlecht über agile Rollen und Frameworks zu sprechen. Irgendetwas scheint seine Meinung geändert zu haben, denn auf einmal findet er es nicht nur grundsätzlich ok wenn agil gearbeitet wird, er erkennt sogar an, dass Agile Coaches dazu einen wertvollen Beitrag leisten können - was er allerdings vor allem im Delivery-Bereich sieht.

Sebastian Sigl: High-Performing Teams Focus On These 4 Areas to Remain Successful

Zugegeben, Sebastian Sigls Überschrift klingt auf den ersten Blick so, als würde als nächstes eine Plattitüden-Sammlung folgen. Tatsächlich ist seine Übersicht aber durchaus sinnvoll, denn er zählt nicht nur die vier Bereiche auf (Anpassungsfähigkeit, Zielsetzung, Psychologische Sicherheit und Feedback), sondern er zeigt auch Fehler auf die man vermeiden sollte, wenn man hier besser werden möchte - darunter auch einige unerwartete, wie z.B. ein zu grosses Vertrauen in Expertenwissen.

Dienstag, 28. Januar 2025

Zwerge auf den Schultern von Riesen

Bild: Wikimedia Commons / Japanische Akademie der Wissenschaften - CC BY 4.0

Manchmal kommen die tragischen Entwicklungen schnell und unverhofft. Nur zwei Tage nachdem ich sein bahnbrechendes Paper The New New Product Development Game empfohlen habe ist Ikujirō Nonaka gestorben, einer der grossen Vordenker der Methoden, die wir heute ale Agil bezeichnen würden. Was dadurch in Erinnerung gerufen wird: leider müssen wir uns in den nächsten Jahren auf weitere derartige Trauer-Nachrichten einstellen - und die werden Folgen haben.


Zur Einordnung: grossteils aufbauend auf das oben erwähnte Paper sind die meisten agilen Vorgehensmodelle (Scrum, XP, IT-Kanban, Agile Testing, etc) zwischen den späten 80er und frühen 2000er Jahren entstanden. Da ihre Erfinder bereits damals über einige Jahre oder sogar Jahrzehnte Berufserfahrung verfügten, sind sie mittlerweile in ihren 60ern, 70ern oder 80ern angekommen. Und obwohl sie hoffentlich noch lange leben werden - nicht jeder dürfte 90 werden, so wie Nonaka.


Das ist deshalb von Bedeutung, weil diese Vordenker bisher durch ihre öffentlichen Meinungsäusserungen ein Korrektiv zu den verbreiteten esoterischen oder komerziell getriebenen Fehldeutungen ihrer Arbeit bilden konnten, legitimiert dadurch, dass sie schliesslich selbst am Besten sagen können, was sie mit ihren Ansätzen beabsichtigt haben und was nicht (das bekannteste Beispiel dafür dürfte ihre einhellige Ablehnung des Scaled Agile Framework / SAFe sein).


Mit dem absehbaren Verschwinden dieser Stimmen (das auch bereits durch einen altersbedingten Rückzug aus der Öffentlichkeit geschehen kann) dürfte es in der Zukunft immer weniger mit einer derartigen Autorität ausgestattete Widersprüche gegen absichtliche oder versehentliche Verfremdungen der agilen Ideen und Prinzipien geben. Und noch bedenklicher: kommerzielle Organisationen wie Scrum Alliance, SAFe, Kanban University und PMI werden diese Autorität vermutlich für sich beanspruchen.


Um so wichtiger wird es werden, die von den agilen Pionieren verfassen Originalquellen (von denen es aufgrund der Entstehung der Agilität in den Schatten ohnehin viel zu wenige gibt) in Erinnerung zu behalten und als Massstab für die Bewertung neuer Entwicklungen zu benutzen, von der Forschung Nonakas und Takeuchis über die frühen Vorträge auf den OOPSLA- und Agile-Konferenzen bis zu den Büchern und Artikeln der Verfasser des Manifests für agile Softwareentwicklung.


Die grosse Herausforderung dabei wird es sein, derartig auf den Schultern der Riesen zu stehen, dass deren Absichten gewahrt bleiben, ohne dass es zu einer rückwärtsgewandten Erstarrung der damit verbundenen Methoden kommt. Andererseits - verglichen mit dem, was zwischen den späten 80er und frühen 2000er Jahren geleistet wurde, ist das eine fast schon einfache Aufgabe. Und noch haben wir genug Zeit um uns von den agilen Vordenkern inspirieren zu lassen.

Donnerstag, 23. Januar 2025

Ein Hoch auf die Wissenschaft

Wenn man Aussagen sucht, auf die die agile Bewegung sich einigen kann, dann wird man schnell auf die stossen, dass agiles Arbeiten Empirie- und Evidenz-getrieben sein sollte, oder mit anderen Worten: wissenschaftlich. Ernst genommen bedeutet das zum Einen, dass man im Kleinen selbst versuchen sollte, so vorzugehen, zum Anderen aber auch, dass man sich für wissenschaftliche Erkenntnisse interessieren sollte, die das eigene Arbeitsfeld betreffen - und wer danach sucht, findet Einiges.


Ich bin mit der Zeit auf eine ganzen Reihe wissenschaftlicher Papers gestossen und spiele gerade mit dem Gedanken, eine Beitragsreihe zu starten, in der ich jeweils einige von ihnen vorstelle. Ob es wirklich dazu kommt wird sich zeigen, für den Moment habe ich aber zumindest fünf, die mir erwähnenswert erscheinen. Sie gehen quer durch alle möglichen Themen durch und sind natürlich eine subjektive Auswahl, aber eine die ich empfehlen möchte. Hier sind sie:


Takeuchi, Hirotaka; Nonaka, Ikujiro: The New New Product Development Game

Eine der Initialzündungen dessen, was wir heute agile Produktentwicklung nennen. Vereinfacht gesagt haben Takeuchi und Nonaka Feldforschung betrieben um herauszufinden, warum manche Firmen effektiver Produkte entwickeln als andere. Ihre Forschungsergebnisse sind zwar schon 40 Jahre alt, haben aber nichts von ihrer Aktualität eingebüsst.


Verwijs, Christiaan; Overeem, Barry: The Double-Edged Sword Of Diversity In Teams

Manchmal tun Erkenntnisse weh. Verwijs und Overeem haben versucht, den in der agilen Bewegung verbreiteten Glaubenssatz zu validieren, dass Diversität in Entwicklungsteams etwas grundsätzlich Gutes ist. Ihre Erkenntnis - ganz so einfach ist es nicht. Zwar gibt es eindeutig positive Effekte, in einigen Dimensionen ist Diversität aber ohne Auswirkungen oder führt sogar zu Nachteilen.


Eilers, Karen; Peters, Christoph; Leimeister, Jan: Why the agile mindset matters

Diese Arbeit ist wirklich verdienstvoll. Zum ersten mal habe ich hier gesehen, wie versucht wird, den umstrittenen Begriff des "Agilen Mindset" neutral und sachlich einzuordnen und zu untersuchen. Ein wohltuender Kontrast zu dem eher esoterischen und zum Teil sogar übergriffigen Umgang, der sonst in der Beschäftigung mit diesem Begriff vorherrschend ist.


Flyvbjerg, Bent; Budzier, Alexander: Why Your IT Project May Be Riskier than You Think

Der bemerkenswerte Forschungsschwerpunkt von Bent Flyvbjerg sind (scheiternde) Grossprojekte. Dass die häufig ausser Kontrolle geraten ist zwar bekannt, er differenziert es aber entscheidend aus. Vereinfacht gesagt: es geht nicht immer schief, aber wenn es schiefgeht, dann richtig. Und: die Gründe dafür sind identifizierbar und es gibt erfolgsversprechende Gegenmassnahmen.


Kühl, Stefan: Das Scharlatanerieproblem – Zwischen Professionsbildung und Professionalisierung

Noch einmal Erkenntnisse, die weh tun. Über die Zeit hat sich Stefan Kühl die Rolle des Hofnarren der (agilen) Berater-Szene erarbeitet, der er ihre Unzulänglichkeiten aus soziologischer Perspektive und mit erkennbarer Freude vorhält. An dieser Stelle mit Fokus auf einem der grossen strukturellen Defizite: dem weitgehenden Fehlen verbindlicher professioneller Standards zur Qualitätssicherung ihrer Arbeit.

Montag, 20. Januar 2025

Agile Sucess Stories: Die agile Revision

Bild: Pexels / Vlada Karpovich - Lizenz

Leider ist es so, dass viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) mit der Zeit eine eher negative Weltsicht entwickeln. Das ist auch menschlich verständlich, wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann leicht in Frustration abrutschen. Um nicht selbst in dieses Muster verfallen, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.


Diese hier hat sich in einem grossen Unternehmen in einer gesetzlich regulierten Branche zugetragen. Die Einhaltung dieser Regulierungen wurde von einer eigenen Abteilung überprüft, der Revision, die von Zeit zu Zeit anderen Abteilungen einen Besuch abstattete, sich deren Abläufe und Ablaufdokumentationen zeigen liess, diese überprüfte und für regulierungskonform oder nicht regulierungskonform erklärte. Wenn das zweite der Fall war, mussten diese angepasst werden, danach wurden sie nochmals überprüft.


Bewusst oder unbewusst hatte sich in dieser Firma mit der Zeit ein eher dysfunktionaler Umgang mit der Revision etabliert: im Vorfeld wurde die Herausgabe von Informationen möglichst stark verzögert, während der eigentlichen Prüfung wurde die Revision dann dafür mit möglichst viel Material überflutet. In dem waren einige offensichtliche aber sehr geringfügige Fehler prominent plaziert, um schnell gefunden zu werden und die Revisoren von einer genaueren Überprüfung der anderen Bereiche abzulenken.


Als externem Berater/Agile Coach war ich in diese Feinheiten nicht eingeweiht worden, weshalb ich mir keine grossen Gedanken machte, als ich kontaktiert und nach einer Prozessdokumentation der agilen Software-Entwicklung gefragt wurde. Bereitwillig verwies ich auf den Scrum Guide und einige Intranet-Seiten, auf denen erklärt wurde, wie Scrum in der Entwicklungsabteilung umgesetzt wurde, die ich zu dieser Zeit begleitete. Noch am selben Tag brach dort Unruhe aus.


Schlafende Hunde hätte ich geweckt und die Revisoren "angefüttert", hiess es, jetzt hätten die mehr Zeit als sonst um sich zu informieren, sich vorzubereiten und noch genauer als sonst zu prüfen, und dadurch würden sie auch mehr finden können und für alle mehr Arbeit verursachen. Ein grosses Drama. Um alle zu beruhigen bot ich schliesslich an, die Vorbereitungs-Arbeiten der Revisions-Prüfung selbst zu übernehmen. Es waren noch etwa fünf Wochen bis zum Revisionstermin.


Eine wirkliche Idee was ich alles abzuliefern hätte hatte ich am Anfang noch nicht, dafür aber eine Idee wen ich fragen könnte - den Revisor, der mich nach Prozessdokumentation gefragt hatte. Und tatsächlich, von ihm bekam ich die "Richtlinien zur Inbetriebnahme, Modifizierung und Ausserbetriebnahme von Netzwerk- und Informationssystemen". Ein riesiges, unübersichtliches Dokument, voller Fachbegriffe und juristischer Formulierungen. Ich verstand bestenfalls die Hälfte.


Immerhin, er war bereit, es mir zu erklären, also stellte ich einen längeren Termin mit ihm ein, der erstaunlich konstruktiv und produktiv war. Hinter den meisten Formulierungen verbargen sich sehr einfache und nachvollziehbare Vorgaben, z.B. dass es ein Vorgehen zur Priorisierung von Anforderungen geben müsste, dass ein Vier-Augen-Prinzip gewährleistet sein müsste und dass neu entwickelte Funktionen eine Qualitätssicherung dürchlaufen müssten.


Umgekehrt konnte ich erklären, was es mit den verschiedenen Fachbegriffen aus Scrum auf sich hatte. Welche Meetings es gab, wer an ihnen teilnahm und dort welchen Beitrag leistete und welche zusätzlichen Praktiken in den Teams verwendet wurden, z.B. User Stories, Pair Programming und Code Reviews. Wir gingen auseinender mit einer Idee: bis zur nächsten Woche sollte ich eine Übersicht erstellen, welche Richtlinien durch welche Scrum-Regeln und Praktiken abgedeckt wurden.


Im nächsten Termin konnte ich bereits für die meisten Richtlinien etwas vorweisen: das Refinement für die Anforderungs-Priorisierungen, die Code Reviews für das Vier-Augen-Prinzip, die Akzeptanz- und Regressionstests für die Qualitätssicherung, etc. Natürlich war noch nicht alles abgedeckt, aber wir konnten jetzt sortieren - Themen bei denen es nichts mehr zu tun gab, Themen bei denen nur noch die Dokumentation genauer werden musste und offene Themen.


In den verbleibenden drei Wochen arbeiteten wir diese Liste durch: zwischen den jeweils wöchentlichen Terminen konnte ich die Prozessdokumentation vervollständigen und Vorschläge erarbeiten, welche noch offenen Richtlinien wie in Scrum umgesetzt werden könnten (z.B. wurden Security-Vorgaben in die Definition of Done aufgenommen), umgekehrt konnte der Revisor sich mit seinen Kollegen abstimmen, ob das auch nach deren Meinung ausreichend war.


Letzteres führte dann auch zu einem unerwarteten Effekt: einige der anderen Revisoren hatten vorher in anderen Firmen bereits agile Prozesse überprüft, und konnten berichten, wie Regularien dort erfüllt worden waren. Sobald uns das bewusst war, fragten wir auch  bei weiteren noch unklaren Fällen nach Erfahrungswerten, und bekamen auch einige (z.B. dass die Nennung einer einzuhaltenden Richtlinie in den Akzeptanzkriterien einer User Story eine ausreichende Dokumentation war).


Der Revisionstermin war dann trotz allem lang und umständlich, schliesslich war es vorgegeben, dass mehrere Revisoren zusammen mit mehreren Mitgliedern der Entwicklungsabteilung den gesamten Prozess und seine Dokumentation im Detail durchgehen mussten. Anders als bei den letzten Terminen war das Meiste den Revisoren aber bereits bekannt - und als ein weiteres Ergebnis der Vorbereitung war die zu sichtende Dokumentation auf das Wesentliche reduziert, hatte also deutlich weniger Umfang.


Am Ende stand die geringste Menge an notwendigen Nacharbeiten, an die sich alle Beteiligten erinnern konnten, und gleichzeitig waren die Vertreter der Revisionsabteilung der Meinung, dass sie noch nie die Prozesse einer geprüften Abteilung so gut verstanden hätten. Auch in der Entwicklungsabteilung wurde anerkannt, dass die frühe und transparente Zusammenarbeit mit den Revisoren nicht die befürchteten negativen Folgen gehabt hatte, sondern sinnvoll gewesen war.


Ein kleines Highlicht fand ganz zum Schluss statt: ein zufällig anwesender Manager hatte von den wöchentlichen Vorbereitungsterminen erfahren und glaubte daraus ableiten zu können, dass jetzt auch die Revisionsabteilung jetzt nach Scrum arbeiten würde. Die Revisoren korrigierten ihn höflich - agil wäre das Vorgehen durchaus gewesen und incrementell-iterativ auch, aber kein Scrum, da das aus bestimmen Gründen hier nicht sinnvoll anwendbar wäre. Sie hatten es tatsächlich verstanden.