In vielen Unternehmen entsteht derzeit ein merkwürdiges Missverhältnis: Die Fähigkeit, Arbeit zu produzieren, wächst deutlich schneller als die Fähigkeit, aus den Ergebnissen dieser Arbeit zu lernen.
Mit KI wird dieses Problem noch sichtbarer. Anforderungen lassen sich schneller formulieren, Code schneller erzeugen, Tests schneller schreiben und Änderungen schneller ausliefern. Was früher mehrere Tage gedauert hat, kann unter guten Bedingungen innerhalb weniger Stunden umgesetzt werden.
Das klingt zunächst nach einem Produktivitätsgewinn.
Ist es auch.
Allerdings nur dann, wenn die Organisation anschließend noch weiß, ob das, was schneller produziert wurde, tatsächlich etwas verbessert hat.
Genau hier entsteht Feedback Debt.
Feedback Debt bezeichnet die wachsende Menge an Arbeit, Entscheidungen und Veränderungen, deren tatsächliche Wirkung nie oder erst sehr spät überprüft wurde. Es ist gewissermaßen die organisatorische Schuld, die entsteht, wenn Umsetzung schneller erfolgt als Rückkopplung.
Und davon haben viele Unternehmen erstaunlich viel angesammelt.
Unternehmen sind hervorragend darin geworden, Arbeit zu starten
Neue Anforderungen entstehen nahezu überall.
Ein Fachbereich meldet einen Bedarf. Ein Kunde äußert einen Wunsch. Im Management wird eine neue strategische Initiative beschlossen. In einem Workshop entstehen Maßnahmen. Eine Retrospektive produziert Verbesserungsaktionen. Ein Projekt identifiziert weitere Arbeitspakete.
Danach beginnt die Maschinerie.
Tickets werden erstellt, priorisiert, spezifiziert, geschätzt, geplant, umgesetzt, getestet und irgendwann produktiv gestellt.
Für diesen Teil existieren meist erstaunlich ausgefeilte Prozesse.
Es gibt Backlogs, Boards, Projektpläne, Roadmaps, Statusberichte, Portfolio-Meetings, Steering Committees und Dashboards.
Was deutlich seltener existiert, ist eine ebenso systematische Antwort auf eine wesentlich einfachere Frage:
Hat es funktioniert?
Nicht:
Wurde es ausgeliefert?
Nicht:
Ist das Ticket geschlossen?
Nicht:
Ist das Projekt grün?
Sondern:
Hat sich durch die Änderung tatsächlich das verbessert, was verbessert werden sollte?
Diese Frage klingt banal. In vielen Organisationen ist sie erstaunlich schwer zu beantworten.
„Done“ bedeutet meistens nur: Die Arbeit ist vorbei
Softwareentwicklung besitzt eine starke Tendenz, ihren Erfolg über Output zu definieren.
Ein Feature wurde veröffentlicht.
Eine Schnittstelle wurde gebaut.
Ein Prozess wurde digitalisiert.
Ein neues Dashboard ist verfügbar.
Das Projekt wurde abgeschlossen.
Damit verschwindet die Arbeit vom Board und die Aufmerksamkeit wandert zum nächsten Thema.
Organisatorisch ist das nachvollziehbar. Neue Anforderungen stehen bereits bereit, Stakeholder warten und die nächste Initiative läuft längst.
Genau dadurch entsteht jedoch Feedback Debt.
Denn mit jeder Änderung bleiben unbeantwortete Fragen zurück.
Nutzen Menschen die neue Funktion überhaupt?
Hat sich der erwartete Prozess verbessert?
Wurde tatsächlich Zeit eingespart?
Sind weniger Fehler entstanden?
Hat sich lediglich das Verhalten verlagert?
Sind unbeabsichtigte Nebenwirkungen entstanden?
War die ursprüngliche Annahme überhaupt korrekt?
Solange diese Fragen offen bleiben, besitzt die Organisation zwar mehr Software, aber nicht zwingend mehr Wissen.
Feedback Debt ist zunächst unsichtbar
Technische Schulden werden irgendwann spürbar.
Änderungen dauern länger, Systeme werden fragiler, Tests komplizierter und Entwickler beginnen, bestimmte Bereiche des Codes nur noch mit leichtem Unbehagen anzufassen.
Feedback Debt verhält sich anders.
Ein Feature kann technisch hervorragend umgesetzt worden sein und trotzdem keinerlei relevanten Nutzen erzeugen.
Das System funktioniert.
Die Tests sind grün.
Die Architektur ist sauber.
Nur braucht es niemand.
Organisatorisch kann dieser Zustand erstaunlich lange unentdeckt bleiben, weil klassische Steuerungsmechanismen vor allem beobachten, ob Arbeit erledigt wurde, und deutlich seltener, was diese Arbeit bewirkt hat.
Dadurch entsteht ein gefährlicher Effekt: Fehlendes Feedback sieht zunächst nicht wie ein Problem aus.
Es sieht nach Fortschritt aus.
In großen Organisationen wächst diese Schuld besonders leicht
Je größer eine Organisation wird, desto weiter entfernen sich häufig diejenigen, die eine Entscheidung treffen, von denjenigen, die ihre tatsächlichen Auswirkungen erleben.
Zwischen einer Produktidee und ihrer Wirkung können mehrere organisatorische Ebenen liegen.
Management.
Portfolio.
Fachbereich.
Product Management.
IT.
Entwicklungsteam.
Betrieb.
Kundenservice.
Nutzer.
An jeder dieser Stellen entstehen Informationen. Aber diese Informationen fließen nicht automatisch zurück.
Ein Support-Team erkennt vielleicht seit Monaten ein bestimmtes Nutzungsmuster. Die Produktentwicklung sieht jedoch nur Tickets.
Ein Fachbereich bemerkt, dass ein neuer Prozess regelmäßig umgangen wird. Das Projekt, das ihn eingeführt hat, wurde längst abgeschlossen.
Monitoring zeigt, dass eine Funktion kaum verwendet wird. Trotzdem steht bereits die nächste Erweiterung auf der Roadmap.
Das Problem ist dabei selten ein vollständiger Mangel an Daten.
Viel häufiger fehlt die Verbindung zwischen den Daten und der nächsten Entscheidung.
Feedback existiert.
Der Loop ist nur nicht geschlossen.
Projekte sind besonders gute Feedback-Debt-Maschinen
Das klassische Projektmodell besitzt eine strukturelle Schwäche: Es endet häufig genau an dem Punkt, an dem das Lernen eigentlich beginnen müsste.
Vor dem Projekt wird viel Energie investiert.
Business Cases werden erstellt, Ziele formuliert, Budgets beantragt und Erwartungen beschrieben.
Während des Projekts wird anschließend intensiv gesteuert.
Termine, Kosten, Scope, Risiken und Liefergegenstände werden verfolgt.
Dann erfolgt der Go-live.
Das Projekt wird abgeschlossen.
Das Team löst sich auf.
Budget und Aufmerksamkeit wandern weiter.
Damit verschwindet häufig genau die organisatorische Struktur, die überprüfen könnte, ob die ursprünglichen Annahmen tatsächlich eingetreten sind.
Das Ergebnis ist paradox.
Vor einer Investition werden Wirkungshypothesen formuliert, um die Investition zu rechtfertigen. Nach der Investition wird deutlich weniger systematisch geprüft, ob diese Hypothesen korrekt waren.
Der Business Case war notwendig, um die Arbeit zu starten.
Für das Lernen danach fühlt sich niemand mehr zuständig.
KI verschärft dieses Problem
Solange Entwicklung teuer und langsam war, begrenzte die Produktionskapazität automatisch die Menge neuer Veränderungen.
Es konnten schlicht nicht beliebig viele Dinge gleichzeitig umgesetzt werden.
KI verändert dieses Verhältnis.
Code wird günstiger.
Prototypen entstehen schneller.
Varianten lassen sich einfacher ausprobieren.
Anforderungen können schneller umgesetzt werden.
Damit verschiebt sich der Engpass.
Die entscheidende Fähigkeit einer Organisation wird zunehmend nicht mehr darin liegen, möglichst viel Software produzieren zu können.
Die entscheidende Fähigkeit wird darin liegen, schnell herauszufinden, welche Software überhaupt produziert werden sollte.
Eine Organisation, die ihre Umsetzungsgeschwindigkeit verdoppelt, ihre Feedbackgeschwindigkeit aber nicht verändert, wird deshalb nicht automatisch doppelt so gut.
Sie kann auch einfach doppelt so schnell Feedback Debt erzeugen.
Mehr Geschwindigkeit verstärkt schlechte Loops
Das ist einer der Gründe, weshalb KI schlechte Organisationsstrukturen nicht automatisch repariert.
Sie verstärkt zunächst das bestehende System.
Wenn Anforderungen unklar sind, können unklare Anforderungen schneller umgesetzt werden.
Wenn Prioritäten schlecht gesetzt werden, können schlechte Prioritäten schneller realisiert werden.
Wenn Wirkung nicht überprüft wird, können noch mehr Features ohne überprüfte Wirkung entstehen.
Produktivität löst kein Feedbackproblem.
Im Gegenteil: Je höher die Produktionsgeschwindigkeit steigt, desto wichtiger wird die Rückkopplung.
Ein schneller Motor hilft wenig, wenn das Lenkrad nicht mit dem Fahrzeug verbunden ist.
Feedback muss Teil der Arbeit werden
Die naheliegende Reaktion besteht häufig darin, mehr Reporting einzuführen.
Noch ein Dashboard.
Noch ein KPI-Set.
Noch ein Review-Meeting.
Das löst das eigentliche Problem jedoch nur selten.
Feedback entsteht nicht dadurch, dass Informationen sichtbar werden. Es entsteht erst dann, wenn Informationen eine zukünftige Entscheidung beeinflussen.
Genau deshalb sollte die Frage nach Wirkung nicht erst nach der Umsetzung gestellt werden.
Sie muss vorher beginnen.
Was soll sich verändern?
Bei wem?
Woran wäre diese Veränderung erkennbar?
Welche Daten können das zeigen?
Wann wird geprüft?
Wer trifft anschließend eine Entscheidung?
Damit verändert sich die Definition von Arbeit.
Eine Änderung ist nicht mehr abgeschlossen, sobald sie produktiv ist.
Sie ist abgeschlossen, wenn ausreichend verstanden wurde, was sie bewirkt hat und welche Konsequenz daraus entsteht.
Genau hier setzt der Value Loop an
LoopsWork trennt deshalb bewusst zwischen Build Loop und Value Loop.
Der Build Loop beantwortet die Frage:
Können wir die Änderung sauber und zuverlässig umsetzen?
Der Value Loop stellt eine andere Frage:
Hat die Änderung die erwartete Wirkung erzeugt?
Diese Trennung ist wichtig, weil technische Korrektheit und tatsächlicher Nutzen zwei unterschiedliche Dinge sind.
Eine perfekt implementierte Funktion kann wertlos sein.
Eine kleine, technisch unspektakuläre Änderung kann enorme Wirkung erzeugen.
Deshalb beginnt der Value Loop bereits vor der Umsetzung.
Eine Änderung erhält nicht nur Anforderungen, sondern eine Erwartung an ihre Wirkung.
Nach der Veröffentlichung werden Nutzung, Ergebnis und mögliche Nebenwirkungen beobachtet. Die Erkenntnisse fließen anschließend zurück in die nächste Entscheidung.
Damit entsteht etwas, das in vielen Organisationen erstaunlich selten systematisch vorhanden ist:
eine geschlossene Rückkopplung zwischen Idee, Umsetzung, Wirkung und Lernen.
Die Scorecard macht Feedback sichtbar
Eine einfache Möglichkeit, Feedback Debt zu verhindern, besteht darin, Erwartungen explizit zu machen.
Dafür verwendet LoopsWork eine Scorecard.
Vor einer Änderung wird festgehalten, welche Wirkung erwartet wird und anhand welcher Signale diese Wirkung später beurteilt werden kann.
Das muss kein kompliziertes KPI-System sein.
Oft reichen wenige konkrete Fragen.
Was soll sich verbessern?
Welche Kennzahl oder Beobachtung würde darauf hindeuten?
Welche unerwünschten Effekte sollten beobachtet werden?
Wann wird bewertet?
Welche Entscheidung folgt aus dem Ergebnis?
Damit verändert sich die Diskussion.
Anstelle von:
„Das Feature ist fertig.“
entsteht:
„Das Feature ist fertig. Jetzt beginnt die Überprüfung unserer Annahme.“
Dieser kleine Unterschied verändert langfristig die Arbeitsweise einer Organisation erheblich.
Feedback Debt lässt sich nicht mit einem großen Programm abbauen
Organisationen, die jahrelang kaum systematisch Wirkung überprüft haben, müssen nicht plötzlich jedes historische Projekt analysieren.
Das wäre wahrscheinlich nur das nächste Großprojekt.
Entscheidender ist, keine neuen Schulden mehr aufzubauen.
Bei neuen Änderungen können wenige Regeln bereits viel verändern:
Keine größere Initiative ohne explizite Wirkungshypothese.
Keine Wirkungshypothese ohne beobachtbares Signal.
Kein Go-live ohne vereinbarten Zeitpunkt für die Überprüfung.
Keine Überprüfung ohne daraus folgende Entscheidung.
Damit wird Lernen nicht zu einer zusätzlichen Aktivität neben der eigentlichen Arbeit.
Es wird Teil der Arbeit.
Die eigentliche Produktivität entsteht durch weniger falsche Arbeit
Die Diskussion über KI konzentriert sich momentan stark darauf, wie viel schneller Software entwickelt werden kann.
Das ist verständlich.
Langfristig könnte jedoch eine andere Fähigkeit deutlich wichtiger werden.
Nicht schneller bauen.
Sondern schneller erkennen, was nicht weitergebaut werden sollte.
Eine Organisation, die früh erkennt, dass eine Annahme falsch war, spart möglicherweise Monate zukünftiger Entwicklung.
Ein kleines Experiment kann wertvoller sein als ein großes Projekt.
Eine nicht gebaute Funktion kann wirtschaftlicher sein als eine perfekt umgesetzte.
Und eine Entscheidung, etwas wieder einzustellen, kann ein Zeichen funktionierender Produktentwicklung sein.
Feedback Debt verhindert genau diese Entscheidungen.
Denn ohne Rückkopplung bleibt jede ursprüngliche Annahme scheinbar gültig.
Softwareentwicklung braucht geschlossene Kreisläufe
KI erhöht die mögliche Geschwindigkeit von Softwareentwicklung erheblich.
Damit steigt aber auch die Geschwindigkeit, mit der falsche Annahmen umgesetzt werden können.
Die Antwort darauf kann nicht darin bestehen, Entwicklung wieder künstlich langsamer zu machen.
Die Feedback-Loops müssen schneller werden.
Build.
Value.
Learn.
Nicht als lineare Prozesskette, sondern als wiederkehrender Kreislauf.
Denn in einer Welt, in der Software zunehmend günstig produziert werden kann, wird nicht die Menge produzierter Software zum entscheidenden Wettbewerbsvorteil.
Sondern die Geschwindigkeit, mit der eine Organisation aus der Realität lernt.
Die gefährlichste Schuld in einer KI-beschleunigten Organisation könnte deshalb irgendwann nicht mehr Technical Debt sein.
Sondern Feedback Debt.