There is an interesting discussion that has been reignited by Jeff Sutherland about the U.S. Department of Defense using Agile project management. While it seems that there is broad consensus as to the value of using Agile on government projects, Glen Alleman brings up some practical, contracting/regulations issues.
Given those concerns, is Agile feasible for large DoD projects? If so, how can the issues be addressed?
Maybe the work I did with US govt is transferrable to your situation.
We had a lot of changes in scope over the course of our DHHS programs as we were doing pharmaceutical development which to a very large degree is iterative and subject to change... kind of like Agile but dragged out over months/years. This required endless contract modifications to amend scope, cost and timescales - not only between us and DHHS but also us and our subcontractors.
Factoring in the costs of a FT contracts specialist isn't a big deal. What will cause you problems is the time to get the contract mods started. Your US govt contracting officer will need to have thorough documentation on what the impacts on time and cost are for each change in scope so that s/he can justify the changes. Depending on the contracting officer this can involve a lot of back & forth even to get to the point where they say "We are OK with changes, you are authorized to proceed". If you need the contract mod in place before they will authorize it will be even longer. Bottom line is you will have to plan on your sprints being long enough to accomodate this type of discussion.
Doug and Mark,
Not only is agile feasible, it is already in use in many forms. Starting 2002, Lockheed Martin applied eXtreme Programming to the Atlas-V embedded flight control systems. A paper was presented at the SEI CMMI conference in Denver. I have a copy if you want.
Many aerospace and defense contractors use iterative and incremental development processes embedded in Rolling Wave program management. Rolling Waves, incremental "drops," emergent requirements are built into the DoD procurement processes in the form of the Integrated Master Plan / Integrated Master Schedule paradigm.
Here's a briefing http://slidesha.re/mq37vD on how to integrate agile with the FAR/DFARS procurement processes. It's the procurement processes that need to change. Ignoring the need to have credible agile processes in place. As well, Earned Value Management from the FAR/DFARS flow down ANSI-748-B Guidelines must also be in place.
Much has been written on how to do this, but care is needed:
It can be done, but rarely is it successful by trying to displace the existing processes - as is common in the commercial world. There are efforts underway inside DoD and the NDIA (National Defense Industry Association) for deploying agile methods for enterprise IT. The NDIA C4ISR group is where this effort takes place.
I currently work with DHS defining how agile will be adopted across the department. We created our basic framework in a couple of months and there are now several level 1 and 2 (ie large multi million dollar) projects that are following it. As part of that, we have had the opportunity to chat with several DoD folks (and to join the SEI group doing research at the DoD on agile procurement) and they are executing in an agile fashion. They are incorporating some of the open source movement as well in forge.mil. The procurement and systems engineering practices and processes came out of bending metal and were adopted to software initially. Now there are at least a couple of schools of thought moving through the existing governance. First is to rewrite and second is to interface. While there is a movement to rewrite, it has not yet come to fruition. Interfacing with governance is a more common practice. Figuring out the proper places to run agile within the program, but be able to report out as needed for procurement functions. The project I am working on now does exactly that and has been appluaded for the ways that we are using agile to comply with the procurement processes and been approved for all of the traditional "gates" while executing on the project in an agile fashion.
Many excellent points are raised in other answers. Keep in mind that doing agile development really well mandates a culture shift. Everyone needs to buy in.
For agile development, as envisioned in the Agile Manifesto, to succeed in the large, gov't project space, the procurement process would have to change. As Greg points out - "you're spending the public's money" so procurement rules must be obeyed.
That's a really tough nut to crack which is why I've avoided the federal government space for years.
