The idea of “Failure Demand” comes from systems thinker, John Seddon, who describes it as “unnecessary burden on the system.” By looking at removing failure demand on a system, you free up more capacity to focus on value added work. Much of failure demand also maps to the lead concept of “waste” although not all “waste” is the same as failure demand.
Some classic examples (and tell-tale signs) I see with companies include:
- Poor quality work – Features that are not tested, or well designed end up generating bugs. A smell to look for is lots of issues reported by end users. Lots of errors in production logs are also another great smell for detecting this.
- Features designed without thinking about User Experience – Without putting the end user of a system in mind, many organisations build functionality without exploring how/why an end user of their system will end up using it. Working with an effective user experience capability means simpler, clearer interfaces that help end users get the job done. Smells to look out for include interfaces that have too many additions or features added to it.
- Requirements solely driven by a Product Manager – Many organisations rely solely on the HiPPO (the Highest Paid Person’s Opinion) to drive requirements. Although a Product Manager role is still useful for other reasons, faster experimentation and data collection of testing hypothesis is of use. Look out for smells like long release cycles, date driven requirements, or large backlog requests of detailed “user requirements” specified by the Product Manager without real involvement or feedback from end users.
- Misunderstandings – As a software organisation grows, the communication channels significantly increase. When people do not validate their understandings with each other, they end up doing more rework than necessary. Depending on how complex the problem space is, using visual models, workshops that explore a certain approach and simply showing progress constantly (daily or weekly basis) help to resolve this.