Cargo Cult

Gelegentlich trifft man auf Organisationen, die nach außen hin behaupten, agil zu sein, bei näherer Betrachtung aber kaum eine agile Kultur entwickelt haben oder entwickeln wollen. Agile Berater verwenden dafür den Begriff Cargocult, wenn Organisationen agile Methoden ohne Nutzwert, sondern eher aus symbolischen Gründen einführen.

Cargocult ist ursprünglich eine religiöse Bewegung auf einigen Pazifikinseln, bei der z.B. Teile von Flughäfen aus Holz nachgebaut werden und die Aktivitäten eines Flughafenbetriebs symbolisch nachgeahmt werden, um die Rückkehr der Ahnen herbeizuführen, die Cargo (Fracht) bringen werden. Frachtgüter, wie sie die amerikanischen Truppen im Zweiten Weltkrieg massenhaft auf die Inseln brachten.

Meiner Erfahrung nach sind die allermeisten „Cargocult“-Fälle in Unternehmen anders gelagert. Ich habe in einem Fall erlebt, dass agile Methoden in der IT eingeführt wurden. Die Mitarbeiter:innen erfuhren dies buchstäblich über Nacht, hatten keinerlei Training, sollten aber alle laufenden Projekte auf agile Arbeitsweisen umstellen. Da es sich um ein hierarchisch geführtes Unternehmen handelte, wurde dies auch in den meisten laufenden Projekten versucht. Das Management verkündete nach 4 Wochen, dass man agiler und besser als die Branchenführer sei.

Die Umstellung auf symbolisch-agiles Arbeiten führte bei allen Projekten zu erheblichen Verzögerungen. Es wurde von den Projektleitern zu agilen Methoden gerätselt und interpretiert, sehr oft mit einer simplen Fehlzuordnung wie: Definition-of-Done ist doch unser altbekanntes Abnahmeprotokoll. Es entstand ein erstaunlicher Unsinn, sogar Repressalien sollten unter dem Namen Agilität durchgesetzt werden.

Das Ganze endete nach 9 Monaten, am Ende dozierte das Management über die Unzulänglichkeiten agiler Methoden. Ich bin während und nach diesem Massenversuch angesprochen worden, habe mit den Menschen gesprochen. Die allermeisten haben unter diesem Unfug gelitten. Einige wenige haben sich immer politisch korrekt geäußert und alles richtig befunden.

Dass diese Arbeitsweise nichts mit Agilität zu tun hat, war der Mehrheit schon nach kurzer Zeit klar. Ihr aufkeimender Widerstand führte schließlich auch zum offiziellen Abbruch des Projekts. Verblieben die Befürworter, glaubten sie an einen Cargocult? Ich vermute eher, man wollte sich mit agilen Kleidern schmücken. Wollten der Welt erzählen, nun auch eine agile Organisation zu sein. Im Inneren solle alles so hierarchisch wie möglich bleiben.

Der Verdacht liegt nahe, dass man sich modern geben wollte und es gar nicht ernst meinte. Eher eine Art symbolisches agiles Arbeiten, um dem Management und der Außenwelt etwas vorzugaukeln. Für mich passt da eher der Begriff Potemkinsche Dörfer, da wohl niemand erwartet, dass die agile Kultur irgendwann vom Himmel fällt.

„New Work“ potemkinsche Dörfer sind natürlich eine überflüssig wie nur was. In den Beispielen, die ich kenne, richten sie keinen nachhaltigen Schaden an, die Mitarbeiter:innen kennen derartigen Unsinn. Ein paar junge Mitarbeiterinnen werden mittelfristig gehen. Übrigens werden rechtlich notwendige Rahmenbedingungen in diesen Unternehmen auch so eingeführt. Diese landen dann meist in einer Stabsabteilung, da gibt es immer entsprechende ISO-Beauftragte.

Bleibt die Frage: Warum macht man so etwas? Ich habe mit HR Kolleg:innen gesprochen, die ja meist mit derartigen „New Work“ Kulturveränderungen beauftragt werden. Die waren alle genervt von solchen Projekten, es mangelte fast immer an Unterstützung, Ressourcen und Budget in ihren Unternehmen. Eine transparente Kommunikation, welche Ziele mit den viel zu knappen Ressourcen eigentlich erreicht werden können, gab es bei ihnen nicht.

