Dinge ändern und Gelassenheit

Kennt ihr das? Man steht auf dem Flur und ein Kollege äußert mal wieder seinen Unmut über die da oben, die Nachbarabteilung oder die Kunden. Sein Unmut ist immer pauschal, geht oft davon aus, dass die Gescholtenen dumm sind. Auf seinen Einfluss angesprochen, kann er eben nichts machen.

In diesem Zusammenhang wird dann gerne das Gelassenheitsgebet von Reinhold Niebuhr zitiert: Gott, gib mir die Gelassenheit, Dinge hinzunehmen, die ich nicht ändern kann, den Mut, Dinge zu ändern, die ich ändern kann, und die Weisheit, das eine vom anderen zu unterscheiden.

Wieder einmal ein schöner Sinnspruch, der dazu aufruft, sich auf die Dinge zu konzentrieren, die man ändern kann. Kaum gelesen, schon wieder vergessen. Was fehlt sind konkrete Hilfestellungen oder gar leicht anwendbare Methoden. Aus dem Einsatz von Lean Management kann ich dazu vielleicht etwas beitragen.

Als wir vor einigen Jahren begannen, im Team Concerns zu sammeln, wurde zunächst die Liste immer länger. Es waren Kleinigkeiten, einmalige Vorfälle, echte Hindernisse und Unmut. Gegen die immer länger werdende Liste musste etwas getan werden, die Concerns wurden im Team verteilt. Einmalige Vorfälle und Kleinigkeiten, die wenig störten, wurden schnell abgearbeitet.

Die Hindernisse wurden mittels Problem Solving analysiert. Die Teile, die das Team selbst oder durch Einbeziehung von Nachbarn und Kooperationspartnern lösen konnte, brachten oft so viel Verbesserung, dass der Concern selbst vom Board genommen werden konnte.

Concerns, die Kunden, die Bereichsleitung oder „die da oben“ betrafen, wurden durch das Problem Solving sehr gut aufbereitet. So gut, dass bei der Darstellung der Problemlage und der Lösungsalternativen oft anerkennend genickt wurde. Dennoch änderte sich meist nichts.

Aber im Team hat sich das Bild von den Dingen, die wir anpacken und lösen können, sehr geschärft. Bei Dingen, die nicht in unserer Macht standen, haben wir je nach Workaround auch mal Gelassenheit gezeigt und den Concern einfach in den Papierkorb geworfen.

Das Erfolgsrezept ist einfach: Visuelles Management, Konzentration auf die eigenen Stärken und machen.

Katze auf dem Dach
Katze auf dem Dach

Kann man Unordnung messen?

Immer wieder begegnen mir Ausschreibungen, deren Ziel es ist, eine bestehende, historisch gewachsene Servicedienstleistung zu standardisieren. Dieser Service wird bisher in den unterschiedlichsten Ausprägungen und Qualitäten von den unterschiedlichsten Personen erbracht. Nach einigen Firmenfusionen, lokaler IT in den Ländern, verschiedenen Kostenstellen und diversen internen Kunden kann das schon recht unübersichtlich werden.

Viele Berater:innen empfehlen in einer solchen Situation, man müsse nur ganz genau beschreiben, was für eine Leistung man benötigt und entsprechende Service Level Targets von den Anbietern einfordern. Dies ist in vielen Fällen eine kaum lösbare Aufgabe. Allein die Tatsache, dass die Organisation in den verschiedenen Geschäftseinheiten mit unterschiedlichen Modellen zurechtkommt. Macht es schwierig, den richtigen Service zu definieren.

Derartige Ausschreibungen sind in der Regel sehr auffällig. Bei der Durchsicht fällt auf, dass viele Zahlen nicht zusammenpassen und die geforderten Service Levels meist zu hoch und damit zu teuer sind. In der weiteren Kommunikation werden die Zahlen auf Kundenseite typischerweise alle paar Wochen korrigiert, bleiben aber bis zum Schluss unbefriedigend.

Ich war selbst einige Jahre auf Kundenseite tätig und erinnere mich ungern an die Forderungen Simplifizierungen zentraler Stakeholder mit der platten Aussage: „Was soll denn daran so schwierig sein?“ Darauf möchte ich eine Antwort geben. Eine über Jahre ohne Standardisierung gewachsene Struktur mit hunderten unterschiedlicher Nutzergruppen ist komplex, wenn nicht gar chaotisch. Sie ist mehr als kompliziert und kann nicht in kurzer Zeit hinreichend gut analysiert werden.

