If you’ve read the awesome graphic novel, “Commitment”, you’ll know the rules of Real Options already:

• Options have value
• Options expire
• Never commit early unless you know why.

There’s an additional rule which is sometimes added to this:

• Options have more value as uncertainty rises.

…and software development is full of uncertainty.

We do want to make commitments; also investments, which are the subject of this blog. Failure to act is itself a decision, and at some point options do expire. As David J. Anderson says, “If you leave it long enough, eventually everything becomes an expedite.” The problem comes when the commitments are premature, and the investments speculative. So this post is about minimizing speculative investments, and avoiding premature commitments altogether.

An option is the right, but not the obligation, to do something or get something.

Chris Matts took the term “Real Options” from financial options, for which we can easily assign value; the right to buy cocoa beans at a certain price right before Christmas so that your chocolate factory can meet its own commitments to provide chocolate Santas to its customers, for instance. If cocoa beans are cheaper than the option price, we don’t need to use the option. If they’re more expensive, we exercise the option and we get our beans affordably.

In real life, options are harder to value. They’re just choices. However, they have value, and we as human beings tend to exercise our options way before we need to. We have an innate dislike of uncertainty. Our confirmation bias serves to make us think we have certainty and understand the patterns we see, even when we don’t. That’s great for helping us move forward in an uncertain world… but if we could move forward in a way that kept two directions open for us, cheaply, why wouldn’t we?

The other problem I’ve encountered is that we don’t actually commit a lot of the time. Instead, we make heavy, and speculative, investments.

A speculative investment is risky.

In finance, a speculative investment is one which may entail a significant degree of loss, and which by its nature is uncertain. I’m talking about real-life investments, which might be of time or effort or willpower or social capital. The term “speculative” also means “based on conjecture, rather than knowledge.” Like premature commitments, a speculative investment is one made in an absence of good information.

So what’s the difference between a commitment and an investment?

Commitments are discrete; investments are continuous.

Let’s say you’re skiing, and the lift is broken. You plod up the mountain with your skiis, investing in the ride down. At some point you realise the slope is a bit steeper than you thought, and not a good match for your ability. You decide you’ve invested enough, and put your skiis on, and off you go. Only the effort you’ve spent is committed; you haven’t made any future commitments. The decision is a continuous one, and can be changed at any point, dampening future consequences. If it’s a bit too steep for you you might feel a bit uncomfortable and you’ve still got a chance of crashing, but at least you were able to stop when you did.

A commitment is jumping out of a plane. If your parachute doesn’t work, you can’t change your mind half-way down and decide you’ve had enough. The future consequences are unavoidable.

I think of investments like a slope of expired options against time, with the steeper slopes being heavier investments, and commitments being a vertical line. Sometimes investments can turn into vertical lines, like the V1 point at which a pilot is pretty much committed to taking off from the runway and can’t abort. Sometimes they can be unwound, but the unwinding can be painful, like plodding all the way back down the mountainside.

Investments in software development prove really interesting, particularly because of two human biases: confirmation bias, and the sunk-cost fallacy.

Together, they lead us to commit to the direction set by speculative investments, thinking that we have certainty and good information when we don’t; and to build on the investments we’ve already made, even if we do have information that they’re wrong. Sometimes the commitment is just a mental block. Sometimes we communicate it to others, creating reputational or contractual commitments. Sometimes we tie other decisions to the investment, making it a far heavier investment than it was before, until it’s practically a vertical line anyway.

Here are some common examples of speculative investments that I see in software development, and some ways of improving your process by making that investment smaller and lighter and less likely to invite commitment.

Research, analysis and design done a long time ahead of the actual development. (Yes, two weeks is a long time.) Prototype as soon as you can, especially if the solution is technically complex. Use the prototype for guerrilla testing. Keep your options open by having several different designs (concurrent set-based engineering, or in Cynefin-speak, parallel probes). Don’t worry about bits of the design which are easy to change; fonts and colours and spacing and even layout can be sorted out later. Bonus points to designers who can sit with the devs and help them tweak the final bits… especially if it means you learn a bit of code yourselves.

Backlogs that require grooming. This is another sign of speculative investment in the form of analysis. I find planning at the capability level is a good level of granularity at which to stop. Put them on cards or post-its and stick them on a wall somewhere. A big one-year trading project had about 37 cards. The projects I work on now are typically a few months long and have ten cards or so. Let the team break them down as they come to them. Focus on the riskiest ones that the team know least about, too, so that you can make discoveries and get the information for good decisions early. And minimize the work you’re looking at! If you don’t need it, don’t put it on the wall until you’ve done the stuff you need (and often, discovered what that really is). Everything else is an option, and options have value.

Yearly budgeting cycles. Most organizations do have a process for changing direction mid-year, but it’s painful. The cost of unwinding heavy investments often is. Bjarte Bogsness’s work on Beyond Budgeting is excellent for separating the different concerns of budgets like resource allocation and motivation and prioritisation, providing more flexibility, as well as being beautifully alliterative. Budgeting for half a year or quarterly lets you change direction more frequently. Concepts like BHAGs, True North and the One Metric That Matters (OMTM) can help departments to align, letting them make decisions locally, enabling greater trust and more autonomy for spending the money you’re giving them.

Leaving testing to the end. Doing this at the end of a project is going to hurt you badly, but even leaving testing to the end of a sprint means you’ve got two weeks of speculative investment of code. Devs, if you’ve got something working on your machine, and your tester is co-located, go and get them so they can see it. Chances are you’ve forgotten something. (Chances are good you’ll remember it as you’re walking across the room.)

Big releases without the possibility of rolling back… or without the information that tells you that you need to. Actually, this is a commitment rather than an investment, since you’ve got no choice but to enjoy the freefall. I heard of one company that had to cease online trading for months afterwards… or there’s Knight Capitol Group, which, well, it doesn’t exist any more. Don’t do big-bang releases with no rollback, unless you’re really sure that you’ve eliminated uncertainty or opened some options for yourselves through other means. (If this is the norm for you, you probably don’t have those techniques either. Start learning, because your competitors do.)

It’s all about investments and commitments.

These are just a few examples of speculative investments that I see in software and the wider organization, from code to corporate strategy. We’ll always have some level of speculative investment, because we need to move forwards and uncertainty always exists, but it doesn’t need to be heavy. Minimizing speculative investment is a principle which scales.

I’ve realised that just about every aspect of my job as a Lean / Agile coach and consultant is about minimizing these speculative investments and avoiding premature commitments; encouraging people to keep options open by creating safety (organizational, technological and psychological), minimizing queues and feedback loops and embracing the riskiest and most uncertain work so that information for making better decisions arrives earlier, helping people limit the work in progress with that “stop starting, start finishing” mantra so that the investments already in flight pay out or give us feedback earlier, clarifying direction to allow for swift and autonomous changing of decisions, and helping people communicate and visualize with greater transparency.

Everything decision we make, we do with the information we have. We often make the wrong decisions, and more so when we don’t have good information. Unless there’s something urgent going on (because chaos is often what happens when you make premature commitments), we want our investments in uncertainty to be probes; a Cynefin term which means trying something out that’s safe-to-fail, with feedback on whether it’s succeeding or failing and mechanisms for amplifying it or dampening it accordingly.

With investments, being wrong less doesn’t have to mean being right. It can mean being wrong with less money, in smaller contexts, for less time, with less stuff and fewer people.

That’s how we keep our most important option open: the option to do something else instead.