On Lean and Agility

Agile Transformationen hat es mittlerweile viele gegeben, und dementsprechend auch viele Erfahrungsberichte. Dieser hier gefällt mir, da er nicht nur eine der üblichen (und meistens geschönten) Erfolgsgeschichten ist, sondern klar benennt, dass es Probleme gegeben hat, und welche.

Darüber hinaus bietet die Referentin Polina Patsulda einen Blick in ihren Werkzeugkoffer, in dem sich vom Scarf Model über den Kübler Ross-Zyklus bis Radical Candor verschiedene Ansätze befinden, von denen man erfahren kann, wie sie hier eingesetzt wurden. 

Bild: Unsplash / Vitaly Gariev - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, RTEs etc.) mit der Zeit eine eher negative Sicht auf die Welt entwickeln ist bedauerlich, aber erklärbar. Wer sich täglich mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Ich durfte vor einiger Zeit als externer Berater eine agile Transformation eines grossen Konzerns begleiten, zu welcher eine ganze Reihe von Massnahmen gehörte: Reorganisation von Spezialisten-Gruppen zu crossfunktionalen Teams, Delegation von Verantwortung nach unten, Abbau von Vorschriften, Einführung von Retrospektiven und vieles mehr - was aber nach Aussage fast aller Beteiligten die wichtigste Änderung war, war die der Budgetierung.

Bis zu diesem Zeitpunkt waren die Budgetierungsprozesse so verlaufen wie in den meisten Unternehmen. Ein Budget "gehörte" einer Fachabteilung oder Initiative, die mit den umsetzenden Einheiten aushandelte, was sie dafür erhalten würde. Ab da wurden die Arbeitsstunden den jeweiligen Budgetposten zugeordnet - und nur an Arbeitspaketen für die noch Budget vorhanden war, durfte auch gearbeitet werden. Arbeit an nicht budgetierten Aufgaben war nicht erlaubt.

Dieses Vorgehen hatte ursprünglich einen sinnvollen Kern gehabt, so sollte sichergestellt werden, dass nur an den aus Unternehmenssicht wirklich wichtigen Aufgaben gearbeitet wurde, denn nur die hatten ein Budget erhalten. Für eine Welt sich schnell ändernder Märkte und Technologien war es aber zu langsam und zu bürokratisch - wer den Umsetzungsplan ändern wollte, musste bis zur nächsten (jährlichen) Budgetierung warten oder ausufernde Change Request-Dokumente ausfüllen.

Da das dazu geführt hatte, dass selbst offensichtlich notwendige Planungs-Änderungen nicht stattgefunden hatten, war die Trennung von Arbeitsplanung und Budgetierung eines der Hauptziele der agilen Transformation gewesen. Und glücklicherweise liess sich das Management auch von einem alternativen Ansatz überzeugen: von Beyond Budgeting, das bereits in den 70er und 80er Jahren in Skandinavien entwickelt worden war.

Im Rahmen seiner Umsetzung wurde die harte Verdrahtung von Budgets und Fachbereichs-Anforderungen aufgehoben, stattdessen wurden den Entwicklungsteams jeweils Budgets für ganze Jahre zugewiesen, die lediglich mit groben Themengebieten wie z.B. Zahlungsabwicklung oder Kundenkommunikation verbunden waren. Dass an den wichtigsten Dingen gearbeitet wurde, wurde nicht mehr über die Budgets, sondern durch eine übergreifende Priorisierung sichergestellt.

Wenn sich jetzt während der budgetierten Zeiträume Notwendigkeiten oder Prioritäten änderten, war es nicht mehr nötig, die ganze Finanzplanung anzupassen, es musste nur die übergreifende Priorisierung geändert werden. Natürlich war auch das mit Arbeit verbunden, im Vergleich zum alten Vorgehen war der Aufwand aber deutlich geringer. Dass notwendige Planungs-Änderungen aus Abneigung gegen den damit verbundenen Arbeitsaufwand verschoben wurden, kam ab da kaum noch vor.

Auch die budgetierten Zeiträume selbst wurden flexibler gestaltet. Es gab zwar weiterhin Jahrespläne, diese fanden aber auf einem eher hohen Abstraktionsgrad statt. Das Herunterbrechen erfolgte jeweils zum Beginn der Quartale, wodurch ein längeres Auseinanderlaufen aus (Budget-)Planung und Arbeits-Fortschritt vermieden werden konnte. In einer späteren Phase der agilen Transition wurde diese Quartalsplanung als Ressort-übergreifendes Big Room Planning durchgeführt.

Zur ganzen Geschichte gehört auch, dass diese Umstellungen nicht ohne Konflikt abgelaufen sind. Den Verlust der Kontrolle über die Detail-Budgetierung empfanden manche Fachbereichs-Manager auch als Verlust von Status und von Druckmitteln, die bisher zur Durchsetzung eigener Ziele gegen andere Interessen genutzt werden konnten. Am Ende konnte Beyond Budgeting deshalb auch nicht überall umgesetzt werden. Dort wo es gelungen war, führte es allerdings zu deutlich effektiverem Arbeiten.

Die Geschichte von den zwei Wettbewerbern, die um die Wette an einer gleichen Software bauen, um als erster eine Marktlücke besetzen zu können, ist mittlerweile altbekannt. Und genau so alt sind die Zweifel: ist das wirklich jemals irgendwo so passiert? Seit kurzem können wir das nicht nur bejahen und mit einem Beispiel belegen, sondern sogar mit einem besonders wilden. Es geht um eine Branche im Umbruch, um eine einmalige Gelegenheit, um künstliche Intelligenz - und um den Nationalsozialismus.

Beginnen wir mit der Branche im Umbruch, mit den Medien. Bereits seit Jahrzehnten gehen die Zahlungsbereitschaft der Leser und mit ihnen auch Umsätze und Gewinne zurück. Gleichzeitig wird der Wettbewerb härter - die Nachrichten gibt es einen Klick weiter auf einer anderen Website umsonst. Um Abonnements zu verkaufen brauchen die Verlage also exklusive Inhalte, und idealerweise solche, die kein Wettbewerber hat, und die man auch nicht so einfach abschreiben kann.

Im März 2026 gab es auf einmal eine Gelegenheit, sich solche Inhalte zu erschaffen. Das US-amerikanische Nationalarchiv veröffentlichte die im zweiten Weltkrieg beschlagnahmte Mitgliederdatei der NSDAP, allerdings in einem nur aufwändig zu durchsuchenden Format. Die Chance: der Erste, der sie einfach durchsuchbar machen würde, konnte diese Suche hinter eine Paywall stellen und damit neue zahlende Abonennten gewinnen, die die eigene Familiengeschichte überprüfen wollten.

Zwei der grössten deutschen Medien nahmen die Herausforderung an, eine solche Lösung als erster zu entwickeln: die Zeit und der Spiegel. Und das Ergebnis dieses Wettrennens war eindeutig: am 18.03. ging das Archiv in den USA online, schon am 7. April veröffentlichte die Zeit ihre Suchmaschine, der Spiegel folgte erst am 7. Mai. Wer wissen wollte, ob Oma und Opa Nazis waren, hatte da schon längst ein Abonnenement der Zeit gekauft, das Marktfenster war bereits weitgehend geschlossen.

Wie genau es geklappt hat, in nur drei Wochen eine solche Software zu entwickeln hat die Zeit zwar nicht im Detail beschrieben (nur dass sie bei der Programmierung die KI Gemini benutzt hat), es ist aber offensichtlich, dass in einem agilen Modus gearbeitet wurde. Für Anforderung, Entwicklung, Test und Rollout standen schliesslich jeweils nur wenige Tage zur Verfügung, am Ende ist dabei das alte Versprechen der agilen Bewegung, Software in 30 Tagen zu erstellen, sogar unterboten worden.

