This past Tuesday, December 14th, I attended the U.S. Department of Defense Agile Development Conference in Washington DC put on by the Association For Enterprise Information (AFEI) - http://www.afei.org/events/1A01/Pages/default.aspx. During the conference the expanding commitment to agile by the DOD community was clear. Agile practices, from contract policies to cloud based development, have:
- achieved clear support up to the US congressional level as evidenced by the HR 2647, National Defense Authorization Act for Fiscal Year 2010 sec 804. This act is a significant milestone for Agile, in that, sec 804 prescribes that the U.S. Secretary of Defense must tell Congress how it will implement agile development in its future programs, and
- revealed benefits that are understood by the highest level of U.S. defense executives. e.g., DISA CTO Dave Mihelcic and DOD policy leaders such as Daniel Risacher (Associate Director for Information Policy and Integration, ODCIO DOD) who are driving IT practices DOD wide towards agile and open source, and
- recognized strong support from scores of program offices and tens of thousands of developers.
Although tremendous progress has been made, DOD adoption of agile is still in its early stages. Agile practices will need to expand dramatically in the defense industry before it achieves mainstream acceptance within the DOD - not just in development, but in policies and contracting methods as well. This represents a great opportunity for the defense department, contractors, agile and open source evangelists, and industry vendors/suppliers alike.
What’s remarkable is that this is quite a different response to the one we received 7-8 years ago when CollabNet first started promoting “collaborative open source development practices (which later evolved to “agile”)” to the DOD. These practices can literally shave billions of dollars off of the defense budget by enabling the well know infrastructure benefits of the cloud, shortening development cycles, and by enabling systems interoperability. Fast forward to December 2010.
At this year’s AFEI conference, sessions were led by leaders in the agile defense community including my colleague Mike Kochanik – VP of CollabNet Federal, Scott Ambler – Practice Leader Agile Development at IBM, Dave Mihelcic – CTO of DISA, and many others. Nearly 200 prominent industry and defense executives, program owners, and developers spent the day discussing the merits of agile and sharing success stories and challenges of using agile methods versus traditional methodologies. It was a healthy debate.
Despite the acceptance of agile, by what now seems like virtually every corner of the defense community, an indication that the adoption of agile in DOD is still in its infancy was illustrated by a simple poll of the audience. When the 200 member audience was asked: “How many of you have attended a 2 day Scrum course to get started?” less than 10 attendees raised their hands. So even while there are many expert agile teams and suppliers in the defense community, this simple poll demonstrated that even the basics of agile are not well understood. This is important, because many agile advocates believe that laying a solid foundation is critical to growing agile successfully within an organization.
The bottom line is that is that Defense Programs are unique, which means that Agile practices will need to evolve to address the DOD’s needs. Agile in the DOD will need to address governmental policy and contracting issues associated with the move to Firm Schedule/Fixed Price Contracts, the demand for development tools that support top secret security requirements, the resistance by traditional integrators whose business models still rely on time and materials based contracts and more. I won’t dwell on these topics and others that were discussed at the conference, but a few are worth sharing further:
- Complex and Distributed Contractor Hierarchy – The defense community often has software components that don’t always fit so nicely within contractor corporate boundaries. It is quite common that geographically dispersed contractors work on the same code –with markedly strenuous security and IP concerns. For example, I