Wäre ja schön, wenn jemand sagen würde: Wir wollen das nur draußen an der Tür stehen haben, weil alle das jetzt so machen. Ist aber nicht so…

Tanker unscharf im Meer

Das geht alles den Bach runter

Bei Veränderungen gibt es eine Late Majority, die einer Transformation fast immer negativ gegenübersteht. Selbst wenn ein altes System aus dem letzten Loch pfeift, finden diese Gruppen immer noch Gründe, warum ein neues System, ein neuer Prozess oder eine neue Herangehensweise richtig schlecht ist und das Unternehmen in den Ruin treiben wird.

Die Late Majority ist dann die letzte aktive Gruppe, die an der Änderung mitwirkt. Wenn sie dann irgendwann auch emotional mit der Veränderung durch sind, das neue System sehr gut läuft, neue Kunden gewonnen wurden und so weiter, dann kommen manchmal von den gleichen Leuten Aussagen wie, ich habe ja immer gewusst, dass das neue System so hervorragend für uns ist.

Ich unterhalte mich gerne mit diesen Leuten bei einem Kaffee, um zu verstehen, wann der Meinungsumschwung stattgefunden hat und ob ich diesen in irgendeiner Weise hätte beschleunigen können. Das Erstaunliche ist, dass alle, die ich angesprochen habe, bestreiten, jemals Gegner des Neuen gewesen zu sein.

Selbst wenn der Tischnachbar noch einmal bestätigt, aber du hast doch damals aktiv gegen das Neue gearbeitet, kommen nur Ausflüchte wie, das war ja auch nicht so gemeint. Egal wie transparent oder fehlertolerant der Kunde war, immer wird geleugnet, jemals gegen das Neue, nunmehr besser Funktionierende gewesen zu sein.

In diesem Zusammenhang sind anfängliche Vorbehalte durchaus verständlich. Wenn eine Organisation zu lange gewartet hat, auf Verschleiß gefahren ist, ist das Personal oft so belastet, dass eine Transformation wie eine wahnsinnige Last erscheint. Wenn nach einer erfolgreichen Transformation ein anfänglicher Gegner sagt, ja, ich dachte, das kann die Mannschaft nicht auch noch schultern. Ist das sehr verständlich.

Für Veränderungsprozesse sind auch die Zurückhaltenden sehr wichtig, sie helfen zu Beginn bei der Stabilisierung und am Ende haben sie manchmal die Chance, das neue System noch besser einzuführen als die Early Adopters. Traut euch, zuzugeben, dass ihr am Anfang Bedenkenträger wart, denn daraus können wir alle lernen.

https://en.wikipedia.org/wiki/Diffusion_of_innovations

Bach

Keine Kenntnisse, keine Kritik

In den sozialen Medien wird oft über ungerechtfertigte Kritik oder herablassende Bemerkungen aufgrund des Geschlechts, der Herkunft, der Kleidung usw. geklagt. Solche Klagen werden dann gerne mit der Aussage garniert, dass andere gesellschaftliche Gruppen unter solchen Dingen nicht zu leiden hätten. Meiner Erfahrung nach ist ausgrenzende Kritik sehr universell und missbraucht gerne Äußerlichkeiten wie irrelevante Eigenschaften oder Hobbys. Hauptsache, es ist ein billiges Vehikel, um die angegriffene Person zu ächten.

Ich bin und war an sehr vielen Veränderungsprozessen beteiligt, und da hört man diese Sprüche sehr oft in der Kaffeeküche. Manche Führungskräfte, die Veränderungen vorantreiben, kriegen ihr Fett weg. Diese Verunglimpfungen werden oft von den Laggards getrieben, das sind die Leute die als allerletzte die Veränderungen übernehmen. Als Außenstehender bin ich eher selten betroffen.

Aber einmal ist es mir passiert: Ein Unternehmen musste dringend seine dezentrale, inhomogene IT effizienter machen, weil es rote Zahlen schrieb. Nach einigen Monaten des ersten Fortschrittes gab es ein großes Projektmeeting, in dem Alternativen diskutiert werden sollten. Ein Geschäftsbereich war kurzfristig dazugekommen und hatte einen Vertreter geschickt. Ich war eigentlich nur Gast und saß ganz hinten im Raum.

