On Lean and Agility

Ü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 dann 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".

Karte: Open Street Map - CC BY-SA 2.0

Weiter geht es mit den "agilen Erfolgsgeschichten". Der Grund für ihre Veröffentlichung bleibt der gleiche: 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, und schlimmstenfalls eine negative Weltsicht entwickeln. Wer sich die durch agile Praktiken und Methoden erzielten Erfolge und Fortschritte vergegenwärtigt, wird sich dagegen leichter damit tun, erfolgreich für sie zu werben.

Zu den Mythen die seit einiger Zeit durch die Arbeitswelt wabern, gehört der, dass Silicon Valley-Firmen (vor allem Google) ihren Mitarbeitern angeblich 20 Prozent ihrer Arbeitszeit zur freien Verfügung stellen, und dass zentrale Produkte wie Adsense und Google News in dieser Zeit "selbstorganisiert entstanden" sind. Zum Wahrheitsgehalt dieser Aussagen findet man unterschiedliche Aussagen, wahr ist aber, dass viele Firmen inspiriert davon ihren Mitarbeitern eine ähnliche, so genannte "Side Project Time" gewähren.

Eine dieser Firmen durfte ich eine Zeit lang begleiten. Die Zeit, die den Entwicklern hier für selbstgewählte Nebenprojekte (→ Side Projects) zur Verfügung stand, war vier Stunden pro Woche, plus längeren Zeiträumen für die in den Ferien arbeitenden Rumpfteams. Die Sinnhaftigkeit dieser Regelung wurde von anderen Abteilungen regelmässig in Frage gestellt, was irgendwann dazu führte, dass die Ergebnisse aller derartigen Seitenprojekte gesammelt und zur Überprüfung veröffentlicht wurden.

Angesichts der Grösse von mehreren hundert Entwicklern war natürlich ein gewisser Anteil an Unsinn dabei, wie z.B. ein Chatbot, der auf alle Fragen zu Konkurrenzunternehmen mit wüsten Beschimpfungen antwortete, oder ein Zufallsgenerator für die Erstellung möglicht absurder User Stories, es gab aber auch einige Ergebnisse, die auch den grössten Kritikern Respekt und Anerkennung abnötigten, und dafür sorgten, dass die Side Project Time erhalten blieb.

Einige Entwickler hatten sich z.B. gemeinsam der Aufgabe verschrieben, die technischen Probleme zu beseitigen, die bis dahin dazu geführt hatten, dass ein Grossteil der Meetings deutlich verspätet begonnen hatte. Als Lösung hatten sie jeden Meetingraum mit einem Computer versehen, der fest mit Beamer und Internet verbunden war und einen eigenen Videoconferencing-Account hatte. Ab da musste man nur den Raum betreten, den Rechner anschalten, und es konnte losgehen.

Ein Team hatte eine Intranet-Website gebaut, auf der alle, die sich dort anmeldeten, zu nach Zufallsprinzip erstellten Mittagessens-Verabredungen zusammengebracht wurden. Auf diese Seite entstanden Bekanntschaften kreuz und quer durch das ganze Unternehmen, wodurch abteilungübergreifende Zusammenarbeit und die Suche nach Ansprechpartnern für selten behandelte Themen deutlich vereinfacht und beschleunigt werden konnten.

Eine weitere Gruppe hatte ein Wiki zu den Kantinen, Restaurants und Imbissbuden der Umgebung aufgesetzt, mit Informationen zu Auswahl und Qualität, aber auch zu Stosszeiten, Geschwindigkeit der Bedienung und der Möglichkeit zu bargeldlosem Bezahlen. Das durch Umfragen festgestellte Ergebnis waren kürzere Mittagspausen, in denen gleichzeitig aber mehr Zeit für Essen und Unterhaltungen zur Verfügung stand als vorher.

Das (intern ) bekannteste Ergebnis erzielte aber das Nebenprojekt, in dem einige Entwickler im Firmen-eigenen Auslieferungslogistik-Leitsystem das für betriebliche Anwendungen kostenpflichtige Google Maps durch das kostenlose Open Street Maps ersetzt hatten. Besonders ein Feature erregte Aufsehen: ein Dashboard, mit dessen Hilfe man für beliebige Zeiträume überprüfen konnte, wieviel Geld durch die Ersetzung von Google Maps gespart worden war - er waren auf Dauer erhebliche Summen.

