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.

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 to daily interactions with BT's software developers, even some external customers "have become complete believers in this, in that it gives them far better control" in project development efforts, says Ramji.

BT's development organization invested less than US$5 million to launch the agile initiative, including classroom and workshop training for its developers. The company also had to change its own outlook as to how projects would be managed and executed. A quick, iterative agile development approach lends itself to software projects involving co-located development teams situated in, say, London and India, says Rangaswami.

Ramji, Rangaswami and other BT IT leaders also had to convince IT managers and staffers that agile didn't necessarily mean they were deemphasizing software quality assurance and testing. "Historically, we used to do 16 or 17 different types of tests" before a system was put in production, says Rangaswami. "Now we've determined that only one test matters -- from customer concept to completion."

So instead of measuring the differences in software defects that might have been introduced using a waterfall development approach versus agile, BT has begun tracking improvements in development cycle times and "right first time" feature metrics, says Rangaswami, who said the group does not yet have metrics to share.

BT's shift to agile has been a boon to developers like Buckley. "The main advantage I see is that you spend more time working on the right [system] features by talking to customers all the time and working on it," he says. This is instead of incorporating customer requirements into software development under a waterfall approach, which includes testing the system with end users and then discovering "this isn't really what they wanted," says Buckley.

Other benefits are more difficult to calculate. Rangaswami asks, "How do I quantify the value of taking 3,000 people who were once viewed as a cost to revenue-generators?"