Value Driven – A Simple Context

I’ve been struggling with the idea of shifting a team’s focus away from activity and towards that of value based measures. However I’m finding it hard to articulate these ideas well. So I thought I’d build a simple fictional cased to try out these ideas and stimulate some discussion.

Imagine if you will our virtual development team is working within a small ecommerce company. They have little legacy code or backend logistics to worry about. Most days they can code, test, deploy pretty rapidly. There are no barriers between the development team and the business/marketing folks, in fact we can view them as one big happy family.

So I believe value is pretty simple in this context. Our costs are fixed. If the team stop work tomorrow, the website will continue to operate at the same level of sales. So the team delivers value by increasing sales.

Imagine the team currently has no work in progress. We’re in effect starting with clean sheet. So what do they do next?

The first thing the team need is some ideas. In our virtual space, I can’t see any other way for our team to get started. The developers might have ideas for improving site speed, marketing see opportunities with the latest social network integration, the usability guys have a step in the basket that they think can be improved and some suggestions from customers on twitter also get added to the list.

So we have our classic backlog of work. Given the way value is generated in this imaginary world, how should the team prioritise which ideas to attack first? There are going to be some simple, small tweaks, that are low risk but not particularly likely to introduce a step change in sales. There are also more audacious ideas, which the team think might make a massive improvement to the business but that come with a great deal of risk.

Now I’m beginning to get nervous for our fictional friends. It feels like the team could spend a whole chunk of time “analysing” the situation without adding value, this kind of waste is really bad and might result in analysis paralysis. However I’m also worried if they just want to “crack on” then they are more likely to favour the smaller less risky ideas, as these get people busy and start delivering some real value earlier (perhaps the classic agile mind-set) but then the large items will get ignored.

To help out our crew I’d like to find a quick (low cost) method of comparing two ideas. One low value and relatively risk free and the other high value and even higher risk. The low value item should be pretty straight forward, there is an estimated value with some level of uncertainty. For example we’re expecting our tweak to the basket process to have a 75% chance of delivering a 2% increase in sales. Whereas our big item, which involves integrating some new 3^rd party mapping interface on the homepage only has a 25% chance of going right in which case it is likely to increase sales by 20%, but if it doesn’t work then we’re looking at a 10% decrease, as performance and usability of the homepage takes a dive. Of course these are all little better than guesses at this stage so no need to sweat about the numbers too much.

	Worst	Best	Average
Idea 1	0% (25%)	+2% (75%)	1.5%
Idea 2	-10% (75%)	+20% (25%)	-2.5%

What our team needs is to create a 3^rd idea. This work item is better called an experiment. It is designed to improve our understanding of the potential outcome of our big idea. This experiment needs to be totally safe to fail, and should be designed in such a way as to not impact sales either way. In other words it is 100% likely to deliver 0% increase in sales. So how can we assign value to this 3^rd idea? The team need to focus on failing earlier, so should be exploring the reasons why this big idea might fail. In this case the potential performance problems the integration might cause. So they come up with an experiment which has a 50% chance of proving the performance issues and if successful will reduce the downside of our big idea to zero.

	Worst Best	Best	Average
Idea 3	0% (50%)	0% (50%)	0%
Idea 2	0% (75%)	20% (25%)	5%
Idea 3+2	0% (37.5%)	20% (12.5%)	2.5%

By doing our experiment before we tackle the big idea, we’ve turned the estimated value from a negative to a positive, and given it a relative measure above that of the simple thing. Now the team know what to tackle next, the experiment first. If that is successful then the big idea.

So now let’s fast forward a few months. How can we best measure the effectiveness of our team?

Clearly the speed at which we can take an idea, commit to working on it and then measure the effect on sales is going to be important (classic cycle time). This will ensure the team remains agile and able to reprioritise the next item to work on quickly. Experiments are more interesting, it has been said the optimum success/failure rate for experiments is around 50%, at this level we are learning the most, and it may be good for our team to be able to prove that. Perhaps also the ratio of experiments to other work would be important, as it ensures the team can get the balance between low risk/low value items and our bigger value items. Finally throughput as measured in terms of increase in sales would be the most interesting measure and something the team can be sure will talk volumes to the business folk.