Agile Software Development: Bridges to the Future

BusinessWeek reader and Best Buy Senior E-Biz Architect Kevin Matheny writes that more companies would benefit from embracing agile project management

By Kevin Matheny

Maplewood (Minn.)-based BusinessWeek.com reader Kevin Matheny is senior e-business architect for BestBuy.com. He is also BusinessWeek.com Editor-in-Chief John A. Byrne's 2,500th follower on Twitter, where he's @kevinmatheny.

Story Tools

• post a comment
• e-mail this story
• print this story
• order a reprint
• suggest a story
• digg this
• save to del.icio.us

On my daily commute, I cross the Wakota Bridge in South St. Paul, Minn., and I find the contrast between bridge-building and -making software to be fascinating. The Wakota Bridge has been under construction since 2002 and is projected to finish in 2010. It's taken years longer than expected, but the delays won't significantly affect the quality of the end product.

It's frustrating to those of us who have to navigate the construction zone, but multiyear delays in a bridge project are not otherwise a problem because the fundamental constraints on bridge-building don't change much in that span of time. The river isn't going to get any wider, the structural strength of concrete isn't going to decrease, and the force of gravity isn't going to change.

Software engineering, particularly in Web development, does not enjoy the same kind of stability. Processors get faster, hard drives get bigger, bandwidth increases, operating systems and programming languages evolve. These technical changes, and the deliberate efforts of smart people all over the world, rapidly change the expectations of customers.

In 2002, when the Wakota Bridge construction started, Wikipedia had 48,000 articles and you probably hadn't heard of it. Today, it has more than 2.6 million articles in English alone, and if you haven't heard of Wikipedia you've been living under a bridge.

What's more, in 2002, YouTube, Facebook, and MySpace didn't exist, Google (GOOG) was the second-biggest search engine, and just 12% of U.S. households had broadband connections.

Clearly, we've seen incredible changes to the way people use the Internet and technology, and as a result, significant changes in their expectations. The Internet we have now is not the one we had six years ago. It's not even the one we had a year ago.

Longer Timelines, Greater Risks

What this means for managing projects—including any project that relies on the Internet to deliver its value proposition—is simple: The longer your project timeline, the greater the risk that what you deliver will not be what you or your customers need when you deliver it. Not only are longer-term projects more likely to fail due to changes in requirements or conditions during the project, they're more expensive. This increases the cost of failure. And because we can only do a few of them in a year, the impact of any one failure is huge.

So why embark on big projects? We are trying to minimize the wrong risks. We're so focused on avoiding the risks associated with incomplete information that we overlook the risk of changes in requirements. Large projects using the standard "waterfall" methodology (sequential stages of requirements, design, development, testing, and deployment) are designed to resist change, with formal change-request and approval processes. In an environment where the river can get wider while you are building the bridge, resistance to change is not a survival characteristic.

Mastering Corporate Agility

Like Best Buy (BBY), more companies need to embrace the mindset and principles behind agile software development. From a business perspective, that means three key principles: working components instead of complete solutions, expecting and responding to change instead of trying to eliminate it, and trust rather than control.

I had the chance to put this into practice in my current project, "Remix," an open API (application programming interface) for the BestBuy.com product catalog. Overall, it's gone extraordinarily well. We were able to get an initial version of the API up and running in less than 60 days—less time that it would have taken for us to complete a "vision and scope" document in the traditional process. Here's how we applied the principles.