When the process is mature and requirements are stable, waterfall is more suitable, said Abid. But when you are innovating and developing new business processes, iterative development technology makes more sense.
Jon Hughes, VP, Technology Solutions Group for Robbins-Gioia said in his business the customers often have the method selected before engaging his firm. But there are times that he needs to step in and make a recommendation when they have chosen the wrong method.
We usually comply with what they ask for unless we realize that there is a cultural inhibitor to doing a spiral or agile development that will make it unsuccessful, he said. If someone wants to do a spiral development methodology, but is not willing to commit resources (and) time to periodic reviews, there is a fundamental problem. They should be doing waterfalls.
Luxoft's Bykov likes to talk about a large development project his company completed that involved a complex set of business rules, large amounts of data and a high volume of transactions. "The underlying cause was pretty typical: unstable requirements and long releases. The client worked very closely with us on all details, but numerous changes introduced made project planning nearly impossible.
Luxoft shipped the builds according to the plan, but each took a long time to test and produced a huge number of corrections and enhancements. As the initial deadline approached, it became clear that implementing all the change requests could not be accomplished in the allotted time. This extended the initial time estimate of nine months to 15.
After some hard replanning, we decided to change the project implementation approach to agile, introduce daily builds, and weekly reviews of the results with the customer, said Bykov. It's hard to make such a change in the middle of a project, but it looked like it was the only way to ever get the software into production.
The change produced the desired result. The number of bugs declined and the much shorter iterations inherent in the agile methodology made it easier to introduce enhancements and changes. The initial production version finally was released and Luxoft created follow-up versions of the system later.
The lesson we learned is that mistakes in the choice of development methodology can be very expensive later in the project, said Bykov. It often makes sense to persuade a customer to change their standard approach to something more fitting to the nature of the project.