IT departments are failing to reap the benefits of agile programming because they are not using it in the way it was intended, it was claimed today.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Project management training consultant ESI said it had become trendy for IT departments to adopt the trappings of agile programming, but many lacked the discipline to benefit from the technique.
Agile programming is designed to help programming teams develop software quickly. Agile programming uses techniques such as stand-up meetings or scrums and programming sprints to develop software through a series of iterations.
But Denise Vestin, a project management consultant with ESI, said scrums and sprints alone will not guarantee success.
"If you decide to go ahead with a scrum, you still have to adhere to the rules to see if they work", she said. "Its really not about agile programming, but running your project in an agile way," Denise Vestin said.
Denise Vestin said organisations go wrong by failing to appoint a "product owner" with the authority to steer the project, invest more money or pull the financial plug.
The product owner needs to work alongside the programmes and review each iteration of the code, said Vestin
"The whole idea of the product owner is that they should see the results of the scrum. It only takes 2 or 3 hours every week. If you don't keep to that discipline, you start impacting delivery," she said.
Agile programming, carried out properly, helps organisations eliminate unnecessary features from software, said Vestin. Research shows that 2/3 of features in most software packages are redundant.
"That's why it's important to demonstrate the software to the product owner every sprint. They need to ask: 'Do we need it? Do we want it? Should we throw it out? Should we continue with the project?'"
Agile allows organisations to define the essential functions of a project more effectively than traditional techniques, such as the widely used waterfall methodology.
"With waterfall, the users give you every possible requirement. Then you ask them what's important, and they say it's all important," she said. "Its like a bad prophesy that comes true."
Structured programming techniques like waterfall do not work, because they treat programming like an engineering project with a predictable outcome, said Vetrin.
"In the past we tried to copy what engineers where doing, with the predictability they have when they build a bridge. The problem is that software is not predictable and creativity is not predictable," said Vestin.
Agile programming works best for innovative projects, where the final specifications of the work are unlikely to be clear at the start of the project, she said.
External resources on agile programming: