Kommentierte Links (CXXIV)
 |
| Grafik: Pixabay / Brian Penny - Lizenz |
Freitag, 28. Februar 2025
Dienstag, 25. Februar 2025
Der andere Kanban Guide
 |
| Bild: Flickr / Rosenfeld Media - CC BY 2.0 |
Einer der grossen Unterschiede zwischen den beiden populärsten agilen Frameworks, Scrum und Kanban, war immer, dass Scrum mit dem Scrum Guide ein verbindliches Regelwerk hatte, während Kanban trotz weit verbreiteter und allgemein anerkannter Praktiken eher "Open Source" war, so dass jeder hineindefinieren und -interpretieren konnte was er wollte. Diese Unklarheit hat immer wieder den Wunsch nach einem "Kanban Guide" aufkommen lassen.
Die erste Organisation die versucht hat diese Lücke zu füllen (bzw. den damit verbundenen Zertifizierungs-Markt zu erschliessen) war die Lean Kanban University, die 2016 den trotz seines Namens etwas aufgeblähten Essential Kanban Condensed Guide veröffentlichte, der dann 2021 durch den schlankeren "Official" Kanban Guide abgelöst wurde. Aufgrund seines Namens wird der immer wieder für das einzige und verbindliche Kanban-Regelwerk gehalten.
Da der Begriff und die Idee von Kanan nicht geschützt sind, gibt es aber auch Alternativen, unter denen die vielleicht bekannteste schlicht The Kanban Guide heisst. Selbst wenn seine Verfasser Daniel Vacanti und John Coleman mit ProKanban (einer anderen Zertifizierungs-Organisation) verbunden sind, ist das Dokument bewusst nicht mit deren Brand verbunden oder auf deren Website gehostet, um so seinen universellen Anspruch und seinen nicht-kommerziellen Charakter hervorzuheben.
Von seiner Struktur her organisiert er sich sehr stark am Scrum Guide, bis hin zu dem Punkt, dass mehrere seiner Abschnitte fast identisch benannt sind (Purpose of the Kanban Guide statt Purpose of the Scrum Guide, Definition of Kanban statt Scrum Definition, Kanban Theory statt Scrum Theory, etc.).1 Lediglich in seinem Mittelteil gibt es Abweichungen, gegen Ende entspricht der Aufbau mit End Note und Acknowledements wieder sehr stark dem des Scrum Guides.
Inhaltlich sind es auch vor allem diese mittleren Abschnitte, die Kanban Practices, das Improving the Workflow und die Kanban Measures die interessant sind.2 Den grössten Teil nehmen dabei die Practices ein, es handelt sich bei ihnen um Defining and Visualizing the Workflow, Actively Managing Items in a Workflow, Controlling Work In Progress und Service Level Expectation.3 Nach Ansicht der beiden Autoren handelt es sich dabei um die unverzichtbaren Kernbereiche der Kanban-Methode.
Mit Actively Managing Items in a Workflow sind im Kanban Guide die Tätigkeiten gemeint, die den reibungslosen Durchfluss von Arbeit durch das System sicherstellen oder wiederherstellen sollen. Im Einzelnen sind das Controlling Work in Progress (d.h. dessen Menge), Avoiding work items piling up in any part of the workflow, Ensuring work items do not age unnecessarily (mit Hilfe von Service Level Agreements) und Unblocking blocked work.
Mit Controlling Work in Progress und Ensuring work items do not age unnecessarily bekommen die erste und letzte der zuletzt genannten Tätigkeiten noch einen eigenen Abschnitt, in dem tiefergehend erläutert wird, was sich dahinter verbirgt, bzw. welche weiteren Konzepte damit verbunden sind. Hier finden sich u.a. auch das Pull-Prinzip und das probabilistische Forecasting, die damit im Vergleich zu anderen Kanban-Auslegungen eine eher wenig prominente Plazierung haben.
Im Vergleich dazu ist das Improving the Workflow relativ knapp beschrieben. Hervorgehoben wird vor allem, dass es überhaupt stattfinden sollte, dass es auf der Grundlage von Zahlen und/oder Erfahrungen erfolgen sollte und dass es Verbesserungen der Effizienz, Effektivität und Vorhersagbarkeit zum Ziel haben sollte. Bemerkenswert ist, dass explizit nicht nur kleine sondern auch grosse Verbesserungen möglich sind, also nicht nur Kaizen sondern auch Kaikaku.
Die Kanban Measures sind schliesslich wieder die grossen Klassiker: Work in Progress-Menge, Throughput, Work Item Age und Cycle Time (Lead Time dagegen bemerkenswerterweise nicht). Neben ihrer kurzen Erklärung wird noch unterstrichen, dass sie nur zum Zweck der Prozessverbesserung erhoben und kein Selbstzweck sein sollen, und dass es möglich ist, sie um weitere Metriken zu ergänzen, wenn man darin einen Mehrwert sieht.
Was der Kanban Guide nicht (bzw. nur als Nennung optionaler Möglichkeiten) enthält, sind Meetings und Rollen. Es wird zwar erwähnt, dass es möglich ist, Dailies und Retrospektiven (die hier nur Reviewing the Definition of Workflow from Time to tTime heissen) abzuhalten, von einer zu starken Formalisierung wird aber abgeraten. Im Fall der Rollen ist nicht mal das gegeben, sie werden an keiner Stelle des Kanban Guide auch nur erwähnt, geschweige denn vorgegeben.
Zur Bewertung, bzw. Einordnung: das auf den ersten Blick Auffälligste am Kanban Guide dürfte die starke Anlehnung seiner Struktur an die des Scrum Guide sein. Die mag ihre Vorteile haben, da jemand der bisher nur Scrum kennt sich leichter zurechtfinden wird, andererseits wirkt sie etwas gezwungen und z.T. sogar un-originell, etwa in den End Note, die in einigen Passagen eine Eins-zu Eins-Kopie ist. Auch die Definition of Workflow wirkt etwas gezwungen.
In Abgrenzung zum "Official" Kanban Guide der Kanban University ist erkennbar, dass die jeweiligen Verfasser jeweils unterschiedliche Elemente für wichtig oder verzichtbar gehalten haben. Während z.B. im "Official" Kanban Guide Aufbau und Nutzung eines Kanban-Boards einen grossen Platz einnehmen, fehlen sie in The Kanban Guide völlig. Das macht einmal mehr die Gestaltungsoffenheit von Kanban deutlich (die dann allerdings mit den Mindestvorgaben der Verfasser kollidiert).
Genau die Offenheit an dieser Stelle, durch die klar wird, dass Kanban zwar in Form eines Boards mit Kartenoder Kacheln dargestellt werden kann, aber keinerswegs dargestellt werden muss, ist übrigens eine, die grossen Teilen der Kanban-Community fehlt (Alternativen sind Ampelfarben, Kontroll-Charts, Kummulative Flussdiagramme, etc.). Alleine in dieser Hinsicht ist Vacantis und Colemans Guide eine wertvolle Ergänzung.
Auffällig ist ausserdem, dass ihr Regelwerk nochmal kürzer und komprimierter ist als die von Scrum und der Kaban University. Einschliesslich Inhaltsverzeichnis umfasst er nur neun Seiten. Aufgrunddessen kann man ihn auch ohne grossen Aufwand als Ergänzung zum nur unwesentlich längeren Guide der Kanban University benutzen, alleine um verschiedene Blickwinkel auf das Thema Kanban zu bekommen, dass sich mit einem Dokument alleine kaum abbilden lässt.
2Ähnlich wie im Scrum Guide ist der Theorieteil sehr kurz und besteht im Wesentlichen aus einer Aufzählung zugrundeliegender Methoden und Frameworks
3Es gibt zwar eine deutsche Übersetzung, da deren Wortwahl mitunter etwas sperrig ist bevorzuge ich das englische Original
Donnerstag, 20. Februar 2025
Bürokratie
 |
