A common question for product managers, project managers, technical program managers, and software developers alike is what methodology to use given a project. There is plenty to choose from, whether it be Agile, Waterfall, Scrum, or Kanban. By and large, however, the two most popular for today's organizations are the Waterfall and Agile methodologies. So what are the differences? Which should you and your teams decide the utilize? These questions and more will be answered in this article. Let's get started with Agile vs. Waterfall.

What are Project Methodologies and Why are They Important?

First and foremost, let's just recap what these project methodologies are and why they're necessary for today's businesses. A project management (or software development) methodology is simply a particular set of principles, procedures, processes, rules, or techniques that teams use during their day-to-day in executing a project. It really just comes down to the method in which work is done. Whichever methodology a team operates under will heavily influence how they work and communicate with one another.

Methodologies are obviously necessary because companies have many projects that need to be completed. Given the fact that many of these projects are highly complex, multifaceted, and require many steps, a defined way of completing work is vital. Think about the complexity involved in developing and releasing a piece of software. Quite frankly, nothing could be done or done well without a methodology. But there are plenty to choose from, and each function a little differently with different results. Without and further delay, let's look at two of the most common: Waterfall and Agile.

What is Waterfall?

The waterfall methodology is one of the oldest models of breaking down projects. It derives its name from its linear nature. Each stage of the project is completed in one linear sequence flowing in the same direction: downwards like a waterfall. Every stage of the project requires the deliverables of the one before it. Each phase is specialized in terms of the project activities required. In other words, the development phases such as conception, initiation, analysis, design, construction, testing, implementation, and maintenance are all done one at a time in a downwards sequence.

As you can see from the above image, the waterfall method is usually delineated into the following phases, each of which is to be totally completed before moving onto the next:

Requirement Development

In those projects developed under the Waterfall methodology, all the requirements must be agreed to and understood at the beginning of the development cycle. All of which need to be gathered from the client, with input from all relevant stakeholders. It is these initial steps that will become the foundation for all future development.

Design

After the requirements are established, the developers are responsible for designing technical solutions to the product requirements. This means things like the programming languages and the kind of databases need to be decided on. A higher-level design needs to be created by the developers that describe the purpose of the project. Then, the developers must establish a physical design with specific hardware/software technologies.

Implementation

After a design is completed, the teams can begin to implement them. This is where the actual software is built in the Waterfall methodology. The implementation phase may be shorter or simpler compared to the previous stages, as the development design has already been established. Problems may arise during this phase if significant changes become necessary, as the structure of the Waterfall methodology would force the developers back into the design phases.

Verification

Once the software or application has been developed, and the product requirements are implemented, the testing or verification phase begins. A product cannot be released to customers or clients if bugs aren't fixed or requirements are missing. Waterfall teams would use the documentation from the previous phases, such as customer personas or design documents, to help them verify the project.

Deployment

As the name suggests, this is the stage where the product/application is deployed. It is at this point the application becomes live, and the client can receive the product.

Maintenance

The final stage of the Waterfall methodology involves the on-going maintenance of the deployed application. Once the product is in the hands of customers or the market, problems may arise, or specific changes may become necessary. The maintenance phase of Waterfall is where updates and new version releases will take place.

Pros and Cons of Waterfall

Pros

While many today feel as though the Waterfall method is on its way out, it still has many benefits for the right projects:

• Waterfall projects tend to be simpler and more straight-forward.
• Planning is less challenging with Waterfall, as each phase in the development cycle has firm starting and finishing dates.
• Resource planning and allocation are also more straight-forward for the same reason: start and end dates are concrete and clear.
• Development costs and project budgets can be established beforehand.
• Comprehensive procedures and processes can be developed to help regulate the development cycle.
• Because development phases are strictly delineated in Waterfall, team members only need to participate in their particular development phase.

Nevertheless, the Waterfall Methodology does have its limits and drawbacks:

The Cons

• Strictly established requirements don't have much wiggle room for creativity or mid-development changes.
• A waterfall methodology can become expensive if changes need to be implemented after the design phases.
• Requirements may not always be fully understood by all stakeholders, leading to development problems down the line.
• Large amounts of time are spent writing documentation, whereas there is less time building the product.

Tips for Using Waterfall

Ultimately, the waterfall methodology works best for those projects where there is some stability in the development cycle. This means that the requirements and the developers can't be changed frequently throughout the project execution.

Fully Flesh out Your Project Requirements

Because Waterfall is structured in a rigid, step-by-step manner, it can be quite detrimental to the project if the product requirements are not fully fleshed out. If they are too vague, it may become necessary to implement changes in the middle of the development cycle. If this happens during a Waterfall project, the team will need to go back into the initial design phases.

Avoid Changes to Requirements

While changes can be avoided by fully fleshing out a complete set of requirements from the client, it is not the only way. When you're in the initial phases of establishing product requirements, be sure to allow all the relevant stakeholders the chance to offer their input. They may foresee a potential problem or change down the line.

Do Your Due Diligence

