Detecting agile theatre with real delivery signals

TL;DR

Agile is measured by delivery, feedback, and decision-making authority in the hands of teams, not by visible ceremonies or tooling.

25 May 2026
Written by Martin Hinshelwood
2 minute read
Comments
Subscribe

A delivery system is not agile because it uses agile practices. It is agile when the people closest to the work can deliver usable software, observe real feedback, change the work, change the process, and move value through the wider delivery system without being blocked by a contradictory authority structure.

That is why I use the Detecting Agile Bullshit questions, adapted from the US Defence Innovation Board, as a practical diagnostic for agility.

  1. Are teams delivering working software to at least some subset of real users every iteration (including the first) and gathering feedback?
  2. Is there a product charter that lays out the mission and strategic goals? Do all members of the team understand both, and are they able to see how their work contributes to both?
  3. Is feedback from users turned into concrete work items for sprint teams on timelines shorter than one month?
  4. Are teams empowered to change the requirements based on user feedback?
  5. Are teams empowered to change their process based on what they learn?
  6. Is the full ecosystem of your project agile? Agile programming teams followed by linear, bureaucratic deployment is a failure.

This is the minimum bar I would use. Agile can be more than this, but anything materially below this is agile theatre.

The diagnostic value of these questions is that they do not ask whether an organisation uses Scrum, Kanban, Jira, SAFe, story points, stand-ups, or any other visible practice. They ask whether the organisation has built a system of work that can deliver software, expose it to real users, learn from the result, and change direction without waiting for permission from a separate authority structure.

That is the core of agility in software:

  1. Maintain direct connection between delivery and user outcomes.
  2. Colocate accountability and authority.
  3. Keep feedback loops shorter than the decision cycles they are meant to inform.
  4. Ensure the whole delivery ecosystem can respond, not just the development team.

Frameworks, tools, and practices are only useful to the extent that they serve that intent. When they do not, they become evidence of theatre rather than evidence of agility.

The uncomfortable point is that many organisations are not confused about agility. They are using agile language to avoid confronting the operating model they have actually built.

Ref: https://media.defense.gov/2018/Oct/09/2002049591/-1/-1/0/DIB_DETECTING_AGILE_BS_2018.10.05.PDF

Smart Classifications

Each classification [Concepts, Categories, & Tags] was assigned using AI-powered semantic analysis and scored across relevance, depth, and alignment. Final decisions? Still human. Always traceable. Hover to see how it applies.

Comments
Subscribe

What to read next

Article Product Development Product Management

Why Most Companies Operating Models Fail in Dynamic Markets

A concise comparison of Predictive and Adaptive Operating Models, explaining why traditional structures fail in dynamic markets and how …

Read article
Article Product Development Technical Leadership

Don’t Manage Dependencies, Remove Them

Explains why dependencies are a sign of poor system design and outlines steps to eliminate them by aligning teams, clarifying ownership, and …

Read article
Article Product Development Engineering Excellence

The Estimation Trap: How Tracking Accuracy Undermines Trust, Flow, and Value in Software Delivery

Tracking estimation accuracy in software delivery leads to mistrust, fear, and distorted behaviours. Focus on customer value, flow, and …

Read article
Article Kanban Product Development

Flow of Value vs Flow of Work – Misnomer or Useful Shorthand?

Compares “flow of value” and “flow of work” in Kanban, explaining why only validated outcomes count as value and stressing the need for …

Read article
Video Technical Leadership Engineering Excellence

Why Outsourcing DevOps Fails, and How Real Engineering Excellence Starts With Your Team

Avoid DevOps vendor lock-in, discover how true engineering excellence starts with partnership, not outsourcing. Ready to transform your …

Watch video
Article Product Development Engineering Excellence

Estimating Better in an Overloaded System Is a Poor Man’s Strategy

High work in progress (WIP) causes delays and unpredictability; improving estimates won’t help. Limiting WIP and focusing on flow is key to …

Read article