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?

4 Answers 4


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.

  • 1
    +1 nice point on looking at the sprint lengths and incorporating contract mods in the length. Would you factor it into the release cycle or, into a planning or retrospective cycle. I was just reading Pawel's latest blog post and the mods seem like a relevant factor in Cadence for using Agile in large gov't projects. blog.brodzinski.com/2012/07/cadences-iterations.html Jul 19, 2012 at 16:06
  • 1
    The contracting discussion should probably occur during the retrospective, with planning only starting when you have authorization from the CO to proceed. This is based on my experience where contracts with DHHS were firm-fixed for materials and subcontracts but cost-plus for labor. Effort we put in before getting authorization could not be billed to US govt. If your contract is straight firm-fixed you could always start planning before getting authorization but that is a risk. Also, per Pawel's blog a retrospective every cycle may not be necessary, again that is also your risk.
    – Doug B
    Jul 19, 2012 at 18:46

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:

  1. Procurement guidelines come first, not agile development - you're spending the public's money.
  2. Program performance meassured in Earned Value comes next (if applicable).
  3. The management of capabilities and the derived requirements (all requirements are derived BTW), must be done with ruthless control. The open ended style of commercial software development has limited appeal in the DoD. There are instances where this is applicable, but most programs have a fixed "launch" date, with a fixed set of capabilities.
  4. There must be a "master plan," similar to the Epic concept, where the needed capabilities are defined in enough detail to recognize them when they appear. From there releases, and the iterations within those releases fit nicely into the IMP/IMS procurement framework of DoD 5000.02.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.