One of the first decisions we faced for our project implementations at East Agile was “Which development methodology should we use?” There are a lot of discussion regarding Agile versus Waterfall and if this is not something you have worked with before, a definition of development methodology is in order; put very simply, it’s a way of organizing the work of software development. This is NOT about a style of project management or a specific technical approach, although you will often hear these terms all thrown together or used interchangeably.

The two basic, most popular methodologies are:

• Waterfall: The more “traditional” approach towards software development, and
• Agile: A specific type of Rapid Application Development and a relatively newer methodology in comparison to Waterfall, which often implemented using scrum.

Both of these are viable, mature methodologies and since we have been involved in software development projects for a long time, here are our thoughts on the strengths and weaknesses of each.

THE WATERFALL METHODOLOGY

Waterfall is a linear approach to software development and in this methodology, the sequence of events is something like this:

• Gather and document requirements: Developers and customers agree on what will be delivered early in the development lifecycle. This makes planning and designing straightforward. Progress is more easily measured as the scope of work has already been documented and there is a possibility for various members of the team to be involved or to continue with other assignments, throughout the development effort. This is dependant on the active phase of the project. A good example would be, business analysts can learn about and document what needs to be done, while developers are working on other projects. Testers can prepare test scripts from the product documentation while coding is underway.

• Design: Design work is completed in the early stages of the development lifecycle which lends itself to projects where multiple software components must be designed (sometimes in parallel) for integration with external systems.
• Code and unit testing: software can be designed completely and more carefully, based upon a more complete understanding of all software deliverables. This provides a better software design with less likelihood of the “piecemeal effect” , a development phenomenon that can occur as pieces of code are defined and subsequently added to an application where they may not fit well.
• Perform system testing: In the traditional waterfall model the role of the test organization is not made explicit until the system testing and acceptance testing phases. Most of the activity of the earlier phases, such as design, coding, and unit testing, are associated primarily with the software development team. For this reason it is useful to derive a corresponding life cycle model.
• Perform user acceptance testing (UAT): When system testing is completed, the product can be sent to users for acceptance testing. If the users are internal to the company, the testing is usually called alpha testing. If the users are customers who are willing to work with the product before it is finished, the testing is beta testing. Both alpha and beta tests are a form of pilot tests in which the system is installed on an experimental basis for the purpose of finding bugs. Another form of acceptance test is a benchmark test in which the customer runs a predefined set of test cases that represent typical conditions under which the system is expected to perform when placed into service. The benchmark test may consist of test cases that are written and debugged by your test organization, but which the customer has reviewed and approved. When pilot and benchmark testing is complete, the customer should tell you which requirements are not satisfied or need to be changed in order to proceed to final testing. The final type of acceptance test is the installation test, which involves installing a completed version of the product at user sites for the purpose of obtaining customer agreement that the product meets all requirements and is ready for delivery.
• Fix any issues: Maintenance of a product is an often challenging task for the development team and the test team. Maintenance for the developer consists of fixing bugs that are found during customer operation and adding enhancements to product functionality to meet evolving customer requirements. For the test organization, maintenance means verifying bug fixes, testing enhanced functionality, and running regression tests on new releases of the product to ensure that previously working functionality has not been broken by the new changes.
• Deliver the finished product: Except for reviews, approvals or status meetings there will be little to no interaction with the client. Especially after the “requirements phase”.

In a true Waterfall development project, each of these represents a distinct stage of software development and each stage generally finishes before the next one can begin. There is also typically a stage gate between each; for example. Requirements must be reviewed and approved by the customer before design can begin. There are definitely benefits when using the Waterfall methodology, however there are definitely some disadvantages that you will encounter: 

• Keep in mind that some clients are not always able to visualise an application in the early stages. Gathering data and documenting requirements are in a way both meaningful to a client and often the most difficult part of software development. Customers can be intimidated by the specifics of the requirements that need to be provided early in the project. This area almost always falls short in its effectiveness. Wireframes and mockups can help, but there’s no question that most end users have some difficulty putting these elements together with written requirements to arrive at a good picture of that they will be getting.
• Another potential drawback of pure Waterfall development is the possibility that the customer will be dissatisfied with their delivered software product. As all deliverables are based upon documented requirements, a customer may not see what will be delivered until it’s almost finished. By that time, changes can be difficult and costly to implement.

THE AGILE METHODOLOGY

Agile is an iterative, team-based approach to development. This approach emphasizes the rapid delivery of an application in complete functional components. Rather than creating tasks and schedules, all time is “time-boxed” into phases called “sprints.” Each sprint has a defined duration (usually in weeks) with a running list of deliverables, planned at the start of the sprint. Deliverables are prioritized by business value as determined by the customer. If all planned work for the sprint cannot be completed, work is reprioritized and the information is used for future sprint planning. As work is completed, it can be reviewed and evaluated by the project team and customer, through daily builds and end-of-sprint demos. Agile relies on a very high level of customer involvement throughout the project, but especially during these reviews.

We have listed out some advantages of the agile approach:

• The client has frequent and early stage opportunities to see the work being delivered allowing him to make decisions and changes throughout the development project.
• The client gains a strong sense of ownership by working extensively and directly with the project team throughout the development process.
• If time to market for a specific application is a greater concern than releasing a full feature set at the initial launch, Agile can quickly produce a basic version of working software which can be built upon in successive iterations
• Development is often more user-focused, likely a result of more and frequent direction from the customer.

Keep in mind that Agile development has some aspects which are disadvantageous:

• The very high degree of customer involvement, while great for the project, may present problems for some customers who simply may not have the time or interest for this type of participation.
• Agile works best when members of the development team are completely dedicated to the project.
• Because Agile focuses on time-boxed delivery and frequent reprioritization, it’s possible that some items set for delivery will not be completed within the allotted time frame. Additional sprints (beyond those initially planned) may be needed, adding to the project cost. In addition, customer involvement often leads to additional features requested throughout the project. Again, this can add to the overall time and cost of the implementation.
• The close working relationships in an Agile project are easiest to manage when the team members are located in the same physical space, which is not always possible. However, there are a variety of ways to handle this issue. (Related article: Working With An Offshore Software Development Team)
• The iterative nature of Agile development may lead to a frequent refactoring if the full scope of the system is not considered in the initial architecture and design. Without this refactoring, the system can suffer from a reduction in overall quality. This becomes more pronounced in larger-scale implementations, or with systems that include a high level of integration.

SUMMARY

In order to decide which methodology to adopt, Agile and Waterfall, you should start by defining your own process. This is also known as the Process Framework, which is a variation on the traditional Waterfall methodology. Look at your internal environment, schedule, timeline, budget and involvement. This helps to give you a better view of how you want to shape your product, improves the team’s understanding of requirements and communication. 

Are you searching for a solution on which methodology fits with your company? Do not hesitate to Contact us for more information. We will get back to you!