Kommentierte Links (CXXVI)

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.

John Cutler: The 4 Framework Jobs (And Why It Matters)

Vorgehensmodelle jeglicher Art sind in praktisch allen grösseren und mittleren Organisationen weit verbreitet, von klassischem Projekt und Prozessmanagement über Lean Six Sigma und Total Quality Management bis hin zu Kanban, Scrum und SAFe. Was John Cutler zurecht anmerkt ist aber, dass zu selten darüber nachgedacht wird, warum diese Modelle ursprünglich ausgewählt wurden, was mit ihnen erreicht werden sollte und ob sie noch immer der beste Weg zu diesen Zielen sind.

Sjoerd Nijland: How to Say “It Depends” with Data

"Es kommt darauf an" ist die klassische Antwort aller Produkt- und Projektmanager, wenn sie nach Fortschritten und Fertigstellungsdaten gefragt werden. Dass diese Antwort ohne Kontext und Begründung nicht zufriedenstellend ist, ist offensichtlich, weshalb Sjoerd Nijland eine entscheidende Erweiterung vornimmt: er nennt eine entscheidende Variable auf die es ankommt, nämlich das Ausmass der messbaren Volatilität des Backlogs. Je höher diese ist, desto unklarer die Fortschritts-Prognosen.

Hunter Schwarz: This 3D-printed train station in Japan took less than 6 hours to build

Dass CAD und 3D-Druck agiles Arbeiten auch in Bauprojekten möglich macht, ist eine der spannenden Entwicklungen der letzten Jahre. Welche Umsetzungs-Geschwindigkeiten damit erreicht werden können beschreibt Hunter Schwarz anhand des Neubaus des japanischen Bahnhofs in Arida, der in unglaublichen sechs Stunden abgeschlossen werden konnte, also in nur einer einzigen Nacht. Zum vergleich: vergleichbare Arbeiten in Deutschland dauern Monate.

Maarten Dalmijn: The Explosive Nature of 'Big Bang' Rewrites

Dass Big Bang-Releases neu entwickelten problematisch sind, sollte mittlerweile allgemeines Verständnis sein. Maarten Dalmijn fügt dieser Erkenntnis noch eine weitere Dimension hinzu: auch das komplette Umschreiben einer bestehenden Anwendung mit anschliessender Big Bang-Ablösung des Bestandssystems ist riskant. Zwar sind die Nutzerbedürfnisse (hoffentlich) bekannt, das Wissen um die inneren Zusammenhänge ist aber schon schnell zu gross um sich noch verlässlich planen zu lassen.

Luís Gonçalves: Scaling Startups - The Ultimate Guide For Founders

Wo würden agile Vorgehensweisen Sinn machen, wenn nicht in einem Startup? Und wodurch zeichnet sich ein Startup aus, wenn nicht durch starkes Wachstum? Dass es aber auch hier Differenzierungen gibt kann man bei Luís Gonçalves nachlesen, der vor allem den Unterschied zwischen Start Up und Scale Up hervorhebt. Der ist gravierender als man denken könnte (selbst wenn es eine Übergangsphase dazwischen gibt), so dass es sich lohnt, die beiden Typen zu kennen.

Der Unterbau von OKRs

Für sich genommen klingt die Idee der Objectives and Key Results (OKRs) erstmal einfach. Man setzt ein abstraktes, mittelfristiges Ziel (z.B. Erschliessung eines neuen Kundensegments im nächsten Quartal) und verbindet es mit wenigen konkreten, messbaren Ergebnissen (z.B. X Nutzer nach dem ersten Monat, Y Wachstumsrate im 2. Monat, Z Prozent Verlängerungen nach der Probezeit). Die Herausforderung, die dadurch entsteht ist aber: wie lässt sich das mit dem Alltagsgeschäft verbinden?

Die erste und naheliegende Antwort ist es, in kurzen Abständen (z.B. wöchentlich) zu überprüfen, ob Forschritt in der gewünschten Richtung stattfindet und ggf. Anpassungsmassnahmen zu beschiessen, falls die bisherigen Ergebnisse zu wünschen übriglassen. Auch hier bleibt aber offen, was genau es ist, das da begutachtet wird. Natürlich kann man sich immer wieder die OKRs selbst vorlegen, die Verbindung zum Alltagsgeschäft wäre damit aber noch immer nicht gegeben.

Ein häufig anzutreffender Ansatz zum Schliessen dieser Lücke ist, für die jeweiligen Key Results einen weiteren Work Breakdown durchzuführen und die Umsetzung der sich so ergebenden Arbeitspakete mit Hilfe eines Backlogs oder einer Roadmap zu planen.¹ Damit wird nicht nur die Umsetzungslücke geschlossen, es ist darüber hinaus möglich, die OKR-Aufwände und die sonstigen Tätigkeiten in einer gemeinsamen Planungssicht zusammenzufassen und so Redundanzen und Überplanung zu vermeiden.

Die Art der jeweiligen Arbeitspakete kann schliesslich variieren. Sie können die Bereitstellung der (Infra-)Strukturen zum Gegenstand haben, die für die Erbringung von Leistungen Voraussetzung sind, sie können aus der Fertig- und Bereitstellung von neuen Produkten, Features oder Services bestehen, sie können aber auch die Form von Business-Experimenten haben, durch die erforscht wird, auf welche Art und Weise sich Nutzergewohnheiten ändern oder Kaufanreize setzen lassen.

Wichtig bei der Definition dieses Unterbaus unterhalb der OKRs ist dabei weniger, um was für Arbeitspakete es sich genau handelt, sondern eher ob sie zur Erreichung der übergeordneten messbaren Ergebnisse, der Key Results, beitragen. Stellt sich heraus, dass sie einen Beitrag leisten, sollten sie ggf. wiederholt und intensiviert werden können, leisten sie keinen erkennbaren Beitrag muss es möglich sein, sie unbürokratisch zu variieren oder zu verwerfen. Auf keinen Fall dürfen sie zum Selbstzweck werden.

Der Vollständigkeit halber sei noch erwähnt, dass diese Art mit Objectives and Key Results zu arbeiten weder die einzige ist, noch eine die per Definition besser als andere Vorgehensweisen wäre. Es ist aber eine, mit der sich die Verbindung zwischen OKRs und Alltagsgeschäft gut herstellen lässt. Wer in diesem Bereich Verbesserungspotential sieht, kann daher einen Versuch wagen und überprüfen, wie gut dieser Ansatz für ihn funktioniert - idealerweise anhand von im voraus definierten Erfolgskriterien.

¹Ein naheliegender Ansatz ist die Nutzung der Key Results als Sprintziele in Scrum

Ein Bild sagt mehr als 1000 Worte (XLVII)

Grafik: Manu Cornet / Bonkersworld.net - CC BY-NC-ND 3.0

Das wirklich Bemerkenswerte an dieser Darstellung ist ihr Alter - sie ist aus dem Jahr 2011, hat aber bis heute nichts von ihrer Aktualität eingebüsst. Ein zeitloser Klassiker.

Change Management (II)

Grafik: Pixabay / Mohammed Hassan - Lizenz

Change Management ist einer dieser Begriffe, die je nach Betrachtungsweise unterschiedliche Bedeutungen haben können - von denen aber keine einzige die "offiziell richtige" ist. Das kann Gespräche und Vorhaben zu diesem Thema leicht in Missverständnisse führen. Um das zu vermeiden hilft es, sich die verschiedenen möglichen Bedeutungen bewusst zu machen, um auf dieser Basis gemeinsam explizit zu machen, welche man gerade meint.

Eine Möglichkeit sich dem zu nähern ist die Frage, was genau im Change Management eigentlich "gemanaged" wird, denn das ist tatsächlich keineswegs so eindeutig wie es auf den ersten Blick scheinen mag (der Grund dafür ist die Vieldeutigkeit des englischen Wortes "Management", der nicht-Muttersprachlern zum Teil nicht bewusst ist). Gegenstand des Change Managements können nämlich sowohl die Veränderungen selbst sein, als auch der Umgang mit ihnen.

Die erste Variante dürfte auch die eingängigere sein. In ihr ist Change Management die Summe aller Tätigkeiten, durch die Veränderungen auf Organisationsebene (Team, Abteilung, Firma, etc.) ausgelöst, verhindert, begleitet, durchgeführt, verstärkt, abgeschwächt, beendet oder verstetigt werden sollen. Diese Art von Tätigkeiten ist im klassischen Projektmanagement häufig Teil eines Change Management Plans, dessen Einhaltung Gegenstand von Controlling und Reporting ist.

Die zweite Variante ist in gewisser Weise eine Äquivalenzklasse zu Konzepten wie Stress Management und Anger Management und kann sich ggf. mit diesen überschneiden. In ihr ist Change Management ein auf individueller Ebene stattfindender (und ggf. professionell begleiteter) Prozess, in dem es darum geht, zu erkennen, ob und wie man von Veränderungen betroffen ist, welche persönlichen Konsequenzen sich daraus ergeben und wie man mit ihnen stress- und frustrationsvermeidend umgehen kann.

Je nach Art der Veränderung kann die zweite Variante auch eine soziale Dimension haben, also ganze Gruppen betreffen, die dann gemeinsam einen Weg finden müssen, damit umzugehen. Das ist vor allem dann der Fall, wenn gemeinsame identitätsstiftende Elemente sich ändern oder ändern sollen, zum Beispiel (organisatorische) Zugehörigkeiten, Ziele und Aufgaben, aber auch Überzeugungen, Identitäten, Gewohnheiten oder Erwartungen.

Man kann schnell erkennen, dass diese beiden Varianten des Change Managements vollkommen unterschiedliche Notwendigkeiten, Herausforderungen und Rahmenbedingungen mit sich bringen, und ggf. sogar gegenläufig zueinander sein können, etwa dann, wenn auf organisations-Ebene Veränderungen schnell vorangetrieben werden sollen, während auf Personen- oder Gruppenebene der Wunsch vorherrscht, diese zu verlangsamen, um sich besser auf sie einstellen zu können.

