There is an initiative to connect Agile Software Development with Earned Value Management. I've talked a couple of times on this topic. While here at the PMI College of Performance Management - the Earned Value Community of Practice - conference I was approach about contributing to PMI's effort to integrate EV with Agile in the new PMI Agile Certification.
My first response is - In what domain? Then the next response - do you have a mandate for EV? And finally - what are you trying improve?
The critical issue is what is wrong with the agile software development process you are using now? Is Scrum working to deliver products on time, on budget, and meeting customer needs?
If so, then what can EV add to the mix? Not much would be my contribution, on programs that do not have an EV mandate?
So let's invert the question. If you have an EV program - mandated by FAR/DFAR clauses, or internal company governance - how can Agile software development add value to the project? The answer is of course yes.
- Agile measures physical percent complete, so does EV through Earned Value Techniques (EVT) measures of progress to plan.
- Agile has bounded scope during the iteration, so does EV through Work Packages and Planning Packages on baseline.
- Agile postpones the details of work that is in the future, so does EV through Planning Packages.
- Agile manages risk through frequent delivery of working products, so does EV, when using a credible IMS and Integrated Master Plan with Accomplishments and Criteria for each Program Event.
- Agile provides for teams to manage themselves, so does EV with Control Account and Work Package managers.
- Agile focuses on deliverables, so does EV through the Work Breakdown Structure terminal nodes.
So what's the issue?
- EV is defined by ANSI-748B. All 32 criteria don't need to be in place, but 11 of the 32 do need to be there. Anyone making up their own version of EV should look to AACEI (International in I), UK MoD, Australia MoD, and most large construction firms use 748B as a starting point before defining the processes necessary for EV's application to projects.
- Agile and EV have much in common once you get above the noise of compliance and the theology of agile.
- Measurements of physical percent complete are needed in both domains. These should be the same in both domains - at least for software. The measurement is "working software."
- The architectural issues need to be worked out in agile. Coupling and Cohesion are critical concepts in all software and more importance in EV + Agile software for a simple reason. The forecast of future performance depends on credible estimates of the work to be done. Re-architecting, untangling poor architecture, refactoring the code to make it better costs time and money. That time and money has to come from somewhere. That somewhere has to be the Budgeted Cost for Work Scheduled (BCWS). That number is on baseline and not easily changed.
So in the end Agile and EV are buddies. But EV starts first, than Agile. The other way around is suggested to be possible. "EV Light," "AgileEV," what ever you call it. Call it anything, but if it's not traceable to the 748B criteria, I'd suggest it's not EV.
