Silent Code

Es ist ja die besinnliche Zeit - passend dazu gibt es besinnliche Musik. 

Überwintern

Bild: Pixabay / Fabio Piccini - Lizenz

Es gibt Phasen, in denen machen agile Transitionen eine Pause. Ein neues Management kommt, will durchregieren und alles kontrollieren, langfristige Detailplanungen machen, die Arbeit in Gewerke oder Wasserfall-Stufen aufteilen, Herrschaftswissen aufbauen und dergleichen mehr. Das ist unschön, zumindest in grossen Organisationen aber temporär - der nächste Management-Umschwung kommt so sicher wie der nächste Frühling. Irgendwann gibt es dann wieder Transparenz und Selbstorganisation.

Die typische Reaktion von Konzernmitarbeitern mit Neigung zu solchen Arbeitsweisen ist es, in einen "Überwinterungszustand" zu gehen. Man zieht sich von der Vorderbühne der Organisation zurück, sucht sich einen geschützten Raum (Projekte, Abteilungen, etc), in dem der Veränderungsdruck erträglich erscheint, und bildet dort mit anderen gleichgesinnten eine Schläferzelle, die wieder aktiviert werden kann, wenn der Management-Wind sich erneut dreht.

Derartige Überwinterungen werden häufig vom Management eher kritisch gesehen, da hier ein Unterlaufen der aktuellen Unternehmensführung gesehen wird. Man kann aber auch eine positive Sicht darauf haben - wer in die Überwinterung geht, macht die Bühne frei für andere, die vom aktuellen Vorgehensmodell überzeugter sind, gibt ihnen die Chance sich zu beweisen, bewahrt aber die eigene Expertise, für den Fall, dass sie doch gebraucht wird.

Die spannende Frage, die sich daraus ergibt, ist aber, wie der Expertisen-Erhalt in einer Überwinterungs-Phase stattfinden kann? Der offizielle Arbeitsmodus ist schliesslich ein anderer, so dass Learning by Doing (oder Sustaining by Doing) nicht mehr so einfach möglich sind wie vorher. Und auch das Budget für Weiterbildungen und Schulungen wird jetzt für andere Zwecke eingesetzt. Hier sind einige praxiserprobte Ideen wie das gelingen kann.

Agile Ausgestaltung anderer Termine und Prozesse

Auch in einem formal nicht-agilen Arbeits-Setting spricht nichts dagegen, den Tag mit einer Morgenrunde zu beginnen, in dem jeder ein Update dazu gibt woran er gerade arbeitet, wie er vorankommt oder wo er Hilfe brauchen könnte. In Status-Meetings kann man Feedback integrieren, in Abteilungs- oder Projektmeetings Verbesserungsideen, etc., etc.

Arbeit an technischer Exzellenz

Ein spannender Fall von notwendiger und hinreichender Bedingung: man kann ohne technische Exzellenz nicht agil arbeiten, aber ohne agil zu arbeiten technische Exzellenz vorantreiben. Von Clean Code über hohe Testabdeckung bis hin zu klarer Architektur - das alles hilft in jedem Arbeitsmodus, und es kann später wieder eine gute Ausgangsbasis für iterativ-incrementelles Arbeiten sein.

Lösungsorientiertes Vorschlagswesen

Selbst wenn man in einem hierarchisch organisierten Umfeld vieles nicht selbst entscheiden kann - Vorschläge machen kann man immer. Und wenn die zum Gegenstand haben, dass sich irgendetwas mit vertretbarem Umwand so umstellen lässt, dass es schneller, billiger oder in besserer Qualität fertig wird, dann ist die Wahrscheinlichkeit gross, dass man Gehör findet.

Nutzung leichtgewichtiger Tools

Es müssen nicht immer Jira und Miro sein, in fast jeder Firma finden sich mittlerweile Tools, die kollaboratives Arbeiten ermöglichen. Um ein einfaches Beispiel zu nennen: geteilte Präsentationen in Google Docs oder Microsoft 365 können mittlerweile in Meetings ähnlich genutzt werden wie Miro oder Conceptboard (siehe hier). Man muss nur bereit sein, etwas herumzuprobieren.

Feedback auf dem kurzen Dienstweg

Nur weil es keine Sprint Reviews gibt heisst das nicht, dass man mit Kollegen und internen Anwendern nicht sprechen kann. Vom schnellen Abstimmungscall über gemeinsames Kaffeetrinken bis hin zum Sitzen an benachbarten Arbeitsplätzen (wenn es im Büro flexible Platzwahl gibt) ist vieles möglich, um einfache und schnelle Kommunikation möglich zu machen.

Über den Tellerrand blicken

Auch über die unmittelbare eigene Arbeitsumgebung hinaus gibt es Möglichkeiten, die eigene "agile Expertise" zu erhalten und auszubauen. Geld für Konferenzen und Schulungen mag keines da sein, aber in fast jeder grösseren Stadt gibt es einen Scrumtisch, einen Lean Coffee oder ähnliche Meetups auf denen man sich austauschen und dazulernen kann.

Wie immer bei derartigen Listen ist es auch bei dieser so, dass sie noch lange weitergehen könnte, die Grundidee ist aber klar: auch in einem offiziell nicht-agilen Arbeitsumfeld lässt sich viel machen, um auch während einer Überwinterungsphase noch agil arbeiten und lernen zu können. Gegebenenfalls nicht mit den sonst üblichen Begriffen, Tools und Methoden, aber orientiert an den darunterliegenden Ideen und Prinzipien. Und das ist schliesslich das eigentlich Wichtige.

Und ganz nebenbei: auch wenn es länger dauern sollte bis auch offiziell wieder agil gearbeitet werden kann - die Dinge die weiter oben stehen machen auch jeden anderen Arbeitsmodus effektiver. Ein weiterer Grund dafür, sie zu tun.

The agile Bookshelf: Range

Falls jemand noch ein Buch zum Verschenken sucht - Range: Why Generalists Triumph in a Specialized World ist sehr empfehlenswert. Geschrieben wurde es vom amerikanischen Journalisten David Epstein, und er hat mit ihm das Kunststück vollbracht, ein Werk zu schreiben, das für gleich mehrere unterschiedliche Bereiche relevant ist: Erziehung, Karriereplanung, Persönliche Entwicklung, Personalentwicklung, Organisationsentwicklung und mehr.

Der Entstehungshintergrund des Buches ist eine zu Beginn des 21. Jahrhunderts stattfindende Debatte darüber, ob eine möglichst frühe, und idealerweise bereits in der Kindheit beginnende, Spezialisierung der beste Weg zu überdurchschnittlichen Leistungen in einem Wissensgebiet oder Tätigkeitsfeld ist. In der allgemeinen Wahrnehmung wurde das eher bejaht, und mit Verweisen auf "Wunderkinder" wie Tiger Woods oder Wolfgang Amadeus Mozart belegt.

In dieser Zeit fiel Epstein bei seinen Recherchen zu seinem vorherigen Buch The Sports Gene auf, dass es zahlreiche Fälle von Spitzensportlern gab, deren Karriere genau gegenteilig verlief - bis in in ihre jungen Erwachsenenjahre wechselten Sie zwischen verschiedenen Sportarten, bevor sie sich für eine entschieden. Und sie benannten diese grosse Bandbreite nicht etwa als ein Hindernis für ihren Erfolg, sondern sogar als einen der wichtigsten Erfolgsfaktoren.

Aufmerksam geworden begann er zu recherchieren, ob diese Abweichungen von der angenommenen Wahrheit der sinnvollen frühen Spezialisierung auch ausserhalb des Sports auftraten, und wurde auch dort fündig. Egal ob in Wirtschaft, Wissenschaft, Kunst oder anderen Bereichen, überall gab es Karrieren, in denen sich Schwerpunkte erst spät oder nur temporär herausgebildet hatten, von Charles Darwin über Albert Einstein und Roger Federer bis Mark Zuckerberg.

Alleine die Erkenntnis, dass frühe Spezialisierung nicht der beste oder einzige Weg zum Erfolg ist, war bereits bemerkenswert, darüber hinaus fand Epstein aber einen Bereich, in dem vielfältig, generalistisch oder fachfremd ausgebildete Menschen bessere und schnellere Lösungen fanden als die, die sich schon früh auf nur ein Thema focussiert hatten - bei neuartigen oder komplexen Problemen. Hier war es offensichtlich von Vorteil, einen breiten Erfahrungshorizont zu haben.

Range: Why Generalists Triumph in a Specialized World ist eine Leseempfehlung, weil es eine seltene Kombination verschiedener Aspekte ist. Es regt zum Denken an und hinterfragt scheinbare Gewissheiten, es ist mit zahlreichen Fakten und Belegen untermauert, es ist flüssig und unterhaltsam geschrieben und es enthält Anstösse, die man im  eigenen Berufs- und Privatleben umsetzen kann.

Trust as Infrastructure

Trotz aller künstlichen Intelligenz - am Ende sind es Menschen, die Software erstellen. Auf diese Prämisse baut Bryan Cantrill seinen Vortrag auf, in dem er das Vertrauen in die Menschen in den Software-Entwicklungsorganisationen zu einer zentralen Infrastruktur der IT-Industrie erklärt. Dieses Vertrauen muss gegeben sein, da in einem komplexen Umfeld vollständige Kontrolle nicht möglich ist.

Spannend ist dabei, dass Cantrill das Thema Vertrauen von seiner verbreitetsten Interpretation löst, nämlich dem, dass es eine auf einzelne Personen bezogene positive Erwartung ist. Stattdessen arbeitet er heraus, dass es in Organisationen oder Bewegungen (wie der Open Source-Bewegung) ein ganzes Geflecht verschiedenster Vertrauensbeziehungen innerhalb zwischen verschiedenen Gruppen geben muss, wenn irgendetwas funktionieren soll.

