Thank 
you 
for 
having 
me 
this 
morning. 
You’ve 
heard 
many 
speakers 
address 
way 
of 
developing 
so:ware 
using 
...
Before 
any 
of 
the 
current 
“agile” 
development 
methods 
were 
around, 
Earned 
Value 
Management 
provided 
informaC...
You 
will 
hear 
or 
you 
will 
have 
heard 
lots 
of 
definiCons 
of 
Agile 
this 
week. 
Here’s 
mine. 
Well 
it’s 
not ...
Before 
we 
go 
any 
further, 
let’s 
establish 
the 
connecCon 
between 
the 
need 
for 
agility 
in 
DoD 
IT 
procuremen...
StarCng 
at 
the 
top 
means 
asking 
a 
simple, 
yet 
powerful 
quesCon, 
of 
any 
procurement 
processes. 
The 
two 
doc...
Before 
we 
start 
into 
any 
details, 
let’s 
establish 
the 
domain 
and 
context 
for 
today’s 
discussion. 
Agile 
So:...
With 
that 
in 
mind, 
let’s 
set 
the 
stage 
how 
we 
arrived 
at 
the 
state 
of 
so:ware 
development 
projects. 
This...
So 
what 
can 
we 
do 
in 
the 
presence 
of 
these 
complex 
problems. 
The 
first 
thing 
to 
do 
is 
to 
step 
back 
an...
There 
are 
lots 
of 
definiCons 
of 
agile. 
Most 
come 
from 
the 
so:ware 
development 
world. 
But 
let’s 
have 
a 
de...
Let’s 
bring 
the 
discussion 
back 
to 
some 
simple, 
clear, 
and 
concise 
terms. 
What 
are 
we 
a:er 
when 
I 
sugges...
So 
if 
we’re 
looking 
for 
a 
higher 
moCvaCon 
in 
our 
search 
for 
correcCve 
acCons 
to 
being 
over 
budget 
and 
b...
So 
let’s 
change 
course 
here 
for 
a 
bit. 
There 
are 
lots 
of 
“myths” 
around 
agile 
so:ware 
development. 
Just 
...
Let’s 
start 
with 
some 
myths 
no 
the 
Defense 
AcquisiCon 
side. 
These 
come 
from 
then 
Capt. 
Dan 
Ward, 
now 
Lt....
Here’s 
some 
more 
myths 
around 
US 
DoD 
so:ware 
development 
programs. 
The 
Myth 
on 
the 
le: 
is 
a 
popular 
stat...
Here 
are 
some 
popular 
myths 
about 
agile 
so:ware 
development, 
itself. 
Confirmed 
! In 
the 
DoD 
domain 
and 
spe...
In 
the 
presence 
of 
all 
those 
myths 
– 
procurement, 
DoD 
IT, 
and 
Agile 
So:ware 
Development, 
here 
is 
ample 
e...
So 
now 
that 
we’ve 
had 
a 
good 
tour 
of 
agile 
some 
myths 
busted 
or 
confirmed, 
and 
the 
interacCon 
of 
agile ...
Let’s 
take 
another 
turn 
here, 
away 
fro 
all 
the 
regulaCon, 
audit 
and 
surveillance 
stuff 
for 
a 
minute. 
Back...
I’m 
going 
to 
conjecture 
agile 
and 
earned 
value 
have 
a 
symbioCc 
relaConship. 
There 
are 
claims 
agile 
can 
ad...
We’ve 
seen 
the 
formal 
guidance 
for 
applying 
Earned 
Value. 
We 
seen 
the 
beginnings 
of 
the 
agile 
message 
– 
...
We’re 
gezng 
close 
to 
the 
half 
way 
point 
in 
this 
briefing, 
so 
let’s 
have 
a 
process 
check. 
First 
where 
ha...
The 
answers 
to 
those 
three 
quesCon 
comes 
down 
to 
“measurement.” 
Measurement 
sounds 
like 
a 
non-­‐agile 
word....
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
The 
four 
items 
here 
are 
a 
restatement 
of 
the 
formal 
release. 
Let’s 
look 
again. 
1. Deliver 
early 
and 
o:en ...
The 
introducCon 
of 
agile 
to 
DoD 
IT 
acquisiCon 
programs 
comes 
the 
party 
that 
has 
already 
started. 
Earned 
V...
50
There 
are 
already 
several 
“agile” 
paradigms 
in 
DoD. 
One 
of 
the 
best 
know 
is 
Col. 
John 
Boyd's 
OODA 
proces...
52
Upcoming SlideShare
Loading in …5
×

Earned Value + Agile = Success

1,600 views

Published on

Integrating Agile on Earned Value Management programs is a natural process if done correctly.

Published in: Technology, Business
1 Comment
3 Likes
Statistics
Notes
No Downloads
Views
Total views
1,600
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
73
Comments
1
Likes
3
Embeds 0
No embeds

No notes for slide

Earned Value + Agile = Success

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. 23
  24. 24. 24
  25. 25. 25
  26. 26. 26
  27. 27. 27
  28. 28. 28
  29. 29. 29
  30. 30. 30
  31. 31. 31
  32. 32. 32
  33. 33. 33
  34. 34. 34
  35. 35. 35
  36. 36. 36
  37. 37. 37
  38. 38. 38
  39. 39. 39
  40. 40. 40
  41. 41. 41
  42. 42. 42
  43. 43. 43
  44. 44. 44
  45. 45. 45
  46. 46. 46
  47. 47. 47
  48. 48. 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
  49. 49. 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
  50. 50. 50
  51. 51. 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
  52. 52. 52

×