Analyzing Xp With Options Pricing

There are four particularly important kinds of options that occur in real projects, and I think that XP supports the development of all of them.

Option to abandon: if you find that the overall business value of your project has diminished, you can abandon it. XP provides an explicit abandonment step. Abandonment value is increased by virtue of having developed and used core skills whose value is retained under abandonment. Many processes do not consider explicitly the idea of abandonment (except in terms of "failure" and "disaster").
Option to switch: this is very explicit in XP, the option to switch course that is created by the continuous re-evaluation of what you are doing and where you are going, and by not assuming a priori that you will never change direction.
Option to defer investment: This is the one I really am impressed with, because here XP really goes against the grain of IT conventional wisdom. Conventional wisdom says that you should always build in stuff early, even if it's not clear yet that you'll need it later. XP acknowledges explicitly that sometimes it's better to wait, because the projected value of making that early investment may not materialize. XP explicitly recognizes the value of your option to wait.
Growth option: investment to take advantage of a possible future opportunity. Well, okay, this is a little less clear in the case of XP, but the fact that XP encourages development of core capabilities that can be employed if the market opportunity explodes helps.

Now, here are the main factors that influence the value of any option:

the amount of investment required to obtain the option.
the value of the "prize" - the investment that the option allows you to make.
the uncertainty surrounding the value of the "prize"
the amount of time between when you have the option and when you have to make that contingent decision

Far and away the biggest influence of all those factors is the third one: the amount of uncertainty. This says that XP exhibits the most value in uncertain environments, where "anything could happen" in the external environment. In certain environments, where the future is stable and well-understood, a traditional plodding development process is fine, because you can predict exactly what you're gonna need and when.

-- JohnFavaro (also thanks to MaroanMaizar)

The finance theorists call the use of options pricing for evaluating projects 'Real Options'. However it is a bit iffy to use analogies with options on traded assets because they have peculiar properties. (Although it is quite a good way of justifying ludicrous valuations of dotcom companies :)

In particular with options on traded assets more uncertainty == more value and expected return on the underlying thing is irrelevant. In options on non-traded things this isn't necessarily the case. This is because with the traded asset you can (in theory) have a strategy to continuously buy and sell it and end up with something that behaves exactly like your option. You can't do this with an option on something which is not traded.

-- ChrisCottee

Actually, "more uncertainty = more value" even if an underlying asset of an option is non-traded. This is an artifact of an option's non-linear payoff. By definition, the payoff function is skewed towards the upside, so when you increase uncertainty, you increase the upside potential, but the downside risk remains limited. So the option value, which is in essence an expected value, also increases. The rational exercise principle -- i.e., exercise only if expected payoff at the time of exercise is positive -- ensures this. Tradeability has little, if any, to do with uncertainty-value relationship.

For valuation purposes, financial option-real option analogy may indeed be iffy. As a reasoning tool, this technical assumption is not that critical, especially when comparing alternatives. Think of option value as an "idealized value" relative to a hypothetical benchmark (an imaginary trading strategy replicates the payoffs of the option), as a ranking metric, not as fair market value. Besides, not all option pricing methods rely on traded-asset assumption. Use your favorite option pricing technique. It is even possible to get significant insight by valuing an option through good old decision tree analysis. Risk-neutral valuation, a popular option pricing technique, is attractive because it requires less information although it relies on tradeability. It's also easy to combine with decision tree analysis. Otherwise one needs to explicitly estimate a probability distribution for the payoff, which is not less problematic than tradeability.

-- HakanErdogmus (June 24, 2002)

Options pricing is a fine fit for XP thinking, both in estimating the value of an XP decision as well as in implementing the pricing models themselves.

Like XP, options pricing is itself an iterative process that needs to remain agile. Both decision trees and monte carlo techniques work for valuing real options. The underlying does not need to be a tradeable instrument. For more detail, see any book on real options valuation.

For a probability distribution, you only need to be approximate (and approximate is better than not trying at all). Most individual real options use only a binary probability anyway (%likely/unlikely), allowing groups of them to be valued using a binary decision tree.

