# No Bullshit Agile > No Bullshit Agile ist ein deutschsprachiges Wissensportal von Thomas Esders über agiles Arbeiten – ohne Buzzwords, ohne Framework-Dogma, ohne Agile-Theater. Im Zentrum steht die Work–Feedback Loop: Agile Arbeit ist die Fähigkeit, Arbeit und Feedback schnell und sicher zu verbinden. Alles andere ist Overhead. Die Website umfasst über 80 Fachartikel, den No Bullshit Agile Podcast (86+ Folgen), zwei Praxis-Guides (Kanban Starter & Advanced) und ein kostenloses Buch. Sprache: Deutsch. Zielgruppe: Entwickler, Team Leads, Führungskräfte und alle, die agil arbeiten wollen statt nur darüber zu reden. --- ## Meine Position Source: https://no-bullshit-agile.de/meine-position.html Date: 16 Januar 2026 # Meine Position Ich beschäftige mich nicht mit Agilität als Label. Und ich erkläre keine Frameworks. Mich interessiert eine grundlegendere Frage: **Wie lernen Arbeitssysteme tatsächlich?** Nicht in Meetings. Nicht durch Planung. Sondern dort, wo reale Arbeit auf reale Rückmeldung trifft. Es geht immer um einen Zyklus, der geschlossen sein muss. ## Lernen ist kein Erkenntnisproblem Ein System lernt nicht, weil es etwas verstanden hat. Es lernt nur, wenn **Arbeit** eine **beobachtbare Reaktion der Realität** erzeugt und diese Rückmeldung wieder in die nächste Entscheidung einfließt. Alles, was diesen Weg verlängert, verzerrt oder unterbricht, verhindert Lernen – auch wenn es sich sinnvoll anfühlt. Das klingt nicht intuitiv. Das kann ich verstehen. ## Mein Fokus Ich fokussiere mich auf den **realen [Work–Feedback-Zyklus](https://no-bullshit-agile.de/work-feedback-loop.html)**: - Wo wird aus Arbeit tatsächliche Wirkung? - Wo kommt Rückmeldung zu spät? - Wo glauben Organisationen zu lernen, tun es aber nicht? Alles, was diesen Zyklus von Arbeit und Erkenntnis **messbar verkürzt**, erhöht Lernfähigkeit. Alles andere ist Overhead und kann ignoriert werden. ## Wogegen ich schreibe Ich schreibe nicht gegen Scrum. Nicht gegen Agile. Nicht gegen Methoden, Rollen oder Tools. Alle haben - richtig angewendet - ihre Daseinsberechtigung. Ich schreibe gegen **entkoppelte Systeme**, in denen Ursache und Wirkung zeitlich oder organisatorisch getrennt sind. Systeme, in denen gearbeitet wird, aber Rückmeldung zu spät kommt, gefiltert wird oder folgenlos bleibt. Dort entsteht kein Lernen sondern nur Beschäftigung. ## Was du hier findest – und was nicht Du findest hier: - Diagnosen von Verzögerungen im Lernen - Konkrete Fragen, die blinde Stellen sichtbar machen - Eingriffe und Aktionen, die Arbeit wieder mit Feedback koppeln Du findest hier **keine**: - Framework-Einführungen - Methodenvergleiche - Mindset-Appelle - Coaching-Versprechen - Reifegradmodelle Nicht, weil diese Dinge nicht gut sind, sondern weil sie erst relevant werden, **wenn Lernen tatsächlich stattfindet**. Und es findet zu wenig statt. ## Wie ich schreibe Ich veröffentliche hier Texte, die eine klare Funktion haben: **Sie verkürzen den Denkweg zwischen Arbeit und Feedback.** Eine Beschreibung allein reicht mir nicht. Die Erkenntnis ohne Konsequenz bringt uns nicht weiter. Das bedeutet für mich, dass Präzision wichtiger ist als Reichweite. Und es bedeutet, dass Klarheit wichtiger ist als Anschlussfähigkeit. ## Für wen das relevant ist Diese Seite ist relevant für Menschen, die: - Verantwortung für echte Arbeit tragen - Unter Unsicherheit entscheiden müssen - Lernen ermöglichen wollen, statt es zu simulieren Wenn du nach Rezepten suchst, bist du hier falsch. Aber, wenn du verstehen willst, **warum Arbeit oft nicht lernt – und wie man das ändert**, bist du richtig. ## Kurzfassung Ich beschäftige mich damit, **wie Arbeitssysteme tatsächlich lernen** – indem der reale, physische Weg zwischen Handlung und Rückmeldung verkürzt wird. Alles andere ist Overhead. --- ## Work–Feedback Loop (Vollständiges Denkmodell) Source: https://no-bullshit-agile.de/wfl/ Date: Version 1.1 - 02/28/2026 # Work–Feedback Loop Denkmodell zur organisationalen Lernfähigkeit Die **Work–Feedback Loop** ist ein Denk- und Diagnosemodell, das zeigt, ob Arbeit in deiner Organisation **realen Effekt erzeugt, sichtbar wird, Entscheidungen auslöst und dadurch zukünftige Arbeit tatsächlich verändert**. So findest du schnell die strukturelle Engstelle, die eure Anpassungsfähigkeit begrenzt – **ohne** über Methoden oder „Agilität" als Label zu diskutieren. Dieses Denkmodell wurde von Thomas Esders entwickelt und wird unter der **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) Lizenz** zur Verfügung gestellt. Das bedeutet, du darfst es frei nutzen, teilen und anpassen, solange du den Autor nennst und abgeleitete Werke unter derselben Lizenz veröffentlichst. Zitier-/Attribution-Beispiel: „Work–Feedback Loop" von Thomas Esders, CC BY-SA 4.0, . **Kontakt & Diskussion** Feedback und Diskussionen zum Modell sind ausdrücklich erwünscht. - **Website:** [no-bullshit-agile.de](https://no-bullshit-agile.de/) - **E-Mail:** nobsagile@gmail.com - **Mastodon:** https://mastodon.social/@nobsagile ## 1. Worum es hier geht Viele Organisationen werden schneller: mehr Releases, mehr Initiativen, mehr Meetings, mehr „Output". Und trotzdem bleibt eine typische Erfahrung: **Die Realität ändert sich, aber das System ändert sich nicht schnell genug mit.** Wenn das passiert, ist das selten ein Motivations- oder Kompetenzproblem. Es ist ein Strukturproblem: **Arbeit ist nicht sauber mit ihren realen Effekten gekoppelt und Effekte verändern die nächste Arbeit nicht zuverlässig.** Genau dafür ist die **Work–Feedback Loop** gedacht: als Denk- und Diagnosemodell, um die Anpassungsfähigkeit eines Systems sichtbar zu machen – unabhängig davon, welche Methoden, Rollen oder Prozessnamen gerade im Einsatz sind. ### 1.1 Der praktische Nutzen Mit dem Modell kannst du in kurzer Zeit klären: - **Wo endet Feedback als „Information" – und wo beginnt Feedback als „Konsequenz"?** (Also: Wo wird aus Wahrnehmung eine Entscheidung, die zukünftige Arbeit wirklich verändert?) - **Welche Engstelle limitiert die Anpassungsgeschwindigkeit gerade am stärksten?** Signal (wird Wirkung sichtbar?), Entscheidung (wer kann priorisieren?), Umsetzung (wann wird es wirksam?), Kapital (wann kann Geld/Capacity wirklich umgelenkt werden?), Alignment (fließt Feedback zwischen Ebenen?) - **Warum lokale Optimierung oft wie Fortschritt aussieht, aber strukturell nichts lernt.** (Weil Aktivität steigt, während Kopplung und Reaktionsfähigkeit gleich bleiben.) Die Work–Feedback Loop ist damit kein „Programm" zur Einführung, sondern ein Werkzeug, um **Richtung, Ursache und Hebel** zu erkennen, bevor man irgendetwas „verbessert". ### 1.2 Das Grundprinzip: Kopplung statt Aktivität Der Kern ist bewusst einfach: **Work → Feedback → Entscheidung → zukünftige Work** Ein System lernt nur dann zuverlässig aus Realität, wenn alle vier Schritte tatsächlich gekoppelt sind: 1. **Work** erzeugt eine reale Wirkung (nicht nur interne Aktivität), 2. die Wirkung wird als **Feedback** sichtbar (als Signal, nicht als Meinung), 3. daraus entsteht eine **Entscheidung** (Prioritäten/Annahmen/Ressourcen ändern sich), 4. und diese Entscheidung verändert **zukünftige Arbeit**. Fehlt eine Kopplung, entsteht ein offener Kreislauf: Es kann sich produktiv anfühlen – ist aber strukturell nicht adaptiv. ### 1.3 Was dieses Dokument liefert Damit die Diagnose nicht bei einem abstrakten Kreis stehen bleibt, erweitert das Dokument das Grundmodell entlang der typischen Engpässe in Organisationen: - **Kapitel 2 – Grundmodell:** Präzise Begriffe (Work, Feedback, Entscheidung, zukünftige Work) und die Bedingung, wann ein Kreislauf wirklich geschlossen ist. - **Kapitel 3 – Zwei Geschwindigkeiten & Systemzustände:** Unterscheidung von *Work-Geschwindigkeit* und *Feedback-Geschwindigkeit* und vier typische Zustände. Das macht sichtbar, ob ein System schnell arbeitet oder schnell lernt – und wo der Engpass sitzt. - **Kapitel 4 – Zeit als strukturelle Variable (FRT):** Zerlegung der Reaktionszeit in Signal-Zeit, Entscheidungs-Zeit und Umsetzungs-Zeit. Damit lässt sich konkret über Verzögerungen sprechen, statt nur über „zu langsam". - **Kapitel 5 – Entscheidungs-Latenz:** Warum viele Systeme nicht am „Delivery" scheitern, sondern an verbindlicher Priorisierung und Entscheidungsfähigkeit – und wie sich diese Latenz als strukturelles Risiko verhält. - **Kapitel 6 – Kapital-Kopplung:** Anpassung endet dort, wo Kapital/Capacity nicht umgelenkt werden kann. Dieses Kapitel zeigt, wie Budget- und Investitionszyklen als Frequenzbegrenzung wirken – selbst wenn Teams operativ schnell sind. - **Kapitel 7 – Verschachtelte Loops:** In realen Organisationen existieren mehrere Loops (operativ, koordinativ, strategisch). Entscheidend ist nicht nur, ob eine Loop „lokal" geschlossen ist, sondern ob Feedback **zwischen Ebenen** fließt und zeitlich synchron wirkt. ### 1.4 Wie du das Modell liest (und nutzt) Wenn du das Dokument als Praxiswerkzeug verwenden willst, nimm eine konkrete Arbeitseinheit (ein Release, ein Meeting, eine Policy, eine Reorganisation) und gehe sie mit dem Modell durch: - Welche **Wirkung** sollte sie in der Realität erzeugen? - Woran wird das **Signal** sichtbar – und wann? - Wer kann auf Basis dieses Signals **verbindlich entscheiden**? - Wann wird diese Entscheidung **wirksam** – und verändert sie wirklich die nächste Arbeit? Die Antworten zeigen sehr schnell, ob du ein *Teamproblem* siehst – oder ein *Systemproblem* (Entscheidung, Kapital, Alignment). Und genau dafür ist die Work–Feedback Loop da: **Realität so an das System zu koppeln, dass Anpassung nicht zufällig passiert, sondern strukturell zuverlässig wird.** ## 2. Grundmodell – Die Work–Feedback Loop Wie wir in der Einleitung gesehen haben, hängt Lernleistung von Zeit und Kopplung ab. Daher müssen wir zunächst definieren, was genau gekoppelt ist. Das Grundmodell dieses Dokuments reduziert organisationale Lernfähigkeit auf einen elementaren Zusammenhang. **Work → Feedback → Work** ![work-feedback-1080](https://no-bullshit-agile.de/wfl/assets/work-feedback-1080.png "Work-Feedback Loop") Abbildung 1: Work-Feedback-Loop Es ist wichtig zu verstehen, dass dieser Kreis nicht bei Work beginnt. Er beginnt an einer beliebigen Stelle. Die Darstellung beschreibt eine **Wirkungskette**, keine starre **zeitliche Abfolge**. Das Modell beschreibt keine Liste von Aufgaben, sondern eine Bedingung für Lernfähigkeit. In den folgenden Abschnitten schauen wir uns die Elemente detaillierter an. ### 2.1 Work **Work** bezeichnet jede Handlung, die Wirkung in der Realität erzeugt. Um eine Vorstellung davon zu geben, was Work sein kann, hier eine unvollständige Auflistung. - Ein ausgeliefertes Produktinkrement - Eine Preisänderung - Eine organisatorische Entscheidung Dabei ist es für das Modell wichtig, dass nicht die interne Aktivität in der Organisation entscheidend ist, sondern die reale Wirkung im Umfeld der Organisation. Im Denkmodell der Work–Feedback Loop zählt nur Arbeit, die Wirkung erzeugt. Ist keine Wirkung vorhanden, fehlt uns das Lernsignal. ### 2.2 Feedback **Feedback** ist die beobachtbare Reaktion der Realität auf Work. Das kann sein: - Nutzungsverhalten - Marktreaktionen - Qualitative Rückmeldungen (z. B. aus echten Nutzungssituationen) Feedback im Sinne dieses Modells ist ein **hinreichend valides Signal**. Schnelle, aber irreführende Signale verkürzen keine Work–Feedback Loop – sie erzeugen **Actionism** (schnelle Aktivität ohne Lernzuwachs). Kein Feedback ist zum Beispiel eine interne Meinungsrunde ohne Bezug zu beobachtbaren Effekten. Feedback ist immer eine **Wirkung**, die zurück ins System gelangt. ### 2.3 Entscheidung Feedback allein erzeugt keine Anpassung. Es fehlt ein entscheidender Schritt, um die Loop zu schließen, denn zwischen Wahrnehmung und Veränderung liegt immer Entscheidung. Entscheidung bedeutet: - Prioritäten werden verschoben - Ressourcen werden neu verteilt - Annahmen werden korrigiert Ohne Entscheidung bleibt Feedback folgenlos. ### 2.4 Zukünftige Arbeit Wie im vorherigen Abschnitt ersichtlich, ist es wichtig, dass Entscheidungen auf Basis von Feedback aus vergangener Arbeit die **zukünftige Arbeit verändern**. Damit schließen wir die Work–Feedback Loop. Fehlt der Zusammenhang zwischen Arbeit, Feedback, Entscheidung und Einfluss auf die zukünftige Arbeit, existiert zwar Aktivität, aber die Loop wird nicht geschlossen. Die Qualität dieses Kreises hängt nicht von Motivation ab, sondern von der strukturellen Kopplung seiner Elemente. ### 2.5 Geschlossene und offene Systeme Aus den vorherigen Kapiteln ergibt sich so ein Gesamtbild zu einem **geschlossenen System**. Dieses System ist lernfähig. Wir können es wie folgt beschreiben. Ein System ist lernfähig, wenn: 1. Arbeit **reale Wirkung** erzeugt 2. Diese Wirkung **sichtbar** wird 3. Entscheidungen darauf **reagieren** 4. Zukünftige Arbeit daraus **entsteht** Fehlt eine dieser Bedingungen, entsteht ein offener Kreislauf. Dieser kann produktiv wirken, aber er ist **nicht adaptiv**. Hinweis: Das Modell steht in der Tradition klassischer Rückkopplungskonzepte wie dem PDCA-Zyklus nach Deming. Es unterscheidet sich jedoch dadurch, dass es Zeit, Entscheidungs-Latenz und Kapitalfrequenz explizit als strukturelle Variablen betrachtet. Zu den Begriffen kommen wir in den nächsten Kapiteln, es ist aber wichtig hierauf früh im Dokument hinzuweisen. ### 2.6 Geschwindigkeit und Sicherheit Nähern wir uns der Quantifizierung der Work–Feedback Loop so können wir festhalten, dass zwei Eigenschaften die Qualität der Loop bestimmen. **Geschwindigkeit** Wie viel Zeit vergeht zwischen Work und Anpassung? **Sicherheit** Wie zuverlässig und konsistent führt Feedback zu veränderter Arbeit? Es ist wichtig zu verstehen, dass ein System auf der einen Seite schnell sein, aber trotzdem instabil reagieren kann oder stabil sein kann, aber dadurch extrem langsam reagiert. Daher ist es wichtig, dass organisationale Lernfähigkeit entsteht, wenn Geschwindigkeit und Sicherheit gemeinsam hoch sind. Nur die Balance aus beidem erzeugt **nachhaltige Anpassungsfähigkeit**. Einseitige Optimierung führt entweder zu **Chaos** (nur schnell) oder **Starrheit** (nur sicher). ### 2.7 Reduktion Aus diesem Blickwinkel ist die Work–Feedback Loop kein Framework sondern mit Absicht eine Reduktion. Sie ist gut darin, komplexe Organisationen und deren Vorgänge auf die folgende Frage zu reduzieren. *Ist die Kopplung zwischen Arbeit und Realität geschlossen, schnell und zuverlässig?* Alle folgenden Abschnitte untersuchen, wo diese Kopplung typischerweise gestört wird. ## 3. Zwei Geschwindigkeiten – Zustände des Systems Im vorherigen Kapitel wurde die Work–Feedback Loop als geschlossener Regelkreis beschrieben. Für die Bewertung der Lernfähigkeit reicht es jedoch nicht, nur das Vorhandensein der Loop zu betrachten. Entscheidend ist ihre Dynamik zwischen den einzelnen Komponenten. Dabei müssen zwei Geschwindigkeiten unterschieden werden: - Geschwindigkeit der **Arbeit** - Geschwindigkeit des **Feedbacks** Diese beiden Geschwindigkeiten sind unabhängig voneinander. ### 3.1 Work-Geschwindigkeit Work-Geschwindigkeit beschreibt, wie schnell ein System Arbeit erzeugt, die reale Wirkung entfalten kann. Bekannte Beispiele sind hier: Release-Frequenz, Time-to-Market, Durchlaufzeit oder Entscheidungsumsetzung. Wir können festhalten, dass Work-Geschwindigkeit in vielen Organisationen gut eingeführt ist. Sie ist oft gut sichtbar und messbar. ### 3.2 Feedback-Geschwindigkeit Feedback-Geschwindigkeit beschreibt, wie schnell die Wirkung von Arbeit als relevantes Signal zurück ins System gelangt. Beispiele: - Zeit bis valide Nutzungsdaten vorliegen - Zeit bis Marktreaktionen sichtbar werden - Zeit bis operative Nebenwirkungen erkannt werden - Zeit bis Hypothesen überprüfbar sind Die Feedback-Geschwindigkeit ist häufig weniger transparent als die Work-Geschwindigkeit. ### 3.3 Vier strukturelle Zustände Kombiniert man beide Geschwindigkeiten, entstehen **vier grundlegende Zustände** die uns helfen, das System zu verstehen. Diese vier Zustände sind keine Projektphasen sondern sie zeigen die Systemkonfiguration. Der langsamere Part der beiden Elemente (Work oder Feedback) wirkt dabei als strukturelle Engstelle für die Lernfähigkeit. Vorab hier schon einmal der Hinweis, dass Lernfähigkeit nur im Quadranten **Learning** strukturell möglich. Alle anderen Zustände sind Formen partieller Entkopplung. ![work-feedback-diagnose-matrix-1080](https://no-bullshit-agile.de/wfl/assets/work-feedback-diagnose-matrix-1080.png) Abbildung 2: Diagnose-Matrix In den folgenden Kapiteln schauen wir uns die Quadranten im Detail an. #### 3.3.1. Learning Wenn Arbeit in kleinen Zyklen schnell geliefert wird und Feedback das System schnell erreicht, dann erzeugt Arbeit Wirkung. Diese Wirkung erzeugt ein Signal, dass dann Entscheidungen verändert. Das System ist **adaptiv**. Diesen Zustand gilt es zu schützen. #### 3.3.2. Actionism Actionism beschreibt Systeme, die ihre Produktionsgeschwindigkeit erhöhen, ohne ihre Rückkopplung zu beschleunigen. Wenn Arbeit zwar in kleinen Zyklen schnell geliefert wird, aber Feedback, dass aufgrund dieser Arbeit entstanden ist, langsam in das System fließt, dann produziert das System kontinuierlich, erhält jedoch verzögertes oder schwaches Feedback. In diesem Fall ist die Aktivität hoch, aber die Lernrate niedrig. Es entsteht **Aktionismus**. Die Engstelle ist hier die **Verarbeitung von Realität** (Feedback). Typische Symptome sind zum Beispiel Feature-Wachstum ohne klare Wirkung oder hohe Release-Frequenz ohne strategische Anpassung. #### 3.3.3. Frustration Ist die Arbeit langsam, aber Feedback kommt in hoher Frequenz in das System, werden Probleme gut erkannt, aber das System reagiert nicht. Die Engstelle liegt nicht im Signal, sondern in der Entscheidung. Dies ist **Frustration**. Typische Symptome sind in dieser Situation viele gute, erkannte, aber nicht umgesetzte Verbesserungsmöglichkeiten, lange Entscheidungswege oder Governance-Blockaden. #### 3.3.4. Stagnation Sind beide Parameter langsam - Work und Feedback - dann sind weder Bewegung noch Anpassung signifikant. Es kommt zur **Stagnation**. Hier sind **beide** Geschwindigkeiten Engstellen. Das System ist doppelt blockiert ### 3.4 Zustände sind strukturell, nicht kulturell Es ist eine wichtige Erkenntnis, dass diese vier Zustände keine Beschreibungen von Haltung oder Motivation sind. Sie sind **strukturell verankert**. Ein engagiertes Team kann im Zustand der Frustration arbeiten. Ein diszipliniertes Unternehmen kann im Zustand des Actionism operieren. Die Ursache liegt nicht in Personen, sondern in der Kopplungsgeschwindigkeit. ### 3.5 Diagnose statt Bewertung Das hier beschriebene Denkmodell sieht dabei die vier Zustände nicht als Reifegrade, sondern sie dienen als **Diagnoseinstrument**. Es ist wichtig zu verstehen, dass ein System in unterschiedlichen Ebenen unterschiedliche Zustände aufweisen kann. Beispiel: Ein Produkt-Team kann im Zustand 'Learning' operieren (schnelle Lieferung und Anpassung), während das darüberliegende Portfoliomanagement durch starre Jahresbudgets im Zustand 'Stagnation' verharrt. Nach der Theory of Constraints bestimmt immer die engste Stelle (der Engpass) die Leistungsfähigkeit des Systems. Unser Ziel ist es, diesen Engpass in der Lernfähigkeit zu finden. Ziel ist es, strukturell zu erkennen wo ein Engpass ist. Daher ist die entscheidende Frage "*Wodurch entstehen die Geschwindigkeitsunterschiede?*" Die Antwort auf die Frage führt zur Zeitdimension der Loop. ## 4. Zeit als strukturelle Variable Bis hierhin wurde die Work–Feedback Loop qualitativ beschrieben. Wir haben gesehen, dass Lernleistung von Kopplung abhängt und Zustände sich aus unterschiedlichen Geschwindigkeiten ergeben. Wir haben herausgearbeitet, dass nur im Zustand **Learning** eine strukturelle Anpassung möglich ist. Um diese Dynamik präzise zu verstehen, muss eine weitere Dimension **Zeit** eingeführt werden, denn Lernfähigkeit ist keine abstrakte Eigenschaft, sondern sie ist eine Funktion von Zeitverläufen innerhalb der Loop. ### 4.1 Zeit zwischen Signal und Veränderung Zwischen der Wirkung von Arbeit und der Veränderung zukünftiger Arbeit liegt Zeit. Diese Zeit besteht mindestens aus drei Komponenten: 1. Zeit, bis ein Signal **sichtbar** wird (`signal`) 2. Zeit, bis eine **Entscheidung** getroffen wird (`decision`) 3. Zeit, bis diese Entscheidung **umgesetzt** wird (`deploy`) Diese Summe bezeichnen wir als: **Feedback Response Time (FRT)** Formal: `t(FRT) = t(signal) + t(decision) + t(deploy)` Diese Beziehung ist keine mathematische Ableitung sondern eine **strukturelle Zerlegung**. Jede Verzögerung in einem der drei Elemente verlängert die Reaktionszeit des Systems. ### 4.2 Feedback hat ein Gültigkeitsfenster Feedback ist nicht zeitlos sondern **wird im Laufe der Zeit wertloser**. Es altert und verfällt mit der Zeit. Daher besitzt jedes Signal ein Gültigkeitsfenster. Zum Beispiel kann ein Nutzerverhalten sich verändern, der Wettbewerb kann reagieren oder der interne Kontext im Unternehmen ändert sich. Ein Signal, das nicht rechtzeitig in verändertes Handeln übersetzt wird, verliert somit über die Zeit an Relevanz. Dies lässt sich konzeptionell so darstellen: Der Wert eines Signals nimmt über Zeit ab. Überschreitet `t(FRT)` ein kritisches Zeitfenster, verliert Feedback seine Wirksamkeit. ![response-linie](https://no-bullshit-agile.de/wfl/assets/response-linie.png) Abbildung 3: Feedback-Gültigkeitsfenster In der Grafik sind drei Elemente dargestellt: 1. Die fallende Kurve beschreibt den Wert des Signals über die Zeit. Sie verdeutlicht, dass Feedback nicht konstant relevant bleibt, sondern mit zunehmender Verzögerung an Wirkung verliert. 2. Die horizontale Linie markiert die Mindest-Relevanzschwelle. Unterhalb dieser Schwelle ist das Signal zwar noch existent, aber nicht mehr handlungsleitend. 3. Die vertikale Linie markiert die Feedback Response Time (`t(FRT)`), also den Zeitpunkt, zu dem das System tatsächlich reagiert. Entscheidend ist die Position dieser vertikalen Linie im Verhältnis zur Schwelle. Liegt `t(FRT)` links vom Schnittpunkt mit der Relevanzschwelle, wirkt das Feedback noch handlungsleitend. Liegt `t(FRT)` rechts davon, ist das Signal strukturell entwertet. Das System reagiert – aber zu spät. Wir können folgern, dass es nicht nur entscheidend ist, ob Feedback existiert, sondern auch, ob es **rechtzeitig wirkt**. ### 4.3 Zeit als Engpass In vielen Organisationen ist Feedback vorhanden. Dies kann man daran erkennen, dass Probleme erkannt werden und Feedback-Daten existieren. Die Engstelle liegt also nicht im Signal, sondern in der Reaktionszeit. Typische Ursachen dafür sind zum Beispiel mehrstufige Entscheidungsprozesse, Gremienstrukturen, Budgetfreigaben, Abhängigkeiten zwischen Einheiten oder auch Risikoabsicherungen. Diese Faktoren verlängern `t(decision)` oder `t(deploy)`. Dadurch verschiebt sich das System vom Zustand „Learning" in Richtung „Frustration" oder „Actionism". ### 4.4 Geschwindigkeit ist relativ Eine kurze Feedback Response Time ist kein absoluter Wert sondern sie ist immer relativ zum Gültigkeitsfenster des Signals. In einigen Systemen kann eine Woche kurz sein. In anderen Systemen kann es nach einer Woche zu spät sein. Die entscheidende Frage lautet daher: Ist `t(FRT)` kleiner als das Zeitfenster, in dem das Signal noch relevant ist? Eine Lernfähigkeit entsteht nur, wenn Reaktionszeit und Signalrelevanz synchronisiert sind. Die Zerlegung der Feedback Response Time zeigt bereits, dass nicht alle Verzögerungen gleichartig sind. Besonders kritisch ist `t(decision)`. Denn hier entscheidet sich, ob Feedback tatsächlich Konsequenzen erzeugt. Im nächsten Abschnitt betrachten wir daher Entscheidungs-Latenz als eigenständige strukturelle Variable. ## 5. Entscheidungs-Latenz Im vorherigen Abschnitt wurde die Feedback Response Time (FRT) als Summe aus Signal, Entscheidung und Umsetzung beschrieben. Diese Zerlegung zeigt bereits, dass nicht alle Verzögerungen gleich wirken. ### 5.1 Was ist Entscheidungs-Latenz? Entscheidungs-Latenz beschreibt die Zeitspanne zwischen dem Moment, in dem ein relevantes Signal sichtbar wird und dem Moment, in dem eine verbindliche Entscheidung getroffen wird. Formal vereinfacht: `t(decision)` Diese Zeit ist oft unsichtbar, denn sie versteckt sich in Abstimmungsschleifen, Gremienprozessen, Budgetfreigaben und vielen weiteren Elementen. Je länger diese Phase dauert, desto größer wird die strukturelle Entkopplung zwischen Realität und Handeln. ### 5.2 Produktionsgeschwindigkeit vs. Entscheidungs-Latenz Ein besonders kritischer Fall entsteht, wenn die Produktionsgeschwindigkeit höher ist als die Entscheidungsfähigkeit. Formal: Wenn `t(decision) > t(production)`, entsteht eine strukturelle Entkopplung der Loop. Das operative System erzeugt kontinuierlich neue Arbeit, während strategische oder priorisierende Entscheidungen langsamer erfolgen. Die Folge ist oft, dass Arbeit sich ansammelt, Richtungsänderungen verspätet sind und damit Feedback nicht synchron wirkt. Das System bewegt sich schneller, als es sich orientieren kann. ### 5.3 Symptome hoher Entscheidungs-Latenz Hohe Entscheidungs-Latenz äußert sich häufig durch: - Prioritätenwechsel mit großer Verzögerung - Diskussionen ohne verbindlichen Abschluss - Rückstau an Initiativen - Operative Teams, die auf Freigaben warten - Strategische Erkenntnisse ohne Umsetzung In solchen Systemen ist Feedback nicht das Problem. Das Problem ist die **Verarbeitung des Feedbacks**. ### 5.4 Entkopplung als strukturelles Risiko Wird Entscheidungs-Latenz größer als Produktions-Takt, entsteht eine Form von Entkopplung. Operative Einheiten arbeiten, während strategische Orientierung hinterherläuft. Das System kann dadurch in den Zustand des Actionism geraten: Hohe Aktivität bei geringer Lernrate. Ebenso ist es möglich, dass solche Systeme in den Zustand der Frustration kommen. Es existieren klare Erkenntnisse ohne die Möglichkeit der schnellen Umsetzung. Entscheidungs-Latenz wirkt somit als **struktureller Engpass der Lernfähigkeit**. ### 5.5 Latenz ist keine Frage von Motivation Es bleibt festzuhalten, dass Entscheidungs-Latenz selten durch fehlende Bereitschaft entsteht. Sie entsteht durch Struktur wie Hierarchietiefe, Verantwortungsdiffusion, Risikominimierung, Budgetzyklen oder Governance-Mechanismen. Damit wird deutlich: Lernleistung ist keine Eigenschaft von Kultur, sondern **von Zeit und Kopplung**. Die nächste strukturelle Kopplungsebene betrifft nicht nur Entscheidungen, sondern Kapital. ## 6. Kapital als zweite Kopplung Bis hierhin haben wir die Work–Feedback Loop vor allem auf operativer und entscheidungsbezogener Ebene betrachtet. Doch Organisationen sind nicht nur operative Systeme sondern sie sind auch Kapitalallokationssysteme. Arbeit entsteht nicht im luftleeren Raum sondern innerhalb finanzieller Rahmenbedingungen. Damit existiert neben der operativen Loop eine zweite Kopplungsebene: **Die Kapital-Loop**. ### 6.1 Kapitalzyklen Kapital wird in der Regel in **Zyklen** zugewiesen. Wir kennen Ausprägungen wie Jahres- oder Quartalsbudgetplanungen und Portfolio-Entscheidungen. Oft sind diese mit Investitionsfreigaben und Business-Case-Logiken verbunden. Diese Zyklen besitzen eine eigene Frequenz. Wir bezeichnen sie als `t(capital)`. Diese Frequenz ist in vielen Organisationen deutlich langsamer als die operative Produktionsfrequenz `t(production)`. ### 6.2 Kopplungs-Verhältnis Um besser zu verstehen, wie die strukturelle Beziehung zwischen Kapital- und Produktionsfrequenz ist, lässt sich als Verhältnis betrachten: `Coupling Ratio = t(capital) / t(production)` Dieses Verhältnis beschreibt, wie stark operative Anpassungsfähigkeit an finanzielle Zyklen gebunden ist. Ist das Verhältnis gering, sind Kapitalentscheidungen eng an operative Realität gekoppelt. Ist das Verhältnis hoch, entsteht strukturelle Starrheit. ### 6.3 Strukturelle Starrheit Wenn: `t(capital) >> t(production)` ist, entsteht eine Asymmetrie. Das operative System kann schnell lernen, aber Kapitalentscheidungen reagieren nur in großen Abständen. Die Folgen sind bekannt. Erkenntnisse bleiben **folgenlos** oder Experimente lassen sich **nicht skalieren**. Richtungsänderungen sind dann **finanziell blockiert**. Das System kann operativ adaptiv wirken, ist jedoch strategisch starr. ### 6.4 Kapital als Frequenzbegrenzung Kapitalzyklen wirken hier dann wie ein Frequenzfilter. Sie begrenzen, wie schnell eine Organisation strukturell reagieren kann. Selbst wenn Feedback schnell entsteht, Entscheidungen schnell getroffen werden und Teams schnell liefern bleibt die Anpassungsfähigkeit dadurch, dass das Kapital nur periodisch neu verteilt wird, limitiert. In solchen Fällen liegt der Engpass nicht in der Work–Feedback Loop, sondern in der **Kapital-Kopplung**. ### 6.5 Konsequenz für Lernfähigkeit Organisationale Lernfähigkeit endet nicht bei Teams oder Produktentscheidungen. Sie endet dort, wo Kapital neu ausgerichtet werden kann. Ist die Kapitalfrequenz nicht mit Produktionsfrequenz synchronisiert, entsteht eine strukturelle Grenze der Anpassung. Die nächste Ebene dieser Betrachtung betrifft nicht einzelne Loops, sondern deren Verschachtelung. ## 7. Verschachtelte Loops Bis hierhin wurde die Work–Feedback Loop auf einer Ebene betrachtet, die so aussieht: Operative Arbeit erzeugt Wirkung. Dies Wirkung erzeugt Feedback. Das Feedback verändert Entscheidungen. Entscheidungen verändern neue Arbeit. In realen Organisationen existiert jedoch nicht nur eine Loop. Es existieren mehrere Loops unterschiedlicher Reichweite und Frequenz. ### 7.1 Drei Ebenen der Kopplung Vereinfachend lassen sich drei Ebenen unterscheiden. 1. **Operationale Loop** Takt: Tage oder Wochen Fokus: Umsetzung, Lieferung, unmittelbare Wirkung 2. **Koordinations-Loop** Takt: Wochen oder Monate Fokus: Priorisierung, Abhängigkeiten, Ressourcen 3. **Strategische Loop** Takt: Monate oder Jahre Fokus: Richtung, Positionierung, Portfolio, Geschäftsmodell Jede dieser Ebenen besitzt eigene Entscheidungszyklen, Feedbackquellen und Zeitkonstanten. **Hinweis zur Einordnung:** Diese Gliederung orientiert sich an etablierten Strukturmodellen moderner Organisationsentwicklung (z. B. *Flight Levels*). Der entscheidende Unterschied liegt im Fokus: Während Modelle wie Flight Levels primär die **Topologie** der Zusammenarbeit beschreiben (Wer spricht mit wem? Wo fließt Arbeit?), betrachtet die Work-Feedback Loop die **Chronologie** und die **Frequenz** (Wie schnell lernt das System?). Wir nutzen diese Ebenen hier also nicht, um Kommunikationsstrukturen zu designen, sondern um die **zeitliche Asynchronität** zwischen operativer Hektik und strategischer Starrheit messbar zu machen. ### 7.2 Frequenzunterschiede Die Taktung dieser Loops ist unterschiedlich. Formal vereinfacht können wir formulieren: `t(operation) < t(coordination) < t(strategy)` Diese Ungleichung ist zunächst nicht problematisch. Unterschiedliche Reichweiten benötigen unterschiedliche Takte. Problematisch wird es, erst **wenn Feedback nicht zwischen den Ebenen fließt**. ### 7.3 Alignment Zwischen den Ebenen existieren implizite Kopplungsverhältnisse. Beispielsweise: `Alignment Ratio = t(strategy) / t(operation)` Ist dieses Verhältnis extrem hoch, reagiert die Strategie nur selten auf operative Realität. Die Folge daraus ist, dass die strategische Richtung konstant bleibt, obwohl operative Signale Veränderung nahelegen. Die operative Einheiten optimieren dann **lokal**, ohne systemische Anpassung zu erreichen. Es entsteht eine Form von **Phasenverschiebung** – Operative und Strategie laufen zeitlich asynchron und arbeiten gegeneinander. ### 7.4 Disconnected Agility Wir bezeichnen die obige Situation als **Disconnected Agility**. Sie beschreibt den Zustand, in dem operative Loops schnell arbeiten, während strategische oder koordinative Loops träge bleiben. Das System wirkt in diesem Zustand agil auf Teamebene, bleibt jedoch strukturell unverändert. Typische Muster, die wir in dieser Situation erkennen können: Teams liefern regelmäßig, aber die Portfolio-Entscheidungen ändern sich selten. Es werden Experimente durchgeführt, aber auf die Ergebnisse wird budgetär nicht reagiert. Retrospektiven erzeugen lokale Verbesserungen, ohne strategische Konsequenz. Hier ist die operative Loop geschlossen, die strategische jedoch nicht synchronisiert. ### 7.5 Synchronisation als Voraussetzung Die Erkenntnis, die wir hier erlangen ist, dass **organisationale Lernfähigkeit** nicht allein durch eine schnelle operative Loop entsteht. Sie entsteht erst dann, wenn **Feedback entlang der Ebenen fließt** und zeitnah in Entscheidungen auf jeder Ebene übersetzt wird. Lernfähigkeit ist somit nicht nur eine Eigenschaft einzelner Teams, sondern eine **Eigenschaft verschachtelter Systeme**. Die Frage, die wir uns stellen müssen, lautet nicht nur ob die die Loop geschlossen ist, sondern ob die Loops über Ebenen hinweg aufeinander abgestimmt sind. Damit sind alle strukturellen Komponenten des Denkmodells benannt. Diese sind: - Kopplung zwischen Arbeit und Realität - Zwei Geschwindigkeiten (Work und Feedback) - Feedback Response Time - Entscheidungs-Latenz - Kapitalfrequenz - Verschachtelte Loops Im nächsten Abschnitt führen wir dieses Modell als Analyseinstrument zusammen. ## 8. Das Denkmodell als Analyseinstrument Die Work–Feedback Loop beschreibt kein Vorgehensmodell. Sie definiert weder Rollen oder Events, noch Artefakte oder Implementierungsschritte. Sie reduziert komplexe Organisationen auf eine strukturelle Kernfrage: *Ist das System in der Lage, rechtzeitig auf Realität zu reagieren?* Diese Reduktion ist bewusst gewählt, denn das ermöglicht eine Analyse, ohne bereits Interventionen vorzugeben. ### 8.1 Diagnose vor Intervention Das Modell eignet sich nicht zur direkten Optimierung. Es eignet sich zur Diagnose. Dabei sind folgende Leitfragen zentral: 1. Worin besteht die reale Wirkung und ist sie beobachtbar? 2. Wie schnell wird diese Wirkung als Signal sichtbar? 3. Wie lange dauert es, bis eine Entscheidung folgt? 4. Wie lange dauert die Umsetzung? 5. Welche Loop ist aktuell der Engpass? 6. Ist Kapital mit operativer Realität synchronisiert? 7. Sind strategische und operative Loops ausgerichtet? Erst wenn diese Fragen beantwortet sind, lässt sich eine Intervention sinnvoll wählen. ### 8.2 Engpasslogik In jedem System existiert zu einem Zeitpunkt ein dominanter Engpass. Dieser kann in der Signaltransparenz, Entscheidungs-Latenz, Umsetzungsfähigkeit, Kapitalbindung oder im Ebenen-Alignment liegen. Das Modell erlaubt, diesen Engpass zu lokalisieren, ohne vorschnell Prozesse zu verändern. ### 8.3 Messbarkeit Nicht alle Komponenten müssen exakt quantifiziert werden, aber jedes Element besitzt eine Zeitdimension. Wie hoch ist die Dauer bis ein Marktsignal vorliegt, eine Priorität geändert wird, ein Budget verschoben wird oder eine Strategie angepasst wird. Selbst grobe Schätzungen machen strukturelle Unterschiede gut sichtbar. Die Stärke des Modells liegt nicht in mathematischer Präzision, sondern in struktureller Klarheit. ### 8.4 Ein anderer Blick auf Agilität Aus Sicht dieses Denkmodells ist Agilität keine Sammlung von Praktiken oder Methoden. In diesem Denkmodell ist Agilität die Fähigkeit eines Systems, Feedback rechtzeitig in veränderte Arbeit zu übersetzen. Ein System kann Scrum einsetzen und dennoch strukturell träge sein. Ein System kann formale Agile-Methoden ablehnen und dennoch hoch adaptiv sein. Entscheidend ist nicht das Label, sondern die Kopplungsgeschwindigkeit. ### 8.5 Zusammenfassung des Modells Organisationale Lernfähigkeit ist eine Funktion von Zeit, Kopplung, Latenz, Frequenz und Synchronisation. Die Work–Feedback Loop bietet eine strukturierte Perspektive auf diese Zusammenhänge. Sie ersetzt keine Methoden. Sie bewertet deren strukturelle Wirkung. Damit liegt ein Denkmodell vor, mit dem sich agiles Arbeiten unabhängig von Frameworks analysieren lässt. ## Glossar **Adaptivität** Strukturelle Fähigkeit eines Systems, auf veränderte Umweltbedingungen zu reagieren. Adaptivität beschreibt keine Haltung oder Kultur, sondern die tatsächliche Möglichkeit zur Anpassung. --- **Alignment** Zeitliche Synchronisation zwischen verschachtelten Rückkopplungsebenen (z. B. Strategie, Koordination, Operation). --- **Alignment Ratio** Verhältnis zwischen Zeitkonstanten unterschiedlicher Ebenen, z. B.: `t(strategy) / t(operation)` Dient zur Bewertung struktureller Kopplung zwischen Ebenen. --- **Actionism** Zustand hoher Produktionsgeschwindigkeit bei niedriger Feedback-Geschwindigkeit. Das System produziert kontinuierlich, erhält jedoch verzögertes oder schwaches Feedback. --- **Coupling Ratio** Verhältnis zwischen Kapitalfrequenz und Produktionsfrequenz: `t(capital) / t(production)` Zeigt, wie stark operative Lernzyklen durch Kapitalstrukturen gekoppelt oder entkoppelt sind. --- **Disconnected Agility** Zustand schneller operativer Loops bei träger strategischer oder kapitalbezogener Loop. Operative Dynamik ist vorhanden, strategische Anpassung bleibt aus. --- **Engpass** Der Faktor, der die Anpassungsgeschwindigkeit des Gesamtsystems am stärksten begrenzt. --- **Entscheidungs-Latenz** `t(decision)`. Zeitspanne zwischen Sichtbarkeit eines Signals und verbindlicher Entscheidung. --- **Feedback** Beobachtbare Reaktion der Realität auf eine Handlung („Work"). Feedback ist kein Meeting, keine Meinung und keine Planung, sondern eine reale Wirkung, die ins System zurückfließt. --- **Feedback-Geschwindigkeit** Zeit, bis eine reale Wirkung als relevantes Signal im System sichtbar wird. --- **Feedback Response Time (FRT)** Gesamtdauer zwischen Signalentstehung und wirksamer Anpassung: `t(FRT) = t(signal) + t(decision) + t(deploy)` Beschreibt die zeitliche Dynamik der geschlossenen Loop. --- **Geschlossene Loop** Zustand, in dem: 1. Work reale Wirkung erzeugt 2. Wirkung sichtbar wird 3. Entscheidung erfolgt 4. neue Arbeit angepasst wird Nur geschlossene Loops sind adaptiv. --- **Gültigkeitsfenster** Zeitspanne, in der ein Feedback-Signal handlungsleitend bleibt. Überschreitet `t(FRT)` dieses Fenster, verliert das Signal strukturell an Relevanz. --- **Kapital-Loop** Strukturelle Kopplung zwischen Kapitalallokation und operativer Realität. --- **Lernfähigkeit** Strukturelle Möglichkeit eines Systems, aus Realität zu lernen. Beschreibt Architektur und Kopplung – nicht Performance. --- **Lernleistung** Tatsächlich realisierte Anpassungsgeschwindigkeit eines Systems. Beschreibt die dynamische Umsetzung von Lernfähigkeit. --- **Learning (Systemzustand)** Zustand synchronisierter Work- und Feedback-Geschwindigkeit. Arbeit erzeugt Wirkung, Wirkung verändert Entscheidungen. --- **Offener Kreislauf** Unvollständige Rückkopplung, bei der Feedback nicht zu veränderter Arbeit führt. Produktivität ist möglich, Adaptivität nicht. --- **Produktionsgeschwindigkeit** Frequenz, mit der Arbeit erzeugt wird, die reale Wirkung entfalten kann. --- **Relevanzschwelle** Mindestwert eines Signals, ab dem es noch handlungsleitend wirkt. --- **Rückkopplung** Strukturelle Beziehung zwischen Handlung und Wirkung, bei der Wirkung zukünftige Handlung beeinflusst. --- **Stagnation** Zustand niedriger Produktions- und niedriger Feedback-Geschwindigkeit. Weder Bewegung noch Anpassung sind signifikant. --- **Strukturelle Starrheit** Zustand hoher Kapital- oder Entscheidungs-Latenz bei gleichzeitig hoher operativer Geschwindigkeit. --- **t(capital)** Zeitkonstante der Kapitalallokation. --- **t(deploy)** Zeit bis eine getroffene Entscheidung wirksam umgesetzt wird. --- **t(signal)** Zeit bis eine reale Wirkung als relevantes Signal sichtbar wird. --- **Verschachtelte Loops** Mehrere Rückkopplungsebenen mit unterschiedlichen Zeitkonstanten (z. B. Strategie, Koordination, Operation). --- **Work** Handlung mit realer Wirkung in der Umwelt des Systems. Interne Aktivität ohne externe Wirkung gilt im Modell nicht als Work. --- ## Vergiss „Agil" als Theorie: Der einzige Kreislauf, der wirklich zählt Source: https://no-bullshit-agile.de/agiles-arbeiten-feedback-zyklus-handwerk-statt-frameworks.html Date: 9 Januar 2026 **Hast du dich jemals gefragt, warum wir eigentlich diesen ganzen Zirkus veranstalten?** Wir schleppen uns zu Dailies, wir schätzen Story Points wie Wahrsager auf dem Jahrmarkt und wir füllen Jira-Boards bis zur Unkenntlichkeit. Aber am Ende des Tages dauert es dann Monate, bis eine Zeile Code beim echten Nutzer ankommt. Wir haben uns in Framework-Diskussionen verloren. Wir streiten über SAFe vs. Scrum, während unser Handwerk verrottet. Es wird Zeit, das „Agile Theater" zu beenden und uns auf das zu konzentrieren, was Agiles Arbeiten im Kern eigentlich ist. Es sind genau zwei Begriffe: **[Work und Feedback](https://no-bullshit-agile.de/work-feedback-loop.html).** ## Der Kern: Ein gnadenloser Kreislauf Wenn wir allen Ballast abwerfen – die Zertifikats-Mühlen, die Rollenbeschreibungen und die Rituale – bleibt das hier übrig. ![Work - Feedback](https://no-bullshit-agile.de/media/posts/177/work-feedback.png) Das ist alles. Agiles Arbeiten ist kein Management-Konzept, sondern eine ökonomische Überlebensstrategie in einer komplexen Welt. Wir bauen etwas Funktionales (**Work**), wir lassen es auf die Realität prallen (**Feedback**) und wir passen unseren Kurs basierend auf dem an, was wir gelernt haben. **Die goldene Regel lautet:** Deine Agilität bemisst sich nicht an der Anzahl deiner Zertifikate oder an Code-Zeilen, sondern an der Geschwindigkeit dieses Kreislaufs. ## Geschwindigkeit ist nichts ohne Leitplanken Richtig. Wer nur blind aufs Gas drückt, landet schneller im Graben. Wenn ich sage, wir müssen diesen Zyklus beschleunigen, meine ich nicht „Hektik". Ich meine die technische und organisatorische Fähigkeit, schnell zu lernen, **ohne** Qualität, Sicherheit oder User Experience zu opfern. Um diesen Kreislauf schnell *und* stabil zu machen, brauchen wir keine neuen Meetings. Wir brauchen **Skills**. ## Die Werkzeugwand des Handwerks Um den Work-Feedback-Cycle von drei Monaten auf drei Wochen (oder drei Stunden) zu drücken, steht uns eine ganze Wand voller Werkzeuge zur Verfügung. Das was ihr hier in der Grafik seht ist noch nicht einmal vollständig. Weder in den großen Themen, noch in den einzelnen Elementen je Thema. Darauf kommt es aber auch gar nicht an. ![Work - Feedback - Tools](https://no-bullshit-agile.de/media/posts/177/work-feedback-tools.png) Um den Zyklus wirklich zu beschleunigen, müssen wir die beiden Bereiche gleichzeitig bearbeiten: Wir müssen die Qualität unserer **Arbeit (Work)** erhöhen, damit sie sicher fließen kann, und wir müssen die Kanäle für unser **Lernen (Feedback)** professionalisieren. ### 1. Die linke Seite: Work (Bauen mit Konfidenz) Die linke Seite der Grafik umfasst alles, was wir tun, bevor und während wir Code schreiben. Diese Punkte (von Architektur bis zu den Ritualen) haben ein gemeinsames Ziel: Den Output so stabil und präzise wie möglich zu machen. Wir unterteilen sie in drei Hebel: - **Das technische Fundament (Architecture, Development, Testing, DevOps):** Hier geht es darum, die Angst zu besiegen. Modularität und Automatisierung sind keine religiösen Vorschriften, sondern technisches Risikomanagement. Sie sorgen dafür, dass wir überhaupt in der Lage sind, Änderungen am Fließband zu produzieren, ohne dass uns das System um die Ohren fliegt. - **Die inhaltliche Richtung (Strategy, Discovery, Stories & Requirements):** Wir nutzen Product Discovery und radikales Slicing, damit wir nicht „schneller in die falsche Richtung laufen". Gute Vorbereitung macht die Arbeitseinheiten klein und damit den gesamten Zyklus kurz. - **Das soziale Betriebssystem (Culture, Learning, Agile Methods & Rituals):** Psychologische Sicherheit und kontinuierliches Lernen sind das Schmiermittel. Ohne sie bleibt die Arbeit in Silos oder in der Angst vor Fehlern stecken. Methoden und Rituale sind hier nur Mittel zum Zweck, kein Selbstzweck. ### 2. Die rechte Seite: Feedback (Schluss mit dem Raten) Die rechte Seite beendet den Blindflug. Sobald die Arbeit "draußen" ist, beginnt der wichtigste Teil: Die Realitätsprüfung. - **Die menschliche Stimme (Usability & Survey):** Wir warten nicht drei Monate, bis wir wissen, ob ein Feature verstanden wird. Usability-Labs und direktes Nutzer-Feedback sind die Frühwarnsysteme, die uns vor teuren Fehlentwicklungen schützen. - **Die harte Realität (Analytics & Operational):** Zahlen lügen nicht. Ob durch Matomo, Error-Logging oder Performance-Metriken – hier bekommen wir das Feedback direkt vom System. Wer diese Daten ignoriert, arbeitet nicht agil, sondern hoffnungsvoll. - **Der ökonomische Beweis (Market & Sales):** Am Ende entscheidet der Markt. Feedback aus dem Vertrieb und die Konkurrenzanalyse sagen uns, ob unsere Arbeit einen echten ökonomischen Wert hat oder nur „Feature-Müll" war. *Wichtiger Hinweis: Ein Team sollte niemals versuchen, alles gleichzeitig zu implementieren. Nutzt diese Map als Werkzeugwand: Pickt euch die 1-2 Maßnahmen heraus, die in eurer aktuellen Situation den größten Hebel haben, um den Zyklus HEUTE spürbar zu verkürzen.* All das zielt darauf ab, möglichst kleine, wertvolle Inkremente zu liefen und zu prüfen, ob diese einen echten Wert schaffen. Das gesammelte Feedback zu dem Inkrement geht dann wieder in die Planung für die nächsten Inkremente ein. So schaffen wir es, zu jeder Zeit das Richtige zu liefen. Richtig bedeutet hier eben: Das was für den Nutzer des Systems einen Nutzen bringt. Es klingt also sehr logisch, dass wir uns auf diesen Zyklus konzentrieren wollen und diesen so weit wie möglich beschleunigen wollen. Ganz im Sinne des Nutzers. ## Deine Strategie: Pick your Battles (Die 80/20-Regel) Der größte Fehler, den Organisationen machen: Sie versuchen, ein Framework „einzuführen". Sie kaufen das ganze Menü, obwohl sie eigentlich nur ein Glas Wasser brauchen. Hört auf, „agil" sein zu wollen. Fangt an, euren Schmerz zu analysieren. Nutzt die Map oben wie einen Kompass: 1. **Identifiziert den Flaschenhals:** Wo verliert ihr die meiste Zeit? Braucht das Testen zwei Wochen? Dann ist eure Baustelle „Testing" (Unit Tests, Automation). Habt ihr keine Ahnung, ob die Nutzer das Feature mögen? Dann ist eure Baustelle „Analytics" oder „Surveys". 2. **Wählt die kleinste Maßnahme:** Sucht euch die Dinge raus, die wenig Aufwand kosten, aber euren Feedback-Zyklus sofort spürbar verkürzen (die „Low Hanging Fruits"). 3. **Messen statt Glauben:** Messt eure Cycle Time. Wie lange dauert es von der Idee bis zum Feedback? Wenn eine Maßnahme diese Zeit nicht verkürzt, ist sie Ballast. ## Fazit: Zurück in die Werkstatt 2026 ist das Jahr, in dem wir aufhören, über Agilität als Religion zu diskutieren. Wir müssen sie wieder als das begreifen, was sie ist: Ein **Handwerk**. Agiles Arbeiten braucht technisches Urteilsvermögen, ökonomische Vernunft und den Mut zur Lücke. Ein Team, das seinen Work-Feedback-Zyklus beherrscht, braucht kein 500-seitiges Framework-Handbuch. Es braucht nur die richtigen Skills. Das Label ist verbrannt. Die Arbeit beginnt. **Willkommen in der Werkstatt.** --- ## Das Label "Agile" ist verbrannt. Agiles Arbeiten als Handwerk fängt gerade erst an. Source: https://no-bullshit-agile.de/label-agile-verbrannt-agiles-arbeiten-handwerk.html Date: 30 Dezember 2025 Wenn das Label "Agile" so viel Ballast mit sich herumschleppt, dass es die Lösung verhindert, müssen wir es loslassen. 2026 beenden wir das Agile Theater und fangen wieder an zu bauen. ## Die Asche des Hypes – Warum das Label am Ende ist Die Erschöpfung rund um das Thema "Agile" ist überall zu spüren. Sei es in sozialen Netzen, in Teams und auch in Unternehmen. Das liegt vor allem daran, dass "Agil" zum Container für alles und jedes wurde – vom Micromanagement unter neuem Namen bis zur reinen Selbstbeschäftigung der „Methoden-Hüter". Die Konsequenz: Wer 2026 noch „Agilität einführen" will, erzeugt keine Aufbruchstimmung mehr, sondern nur noch Abwehrreaktionen. ## Warum ich schon immer von „agilem Arbeiten" spreche Einigen ist es schon ganz am Anfang aufgefallen. Ich sage nicht Agilität, ich sage **agiles Arbeiten**. Diese Worte habe ich bewußt gewählt - hier im Blog, im Podcast und auch [im Buch](https://no-bullshit-agile.de/buch-agiles-arbeiten-in-der-praxis.html). Agilität ist ein (mittlerweile verbranntes) Substantiv, das nach einem statischen Zielzustand klingt. Das ist vom Ansatz her schon falsch. Agilität ist auch kein Ziel, es ist ein Mittel, ein Ziel zu erreichen. Agiles Arbeiten beschreibt daher viel besser, worum es gehen sollte: Wir arbeiten agil, weil wir ein Ziel erreichen wollen. Das Ziel ist in einem komplexen Umfeld gute Software schnell zu liefern. Wir wollen Werte und keinen Waste schaffen. Dafür gibt es nur eine Herangehensweise: Iteration und Feedback. Und das ist harte Arbeit. Übrigens: mehr ist agiles Arbeiten auch nicht. **Iteration und Feedback**. ## Die Logik des Systems – Warum Frameworks die Arbeit oft verhindern Es gab letztens eine schöne [Umfrage auf Mastodon](https://mastodon.social/@scrumschau/115739394235104537) von Marco von [SCRUMschau](https://scrumschau.wordpress.com/). ![](https://no-bullshit-agile.de/media/posts/174/scrum-umfrage.png) **80% aller Teilnehmer** haben entweder keine Ahnung, warum sie Scrum machen oder sagen klar, dass es von oben vorgegeben ist. Und wie ist das Management wohl auf Scrum gekommen? Wollten sie wirklich mehr Wert schaffen und hatten sie wirklich die Chance zu verstehen, ob Scrum ihnen dabei hilft? In so einem Umfeld brauchen wir nicht darüber reden, welches wohl das bessere Framework ist - der Drops ist gelutscht. Alle werden diese Diskussion ablehnen. Das Thema wird als Fremdkörper verstanden. Kein Wunder, dass ich heute auf LinkedIn als Lösung zu einer Frage von mir nicht nur einmal gelesen habe, dass mehrere nach neuen Begriffen, Methoden oder Frameworks verlangen. **Das ist nicht der Weg**. Es ist klar absehbar, dass das alles nur alter Wein in neuen Schläuchen sein wird. Die neuen Begriffe, Methoden und Frameworks werden auch alle verbrennen. Der Glaube, dass man durch das Ändern von Rollentiteln und die Einführung eines regelmäßigen Zusammenstehens mehr Wert schafft, klingt absurd. Der Ausweg: Keine Missionierung sondern eine ehrliche Nutzen-Diskussion. Wir hören auf, die Leute zu „agilen Gläubigen" zu erziehen, und fangen an, ihre echten Painpoints im Handwerk zu lösen. Handwerk - agiles Arbeiten. Ich bin mit dieser Sicht nicht allein. Ansätze wie die '[Agile Primitives](https://age-of-product.com/transformation-agile-primitives/)' von Stefan Wolpers zeigen genau in diese Richtung: Weg von komplexen Regelwerken, zurück zu den fundamentalen Bausteinen, die Zusammenarbeit wirksam machen. Es geht nicht um den Erfolg eines Frameworks, sondern um den Erfolg der Arbeit. Wenn wir über Painpoints sprechen, sollten wir auch so ehrlich sein und sagen, dass agiles Arbeiten erst einmal ein **Overhead** ist. Die Rituale, das Verbreiten des Mindset, das Kleinschneiden von Anforderungen, die Feedback-Zyklen. Alles Overhead und teuer. Daher gehört es in einer Painpoint-Analyse dazu, genau zu schauen, ob die Arbeit überhaupt all das braucht. Das vergessen nämlich leider sehr viele Menschen. Es gibt Arbeit, die muss **nicht** agil umgesetzt werden. Ist sie einfach genug, um sehr **genau vorherzusagen**, was rauskommen soll und **wie es umgesetzt werden soll.** In so einem Szenario brauchen wir "agile" nicht. Repetitive Tätigkeit. Warum sollte man dann noch etwas darüber stülpen, dass für ganz andere Situationen gedacht und teuer ist? ## Der Entwickler als Architekt – Handwerk schlägt Ticket-Schubsen Entwickler haben das Theater am schnellsten durchschaut. Sie sind schon lange frustriert. Sie wollen schon lange "einfach nur arbeiten". Sie sind müde. Ihr Motivator ist es, [Software in guter Qualität zu liefern](https://survey.stackoverflow.co/2025/work/#job-satisfaction), die einen Zweck erfüllt und benutzt wird. Warum kollidiert das dann mit der "agilen" Realität? Weil wir in den meisten Unternehmen nicht über agiles Arbeiten reden. Ihnen wurden Methoden und Frameworks verkauft, egal ob sie passten oder nicht. In der Theorie, ganz nüchtern betrachtet, sollte aber agiles Arbeiten und die oben beschriebene Motivation von Devs zusammenpassen. Agiles Arbeiten ohne Architektur-Verständnis, Clean Code, Test-Automatisierung und Feedback - also all das, was wir auch unter technischer Exzellenz verstehen - führt nur dazu, dass wir „schneller im Kreis laufen". Damit verbessern wir uns nicht. Und daran scheitern Implementierungen von agilem Arbeiten in Unternehmen heute. Ich bin sicher: Die neue Währung in 2026 wird technisches Urteilsvermögen. Es wird um das Handwerk gehen. Es wird immer weniger darum gehen, in Jira ein Ticket zu schubsen oder jeden Tag morgens einmal zusammen zu stehen. Es gibt noch eine weitere Entwicklung, die das unterstützen wird. ## KI als der gnadenloser Bullshit-Filter "KI" ist ein sehr weiter Begriff, daher muss ich etwas trennschärfer werden. Ich rede hier vor allem vom Einsatz von LLMs in der Entwicklung. Ich denke, nach drei Jahren öffentlicher LLMs sehen wir klar. Für mich hat sich in dem Bereich in 2025 auch wenig getan - vor allem, wenn ich das mit 2023 oder 2024 vergleiche. Es ist klar, was LLMs können und was sie nicht können. Natürlich ist das Ökosystem um LLMs weiter gewachsen (Agenten, MCP, CLIs, ...). Aber alles basiert auf einem Sprachmodell. Und diese Technologie hat sich eben nicht deutlich verändert in 2025. Zeit also zu schauen wo wir stehen und wo die Reise hin geht. Es ist klar, dass der richtige Einsatz von LLMs ein Einsparpotential besitzt. Ich spreche hier von One Shot Prototypen die in den Müll wandern können, komplexerer Code Completion oder Scannen von Code auf Qualität, Security und Performance. Hier steckt ein Potential und wir alle nutzen es. Es ist auch klar, dass der Traum einiger, zumindest Juniors nicht mehr zu brauchen und damit Personalkosten zu sparen, nicht "in Erfüllung" geht. Es gibt sehr viele Beispiele, in denen Unternehmen, die diesen Weg versucht haben, [zurückrudern](https://www.msn.com/en-in/money/news/ai-bubble-bursting-salesforce-execs-admit-trust-issues-after-laying-off-4000-techies-now-scaling-back-use-of-ai-models/ar-AA1ST8Sl). Das ist die logische Konsequenz. **Wir können Juniors nicht ersetzen**. Sie sind die Seniors der Zukunft. Oder woher sollen sonst die Architekten unserer Software in Zukunft kommen? Ebenso sind LLMs nicht in der Lage, Seniors zu ersetzen, da sie permanente Kontrolle benötigen. Was viele noch gar nicht in der Diskussion bedenken: Heute kosten API Calls an LLMs ein paar Cent. Es ist aber offensichtlich, dass das **nicht kostendeckend** ist. Auch klar ist, dass der Zeitpunkt kommen wird, wo Investoren etwas von ihrem investierten Geld sehen wollen. Das wird dazu führen, dass die Anbieter von LLMs die Preise erhöhen, denn Werbung im Code ist wohl keine Alternative. Und wenn dann das monatliche Budget für LLMs statt €2.000 in Richtung €10.000 geht, ist der Weg nicht weit, einen Menschen einzustellen, der wirklich intelligent ist. Bei dem, was dann von der LLM-Nutzung übrig bleibt, sind die Prinzipien des agilen Arbeitens perfekt geeignet, dies zu integrieren. Prototyping, Testing, Code Completion - alles Technologien, die wir für unsere schnellen Feedback-Zyklen brauchen. ## 2026 – Die Rückkehr zur ökonomischen Vernunft Ich prophezeie, dass 2026 für das **echte agile Arbeiten** ein tolles Jahr wird. Aber eben nur für dieses echte Arbeiten - nicht für das unreflektierte Einsetzen von Frameworks oder das Consulting, dass die immer gleiche Methodik einführt. Auch das Erfinden von neuen Frameworks oder die Einführung neuer Namen wird keinen retten. In 2026 sehen wir das Ende der „Glaubenskriege" (Scrum vs. Kanban vs. SAFe). Unternehmen fordern wieder operative Wirksamkeit und Ergebnisse in kurzen Zyklen. **Gut so!** Die logische Konsequenz: Weg vom Zeremonienmeister, hin zum Ermöglicher, der Hindernisse im Wertstrom erkennt und beseitigt. Das Label ist tot. Die Arbeit beginnt. Willkommen in der Werkstatt des agilen Arbeitens.