Wenn Veränderungsvorhaben auf den Weg gebracht werden, kann es daher eine gute Idee sein, zu Beginn ein gemeinsames Verständnis darüber herzustellen, was in diesem Fall unter dem Begriff Change Management verstanden wird. Das mag zwar etwas abstrakt und theoretisch wirken, auf lange Sicht kann man sich dadurch aber einiges an Missverständnissen und Konflikten ersparen, wodurch die Veränderungsarbeit dann einfacher und tendenziell auch erfolgreicher wird.

Agile ≠ Improvement

Bild: Unsplash / Jessica Gale - Lizenz

Ich kann es nicht mehr genau nachvollziehen, aber mittlerweile dürfte ich über hundert Job-Interviews mit Scrum Mastern, Agile Coaches und Inhabern ähnlicher Rollen geführt haben, sowohl für meine eigene Firma als auch für verschiedene Kunden. Und selbst wenn es die eine entscheidende Antwort auf sie nicht gibt, mit der Zeit habe ich eine Frage gefunden, mit der sich gut feststellen lässt, ob mein aktueller Gegenüber wirklich verstanden hat, was es mit dem Konzept der Agilität auf sich hat.

Sie ist relativ einfach: "Gibt es irgendeinen Kontext, in dem es nicht sinnvoll ist, agil zu arbeiten?" Erstaunlich viele Bewerber verneinen das und versteifen sich darauf, dass es immer sinnvoll wäre, agil vorzugehen. Und wenn man darum bittet, das zu erklären, erfolgt fast immer die selbe Erläuterung: "Es gibt immer irgendetwas, was man besser machen kann. Deshalb ist es grundsätzlich in jeder Situation eine gute Idee, agil vorzugehen".

Der grundsätzliche Denkfehler, der dieser Argumentation zu Grunde liegt (und durch den man zeigt, die Idee der Agilität noch nicht zur Gänze verstanden zu haben) ist die Gleichsetzung von agilem Arbeiten mit der Suche nach Verbesserungspotential. Dabei handelt es sich allerdings um eine Verwechselung der notwendigen und der hinreichenden Bedingung. Wer agil arbeiten will, muss zwar nach Verbesserungen suchen, aber nicht jeder der nach Verbesserungen sucht, arbeitet agil.

Um das zu erläutern: eine agile Vorgehensweise unterscheidet sich von der blossen Suche nach Verbesserungspotential durch zwei Eigenschaften: sie findet kontinuierlich statt und sie ist potentiell disruptiv. Und auch die lassen sich nochmal besser erläutern, angefangen mit der ersten. Eine Suche nach Verbesserungen könnte auch jährlich oder quartalsweise stattfinden. Um das agil-typische ständige Inspect & Adapt zu erfüllen reicht das aber nicht - kontinuierlich bedeutet hier eher monatlich.¹

Jetzt zur zweiten, etwas schwerer zu erklärenden Eigenschaft: die blosse Suche nach Verbesserungen kann auch lediglich auf Effizienzsteigerungen ausgerichtet sein, also darauf, einfach schneller und reibungsloser zu arbeiten. Agiles Arbeiten ist dagegen auf Effektivitätssteigerung ausgerichtet, also auf die Frage, ob überhaupt noch am richtigen Thema gearbeitet wird, oder ob sich Rahmenbedingungen oder Ziele inzwischen so geändert haben, dass man eine grundsätzlich andere Richtung einschlagen solllte.

Diese Möglichkeit, die bisher verfolgten Zielsetzungen anzupassen, ist das, was agiles Arbeiten disruptiv macht. Und da diese Richtungsanpassung nichts ist, was man bei jeder Verbesserungsbemühung zwangsläufig machen sollte, sondern nur dann, wenn man darin einen Sinn erkennt, ist Agilität nicht zwangsläufig disruptiv sondern lediglich potentiell disruptiv. Es kann zu einer grundsätzlichen Anpassung kommen, es muss aber nicht. Notwendige und der hinreichende Bedingung.

Um auch die anderen Vorgehensmodelle beim Namen zu nennen - seltene (bzw. nicht-kontinuierliche) Veränderungen entsprechen dem klassischen Verbesserungsmanagement, dessen explizites oder implizites Ziel die (Wieder-)Herbeiführung eines stabilen Zustandes ist. Und kontinuierliche, aber nicht disruptive Optimierungen finden sich im Lean Management, das einen gleich bleibenden Ablauf nach und nach immer effizienter machen will.

Diese drei Typen (agiles Arbeiten, klassisches Verbesserungsmanagement und Lean Management) unterscheiden zu können ist etwas, das jeder Scrum Master oder Agile Coach eigentlich beherrschen sollte - zumindest dann, wenn er in einer beratenden Funktion arbeitet, sei es extern (wie in meiner Firma) oder intern (als Change Agent innerhalb einer Organisation). Kann man das noch nicht ist das zwar kein Drama, aber ein deutlicher Hinweis darauf, wo noch dazugelernt werden muss.

¹Wenn sich gerade jemand fragt, woher diese Festlegung kommt - aus dem Manifest für agile Softwareentwicklung, dem Gründungsdokument der agilen Bewegung.

Working on Software in the Desert and the Forest

Zu den wichtigsten Praktiken des Extreme Programming gehört der Einsatz von Metaphern, mit deren Hilfe man komplexe Sachverhalte einfach erklären kann. Zu den prominenteren Beispielen der letzten Zeit gehören dabei the Desert and the Forest von Kent Beck und Beth Andres-Beck. Der Wald (Forest) steht dabei für eine Umgebung, in der moderne Software-Entwicklungspraktiken möglich sind, während sie in der Wüste (Desert) nicht angewandt werden können. In diesem Konferenz-Vortrag erklären sie, was sich hinter diesen Metaphern verbirgt.

Erwähnenswert ist dabei ihre Einordnung ihres Konzepts in die Realitäten der Softwareentwicklung in vielen Firmen. Die Wüste gilt bei ihnen nicht als etwas per se Schlechtes, sondern als etwas was historisch gewachsen ist, durchaus Ergebnisse bringen kann (wenn auch relativ langsam) und durch die richtigen Entscheidungen nach und nach zu einem Wald werden kann.

Bürokratisierung der Entbürokratisierung

Vor einiger Zeit reifte in einer Behörde, deren IT-Projekte ich begleiten durfte, die Einsicht, dass die eigenen Prozesse zu starr und zu langwierig waren. Um dem zu begegnen wurde ein neues "Referat für den Abbau von Bürokratie" geschaffen, das dem entgegenwirken sollte. Seine erste Amtshandlung bestand darin, alle anderen Referate anzuweisen, alle ihre Arbeitsabläufe detailliert zu dokumentieren. Auf Basis dieser Dokumente sollte dann entschieden werden, wo Bürokratie abgebaut werden könnte.

Dieses widersinnige Vorhaben (das nicht zu weniger sondern zu mehr Verwaltungsaufwand führte) gehört zu einem Trend, den der Soziologie-Professor Stefan Kühl treffend als "Bürokratisierung der Entbürokratisierung" beschrieben hat. Hinter ihm verbergen sich die zunehmend verbreiteten Massnahmen, Bürokratieabbau, Digitalisierung, Effizienzzsteigerung und ähnliche Dinge dezidierten Organisationseinheiten zuzuordnen - und damit versehentlich alles nur noch schlimmer zu machen.

Diese Verschlimmerung ergibt sich aus verschiedenen, mit grosser Wahrscheinlichkeit eintretenden Dynamiken. Zunächst gibt es für die neue Zentraleinheit starke Anreize, Informierungs-, Beteiligungs- und sonstige Pflichten anzuordnen, wodurch es wie im Fall des oben genannten Bürokratieabbau-Referats dazu kommen kann, dass alleine der dadurch notwendige Kommunikationsaufwand zu der perversen Konsequenz führt, dass alles ineffizienter wird statt effizienter.

Wenn es darüber hinaus dazu kommt, dass nicht nur über die eigenen Prozesse berichtet werden muss, sondern Änderungen an ihnen zentral begutachtet und ggf sogar genehmigt werden müssen, wird die dafür zuständige Einheit zu einem verlangsamenden Flaschenhals für alle anderen. Schlimmstenfalls kann es dazu kommen, dass selbst dringende und von allen gewollte Änderungen lange verzögert werden, weil die für die Freigabe zuständigen Personen überlastet sind.

Als Folge dessen kann es sogar zu nochmals weiteren Verschlechterungen kommen: um eine eigene Überlastung zu verhindern oder abzubauen neigen viele Zentraleinheiten dazu, der restlichen Organisation einheitliche Vorgehensmodelle oder Berichtsformate vorgeben zu wollen, um deren Lage einfacher verstehen und vergleichen zu können. Diese Vereinheitlichung kann oft nur auf Kosten der optimalen Bedienung der lokalen Bedürfnisse erreicht werden.

Gleichzeitig entstehen demotivierende Auswirkungen für die dezentralen Einheiten. Wenn plötzlich alle eigenen Verbesserungsbemühungen zu Dokumentations- und Kommunikationsmehraufwand führen und darüber hinaus befürchtet werden muss, dass von aussen gut gemeinte Verschmlimmbesserungen stattfinden, dann ist das ein Anreiz, solche Bemühungen gar nicht mehr (oder nur lokal, unangekündigt, unabgestimmt und intransparent) durchzuführen.

Zuletzt stehen Bürokratieabbau-Einheiten aufgrund der mit ihnen verbundenen Erwartungen und Aufwände unter hohem Erfolgsdruck, der (vor allem dann wenn die Erfolge Voraussetzung für Gehalts-, Karriere- und Statusverbesserungen sind) dazu führen kann, dass Fortschritte aufgebauscht und voreilig oder wahrheitswidrig verkündet werden, mit der Folge, dass vordergründig Verbesserungen stattzufinden scheinen, während in Wahrheit Verspätung, Stillstand und Verschlechterungen vorherrschen.

Die Zuordnung von Bürokratieabbau, Digitalisierung, Effizienzzsteigerung, etc. zu dezidierten Organisationseinheiten ist aus all diesen Gründen mit dem hohen Risiko verbunden, das Gegenteil des Angestrebten zu erreichen. Ein wesentlich besserer Weg kann es sein, dezentrale Freiräume für Verbesserungsbemühungen (incl. Zeit und Budget) zu schaffen, alleine verbunden mit der Bedingung einer transparenten Durchführung, um auf versehentliche Fehlentwicklungen hinweisen zu können.

