Earned Value + Agile = Success

EARNED VALUE + AGILE =
SUCCESS
Increasing the Probability of Program Success
requires connecting the dots between EV and Agile
Development.
Glen B. Alleman
Niwot Ridge, LLC
1
C4ISR Systems, McLean, VA

Today’s Briefing
2
 How can Agile Development methods increase
the Probability of Program Success (PoPS)?
 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 ANSI-
748B?
 What are the measures of success for Agile
methods in the context of ANSI-748B?

3
Let’s Start With An
Assumption:
Project Controls are the
basis of Project Success

4
There is already a clear, concise, and simple
mission statement for agile software
development

5
†Project Management the Agile Way, John C, Goodpasture, J. Ross, 2010
Agile Software In The Context Of
The Department Of Defense

The Foundation For
Earned Value Management …
7
 ANSI-748B, page 1, defines the top level
activities for a successful EV based project.
 We need to “connect the dots” between
these and agile development.

12 Principles of the Agile
Manifesto9

A Quick View of the DoD IT
Acquisition Lifecycle’s Impact on
Agile10
Earned Value requirement in Table 3, Pg. 30, A New Approach for
Delivering Information Technology Capabilities in the Department of

What Do We Mean When We Say Agile?
† Dr. Ashton Carter, Under Secretary of Defense for Acquisition, Technology and Logistics, Sep/Oct, 2010
11

Simple Rule for Earning Value in
Agile
12

Starting to “Connect the Dots”†
13
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 professional define the
boundaries
Agile team 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 and John
Goodpastuer, Project Management the Agile Way

3 Simple Connections
14
Earned Value
Management
Agile+
1
Measures of progress in
units of “physical percent
complete.”
Each iteration produces
100% working products.
2
Forecast of future
performance provided by
past performance.
Forecast performance in
units of product 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
iteration and release.

15
An Epic is a group of related User Stories
All these Stories work together inside a
Project or Program to produce the needed
Capabilities according to the Product Road

16
A User Story contains one or more
Features
The User Story is completed in a
single iteration, and is
Each Feature is then broken into
Tasks and these Tasks live in Work
Packages.
 Independent of other User Stories
 Negotiable during the planning stage
 Has measureable Valuable
 Small relative to the overall project
effort
 Testable with pre-defined success
criteria

This decomposition looks very
familiar!
17

How about this organization
18

Define what deliverables are needed at the end of a
phase, rolling wave, program event to fulfill the
Technical Performance Measures, Performance
Assessment Criteria, or assess the increasing maturity
of the final deliverable, measured in units of Physical
Percent Complete - BCWP.
Connecting Agile terminology with
DoD acquisition terminology
19
Events / Milestones define the
availability of a capability
at this point in the
schedule
Accomplishments define the
entry conditions for each
Event or Milestone
Criteria are the
exit conditions for
each Work Package
Work
Package
Work
Package
Work
Package
Work
Package
Work
Package
Work
Package
Work
Package
Work
package
Define what features are
needed to deliver value to the
customer at the end of the
release in units of measure
meaningful to the customer.
Minimal
Marketable
Features
inside of
User
Stories
inside of an
Epic

The WBS in an Agile Paradigm
20
 The top levels in the
project plan are Epics
and user stories.
 The project scope is
described by Epics.
 The project budget
starts on this Epics
level.
 Further detailing on the
User Story level and
the sprint task levels.
 Full traceability top
down and bottom up on
cost and progress.

One more level of detail is needed to
start connecting Agile with Govt.
Contracts21
 For govt.
contracts
some level
of stability in
the WBS is
needed.
 Maybe at the
Epic
boundaries?
 But this
topology
looks a lot
like an agile
project.
Business Need
Process Invoices for Top
Tier Suppliers
1st Level
Electronic Invoice
Submittal
1st Level
Routing to Payables
Department
2nd Level
Payables Account
Verification
2nd Level
Payment Scheduling
2nd Level
Material receipt
verification
2nd Level
“On hand” balance
Updates
Deliverables defined in WP

