I like real options, it makes sense to me and I try to use it, but sometime the obvious way is perhaps not always the best option
I was at a stand-up the other day and one of the Devs had been doing a bit of learning, its termed a “spike” here an Extreme Programming (XP).
In the XP usage it means to knock up a quick and dirty bit of code to show a solution to a potential technical or design problem. The outcome is the proof or otherwise that we can solve the problem and the output is most certainly not good enough to use further without additional work.
So it was proved out and I ended up in a debate about what’s next, for me the the purpose of a “spike” is to learn and having done that the spike was complete, however there was some stern resistance,
” but it has a memory leak we need to fix it.”
I pointed out that as we didn’t actually know if we were going to move forward with the solution any additional work was possible waste, but was countered with,
“we must consider the implementation”.
And again I pushed back as the right way to do this was to stop and it got a bit feisty, however my advice was predicated on the understanding that we had multiple options on the table and we wanted not to converge on a single option too early, real options tells us to pay to keep options open after all, options have value.
When I dug further it became apparent that this was actually the only solution on the table and from the developers standpoint not to progress this now when they had their heads around it was just blindingly stupid.
This made me think about what we should have done in this context.
We talk about carrying out multiple concurrent, safe to fail experiments, some contradictory, some oblique, some naive. To do this there is an assumption that we have multiple engineers on hand to carry the work out. And yes the most expensive way to validate a hypothesis is to code it out, but when you are finding a solution to nutty technical problem sometimes a bit of coding is the right way to go.
So in this case the developers had made their best guess about what needed to be done and gone ahead and done it and having found “a” fit as far as they were concerned that was good enough and I suppose it was, for now.
Yes we could have gone back, examined why we didn’t focus all three developers on this one single high value experiment, come up with a few experiments and gone for it, but they also had to deliver some features at the same time to pay the bills.
So what to do, we moved forward pragmatically, but making sure we build it in such a way that allows us the option to swap it out at a later date and replace it with a better solution, if needed. In other words we make sure we don’t back ourselves into a corner
The point, we don’t always have the option to have options, especially upfront when we need to deliver, but that doesn’t means we have to kill all of the options.
So keep your options open!
.. oh and buy this commitment