Many in the agile community use the term "value" to mean business value, but in fact do not define the units of measure for this "business value." They leave that to the customer. The customer in many cases has no clue what it means to speak in "business value" outside their own business unit or possibly their own operational needs.
If we are to successfully connect the methods of Agile Software Development with business success, then there needs to be a conversation about what is meant by "Business Value."
Some in the agile community have confused the term "Earned Value" as it is defined in ANSI-748B with "business value." They do this through a simple mistake of not defining the domain, context, and units of measures.
Let's take a slight diversion and look at some classic comments from a vocal (but mis-informed) speaker about "value."
Earned value management is another lie – there is no value until the software is delivered. It is just not the right metric.
...this of course is the exact process of ANSI Earned value - measuring physical deliverables on planned boundaries - weekly or monthly for XP or Scrum - end of the Work Package for 748B programs (which BTW is usually has the Work Packages limited to one accounting period - a month)
Working software is the primary measure of progress. The primary measure of software development should be the delivery of working software which meets the changing needs of its stakeholders, not some form of "earned value" measure based on the delivery of documentation of the holding of meetings.
... and of course this is simplly misinformation. Meetings are Level of Effort in EV and documents are discrete only if they are called out as a deliverable in the contract (CDRL) or needed for the proper operation of the software system - the pilots operating manual for the aircraft or the maintenance manual. Measures of progress are ALWAYS in tangible evidence - Technical Performance Measures (TPM).
True earned value, not documentation-based “earned value”
... nope wrong again, "documentation doesn't fly," is a common phrase in our manned spaceflight and aircraft business. Measures of performance for documentation are rarely used expect for LOE. "Flying software," is the best measure of performance for a flight avionics system.
Proponents of Earned Value Management (EVM)claim that it is an objective approach to communicating progress to stakeholders, enabling you to declare that you're X percent done at any given point in a project.
... ANSI-748B and the DoD Earned Value Management Intent Guide (EVMIG) call out the use of Technical Performance Measures (TPM) and Physical Percent Complete. It seems the author has been talking to folks who would not pass the Earned Value Professional (EVP) test or a DCMA Validation.
Measures of Effectiveness and Measures of Performance are Critical Success Factors for all projects
Independent of the actual experience or capabilities of the author in the Earned Value (ANSI-748B) domain, the "value" in Earned Value is not the same as the "value" in business value.
- Measures of Effectiveness - The operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions.These are the "business value" measures seen by the customer.
- Measures of Performance - Measures that characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions.These are the software development performance measures seen by the development team.
Now that we've connected "business value" with "software development" value and addressed the unfounded conjecture that Earned Systems cannot be directly used with Agile's principle of measuring progress through working software it's time to see where this topic is being discussed with the proper background. The recent DoD Agile directive and the upcoming conference on Agile IT and the US DoD are places to seek information beyond conjecture.
In Earned Value practice, measures of physical percent complete are "taken" at the end of each iteration uses agile software development methods in EXACTLY the same way the measures of physical percent complete are "taken" weekly at the end of 0%/100% tasks or at the end of Work Packages on ANSI-748B DCMA Validated Earned Value Management Systems.
But that is for another time. Here's some more backgroud on using EV for "emergent" projects. Principles of Technical Management.
Connecting Business Value to the Measures of Performance for Software Projects
Here's an approach defining "business value" and developing measures of "business value" in the context of strategy - in this case IT strategy, and connects the dots between the value the business should be speaking about and the development of software intensive systems that implement that business value. And how to start learning how EV is "actually" used.
approach to communicating progress to stakeholders, enabling you to declare that
you're X percent done at any given point in a project.
