Glen alleman agile 04 ev+agile=success

Thank you for having me this morning.
You’ve heard many speakers address way
of developing software using agile
development methods.
That is not the topic of this briefing.
I’m going to introduce a parallel topic to
the development of software using agile
methods.
This topic starts and ends with the
requirement – a Federal Acquisition
Regulation requirements – for the
application 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 matter 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 Software
Development and the directive that comes
form the NDAA 2010, Section 804.
1
Integrating Agile with EVM
Glen B. Alleman, Niwot Ridge, LLC
EVM World, 2013
May 29-31, 2013
Naples Florida

Before any of the current “agile”
development methods were around,
Earned Value Management provided
information for planning and controlling
complex projects by measuring how much
"value' was produced for a given cost in a
period of time. With the connection 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
Acquisition process in the Air Force, Army,
and Navy. It asks and answers the question
“what are the key performance
parameters (KPP) for the success of the
program?”
While agile’s contribution to the
development of software is the topic of
many of the speaker, I’d like to introduce
the notion that projects and programs in
the US Department of Defense are still
subject to the Federal Acquisition
Regulation (FAR) and Defense Federal
Acquisition Regulation (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
EVM World, 2013
May 29-31, 2013
Naples Florida

The PoPS Operations Guide for ALTESS is
shown highlighted here.
Starting at the top means asking a simple,
yet powerful question, of any procurement
processes. The two documents with larger
borders are guidance from the IT
initiatives. The other documents provide
actionable outcomes for “increasing the
probability of program success”
What is the probability of success?
This is a legitimate question 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 question:
 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 question needs to be asked of
Earned Value, or for that matter any
process – existing or proposed.
3
EVM World, 2013
May 29-31, 2013
Naples Florida

You will hear or you will have heard lots of
definitions 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 software magazines, or
in the agile press our blogosphere.
Unlike many agile books that tell you how
to write software using agile software
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 software
development projects.
4
EVM World, 2013
May 29-31, 2013
Naples Florida

Before we go any further, let’s establish
the connection between the need for
agility in DoD IT procurement and Earned
Value Management.
Page 30, Table 3 of A New Approach for
Delivering Information Technology
Capabilities 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,
5
EVM World, 2013
May 29-31, 2013
Naples Florida

With that in mind, let’s set the stage how
we arrived at the state of software
development projects. This by the way is
not unique to software development in
the DoD or any government agency. Or for
that matter 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 software
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 solution. It is beyond Earned Value. It
is beyond Agile Software development. It
may be beyond our ability to manage
complex systems.
6
EVM World, 2013
May 29-31, 2013
Naples Florida

There are lots of definitions of agile. Most
come from the software development
world. But let’s have a definition that is
meaningful to the problem at hand. That
problem is defined in Section
804’s instructions. If we haven’t heard of
NDAA Section 804, it’s the National
Defense Authorization Act 2010, Section
804. we’ll see the details in a bit, but for
now Section 804 says:
 SEC. 804. IMPLEMENTATION OF NEW
ACQUISITION PROCESS FOR
INFORMATION TECHNOLOGY SYSTEMS.
 The Secretary of Defense shall develop
and implement a new acquisition
process for information technology
systems. The acquisition process
developed and implemented pursuant to
this subsection shall, to the extent
determined appropriate by the Secretary
 Be based on the recommendations in
chapter 6 of the March 2009 report of
the Defense Science Board Task Force on
Department of Defense Policies and
Procedures for the Acquisition of
Information Technology; and
(2) be designed to include—
 (A) early and continual involvement of
the user;
 (B) multiple, rapidly executed increments
or releases of capability;
 (C) early, successive prototyping to
support an evolutionary approach; and
 (D) a modular, open-systems approach.
The last four phrases should be sound
familiar to any of you practicing agile
software development.
7
EVM World, 2013
May 29-31, 2013
Naples Florida

In our standard software development
domain, in the DOD or in most commercial
enterprises, what done looks like is a
moving target.
This is no only the norm, in many cases it
is beneficial, since the customer may not
know or even have to ability to know what
done looks like in definitive terms needs to
write a functional specification for the
software.
So we need a new definition of what done
looks like. a definition based on the
needed capabilities first. And only them
can we search for the techncial
requirements.
It is assumed, and needs to be stated
again, that these programs are using
Earned Value Management. That is why
this briefing is being given at an Earned
Value Management conference, rather
than an Agile Software Development
conference.
So we’re using EV on our program with
agile development as the engineering
method, but we don’t have a definitive
techncial specification.
Agile provide a solution to this problem. It
produces working software in incremental
steps against a top level “needed
capabilities” description .
EVM World, 2013
May 29-31, 2013
Naples Florida
8

Let’s bring the discussion back to some
simple, clear, and concise terms.
What are we after 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 time and
money?”
This is a core question, in the same way to
previous question – what is the probability
of program success – is a core question.
If we proceed further without understand
the importance of these core questions,
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.
9
EVM World, 2013
May 29-31, 2013
Naples Florida

So if we’re looking for a higher motivation
in our search for corrective actions 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 interesting in
that it is a “directive” 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 continuous 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 evolutionary approach – means what
it says. Early – not late, evolutionary –
not big bang, prototyping – partially
complete things that can be examined
to see if that’s what we really want.
10
EVM World, 2013
May 29-31, 2013
Naples Florida

Before we start done the path to
integrating Agile with Earned Value
Management, we need to recognize that
simply sewing Agile with EVM will not
result in usable approach to improving the
probability of program success.
To do this, we need the make connections
between the practices of EVM with the
Agile practices.
First let’s address the myths first, then
connect the dots between EVM and Agile.
EVM World, 2013
May 29-31, 2013
Naples Florida
11

So let’s change course here for a bit.
There are lots of “myths” around agile
software 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
EVM World, 2013
May 29-31, 2013
Naples Florida

Let’s start with some myths no the
Defense Acquisition 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
adaptive in the weapons system
procurement business.
Dan writes articles for the Acquisition,
Technology and Logistics 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 Acquisition University’s
Community of Practice portal.
These myths are self evident. Meaning
when you statement them, you can figure
pretty quickly if they can be “busted” or
not. There are 6 here, all “busted.”
13
EVM World, 2013
May 29-31, 2013
Naples Florida

Here’s some more myths around US DoD
software development programs.
The Myth on the left 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.
These myth prevent the joining of agile
and EVM from both sides. Actual DOD
programs have emergent requirements
and are managed using an “increasing
maturity” process in the IMP/IMS.
Rarely would all requirements be defined
on day one. Just like Agile, assessing what
the customer “actually” wants as products
are developed.
14
EVM World, 2013
May 29-31, 2013
Naples Florida

Before we get into the details, or run out
of time for getting into the details, let’s
look ahead of how to “connect the dots”
between agile process and an enterprise
process framework.
We’re not yet ready to do the same for
Earned Value, but this is the basis of that
coming step.
These come from a Scott Ambler article
and John Goodpastuer’s book Project
Management the Agile Way. John’s book is
one of the best sources of agile practices
in the presence of existing enterprise
management processes. In this case
Earned Value Management.
15
EVM World, 2013
May 29-31, 2013
Naples Florida

In the presence of all these myths –
procurement, DoD IT, and Agile Software
Development, here is ample evidence DoD
IT is headed down the path of agile
acquisition and development.
Mrs. McGrath spoke at a recent AFCEA
NOVA lunch I attended and laid out where
she was going in her office.
But we still need to “connect the dots”
between the Governance of DoD IT
programs and the technical activities we
find in the development of software. As
mentioned earlier “writing software” is
not the same as “managing the writing of
software.”
No matter 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
EVM World, 2013
May 29-31, 2013
Naples Florida

So now that we’ve had a good tour of agile
some myths busted or confirmed, and the
interaction of agile with the project and
the development of software, let’s revisit
that some guidance that is in place no
matter what software 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
matter 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
settle (if there is one).
The two logos on the left are from the
Defense Contract Management Agency
and the Defense Contract Audit Agency.
They are accountable for looking after the
money issued to contractors for the
acquisition 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 times.
They do this with a “politically correct
word” surveillance – which mean audit –
enabled by the regulations and guidance
listed at the bottom of this chart.
17
EVM World, 2013
May 29-31, 2013
Naples Florida

Let’s take another turn here, away fro all
the regulation, 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 disruptive. I spoke at an early
agile conference while I was a program
manager at a multi-billion dollar
Department of Energy program, when the
agile thought leaders and process owners
where dominated by individual
developers. There was a definite
antiestablishment 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 software development in the
domain of DoD IT.
We’re early in the cycle, but there is now
“past performance” that can be examined
to connections to this domain (DoD) and
the context of that domain (IT). On page
51 of Boyd’s treatise is the section “The
Defense Turn,” possible used by Dr.
Carter’s quote of “turning inside the loop
of unfolding events.”
18
EVM World, 2013
May 29-31, 2013
Naples Florida

We’re getting 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 mentioned inside the
walls of the DoD.
We’ve seen there are external guiding
regulations and documents that impact
DoD procurement no matter what method
is being used to develop the software.
So let’s take the first attempt to “connect
the dots,” between those two worlds.
Here’s three ways they can be connected.
 Measuring progress
 Forecasting future progress
 Integrating the performance reporting
in a form needed by the government.
19
EVM World, 2013
May 29-31, 2013
Naples Florida

The answers to those three question
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 definition. 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.
20
EVM World, 2013
May 29-31, 2013
Naples Florida

One of the difficulties with the Agile
Manifesto besides the term “over,” is it is
not directly actionable.
If we look at these 12 “principles” and
remove the term “agile” there is not one
of them that we would not want on any
project.
How would not want…
 To satisfy the customer with early and
continuous delivery of value
 To have business and developers work
together.
 To frequently deliver working products.
 To have continuous attention to
technical excellence
21
EVM World, 2013
May 29-31, 2013
Naples Florida

There are 11 critical Earned Value
Management processes for project success
1-Define the WBS for the deliverables
2-Identify the organization of the staff that
produces the deliverables
5-Integrate these two to identify the
accountable person for the deliverable
6-Schedule the work
7-Idenitify the Products and Milestones in
the schedule
8-Set Time Phased Budget for each Work
Package
16-Record Direct Costs so we know how
much we’re spending
23-Determine Variances to see if we’re
following the plan
25-Sum Data and Variances so we can see
if the project is making progress
26-Manage Action Plans for fixing the
variances
28-Incorporate Changes
22
EVM World, 2013
May 29-31, 2013
Naples Florida

The connections between earned value
management and agile software
development are made at the work
package level. In agile the list of “features”
to be developed is assumed to be present.
The source of those “feature” comes from
the customer. In the EVM world, those
“features” need to be baselined in some
manner for EV to have any benefit.
Changing the baseline on a whim is not
just bad EVM, it makes EVM worthless,
since the real value of EVM comes from
measuring progress against baseline – the
original plan.
The plan can change of course, and many
times it does. But those changes are
recognized as a “re-baseline” and wash
out the variances used to manage the
project.
EVM World, 2013
May 29-31, 2013
Naples Florida
23

So let’s look again at the top level
connections between Earned Value
Management – as practiced using EVM
guidance from ANSI-748-B, DOE, and the
PMI EVM Practice Guide.
If you make up your own practices, that’s a
different story.
The 11 core practices of Earned Value
Management have strong connections to
the practices of agile development.
24
EVM World, 2013
May 29-31, 2013
Naples Florida

But while we’re getting all excited about
connecting agile into EVM projects, let’s
not forget that we are managing other
people money with these processes.
The Business Management Processes are
the over arching framework for any
project.
Each of these processes must be in place
and applied – successfully applied – if we
are to have any hope of success on our
project.
25
EVM World, 2013
May 29-31, 2013
Naples Florida

It turns out of course that this idea of
incremental development, emerging
requirements and measures of tangible
progress to plan have been around awhile.
We’ve forgotten about them for a variety
of reasons, not the least of which is we
don’t use history to inform the present or
future.
Like Santanyana says "Those who cannot
remember the past are condemned to
repeat it.”
26
EVM World, 2013
May 29-31, 2013
Naples Florida

So we’re back to the beginning.
Here’s our call to action.
27
EVM World, 2013
May 29-31, 2013
Naples Florida

The OODA Loop can be applied to any
problem. Agile integration with EVM
system is one.
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,” “Patterns of Conflict,” and the
paper that started it all “”Aerial Attack
Study,” 1964.
The OODA paradigm informs the agile
conversation in a broader context of DoD
vocabulary.
28
EVM World, 2013
May 29-31, 2013
Naples Florida

The notion of product development using
a linear “waterfall” process in the
government is log gone. Starting with the
removal of this approach in DODI 5000.01,
where spiral was introduced. In DODI
5000.02,
http://www.dtic.mil/whs/directives/corres
/pdf/500002p.pdf,
Iterative processes are used.
Since all projects involve complex, high
risk, and fast moving requirements, agile ia
a natural addition to the current
procurement processes.
EVM World, 2013
May 29-31, 2013
Naples Florida
29

30
EVM World, 2013
May 29-31, 2013
Naples Florida

31
EVM World, 2013
May 29-31, 2013
Naples Florida

With the 11 EVMS Guidelines, let’s look at
how Agile can be connected to them.
The next section shows how to do this.
32
EVM World, 2013
May 29-31, 2013
Naples Florida

Guideline 1 creates the Work Breakdown
Structure for the deliverables. The WBS is
a product focused view of the project. It
shows what is being delivered and how
those deliverables are structured between
parent and child.
At the terminal nodes of the WBS are the
Work Packages that contain the work
effort to produce the deliverables.
The WBS is used to assign budget for the
work efforts and collect costs against that
budget.
The Earned Value Management processes
asses the “earned value,” BCWP using the
WBS.
With these three numbers, forecasts of
future performance can be made for each
deliverable.
The WBS is not a decomposition of the
functions in the project. Design, Code,
Test, would not be seen in the WBS. Only
products and the services needed to
produce those products.
33
EVM World, 2013
May 29-31, 2013
Naples Florida

With the deliverables defined, we now
need to know who is going to do the work.
On agile teams this is straight forward,
since the team members are known and
are assigned to the project for long
periods of time.
On government programs, this is not
always the case, so the connection
between agile and GL 2 is easy.
34
EVM World, 2013
May 29-31, 2013
Naples Florida

With the products and the staff building
the products we need to connect the dots.
On single agile project this is simple, but
for multiple teams these connections are
useful, since resource allocation will likely
be an issue.
35
EVM World, 2013
May 29-31, 2013
Naples Florida

In agile scheduling is straight forward, or
may appear to be so.
In fact on agile programs, scheduling is
needed on government programs.
Contractually the work needs to produce
some minimal set of capabilities in a
planned period of time for a planned
budget.
Knowing when the work products will be
produced, for what effort, and by whom is
part of scheduling.
36
EVM World, 2013
May 29-31, 2013
Naples Florida

Planning in agile starts at the top. What
capabilities are needed for the customer
to consider the project a success.
This Epic planning is nearly identical to the
Capabilities Based Planning process found
on government programs.
37
EVM World, 2013
May 29-31, 2013
Naples Florida

Budgeting in agile is level of effort if the
team content doesn’t change.
What is different is the planned outcomes
and the absorption of the budget using
those fixed resources.
Scaling the agile team up and down and
producing a budget profile, does not fit the
paradigm of agile.
So with a “flat spread” budget, the
independent variable is the teams capacity
for work.
38
EVM World, 2013
May 29-31, 2013
Naples Florida

Direct costs are dominated by labor.
With a flat spread of labor, this is simple.
39
EVM World, 2013
May 29-31, 2013
Naples Florida

The variances in agile are around the
production of outcomes for the flat spread
work effort.
Adjusting the “Capacity for Work,” starts
with assessing the current production of
outcomes from that work.
40
EVM World, 2013
May 29-31, 2013
Naples Florida

Assessment of performance to plan is the
basis of any credible project management
method.
Agile is no different.
 How many features, stories, outcomes
were planned?
 How many were produced?
 With this variance, what changes need
to be made to the team to stay on plan?
41
EVM World, 2013
May 29-31, 2013
Naples Florida

With the information from GL 25, how can
the team get back on plan, when they fall
short of the committed outcomes.
42
EVM World, 2013
May 29-31, 2013
Naples Florida

Management of the project means
management decisions need to be made.
Here is where that takes place.
43
EVM World, 2013
May 29-31, 2013
Naples Florida

44
EVM World, 2013
May 29-31, 2013
Naples Florida

45
EVM World, 2013
May 29-31, 2013
Naples Florida

Here are some popular myths about agile
software development, itself.
Confirmed
 In the DoD domain and specific context,
a specification of what “done” looks like
is part of the culture and part of the
contracting process for the use of public
money.
 You would not give $10M to a software
development firm without a detailed set
of capabilities and requirements for
what you’re expecting 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 software.
 Stage gates are the definition of
releases.
 There are many aspects of a software
project that aren't about software.
 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 sometime problematic
 The accountability is no formal as
required by 748B
 The jury is out on this, although TS (tech
solution) is a small part of CMMI
 This can happen in the absence of
leadership
46
EVM World, 2013
May 29-31, 2013
Naples Florida

47
EVM World, 2013
May 29-31, 2013
Naples Florida

48
EVM World, 2013
May 29-31, 2013
Naples Florida

The four items here are a restatement of
the formal release.
Let’s look again.
1. Deliver early and often – these are
core concepts of agile.
2. Incremental and iterative is a critical
success factor for any project.
3. By rationalize it could mean that the
customer defines them with face-to-
face interaction with the developers.
4. The processes, in this case Earned
Value, need to “earn its keep” to be
effective.
49
EVM World, 2013
May 29-31, 2013
Naples Florida

The introduction of agile to DoD IT
acquisition 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).
50
EVM World, 2013
May 29-31, 2013
Naples Florida

51
EVM World, 2013
May 29-31, 2013
Naples Florida

52
EVM World, 2013
May 29-31, 2013
Naples Florida

53
EVM World, 2013
May 29-31, 2013
Naples Florida

Glen alleman agile 04 ev+agile=success

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Glen alleman agile 04 ev+agile=success

Similar a Glen alleman agile 04 ev+agile=success (20)

Más de Glen Alleman

Más de Glen Alleman (20)

Último

Último (20)

Glen alleman agile 04 ev+agile=success