In my last article I asserted that iterative development is one of the key practices that will improve development effectiveness. I speak from personal experience on this, and there is abundant literature that supports this claim. So why aren’t we all jumping on this methodology?
At one company I worked for it was the practice to capitalize most major new development projects. That is good because it allows us to postpone the expense of doing a significant amount of our development work until the results of that work are being offered for sale, thus making development more affordable. But it is also bad because it requires us to prove that we are developing an asset for which we will be able to recover the development costs in the future. Part of the burden of proof is called “technical feasibility,” and appears to be a significant impediment to doing iterative development.
Here’s a layman’s explanation: Capitalization is really a “deferred payment plan” for the cost of software development. Without capitalization, we would have to incur all of the cost of developing a piece of software up front, but we would not start recovering the cost of that development until after development has completed and we start selling the product. We are out of pocket for the cost of development until we have sold enough of the product to cover our cost, which would reduce our ability to do more development. When we capitalize development costs, we are deferring the expense for a period of time, usually 3 years, during which time we expect to cover our costs by selling the product. This is a bit like buying something on credit. If you pay cash, you incur all of your cost up front but your benefit happens over a period of time thereafter, while if you buy on credit you are paying for the product at the same time as you are benefitting from it.
But there is a price to be paid. To capitalize a project, we have to be very sure that the project will pay for itself – a bit like a credit check. Part of this requires a strong business case that makes us confident that the project will create enough revenue to more than cover the development cost, and the other part is proof of technical feasibility from development, which means that we can actually build everything needed to support the business case for the estimated cost. To capitalize, we are required to show that we expect to cover the deferred cost.
This is a problem for iterative development because in true iterative development, not everything is known up front. Typically the requirements are discovered and validated over a series of iterations as a release emerges. If you are doing iterative development, many things are not known precisely so how can we ever declare technical feasibility?
I believe this can be done, although doing so might violate (slightly) some of the principles of “pure” iterative development. Here’s how:
We need to have a starting point, so we use a base set of requirements as defined by Product Management to define a release. Subdivide the release cycle into a number of iterations, perhaps 1 per month, so a 1 year release cycle would have 12 iterations. The goal of the first several (3?) iterations would be to prove technical feasibility of the given requirements and thus would be non-capitalizable. Those iterations would be used for fleshing out the requirements, estimating, prototyping, and even coding. At a certain point, all of the base requirements should have good estimates and technical feasibility is declared. All subsequent iterations are then capitalized. This violated a tenet of true iterative development, but I think preserves the spirit.
I would combine this with one more practice, perhaps controversial. The committed plan for the release (i.e. the set of requirements that are covered by the estimates that are used for technical feasibility) should not consume 100% of the development capacity. This is reasonable because any responsible plan should include some contingency. If the committed plan is conservative because it includes contingency, it not only assures that the committed content can definitely be delivered on budget, it should also provide some “extra” capacity that can be used for new things that arise during the iterative process, whether new requirements or whatever. and this would provide a lot of the flexibility that iterative can take advantage of.
So I think that we can do iterative development within an environment that requires capitalization.