Und um Missverständnissen vorzubeugen - Referate die den Abbau von Bürokratie bürokratisieren gibt es nicht nur in der staatlichen Verwaltung, sondern auch in der freien Wirtschaft. Sie tragen dort nur andere Namen, z.B. Prozessmanagement, Inhouse Consulting, Betriebsorganisation oder Agiles Transitionsteam.

Nachtrag 24.04.2025:

Stefan Kühl hat seine Gedanken zur Bürokratisierung der Entbürokratisierung im Sozialtheoristen-Blog präzisiert.

Business Owner (BO)

Bild: Wikimedia Commons / JCS - CC BY 3.0

Sobald agiles Arbeiten über die Teamebene hinaus in einem Unternehmen etabliert werden soll, stossen praktisch alle agilen Frameworks auf das immer gleiche Problem: oberhalb der Teams und um die Teams herum gibt es vor allem in grösseren Firmen eine unberschaubare Zahl von Management-Rollen. Teilprojekt-, Projekt- und Programmleiter, Test-, Release- und Security Manager, Heads of Legal, Product und Sales, Team- Abteilungs- und Bereichsleiter und viele, viele mehr. Was macht man jetzt mit denen?

In den meisten Fällen gibt es darauf keine klaren Antworten; Scrum, Kanban, DevOps und fast alle weiteren agilen Vorgehensmodelle befassen sich einfach nicht mit diesem Thema, was Unklarheit und Unsicherheit zur Folge hat. Schlimmstenfalls erwächst aus dieser Unklarheit sogar ein Konflikt - wenn den verschiedenen Managern gesagt wird, dass sie im Umfeld selbstorganisierter Teams bald nicht mehr benötigt werden, werden die meisten von ihnen natürlich um ihren Status und ihre Karriere kämpfen.

Und auch das gehört dazu: viele der bisherigen Management-Aufgaben können nicht so einfach dezentral in alle Teams delegiert werden. Irgendjemand muss die grossen strategischen Entscheidungen treffen, irgendjemand muss Ansprechpartner für Gehaltsverhandlungen, Beförderungen, Versetzungen und Eskalationen sein, und irgendjemand muss letzten Endes die Verantwortung tragen, wenn es um zivilrechtliche Haftungsfragen geht, etwa wegen Verstössen gegen Arbeitsschutz oder Compliance.

Das meines Wissens nach einzige agile Framework, dass diese Umstände in seinem Regelwerk berücksichtigt (wenn man von einigen offensichtlich nur halb-ernst gemeinten Management-Rollen in Extreme Programming absieht) ist das Scaled Agile Framework/SAFe, in dem eine Rolle enthalten ist, die einen Grossteil der oben genannten Verantwortungen enthalten kann - wenn auch nicht in jedem Fall enthalten muss. Die Rede ist von dem Business Owner (BO).

Auf der entsprechenden Website beschreibt SAFe fünf Aufgabenbereiche, die ein BO haben kann: Leading by Example, Engaging in Lean Portfolio Management, Aligning Priorities & PI Planning, Realizing Business Outcomes und Sponsoring Relentless Improvement. Wie vieles andere in diesem Framework ist das im Folgenden gleichzeitig hinreichend unkonkret um individuell ausgestaltet zu werden und spezifisch genug um "agile Puristen" zu provozieren.

Zu den hinreichend unkonkreten Formulierungen, mit denen die fünf Aufgabenbereiche beschrieben werden, gehören beispielsweise mehrere, in denen davon die Rede ist, durch eigenes Verhalten ein Vorbild zu sein, Visionen zu kommunizieren, anderen Führungsrollen zu helfen, den Geschäftskontext zu vermitteln, den Teams Feedback zu geben und andere zu motivieren. Dahinter kann sich alles Mögliche verbergen, von der Sonntagsrede bis zur Hands On-Unterstützung.

Provozierend für agile Puristen sind weitere Formulierungen, die implizieren, dass die Business Owner Aufgaben übernehmen können, die auch von selbstorganisierten Teams direkt übernommen werden könnten. Das Vermitteln bei internen Konflikten und Widerständen gehört dazu, das Organisieren teamübergreifender Communities of Practice, Stakeholdermanagement, Abhängigkeitsmanagement, die Beseitigung von Impediments, die Definition von KPIs und die Optimierung von Arbeitsflüssen.

Während diese beiden Aufgabenbereiche diskutierbar und ggf. verzichtbar sind, gibt es aber einen dritten, der unverzichtbar und entscheidend ist - das Schaffen optimaler Rahmenbedingungen: Business Owner sind zuständig für die Bereitstellung von ausreichend Budget, Personal und Ressourcen, für das Setzen und Anpassen strategischer Ziele sowie für das Beseitigen demotivierender Vorschriften und Prozesse. Das sind Schlüsseltätigkeiten, auf deren Basis Selbstorganisation überhaupt erst möglich ist.

Insgesamt ergibt sich so ein für SAFe typisches Bild: mit der BO-Rolle werden Dinge thematisiert und formalisiert die wichtig sind, in anderen agilen Frameworks aber nicht erwähnt werden. Gleichzeitig sind sie aber eingebettet in eine Menge weiterer derartig unscharf formulierter Vorgaben, dass auf deren Basis praktisch alles möglich ist, unterstützender von Hilfe zur Selbstorganisation bis hin zu übergriffigem Hineinregieren in die Teams.

Um das Positive darin zu sehen - wenn man im Unternehmen ein Management mit einer (aus einer "agilen Perspektive") "richtigen" Einstellung hat, kann man seine Mitglieder als Business Owner auf passende, hilfreiche und sinnstiftende Weise einbinden. Wenn auf der anderen Seite eine eher "falsche" Einstellung vorherrscht, würde auch ein methodischer Rahmen ohne diese Rolle nur in begrenztem Ausmass für Verbesserung sogen. In diesem Sinn: gebt den BOs eine Chance.

Vibe Coding

Es kommt nicht mehr oft vor, dass eine neue Art der Software-Programmierung erfunden wird, aber es kommt vor, zuletzt im Februar 2025 durch Andrej Karpathy, einen slowakisch-kanadischen Software-Entwickler und ehemaligen Manager von Tesla und OpenAI. Der neue Programmier-Stil wurde von ihm in einem Posting im Social Nework X zum ersten mal beschrieben und Vibe Coding genannt. In kurzer Zeit erreichte er weitgehende Bekanntheit. Hier ist seine Beschreibung:

Zu Deutsch: Vibe Coding benötigt eine künstliche Intelligenz mit Spracherkennung. In der Interaktion mit dieser gibt man sich ganz seiner gegenwärtigen Stimmung (den Vibes) hin, äussert Wünsche und Vorstellungen und und lässt die KI auf diese Weise fast ausschliesslich durch Spracheingabe ein Stück Software erstellen, das dann irgendwann mehr oder weniger fertig und lauffähig ist. Mit Karpathys eigenen Worten: "just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works".

Aufbauend auf diesen Beitrag kam es in kurzer Zeit zu zahlreichen Artikeln in Medien wie Fortune, Forbes, TechCrunch und New York Times, die grossteils den selben Tenor hatten: Programmieren lernen ist nicht mehr nötig, auch als Laie kann man jetzt Software erstellen. Viele dieser Beiträge waren ausserdem verbunden mit marktschreierischen Verheissungen (jeder kann jetzt ein Startup gründen und reich werden) oder Untergangsszenarien (alle Entwickler werden bald arbeitslos sein).

Dass all das erkennbar an der Realität vorbeigeht hätte man dabei bei einem sorgfältigeren Lesen von Karpathys Post leicht erkennen können. Wie er selbst schreibt und wie kritische Stimmen bald anmerkten führt Vibe Coding dazu, dass selbst der "Urheber" nicht mehr genau sagen kann, wie sein Code entstanden ist und was er im Detail tut. Im besten Fall führt dieser Blindflug zu vielen kleinen Bugs, im schlechtesten Fall zu schweren Fehlfunktionen. Zum Herumspielen ist das gut, zu mehr aber nicht.

In diesem Herumspielen steckt allerdings auch eine Potential, das man nicht verachten sollte: mit Vibe Coding erstellte Anwendungen taugen zwar nicht für echte Markt- oder Produktions-Anwendungen, was sie aber sein können sind erstaunlich realitätsnahe Prototypen, mit denen man in Product Discovery oder Lean Startup Nutzerbedürfnisse und Nutzungsbereitschaft evaluieren kann, um sich dann schnell dem Bedarf anzupassen - frühe Entwicklungsphasen lassen sich so deutlich beschleunigen.

Und was ebenfalls oft nicht ausreichend beachtet wird: das "Programmieren" mit Hilfe gesprochener Prompts führt dazu, dass Anforderungen wesentlich klarer und präziser formuliert werden müssen als das in den meisten klassischen Anforderungs-Dokumenten der Fall ist, die oft eher kryptisch, verschachtelt und inkonsistent sind. Am Ende hat man im Vibe Coding also gleich zwei Ergebnisse - einen vorführbaren Prototyp und klarer formulierte Wünsche und Anforderungen.

Natürlich entspricht das bei weitem nicht den oben genannten, durch marktschreierische Berichterstattung hervorgerufenen Erwartungen oder Befürchtungen. Es ist aber in mehrfacher Hinsicht eine deutliche mögliche Verbesserung im Vergleich zum Ist-Zustand. Um eine Prognose zu wagen: als Buzzword wird Vibe Coding wieder verschwinden, die möglichen Mehrwerte werden aber bleiben und auf einem geringeren Aufmerksamkeits- und Verheissungsniveau zu deutlichen Verbesserungen führen.

Kommentierte Links (CXXV)

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.

Lavaneesh Gautam: Behind the Bottlenecks - The Root Causes of Dependencies in Teams

In komplexen Umgebungen ist es sehr häufig so, dass sich hinter scheinbar einfachen Begriffen erstaunlich vielschichtige Sachverhalte verbergen. Dass das auch im Fall der Abhängigkeiten so ist arbeitet Lavaneesh Gautam sehr schön heraus: je nachdem ob sie durch berufliche Spezialisierung, geteilte Verantwortlichkeiten, Architektur-Muster oder Organisationsdesign verursacht werden, können sie sehr unterschiedliche Formen annehmen und unterschiedliche Behandlung erfordern.

