Earned Value + Agile = Success

Thank
you
for
having
me
this
morning.
You’ve
heard
many
speakers
address
way
of
developing
so:ware
using
agile
development
methods.
That
is
not
the
topic
of
this
briefing.
I’m
going
to
introduce
a
parallel
topic
to
the
development
of
so:ware
using
agile
methods.
This
topic
starts
and
ends
with
the
requirement
–
a
Federal
AcquisiCon
RegulaCon
requirements
–
for
the
applicaCon
of
Earned
Value
Management
for
programs
greater
than
$20M
and
for
the
use
of
a
DCMA
validated
system
for
programs
greater
than
$50M.
We’ll
see
the
sources
of
this
guidance
in
a
moment.
But
no
maPer
what
the
guidance
says,
how
it
is
applied
–
or
not
applied
–
I’m
going
to
try
and
convince
you
that
Earned
Value
Management
is
a
good
thing
in
the
context
of
Agile
So:ware
Development
and
the
direcCve
that
comes
form
the
NDAA
2010,
SecCon
804.
1

Before
any
of
the
current
“agile”
development
methods
were
around,
Earned
Value
Management
provided
informaCon
for
planning
and
controlling
complex
projects
by
measuring
how
much
"value'
was
produced
for
a
given
cost
in
a
period
of
Cme.
With
the
connecCon
to
the
Business
Value
in
agile,
both
technical
performance
and
business
performance
can
be
used
to
guide
the
performance
of
an
enterprise
IT
project.
The
concept
of
Probability
of
Program
Success
is
applied
to
other
DoD
AcquisiCon
process
in
the
Air
Force,
Army,
and
Navy.
It
asks
and
answers
the
quesCon
“what
are
the
key
performance
parameters
(KPP)
for
the
success
of
the
program?”
While
agile’s
contribuCon
to
the
development
of
so:ware
is
the
topic
of
many
of
the
speaker,
I’d
like
to
introduce
the
noCon
that
projects
and
programs
in
the
US
Department
of
Defense
are
sCll
subject
to
the
Federal
AcquisiCon
RegulaCon
(FAR)
and
Defense
Federal
AcquisiCon
RegulaCon
(DFAR)
once
the
program
has
reached
a
predefined
dollar
value.
At
some
point
in
the
IT
procurement
process,
it
is
likely
a
DoD
IT
program
will
cross
that
threshold.
2

You
will
hear
or
you
will
have
heard
lots
of
definiCons
of
Agile
this
week.
Here’s
mine.
Well
it’s
not
actually
mine.
It
is
John
Goodpastuer’s.
John’s
book
Project
Management
the
Agile
Way,
is
one
of
those
sleeper
texts
that
is
not
on
the
cover
of
so:ware
magazines,
or
in
the
agile
press
our
blogosphere.
Unlike
many
agile
books
that
tell
you
how
to
write
so:ware
using
agile
so:ware
development
methods,
John
tells
us
how
to
manage
projects
that
have
agile
development
methods
embedded
in
them.
John’s
book
is
one
place
to
look
for
Earned
Value
methods
on
agile
so:ware
development
projects.
3

Before
we
go
any
further,
let’s
establish
the
connecCon
between
the
need
for
agility
in
DoD
IT
procurement
and
Earned
Value
Management.
Page
30,
Table
3
of
A
New
Approach
for
Delivering
Informa;on
Technology
Capabili;es
in
the
Department
of
Defense.
this
document,
which
you
can
find
on
the
web,
is
from
the
Deputy
Secretary
of
Defense,
Office
of
the
Deputy
Chief
Management
Officer,
4