Die ganze Geschichte ist ein schönes Beispiel dafür, dass in einem IT-Projekt die auf den ersten Blick gar nicht so lange Differenz von vier Wochen entscheidend für den Erfolg eines Produkts oder Features sein kann. Und wer weiss - vielleicht sitzt irgendwo beim Spiegel gerade ein Manager und ärgert sich darüber, dass sein Unternehmen moderne Arbeitsweisen lange eher reflexhaft verdammt hat, als ihnen mit Offenheit und Interesse gegenüberzutreten.

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, RTEs etc.) mit der Zeit eine eher negative Sicht auf die Welt entwickeln ist bedauerlich, aber erklärbar. Wer sich täglich mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Die heutige trug sich in einem Robotik-Startup zu. Wie in derartigen Firmen üblich war am Anfang alles klein und überschaubar gewesen, was sich mit zunehmendem Wachstum aber nach und nach änderte. Besonders häuften sich die Probleme, nachdem die MVP-Phase überwunden war. Um die funktionale Sicherheit der Embedded Software (des Betriebssystems) zu gewährleisten waren jetzt umfangreiche Tests nötig, die schon bald so lange dauerten, dass kaum noch Zeit für die Entwicklung blieb.

Um das nachvollziehbar zu machen: anders als im Fall reiner Softwareprodukte ist das Testen von Robotern nur schwer zu beschleunigen und zu parallelisieren. Dass z.B. ein Sensor nach zu langem Dauerbetrieb des Roboters der Software ein Signal übermittelt, das dort eine Warnung vor drohender Materialermüdung auslöst, kann nur in einem sehr langwierigen Testdurchlauf validiert werden, der nur in Gänze und ohne Unterbrechung ausführbar ist.

Aufgrunddessen besteht ein Grossteil der Robotik-Entwicklung aus Testläufen in einem Testlabor, was in grossen Organisationen das Risiko einer der folgenden beiden Auswirkungen hat: entweder das Entwicklungsteam betreibt auch das Labor, was aufwändig ist und ständige Kontextwechsel zur Folge hat, oder die Tests werden von einem separaten Test-Team durchgeführt, was zu einer Wasserfall-artigen Silo-Bildung führt, die in der modernen Produktentwicklung eigentlich nicht mehr gewollt ist.

Um es nicht dazu kommen zu lassen, wählten wir in dem erwähnten Robotik-Startup einen anderen, eher ungewöhnlichen Weg. Es gab zwar ein separates Team, das für das Testlabor zuständig war, es führte die Tests aber nicht selbst aus, sondern war nur dafür zuständig das Labor zu betreiben und zu erweitern. Seine Nutzung wurde den anderen Teams überlassen, die es quasi als Plattform-Dienstleistung nutzen konnten. "Test Lab as a Service" wurde es auch scherzhaft genannt.

Konkret sah das so aus, dass am Rand der Testfläche eine ausreichende Zahl der neuesten Generation von Hardware-Prototypen stand. Auf einer grafischen Weboberfläche wurde angezeigt welcher von ihnen gerade verfügbar war und welche Software-Version auf ihm lief. Sobald es eine neue Version dieser Betriebssoftware gab, konnte das jeweilige Entwicklungsteam sie auf einen der Roboter-Prototypen laden, eine Testfahrt starten und sich dann erstmal mit anderen Dingen beschäftigen.

Die im Folgenden stattfindende Testfahrt wurde von verschiedenen Kameras aufgezeichnet. Am Ende der Fahrt wurden das so entstandene Video, die Telemetriedaten der Sensoren des Roboters und die Monitoring-Daten der Software in einem gemeinsamen Ordner abgelegt und das Entwicklungsteam wurde benachrichtigt. Die Hard- und Software, die diese Daten automatisiert sammelte und zur Verfügung stellte, war Teil der Dienstleistung des Plattform-Teams für die Entwicklungsteams.

Die positiven Folge dieser Aufteilung waren spiegelbildlich zu den oben genannten Risiken. Die Entwicklungsteams konnten sich auf die Entwicklung und das Testen ihrer Features konzentrieren und mussten sich nicht mit dem aufwändigen Betreiben des Testlabors befassen. Das Plattformteam dagegen hatte einen klaren Focus auf dem zu Verfügung stellen dieses Labors, ohne selbst mit dem Durchführen der Testfahrten beschäftigt zu sein (von gelegentlichem Troubleshooting abgesehen).

Durch dieses Vorgehen entstand ein hochgradig effektiver und effizienter Entwicklungsprozess, der von allen Beteiligten als einer der besten gelobt wurde, den sie in der Embedded Software bis dahin erlebt hatten. Und als Nebeneffekt führte die automatisierte statt manuelle Überwachung der Testläufe dazu, dass ein immer grösser werdender Schatz an Daten entstand, der für wiederholte Auswertungen zur Verfügung stand. Heute, mit KI, wären damit nochmal ganz andere Dinge machbar.

Wenn man sich anschaut, wie die erfolgreichen agilen Vorzeigeunternehmen organisiert sind, bekommt man nur selten ein vorbildhaft implementiertes agiles Framework zu sehen, dafür aber viele spannende Inspirationen. Diese hier verdanke ich Thuan Pham, dem ersten CTO von Uber, der im Pragmatic Engineer-Podcast von einer bemerkenswerten Praxis dieser Firma erzählt:¹ wer will, kann jederzeit und ohne Hindernisse seinen Vorgesetzten wechseln.

Dass diese Möglichkeit ein deutlicher Paradigmenwechsel im Vergleich zur üblichen Geschäftswelt ist, ist offensichtlich. In fast allen anderen Firmen ist der Vorgesetzte jemand, den man im Wortsinn vorgesetzt bekommt. Man hat bei der Zuteilung wenig bis gar kein Mitspracherecht, er entscheidet über Versetzungen und Beförderungen (oder muss zumindest beteiligt werden) und ein Wechsel zu einer anderen Führungsperson ist meistens nur mit grossem Aufwand möglich.

Ist die Beziehung zum eigenen Vorgesetzten gut, ist das Alles kein Problem, ist sie dagegen eher schlecht, kann es hochproblematisch sein. Aufgrund des gegebenen Abhängigkeitsverhältnisses wird eine Unzufriedenheit oft gar nicht oder erst zu spät thematisiert. Die freie Vorgesetzten-Wahl bei Uber ist laut Pham eine bewusste Massnahme gewesen, um dieses Macht-Ungleichgewicht aufzubrechen und eine Beziehung auf Augenhöhe zu ermöglichen.

Die offensichtlichsten Folgen hat das im Fall eines Vorgesetzten, der eine sehr volatile oder ständig schrumpfende Mitarbeiter-Gruppe hat. Für das obere Management ist beides ein deutlicher Indikator dafür, dass hier möglicherweise ein Führungsproblem vorliegt, um das man sich kümmern sollte - und für jeden Mitarbeiter, der gerade einen neuen Vorgesetzten sucht, ein Zeichen dafür, dass er sich erst über diese Führungskraft informieren sollte, bevor er sie auswählt.²

Es gibt aber auch in konfliktfreien Konstellationen Vorteile, die sich aus der freien Vorgesetzten-Wahl ergeben. So gibt es auch in dieser Rolle unterschiedliche Stärken, seien sie fachlich, technisch, sozial oder sonstwie geartet, wodurch es Vorteilhaft sein kann, immer zu demjenigen zu wechseln, dessen Profil den aktuellen eigenen Bedürfnissen am Besten entspricht (gegebenenfalls nur temporär, um irgendwann zurückzukommen. Auch das ist ja möglich).

Natürlich lässt sich diese Praktik nicht in jedes andere Unternehmen übertragen, je nach Branche, Unternehmensgrösse, Art der Arbeit, beruflichem Spezialisierungsgrad und Betriebsverfassung kann das einfacher oder schwerer sein. Es ist aber zumindest etwas, was man samt möglicher Vor- und Nachteile erwägen und für sich ausprobieren kann. Und wenn man es ausprobiert, hat es in jedem Fall das Potential zu sehr deutlicher Flexibilisierung und kultureller Veränderung eines Unternehmens.

Mit sichtbarer Zufriedenheit stellte sich der Geschäftsführer Wirtsrat vor seine Belegschaft. Viele Themen wollte er anlässlich der Frühjahrstagung seiner Organisation ansprechen, aber eines ganz besonders und zuerst: seine Freude darüber, dass die Sachbearbeiter jetzt endlich die Vorteile des im letzten Jahr angeschafften teuren neuen CRM-System akzeptierten und seine intelligenten Funktionen benutzten. Er hatte keine Ahnung, wie es sich in Wirklichkeit verhielt.

