TORONTO -- If your IT projects are consistently late and over budget, chances are you haven’t implemented Agile software development practices.
Speaking at this week’s ProjectWorld/Business Analyst World in Toronto, Scott Ambler, practice leader of Agile development at IBM Corp., told a crowd of IT professionals to throw away most of their traditional software development theories and take a new approach in their future projects.
In most development projects, Ambler said, business analysts write out a detailed requirements specification document and send it over to the software developers to carry out the design. By developing the plans upfront, he said, the people making the requirements document end up guessing the type of things the company may need down the road and more often than not, the IT projects end up in failure.
“Writing a detailed requirement spec up front is a worst practice, despite being considered a best practice for the longest time,” he said. “When you do this, you are building to specs as opposed to building to what people actually need.”
Ambler also said that because many IT projects carve their requirements in stone before any actual tests or coding has been done, their budgets are often unrealistic and inaccurate.
“Fixed prices for IT projects are unethical,” he said. “We can’t estimate up front and the only way to enforce the costs is through change management, which is also unethical. Change management is really about change prevention.”
To combat these ineffective IT projects, Ambler recommended organizations consider the Agile approach – which he defined as an incremental process that is performed in a highly collaborative manner to meet the changing needs of the stakeholders.
“The traditional way of writing a bunch of documentation and flipping it over to the next group doesn’t work,” he said. “We prefer executable documentation, which requires that we test the code first. It’s far more disciplined and [for example] every two weeks or so we have working and visual software to show to our stakeholders.”
Besides increased teamwork between multiple business groups, some of the key criteria to an agile system, according to Ambler, include continuous testing that drives development, daily work with the stakeholders, and producing working software on a regular basis. Many IT organizations, he said, too often lose sight of their true goals. “You have to know your audience,” Ambler said. “Treat your stakeholders like adults and keep them involved in the process. Any dollar spent on documentation is a dollar not spent on working software.”
Cem Kaner, author of Lessons Learned in Software Testing and Testing Computer Software, agreed, saying Agile development can reduce the cost of late changes and make it easier for IT organizations to respond as the stakeholders’ needs continually evolve.
“The most important thing the executive can do is keep asking the critical question, ‘How does this practice (paired programming, test-first programming, whatever the group is proposing this week) make us more able to be more responsive later,’” Kaner, who is professor of software engineering at the Florida Institute of Technology, added. If those implementing the process can't answer this question convincingly, Kaner said, it's a big red flag.
icon.
Thank-goodness they said it
