Waterfall or Agile? Measuring Up Methodologies

 

Right from the start, choosing a development methodology is crucial to creating software. So important that it has stirred quite a bit of discussion and debate over the years among developers.

Simply put, a development methodology is the manner or style by which a company creates its applications. That is, it dictates how the software development cycle is supposed to go. The two currently most popular mature methodologies are Waterfall and Agile.

Chasing Waterfalls

Also known as the traditional method, the Waterfall methodology is by far the more linearly sequential process. The steps are as follows: 1. Establish and document the software requirements; 2. Design the application; 3. Write the code; 4. Perform unit and system testing; 5. User acceptance testing; 6. Debug and continue testing; and finally, 7. Release the finished application to market.

Because it is entirely sequential, one phase needs to be completed before development can move on to the next one. In between stages, approval from an authority or the customer is typically needed before one may proceed.

The Waterfall approach has several good points going for it.

• Early on, developers and client come to an agreement on the final deliverables.
• Due to the linear process, once can monitor progress and easily identify what stage they are currently at. Testers, for example, may already start building theoretical test cases during the documentation process or while coding is being done.
• Reviews and approvals aside, it is not necessary for the client to be around to monitor the process.
• This methodology is applicable to software projects that have many different parts and are designed to integrate with other systems.
• Given the clear understanding of the software deliverables, it may provide a thorough and careful approach to the project. This way, it is less likely that developers will create code that won’t fit into the software as a whole.

All that said, the Waterfall methodology also has its drawbacks:

• For the entire project to work, developers must be able to effectively gather and document the needed requirements at the start. Sometimes, customers may not have the specific details on hand, or they may not be able to effectively describe or visualize it on a document for developers to understand. Without a clear picture, the software development cycle is hamstrung even before it can begin.
• Another possible problem is that the client may wind up unhappy with the end product. Since the client isn’t usually present throughout the cycle, they may not see the product until it is almost done. Any alterations to it may come at a great expense.

In Comes Agile

Agile is a different sort of animal. This time, the approach is team-oriented and iterative, with a focus on quick delivery and turnaround of the product. Instead of the usual assigned task, the project is divided into parts called sprints. Each sprint has its own set of deliverables defined at the beginning, with each deliverable selected and prioritized based on the customer’s approval. Anything not completed by the sprint’s end is reprioritized for another sprint.

Throughout it all, the client remains an active participant. As the sprints go on, the client reviews completed items, builds, and demos with the project manager.

Agile naturally provides the following pros:

• The customer’s involvement allows them to provide input on the software development and thus maintain a high level of ownership and satisfaction for the end product.
• Agile focuses on quick turnaround times, so if needed it is possible to come up with an unfinished working version of the product for demo purposes, with the full version at a later date.
• Due to the employment of user experience to create an acceptance criteria, Agile tends to focus on actual user needs. Each sprint may end with a beta test for gaining feedback to be used for the next sprint.
• Since the project is divided into phases, this makes the process more manageable. The team can then collaborate on coding, testing, and documentation. Since testing and reviews are done with every sprint, one can find and fix bugs rapidly.

Of course, Agile has its own built-in disadvantages to beware of:

• The client may not have the time or inclination for the kind of involvement this methodology entails.
• The time and effort required by Agile methodology need team members who are completely devoted to the project.
• Because of the often shifting nature of sprint priorities, certain components may not be completed at the time scheduled and will be put off till future sprints. This may mean new sprints to cover them, adding to the cost of development.
• Due to the sheer number of iterations involved in Agile, it may require that the scope of the project be changed. This happens more often with large-scale projects or ones that involve integrations with external systems.

How to Choose

What methodology works best? Here are copebit, we prefer to make our own approach: one that relies on key factors to determine what approach to take.

• Project Scope – We lean towards an Agile methodology when the scope is not known or well-defined, though we are aware that it may come at additional time and expense. When the scope is well-defined, we go with the contract defined with the customer.
• Prioritization – We prioritize which features to develop first according to the business value assigned by the client. This way, it is more likely to create a usable product, even with limited funds. This, of course, depends on the agreement with the customer, as they may prefer everything to be accomplished.
• Customer Participation – time and availability permitting, customers are invited to take part in the development process to reduce the risk of going off track with the project. In the early stages of the process, we try to create working prototypes of the final product in order to give the client a visual idea of where the project is headed, and thereby help us keep it on track.
• Funding – Where prices are fixed according to agreed upon contract, it will be harder to implement an Agile approach.
• Team – Collaboration is always welcome. Agile requires a small, dedicated team to work with a high degree of collaboration, but we are aware this may not be feasible when outside vendors are involved to handle different components of the project.

Overall, our framework leans toward the Agile approach, but we take our cue from the client’s input and requirements and employ the strengths of each methodology to each specific project. This hybrid approach has seen rapid adoption in many software development companies, prompted by the great value it provides their clients.

In the end, no matter what approach we choose, copebit’s ultimate goal is to create a product that makes our client happy.