Hello and welcome to Lesson 1.3 Waterfall versus Agile.
In this lesson, we will get to the heart of the matter.
What is the waterfall project management methodology and what is the agile project management methodology? How do they differ?
And how does agile bring additional value to the organization? Because, obviously, if you are not bringing value to the organization,
then why change your processes at all? Right?
So let's talk about waterfall for a minute. We already mentioned in the Enterprise Project Management Course. Um, the fact that project management in general is a cognitive process. But that means in English
is that the project management
output, if you will, is merely the
the some of the cognitive processes of all of the members of the project team. And there's no actual Walt. There's a product manager at plan, but there's no riel
ah, product that is produced by Project Management. It's mawr of developing a framework and best practices for again, how to get the most work done in the least amount of time.
So in the waterfall cognitive process, what we're looking at is understanding
the dependencies between
different items of a project so for trying to achieve the most amount of work in the least amount of time,
from what we want to do is look at what is dependent on other things as their input
before they can be done right? So in the case of
we'll use building a house as a good example.
In the case of building a house, if I wanted to build a house using waterfall techniques, what I would do is I would start with the list of all of the work items that had to be done. Run wiring, run plumbing,
build a roof, build a foundation, build walls, all that kind of stuff. And I wouldn't really worry so much about where they fell in the order, right, cause it's the first part of the process is just identifying all of the work item that needed to be done.
Step two is Look at OK.
My refers are available on Monday,
but my walls won't be done until Thursday.
get my roof put in two days or for my walls?
Well, if you ever lived in the house, which most of us have, you know that doesn't make a lot of sense right. So in order to
be in a position to put the roof on a house, I first have to have the walls all set up. So if you're building a house via waterfall, what you're looking to do is understand the dependencies and say, OK,
I can't build a wall until my foundation is done and dried or what around a lot about construction, But you get the foundation before you can put walls up. And I can't put a roof on the house until the walls were up
walls hold up the roof and I can't run plumbing and electrical until the walls and the roof both are up and so on and so on. So what you're doing is you're developing a process and you're building a house
based on the steps that it would take in order to build that house.
That's very normal. That makes a lot of sense to most people. And so the waterfall concept
is appeals to a lot of folks because they can see the dependency charts, and they can understand
what needs to be done
before something else could be done. So looking at this project management plan in Microsoft Project here. We see sort of that waterfall concept, and we also see why is called Waterfall because it looks quite a bit like a waterfall if you look at the gang chart on the right hand side of this picture here.
So if I'm developing software and I'm using a waterfall approach, what I am doing is I'm saying, Okay,
the core structure of the software, and that means you know, the ability log in the ability launched the software. What are the basic processes that have to be there? In order for the software to be able to launch on my computer,
connect to a database, get the initial log in data
process. That data give me access to the system based on my permissions.
Show me whatever that the software wants to show me
and then move from there. So if you remember from the previous lesson, we looked at the flow chart versus the
the three by five cards, which we'll get into more detail about those later.
You see that in the waterfall world were very flow chart focused. We design software for waterfall as a holistic process whereby we develop the business process, which is again that flow charting.
And then once we develop the business process, we hang technology off of that process
so that the technology mirrors the business process.
Understanding this all came about during the 19 nineties, early two thousands, when most software with what they call client server. So you had a client
software package that connected to a centralized database. And in orderto update, said Client software, you had to develop a new package, deploy it and actually have all of your employees update that software package with all the latest and greatest features.
Let's look at Web based world, right? We were talking late nineties early, two thousands. All of a sudden, the Onley client requirement that I needed
was the Internet browser. If I had a Internet browser every time I access that Web application, I was going to get the latest and greatest code that was developed
with that whatever product manager methodology was being used.
So if I'm using waterfall,
I can't deploy a new
functionality with my existing Web based software until the entire project or programme was done,
I might spend 12 maybe even three years, developing a whole suite of new enhancements that my customer would never see until the entire project was done.
But based on the fact that I'm pulling new code with the Web application every single time I load that website.
I'm missing out on several years worth of innovations.
That agile does not you have that problem? Talk about agile here a second, but that you see the problem. The problem is, I'm not delivering any value to my business
until three years later.
But from a technological standpoint, that's not required. Once we moved into a Web based applications that was no longer an issue.
So let's talk about agile and there's a really nice picture here about what agile looks like. Agile is iterative.
The cognitive process for agile is based on the idea that I can deliver
a small bit of additional business value
Even though I can't give you the entire house, I can give you very small improvements, right? So how would we build a house with agile,
which I don't recommend, by the way, But you could build a house agile if you did whatever your initial task was, and then the customer walked in and said, Well, you know, like the where the windows were at. But it would be better if the window was moved 15 inches to the
the Easter, the last or whatever,
because that would bring in more sunlight. So, OK, cool. I'll cut the wall down and move the window, and so on, so on. That's very
time and cost intensive, so that doesn't make a lot of sense. So building a house agile is not really a very viable option.
if we're developing client server software again, think back to the nineties.
We can still kind of do releases. If we have automated method of updating the software on our customers computer, we can kind of make that work. But if we're talking about external users, partners, vendors, things like like that
becomes more challenging. So designing software with agile is a little bit more of a challenge.
But again, if you're if you think about the normal three year software development, Lifecycle, agile in the nineties, is definitely faster than the three year life cycle
here for Agile makes its money.
If you're designing a Web based application, which was a relatively new phenomenon in the 19 nineties,
and you download the entire website or not download, but you see a new version of the website
every time you log in.
All of a sudden, I can make small interim improvements to my application,
and all of my customers will see them every single time. I release something new so I can add value to my organization every two weeks month, quarter whatever, rather than having to wait three years for some new functionality.
So if you're designing a Web based application with agile,
you can bring additional value on a much, much faster scale. And if you deliver new value and the customers and like it, guess what, you can fix it
still again deliver new value to the customer. Maybe two weeks later. If you're using ah sprint type methodology, that's two weeks long.
Rather than waiting the three years that it was taking prior to agile becoming popular. So that really is the ah ha moment. The ah ha moment is understanding that my I T developers
I t product managers if they embrace agile project management,
they can deliver value in some cases
ahead of where waterfall would build value for that organization. And if you're an organization worried about cash flow value, although our oi all those kind of things that are really important for organizations all of a sudden agile becomes much more attractive.
And that concludes lesson 1.3. I hope you get excited about the idea of agile and hope. You told me for the next lesson. Thank you. And have a great day.