The Starting Point for “Connecting
the Dots” is the Rolling Wave
22
 Tune the Rolling Waves to the rhythm of the
project.
 These cycles are below the NDAA Section 804
suggestions.
X3_1158_043_F
Month 3 Month 4 Month 5 Month 6 Month 7 Month 8 Month 9 Mon10
Time Now
WP #4
Plan and Input
Next RW Period
WP #5
WP #6
WP #7
WP #9
WP #8
Minimum of 1 month
advance detail planning
Detail planning of next
rolling wave
30 Days
RW #3RW #3
Rolling Wave Period #2
Rolling Wave Period #1
WP #2
WP #3

11 criteria for any successful
project
23
 The 32 EVM Criteria are all designed to deliver
value.
 These 11 are the basis of “connecting the
dots.”

Here’s some more Connections
24
# 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

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
25

Conclusions
26
 Epics, Stories, Tasks, and the Work Packages executing
the Tasks are the same in Agile and DoD Program
Management.
 Earned Value “earns” the budget for the work that
produces the “business value.”
 Both are needed to increase the Probability of Program
Success (PoPS).
 Rolling Waves provide the mechanism to deal with
emergence within the rules of the Performance
Measurement Baseline (PMB).
 Agile focuses on code development
 EV focuses on the productivity of the resources developing
that code.

27
Call to Action
 Measure tangible evidence
of progress to plan as
“Physical Percent
Complete”
 Define what “done” looks
like in fine grained
increments before starting
the work.
 Define the planning horizon
to be inside your ability to
control the future.
 Learn how Earned Value
Management integrated
with Agile Software
Development provides the

Using the Earned Value Management Intent
Guide (EVMIG), here’s how to connect the
dots at the next level down.
The 11 criteria of Earned Value connected
with the 12 principles of Agile.
Putting These Ideas To Work30

2.1.a: Define Authorized Work
Elements
31
Define the authorized work elements for the program. A work breakdown structure
(WBS), tailored for effective internal management control, is commonly used in this
process.
EVMIG Objective Evidence Agile Objective Evidence for EV
 Work Breakdown Structure (WBS).  Road Map & Release Plan consisting of
Capabilities, Product Backlog & Iteration
Backlog.
 WBS dictionary (may or may not be used,
but a method to reconcile the statement
of work to the WBS structure must be
demonstrated).
 WBS dictionary: agile user stories are
deliverables that you can measure “done”
for, therefore user stories satisfy wbs
dictionary.

2.1.b: Identify Program
Organizational Structure
Identify the program organizational structure, including the major subcontractors
responsible for accomplishing the authorized work, and define the organizational
elements in which work will be planned and controlled.
 Organization Breakdown Structure
(OBS).
 CAM just builds a team as usual, but the
team needs to be persistent, and not
interchangeable parts.
 OBS intersections with the WBS.  Team hierarchy definition with resources
associated with their sub–teams.
 Done at the level of granularity to
support the basis of estimate (BOE).
 Persistent teams are needed to apply
throughput benchmarks to product
backlogs to validate plans.
32

2.1.e: Integrate WBS and OBS
Provide for integration of the program work breakdown structure and the program
organizational structure in a manner that permits cost and schedule performance
measurement by elements of either or both structures as needed.
 Control accounts.  Evidence that the CA meets the 90%
discrete work rule.
 Defend schedule & cost performance at
the CA level?
 Agile CA = one release.
 Actuals captured at the story level.
 Responsibility Assignment Matrix (RAM).  Done at too high a level for the SW
development approach to make a
difference.
 Contract Performance Reports (CPRs), if
applicable.
 Given an objective of X stories in
iteration Y, completed stories are earned;
all unearned return to backlog and a new
ETC is developed from the benchmarks
33

2.2.a: Schedule the Work
Schedule the authorized work in a manner which describes the sequence of work and
identifies significant task interdependencies required to meet the requirements of the
program.
 Integrated network schedules including
