On Lean and Agility

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

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.

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.

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.

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

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.

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.

Grafik: Pixabay / Brian Penny - Lizenz

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

Jeff Gothelf: OKRs for Organizational Agility

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

Marty Cagan: The Product Model and Agile

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

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.