Waterfall vs. Agile Project Management Methodologies

Let's talk about different project management methodologies. If you think about how many different kinds of projects there are, from manufacturing to construction to software development, just to name a few, there are so many different kinds of things that are so different from each other, like developing an app versus developing a physical product or building a building. These are very different kinds of projects that we would undertake.

So do you think it makes sense that there's just one method that we use to manage all of these different kinds of projects? No, I think it makes sense that there are different ways to manage different kinds of projects. Here are just a few of the different methodologies. Now, don't be overwhelmed, we're going to be focusing on just a few of these.

Waterfall, critical path, we'll talk about agile with things like Scrum and Kanban. You do not have to know all methodologies; you can find the ones that work best for you. Some of these focus on specific types of approaches and specific desired outcomes, but let's talk about a couple of these, so we understand some of the differences in their approaches.

Starting with waterfall, waterfall is very sequential, meaning it's very linear. You do one thing before doing another, and there are very distinct phases or tasks where we're doing one thing, and we have to finish that before moving on to the next. So if you look at this waterfall of phase one, then phase two, and then phase three, we have to do phase one before moving on to phase two.

So if you think about a project, there's probably some end goal that you have in mind, but that's not where you start. You have to start somewhere. So if your goal is to, let's say, you want to have a building, you want to have a house, you want to have a business or something, but let's say a house, you want a roof over your head.

You can't just put up the roof because it'll fall down on you, so you need walls to hold it up, but you can't just put walls on grass on the ground. You need a foundation that's strong enough for it to sit on, so it doesn't rot into the ground. Now, if you're going to pour a foundation, you need a hole in the ground, right? And the governments normally don't just let you dig a big hole in the ground without some sort of permit.

See how we're figuring out sometimes in reverse the order of things that we need to do. Your mind might not start with step one. Your mind, when you're thinking about what you need to do, you might end with something, right? Or you might have something in mind, but then you kind of have to work backwards into what is the first thing that we actually have to do.

But then once you get this kind of linear kind of waterfall approach, the first step is that you have to, let's say, get a permit, right? And this might not be an exact, you know, perfect step-by-step of everything. I'm greatly simplifying it. But, you know, step one is you've got to get a permit.

And if you don't have a permit, you can't dig the hole to pour the foundation. And until you've dug the hole, you cannot pour the foundation. And you cannot put up the walls until you have poured the foundation and it's dry, and so on and so on.

Now, sometimes in this process, there might be some parts that can be done at the same time. For example, once the walls are up, you might be able to do plumbing and electrical at the same time, do those things concurrently, because, you know, maybe a plumber can be in one room while an electrician is in the other room. But both of those would need to be done before you go on to, let's say, drywall to put that drywall over top of the electrical and plumbing work.

So there's definitely a sequence, right? We got to go from one phase to another to another. This waterfall approach is the most straightforward, the most linear of doing something, then moving on to something else, then moving on to something else. It's very traditional.

It's used in a lot of different projects and different types of projects. So it's a primary one that we're going to focus on in this class. And if you can understand that, there are a lot of other kinds of offshoots that are very similar, that use similar ideas.

And then you can learn the differences between those other approaches. Now, one aspect of waterfall, when we think about it, is that there's something called the critical path method. And here you see abbreviations like CPM, where in the project management industry, it seems like this industry really loves abbreviations.

We even abbreviate our job title, PM, or PMs, project managers. So I always like to have the abbreviation with the full out written explanation of it. But the critical path method, or critical path for short, is thinking about waterfall, but recognizing, really focusing on those dependencies of one task being dependent on another, forming what's called the critical path.

We'll see examples of this later. I'm just doing an overview right now. And we'll see specific examples of this in the future.

And the idea is that the critical path is the longest sequence of tasks that must be finished in order for the whole project to be completed. What I mean by that is, as I was mentioning, there are some tasks that could be done at the same time, such as electrical, plumbing, and so on. But there are certain tasks where you must do one thing, and the next one can't be started until that first task is done.

That forms a chain, a path, this critical path, where we have one step, and then another, and then another, that sequence, you must do those steps in that order. And you can't move on to the next step until the first step is done. So that forms this path, this critical path.

It's critical because that's how long your project is. It's going to take that long because you need to do all of those steps in that order. And if there were any delay in that critical path, well, you're going to have to delay all the future steps when one step is delayed, because you can't move on to the next step until the first step is done.

So it's really critical that we keep an eye on that critical path, because we are highly dependent on that going as best as possible according to plan. So delays in that critical path are going to delay the whole project. So we've got to really be careful of those.