StarCng
at
the
top
means
asking
a
simple,
yet
powerful
quesCon,
of
any
procurement
processes.
The
two
documents
with
larger
borders
are
guideance
from
the
IT
iniCaCves.
The
other
documents
provide
acCoanble
outcomes
for
“increasing
the
probability
of
program
success”
What
is
the
probability
of
success?
This
is
a
legiCmate
quesCon
for
any
endeavor
that
evolves
risk.
The
processes
and
methods
being
described
over
the
3
days
of
this
conference
should
be
asking
and
answering
the
quesCon:
! how
can
we
increase
the
probability
of
program
success
PoPS?
! How
can
we
“connect
the
dots”
between
the
proposed
methods
–
agile
methods
–
and
the
increase
in
PoPS?
! Same
ques;on
needs
to
be
asked
of
Earned
Value,
or
for
that
maNer
any
process
–
exis;ng
or
proposed.
5

Before
we
start
into
any
details,
let’s
establish
the
domain
and
context
for
today’s
discussion.
Agile
So:ware
Development
is
broadly
defined
as
the
methods
used
to
develop
so:ware
products
using
the
principles
of
Agile.
These
principles
will
be
defined
today
starCng
with
the
Agile
Manifesto
and
the
12
supporCng
principles
for
that
manifesto.
There
are
specific
named
development
methods
that
belong
to
that
broad
set
of
principles.
Scrum,
eXtreme
Programming,
DSDM,
Featured
Driven
Development,
and
others.
But
those
product
development
methods
live
inside
a
larger
context,
especially
for
DoD
programs.
The
“programmaCc”
aspects
of
DoD
procurement
are
defined
in
the
FAR
and
DFAR,
plus
other
referenced
documents.
For
federal
government
procurements
this
guidance
cannot
be
ignored.
Some
of
this
guidance
speaks
to
applying
Earned
Value.
Other
guidance
speaks
to
the
procurement
processes
themselves
–
how
contracts
at
issued
and
executed,
how
performance
is
reported
and
what
milestones
and
measure
criteria
are
used.
As
well
3rd
party
agencies
are
involved
in
this
procurement
process.
6

With
that
in
mind,
let’s
set
the
stage
how
we
arrived
at
the
state
of
so:ware
development
projects.
This
by
the
way
is
not
unique
to
so:ware
development
in
the
DoD
or
any
government
agency.
Or
for
that
maPer
other
programs
in
the
government.
Or
finally
for
IT
programs
in
the
private
sector.
This
“road
map”
is
all
too
common
in
almost
every
non-‐trivial
so:ware
development
or
complex
system
development
project
or
program.
While
this
picture
tells
a
story,
it
is
more
complex
than
this
simple
linear
sequence
of
events.
The
source
of
the
problem
is
beyond
any
one
soluCon.
It
is
beyond
Earned
Value.
It
is
beyond
Agile
So:ware
development.
It
may
be
beyond
our
ability
to
manage
complex
systems.
7

So
what
can
we
do
in
the
presence
of
these
complex
problems.
The
first
thing
to
do
is
to
step
back
and
look
at
the
meta-‐problem
and
the
meta-‐
systems.
What
are
the
capabiliCes
we
need
to
address
the
complexity
of
the
problem.
What
actually
is
the
problem?
Here
are
some
answers
that
are
in
effect
today:
! We
need
measures
of
progress.
Progress
to
some
plan.
Possibly
a
plan
that
is
itself
changing.
! We
need
to
know
about
the
“probability”
of
success.
! SecDef
Gates
says
…
“
With
the
pace
of
technological
and
geopoliCcal
change
and
the
range
of
possible
conCngencies,
we
must
look
more
to
the
80-‐percent
soluCon,
the
mulC-‐service
soluCon
that
can
be
produced
on
Cme,
on
budget
and
in
significant
numbers.
As
Stalin
once
said,
"QuanCty
has
a
quality
all
of
its
own."
! We
need
to
both
start
at
the
top
and
start
at
the
boPom
in
search
of
the
80
percent
soluCon.
8
hPp://www.defense.gov/Transcripts/Transcript.aspx?TranscriptID=4404