Roman Pichler: Setting up Product Teams for Success

Seit einigen Jahren haben die Konzepte von agiler Entwicklung und Product Thinking begonnen sich mehr und mehr zu überlagern. Dieser Artikel von Roman Pichler könnte daher auch "Setting up agile Teams for Success" heissen, die relevanten Parameter sind die gleichen. Wie immer sollte man das Ganze nicht unreflektiert als Blaupause benutzen, es ist aber einguter Denkanstoss.

Militarnyi: Saab Develops Anti-Aircraft System in Record 84 Days

Ich bin schon lange überzeugt, dass agiles Arbeiten überall möglich ist, wenn der Sense of Urgency gross genug ist. Ein (drohender) Krieg ist leider gerade der unter diesen Treibern, der stark zunimmt. Als Ergebnis sehen wir plötzlich auch bei hochkomplexen Produkten Entwicklungsgeschwindigkeiten, die wir noch vor wenigen Jahren für unmöglich gehalten hätten. Und die Erfolgsmechanismen sind die bekannten: Modularität, Einfachheit des Designs und Entscheidungsspielraum der Umsetzungsmannschaft.

Pawel Rola: Product Backlog Management with Upstream Kanban – From Chaos to Clarity

Mal wieder ein Klassiker. Pawel Rola erklärt sehr gut nachvollziehbar, wie die Nutzung von Kanban-Praktiken dafür sorgen kann, dass der Anforderungsmanagement-Prozess eines agilen Teams transparenter, expliziter und flüssiger werden kann. Und das sogar in Übereinstimmung mit den Vorgaben, die Scrum für ein Product Backlog macht - man muss es einfach nur horizontal abbilden statt vertikal, und alles passt wunderbar zusammen.

John Ward: Agile marketing - The source of enterprise agility

Als Letztes etwas zum Nachdenken. John Wards Idee, dass Enterprise Agility (also die Fähigkeit einer Gesamtorganisation, sich schnell an Veränderungen anzupassen) nur unter Einbezierung des Marketings möglich ist, ist naheliegend. Das Marketing dabei als treibende Einheit zu sehen ist aber eher selten, diese Rolle haben meistens eher IT oder HR. Ein interessanter Ansatz.

The Law of unintended Consequences

Bild: Flickr / McKinney75402 - CC BY 2.0

Unter den verschiedenen "Gesetzmässigkeiten", die in Projektmanagement-Kreisen gerne zitiert werden, nimmt das Gesetz der unbeabsichtigten Konsequenzen eine Sonderstellung ein. Anders als fast alle anderen (Conway's Law, Gall's Law, Goodhart's Law, etc) ist es nicht nach einer Person benannt, die es erfunden und popularisiert hat, sondern ist nach und nach in den Wirtschafts- und Sozialwissenschaften entwickelt worden, u.a. von John Locke, Adam Smith und Friedrich Hayek.

Sie alle hatten unabhängig voneinander die folgende Einsicht: wer in komplexen, vernetzten oder volatilen Systemen Veränderungen vornimmt, der wird nicht nur den Effekt erzielen den er beabsichtigt,¹ sondern auch andere, unbeabsichtigte. Zu einem "Gesetz" wird es dadurch, dass diese ungewollt eintretenden Konsequenzen praktisch unvermeidbar sind, einzig ihre Art und Intensität kann von Fall zu Fall anders sein. Vereinfacht gesagt sind mindestens sechs verschiedene Varianten möglich:

Unerwartete positive Konsequenzen

Der beste Fall der eintreten kann, in ihm treten positive Effekte auf, mit denen man gar nicht gerechnet hatte. Ein Beispiel wäre ein Sparkurs, durch den ein Grossprojekt auf nur noch wenige Teams zusammenschrumpft. Da diese jetzt jeweils mehr Themengebiete abdecken müssen, werden sie crossfunktionaler und weniger arbeitsteilig, wodurch nicht nur die Personalkosten sinken, sondern auch der bisherige Koordinationsaufwand und mit ihm weitere Kosten.

Unerwartete negative Konsequenzen

Das Gegenteil des ersten Falls. Ein Beispiel dafür wäre die Neueinführung gehaltsrelevanter Ziele für einzelne Mitarbeiter. Die arbeiten dann zwar mit gesteigerter Motivation an diesen Zielen, aber das im Zweifel auch auf Kosten der gemeinsamen Team- oder Unternehmensziele. Ein Sicherheitsbeauftragter, der für jeden gefundenen Regelverstoss belohnt wird, hat etwa einen starken Anreiz, seine Kollegen mit einer lähmenden und demotivierenden Kontroll-Bürokratie zu überziehen.

Unerwartete perverse Konsequenzen

Eine derartige Übersteigerung der negativen Konsequenzen, dass es sogar zu einer Verschlechterung in dem Bereich kommt, der eigentlich verbessert werden sollte. Ein bekannter Fall der Versuch, durch die Einführung von gemeinsamen Grossraumbüros die Kommunikationsbarrieren zwischen Mitatarbeitern abzubauen. Forschungsergebnisse zeigen, dass das Gegenteil der Fall ist - um den Geräuschpegel auszublenden werden Headsets aufgesetzt, wodurch die Kommunikation sogar zurückgeht.

Unerwartete positive Seitenauswirkungen

In diesem Fall treten unbeabsichtigte positive Effekte auf, die ihre Auswirkungen in einem anderen Bereich entfalten als dem, in dem die Veränderungen stattgefunden haben. So können Programme zur Förderung von Achtsamkeit und Sorgfalt nicht nur zu geringeren Fehlerquoten bei der Arbeit führen, sondern auch zu einem generell bewussteren und verantwortungsvolleren Konsumverhalten, wodurch im Privatleben der Beteiligten weniger Haushaltsmüll erzeugt wird.

Unerwartete negative Seitenauswirkungen

Wieder das Gegenteil des letzten Falls, hier tretennegative Effekte in einem anderen Bereich auf als dem, in dem die Veränderungen stattgefunden haben. Wenn eine Firma beispielsweise Kosten senken will indem sie von externen Mitarbeitern Gebühren für die Nutzung des eigenen Parkhauses verlangt, wird sie dadurch die Verkehrs- und Parkplatz-Situation in der Nachbarschaft verschlechtern, da auf die hier befindlichen Pakkplätze ausgewichen wird.

Sonstige unerwartete Seitenauswirkungen

Auch das gibt es - unbeabsichtigte Auswirkungen auf andere Bereiche als den, in dem die Veränderungen stattgefunden haben, die weder positiv noch negativ sind. Ein anschaulicher Fall dafür wäre eine Firma, die im Rahmen eines Corporate Design-Relaunch die Farbe ihrer Dienstwagen von Gelb zu Grün ändert. Das Strassenbild der Umgebung wird das zwar verändern, allerdings nicht zum Besseren oder Schlechteren, es sieht einfach nur anders aus.

Welche auch immer es sind, die Gemeinsamkeit der verschiedenen unbeabsichtigten Konsequenzen ist, dass sich weder ihre Art noch die Schwere ihrer Auswirkungen vorhersagen lassen. Dort wo in komplexen, vernetzten oder volatilen Systemen Veränderungen vorgenommen werden, ist es daher eine gute Idee, regelmässig zu überprüfen, ob derartige Effekte auftreten. Nur dann ist es möglich ggf. schnell Gegenmassnahmen zu ergreifen. Auch hier gilt also wieder: Inspect & Adapt.

¹Falls der überhaupt eintritt

Agile Success Stories: Agile by Accident

Bild: Pexels / Moe Magners - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) mit der Zeit eine eher negative Weltsicht entwickeln ist schade, aber erklärbar. Wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht in Frustration und Fatalismus 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 habe ich mehrfach in ähnlicher Form erlebt, aber die an die ich gerade denke, begann damit, dass ich als externer Scrum Master oder Agile Coach in eine Firma gekommen bin und dort Teams vorgefunden habe, die mir gleich zu Beginn Eines unmissverständlich klar machen wollten: dass es agiles Arbeiten bei ihnen nicht geben würde. Sie hätten das bereits versucht gehabt, es sei furchtbar gewesen und sie wären heilfroh, es zugunsten eines besseren Vorgehens  hinter sich gelassen zu haben.

Bedingt dadurch, dass ich diese Erfahrung wie gesagt bereits mehrfach gemacht habe, lasse ich mich in derartigen Situationen zunächst noch auf keine Diskussion über das zukünftige Vorgehen ein, sondern lasse mir zuerst erklären, warum der agile Arbeitsmodus als so furchtbar empfunden wurde und was den stattdessen gewählten so viel besser macht. Und es stellte sich dabei heraus, dass hier zwei aufeinander aufbauende Missverständnisse vorlagen.¹

Das erste dieser Missverständnisse betraf das, was dort irgendwann mal unter dem Namen "Agile" eingeführt worden war. Mit der zugrundeliegenden Idee hatte das eher wenig zu tun, stattdessen wurden lediglich zusätzlich zu den bereits bestehenden (und z.T. unverändert gültigen) Prozessen einzelne aus Scrum oder SAFe entlehnte Meetings, Titel und Begriffe eingeführt, die aber ohne geänderte Rahmenbedingungen nichts verbessert sondern nur alles verkompliziert hatten. Cargo Cult also.

Aufbauend darauf war das zweite Missverständnis entstanden. Da "Agile" als komplizierter, unverständlicher und bürokratischer Prozess wahrgenommen wurde, hatten die Teams stattdessen ein Alternativvorgehen entwickelt, dass auf direkter Kommunikation, crossfunktionaler Zusammenarbeit, wenigen Regeln, kurzen Lieferzyklen und regelmässigen Prozessverbesserungen beruhte.² Folgerichtig hielten sie dieses Vorgehen für nicht-agil und dem agilen Arbeiten überlegen.