And we'll come back, we'll talk more about that. Well, as I said, I'll give some examples of how we can identify what tasks make up that critical path. Now, one way to visualize the projects that we have is something called Gantt charts.

And it's a way to simply visualize the things that we have in our project. And they're actually there; they were named Gantt charts because they were named after Henry Gantt, who designed this kind of chart back in the early 1900s. You know, he was working on his computer and decided, in the 1900s, he didn't have a computer; they were drawing these by hand.

So what this is showing here is the length of tasks and the sequence of tasks. And this was a way for us to visualize and kind of conceptualize how long things take, the dependencies of things. And of course, we do these on computers today.

But years ago, they were still finding these things so useful that they hand-drew them. But when we look at this, the longer the task, the longer it takes; the shorter it is, the less time it takes. Also, I can very quickly see the overlap between things.

And so let's say one task was finished, and then the next task must start after that, that would form a critical path, and it would look like a waterfall. So in this case, we can start research before the planning is fully finished. So they're going to start planning.

And while they're still doing some planning, they can start doing some research, probably on some of the things that they started planning. Also, when it comes to design, they have evidently done enough planning and enough research that they can start designing some things. And once some of the design is done, they can start implementing, even if not all the design is done.

So that's very interesting about this particular project, because sometimes you'd have to finish completely the design. And that would end here before the implementation starts. So Gantt charts are a way to help visualize, and they help you to create this kind of mental image of how long things take, the sequence, and the relationships of those tasks.

And when we think about project management applications, which we use today to create these, you can create these in Excel or Google Sheets, if that's all you have. But there are dedicated project management software programs that you can use. Some of them will have free levels or free trials.

Most of the time, for most software, they don't give Gantt charts at the free level. They normally make you pay because they know that it's so useful for project managers. Now switching gears from that waterfall approach to a very different approach, agile project management.

And right now, these are just kind of overviews of these things. We'll be diving deeper into different aspects, seeing more examples, and I will come back later to talk more about agile. But for now, I just want to overview it so we can kind of keep these things in mind as we go further and learn about these things.

So there's this thing called the Agile Alliance, and this is something that they've written, Agile Software Development. So this was created for software development. One, we started creating things like applications and websites, doing digital type work to create software.

A new style of project management was necessary because of the flexibility that was required to develop these things. When you're, let's say, building a McDonald's, you don't get halfway through a McDonald's and be like, oh, this should be a hospital instead, or vice versa. You know, you're building a hospital, and you're halfway through that, and you're like, this should be a McDonald's.

No, you're generally building a building for a specific purpose. But software, you know, in terms of new features, things that we're adding to it, can be flexible. That can change.

And the pace of that change is much more rapid. Now, I know that this is talking about software development, and the need for flexibility has grown across different industries. It's not just for software development.

So if you're not in software, don't think, oh, I don't need to listen to this. You still, if you need flexibility and you need to be able to adapt quickly, this style of project management still might be useful for you. So don't just tune this out.

You never know when this can come in handy. Agile software development is an umbrella term for a set of frameworks and practices based on the values and principles expressed in the manifesto for agile software development and the 12 principles behind it. Now, what is this manifesto? We, as an agile alliance, so this is the agile alliance speaking here, we are uncovering better ways of developing software by doing it.

So this is not some theory that they're sitting in a boardroom thinking about never having done it. No, they're uncovering better ways of developing software by doing it and helping other people do it. So they've kind of realized certain things in the work, right? So that's the best way to make sure that things work well: to actually do it and help people to do it.

And through that experience, they, through that work, they've come to value certain things. They value individuals and how they interact in teams and things, and how they work with each other more than processes and tools. Meaning we care about the people who are working for our company and working in our teams, and how they work together as a team.

We care about that more than a process or tool. If there's a process or tool that we've had for let's say years, and it's not working anymore, and it's hindering people and how they work together. If we stay with it, we care more about the process or the tool than we do the people, because if there was a better process or tool that we can switch to, if we don't switch to it, we care more about the process or the tool.

So when it comes down to it, if we could change and we can improve the process or tool so that people can work better together, wouldn't we want to do that? That's the Agile way. Now, some places say I'm sticking to this. This is the way we've done it for years.

Even though it's not as good, they care more about the process or tool. Agile cares more about the working software versus, let's say, comprehensive documentation. So if I had a choice to let's say make software better to improve the service or the thing that I'm creating to make a better product versus documenting maybe how it doesn't work so well, if I had to make a choice, I'd care about making it better rather than documenting how it doesn't work so well or documenting a workaround.

