Kommentierte Links (CXVIII)

Grafik: Pixabay / Geralt - Lizenz

Das Internet ist voll von Menschen, die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Pim de Morree: The Anatomy of a Self-Managing Organization - Why Networks Trump Hierarchies

Die Idee einer netzwerlartigen Organisation wird immer wieder angeführt, wenn diskutiert wird, wie auch im grossen Masstab Agilität und Flexibilität möglich sein können, die dabei immer wieder gestellte Frage ist aber die, ob das auch in der Realität funktionieren kann. Pim de Morree kann diese Zweifel ausräumen indem er verschiedene grosse und mittelgrosse Unternehmen nennt, in denen bereits jetzt so gearbeitet wird, von Haier über Indaero, Buurtzorg und Vertica bis hin zu W.L. Gore. Derartige Praxisbeispiele können nicht nur Zweifel zerstreuen, sie bringen die Diskussion auch wieder zum richtigen Thema zurück: was müssen wir tun um selbst so arbeiten zu können?

Erik de Bos: The Puzzle of Self-Organisation

Dieser Artikel von Erik de Bos enthält mit Enrise ein weiteres Beispiel für eine Netwerk-Organisation, konzentriert sich aber auf ein anderes Thema: was muss für wirkliche Selbstorganisation auf Teamlevel eigentlich gegeben sein? Der wichtigste unter den von ihm genannten Faktoren ist dabei eine gewisse Erfahrung, was auch intuitiv Sinn ergibt - ohne Erfahrungwerte ist es schwer, Potentiale und Risiken einzuschätzen, und ihnen vorbeugend oder reaktiv zu begegnen. Dort wo Erfahrungen vorhanden sind (oder nach und nach entstehen) sind Effektivität und Erfolgsaussichten von selbstorganisierten Einheiten dagegen deutlich höher.

Bob Galen: Shatters Anonymous

Ein bisschen Meta-Perspektive. Bob Galen sinniert hier über zwei viral gegangene Linkedin-Artikel des Disciplined Agile-Erfinders Scott Ambler, in denen dieser (mit grenzwertiger Wortwahl) der agilen Bewegung vorgeworfen hat, ihre eigene Position durch Dogmatismus, Kommerzialisierung und fehlende Lösungsorientierung untergraben zu haben. Galen stimmt dieser Beschreibung grundsätzlich zu, was ihm darin fehlt, ist aber eine wie auch immer geartete Lösungsorientierung. Er ruft daher alle Meinungsführer der agilen Bewegung dazu auf, die zu erarbeiten. Ein Aufruf dem man sich nur anschliessen kann.

Prateek Singh: On Deterministic Fixed-Length Timeboxes

Ein Artikel, der in gleich zweifacher Hinsicht interessant ist. Zum einen, weil Prateek Singh in ihm die Probleme, die mit festen Deadlines oder festen Sprintlängen verbunden sind, gut herausarbeitet. In komplexen Umfeldern lässt sich eine Fertigstellungsdauer nicht seriös prognostizieren, dafür gibt es zu viele Unbekanntheiten und Dynamiken. Zum anderen ist aber interessant, wie wenig er über die Praktiken zu wissen scheint, mit denen in den Iterativen Ansätzen damit umgegangen wird (vereinfacht gesagt mit variablem Scope eines fixen Ziels). Mit diesem Wissen hätte er (der hier stellvertreten für die Kanban-Community steht) Scrum noch besser kritisieren können.

Charles Lambdin: What Is Cost of Delay?

Zuletzt etwas Grundsätzliches. Charles Lambdin nimmt sich eines oft diskutierten aber z.T. sehr unterschiedlich verstandenen Konstrukts an, der Verspätungs-Kosten (Cost of Delay). Zu den verschiedenen interessanten Aspekten auf die er dabei eingeht gehört u.a., dass es auch negative Verspätungskosten gibt (die er mit Benefits of Delay treffender benennt) und dass es trotz einer letztendlichen Unbezifferbarkeit gute Gründe dafür gibt, es trotzdem zu versuchen. Lesenswert.

Agile Success Stories: Entwickler und Anwender zusammenbringen

Bild: Pexels / Ivan Samkov - Lizenz

Dass "agile Methodiker" (Agile Coaches, Scrum Master, etc.) mit der Zeit eine eher negative Weltsicht entwickeln, ist leider ein verbreitetes Phänomen. Das ist auch irgendwie verständlich, wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann schnell in Frustration abrutschen. Um nicht selbst in dieses Muster verfallen, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Diese hier beginnt mit einem Problem. In einem Konzern, dessen agile Transformation ich begleiten durfte, galt das Verhältnis zwischen der internen Softwareentwicklung und den Anwendern in den Filialen als zerrüttet. Die Software würde schwer zu verstehen und zu bedienen sein, hiess es von den Filialkräften, umgekehrt beschwerten sich die Entwickler über unvollständige und erratische Anforderungen und Fehlermeldungen. Jede Seite sah das Problem bei der anderen.