| Bild: Flickr / Queensland State Archives - Public Domain |
Die Klagen über zu viel Bürokratie kennt man aus nahezu jeder grösseren Organisation, egal ob in der freien Wirtschaft, in der staatlichen Verwaltung oder bei Nichtregierungsorganisationen. Erstaunlich ist dabei aber in fast allen Fällen, dass es sich um eher unspezifische Beschwerden handelt - meistens werden nur zu viele Prozesse und Vorschriften genannt, ohne die genauer zu beschreiben. Dabei ist es durchaus möglich, diese aufzuschlüsseln, um sie deutlich klarer erkennen und ggf. beseitigen zu können.
Wichtig ist dabei, dass die offiziellen Kategorien nur eingeschränkt hilfreich sind, da es sich bei ihnen oft um Sammelbegriffe für verschiedene vorgeschriebene Tätigkeiten handelt. So kann sich z.B. hinter einer Sorgfaltspflicht oder einer Nachweispflicht alles Mögliche verbergen, mit je nach Einzelfall deutlich unterschiedlichen Auswirkungen. Eine differenzierte Betrachtung macht daher Sinn, und mit ihr kommt man zu dieser (sicherlich unvollständigen) Liste bürokratiefördernder Vorgaben:
Durchführungspflichten
Hier geht es darum, wer was zu tun hat und in welcher Reihenfolge der Arbeitsschritte. Das kann abstrakt sein, wie bei der Vorgabe eines Vier-Augen-Prinzips, aber auch komplizierte vorgegebene Abläufe umfassen, z.B. bei der Wartung einer Maschine.
Informierungspflichten
Aufbauend auf den Durchführungspflichten geht es als nächstes darum, andere über das was man selbst getan hat (oder vorhat) in Kenntnis zu setzen. Detailgrad und Empfänger können dabei je nach Fall unterschiedlich sein, wichtig ist, dass irgendjemand informiert worden ist.
Begründungspflichten
Bereits etwas einengender. Es reicht nicht mehr, zu berichten, was man getan hat oder vorhat, es muss auch klar werden, aus welcher Motivation heraus das geschieht, mit welchem Ziel oder auf wessen Anweisung. Eine häufige Erweiterung ist die Begründung für den Durchführungszeitpunkt.
Dokumentationspflichten
Die Formalisierung der Informierungspflichten. Der Kommunikationskanal zur Übermittlung der Informationen ist nicht mehr frei wählbar sondern vorgegeben, am häufigsten ist dabei die Vorgabe der Schriftform (ggf. verstärkt durch die Pflicht zur persönlichen Identifikation durch Unterschreiben).
Formatierungspflichten
In gewisser Weise die Formalisierung der Formalisierung. Es reicht nicht mehr, in irgendeiner Form die Informationen über die eigenen Handlungen zu übermitteln, auch die Struktur dieser Information wird jetzt vorgegeben, z.B. in Form einer Tabelle oder eines Formulars.
Nutzungspflichten
Die Vorgabe von Arbeitswerkzeugen. Das können physische Werkzeuge sein, digitale Werkzeuge aber auch bestimmte Räumlichkeiten, in denen Arbeit verrichtet werden muss. Eine noch immer erstaunlich häufige Extremform ist die an den hierarchischen Rang gekoppelte Vorgabe der Tintenfarbe.
Unterlassungspflichten
Das Spiegelbild der Nutzungspflichten. In einer restriktiven Variante ist alles zu unterlassen, was nicht explizit zur Nutzung vorgegeben ist, in einer offeneren Variante sind nur solche Handlungen zu unterlassen, die explizit verboten werden. Beides kann aber ggf. zu Handlungsunfähigkeit führen.
Anhörungspflichten
Während die zuvor genannten Pflichten eine Person oder Organisationseinheit selbst betreffen, werden jetzt andere einbezogen, die ein Recht darauf haben, ihre Meinung zu den Sachverhalten abzugeben, über die sie informiert wurden (ggf. mit der Erweiterung, dass diese festzuhalten ist).Beteiligungspflichten
Mit dieser Stufe ist das Mitwirken Anderer nicht mehr optional und auf die Meinungs- oder Bewertungsabgabe beschränkt, sondern verpflichtend und in die Arbeitsabläufe fest eingebunden, z.B. in Form einer Zulieferung oder Qualitätssicherung.
Kenntnisnahmepflichten
Das Gegenstück zu den Informierungspflichten. Wer auch immer Informiert wird darf das nicht einfach ignorieren, sondern ist verpflichtet, es selbstverantwortlich zur Kenntnis zu nehmen und von sich aus zu reagieren, wenn er angehört oder beteiligt werden will.
Überprüfungspflichten
Die Steigerung der Kenntnisnahmepflichten. Übermittelte Informationen müssen nicht nur zur Kenntnis genommen, sondern auf ihre Richtigkeit und ggf. Angemessenheit überprüft werden, einschliesslich einer Rückmeldung, wenn eines davon nicht gegeben sein sollte.
Genehmigungspflichten
Die Formalisierung und Generalisierung der Überprüfungspflichten. Übermittelte Informationen müssen nicht mehr nur zur Kenntnis genommen und ggf. überprüft werden, ohne eine auf dieser Überprüfung beruhende Freigabe darf der jeweilige Arbeitsvorgang nicht fortgesetzt werden.
Rechtfertigungspflichten
Spätestens an dieser Stelle wird es unangenehm. Wenn ein Überprüfungs- oder Genehmigungsprozess zu einem negativen Ergebnis führt, ist zu erklären, durch welche Fehler oder Nachlässigkeiten es überhaupt dazu kommen konnte.
Qualifizierungspflichten
Sowohl als Folge von Überprüfungs- oder Genehmigungsprozessen oder vorbeugend kann es sein, dass bestimmte Ausbildungen oder Schulungen verpflichtend vorgegeben werden, in der Regel vermunden mit der Pflicht zum Nachweis der Teilnahme oder des Bestehens einer Prüfung.
Weiterbildungspflichten
Die Verstetigung der Qualifizierungspflichten. Es reicht nicht mehr aus, Ausbildungen oder Schulungen einmal zu durchlaufen, es muss darüber hinaus in regelmässigen Abständen zu Wiederholungen, Auffrischungen, Erweiterungen oder Resensibilisierungen komen.
Stellenbesetzungspflichten
Eine Konsequenz aus den zuvor genannten Pflichten. Um ihre Erfüllung mit der nötigen Kapazität, Qualifikation und Aufgabenteilung durchführen zu können, sind Planstellen notwendig. Eigentlich nur ein Symptom der Bürokratisierung, selbst wenn es oft selbst für Bürokratie gehalten wird.
Wie oben gesagt, diese Auflistung ist sicher noch unvollständig, dass die Befolgung aller dieser Pflichten in erheblichem Ausmass zu Bürokratie im Sinn von formalisierter, nicht Mehrwert schöpfender Verwaltungsarbeit führen kann (und meistens auch führen muss), dürfte aber offensichtlich sein. Und trotzdem ist es so, dass sie alle in jeder grösseren Organisation anzutreffen sind (wenn auch in unterschiedlicher Ausprägung).
Dass das so ist, liegt daran, dass keine dieser Vorgaben komplett unsinnig ist, in jeder von ihnen wird man einen Kern von Sinnhaftgkeit finden können, schliesslich erfüllt Bürokratie durchaus einen Zweck. Es kann also kein Ziel sein, sie (oder die ihr zu Grunde liegenden Pflichten) komplett abzuschaffen. Stattdessen muss es darum gehen, die Bürokratie auf das sinnvolle Mindestmass zu beschränken - im Zweifel durch regelmässige Evaluierung und Justierung.
Und jetzt kommt es: um Evaluierung und Justierung durchführen zu können, sind wieder einige der oben genannten Pflichten notwendig, selbst wenn auch diese zwangsläufig bis zu einem gewissen Grad bürokratisch sein müssen Die finale Pointe lautet also - um Bürokratie zu bekämpfen, braucht man noch mehr Bürokratie.
Montag, 17. Februar 2025
From XP to TCR & Limbo
Zu den (wenigen) Kritikpunkten an Extreme Programming (XP) gehört, dass es seit ca. dem Jahr 2000 nicht mehr weiterentwickelt wurde. Diese Einschätzung ist allerdings falsch - wie XP-Erfinder Kent Beck in diesem Interview erklärt, gibt es mittlerweile mindestens einen neuen Bestandteil: TCR (mit dieser Abkürzung wurde der etwas sperrige ursprüngliche Name test && commit || revert ersetzt). Verkürzt gesagt: neu geschriebener Code wird in kleinsten Mengen sofort nach dem Schreiben durch einen vordefinierten Test geprüft - und bei fehlgeschlagenem Test automatisch gelöscht, so dass man neu beginnen muss. Extreme Programming, aber noch ein bisschen extremer als bisher.
Das Interview umfasst ausserdem noch verschiedene weitere Themen. Wer ein bisschen Zeit hat und sich auch zu denen informieren will, kann das auf der Website zum Interview tun, wo es nicht nur das Transkript gibt, sondern in ihm eingebettet weitere Videos, die das jeweilige Thema vertiefen.
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.
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.
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.