Dieser Vertreter hat eine kleine Umbaupause genutzt, ist nach vorne gegangen, hat sich das Mikrofon geschnappt und hat mich als Person beschimpft. „Ob man sich von diesem bescheuerten Deutschen was sagen lassen will“ war noch die harmlosere Variante. Ich war sehr überrascht, Adrinalin schoss durch die Blutbahn, aber ich konnte die Zeit der Beschimpfung nutzen, um mich zu sammeln.

Ich ging langsam nach vorne, stellte mich neben ihn, schaute ihn an und deutete mit den Händen an, dass ich das Mikrofon haben wollte. Er war sehr verwirrt, sprach weiter, ich machte die Handbewegung ohne etwas zu sagen. Er gab mir das Mikrofon und ging zu seinem Platz zurück. Ich fasste kurz zusammen, dass wir alle hier sind, um Alternativen zu diskutieren, bat ihn um konstruktive Mitarbeit und verbot ihm, mich persönlich anzugreifen. Konstruktive Kritik an meiner Arbeit sei jedoch immer willkommen. Er rief noch etwas Unverständliches von seinem Platz, dann war Ruhe.

Ich finde es wichtig, kurz auf den Angriff zu kontern. Nicht auf den Inhalt, denn ein solcher Angriff hat keinen Inhalt. Das kann so niederschwellig sein wie ein Slow Blink, den ich zwei Damen zuwarf, die ich bei einem Konzert nicht vordrängeln lies, die sich dann mit zwei Reihen hinter mir begnügen mussten und mich dann herablassend mit Äußerlichkeiten und vermeintlichen Eigenschaften beleidigten.

Oft erfährt man so etwas erst über eine zweite Person, auch da spreche ich es immer an. Dabei verzichte ich auf Verdächtigungen, sondern spreche eher über die Inhalte. „Ich habe gehört, du magst die anstehenden Veränderungen nicht“, die Reaktionen sind vielfältig, von „Doch, doch, alles gut“ über konstruktive Kritik bis hin zu „Ja, der Meyer ist ein Arsch, schau mal, was für eine Prozkarre der fährt“.

So eine herablassende Kritik kann einen ganz schön treffen. Weil man gerade einen schwachen Moment hat, weil man mit anderen Dingen im Projekt kämpft, weil die Kritik geschickt einen wunden Punkt getroffen hat.

Wenn mir so etwas passiert ist, setze ich mich damit auseinander. Ich suche nach Ursachen, warum es mir nahe gegangen ist und versuche, es für mich abzuschließen. Ein wichtiger Prüfpunkt ist: Würde ich diese Person um Kritik bitten? Wenn nicht, ist die Kritik nicht für mich, sondern sagt vielmehr etwas über die Gegenseite aus.

Kritiker der Nasenlängen sind nevig und verdienen keine Beachtung. Du kennst mich nicht oder den Inhalt nicht, dann hast du kein Recht auf Kritik.

Abschließend ein kurzer Gedanke zu guter Kritik. Wenn es sich um eine Mentor-Mentee-Beziehung oder eine Vorgesetzten-Mitarbeiter-Beziehung handelt und man um Kritik zur Verbesserung gebeten wird. Aus der Beobachterperspektive kann man Stärken hervorheben und Schwächen als Alternativen anbieten. Statt „In der Kundenansprache musst du noch einiges lernen, Kalkulation und Technik kannst du schon sehr gut“ kann man sagen, was man schätzt: „Wenn wir beide beim Kunden sind, finde ich es toll, dass du mir die Technik und die Zahlen abnimmst. So kann ich mich ganz auf den Kunden konzentrieren.“ Als Einstieg in ein Gespräch können so einige Verbesserungsideen entwickelt werden, der Gesprächspartner hat maximale Freiheit, sich Alternativen zu nehmen und diese zu diskutieren.

Slow Blink
Slow Blink

Werft alte Zahlen weg!