Mit Hilfe von Cynefin würde ich das Umfeld analysieren und statt einer einfachen Antwort z.B. eine komplexe Problemstellung annehmen und mit Ausprobieren -> Wahrnehmen -> Handeln (Emerging Practice) antworten. Was bedeutet das für eine Ausschreibung? Zum Beispiel eine adaptive Ausschreibungsmethode wählen oder, wenn es klassisch bleiben soll, mit Rahmenvertrag in Phasen lernen und standardisieren.

Wenn man von den Cynefin-Kategorien ausgeht und einen einfacheren Kontext wählt, als er tatsächlich gegeben ist, hat man weniger Steuerungsinstrumente als notwendig. Ashby’s Gesetz besagt, dass die Vielfalt des Steuerungssystems mindestens so groß sein muss wie die Vielfalt der auftretenden Störungen, um die Steuerung durchführen zu können. Mit anderen Worten, Kategorienfehler sind ein hohes Risiko, absichtliche Kategorienfehler sind Glücksspiel.

Und genau das ist meine Beobachtung in solchen Fällen.

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

IT Sozialarbeiter

IT, das sind die Nerds mit Hoodie im Keller. Vor allem in der Medienberichterstattung, wenn es eine öffentlichkeitswirksame Computerpanne in einer Firma gab. Hintergrundbild ist eine Person vor einem Laptop, heruntergelassene Jalousien, die einen gestreiften Schatten auf den Hoodie werfen. Das einzig Neue seit einigen Jahren ist, dass der Hacker auch mal weiblich ist.

Neulich habe ich einem Schreiner auf die Frage, was man denn so beruflich mache, geantwortet, dass ich in der Informatik tätig sei. Seine Antwort war, den ganzen Tag vor dem Computer sitzen, das könne er nicht. Daraufhin habe ich geantwortet, das kann ich auch nicht. Er meinte, er würde mit Menschen arbeiten. Ich fragte ihn, wo und wann er denn mit Menschen arbeitet. So ungefähr alle 6 Wochen berät er Kunden über einzelne Möbelstücke oder deren Aufarbeitung, ansonsten arbeitet er alleine in der Werkstatt.

Dass ich viel mehr mit Menschen arbeite, nahm er mir nicht ab. Für ihn bedeutet IT, dass man vor dem Computer sitzt und programmiert. Also habe ich versucht, ihm die Aufgaben eines IT-Architekten zu erklären. Ich sagte ihm, dass ich den Kunden verstehen muss, seine Kultur, seinen Reifegrad. Dass wir uns auf das richtige Maß an IT-Dienstleistungen verständigen müssen, die dem Kunden einen realen Geschäftswert bringen. Das Bild, das ich mir von der Kunden-IT gemacht habe, muss ich mit der Realität im Unternehmen in Einklang bringen. Dass ich Menschen überzeugen muss, ihre Arbeit zu verändern und ihnen ein differenziertes Bild ihrer Zukunft aufzeigen muss.

Ich weiß ehrlich gesagt nicht, ob ich wirklich zu ihm durchgedrungen bin. Zumindest weiß er, dass es Leute in der Informatik gibt, die intensiv mit Menschen und sozialen Systemen arbeiten. Aber ich vermute, er glaubt weiterhin, dass die meisten von uns mit Pizzafingern im Keller arbeiten.

Dieses hochdämliche Image von IT-Berufen dürfte viel dazu beitragen, dass uns in diesem Bereich seit Jahren der Nachwuchs fehlt. Gerade für weibliche Auszubildende und Studierende dürfte „den ganzen Tag vor dem Computer sitzen“ eine ziemliche Abschreckung sein.

Ich kann nur sagen, die Berufsbilder in der IT sind extrem vielfältig, man lernt tolle Kunden kennen, kann gemeinsam super interessante Innovationen für das Business entwickeln. Und es vergeht kein Tag, an dem ich nicht mit Menschen zusammenarbeite.

Liebe Informatikerinnen und Informatiker, lasst uns öfter über unseren Beruf sprechen, über aufregende, herausfordernde oder lustige Begegnungen mit Kundinnen und Kunden, immer bei Sonnenschein und manchmal gerne auch im Hoodie.

Hoodie

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