There
are
lots
of
definiCons
of
agile.
Most
come
from
the
so:ware
development
world.
But
let’s
have
a
definiCon
that
is
meaningful
to
the
problem
at
hand.
That
problem
is
defined
in
NDAA
SecCon
804’s
instrucCons.
If
we
haven’t
heard
of
NDAA
SecCon
804,
it’s
the
NaConal
Defense
AuthorizaCon
Act
2010,
SecCon
804.
we’ll
see
the
details
in
a
bit,
but
for
now
SecCon
804
says
! SEC.
804.
IMPLEMENTATION
OF
NEW
ACQUISITION
PROCESS
FOR
INFORMATION
TECHNOLOGY
SYSTEMS.
! The
Secretary
of
Defense
shall
develop
and
implement
a
new
acquisiCon
process
for
informaCon
technology
systems.
The
acquisiCon
process
developed
and
implemented
pursuant
to
this
subsecCon
shall,
to
the
extent
determined
appropriate
by
the
Secretary
! Be
based
on
the
recommendaCons
in
chapter
6
of
the
March
2009
report
of
the
Defense
Science
Board
Task
Force
on
Department
of
Defense
Policies
and
Procedures
for
the
AcquisiCon
of
InformaCon
Technology;
and
(2)
be
designed
to
include—
! (A)
early
and
conCnual
involvement
of
the
user;
! (B)
mulCple,
rapidly
executed
increments
or
releases
of
capability;
! (C)
early,
successive
prototyping
to
support
an
evoluConary
approach;
and
! (D)
a
modular,
open-‐systems
approach.
The
last
four
phrases
should
be
sound
familiar
to
any
of
you
pracCcing
agile
so:ware
development.
9

Let’s
bring
the
discussion
back
to
some
simple,
clear,
and
concise
terms.
What
are
we
a:er
when
I
suggest
Earned
Value
Management
can
be
used
with
Agile
Development?
Actually
in
the
Federal
procurement
domain,
it’s
agile
being
used
with
Earned
Value.
The
answer
is
“how
can
we
recognize
that
value
–
business
value
–
is
being
EARNED
in
exchange
for
spending
Cme
and
money?”
This
is
a
core
quesCon,
in
the
same
way
to
previous
quesCon
–
what
is
the
probability
of
program
success
–
is
a
core
quesCon.
If
we
proceed
further
without
understand
the
importance
of
these
core
quesCons,
we
have
heard
and
seen
some
very
cleaver
tools
and
approaches.
But
we
won’t
understand
WHY
they
are
cleaver.
And
most
importantly
if
they
are
in
fact
the
appropriate
approaches
to
the
problem.
And
we
all
understand
the
problem
right?
We’re
over
budget,
behind
schedule,
and
off
the
technical
performance
measures
on
many
programs
in
IT
and
other
DoD
procurement
domains.
10

So
if
we’re
looking
for
a
higher
moCvaCon
in
our
search
for
correcCve
acCons
to
being
over
budget
and
behind
schedule,
we
need
look
no
further
than
the
current
NDAA.
Here’s
the
actual
worlds
from
the
NDAA.
If
you
have
not
read
this,
it
would
worthwhile.
The
NDAA
is
interesCng
in
that
it
is
a
“direcCve”
from
SecDef
to
the
DoD
IT
community.
It
provides
clear
and
concise
statements
about
what
to
search
for.
A,
B,
and
C
say
it
in
clear
terms.
! Early
and
conCnuous
user
involvement
! Rapidly
executed
increments
or
released
of
capability.
Capability
is
a
DoD
term
(Capability
Based
Planning
is
a
DoD
process).
Capability
means
“I
can
do
something
with
the
thing
you
just
gave
me.”
! Early
successive
prototyping
to
support
an
evoluConary
approach
–
means
what
it
says.
Early
–
not
late,
evoluConary
–
not
big
bang,
prototyping
–
parCally
complete
things
that
can
be
examined
to
see
if
that’s
what
we
really
want.
11

