Discussing Agile With a CFO
The Chief Financial Officer is responsible for financial planning, financial reporting, financial analysis and managing financial risks. What would be a better language than finance, to explain the benefits of Agile to a CFO?
David Chilcott, started this interesting discussion on the Scrum Development group to understand the important points about Agile which would interest a CFO. Michael Spayd mentioned that he would certainly like to talk in terms of pure business benefit. According to Michael, he would talk about
- The benefits of frequent deployments by considering the NPV for a waterfall and an Agile project.
- The ability to stop a successful project when it is past its value realization curve.
- Capitalization vs. expense benefits in terms of how the investment of Agile projects is accounted for in the company's books vs. waterfall projects.
- Lower turnover on Agile teams thus leading to lower training and hiring costs.
Likewise, John Goodsen suggested that he is more inclined to use lean thinking than Scrum when talking to the CxO's. According to John,
I like to feel them out if they understand the difference between cost and throughput accounting, first, and then understand which model they are using. If it's the latter, you are on solid ground. If it's the former, then you have more work ahead of you. The follow-on conversation is about the cost of WIP, the cost of Delay and the value of Limiting WIP to establish flow. You might draw an ROI over Time chart that compares to traditional development showing short, frequent releases do not require as deep of an initial captial investment before you see a return.
According to John, the longer you wait to deliver value and receive money, the deeper the investment gets. Small features should be released on frequent intervals to establish a quicker return on investment. John has an interesting picture to show the ROI difference for an Agile versus a waterfall project scenario.
Trond Wingård presented his thoughts about Agile for a CFO by comparing the NPV (net present value), IRR (internal rate of return), payback period and ROI (return on investment) for a waterfall project and an Agile project. He laid down the criteria for his fictional project as
Let’s imagine a project:
- It is scheduled to last for 12 months
- During that time it costs 5 million USD
- The resulting product will provide a financial benefit of USD 200,000 per month (extra revenue or saved costs minus any monthly expenses), until
- The product abruptly stops producing its benefit 4 years after the project is started. You may say there’s a 4-year window of opportunity for this particular product.
- (I also assume a 10 percent discount rate in the NPV calculations
According to the calculations, the statistics for a going in a waterfall mode versus making one release every 6 months versus making a release every 3 months were as follows,
Likewise, Trond aslo compared the situation when there was a 4 month delay in the project. Still, as per the numbers, making frequent releases justified the financial statement
Trond's worksheet for the CFOs can be downloaded here.
Thus, there is enough meat to discuss Agile in financial terms with the CFO. The numbers under various scenarios adequately demonstrate the benefit of going Agile.
What has Agile go to do with it?
So two questions come to mind.
1. Does Agile/LEAN have any financial benefits which can't also be ascribed to *any* incremental/iterative method? (I.e. Is this a business case for going Agile? Or is it a business case for incremental/iterative delivery, and Agile is just an example of one possible way of doing this?)
2. Are you prepared to do benefits realisation? (And I don't mean "we delivered the software so the benefit must be there.") You need to be able to prove that you project is delivering value if you want to make claims like "we can drown the puppy when it's no longer of use" or "it generated 100k in value." Think sales campaign: we can ascribe sales to a campaign (offering via a channel) so we can determine stuff like ROI and identify the point when return dips below cost.You also need to factor in substitutions: generating 100k of sales on the new portal is nice, but but how many more sales is this than you would have received on the old portal? If there's no change then why did you bother with the investment?
NPV is calculated using interest rates. They are currently at 0.5% in England. You are adding unnecessary complexity that is unnecessary and misleading. The future cash flow projections in Business (IT) projects have massive variance which drowns any accuracy that NPV would add. For example, we predict a cash flow of £100 to £200 which we have made more accurate by applying NPV so the cashflow will be £99.5 to £199. Sound silly. It will do to a CFO as well.
The benefits of Agile/Lean are nothing to do with NPV.... or IRR or ROI. The benfits are all to do with business investment risk.
There are many real options in Agile/Lean that make it easier to manage risk than on a more traditional approach. ( even the option to change code and know you have broken something - TDD )
Lets drop the silly accouting talk. The business see straight through it. It reminds me of authors who want to sound techy by talking about sed and wak.
For more info on real options, ask Olav. :-)
Re: What has Agile go to do with it?
Regarding your second part, I believe that there are ways to do the value realization of software. Wouldn't you know if your sales on the portal are going up or down. Like wise wouldn't you know the if the cost of adding a new feature on the current platform is becoming increasingly prohibitive and thus you need to bother about the investment
I am sure that people understand the benefits of Agile as you correctly point out. Agilists like Michael and Trond are trying to give a financial perspective to it and make it interesting for the CFO.
It is more like the analogy that all of us understand the benefits and the need to save paper. Have you seen those messages in many mails which ask you not to print the email unless absolutely necessary ;) Some of who are environmentally inclined would like to think of saving some trees. Some of us who are financially inclined would also be interested in how it saves money for the organization and makes my books look greener :)
So the same concept, the same end goal but different lenses to look at it by different people. I believe that there is nothing wrong with that.
Also as Trond points out with his calculations and as John depicts in his picture you are managing business investment risk by releasing early and often.
You miss my point.
A CFO will have CIMA, ACCA, CFA or some similar qualification. They will have been using NPV, IRR etc. for many many years before hitting the executive suite.
Using NPV, IRR to communicate the benefit of Agile/Lean will simply telegraph your lack of understanding of Finance. It is NOT a good argument. When valuing the Cash Flows associated with the benefits of an IT related business investment, the NPV effect is INSIGNIFICANT compared to the risk associated with the cash flows themselves. Bringing those cash flows early to reduce the the uncertainty in the returns has huge benefit and it also has nothing to do with NPV.
If you want to communicate to the CFO, you need to explicitly talk about business investment risk and the real options that Agile/Lean offer to manage that risk.
I apologise if I'm being a bit harsh here but this is what I have been doing for a living for the past 15 years. I moved away from NPV 10 years ago when I worked on a project that created a business model using NPV. The cashflows estimates fed into that model were two orders of magnitude out.
The benefit is about risk. NPV, IRR etc. are a total red herring.
I think this is a very good point. This adds a lot of value to the discussion at hand. May be you are right that NPV and IRR are not good arguments and one should focus on business investment risk. Having said that are there other economies around the world where NPV is not that insignificant. I know you mentioned the example of UK but what about China and India? Could the NPV argument hold some weight there?
Another look at Agile
Re: Another look at Agile
Have you seen much talk of deployment automation when discussing Agile benefits?
The recent DevOps movement, with an emphasis on extending smooth flow through integration and deployment using automation and collaboration, is doing exactly that.
Re: What has Agile go to do with it?
There's also a number of incremental/iterative IT approaches which don't belong to the Agile/LEAN family. (Believe it or not, but RUP was conceived as incremental and iterative, it's just not practiced that way very often.)...
(I.e. Is this a business case for going Agile? Or is it a business case for incremental/iterative delivery, and Agile is just an example of one possible way of doing this?)
RUP was indeed a step in the right direction.
- It called for aggressive reduction of technical risk and an architecture focus.
- It transformed requirements into something that could actually be used as is to guide design and development (use cases), instead of the granular IEEE "the system must" statements more suitable for contract disputes
- It laid the foundation for empirical process control (feedback loops), as opposed to defined process control (plan the work, work the plan)
But IMO, RUP had two big problems (well, three, if you count the lack, of a UI modeling component of UML, but that could be bolted on)
- If used "out of the box" RUP was extremely heavy. Roles and deliverables oh my! It could (and should) be cut to fit, but to do that without breaking it, you had to understand why it worked. The same is true of Agile, and people are still cutting through the Load-Bearing Walls, and then saying, "we tried Agile but it didn't work."
- RUP didn't really have a built in mechanism for schedule and budget estimation and commitment, so it tended to be executed in a waterfall "but you promised" governance framework, with all of the attendant problems when the initial commitment was too optimistic (death march, mistakes and loss of discipline, throw people at it, loss of design coherence, loss of quality, rising bug count and swelling remediation work leading to even more schedule pressure etc)
What agile did was
- cut out a lot of the RUP weight (not needed for the vast majority of projects),
- built an estimation, planning, and scope management mechanism right in (the Planning Game, Story Points, and Velocity in their various forms), and
- reduced the batch size (cycle length) so that feedback control on plan, quality, and fitness for use could really work.
By keeping the product of shippable quality (though feature-incomplete) at all times, it's possible to do a true variable-scope project within a schedule and budget constraint without generating a lot of waste. And that alone solves the estimation-and-commitment problem.
I once heard Bob Martin convincingly argue that eXtreme Programming (XP) was actually a small subset of RUP.