“Failure demand is demand caused by a failure to do something or do something right for the customer.” – John Seddon 2009
All work a team does comes from some source of “demand”. These can be new features requested by a customer or the Product Owner. They can also be defect reports, usability issues, and a whole host more. Some of these requests (“demand”) are adding new value, and some of these are making up for past problems – the failure demand.
When we see service and product teams dealing with a high volume of requests, it can be very instructive to look, roughly, at how much of the work comes from new value requests and how much is the failure of the system/product to meet the customer’s needs in the first place. With some operations teams, over 80% of their work effort is spent dealing with failure demand. In situations like this, attempting to improve other parts of the system without addressing the failure demand is a waste of time.
Examples:
– When John Seddon coined the phrase, he was working with DEC trying to help them sell more computers over the phone. Ideally, the phone agents would be talking to customers about their computer needs and sell them more computers. In practice, when they talked to customers they discovered the customers wanted help with the existing problems: documentation, billing, missing parts for existing orders. This demand was a **failure** of the system to deliver what was needed. Hence the term “Failure Demand”.
– At a pub during high demand periods, the kitchen would often cook the wrong food, undercook it, or burn it. So if the demand was 100 meals, the mistakes the kitchen made meant they might have to cook 150 meals in total. This in turn led to longer delays, customer dissatisfaction and, of course, reduced profits.
– An insurance company reshoring (from India to the UK) their call centre discovered 70% of the calls to the call centre came from contract specifications that were too rigid and left agents no room to respond to customer needs.
Seddon (the ideas originator) says to make your measurement a snapshot. Use it to create awareness of the problem, then put the effort into fixing the system, not monitoring.
Resources:
- Avoidable Contact – Early Paper on Failure Demand
- A definition of failure demand – for Digital
- Failure Demand
- Failure Demand and Software Development
- Failure demand: what’s the big secret?
- Failure demand vs Value Demand – Is churn affecting how you deliver value
- How Understanding Failure Demand Can Transform Your Product Into a Fit-For-Purpose Value Proposition
See also:
Systems Thinking
Lean Software Development
Kanban
Special Teams
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
*Thank you for visiting the World's Largest Opinionated Agile Reference Library. This content is created and the links are curated through the lens of Agile Pain Relief Consulting's view of what is effective in the practice of Scrum and Agile. We don't accept submissions and emails to that effect are marked as spam. Book listings may use affiliate links that could result in a small commission received by us if you purchase, but they do not affect the price at all. From experience, this won't amount to anything more than a cup of coffee in a year.« Back to Glossary Index