BT: A case study in agile programming

In 2005, BT Group began replacing an aging Unix-based phone-traffic monitoring system with a Web-centric architecture. The intent: To allow traffic managers to make quicker changes to switches and other physical devices to handle shifts in network loads -- on any point in the company's vast telecommunications network -- without risking system overloads.

The new system, rolled out in late 2005, has made the work of these phone-traffic controllers much easier for network load balancing; the system it replaced was difficult to upgrade. At that point, few people in the company even knew how the old system worked, says Kerry Buckley, a lead software developer in Ipswich, U.K., who worked on that project team.

But the most dynamic part of the development effort was this: The project was completed within the construct of BT's nascent 90-day agile development cycle. Prior to the London-based telco giant's shift to an agile development methodology in 2005, it could take three to nine months for a third-party developer to gather specifications. Then the development itself could take up to 18 months or longer to complete, according to Al-Noor Ramji, CEO of BT Design and CIO at BT Group.

A traditional software-testing cycle, typically done after coding had been completed, would have prolonged the project by several additional months, says Ramji. The company's shift to 90-day and often 30-day software iteration cycles is at least four times as fast, he says, meaning they could deliver the end product that much faster. The central idea behind agile programming is to code quickly, test out what you've done, fix any problems and then move on.

Although telecommunications companies haven't historically been associated with progressive development approaches like agile, BT's IT organization needed to speed up its system development cycles to help it deliver new mobile and other types of telecommunications services.

BT's shift to agile also meant that its 3,000-person global development organization would be working more closely with end-users. This was especially true during the requirements-gathering stage to better understand and meet user needs, says J.P. Rangaswami, managing director of service design at BT Design in London.

To help beef up its developers' people skills and understanding of agile, BT put its programmers through a series of classroom and hands-on training sessions, says Rangaswami. The company has also recruited an unspecified number of IT professionals with agile experience from a variety of industries over the past two years who are helping to teach other developers who are relatively new to these disciplines, he adds.

Changing the mind-set
Even though BT's shift from traditional waterfall development techniques to agile has led to significant productivity and business benefits, it didn't happen overnight, nor was it easy for a company as massive and widespread as BT, say Ramji and Rangaswami.

For starters, the company's IT leaders had to break through some misperceptions among internal and external business customers that agile meant they could introduce frequent feature changes during the development cycle to suit their whims, says Ramji.

Plus, the company's shift to agile development was "more readily accepted" by senior executives and junior staffers, says Ramji. Middle managers were more skeptical about how it may impact them. The naysayers included IT infrastructure managers who had gotten used to having more formalized documentation for new software or enhancements being made to existing systems, says Rangaswami.