Is agile the answer to government's IT skills deficit?

More and more I am hearing from people in or around the government IT community worries about the technical skills of the federal IT workforce. I suspect that the situation is not as bad as some allege -- clearly there are some very talented technologists the government -- but there does seem to be a problem with dated, or never-developed, skills in government IT shops.

That observation is central to the case for contracting out as much IT technical work as we do in government. (Inside commercial firms, a considerably larger share of such work is often done in-house). But the worry about lack of technical skills goes further than the suggestion that this justifies outsourcing so much IT. The larger fear is that the inadequate technical skills of many civil servants in agency IT shops not only keep them from writing code, but also leaves them unable to monitor the IT work product of contractors and pass judgment about whether it is good enough to accept or reward.

I want to put out there a thought about a way for the government to mitigate this problem. My basic idea is that using agile for IT development -- in addition to its other virtues as a way to increase the chances for a project's success -- also makes it easier for less technically trained government folks to evaluate contractor work.

There a several differences between the deliverables the government receives from a contractor during execution of an agile product and those received as milestone deliverables in a waterfall project. The first is that there are many more of them, connected with the many sprints into which an agile project is divided. This makes it easier for the government itself to learn by doing over time, and get better at judging agile work product.

Second, the individual work products are less complex and therefore easier to evaluate. Often the test for evaluating a work product is as simple as observing whether the incremental functionality actually works as promised. The government person will often be able to make this judgment as a user, even without technical skills. In evaluating deliverables the government is focused on whether a feature works, not whether it is properly architected or elegantly coded.

Compare this with the knowledge requirements for evaluating waterfall interim deliverables. Since the contractor often isn’t submitting anything that actually works at the early milestones, the government may want to evaluate the quality of code or architecture submitted, both of which require more skills. It the contractor submits “percentage complete” estimates, the government, to evaluate the deliverable properly, will have the difficult job of attaching a degree of credibility of such estimates.

Agile is not a magic bullet solution, of course. Even if individual deliverables from a contractor work and thus “pass,” the less-technical civil servant can’t figure out how good the architecture is. (Will it scale? Is it an efficient use of resources?) To answer such questions, the government may need specialized in-house skills or an independent verification and validation contractor. But agile allows the government to get a fair bit down the contract management road even with limited technical skills, and to economize on the need for not-always-present IT technical skills. It is a way out for what otherwise might be a very difficult dilemma for government.

As I have written a number of times in the past, there are many virtues to agile over waterfall as a development method, separate from any advantages in terms of contract management. I believe, though, that the argument I am presenting here is valuable icing on the agile cake. This may -- and I hope will -- encourage some government organizations to take the agile plunge.

Reactions from agile users, non-users and maybe-will-become-users are welcomed.