Applying Agile Software Development to Earned Value Management projects started in 2002 as the VP of Program Management at Rocky Flats Environmental Technology Site (RFETS) for Kaiser-Hill (a Joint Venture between ICF Kaiser and CH2MHill).
We introduced the software development process of eXtreme Programming (XP) and spoke about our efforts at several Agile Development Conferences.
That work continued with developing processes compliant with EIA-748 on DCMA-validated systems and with more speaking and writing at NDIA and PARCA conferences.
This set of briefing decks is the culmination of those efforts under the initiatives of the US DOD and other Federal Agency efforts to increase the probability of success for software intensive systems by integrating agile development methods into earned value programs.
- Getting Started - Managing Complex System of Systems Subject to FAR 34.2 and DFARS 234.2 by Applying Agile at Scale
- Executive Overview - Earned Value Management and Agile Software Development have much in common.
- First Comes Earned Value Management - Program success depends on many things ? technical and programmatic. Without program controls, the technical aspects of the program have no planning, risk management, performance assessment, and corrective actions needed to deliver the needed program outcome on the planned date for the planned cost.
- Opening Background - This is the background material needed to establish the core principles of Earned Value Management (EVM) and Agile Software Development (ASD), in this case, SCRUM. The PMB is one of the common data items between Agile and EVM, along with the Physical Percent Complete and the Capabilities Based Plan, which defines the Product Roadmap and contents of the Cadence Releases.
- Start with the End in Mind - The integrated value proposition of Agile and EVM, needs to be articulated up front. And revisited when we get stuck and can’t answer why are we doing this?
- Framing Assumptions - Framing Assumptions define and track key program assumptions that are made early in program development and throughout the program's life. Framing Assumptions serve as a form of risk analysis to identify uncertainties that may or may not be recognized as such.
- Foundations of Earned Value Management - Earned Value Management and Agile development have much in common. The measure of Physical Percent Complete used to forecast future performance is a critical success factor in both paradigms. Bounded assessments of progress to plan is another. Estimating is bottom-up in both EVM and Agile. This integration provides actionable information to increase the Probability of Program Success (PoPS)
- Performance Planning - Measuring performance in EVM is done, as 748–C states, by, objectively assessing accomplishments at the work performance level. Physical Percent Complete using 0/100 EVT does this best. Agile’s performance assessment is Working Software at the end of each Sprint. These two methods are nearly identical.
- Connecting the Dots - Earned Value Management and Agile Software Development share a common theme – Progress to Plan is measured by Physical Percent Complete (P%C) In EVM, P%C is defined by compliance with Measures of Effectiveness, Measures of Performance, Technical Performance Measures and Key Performance Parameters and assessed through Quantifiable Backup Data. In Agile P%C is defined as Working Software.
- The Requirements Elicitation Problem - In traditional programs ? technical and operational requirements are flowed down in the Statement of Work, Statement of Objectives, Concept of Operations and other contractual compliance documents. In Agile, requirements emerge from the needed Capabilities as the program progresses and working software is produced for the customer. These emerging requirements impact the integrity of the Performance Measurement Baseline.
- Planning, Budgeting, and Estimating in Agile - In Agile, Story Points can be used as measures of effort. In Earned Value there is no concept of Story Points, rather Dollars and Hours are the measures of effort and duration for the work. When using Agile on EVM projects, each unit of measure has value to the benefits produced through the integration, IF these concepts are properly segregated.
- Step-By-Step to Building the Performance Measurement Baseline - In Agile, the notion of the Performance Measurement Baseline (PMB) does not exist. For EVM programs, we need a PMB for reporting and contract management. Adjustments to the notion of Release and Sprint planning are needed to integrate these two paradigms.
- Dependency Management—With multiple Agile teams working on System of Systems development programs, dependencies will be a natural outcome. The complexity arises from the parallel development streams and is unavoidable for any non–trivial development effort.
- Risk Management - The naturally occurring uncertainties (Aleatory) in cost, schedule, and technical performance can be modeled in a Monte Carlo Simulation tool. The Event Based uncertainties (Epistemic) require capture, modeling of their impacts, defining handling strategies, modeling the effectiveness of these handling efforts, and the residual risks, and their impacts of both the original risk and the residual risk on the program.
- Change Control - on Earned Value Management programs differs greatly from Change Control on Agile programs. Replanning, Reprogramming, and Rebaselining are all allowed in EVM. Agile does this continually, so adhering to EVM guidelines is the starting point for integrating Agile with EIA–748–E programs.
- Physically Connecting the Dots - With the processes described so far, we now need to define the Physical connectivity between the components of Agile, program planning and control, Earned Value Management, and reporting.
- The Dark Side of Agile - Both Earned Value Management and Agile have Dark Sides. Things that are not talked about in public. However, when they are integrated, each provides a solution for the other's problems. Assessing current and desired Maturity for Agile and EVM is the starting point for integrating these two processes.
- Failure Modes of Agile Transformation and Program Performance Management - The root causes of Failure to Transform to an Agile Organization and Failure to Adopt Agile methods are two Critical Success factors that require correct actions for any Agile at Scale initiative to be successful.
- Maturity Models for Deploying Agile at Scale - Applying Earned Value Management to software development programs means establishing a governance foundation for that development effort. CMMI ? is one place to start. So is Agile development. Both CMMI ? and Agile have complementary processes that can be connected with Guidelines in EIA–748–E.
- Root Cause Analysis - Root Cause Analysis is the method of problem-solving that identifies the root causes of failures or problems. A root cause is the source of a problem and its resulting symptom that, once removed, corrects or prevents an undesirable outcome from recurring.
- Agile Contracts - FAR 15 and other contract clauses flow onto software development contracts where Agile is the development method. What does this mean for traditional government contracting?
- Conclusion - Integrating Agile on Earned Value Management programs is straightforward once the Bright Line is established between the PMB and the Agile Release, Sprint, and Story activities
- Agile + Performance Management Bibliography - This Collection of resources is the starting point for anyone interested in applying the principles, processes, and practices of integrating Agile development with Earned Value Management in the domain of Software Intensive Systems of Systems
