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.
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.
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:
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.
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.
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.
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.
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.
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.
While many today feel as though the Waterfall method is on its way out, it still has many benefits for the right projects:
Nevertheless, the Waterfall Methodology does have its limits and drawbacks:
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.
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.
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.
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.
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:
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:
So what are the drawbacks and benefits of using the Agile methodology compared to the Waterfall?
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.
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.
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!
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:
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:
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!