So
let’s
change
course
here
for
a
bit.
There
are
lots
of
“myths”
around
agile
so:ware
development.
Just
like
there
are
lots
of
myths
around
Earned
Value
and
Earned
Value
Management.
Let’s
look
at
some
of
these
to
get
a
sense
if
these
myths
have
any
validity
to
them.
If
not
let’s
bust
them.
If
so,
let’s
use
them
to
make
improvements
in
our
understanding
of
what
to
do
next
to
Increase
the
Probability
of
Program
Success.
Remember
that
phrase.
That’s
the
phrase
we
want
to
start
using
to
keep
everyone
honest.
How
does
your
suggested
improvement
Increase
the
Probability
of
Program
Success?
12

Let’s
start
with
some
myths
no
the
Defense
AcquisiCon
side.
These
come
from
then
Capt.
Dan
Ward,
now
Lt.
Col
Dan
Ward,
USAF.
Dan
and
I
have
shared
ideas
for
awhile
around
what
it
means
to
be
agile
and
adapCve
in
the
weapons
system
procurement
business.
Dan
writes
arCcles
for
the
AcquisiCon,
Technology
and
LogisCcs
journal
–
a
real
page
turner
if
anyone
is
interested.
Dan
also
has
a
Blog
and
writes
books
about
management,
especially
program
management.
Most
of
Dan’s
work
can
be
found
on
the
Defense
AcquisiCon
University’s
Community
of
PracCce
portal.
These
myths
are
self
evident.
Meaning
when
you
statement
them,
you
can
figure
prePy
quickly
if
they
can
be
“busted”
or
not.
There
are
6
here,
all
“busted.”
13

Here’s
some
more
myths
around
US
DoD
so:ware
development
programs.
The
Myth
on
the
le:
is
a
popular
statement
outside
the
DoD.
The
“busted”
statement
on
the
right
is
the
understand
from
those
of
us
working
the
programs
inside
the
DoD
contractors.
14

Here
are
some
popular
myths
about
agile
so:ware
development,
itself.
Confirmed
! In
the
DoD
domain
and
specific
context,
a
specificaCon
of
what
“done”
looks
like
is
part
of
the
culture
and
part
of
the
contracCng
process
for
the
use
of
public
money.
! You
would
not
give
$10M
to
a
so:ware
development
firm
without
a
detailed
set
of
capabiliCes
and
requirements
for
what
you’re
expecCng
to
get
for
your
money.
Busted
! The
brief
will
show
how
to
connect
EV
with
Agile
! You
can
measure
anything
once
you
define
the
units
of
measure.
In
agile
that
is
working
so:ware.
! Stage
gates
are
the
definiCon
of
releases.
! There
are
many
aspects
of
a
so:ware
project
that
aren't
about
so:ware.
! Agile
may
or
may
not
be
quicker,
there
is
no
way
to
have
parallel
comparisons.
Plausible
! The
FAR
rules,
not
agile
! The
less
than
formal
planning
processes
are
someCme
problemaCc
! The
accountability
is
no
formal
as
required
by
748B
! The
jury
is
out
on
this,
although
TS
(tech
soluCon)
is
a
small
part
of
CMMI
! This
can
happen
in
the
absence
of
leadership
15

In
the
presence
of
all
those
myths
–
procurement,
DoD
IT,
and
Agile
So:ware
Development,
here
is
ample
evidence
DoD
IT
is
headed
down
the
path
of
agile
acquisiCon
and
development.
Mrs.
McGrath
spoke
at
a
recent
AFCEA
NOVA
lunch
I
aPended
and
laid
out
where
she
was
going
in
her
office.
But
we
sCll
need
to
“connect
the
dots”
between
the
Governance
of
DoD
IT
programs
and
the
technical
acCviCes
we
find
in
the
development
of
so:ware.
As
menConed
earlier
“wriCng
so:ware”
is
not
the
same
as
“managing
the
wriCng
of
so:ware.”
No
maPer
the
examples
in
the
commercial
worlds,
where
the
development
teams
are
“self
managed,”
that
is
likely
too
big
a
leap
for
FAR
/
DFAR
compliant
programs
to
take.
There
will
always
be
the
requirement
for
Program
Management
processes
based
on
Earned
Value
for
contract
awards
greater
than
$20M.
16

