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.

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.