Ich habe den Geschäftsführer Wirtsrat (der in Wirklichkeit anders hiess) vor langer Zeit in einem meiner ersten Jobs kennengelernt. Er war ein eher klassisch sozialisierter und denkender Vorgesetzter, der überzeugt war, dass zu viel Transparenz und Mitsprache Entscheidungen nur verzögern würden. Aus diesem Grund hatte er das besagte CRM-System auch alleine ausgewählt und gekauft, ohne vorher mit denen zu reden, die es später benutzen würden. Er wusste schliesslich, was gut war.

Die Anwender hatten eine ganz andere Meinung. An sich fanden sie das System ähnlich gut wie das alte, nur eine Funktion fanden sie extrem nervtötend: beim Öffnen jeder einzelnen Ebene des zentralen Ordnerbaums erfolgte ein Ladevorgang von mehreren Sekunden, während denen die "intelligenten Funktionen" geladen wurden - Hilfs- und Hinweis-Funktionen, die sich alle etwa auf dem Niveau von Karl Klammer bewegten: gut gemeint, aber schon nach Kurzem sehr nervig.

Der eigentliche schlimme Nervfaktor war aber ein anderer: es waren die Ladevorgänge, die sich bei tieferen Ordnerbäumen auf bis zu einer halben Minute summieren konnten. Ständig hörte man im Büro fluchende Mitarbeiter, die ewig darauf warteten, endlich bei der Zielebene anzukommen. Der Geschäftsführer Wirtsrat hielt allerdings starr an seiner Meinung fest: die intelligenten Funktionen wären eine wertvolle Hilfe und das neue CRM wäre deswegen gut.

Auch ich war schon nach kurzem von den langen Ladezeiten genervt, und besonders an einem Morgen dauerte alles gefühlt doppelt so lange wie sonst. Ohne gross darüber nachzudenken überbrückte ich die Zeit durch schnelles, ununterbrochenes Klicken auf den Apply-Button, als auf einmal etwas Unerwartetes geschah - eine Systemmeldung tauchte auf und zeigte an, dass das System wegen zu vieler Eingaben überlastet war, weswegen die intelligenten Funktionen temporär ausgeschaltet würden.

Auf einmal waren die Ladezeiten weg. Mit ihnen zwar auch die Hilfsfunktionen, aber die waren wie gesagt ohnehin verzichtbar. Nach dem Neustart war zwar alles wieder da, aber nach kurzem Ausprobieren stellte sich heraus, dass man mit erneuten Dauerklicken die Hilfsfunktionen wieder vorübergehend deaktivieren konnte. Schon nach kurzem hatte sich der Trick herumgesprochen, und der Arbeitstag fast aller Kollegen begann mit schnellem Klicken, gefolgt von zufriedenen Seufzern.

Dem Geschäftsführer Wirtsrat hat während meiner Zeit in seiner Organisation niemand gesagt, dass praktisch jeder Mitarbeiter an jedem Morgen als erstes die intelligenten Funktionen deaktivierte, um während des restlichen Tages produktiv arbeiten zu können. Er hielt die plötzlich stark zurückgehenden Beschwerden für ein Zeichen von Akzeptanz, weshalb es diese auch stolz auf der zu Beginn erwähnten Frühjahrstagung vor allen Mitarbeitern erwähnte. Die Mitarbeiter grinsten und schwiegen.

Natürlich war das ein Extremfall, in verschiedenen Abwandlungen findet man derartige Funktionen und Manager aber in vielen, vielen Organisationen. Und für mich ist dieses Erlebnis, bei dem für viel Geld ein neues System angeschafft wurde, das praktisch alle Mitarbeiter so nervte, dass sie es täglich durch destruktives Nutzerverhalten deaktivierten, ein prägendes gewesen. Davon, ein neues System zwangsweise, ohne Einbeziehung der Nutzer einzuführen, habe ich seitdem immer abgeraten.

Es ist eine Traumvorstellung vieler Angestellter - ein Berufsleben ganz ohne Regelmeetings, fest definierte Prozesse oder sonstige einengende Strukturen. Eines in dem man "einfach nur arbeiten" kann. Und es gibt sogar Firmen, denen das anscheinend weitgehend gelungen ist, z.B. WhatsApp vor der Übernahme durch Facebook. Wie genau das ausgesehen hat kann man sich jetzt anhören, denn die damalige WhatsApp-Mitarbeiterin Jean Lee berichtet im Pragmatic Engineer Podcast davon.

Der erste, und vermutlich wichtigste, Punkt den man von ihr lernen kann ist, dass WhatsApp damals eine kleine Firma war, und sich bewusst entschieden hat, klein zu bleiben. Zum Zeitpunkt der Übernahme gab es 30 Angestellte, davon 20 in der Softwareentwicklung. Eine derartig überschaubare Gruppe ist natürlich viel einfacher ad hoc und auf Zuruf zu koordinieren. Um so klein bleiben zu können, wurde sogar bewusst auf zusätzliche Features und Marktsegmente verzichtet.

Im Zusammenhang damit stand, dass alle Firmenangehörigen jeden Tag in einem grossen gemeinsamen Büro sassen. In einem derartigen Setting ist jeder sofort erreichbar, man bekommt zwangsläufig mit was die anderen tun, und Informationen können schnell und beiläufig an der Kaffeemaschine oder im Aufzug ausgetauscht werden. Ein zusätzlicher Vorteil ist, dass Information Radiators wie digitale Displays oder Kanban Boards durchgehend für alle sichtbar sind.

Als nicht zu vernachlässigendes Element kommt dazu, dass es kaum funktionale Spezialisierungen gab. Wie Jean Lee berichtet, waren in der damaligen Firma WhatsApp die Manager (einschliesslich des CEO) gleichzeitig an der Softwareentwicklung beteiligt, während die eigentlichen Entwickler Crashkurse in den wirtschaftlichen Aspekten erhielten und auch alle Geschäftszahlen kannten. Es gab also keine organisatorischen Silos, die sich untereinander prozessual koordinieren mussten.

Zuletzt darf man nicht vergessen, dass WhatsApp damals erst wenige Jahre alt war, und ein sehr minimalistisches Produkt hatte (im Wesentlichen eine Messaging App, Features wie Video Calls, Channels, Stories und DesktopApp existierten noch nicht), es gab also vergleichsweise wenige Feature Requests, technische Schulden und Refactoring-Wünsche, die man in einem strukturierten Planungs- und Priorisierungsprozess hätte verhandeln und eskalieren müssen.

Ich habe bereits mit anderen Firmen vergleichbarer Grösse und Struktur arbeiten dürfen, und z.T. auch dort ein vergleichbares Minimum an Prozessen und Strukturen erleben dürfen, was aber in allen Fällen nur gut funktioniert hat, so lange die Produkte und Organisationen von überschaubarer Grösse und Kompliziertheit waren. Sobald Wachstum stattfand, kamen auch die Prozesse (und Vergleichbares passierte laut Jean Lee nach der Übernahme von WhatsApp durch Facebook).

Es bleibt also am ende eine gleichzeitig positive und negative Erkenntnis: Berufsleben ganz ohne Regelmeetings, fest definierte Prozesse oder sonstige einengende Strukturen ist möglich, vermutlich aber nur in sehr kleinen und jungen Unternehmen. Wer Wert darauf legt, wird also alle paar Jahre zu einem neugegründeten Startup wechseln müssen. Wer dagegen einen Job etwas länger behalten möchte, der wird schon bald um Prozesse nicht mehr herumkommen.

Heute gibt es einmal mehr ein Praxisbeispiel, diesesmal von Airtable, einem KI Startup aus dem Silicon Valley. Wie alle Startups muss auch dieses hier agil im eigentlichen Sinn sein, also in der Lage, schnell auf sich ändernde Kundenwünsche und Marktbedingungen zu reagieren. Anders als man denken könnte sind dort aber nicht alle Teams mit dem Ziel einer schnellen Reaktionsfähigkeit aufgesetzt, wie Firmengründer Howie Liu in Lenny's Podcast erklärt.

Es gibt bei Airtable zwei verschiedene Arten von Teams, deren jeweiliges Organisationsmodell an die zwei Arten des Denkens aus Daniel Kahnemans Bestseller Thinking, Fast and Slow angelehnt ist - auf der einen Seite die Fast-thinking Teams, die schnell, proaktiv, intuitiv und experimentgetrieben vorgehen sollen und auf der anderen Seite die Slow-thinking Teams, die abwägend, analytisch, strukturiert und sorgfältig arbeiten.

