Agile Versus Waterfall Methodology
Abstract
Agile methodology and waterfall methodology are effective in their own ways. Both processes explain their steps and beliefs appropriately; however why should developers prefer one of the processes to the other? Are they right in their decision to champion one over the other? Although both are effective, there must be one which seems to offer more comfortable options for developers. This paper analyses the effectiveness of the agile and waterfall methods so as to help in determining if the developers are right or wrong. The developers are right in their choice to champion the agile methods over the waterfall methods.
Keywords: Agile methodology, waterfall methodology, developers.
Introduction
Agile methods and waterfall methods are main methodologies used for software development today. However, of late most developers have championed the role of agile methods over waterfall methods. Agile methodology features a development scheme of both interactive and incremental whose requirements and solutions evolve through the collaborations of self-organizing, cross functional groups. The waterfall methodology features design in which progress appears to be steadily flowing downwards, just as a waterfall, through the necessary phases such as conception, initiation, analysis, design and many others.
Agile Methods versus Waterfall Methods
Both agile methods and waterfall methods have their benefits and setbacks. They are both theories to help developers in the process of software development and thus none of them can be totally true (Guntamukkala, Wen & Tarn 2006, p. 266). A very big percentage of all the IT meetings held always debate endlessly about these two methods (‘Changing the Paradigm of Software Engineering’ 2006, p. 67). Some believe that agile is more effective than the waterfall methods while others believe that the waterfall methods are more effective. Strong feelings are mainly on the subject that agile is “for the moment” while waterfall is thought to be always passe. Such arguments are the reasons why it is essential to consider the background of both methodologies before deciding which one is more effective.
The waterfall method features a classical linear and sequential approach to both software design and system development (Guntamukkala, Wen & Tarn 2006, p. 268). Here, each stage is assigned to a set team so as to guarantee a greater project and deadline control. This is usually important for on-time deliveries. This approach moves stage by stage. First of all, the team chosen to handle the project first analyses the business requirements of the whole project before they determine and prioritize the needs. In the second step, the design phase of the prioritized business requirements is translated into IT solutions. Then decisions are made about which underlying technology should be used. There are many technologies, which IT personnel can apply in their projects such as, COBOL, Java, Visual Basic and many others (Guntamukkala, Wen & Tarn 2006, p. 269). After these processes are defined and the online layouts created, code implementation follows. In the next stage, data conversion is taken care of such that the whole stage evolves into a wholly tested solution whereby implementation and testing are evaluated by the end user. The final stage in this methodology features evaluation and maintenance. These two are very important as they ensure that every process runs smoothly as intended. This methodology features a disadvantage since if, in the last stage a problem shows, the software cannot be changed (Guntamukkala, Wen & Tarn 2006, p. 270). The only way to repair the mistake is to go back to the beginning and start all again by developing a new code.
Most developers believe that agile has a very minimal risk (Cuellar 2006, p. 34). This low overhead method emphasizes on the values principles of software development rather than on the processes used. In a cycle of weeks or months, the project priorities are usually re- evaluated after each stated cycle (Cuellar 2006, p.34. This agile method constitutes of four principles: the reigning supreme of persons and their interactions over processes and tools; supreme of the working software over the comprehensive documentation; supreme of the customer collaboration over the contract negotiation; and responding to change over the plan follow-throughs (Hamdan Mohammad, Alwada’n & Ababneh 2013, p. 456).
Judging from the backgrounds of the two methodologies, it can be concluded that waterfall method is based on predictability while agile method is based on adaptability. The agile methods are well known for being effective in reducing overheads such as rationale, justifications, documentation and also meetings (‘Changing the Paradigm of Software Engineering’ 2006, p. 70). It keeps these as minimal as possible. This methodology has benefited small teams whose requirements are constantly changing. According to a survey carried out in 2010, of all the respondents, 64.6% claimed that the agile principles were valuable and effective (‘What Agile Teams Think of Agile Principles’ 2012, p. 73).
Agile is based on empirical methods, as opposed to defining methods (Cuellar 2006, p. 36). Therefore, it is mainly based on light maneuverability as well as sufficiency for ensuring that future developments are secure. Defined methods can be acted upon by planning and then enforcing these plans (Sue, Kendall & Kendall 2012, p. 10). This is exactly what the waterfall method does. It focuses on producing a product based on the plans it created (Saran 2013, p. 4). Agile works very differently as it describes the product it wants before manipulating the plan so as to ensure that this product is produced (Hamdan Mohammad, Alwada’n & Ababneh 2013, p. 457). In Agile methodology, the whole progress is lost once there are some issues noted in one of the stages (Ionel 2009, p. 382). This is because it mainly focuses on the planning rather than on the product. Agile methodology can easily change the plan in case of a problem so as to come up with a product.
A good example of the agile methodology is the Extreme Programming. It features effective communication between customers and other team members, simple and clean designs, feedback given on the 1st day of software testing and lastly early product delivery and the implementation of suggested changes (Cuellar 2006, p.37).
The main focus of Agile methodology is to cut down the big picture into smaller bits just like puzzles and then fit them together when the time is finally right (Ionel 2009, p. 384). These bits may include the design or even coding and testing bits. Therefore, while there are many reasons to support the waterfall methodology, a closer looking into both of them gives an idea why most software developers prefer to use the agile methodology (Jacobson, Spence & Pan-Wei 2013, p. 54).
In the waterfall methodology, once a section is complete there is no turning back. This is mainly because most of software designed and implemented under this method is almost impossible to change because of time and the user needs (Ionel 2009, p. 385). Hence, this problem can only be fixed by starting over and designing an entirely new system. This is a very costly and inefficient step. Agile methodology, on the other hand, can easily adapt to change. This is made possible due to the provision at the end of each stage or cycle, the logical program which has been designed to cope and also to adapt to new ideas from the very beginning, allows for the changes to be made without affecting any other process (Jacobson, Spence & Pan-Wei 2013, p. 56). Agile methodology allows for new changes to be made without necessarily rewriting the whole project. This reduces overheads and also enhances the upgrading of programs.
At the end of each tested stage, the agile method results to a product which can be launched (Roche 2013, p. 40). This gives room for the identification of bugs and their elimination in the development stage (Keith, Demirkan & Goul 2013, p. 227). After this, product passes through tests once again to ensure there are no more bugs. The waterfall method does not allow for this counterchecking since the product is only tested at the very end of the process. This means that if a bug is noted, the whole process will have to be redone (Okoli & Carillo 2012, p. 154).
The modular nature of Agile method features employing designs and programs which are better suited for the object. This means that a developer will always have a working model in time for the release even if it still does not match the customer specifications (Jacobson, Spence & Pan-Wei 2013, p. 56). In the waterfall method there is only one release which is the main one. This means that, in case of a problem with the product or delays, the customer will be highly dissatisfied.
Agile methodology spells customer satisfaction as it allows for specification changes to be made easily as per the end users requirement requests (Keith, Demirkan & Goul 2013, p. 229). This puts it a greater advantage as any of these changes cannot be made with similar ease in the waterfall method as the whole project will need to be started.
Both methods allow for departmentalization (Okoli & Carillo 2012, p. 155). Waterfall features stages while Agile features the coding module being delegated to separate groups. This departmentalization used in Agile puts it at an advantage as it allows for different parts of the project to be handled all at the same time but with different people. The defined stages of waterfall methodology, however. Also gives it an advantage as it enables for thorough planning, especially the logical design, implementation as well as deployment.
Conclusion
Although the waterfall methodology also has its plus sides, there is more evidence that the Agile method is the best to be used by software developers since it is time conscious, allows for changes to be made, reduces overhead, enhances effective communication, gives each stage enough thought and hence resulting to a very specific product. The developers are right in their choice of offering support to the agile method since it saves them time. Time is essential as it gives room for the production of other products which improve the performance of a specific company. It also reduces costs because they can easily make changes without having to restart the whole production process all again. A wasted production process, as is the case with waterfall methodology results to a lot of wastage in raw materials. Agile methodology does not result to too much wastage as the product can easily be fixed without having to start over again with new raw material.
List of References
‘Changing The Paradigm Of Software Engineering’ 2006, Communications Of The ACM, 49, 8, pp. 67-70, Business Source Complete, EBSCOhost, viewed 22 December 2013.
Cuellar, R 2006, ‘Agile Software Development and Test Driven Development’, Journal Of The Quality Assurance Institute, 20, 3, pp. 33-38, Business Source Complete, EBSCOhost, viewed 22 December 2013.
Guntamukkala, V, Wen, H, & Tarn, J 2006, ‘An empirical study of selecting software development life cycle models’, Human Systems Management, 25, 4, pp. 265-278, Business Source Complete, EBSCOhost, viewed 22 December 2013.
Hamdan Mohammad, A, Alwada’n, T, & Ababneh, J 2013, ‘Agile Software Methodologies: Strength and Weakness’, International Journal Of Engineering Science & Technology, 5, 3, pp. 455-459, Academic Search Premier, EBSCOhost, viewed 22 December 2013.
Ionel, N 2009, ‘Agile Software Development Methodologies: An Overview Of The Current State Of Research’, Annals Of The University Of Oradea, Economic Science Series, 18, 4, pp. 381-385, Business Source Complete, EBSCOhost, viewed 22 December 2013.
Jacobson, I, Spence, I, & Pan-Wei, N 2013, ‘Agile and SEMAT- Perfect Partners’, Communications Of The ACM, 56, 11, pp. 53-59, Business Source Complete, EBSCOhost, viewed 22 December 2013.
Keith, M, Demirkan, H, & Goul, M 2013, ‘Service-Oriented Methodology for Systems Development’, Journal Of Management Information Systems, 30, 1, pp. 227-260, Business Source Complete, EBSCOhost, viewed 22 December 2013.
Okoli, C, & Carillo, K 2012, ‘The best of adaptive and predictive methodologies: open source software development, a balance between agility and discipline’, International Journal Of Information Technology & Management, 11, 1, pp. 153-166, Business Source Complete, EBSCOhost, viewed 22 December 2013.
Roche, J 2013, ‘Adopting DevOps Practices in Quality Assurance’, Communications Of The ACM, 56, 11, pp. 38-43, Business Source Complete, EBSCOhost, viewed 22 December 2013.
Saran, C 2013, ‘How to get the best from agile and waterfall development approaches’, Computer Weekly, pp. 4-5, Business Source Complete, EBSCOhost, viewed 22 December 2013.
Sue, K, Kendall, J, & Kendall, K 2012, ‘Project Contexts And Use Of Agile Software Development Methodology In Practice: A Case Study’, Journal Of The Academy Of Business & Economics, 12, 2, pp. 1-15, Business Source Complete, EBSCOhost, viewed 22 December 2013.
‘What Agile Teams Think of Agile Principles’ 2012, Communications Of The ACM, 55, 4, pp. 71-76, Business Source Complete, EBSCOhost, viewed 22 December 2013.