Nach kurzem Nachforschen liess sich ein Grund für diese Missstände identifizieren: der Anforderungsmanagement-Prozess war (freundlich gesagt) suboptimal. Neue Anforderungen wurden (wenn sie überhaupt aus den Filialen kamen) von deren Leitern gestellt, die gar nicht mit den jeweiligen Systemen arbeiteten. Auf dieser Basis erstellte die IT-Konzeptionsabteilung eine Detailspezifikation und gab diese ohne Rücksprache mit dem Anforderer an die Entwicklung weiter, die nur noch umsetzte.

Natürlich kam es entlang dieser Strecke fast schon zwangsläufig zu Missverständnissen und Stille Post-Effekten, die dann in den oben genannten Problemen resultierten. Um das zukünftig zu verhindern, sah der neue Prozess etwas für diese Firma geradezu Revolutionäres vor: Anwender und Entwickler sollten diekt miteinander sprechen, und das nicht nur ab und zu sondern regelmässig. Und mit regelmässig war gemeint mindestens einmal pro Monat.

Umgesetzt wurde das, indem der gewählte Arbeitsmodus Scrum etwas angepasst wurde. Nach jedem zweiten Sprint fanden die Sprint Reviews in einer der Filialen statt. Im Mittelpunkt standen dabei nicht die Ergebnisse des letzten Sprints (die wurden in den dazwischenliegenden "normalen" Reviews besprochen) sondern das Feedback der Filialkräfte, und zwar sowohl zu Verständlichkeit und Bedienbarkeit der Anwendungen als auch zur Sinnhaftigkeit der als nächtes geplanten Funktionen.

Diese Filialbesuche brachten regelmässig erhellende Erkenntnisse. Immer wieder kam es vor, dass Funktionen, die Management und IT-Konzeption für zentral gehalten hatten, sich in der Realität als unbenötigt herausstellten, umgekehrt wurden von den Anwendern wiederholt Features gewünscht, die an die niemand gedacht hatte. Und nachdem dieser Arbeitsmodus eine Zeit lang gelaufen war, wurden die Reviewss immer positiver, da mehr und mehr der Wunsch-Features tatsächlich gebaut wurden.

Zur ganzen Wahrheit gehört, dass die Veränderungen nicht für alle Beteiligten positiv waren. Besonders die IT-Konzeptionsabteilung musste damit leben, in der Entwicklung der Filial-Software praktisch nicht mehr benötigt zu werden - und dass dann noch betont wurde, dass erst durch die direkte Kommunikation zwischen Entwicklern und Anwendern die Zufriedenheit mit der Software besser geworden war, dürfte für die bisher zwischen ihnen vermittelnden IT-Konzepter deprimierend gewesen sein.

Im Grossen und Ganzen empfanden aber fast alle das neue Vorgehen als eine Verbesserung, sowohl in Bezug auf die Zusammenarbeit als auch in Bezug auf die dadurch erzielten Ergebnisse. Wie ein Manager es irgendwann mal treffend bemerkte: "Wenn man sieht, wie gut es jetzt läuft, fragt man sich schon, warum wir das jemals anders gemacht haben."

Wie ein einziger Manager eine Firmenkultur herunterwirtschaften kann

Bild: Pixabay / The Digital Artist - Lizenz

Eine der grossen Gemeinheiten beim Thema Firmenkultur ist es, dass man sie nur sehr schwer und langsam zum Besseren verändern kann, aber erstaunlich schnell zum Schlechteren. Und während eine Verbesserung immer nur durch eine Gemeinschaftsleistung erreichbar ist, kann eine Verschlechterung sogar von nur einem einzigen Manager herbeigeführt werden, wenn er denn nur weit genug oben in der Hierarchie seine Position hat. Das klingt unglaublich, ist aber immer wieder zu beobachten.

Nehmen wir den Fall von Peter, den ich selbst miterleben durfte (und der in Wirklichkeit natürlich anders heisst). Peter war relativ neu in einer Führungsposition in einem Konzern, der bis dahin eine vergleichsweise gute Unternehmenskultur gehabt hatte. Auf die traf jetzt Peter, der zuvor in einer anderen Landesgesellschaft gearbeitet hatte, und sich dort einen besonderen Glaubenssatz angeeignet hatte: der Chef muss möglichst allen wichtigen Entscheidungen selber treffen, sonst sind sie nicht gut.

