On Lean and Agility

Bild: Unsplash / Austin Distel -

Für viele Scrum Master oder Scrum Teams ist die Frage nach dem wichtigsten Scrum-Meeting schnell beantwortet: die meisten werden schnell die Retrospektive nennen, die in der Regel als das Inspect & Adapt-Event schlechthin gesehen wird. Ein nennenswerte Minderheit dürfte eher zum Daily Scrum tendieren, in dem auf tagesaktueller Basis der Arbeitsfortschritt besprochen wird. Ich dagegen würde ein drittes Meeting als das wichtigste bezeichnen: das Sprint Review.

Um zu verstehen wie ich dazu komme besinnen wir uns kurz auf etwas Grundlegendes: der einzige Existenz-Zweck eines Scrum Teams ist die Lieferung von benutzbarem Mehrwert für ein Markt- oder Kundensegment. Alle anderen üblicherweise angestrebten Ziele (schlanke Prozesse, schnelle Reaktionsfähigkeit, technische Exzellenz, psychologische Sicherheit, etc.) sind nur Mittel um dieses Haupt-Ziel zu erreichen denn nur dieses Hauptziel sichert das wirtschaftliche Überleben.

Die Überprüfung, ob auf dieses Hauptziel noch immer hingearbeitet wird könnte nun theoretisch in jedem der Scrum Meetings stattfinden. Im Planning sollten nur wertstiftende Sprintziele eingeplant werden, im Daily sollte sichergestellt werden, dass nur auf dieses Ziel hingearbeitet wird, in der Retrospektive kann daran gearbeitet werden, all das nochmals zu optimieren. Eines aber ist in all diesen Meetings nicht möglich: zu überprüfen, ob wirklich Wert geschaffen wird.

Der Grund dafür ist einfach: in allen Regel-Meetings (mit der einen Ausnahme des Sprint Reviews) sind die meisten Scrum Teams unter sich. Ob tatsächlich etwas Wertschöpfendes geplant und geschaffen wird, sehen sie dort nur aus ihrer subjektiven Perspektive - und schlimmstenfalls ist die verfälscht, durch Group Think, Betriebsblindheit, Confirmation Biases und andere Antipattern. Derartige Teams bauen ihr Produkt de facto nur noch für sich, und oft genug an ihrer Zielgruppe vorbei.

Um es dazu nicht kommen zu lassen hilft nur eines: die eigene Filterblase regelmässig platzen lassen und den Kontakt mit der echten Welt da draussen suchen. Nur echte Kunden (und wenn die nicht greifbar sind dann wenigstens echte Kundenservice- oder Vertriebsmitarbeiter) können wirklich sagen, ob eine Nutzungs- und/oder Kaufbereitschaft für das erstellte Produkt besteht. Und diese echten Kunden oder Kundenvertreter trifft das Scrum Team eben im Sprint Review, das darum das wichtigste Meeting ist.

Das heisst natürlich nicht, dass die anderen Scrum Meetings unwichtig sind, im Gegenteil. Jedes von ihnen erfüllt einen bestimmten und entscheidenden Zweck. Aber in Relation zum Sprint Review und seiner für die Validierungs des Existenzwecks des Team elementaren Funktion treten sie alle ein Stück in den Hintergrund. So zumindest meine Meinung, die ich schon seit Jahren und in jeder sich bietenden Diskussion gerne verteidige.

Der Vollständigkeit halber sei natürlich erwähnt, dass es in Scrum theoretisch auch noch andere Möglichkeiten gibt, durch Zielgruppen- oder Stakeholder-Einbindung aus der eigenen Filterblase herauszukommen. Mehr dazu hier. Aber nach über 10 Jahren in zig Unternehmen traue ich mir die Aussage zu, dass das nur in sehr, sehr wenigen Teams stattfindet. Warum auch immer.

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

Sehr wohltuend an der gerade laufenden Marktbereinigung: es hat schon länger niemand mehr den Gartner Hype Cycle auf irgendetwas Agiles angewandt.