Wie der Staat wieder handlungsfähig wird (IV)

Manchmal finden die spannenden Sachen direkt vor der eigenen Haustür statt, wie in dieser Woche die Fachkonferenz Public Sektor und Beratung in Bonn. Vertreter verschiedener grosser und kleiner Beratungsfirmen (u.a. meiner) könnten hier mit Experten aus dem Bundesministerium für Digitales und Staatsmodernisierung, dem Landesrechnungshof, dem Bundesverwaltungsamt und anderen Behörden diskutieren, wie die öffentlich Verwaltung effektiver arbeiten und beraten werden kann

Ein Thema, das sich dabei durch fast alle Vorträge und Diskussionen zog, war dabei das staatliche Einkaufswesen, bzw. dessen Unzulänglichkeiten. Mehrere Sprecher gingen sogar soweit, die hier nötigen Reformen zum entscheidenden Erfolgsfaktor der Verwaltungsmodernisierung zu erklären. Da er einen derartig prominenten Status zu haben scheint, lohnt sich ein näherer Blick auf die Konferenz-Erkenntnisse - was liegt denn laut Expertenmeinung im Argen im staatlichen Einkauf?

Beauftragende Stellen und Einkaufsabteilungen sind oft schlecht abgestimmt

Einer der schlimmsten Punkte direkt zu Beginn: der Einkauf und die Menschen für die etwas eingekauft wird reden in vielen Fällen zu wenig miteinander. Wenn z.B. eine kleine Behörde einen IT-Administrator braucht, fragen viele Einkäufer nicht nach für welche Systeme oder mit welchen benötigten Fähigkeiten, sondern googlen nur danach, was man dafür können müsste, und übernehmen das dann unverändert.

Viele Ausschreibungen sind inhaltlich irreführend oder sogar falsch

Vor diesem Hintergrund ist es wenig überraschend, dass viele eingekaufte Leistungen komplett am Bedarf vorbeigehen. Ein Beispiel das auf der Konferenz genannt wurde war eine Behörde, die auf der Suche nach jemandem war, der in der Poststelle physische Werbesendungen aussortieren sollte. Beauftragt wurde jemand, der Spezialist für Spamfilter in Email-Programmen war.

Zusammengehörende Gewerke werden separat ausgeschrieben

Dieser Missstand hat einen erkennbaren Taylorismus-Ursprung. Statt zusammengehörende Leistungen gemeinsam zu beauftragen, werden sie oft künstlich getrennt und separat vergeben. Ein Beispiel war ein IT-System das von einem Dienstleister kontinuierlich weiterentwickelt wurde, während ein zweiter die Nutzer darin schulen sollte - ohne zu wissen, was daran zuletzt geändert worden war.

Die Ausschreibungen sind oft unnötig detailliert

Hier kann man zumindest den Wunsch unterstellen, genau das Richtige einzukaufen. In der Realität kommt es aber immer wieder zu einem absurden Detailgrad, etwa dann, wenn ein Dienstleister nicht nur für alle Mitglieder seines Teams die Schul- und Hochschulzeugnisse angeben soll, sondern auch an welchen Kalendertagen diese Zeugnisse jeweils ausgestellt wurden.

In vielen Ausschreibung stehen unrealistische Anforderungen

In diesen Fällen zeigt sich, wie viele Detailkenntnisse die jeweiligen Einkäufer haben. Immer wieder genannte Klassiker sind die Anforderungen nach fünf- oder zehnjähriger Erfahrung mit Technologien, die es noch gar nicht so lange gibt (z.B. modernen LLM-Anwendungen). Die Zahl der Fälle, in denen wegen derartiger unerfüllbarer Anforderungen kein einziges Angebot eingeht, ist anscheinend beträchtlich.

Selbst kleine Formfehler können zum Ausschluss führen

Ein Beispiel, dass ich selbst erlebt habe: beim Nachfassen wegen eines abgegebenen Angebots wurde mir mitgeteilt, dass wir aussortiert worden waren, da der angebotene Berater keine PSM II-Zertifizierung hatte. Was in unseren Unterlagen stand - er hatte eine PSM 2-Zertifizierung. Inhaltlich das Selbe, aber da wir arabische statt römischer Zahlen benutzt hatten, waren wir draussen.

Die Vergabekriterien sind oft sehr unklar

Um mit dem Positiven zu beginnen: es wird oft versucht, den Entscheidungsprozess transparent zu machen, etwa indem angegeben wird, durch welchen Faktor wieviele Bewertungspunkte zu erreichen sind. Bei einer Angabe wie "Konzept: 20 Punkte" (ein reales Beispiel) bleibt aber völlig offen, anhand welcher Kriterien das einzureichende Konzept bewertet wird.

Zu häufig gibt nur der Preis den Ausschlag

In der Theorie ist zwar der Preis nur eines von mehreren Entscheidungskriterien, in der Realität vieler Beratungs-, Bau- und IT-Projekte wird aber sehr häufig das billigste Angebot angenommen, das gaben die Behördenvertreter auf der Konferenz zu. Da niedrige Preise aber vor allem durch Niedriglohn-Personal und billiges Material möglich werden, bedeutet das meistens auch schlechte Qualität der Ergebnisse.

Ausschreibung ≠ Beauftragung

Für die an Ausschreibungen teilnehmenden Unternehmen einer der grössten Frustfaktoren: anders als man denken könnte, ist der Gewinn einer Ausschreibung oft nicht mit einer Beauftragung gleichzusetzen. Man gewinnt nur einen Rahmenvertrag, ob in dessen Rahmen wirklich die eigentliche Beauftragung stattfindet ist unklar. Viele Behörden schreiben "auf Vorrat" aus, nicht wegen akutem Bedarf.

Die Liste liesse sich noch ewig fortsetzen, auf der Konferenz wurden noch zahlreiche weitere Ärgernisse genannt, von ausufernden Dokumentationspflichten über in der Realität nur schlecht funktionierende juristische Konstruktionen wie das 3 Partner Modell/3PM bis zu dreisten Forderungen wie einer unbezahlten Einarbeitungszeit. Aber genug gejammert, wie ginge es besser?

Worüber sich fast alle Konferenzteilnehmer einig waren: zusätzliche Vorschriften, Richtlinien und Verbote für die staatlichen Einkaufsabteilungen wären keine Lösung, sondern würden nur zu noch mehr Bürokratie führen. An vielen Stellen wäre es vielmehr sinnvoll, der Regulierungsumfang zurückzufahren, da er ein wesentlicher Grund für das Ausufern der Einkaufsprozesse ist.

Ein zielführenderer Ansatz wäre eine bessere Qualifizierung und Begleitung der staatlichen Einkaufsabteilungen. Diese sind bisher in vielen Fällen von Umfang und Komplexität der Materie überfordert. Man denke z.B. an eine Kleinstadt, die durch die Übernahme einer aufgegebenen Kaserne ein Bauprojekt noch nie dagewesener Grösse stemmen muss. Woher soll dafür die Kompetenz kommen?

Für die Qualifizierung und Begleitung der Mitarbeiter in derartigen Behörden gibt es tatsächlich bereits mehrere staatliche Stellen, die als "Inhouse Consulting" der öffentlichen Verwaltung funktionieren, etwa das Beratungszentrum des Bundes oder das Auftragsberatungszentrum Bayern. Ein erster Schritt wäre es, diese relativ unbekannten Angebote bekannt zu machen.

Auch weitere Ideen gibt es, etwa den auf der Fachkonferenz Public Sektor und Beratung vorgestellten "Berater-Führerschein". Angedacht ist, dass diese Weiterbildung für jeden verpflichtend wird, der Beratungsaufträge ab einer bestimmten Höhe vergeben darf. Die Idee ist, durch ihn nicht nur Wissen über den Einkauf, sondern auch über die Steuerung und Effizienzmessung von Beratern zu vermitteln.

Die Gemeinsamkeit derartiger Ansätze: den auf diese Art qualifizierten Einkäufern wird danach grösserer Freiraum gelassen, in dem Vertrauen, dass ja auch sie selbst ein Interesse an einer möglichst reibungslosen und erfolgreichen Abwicklung ihrer Einkaufsprozesse haben. Und als Seiteneffekt wird der Beruf dadurch auch attraktiver.

Siehe auch: 

Steve Blank: The Department of War Just Shot the Accountants and Opted for Speed

Agile Bauprojekte (IX)

Bild: Pexels / Javier Gonzalez - Lizenz

Der grosse Hype um das Thema Künstliche Intelligenz (KI/AI) ist nicht mehr ganz so ausgeprägt wie er es kurz nach dem Markteintritt von ChatGPT & Co war. Eigentlich gut so, denn jetzt kann man mit etwas nüchternerer Betrachtung bewerten, wo dadurch ein wirklicher Mehrwert erbracht wird. Einer der Bereiche in denen das stattfindet ist das Baugewerbe, und die Technik die hier im Einsatz ist, trägt einen relativ unbekannten Namen: Parametric Design.

Kurz zum Kontext: beim Bauen von Gebäuden kann man anders als beim Maschinen- und Gerätebau nicht mit einem Prototypen beginnen, aus ihm lernen und einen besseren bauen. Was einmal steht lässt sich nur teuer wieder abreissen. Die ersten Ergebnisse (wenn man von Design-Skizzen absieht) bestehen hier daher aus Berechnungen der Statik und der Materialbelastbarkeit der zukünftigen Gebäude. Erst wenn die fertig sind, kann das eigentliche Bauen beginnen.