Am Anfang hatten alle gedacht, dass das alleine daran scheitern würde, dass Peter gar nicht die Zeit finden würde, um sich um alle Themen zu kümmern. Aber er war anderer Meinung und glaubte, mit einem strikten Zeitmanagement wäre das kein Problem. Er teilte seinen Tag in eine ununterbrochene Reihe von dreissig- oder sechzigminütigen Calls und Meetings ein, von Acht Uhr morgens bis Neun Uhr Abends. In denen hörte er sich jeweils die Sachstände an, traf Entscheidungen und setzte Deadlines.¹

Mit diesem strikten Zeitmanagement war allerdings ein Risiko verbunden - wenn es einmal nicht zu einer Entscheidung kam, wurden Folgetermine nötig, die aber in den vollen Kalender nicht mehr hineinpassten. Um es nicht dazu kommen zu lassen, versuchte Peter in möglichst jedem Termin eine Entscheidung zu erzwingen. Und sobald die einmal stand, durfte das Thema nicht nochmal aufgebracht werden. "Warum reden wir darüber?" fragte er dann, "Ich habe doch schon entschieden, nächsten Thema."

Für die anderen Angestellten waren diese Verhaltensweisen ein Problem. Nicht nur mussten sie die Erklärung ihrer z.T. hochkomplexen Themen so zusammenkürzen, dass wichtige Aspekte fehlten, die auf dieses Basis getroffenen (und praktisch irreversiblen) Entscheidungen waren dementsprechend auch nicht immer die besten und führten oft zu neuen Problemen, vermeidbarer Mehrarbeit, verärgerten Kunden oder verpassten Geschäftspotentialen.

Schon bald begannen sich daher die in Peters Termine mitgebrachten Unterlagen zu verändern. Um ihn an vorschnellen Entscheidungen zu hindern, wurde prominent auf noch fehlende wichtige Informationen hingewiesen, auf unabsehbare Konsequenzen zu früher Entscheidungen, auf eine unklare Rechtslage oder ähnliche Faktoren. Mit anderen Worten: die ursprünglich sehr lösungsorientierten Menschen in Peters Umfeld entwickelten mehr und mehr eine Problemfixierung und Bedenkenträger-Argumentation.

Bereits das wäre schon problematisch gewesen, es ging aber noch weiter. Immer wieder kam es vor, dass Peter zwar mit Verweisen auf fehlende Informationen oder unabschätzbare Risiken von Schnellschüssen abgehalten werden konnte, er aber in einem anderen Termin von anderen Mitarbeitern versehentlich Informationen bekam, die ihm doch eine Entscheidung ermöglichten. Von der dann nur noch in Kenntnis gesetzt zu werden war eine erstaunlich häufige Frustrations-Erfahrung.

Um dieser Erfahrung nach Möglichkeit nicht ausgesesetzt zu sein, begannen die Mitarbeiter damit, Informationen nicht mehr untereinander zu teilen oder sie möglichst unklar zu formulieren. Da es sich oft im Nachhinein herausstellte, dass einige dieser Informationen auch für andere wichtig gewesen wären, verschlechterte sich die Stimmung in der Belegschaft deutlich. Während vorher ein kollegialer und hilfsbereiter Umgang vorherrschte, entstand jetzt eine Misstrauens- und Blaming-Kultur.

Die Geschichte hatte noch einige weitere unschöne Aspekte, aus den hier beschriebenen lässt es sich aber erkennen, dass tatsächlich ein einziger Manager eine Firmenkultur herunterwirtschaften kann. Und selbst wenn dieser Fall hier ein besonders plakativer ist, es gibt noch viele andere Möglichkeiten, es zu tun, von falsch gesetzen finanziellen Anreizen über bürokratische Prozessvorgaben bis hin zur gezielten Einstellung und Beförderung nicht teamfähiger "Rockstars".

Natürlich steht auch hier am Ende die Frage, wie es besser ginge - die auch (scheinbar) einfach zu beantworten ist: man sollte Menschen wie Peter nicht in hohe Verantwortungspositionen befördern. Das zu schaffen ist aber eine grössere Herausforderung als man denken sollte. Finale Pointe: der hier beschriebene Peter hiess zwar nicht so, wurde aber hinter seinem Rücken so genannt, da seine Karriere dem Peter-Prinzip zugeschrieben wurde. Das wäre nochmal ein grosses und eigenes Thema.

¹Auch das Mittagessen war ein Arbeitstermin, und Emails beantwortete er Nachts oder am Wochenende

Rocks, Pebbles, Sand