Wichtig für das Verständnis dieses Ansatzes ist, dass keine der beiden Team-Kategorien grundsätzlich besser oder schlechter ist als die jeweils andere (weder Kahnemann noch Liu sehen in dem Konzept des "langsamen Denkens" etwas Negatives), beide haben in ihrem jeweiligen Kontext ihre Vorzüge. Und diese unterschiedlichen Kontexte (und die Zuordnung der Kategorien zu ihnen) sind es auch, die die Idee der Fast- and slow-thinking Teams so interessant machen.

Fast-thinking Teams werden dort eingesetzt, wo neue Features und Produkte entwickelt werden, was besonders auf dem Markt für KI-Produkte hochgradig anspruchsvoll ist. Ein geradezu rasender technischer Fortschritt, ständige Innovationen, starker Wettbewerb und volatile Kundenbedürfnisse machen schnelles Agieren und Reagieren nötig, weshalb in diesem Bereich eine iterativ-incrementelle Auslieferung von Features im Wochenrhythmus vorgesehen ist.

Slow-thinking Teams sind dagegen dort angesiedelt, wo die Infrastruktur entwickelt wird, die die Basis dafür bildet, dass die von den Fast-thinking Teams entwickelten Features von einer rapide wachsenden Nutzerbasis in hoher Frequenz genutzt werden können. Hier stehen eher Verlässlichkeit, Skalierbarkeit, Resilienz und Berechenbarkeit im Focus, wodurch die Entwicklungsschritte hier deutlich langsamer, dafür aber mit grösserer Sorgfalt und Planung erfolgen.

Dieses bewusste gleichzeitige Aufsetzen von zwei verschiedenen und komplementären Vorgehensmodellen ist in modernen Tech-Unternehmen eher selten, viel häufiger wird versucht, alles nach einem gleichen Muster zu organisieren, dass dann im Einzelfall unpassend ist. Der Denkanstoss, den sich viele mitnehmen können, ist, dass Uneinheitlichkeit durchaus Sinn machen kann. Die kann dann in Form von Fast- and Slow-thinking Teams auftreten, ggf. aber auch ganz anders.

Über die Folgen des Einsatzes künstlicher Intelligenz in der Softwareentwicklung konnte man in den letzten Jahres einiges lesen, das meiste allerdings mit wenig Realitätsbezug. Das heisst aber nicht, dass es keine sinnvollen Anwendungsfälle gäbe, im Gegenteil. Nach und nach werden sie erkannt, ausprobiert, bewertet und veröffentlicht, so wie in diesem Fall: dem Einsatz von Vibe Coding-Prototypen statt Anforderungsdokumenten bei Google.

At @Google, we are moving from a writing‑first culture to a building‑first one.

Writing was a proxy for clear thinking, optimized for scarce eng resources and long dev cycles - you had to get it right before you built.

Now, when time to vibe-code prototype ≈ time to write PRD,…

— Madhu Guru (@realmadhuguru) July 29, 2025

Zum Kontext: Anforderungsdokumente (oder Product Requirements Documents/PRDs) sind in der Softwareentwicklung bisher ein notwendiges Übel. Sie sind abstrakt, können missverstanden werden und sind aufwändig in der Erstellung und Aktualisierung. Allerdings müssen Anforderungen irgendwo festgehalten werden, Inhalt, Intention und Kontext sind meistens zum umfangreich um ohne derartige Unterstützung im Gedächtnis zu bleiben.

Madhu Garu, der für Gemini zuständige Produktmanager bei Google, beschreibt im oben eingebetteten Post ein alternatives Vorgehen: anstelle eines Anforderungsdokuments präsentiert ein Produktmanager seinem Team einen digitalen Prototypen, also ein noch unfertiges, nicht integriertes und ggf. fehlerhaftes Stück Software, das aber die gewünschte Funktion bereits in einer so guten Form enthält, dass ein Entwicklungsteam sie nachbauen kann.

Dass Produktmanager oft nicht selbst programmieren können wird dabei umgangen, indem der Prototyp durch Vibe Coding erstellt wird, also dadurch, dass er einem KI-Programm beschrieben wird, das ihn dann programmiert (mehr dazu hier). Die Anforderung wird durch den Prototypen deutlich plastischer als durch eine blosse Beschreibung in textform, und (und jetzt wird es interessant) ist im Vergleich zu einem Anfoderungsdokument oft schneller zu erstellen.

Garu geht in den Kommentaren unter seinem Post noch auf weitere Aspekte des Vorgehens bei Google ein: so wird es auch dort nicht überall eingesetzt, bzw. vorgeschrieben, sondern nur dort, wo der Produktmanager es beherrscht und für sinnvoll hält, ob weitere Teams es übernehmen entscheiden sie selbst, Vibe Coding-Prototypen werden nicht auf Produktion deployed und für grössere oder abstraktere Themen ist weiterhin die Schriftform Standard.

Insgesamt eine spannender Erfahrungsbericht von einem Unternehmen, das schon mehrfach bewiesen hat, agile Entwicklungspraktiken zu beherrschen. Sowohl die Art des Einsatzes als auch die Art der Einführung dürften erkennbar dazu beitragen, dass die Kommunikation effektiver, das Feeback schneller und die Lieferzyklen kürzer werden. Eine empfehlenswerte Inspiration also, die man auch im eigenen Unternehmen bei Gelegenheit ausprobieren sollte.

Bild: Wikimedia Commons / Anton Heiz - CC BY-SA 4.0

Unter den vielen Berichten über sich verzögernde Infrastruktur-Projekte ist dieser hier kaum aufgefallen: der Bau des Fehmarnsundtunnels (Teil der Fehmarnbelt-Querung) dauert mindestens drei Jahre länger als geplant. Auffällig dabei ist, dass ein Grossteil dieser Verspätung nicht etwa durch Probleme beim eigentlichen Bauvorhaben entsteht (das hat noch gar nicht begonnen), sondern durch Bürokratie: Ausschreibungsprozesse, zu beachtende Fristen, Einspruchsverfahren, Klagemöglichkeiten, etc.

Der Fehmarnsundtunnel ist dabei kein Einzelfall: wer mit Bauträgern und Behördenvertretern spricht bekommt zahllose derartige Geschichten zu hören, bei denen das eigentliche Vorhaben mehr oder weniger im Plan liegt, bei denen aber bürokratische Vorgaben immer wieder zu verzögertem Start oder zwischenzeitlichen Unterbrechungen führen - und das nicht etwa durch Behördenwillkür, sondern nur weil auch die sich an Gesetze und Vorschriften halten müssen.

Wie sehr es tatsächlich die Verwaltungsbürokratie ist, die alles verlangsamt, kann man an einem anderen Beispiel sehen. den LNG-Flüssiggas-Terminals, die ab dem Jahr 2022 an der Nord- und Ostseeküste gebaut wurden. Für deutsche Verhältnisse sind sie in atemberaubender Geschwindigkeit fertig geworden, zum Teil lag zwischen dem Beschluss des Vorhabens und dem Ende der Bauarbeiten weniger als ein Jahr. Und man kann jetzt bereits ahnen, wie das gelungen ist.

Das für diesen Zweck erlassene "Gesetz zur Beschleunigung des Einsatzes verflüssigten Erdgases" (LNG-Beschleunigungsgesetz) macht fast ausschliesslich Eines: es setzt andere Gesetze und Vorschriften ausser Kraft. Formulierungen wie "Abweichend von § X ..." oder "§ Y des Gesetzes Z ist nicht anzuwenden" ziehen sich durch seinen gesamten Text und machen deutlich klar, dass hier ein subtraktiver Wandel stattfindet. Mit anderen Worten: Verbesserung durch Weglassen.

Natürlich heisst das nicht, dass alle bisherigen Gesetze und Vorschriften sinnlos sind und abgeschafft werden sollten, derartige Kettensägen-Methoden gehören (wenn überhaupt) in ganz bestimmte Sektoren der Privatwirtschaft, die entfesselnde Wirkung eines Regulierungs-Rückbaus ist aber an diesem Fall mehr als deutlich zu erkennen. Wenn der Staat wieder handlungsfähig werden soll, ist das temporäre oder dauerhafte Ausserkraftsetzen also ein durchaus gangbarer Weg.

