12 March 2008

Measuring the Cost Benefit of Agile

Currently at the office we are doing a pilot project using Agile development methods. For the most part, I think Agile is a great idea.

The concept of short iterations is a lot more sensible than trying to get everything done up front with the customer only involved at the start and the end of the process.

I could go into the reasons why, but there are many other resources that do that better than I could in this forum.

However, I have a couple of issues with Agile. The first is that too often people don't consider the larger business context of the development process.

Question: How do you justify a project to a bean counter?
Answer: With a measure of the cost vs. benefit.

Question: How do you quantify the cost of an Agile project?
Answer: Use something like AgileEVM

As the article referenced above states, Earned Value Management (EVM) is a well established and accurate measure of a project's cost performance. Anyone who has ever had to manage a budget knows that tracking the cost of a project is an important part of managing a project portfolio. This does not change if you use Agile development.

I have had to justify too many projects to the people with the money to ignore some form of EVM just because I am using a lightweight development methodology. In my experience measurement is a necessary piece of the overhead and that means implementing some form of tracking actual performance within your Agile process.

So the idea to take from this is that Agile should work within the larger business context, not separate from it. It should provide a useful measure for the people responsible for spending the money wisely (e.g. AgileEVM).

Next: Design/application architecture within Agile.

9 comments:

  1. I missed something; EVM in any form is useful for managing/contolling projects, but where is the "Benefit" measurement mentioned in the title of your post? It doesn't really how good your project is if no benefit will be realized by carrying it out.

    ReplyDelete
  2. Josh Milane10:03 am

    I dont understand David's comment.

    And I dont understand why I am not on your blogroll.

    Best,

    josh :)

    ReplyDelete
  3. I am guessing the hypothetical project in this discussion has an established benefits plan before the work begins.

    I am thinking that in an agile development each iteration should be making a contribution to the business case. Maybe not directly, but there should be a link.

    For example, when starting off with building user logins there is presumably a logical link between being able to log in and the benefits plan.

    I haven’t clicked through and read the Agile EVM article yet, but it’s an interesting idea that each package of delivered work should be able to justify itself.

    If you are thinking like this you are thinking of not just earned value, but value management. And you are no longer living exclusively in Agile world, you are now dealing in good old generic project management and customer service.

    My 2cents

    ReplyDelete
  4. PS Josh - you are in the RSS feeds we have down below. How could I leave your great blog out of my regular reading list.

    ReplyDelete
  5. To answer David, what Craig said is correct. Pardon my poor wording choice - I should have made that clearer.

    ReplyDelete
  6. Ilja Preuß3:07 am

    I'm not sure I understand why that's an issue with Agile. Is there something in Agile that says you shouldn't do it? Or something that makes it harder to do?

    I'd actually think that with the short feedback cycles, it would in fact be easier, but perhaps I'm missing something...

    ReplyDelete
  7. Newbie.

    I'm not very agile, just flexible. I'm not sure what the document overhead there is/isn't in Agile. I guess it's defined somewhere, but then maybe again - it isn't. My point is that I firmly believe the best way to define and measure what I mean by progress is in a use case diagram. Never met a user or a pm who couldn't understand one. They'll soon tell you if it's wrong if they don't understand it! That's the beauty of it. Don't laugh at me it works. It's only stick men and ovals, right? Of course, it's all about getting the right use cases. I wrote a pattern language called the Inflatable Facade Pattern Language for Requirements. Works for me. Anybody want to look at it?

    Peter

    ReplyDelete
  8. Peter

    Love to see your model. You can email me direct via a link on the left of the front page, or you can open up a discussion thread a Modern Analyst if you prefer.

    ReplyDelete
  9. Ilja,

    Everything I've read about Agile only talks about tracking burn down rates. EVM requires at least one more measure to calculate cost performance index etc. and that is actual cost.

    Since I am new to Agile, I've been trying to figure out how to meet a lot of the business requirements I still have while working within Agile and this is one of the answers I found that I thought I'd share.

    Janet

    ReplyDelete

Search This Blog