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.¹

Dass dieser anfangs eher überschaubare Anwendungsfall es zeitweise schaffte, zum populärsten agilen Famework zu werden,² 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.³

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.⁴

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.