Agile vs. Waterfall: Which one should you choose for your project? This article explores the pros and cons of both approaches and helps you make an informed decision. Don’t miss it!

Agile vs. Waterfall

I was in a training class to prepare for a project management certification in Agile principles.  Full disclosure, I did not take the test to get certified. I should have but I didn’t. I’m actually debating if I should revisit taking the test. Enough about me.  I just like to be open and transparent.

Back to the article, I was familiar with the concepts of Agile but had not received any formal training.  It appears I had been using various Agile techniques for years without knowing. To me, Agile has a common sense approach to approaching projects. Many times, when starting out, you have an idea of what the end goal is.  I want to build a software, product, or service that __________. (fill in the blank here)

The class kept asking if agile or a waterfall approach should be used for a project. The instructor and students, including me, discussed this topic and provided answers. I wanted to further explore this concept, so I wrote this article.

So let's look at the two approaches and attempt to answer the question.  Whether one should be chosen over the other.

Let's talk about Agile

Agile is governed by the Agile Manifesto click Agile Manifesto to see the full version and the originators.

Agile Manifesto:

Individuals and interactions over processes and tools

Working Software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change by following a plan

It goes on to say

while there is value in the items on the right, we value the items on the left more.  This is referring to the words on either side of the word over.

Now, this was developed to implement software.  However, I believe this method can be used to build processes and tools, ironically. It can be used to build businesses, etc…

I personally believe the manifesto is really good. it prefers moving forward over formalities of moving forward.

However another Ironic part of agile is, there are several procedural ways to be agile. It seems no matter how hard we attempt to be agile and free flowing we must create some type of order.

The manifesto guides those that believe in agile however, the methods are a different story.

There are several ways to implement an agile project.  Here is a list of some of them:

●        Crystal

●        Scrum

●        Kanban

●        eXtreme Programming

●        Dynamic Systems Development Method (DSDM)

●        Adaptive Software Development (ASD)

Digging into these is beyond the scope of this article.  It is important to note there is more than one way to be agile. Which makes the agile process itself … Well, agile.

Now the waterfall method.

I took a scroll around the internet to see what people are writing about the waterfall method.  I noticed something interesting. They all address these 5 core components.

●        Requirements

●        Design

●        Implementation

●        Verification

●        Maintenance

But they seem to leave off what I remember as the 1st step and really in my opinion why agile has become a thing.  That is the planning.  I would state the phases of waterfall as

●        Planning

●        Requirements

●        Design

●        Implementation

●        Verification

●        Maintenance

Again, I don’t want to get into the specifics of each phase but I will talk about the planning. I’ve been on multiple waterfall projects in the early stage of my career. In my opinion, although the process each has many differences, the two primary differences are planning, and feedback. 

In the waterfall, most of the planning is performed upfront. It requires a high degree of understanding of the end goal at the beginning of the project.  With a high-level understanding of the end goal, some people come together and determine how long it should take to perform each phase of the project and how many people are needed, how much it should cost, and a general understanding of the end product. For example, say building a nuclear power plant. Would you build the reactor room using let's just build the building, put some nuclear material in there, and see what happens? Or would you define all the requirements for the controls, and building materials, to keep everyone safe before moving forward?

In agile, the planning is around the minimum viable product. What is the minimum amount we have to create for it to be a usable product? This method can apply to many things like software, products, and businesses.  However, you do not want to build the minimum viable nuclear plant.  We want that thing to be over the top in safety because of the level of risk to safety in failure.

In waterfall, customer feedback is provided near the end of the project after everything has been built. In agile, feedback is provided often starting with the MVP, and that feedback is used to make a better product.

So which methodology should be used when?

In my opinion, when safety is the ultimate concern and risks of failure are high the waterfall approach is a solid approach to a project.

When the risk is not as great, speed is important and the true end product requires feedback from others.  Agile is a great way to approach your project.

I personally believe there is more than one way to solve a problem and you choose the technique you are most comfortable with. If you look at it, delivering the MVP is very much like the waterfall method. A decision is made upfront on what has to be delivered for a functioning product, with budget and resources assigned. However, the goal of agile is to receive feedback quickly and build an improved version. In the waterfall, we are simply done and it is now up to support to help you.

I hope this helps…

Leave your thoughts or questions in the comments.  I will do my best to get back to you.

Until next time…