So the project or release or iteration is done. We’ve “finished”. The customer and users are (hopefully) reasonably satisfied, and we say that we’ve delivered the software.

There’s a second hidden deliverable that we don’t usually think about and that’s the malleability of the thing we’ve just delivered. How easy it will be to modify the software in the future.

We can think of it as the “potential cost of future change”.

Even though we cannot measure productivity and estimating this future cost is likely to be either impossible, pointless, or both; it still may be a useful concept.

Once we start to treat the potential cost of future change as a deliverable in its own right, we can have important conversations with the team/customer/user. We can trade off the potential cost for future change against getting the next thing released as soon as possible.

We of course have the technical debt metaphor  and this concept is strongly related. We can phrase it in such a way as: “we’re going to deliver feature X but we want to keep the potential cost of future change as low as possible” or “it’s highly unlikely that we’ll ever need to change it so we don’t care about potential cost of future change” or “we need to get something into the market to test the water ASAP so initially we don’t care about the potential cost of future change”, etc.

While this diagram could do with some work, it may prove useful.

So according to this diagram, we can increase the speed of the delivery of feature vNext but this may mean an increase in the potential cost of future change and an increase in the amount of technical debt. Conversely, as we reduce the speed of the delivery of feature vNext, the potential cost of future change and amount of technical debt may decrease.

SHARE: