National Defense Industrial Association Information Systems Summit II

Image via WikipediaLast week I had the privilege of attending National Defense Industrial Association Information Systems Summit II sponsored by its C4ISR Division. The focus of the conference was on the usage of Agile development within the Department of Defense.  After reviewing the attendee roster list, I believe NDIA did a good job in getting a good mix from government and industry to attend and share their knowledge. I was pleased to observe that many of the attendees were either involved in their agencies’/companies’ existing Agile projects, or were seeking more information because their agency/company is planning future Agile projects. The conference allowed for a meaningful dialogue where attendees were able to share their experiences and ask questions of the speakers and other fellow participants. Even though the tagline for the conference was “What’s All This Agile Stuff About, Anyway?,” the goal of the conference was to provide attendees with an understanding and accelerate the adoption of the Manifesto for Agile Software Development within DoD. My opinion is Agile is here.

To show how far Agile has come, the National Defense Authorization Act for Fiscal Year 2010 within Section 804, Implementation of New Acquisition Process for Information Technology Systems, shown below supports Agile SCRUM:

 “…(a) NEW ACQUISITION PROCESS REQUIRED.—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—

(1) 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.

(b) REPORT TO CONGRESS.—Not later than 270 days after the date of the enactment of this Act, the Secretary of Defense shall submit to the Committees on Armed Services of the Senate and the House of Representatives a report on the new acquisition process developed pursuant to subsection (a). The report required by this subsection shall, at a minimum—

(1)    describe the new acquisition process;
(2) provide an explanation for any decision by the Secretary
to deviate from the criteria established for such process in paragraphs (1) and (2) of subsection (a);
(3) provide a schedule for the implementation of the new acquisition process;
(4) identify the categories of information technology acquisitions to which such process will apply; and
(5) include the Secretary’s recommendations for any legislation that may be required to implement the new acquisition process…”

A mechanism that is gaining steam for managing Agile projects following Section 804 is AgileEVM1, which uses the capabilities of the Agile SCRUM framework to develop Cost Performance Index (CPI) and Schedule Performance Index (SPI). These indices develop an Earned Value (EV)—or a project management technique for measuring project performance and progress in an objective manner. The net is ability for business owners to understand the Earned Business Value of an Agile project. The approach between traditional EV and AgileEVM are different, but the important point is a dialogue now exists where Agile SCRUM teams can be compliant with DoD acquisition guidelines. The following two bullet points show some of the difference in collected metrics: 

     CPI

• Traditional CPI = Budgeted Cost of Work Performed/ Actual Cost of Work Performed
• AgileEVM CPI = (Baseline Cost per StoryPoint)/Actual Cost per StoryPoint

    SPI

• Traditional SPI = EV/ Planned Value
• AgileEVM SPI = (Actual Velocity)/(Baseline Velocity)

From the time the Agile Manifesto was put on paper in 2001 so developers could provide their communal voice on how software should be developed, we are now hearing from the acquisition side of the house on how we can measure the value of their approach to software development. 

Related articles

• Keep Agile Development Going (devx.com)
• Agile development and Enterprise Architecture practice - Can they coexist (setandbma.wordpress.com)
• Agile eLearning - 27 Great Articles (downes.ca)