Waterfall vs. Agile

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or

Already have an account? Sign In »

Time
3 hours 55 minutes
Difficulty
Intermediate
CEU/CPE
4
Video Transcription
00:00
>> Hello and welcome to Lesson 1.3,
00:00
>> Waterfall versus Agile.
00:00
>> In this lesson, we will get to the heart of the matter.
00:00
What is the waterfall project management methodology
00:00
and what is the agile project management methodology.
00:00
How do they differ and how does
00:00
agile bring additional value to the organization?
00:00
Because obviously, if you are not bringing value to
00:00
the organization then why change your processes at all?
00:00
Let's talk about waterfall for a minute.
00:00
We already mentioned in
00:00
the enterprise project management course,
00:00
the fact that project management
00:00
in general is a cognitive process.
00:00
What that means in English,
00:00
is that the project management output, if you will,
00:00
is merely the sum of the cognitive processes of all of
00:00
the members of the project team and
00:00
there's a product management plan,
00:00
but there's no real product
00:00
that is produced by project management.
00:00
Is more of developing
00:00
a framework and best practices for again,
00:00
how to get the most work
00:00
done in the least amount of time.
00:00
In the waterfall cognitive process,
00:00
what we're looking at is understanding
00:00
the dependencies between different items of a project.
00:00
If we're trying to achieve
00:00
the most amount of work in the least amount of time,
00:00
what we want to do is look at what is dependent on
00:00
other things as their input before they can be done.
00:00
We'll use a building a house as a good example.
00:00
In the case of building a house,
00:00
if I wanted to build a house using waterfall techniques,
00:00
what I would do is I would start with the list
00:00
of all of the work items that had to be done.
00:00
Run wiring, run plumbing,
00:00
build a roof, build a foundation,
00:00
build the walls, all
00:00
that stuff and I wouldn't really worry
00:00
so much about where they fell on the order.
00:00
Because the first part of
00:00
the process is identifying
00:00
all of the work items that need to be done.
00:00
Step 2 is to look at,
00:00
my roofers are available on Monday,
00:00
but my walls won't be done until Thursday,
00:00
can I get my roof put in two days before my walls?
00:00
Well, if you've ever lived in a house
00:00
which most of us have,
00:00
you know that doesn't make a lot of sense.
00:00
In order to be in a position to put the roof on a house,
00:00
I first have to have the walls all set up.
00:00
If you're building a house via waterfall,
00:00
what you're looking to do
00:00
is understand the dependencies and say,
00:00
I can't build a wall until my foundation is
00:00
done and dried or whatever.
00:00
I don't know a lot about construction.
00:00
But you got to have a foundation
00:00
before you can put walls up.
00:00
I can't put a roof on the house until the walls are
00:00
up because the walls hold up
00:00
the roof and I can't run plumbing and
00:00
electrical until the walls
00:00
and the roof both are up and so on.
00:00
What you're doing is you're
00:00
developing a process and you're building
00:00
a house based on the steps that
00:00
it would take in order to build that house.
00:00
That's very normal.
00:00
That makes lot of sense to most people.
00:00
The waterfall concept appeals
00:00
to a lot of folks because they can see
00:00
the dependency charts and they can understand what
00:00
needs to be done before something else can be done.
00:00
Looking at this project management plan
00:00
in Microsoft project here,
00:00
we see that waterfall concept
00:00
then we also see why it's called waterfall
00:00
because it looks quite a bit like a waterfall if you
00:00
look at the Gantt chart
00:00
on the right-hand side of this picture here.
00:00
If I'm developing software
00:00
and I'm using a waterfall approach,
00:00
what I'm doing is I'm saying,
00:00
I have to build
00:00
the core structure of the software
00:00
and that means the ability to login,
00:00
the ability to launch the software.
00:00
What are the basic processes that have to be
00:00
there in order for
00:00
the software to be able to launch on my computer,
00:00
connect to a database,
00:00
get the initial login data, process that data,
00:00
give me access to the system based on my permissions,
00:00
show me whatever that the software wants to show me,
00:00
and then move from there.
00:00
If you remember from
00:00
the previous lesson when we looked at
00:00
the flowchart versus the three by five cards,
00:00
which we'll get into more detail about those later,
00:00
you see that in the waterfall world,
00:00
we're very flowchart focused.
00:00
We design software for waterfall as
00:00
a holistic process whereby
00:00
we develop the business process,
00:00
which is again that flowchart thing.
00:00
Then once we develop the business process,
00:00
we hang technology off of
00:00
that process so that
00:00
the technology mirrors the business process.
00:00
Understanding this all came about during the 1990s,
00:00
early 2000s when most software
00:00
were what they call client server.
00:00
You had a client software package that connected to
00:00
a centralized database and in
00:00
order to update said client software,
00:00
you had to develop a new package, deploy it,
00:00
and actually have all of your employees update
00:00
that software package with
00:00
all of the latest and greatest features.
00:00
Let's look at web-based world.
00:00
We're talking late '90s, early 2000s.
00:00
All of a sudden,
00:00
the only client requirement that I
00:00
needed was an Internet browser.
00:00
If I had an Internet browser,
00:00
every time I access that web application,
00:00
I was going to get the latest and greatest code that was
00:00
developed with
00:00
whatever project management methodology was being used.
00:00
If I'm using waterfall,
00:00
I can't deploy a new functionality with
00:00
my existing web-based software
00:00
until the entire project or program was done.
00:00
I might spend 1, 2,
00:00
maybe even three years developing a whole suite of
00:00
new enhancements that my customer would
00:00
never see until the entire project was done.
00:00
But based on the fact that I'm pulling new code
00:00
with the web application every
00:00
single time I load that website,
00:00
I'm missing out on several years worth of
00:00
innovations that agile had that problem.
00:00
We'll talk about agile here in a second.
00:00
But you see the problem.
00:00
The problem is, I'm not delivering
00:00
any value to my business,
00:00
to my sponsor until three years later.
00:00
But from a technological standpoint that's not required.
00:00
Once we moved into web-based applications,
00:00
that was no longer an issue.
00:00
Let's talk about agile.
00:00
There's a really nice picture
00:00
here about what agile it looks like.
00:00
Agile is iterative.
00:00
It's fast paced.
00:00
The cognitive process for agile
00:00
is based on the idea that I can deliver
00:00
a small bit of additional business value very rapidly.
00:00
Even though I can't give you the entire house,
00:00
I can give you very small improvements.
00:00
How would we build a house with agile,
00:00
which I don't recommend by the way.
00:00
But you could build a house to agile if you did
00:00
whatever your initial task was
00:00
and then the customer walked in and say,
00:00
well, I like the where the windows are at,
00:00
but it will be better if
00:00
the window was moved 15 inches to
00:00
the east or the west or
00:00
whatever because that would bring him more sunlight.
00:00
Okay, cool. I'll cut
00:00
the wall down and move the window and so on.
00:00
That's very time and cost intensive.
00:00
That doesn't make a lot of sense.
00:00
Building a house to agile
00:00
is not really a very viable option.
00:00
However,
00:00
if we're developing client server software, again,
00:00
think back to the '90s,
00:00
we can still do releases if we have
00:00
automated method of updating
00:00
the software on our customers' computer,
00:00
we can make that work.
00:00
But if we're talking about external users, partners,
00:00
vendors, things like that, becomes more challenging.
00:00
Designing software with agile is a little
00:00
bit more of a challenge.
00:00
But again, if you're thinking about
00:00
the normal three-year software development life-cycle,
00:00
agile in the '90s is
00:00
definitely faster than the three-year life cycle.
00:00
Here's where agile makes its money.
00:00
If you're designing a web-based application,
00:00
which was a relatively new phenomenon in the 1990s and
00:00
you see a new version
00:00
of the website every time you login,
00:00
all of a sudden I can make
00:00
small iterative improvements to
00:00
my application and all of my customers will see
00:00
them every single time I release something new.
00:00
I can add a value to
00:00
my organization every two weeks, month,
00:00
quarter or whatever, rather than having to wait
00:00
three years for some new functionality.
00:00
If you're designing a web-based application with agile,
00:00
you can bring additional value on a much faster scale.
00:00
If you deliver new value
00:00
and the customer doesn't like it,
00:00
you can fix it and still again,
00:00
deliver new value to the customer maybe two weeks later,
00:00
if you're using a sprint type methodology
00:00
that's two weeks long,
00:00
rather than waiting the three years
00:00
that it was taking prior to agile becoming popular.
00:00
That really is the aha moment.
00:00
The aha moment is understanding that
00:00
my IT developers, IT product managers,
00:00
if they embrace agile project management,
00:00
they can deliver value, in some cases,
00:00
years ahead of where waterfall would build
00:00
value for that organization and if you're
00:00
an organization worried about cash-flow,
00:00
value, or the ROI,
00:00
all those things that are really
00:00
important for organizations,
00:00
all of a sudden agile becomes much more attractive.
00:00
That concludes Lesson 1.3.
00:00
I hope you get excited about the idea of agile,
00:00
I hope you join me for the next lesson.
00:00
Thank you and have a great day.
Up Next