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.

I'm Gojko Adzic, author of Impact Mapping and Specification by Example. My latest book is Fifty Quick Ideas to Improve Your Tests. To learn about discounts on my books, conferences and workshops, sign up for Impact or follow me on Twitter. Join me at these conferences and workshops:

Specification by Example Workshops

How to get more value out of user stories

Impact Mapping

2 thoughts on “Is prioritisation based on business value right?

  1. Pingback: Gojko Adzic » Is prioritisation based on business value right? | business

  2. Not sure I understand the definitions behind some of the ideas here.

    (1). “…a technology does not satisfy the needs…” I’m not seeing how this is connected with risk or with value. It sounds like a normal learning experience when we apply an adaptive approach. It is neither success nor failure, neither value nor risk.

    (2) “…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.” Eh? Why would they stop aiming for value? It seems this is another learning experience that is supposed to occur with an adaptive approach. The target has moved, that’s all.

    (3) “…develop for business value once the risks are down…” Who decides when the risks are sufficiently down to start focusing on business value? And which sort of risk are we talking about? Business risk is not the same as project delivery risk. As technologists, we tend to think of project delivery risk as equivalent to business risk because that’s our domain. Is that really correct? Many people I’ve worked with have treated their own ignorance of some new technology as a “business risk,” when the real business risk is more about the economic impact of failing to enter a new market before competitors do so. The former is just a normal learning curve issue, not a “business risk.”

    I think there is something worthwhile in the concept of shifting emphasis between growing business value and reducing “risks” (whatever that means), but I’m not sure the concept has been elaborated very well so far. Maybe the presentation had a bit more detail than the blog post.

    At the moment, I think I’ll have to go with prioritization based on perceived anticipated business value. Risks usually fall out naturally from an analysis of the anticipated value. We can also avoid the potential trap of trying to mitigate “risks” that don’t have any real impact to the business, just because they happen to be within our familiar domain.

Leave a Reply

Your email address will not be published. Required fields are marked *