Donnerstag, 12. September 2024

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


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.



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

Montag, 9. September 2024

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.


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.

Donnerstag, 5. September 2024

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.

Dienstag, 3. September 2024

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.