One of my mantras to product owners is “value first, risk first”. But at first blush there’s a conflict here.

“Value first, risk first” is intended to guide people on what to prioritise. Agile software development is about delivering value, and the highest value deliveries need to be highest up the list. By prioritising value you get a much earlier return on your effort, and you have more flexibility for later changes.

Prioritising risk does a slightly different job. It surfaces problems earlier, therefore either giving you to more time to find alternative actions or establishing earlier a steadier (lower) rate of progress. If you’ve got a lower rate of progress, for example because one of the technologies you’re dealing with is more challenging than expected, then that’s clearly not great but at least you find out sooner rather than just before a supposed launch.

The problem seems to be that when risk is pitched against value it’s hard to tell which one takes higher precedent. We seem to be comparing apples and oranges.

But in some way there is a comparison, because bottoming out risks early on adds real value to the work. It may not add value in terms of an end user feature, but it does add value in in terms of how rapidly you can deliver more end user features down the line. If you discover early on that your time is shorter than expected or some aspects of your product may be costlier to deliver than expected then you can adjust accordingly where you spend your resources to get the most value.

A corollary to this is that product owners—the people who make the value judgements on prioritisation—need to be responsible for the cost (in some form) as well as for the functional outcomes. This is often the case, but when the product owner does not feel the pain of a cost or time overrun then it is unlikely results will be delivered efficiently.

Photo by Automania on Flickr