In der Theorie klingt das Arbeiten in Sprints ganz einfach. Zu Beginn wird ein fachliches Ziel mit hohem Business Value ausgewählt und ggf. noch einmal in kleinere (Teil-)Ziele aufgeteilt, die jeweils in einen Sprint passen. Während dieses Zeitraums (meistens zwei oder drei Wochen) wird konzentriert an der Fertigstellung gearbeitet, danach wird das Ergebnis den Stakeholdern vorgestellt und mit ihnen besprochen, im Anschluss daran wird ein neuer Sprint mit einem neuen Ziel geplant.

In der Realität ist es meistens schwieriger. Zum Einen ist es meistens so, dass es auch Aufgaben gibt, die nicht den höchsten Business Value haben, die aber irgendwann erledigt werden müssen (Einspielen von Versionsupgrades, Vereinheitlichung von Farbschemata, etc). Meistens sind die auch nicht gross genug für ein eigenes Sprintziel. Zum anderen füllen Sprintziele einen Sprint fast nie völlig aus, es bleibt immer eine gewisse Restkapazität übrig.

Viele Teams gehen mit dieser Situation um indem sie etwas Naheliegendes machen: sie planen zuerst alles ein, was für die Erreichung des Sprintziels nötig ist und füllen die verbleibende Kapazität auf indem sie in der restlichen Zeit die anderen Aufgaben abarbeiten. Das ist auch grundsätzlich sinnvoll - unter der Voraussetzung, dass diese Arbeiten auch im verbleibenden Sprint abgeschlossen werden können und nicht halbfertig in den nächsten rutschen und dort Kapazität blockieren.

Ein Weg um das sicherzustellen trägt den Namen Rocks, Pebbles, Sand. Angeblich bei PayPal erfunden und durch die PayPal Mafia popularisiert funktioniert er folgendermassen: zu Beginn eines Planungstermins plant man die grossen Arbeitspakete ein, die "Felsbrocken" (Rocks). Als nächstes füllt man die verbleibende Zeit mit mittelgrossen Aufgaben, den "Steinen" (Pebbles). Die zuletzt verbleibende Zeit ist schliesslich für Kleinst-Aufgaben vorgesehen, den "Sand".

Was der Schlüssel für eine erfolgreiche Anwendung dieses Vorgehens ist, ist ein Focus auf dem Erstellen von Aufgaben, die so klein sind, dass sie die eingeplante Zeit möglichst nicht sprengen. Rocks sollten maximal so gross sein wie ein Sprint, Pebbles maximal so gross wie die im Sprint verbleibende Zeit nach dem Abzug des für die Rocks eingeplanten Aufwandes, die "Sandkörner" maximal so gross wie das, was danach noch übrig ist.

Natürlich ist damit das Risiko verbunden, dass eine derartige Kapazitätsplanung zu einer versehentlichen Überlastung führt, oder zu einer Situation in der bereits kleine zusätzliche Aufwände den verfügbaren Zeitrahmen sprengen. Es empfiehlt sich daher, auch in diesem Vorgehen einen gewissen Teil der Zeit unverplant zu lassen. Ebenfalls möglich ist es, die Aufgaben des Sand-Typs nur dann in den Sprint zu ziehen, wenn gerade kurzfristiger Leerlauf besteht.

Mit ein bisschen Übung kann es gelingen, durch Rocks, Pebbles, Sand in einen Modus zu kommen, in dem wichtige Aufgaben zuerst bearbeitet werden, kleinere nicht unnötig lange liegen bleiben, die verfügbare Zeit effektiv genutzt wird und es zu keinen in den nächsten Sprint zu schiebenden Langläufern kommt. Das ist vielleicht noch nicht der Idealzustand focussierter Outcome-orientierung, für ie meisten Teams dieser Welt wäre es aber ein Fortschritt.

The World Depends on 60-Year-Old Code: COBOL

Heute ein etwas abseitiges Thema: COBOL. Es handelt sich dabei um eine Programmiersprache aus den 50er Jahren (!), auf der bis heute (!!) der Grossteil der Kern-Anwendungen in Banken, Versicherungen, der öffentlichen Verwaltung und vielen anderen grossen Organisationen beruht. In Coding mit Dee gibt es dankenswerterweise einen Überblick darüber was COBOL ist, und was man zu seiner Geschichte und Anwendung wissen muss.

Was mir an Dees Ausführungen besonders gefällt ist die neutrale Einordnung, samt aller Vor- und Nachteile. Sie legt Wert darauf, dass nicht die veraltete Programmiersprache selbst das Problem ist, sondern dass es stattdessen Faktoren wie fehlende Dokumentation, die Verrentung der Wissensträger und die "historisch gewachsenen" Systemstrukturen sind, die zu den Schwierigkeiten führen, über die sich bei COBOL häufig beklagt wird (und wegen denen oft behauptet wird, COBOL-Anwendungen nicht agil weiterentwickeln zu können).

Welchen Zweck haben Meetings?