Als ich auf diese beiden Missverständnisse hinwies, und darauf, dass der "nicht-agile Arbeitsmodus" in Wirklichkeit sehr agil war, waren zunächst Überraschung und Unglaube gross. Erst nachdem sich einige Teammitglieder bereiterklärten, einige der Originalquellen (Scrum Guide und Agiles Manifest) zu lesen, setzte sich langsam die Erkenntnis durch, dass sie die Idee falsch verstanden hatten, und durch die Abwehr der Cargo Cult-Methode "versehentlich" agil geworden waren.

Wirklich warm geworden sind sie mit dem Begriff zwar nicht mehr, dafür hatten sie sich bereits zu sehr auf ihn eingeschossen. Aber ganz ehrlich - sie waren nah am Kunden, lieferten regelmässig Mehrwert aus, passten das eigene Vorgehen regelmässig an und arbeiteten gut zusammen. Angesichts dessen war die Ablehnung des Wortes "Agil" ein Thema, das man mit gutem Gewissen vernachlässigen konnte. Wenn das Ergebnis stimmt, ist der Name des Prozesses nicht so wichtig.

¹Es gab natürlich auch Fälle in denen agiles Arbeiten verstanden und trotzdem abgelehnt wurde. Das ist nochmal ein eigenenes Thema.
²Dieses selbstentwickelte Vorgehen war auch deutlich schlanker und effektiver als der ursprüngliche, "vor-agile" Prozess

The Philosophy of Architecture

Das hier gefällt mir wirklich: Barry O'Reilly versucht sich an einem philosophischen Blick auf das Konzept der Software-Architektur. Verkürzt gesagt - während sie häufig als ein logischer und konsistenter Ansatz zur Strukturierung von Software gesehen wird, ist sie in Wirklichkeit eine soziale Technik, mit der versucht wird, Ordnung in eine Welt zu bringen, die sich in einem Prozess der permanenten Unordnung befindet.

Alleine die oben genennten Gedanken hätten vermutlich schon für einen eigenen Vortrag gereicht, aber dieser geht deutlich weiter, und berührt unter anderem Essentialismus, Strukturalismus, Determinismus (und dessen Negierung), die Diskrepanz zwischen Sein und Werden, Positivismus, Interpretivismus, naive Kybernetik, Kausalität, Dekonstruktion und die philosophischen Grundlagen der Matrix-Filmreihe. Definitiv sehens- und hörenswert.

Warum deutsche Unternehmen keine Silicon Valley-Startups kaufen sollten

Bild: Pexels / Yan Krukau - Lizenz

Das Silicon Valley - Speerspitze des Fortschritts, Verkörperung technischer Disruptionen, Geburtsstätte bahnbrechender Innovationen und immerwährender Kreativität. Sich durch die Übernahme eines dort angesiedelten Startups in diese Wunderwelt einzukaufen erscheint den Managern vieler deutscher Konzerne und Mittelständler eine gute Idee zu sein, in der Realität enden diese Zukäufe allerdings meistens in Enttäuschungen. Und dass es immer wieder so kommt ist kein Zufall.

Um es vorwegzunehmen: was jetzt folgt ist anekdotische Evidenz. Ich habe einige dieser gescheiterten Silicon Valley-Expansionen selbst miterlebt, bei einigen weiteren kenne ich Menschen die dabei waren. In Summe lediglich eine niedrige zweistellige Zahl von Fällen, also Nichts was wissenschaftliche oder statistische Validität hätte. Da aber bestimmte Probleme immer wieder aufgetreten sind, glaube ich, dass es hier erkennbare (und prognostizierbare) Muster gibt.

Um mit dem Folgenschwersten (und auf den ersten Blick unglaublichsten) zu beginnen - die meisten deutschen Unternehmen sind sehr schlecht im Gestalten und Befolgen von Prozessen. Das kann bedeuten, dass es selbst für zentrale Geschäftsvorgänge keine klare Definition gibt (v.a. im Mittelstand anzutreffen), oder dass in Konzernen alles so überreguliert ist, dass die Mitarbeiter gezwungen sind, sich auf informelle Prozesse zurückzuziehen, um überhaupt arbeitsfähig zu sein (→ brauchbare Illegalität).¹

In beiden Fällen ist das Ergebnis, dass neue Mitarbeiter die inoffiziellen, aber für das Funktionieren der Firma elementaren Prozesse erst nach und nach herausfinden müssen, da diese lediglich im kollektiven Gedächtnis festgehalten sind. In Folge dessen dauert es entsprechend lange bis sie wirklich arbeitsfähig sind - sechs bis zwölf Monate sind in grossen Unternehmen nicht ungewöhnlich. Da in Deutschland viele Angestellte jahrzehntelang in ihrer Firma bleiben, ist das aber ein eher geringes Problem.

Im Silicon Valley findet man gleichzeitig ein Muster, das mit dem zuvor genannten komplett inkompatibel ist - die meisten Angestellten bleiben weniger als zwei Jahre bei einem Arbeitgeber, viele wechseln sogar mehrmals im Jahr. Das langsame Aufbauen von Wissen über die inoffiziellen Prozesse ist daher nicht möglich, weshalb die offiziellen möglichst minimalistisch gehalten, dafür aber strikt durchgesetzt und neuen Mitarbeitern durch starke und umsetzungsnah agierende Manager vermittelt werden.

Übernimmt jetzt ein deutsches Unternehmen ein Silicon Valley-Startup, kommt es mit hoher Wahrscheinlichkeit zu einem Culture Clash: in der (unbewussten) Erwartung, dass sich die Mitarbeiter die (inoffiziellen) Prozesse mit der Zeit selbst aneignen werden, wird von den deutschen Managern ein weniger strikter Führungsstil eingeführt. Der ständig wechselnden Belegschaft fehlen damit sowohl die schnelle Einweisung in die offiziellen, als auch das langsame Erlernen der inoffiziellen Prozesse.

Die unvermeidbare Folge eines derartigen Zusammenpralls so unterschiedlicher und inkompatibler Unternehmenskulturen ist ein erstaunlich schnelles Zusammenbrechen von Abläufen und Strukturen. Innerhalb von ein bis zwei Jahren sind kaum noch Kollegen da, die Erfahrung damit haben, die Prozesse am Laufen zu halten, stattdessen sind die meisten erst seit einigen Monaten an Bord, wurden nie richtig eingearbeitet und sind dadurch nur eingeschränkt zu effektivem Arbeiten in der Lage.

Diesem rapiden Verfall des intellektuellen Kapitals folgt meistens ein genauso schneller Einbruch der Produktqualität. Marktforschung, Product Discovery, technische Exzellenz und Qualitätssicherungs-Routinen sind mit den sich auflösenden Strukturen und Prozessen nur noch eingeschränkt durchführbar, Bugs und technische Schulden häufen sich an, die Umsetzungsgeschwindigkeit sinkt und mit ihr die Wettbewerbsfähigkeit und die Marktanteile. Irgendwann kann man alles nur noch abwickeln.

Selbst wenn diese Abläufe immer wieder zu beobachten sind, sind sie natürlich kein Naturgesetz. Sind die zugrundeliegenden Muster einmal erkannt, kann man gegensteuern und eine Silicon Valley-Tochtergesellschaft auch von Deutschland aus gut führen. Voraussetzung dafür ist allerdings, sich die Unzulänglichkeit oder Lückenhaftigkeit der meisten offiziellen Prozesse einzugestehen und ihre Unbrauchbarkeit in einer Umgebung mit hoher Personalfluktuation zu erkennen. Eine hohe Hürde.

¹Natürlich ist in der Regel ein Grossteil der Prozesse gut beschrieben und wird auch befolgt, bei einem signifikanter Teil ist es aber umgekehrt.

Wie man ein Spezialistenteam reibungslos auflöst

Bild: Unsplash / Annie Spratt - Lizenz

Zu den Grundüberzeugungen aller agilen Frameworks gehört, dass Entwicklungsteams nach Möglichkeit Crossfunktional sein sollten, also in der Lage, alle im Rahmen der Produktentwicklung nötigen Tätigkeiten selbst durchzuführen, ohne dabei von anderen Abhängig zu sein. In traditionell arbeitenden Unternehmen dominieren dagegen die Spezialistenteams, die nur eine bestimmte Spezialtätigkeit beherrschen, die aber besonders effizient.

Am Anfang von agilen Transitionen stehen daher häufig Reorganisationen, in denen die Spezialistenteams aufgelöst und ihre Mitglieder auf die neuen, crossfunktionalen Teams verteilt werden. Wenn es in solchen Situationen aber mehr dieser neuen Teams gibt als bisher Spezialisten, treten Probleme auf. In den einen Teams feht das Spezialistenwissen, sie sind also doch wieder von anderen abhängig. Die anderen Teams müssen wiederum die erste Gruppe unterstützen, was zu Defocussierung und Prioritätskonflikten führt.

Um das zu vermeiden ist es sinnvoll, die Auflösung der Spezialistenteams nicht von jetzt auf gleich durchzuführen, sondern im Rahmen eines langsamen Prozesses, während dem immer mehr Wissen und Zuständigkeiten in die Breite verlagert werden. Wie das im Einzelnen geschehen kann wird natürlich von Fall zu Fall unterschiedlich sein, es gibt allerdings einen Denkansatz, mit dessen Hilfe sich der Übergang strukturiert durchführen lässt: Team Topologies.

Team Topologies geht von vier grundlegenden Team-Typen aus: Stream-aligned Teams (crossfunktional, können alles selbst), Enabling Teams (befähigen andere Teams), Complicated Subsystem Teams (besondere Spezialistenteams, deren Tätigkeit sich nicht so einfach aufteilen lässt) und Platform Teams (stellen anderen Teams Produkte oder Dienstleistungen zur Verfügung, die diese ohne externe Unterstützung sich selbst beschaffen und benutzen können). Mehr dazu hier.

Da spezialisierte Teams in Team Topologies den Complicated Subsystem Teams entsprechen sind diese der Ausgangspunkt, von dem aus zwei Weiterentwicklungen möglich sind: entweder sie können ihr Spezialgebiet zu einer Plattformdienstleistung umwandeln, die von den anderen Teams in einem Selbstbedienungs-Modus genutzt werden kann, oder sie wandeln sich zu enabling Teams indem sie das, was sie bisher selbst gemacht haben, anderen beibringen.