Wass all diese Side Projects gemeinsam hatten, entsprach genau den Gründen, wegen denen ihnen selbstorganisiert abrufbare Zeit eingeräumt worden war: sie wären im Rahmen des offiziellen Priorisierungsverfahren niemals auf den Roadmaps der Teams gelandet, sie lösten konkrete Probleme, mit denen die Entwickler regelmässig zu kämpfen hatten, und sie sorgten in erkennbarem Ausmass für Effektivitätssteigerungen, Kostenersparnisse und höhere Mitarbeiterzufriedenheit.

Man soll ja Erfolge nicht nur feiern, sondern auch in Erinnerung behalten, denn wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann sonst leicht in Frustration abrutschen. Um es nicht dazu kommen zu lassen, möchte ich von einer weiteren "agilen Erfolgsgeschichte" erzählen, die sich einmal im IT-Systemhaus einer grossen Bankengruppe zugetragen hat, bei der Entwicklung eines neuen Onlinebanking-Systems.

Agiles Arbeiten steckte dort noch in den Anfängen, und wie in vielen anderen Unternehmen auch wurde noch davon ausgegangen, dass es sich dabei nur um eine neue Arbeitsweise für die Software-Entwicklung handeln würde. Andere Organisationseinheiten reagierten nur mit einer Mischung aus Amüsiertheit und Entrüstung, als angeregt wurde, dass auch sie ihren Arbeitsmodus ändern sollten. Ihre Ideen waren klar: sie wollten im Voraus definieren, was sie wollten, und dann warten bis es fertig war.

Was zu ihrer Überraschung anders war, war aber, dass ihnen schon früh mitgeteilt werden konnte, wie (un)realistisch ihre Vorstellungen waren. Durch feature- statt komponentenorientierte Entwicklung, frühe Integration und automatisiertes Testen war der reale Arbeitsfortschritt klar erkennbar, und durch eine grobe Schätzung der noch offenen Anforderungen auch die noch nötige Zeit, beziehungsweise die vermutlichen Liefertermine der fehlenden Features. Und nätürlich - die waren später als gewünscht.

Die ersten Reaktionen darauf waren abwiegeln und abstreiten. Es wäre doch noch viel zu früh für solche Aussagen, die Roadmap wäre schliesslich von Experten gemacht worden, die Entwicklungs-Teams müssten nur bereit sein, "etwas Gas zu geben", dann würde der Zeitplan wieder passen. Und so weiter. Allein - alle drei Wochen bestanden die Entwickler in den Sprint Reviews auf ihren schlechten Botschaften. Im ersten Quartal, im zweiten, im dritten, und am Anfang des vierten.

Wenige Monate blieben damit noch bis zum geplanten Go Live in der ersten Tochtergesellschaft, und plötzlich wollten auch die anderen Organisationseinheiten agil werden. Besonders ein Begriff hatte es ihnen auf einmal angetan: das Minimum Viable Product (MVP), in ihrem Verständnis ein nur auf das absolut Notwendige reduzierter Funktionsumfang, mit dem der anvisierte Termin noch irgendwie zu halten sein müsste. Den wollten sie haben, und den glaubten die Entwickler auch liefern zu können.

In der Folgezeit wurden die Anforderungen Seite um Seite zusammengestrichen. Opulente Redaktions-Workflows? Erstmal nicht. Der komplette Nachbau aller Features des alten Systems im Neuen? Völlig übertrieben. Die Umstellung aller internen CMS-Seiten auf die Fonts, Formen und Farben des Corporate Design? Unnötig. Etc. Am Ende blieb nur ein letztes der unrealistisch grossen Arbeitspakete übrig, das angeblich nicht verhandelbar war. Das so genannte Reporting Center.

Dieses letzte laut Compliance-Abteilung zwingend nötige Feature sollte sicherstellen, dass sich nachvollziehen liess, welcher interne Mitarbeiter wann welche Änderungen in dem Onlinebanking-System vorgenommen hatte. Zu diesem Zweck sollte es möglich sein, sich alle Änderungen anzeigen zu lassen, sie nach Zeitraum, Bearbeiterrolle oder betroffenem Teilsystem zu filtern und grafisch aufbereitet anzeigen zu lassen. "Wenn es das nicht gibt, macht uns die Bafin den Laden zu", hiess es.

Als zwei Wochen vor Weihnachten absehbar wurde, dass auch diese Drohung nicht zu einer wundersamen schnellen Fertigstellung führen würde, fiel auf einmal auch hier das neue magische Wort. "Gibt es nicht auch davon ein MVP, und wenn ja, welches?" Und es gab eines - eine aus dem System exportierte Tabelle aller Bearbeitungsvorgänge, mit dem Angebot der Entwickler, ggf. beim Verständnis zu helfen. Und ein inoffizielles Vorfühlen bei der Bafin ergab: für die erste Version würde das reichen.

Und damit war es geschafft. Das Go Live in der ersten Tochtergesellschaft konnte wie geplant stattfinden, und nicht nur das. Die dort mit dem MVP-System arbeitenden Mitarbeiter konnten gefragt werden, wie sie mit dem System zurechtkamen, ihnen konnte gesagt werden, welche Features sonst noch geplant waren, und was sie vermutlich kosten würden. Und völlig überraschend kam das Feedback, dass viele davon gar nicht benötigt würden und stattdessen etwas Anderes sinnvoll wäre.

Dem Vernehmen nach ist das etwas überdimensionierte Reporting Center irgendwann doch gekommen, aber trotzdem enthält diese Geschichte einigen von dem, was agiles Arbeiten so wirkungsvoll macht: frühe Auslieferung, hohe Transparenz, ständiges Feedback, ein MVP, aus dem man mehr über die echten Bedürfnisse echter Anwender lernen kann und eine Anpassung der Pläne an die Realität (statt des Versuchs das Gegenteil zu erzwingen). Und all das in einer stark regulierten Branche.

Bild: Pexels / Ketut Subiyanto - Lizenz

Es ist mal wieder Zeit für eine Agile Success Story. 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, das kann man viel zu oft bei Agile Coaches, Scrum Mastern und ähnlichen Rollen erleben. Um nicht selbst in dieses Muster verfallen, möchte ich dagegenhalten, indem ich selbst erlebte "agile Erfolgsgeschichten" veröffentliche, heute eine zum Thema Kanban.

Eigentlich hatte ich den Auftrag gar nicht annehmen wollen. Insgesamt sieben verschiedene Abteilungen eines Kunden wollten "ihre Zusammenarbeit agiler machen", davon drei Fachabteilungen, zwei aus der IT, eine aus Operations und eine aus dem Einkauf. Das klang als Herausforderung durchaus spannend, das Problem war aber das Budget - für eine Woche in Vollzeit würde es reichen, danach nur noch für vier Tage pro Monat während des restlichen Jahres. Im Grunde viel zu wenig.

Am Ende liess ich mich darauf ein, wenn auch mit einer klaren Einschränkung: in dieser knappen Zeit würde zu Beginn kaum mehr möglich sein als die Ermittlung und Visualisierung des Value Streams, und in späteren wöchentlichen Terminen ein Inspect & Adapt in kleinen Schritten. Die urspünglich vom Kunden gewünschte Einführung eines agilen Skalierungsframeworks wäre mit diesem geringen Aufwand illusorisch gewesen. Das wurde angenommen, also legten wir los.

Bereits das Value Stream Mapping war dann anspruchsvoll genug. Es handelte sich um eine geschäftskritische Anwendung, die auf Wunsch interner und externer Stakeholder ständig weiterentwickelt wurde. Neue Features wurden jeweils von einer der drei Fachabteilungen beauftragt und entweder von einer der beiden internen IT-Abteilungen oder durch externe Dienstleister (koordiniert durch den Einkauf) entwickelt.

Das, was dieses Vorgehen schwierig machte, waren Unübersichtlichkeit und Intransparenz. Es gab so viele Feature Requests (die natürlich alle dringend waren), dass niemand einen Gesamtüberblick darüber hatte, welche internen oder externen Entwickler gearde im Auftrag welcher Fachabteilung etwas umsetzten. Das Ergebnis waren redundante Arbeiten, die Entwicklung inkompatibler Features, ständige Nacharbeiten, zu hohe Arbeitsbelastung und ständig gerissene Deadlines.

Nach einer Woche intensiven Nachforschens gab es dann ein erstes Ergebnis: abhängig von den beiden Variablen bestehendes/neues Budget und interne/externe Entwicklung liessen sich drei Varianten des Value Streams identifizieren, eine mit 10 Stationen, eine mit 15 und eine mit 19 (!). Da das bei weitem zu viel war um auf einem Bildschirm überblickbar zu sein, fand die Visualisierung in Form eines physischen Kanban-Boards statt - Drei Zeilen mit jeweils 10, 15 und 19 Spalten.¹