Bild: Pexels / Tima Miroshnichenko - Lizenz

Wenn es ein Dauerbrenner-Thema in jeder halbwegs grossen Organisation gibt, dann sind es Meetings. Und der Tenor ist immer der selbe: es sind zu viele, sie sind zu lang, sie sind langweilig und ein Grossteil der Anwesenden kann nichts beitragen. Auf die Frage wie es besser ginge folgt dann meistens ein undifferenziertes "einfach weniger Meetings!", was aber nicht hilfreich ist. Lässt man nämlich einfach einige weg, entstehen meistens Verzögerungen oder Unterbrechungen im Informationsfluss.

Dass ein Grossteil aller Meetings gleichzeitig unerträglich und unersetzlich erscheint, ist dabei Teil des Problems - sehr viele der eingestellten Termine haben keinen inhaltlichen Focus, sondern es handelt sich um die Regelmeetings von Organisationseinheiten (die legendären Team-, Abteilungs-, Projekt- oder Technik-Runden). In ihnen wird alles abgehandelt was irgendwo gerade anliegt, mit der Folge, dass auch Nicht-Betroffene es sich anhören müssen, nur weil sie Teil der selben Organisationseinheit sind.

Da jedes dieser Themen aber für irgendeinen Zweck wichtig ist, ist ein einfaches Abschaffen keine praktikable Lösung. Zielführender ist es, diese Zwecke zu identifizieren und danach gleichartige Themen in Meetings zu konzentrieren, zu denen dann nur diejenigen eingeladen werden können, die benötigt werden oder ein Interesse haben. Bestenfalls werden die für den einzelnen Teilnehmer dadurch sowohl weniger als auch relevanter. Also: welche Kategorien könnte es geben?

Teilnehmer-Status sichtbar machen

Man mag davon halten was man will, aber Meetings können Statussymbole sein, denn in einem Führungskreis oder einer Expertenrunde eingeladen zu sein kann als Bestätigung der eigenen Bedeutung oder Expertise verstanden werden. Wenn sie nur diesen Zweck haben sind derartige Termine wenig sinnvoll aber politisch bedeutsam. Wenn man sie nicht abschaffen kann, kann man sie zumindest seltener stattfinden lassen oder verkürzen (z.B. zu einem 15-minütigen "Leadership Daily").

Berufliche Existenzberechtigung sichern

Ein weiterer etwas schräger Fall. Viele Führungsrollen (manche Manager, aber auch einige Scrum Master) laden vor allem deshalb zu Meetings ein, um sich durch deren Moderation oder durch dort festgestellte Unterstützungsbedarfe selbst Arbeit zu erzeugen, die man später als Nachweis der eigenen Mehrwertstiftung vorweisen kann. Auch das ist inhaltlich verzichtbar aber politisch heikel, ggf. müssen diese Rollen bei einer Abschaffung dieser Termine andere sinnstiftende Tätigkeiten bekommen.

Reporting und Controlling

Vermutlich der Klassiker unter den Meeting-Formaten. Irgendwer hat irgendwelche Aufgaben aus einem der letzten Termine mitgenommen und berichtet wie weit er gekommen ist. Das ist vor allem dann problematisch, wenn es in generische Meldungen wie "ich bin weiter dran" verflacht. Ein sinnvoller Umgang kann sein, nur dann einen Bericht abzugeben wenn es einen Fortschritt gibt, und den ggf. auf den Hinweis zu beschränken, dass es für alle Interessierten einen separaten Termin gibt.

Ein Ventil bieten

Auch das darf man nicht unterschätzen: für viele Menschen, die sonst weitgehend alleine arbeiten, bieten Meetings die Möglichkeit Luft abzulassen und sich Frust und Sorgen von der Seele zu reden. Diese Funktion kann durchaus hilfreich sein, es besteht aber das Risiko, dass das Ranten und Jammern alle anderen Themen überlagert. Ein sinnvoller Weg kann sein, das bewusst einzuplanen, es aber auch mit (Zeit-)Grenzen zu versehen (hier ein Beispiel dafür).

Kommunizieren

Eine der positiveren Kategorien. Meetings können genutzt werden um Informationen zu verteilen. Wichtig ist dabei, dass es sich nicht nur um Einweg-Kommunikation handelt (dann würde meistens eine Email reichen), sondern durch Nachfragen und Erklären ein besseres Verständnis möglich wird. Ebenfalls hinterfragen kann man, ob alles kommuniziert werden sollte "was gerade so anliegt" oder ob kleinere themenspezifische Termine mehr Focus und Mehrwert stiften würden.

Entscheiden

