the lectern banner

By Steve Kelman

Blog archive

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

Shutterstock image. Copyright: Kalakruthi

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.

Posted by Steve Kelman on May 24, 2017 at 11:52 AM

Cyber. Covered.

Government Cyber Insider tracks the technologies, policies, threats and emerging solutions that shape the cybersecurity landscape.


Reader comments

Thu, May 25, 2017 Mike Moxcey

I think the reason agile works "better" than waterfall is only because of the speed. 1. You can get the project done before the users can change their minds (major problem with waterfall methodology and all-in-one projects). 2. The users themselves are forced to talk to the developers and start hearing "No, that's not going to work." Most folks have this idea that the computer software is the process when in reality, the process is whatever the organization does and the computer is supposed to support it. The system cannot enforce correctness tho (but that's the goal in the back of all the manager's minds).

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above

More from 1105 Public Sector Media Group