So
now
that
we’ve
had
a
good
tour
of
agile
some
myths
busted
or
confirmed,
and
the
interacCon
of
agile
with
the
project
and
the
development
of
so:ware,
let’s
revisit
that
some
guidance
that
is
in
place
no
maPer
what
so:ware
development
we’re
using
now
or
want
to
use
in
the
future.
We
come
to
the
elephant
in
the
room.
For
programs
in
the
DoD
(or
for
that
maPer
any
government
agency)
that
have
award
values
greater
than
$20M
the
FAR,
DFAR,
and
OMB
(White
House)
requires
Earned
Value
management,
guided
by
ANSI
748-‐B.
I’ll
wait
for
the
shudder
in
the
room
to
sePle
(if
there
is
one).
The
two
logos
on
the
le:
are
from
the
Defense
Contract
Management
Agency
and
the
Defense
Contract
Audit
Agency.
They
are
accountable
for
looking
a:er
the
money
issued
to
contractors
for
the
acquisiCon
of
services
and
materials
in
the
US
Government.
They
are
one
of
those
overworked
agencies
that
are
always
looking
for
ways
to
make
your
life
unpleasant
at
inconvenient
Cmes.
They
do
this
with
a
“poliCcally
correct
word”
surveillance
–
which
mean
audit
–
enabled
by
the
regulaCons
and
guidance
listed
at
the
boPom
of
this
chart.
17

Let’s
take
another
turn
here,
away
fro
all
the
regulaCon,
audit
and
surveillance
stuff
for
a
minute.
Back
to
the
theme
of
this
conference.
The
agile
manifesto
was
the
start
of
the
principles
of
agile.
The
manifesto
was
first
seen
an
a
disrupCve.
I
spoke
at
an
early
agile
conference
while
I
was
a
program
manager
at
a
mulC-‐billion
dollar
Department
of
Energy
program,
when
the
agile
thought
leaders
and
process
owners
where
dominated
by
individual
developers.
There
was
a
definite
anCestablishment
feel
in
Salt
Lake
City
in
June
of
2003.
We’ve
come
a
long
since
then.
The
“mainstream”
has
started
to
absorb
many
of
the
concepts.
We’re
here
today
talking
about
agile
so:ware
development
in
the
domain
of
DoD
IT.
We’re
early
in
the
cycle,
but
there
is
now
“past
performance”
that
can
be
examined
to
connecCons
to
this
domain
(DoD)
and
the
context
of
that
domain
(IT).
On
page
51
of
Boyd’s
treaCse
is
the
secCon
“The
Defense
Turn,”
possible
used
by
Dr.
Carter’s
quote
of
“turning
inside
the
loop
of
unfolding
events.”
18
Earned
Value
+
Agile
=
Success
Glen
B.
Alleman,
VP
Program
Controls,
Niwot
Ridge,
LLC
NDIA
InformaCon
Systems
Summit
II
4/4/2011
–
4/6/2011
HyaP
Regency,
BalCmore,
Maryland

