The 12 Principles of Agile Software Development fit very nicely with the principles of Agile. Here's how

1. Integrating
Agile Software Development
with
Earned Value Management
Presented by Glen Alleman

2. Today’s Briefing
§ How can Agile Development methods increase the Probability of
Program Success (PoPS) on Earned Value programs?
§ How can Agile development be integrated with the FAR / DFAR and
OMB mandates for program performance measures using Earned
Value?
§ What are the “touch” points (or possible collision points) between
Agile and EIA-748-C?
§ What are the measures of success for Agile methods in the context of
EIA-748-C?
§ How can Agile Development methods increase the Probability of
Program Success (PoPS) on Earned Value programs?

3. In case we’ve forgotten what EIA-
748-C says
§ EIA-748-C, page 1, defines the top level
activities for a successful EV based project.
§ We need to “connect the dots” between these
and agile development.

4. 12 Principles of the Agile
Manifesto

5. A Glossary
5
DODI 5000.02 Agile
WBS – displays and defines the product, or products, to
be developed and/or produced.
Backlog – a list of deliverables which the team
maintains.
Deliverable – a tangible outcome delivered to the Government from the program
Task – lowest level work activities on the program, where budget and resources assigned to produce deliverables.
Program Event – An assessment point that occurs at
the culmination of significant Program Event in the
Integrated Master Plan.
Release – on CODE: CoDR, SRR, DS-Interim, PDR
maturity assessments.
Rolling Wave (RW)– Converting planning
packages into detailed work packages so that near-term
effort is always detailed.
Iteration – a time box in which development of
deliverables tasks place
Rolling Wave Planning – with current definitized RW,
planning for upcoming RW’s no further than the
planning horizon.
Iteration Planning – the teams plan for work by
selecting items from the Backlog and committing them
to an iteration.
Program Event Planning in IMP/IMS
Release Planning – planning assignment of
deliverables to specific iterations and staff.

6. Putting Earned Value Management and
Agile Software Development Together
Integrated Master Plan
Performance Measurement Baseline
Objective Assessment of
Accomplishments at Work
Performance Level
§ Program Milestones or Events
§ Accomplishments and Criteria
Release 1 Release n
§ Control Accounts
§ Work Packages
§ Planning Packages
The Bright Line Between EVM and Agile
Feature 3
Feature 2
Feature 1
Feature n
Sprint Sprint Sprint
Sprints are fixed duration work efforts that produce Features for the planned Release
Story
Story
Story
Story
Story
Story
Story
Story
Story
Tasks are work
needed to
produce a story
…
EVMS
Agile Dev

7. Building the PMB in a Agile
Paradigm
WBS
Iteration 1 Iteration 2 Iteration 3 … Iteration n Close Out
§ Deliverables
§ Tasks
§ Tasks
§ Deliverables
§ Deliverables
§ Deliverables
§ Tasks
§ Tasks
CA CoDR
…
PDR
WBS basis of deliverables Backlog, per MIL-STD-881C,
decomposed into Release Backlog, then into Iteration
Backlog for delivery by Stories and Tasks.

8. An Actual Earned Value + Agile
Program

9. Connecting the Moving Parts into an
Integrated Whole
With both Earned Value and Agile parts, let’s connect them into a Performance Measurement
Baseline ready for execution and reporting in the IPMR

10. Three Systems Needed for an
Integrated Solution
§ Business Accounting
§ Actuals
§ Subcontract management
§ Time phased Budget allocations to Control Accounts
§ Earned Value Management
§ BCWS baseline
§ BCWP calculated from physical percent complete using
Quantifiable Backup Data (QBD)
§ Agile Development process and supporting tools
§ Backlog management
§ Work planning
§ Physical Percent Complete measurement

11. Three Systems are Needed for an
Integrated Solution
§ Shared data
between each
system
§ Planning flowed
from IMS to
Agile
§ Physical
Percent
Complete
flowed back

12. Data Flow Between the Three
Systems

13. Data Used By Integrated System

14. Data Connectivity in the
Integrated System