Bild: CCNull / Marco Verch - CC BY 2.0

Es dürfte nur wenige Personen geben, deren Image sich in wenigen Jahren so stark gewandelt hat wie das von Elon Musk - vom ökologisch-liberalen Hoffnungsträger zum techno-faschischen Oligarchen. Was dabei in Vergessenheit zu geraten droht ist, dass Musk in seinen Unternehmen vieles umgesetzt hat, was aus "agiler Perspektive" als vorbildhaft gilt.Dazu gehört unter anderem auch das fünfstufige Effektivitäts-Framework von Tesla und SpaceX, der u.a. in seiner autorisierten eponymen Biografie beschrieben ist.

pic.twitter.com/EbATALczdf

— Startup Archive (@StartupArchive_) July 20, 2025

1. Question every requirement (make them less dumb)

Die konsequente Umsetzung dessen, was auch als maximizing the amount of work not done bekannt ist. Wichtig dabei ist als Voraussetzung, dass Anforderungen immer einer Person zuzuordnen sein müssen, bei der man sie hinterfragen kann. Und ebenfalls, dass dieses Hinterfragen nicht nur als Legitim sondern als sinnvoll und gewünscht wahrgenommen wird, da jedem bewusst ist, dass niemand (egal wer er ist) davor gefeit ist, Fehler zu begehen - und zwar auch dumme Fehler.

2. Delete as much process as possible - even if it is too much

Ein Grundsatz, der seit Musks Kettensägen-Bürokratieabbau sicher kritischer gesehen werden muss, der aber einen rationalen Kern hat: von vielen (Umsetzungs-)Prozessen weiss man erst ob sie verzichtbar sind, wenn man durch ihre vollzogene Abschaffung getestet hat ob sie fehlen würden - andernfalls wird sich immer jemand finden, der sie verteidigt (im Zweifel der, dessen Job die Prozess-Aufrechterhaltung ist). Und wenn sie wirklich fehlen, kann man sie ja erneut einführen.

3. Simplify and optimize

Ab hier wird das Vorgehen dem ähnlicher, das aus Scrum, Kanban & Co bekannt ist. Wichtig ist dabei aber, dass zuerst die beiden ersten Schritte durchgeführt worden sind, um zu verhindern, dass unsinnige Anforderungen umgesetzt oder sinnlose Prozesse optimiert werden. Ein bekanntes Beispiel für die danach folgende Vereinfachung und Optimierung sind die Fertigungsstrassen der neuen Tesla-Fabriken, die erst in Zelten gebaut und optimiert werden, bevor die (teure) Fabrik um sie herum gebaut wird.

4. Accelerate cycle time

Sobald ein Fertigungs- oder sonstiger Arbeitsprozess grundlegend eingerichtet ist kann er in seinem Ablauf beschleunigt werden, z.B. indem Arbeitspakete kleiner geschnitten werden, Kopfmonopole aufgelöst werden oder Routinen entwickelt werden. Das Ganze idealerweise auf Basis von Daten wie Durchlaufzeiten, Qualitätsschwankungen oder Abnutzungsraten. Und auch hier gilt: die vorherigen Schritte müssen vorher stattgefunden haben, sonst riskiert man, etwas Falsches zu beschleunigen.

5. Automate

Dass die Automatisierung von Prozessschritten erst ganz am Ende erfolgt, hat einfache Gründe: sie ist kostspielig, und sollte daher erst stattfinden, wenn möglichst klar ist, dass das was automatisiert wird wirklich sinnvoll und effektiv gestaltet ist. Und sobald die Automatisierung stattgefunden hat, sind die Anforderungen und Abläufe der Sichtbarkeit der Menschen entzogen, und damit auch dem kritischen Hinterfragen. Frei nach Thorsten Dirks: automatisierte Scheissprozesse sind zu vermeiden.

Wie oben gesagt, spätestens Elon Musks Tätigkeit für die US-Regierung, in der sich sein Effektivitäts-Framework wiedererkennen lässt, hat aufgezeigt, dass es nicht in jeden Kontext übertragen werden kann oder übertragen werden sollte. Gleichzeitig hat es seine Unternehmen aber unbestreitbar erfolgreich gemacht, bis hin zu zeitweisen Quasi-Monopolen auf ihren Märkten. Wie so oft gilt daher auch hier: bitte nicht unhinterfragt kopieren, sondern zuerst kritisch bewerten. Z.B. mit den eigenen Schritten 1 bis 3.

Dass die öffentliche Verwaltung an manchen Stellen agiler ist als man vermuten würde, habe ich schon an der einen oder anderen Stelle geschrieben. Ich muss aber zugeben, dass jeder neue Fall auch mich etwas überrascht, so viele sind es schliesslich auch wieder nicht. Die aktuelle Überraschung tritt dabei an einer besonders prominenten Stelle auf, nämlich in der Bundesregierung, genauer gesagt im neuen Bundesministerium für Digitales und Staatsmodernisierung (BMDS).

Die erste Anwendung agiler Praktiken findet dabei gleich im Rahmen des Organisationsaufbaus statt. Statt möglichst lange möglicht im Verborgenen an einem möglichst perfekten Organigramm zu arbeiten, das dann nicht mehr verändert werden soll, hat das BMDS bewusst einen noch unfertigen Entwurf veröffentlicht, in gewisser Weise ein MVP. Dadurch sollen möglichst viele der zukünftigen Mitarbeiter früh Wünsche und Feedback äussern können, die dann in spätere Versionen einfliessen können.

Und damit nicht genug - diese Transparenz und Offenheit für Rückmeldungen soll nicht nur einmal stattfinden sondern mehrfach, das Ministerium plant "die Umsetzung in eine feste Struktur [...] in Form eines iterativen Prozesses", es wird also mehrere Veröffentlichungs-, Feedback- und Ansassungs-Schleifen geben, bis irgendwann ein Organisationsaufbau in einer Form definiert worden ist, die eine zeit lang stabil bleiben kann (so ähnlich habe ich auch schon einmal gearbeitet).

Alleine das ist für eine Behörde bereits beeindruckend genug, bei der Süddeutschen Zeitung kann man aber nachlesen, dass noch weitergehende Organisationsdesign-Prinzipien umgesetzt werden sollen: in einer Abkehr von sonst üblichen Paradigmen sollen die entstehenden Abteilungen nicht in Form von Silos auf Fach- oder Aufgabenteilungs-Basis entstehen, sondern um so genannte "Missionen" gruppiert sein, also um konkrete Modernisierungs- und Digitalisierungs-Aufgaben.

Eher der Umbruchssituation geschuldet, trotzdem aber bemerkenswert ist der Improvisationsgeist, von dem die Süddeutsche Zeitung berichtet. Statt sich lange mit den in der öffentlichen Verwaltung legendär langwierigen und komplizierten Bestellprozessen aufzuhalten werden Büroausstattungen gebraucht gekauft oder geliehen, unbürokratisch verteilt und bei Bedarf zweckentfremdet. Und noch etwas erinnert mich an ein eigenes Erlebnis: die pragmatische Beschaffung von dringend nötigem Klopapier.

Ob sich der "agile Geist" in diesem neuen Ministerium halten wird, ist natürlich noch nicht absehbar. Bestenfalls wird er in die Organisationskultur übergehen, schlimmstenfalls wird er sich nach und nach verflüchtigen. Aber alleine dass Agilität an einem solchen Ort, an dem man sie nicht vermuten würde, möglich ist, ist schon für sich genommen eine bemerkenswerte Geschichte. Eine die man durchaus weitererzählen könnte, wenn wieder jemand undifferenziert auf Behörden schimpft.

Bild: Pexels / Ketut Subiyanto - 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 zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Am Anfang von dieser hier stand wie so oft ein Frustrationserlebnis. Eine grosse Firma, bei der ich im Einsatz war, hatte sich in einem Pilotprojekt auf die Idee crossfunktionaler Entwicklungsteams eingelassen, in der Hoffnung, dadurch die alles verzögernden Warte- und Übergabephasen zwischen den bisherigen Spezialistenteams deutlich verkürzen zu können. Bis zu einem gewissen Grad war das auch eingetreten, allerdings bei Weitem nicht in dem von allen erhofften Ausmass.

