- As I've mentioned in my previous videos,
my background is in production,
specifically live sound and more recently film and video.
In both of these arenas,
nearly every project that I've been a part of,
whether I knew it or not used a waterfall approach
to planning and executing the project.
Until I started working at TeamGantt,
I had never even heard the term agile,
at least not as it relates
to project management methodologies.
Though, to be fair, I hadn't heard of waterfall
as a methodology either.
For most of my career, I only viewed projects linearly.
There was a series of steps or tasks
that had to be completed
before the next series of steps or tasks could begin.
And if at some point in the project, a big change was made,
we might have to go all the way back to the beginning
and redo some number of those initial tasks,
and then hope that any work we had done past that point
was still usable.
It usually wasn't at least not entirely.
This worked well because in film and video production,
you're not worrying about delivering anything
early or often.
You're headed towards the release
of a single complete deliverable, the movie
or documentary or episode.
All the decisions are made up front
and then they're executed meticulously in order,
the end result is a summer blockbuster
or at least a respectable showing at a festival, hopefully.
The point is that for projects like that,
waterfall makes the most sense
because every part of the project builds on the previous
in a predictable way.
The idea becomes a script then storyboards,
which leads to locations being chosen.
Then the art department comes in and does their magic
to create the visual world of the story.
After that the grip and electric department come in
and get everything lit.
The camera teams, get the camera set up and ready to roll
while the actors are in hair and makeup.
Finally, the director calls action
and the movie magic begins.
Some of those tasks can happen concurrently
and some are dependent on others finishing first.
The sets can't be lit until they're built or dressed
and they can't be built or dressed until the location
or soundstage is chosen.
You get the idea.
Even once the shooting has wrapped,
there's still months of work to be done
and it usually happens in a waterfall method.
The assistant editors get all the footage
and start building rough sequences,
then the editor starts cutting what will become
the final film.
Once there's a rough cut, some of the visual effects
can start and the sound mixers can start
getting everything crisp.
I could keep going here, but I think you get the idea.
Unlike movies, things like software development
don't need to be tackled quite so head on.
The project teams also don't necessarily
need to have all the details before they can begin working.
Sure, there are some key details that need to be planned out
and spoiler this part is usually done
in a very waterfall method,
likely on a Gantt chart.
But once they know what their tech stack will look like,
they can at least start building the backend
of the application and begin testing it.
Agile workflows generally work in sprints,
usually a two to four week chunk of time
where the goal is to deliver a working product
or at least part of it.
Sprint planning enables the team to estimate tasks
and determine what work they'll take on
in the sprint backlog,
which essentially serves as the task list
for the next sprint.
Then there's a daily check-in
where the team gets together
talk about what they worked on yesterday,
what they're doing today
and if there are any blockers in their way.
At the end of a sprint,
there's a sprint review,
in this meeting the whole team sits down
with product owners to review or demo work done
in the sprint and get feedback or approvals.
Finally, there's the sprint retrospective
where the team talks through what worked and what didn't
in the last sprint.
Everyone commits to making changes together
to improve communication, collaboration,
and even deliverables to make future sprints
go more smoothly.
Once all that is complete,
the process starts all over again and continues
until the project is ready to launch.
This approach was designed for and works really well
with software development,
but it's taken other industries and project types by storm
in the last couple of years.
In some cases it's worked out really well
and others there've been growing pains.
Let me stop here for a second and say that
there's no wrong methodology for a project,
find what works best for your team and your stakeholders
and run with it.
If you find that planning to build the next killer app
in a pure waterfall approach works for you and your team,
then go for it.
And if you wanna plan the next citizen Kane
in two week sprints, by all means, knock yourself out.
All of that said, it seems pretty rare these days
to find a project that's pure agile or pure waterfall.
There's almost always a hybrid approach and for good reason,
let's take a look at some of the strengths and weaknesses
of both agile and waterfall approaches,
clear and complete documentation.
The fact that waterfall produces
detailed project requirements
means every piece of your project
will be well-defined and documented.
If someone wants to change a requirement,
discuss it head on because scope and budget
will always be affected.
Solid estimates, set clear expectations,
Most waterfall project leaders
will create a work breakdown structure
of all tasks and sub tasks.
That detailed estimate can then translate
to a firm project scope that correlates
to a detailed project plan,
creating very clear expectations about timing and scope.
Visual project plans are easy to understand,
creating a waterfall project plan is fairly straightforward
because projects run in a linear manner
with defined dependencies and responsibilities.
Plus the division of steps and tasks is simple to interpret.
This makes planning your team's time easier
and leads to a clear ending.
It's easy to measure the impact of project changes
while it's difficult to make up for changes
or miss deadlines, it's easy to determine the impact
of a change and quickly make adjustments
though, that does usually mean your deadline
will be effected.
Communicating progress is simple,
it's easy measure the completeness of your projects
because all tasks and milestones
are mapped out with dependencies.
Accountability is clear, each person can see
when they're expected do their part
and what happens if there's a delay,
Communications are easier
when everyone can visualize the project,
you're able to easily communicate with bosses,
clients and team members.
Everyone can review the project plan together
when it's drafted and spot potential issues
or areas that might require special attention.
Of course, waterfall project management
comes with a few limitations too.
So consider these things before deciding if waterfall
is right for your project.
Silos and lack of collaboration,
because team members work on specific tasks
in phases and handoff work to someone else,
it leaves less room for collaboration across teams.
Instead, it's all about getting work done
to documentation and ensuring the next person in line
can use what was previously created or documented.
Speed to launch, when you build one thing at a time,
it means you take a considerable amount of time
to get just one thing done even if you could be working
on other things at the same time.
Ideation, if you don't know what you wanna build,
waterfall project management is not for you.
The idea here is to receive or create project requirements
and act on them, not iterate on them throughout the process.
Change and documentation,
things change in business and when documentation is built
at the beginning of a project,
the project can't always change with the business
without serious impact.
Sometimes that impact might be
to start your whole project over.
So while the documentation is strong,
it can serve as a risk on longer projects.
Now let's break down the pros and cons
of agile project management.
Here are the big key benefits you'll find
using an agile method.
Focus on quality because products are built collaboratively
and tested during sprint cycles,
the product has many eyes on it at all times.
And the flexibility of the process enables teams
to pivot and make a change for the better
if something's not working well.
Lightweight process scram offers a light framework
for helping teams work together,
lower level documentation and collaboration
means the focus is on rapid delivery and iteration.
Continuing evaluation, and optimization,
the measuring and evaluating the work and how it's done
allows accurate and early visibility into the progress
or even problems with a project.
Plus sprint reviews regularly open the door
to gain alignment and act on feedback more quickly.
Reduced risk, agile methodology is virtually eliminate
the chances of absolute project failure
unless the team is just not performing well.
But the fact that teams work in sprints
toward releasing a working product,
means there's always progress.
Even if that progress is open to change,
a team is working toward goals set by the product owner.
High stakeholder satisfaction, because changes easy
to adapt to and the process requires them
to be more involved, stakeholders are more aligned
with the project team and tend to be happier
because they have a higher probability of getting
what they want.
Okay, so we've talked about agile and waterfall
and the pros and cons to both,
but what about this hybrid thing I mentioned?
Like I said earlier,
almost no project today is pure waterfall or pure agile,
agile software projects still rely
on larger overarching plan of some sort.
At least if you want the product to be complete
by a specific time.
If you have a launch day that you're shooting for
a pure agile approach won't work well
because there's no hard end to the iteration process.
Somewhere hidden in an office that the project teams
never get to see is likely a Gantt chart
that the project leader is referencing
to make sure everything is on track
in terms of overall timing.
And that's okay, it doesn't make the project
any less agile.
Also on even the most linear projects,
there are almost always tasks or groups of tasks
that can happen concurrently and require,
or at least benefit from collaboration across teams.
To go back to my movie example,
the writing process is usually very collaborative
and iterative, it's not really important
that the story be written from start to finish.
Some writers enjoy having an ending in mind
and backing their way into it,
others prefer to just have a loose premise
and see where the story takes them as they write.
There seems to be something of a war
between the Agileists and waterfall folks out there,
but there really shouldn't be,
both of these methodologies are powerful tools
to help you get projects done on time and on budget.
And there's no reason they can't coexist
and be used in conjunction to get the most
out of your project and your teams.
I'd love to hear from you though,
are your projects mostly agile, waterfall
or some combination of both?
Have you been hesitant to try one method over the other?
Let me know in the comments and if this video
has helped you out, I'd love it
if you could return the favor and hit that like button
and don't forget to subscribe to our channel
and turn notifications on so you don't miss
any of our videos.
Thanks for watching, I'll see you next time.
(upbeat music)