The NDIA Information Systems Summit II held in Baltimore was interesting in many ways:
- The government is seeking ways to improve the effectiveness of their IT dollars by (1) Early and continual involvement, (2) multiple and rapidly executed increments or releases of capability, and (3) early, successive prototyping to support and evolutionary approach. This directive from congress to the SecDef is stated in Section 804 of the National Defense Authorization Act .
- The domain of Department of Defense procurement was new to many of the agile participants. This was a surprise when the speakers from DoD were engaging in a conversation about how to bring agile into the DoD and the agile folks started with a clean slate assuming all the agile practices could just be installed and used.
- We had briefings from senior DoD leaders. The deputy CIO's and deputy DISA CTO. These guys have multi-billion dollar budgets. The US Government IT budget is $80B, DoD $38B, most of the services have their own around $7B or so, with DISA itself around $18B. As well the leaders are 2 and 3 star generals or senior government managers.
The prime outcome of the conference is:
- Agile can be integrated into government contracts. There is nothing in the regulations that defined the software development method.
- Agile is a software development method. Project and Program management is established inside the DoD context, so all the agile approaches to project management - mainly leaving the project manager out of the conversation - aren't there. What is there are coaches, Scrum Masters, "product owners" and that.
- The realization that Earned Value and a bunch of other FAR/DFAR guidance is required was news to many of the agile thought leaders. They were unfamiliar with the rigor these regulations are applied and the complexity of the acquisition process.
- While the agile folks see agile as doing everything on the project, the DoD folks defined boundaries where agile can go. That seemed to be news as well.
How to make Agile work in DoD
- Start bottom up. Start with the processes for developing deliverable code. Use Stories for capturing the behavior of software "pieces."
- Use Capabilities Based Planning to define the "architecture" of the product in a way that is familiar to the agile community. This is usually done with Stories, User Stories, Use Cases and the like. There were discussions about the various ways of doing this, what things are called, and how they are developed.
- This is one thing that needs improvement. There is really no standard definition (OK, a few) for what things are called. Epics, Releases, Iterations, etc. I'm going to try and collect these for our next meeting and start a Glossary.
- Keep the agile activities "inside" the work package for a start. This allows the Work Package manager to arrange the work around the release and not have to deal with the structure of the formality of DoD procurement at the actual development level.
- With the sequence of Work Packages around each iteration, and mainatining the BCWS across a rolling wave, Scrum-like activities can start to be directly applied to development.
The basis for all this is anchored in several sources. The best one is of course Dan Wards F.I.S.T. work. Dan's The Fist Handbook, The Simplicity Code, and Rogue Project Leader, should be mandatory reading for any agile advocate working in the DoD world and also the interview with Dan on POGO.
There will be much more on this topic in the coming months. But here's the core theme...
Agile software development can be used in formal and structured environments - like DoD - if the baseline conditions for the program (FAR/DFAR/OMB) are the starting point, then following the guidance from Dan, and then and only then deploying the agile principles.
I'm going to conjecture this approach will result in the broadest deployment of agile development processes. The IT budget of $80,000,000,000.00 completely overwhelms every other IT project collection on the planet. This is where the maximum impact will take place.