Eine Untersuchung der betroffenen Einheiten und Prozesse konnte dann klar aufzeigen, woran das lag: das Team war nur crossfunktional innterhalb der Softwareentwicklung (Frontend, Backend, Data Science, UX), was aber bei weitem nicht alle Arbeitsschritte abdeckte. Das Produkt (ein Kundenservice-Chatbot) musste nach der Entwicklung noch zur Fachabteilung, um von der mit Daten versorgt und trainiert zu werden, um dann von der Rechtsabteilung freigegeben zu werden. Hier entstanden weiter Wartezeiten.

Auch Mitglieder dieser beiden Abteilungen in das crossfunktionale Teams aufzunehmen war die offensichtliche Lösung, führte aber zu Beginn zu heftigen Abwehrreaktionen; dafür gäbe doch gar nicht genug Zeit, und es gäbe zu viel Anderes zu tun, das wichtig wäre. Auch hier führte eine Nachforschung schnell zu einer Identifikation des eigentlichen Problems: die betroffenen Kollegen waren stark überplant und hatten nur wenige Stunden pro Woche für das Pilotprojekt zur Verfügung - deutlich zu wenig.

Es brauchte mehrere Wochen und Eskalationen bis ins Top-Management um dieses Problem zu lösen, aber am Ende stand ein deutlich besseres Setup. Aus der Fachabteilung wurden mehrere Mitarbeiter für vier Tage pro Woche exklusiv für das Projekt freigestellt, aus der Rechtsabteilung immerhin ein Kollege für drei halbe Tage pro Woche. Damit konnten sie in das jetzt wirklich crossfunktionale Team eingegliedert werden, an dessen Meetings teilnehmen und eng mit den anderen Teammitgliedern zusammenarbeiten.

Durch diese Neuorganisation trat dann endlich die angestrebte Beschleunigung ein. Durch die täglichen Abstimmungen war jetzt jederzeit klar, wann die Übergaben zwischen den Teilteams stattfinden würden, und durch die realistischere Kapazitätsplanung konnten sie auch fast immer sofort stattfinden. Die Durchschnittlsdauer der Warte- und Übergabephasen sank von Tagen und Wochen auf Stunden (und als Nebeneffekt konnten die Meetings entfallen, in denen die zu übergebende Arbeit verwaltet wurde).

Natürlich gab es noch weitere positive Effekte dieses Vorgehens, z.B. die oben erwähnte Aufdeckung der strukturellen Überplanung vieler Mitarbeiter, da schnellere Durchlaufzeiten durch crossfunktionalere Teams aber das Hauptziel der Umstellung auf agiles Arbeiten waren, steht auch das hier im Focus dieser "agilen Erfolgsgeschichte". Und darüber hinaus ist es ein gutes Beispiel dafür, wie weit wirkliche Crossfunktionalität gehen kann.

Wer sich inspirieren lassen will, wie ein über Scrum und SAFe hinausgehendes individuelles agiles Framework aussehen könnte, der findet bei erfolgreichen Tech-Unternehmen eine Vielzahl von Beispielen, von Youtube über Amazon und Spotify bis hin zu Netflix und X/Twitter. Ohne nachzudenken kopieren sollte man nichts davon, aber Ideen zum Ausprobieren sind immer wieder dabei. Hier ist eine weitere: die forward-deployed Engineers (FDEs) der Firma Palantir.

Die an verschiedenen Stellen (z.B. hier, hier und hier) erklärte Idee ist einem Gründungsmythos zufolge nach dem Besuch in einem französischen Restaurant entstanden, in dem die Kellner viel Zeit mit den Gästen verbrachten, zusammen mit ihnen von der Karte abweichende Menüs erstellten und diese dann in Teilen selbst mit zubereiteten. In ähnlicher Form sollen zum Kunden entsandte (forward deployed) Teams von Palantir direkt mit den Anwendern Software-Features entwerfen und für sie erstellen.

Bewusst oder unbewusst scheint dieses Vorgehen eine (je nach Sichtweise) Weiterentwicklung oder Umdrehung der Rolle des Onsite Customers aus dem Extreme Programming zu sein. In beiden Fällen ist es das Ziel, Entwickler und Anwender möglichst nah zusammenzubringen. Während das im Extreme Programming aber dadurch stattfand, dass Kundenvertreter in die Entwicklungsteams integriert wurden, ist es bei den forward-deployed Engineers umgekehrt.

Die sich daraus ergebenden Vorteile (enger Zielgruppenkontakt, sofortige Erprobung neuer Ideen, unmittelbares Feedback) sind offensichtlich, allerdings sollte sich jeder bewusst sein, dass diese mit einem Preis kommen, und das ist in diesem Fall wörtlich zu nehmen. Bei Kunden eingesetzte FDEs werden dort lokale Lösungen entwickeln, die ggf. mit anderen lokalen Lösungen redundant oder inkompatibel sind, ihre Integration oder ihr parallel-Betrieb sind aufwändig, die Synergie-Effekte gering.

Dass dieser Weg für Palantir trotzdem der richtige ist, hat mit der Kundenstruktur dieser Firma zu tun. Sie ist im Rüstungssektor tätig und hat darum wenige, dafür aber potentiell riesige Kunden (v.a. die Armeen verschiedener Länder und grosse Rüstungskonzerne, wie z.B. Airbus). Diese Grosskunden sind problemlos in der Lage, die mit diesem Vorgehen verbundenen Kosten zu stemmen, gleichzeitig ist ihre Anzahl so überschaubar, dass die Varianz der entstehenden Lösungen handhabbar bleibt.

Von Bedeutung ist ausserdem, dass es sich bei den in diesem Kundensegment erstellten Palantir-Produkten um Individualsoftware handelt, die zum Grossteil bewusst nicht an andere Kunden verkauft werden soll (und zum Teil aufgrund von Geheimhaltungs- und Exklusivitätsvereinbarungen auch gar nicht verkauft werden darf). Die bei der Erstellung von Standardsoftware normalen und sinnvollen Vereinheitlichungs- und Effizienz-Bestebungen spielen daher hier keine Rolle.

Die forward-deployed Engineers sind daher in gleich doppelter Hinsicht ein interessanter Anschauungsfall. Zum einen weil sie einen Weg zu extrem effektiver und intensiver Kunden- und Nutzer-Interaktion darstellen, zum anderen weil es bei ihnen sehr deutlich erkennbar ist, wie kontextspezifisch ihr Einsatz ist und wie wenig übertragbar er auf die meisten anderen Unternehmen wäre. Daher, wie oben gesagt - eine Inspiration können sie sein, einfach kopieren sollte man sie aber nicht.

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.

Bild: Pexels / Vlada Karpovich - Lizenz

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

Diese hier hat sich in einem grossen Unternehmen in einer gesetzlich regulierten Branche zugetragen. Die Einhaltung dieser Regulierungen wurde von einer eigenen Abteilung überprüft, der Revision, die von Zeit zu Zeit anderen Abteilungen einen Besuch abstattete, sich deren Abläufe und Ablaufdokumentationen zeigen liess, diese überprüfte und für regulierungskonform oder nicht regulierungskonform erklärte. Wenn das zweite der Fall war, mussten diese angepasst werden, danach wurden sie nochmals überprüft.

Bewusst oder unbewusst hatte sich in dieser Firma mit der Zeit ein eher dysfunktionaler Umgang mit der Revision etabliert: im Vorfeld wurde die Herausgabe von Informationen möglichst stark verzögert, während der eigentlichen Prüfung wurde die Revision dann dafür mit möglichst viel Material überflutet. In dem waren einige offensichtliche aber sehr geringfügige Fehler prominent plaziert, um schnell gefunden zu werden und die Revisoren von einer genaueren Überprüfung der anderen Bereiche abzulenken.

Als externem Berater/Agile Coach war ich in diese Feinheiten nicht eingeweiht worden, weshalb ich mir keine grossen Gedanken machte, als ich kontaktiert und nach einer Prozessdokumentation der agilen Software-Entwicklung gefragt wurde. Bereitwillig verwies ich auf den Scrum Guide und einige Intranet-Seiten, auf denen erklärt wurde, wie Scrum in der Entwicklungsabteilung umgesetzt wurde, die ich zu dieser Zeit begleitete. Noch am selben Tag brach dort Unruhe aus.

