From AccuRev
May 9, 2011 In a recent Dr. Dobbs' report, IT expert Scott Ambler claimed that an earned value management, or EVM, strategy is not necessary for Agile software development projects.
EVM helps organizations track their schedule and budget results throughout the life of a project. By comparing actual outcomes to those planned, the idea is that EVM enables team members to gather information that can help to steer the project. It is also meant to enable project managers to determine the percentage of expected value that has been earned at a given point in time.
Ambler claimed that, for teams using a traditional waterfall software development model, EVM is "pure hogwash," since the value of a waterfall-designed project doesn't come into being at all until the project is completely finished.
While Agile software developers take a "much less risky" approach by producing potentially consumable solutions in each iteration of development, some have suggested that it is more compatible with EVM. According to Angler, this is not the case.
"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," he said.
In addition to software development, Agile is now used for a range of other tasks. According to a recent ITWire report, it may be possible to reduce business intelligence costs by up to 50 percent with the help of Agile.
First Things, First
In the EV world, validation of the processes, either formally or self-validation is the starting point for credibly apply EV to a project, a program, or across all programs in a company. One of the assessment questions is obvious. Are the people in the organizations, from management down to those responsbile for managing the work, trained to use Earned Value?
No, then get them trained. It takes all the challenge out of applying EV - or any process for that matter, Scrum, RUP, CMMI (I know this is not a process) - if people are trained. But more importantly, management is trained and signs off on the process. There is a signature block on the EVM System Description (either in the Advanced Agreement or the post award agreement) for senior management.
To do otherwise simply lays the ground work for failure of both EV and the project using it. And then lays the groundwork for the un-informed to come along and say "see EV doesn't work." "Senior management is mis-using EV." "Engineers aren't getting any value out of EV."
Don't do stupid things on purpose.
Let's take a closer look.
- Earned Value measures progress as "physical percent complete" against the planned percent complete." This "value" is earned minimally in large government contracts monthly. Many projects make this measurement weekly, even on large complex, software intensive projects. Here's an example Weekly Earned Value Method.
- The notion that in "traditional waterfall software development ... the value does not come to the end," is seriously misinformed. First FAR 34.2 and DFAR 252.234-70002 call out "periodic measures of performance" for projects. The Contract Performance Report (DID 81664A) calls outs monthly reporting of EV performance.
- Earned Value should be seen as a measure of the prodictivity of the budget assigned to the work. With this measure, the forecast of the total budget's performance is developed.
So the notion that projects are managed this way is actually "against the law," the Federal Acquisition Regulation. So maybe a bit of homework would have turned this little fact up.
Now let's look at another seriously misinformed notion.
- I wonder if Scott has actually worked on a software intensive EV program. One that produced the CPR monthly or even bi-weekly on 1/2 billion to billion dollar programs. I get the sense Scott is making this stuff, has some bone to pick, or is just a curmudgeon.
- It turns out of course Earned Value, using Work Packages, with standard durations (crossing only one accounting period), with tangible evidence of physical progress to plan (the WP deliverable) are nearly identical to Scrum Iterations, at the planning and execution level.
- I love to quote "it may be possible." Lot's of things are possible, and when you add "may" that pretty much opens the universe to possibilities.
So what's the problem here?
When we get vocal and highly visible voices speaking about topics ut their area of expertise it probably doesn't really matter. Unless the voices have a platform to confuse those actually needing help.
- DoD's IT budget is something around $36B.
- EV is part of this procurement process.
- Successful deployment of IT in DoD is not a poster child.
- DoD OSD has initiative in the NDAA Section 804 to provide (2)(A) early and continual involvement of the user, (2)(B) multiple, rapidly executed increments or releases of capability, and (2)(C) early, successive prototyping to support evolutionary approach.
- More details can be found at recent NDIA C4ISR meeting.
- Finally While Agile software developers take a "much less risky" approach by producing potentially consumable solutions in each iteration of development, some have suggested that it is more compatible with EVM. According to Angler, this is not the case. I'd ask for references. If we're looking for an example of Pure Hog Wash, this is a prime example.
When there is simple misinformation being proffered by thought leaders it's troubling at best. At worse it's just plain old counter productive. I'd invite Scott to use some of his travel budget and come visit some software intensive sites to see how "agile development processes," and Earned Value are used weekly.
Maybe some discussion with those actually doing the work of integrating agile with EV might provide Scott with insight on how this works, why it is critically important to government procurement and enterprise IT, and maybe, just maybe provide a mechanism for improving the credibility of those voices claiming things that just are true.
