Ich gestehe: nachdem ich den Grossteil meines Berufslebens in Konzernen verbracht habe, ist mir an vielen Stellen gar nicht mehr bewusst, wie merkwürdig die Sprache ist, die dort mit der Zeit entstanden und normal geworden ist. Dabei sind ihre z.T. speziallen Redewendungen nicht zufällig entstanden, wie die Linguistin Erica Brozovsky hier erklärt.
Manche Dinge ändern sich über die Zeit erstaunlich wenig. Vor genau 10 Jahren habe ich darüber geschrieben, dass (vor allem grosse) Unternehmen Prozessverbesserungen in erster Linie dadurch angehen, dass sie ihnen neue Regeln, Rollen und Liefergegenstände hinzufügen wollen - in vielen Fällen mit dem Ergebnis, dass sich alles eher verschlechtert als verbessert. Dieses kuriose Verhalten lässt sich nahezu überall beobachten - und mittlerweile auch erklären.
Im Artikel People systematically overlook subtractive changes veröffentlicht 2024 im Nature-Magazin haben die schwedischen und amerikanischen Wissenschaftler Joshua Juvrud, Laurence Myers und Pär Nyström das Phänomen beschrieben, dass die meisten Menschen Verbesserungen vor allem durch das Hinzufügen von etwas (additive Veränderung) bewirken wollen, selbst wenn das Weglassen von etwas (subtraktive Veränderung) zu deutlich besseren Ergebnisse führen würde.
Dabei beobachteten die erwähnten Forscher in ihren Untersuchungen nicht etwa, dass subtraktive Veränderungen kategorisch ausgeschlossen wurden. Vielmehr war es so, dass additive Veränderung den meisten untersuchten Menschen als die spontan naheliegendere Option erschien und unreflektiert gewählt wurde, während subtraktive Veränderung erst dann erwogen wurde, wenn additive Veränderungen ergebnislos, unmöglich oder offensichtlich unsinnig waren.
Dieses grundlegende Vernachlässigen subtraktiver Veränderungen (das so genannte Subtraction Neglect) war dabei abhängig von unterschiedlichen Faktoren unterschiedlich stark ausgeprägt. Zu ihnen gehörten neben der Art der Aufgabe auch Alter, sozialer Hintergrund und nationale, bzw. kulturelle Zugehörigkeit. Die zentrale Erkenntnis hierbei war, dass der Subtraction Neglect wenn nicht sogar durch Sozialisation erworben, dann zumindest deutlich von ihr geprägt ist.
Und das bringt uns zurück zu den grossen Organisationen, die ihre Prozesse durch ständiges Hinzufügen weiterer Regeln, Rollen und Liefergegenstände immer stärker überladen und sie so verschlechtern, statt sie zu verbessern. Ausgehend von der erwähnten Forschung kann zunächst mit hoher Wahrscheinlichkeit davon ausgegangen werden, dass das in weiten Teilen auf das Phänomen des Subtraction Neglect zurückzuführen ist, es also unbewusste Ursachen hat.
Gleichzeitig ermöglicht die Beeinflussung der Subtraction Neglect durch soziale Prägung aber auch ein Gegensteuern. Alleine das Bewusstmachen der subtraktiven Veränderung als möglicher Massnahme kann bereits zu einer besseren Optionenabwägung führen und eine Empfehlung sie anzuwenden kann das nochmal verstärken. Und wird dadurch sogar noch ein Erfolg erzielt, kann sich sogar die Grundeinstellung ändern, auch das geht aus der erwähnten Forschung hervor.
Zwölfter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: das Suchen nach einem Schuldigen.
Dass immer dann, wenn irgendetwas schief gelaufen ist, zuerst nach einem Schuldigen gesucht wird, ist ein verbreitetes Phänomen. Wie konnte das passieren? Wer hat da nicht aufgepasst? Wessen Aufgabe wäre es gewesen das zu verhindern? Wer wäre verantwortlich gewesen für einen Prozess der das verhindert? Solche und ähnliche Fragen sind absolute Klassiker, wenn es um die Aufarbeitung geht, und sie alle haben eines gemeinsam: sie sind nicht besonders zielführend.
Zunächst führen sie immer wieder zu einem erstaunlichen Forschungs- und Exegese-Aufwand, um rückwirkend aus irgendeiner Vorschrift oder Abmachung ableiten zu können, wer sich theoretisch oder nach "gesundem Menschenverstand" hätte verantwortlich fühlen müssen, oder wer irgendwann mal eine Zusage gemacht oder eine Aufgabe übernommen hat, aus der sich die Verantwortung für das mittlerweile eingetretene Missgeschick ableiten liesse.
Umgekehrt ergeben sich aus ihnen ähnlich grosse Aufwände, mit denen alle, die für die Schuld in Frage kommen, belegen wollen, dass sie selbst in keinem Fall verantwortlich sind. Auch von ihnen werden alle möglichen Vorschriften, Abmachungen, Protokolle, Pläne, Zuständigkeitsbeschreibungen und sonstigen Dokumente gewälzt werden um mit deren Hilfe nachweisen zu können, zum jeweiligen Zeitpunkt nicht informiert, verfügbar oder zuständig gewesen zu sein.
Und damit endet es nicht. Sind einer oder mehrere Schuldige gefunden worden, werden sie erfahrungsgemäss erhebliche weitere Aufwände in Distanzierungen, Absicherungen und ähnliche Tätigkeiten stecken, um beim nächsten mal nicht mehr Schuld zu sein. Und sollte die Schuldzuordnung unklar gewesen sein, fliessen häufig erhebliche weitere Aufwände inzusätzliche Regeln, Dokumentations-Pflichten und weitere Massnahmen, um das nächste mal die Schuld klarer zuweisen zu können.
Nichts davon erzeugt einen Mehrwert, alles davon verbraucht Zeit und Energie. Es ist Muda in Reinform.
Um eine Alternative aufzuzeigen: statt den Schuldigen zu suchen könnte man überlegen, wie man Prozesse sicherer oder unbürokratischer gestaltet, Kommunikation einfacher und direkter möglich macht, Qualitätssicherungs-Massnahmen einführt die nicht nur aus Dokumentations-Pflichten bestehen und vieles mehr. Das wären Schritte, die zwar auch Aufwand verursachen, aber einen der sich auszahlt und nicht bloss alle Beteiligten frustriert.
 |
| 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.
— Madhu Guru (@realmadhuguru) July 29, 2025
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,…
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.