Schlafende Hunde hätte ich geweckt und die Revisoren "angefüttert", hiess es, jetzt hätten die mehr Zeit als sonst um sich zu informieren, sich vorzubereiten und noch genauer als sonst zu prüfen, und dadurch würden sie auch mehr finden können und für alle mehr Arbeit verursachen. Ein grosses Drama. Um alle zu beruhigen bot ich schliesslich an, die Vorbereitungs-Arbeiten der Revisions-Prüfung selbst zu übernehmen. Es waren noch etwa fünf Wochen bis zum Revisionstermin.

Eine wirkliche Idee was ich alles abzuliefern hätte hatte ich am Anfang noch nicht, dafür aber eine Idee wen ich fragen könnte - den Revisor, der mich nach Prozessdokumentation gefragt hatte. Und tatsächlich, von ihm bekam ich die "Richtlinien zur Inbetriebnahme, Modifizierung und Ausserbetriebnahme von Netzwerk- und Informationssystemen". Ein riesiges, unübersichtliches Dokument, voller Fachbegriffe und juristischer Formulierungen. Ich verstand bestenfalls die Hälfte.

Immerhin, er war bereit, es mir zu erklären, also stellte ich einen längeren Termin mit ihm ein, der erstaunlich konstruktiv und produktiv war. Hinter den meisten Formulierungen verbargen sich sehr einfache und nachvollziehbare Vorgaben, z.B. dass es ein Vorgehen zur Priorisierung von Anforderungen geben müsste, dass ein Vier-Augen-Prinzip gewährleistet sein müsste und dass neu entwickelte Funktionen eine Qualitätssicherung dürchlaufen müssten.

Umgekehrt konnte ich erklären, was es mit den verschiedenen Fachbegriffen aus Scrum auf sich hatte. Welche Meetings es gab, wer an ihnen teilnahm und dort welchen Beitrag leistete und welche zusätzlichen Praktiken in den Teams verwendet wurden, z.B. User Stories, Pair Programming und Code Reviews. Wir gingen auseinender mit einer Idee: bis zur nächsten Woche sollte ich eine Übersicht erstellen, welche Richtlinien durch welche Scrum-Regeln und Praktiken abgedeckt wurden.

Im nächsten Termin konnte ich bereits für die meisten Richtlinien etwas vorweisen: das Refinement für die Anforderungs-Priorisierungen, die Code Reviews für das Vier-Augen-Prinzip, die Akzeptanz- und Regressionstests für die Qualitätssicherung, etc. Natürlich war noch nicht alles abgedeckt, aber wir konnten jetzt sortieren - Themen bei denen es nichts mehr zu tun gab, Themen bei denen nur noch die Dokumentation genauer werden musste und offene Themen.

In den verbleibenden drei Wochen arbeiteten wir diese Liste durch: zwischen den jeweils wöchentlichen Terminen konnte ich die Prozessdokumentation vervollständigen und Vorschläge erarbeiten, welche noch offenen Richtlinien wie in Scrum umgesetzt werden könnten (z.B. wurden Security-Vorgaben in die Definition of Done aufgenommen), umgekehrt konnte der Revisor sich mit seinen Kollegen abstimmen, ob das auch nach deren Meinung ausreichend war.

Letzteres führte dann auch zu einem unerwarteten Effekt: einige der anderen Revisoren hatten vorher in anderen Firmen bereits agile Prozesse überprüft, und konnten berichten, wie Regularien dort erfüllt worden waren. Sobald uns das bewusst war, fragten wir auch  bei weiteren noch unklaren Fällen nach Erfahrungswerten, und bekamen auch einige (z.B. dass die Nennung einer einzuhaltenden Richtlinie in den Akzeptanzkriterien einer User Story eine ausreichende Dokumentation war).

Der Revisionstermin war dann trotz allem lang und umständlich, schliesslich war es vorgegeben, dass mehrere Revisoren zusammen mit mehreren Mitgliedern der Entwicklungsabteilung den gesamten Prozess und seine Dokumentation im Detail durchgehen mussten. Anders als bei den letzten Terminen war das Meiste den Revisoren aber bereits bekannt - und als ein weiteres Ergebnis der Vorbereitung war die zu sichtende Dokumentation auf das Wesentliche reduziert, hatte also deutlich weniger Umfang.

Am Ende stand die geringste Menge an notwendigen Nacharbeiten, an die sich alle Beteiligten erinnern konnten, und gleichzeitig waren die Vertreter der Revisionsabteilung der Meinung, dass sie noch nie die Prozesse einer geprüften Abteilung so gut verstanden hätten. Auch in der Entwicklungsabteilung wurde anerkannt, dass die frühe und transparente Zusammenarbeit mit den Revisoren nicht die befürchteten negativen Folgen gehabt hatte, sondern sinnvoll gewesen war.

Leider ist es unverkennbar, dass viele Mitglieder der agilen Bewegung mit der Zeit eine eher negative Grundeinstellung entwickeln. Das ist auch menschlich verständlich, wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann leicht in Frustration abrutschen. Um nicht selbst in dieses Muster verfallen, veröffentliche ich ab und zu selbst erlebte "agile Erfolgsgeschichten". So wie diese hier.

Es war in einem meiner letzten Einsätze als klassischer Projektleiter. Ein grosser Mittelständler hatte vor, seine Website einem Relaunch zu unterziehen, inclusive des dort eingebundenen Shops. Insgesamt fünf Teams arbeiteten daran, aus der IT, aus dem Marketing und aus der Unternehmenskommunikation, und wie mir im Vorfeld gesagt wurde, war das Meiste schon fertig. Als externe Krankheitsvertretung des Projektleiters sollte ich nur noch die letzten Arbeiten koordinieren.

Die Realität, die ich vorfand, war dann allerdings eine andere. Zwar war die Arbeit tatsächlich schon weit fortgeschritten, die einzelnen Teile (Shop, CMS, Redaktionssystem, Single Sign on, etc.) passten aber an keiner Stelle zusammen. Jeder Versuch, irgendetwas fertigzustellen oder mit irgendeinem anderen Teil zu verbinden, führte zu einer Kaskade an Fehlermeldungen. Und mit gleicher Zuverlässigkeit ergoss sich regelmässig eine Kaskade aufgebrachter Stakeholder in das Projektleitungs-Büro.

Genau das erwies sich auch als die Ursache des Problems. In früheren Projektphasen hatte jeder Stakeholder ständig seine Wünsche in das Projekt einbringen dürfen. Und aus dem Wunsch heraus, alle gleich gut zu behandeln, hatte die alte Projektleitung die Teams angewiesen, an allem gleichzeitig zu arbeiten. So war es dazu gekommen, dass zwar Alles angefangen war, aber Nichts fertig, Nichts integriert, Nichts getestet und Nichts funktionierend.

Der einzige Vortrteil an dieser Situation war, dass das Projekt intern bereits als gescheitert galt, und alle Manager sich fern von ihm hielten, um zu verhindern, dass sie mit ihm in Verbindung gebracht wurden (das war auch der wahre Grund, warum ich als Externer der Projektleiter geworden war). Dadurch hatte ich relativ grosse Freiheiten, um neue Wege auszuprobieren. Nur welche das sein sollten, war mir noch nicht kar - also fragte ich die Entwicklungsteams. Und die hatten tatsächlich eine Idee.

Statt gleichzeitig an allem zu arbeiten und nirgendwo weiterzukommen wollten sie sich immer nur auf ein Feature konzentrieren, das fertigstellen, testen und integrieren, dann das Gleiche mit einem zweiten machen, dann mit einem dritten, und so weiter. Um zu zeigen, dass sie dabei wirklich vorankommen würden, boten sie mir einen täglichen kurzen Statusbericht an, vor einem Board auf dem der Fortschritt jedes Arbeitspaketes visualisiert wurde. Kanban nannten sie das (der Begriff war mir damals noch neu).

