Head Office:
24 Sturdee Avenue,
Contact details:
+27 (0) 11 301 0900
Office Hours:
Monday to Friday
07:30 to 16:30
  • EnterpriseWorx IT

Finding the best approach to software development

Two opposing ways of building software products have engaged developers over the past few years. The agile method rocketed to prominence in the 1990s as a reaction to the rigorous processes of the waterfall method, and Gartner predicts that by the end of 2012, agile will be used in 80% of software development projects.

“Agile came about as an attempt to address the lengthy time cycles and wastefulness of waterfall,” says Neal Donnan, application development executive of information solutions specialist EnterpriseWorx. “However, it is not suitable for all circumstances, and many companies are adopting a hybrid approach. A lot depends on the fit with the organisation and the industry.”

According to the Ambysoft 2011 IT Project Success Rates Survey, traditional waterfall development paradigms have a 50% chance of success, compared to nearly 65% for agile development.

Structured processes such as waterfall follow a rigid development schedule and emphasise completion of one task before proceeding to the next. Waterfall demands first doing analysis and design, then development and implementation, followed by testing – towards the end of the process. “Sometimes, when you get to the testing stage say six months down the line, you find that the result is not what you want,” says Donnan.

Agile seeks to improve output with each iteration. Benefits include being able to demo the software every two weeks at the end of a release cycle or ‘sprint’ so users can see results immediately and make changes quickly. “However, even using agile methods such as Scrum, you do need to plan properly upfront,” says Donnan.

“Many companies say they have adopted an agile model without understanding the full ramifications. Agile is flexible and can boost productivity, but it requires a disciplined approach.”

Agile is suited to projects such as the development of a totally new software application where much of the work is exploratory. It is also likely to perform well when a new application is to be developed with the goal of deployment in the cloud by a team that has not used cloud platforms in the past.

It works best with a team of experienced developers and engineers. The project team tends to have a loose structure but must work in collaboration with management and users. “Do not start the project without the support of business representatives,” says Donnan. “If they are not an active part of the process, many of the benefits of adopting an agile approach will not be realised.”

While those who favour an agile approach have attacked waterfall, Donnan believes it is a better fit when working on large corporate projects where several different teams and vendors that do not use an agile process are involved since specifications and contracts can be more tightly managed. When buying a vendor product, such as a SAP human resources system off the shelf, and integrating it with other processes according to a well-defined road map, waterfall may also be a better choice.

“For agile to succeed, you need buy-in from the various business partners as well as the larger IT department including deployment managers, project managers, architects and developers. With this iterative approach, users can see early on how the software works and if it meets their needs. Misunderstandings are brought to light early on and problems can be fixed for the next release. Testing is built into the core methodology; it’s a process of test-driven development.”

“With waterfall, testing is one block right at the end. Particularly in the case of software integration, if you discover problems late in the process, you may have to go back to the drawing board after a lot of money has already been spent.”

However, it’s often not as simple as dropping waterfall and moving to agile. “Neither approach is a silver bullet,” says Donnan. “What may be needed is a compromise between the two. In cases where high-level project deadlines and requirements have been set and there is no business representation dedicated exclusively to the project, a traditional functional analyst can take the role of client. Agile principles such as short, controlled iterations, continuous integration, face-to-face communication, code refactoring and test driven development can also be adopted.

“Agile may be the pathfinder at present, but the important thing is to use the right management tool for the particular application.”