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