If Agile is not about making things cheaper for cost sake, although cost improvements as measured by economic value delivered to the P+L and asset secured to the balance sheet certainly are, how do we measure the payoff?
The decision we need to make in Agile software development is not just about cost. Nor is it just about Value, or maybe not even Return On Investment. Whilst all of these will have an influence, focusing on just the cost does not allow good economic decisions to be made.
It is not just about the number. For example, the statement that an organisation needs to save £x from its R&D budget needs to be examined very closely to discover why this reduction is deemed necessary. It could be that this level of expenditure is necessary to support the development of the new products and the revenue streams that support it, so why the need for change? Now if the revenue stream does not support the expenditure, then isn’t it about reducing the capacity of the R&D organisation? And if this is so, then what has that got to do with Agile?
There are a number of variables which can be measured, referred to as proxy variables, and the tendency is to try to use these in isolation to make decisions. Just looking at Cost could be one of those. But what is possibly poorly understood is that these variables interact, and making the right decision is understanding how they do, by using economics. For example we can’t answer questions like “Which is less expensive: a 1-month delay or a $5,000 increase in expense?” or “Is this feature worth pursuing if it will take twice as long to implement?”, if we don’t take into account how these things interact. If the focus is only on cost saving then the increase in expenses is rejected, when in reality it could actually give the correct payoff in economic terms.
Cost Accounting and utilisation
The cost accounting model encourages management to look at resource utilisation, trying their best to achieve 100% in the belief that it is them optimised for costs. This is a false goal, as increasing utilisation is not conducive to optimising flow (just look at the M25 in rush hour!). Reinertsen quotes a formula:
Cycle Time / Value Added Time = 1 / 1 – rho,
where rho is the utilisation figure.
The aim should be to make left and right tend towards 1. For the left hand side this means that there is no waste in the system and that the time it takes for a piece of work to flow through the system is all devoted to value adding work (an almost impossible position, but worth targeting). For the right hand side it means that “rho” must tend towards 0, or in other words the utilisation figures need to reduce, which is against the instincts to save costs.
It is very likely that costs will be reduced as a result of implementing Lean and Agile approaches, but it is best treated as a secondary benefit, rather than a primary target, for the reasons outlined above. It could be considered a proxy variable, in the sense that whilst we are interested in it, it is not the primary target of the transformation, and that the real targets, like waste reduction, improved flow, etc, will lead to cost reduction. But these are better motivators and change agents than cost reduction.
So when your boss states that we must focus on costs and that is the ‘why’ he is implementing Agile you would do well to encourage a dialogue. That should be focussed and directed at
- what are the organisations problems
- why (the reasons) behind them
- how Agile methods might help address them
- En sure that the goal is about improving the flow of high value to the business from those reasons of failure
The best cost will be delivered through doing the right things better, not as a simple aim in itself.