Vielleicht der idealtypische Meeting-Zweck. Während Vorarbeiten oder Informationsbeschaffung meistens dezentral und asynchron erfolgen können, ist das bei Entscheidungsfindungen (bzw. den dazugehörenden Diskussionen) nur schwer möglich. Alle Beteiligten in einen Raum oder Call zu holen, alle Argumente zu hören und eine Management- oder Mehrheitsentscheidung herbeizuführen ist der bei Weitem effektivste und effizienteste Weg damit umzugehen.

Lernen

Egal ob Retrospektive, Kaizen-Event, Post Mortem, Schulterblick oder Near Miss - es gibt eine grosse Vielfalt von Meetings die dem Thema Lernen gewidmet sind (und idealerweise auch die darauf aufbauende Arbeit an Verbesserungsschritten enthalten). Man kann auch nicht viel dagegen sagen, mit vielleicht einer Ausnahme - aus Fehlern zu lernen ohne daran zu arbeiten (oder daran arbeite zu dürfen) sie in Zukunft zu vermeiden, ist auf Dauer frustrierend. Aber das kommt zum Glück selten vor.

Zusammenarbeiten

Ein Grenzfall, da viele Menschen zwischen Meetings und "der eigentlichen Arbeit" unterscheiden. Zumindest in Kreativ- und Wissensberufen ist diese Trennung aber nicht aufrechtzuerhalten, hier kann es auch Arbeitstermine geben, in denen von Brainstorming bis Mob Programming alles Mögliche stattfinden kann. Und in Remote-Settings ist der Kalendereintrag für eine gemeinsame Arbeit an irgendetwas nicht mehr von einem Meeting zu unterscheiden.

Alleine Arbeiten

In Unternehmen mit vollen Kalendern kann auch diese ungewöhnliche Form von Terminen auftreten: in ihnen (oder in ihrem ersten Teil) findet keine Interaktion zwischen den Teilnehmern statt, stattdessen sind sie ein Blocker um alleine (aber in einem Raum mit den anderen) eine Tätigkeit zu erledigen, die dann für einen weiteren, interaktiven Teil benötigt wird. Das bekannteste Beispiel dürften die PR/FAQ-Dokumente sein, die zu Beginn jedes Meetings bei Amazon von jedem gelesen werden müssen.

Beziehungen entwickeln

Eigentlich ein Nebeneffekt, der vor allem in Umgebungen wichtig ist, in denen sich die Menschen zwischen ihren Meetings nur selten oder gar nicht sehen. Da der nachvollziebare Wunsch nach persönlichem Kennenlernen und Austauschen nicht mehr durch Kantinengespräche o.Ä. erfüllt werden kann, tauchen private Themen hier auch in beruflichen Meetings auf. Ein sinnvoller Umgang damit kann sein, spezielle Meetings nur für diesen Zweck einzurichten.¹

Anerkennung geben und Erfolge feiern

Ob Projekt-Resultate, steigende Kennzahlen oder andere Erfolge - die meisten Menschen freuen sich darüber, ihre Arbeitsergebnisse zeigen zu können, Anerkennung dafür zu bekommen oder anderen Anerkennung dafür zu geben. Auch das kann in Meetings passieren, entweder explizit mit diesem Zweck oder implizit, z.B. wenn bei Ergebnis-Präsentationen bestimmte Beiträge besonders lobend hervorgehoben werden.

Wie immer bei derartigen Aufzählungen liessen sich sicher noch weitere Kategorien finden, die wichtigsten dürften aber enthalten sein. Wie zu Beginn gesagt, sobald die Identifikation dieser Kategorien, bzw. Meeting-Zwecke stattgefunden hat, kann man bei einer Neustrukturiereung versuchen, die Meetings so zu restrukturieren, dass sie nur noch einem oder wenigen dieser Zwecke dienen, um so klarer zu machen, wer wo benötigt wird und wer nicht.

¹Was in vielen Unternehmen zu der Frage führt, ob das bezahlte Arbeitszeit ist oder nicht.

Affordanz

Bild: Pixabay / Benjamin Nelan - Lizenz

Wenn irgendwo eine Methode zur Organisation von Arbeit ausprobiert wird, und das Ergebnis nicht den Erwartungen entspricht, ist eine Aussage meistens nicht fern: die Methode selbst könne man nicht dafür verantwortlich machen, sie wäre nur ein Werkzeug. Bei anderer Benutzung hätte sie auch andere Ergebnisse gebracht. Das ist auch nicht falsch, es ist aber auch nicht völlig richtig, denn bis zu einem gewissen Grad verleiten Methoden ihre Anwender zu bestimmten Handlungen.

Der Fachbegriff für dieses Phänomen lautet Affordanz und lässt sich folgendermassen erklären: zum Gebrauch gedachte Subjekte haben Charakteristika, die bestimmte Anwendungen möglich oder unmöglich, anstrengend oder einfach und effektiv oder ineffektiv machen. Am Beispiel eines Hammers erklärt - das Einschlagen eines Nagels ist möglich, einfach und effektiv, das Eindrehen einer Schraube unmöglich, das Einreissen einer Wand möglich aber anstrengend und ineffektiv.

Auch auf die Methodenwelt lässt sich das Affordanz-Konzept übertragen, schliesslich sind auch Methoden zur Anwendung gedacht. Auch hier ein Beispiel: mit Scrum lässt sich die Arbeit eines einzelnen Software-Entwicklungsteams einfach und effektiv organisieren, der Betrieb einer Fabrik nach Scrum geht gar nicht, und im Regelbetrieb eines Call Center wäre es zwar möglich, aber durch die vielen (und in diesem Kontext unnötigen) Meetings hochgradig ineffektiv. 

Das alles scheint bisher noch wenig bemerkenswert, hat aber an einer Stelle weitreichendere Implikationen als man auf den ersten Blick denken könnte, nämlich dort, wo eine Anwendung möglich aber ineffektiv ist. Der Erfinder des Affordanzkonzepts, der amerikanische Psychologe James J. Gibson, erkannte durch seine Forschung, dass alleine die Möglichkeit einer Anwendung dazu verleitet, sie wahrzunehmen - und zwar auch dann, wenn das wenig sinnvoll ist. Mit seinen eigenen Worten:

The affordances of the environment are what it offers [...], what it provides or furnishes, either for good or ill.

James J. Gibson, The Theory of Affordances, 1979

Und mit diesem Wissen im Hinterkopf können wir die Betrachtung einer Methode als neutrales Werkzeug nicht mehr aufrechterhalten, ihr Angebotscharakter verleitet zu bestimmten Umsetzungs-Arten. Scrum bietet die Möglichkeit, sich durch harte Definitions of Ready in Wasserfall-artige Phasen aufzuteilen? Die Wahrscheinlichkeit ist gross, dass genau das passieren wird. In SAFe lassen sich bis zu drei Hierarchie-Ebenen einrichten? Mit hoher Wahrscheinlichkeit wird genau das passieren. Etc.

Um nicht missverstanden zu werden: Affordanz impliziert keine deterministische Gesetzmässigkeit, es ist also möglich, gegenzusteuern und eine unnötig schwerfällige Methodenumsetzung zu verhindern. Um das tun zu können ist es aber hilfreich, wenn man sich unterschwelliger psychologischer Mechanismen wie eben der Affordanz bewusst ist.

Der agil-industrielle Komplex (II)

Wir müssen noch einmal zu einer der unschöneren Gruppen hauptberuflicher Agilisten kommen, dem agil-industriellen Komplex. Zur Erinnerung: er umfasst Zertifizierungsorganisationen, die von Trainings-Anbietern finanziert werden, welche von Unternehmensberatungen für wirkungslose Pseudo-Transformationen instrumentalisiert werden, die wiederum von Unternehmen beauftragt werden, deren interne Prozesse eher auf schnelle Scheinerfolge als auf nachhaltige Veränderungen ausgelegt sind.

Die problematischen Auswirkungen dieser Kommerzialisierungs-Maschinerie dürften mittlerweile in allen Bereichen des agilen Arbeitens spürbar sein, hier soll es aber um eine besonders folgenschwere gehen: die Aufblähung der ursprünglisch schlanken agilen Frameworks zu umfangreichen, schwergewichtigen Regelwerken, die von ihren (oft unfreiwilligen) Anwendern eher als Belastung und weniger als Hilfe empfunden werden - und schon gar nicht als Erleichterung.

Die Hauptursache dieser Entwicklung sind einmal mehr die Zertifizierungen, die die Haupt-Einkommensquelle und den Haupt-Ergebnistyp des agil-industriellen Komplexes bilden. Der für sie zu entrichtende drei- bis vierstellige Preis muss gerechtfertigt werden, was bedeutet, dass in allen von ihnen relevantes Wissen vermittelt werden muss. Relevant wird das durch seinen offiziellen Status, und um den zu erreichen, muss das Wissensgebiet (halb-)offizieller Teil eines Frameworks werden.

Wie diese Aufblähung aussieht, kann sich von Fall zu Fall unterscheiden, der offensichtlichste Weg ist aber, möglichst viel in den offiziellen Umfang eines zu vermarktenden Vorgehensmodells aufzunehmen. Das bekannteste Beispiel dafür ist SAFe, dessen Dokumentation mittlerweile eine deutlich dreistellige Seitenzahl umfassen dürfte, auch Disciplined Agile entwickelt sich seiner Übernahme durch PMI erkennbar in diese Richtung.

