Covert Agile

I selected the "Covert Agile: Development at the Speed of…Government?" session to complete my Tuesday morning schedule. It turned out to be a pretty interesting experience report by a consultant who did a contract for the United States Department of Defense. The project was to re-write some legacy satellite scheduling software so it would work with modern hardware. It wasn't just for the thrill of using the latest and greatest hardware though. They were actually forced to go on ebay.com to find replacement parts because nobody produced the old hardware they were dependent on. Having DoD software running on machines bought on ebay is not very reassuring for American citizens.

They knew that at least one previous attempt at doing this by another company had failed. It didn't fail because that company didn't deliver, on the contrary, they delivered a complete working solution after many months of work. However, the operators simply didn't like the interface. They refused to use the new software so the project was a failure.

So it was obvious that if they were to succeed, they needed to include the operators very early in the process, and have relatively short iterations, with rather fluid requirements. They wanted to be Agile. However, in order to get the contract they needed to hide their Agility! They were required by DoD to provide "Waterfall" type artifacts at various milestones in the project. They actually had to hire people to produce all these "Waterfall" artifacts, and deliver them to DoD. These people were not contributing anything to the software, they were just producing heavy documents and sending them upward to be able to keep the contract.

In the end they succeeded, but the presenter said he hoped to never have to do such a contract ever again. I think a part of his soul died during this project and was buried in a large requirements binder.

As a last note on this session: the presenter mentioned that one thing they did that helped them was to leave a certain proportion of sprints (say 1 in 4, or 1 in 5) entirely dedicated to bug fixes, refactorings, etc. We sometimes do something similar, but in our team it seems to be reactive, and somewhat disruptive for the schedule. In their case, they were proactively planning for it from the beginning of the project.