Lately I’ve been thinking about the value of ideas, particularly in the context of an Agile software development project. In the Wikipedia article, “Time Value of Money,” we read:

“The time value of money is the value of money figuring in a given amount of interest earned over a given amount of time.”

Simply said, the value of money increases over time due to interest. (“Interest” in this context indicates the return on the investment of the money). Not exactly a revolutionary concept.

In stark contrast, the value of “feature ideas” in a software project has the opposite valuation over time. Ideas that seem vital upfront gradually lose their luster as a project develops. A definition for the “Time Value of Ideas” might read:

“The time value of ideas is the value of an idea (or feature) figuring in the amount of interest lost over a given amount of time.”

Simply said, the value of feature ideas decreases over time due to loss of interest. (“Interest” in this context indicates the emotional attachment of the client to the ideas as the product takes shape. This is especially true of perceived value).

The Time Value of Ideas (TVI) is Opposite of the Time Value of Money (TVM).

The Time Value of Ideas (TVI) is Opposite of the Time Value of Money (TVM).

We’ve all seen it. Day one, the customer has a long list of features they just know are “must haves.” Two weeks in, new ideas emerge, and the old ideas start to look a little moldy. Four weeks in, a whole new batch of ideas come cropping up (even better than the batch at week two), and suddenly the client doesn’t seem to care about 25% of their original list.

What’s a guy to do?

Here are some common responses to these new, shiny but unplanned ideas:

1. “No, that’s not in scope. Sorry.”

While hard lining is excellent at controlling scope, it almost always means you’re not building the best product possible. Also, it’s a great way to make sure the customer is unhappy with both the end result as well as your relationship.

2. “Well, that’s not really in scope. But let’s make a change order so you can have it.”

Congratulations, you’ve just entered into the joyous dance of pricing features, or (even better) “horse trading” one nebulous idea for another. The customer is happy… sort of, but you rarely come out ahead on these trades, even if you do get more cash. Plus, on a personal note, I hate this process.

3. “Sure, we can fit that in!”

This is a great way to keep the customer happy, and lose your business in the process. Plus, try holding the “hard line” with a customer after you’ve pulled this move--Impossible.

So, is there a better way?

Absolutely. Go Agile. (Cue music, sunshine, clouds parting, blue skies, and rainbows.)

Absolutely. Go Agile. (Cue music, sunshine, clouds parting, blue skies, and rainbows.)

The Agile approach to software development (sometimes referred to as “lean”) values learning over planning. As a result, it values the ideas learned from building, using, and releasing over the ideas generated at a project’s inception. Explaining to your customer at project kickoff that all their good ideas for features are simply “candidate features,” and that they can re-prioritize between them (or add new ones!), frees you from worrying about what may or may not have been in the original scope.

This also means that as developers we avoid selling our work based on the traditional big-upfront-price-tag approach. Instead we sell our clients individual “sprints,” each at a fixed price based on pre-set time frame, team size, and measure of effort. In the end, by letting the customer prioritize specific features within each sprint, the whole “Time Value of Ideas” problem literally disappears.

Want proof?

We recently finished an 8-sprint project where we let the customer define, prioritize, and write stories about any feature they wanted, regardless of whether or not it was in the original “feature catalog” or not. By the end, we had made so many changes, improvements, and zig-zags based on what the customer learned from their real users, the product barely resembled the original vision. At the same time, by holding regular checkpoints at the close of each sprint, we still ensured that a holistic product was assembled.

The final product matched the customer’s current ideas about the product, not the ideas they had 16 weeks earlier. The old ideas had dulled and lost value, while the new ideas (the ideas that actually made it in) were still bright and beautiful.

The old ideas had dulled and lost value, while the new ideas (the ideas that actually made it in) were still bright and beautiful.

We also avoided devaluing our time and effort by accepting new features for free. New features were added and prioritized without having to back track or redouble our efforts.