On Lean and Agility

Genau wie bei den etwas älteren agilen Frameworks stellt sich auch beim relativ neuen AI-Driven Development Lifecycle (AI-DLC) die Frage: wie lässt es sich in die umgebende Organisation so integrieren, dass Risikomanagement, Kostenmanagement, Wissensmanagement, etc. weiterhin funktionieren? Dieser Erfahrungsbericht von Shilpa Nagavara ist einer der ersten, die dieses Thema öffentlich beleuchten.

Spannend an ihren Ausführungen ist, dass bei der Umsetzung sowohl soziale als auch technische Probleme auftreten und ineinandergreifen, von der Notwendigkeit nonverbale Kommunikation gegenüber der KI explizit zu machen bis hin zur Token-Ökonomie. Und was Shilpa Nagavara zu Recht hervorhebt: es ist noch alles im Work in Progress-Zustand, im wohnt also noch der Anfangszauber inne.

Das was Randy Shoup hier abliefert ist ein bemerkenswerter Einblick in die Welt grosser (IT-)Organisationen. Seine zentrale Botschaft, die er mit zahlreichen Beispielen aus seiner Zeit bei Ebay unterlegt: wenn ein Unternehmen eine dysfunktionale Unternehmenskultur hat, dann wird eine Modernisierung der Prozesse, Tools und IT-Systeme nur in begrenztem Ausmass zu Verbesserungen führen. Keine neue Erkenntnis, aber sehr anschaulich an einem bekannten Beispiel erklärt.

Eine zweite von ihm erzählte Geschichte, die in der oben genannten Enthalten ist, ist die der bei Ebay vorgenommenen Prozess-, Tool- und System-Modernisierungen, die trotz des letztendlichen Scheiterns an kulturellen Mustern zwischenzeitlich zu deutlichen Verbesserungen geführt haben. Shoup zufolge ist das mit einem geradezu minimalistischen Vorgehensmodell gelungen: der kontinuierlichen Identifikation von verlangsamenden Faktoren und deren sequentieller Abarbeitung durch ein die Entwicklungsteams unterstützendes Plattform-Team. Geradezu das Gegenmodell zu SAFe & Co.

Wenn die Aussenwahrnehmung eines Arbeitgebers sehr stark durch einen einzigen HR-Aspekt geprägt ist, dann muss das schon ein ganz besonderer sein. Dementsprechend sind solche Fälle zwar selten, aber es gibt sie immer wieder. Die Side Project Time bei Google ist ein bekanntes Beispiel oder die freie Vorgesetzten-Wahl bei Uber. Das vermutlich kontroverseste dieser Beispiele dürfte aber der so genannte "Keeper Test" von Netflix sein.

Besagter Test wurde in dieser Firma bereits 2001 als Praktik eingeführt, 2009 im so genannten Culture Deck offiziell gemacht und 2020 im Buch No Rules Rules einer breiteren Öffentlichkeit vorgestellt. Es gibt ihn in verschiedenen (inhaltlich gleichen) Varianten, die im besagten Buch vorgestellte ist diese hier:

If a person in your team were to quit tomorrow, would you try to change their mind? Or would you accept their resignation, perhaps with a little relief? If the latter, you should give them a severance package now, and look for a star, someone you would fight to keep.

Zu Deutsch: jeder Manager sollte sich bei jedem seiner Untergebenen fragen, ob er ihm eine Kündigung ausreden würde - und wenn nicht, dann soll er ihm eine Abfindung zahlen, damit er geht, und sich einen besseren Ersatz suchen. Das klingt zunächst einmal extrem hart und hat tatsächlich auch dazu geführt, dass Netflix in den Medien das Schaffen einer Angstkultur vorgeworfen wurde. Aber wie so oft in derartigen Fällen: ganz so einfach ist es nicht.

Zunächst muss man die wichtige Kontext-Information kennen, dass in der IT-Industrie im Allgemeinen und im Silicon Valley im Besonderen kurze Firmenzugehörigkeiten von jeweils wenige Jahren nichts Ungewöhnliches sind, bei vielen Unternehmen sind sie sogar der Normalfall. Den Menschen, die den Keeper Test nicht bestanden haben, wird also keine Job weggenommen den sie bis zur Rente behalten wollten, es fällt lediglich eine von vielen Stationen etwas kürzer aus.

Ebenfalls wichtig ist, dass die Angestellten von Netflix keineswegs in ständiger Ungewissheit über die Meinung ihrer Vorgesetzten leben müssen. Es gibt sogar ein fest definiertes Auskunftsverfahren, den so genannten "Keeper Test Prompt", mit dem man sein aktuelles Ergebnis erfragen kann. Und da dieses Ergebnis nicht nur aus den Extremwerten Bleiben und Gehen besteht, sondern auch aus vielen Zwischenstufen, hat jeder die Gelegenheit, an sich zu arbeiten um das Testergebnis wieder zu ändern.

Auch ist in der Realität auch das Scheitern an einem Keeper-Test nicht automatisch mit einer Kündigung verbunden (selbst wenn auch das natürlich oft genug vorkommt). In No Rules Rules werden auch Fälle beschrieben, in denen stattdessen eine Versetzung in andere Abteilungen stattfand, in denen die Betroffenen für sie passendere Rahmenbedingungen vorfanden. In Einzelfällen kann die Überlegung, wo der durch den Test gefallene Kollege einen Mehrwert stiften kann, sogar zu Beförderungen führen.

Zuletzt sollte man nicht aus den Augen verlieren, dass der Keeper-Test auch eine sehr positive Seite haben kann. Elizabeth Stone, der Chief Product and Technology Officer (CPTO) von Netflix, hat beispielsweise in einem Podcast erzählt, dass sie in den Personalgesprächen mit ihren Untergebenen regelmässig hervorhebt, was diese so gut machen, dass sie darum kämpfen würde, sie in jedem Fall bei sich zu behalten. Denn auch das gehört dazu: in vielen Einheiten bestehen alle den Test.

Trotz allem bleibt aber die Kernaussage aber natürlich bestehen - die Mitarbeiter, um die man nicht kämpfen würde, sollen bitte gehen. Auch das wird in No Rules Rules detaillierter erklärt: zu denen, von denen man sich trennt, gehören nicht nur die, die schlechte Arbeit leisten, sondern auch die, die sich technischen Innovationen verweigern, die strategische Entscheidungen und organisatorische Veränderungen nicht mittragen wollen, oder die einfach ständig für schlechte Stimmung sorgen.

Aber führt das am Ende nicht doch zu einer Angst- und Ellenbogen-Kultur? Nicht unbedingt. Das Buch zitiert Forschungsergebnisse der amerikanischen Business School-Professorin Erin Meyer, die folgende Zahlen ermittelt hat: Netflix kündigt jährlich im Schnitt 8% seiner Angestellten, und liegt damit nur leicht über dem Branchenschnitt von 6% - gleichzeitig liegt aber die Kündigungsrate der Mitarbeiter bei nur 4%, während diese im Branchenschnitt bei 12% liegt. Eine Angstkultur sähe anders aus.

Was hinter diesen Zahlen steckt ist die Erkenntnis, dass mit den Angestellten, die den Keeper Test nicht bestehen, nicht nur menschlich geschätzte Kollegen die Firma verlassen, sondern vor allem solche, die durch konstant schlechte Arbeitsergebnisse oder durchgehend grenzwertige Verhaltensweisen auf alle anderen demotivierend wirken. Vielleicht ist das der eigentlich kontroverse Gedanke - dass das humane Verhalten gegenüber denen, die die Erwartungen nicht erfüllen, inhuman gegenüber allen anderen ist.

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.