Häufige Anwendungsfälle für die Weiterentwicklung in Richtung Platform Team sind Spezialisten-Einheiten, von denen bisher Werkzeuge, Daten oder Infrastruktur verantwortet wurden. Die können in Selbstbedienungs-Portale überführt werden, in denen man sich Entwicklungsumgebungen, Testdaten, Anleitungen, Nutzungs-Simulationen o.ä. konfigurieren kann, die dann automatisiert erstellt und zur Verfügung gestellt werden.

Alternativ kann das bisherige Spezialisten-Team seine bisher verantworteten Themen direkt an die neuen, crossfunktionalen Teams weitergeben, allerdings mit einer wichtigen Ergänzung - statt diese mit ihrer neuen Aufgabe alleinzulassen, stehen die bisherigen Spezialisten als Trainer, Ratgeber, Erklärer und Notfallhelfer zur Verfügung, und das so lange bis sichergesetellt ist, dass ihre Unterstützung nicht mehr benötigt wird und sie sich neue Aufgaben suchen können.

In beiden Fällen (Umwandlung in ein Platform Team und Umwandlung in ein Enabling Team) kann es schliesslich zu einer finalen Entwicklungsstufe kommen, in der sich die ursprüngliche Spezialisteneinheit zwar auflöst, als "virtuelles Team" aber erhalten bleibt. Das kann z.B. in Form einer Community of Practice stattfinden, in der (ggf wechselnde) Vertreter aller crossfunktionalen Teams gemeinsam eine Platform-Dienstleistung oder einen Wissenstransfer am Leben halten.

In der Realität findet man derartige kontrollierte Auflösungsprozesse von Spezialistenteams übrigens in den meisten Fällen ohne die Nutzung der Teams Topologies-Begriffe. Das ist auch vollständig in Ordnung, es handelt sich bei ihnen nicht um eine Prozessvorgabe, sondern um nur ein Denkwerkzeug, mit dem man abstrakte Konzepte in Worte fassen kann.

Overcompliance

Wer versucht in grossen Organisationen Bürokratie zu bekämpfen, der wird möglicherweise an der folgenden paradoxen Situation vorbeigekommen sein: während die Ausführungs-Ebene unter der Last der Prozesse und Vorschriften ächzt, ist sich die Führungsebene keiner Schuld bewusst, und kann sogar darauf verweisen, dass das offizielle Regelwerk sogar relativ schlank ist. Für diesen scheinbar widersinnigen Zustand gibt es einen häufigen Grund: Overcompliance.

Um das besser begreifen zu können schauen wir uns zunächst den zugrundeliegenden Begriff an: die Compliance. Hinter ihm verbirgt sich die anzustrebende Regelkonformität von Unternehmen, Behörden und sonstigen Organisationen, also die Einhaltung von Gesetzen, Richtlinien und internen Vorschriften. Compliance zu haben (bzw. Compliant zu sein) ist als Folge dessen das Ziel zahlreicher Prozesse, Tätigkeiten und Organisationseinheiten, die nur zu diesem einen Zweck existieren.

Das Problem bei der Herstellung von Compliance ist allerdings, dass es an ihren Rändern eine Grauzone gibt. Ab wann wird aus einer Routine ein zu dokumentierender Prozess? Gibt es Bagatellgrenzen für Zeit-, Qualitäts- und Budgetabweichungen? Wann können Anweisungen mündlich erfolgen, wann ist die Text-Form ausreichend und wann ist die Schriftform nötig? Alle diese Fragen sind in den Einzelfällen nicht immer eindeutig zu beantworten und lassen einen Interpretationsspielraum offen.

So lange dieses freie Interpretieren innerhalb der Grauzone keine negativen Folgen hat, ist das auch meistens unproblematisch, schwierig kann es aber werden, wenn das zu Unfällen, Qualitätsmängeln oder versehentlichen Regelverstössen führt. Viele Organisationen kehren in derartigen Situationen den Interpretationsspielraum um - alles woraus sich eine wie auch immer geartete Verantwortlichkeit ableiten lässt, wird rückwirkend zur Norm erklärt - oft mit disziplinarischen Folgen für die Betroffenen.

Und an dieser Stelle kommt es zur Overcompliance: um nicht ebenfalls oder erneut für etwas zur Verantwortung gezogen zu werden, was sich innerhalb einer Grauzone abspielt, beginnen die Mitarbeiter jetzt die jeweils strengste (und für sie sicherste) Auslegung der Gesetze, Richtlinien und internen Vorschriften anzuwenden. Im Zweifel also alles dokumentieren und schriftlich genehmigen zu lassen, und bereits kleinste Abweichungen zu verfolgen und zu eskalieren.

Bereits das kann lähmende Auswirkungen auf nahezu alle Abläufe haben, im schlimmsten Fall kann es aber sogar noch schlimmer werden - wenn es als Reaktion auf eine kontrollierende und überwachende Variante der Overcompliance dazu kommt, dass selbst für kleinste Aufwände explizite und schriftliche Anweisungen und Abnahmen nötig sind (gewissermassen Gegen-Overcompliance), ist es nicht mehr weit bis zu gegenseitigen Blockaden und bis zum totalen und dauerhaften Stillstand.

Um sich aus einer derartigen Situation zu befreien (oder um es gar nicht erst soweit kommen zu lassen) sind zwei Dinge notwändig: zum einen muss man akzeptieren, dass sich nicht alle Eventualitäten vorhersehen und mit vertretbarem Aufwand regulieren lassen, und zum anderen muss man darauf verzichten, nach in Grauzonen stattgefundenen Unfällen, Qualitätsmängeln oder versehentlichen Regelverstössen immer nach einem Schuldigen zu suchen und ihn bestrafen zu wollen.¹

Was darüber hinaus ein sinnvolles Werkzeug für die Verhinderung von Overcompliance sein kann, ist eine Vereinbarung, bei allen Regel-Umsetzungen immer die am wenigsten restriktive Variante anzustreben und von anderen zu fordern. Idealerweise kann das sogar Teil eines "Gesellschaftsvertrages" werden, an dem sich die gemeinsame Zusammenarbeit ausrichtet und auf den man sich bei Prozessgestaltungen, in Konflikten und bei Meinungsverschiedenheiten berufen kann.

¹Das bedeutet natürlich nicht, dass man darauf verzichtet, daran zu arbeiten, dass sich derartige Vorfälle nicht wiederholen - das geht aber auch ohne Schuldzuweisungen

Ein Bild sagt mehr als 1000 Worte (XLVI)

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

Erinnert mich ein bisschen an den Klassiker I fucked up Git so bad it turned into Guitar Hero.

Thermal Teams

Bild: Pixabay / Ferafba - Lizenz

Fast immer wenn in grossen Organisationen der Handlungsdruck gross ist, Termine stark in Gefahr geraten oder irgendwie Nichts weitergeht, werden Task Forces gegründet - kleine, crossfunktionale und auf eine einzige Aufgabe focussierte Einheiten, die die anstehenden Aufgaben schnell erledigen können. Eine Frage die in solchen Situationen häufig gestellt wird ist die, ob sich dieser Arbeitsmodus nicht formalisieren lässt, um in Zukunft von Anfang an derartig lieferfähig sein zu können.

Die Antwort: natürlich geht das, und in verschiedenen Unternehmen gibt es auch Beispiele dafür. Ein prominentes sind die Thermal Teams oder Thermal Projects bei Twitter, bzw. X, deren Funktionsweise die beiden Manager Keith Coleman (VP of Product) und Jay Baxter (ML Lead) in Lenny's Podcast erklärt haben. In Anlehneng an die thermischen Aufwinde, die Vögeln das Fliegen erleichtern, handelt es sich bei ihnen um vom Top-Management geförderte Vorhaben mit besonders guten Rahmenbedingungen.¹

Wie immer in solchen Fällen gilt natürlich auch in diesem hier, dass es sich um eine Fallstudie aus einem sehr spezifischen, nicht in allen Asspekten nachvollziehbaren Kontext handelt, die darum nicht mit Copy & Paste in andere Unternehmen übertragbar ist. Allerdings handelt es sich auch um eine der bekanntesten und erfolgreichsten IT-Firmen der Welt, so dass es durchaus interessant und inspirierend sein kann, sich deren Vorgehensmodell anzuschauen.²

Die erste der oben genannten fördernden Rahmenbedingungen ist bei Twitter/X das Vorhandensein eines möglichst hochrangigen Sponsors (idealerweise in Person von Elon Musk selbst), der auch als Eskalations-Instanz dient, wenn es mit anderen Team zu Konflikten über Architektur, Ressourcen oder Sonstiges kommt. Das sorgt nicht nur für ein schnelles Lösen von Blockaden, es limitiert indirekt auch die Zahl der Thermal Teams, da die Anzahl möglicher Sponsoren nur klein ist.

Bei der nächsten fördernden Rahmenbedingung handelt es sich um die Selbst-Auswahl der Teammitglieder. Wenn der Start eines neuen derartigen Teams verkündet wird, sucht nicht das Management die aus seiner sicht passenden Entwickler aus, sondern diejenigen die Interesse haben melden sich selbst.³ Dadurch ist sichergestellt, dass alle Beteiligten intrinsisch motiviert sind und bereit sind, ihr gesamtes Leistungsvermögen einzubringen.

Als nächste Besonderheit sind die so entstehenden Einheiten möglichst klein, mit im besten Fall deutlich weniger als zehn Teammitgliedern, wodurch die interne Kommunikation einfacher und schneller wird. Ein begrenzender Faktor ist dabei, dass möglichst crossfunktionale Einheiten angestrebt werden, die alle in Frage kommenden Arbeiten selbst ausführen können. Dort wo hohe Spezialisierung nötig ist, führt das ggf. zu grösseren Gruppen.

Wichtig ist ausserdem, dass Thermal Teams soweit wie möglich von allen anderen Verpflichtungen und Vorschriften befreit sind. Das bedeutet vor allem, dass sie nicht parallel in anderen Projekten mitarbeiten dürfen und sich nicht mehr an anderen Meetings und Reportings beteiligen müssen, es bedeutet aber auch, dass sonst vorgehebene Tools und Standards nicht mehr benutzt werden müssen. Coleman und Baxter nennen als Beispiel Jira, von dessen Nutzung Thermal Teams befreit sind.