Der Beitrag, den ich dazu leisten musste, war, ihnen alle Stakeholder vom Hals zu halten, an deren Feature gerade nicht gebaut wurde. Mit Erbitterung und erstaunlicher Ausdauer drangen diese darauf, dass jetzt doch auch endlich sie wieder an der Reihe sein müssten, verlangten Fortschrittberichte, brachten neue Ideen auf, die sie noch spät in die Umsetzung einbringen wollten und eskalierten ständig beim Top-Management (das sich aus den oben genannten Gründen aber heraushielt). Ein Vollzeit-Job.

Während ich mir also irgendwo Powerpoint-Saalschlachten mit uneinsichtigen Leuten lieferte, wurden so fast unbemerkt die ersten Funktionen fertig. Zu Beginn noch mit Ablehnung aufgenommen ("Was? Nur so wenig? Da fehlt doch noch alles andere!") wurden sie nach und nach mehr und mehr. Und mit diesen frühen Funktionsumfängen gelang das erste kleine Wunder: als die ersten Stakeholder sahen, dass ihre Kernfunktionen fertig waren, waren sie fürs Erste zufrieden und zogen ihre Zusatzwünsche zuück.

Die verbliebenen kämpften zwar um so verbissener für ihre Interessen, da jeder befürchtete, dass am Ende für die Letzten keine Zeit und kein Budget mehr übrig sein würde, aber die Runden wurden nach und nach kleiner und beherrschbarer. Und irgendwann gelang das zweite kleine Wunder. Nachdem die konzentrierte Arbeit dazu geführt hatte, dass die Teams endlich liefern konnten, wurde ihren Zeitplänen auf einmal Glauben geschenkt und die Eskalationen wurden seltener.

Das aus der Sicht des Unternehmens grösste Wunder fand aber ganz zum Schluss statt: nach der Fertigstellung eines zufriedenstellenden Funktionsumfangs hatten sich alle auf das eingerichtet, was sie in vergangenen Projekten als unvermeidbaren Teil der Softwareentwicklung kennengelernt hatten - eine lange und für alle Beteiligten quälende Phase des Software-Testens und Reparierens, bei der nie so ganz abbsehbar war, wie lange sie dauern würde. Diesesmal aber was diese Phase kurz und schnell vorbei.

Der Grund dafür war, dass jede fertiggestellte Funktion sofort mit den anderen integriert und zusammen mit ihnen getestet worden war. Und da immer nur an einer gearbeitet wurde, waren die jeweils neuen Umfänge und Fehlerquellen immer überschaubar gewesen, wodurch sich die Test- und Reparatur-Aufwände in Grenzen gehalten hatten. Statt erst ganz am Ende mit der Qualitätssicherung beginnen zu müssen, war das meiste davon zu diesem Zeitpunkt schon abgeschlossen.

Am Schluss war auf diese Weise einiges von der zwischenzeitlichen Verspätung aufgeholt worden, und das Projekt endete mit jeweils zehn Prozent Zeit- und Budget-Überschreitung. In der gesamten jüngeren Unternehmensgeschichte (in der nie ein IT-Projekt pünktlich fertiggeworden war), war das der beste Wert an den man sich erinnern konnte. Und für mich selber war es der Anstoss, nur noch so arbeiten zu wollen (was ich mittlerweile auch geschafft habe).

Die Entwicklung einer negativen Weltsicht durch viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) ist ein bedauenswertes, aber auch menschlich verständliches Phänomen - wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann leicht in Frustration abrutschen. Um nicht selbst in dieses Muster verfallen, veröffentliche ich ab und zu selbst erlebte "agile Erfolgsgeschichten", um zu zeigen, dass vieles auch gut läuft.

In dieser hier geht es um das Durchführen einer Konzern-Reorganisation. Besagter Konzern hatte in den Jahren zuvor bereits mehrere Reorganisationen durchgeführt, und alle Beteiligten waren sich einig, dass sie nur mittelgut verlaufen waren. Am Anfang hatte es zwar jedesmal gut durchdachten Pläne gegeben, sobald die auf die Realität trafen, hatten sie sich aber jedesmal als lückenhaft erwiesen. Die Anpassung an die Realität hatte dann jedesmal zu Bürokratie, Unordnung und Unzufriedenheit geführt.

Das neue Vorgehen, mit dem es diesesmal anders werden sollte, sah zunächst vor, die Veränderungen in Arbeitspakete aufzuteilen, die nach und nach, in Abständen von wenigen Wochen, ausgeliefert werden sollten. Das Besondere daran: spätere Schritte wurden bewusst noch nicht ausdetailliert, stattdessen wurde nach jeder Auslieferung ein Feedback-Prozess gestartet, auf dessen Basis die Detaillierung angepasst wurde. Sogar das Rückgängigmachen früherer Reorganisationsschritte war ggf. möglich.

Um es an Beispielen konkret zu machen: ein erstes Arbeitspaket war die grundsätzliche Aufteilung und Bündelung von Zuständigkeiten, ein zweites der darauf aufbauende Zuschnitt der Bereiche und Abteilungen, ein drittes die Besetzung der Leitungspositionen, ein viertes die Zuordnung derjenigen Mitarbeiter, deren Tätigkeitsprofil das eindeutig zuliess, ein fünftes die Zuordnung der nicht ganz so eindeutigen Fälle, ein sechstes die Verteilung der neuen Einheiten auf die Büros.¹

Der Feedback-Prozess, der nach der Fertigstellung von jedem dieser Arbeitspakete folgte, bestand aus mehreren Dimensionen. Zum einen gab es Versammlungen der (bisherigen) Standorte und Abteilungen, in denen Fragen, Bedenken und Hinweise geäussert werden konnten. Parallel dazu wurden Mitarbeiter aus allen Organisationseinheiten zu Teilzeit-Change Managern ernannt, die dort Ansprechpartner waren und Rückmeldungen sammelten. Zuletzt gab es physische und virtuelle Feedback-Briefkästen.²

Die Erkenntnisse aus diesen Feedbacks waren zum Teil sehr wertvoll. An einer Stelle wurde z.B. darauf hingewiesen, dass beim Abteilungsschnitt eine Zuständigkeitslücke gelassen wurde, an einer anderen Stelle, dass die Aufteilung bestimmer Aufgaben auf zwei Abteilungen zwar theoretisch möglich, in der Realität aber schwierig umzusetzen sein würde, da sie bisher von den selbem Personen durchgeführt wurden. Mehrfach führte das zu Anpassungen, die ebenfalls wieder Gegenstand von Feedback wurden.

Dass diese Anpassungen mit verhältnismässig gerigem Aufwand durchgeführt werden konnten, war vor allem dem Verzicht auf zu frühe Detailplanung zu verdanken. So wären in den beiden erwähnten Beispielen die Korrekturen der suboptimalen Abteilungsschnitte deutlich schwieriger gewesen, wenn zu dem Zeitpunkt bereits alle Versetzungen in diese Einheiten stattgefunden hätten. Da die Versetzungen jetzt erst in einem nächsten Schritt stattfanden, entstanden die Probleme gar nicht erst.

Als Nebeneffekt wurde auch die Kommunikation der Veränderungsmassnahmen deutlich einfacher. Statt alle Veränderungen auf einmal konsistent erklären und als Ganzes verstehen zu müssen, wurde jeweils nur auf das aktuelle Arbeitspaket vertieft eingegangen, bei den späteren reichte eine kurze Ankündigung des Inhalts und des geplanten Zeitpunkts. Sowohl im Kommunikationsteam als auch in der Belegschaft wurde das im Vergleich zu früheren Reorganisationen als deutliche Verbesserung empfunden.

Eine Pointe dieser Geschichte hier ist, dass das in ihr beschriebene Vorgehen, nie offiziell als "agil" konzipiert oder bezeichnet wurde. Stattdessen ging es nach Ansicht aller Beteiligten lediglich auf Common Sense und Erfahrungswerte zurück, aus denen sich ganz selbstverständlich die hier beschriebenen Schritte ergaben. Erst ganz zum Schluss fiehl einem Vorstand auf, dass es offensichtliche Parallelen zur agilen Produktentwicklung gab. Grösser thematisiert wurde das aber nie.

Bild: Pexels / Ivan Samkov - Lizenz

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

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

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

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

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

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

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

Bild: Pixabay / The Digital Artist - Lizenz

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

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

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

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

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

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

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

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

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