master, intermediate (if any), and detailed
schedules.
 CAM’s agile roadmap becomes the
auditable intermediate schedule
demonstrating significant
accomplishments (SA).
 MRP or ERP schedules, or planned order
reports.
 Each task in IMS has associated
resources.
 Control account plans (may be separate
plans or detail schedules).
 CAM creates schedules compliant to
DCMA 14 point assessment.
 Work authorization documents.  Nothing different.
34

2.2.b: Identify Products and
Milestones
Identify physical products, milestones, technical performance goals, or other indicators
that will be used to measure progress.
 Integrated schedules including master,
intermediate (if any), and detailed
schedules that identify contract
milestones and key events.
 Agile dev performance reporting follows
the approved program system description
 Apportioned technical performance
milestones to reduce risk & roll up
intermediate technical performance.
 MRP or ERP production planned order
reports.
 Not relevant to sw development.
 Control account plans (may be separate
plans or detail schedules)
 Not relevant to sw development because
we are reporting tasks as physical %
complete, which will automatically roll
up.
35

2.2.c: Set Time Phased Budget
Establish and maintain a time–phased budget baseline, at the control account level,
against which program performance can be measured. Initial budgets established for
performance measurement will be based on either internal management goals or the
external customer negotiated target cost including estimates for authorized but
undefinitized work.
 Control account plans.  Time phased budget created for the current iteration(s)
and future work.
 Summary level planning
packages.
 Agile summary level planning documented in road
map. Comprises capabilities, features and stories
 Agile planning packages driven by persistent teams
with proven benchmarks.
 Performance Measurement
baseline.
 Is there a target threshold for future work as described
in a PMB? Within 10% OTB?
 Undistributed budget logs.  Does this have anything to do with SW dev approach?
 Notification to the customer
of an over–target baseline.
 Does this have anything to do with SW dev approach?
36

2.3.a: Record Direct Costs
Record direct costs in a manner consistent with the budgets in a formal system
controlled by the general books of account.
 Reconciliation of project costs with the
accounting system.
 CAM would follow program direction on
these.
 These are not impacted by sw dev
approach
 Actual costs are reported at the control
account level at a minimum.
 Not impacted by SW development
approach.
 Reconciliation of subcontract reported
actual costs to subcontract payments.
approach.
 Internal and external performance reports
for subcontractors.
approach.
 Subcontractor control account plans,
when utilized.
approach.
37

2.4.b: Determine Variances
Identify, at least monthly, the significant differences between both planned and actual
schedule performance and planned and actual cost performance, and provide the
reasons for the variances in the detail needed by program management.
 Variance analyses (budget based
schedule variances and cost variances).
 Can track & report variances per the
approved program system description
 Management action plans.  Actionable recovery plans per issue.
 Updated schedule task completion and
cost–at–completion forecasts.
 Scrum Agile has a POD and Plan for
Iteration.
 CAM’s monthly EAC reporting follows
the approved program system
description
 Project schedules and schedule analysis
outputs.
 PM tracks the dynamic backlog, which
will go up and down based on sponsor
feedback
38

2.4.d: Summarize Variances
Summarize the data elements and associated variances through the program
organization and/or work breakdown structure to support management needs and any
customer reporting specified in the project.
 Variance analyses.  There is nothing in Agile’s approach to SW
development that precludes reporting variances at
the WP level.
 Agile is more dynamic than EVM so variances are
less the issue than the evolving baseline, as
approved in governance. The sponsor will want to
track accumulating business value and variances
to total product needs.
 Schedule and cost performance
reports.
 Similar – but measures of performance not
usually in dollars
 Management action plans.  Similar – but less formal. Collaborative discussion
of what actions to take include the customer.
 Updated schedule and cost  Similar – but less formal. Planning processes
39

2.4.e: Implement Management
Plan
Implement managerial action taken as the result of earned value information.
EVMIG Objective
Evidence
Agile Objective Evidence for EV
 To–Complete