For a Waterfall project to be successful, teams will need to do all their due diligence beforehand. Ultimately, the entire implementation of the development cycle rides on the planning done in the initial stages. Be sure your requirements, product design, and project budget are square before moving on to the later phases.

What is Agile?

As developers continued to use the Waterfall methodology, some problems arose given the inflexibility of its structure. If changes or issues arise while implementing the project design, developers would need to restart the entire development cycle. As a result, developers started using the Agile Methodology to support fixing errors, bugs, requirement changes, user feedback, or new ideas as the product is being built. The four guiding principles of Agile, as stated by the Agile Manifesto, are:

1. Individuals and interactions take precedence over processes and tools
2. Emphasize working, bug-free software over comprehensive documentation
3. Collaborate with customers regarding contract negotiation
4. Be responsive to change rather than follow a strict plan

In the Agile development methodology, project requirements and solutions occur over time, rather than at the beginning like in Waterfall. Agile gives developers the flexibility to self-organize while 'discovering' the product and the solution over several iterations.

In practice, this may look something like this:

1. Develop the initial product requirements
2. Design Phase
3. Development Phase
4. Testing Phase
5. Deployment Phase
6. Evaluating results
7. Collect user or customer feedback on current progress
8. Develop a new set of requirements for the next cycle using the user feedback & previously measured results.

Pros and Cons

So what are the drawbacks and benefits of using the Agile methodology compared to the Waterfall?

Pros:

• Agile products are highly client/customer focused. Clients can be more involved than Waterfall projects.
• Developers and cross-functional teams are often more motivated on Agile projects. The self-organization of teams can produce better overall results.
• Considering Agile projects are continuously tested and developed, Agile products can be of higher quality with fewer bugs.

Cons:

• Agile is not always suited well for smaller projects.
• Agile projects require some members of the team to make significant decisions during daily meetings.
• The budget of Agile projects may need to be larger than that of Waterfall.
• If the product outcomes or requirements are not clear enough, the development cycle could be derailed.

Tips for Using Agile

Use Strategy Meetings

At the start of your agile projects, be sure to hash out a clear vision of the project with strategy meetings between the key stakeholders. Because the direction of agile projects may change throughout their execution, a big-picture vision must be clear for all stakeholders. It's during these meetings that aspects such as key product benefits, the primary competitive alternative, and the target customers can be established across all teams.

Design a Goal-Oriented Roadmap

After a clear strategy is established for the agile project, a goal-oriented roadmap is required to complete development. This roadmap is essentially a big picture overview of the project requirements with flexible timelines for the development cycle. Agile's main strength lies in this flexibility. Unlike Waterfall, Agile projects are not entirely planned out in advance and forced to stick to that plan. Instead, Agile projects allow developers to 'discover' the product, if you will, finding new solutions, ideas, or requirement changes along the way. As such, Agile roadmaps should be oriented around their goals. The focus should be on the outcomes a project should achieve, the objectives of the product, along with finding new customers and boosting user engagement.

Keep Projects Moving with Sprints & Daily Startups

Agile projects ultimately play out in something referred to as "sprints." These are the short, iterative cycles in which specific progress is made. These sprints are usually organized for a few weeks at a time, anywhere from one week to a full month. The length of the sprints should be consistent throughout the entire Agile project. To keep the project moving, teams need to create a backlog of tasks to complete in the length of the sprint. Then, you simply need to work through them!

Which Methodology is Right For Your Project?

When to Use Waterfall

Ultimately, the Waterfall methodology is best used for those projects that have firm costs and timelines. Waterfall can be of great use if the requirements and regulations of a project are well defined and relatively unchanging. With these projects, the waterfall methodology can serve you best in providing a firm and well-defined feature set when budgets and timelines are strict.

Use the Waterfall methodology when:

• You have a tight, fixed budget for the project,
• The product owner or the client isn't heavily involved,
• The project timeline is lengthier and less flexible,
• Many varying project requirements.

When to Use Agile

If you have a project that may change significantly in the future or one without a very specific scope, Agile could be the best methodology. If during development, the team finds that they need to change directions or make some development adjustments, Agile allows them to do so smoothly. Therefore, it's best to use the Agile methodology if your project needs the flexibility to take advantage of those opportunities that may come throughout the development cycle.

Use the Agile methodology when:

• The project budget is flexible,
• The project timeline is shorter and flexible,
• The product owner or the client is heavily involved in the development cycle,
• There are few or flexible product requirements.

Ace the Tech Interview with Exponent

While your interviewers will undoubtedly be exploring your knowledge of development methodologies, that's not all they'll be looking at. We know, better than anyone, that there are dozens of different topics and questions that are discussed during tech interviews. If you find yourself becoming overwhelmed during your interview prep, then Exponent can help. Whether it with our company-specific interview guide, interview prep courses, interview coaching, or access to our community of tech insiders and like-minded job seekers, Exponent has the tools you need to ensure you nail your upcoming tech interviews. So what are you waiting for? Come join Exponent today!