Guest View: It's Not Too Late to Learn - Software Development Times On The Web

Guest View: It's Not Too Late to Learn
By James Shore

August 15, 2005 — On Feb. 3, 2005, Robert S. Mueller III, director of the Federal Bureau of Investigation, appeared before a Senate subcommittee to explain how the FBI had managed to waste US$104.5 million.

This couldn’t have been a very comfortable position to be in.

In 2001, the FBI had launched the Trilogy project, a project designed to update the FBI’s IT infrastructure.

Trilogy came in three parts: update the network, update the hardware and update the software. Guess which one Robert Mueller was talking about?

That’s right—the software. “Virtual Case File,” or VCF, was intended to allow FBI agents to upload information to a centralized database so that it could be easily accessed by others.

It was a disaster, and the $170 million project was canceled for a loss of $104.5 million.

Sadly, the loss was entirely avoidable: The FBI made many classic mistakes. In this article, I’ll take a look at three of these mistakes and apply lessons learned from the agile software movement.

Classic Mistake No. 1: Ignoring the Users. User involvement is a critical factor in the success of software projects.

In its 2004 CHAOS report, the Standish Group cites user involvement as the top project success factor, and lack of user input as the top cause of project problems. Despite this, there is no indication that the FBI made the involvement of actual agents a priority in VCF development.

In agile projects, user involvement is a central concern.

Many agile projects have an “on-site customer”—a user representative who is directly responsible for picking priorities and defining features. Agile teams produce working software every month (or even every week) for demonstrations and user review. They recruit outside customers to regularly review these releases and provide feedback.

User involvement isn’t easy. At the March meeting of the Portland Software Development Roundtable, a participant described a government project for the state of Oregon. For several periods of six months, different groups of seven to eight users were physically moved to the capitol in order to work out detailed requirements. Larger user groups did extensive testing and review close to each release.

Ultimately, development involved 1,000 users around the state. This was no small investment, but it resulted in a successful project.

Admittedly, the users with the best understanding of what’s needed are often the ones who are the busiest doing other important things.

It can be hard to get their time. It’s tempting to say that you don’t need those users and hope that you can get by with just your business analysts.

Got $104.5 million to burn to find out?

Classic Mistake No. 2: Expecting Requirements to Remain Stable. Requirements always change. Always. Expecting requirements to remain stable is like expecting the weather to be the same every day. It’s tough for users to imagine what they want without seeing it, so when they do see it, they’re going to change their mind.

The FBI dealt with this fact of life in the same way many companies do: by complaining about it. This is a slightly less sophisticated form of the “change control board,” a thinly disguised mechanism for preventing requirements changes. Either way, preventing requirements changes just means that the software you deliver is less likely to do what your users need.

Agile projects acknowledge that change is inevitable and put mechanisms in place to make it possible.

As previously mentioned, agile teams take every opportunity to produce working software and to show their software to actual users. This helps identify changes early and allows them to be implemented more easily.

Extreme Programming, an agile method with the catchphrase “embrace change,” goes even further. It describes specific design and programming techniques that make the software more malleable and able to deal with arbitrary changes. These techniques include Test-Driven Development, Refactoring and Simple Design. If your team isn’t familiar with these practices, now is the time to learn.

Classic Mistake No. 3: “Big Bang” Deployment. VCF was meant to be a replacement for a mainframe-based “green-screen” application. The FBI decided to deploy VCF with a “big bang” approach: They would develop a full replacement for the old application, switch off the old one, and switch on the new one.

This is a foolhardy approach. From a technical perspective, it means that you have to have a complete replacement for all of the functionality in the old system.

Often, it means that even defects in the old system have to be replicated, because other systems depend on those defects to work properly. It’s an immense undertaking, one that’s very difficult to get right.

Even with perfect technical execution, a big-bang deployment is foolish from an economic perspective as well. Big-bang deployment means that you can’t deploy anything until the end of the project. That means you see no benefit—no return on investment—until the very end of the project.

Agile projects already create working software on a monthly or weekly basis for their users to review.

It’s no surprise that agile teams like to deploy frequently as well. Rather than waiting for all features to be completed and doing a big-bang deployment, an agile team will identify the most valuable features of the new system, work on one at a time, and deploy each one incrementally as soon as it’s finished.

This makes a lot of sense. Integration is a big source of risk and doing it in a smaller chunk, sooner, helps mitigate that risk. At the very least, it identifies unexpected integration problems much earlier in the project. Economically, it allows value to start flowing early. Incremental deployment requires the old and new system to exist side by side for a time.

Although this can be a technical challenge, and could increase costs, it’s lower risk than a big-bang deployment. The reduced risk and economic benefit of seeing value earlier should outweigh the increased costs in almost every case. Big-bang deployments are just too dangerous.

It’s Not Too Late
The classic problems listed above weren’t the only problems plaguing the VCF project. Contractual issues and management churn completed the cocktail. As a result of these problems, VCF has been canceled, to be started over with a new acronym.

The FBI director’s testimony before the Senate shows that the FBI has recognized Classic Mistake No. 3 but not the other two.

It’s too late for the FBI, but it may not be too late for you.

Does your project involve users, expect requirements change, and deploy incrementally? If not, now is the time to start.

Standing before the Senate and telling them you’ve wasted $104.5 million of taxpayers’ money is no place to be.

James Shore is a longtime Extreme Programming coach and agile practitioner. He writes about agile software development at www.jamesshore.com.

EMAIL THIS ARTICLE

SEND FEEDBACK

MORE OPINIONS

SUBSCRIBE TODAY!

E-Newsletters:
  News on Mon/Thurs.
  Test & QA Report
  EclipseSource

SUBMIT

JOB BOARD

PDF & PRINT EDITION

* Requires Resource Account! LOGIN or SIGN UP

* Download Current Issue!
ISSUE 8/1/2008 PDF

* Need Back Issues?
DOWNLOAD HERE

Receive The Print Edition?
SUBSCRIBE HERE

EVENTS CALENDAR

SHARE 2008
8/10/2008 to 8/15/2008
San Jose
SHARE

ACM SIGGRAPH
8/11/2008 to 8/15/2008
Los Angeles
ACM SIGGRAPH

Intel Developer Forum
8/19/2008 to 8/21/2008
San Francisco
Intel

Business of Software 2008
9/3/2008 to 9/4/2008
Boston
Red Gate Software

VSLive New York
9/7/2008 to 9/10/2008
New York City
1105 Media

MORE EVENTS

GET NOTIFIED!
About all of the latest Resources

SD TIMES 100

6th Annual SD Times 100

It's time once again to
recognize the organizations
or individuals that have
demonstrated leadership in
their markets.

HOME SITE MAP RSS CURRENT ISSUE BACK ISSUES SUBSCRIBER SERVICES ABOUT US CONTACT US BZ MEDIA