Performance Index
(TCPI).
 TCPI = Work Remaining / Cost Remaining ((BAC –
BCWPcum) / (EAC – ACWPcum)). In Agile, work remaining
is the product backlog. Backlog is BAC – BCWP.
 Independent
completion estimates.
 No longer used in 2010
 Risk management data
and similar metrics.
 Qualitative Risk Burn–down Chart (risk rating)
 Management action
plans and review
briefings.
 Agile approach called Commitment Based Planning –
where the SCRUM team makes and meets its time phase
BCWS commitments.
 Any team, when behind, gives voice to the customer when
evaluating/reweighting the triple constraint.
 Variance analyses.  This is an issue of cost mgmt and system description
would define when and where team members would bill
40

2.5.a: Incorporate Changes (1)
Incorporate authorized changes in a timely manner, recording the effects of such
changes in the budgets and schedules.
 Contractual change documents.  Bug reports, new user stories, but not
necessarily cost sized.
 User stories above baseline are tracked as
new scope (with a valid BOE) and require
BCWS
 Change control logs (management
reserve, undistributed budget,
performance measurement baseline,
and contract budget base).
 New or materially altered features or stories
are changes.
 Control account/work
package/planning package plans.
 Product and iteration backlogs are frozen
during the development period
41

2.5.a: Incorporate Changes (2)
Incorporate authorized changes in a timely manner, recording the effects of such
changes in the budgets and schedules.
 Master schedules, intermediate
schedules (if any), and detailed
schedules.
 Iterations and evolutionary planning at the
detailed levels merges with the end to end
planning for agile.
 Statement of work, WBS, and WBS
dictionary.
 Customer owner and Planning processes
identify requires work and its description.
 Work authorization documents.  Planning sessions, authorize a set of
Stories to be developed during the iteration.
 Management reports (contract
performance reports or other
applicable management reports).
 Big Visible Charts, “sticky notes” display
progress to plan for the agile team.
42

Back Up Material43
http://dcmo.defense.gov/IT3Reform/index.html

44
No matter what method we’re using, the
definition of DONE has special meaning to
those directly involved in the project
Mission Specialist Bruce McCandless II, is seen further away from the confines and safety of the Space Shuttle
Challenger than any previous astronaut has ever been from an orbiter in this February 12, 1984 photo.

Agile Myths As A Conversation
Starter
 It is very difficult to
negotiate contracts for
agile work.
 Agile projects employ
counter intuitive
planning practices.
 Agile methods avoid
accountability.
 Agile methods erode
the gains made
towards recognizing
SW development as a
serious engineering
discipline.
 Agile methods ignore
enterprise
architecture.
46
Plausible
(Could be, needs a
domain)
 Agile projects cannot
be tracked with
earned value.
 You cannot accurately
estimate agile
projects.
 Stage gates don't
work for agile
projects.
 Agile scales naturally.
 Agile teams are
happier.
 Since empowered
teams self-organize
and self-select work,
the role of the project
manager goes away.
Busted
(Not True)
 Without specifications
you do not know
when you are done.
 You would not allow a
housing contractor to
proceed without a
clear plan and
estimate, why develop
SW this way?
Confirmed
(True in the right
domain)
Mike Griffiths, Leading Answers,

47
He who rejects
change is the
architect of
decay.
The only human
institution which
rejects progress
is the cemetery.
‒ Former Prime
Minister of
England,
Harold Wilson

48
Optimism is an
occupational hazard
of programming,
feedback is the
treatment.
Both EV and Agile
provide “feedback” in
units of measure
meaningful to all
participants
Kent Beck, one of the founders of Agile

Remember NDAA §804’s
Direction?49

How To Connect The Dots Has
Been Stated Before
50

What Does Agile Mean in the
DoD Acquisition Context?
51

Earned Value + Agile = Success

More Related Content

What's hot (20)

Similar to Earned Value + Agile = Success (20)

More from Glen Alleman (20)

Recently uploaded (20)

Earned Value + Agile = Success

Editor's Notes