FDD/Agile Development Metrics

Hi all,

Can anyone point me to metrics that demonstrate the advantages (or disadvantages) of adopting an agile development methodology and/or FDD? I'm looking for things like cost savings, defect density, SLOC/hour, etc.

Thanks a bunch! :)

-- Patrick

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Jeff De Luca's picture

Try Looking At Some of the Techniques

Hi Patrick,

I don't think you'll find anything scientific, only anecdotal. Unfortunately, many are not interested in measurement and experiment, they are only interested in "do this because I say so, and if it doesn't work for you then you must be doing it wrong." I'm not aware of a study of any agile approach that I would value.

In terms of FDD what directly inspired me in how I run projects is metrics and studies etc. There are a large number and I reference several in my workshops, but Capers Jones books are a good source. McConnell's Code Complete is a good summary of a large number of these. What's nice is that he always references the study. That book is a good place to start, then you could go get the referenced materials for those areas that are of most interest to you.


Thank You


Thanks for the reply. I'll check out the references you mention.

-- Patrick

Look at profit and cashflow

Profit, ROI and cashflow are the most important measures. If you release your product earlier than you would if you did it by waterfall, then ask your customers to quantify how much more money the product would earn.

For instance, my last project was (predicted to be) worth £20M / annum, but it was roughly 3 years before any money come in. It was built using waterfall, so had one release. If they had been technically able to release partial products, then they would been able to earn roughly £10M / annum after 1 year. You do the maths from here ...

Jeff De Luca's picture

But is any of that Agile?

Sure but what you're describing is staged delivery. If I planned to have 3 releases - year 1, year 2 and year 3, I could achieve the same thing and I could do each release using waterfall.

Also, your maths presumes that whatever function can be delivered after 1 year is able to deliver a return of exactly 1/3 of the original 3 year delivery. I don't often see such linearity but I'll concede this is entirely situational.

Whether any of this is even Agile is another matter. Some equate planned staged delivery to incremental. Some equate incremental to Agile (and thus a lot of projects going back 20 years can fit that).

Being Agile means (in general) we are more able to adapt to incremental delivery out to the field and where that delivery does have a meaningful return. But in your example, I could achieve the same thing by planning staged delivery (three projects, one year each and I could run each using waterfall).