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

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.

An agile business is willing to deliver part of the solution now to start generating value now. What part of the value proposition can you deliver within two months? Get that done and roll it out. Find out what people think of it, and change course as needed.

For Remix, we focused on a limited scope (read-only product catalog data). We know we have an imperfect solution—there's more latency in the data than we want, we don't have a commerce API yet, and our store-level availability data is a nightly snapshot rather than real-time. But we have something out there in the wild that people can use and react to, and we're getting real feedback on what works and what doesn't. We're also realizing value out of what we do have now, rather than in two years.

Making Change Work for You

When you are dealing with a moving target, trying to control change only hampers your ability to course-correct. Don't try to create complete documentation up front. It will be out of date before you are done. Do have a good system for keeping all team members up to date on what you're doing. Regular meetings are one way to do this, but keep them short. Remind the team that the important thing is the outcome, not the path to it. Create the documentation as you go, recording what the system does, not what it's supposed to do.

For example, I recently added a story to the tracker for Remix that read simply "flag products as new if their start display date is less than 30 days in the past." That's all the up-front documentation needed for Pivotal Labs, a development company that specializes in agile software development, to code that function into Remix. Any additional information can be gathered in the daily 15-minute team meetings or in a longer follow-up if more time is required.

Trust is tied closely to how you deal with change. Often, extending trust is hard for businesspeople working on technology projects, because we don't know how to do the work. We often look to the documentation—requirements, design specifications, and the like—to give us the feeling of control over the outcome. Don't bother. If you can't trust your team to deliver, you have the wrong team.

Find people you can trust, and then let them do the work. Talk every day, and make sure that the development team has direct access to someone who will be using the product every day after release. For Remix, we've never had a formal project plan, never had a requirements-gathering session, never created a requirements document. We chose the right partners, told them what we needed, and got to work. We have control over the outcomes, but we're not worried about trying to control the details of how we get there.

Agility Benefits

Aside from reducing risk of failure or irrelevance due to long time frames, there are three other key benefits to embracing agility. Your projects will consume fewer resources, so you'll have a lower barrier to entry for your project process. You'll be able to try more things, increasing your chances of finding the standout ideas. You'll get feedback more quickly, so you can identify what's working and what isn't—and cut your losses on the things that are not working. And as you'll be putting part of the solution in play quickly, you'll be able to start recouping the financial investment in your project sooner.

Becoming agile isn't easy, but it's increasingly necessary as the pace of change in the world increases. And it's incredibly rewarding as well. Not only do we get results more quickly, I spend more time on productive activities instead of on documentation, administrative busywork, and fighting over whether what we got was what we wanted. For your next project, try becoming agile. You'll never look back.


Tim Cook's Reboot
LIMITED-TIME OFFER SUBSCRIBE NOW
 
blog comments powered by Disqus