Agile is a method, popular in software development, that is characterised by iterative and incremental practices which seek to exploit feedback cycles together with flexible and collaborative organisational structures (e.g., self-organisation, cross-functionality, adaptive planning) as a mechanism for coping with change and uncertainty.
Since the launch of its manifesto in 2001, agile practices have entered the mainstream in the IT industry and established themselves in terms of product development and project management. In fact, nowadays it has become so common to find pair programming, continuous integration and refactoring alongside a host of other activities, that software developers seldom think twice about the presence of agile in their workplace.
And yet one of the central claims of agile, that it adds value to the bottom line, has until recently received relatively little attention. At the heart of this claim is the suggestion that simply being agile improves the profitability of the organisation (e.g. ROI).
This is problematic because as anyone familiar with accounting will attest, profit is largely a matter of (accounting) opinion.
This means that any project sponsor, manager or team member needs to understand how to correctly measure the financial performance of their projects and become aware of how agile can improve it.
Profit is a matter of opinion
Ask the average person what they think profit means and the answer might be something along the lines of what is left over in revenues once costs have been deducted. This is fine if an organisation is involved in a single project, but becomes more complicated as soon as multiple projects are undertaken in parallel.
To see what the issue with a profitability measure is, one needs to look at simple example. Suppose that an organisation sponsors two projects, A and B, with direct costs of £550K and £800K respectively, along with shared indirect costs of £1M (e.g. facilities, software licensing, shared services). The total costs (and hence the profitability) of each project depends not only on their direct costs but also on the method for apportioning the indirect costs.
So, for example, if the £1M of indirect costs were to be assigned based on usage and if project A consumes twice as much as project B then project A would be attributed approximately £670K of the indirect costs and the remaining £330K would be assigned to project B.
This would result in a total cost for project A of £1.22M and £1.13M for project B. If, on the other hand, indirect costs were based on project team size and project B had twice as many members as project A then project B would be assigned approximately £670K of the costs, costing it at £1.47M whereas project A would assume £330K of the indirect costs, costing it at £880K in total. Therefore, it was the apportionment decision, not the projects themselves, that determined the profitability of the projects.
Value is all about the timing of money
The key to value in projects lies in the timing of their cash flows which, in turn, is related to the expected rate of return, i.e. what might reasonably have been expected to be earned were the money to have been invested elsewhere. To understand this concept, consider whether or not it would be better to have 91p today or wait one year for £1. What should one do?
If one could reasonably expect to earn 10 per cent p.a. on the principal, then either option would be fine since 91p invested at 10 per cent yields £1 (i.e. £1 = 0.91 x 1.1). If a lower rate is anticipated then it would be better to wait for one year for the money and if a higher rate could be expected then the 91p should be taken now and invested at that rate.
An accountant will tell you that 91p is the net present value (NPV) of £1 based on a rate of 10 per cent or, in other words, that 9p is the cost of having to wait a year. This principle remains the same whatever the expected rate of return is, though the figures of course vary.
The point to take away here is that delay erodes value since money invested today must accrue at a rate equal to or higher than the expected rate of return for it to retain or increase its value over a specified period of time. Common causes of delays in (software development) projects tend to include:
- Writing full up-front specifications before starting development
- Waiting until the product is finished before testing
- Delivering the final product only when everything else is completed.
These are precisely the hallmarks of phased product development that agile sets out to tackle, and it is the tendency of agile to avoid incurring unnecessary delays that lies at its value creating capability.
Where’s the value in agile?
Agile improves the bottom line of an organisation through the combination of the following two mechanisms:
- Prioritisation of high value deliverables based on the customer’s perception of value (e.g. backlogs)
- Delivery to market of increments (partially complete products) that ensure market validation of the emergent solution and a bringing forward of future revenues.
When combined, these elements will prevent a situation where the customer is waiting for high-value deliverables while lower-value ones are still under development.
It will also help to reshape the cash flows of the project by bringing forward future revenues and deferring future expenses. This will push up the net present value of the project, ensuring it contributes more to the organisation.
This dynamic also ensures that investment appraisals continue to be deemed viable for agile projects even under increasingly demanding rates of return.
Recalling the earlier example of how indirect costs are apportioned to projects, it is important for agile managers to communicate clearly how their projects contribute value by focusing on their net present value contribution and to ensure that appropriate metrics are used to assess their projects (e.g. avoidance of profitability or payback measures).
Implement agile budgeting
Since agile is incremental in nature it is fitting that the budgetary practices of agile projects should also be incremental. This suggests an alignment of the funding of agile projects with their resultant cash flows.
For example, accompanying every agile planning session (e.g. release planning) there should be a financial appraisal of projected costs and anticipated revenues on the basis of which the incremental funding of a project can be determined.
Following solution development and delivery of the increment, the appraisal can be validated against the market response to the product increment thereby ensuring appropriate feedback into financial planning for the next cycle.
Anyone who works with agile project finances must understand what profit means and how to appraise agile projects in a manner that makes clear the benefits they deliver.
The fundamental value dynamic of agile lies in the incremental delivery of prioritised (high value) deliverables that translates directly into the daily practices found in most agile teams. It needs, however, to be embedded into the wider budgetary process, which must ensure that agile projects are being measured correctly and reported in terms of bottom line value.