An sich klingt es erst einmal wie etwas Positives: mit Hilfe der immer besseren und intuitiveren KI-Tools ist es heute so einfach wie nie, Software zu erstellen. Sei es als Programmier-Unterstützung, wie im Fall des Github Copilot, oder als ein Programm, dass einem den Grossteil der Arbeit abnimmt, wie Lovable - es gibt eine ganze Reihe von Möglichkeiten, die eigene Produktivität in bisher ungeahnte Höhen zu schrauben. Und doch steckt auch ein Risiko dahinter.

Vereinfacht gesagt: wenn es auf einmal so einfach ist, neue Programme und Features zu erstellen, wird das auch mit grösserer Bereitwilligkeit getan werden als bisher. Statt aufgrund der begrenzten Kapazität der IT-Abteilungen nur die wirklich wichtigsten Anforderungen umzusetzen, kann jetzt jeder Kundenwunsch, jede einzelne Stakeholder-Anforderung und jede Entwickler-Idee in Produktion gebracht werden. Und das ist bei weitem nicht so positiv, wie es klingen mag.

Die offensichtlichste Folge eines derartigen bereitwilligen Umsetzens aller Wünsche ist die Entstehung von Bloatware, also von Anwendungen, die derartig mit Funktionen überladen sind (von denen viele nur eine sehr kleine oder ggf. sogar lediglich eine hypothetische Anwendergruppe haben) dass sie unübersichtlich werden, schlecht zu bedienen sind, hohe Ladezeiten haben und viel Speicherplatz einnehmen. Mit anderen Worten - es wird ein aus Kundensicht schlechtes Produkt.

Und auch unterhalb der Benutzeroberfläche führt das massenhafte Erzeugen von Funktionalitäten (und damit von Code) zu Problemen. Auch hier ist die Unübersichtlichkeit ein zentrales Problem. Je grösser die Codebase wird, desto schwieriger wird es zu sagen, an welcher Stelle was passiert. Die Überprüfung der KI-Ergebnisse durch einen Menschen (deren Verzicht einem Kontrollverlust gleichkäme) wird immer schwieriger und irgendwann sogar unmöglich.

Diese Phänomene erinnern nicht ohne Grund an die Build Trap (sinngemäss die Produktivitäts-Falle), die 2019 von Melissa Perri in ihrem gleich benannten Buch beschrieben wurde. Auch ihr selbst ist diese Parallele aufgefallen, und sie hat sie in mehreren Social Media-Posts thematisiert. Von ihr stammt auch die Erweiterung des ursprünglichen Begriffs zu dem der AI Build Trap, der damit als zusätzliche und spezifische Ausprägung dieses Antipatterns beschrieben ist.

Um auch hier zu einem konstruktiven Ausblick zu kommen: in die AI-Produktivitäts-Falle zu geraten, ist zum Glück kein Naturgesetz, man kann (und sollte) es auf verschiedene Weisen verhindern. Zum einen, indem man durch kleine, schnell veröffentlichte Incremente überprüft, ob es für die neuen Funktionen überhaupt Bedarf oder Akzeptanz gibt, zum anderen indem intern regelmässig sichergestellt wird, dass der Code von Menschen verstanden wird und ggf. verändert werden kann.

Das kann sich natürlich wie eine Entschleunigung der gerade erst gewonnenen Programmier-Höchsgeschwindigkeit anfühlen - und es ist auch eine. Trotzdem ist es sinnvoll, sich darauf einzulassen, wenn man nicht riskieren will, sich in der Build Trap wiederzufinden, und Produkte gebaut zu haben, die vom  Kunden nicht gewollt und von den eigenen Entwicklern nicht verstanden werden.

Witzig ist das auf gleich zwei Ebenen: zum einen, weil es die durch die DevOps-Community wabernden Buzzword-Wolken treffend persifliert, zum anderen weil in dem ganzen Wortsalat einige sehr scharfe Abrechnungen mit häufigen Umsetzungs-Fehlern versteckt sind. "DevOps is a mindset - you build it, you run it. Now you're bad at building and running it." Soll tatsächlich so vorkommen.

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

