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.
For Ambler, the agile process simply treats IT project requirements like a prioritized stack.
“We go to the top of the stack in two-week iterations and start working on it from there,” he said. “You begin with the good stuff and eventually work your way to the stuff you rarely need. We have a higher success rate because at the end of the iteration, we have potentially shippable software.”
The smarter executives, Ambler said, will often want to wrap up the project once they see all the useful features fully integrated. This means IT projects are finished sooner and you can gain increased confidence and funding from the stakeholders for future tasks.
“Because you are creating workable software, they can continue to fund the project until they see something they want to use,” he said. “That means they’re managing their IT investment like an investment and not like a gamble.”
But as with any process change, the effects won’t be seen immediately. James Kricfalusi, service delivery executive at TEKSystems, said it can take time for the process to take hold.
“Sponsors and executives equate agile with immediate results,” he said. “This is not realistic. Trust the team, relax and let them do their thing. Lower your expectations in the beginning because most of the initial advances cannot be in the functionality of the first release.”
According to Kricfalusi, in the early work on an Agile project, initial iterations are an investment in frameworks, new ideas, process definitions and understanding of the requirements. The initial release may miss the mark, but the team will have developed a cheap and effective means of providing effective feedback to improve later versions.
Judge the results relative to the time frame of the existing processes, Kricfalusi advised.
“If your prior project time frames were 6 months to a year, it will take about that long before you can have the proper perspective to evaluate your progress.”
ProjectWorld 2008 wrapped up Thursday.
–With files from IDG News Service
