7/31/2019 BT Case Study on Agile

1/2

InfoWorld Home/Developer World /News / BT: A case study in agile programming

March 11, 2008

BT: A case study in agile programming

U.K. telecom giant BT Group adopted agile programming in

2005 and found that after some initial speed bumps, the

development philosophy is a boon to its business

By Thomas Hoffman, Computerworld | IDGSister

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

The new system, rolled out in late 2005, has made the work of these phone-trafficcontrollers much easier for network load balancing; the system it replaced was difficult toupgrade. 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 thatproject team. But the most dynamic part of the development effort was this: The projectwas completed within the construct of BT's nascent 90-day agile development cycle. Priorto 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. Thenthe 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, wouldhave prolonged the project by several additional months, says Ramji. The company's shiftto 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 agileprogramming is to code quickly, test out what you've done, fix any problems and thenmove on. Although telecommunications companies haven't historically been associatedwith 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 oftelecommunications services.

BT's shift to agile also meant that its 3,000-person global development organization wouldbe 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, managingdirector of service design at BT Design in London. To help beef up its developers' peopleskills and understanding of agile, BT put its programmers through a series of classroom

http://www.infoworld.com/http://www.infoworld.com/http://www.infoworld.com/d/developer-worldhttp://www.infoworld.com/d/developer-worldhttp://www.infoworld.com/d/developer-world/newshttp://www.infoworld.com/d/developer-world/newshttp://www.infoworld.com/http://www.infoworld.com/d/developer-worldhttp://www.infoworld.com/d/developer-world/news

7/31/2019 BT Case Study on Agile

2/2

and hands-on training sessions, says Rangaswami. The company has also recruited anunspecified number of IT professionals with agile experience from a variety of industriesover the past two years who are helping to teach other developers who are relatively new tothese disciplines, he adds.

Changing the mind-setEven though BT's shift from traditional waterfall development techniques to agile has ledto significant productivity and business benefits, it didn't happen overnight, nor was it easyfor 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 amonginternal and external business customers that agile meant they could introduce frequentfeature changes during the development cycle to suit their whims, says Ramji. Plus, thecompany's shift to agile development was "more readily accepted" by senior executives andjunior staffers, says Ramji. Middle managers were more skeptical about how it may impactthem. The naysayers included IT infrastructure managers who had gotten used to having

more formalized documentation for new software or enhancements being made to existingsystems, says Rangaswami.

To help work through those doubts, business customers were invited to BT's development"hothouses" to see for themselves how the 90-day development cycles worked. Thanks todaily interactions with BT's software developers, even some external customers "havebecome complete believers in this, in that it gives them far better control" in projectdevelopment efforts, says Ramji. BT's development organization invested less than $5million to launch the agile initiative, including classroom and workshop training for itsdevelopers. The company also had to change its own outlook as to how projects would bemanaged and executed. A quick, iterative agile development approach lends itself to

software projects involving co-located development teams situated in, say, London andIndia, says Rangaswami. Ramji, Rangaswami and other BT IT leaders also had to convinceIT managers and staffers that agile didn't necessarily mean they were deemphasizingsoftware quality assurance and testing. "Historically, we used to do 16 or 17 different typesof tests" before a system was put in production, says Rangaswami. "Now we've determinedthat only one test matters -- from customer concept to completion."

So instead of measuring the differences in software defects that might have beenintroduced using a waterfall development approach versus agile, BT has begun trackingimprovements in development cycle times and "right first time" feature metrics, saysRangaswami, who said the group does not yet have metrics to share. BT's shift to agile hasbeen a boon to developers like Buckley. "The main advantage I see is that you spend moretime working on the right [system] features by talking to customers all the time andworking on it," he says. This is instead of incorporating customer requirements intosoftware development under a waterfall approach, which includes testing the system withend-users and then discovering "this isn't really what they wanted," says Buckley. Otherbenefits are more difficult to calculate. Rangaswami asks, "How do I quantify the value oftaking 3,000 people who were once viewed as a cost to revenue-generators?"