Agile development requires agile developers

Agile Development Stock Image

The federal government is actively adopting agile development for IT software projects. But transforming to agile development is hard for agencies with a long history of “detailed-requirements-first thinking” that is codified in every step from procurement to production delivery. And the government’s struggle with constructing appropriate contracting arrangements for agile development only compounds the situation.

As we move to agile, it helps to remember the lessons we learned from the last era’s mistakes ─ large, low-skill teams and long timelines can equal costly failures. 

Specifically, I contend that to get the best results from software development projects, we must attract and retain skilled individuals, and we must invest in building high-performing teams over several years.

Impediments to agile

The latest trend in agile contracting is creating contract mechanisms that allow the government to buy teams of programmers and coders for short periods of time.

For example, an agency might want an agile team of seven or eight people for the next six months. But there is no ready “bench” of agile teams (much less high-performing teams) waiting to ship out whenever the government decides it needs them. Building productive teams takes time, because they need to learn to work together and to learn the mission and problem domain.

Also, leadership needs to frequently make adjustments in staffing in response to changing conditions or to correct a bad fit. Only rarely does a team become high-performing in less than six months. The result: organizations never reach their potential -- which keeps costs higher and quality lower. I equate it to feeling like you’re stuck in first gear.

Furthermore, current government approaches have focused on keeping costs down by keeping unit costs low. This means hiring the least expensive personnel. Dozens of studies over the last four decades have found that top performers are as much as 50 times more productive than the median. Yet, they rarely cost 50 percent more than the median. If one does the math, it’s not hard to see that a small team of high performers dramatically outperforms a large team of mediocre performers ─ delivering more features, with higher quality, at substantially less cost. We need to shift contracting to select for high individual and team productivity, not low individual labor rates.

Finally, the federal government tends to separate new application development from application operations and maintenance. Such a division in software development contributes to high operational cost, increases risk for new programs and stifles innovation in operations where most of the lifecycle cost of application work resides. The most successful agencies do not separate this work, and neither do world-class companies like Google and Facebook.

Building skilled teams over time makes the difference

Organizations ensure inefficiency when they contract for resources short-term, select contractors on lowest unit cost and isolate maintenance (i.e., domain knowledge) from new development. They never achieve productivity because every activity is going to be a startup exercise, which is the least effective point on the productivity curve. Transforming O&M into high performance delivery organizations yields astounding productivity and delivery results, and drives innovation.

One successful example is the Federal Communications Commission’s recent spectrum auction. This was a $45 billion sale of government airwaves to commercial firms. With only three months between the project start and the beginning of the auction, success was achieved because a skilled team delivered small, frequent iterations for early validation.

The lesson is clear. To improve contracting for agile development in the federal government, organizations should seek small- to medium-sized, multi-year contracts for small, high-performing teams. Hold the contractor accountable for timely, incremental delivery of quality software. Multi-year contracts allow the vendor community to hone the team over time, bring the best possible skilled team members to the mission, and deliver savings, innovation and quality to the government.

A major benefit of this approach will be fewer program failures and more successes. An added benefit is that less money will be spent on application development and it will improve overall efficiency and project success.

About the Author

Lawrence Fitzpatrick is a general manager and senior vice president for NCI Inc. of Reston, Va.

Rising Stars

Meet 21 early-career leaders who are doing great things in federal IT.


Reader comments

Thu, Jul 2, 2015 Ina Beth Wash, DC

It's amazingly sad that stating the obvious seems necessary, but unfortunately it seems to be the case. This article is rudimentary, yet rudimentarily true. The government is largely rate focused and two steps away from picking up its programmers at the local 7-11. It's the only entity on the planet which I'm aware of that, on firm fixed price contracts (where the idea is one pays for delivery), consistently asks for labor categories, hourly rates and level of effort estimates. As long as outcome is not the key driver, no amount of "how" will change the game.

Fri, Jun 26, 2015 OccupyIT

"But there is no ready “bench” of agile teams (much less high-performing teams) waiting to ship out whenever the government decides it needs them." More self congratulatory horse hockey justifying poorly managed USG projects. Take a look at GSA's vaunted 18F BPA. The government can't even answer the question in an agile way and is now extending the deadline for submission - arguably one of the key criteria for an agile response. Agile teams exist but the government counterparts are just not mature enough to take advantage, or in some cases even recognize an agile team if they had one in front of them. I do agree with the part about looking at smaller, already successful projects - odds are they are ALREADY agile in order to get the work done but get dismissed by the cocktail circuit CIOs as small fries. So, we wait for GSA to give the fat boys enough time to get their lumbering organizations in gear so they can glad hand everyone into giving each other Fed 100 awards for their 'new' agile projects. I guess people can look each other in the mirror each morning and convince themselves of just about anything. Agile requires an organizational maturity that includes self analysis for continuous improvement. If you can't even tell you're not agile...

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