Agile Development Can Avert Disaster

CASE 1 A Portal to Nowhere

The developer: Kent Odland, technical manager at Federal Express.

The project: A B2B portal for the parcel delivery industry.

The damage: More than $15 million over four years.

In 1994 FedEx conceived of a massive B2B supply chain automation system that would link order information and inventory, among other systems, in real-time. The system would link all parcel companies with all their customers, partners, banks and suppliers in real-time. In 1996 the project broke virtual ground. Then, one day in 1998, the approvals?for equipment and for consultants?just stopped.

“That’s when I sort of knew it was over,” says Odland, the portal’s technical manager. “Things just dragged. It starts with talk like, ’Maybe we could use this internally,’ or ’We ought to think about how to redirect this effort toward something else.’”

The project limped on for another quarter until its director and chief architect finally resigned. Most of the development team followed, and eventually, FedEx was out of the portal business without ever finishing the software.

Odland’s blame pie reflects three key reasons why the project collapsed.

Sponsor apathy. Odland remembers his team members selling C-level executives on the idea for the portal. They gained high-level sponsors by convincing management that the software could create new revenue streams.

But they forgot to continue selling them. “We didn’t even get a real live customer as a reference. So the sponsors don’t hear from us, don’t have anything to endorse or anyone to endorse it,” Odland says. “At some point they just decided it was costing more than any revenue it promised to bring in.”

Developers’ bad attitude.

Executive myopia. Sales executives blanched at the prospect of running a portal that was open to the competition. But up in the developer’s ivory tower, that was crucial to the platform’s success. Apoplectic sales executives demanded the programmers change it to a company-only B2B exchange. To Odland, that sounded strikingly like the supply chain they already had and were trying to improve upon.

“It was too radical for them,” says Odland. “What we ended up with was a bunch of great ideas for software without any real-life input.”

The Agile Analysis

In theory, Agile Development is supposed to bring the business experts and the developers closer together. In this FedEx project, they were miles apart?literally. Odland was in Dallas, 1,000 miles from FedEx’s Memphis, Tenn., headquarters.

Early on, the project’s funding seemed to be unlimited. Minimal budgeting would have forced Odland to demonstrate the project’s merits to business experts before his budget was simply cut off.

Engineering set requirements. Agile developers always have business input into requirements. When people on the business side realized FedEx would be running a portal that supported packages from, say, UPS, they flinched. If they had been asked about requirements up front, this disconnect would have been discovered before $15 million was wasted.

CASE 2 A Control System Out of Control

The developer: John Brozovich, advisory project manager at a large data storage company. (Brozovich requested that the name of his company not be used.)

The project: Storage management software.

The damage: Seven years, “tens of millions of dollars,” 35 programmers.

Brozovich’s data storage company wanted a new program to control its systems. At the same time, it seemed like a good idea to redefine the requirements of the original software, since the program to be replaced was written in 1974.

The project started in 1991, before Brozovich joined the company. When he came on in 1995, not much had been accomplished other than some new requirements having been loosely defined. In late 1996 a department formed around the effort and gave the software a name: Library Control Systems. More requirements were gathered. Six months later, the name changed to Library System Support. Nine months after that, the team gave the project a code name, Python, and received 18 months of funding.

By then, the team had swelled from 10 to 35 developers. And when the requirements were finally finalized, there were 1,800 of them. Half were engineering requirements written to make the other 900 customer requirements work.

“Right then was about early ’98, I think, and I can’t imagine how many millions of dollars were gone,” Brozovich says.

Brozovich estimates that the team was only about 18 months from a product release when executives decided that they couldn’t wait any longer.

On April 1, 1999, the executives gave the Python team 30 days to finish whatever they were working on, at which time the developers would hand it over and lose their jobs. Happy April Fools’.

“It’s a painful process,” says Brozovich, who divvies his blame pie four ways.

Sponsor apathy. Brozovich is bemused by the fact that the project’s requirements phase dragged and then bulged. Everyone had a requirement to add. No one ever said no, because no one on the business side ever took ownership of the project.

Lack of focus. The sheer number of requirements should have raised a red flag.

No deadlines. The first deadline on the project was the last. Not forcing deadlines fed the lack of focus.

Erratic executives. The project never had one set method of funding. And then executives started reacting to short-term market forces. “The end was in sight. Then a budget cycle comes up, the stock goes down, and they decide they can’t wait,” Brozovich says.

The Agile Analysis

An Agile project sets a minimum number of requirements and turns them into a deliverable product. If more requirements are wanted or needed, they can be added later to a finished product.

The 1,800 requirements and the fact they took years to define are clearly anti-Agile. The whole project?the budgets, deadlines and the size of the team?became bloated.

“For 20 years we’ve trained [executives] to expect a document that lays out the plan,” says Brozovich. “Minimalism suggests you don’t have that detailed a plan.” Instead you have a memo or a diagram on a sheet of paper, like DePauw at Caterpillar Financial Services.

“We need to educate CIOs and CEOs on Agile methods if they’re going to work. Otherwise, they’ll be pounding their fists asking where the hell the requirements document is,” Brozovich says.

The project was ultimately killed because executives simply ran out of patience. If Agile methods had been used, Brozovich believes, the project would have been completed before that had a chance to happen.