Bis zu unserem ersten Einzeltermin hatten die verschiedenen Einheiten sich dann die Aufgabe mitgenommen, alle grösseren Arbeitspakete an denen sie gerade sassen auf dieses Board zu bringen. Als ich nach einer Woche zurückkam war ich erstmal erschlagen - mehr als 60 verschiedene Zettel hingen über das ganze Board verstreut, jeder einzelne davon als Symbolisierung eines Gesamtaufwandes von mindestens einer Personenwoche. Kein Wunder, dass bisher die Übersicht gefehlt hatte.

Eigentlich hatte ich als nächstes vor diesem Board ein Daily etablieren wollen, was aber in einem lauten Proteststurm unterging ("Nicht noch mehr Meetings", wurde gefordert). Worauf sich alle einlassen konnten war aber ein wöchentlicher Termin, in dem Vertreter der sieben Abteilungen alles was in den letzten Tagen stattgefunden hatte auf dem Board aktualisierten, egal ob es neue Requests, Entwicklungsfortschritte, Budget-Zusagen oder sonst etwas waren.

Was in diesen Terminen auffällig war, war, dass nahezu jede Aktualisierung eine mittelgrosse Diskussion auslöste. Deren Inhalte reichten von Überraschung und Interesse über Zustimmung und Feedback bis hin zu Protest und Sinnfragen. Nahezu jeder der teilnahm hatte irgendetwas zu irgendeinem Thema beizutragen, so dass es regelmässig mehr als zwei Stunden dauerte, bis auf dem Board alles auf den aktuellen Stand gebracht war.²

Das wirklich Bemerkenswerte an diesen "Kanban Weeklies" war aber nicht ihre Länge. Anders als man es hätte erwarten können gab es kaum Beschwerden darüber, dass in sie so viel Zeit investiert werden musste oder dass in ihnen so viele Themen diskutiert wurden. Stattdessen wurde regelmässig hervorgehoben, wieviel grösser durch sie Transparenz, Übersichtlichkeit und als Folge dessen auch Planbarkeit und Reaktionsfähigkeit geworden wären.

Gleich mehrfach konnten neue Feature Requests einzelner Fachabteilungen bereits im Anbahnungsstatus gestoppt werden, weil eine der anderen darauf hinwies, etwas Vergleichbares bereits beauftragt zu haben. Die Entwicklungsabteilungen konnten besser absehen, wann grössere Arbeitspakete bei ihnen einschlagen würden und sich entsprechend Zeit einplanen. Die Operations-Abteilung konnte sich auf Lastspitzen durch neue Features besser einstellen. Etc, etc, etc.

Selbst wenn es WIP-Limits, Service-Klassen, Durchlauf-Metriken und viele andere Ideen die ich hatte aufgrund des beschränkten Zeitbudgets nicht mehr in dieses Kanban-System geschafft haben, wurden das Board uns seine Benutzung von allen Beteiligten als eine spürbare Verbesserung gesehen, durch die die meisten der oben genannten Probleme (redundante Arbeit, Intransparenz, ständige Nacharbeiten, etc.) spürbar zurückgegangen waren.

Auch ich habe aus diesem Einsatz eine Lehre mitgenommen: auch eine punktuelle Begleitung kann unter Umständen völlig ausreichend sein. Es braucht nicht immer einen Scrum Master, Kanban Coach oder sonstigen Methodiker, der in Vollzeit ein Team begleitet, manchmal kann es genügen, den Arbeitsfluss zu visualisieren, alle Beteiligten dazu zu bewegen ihn sich regelmässig gemeinsam anzusehen und darauf zu vertrauen, dass sich daraus die richtigen Dinge ergeben werden.

Bild: Pexels / Andrea Piacquadio - 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.

Die heutige kleine Geschichte habe ich in einem grossen Industriekonzern erlebt, der in mehreren Grossprojekten seine Anlagensteuerung und -überwachung digitalisierte und modernisierte. Diese Projekte waren zu Beginn alle nach Wasserfall durchgeführt worden, das in dem ich zeitweise war, war eines der ersten in denen agil gearbeitet wurde - unter misstrauischer Beobachtung übrigens, da es das verbreitete Vorurteil gab, dieser Arbeitsmodus wäre unzuverlässig und unsicher.