Ich war nun ein paar Mal daran beteiligt, wenn IT Organisationen reinen Tisch machen wollten und eine grundsätzliche Neuaufstellung (in Bereichen) anstrebten, sei es durch große Joint-Ventures, Akquisen oder einfach weil das Business in einer Krise steckte.

Vielfach sind mir dort IT Organisationen begegnet, die durchaus wussten das einige Dinge deutlich in Schieflage waren oder einfach alles nur historisch gewachsen sind und jedwede Struktur zu hinterfragen war.

Was mich allerdings wundert ist, dass vielfach die neue Architektur auf bestehende Reports bzw. Zahlen aufgebaut werden sollte. Damit meine ich, das sehr früh noch bei der grundsätzlichen Planung des Veränderungsprozesses vorhandene Reports als Zahlengrundlage genutzt werden sollten.

Es kommen in solchen Veränderungsprozessen nur ganz wenige Beteiligte auf den Gedanken, dass das die Nutzung bestehender KPIs ein Fehler mit möglicherweise immensen Auswirkungen ist. Es liegt auf der Hand, dass die historische Organisation, also die Organisation die in Schieflage gekommen ist, mit diesen Zahlen und Berichten gesteuert hat.

Nur sehr wenige Zahlen in Reports sind objektiv. Die bisherige Organisation dürfte einige KPIs geschaffen haben, an denen Bereiche gemessen wurden, die jetzt angeschlagen dastehen. Natürlich werden KPIs fast immer interpretiert, getuned oder aufgehübscht. Die Messzahlen in vielen Organisationen müssen von Jahr zu Jahr in die gewünschte Richtung wachsen, also tun sie das auch.

Selbst bei Zahlen die mit guter Absicht designed wurden, sind Messpunkte, Konsolidierungen und Abschätzungen zur Berechnung gesetzt worden, dieses Design und seine Kompromisse sollte man sich stets genau ansehen. Viele Dinge sind gar nicht eindeutig oder gar leicht zu messen, also wird ein Stück interpretiert, das ist ganz normal.

Ich wäre sehr vorsichtig und würde nur überprüft saubere Rohdaten heranziehen. Bestehende Reports können eventuell dazu nützlich sein, die alte Organisation zu verstehen und Fehlerursachen bzw. Fehlleitungen zu ergründen.

  • Die meisten Reports werden Aussagelos sein, die wurden irgendwann mal auf dem grünen Tisch entwickelt und seitdem jeden Monat abgeheftet. Specht mit den Verantwortlichen welche Reports die nutzen, was sie daran nutzen und was sie zur Lenkung eingesetzt haben.
  • Bei manchem unsauberen Report ergibt das Monat zu Monat Delta eine brauchbare Aussage. Steigen die Einnahmen bei virtuellen Servern oder fallen diese, auch wenn die Gesamtsumme in Euro nicht mit dem Financial Reporting übereinstimmt. Bitte mit Vorsicht nutzen, manchmal sind Lücken enthalten die einen auf einem Auge Blind machen.
  • Apropos Übereinstimmung: Versucht doch einmal die selbe Zahl (KPI, PI) über verschiedene Business-Unit-Reports zu ermitteln. Anzahl der virtuellen Server einer BU aus den Daten der BU-Reports, CMDB und dem IT Monatsbericht. In einem der letzten Unternehmen waren die so zu ermittelten Abweichungen oft bei bei 15%-20%!
  • Zahlen die durch Interpolation hochgerechnet werden sind in dieser Form irreführend und lohnen keines Blickes. Fehler finden sich zum Beispiel in der Form, dass Zahlen von Hauptstandorten genutzt werden, um auf das Gesamtunternehmen mit einigen großen und vielen kleinen Standorten hochzurechnen. Kleine Standorte funktionieren aber oftmals anders. Sie haben bestimmte Services nicht, diverse Services mit zusätzlichem Aufwand oder ganz simpel eine Shadow IT.

Kurz und gut: Wenn ihr an Bord kommt, um ein auf Grund gelaufenes Schiff wieder in die Fahrrinne zu bekommen. Schmeißt die alten Karten weg und nutzt eure neuen Seekarten. Die alten Karten lassen sich ganz eventuell hernehmen, um die Ursache der Havarie zu ermitteln.