Da diese Berechnungen aufgrund der zahlreichen Parameter (u.a. Höhe, Breite, Grösse der Innenräume, Material, Untergrund, Wetter) sehr umfangreich sind, führten sie bis ins 21. Jahrhundert fast durchgehend zu langen vorgelagerten Planungsphasen. Waren diese einmal abgeschlossen, war ein nachträgliches Anpassen kaum möglich (und wenn es erzwungen wurde sehr teuer, wie im Fall des Berliner Flughafens). Das Vorgehen war also eher Anti-Agil.

Mit dem Aufkommen von KI-Anwendungen hat sich das geändert, vor allem aufgrund des genannten parametrischen Designs. Bei ihm werden nur bestimmte Rahmenbedingungen (Parameter) fest vorgegeben, etwa Stabilität und zu tragende Last. Das System wird dann angewiesen, unter Respektierung dieser Vorgaben Lösungsvarianten für einen Design-Entwurf zu erstellen. Das kann dann deutlich schneller erfolgen als durch einen Menschen.

Zu Beginn wurde diese Technik vor allem für Gebäudepläne eingesetzt, bei denen eine Berechnung durch Menschen extrem lange gedauert hätte, die aber auch mit KI noch langwierig waren (z.B. bei den Setas de Sevilla von 2011). Mit dem Fortschritt in der KI-Technologie ist das aber noch einmal deutlich beschleunigt worden - bei aktuellen Vorhaben, wie dem West Bund Convention Center in Shanghai, konnte eine komplette Neuberechnung im wahrsten Sinn des Wortes über Nacht erfolgen.

Damit ist agiles Arbeiten jetzt auch in der frühen Planungs- und Berechnungsphase eines Bauvorhabens möglich. In wenigen Tagen können umsetzbare Entwürfe entworfen, berechnet und vorgestellt werden, und das bei Bedarf mehrfach nacheinander oder parallel zueinander. Und wenn dann beim eigentlichen Bauen noch modulare Konstrktion oder 3D-Druck zum Einsatz kommen, kann das Bauen von Gebäuden ähnlich schnell möglich werden wie das von Software.

Die Doppel-Organisation

Ich bin schon seit Langem der Meinung, dass sich viele Konzepte der Politikwissenschaft auch für die Analyse grosser Organisationen nutzen lassen und habe das auch schon mehrfach getan (z.B. hier, hier, hier und hier).  Ein weiteres, das ich für hilfreich halte ist das der doppelten Organisation, abgeleitet von der 1940 verfassten Studie Der Doppelstaat des deutsch-amerikanischen Juristen und Politikwissenschaftlers Ernst Fraenkel.

Bevor es damit losgeht macht der Hintergrund von Fraenkels Werk aber eine Klarstellung nötig - er benutzte es um die öffentliche Verwaltung des 3. Reiches zu beschreiben. Eine Übertragung auf moderne Organisationen soll explizit niemanden der dort arbeitenden Menschen mit einem Nationalsozialisten gleichstellen. Es geht vielmehr um das Aufzeigen von Wirkungszusammenhängen, die in bestimmten Kontexten auftreten können.

Das von Fraenkel identifizierte Grundmuster besteht daraus, dass es in bestimmten Fällen dazu kommen kann, dass in der staatlichen Verwaltung zwei grundsätzlich verschiedene Organisations-Prinzipien parallel zueinander bestehen und sich zum Teil überlagern: der statische Normenstaat und der dynamische Massnahmenstaat. Sie treten dann gleichzeitig auf, wenn versucht wird, wesentliche Ziele der Verwaltung zu verändern, ohne ihre elementaren Funktionen zu beschädigen.

Der Normenstaat, bzw. seine Angehörigen, haben dabei das Interesse, die Einhaltung der bestehenden Regeln und Standards sicherzustellen, und so dafür zu sorgen, dass das Verwaltungshandeln verlässlich, planbar, überprüfbar und nachvollziehbar ist. Das ist auch grundsätzlich richtig und wichtig, kann aber bei übermässigem Beharren auf dem Ist-Zustand das Risiko mit sich bringen, dass notwendige Veränderungen verwässert, lange verzögert oder schlimmstenfalls sogar unmöglich gemacht werden.

Um diese Erstarrungseffekte zu verhindern ist es notwendig, den Normenstaat von Zeit zu Zeit zu reformieren, und zwar so, dass auf der einen Seite notwendige Veränderungen zulässig und machbar werden, auf der anderen Seite aber so viel Berechenbarkeit, Verlässlichkeit und Überprüfbarkeit übrig bleiben, dass ein Abgleiten in Chaos und Willkür verhindert wird. Dieser Weg ist sinnvoll, aber langwierig, anstrengend und in seinen Ergebnissen von Kompromissen geprägt.

Wenn jetzt auf den Entscheidungspositionen Menschen sitzen, denen dafür die Geduld oder die Kompromissbereitschaft fehlen, ist es verlockend, eine "Abkürzung" zu nehmen: parallel zum Normenstaat wird eine zweite Struktur aufgebaut, die frei von Beschränkungen, Hemmungen und langwierigen Aushandlungsprozessen Veränderungen anstossen und durchsetzen soll. Diese zweite, parallele Struktur ist der Massnahmenstaat.

Wenn der Massnahmenstaat in der Lage ist, den Normenstaat im Konfliktfall ausser Kraft zu setzen, tut er das allerdings nicht flächendeckend sondern nur punktuell. Die anderen Teile werden intakt gelassen, da sie wesentliche Funktionen erfüllen, wie etwa die Instandhaltung von Infrastruktur und das Generieren von Einkommen. Es kommt daher zu dem oben erwähnten Nebeneinander (und z.T, Gegeneinander) der beiden unterschiedlichen Erscheinungsformen.

Die Parallelen zu vielen Grossorganisationen sind offensichtlich. Auch hier kommt es in Notsituationen, nach Managementwechseln oder in sonstigen Sonderzuständen immer wieder dazu, dass diejenigen offiziellen Prozesse, die gerade als bremsend wahrgenommen werden, "kurzgeschlossen" werden, um Entscheidungen schneller durchzusetzen (man spricht dann auch vom "Durchregieren"). Da andere Prozesse unverändert weiterbestehen, entsteht auch hier eine Doppel-Organisation.

Auf den ersten Blick mag das wie ein notwendiges Übel erscheinen, das in Kauf genommen werden kann um Handlungsfähigkeit herzustellen, allerdings führt es zu einem weiteren Problem, dass auch Fraenkel schon im Doppelstaat identifizierte: das Neben- und Gegeneinander von Normen und Massnahmen führt zu Konflikten und Blockaden, zu deren Beseitigung neue Massnahmen ergriffen werden, die zu neuen Blockaden führen, wodurch neue Massnahmen ergriffen werden, etc, etc.

Das in vielen kriselnden Unternehmen anzutreffende Phänomen erstaunlich vieler und erstaunlich wirkungsloser Beschleunigungsprogramme, Steuerungsgremien, Task Forces, und  Delivery Initiativen lässt sich mit dem Vorhandensein einer derartig wuchernden Doppel-Organisation erklären, die durch eine kontinuierliche Verschlimmbesserung von Prozessen ständig ihre eigenen Ziele verfehlt und gleichzeitig unbeabsichtigt ihre Umgebung behindert und verunsichert.

Wenn es nicht dazu kommen soll, ist es der bessere Weg, sich auf das strukturierte aber langwierige, anstrengende und in seinen Ergebnissen von Kompromissen geprägte Reformieren der gegebenen Normen einzulassen. Es wird zwar nur selten zu schnellen Lösungen führen, dafür werden die Ergebnisse konsistenter, stabiler, beständiger und am Ende konfliktfreier sein. Oder mit anderen Worten: statt der Doppel-Organisation kann eine in sich stimmige neue Organisation entstehen.

Kommentierte Links (CXXXIII)

Grafik: Pixabay / Brian Penny - 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.

Steve Blank: The Department of War Just Shot the Accountants and Opted for Speed

Als externer Berater oder Mitarbeiter erlebe ich die lähmenden Auswirkungen klassischer Einkaufsprozesse regelmässig anhand der eigenen Beauftragung, die sich dadurch erstaunlich lange verzögern kann (der "Rekord" liegt bei mehreren Jahren). Angesichts derartiger Zustände sind Initiativen wie die von Steve Blank hier vorgestellte nur zu begrüssen. Ich hoffe, dass sie in Deutschland wahrgenommen und als Inspiration genutzt wird.

John Cutler: 'Functional' Feature Factories Explained

Der nächste Teil einer bemerkenserten Serie. 2016: 12 Signs You’re Working in a Feature Factory. 2019: 12 Signs You’re Working in a Feature Factory — 3 Years Later. 2022: Scaled Feature Factories. 2024: How to Learn and Practice Product Management in a Feature Factory. und jetzt das hier: 'Functional' Feature Factories Explained. Man kann gespannt sein, wie viele weitere Teile John Cutler noch verfassen wird - hoffentlich einige. 

Maik Seyfert: Shadow Structures - The Unofficial Systems That Actually Run Your Organization

Informelle Strukturen und Prozesse, organisatorische Hinterbühne, Realstruktur (als Gegenstück zur Formalstruktur) und vieles mehr - das was Maik Seyfert hier als "Schattenstruktur" beschreibt hat viele Namen und Erscheinungsformen. Was er richtigerweise hervorhebt: man kann sie weder verbieten noch erfolgreich bekämpfen. Um eine Organisation erfolgreich führen und verändern zu können, muss man sich auf sie einlassen und sie einbinden.

Kent Beck: Why Does Development Slow?

