Is prioritisation based on business value right?

At the Scandinavian Developer Conference today in Göteborg, Alistair Cockburn spoke about “beyond agile: the new face of software engineering”. The main topic of his talk were five “chapters” that will according to Cocburn be a “broad base of software engineering in the next 20-50 years”, although I recognised most of the content from the books he published years ago. But there was a relatively innovative and controversial idea as well. Cockburn challenged the typical agile advice on prioritisation by focusing on highest business value first.

He said that in many companies he worked with, they try to do that but in reality things are different. Many companies initially start aiming for business value but then something doesn’t work out — a technology does not satisfy the needs, a stakeholder misjudged the market opportunities — and then the team switches from aiming at increasing business value to aiming to lowering the risks of failure. These risks might be business, social, technical or cost/schedule risks. By reducing the risk, companies effectively “pay to learn”, said Cocburn.

He advised a strategy of prioritisation to develop for business value once the risks are down and periodically switching from paying to learn and paying to get business value. Successful organisations he works with grow business value and then reduce risks, then grow business value again then reduce risk. In the earlier stages of the projects, the focus is much more on reducing risks than on building value, where in the later stages the focus changes.

The payoff comes from the possibility to “trim the tail”, according to him. When the risks are mitigated, teams can deliver effectively — whether they want to deliver by value or on a particular date. “Once the costs are down, and the business value is largely in place, then you can spend the rest of the time improving the quality”, said Cocburn. As an example, he pointed out that Apple did this with IPhones and IPads. They released a first version wit basic features and a second version a month or two months after, with enhanced features. They were able to “trim the tail” and increase quality very rapidly.

Paying to learn and considering early stages of a project as a journey of exploration seems to a hot topic in the development community now. For a different look at this, check out Dan North’s ideas on deliberate discovery.