Wie man sich denken kann hakte es an einigen Stellen, unter anderem waren viele Stakeholder lange nicht bereit an den Sprint Reviews teilzunehmen, solange noch nicht alle Anforderungen vollständig umgesetzt waren.¹ Erst eine Management-Intervention konnte das ändern, und so liessen sich ein Vierteljahr vor dem Go Live eines neuen Überwachungssystems endlich einige der zukünftigen Anwender vom Entwicklungsteam den bisher fertiggestellen Umfang vorführen.

Einer dieser zukünftigen Anwender war deren Teamleiter, ein Ingenieur namens Xin Mi.² Mit strengem Blick verfolgte er die Vorführung, stellte mehrfach Nachfragen und machte sich jedesmal kopfschüttelnd Notizen, wenn er über ein Feature hörte, dass es erst in einem der kommenden Sprints umgesetzt werden würde. Irgendwann wurde er dann plötzlich hektisch und aufgeregt. Laut auf deutsch, englisch und chinesisch schimpfend stürmte er aus dem Raum, immer wieder "das geht so nicht" rufend.

Sein Problem: die Überwachungs-Ergebnisse des neuen Systems wurden in Echtzeit auf einem Bildschirm angezeigt. Was niemand dem Entwicklungsteam gesagt hatte war aber, dass der nur einer von über 20 auf einer ganzen Bildschirm-Wand sein würde. Was Xin Mi zurecht anmerkte - der davor sitzende so genannte Operator könnte eine auf nur diesem einem Bildschirm angezeigte Störungsmeldung leicht übersehen, und auch der Warnton war so leise, dass er in einem solchen Raum überhört werden könnte.

Etwas irritiert von dem Ausmass des Dramas überlegte das Team sich im folgenden Planning eine Lösung: der Warnton wurde lauter und durchdringender und um den Bildschirm wurde bei Störungen ein rot blinkender Rahmen angezeigt, um den Blick dorthin zu lenken. Die Umsetzung passte auch irgendwie noch in den nächsten Sprint hinein. Der immer noch aufgebrachte Xin Mi war zwar nicht bereit, während des Sprints darüber zu reden, zum nächsten Sprint Review kündigte er sich aber an.

Diesesmal tauchte er in Begleitung mehrerer Manager auf und verhielt sich wieder überraschend. Direkt zu Beginn verlangte er die Agenda umzustellen und mit der Störungsmeldung zu beginnen. Leicht irritiert gab das Entwicklungsteam diesem Wunsch nach und führte die Ergänzungen des letzten Sprints vor. Xin Mi, der gerade angesetzt hatte, den mitgebrachten Managern zu erklären, wie schlimm alles wäre, war völlig perplex. Dass sein Problem plötzlich gelöst war, war für ihn unbegreiflich.

Sein verdattertes Schweigen wurde von den Entwicklern falsch interpretiert und für Unzufriedenheit gehalten, also machten sie ein weiteres Angebot: Wenn Warnton oder Signalfarbe nicht passen würden könnte man auch das im nächsten Sprint noch ändern, jetzt, da die Funktionen da wären, wäre das kein Problem mehr. Für Xin Mi war das zu viel. Mit Tränen in den Augen stand er auf, bedankte sich überschwänglich und entschuldigte sich für sein bisher ablehnendes Verhalten.

Zum Hintergrund: in den bisherigen Wasserfallprojekten waren auch kleinste Änderungen der Anforderungen nur mit erheblichen bürokratischen Aufwänden machbar gewesen. Da neue Funktionen in den alten Anwendungen nur zweimal pro Jahr released wurden, waren diese Releases aufwändig und fehleranfällig, was dazu geführt hatte, dass zusätzliche Änderungen möglichst abzulehnen waren. Für jemanden der aus einer solchen Welt kommt, sind Auslieferungen alle zwei Wochen unvorstellbar.

Obwohl (oder vielleicht gerade weil) die hier beschriebene Anpassung nicht besonders gross war, war ihre schnelle und unkomplizierte Umsetzung für Xin Mi ein Erweckungserlebnis. Er wurde zum begeisterten Teilnehmer der Sprint Reviews und zum grössten Fürsprecher des agilen Arbeitens in seiner Abteilung und zog sogar zeitweise in das Büro des Entwicklungsteams, um so einen noch engeren und intensiveren Austausch haben zu können. Ein Stakeholder wie man ihn sich wünscht.