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.
- Are teams delivering working software to at least some subset of real users every iteration (including the first) and gathering feedback?
- 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?
- Is feedback from users turned into concrete work items for sprint teams on timelines shorter than one month?
- Are teams empowered to change the requirements based on user feedback?
- Are teams empowered to change their process based on what they learn?
- 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:
- Maintain direct connection between delivery and user outcomes.
- Colocate accountability and authority.
- Keep feedback loops shorter than the decision cycles they are meant to inform.
- 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.
What to read next
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 …
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 …
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 …
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 …
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 …
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 …
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 …
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 …
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 …
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 …
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 …
Why Big Bang Rewrites Fail: How Sustainable Change and Engineering Excellence Transform Legacy Systems
Ditch the Big Bang rewrite. Discover why sustainable, in-place change drives true engineering excellence and lasting transformation in your …