From the Trenches: “Real” Real Options in Large-Scale Agile Development

An option is defined as the right, but not the obligation, to take an action in the future. In order to gain this right, one has to spend some upfront cost, which is buying the option. The option is an asset, hence it has value. The higher the uncertainty around the decision tied to the option, the more valuable the option–obviously because it gives the right to walk away and incur just the cost of buying the option. The real options method applies financial options theory to quantify the value of flexibility in real assets and business decisions. And both common sense and the theory demonstrate that the higher the uncertainty, the more it makes more sense to wait to act and defer the decisions.

So far, so good?

Yes, only if you are sure you have bought the option and have accounted for the cost of doing nothing today. This is where the agile mindset and architecture reasoning start diverging , when in fact they could be the best of friends. Agile projects rely on implementing those features that are certain to be required and postponing those that are less likely to be in the system. If such features turn out to be needed at the end and require extensive restructuring of the system, especially in large-scale development, relying only on code-level refactoring often does not suffice. Spending some time architecting can provide better options in many large-scale development contexts that struggle with applying agile techniques. The cost and benefit tradeoff is often made between “do nothing” and “spend a lot of time on something you may not need.” While the concrete benefits of having real options require the tradeoff to be made between “do nothing, possibly suffer a lot later” and “do just a little,suffer less later” (Anyone interested in immersing themselves more into the background and a suggested application of real options to architecture-design decision making can check out our work in quality attributed based economic valuation of architectural patterns).

The agile mindset relies on recognizing and managing uncertainty. The YAGNI principle–you ain’t gonna need it–is not just a catchy software-development pop-culture phrase; it has its roots in Nobel prize-winning options theory,  used to value both financial and real assets. As we progress with our digging, we verify our initial intuition that real-option and technical-debt analogies need quantitative clarification from an architectural perspective. We see them very closely related in many contexts. For example, by setting up an infrastructure for possible scalability–that is, buying the option of scaling up–you can reduce your technical debt down the road. By choosing to take a shortcut–not buying the option–you incur possible technical debt.

Oversimplifying the real-options analogy in large-scale agile development can in the long run lead teams to failure. Not taking into account the long-term implied cost of doing nothing today–in other words ignoring the possible high exercise price that may need to be spent down the line–results in not engaging in development and architecting activities that can reduce further development, operational, and maintenance costs. It is human nature to get carried away with the simplicity of dealing with today’s problems in an easy way. It often leads to not taking into account alternative strategies that still can be implemented with the given resources, yet preparing the system more for the future; in other words, incurring less debt.

Some simple measures can go a long way:

1)      Evaluate the consequences of doing nothing today in light of costs, both for the current release and the future releases. The key here is assessing the possible hidden costs of applying YAGNI principles in the future and comparing them with other possible actions.

2)      Assess technical decisions both for their option costs and value, and their technical-debt costs and value. Such a dual perspective helps specify them further and more importantly bring awareness of their potential and risks.

3)      Consider real options in the form of small architectural steps that can be taken in earlier iterations along with options in the form of foregoing any action due to high uncertainty.

We are currently on the drawing board working on bringing better guidance to managing options and technical debt, which we see as the key to managing the optimal balance of architecting within fast-pace, high-uncertainty agile environments.

Ipek Ozkaya – SEI

Advertisements

One response to “From the Trenches: “Real” Real Options in Large-Scale Agile Development

  1. “do just a little, suffer less later”: I agree this can be an attractive proposition, which I wrote about a few months ago: http://cyrille.martraire.com/2009/08/technical-options.

    However, when looking at real cases, I don’t believe that “buying the option of scaling up”can be considered an example of “doing just a little”.

    I would only suggest “buying” technical options when you are so close to the actual business that you can have deep insights on what is stable Vs. what is likely to change.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s