Agile v Waterfall. Which is the best?

Today, we are arming you with information about both waterfall and agile methodologies so that you can make an informed decision as to what you think is best to use and in what situation and why.

The Waterfall Methodology

Waterfall is a linear sequential method to software development, in which progress flows in one direction downwards (like a waterfall) through the phases. The waterfall development model originated in the manufacturing and construction industries: highly structured physical environments in which after-the-fact changes are impossible or at least prohibitively expensive.

At the time it was adopted for software development, there were no recognised alternatives for knowledge-based creative working. The Waterfall methodology, tends to sequence of stages is something like:

• Gather and document requirements
• Design solution
• Code and unit test
• Perform system testing
• Perform user acceptance testing (UAT)
• Fix any issues
• Deliver the finished product / Operations

In a true Waterfall development project, each of the above represents a distinct stage of software development, and each stage generally has to finish before the next one can begin.

There is also typically a stage gate between each stage; for example, requirements must be reviewed and approved by the customer before the design stage can begin.

There are many good things about the Waterfall approach. On the positive side:

· Developers and customers agree on what will be delivered early in the development lifecycle. This can make planning and designing more straightforward

· Progress can be measured easily, as the full scope of the work is known in advance

· Throughout the development effort, it’s possible for team members to be involved or to continue with other work, depending on the active phase of the project. For example, business analysts can learn about and document what needs to be done, while the developers are working on other projects. Testers can prepare test scripts from requirements documentation while coding is underway

· Except for reviews, approvals, status meetings, etc., a strong customer presence is not strictly required after the requirements phase

· Because design is completed early in the development lifecycle, this approach lends itself to projects where multiple software components must be designed (sometimes in parallel) for integration with external systems

· Finally, the software can be designed completely, based upon a more complete understanding of all software deliverable s. 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 or may not fit well

However here are issues commonly encountered using a pure Waterfall approach:

• Waterfall methodology relies heavily on initial requirements. However, if these requirements are faulty in any manner, the project is doomed.
• One area which almost always falls short is the effectiveness of the initial requirements. Gathering and documenting requirements in a way that is meaningful to a customer is often the most challenging part of software development.
• The Waterfall method makes the assumption that all requirements can be gathered up front during the Requirements phase. Communication with the user is front-loaded into this phase, as the Project Manager does his or her best to get a detailed understanding of the user’s requirements
• Customers can be intimidated by details, and specific details, required early in the project In addition, customers are not always able to visualize an application from a requirements document. Wireframes and mock-ups 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 what they what and 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, collaborative 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 deliverable s, planned at the start of the sprint. Deliverable s are prioritized by business value as determined by the customer. If all planned work for the sprint cannot be completed, work is re prioritized 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.

Some advantages of the agile approach are:

· The customer has frequent and early opportunities to see the work being delivered, and to make decisions and changes throughout the development project.

· The customer gains a strong sense of ownership by working extensively and directly with the project team throughout the project.

· If time to market for a specific application is a greater concern than releasing a full feature set at initial launch, Agile can more quickly produce a basic version of working software which can be built upon in successive iterations.

· Can work well where full customer requirements are not know in advance

· The testing at the end of each sprint ensures that the bugs are caught and taken care of in the development cycle. They won’t be found at the end

· Development is often more user-focused, likely a result of more and frequent direction from the customer.

· For more Agile Development benefits, please see 8 Benefits of Agile Software Development

The disadvantages:

· 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 participation

· Agile works best when members of the development team, including the customer representatives, are completely dedicated to the project

· Because Agile focuses on time-boxed delivery and frequent re-prioritizationit’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.

This can lead to addition 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, today there are a variety of ways to handle this issue, such as tele-conference, webcams, software collaboration tools, etc.

· 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

Making the Choice Between Agile and Waterfall

You should consider the following factors when considering which methodology to use against the challenges you have

· Align project traits with development methodologies. Construction / Manufacturing suits Waterfall, Software / web site development, Agile

· One should note that the above factors are not equally weighted; each is assessed depending on the individual project and circumstances

You Should Use Agile If…

You’re building a new product in an uncertain world and you have a real need for speed. If you don’t have a lot of information up front, enforcing strict requirements and planning at the beginning of your project can lead to costly mistakes further down the line.

Agile was designed to reduce the cost of change and uncertainty, which is why it’s no surprise that many start-ups swear by the methodology.

Agile excels when you don’t have a clear picture of the end goal and requirements are constantly changing.

You Should Use Waterfall If…

Your customer knows exactly what they want, and you’re very confident that there won’t be any major changes in scope throughout the project.

Waterfall works great for building software for clients who have clearly defined requirements that aren’t likely to change throughout the life cycle of your project, think government contracts or legacy systems. When projects are simple and predictable, you can benefit from Waterfall’s inherent stability and linear development path.

Conclusion:

The choice between Agile and Waterfall can best be summed up in two words: flexibility vs. stability.

Once you have decided which basic methodology to utilize, you can further refine the process to best fit your project goals.

Ultimately, although the way in which you undertake your work is important, delivering a solid and maintainable product that satisfies your Customer is what really counts!

Need project templates: https://pmp-practitioners.com/documents/