It's not to say that we won't have processes and tools. It's not to say we won't have documentation, but which do we care more about? We care about people working together to create a good quality product more than processes and tools, more than documentation. We care about those things more.

We are concerned with customer collaboration, and we're putting more of a focus on that than contract negotiation. So it's not to say we won't have contracts, but when it comes down to it, if let's say our client, if their changes need and we want to keep that client, we're collaborating with them, their changing needs, we might need to change with those. If we need to renegotiate a contract and adapt with them, that's going to keep that client.

We're going to hopefully keep working with those clients. If let's say we said when a client, when their needs change, said, oh no, our contract doesn't allow that. We're sticking to the contract, and I know you can't really use this anymore, but we're going to fulfill the needs of the contract, or you're just going to pay us for it.

We're not going to adapt. We're not changing. We're not willing to renegotiate.

We don't want to work with you. Do you think that client's going to want to keep working with your company anymore? Probably not. But if you adapt with them and change with them and are willing to renegotiate contracts, potentially, it's not to say that any one side is going to abuse the other.

This is that we want to collaborate. We want to keep you as a client, and we are willing to change because we know that this is a changing environment. And finally, it's about flexibility.

It's about responding to change versus sticking to a plan. If your plan is not good anymore, you need to be able to be willing to change it and respond to it and change and adapt because there is no guarantee that things are going to work out for your project, for your company. There's one thing that I'll say throughout this training a lot is don't assume success.

Now it might sound pessimistic, but we have to work for success. We don't, we can't just assume success. And if we assume success, we'll have problems.

Like you assume that everything's going to go right. You assume that you'll have no problems. You assume that all your, your estimates and your budgets and everything are correct.

If you just make all these assumptions and there could never be anything that goes wrong, there could never be any risks or things. You're not going to work to figure out what those risks might be. You're just like, oh, nothing's going to go wrong.

Everything's going to be perfect. You wouldn't plan on having flexibility. So companies have done this.

Companies have done this with products. So there's a difference between product development and project management. So if we think about managing a product, a product could be, let's say, the iPhone.

So the iPhone, when, when Apple every year comes out with a new iPhone, that iPhone as a product, which goes through many iterations from year to year to year, they need to be agile in a sense, adapting. For example, artificial intelligence is a big thing today with AI. And I think that, you know, if you had gone a couple of years ago, I don't think that they probably would have thought AI would be as big as it is right now.

So they're having to respond to that change. We'll have to see how they adapt through this, through this changing period. You know, they probably had a plan, but they need to be flexible.

They need to be able to adapt and change as necessary. And so for any given iPhone, let's say one particular iPhone, the iPhone 16, 17, and upcoming 18 for next year. When we think about that particular iPhone, once they've honed in on what an iPhone is going to be, and they're building a physical product, that particular building out of that product for that year, that would probably be done with a waterfall approach, building things like that.

You know, they have to build specific things to specific requirements. Got to do step one, step two, step three. So each version of an iPhone is probably a waterfall approach to manage the building of that iPhone, but from year to year to year as a product overall, and how the iterations of that go, they probably adapt.

Right. And that's an agile approach to that. Now you can do agile approaches within projects themselves as well, which I'll explain in just a moment, but we can't assume success.

Sometimes we need to change. For example, when Steve Ballmer was CEO of Microsoft and the iPhone came out, you know, he's like $600 subsidized iPhone. You know, I like where we're at with the Windows phone that we currently have, which kind of looked like Windows 95.

It was horrible. It wasn't very good. And so they took a really long time.

They stuck to their plan, which took a really long time to respond to change. And, and they failed the windows phone that they eventually released to kind of compete with the iPhone. It was way too late.

Didn't go anywhere. Didn't really get any traction. The CEO of Palm was doing lots of things at the time.

Same thing with BlackBerry. You know, the CEO of Palm said, Apple can't just waltz in here and get it right the first time. Surprise.

They actually did. And you know, they, they completely changed the industry. So, Palm as a company went away.

Although it's webOS that they eventually created as a kind of answer to the iPhone, it lives on in LG TVs. If you have an LG TV, it runs on webOS, which was a remnant of the technology sale from Palm. BlackBerrys, BlackBerrys, they were, people love their BlackBerrys so much.

They call them crackberries. President Obama was the first U.S. president with a smartphone. They had to get him special permission to have his BlackBerry, his crackberry.

He loved it. He loved his BlackBerry. So many people love their BlackBerrys.

