Within the Agile development community, Chris Matts is well-known for discussing in great detail the concept of Real Options, and how it can be used to better software development.
I’ll let you take a minute to look at the wikipedia post….yep, I don’t necessarily understand a lot of that either. I like to think that I’m at least vaguely intelligent, but there’s an intense level of background knowledge required to really understand what is described there.
When it comes to software development, Chris and Olav Maassen have a decent InfoQ post that is a bit easier to understand. One point from that article is what I want to talk about here:
“To use a familiar phrase, Real Options is about "deferring decisions to the last responsible moment," which is an explicit principle in the Lean Software approach. By avoiding early commitments, you gain flexibility in the choices you have later.”
The part of the InfoQ article that I think best summarizes “The Last Responsible Moment for dummies” is the following:
“Given any decision to be made, there are three possible decision categories, namely, a "right decision", a "wrong decision" and "no decision". Most people think there are only two; you're either right or you're wrong. As we normally do not know which is the right or wrong decision, the optimal decision is in fact "no decision" as this defers the commitment until we have more information to make a better informed decision.”
Let me give a dummy level example.
In conversation with a client, we were discussing very high-level requirements for a particular application, let’s call it Project A. There were something like a couple of dozen requirements, a few of which would be impacted by another project, let’s call it Project B. The timelines for both Project A and Project B were not fixed, but both were priorities.
Unsurprisingly, the conversation around the impacted requirements started to turn towards how they would be implemented, as if Project B was implemented before hand.
What became very clear, and which I emphasized in the discussion, is that we didn’t need to make any decisions at this time about those requirements. If Project B was implemented before hand, we would need to consider the options available given that assumption. If Project B wasn’t implemented before hand, we would need to consider the options available given that assumption. But, since we couldn’t know at this time what the status of Project B would be when Project A was being implemented, the best thing to do was to not make any choices but instead to lay out the possible options, and leave it to a later time to decide which option we should ultimately take.
In some sense, this is just common sense, but there’s a tendency when laying out even high level requirements to think that you have to make a choice right now. But, you don’t have to. Making a choice seems to be equivalent to making progress, but it isn’t. Leave your options open until you have to make a choice at that time, and no sooner. If you make a choice sooner than you have to, you will often find that you have to change that choice down the road.
Don’t be irresponsible when it comes to choosing the right option. Instead, wait for the last responsible moment in choosing your option.