# No Bullshit Agile > No Bullshit Agile is an English-language knowledge portal by Thomas Esders about agile work — no buzzwords, no framework dogma, no agile theater. At its core stands the Work–Feedback Loop: agile work is the ability to connect work and feedback quickly and reliably. Everything else is overhead. Language: English. Audience: developers, team leads, managers. --- ## Full Article: My Position Source: https://no-bullshit-agile.com/my-position.html I'm not interested in agility as a label. And I don't explain frameworks. What interests me is a more fundamental question: How do work systems actually learn? Not in meetings. Not through planning. But at the point where real work meets real feedback. It always comes down to a cycle that must be closed. ### Learning Is Not an Insight Problem A system does not learn because it understands something. It only learns when work creates an observable reaction from reality and that feedback flows back into the next decision. Anything that stretches, distorts, or interrupts this path prevents learning — even if it feels reasonable. That's not intuitive. I get that. ### My Focus I focus on the real Work–Feedback Loop: - Where does work turn into actual impact? - Where does feedback arrive too late? - Where do organizations believe they are learning — but aren't? Anything that measurably shortens this cycle between work and insight increases learning capability. Everything else is overhead and can be ignored. ### What I Write Against I don't write against Scrum. Not against Agile. Not against methods, roles, or tools. When applied well, all of them have their place. I write against decoupled systems where cause and effect are separated in time or organization. Systems where work happens, but feedback arrives too late, filtered, or without consequences. No learning happens there. Only activity. ### What You'll Find Here — and What You Won't You'll find: Diagnoses of delayed learning. Concrete questions that expose blind spots. Interventions and actions that reconnect work and feedback. You will not find: Framework introductions. Method comparisons. Mindset appeals. Coaching promises. Maturity models. Not because these things are bad, but because they only become relevant once real learning actually takes place. And too often, it doesn't. ### How I Write I only publish texts that serve a clear purpose: They shorten the thinking path between work and feedback. Description alone isn't enough. Insight without consequence doesn't move anything forward. That means precision matters more to me than reach. And clarity matters more than broad appeal. ### In Short I focus on how work systems actually learn — by shortening the real, physical path between action and feedback. Everything else is overhead. --- ## Full Article: Work–Feedback Loop (Complete Conceptual Model) Source: https://no-bullshit-agile.com/wfl/ The Work–Feedback Loop is a thinking and diagnostic model that shows whether work in your organization creates real effects, makes them visible, triggers decisions, and actually changes future work. It helps you quickly identify the structural bottleneck that limits adaptability — without debating methods or "agility" as a label. This conceptual model was developed by Thomas Esders and is made available under the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license. ### Chapter 1: What This Is About Many organizations are getting faster: more releases, more initiatives, more meetings, more "output." And yet a familiar experience remains: reality changes, but the system doesn't change along with it fast enough. When that happens, it's rarely a motivation or competence issue. It's a structural issue: work is not cleanly coupled to its real effects — and those effects don't reliably change what work happens next. The core principle is coupling over activity: Work → Feedback → Decision → future Work A system only learns reliably from reality if all four steps are actually coupled: 1. Work creates a real effect (not just internal activity), 2. that effect becomes visible as feedback (as a signal, not an opinion), 3. it leads to a decision (priorities/assumptions/resources change), 4. and that decision changes future work. If a coupling is missing, the loop becomes open: it may feel productive — but it is not structurally adaptive. ### Chapter 2: Basic Model Work refers to any action that produces an effect in reality: a delivered product increment, a price change, an organizational decision. Only work that produces an effect counts. If there is no effect, we lack the learning signal. Feedback is the observable reaction of reality to work: usage behavior, market reactions, qualitative feedback from real usage situations. Feedback is always an effect that returns to the system. An internal opinion round without reference to observable effects is not feedback in this model. Decision: Feedback alone does not generate adaptation. Between perception and change, there is always a decision. Priorities are shifted, resources are reallocated, assumptions are corrected. Without a decision, feedback has no consequences. Future work: Decisions based on feedback from past work must change future work. This closes the loop. A system is capable of learning if: (1) Work produces real effects, (2) These effects become visible, (3) Decisions respond to them, (4) Future work arises from them. Two characteristics determine the quality of the loop: Speed (how much time elapses between work and adjustment?) and Reliability (how reliably does feedback lead to changes?). Organizational learning ability arises when both are high. ### Chapter 3: Two Speeds — States of the System Work speed describes how quickly a system generates work that can have a real impact (release frequency, time-to-market, throughput). Feedback speed describes how quickly the effect of work is fed back into the system as a relevant signal (time until valid usage data, market reactions, or operational side effects are detected). Combining both speeds results in four basic states: 1. Learning: Work delivered quickly, feedback arrives quickly. The system is adaptive. This state must be protected. 2. Actionism: Work delivered quickly, feedback flows slowly. Activity is high but learning rate is low. The bottleneck is processing reality. 3. Frustration: Work is slow, feedback enters at high frequency. Problems are recognized but the system doesn't respond. The bottleneck is decision-making. 4. Stagnation: Both work and feedback are slow. Neither movement nor adaptation is significant. Both speeds are bottlenecks. These states are structural, not cultural. A committed team can work in frustration. A disciplined company can operate in actionism. The cause lies in coupling speed. ### Chapter 4: Time as a Structural Variable Feedback Response Time (FRT): t(FRT) = t(signal) + t(decision) + t(deploy) - t(signal): Time until a real effect becomes visible as a relevant signal - t(decision): Time until a binding decision is made - t(deploy): Time until this decision is effectively implemented Feedback has a validity window. A signal that is not translated into changed action in time loses its relevance. If t(FRT) exceeds the validity window, the system reacts — but too late. The bottleneck is often not in the signal but in the response time. Multi-level decision processes, committee structures, budget approvals, and dependencies prolong t(decision) or t(deploy). ### Chapter 5: Decision Latency Decision latency describes the time span between the moment a relevant signal becomes visible and the moment a binding decision is made. When t(decision) > t(production), a structural decoupling occurs. The operational system continuously generates new work while strategic decisions are made more slowly. Symptoms: Priority changes with significant delays. Discussions without binding conclusions. Backlogs of initiatives. Operational teams waiting for approvals. Decision latency rarely arises from lack of willingness. It arises from structures: hierarchical depth, diffusion of responsibility, risk minimization, budget cycles, governance mechanisms. ### Chapter 6: Capital as a Second Coupling Capital is usually allocated in cycles (annual/quarterly budgets, portfolio decisions). These cycles have their own frequency: t(capital). Coupling Ratio = t(capital) / t(production) If t(capital) >> t(production), the operational system can learn quickly but capital decisions only respond at long intervals. Findings remain without consequence, experiments cannot be scaled, changes are financially blocked. Capital cycles act as a frequency filter. They limit how quickly an organization can respond structurally, even when feedback, decisions, and delivery are fast. ### Chapter 7: Nested Loops Real organizations have multiple loops: Operational loop (days/weeks), Coordination loop (weeks/months), Strategic loop (months/years). t(operation) < t(coordination) < t(strategy) This becomes problematic when feedback does not flow between levels. Disconnected Agility describes a state where operational loops work quickly while strategic loops remain sluggish. Teams deliver regularly but portfolio decisions rarely change. Experiments are conducted but there is no budgetary response. Organizational learning ability only arises when feedback flows across levels and is translated into decisions at each level in a timely manner. ### Chapter 8: The Model as an Analytical Tool The model does not describe a process model. It defines neither roles nor events. It reduces complex organizations to: Is the system capable of responding to reality in a timely manner? Key diagnostic questions: 1. What is the real effect and is it observable? 2. How quickly does this effect become visible as a signal? 3. How long does it take for a decision to be made? 4. How long does implementation take? 5. Which loop is currently the bottleneck? 6. Is capital synchronized with operational reality? 7. Are strategic and operational loops aligned? From this perspective, agility is not a collection of practices. It is the ability of a system to translate feedback into changed work in a timely manner. ### Glossary (Key Terms) - Actionism: High production speed with low feedback speed. - Closed loop: Work → visible effect → decision → adjusted work. Only closed loops are adaptive. - Coupling Ratio: t(capital) / t(production). Shows capital-operational coupling. - Decision latency: t(decision). Time between signal visibility and binding decision. - Disconnected Agility: Fast operational loops with sluggish strategic loops. - Feedback Response Time (FRT): t(signal) + t(decision) + t(deploy). - Learning: State of synchronized work and feedback speed. - Nested loops: Multiple feedback levels with different time constants. - Validity window: Time span during which a feedback signal remains action-guiding. - Work: Action with a real effect in the system's environment. --- ## Full Article: Forget "Agile" Theory — The Only Cycle That Really Matters Source: https://no-bullshit-agile.com/agile-working-feedback-loop-skills-over-frameworks.html We trudge to Dailies, estimate Story Points like fortune tellers, and fill Jira boards beyond recognition. But at the end of the day, it still takes months for a line of code to reach the actual user. We have lost ourselves in framework discussions. We argue about SAFe vs. Scrum while our craft is rotting. It is time to end the "Agile Theater" and focus on what Agile Working actually is at its core: Work and Feedback. If we strip away all the baggage — the certificate mills, the role descriptions, and the rituals — agile working is not a management concept, but an economic survival strategy in a complex world. We build something functional (Work), we let it collide with reality (Feedback), and we adjust our course based on what we have learned. The golden rule: Your agility is not measured by the number of your certificates or lines of code, but by the speed of this cycle. When I say we need to accelerate this cycle, I don't mean "hectic." I mean the technical and organizational ability to learn quickly without sacrificing quality, security, or user experience. To make this cycle fast and stable, we don't need new meetings. We need Skills. To shrink the Work-Feedback Cycle from three months to three weeks (or three hours), we must work on both areas simultaneously: increase the quality of our work so it can flow safely, and professionalize our channels for learning (feedback). The left side (Work): Architecture, Development, Testing, DevOps for technical risk management. Strategy, Discovery, Stories for content direction. Culture, Learning, Rituals as the social operating system. The right side (Feedback): Usability and surveys as early warning systems. Analytics and operational metrics for hard reality. Market and sales for economic proof. The biggest mistake organizations make: they try to "introduce" a framework. They buy the whole menu when they actually just need a glass of water. Strategy: (1) Identify the bottleneck — where do you lose the most time? (2) Choose the smallest measure that shortens your feedback cycle. (3) Measure your Cycle Time — if a measure doesn't shorten it, it's baggage. 2026 is the year we stop discussing agility as a religion. We must perceive it again as what it is: a craft. Agile Working requires technical judgment, economic sanity, and the courage to leave gaps. The label is burnt. The work begins. --- ## Full Article: The "Agile" Label Is Burnt Source: https://no-bullshit-agile.com/agile-label-burnt-agile-work-craft.html "Agile" has become a container for anything and everything — from micromanagement under a new name to the pure self-occupation of the "method guardians." Anyone still wanting to "introduce agility" in 2026 no longer creates momentum, but only defensive reactions. I don't say agility; I say agile work. Agility is a burnt noun that sounds like a static target state. Agile work describes much better what it should be about: we work in an agile way because we want to achieve a goal. The goal is to deliver good software quickly in a complex environment. There is only one approach: iteration and feedback. Agile work is nothing more than that. 80% of poll participants either have no idea why they are doing Scrum or say it was mandated from above. In such an environment, we don't need to talk about which framework might be better. The topic is perceived as a foreign body. The belief that you create more value by changing role titles and introducing regular stand-ups sounds absurd. The way out: no missionary work, but an honest discussion about benefits. We stop educating people to become "agile believers" and start solving their real pain points in the craft. When we talk about pain points, we should also be honest enough to say that agile work is first and foremost an overhead. The rituals, spreading the mindset, slicing requirements, the feedback cycles. All overhead and expensive. A pain point analysis must also take a close look at whether the work even needs all of this. There is work that does not need to be implemented in an agile way. If it is simple enough to predict very precisely what the outcome should be and how it should be implemented, then we don't need "agile." Developers saw through the theater the fastest. Their motivator is to deliver software in good quality that serves a purpose and is actually used. Agile work without architectural understanding, clean code, test automation, and feedback only leads to "running in circles faster." The new currency in 2026 will be technical judgment. It will be about the craft. It will be less and less about pushing tickets in Jira or standing together every morning. The label is dead. The work begins. Welcome to the workshop of agile work.