Das Gefühl kennt jeder, der Software-Entwicklungsorganisationen eine Zeit lang begleitet hat - mit der Zeit geht die Geschwindigkeit in der neue Features erstellt werden mehr und zurück, bis irgendwann selbst kleine Änderungen erstaulich lange dauern. Kent Becks "Exhale, Then Inhale"-Ansatz will das ändern, indem er regelmässig Zeit und Ressourcen für Identifikation und Beseitigung der verlangsamenden Faktoren vorsieht. Etwas, das hochgradig sinnvoll klingt.

Christina Wodtke: The Premortem - Your Product’s Autopsy Before Launch

Der Begriff sagt es eigentlich schon aus, wenn man ein Post Mortem eines Vorhabens durchführt, ist es zu spät um aus dem Gelernten noch Änderungen abzuleiten. Christina Wodtkes Pre Mortem setzt nicht nur zeitlich früher an, sondern zeigt auch vier Faktoren auf, die für Produktentwicklungen tödlich sein können, und die deshalb möglichst früh identifiziert und behandelt werden sollten - Technical Failures, Market Failures, Ethical Failures und Regulatory & Environmental Changes.

Ein Bild sagt mehr als 1000 Worte (LIII)

Angefangen hat alles irgendwann mit dem relativ schlichten Comic-Bild 'Dependencies' auf XKCD, das bald zu einem häufig geteilten Meme geworden ist. Das hat dann zahllose Adaptionen und Remixes inspiriert, unter anderem dieses, dieses, dieses, dieses, dieses, dieses und (besonders schön) dieses. Das hier ist meine Version.

Intrapreneur (II)

Wenn man sich auf die Betrachtungsweise einlässt, Organisationsentwicklung als ein Produkt oder einen Service zu betrachten, wird man sie deutlich besser verstehen und beeinflussen können. Das gilt sowohl für die Art wie an ihr gearbeitet wird, als auch für die Wahrnehmung und Behandlung von wichtigen Stakeholdern. Und da sich unter diesen ganz besonders höhere Manager befinden, ist die frage naheliegend - was treibt die eigentlich um?

Eine der wichtigsten Antworten darauf ist: das Geld. Genauer gesagt, die Fähigkeit der Organisation, durch profitables Arbeiten Geld zu erwirtschaften, schliesslich ist es genau das, woran Manager in der Regel von noch höheren Managern, Aktionären, Eigentümern oder Aufsichtsräten gemessen werden. Und mit diesem Gedanken im Hinterkopf ergibt die Ablehnung selbstorganisierter Teams durch viele Manager einen neuen Sinn - dahinter steckt oft die Sorge vor nachlassender Wirtschaftlichkeit.

Dass diese Sorge nicht völlig unbegründet ist, kann man bei vielen in die Selbstorganisation startenden Teams beobachten. Roadmaps und Zeitpläne? Budgetierung und Kostendeckel? Das in Frage stellen von technischem Perfektionismus? All das gilt plötzlich als Teil eines überkommenen Top Down-Managements. Dass durch diese Ablehnung die Profitabilität von Features und Produkten leidet, wird nicht gesehen - und die Verwunderung ist gross, wenn das Management auf einmal interveniert.

Wer es nicht so weit kommen lassen will sollte sich auf ein mittlerweile nicht mehr neues Konzept besinnen, das der Intrapreneurship, womit die Haltung von Angestellten gemeint ist, nicht nur wirtschaftliches Denken und Handeln anzustreben, sondern auch bereit zu sein, sich das dazu notwendige Wissen aus Marketing, Vertrieb, Rechnungswesen, Kundenservice und sonstigen relevanten Bereichen anzueignen und regelmässig aufzufrischen.

Natürlich wird das nicht bei jedem Team Begeisterung auslösen, die oben erwähnte Ablehnung vieler Management-Praktiken führt häufig zur fehlenden Bereitschaft, sich mit diesen manchmal anstrengenden Themen überhaupt auseinanderzusetzen. Das ist auch nachvollziehbar, blendet aber aus, dass diese Auseinandersetzung ein Preis ist, der für die Selbstorganisation (bzw. deren Duldung oder Förderung durch das Management) gezahlt werden muss.

Erst wenn die Führungsebenen die Zuversicht haben, dass auch ohne ihr Zutun Wirtschaftlichkeit und Profitabilität nicht vernachlässigt werden, werden sie die Bereitschaft entwickeln, Entscheidungs-Kompetenzen in nennenswertem Ausmass nach unten zu delegieren. Und noch  weitergedacht: wenn man ihnen glaubhaft machen kann, dass Selbstorganisation zu mehr wirtschaftlichem Denken führen wird als Steuerung und Anleitung, werden sie sogar aktiv nach ihr verlangen.

Und um auch die Manager selbst in die Pflicht zu nehmen: dafür zu sorgen, dass ihre Mitarbeiter wirtschaftlich denken können ist eine ihrer wesentlichen Aufgaben und sollte in Ausbildungen, Weiterbildungen und Personalentwicklung verankert werden. Es handelt sich dabei schliesslich um die Mehrung von Humankapital, die eine zentrale Aufgabe jeder Führungskraft ist - ein weiterer Aspekt des Denkens als Intrapreneur, nur eine Ebene weiter oben.

