- If you work for a large organization,
then you might hear the term Waterfall
or Stage-Gate Release.
The Waterfall model is a step-by-step approach
that was used in engineering.
Each step falls into the next, like a Waterfall.
In the 1970s, a computer scientist named Winston Royce
took this Waterfall model
and reworked it to make it work with software.
The first stage was gather requirements.
Then, analyze the requirements,
design the system,
code the software,
test the software and deploy.
For 30 years, this was the most popular way
to develop software.
In fact, many organizations are still using this approach.
Business analysts will work on analyzing the requirements.
The software architects will design the system.
Software developers will then code the software
and a separate quality assurance team
will run all the tests.
Often, there's a separate infrastructure team
that's responsible for deployment.
Chances are your organization still has several
of these people working on your team.
Many Agile coaches feel that Waterfall
and an Agile mindset are complete opposites,
but the truth is a little trickier.
Remember that Agile is a mindset.
It's a way to think about your work.
While Waterfall is a concrete process.
It's strict guidelines for how you should do your work.
Many large organizations prefer strict guidelines
over a new way of thinking.
So you will almost certainly bump into times
when Waterfall practices
are inconsistent with your Agile mindset.
You see this a lot when organizations want Agile teams
to create detailed requirements,
but your Agile team will still spend plenty
of time planning, designing, analyzing and testing.
It's just that instead of working on these things
in sequential phases,
you'll have the whole team working on these things
all at the same time within a Sprint.
If you think about it,
it would be nearly impossible to deliver every few weeks
if you were using a Waterfall style approach.
If the business analyst got stuck waiting
to hear from the customer,
then the rest of the team would just sit idly
as they wait to start development for the handoff.
Remember that the Agile Manifesto
says in principles four, five and 11
that Agile teams should be motivated and self-organized.
They should also work closely with business people
when delivering the product.
That's why many Agile teams strive to be cross-functional.
So instead of having business analysts,
testers and developers,
you'll have generalized team members
that try to do a little bit of everything.
When you work as a cross-functional team,
you're not as vulnerable to these backups.
The product owner on the team will give you
all the user stories you need to keep working.
So just think of an Agile team as accomplishing
many of the same things as you do in Waterfall,
but they're just doing it in a cross-functional way
and compressing all the phases into a few weeks.