Focus on the people today if you want agile to succeed tomorrow, argues Lawrence Fitzpatrick.
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
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.
NEXT STORY: A guide to creating a culture of performance