Grafik: Pixabay / Brian Penny - Lizenz

Emily Webber: The Scaling Teams checklist

David Pereira: Why Fail Fast Culture Doesn’t Fly In Most Places

Jenny Wanger: Product ops without permission

Falk Steiner: 20 Jahre unbemerkt - Programmierfehler sorgt für fehlende Lehrer.

Maarten Dalmijn: If You're Using AI to Generate Requirements or User Stories You're Completely Missing the Point.

Bild: Public Domain Pictures / Petr Kratochvil - CC0 1.0

Einige der "Gesetze", in denen Zwangsläufigkeiten und Regelmässigkeiten grosser Organisationen beschrieben werden, haben es in den letzten Jahrzehnten zu grösserer Bekanntheit gebracht, etwa Conway's Law oder Goodhart's Law. Heute soll es aber um eines der weniger bekannten gehen. Gefunden habe ich es im Blog des Agilen Otter, und es trägt den Namen TheLaw of the Second Floor, sinngemäss übersetzbar mit Das Gesetz der zwei Stockwerke.

Nobody two levels ABOVE OR BELOW you on the org chart really knows what your days are like

Law of the second floor

Auch das sinngemäss ins Deutsche übersetzt: niemand, der in der Hierarchie zwei Ebenen über oder unter Dir ist, weiss womit Du Deine Arbeitszeit verbringst. Dass diese "Gesetzmässigkeit" (bei der es sich eigentlich um eine häufig zu machende Beobachtung handelt) dann Gesetz der zwei Stockwerke heisst, liegt in der Gleichsetzung von Hierarchieebene und Stockwerk begründet, die sich tatsächlich in vielen Unternehmen so wiederfindet.

Wie alle Beobachtungen ist auch die, auf der das Gesetz der zwei Stockwerke beruht, erst einmal wertneutral, allerdings ist implizit bereits die Bewertung enthalten, dass die Unkenntnis der Situation des jeweils anderen zu suboptmalen Ergebnissen führen wird - in Ermangelung eines genauen Wissens werden Annahmen getroffen, die zu einem gewissen Anteil falsch sind, was wiederum dazu führt, dass darauf beruhende Anweisungen oder die Reaktionen auf diese es ebenfalls sind.

Ein scheinbar naheliegender Verbesserungsansatz wäre es, dieses Problem an seiner Wurzel zu behandeln, indem man allen Beteiligten die Situation der jeweils anderen nachvollziehbar macht. Das ist aber schwer bis unmöglich - unten in der Hierarchie sind Detailgrad und Focus hoch, oben ist der Detailgrad gering und an Stelle eines thematischen Focus tritt eine breite, abstraktere Sicht. In beiden Fällen sind Kontext, Terminologie, etc. hochgradig spezifisch und z.T. gegenläufig.¹

Versucht wird das trotzdem immer wieder, z.B. durch Mitarbeiter-Befragungen, Veröffentlichungen im Intranet, Townhall-Meetings und weitere Formate. Mehr als ein bestenfalls oberflächliches Verständnis entsteht dabei aber selten, alleine aufgrund des damit verbundenen Kommunikations- und Lernaufwandes, der den Beteilgten in der Regel unverhältnismässig erscheint und für den in den meisten Fällen auch gar nicht genug Zeit zur Verfügung steht.

Alleine diese Erkenntnis kann, wenn sie allgemein geteilt wird, zu deutlichen subjektiven und systemischen Verbesserungen führen. Zum einen, weil es die Annahmen und Erwartungshaltungen gegenüber anderen Personen realistischer macht, zum anderen dadurch, dass niemand mehr (irrigerweise) glaubt, im Zweifel bereits alles zu wissen, was für eine Entscheidung notwendig ist. Die gemeinsame Arbeit an übergreifenden Zielen kann dadurch deutlich erleichtert werden.

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.