Als letztes ist von Bedeutung, dass diese Art von Teams bei Twitter/X nur jeweils für eine begrenzte Zeit bestehen sollen (daher auch die alternative Benennung Thermal Projects). Die Grümde dafür dürften offensichtlich sein: zum einen wird so ein Abrutschen in Routinen und ein Zurückgehen der besonderen Motivation verhindert, zum anderen können die Teammitglieder in ihre ursprünglichen Einheiten zurückkehren, in denen ihre Beteiligung schliesslich auch benötigt wird.

Wie oben gesagt, die Idee der Thermal Teams ist nichts was andere Unternehmen einfach kopieren sollten, dafür ist der Kontext in dem sie funktionieren zu spezifisch. Es kann aber eine gute Idee sein, einzelne Elemente davon zu übernehmen, bei sich zu testen, ggf. anzupassen und so sein eigenes Vorgehensmodell zu entwickeln, mit dem sich der eher unstrukturierte Taskforce-Modus ablösen lässt.

¹Anscheinend gehörte es zur Firmenkultur von Twitter, vor allem Namen mit Vogelbezug auszuwählen
²Auf einem völlig anderen Blatt stehen der Besitzer und die Community-Regeln von X, um die geht es hier nicht
³Bei zu vielen, zu wenigen oder ungeeigneten Bewerbungen wird es vermutlich doch zu Management-Entscheidungen kommen

Kommentierte Links (CXXIV)

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.

Luxshan Ratnaravi: The Six Agile People Manager Stances

Über die Jahre hat es immer wieder Artikel gegeben, die die verschiedenen Ausprägungen verschiedener agiler Rollen beschrieben haben: für den Scrum Master, den Product Owner, den Agile Coach, den Agile Leader, den Tech Lead, etc. Luxshan Ratnaravi hat aber tatsächlich noch eine weitere Rolle gefunden, mit der das anscheinend noch nicht passiert ist - den Agile People Manager. Was in dieser Galerie aber bemerkenswerterweise immer noch fehlt, sind die Developer.

Jeff Sutherland: Mastering Agile Spikes for Smarter Resource Management

Anscheinend hat Jeff Sutherland, der Godfather of Scrum, eine neue Firma, JVS Management. Auf deren Seite findet sich diese Übersicht über den Einsatz von Spikes in Extreme Programming und Scrum, von ihrem Ursprung über ihre Einsatzmöglichkeiten bis hin zu einer Case Study. Wie in Sutherlands gesamtem Spätwerk finden sich auch kontroverse Passagen (z.B. "The PO assigns a fixed number of story points to a Spike"), insgesamt ist es aber ein guter Überblick.

Salvatore Sanfilippo: We are destroying software

Ich bin nicht sicher, ob das, was Salvatore Sanfilippo hier verfasst hat, eine blosse Aufzählung ist, eine nüchterne Analyse, eine Anklageschrift, ein Rant, ein Wutausbruch oder eine kopfschüttelnd vorgetragene Betrachtung der über die Zeit aufgekommenen Missstände und Missverständnisse der modernen Softwareentwicklung. Vermutlich ist es von allem etwas, vorallem ist es aber eines: sehr schön minimalistisch im Layout. Das ist doch schon mal etwas.

Doc Norton: Fixing Full-Stack Teams; Specialization Required

Was Doc Norton hier adressiert ist ein häufiges Missverständnis, dass das in agilen Unternehmen meistens angestrebte Full Stack-Prinzip umgibt - hinter diesem Konzept verbirgt sich nicht die Idee, dass jedes Mitglied eines solchen Teams in der Lage ist, alle für dieses Team anliegenden Aufgaben zu erledigen. Stattdesssen sind die Team-Mitglieder in Summe dazu in der Lage. Ist das einmal verstanden werden die Diskussionen um das Full Stack-Prinzip sofort weniger emotional.

Charity Majors: Corporate “DEI” is an imperfect vehicle for deeply meaningful ideals

Der Zeitgeist bewegt sich gerade nicht unbedingt in die Richtung von DEI (Diversity, Equity and Inclusion) - und das nicht nur zu Unrecht, sicher ist dieser Ansatz an einigen Stellen zu weit getrieben worden. Dass er aber grundsätzlich gut ist arbeitet Charity Majors hier sehr schön heraus, einschliesslich der Widerlegung einiger weit verbreiteter Missverständnisse.

Der andere Kanban Guide

Bild: Flickr / Rosenfeld Media - CC BY 2.0

Einer der grossen Unterschiede zwischen den beiden populärsten agilen Frameworks, Scrum und Kanban, war immer, dass Scrum mit dem Scrum Guide ein verbindliches Regelwerk hatte, während Kanban trotz weit verbreiteter und allgemein anerkannter Praktiken eher "Open Source" war, so dass jeder hineindefinieren und -interpretieren konnte was er wollte. Diese Unklarheit hat immer wieder den Wunsch nach einem "Kanban Guide" aufkommen lassen.

Die erste Organisation die versucht hat diese Lücke zu füllen (bzw. den damit verbundenen Zertifizierungs-Markt zu erschliessen) war die Lean Kanban University, die 2016 den trotz seines Namens etwas aufgeblähten Essential Kanban Condensed Guide veröffentlichte, der dann 2021 durch den schlankeren "Official" Kanban Guide abgelöst wurde. Aufgrund seines Namens wird der immer wieder für das einzige und verbindliche Kanban-Regelwerk gehalten.

Da der Begriff und die Idee von Kanan nicht geschützt sind, gibt es aber auch Alternativen, unter denen die vielleicht bekannteste schlicht The Kanban Guide heisst. Selbst wenn seine Verfasser Daniel Vacanti und John Coleman mit ProKanban (einer anderen Zertifizierungs-Organisation) verbunden sind, ist das Dokument bewusst nicht mit deren Brand verbunden oder auf deren Website gehostet, um so seinen universellen Anspruch und seinen nicht-kommerziellen Charakter hervorzuheben.

Von seiner Struktur her organisiert er sich sehr stark am Scrum Guide, bis hin zu dem Punkt, dass mehrere seiner Abschnitte fast identisch benannt sind (Purpose of the Kanban Guide statt Purpose of the Scrum Guide, Definition of Kanban statt Scrum Definition, Kanban Theory statt Scrum Theory, etc.).¹ Lediglich in seinem Mittelteil gibt es Abweichungen, gegen Ende entspricht der Aufbau mit End Note und Acknowledements wieder sehr stark dem des Scrum Guides.

Inhaltlich sind es auch vor allem diese mittleren Abschnitte, die Kanban Practices, das Improving the Workflow und die Kanban Measures die interessant sind.² Den grössten Teil nehmen dabei die Practices ein, es handelt sich bei ihnen um Defining and Visualizing the Workflow, Actively Managing Items in a Workflow, Controlling Work In Progress und  Service Level Expectation.³ Nach Ansicht der beiden Autoren handelt es sich dabei um die unverzichtbaren Kernbereiche der Kanban-Methode.

Hinter Defining and Visualizing the Workflow verbirgt sich das explizit machen des eigenen Arbeitsflusses, wodurch erkennbar wird wer im Rahmen seines Ablaufs was macht, in welcher Reihenfolge, mit welchen Schnittstellen-, bzw. Übergabe-Kriterien und welchen Kontrollmechanismen. Genannt wird das Ganze Definition of Workflow (DoW) - auch hier erkennt man wieder eine Parallele zum Scrum Guide und seiner Definition of Done (DoD).

Mit Actively Managing Items in a Workflow sind im Kanban Guide die Tätigkeiten gemeint, die den reibungslosen Durchfluss von Arbeit durch das System sicherstellen oder wiederherstellen sollen. Im Einzelnen sind das Controlling Work in Progress (d.h. dessen Menge), Avoiding work items piling up in any part of the workflow, Ensuring work items do not age unnecessarily (mit Hilfe von Service Level Agreements) und Unblocking blocked work.

Mit Controlling Work in Progress und Ensuring work items do not age unnecessarily bekommen die erste und letzte der zuletzt genannten Tätigkeiten noch einen eigenen Abschnitt, in dem tiefergehend erläutert wird, was sich dahinter verbirgt, bzw. welche weiteren Konzepte damit verbunden sind. Hier finden sich u.a. auch das Pull-Prinzip und das probabilistische Forecasting, die damit im Vergleich zu anderen Kanban-Auslegungen eine eher wenig prominente Plazierung haben.

Im Vergleich dazu ist das Improving the Workflow relativ knapp beschrieben. Hervorgehoben wird vor allem, dass es überhaupt stattfinden sollte, dass es auf der Grundlage von Zahlen und/oder Erfahrungen erfolgen sollte und dass es Verbesserungen der Effizienz, Effektivität und Vorhersagbarkeit zum Ziel haben sollte. Bemerkenswert ist, dass explizit nicht nur kleine sondern auch grosse Verbesserungen möglich sind, also nicht nur Kaizen sondern auch Kaikaku.

Die Kanban Measures sind schliesslich wieder die grossen Klassiker: Work in Progress-Menge, Throughput, Work Item Age und Cycle Time (Lead Time dagegen bemerkenswerterweise nicht). Neben ihrer kurzen Erklärung wird noch unterstrichen, dass sie nur zum Zweck der Prozessverbesserung erhoben und kein Selbstzweck sein sollen, und dass es möglich ist, sie um weitere Metriken zu ergänzen, wenn man darin einen Mehrwert sieht.

Was der Kanban Guide nicht (bzw. nur als Nennung optionaler Möglichkeiten) enthält, sind Meetings und Rollen. Es wird zwar erwähnt, dass es möglich ist, Dailies und Retrospektiven (die hier nur Reviewing the Definition of Workflow from Time to tTime heissen) abzuhalten, von einer zu starken Formalisierung wird aber abgeraten. Im Fall der Rollen ist nicht mal das gegeben, sie werden an keiner Stelle des Kanban Guide auch nur erwähnt, geschweige denn vorgegeben.

Zur Bewertung, bzw. Einordnung: das auf den ersten Blick Auffälligste am Kanban Guide dürfte die starke Anlehnung seiner Struktur an die des Scrum Guide sein. Die mag ihre Vorteile haben, da jemand der bisher nur Scrum kennt sich leichter zurechtfinden wird, andererseits wirkt sie etwas gezwungen und z.T. sogar un-originell, etwa in den End Note, die in einigen Passagen eine Eins-zu Eins-Kopie ist. Auch die Definition of Workflow wirkt etwas gezwungen.

