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
• 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
• 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 talked to a Program Manager for a major Washington DC Defense System Integrator who migrating his program to the DISA sponsored cloud www.forge.mil, in order to address his need to set up a secure virtual agile development environment for his distributed contractors. By doing so he expects to save hundreds of thousands of dollars and shave months of development time off of his project schedule since the procurement, set-up, and security compliance certification time alone in the defense community can take up to 9 months.  The higher quality, reduced development cycles, and increased user satisfaction agile provides will be added bonus to his Program. What convinced this SI to move his development project to forge.mil was the track record of success he saw for projects using the forge.mil cloud, which currently has over 7,500 defense users and 400 projects (quoted by the forge.mil Program Director Rob Vietmeyer)—and it is growing daily.

• 10 – 30 Year Life Cycles: In the commercial world, agile teams, tools, and support environments often come together like touring rock bands or the Olympics—sustainable teams that may work for months or a couple of years before disassembling. For instance, consumer electronics often have short lifecycles measured in single digit months—just look at the mobile market. But in the defense community, systems are often designed to have a lifecycle of 30 or more years. As a result, special consideration needs to be given to the processes, development strategies and platforms that will support hybrid styles of program with an ability to evolve in a managed fashion over decades. For instance, I talked to a Marine Captain who is achieving big results implementing his Command and Control program using hybrid development processes—waterfall for the overall program, spiral for major system components, and agile for subsystem development—all using forge.mil to support his distributed team and security requirements. This Captain is a huge fan of agile, and he is driving his procurement, culture, and development model more in that direction.

• Contracting Rewards and Policies: The aforementioned Dan Risacher described a case where agile development was used by a Defense Contractor to modify the system specs as the project evolved. The result was a system that was “right on the user target”. The development cycle had overwhelming user involvement and high user satisfaction in the end product. However, the Program Office financially penalized the contractor for not meeting the original DOD system spec which had been meticulously developed and locked down. Sounds crazy, right? But these procurement practices are law. The bottom line is that DOD Reward Policies are cumbersome and slow to react, and need to be modified to account for agile development characteristics. Today’s rapidly changing defense scenarios simply can’t afford the time that a multi-month change order process traditionally has taken to change a requirement. Furthermore, contracting officers need to be educated to fully comprehend the agile process, and what their role is when the War Fighter and the software developers are changing code in real time using virtual environments.

• Test Cycles: Beth McGrath, Deputy Chief Management Officer (DCMO), stated that DOD acquires over $40 billion worth of IT based systems every year and the average delivery time is seven years. It is common for these IT intensive DOD Programs to use a waterfall method of 80 months for development followed by a 6 month testing cycle (functional, performance, security, etc.). Per Dr Steve Hutchinson, the Test and Evaluation Executive for DISA, this process correctly tests the original specifications, but falls short in modern warfare environments where theatre scenarios are changing regularly. Clearly, the defense development and test cycles need to be modified. Over the past year, as agencies are beginning to embrace agile, Dr Hutchinson and his team have worked to reduce agile testing cycles to as short as 6 weeks. Now, there are further testing capabilities being released, such as i) test.forge.mil to further integrate testing into even shorter TDD agile iterations, and ii) the integration of DISA’s Rapid Access Computing Environment (“RACE”) to create a virtual end-to-end agile DevOps environment. 

We know that agile demands changes to commercial organizations with respect to team culture, development processes, and tools—especially now that most agile teams are distributed. I can tell you with certainty that agile issues in the defense industry are even more complex, with deep procurement, policy, security, and distributed team factors to consider. Evolving agile in DOD will benefit the US citizens immensely by saving tens of billions of dollars annually, and realizing reinvestment potential. It is an attainable target rich opportunity that excites and motivates many of us to continue to push the industry envelope—and frankly, for anyone that cares about national security. If you want to get involved, I’d encourage you to attend the AFEI events or join in the cloud-based agile development at www.forge.mil. These are open and vibrant communities.

I’d be interested in getting your feedback, especially from those of you that are in the defense community—there’s a lot we can achieve together.