Introduction

Change: Ally or Enemy?

Kent Beck, during a workshop on XP for capitalists, provoked the audience by proposing that XP could create ten times more value than a heavyweight process. How can this ever be possible? Consider the two fundamental premises of XP.

1. Change is inevitable. Just about the only thing you can predict with some certainty is that change will happen. In Extreme Programming Explained, Beck emphasizes this point.

   Everything in software changes. The requirements change. The design changes. The technology changes. The team changes. The team members change. The problem isn't change per se, because change is going to happen; the problem, rather, is the inability to cope with change when it comes. [Beck2000]

2. Change is easy. The cost of change does not rise exponentially as the system grows. Contrary to popular belief, the rise in the cost of change gradually diminishes.

   We don't question premise A. We take it as a given.

   XP is a lightweight methodology for small-to-medium teams developing software in the face of vague or rapidly changing conditions. [Beck2000]

Premise B is more controversial. We don't know whether it's true or whether it is universally true. We don't know whether it is a consequence of the 12 XP practices or of the advancements in software practice and technology in general. Thus, we will condition our conclusions and insight on the truth (or falsity) of premise B. For the time being, let's take it as a given as well.

Consider the following XP principles and practices.

1. Embracing change

2. Simple design

3. Small initial investment

4. Incremental change

5. Small releases

6. Continuous refactoring

How does one get from the premises A and B to the principles and practices 1 through 6? At a gut level, if change is inevitable, naturally the best way to manage it would be to embrace it. It all seems to make sense, but the cause-effect relationships between the premises and the resulting principles and practices of XP, as well as among the principles and practices themselves, are more subtle and complex than they first appear. True, a flattened cost curve would make 1 through 6 possible. But why would it also ultimately make XP more profitable? True, investing in a complex design would not make sense under highly volatile and vague requirements. But wouldn't this argument hold under an exponential cost-of-change curve even more strongly than it does under a flat cost-of-change curve? So again, how does XP create more value here?

The answer lies behind a crucial characteristic of XP: flexibility. Change is driven by uncertainty. At the heart of any process designed to cope with uncertainty is flexibility. Embracing change means treating uncertainty as an ally rather than viewing it as an enemy. Embracing change means embracing flexibility. Most of the principles and practices, indeed most things that are fundamental to XP, can be in one way or another traced back to flexibility. And flexibility creates value under uncertainty. The more uncertainty there is, the more value it creates.

What Is It with Flexibility, Anyway?

Flexibility can be viewed as an option.

Nobel Prize Lecture in Economics, 1997

This simple yet provocative statement, made during the conferral of the most prestigious prize in economics, forms the point of departure for the discussion of the economics of XP.

Let's begin by considering a simple example of flexibility: a fully refundable plane ticket. Such a ticket gives its holder the flexibility to recover the full cost of the ticket in case of an unexpected event. In other words, the customer has the option to exchange the ticket for its cost on or before the travel date should such an event occur. The flexibility provided by the option is desirable if the future is uncertain the more uncertain the future is, the more desirable the flexibility is. The customer can think of the ticket as a risky asset: If such an event occurs, without the flexibility, the ticket will be worthless; if everything goes well, the ticket will preserve its value.

A refundable ticket costs more than a nonrefundable ticket. Why? Because customers are willing to pay for the additional flexibility, which protects them in case of a negative development, or if they simply change their mind. The airline company demands a premium for this option over the price of a nonrefundable ticket because by offering a full refund, it risks flying with an empty seat and incurring a loss as a result. Customers, by agreeing to pay for the additional flexibility provided by the refundable ticket, implicitly believe that the value of the option, with respect to the amount of uncertainty they are facing, is comparable or superior to the premium demanded by the airline.

Options, Options Everywhere

Options arise everywhere in the business world. Here are some more concrete examples from software development.

• A pioneering Internet security project with a follow-on opportunity in the growing e-business market: Undertaking the pilot creates the option to be a player in an emerging market. This is an example of a growth option [Benaroch+2000; Favaro+1999; Taudes1998].

• Development of a framework for a future product line: The infrastructure investment enables efficient generation of a multitude of closely related applications without committing to a particular one. This is an example of a platform option [Erdogmus2001B; Favaro+1998].

• Abandoning a staged migration project midstream when budget overruns overtake the expected benefits: The ability to stop adds value proportional to the losses that would be incurred with continuing. This is an example of an exit option [Erdogmus+1999; Favaro+1998].

• Developing a prototype before the full application to resolve technical and user uncertainty: Investing first a small amount to learn reveals the feasibility of the larger investment. This is an example of a learning option [Sullivan1996].

• Waiting to see whether the Java technology gains acceptance before migrating a stable application to Java: Waiting before committing may be a cheap way to learn. This is an example of a delay, or timing, option [Benaroch+1999].

These strategic options, both technical and business-driven, commonly arise in the general software industry, but the topic of the discussion is Extreme Programming. What is the relationship of XP to the concept of such options?