For comparison, stock option valuations are a best guess approximation as well. They tend to use normal curves for a probability distribution, because it's a reasonable approximation and supports the use of (low-cpu) Black-Scholes valuation. But in real life, stock prices tend to follow something that looks a lot more like a logistic curve (fat tails, high peak), so normal curves aren't really appropriate. But people use normal curves anyway, because other people use them anyway, so the prices come out pretty close to the market consensus, except when they don't.

The 1987 crash was a fat tail event brought on by everyone selling tradeable instruments (S&P 500 futures) to simulate buying put options on S&P 500 stocks, while assuming nobody else would do that. That crash highlighted the normal curve flaw. Since then we've seen a lot more warpage in price models to make the normal curve sorta work. We also see more attempts at better pricing models, using higher-cpu techniques, including monte carlo. See "Dynamic Hedging" by Nassim Taleb if you want a painful but interesting immersion experience.

The 2008 crash was also brought on by a lot of people using a probability function that assumed that everyone else was using a different probability function. Again, the correlation caused everyone to try to sell the same thing at once. Unlike 1987, events in 2008 unfolded over the course of weeks instead of minutes (hey, maybe we *are* making progress!), which gave people time to doubt their pricing models. Uncertainty in pricing caused people to leave the market altogether, liquidity dropped, bid/ask spreads widened, money stopped moving. In late 2008 I expected it would take several months for developers to come up with new models, test them, get them into production, and get us out of the recession (and the "official" end to the recession came right on cue in June 2009. Hah!) Note that shops using speedier, more XP-like techniques would have been first back into the market.

As XP expects, our best guesses will be wrong at times. Options are tools that help us be less wrong more often. When option models do fail, they tend to fail big, but as in XP, the way to mitigate that is to iterate, iterate, iterate, never believe that we're done, and remember that we can't actually predict worth a darn. Taleb's "The Black Swan" is a good refresher on that subject.

Could the option to grow be the same as the XpMayScale?? Or perhaps XP abandons the value of this option in favor of the value of the other three. More the latter, I think

"Option to abandon" doesn't seem quite right: I happen to be reading the ProcessPatternsBook by ScottAmbler this week, and he hammers home that in the "Justify Stage" (one of the first things one does when a project starts), one must determine if the project is feasible, and kill it if it's not. I think that most methodologies do at least lip service to the planned "cancelability" of projects -- at the beginning, during the project approval process.

(In practice, the "Justify" stage is used to perform heavily slanted sales presentations to the GoldOwners. But that's another issue. ;-)

I think a big advantage to IncrementalDelivery is that it gives the users the option to abandon the project at (nearly) any time -- and still preserve the value (development effort) that has been invested thus far. That is, you have the "option to abandon, and declare the project a success."

I think the "Growth option" with XP would be related to maintainability: Because of DoTheSimplestThingThatCouldPossiblyWork and RefactorMercilessly, the system is highly maintainable and can be changed easily. With waterfall development, flexibility in ways that were designed into the system early on is easy, but changing the system in other ways is relatively hard.

-- JeffGrigg

Found this reference:

"Software design as an investment activity: A real options perspective," K.J. Sullivan, P. Chalasani, S. Jha, and V. Sazawal, in Real Options and Business Strategy: Applications to Decision Making, L. Trigeorgis, consulting editor, Risk Books, December 1999, pp. 215

Anyone read the book?

I haven't read the whole book, but I read the chapter by Sullivan et al. The authors discuss how to reason about some software development strategies as real options using decision trees and dynamic programming. Another article on software investments and real options is "Value Based Software Reuse Investment", by JohnFavaro et al. in Annals of Software Engineering, Vol. 5 (1998), pp. 5-52. John and I also wrote a chapter on this for the book XP Perspectives, entitled "Keep Your Options Open: Extreme Programming and the Economics of Flexibility". You can find it at at http://www.favaro.net/john/home/index.html -- HakanErdogmus

See more financial arguments for XP at FinancialEffectsOfIterations.

CategoryExtremeProgramming