Transcript: The 3 Most Impactful Differences Between Waterfall and Agile Methodology

When we take a look at the three most impactful differences, let’s start first with, “What is Waterfall?” If you’ve got your PMP certification or your Certified Associate in Project Management, or even if you’re working on longer term projects, chances are you’ve utilized some of Waterfall best practices. What is Waterfall? It’s a sequential process flow. Now, what that means in English is basically we are planning in advance; much like a waterfall falls from top to bottom, we are taking a look at different processes. We initiate, then we plan, then we execute, and then we monitor and control before we close everything out.

Chances are scope is pretty well known in the beginning. We’re doing some kind of construction project or mass producing something. We’re looking for something that is tangible. Because scope of work is so well known, chances are we’re better able to pre-plan and then execute. But in Waterfall project management, there’s a very formal change control system. We go forward thinking this is going to be the scope of work. We’re planning on it. We are dependent upon the requirements that we collected. We collect them fairly early in the process, in fact, right at the very beginning of planning.

We’ve got the scope of work requirements. That way, we can better select our durations of time, try and figure out what our finish dates are, and at the same time, look at the cost estimates for resources, equipment, material, and so on, and set an appropriate baseline for the entire project. Because of that, it’s probably a longer term project, maybe a year or longer, and most Waterfall projects end up in something that is tangible. Not all, but most.

When we take a look at the challenges of Waterfall, it’s really one of the things where if you’ve ever created something in a project, a tangible deliverable, and then had the customer come in and sign off on it and validate it at the end and not validate it at the end and then say, “Well, no, I really wanted this instead of that,” that’s very frustrating because if we set things up on the front end and we gather requirements, then we’re hoping that we’re producing the correct end result. Doesn’t always work out that way. Changes in the middle of this are super difficult in some cases to actually implement because we actually have a set plan.

Another thing about Waterfall is heavy documentation. When I teach the PMP classes, I hear from a lot of folks that, “Wow, there’s so much documentation in this course for Waterfall.” Well, basically, there are a lot of best practices for documentation. It’s our job as project managers to pick and choose what documentation we are going to do. But because we’re heavily pre-planning, chances are we’re heavily documenting, as well.

Now, if we get too many scope changes, that can actually cancel our project and we would have to start over. Think about it. If the customer wants you to mass produce them bicycles and in the middle of the project they decide they want a motorcycle instead, that would result in a brand new project. It doesn’t really allow the flexibility for big or impactful scope changes. A lot of times, that becomes the challenge in Waterfall.

What is Agile? Think of the word “agility.” Agile is typically, or was typically, designed for knowledge work because software developers were looking at Waterfall project management and saying, “This isn’t working. We are trying to work with new, cutting edge technology. Things change all the time.” It’s very difficult to pre-plan something like this when we expect changes. Agile was developed to create a very simple design that becomes more clear throughout the project. We expect change and we embrace it. Hey, we wanna build the right thing and we wanna build it right.

The only way to really do that is to not pre-plan too far out into the future. We use short iterations, or sprints, which are 30 days or less. At the end of that sprint, we are producing a workable type of increment that can be reviewed by the customer and they can look at that and say, “Well, on the website that you’re building me, I’d rather have the Enter button on the left instead of the right. Can you do that?” Absolutely, because we haven’t gotten too far into the actual project and we can adapt, adjust, and practice agility. Most of the time, this is going to be for more knowledge work, software development, websites, things like that where we’re not actually producing something tangible.

These days, though, things are getting to be a bit more tailored because there are challenges on both sides. First of all, it’s very difficult to select the right requirements because as we’re changing, as we’re shifting, as we’re being agile, we’re trying to produce something that meets the customer’s needs and actually provides some kind of value. Now, Agile is easy to talk about, but it’s very difficult to do if you’re practicing scrum or XP or future-driven development. If we get inexperienced team members or even senior management that is not engaged fully in the best practices of Agile, then sometimes this can be very chaotic and difficult to actually implement.

Without support from senior management, it’s probably going to be very difficult to implement some kind of Agile best practice on your projects. It’s constantly being practiced, constantly being reaffirmed, that we are doing the right thing and we’re doing the right thing and building the right thing right. That’s the challenge to Agile. Although, the three most impactful differences when you look at Agile versus Waterfall is with Agile, we really don’t have a clear picture in the beginning of what that final product is going to look like.

We know that the customer maybe wants a software program that helps with their payroll system, but we don’t really know what that looks like right away. The other thing that we’re trying to do is create usable increments quickly. Does that mean after one sprint the customer’s going to walk away with exactly what they asked for? No. But they will walk away with the ability to review, test, and make decisions about what they want to update in the next sprint. We expect change. Change is expected. We can add features as needed. But when we’re talking more about a Waterfall environment, we’ve got a very clear picture of the end result.

We’re building a bridge. We’re building a skyscraper. We’re building a housing development. We’re mass producing bicycles. We know what the end result is supposed to look like. That doesn’t mean that we don’t have to collect requirements and that things change, because they always do. You’ve probably heard the term “scope creep.” Yeah. We live it and breathe it in Waterfall. In Agile, we’re like, “Yay! Scope creep!” In Waterfall, “No! That’s not good!” Quality is more important at that point than producing something quickly. Because of that, change is formally controlled and could very well affect our baselines.

Those are the three most impactful differences between the two. Ultimately, when we are talking about an Agile project or Waterfall project and we’re comparing the two, there is value in a lot of the best practices between the two methodologies. We have to pick and choose how we’re going to tailor. Hopefully that helped explain some of the major differences between Waterfall project management and Agile project management so you get a good understanding of the big differences between them and the value and/or challenges of each. Thanks so much.


View the VBlog and video of this transcript HERE[/vc_column_text][/vc_column_inner][/vc_row_inner][/vc_column][/vc_row]