In Abgrenzung zum "Official" Kanban Guide der Kanban University ist erkennbar, dass die jeweiligen Verfasser jeweils unterschiedliche Elemente für wichtig oder verzichtbar gehalten haben. Während z.B. im "Official" Kanban Guide Aufbau und Nutzung eines Kanban-Boards einen grossen Platz einnehmen, fehlen sie in The Kanban Guide völlig. Das macht einmal mehr die Gestaltungsoffenheit von Kanban deutlich (die dann allerdings mit den Mindestvorgaben der Verfasser kollidiert).

Genau die Offenheit an dieser Stelle, durch die klar wird, dass Kanban zwar in Form eines Boards mit Kartenoder Kacheln dargestellt werden kann, aber keinerswegs dargestellt werden muss, ist übrigens eine, die grossen Teilen der Kanban-Community fehlt (Alternativen sind Ampelfarben, Kontroll-Charts, Kummulative Flussdiagramme, etc.). Alleine in dieser Hinsicht ist Vacantis und Colemans Guide eine wertvolle Ergänzung.

Auffällig ist ausserdem, dass ihr Regelwerk nochmal kürzer und komprimierter ist als die von Scrum und der Kaban University. Einschliesslich Inhaltsverzeichnis umfasst er nur neun Seiten. Aufgrunddessen kann man ihn auch ohne grossen Aufwand als Ergänzung zum nur unwesentlich längeren Guide der Kanban University benutzen, alleine um verschiedene Blickwinkel auf das Thema Kanban zu bekommen, dass sich mit einem Dokument alleine kaum abbilden lässt.

¹Sogar die URL ist ähnlich: https://kanbanguides.org statt https://scrumguides.org
²Ähnlich wie im Scrum Guide ist der Theorieteil sehr kurz und besteht im Wesentlichen aus einer Aufzählung zugrundeliegender Methoden und Frameworks
³Es gibt zwar eine deutsche Übersetzung, da deren Wortwahl mitunter etwas sperrig ist bevorzuge ich das englische Original

Bürokratie

Bild: Flickr / Queensland State Archives - Public Domain

Die Klagen über zu viel Bürokratie kennt man aus nahezu jeder grösseren Organisation, egal ob in der freien Wirtschaft, in der staatlichen Verwaltung oder bei Nichtregierungsorganisationen. Erstaunlich ist dabei aber in fast allen Fällen, dass es sich um eher unspezifische Beschwerden handelt - meistens werden nur zu viele Prozesse und Vorschriften genannt, ohne die genauer zu beschreiben. Dabei ist es durchaus möglich, diese aufzuschlüsseln, um sie deutlich klarer erkennen und ggf. beseitigen zu können.

Wichtig ist dabei, dass die offiziellen Kategorien nur eingeschränkt hilfreich sind, da es sich bei ihnen oft um Sammelbegriffe für verschiedene vorgeschriebene Tätigkeiten handelt. So kann sich z.B. hinter einer Sorgfaltspflicht oder einer Nachweispflicht alles Mögliche verbergen, mit je nach Einzelfall deutlich unterschiedlichen Auswirkungen. Eine differenzierte Betrachtung macht daher Sinn, und mit ihr kommt man zu dieser (sicherlich unvollständigen) Liste bürokratiefördernder Vorgaben:

Durchführungspflichten

Hier geht es darum, wer was zu tun hat und in welcher Reihenfolge der Arbeitsschritte. Das kann abstrakt sein, wie bei der Vorgabe eines Vier-Augen-Prinzips, aber auch komplizierte vorgegebene Abläufe umfassen, z.B. bei der Wartung einer Maschine.

Informierungspflichten

Aufbauend auf den Durchführungspflichten geht es als nächstes darum, andere über das was man selbst getan hat (oder vorhat) in Kenntnis zu setzen. Detailgrad und Empfänger können dabei je nach Fall unterschiedlich sein, wichtig ist, dass irgendjemand informiert worden ist.

Begründungspflichten

Bereits etwas einengender. Es reicht nicht mehr, zu berichten, was man getan hat oder vorhat, es muss auch klar werden, aus welcher Motivation heraus das geschieht, mit welchem Ziel oder auf wessen Anweisung. Eine häufige Erweiterung ist die Begründung für den Durchführungszeitpunkt.

Dokumentationspflichten

Die Formalisierung der Informierungspflichten. Der Kommunikationskanal zur Übermittlung der Informationen ist nicht mehr frei wählbar sondern vorgegeben, am häufigsten ist dabei die Vorgabe der Schriftform (ggf. verstärkt durch die Pflicht zur persönlichen Identifikation durch Unterschreiben).

Formatierungspflichten

In gewisser Weise die Formalisierung der Formalisierung. Es reicht nicht mehr, in irgendeiner Form die Informationen über die eigenen Handlungen zu übermitteln, auch die Struktur dieser Information wird jetzt vorgegeben, z.B. in Form einer Tabelle oder eines Formulars.

Nutzungspflichten

Die Vorgabe von Arbeitswerkzeugen. Das können physische Werkzeuge sein, digitale Werkzeuge aber auch bestimmte Räumlichkeiten, in denen Arbeit verrichtet werden muss. Eine noch immer erstaunlich häufige Extremform ist die an den hierarchischen Rang gekoppelte Vorgabe der Tintenfarbe.

Unterlassungspflichten

Das Spiegelbild der Nutzungspflichten. In einer restriktiven Variante ist alles zu unterlassen, was nicht explizit zur Nutzung vorgegeben ist, in einer offeneren Variante sind nur solche Handlungen zu unterlassen, die explizit verboten werden. Beides kann aber ggf. zu Handlungsunfähigkeit führen.

Anhörungspflichten

Während die zuvor genannten Pflichten eine Person oder Organisationseinheit selbst betreffen, werden jetzt andere einbezogen, die ein Recht darauf haben, ihre Meinung zu den Sachverhalten abzugeben, über die sie informiert wurden (ggf. mit der Erweiterung, dass diese festzuhalten ist).

Beteiligungspflichten

Mit dieser Stufe ist das Mitwirken Anderer nicht mehr optional und auf die Meinungs- oder Bewertungsabgabe beschränkt, sondern verpflichtend und in die Arbeitsabläufe fest eingebunden, z.B. in Form einer Zulieferung oder Qualitätssicherung.

Kenntnisnahmepflichten

Das Gegenstück zu den Informierungspflichten. Wer auch immer Informiert wird darf das nicht einfach ignorieren, sondern ist verpflichtet, es selbstverantwortlich zur Kenntnis zu nehmen und von sich aus zu reagieren, wenn er angehört oder beteiligt werden will.

Überprüfungspflichten

Die Steigerung der Kenntnisnahmepflichten. Übermittelte Informationen müssen nicht nur zur Kenntnis genommen, sondern auf ihre Richtigkeit und ggf. Angemessenheit überprüft werden, einschliesslich einer Rückmeldung, wenn eines davon nicht gegeben sein sollte.

Genehmigungspflichten

Die Formalisierung und Generalisierung der Überprüfungspflichten. Übermittelte Informationen müssen nicht mehr nur zur Kenntnis genommen und ggf. überprüft werden, ohne eine auf dieser Überprüfung beruhende Freigabe darf der jeweilige Arbeitsvorgang nicht fortgesetzt werden.

Rechtfertigungspflichten

Spätestens an dieser Stelle wird es unangenehm. Wenn ein Überprüfungs- oder Genehmigungsprozess zu einem negativen Ergebnis führt, ist zu erklären, durch welche Fehler oder Nachlässigkeiten es überhaupt dazu kommen konnte.

Qualifizierungspflichten

Sowohl als Folge von Überprüfungs- oder Genehmigungsprozessen oder vorbeugend kann es sein, dass bestimmte Ausbildungen oder Schulungen verpflichtend vorgegeben werden, in der Regel vermunden mit der Pflicht zum Nachweis der Teilnahme oder des Bestehens einer Prüfung.

Weiterbildungspflichten

Die Verstetigung der Qualifizierungspflichten. Es reicht nicht mehr aus, Ausbildungen oder Schulungen einmal zu durchlaufen, es muss darüber hinaus in regelmässigen Abständen zu Wiederholungen, Auffrischungen, Erweiterungen oder Resensibilisierungen komen.

Stellenbesetzungspflichten

Eine Konsequenz aus den zuvor genannten Pflichten. Um ihre Erfüllung mit der nötigen Kapazität, Qualifikation und Aufgabenteilung durchführen zu können, sind Planstellen notwendig. Eigentlich nur ein Symptom der Bürokratisierung, selbst wenn es oft selbst für Bürokratie gehalten wird.

Wie oben gesagt, diese Auflistung ist sicher noch unvollständig, dass die Befolgung aller dieser Pflichten in erheblichem Ausmass zu Bürokratie im Sinn von formalisierter, nicht Mehrwert schöpfender Verwaltungsarbeit führen kann (und meistens auch führen muss), dürfte aber offensichtlich sein. Und trotzdem ist es so, dass sie alle in jeder grösseren Organisation anzutreffen sind (wenn auch in unterschiedlicher Ausprägung).

Dass das so ist, liegt daran, dass keine dieser Vorgaben komplett unsinnig ist, in jeder von ihnen wird man einen Kern von Sinnhaftgkeit finden können, schliesslich erfüllt Bürokratie durchaus einen Zweck. Es kann also kein Ziel sein, sie (oder die ihr zu Grunde liegenden Pflichten) komplett abzuschaffen. Stattdessen muss es darum gehen, die Bürokratie auf das sinnvolle Mindestmass zu beschränken - im Zweifel durch regelmässige Evaluierung und Justierung.

Und jetzt kommt es: um Evaluierung und Justierung durchführen zu können, sind wieder einige der oben genannten Pflichten notwendig, selbst wenn auch diese zwangsläufig bis zu einem gewissen Grad bürokratisch sein müssen Die finale Pointe lautet also - um Bürokratie zu bekämpfen, braucht man noch mehr Bürokratie.