Failure demand in software
A lot of people seem to like John Seddon’s concept of failure demand. Me too. But Seddon mostly talks about service delivery in areas such as call centers and housing repairs. I tend to work with software development organizations. When Seddon mentions IT, it is in the context of how the workflow systems we create end up reducing the quality of service delivery in call centers and housing repairs. After having used a number of different workflow systems over the years I too have come to the conclusion that most of them are counterproductive.
But what about software development itself? Can the idea of failure demand be applied to software development? A number of people have pondered this and they tend to land on the same short answer: bugs. The answer is so intuitively right that it must be wrong. Sure enough, after mulling this for a while I realized that it is a half truth at best. Before I can show why failure demand in software is a lot more and a lot less than bugs I need to dig deeper into what failure demand is.
The real meaning of failure demand
Seddon defines failure demand as: “demand caused by a failure to do something or do something right for the customer”. If you dig deeper it soon becomes evident that what he is really talking about is wasted capacity. When a customer has to call twice in order to get something fixed, the second call does not create value. If every customer request was handled in the first interaction the organization would be able to help its customers faster, with less frustration and at a lower cost. When a call center tries to save money by shortening the duration of customer calls the net effect is more calls and more waste.
Bugs are not always failure demand
If a software release contains bugs it seems like a no brainer that these can be viewed as failure demand. And many bugs do indeed waste capacity. If you develop something and then have to redo this work, this will steal time that you could have used to develop new features. But many bugs do not require work to be redone. In practice, a large proportion of bugs are missing features and special cases. Most of the time spent on fixing these bugs is not wasted. This work would have had be have been done even if it had been part of the original development.
Other forms of failure demand in software
It is also a fallacy to believe that bugs are the only form of failure demand in software. In many software houses an inordinate amount of time is spent on backlog management. Customers repeatedly ask about when a request can be fulfilled and endless meetings discuss the relative priority of issues. The root cause is often that the underlying processes are so clogged up that few customer requests get handled. I would argue that most of the time used on backlog management does not create value. It is most certainly often a case of failing to do something for the customer.
I would also question a large portion of the work done on estimation. Estimation can have valuable effects as to problem understanding and dialog. A lot of estimation work is unfortunately more about backlog management and does not really create any value.
Niklas Björnerstedt
Posted on 2012.01.13 at 20:47
Comments are off for this post.