A while back I wrote about “The investigation “sick note” card”, in which I said I often found teams opted for investigation work as a way of avoiding doing the actual development work. Investigation isn’t a bad thing, but I felt that it’s purpose was often missed. Here I want to go into a bit more detail.
An investigation task is about reducing uncertainty. It’s not about eliminating uncertainty—that would probably be impossible until the actual work in question was developed, deployed and had been in use for some time. So it is about reducing uncertainty.
The question then is: by how much do we need to reduce our uncertainty? Or, more to the point, how do we know when to stop?
Let’s suppose we are unsure about which database technology to use. The outcome is a recommendation of one database (and we can expect some reasoning to go with that). If we start with a choice of databases then an hour of web searching would probably reduce our uncertainty a little: we’d look at other people’s experiences, search for “problems with database X” and see which options fares better, look at the installation instructions, etc. This would tell us a bit, and so with just one hour’s work we can expect to be in a better place than when we started. At the other extreme we could spend perhaps a month running up a prototype with each of the options. This would reduce our uncertainty considerably, but would almost certainly be excessive. And we can define excessive as “value divided by time is too low”.
So at some point between the two extremes we should recognise we’re at the point of diminishing returns—any more time will deliver less value. How can we best use our time?
- Success in our decision will be influenced by a number of factors—areas of uncertainty—so let’s write those down. In our example they might be: Ease of installation; security; API usage; library options; performance.
- Then we need to order them by importance—which factor is going to be the biggest influence on our decision-making?
- Finally we need to work through them one at a time, in order. Each time we need to think what we need to do to reduce our uncertainty, and then investigate that accordingly.
As we spend time on each item we need to check ourselves every so often and ask: have we got enough clarity to move on to the next item? And before moving onto the next item we should ask: do we really need to continue, or can we stop now?
This approach allows us to use our time to the best effect. It also allows us to say where we are in our thinking at any point. And it gives us a way to exit early.