I’m
going
to
conjecture
agile
and
earned
value
have
a
symbioCc
relaConship.
There
are
claims
agile
can
add
value
in
the
DoD
IT
context.
But
we
can’t
forget
the
need
for
Earned
Value,
rather
than
mandated
use
of
Earned
Value.
It’s
the
work
of
“connecCng
the
dots”
that
will
reveal
how
these
two
seemingly
conflicCng
ideas
can
come
together
to
fulfill
the
goal
of
any
program
–
Increasing
the
Probability
of
Success.
This
may
appear
to
be
different
from
all
the
other
“goals”
of
a
program.
But
in
the
end
it
is
increasing
“probability”
of
success
that
should
be
the
actual
goal.
All
other
goals
flow
from
this
top
level
goal.
Several
ideas
come
from
this
and
most
importantly
that
all
project
work,
especially
so:ware
development
and
acquisiCon
is
probabilisCc
in
nature.
19

We’ve
seen
the
formal
guidance
for
applying
Earned
Value.
We
seen
the
beginnings
of
the
agile
message
–
the
manifesto.
But
let’s
try
to
make
this
even
simpler.
For
any
project,
no
maPer
what
the
method
used
to
develop
the
products,
there
are
some
very
simple
principles
for
increasing
the
probability
of
success.
These
are
the
“programmaCc”
aspects
of
the
project.
The
“technical”
aspects
are
addressed
in
many
ways,
agile
being
20

We’re
gezng
close
to
the
half
way
point
in
this
briefing,
so
let’s
have
a
process
check.
First
where
have
we
come
from?
We’ve
seen
agile
is
being
menConed
inside
the
walls
of
the
DoD.
We’ve
seen
there
are
external
guiding
regulaCons
and
documents
that
impact
DoD
procurement
no
maPer
what
method
is
being
used
to
develop
the
so:ware.
So
let’s
take
the
first
aPempt
to
“connect
the
dots,”
between
those
two
worlds.
Here’s
three
ways
they
can
be
connected.
! Measuring
progress
! ForecasCng
future
progress
! IntegraCng
the
performance
reporCng
in
a
form
needed
by
the
government.
21

The
answers
to
those
three
quesCon
comes
down
to
“measurement.”
Measurement
sounds
like
a
non-‐agile
word.
It
can
certainly
be
done
in
a
non-‐
agile
way.
But
agile
itself
has
many
measurement
processes.
Velocity
is
one
that
is
related
to
Earned
Value.
I
say
related.
Not
the
same
as.
And
related
itself
needs
a
definiCon.
Velocity
and
Earned
Value
are
probably
cousins
rather
than
siblings.
But
both
approaches
–
and
this
is
the
message
of
this
briefing
–
is
that
“measurement”
is
at
the
heart
of
any
approach
to
Increasing
the
Probability
of
Program
Success.
22

The
four
items
here
are
a
restatement
of
the
formal
release.
Let’s
look
again.
1. Deliver
early
and
o:en
–
these
are
core
concepts
of
agile.
2. Incremental
and
iteraCve
is
a
criCcal
success
factor
for
any
project.
3. By
raConalize
it
could
mean
that
the
customer
defines
them
with
face-‐to-‐
face
interacCon
with
the
developers.
4. The
processes,
in
this
case
Earned
Value,
need
to
“earn
its
keep”
to
be
effecCve.
48

The
introducCon
of
agile
to
DoD
IT
acquisiCon
programs
comes
the
party
that
has
already
started.
Earned
Value
for
programs
greater
than
$20M.
The
Work
Breakdown
Structure,
Integrated
Master
Plan
/
Integrated
Master
Schedule
(IMP/
IMS),
DID
81650
Schedule
Risk
Analysis,
and
of
course
the
Performance
Measurement
Baseline
(PMB).
49

There
are
already
several
“agile”
paradigms
in
DoD.
One
of
the
best
know
is
Col.
John
Boyd's
OODA
process.
Boyd’s
“Organic
Design
for
Command
and
Control,”
“A
Discourse
on
Winning
and
Loosing,”
“PaPerns
of
Conflict,”
and
the
paper
that
started
it
all
“”Aerial
APack
Study,”
1964.
The
OODA
paradigm
informs
the
agile
conversaCon
in
a
broader
context
of
DoD
vocabulary.
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