So BlackBerry, Palm, Windows phone, at the time, you know, the iPhone came in, changed everything. And all of those companies, Microsoft, Palm, BlackBerry, they stuck to their plan too long, and they didn't adapt. They didn't respond to change.

And they all, all those products and some of the companies have gone away. Microsoft and BlackBerry are still around, although they do different things. They're not making those devices.

Palm as a company is gone. So, there was one company at the time that responded to that change. And that was Google.

At the time, Google was creating Android. And at the moment before the iPhone came out, the first Android phone was going to look like a BlackBerry. They were copying the BlackBerry, basically.

And then once the iPhone came out, they're like, hey, let's very quickly. No, we're not doing the BlackBerry copy anymore. We're going to copy the iPhone and make it more like that.

And so the only company at the time that responded to change was Google with Android. And they were the ones who succeeded. So projects may fail, companies may fail.

And if they are not agile in either project management or product management, in this class, we're going to focus on project management. Of course, we're not focusing on product management, but I like to say that because agile can be for both projects and products, we need to make sure that we're choosing something when we need that flexibility, that we're managing things that allow for that flexibility. So the things that are on the left, we in agile, we care more about those things.

We value the things on the left more than the things on the right. So it's not to say that the things on the right have no value. They do.

We care about processes and tools and contracts and following plans, but we care about people and how they interact with each other in teams to create good products, such as working software. We value collaboration and responding to change. We care most about those things because they create a good work environment to achieve solid, good results.

So, as an example, let's say to put this kind of thing into some sort of mental idea for you to understand how we approach this. If you were developing something, right, let's say it's Uber, right? So let's say, you know, there's Uber, and there's Lyft. Let's say there are these two companies developing similar products.

If one of them takes a really long time to come to market. So let's say they're doing the waterfall approach and they're going to define exactly what they are going to do. They're going to design it.

They're going to develop it. They're going to test it. They're going to deploy it.

And let's just say for the sake of this, this is going to take a year to do. Let's say that is let's say Uber, and maybe Uber is going to be like, Hey, we're going to do, we're going to do Uber. We're going to do Uber Eats.

We're going to do all of these things from the very beginning. We're going to take a long time to do all these features because we want to be fully, you know, have all of these features before we launch. What if, and this isn't how it went down, but just as I'm just giving an example, what if Lyft had said, Hey, we're not going to do all these things right away.

We're just going to get it out there really quickly as a minimum viable product, an MVP. And we're going to do it really quickly; we're going to define, design, develop, test, and deploy. And we're going to get like the minimum viable product.

It's got to be good enough to release, but it doesn't have to have all of the features. And we're going to see how people respond. And we probably have an idea of how we want this year to play out, but we're going to break it down into three pieces, like the first initial version of the app.

And then we probably have an idea of what we want to do next, but based on market feedback and how people are responding, we could change, we could pivot at that point if we need to. And then again, once we push out the kind of the next updates, then after that, again, we probably have an idea, but, but that's a point at which we've done something, right? You've gotten something out. You can see how the market reacts.

You could decide how the next thing is going to be. And then again, how the next thing is going to be by breaking things down into bite-sized chunks or sprints, these little iterations here, you can change direction at any given point. So breaking it down into bite-sized chunks gives you more flexibility, more agility in how we're doing these things.

Now you do not need that. If you're, let's say, building a hospital, building a McDonald's, or building a specific product, right? So, using another example here, this could be that agile could be doing from one iPhone to the next iPhone to the next iPhone, right? But for one particular iPhone, maybe you do just a waterfall approach because you're specifically, what are you doing for that one iPhone, right? So we'll talk more about agile later, towards the end of level two, we'll go into more specifics, and I'll give a couple of different examples of things like Scrum and Kanban, and we'll talk more about that, but I just wanted to give an overview of these things. As far as choosing a methodology, the traditional methods, such as waterfall and critical path, are often used in building.

So construction, manufacturing, agile is definitely favored in software development, which is why it was created, but anything that requires flexibility, that agility, right? To be able to change can benefit from agile. So it really depends on things like what kind of work you're doing, your need for flexibility. Do you need that agility, that flexibility or not? How much collaboration, how big your teams are, because certain types of agile approaches require a certain setup for your teams and certain team sizes.

So it depends. Anytime you see these links here, which are these colored underline links in your PDF, those are clickable links. If you want to go out and read more in an article, I do like to link out to additional things.

If you want to read more, this will go through different industries, different approaches, and see which one might be appropriate for your particular industry.