Channels ▼

Scott W. Ambler

Dr. Dobb's Bloggers

Agile and EVM Strategies

May 03, 2011

A few days ago on of the Agile Alliance discussion forum someone asked about applying an earned value management (EVM) strategy to agile development projects. The gist of EVM is that you track your actual schedule and budget results throughout a project against what you planned, the theory being that this provides valuable information which you can use to steer the project and also judge the percentage of expected value you've earned to that point. For teams following a traditional waterfall lifecycle, this is pure hogwash because the value of a consumable solution doesn't occur until the very end of the project. Agile teams take a much less risky strategy in that they produce more potentially consumable solutions (what Scrum mistakenly refers to as potentially shippable software) each iteration, producing actual stakeholder value in a visible, incremental manner. But, because agile provides much greater openness and visibility to stakeholders, artificial measures such as EVM typically prove to be overhead at best, whose only value is to cater to the dysfunctional bureaucrats infesting many organizations.

The discussion got me thinking about an article I wrote a few years ago for DDJ, where I questioned the value of EVM. My experience is that adoption of EVM in information technology (IT) settings typically reflects cultural challenges within the organization's project management community. However, I have to admit that when I visit organizations to assess the IT effectiveness, I love to discover that teams are doing EVM because it's an indicator that one or both of the following occur:

  1. Project teams likely aren't producing real value throughout the lifecycle. EVM is incredibly attractive to managers desperate to make it appear that their team is making progress even though actual progress is questionable at best. This is particularly true of traditional teams who invest a lot of effort creating specifications, creating detailed plans, writing lots of supporting documentation, reviewing various artifacts, and making big promises that they'll eventually get around to producing actual business value when they eventually finish up all the paperwork. So, when I see teams taking an EVM approach, there's an incredibly good chance they are struggling and need to be redirected towards a more successful outcome.
  2. The organization's approach to governing development is seriously flawed and senior management very likely needs remedial education in how development projects actually work. The first step is to have a frank discussion about the differences as to what gets reported by the EVM proponents and the actual results at the end of the project. It takes a few minutes, but it's pretty easy to get senior management to admit to horror stories where there were some nasty surprises at the end of projects where EVM was reporting good news throughout most of the effort. We've seen too many IT projects which reported that they were 90% complete, only to have them come hat in hand asking for sufficient time and funding to complete the second 90% of the effort.

The fundamental problem with EVM is that it has very little to do with earning value and everything to do with managing against what often proves to be naive/fictitious schedules and estimates committed to far too early in the project. Although EVM is interesting project management theory, and I have no doubt that it may work in some non-IT domains, it proves to be a really bad project management strategy in practice for IT development projects.

Although EVM can in fact be applied to agile projects, in my opinion EVM is a questionable practice, regardless of paradigm. Organizations that are trying to govern their IT project teams should monitor them in such a way that accurate and timely information is presented. This is clearly not the case with EVM. We have significantly better options available to us. Let's adopt them. More on this in future blog postings.

Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 


Video