Discussing Agile With a CFO

We can discuss potential NVP etc benefits in the context of any iterative and incremental method until the cows come home, but CFOs already get this. Just look at most non-IT projects run but the business (sales campaigns etc). 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.)

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? Really?

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. :-)

I personally believe that the above argument would hold good for any iterative process done the right way including RUP.

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

Sigh really?

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.

Vikas

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.

> 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 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?

Hi Vikas, interesting angle on the benefits of Agile. You mention frequent deployments as one of the business benefits of an Agile approach, which will certainly help expedite time-to-market and cut costs. However, have you considered the issues companies may face in handling these? Agile allows development teams to create more deliverables; however, this can result in a backlog for operations teams who have to struggle to deploy the applications as quickly as they’re being produced. Without a proper process in place, like automating deployments, these more frequent deliverables may very well turn into a business determent rather than a benefit. Have you seen much talk of deployment automation when discussing Agile benefits?

Have you seen much talk of deployment automation when discussing Agile benefits?

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?)

• 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)

• 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)

• 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.

No one has mentioned the regulatory guidelines and requirements for capitalization CFO's must follow! Or the advantages of "capitalized" vs. "expensed" project budgets. Not to mention SOX, SEC, auditors.....