Archive for June, 2012

Scrum and the DOD

Monday, June 18th, 2012

I worked with the Air Force a few years back as a Scrum Master for a series of R&D projects.
In our office watching the movie “The Pentagon Wars” was required viewing.

Working with the DOD is problematic because you are not working with the customer, you are working with the contract office.
The contract officers usually have no visibility into the writing of the contracts.
On top of that, they are judged on how well the contract is followed, not on how well the resulting software meets the needs of the war-fighter.

The problem (or trick) is two fold.

1) you have to get your hands on the Colonel or General who is interested in the success of their project and is willing to have you make the software the way they need it, not like they specified it.
2) you have to write the contract in vague enough language that you could *almost* be playing half-life and still fulfill on the contract.

To a certain extent, we were highly successful.
We usually had Captains, Majors, and senior non-coms on our 2 week sprint reviews, occasionally we would have Lt. Colonels and Colonels in those meetings.
On our development team we had a former Air Force major (from the contract office) as our product owner, and another member of our team was a former naval flight Captain (O-6) from a carrier group.
Having these two on our team made a vast difference in being able to communicate that we understood their pain and were working hard to solve that pain.

Our biggest frustration was that the contract office only wanted our documentation.  They expected us to send them our source code as part of the documentation package, but that was incidental.
Yes, source code.  They never compiled the the software, let alone tested it.
Keeping the CDRL (“See-Druls”) up to date was just part of each stories done-done criteria.
The squadrons that we worked with loved how responsive we were to their requests.  They were amazed that we could put their requests into working code in a 2 week period.

Moving forward:

If you are working with the DOD, need to have a high level staff officer (preferably general grade) who will act as a sponsor and a go between with the contracting office.
This needs to be done *before* the contract is signed.
If you are working with an existing contract, you’re out of luck.

If you can get to a general grade officer and explain to him that you can put software that does what he needs it to do, and more importantly, that you can respond to his situation and give him what he needs today, not what he specified in the contract 8 months ago, you will go far.

The battle field military is a very agile organization.  They understand that they won’t really understand the situation on the ground until they get on the ground.
At the same time, military procurements have always (all the way back to the Romans) been full of graft, corruption and incompetence.
Our current procurement process is in place to try to minimize those excesses.

If you are writing software for the DOD, good luck.  It’s cool work, but its very frustrating at times.