So far, only a small percentage of corporations have adopted an "agile" approach, which aims to help companies attack projects that have unclear or rapidly changing requirements, Giga analyst Liz Barnett said.
She estimated that just 10% of corporate IT organisations now use the emerging lightweight methodologies that are currently creating a stir in programming circles. However, Barnett said she suspects roughly 25% are exploring some form of agile process.
She recommended that companies consider supplementing old processes with some of the newer agile approaches. "I think they will have six or 10 different processes in a shop, and this will be one of them," she said.
At the Giga conference, delegates showed mixed interest in using elements of the various agile methodologies, which include extreme programming (XP), Scrum and Crystal.
Agile approaches typically eliminate the extensive documentation process that can bog down developers, calling for projects to be broken down into pieces based on requirements and for functional code to be delivered in shorter time frames, which can range from 14 to 90 days depending on the methodology used.
Agile methodologies also generally call for more frequent testing and greater communication and feedback between developers and the users for whom they are writing the software.
Erkki Vuorenmaa, manager of local infrastructure in Helsinki, for Scandinavian banking chain Nordea, said he has concerns about being able to get business people involved in the application development process. "It's really irritating," he said. "You have to drag them."
Walt Smith, chief IT architect at a large US-based financial institution who asked that the company not be identified, said the need to produce higher quality software more quickly will drive his company to consider agile methodologies. "Customers want applications in 90 days now, no matter how complex they are, and you can't do that with traditional methods," he said.
But Smith said he has yet to be convinced that agile processes will help his firm address its other problem - reducing development costs. He said working on an individual project may cut costs for that specific project, but the approach could wind up costing his company more when his team has to integrate the application with existing enterprise systems.
He said his firm's early experiments with elements of XP on departmental applications produced code that didn't integrate well with the overall infrastructure or scale in production. "We spent a lot of money fixing those scalability problems," he said.
Jerzy Dutkiewicz, manager of architecture and integration at Sunoco in Philadelphia, has similar concerns about whether the agile approach can produce long-lasting, stable data architecture. He said some agile techniques might work for small projects that do not have high-scalability requirements.
Dutkiewicz noted that agile methodologies appear to be a rehash of rapid development approaches his firm already takes. But he said he can foresee the possibility of incorporating some agile project management elements, such as instituting short-term contracts with users "to minimise the demoralising effect of the blame" when a project runs late or a user claims a requirement may not be fully understood.
Short daily meetings would lead to a better feedback loop, he said, and would be helpful for companies hiring outside consultants. "If the consultant is incompetent or the technology is wrong, I [get] the first indication after 30 days," Dutkiewicz said. "I'm cutting my losses quickly."
But Peter Baker, director of applications at Emcor Group, a US construction company that outsources most of its IT work, said he will not be seeking out consultants that use agile methodologies. "It's just rebranding of classical project management," he said.