Einen anderen Weg sind Scrum Alliance, Scrum.org und Kanban University gegangen, deren eigentliche Regelwerke (Scrum Guide und Kanban Guide) sind mit ca 10 Seiten noch immer sehr komprimiert. Was bei ihnen aber dazukommt ist eine grosse Menge an "offiziellem" Zusatz-Material für die sinngemässe Auslegung, Anwendung oder Einbettung in andere Kontexte (z.B. Scrum + OKRs oder Kanban + Legal), wodurch der Gesamtumfang auch hier erheblich angewachsen ist.

Eine dritte Variante Kommerz-getriebener Aufblähung kann man schliesslich bei Frameworks beobachten, die keiner Organisation zugeordnet sind, sondern gewissermassen Open Source. Hier erfinden Beratungen und Schulungsanbieter ständig neue Elemente, kopieren sie voneinander und erklären sie zur notwendigen "best Practice". Der bekannteste derartige Fall sind zur Zeit die OKRs, deren Kommerz-Variante stark mit Meetings, Rollen und Regeln überfrachtet ist.

Eine spezielle und in allen Varianten vorhandene Art der Aufblähung besteht schliesslich in Form von prozessunterstützender komerzieller Software, die im Rahmen vieler "agiler Transitionen" den Anwendern der agilen Frameworks zwingend vorgeschrieben wird (Beispiele sind Jira für Scrum oder Workboard für OKRs). Da in diesen Kontexten das Vorgehen und die Software untrennbar miteinander verknüpft sind, wird das Wissen um die Software-Funktion de facto Teil des Methodenwissens.

Wie oben erwähnt, für die Anwender ist eine derartige Aufblähung in der Regel eine Belastung. Zum einen dadurch, dass alleine die Aneignung und das in Erinnerung halten eines derartig umfangreichen Wissensumfangs mit Aufwand und Anstrengung verbunden ist, zum anderen dadurch, dass der aufbauend darauf gestaltete Arbeitsalltag von zahlreichen Pflicht-Meetings, komplizierten Regeln und restiktiven Workflows der jeweiligen Anwendungen geprägt ist.

Häufige Reaktionen auf diese Belastung sind Frustration, Dienst nach Vorschrift, der heimliche Aufbau von "Schattenprozessen", mit denen sich die ungeliebten offiziellen Methoden umgehen lassen (deren unnötige Aufblähung den meisten gar nicht bewusst ist) oder ganz einfach der Verlust von Freude an der Arbeit und der Identifikation mit dem eigenen Unternehmen. Konsequenzen deren sich jeder bewusst sein sollte, der sich mit dem agil-industriellen Komplex einlässt.

Um mit einer positiven Note zu enden: es gibt einen Ausweg aus dieser Situation, und der besteht ganz schlicht daraus, zuerst aufzuzeigen, wie die jeweiligen agilen Frameworks eigentlich gedacht sind, und was alles nicht notwendig ist um sie so wie gedacht einzusetzen. Dieser überschüssige Teil, der z.B. im Fall von Kanban oder OKRs alle (!) neu eingeführten Rollen, Meetings und Software-Tools umfassen kann, kann einfach weggelassen werden - und nur dadurch wird bereits vieles einfacher und schneller.

Natürlich braucht es auch dazu in der Regel die Unterstützung von Experten, was eine wichtige Frage aufwirft: wie lässt sich sicherstellen, dass nicht auch die dem agil-industriellen Komplex angehören? Die einfache Antwort: man sollte nur diejenigen in die nähere Auswahl nehmen, deren Lösungen werder Zertifizierungen, noch prozessunterstützende Software, noch umfangreiche Regelwerke oder zahlreiche neue Rollen enthalten. Less is more.

Who Does What by How Much?

Zwei der bekanntesten internationalen OKR-Experten sind Jeff Gothelf und Josh Seiden, die seit etlichen Jahren als Berater, Buchautoren und Konferenz-Speaker bekannt geworden sind. Für die Agile India Conference haben sie nicht nur ihre Sicht auf das Thema OKRs zusammengefasst, sondern sind in einer darauf folgenden Diskussion auch auf verschiedene weiterführende Aspekte eingegangen, wodurch ihre Sicht auf dieses Thema nochmal besser nachvollziehbar wird.

Was man beim Ansehen des Videos im Hinterkopf behalten sollte: es gibt nicht die eine richtige Art OKRs zu verfassen, sondern viele verschiedene Varianten, die parallel nebeneinander koexistieren (siehe hier). Gothelf und Seiden haben starke (und fundierte) Meinungen, und das was sie sagen dürfte dem State of the Art entsprechen. Andere Umsetzungen sind aber nicht falsch - nur anders.