You build it, you (can't) run it

Ich glaube ja, dass man die Entstehungsgeschichte von Ideen und Praktiken kennen sollte, wenn man wissen will, wie sie gedacht sind, welche Probleme sie lösen sollen und wofür sie nicht gedacht sind. Vor diesem Hintergrund bin ich sehr angetan von diesen Ausführungen von Hana Amiri, die sehr schön darstellt wo DevOps herkommt, wie es sich entwickelt hat, was es erleichtert hat und zu welchen neuen Problemen es geführt hat.

Der Gedanke hinter dem provokanten Titel, der das Paradigma "You build it, you run it" negiert, ist, dass diese doppelte Verantwortung viele Teams übermässig belastet und daher nicht skaliert. Der sich daraus ergebende Schluss, dass Platform Engineering die beste Form von DevOps at Scale ist, dürfte kontroverse Debatten auslösen - genau wie gute Vorträge es sollen.

Hardening Sprints

Bild: Pexels / Sternsteiger Stahlwaren - Lizenz

Eine der kontroverseren agilen Praktiken sind die so genannten "Hardening Sprints", in denen keine neuen Funktionalitäten entwickelt werden, sondern in denen stattdessen die noch fehlenden Restarbeiten erledigt werden, die nötig sind um mit Betrieb, Benutzung, Verkauf, o.Ä. beginnen zu können. Warum sie kontrovers ist? Weil sie dem Anspruch zuwiderläuft, nach jedem Sprint durch Erfüllung der Definition of Done "potentially shippable", also direkt gebrauchsfertig zu sein.

Trotz dieser umstrittenen Natur gehören Hardening Sprints zu den ältesten und langlebigsten Scrum-Praktiken. Bereits 2007 wurden sie vom Scrum-Pioneer Mike Cohn (moch unter dem Namen Release Sprint) als ein übliches Vorgehen beschrieben, zu Beginn der 2010er Jahre waren sie Teil von SAFe, (wo aus ihnen später die Innovation and Planning Iteration wurde) und bis heute werden sie von vielen Teams und Unternehmen vor Releases durchgeführt.

Vermutlich geht die kategorische Verteidigung oder Ablehnung von Hardening Sprints aber ohnehin in die falsche Richtung. Statt dogmatisch auf einer dieser Positionen zu verharren könnte man sich fragen, was in einem solchen Sprint stattfinden könnte, selbst wenn das in der vorherigen Zeit entwickelte Produkt nach jedem Sprint potentially shippable gewesen ist (zur Abgrenzung: um Kontexte in denen kontinuierliches potentially shippable nicht möglich ist geht es hier nicht, das ist ein eigenes Thema).

Refactoring

Es kann vorkommen, dass eine Anwendung funktionierend auf Production deployed ist, ohne dass es unter der Motorhaube durchgehend Clean Code, eingehaltene Benennungskonventionen, konsistente Architektur, o.Ä. gibt. Das kann in einem nachgelagerten Sprint nachgeholt werden, um sicherzustellen, dass auch zukünftig alles verstanden und mit geringem Aufwand erweitert werden kann.

Langlaufende Tests

Es ist zugegebermassen ein Edge Case, aber es in manchen Kontexten (z.B. bei kombinierten Hardware-/Software-Produkten) gibt Last- und Regressiontests, die mehrere Tage lang laufen, und damit gegebenfalls sogar länger als ein Sprint dauert. Diese Tests zu Ende zu führen kann sinnvoll und notwendig sein um sicherzustellen, dass wirklich alles funktioniert.

Löschen von Testdaten

Mitunter können sich an erstaunlich vielen Stellen eines Systems noch Testdaten befinden, was ggf. auch unvermeidbar ist, wenn bis zum letzten Tag des letzten richtigen Sprints noch entwickelt und getestet wird. Ein System vor dem Go Live auf derartige Datensätze fiktiver Produkte, Nutzer, etc. zu durchsuchen, bzw. sie mit Probe-Durchläufen sichtbar zu machen, kann eine gute Idee sein.

Aufspielen von Produktionsdaten

Der umgekehrte Fall. Bei vielen der im Echtbetrieb verwendeten Daten ist es wichtig, dass sie so aktuell und genau wie möglich sind, etwa im Fall von Zahlungs- und Auslieferungsbelegen. Dazu kommt, dass ihre Aufspielung auf Entwicklungs- und Testsysteme oft datenschutz- und haftungsrechlich problematisch wäre. Ihre Übertragung kann eine der Entwicklung nachgelagerte Arbeit sein. 

Monitoring (und ggf. Bugfixing)

Auch nach dem Übertragen aller Funktionen und Daten auf die Produktionsumgebung können noch zu erledigende Arbeiten übrigbleiben. Da sich der echte Livebetrieb nie völlig simulieren lässt, beginnt er oft mit einer "Hypercare"-Phase in der durch intensives Monitoring sichergestellt wird, dass nur dort auftretende Bugs schnell gefunden und behoben werden.

Schulung der Service-Mitarbeiter

Ein in vielen Fällen nicht zu unterschätzender Aufwand ist die Schulung der Service-Mitarbeiter, die für die Betreuung der Anwender einer neuen Software zuständig sind. Gerade wenn agil bin in den letzten Sprint Features entwickelt werden, kann sich das Systemverhalten auch bis zum letzten Entwicklungstag ändern, so dass eine Schulung in einer stabilen Phase sinnvoll sein kann.

User Onboarding

Eine ähnliche, und häufig auf den letzten Punkt aufbauende Tätigkeit. Vor allem bei grossflächig firmeninternen Anwendungen kann es notwendig sein, den Anwendern neuer Funktionen die Möglichkeit zu geben, sie auszuprobieren, Fragen zu stellen und Erklärungen zu erhalten. Das kann ggf. bereits im Echtbetrieb stattfinden.

Natürlich ist diese Aufzählung nicht vollständig. Es sind noch viele weitere Tätigkeiten denkbar, die in einem nach dem Ende der Entwicklung stattfindenden Hardening Sprint stattfinden können, ohne dass es sich dabei um Dinge handelt, die bei Einhaltung der Definition of Done früher hätten erledigt werden müssen. Und mit diesem Wissen im Hintergrund sollte es möglich sein, die Diskussion um derartige Sprints sachlich und undogmatisch zu führen.

Aktivismus und Stoizismus

Bild: Pexels / Sharath G. - Lizenz

Unter den vielen Arten, den Umgang mit Veränderungen zu strukturieren, gehört es, sich nicht nur eine Grundhaltung zuzulegen, sondern mehrere. Das geht ein bisschen gegen gängige Weisheiten und Faustregeln, die meistens nur eine derartige Haltung empfehlen, wie z.B. kritischen Rationalismus, Bias for Action, Being like a River und viele weitere. Der Wechsel zwischen Haltungen macht aber Sinn, und ich empfehle besonders zwei: Aktivismus und Stoizismus.

Unter Aktivismus versteht man eine Einstellung in deren Rahmen man bewusste Handlungen durchführt, die das Ziel haben, Veränderungen zu fördern, meistens solche, die man persönlich für wichtig oder dringlich hält. Wie diese Veränderungs-Förderung aussieht kann von Fall zu Fall unterschiedlich sein, vom Schaffen eines Sense of Urgency über das Beschleunigen bereits stattfindender Veränderungen bis hin zum Beseitigen von Hindernissen.

Beim Stoizismus dagegen steht im Mittelpunkt die Fähigkeit, gelassen mit Veränderungen umzugehen, vor allem solchen, die sich nicht verhindern lassen. Mögliche Mittel zu diesem Zweck sind die Bewusstmachung der relativen Nichtigkeit und Flüchtigkeit vieler Sachverhalte, das Gegenüberstellen grösserer, von den Veränderungen nicht betroffener Werte und Zusammenhänge, das Einüben von Anpassungsfähigkeit und Resilienz und der Verzicht auf übermässige Emotionalität.

Beide Haltungen haben in bestimmten Kontexten ihren Sinn. Dort wo Veränderungen möglich, aber ggf. schwierig sind, hilft der Aktivismus. Mit ihm kann man ständig neue Impulse setzen, andere überzeugen und ein Zurückfallen in alte Muster vermeiden. Dort wo unerwünschte oder gegenläufige Veränderungen nicht zu verhindern sind, hilft dagegen der Stoizismus gegen Frustration und ergebnisloses Aufreiben im Kampf gegen das Unvermeidbare.

Die entscheidende Frage ist jetzt "nur noch" wann welcher der beiden Kontexte gegeben ist. Das lässt sich natürlich nicht kategorisch beantworten, allerdings kann man mit der Zeit die Fähigkeit entwickeln, Merkmale zu identifizieren, die starke Indikatoren für einen der beiden sind. Diese Erfahrungsweisheit ist der Schlüssel für den situationsgemäss passenden Einsatz von Aktivismus und Stoizismus. Oder mit einem bekannten Stossgebet gesagt:

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.

Reinhold Niebuhr: Gelassenheitsgebet, ca. 1940

Bullshit-Artefakte

Ich bitte um Entschuldigung, aber hier wird jetzt geflucht. Genauer gesagt wird es um Bullshit gehen, die englische (und wesentlich obszönere) Übersetzung des deutschen Wortes Bockmist, und dabei um ein Phänomen, das viel zu selten beachtet wird - das der Bullshit-Artefakte. Gemeint sind damit Hinterlassenschaften und Ergebnisse von Tätigkeiten, die keinen sinnvollen Zweck erfüllen, aber trotzdem aus irgendeinem Grund stattfinden.

Zuerst ein kurzer Blick zurück. Als Schimpfwort existiert Bullshit etwa seit dem ersten Weltkrieg und stammt angeblich ursprünglich aus Australien und Neuseeland. Zu Beginn ein blosser Ausruf der Frustration, wandelte er sich mit der Zeit zu einem Werturteil über eklatant unsinnige Zustände oder Sachverhalte. In dieser Bedeutung erstmalig  umfassend beschrieben wurde er 1986 vom amerikanischen Philosophen Harry G. Frankfurt in seinem legendären Aufsatz On Bullshit.

Aufbauend darauf definierte der amerikanische Anthropologe David Graeber 2018 die Kategorie der Bullshit Jobs, also von Berufen, die ihrem Wesen nach unsinnig oder überflüssig sind, die aber trotzdem in Organisationen vorgeschrieben oder von ihren Inhabern ausgeübt werden. Beispiele dafür sind der Manager, der aussagefreie Statistiken erhebt oder der Büroarbeiter, der nicht wertstiftende oder nicht nachhaltige Tätigkeiten durchführt.

Die Bullshit Jobs haben seitdem einen festen Platz in der Betrachtung grosser Organisationen gefunden, was aber eher wenig betrachtet wird sind ihre Arbeitsergebnisse. Auf den ersten Blick ist das auch unnötig, schliesslich werden sie ja gerade durch ihre Nicht-Wertschöpfung charakterisiert. Auf den zweiten Blick ist eine Beschäftigung damit aber um so dringlicher, schliesslich stellt sich die Frage, ob nicht doch Ergebnisse entstehen, die genauso unsinnig sind wie die Tätigkeiten.

Und tatsächlich ist genau das der Fall. Zwar entsteht kein nutzbarer Mehrwert, dafür aber Hinterlassenschaften (organisationssoziologisch: Artefakte), verschiedener Art. Diese sind sogar noch kritischer zu betrachten, als man denken könnte, denn nicht nur werden bei ihrer Erstellung Zeit und Ressourcen verbraucht, sie sind häufig auch Ausgangspunkt für weitere, ebenso wenig wertvolle Tätigkeiten, die wiederum weitere derartige Hinterlassenschaften erzeugen, etc.

Bei genauerer Betrachtung lassen sich zwei Typen derartiger Bullshit-Artefakte erkennen. Bei der ersten handelt es sich um die Ergebnisse von Sinnlos-Tätigkeiten. Beispiele dafür sind von niemandem angeforderte und von niemandem gelesene Berichte, die Einhaltung irrelevanter Formatierungen (z.B. der alphabetischen Anordnung von Email-Empfängern) oder das Ausdrucken, Stempeln und wieder Einscannen von Formularen. Schwierig wird das, wenn es zur Vorschrift wird, die alle erfüllen müssen.

Der zweite Typ liegt vor, wenn eigentlich sinnvolle Tätigkeiten mit Sinnlos-Prozessen überzogen werden. Beispiele dafür sind (schein-)genaue Aufwandsschätzungen in volatilen Markt- oder Technik-Umfeldern, die übergreifende Priorisierung aller Aufgaben in Unternehmen, in denen die Teams so spezialisiert sind, dass sie die höher priorisierten Aufgaben im Zweifel gar nicht übernehmen können, oder die Erstellung von Fortschrittsberichten auf Basis unfertiger Arbeitspakete.

Besonders der zweite Typ kann in immensem Ausmass Bullshit-Folgetätigkeiten nach sich ziehen, nämlich dann, wenn versucht wird, die Realität an die Inhalte des jeweiligen Bullshit-Artefakts anzupassen. Das geschieht in derartigen Kontexten nämlich meistens durch noch mehr Bullshit Jobs, also durch weitere unrealistische Aufwandsschätzungen, weitere nicht umsetzbare Priorisierungen, weitere aussagefreie Fortschrittsberichte, etc.

Wichtig beim Gegensteuern gegen derartige Verhältnisse ist übrigens, bei der Wurzel anzufangen. Dort wo sich Bullshit-Artefakte häufen, wird es nur wenig helfen, auf eine bessere Qualität der offensichtlich unsinnigen Berichte, Priorisierungen, Schätzungen, etc. zu dringen. Die erfolgversprechendste Methode ist die ersatzlose Abschaffung der dahinterliegenden Bullshit Jobs. Mit ihnen verschwinden dann auch die von ihnen produzierten unsinnigen Ergebnisse.

Passierschein A38

In Frankreich und Deutschland hat die Passage "Passierschein A38" aus dem Film Asterix erobert Rom es geschafft, sprichwörtlich für die Exzesse überbordender Verwaltungsappareate zu werden, die die Betroffenen durch nicht enden wollende Bürokratie in den Wahnsinn treiben. Mittlerweile kann man sich durchgehend an ihr erfreuen, denn der Rechte-Inhaber Canal+ hat sie auf Youtube veröffentlicht.

Ein häufiger unterschätzter, die Realität gut darstellender Seitenaspekt ist dabei, dass die Bürokraten selbst keineswegs Teil einer sinistren Verschwörung sind, sondern eigentlich normale Menschen, die nur irgendwann durch die sie umgebenden absurden Abläufe abgestumpft wurden, und die ihnen gegebenenfalls ebenfalls als Betroffene ausgeliefert sind.

Mother Tongue (II)

Bild: Unsplash / Alex Mihai C - Lizenz

Wer Methoden und Techniken einsetzt, die in einer anderen Sprache entwickelt wurden, wird das Phänomen kennen: nicht alles ergibt für einen intuitiv den Sinn, den ein Muttersprachler einfach erfassen könnte, viele Bedeutungen müssen nachgeschlagen werden, und an einigen Stellen kommt es vor, dass man erst zu spät herausfindet, irgendetwas falsch verstanden zu haben. Das ist auch bei den verschiedenen agile Frameworks nicht anders.

Ein Problem das dabei für Nicht-Muttersprachler immer wieder auftreten kann, ist die mögliche Mehrdeutigkeit der Begriffe. Besonders bei denjenigen, die vorher unbekannt waren, besteht das Risiko, dass sie nur der einen Bedeutung zugeordnet werden, mit der man sie zu Beginn kennengelernt hat. Im Folgenden kann es schlimmstenfalls zu einem so eingeengten Begriffsverständnis kommen, dass weitere Bedeutungen abgelehnt werden, selbst dann wenn sie ebenfalls richtig sind.

Ein häufig anzutreffendes Beispiel für dieses Phänomen ist das Committment, das vor allem in Scrum eine zentrale Bedeutung hat. hier aber in gleich zwei Bedeutungen vorkommt. Zum einen als einer der Scrum-Werte, der sich übersetzen lässt als die ständige Anstrengung, gute Arbeit abzuliefern, zum anderen als Teil der drei Artefakte Product Backlog, Sprint Backlog und Increment, bei denen es sich um konkrete Umfangs- und Qualitätsbeschreibungen von Zielen und Ergebnissen handelt.

Je nachdem welche dieser Bedeutungen man zuerst gelernt hat, wird man (unter der Voraussetzung, dass man sich die andere mittlerweile nicht auch angeeignet hat) eine sehr einseitige und unvollständige Idee davon haben, wofür das Committment in Scrum steht. Entweder man wird es als einen anspruchsvollen aber abstrakten Anspruch verstehen oder als eine konkrete Beschreibung von Ziel- und Liefergegenstand-Eigenschaften, die die Ausgangsbasis für Planungen und Erfolgskontrollen bildet.

Derartige Beispiele lassen sich immer wieder finden. Eine Policy kann z.B. in Kanban ein Kriterien-Katalog sein, der zu erfüllen ist, bevor eine Aufgabe in den nächsten Status bewegt werden kann, es kann aber auch jegliche andere Regel oder Strategie sein. Ready kann je nach Kontext bedeuten, dass man die Arbeit an etwas beginnen kann, oder dass die Arbeit an etwas abgeschlossen wurde. Ein Planning kann am Anfang eines Sprints stattfinden, aber auch für Einzelaufgaben durchgeführt werden. Etc., etc.

Der beste Weg, sich vor derartigen Begriffsverengungen und den daraus folgenden Missverständnissen zu schützen besteht natürlich darin, die Sprache zu lernen, in der das jeweilige Vorgehen ursprünglich entwickelt wurde. Im Fall der verschiedenen agilen Ansätze ist das fast ausnahmslos (amerikanisches) Englisch und im Fall von Lean Management japanisch, im Fall von einzelfallspezifischen Vorgehensmodellen können auch weitere dazukommen, etwa spanisch oder holländisch.

Für alle, denen dafür Zeit, Geduld oder Veranlagung fehlen, gibt es aber noch eine zweite Möglichkeit: das Zeigen von Demut und Neugier. Demut in dem Sinn, dass man sich ständig bewusst macht, bei der Durchdringung aller Begrifflichkeits-Nuancen Defizite zu haben, und Neugier dahingehend, dass man ständig überprüft, ob es nicht noch weitere Bedeutungen gibt, die einem bisher entgangen sind.

Kommentierte Links (CXXXII)

Grafik: Pixabay / Brian Penny - 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.

Russ Miles: A Myth of Progress

Der Untertitel dieses Artikels fasst gut zusammen, worum es Russ Miles geht: On hype cycles and how to break them by focussing on human needs. Er vergleicht die Versprechen und Befürchtungen rund um Künstliche Intelligenz mit vergangenen Hypes, erkennt vieles wieder und arbeitet Gemeinsamkeiten heraus. Praktisch ist dabei eine Checkliste am Ende, mit deren Hilfe man überprüfen kann, ob man gerade einem Hype aufsitzt und wie man sich davon befreit.

Petra Wille: Why It’s Time to Forget the Project vs. Product Operating Model Debate

Ein weiterer Beitrag zur ewigen Produkt vs Projekt-Debatte, die mittlerweile schon seit mindestens zwei Jahrzehnten durch Blogs und Konferenzen wabert. Diesesmal zumindest eine, die sich nicht in den rhetorischen Schützengraben begibt, sondern differenziert einordnet. Denn was Petra Wille hier beim Namen nennt, sollte eigentlich Common Sense sein - es geht nicht um ein entweder/oder sondern um ein sowohl als auch, bzw. um die Frage, was gerade besser zum Kontext passt.

Gene Kim: A Patient Advocate's Guide to Navigating A Hospital System

Was passiert, wenn die Frau eines Prozessmanagement-Experten ins Krankenhaus eingeliefert wird? Er beginnt die um sie herum stattfindenden Abläufe zu analysieren, um dafür sorgen können, dass sie in der bestmöglichen Art und Weise genutzt werden. Herausgekommen ist dabei dieser bemerkenswerte Erfahrungsbericht des DevOps-Experten Gene Kim, der zwar sicher etwas USA spezifisch, aber trotzdem hochinteressant zu lesen ist.

Maarten Dalmijn: The Best Product Managers Optimize For Reversibility and Optionality

Ein Drama an dem man immer wieder in IT-Projekten vorbeikommt sind Entscheidungen, die sich aus technischen Gründen kaum rückgängig machen lassen, selbst wenn sie sich als falsch herausstellen. Maarten Dalmijn zieht daraus den einzig sinnvollen Schluss: wenn der richtige Weg nicht sicher ist, sollte man sich keine Optionen derartig verbauen, sondern sich immer die Möglichkeit offen lassen, Features wieder ausbauen zu können.

Sean Goedeke: How I influence tech company politics as a staff software engineer

Zum Schluss ein Gedankenanstoss von Sean Goedeke, der einer häufigen Annahme widerspricht - auch als einfacher Softwareentwickler der untersten Hierarchiestufe kann man strategische Entscheidungen im eigenen Sinn beeinflussen - wenn man weiss wie grosse Organisationen funktionieren und sich das zu Nutze macht. Mit anderen Worten: man braucht Systemsicht, Vorbereitung und Reaktionsfähigkeit.

Master

Eigentlich sind Projekt- oder Produktmanagement-Methoden per se unpolitisch, da sie (bzw. ihre Anwender) aber Teil der Gesellschaft sind, schwappen gesellschaftliche Debatten aber immer wieder herüber in den Methodendiskurs. Eine dieser Debatten dreht sich um den vielleicht bekanntesten Titel aller agilen Frameworks, den Scrum Master oder Agile Master, der in Scrum, SAFe, LeSS, Disciplined Agile und ähnlichen Ansätzen eine zentrale Rolle spielt. Aber worum geht es dabei?

Im Englischen hat der Begriff des "Master" eine Dimension, die der deutsche "Meister" nicht hat, nämlich die des Sklavenhalters (siehe hier), die sich in sprichwörtlichen Gegensatzpaaren wie Master and Slave oder Master and Servant bis heute gehalten hat. Seit mehr als zehn Jahren wird daher darüber diskutiert, ob der Scrum Master nicht bedenkliche Stereotype reproduziert und abgeschafft werden sollte (siehe beispielsweise hier, hier, hier, hier und hier).

Wichtig für das Verständnis dieser Debatte ist, dass es in der IT tatsächlich Begriffe gibt, die einen derartig problematischen Hintergrund haben. Am bekanntesten dürfte die Verwendung von Master und Slave für steuernde und gesteuerte Systeme sein, ebenfalls verbreitet sind "Whitelist" und "Blacklist" für gewährte und verwehrte Systemzugänge. Diese Verwendungen werden von immer mehr Firmen zugunsten neutralerer Benennungen aufgegeben (siehe hier).

Das in Frage stellen des Scrum Master- bzw. Agile Master-Titels ist vor diesem Hintergrund zu sehen. Er tritt im Arbeitsalltag sehr häufig zusammen mit den gerade genannten problematischen Benennungen auf, wird deshalb mitunter auf die selben Hintergründe zurückgeführt und deshalb gemeinsam mit ihnen in Frage gestellt. Die Frage, die sich aufbauend darauf stellt: ist der Ursprung tatsächlich der Gleiche, oder ist es eher ein anderer, weniger problematischer?

Um diese Frage zu beantworten wären Aussagen von Ken Schwaber und Jeff Sutherland, den Erfindern der Scrum Master-Rolle am besten geeignet, die sich allerdings online nicht auffinden lassen. Was es dagegen gibt, sind Sekundärquellen auf Scrum.org, der von Schwaber gegründeten Zertifizierungs-Organisation, die dort wohl kaum stehen bleiben würden, wenn sie ihm Falschaussagen unterstellen würden. Und aus ihnen ergibt sich eine andere Herkunftsgeschichte (siehe hier und hier).

Der Ursprung des Rollen-Titels ist ihnen zufolge, dass das für die Methodik zuständige Teammitglied diese in allen wesentlichen Aspekten kennen und beherrschen sollte. Bewusst wird dabei von Schwaber und Sutherland die Parallele zum Handwerks-Meister (genauer gesagt zum Master Carpenter, also zum Schreinermeister) gezogen, der zuerst sein Können über längere Zeit unter Beweis stellen musste, bevor er diesen Titel führen durfte.

Der Entstehungshintergrund ist damit ein völlig anderer als bei den oben genannten Master/Slave oder Whitelist/Blacklist-Begriffspaaren. Er entspricht eher dem Status der aus langer Übung errungenen Meisterschaft, der auch im Englischen eine positive Bedeutung hat und neben dem Handwerksmeister z.B. auch im Schachgrossmeister (Grand Master of Chess) oder in dem (fiktiven) Jedi-Meister aus den Star Wars-Filmen gefunden werden kann.

Dieser Hintergrund in der Ausübungs-Meisterschaft bedeutet übrigens ganz nebenbei auch, dass eine solche Rolle eigentlich nicht geeignet ist, von Berufs- oder Quereinsteigern ausgeübt zu werden. Das aber ist nochmal ein ganz eigenes Thema.

Virtue Signaling (II)

Kommen wir noch einmal zurück zum Thema Virtue Signaling, also zum demonstrativen öffentlichen Kommunizieren von Standpunkten, die als moralisch gut oder sogar überlegen wahrgenommen werden. In der agilen Community ist dieses Verhalten sehr stark ausgeprägt, sowohl als Zeichen der Überlegenheit des eigenen Vorgehens gegenüber "traditionellen" Ansätzen (v.a. Wasserfall), als auch gegenüber falsch verstandenem agilen Arbeiten (so genanntem Cargo Cult). 

Auf den ersten Blick ist das auch naheliegend: wenn der eigene Ansatz nun mal als effektiver, effizienter, wirtschaftlicher und humaner empfunden wird, dann kann man das auch sagen, und wenn es darüber hinaus dazu führt, dass man dadurch einfacher in der Lage ist, Gleichgesinnte zu finden und von ihnen gefunden zu werden - um so besser. Die so entstandenen Erfahrungsaustausch- und Unterstützungs-Netzwerke sind für ihre Mitglieder wertvoll und hilfreich.

Das Problem, das dadurch entstehen kann, ist aber, dass sich andersdenkende Menschen ausgeschlossen oder im schlimmsten Fall sogar auf ungerechte Weise herabgesetzt fühlen können. Auch unter den Anwendern von Prince2, SAFe und weiteren nicht- oder halb-agilen Methoden wird die Mehrheit mit den besten Absichten (und oft sogar mit Erfolg) zur Arbeit gehen. Sich ständig anhören zu müssen, dass nur ein anderes Vorgehen das einzig Wahre ist, kann schnell verletzend wirken.

Alleine die auf diese Art aufgerissenen Gräben zwischen den ständig Virtue Signaling betreibenden Anhängern des agilen Arbeitens und den sich unfair behandelt fühlenden Vertretern klassischer und hybrider Ansätze können bereits zu unnötigen Konflikten, nicht zielführenden Grundsatz-Diskussionen und einem gestörten Betriebsklima führen, im schlimmsten Fall kann die Situation aber auf unschöne Weise noch stärker eskalieren, wenn es nämlich zu einer Gegen-Überreaktion kommt.

Aus politischen Debatten ist das Phänomen des Vice Signaling bekannt, also des Konterns des Virtue Signaling durch das Einnehmen bewusst überspitzter oder übertriebener Gegenpositionen. In gewisser Weise handelt es sich dabei um kollektive Reaktanz, also um den Versuch, einer gefühlten Bedrohung des eigenen Freiheits-Spielraums dadurch entgegenzuwirken, dass er vorsorglich über das notwendige Mass hinaus ausgedehnt wird, so dass er selbst bei einer Einschränkung noch hinreichend gross bleibt.

Sobald sich eine Debatte einmal in einer Wechselwirkung (oder sogar einer Eskalationsdynamik) zwischen agilem Virtue Signaling und nicht-agilem Vice Signaling verfangen hat, ist konstruktives Arbeiten kaum noch möglich. Im schlimmsten Fall verlagern sich die Auseinandersetzungen dann sogar auf eine identitätspolitische Ebene, auf der andersdenkenden Menschen nur aufgrund ihrer Meinung charakterliche oder kognitive Defizite unterstellt werden. Der Diskurs ist dann nachhaltig vergiftet.

Um es nicht dazu kommen zu lassen, kann es sinnvoll sein, das Virtue Signaling in einem überschaubaren Rahmen zu halten - auch und gerade dann wenn man sich selbst absolut im Recht fühlt. Statt das eigene Vorgehen kategorisch zu überhöhen kann man sachlich darlegen, aufgrund welcher Faktoren es in welchen Rahmenbedingungen welche erkennbaren Vorteile im Vergleich zu anderen Methoden bringt. Das Risiko, dass Konflikte entstehen, wird so deutlich geringer ausfallen.

Und der Vollständigkeit halber: natürlich kann es auch Situationen geben, in der das Virtue Signaling von klassisch sozialisierten Projektmanagern ausgeht und das Vice Signaling von überreagierenden Agilisten. Es gibt keine Gruppe, die gegen derartige Fehltritte immun ist. Umso wichtiger ist es, das eigene Verhalten regelmässig kritisch auf den Prüfstand zu stellen.

Steering Committees und Advisory Boards

Bild: Harris & Ewing / Library of Congress - Public Domain

Manche Dinge schliessen sich gegenseitig aus: Feuer und Wasser, Licht und Dunkelheit, Materie und Antimaterie, Selbstorganisation und Steering Committees. Soviel zum leicht polemischen Einstieg, hinter dem aber ein reales Problem steckt - das klassische Management-Instrument des Steering Committee kollidiert alleine aufgrund seiner Natur zwangsläufig mit allen Formen des Empowerment und der Selbstorganisation. Aber zum Glück gibt es eine Alternative.

Zunächst zur Definition: ein Steering Committee (auch Steuerungskreis, Lenkungsausschuss, o.Ä.) ist im klassischen Projektmanagement ein Gremium, das das übergeordnete Entscheidungen für ein einzelnes Projekt oder Programm treffen darf und soll. Wie das im Detail aussieht kann sich je nach Fall unterscheiden, weit verbreitet ist aber, dass Umfang, Qualität, Wirtschaftlichkeit und Zeitplan eines Projekts kontrolliert und ggf. durch Eingriffe korrigiert werden.

Die dahinter stehende Grundidee ist auch erst einmal vernünftig: grössere Projekte sind meistens derartig komplex, dass einzelne Personen kaum in der Lage sind, alle Dimensionen zu überblicken. Durch die Bildung eines Steering Committee aus verschiedenen Experten (z.B. Finance, Marketing, Sales, Legal, IT, Quality, Strategy und Customer Care) werden sie dagegen in der Breite abgedeckt - in gewisser Weise wird die Projektleitung dadurch crossfunktional, was eigentlich etwas Gutes ist.

Ein in der Realität immer wieder auftretende Ergebnis ist aber, dass durch derartige Einheiten Verzögerungen, Kosten und Qualitätsverluste entstehen. Zum einen wegen des Zeitaufwandes, der alleine dadurch entsteht, dass jedem Mitglied alle Informationen mitgeteilt und verständlich gemacht werden müssen, zum anderen aber auch dadurch, dass die im Kommittee versammelten Spezialisten gegenläufige Interessen haben und versuchen, sie durchzusetzen.

Die Beispiele kann man sich denken - der Finance-Vertreter möchte durch möglichst günstige Material- und Personal-Preise Kosten sparen, der Quality-Vertreter hätte dagegen gerne die besten (und dadurch teuersten) Werkstoffe und Teammitglieder. Der Sales-Vertreter möchte neue Features  möglichst schnell verkaufen, die Vertreter von IT und Operations möchten dagegen zuerst technische Schulden abbauen und eine hohe Betriebsstabilität sicherstellen. Etc., etc.

Das Bemerkenswerte an solchen Situationen ist, dass keines dieser Anliegen falsch ist. Für sich genommen sind sie sogar in der Regel hoch rational, wie oben gezeigt aber oft untereinander gegenläufig. Da aber jeder Spezialist aus dem Steering Committee zuerst seine Partikular-Interessen vertritt (was auch Teil seiner Stellenbeschreibung ist), führt das entweder zu Streit untereinander oder zu einer in Summe völlig unrealistischen Erwartungshaltung an das Umsetzungsteam.

Wenn dieses Umsetzungsteam dann auch noch selbstorganisiert sein soll, sind alle Voraussetzungen für eine weitgehende und dauerhafte Blockade gegeben. Sowohl der Versuch, es von aussen zu steuern, als auch die widersprüchlichen Signale in welche Richtung es gesteuert werden soll, führen zusätzlich zu den gegenläufigen Interessen innerhalb des Kommittees zu einem Konflikt zwischen Steuerung und Umsetzung, bzw. darum, bis zu welchem Grad sich das Umsetzungsteam überhaupt steuern lassen muss.

Aus diesem Dilemma gibt es mehrere Wege. Der (zumindest in grossen Organisationen) häufigste ist der, dass im Konfliktfall eine stärkere Führung angeordnet wird, was in den meisten Fällen ein Euphemismus für Micromanagement durch das Lenkungsgremium ist. Das beseitigt zwar den Konflikt mit dem (ab diesem Punkt nicht mehr) selbstorganisierten Umsetzungsteam, lässt die gegenläufigen Interessen innerhalb des Steering Committee aber weiter bestehen.

Ein wesentlich besserer Weg besteht darin, das Steering Committees zu einem Advisory Board (Beratungsgremium) zu machen, dass die Expertise seiner Mitglieder zwar weiter anbietet, aber keine zwingend zu befolgenden Vorgaben mehr machen kann. Einen vernünftigen Mittelweg zwischen den verschiedenen Einzelinteressen zu finden, obliegt dann dem empowerten und (teil-)autonomen Umsetzungsteam (bzw. dessen Projektleiter, Product Owner, o.Ä.).

Das wird vor allem dann möglich, wenn in diesem Rahmen darauf verzichtet wird, die einzelnen Mitglieder des Beratungsgremiums dafür verantwortlich zu machen, dass sie ihre Maximalvorstellungen umsetzen. Wird nicht darauf verzichtet, ist das ein starker Anreiz dazu, sie durch Eskalationen, Katastrophenszenarien, o.Ä. durchdrücken zu wollen. Wird dagegen darauf verzichtet, können sie ihren Standpunkt noch immer vermitteln, allerdings mit deutlich weniger Drama und Emotion.

Eine solche Konstellation bringt natürlich weitere Implikationen mit sich, von denen nicht alle unproblematisch sind. Wenn Umfang, Qualität, Wirtschaftlichkeit und Zeitplan eines Projekts nicht ausser Kontrolle geraden sollen, ist ein starkes Team mit unterstützendem Advisory Board aber erfolgversprechender als ein Steering Committee, in dem Vertreter starker Partikular-Interessen sich gegenseitig blockieren und widersprüchliche Umsetzungsvorgaben machen.

Immerschlimmeritis und Verbesserungsoptimismus

Es gibt Begriffe, die komplexe Sachverhalte prägnant auf den Punkt bringen, und einer davon ist gerade neu erfunden worden: die Immerschlimmeritis. Gemeint ist damit der Glaube, dass sich die Verhältnisse denen man ausgesetzt ist permanent verschlechtern - auch wenn in Wirklichkeit das Gegenteil der Fall ist. Geprägt hat ihn der Ökonom Georg Cremer, VWL-Professor an der Universität Freiburg, in einem Zeit-Artikel über Falschwahrnehmungen der Vermögensentwicklung in Deutschland.

Die spannende Frage ist jetzt, wie es zu einer derartigen, nicht der Realität entsprechenden Immerschlimmeritis kommen kann, und tatsächlich gibt es darauf sogar eine wissenschaftlich fundierte Antwort. Der berliner Soziologie-Professor Stefan Liebig (auf dessen Forschung Cremer seine Analyse aufbaut) hat das Phänomen untersucht und kommt zu der Erklärung, dass sich Einstellungen nur träge an veränderte Trends anpassen. Aber was heisst das?

Wenn sich Verhältnisse über eine längere Zeit in eine bestimmte Richtung entwickelt haben, gehen die betroffenen Menschen unbewusst davon aus, dass das mit einer gewissen Zwangsläufigkeit geschieht und aufgrunddessen auch so weitergehen muss. Wenn es also über längere Zeit zu Stagnationen oder Verschlechterungen gekommen ist, werden neu auftretende Verbesserungen nicht als solche erkannt oder lediglich für temporäre Abweichungen von einer dauerhaften Tendenz gehalten.

Wer schon einmal Veränderungsmanagement in grösseren Organisationen betrieben hat, wird jetzt vermutlich ein Deja-vu haben - selbst spürbare Verbesserungen werden in derartigen Kontexten oft nicht als solche anerkannt oder es wird ihnen eine dauerhafte Wirksamkeit abgesprochen. Diese Grundhaltung lässt sich in vielen Fällen anhand von Liebigs Modell mit der unbewussten Fortschreibung vorhergegangener langfristiger Stagnations- und Verschlechterungs-Erfahrungen erklären.

Diese Erklärung ist zunächst einmal frustrierend, bedeutet sie doch, dass Erfolge und Verbesserungen trotz spürbarer Effekte als vergebliche Mühen und sinnlose Aufwände betrachtet werden können, was im schlimmsten Fall zur Folge haben kann, dass sogar erfolgreiche Veränderungsvorhaben wegen einer irrtümlich wahrgenommenen Wirkungslosigkeit beendet oder sogar rückgängig gemacht werden können. Allerdings gibt es auch eine positive Deutung.

Wenn es gelingt, über einen längeren Zeitraum kontinuierliche Verbesserungen aufzuzeigen, dann kann die verzögerte Anpassung von Einstellungen an veränderte Trends zu einem verstärkenden Faktor von Verbesserungsvorhaben werden - die wiederholten derartigen Erfahrungen führen dann zu einem strukturellen Verbesserungsoptimismus, der spiegelbildlich zur Immerschlimmeritis dafür sorgt, dass die Beteiligten davon ausgehen, dass sich die Lage im Zweifel immer weiter verbessern wird.

Für das Veränderungsmanagement in grösseren Organisationen bedeutet das auf den Punkt gebracht, dass es sich lohnt, einen langen Atem zu haben und sich von anfänglicher fehlender Anerkennung nicht entmutigen zu lassen. Denn wenn kontinuierliche Verbesserungen gelingen, dann kann irgendwann die Zustimmung ähnlich stark werden wie zu Beginn die Ablehnung. Und das ist doch ein Ziel auf das es sich lohnt hinzuarbeiten.

Flooding the Zone (II)

Bild: Wikimedia Commons / Katsushika Hokusai - Public Domain

Noch einmal einige Gedanken zum Flooding the Zone, also zu einem derartigen Überladen einer Diskussion mit Themen, dass es nicht mehr möglich ist, sich auf eines davon zu konzentrieren um es auszudiskutieren oder zu einer Massnahme oder Lösung zu kommen. In sehr vielen Fällen ist dieses Phänomen ein Ausdruck einer destuktiven Einstellung, es gibt aber auch Fälle, in denen es stattfindet ohne dass eine negative Absicht dahintersteht.

Eine häufige Ursache dafür ist, dass ein Gesprächsteilnehmer seit langem keine Möglichkeit mehr gehabt hat, seine Einwände oder Bedenken vorzubringen (weil das von anderen unterbunden wurde, weil er nicht in die dafür geeigneten Termine eingeladen wurde, weil er erst seine Introvertiertheit überwinden musste - es kann viele Gründe dafür geben). Ihn dann darum zu bitten kann einen Dammbruch zur Folge haben, der erstmal alles an die Oberfläche bringt was sich aufgestaut hat. 

Eine anderer Grund kann sein, dass der Gesprächsteilnehmer die Erfahrung gemacht hat, dass er im Durchschnitt nur ein- oder zweimal pro Meeting zu Wort kommt, z.B. weil die strukturell mit Themen überladen sind oder mit zu vielen Teilnehmern stattfinden. In derartigen Fällen hat er einen starken Anreiz, sofort alles vorzubringen, was irgendwann im Gespräch wichtig werden könnte, da er nicht sicher sein kann, ein zweites mal die Gelegenheit dazu zu haben.

Eine dritte mögliche Ursache ist, dass durch solche Momente Probleme der Unternehmenskultur sichtbar werden. Wenn z.B. dem ersten, der ein konfliktlastiges Thema anspricht, sein Standpunkt am meisten geglaubt wird, dann kann das einen Wettlauf zum Mikrofon mit anschliessendem thematischem Rundumschlag zur Folge haben. Das ist im übrigen auch dann das Ergebnis, wenn dieses Kulturproblem gar nicht existiert, es aber irrigerweise unterstellt wird.

Abhängig davon, welche dieser Konstellationen gegeben ist (was sich allerdings nicht immer einfach herausfinden lässt) sind verschiedene Herangehensweisen sinnvoll, um das Flooding the Zone in den Griff zu bekommen. Sinnvoll ist in jedem Fall eine vorher gemeinsam Agenda, bei der den einzelnen Themen realistische Zeiträume zugeordnet sind (womit auch klar ist, worüber nicht geredet wird). Mit Berufung darauf lassen sich zeitlich oder inhaltlich ausufernde Beiträge einfacher abmoderieren.

Ebenfalls hilfreich ist es, wegmoderierte Themen öffentlich sichtbar zu "parken", z.B. auf einer Wand mit entsprechend beschrifteten Post Its oder Moderationskarten. Dadurch wird denjenigen, die sie eingebracht haben, die Sorge genommen, dass sie unter den Tisch fallen könnten. Ggf. kann am Ende des Termins sogar schon festgelegt werden, wann diese Themen stattdessen behandelt werden, auch in welchem Umfang und mit welcher Reihenfolge.

Das meiste Fingerspitzengefühl ist nötig, wenn das Flooding the Zone auf eine problematische Unternehmenskultur zurückgeht. Ein einigermassen erfolgsversprechendes Mittel in derartigen Fällen ist es, die nicht in der Agenda vorgesehenen Debatten konsequent aus der Ergebnis-Dokumentation herauszuhalten, wodurch ein derartiges Verhalten seinen Mehrwert verliert. Um so wichtiger ist in solchen Fällen der Verweis auf einen späteren Zeitpunkt für die Besprechung.

Erfahrungsgemäss kann diese Art, mit zeitlich und inhaltlich ausufernden Wortbeiträgen umzugehen, nach und nach zu einer Verbesserung führen, selbst wenn es zu Beginn eine Zeit lang zu Unzufriedenheit und Widerspruch kommt. Man muss sich dabei aber bewusst machen, dass ein derartiges Verhalten in der Regel über eine längere Zeit entstanden ist, und es dadurch auch entsprechend dauern kann, bis es wieder verschwunden ist.

Ein Bild sagt mehr als 1000 Worte (LII)

Grafik:Forrest Brazeal - CC BY-NC-ND 4.0