Agile Vs. Waterfall: Which Is Best For Your Team?
Agile, Waterfall, Kanban, Scrum, Six Sigma are just a few of the many project management buzzwords you may hear around your office.
So what do all of these words mean? Is one methodology better than another? Today I am going to focus on two of the most popular methodologies in software development – Agile & Waterfall. I will be giving an overview of both approaches and diving into my experience and opinions with both.
The Basics
Waterfall
The Waterfall methodology is a sequential design process, that when diagramed out it looks much like a waterfall. In software development, the phases are usually something like Discovery – Development – QA – Bug Fixing – Launch. Waterfall projects start by confirming the budget, scope and defining all of the requirements up front. Documentation and record keeping is a key part of this process to help teams keep track of progress and improve on the projects in the future. Once the project has been started, you can only move onto the next phase if the current phase is totally complete. If an error is found after completing a phase, you can’t go back and open up that phase again. Instead the project needs to start from the beginning.
Waterfall is traditional and very easy to understand with strong emphasis on documentation. It usually requires low client participation but the inflexibility of this step-by-step process leaves very little room for error.
Agile
The Agile methodology follows an incremental approach to the project instead of a sequential one. The team – called a scrum team – starts off working on a simple first version of the intended product, often called an MVP (Minimum Viable Product). The work is done in small segments that are defined up front and worked on during sprints. Sprints are usually 2-4 week periods of time where a set amount of work is agreed to and the team delivers a working product (MVP) at the end. Throughout the sprint, the team meets for scheduled planning and check-in meetings called ceremonies. These help the team stay on track and allow for discussion on any blockers than need to be removed for the team to continue progressing forward. One of the main benefits of Agile, is that the product is reviewed and tested at the end of each sprint instead of waiting until the end of the project. This makes it easier to fix bugs and make pivots to strategies throughout the project.
Agile is well known for being a very collaborative and flexible process that usually leads teams to launching the product on time. Unfortunately, due to the flexibility of Agile, the final product can end up being very different than the original idea. It is important to remember that Agile is hard to do right, and very easy to do wrong.
My Experience
Most of my career as a project manager has been focused on using the traditional waterfall method. I’ve had success with this method mostly because a lot of my projects at past companies were smaller and focused on creating marketing collateral. The turnaround time on a project was usually 2-4 weeks and the outcome was clearly defined (ie. an email promoting 20% off shoes or a display banner promoting a newly released webinar). However, because the projects were linear, sometimes we ended up having feedback given extremely late in the process which led to late nights of rework and unhappy team members. This was especially common on projects where the design needed to be duplicated across multiple sized collateral and channels. Also, a lot of the last minute feedback given was due to assumptions being made at the beginning on what the final product should look like, and not having the final stakeholders involved in the process the whole time. These issues would have been avoided had we used an agile approach.
The more technical and larger my projects have become the more I have seen a need for agile. I was completely sold on technique after finishing my ScrumMaster training and have been trying to incorporate it into every project that makes sense to do so. One of my current projects is running fully agile and we have been incredibly productive and successful. The biggest catalyst to our success has been the buy-in from the entire team and their willingness to participate in all ceremonies. I did, however, have another fully agile project a few months ago that did not run so smoothly due to team members not being engaged and being spread too thin across multiple projects. If there is a weak link in the team it is painfully obvious when using agile.
In Conclusion
As you can see, both methodologies have their pros and cons. Based on our experience, my colleagues and I believe that the project management methodology should be selected on a project by project basis. A lot of pieces go into making the decision but from a basic standpoint, Waterfall should be used when it is a smaller project and there is a clear picture of what the final product will be. If the deliverable isn’t clear, the scope might change and the project is quite large, then Agile should be used. In the end, the project management process used should be based on the teams working style and end goals.
With many years of experience, the expert project management team here at Bounteous is here to help guide your team to making the best process decision for your project.