15. Steps to setting up the pmb for
agile + evm
§ Here’s the step-by-step activities to define the Performance Measurement Baseline (PMB)
and get it on Baseline in Team Foundation Server, the IMS, and COBRA.
§ This includes Baseline Change Requests and statusing of the baseline to report EV in the
IPMR.
This is the secret sauce of the
principles and theory

16. Simple Rule for Earning Value in
Agile
Each Iteration of each Release is a
“value earning” opportunity
The next step is to connect Agile’s
definition of Value with Earned Value’s
definition of Value
Business Value ≠ BCWP

17. Starting to “Connect the Dots” † ‡
Agile Point of View DoD Program Point of View
Requirements evolve Scope agreed to and maintained
Simple designs are best Architecture thought out and maintained
Teams are self organizing
Organizational structure establishes
boundaries
Delivery teams establish
best prescriptive processes
High level guidance organizes work
Development teams know
what to do
Process professionals define the
boundaries
Agile teams work in an
iterative manner
Product Development Lifecycle is serial
over broader periods of time
† Abstracted from “Reality over Rhetoric,” Scott Ambler IBM Developer Works
‡ John Goodpastuer, Project Management the Agile Way

18. Let’s Start With 3 Simple
Connections
Agile
Both EV and Agile Development Measure Progress as
Physical Percent Complete
+
1
Measures of progress in units of
“physical percent complete.”
Each sprint produces 100%
working product.
2
Forecast of future performance
provided by past performance.
Forecast performance in units of
product(s) produced.
3
A systems approach to the
development of products and
connecting Cost, Schedule, and
Technical Performance.
Increasing fidelity of product and
problem understanding takes
place after each sprint and
release.
Earned Value

19. Assess Performance On A
Weekly Basis
Deliverable
Task
Task
Task
Task
Planned
240 Hrs
% Complete
100%
100%
0%
0%
Remaining
80 Hours
Actual
200 Hrs
DelTek
GCS
Week 1 Week 2 Week 3 Week 4
20 Day Sprints
Every Thursday Status
§ Physical Percent Complete
§ Hours remaining to 100%

20. 11 (EVM) Guidelines (GL) for the
Success of any Project
§ The 32 EVM Guidelines are all designed to deliver value.
§ These 11 are the basis of all good program management.

21. Here’s Those Connections
GL EVM Criteria Agile Approach
1 Define WBS Features and Stories define tasks
2 Identify Organization Self organizing teams
5 Integrate WBS and OBS Self organized teams with a customer
6 Schedule Work Iterations and Releases
7 Identify Products & Milestones Working software at the end of iterations
8 Set time phased budget Fixed length iterations and releases
16 Record direct costs Fixed staff = Level of Effort
23 Determine variances EV + Velocity measures missed features
25 Sum data and variance Missed features moved to next iteration
26 Manage action plans Replan missed features, adjust velocity
28 Incorporate changes Replan missed features, adjust velocity

22. Provide managers
with information at a
practical level of
summarization
Relate time
phased budgets to
specific contract
tasks
Enable statistical
estimation of
completion costs
Track and
monitor
discrete project
metrics
Communicate
project status
Provide
quantitative data
for decision
making
Provide a
documented
project
performance trail
Alert project
managers to
potential schedule
and cost risk
Program
Controls
Practice
…That Must Be Recognized Before Connecting Agile and EVM
But First, Let’s Not Forget Business Management Practices …

23. 11 EVM GL’s and 12 Agile Principles
Connecting Agile with Earned Value
Management is actually obvious
once we get over the social aspects
and focus on the Program Planning
and Controls aspects.
WBS
OBS
WBS+OBS
IMS
Productsand
Milestones
PMB
ACWP
Variances
Sumof
Variances
Corrective
Action
Record
Changes
Early and Continuous Delivery
Welcome Change
Deliver working Software
Business and DEV work together
Motivated individuals
Sustainable development
Working SW measure of progress
Face-to-Face communications
Continuous technical excellence
Maximize work not done
Self-organizing teams
Regular reflections