Guide: Navigating

between waterfall
and Agile
WITHOUT GETTING STUCK IN THE WAGILE TRAP

390075-20

Guide: Navigating between waterfall and Agile

 It’s no secret that waterfall and Agile are two of the most popular methodologies used by
engineering teams. What may not be as clear is which methodology is right for your team.
And even more difficult to understand than that, how to lead your team through a transition
from waterfall to agile.

Whether you choose to use waterfall or transition to Agile, one thing is true: wagile is the
worst option. Don’t know what wagile is? This guide will cover that and much more, including:

SECTION 1:

Choosing your methodology

SECTION 2:

Recognizing and avoiding the wagile trap

SECTION 3:

Agile transformation: What to do and what NOT to do

390075-20

Guide: Navigating between waterfall and Agile

 Section 1: Choosing your methodology

The topic of waterfall vs. Agile can feel like a battle between good and evil, if you’re a firm believer in only one of the
methodologies. Each methodology, however, has advantages over the other and should be applied to projects where those
advantages will make meaningful differences.

Too often, we allow our logical thinking to lead us to create a hybrid of waterfall and Agile; our reasoning has us believe that
combining the two methodologies will leave us with the best of both. That seductive illusion, however, leads to the worst of
both worlds—and it can’t be avoided.

Don’t fall for this trap. This article will help you determine which methodology is right for your project and explain how to
escape the dreaded wagile hybrid.

WATERFALL

Waterfall is our base measurement. Waterfall has been around for more than half a century and is a sequential methodology,
where projects follow a specific order of events. The software development lifecycle, consisting of gathering requirements,
designing a solution, building that solution, testing it, releasing it and maintaining it, is based on the waterfall methodology.

WATERFALL PROS WATERFALL CONS

Waterfall is good for... Waterfall has challenges with…

• Small projects, since they are less likely to change
• Repeatable projects, since there is a known end goal
• Physical projects, since the architecture is
already defined
• And because waterfall is an established methodology,
there is little confusion around how it works.
When to apply waterfall
A great time to apply waterfall is when you’re porting an
existing product to a new platform, such as a board game
to a mobile app.
Performance
• Medium-to-large sized projects, where the scope is
bound to change during implementation
• Innovative work, where the end goal is unknown at the
start of the project
• Digital projects, where the underlying architecture is
always changing
Unfortunately, waterfall has received a terrible reputation
over the years. It’s been proven to fail more often than
succeed, likely because it is frequently used for the types
of projects listed above. As a result, there’s a tendency
to push all requested changes into a “phase two.” The
organization, having been burned before by never actually
receiving their promised “phase two,” tends to push for
everything and the kitchen sink to be included in phase
one, thereby making the project scope grow out of control.

When to avoid waterfall

You’ll want to make sure you avoid applying waterfall when

updating a website or mobile phone app, since infrequent
Waterfall releases cause user frustration and provide opportunities
to the competition.
390075-20

Guide: Navigating between waterfall and Agile

 AGILE
About two decades ago, Agile was born. The intent was for it to be a better methodology. In most cases, it is. Agile is good for
all of the projects that waterfall falls short to support.

AGILE PROS AGILE CONS (OR ARE THEY?)

Agile is good for… Like waterfall, Agile isn’t always the answer. It struggles to

• Medium-to-large sized projects, where the scope is accommodate...

bound to change • Immediate changes, since—unlike waterfall where the

• Innovative work, where the end goal is unknown at the business partner can request changes at any time they

beginning of the project want—changes should only really be added in-between,

• Digital projects, where the underlying architecture is in
flux during development
When to apply Agile
A great time to apply Agile is when you’re developing
anything with a social media feature, since user feedback
is critical to the direction of the product and ignoring it can
backfire very quickly.
and not during, sprints
• Limited employee involvement, since it requires more
interaction with the business by way of a representative
(like a product owner) who joins the development team
• Higher overhead, since it requires daily meetings and
recurring half- to full-day planning sessions
And just like waterfall, Agile also struggles with a poor
reputation. Because Agile is great for innovative work, that
often means there is no predetermined ending, which can
make the project linger. That lingering status tarnishes
its reputation.

Of course, it’s important to know that many people view

these “cons” as positive attributes of Agile. The rigidity
keeps people focused, and while business representatives
may view more communication as intrusive on their time,
Performance

more communication leads to less assumptions and

misunderstandings between them and the development
teams, yielding a better product. Problems with agile’s
Agile
reputation and overhead don’t actually come from Agile;
they come from the hybrid state of wagile. (More on this
Waterfall
in a bit.)

When to avoid Agile

Agile won’t always meet your needs, especially when

government regulations dictate your scope and timeline,
such as is often the case in the healthcare industry.
390075-20

Guide: Navigating between waterfall and Agile

 WAGILE
As previously mentioned, people think they can combine waterfall and Agile to create an even better hybrid methodology
commonly known as Agile-fall, scrum-fall, FRagile, and our favorite, wagile.
WAGILE PROS (OR ARE THEY?)
Many leaders and teams create their wagile process with
the intent to capitalize on...
• The best of both worlds, since waterfall is good for
small, repeatable and physical projects, and Agile is
good for medium-to-large sized, innovative and
digital projects
• Less disruption, since a hybrid approach would not
force extreme change on the team
• The “special” needs of their organization, since every
organization thinks they are unique and a hybrid
approach will help them meet these needs
Of course, all of the above is false. People inexperienced
in Agile think wagile offers them the entire list above.
Logically, it makes sense; in practice, it doesn’t work.
When to apply wagile
Unfortunately, wagile can’t be avoided. You’ll may find
yourself in this state if you are beginning a transition from
waterfall to Agile.
Performance
Wagile
Agile
Waterfall
Guide: Navigating between waterfall and Agile
WAGILE CONS
Wagile can be detrimental to your goals. It offers…
• The worst of both worlds, since it’s intrusive on the
business partners and allows for a lot of scope creep,
causing projects to never end
• Confusion, since it demotivates early Agile adopters and
true believers when Agile rules are ignored
• High overhead, since management often wants to
keep waterfall weekly meetings and add Agile planning
sessions, daily stand-ups and retrospectives on top so
they can stay informed the way they always have
During this transition from waterfall to Agile, you may hear
people say that Agile is not working. But truthfully, when
you’re in a wagile state, you’re not being Agile. Agile will
work just fine once you can get there.
We’ll cut straight to the chase: there are no pros to wagile.
This graph opening this section is a seductive illusion; it
does not exist in the real world. Wagile is the worst.
When to avoid wagile
Always… or when you want to succeed.
This is an illusion
390075-20
 MOVING THROUGH WAGILE
If you find yourself in a wagile state—either because you’re transitioning from waterfall to Agile or because you were enticed by
the illusion of a hybrid methodology—you’ll want to move your team through it. Here’s how to make the full transition to Agile.

PHASE 1

Let’s take a look at a visual timeline of events, starting with phase one, which shows a team using the waterfall methodology.
They realize waterfall has issues and want to transition to Agile. Inexperienced IT leaders and business contributors assume the
change to Agile is as simple as turning on a light switch, that everyone will be working in this new methodology and that things
will be better from here on out.

PHASE 2

As soon as the change is implemented, people enter phase two. They quickly realize change is a process, and it will take some
time to transition from waterfall to Agile. However, inexperienced individuals will assume everything will slowly improve over time,
and they will eventually be Agile. We like to call this incline “the path of hope.”

390075-20

Guide: Navigating between waterfall and Agile

 PHASE 3
People enter phase three just as fast as they entered
phase two. When an Agile transition starts, things almost
immediately get worse. If you are experiencing this right
now, we have some good news and some bad news.
The good news is that this is not unusual. You are not
alone. Every person and every organization experiences
this phase. Some people will resist the change. Others will
be on-board but simply do not have enough experience
to consistently do things the right way. As a result,
performance drops. As people try to figure it out, deadlines
and stress creep up on them. And what does anyone do in
times of stress? They revert to what they know to get the
job done, which in this case is waterfall.
As you already know by now, wagile is not a methodology;
it’s an awkward transition state between waterfall and
Agile. Being in a wagile state is nothing to be ashamed of.
It honestly can’t be avoided if you’re transitioning from one
methodology to the other.
Teams can be in phase three for a very long time. Every
team that’s gone through an Agile transformation has
experienced the wagile state, and every team that will make
the Agile transformation in the future will also experience
the wagile state.
How do we know this? Because transformations involve
people, from both IT and the business. It’s extremely rare to
find an individual that can navigate a challenging transition
without any setbacks. Now imagine finding a team of those
Guide: Navigating between waterfall and Agile
individuals working together at the same organization.
Do you see our point? Wagile exists because it takes just
one person on the team to struggle for the entire team
to struggle.
Phase three is the most critical. One of three things
will happen:
1. Leadership abandons the Agile transformation
and returns to the waterfall methodology. This
is acceptable in some situations and better than
remaining in a wagile state.
2. Leadership realizes they are in a wagile state and
makes the effort to completely let go of the waterfall
and Agile hybrid, thus allowing them to move to an
Agile methodology. (Represented in the graphic above.)
3. Leadership holds onto the flawed idea that a hybrid
of waterfall and Agile methodologies is the best
path forward, thereby remaining in a low performance
environment indefinitely... until one of the other two
outcomes occurs or the company goes out of business.
If leadership opts for choice number two, letting go of
wagile so they can move to Agile, they enter phase four.
390075-20
 PHASE 4

Phase four is when the team finally realizes that adopting Agile
will be a bumpy road, with many successes and failures. They
may experience a few good sprints and then all of a sudden, the
business representative introduces scope creep and doesn’t want
to wait for the next sprint. Or perhaps someone from another area
of IT transfers onto their team, and that individual struggles to let
go of waterfall and wagile and fully embrace Agile. Or a thousand
other scenarios. Eventually, though, the team will stop using
waterfall and be Agile. This journey is a long one but well worth it if
your projects meet the criteria we reviewed earlier.

Choose wisely

While some people reject Agile and believe waterfall is the only
methodology worth using, there are also many people who have
adopted Agile and now reject waterfall completely. We won’t
exclusively recommend one methodology for you because, frankly,
both points of view are flawed. Evaluate your organizational needs
and the projects you’re working on before you make a decision
on which methodology is right for you. But, as you make that
decision, we will give you this definitive guidance: don’t choose
wagile—and if you find yourself there, actively transition out of it.

390075-20

Guide: Navigating between waterfall and Agile

 Section 2: Recognizing and avoiding the wagile trap

Wagile occurs when the Agile methodology is laid on top of the waterfall methodology, and many technology leaders think
this hybrid approach provides the best of both worlds. In reality, it provides chaos and confusion—which is the worst.

As Agile transformations go, most organizations leave a lot to be desired. Transitioning from one methodology to another takes
a lot of work, but the upfront investment will yield the results you were initially after. Wondering how wagile is holding you back
and how you can recover from it? Here are the top indicators of wagile and how your team can fix them.

WAGILE SYMPTOM 1: WE STILL SEEM TO BE THE ONLY AGILE TEAM

Agile has the power to grow from the bottom up. If that doesn’t happen, you and your team might find yourselves as the only
ones being Agile while the rest of the organization sticks to waterfall processes and mindsets. This layers waterfall thinking and
processes on your team when interfacing with the broader organization.

Signs

• Management still wants a single project manager to be accountable

• Your team works in small, incremental timeboxes and delivers in large, infrequent releases

• You and your team have little to no direct interaction with the customer

These signs show themselves when Agile is implemented on the team level but the organization’s transition to
Agile is lagging behind (or non-existent). There are a few things you can do to change this.

Fix 1: Show that Agile is working

Aspire to be the change you want to see in the organization. Set good metrics for your team, track to them and
make sure you broadcast the positive results as broadly as possible—through corporate newsletters, management
briefings, communities of interest meetings, progress meetings and, of course, the big information radiators in and
around your team area. As you share these victories, don’t focus on points, velocities or backlogs; focus on the
value that was quickly delivered. (And side note: It’s even better if you can have your project sponsor share these
victories for you.) Over time, the value of your team will become plenty clear, inspiring others to make the switch to
Agile.

Fix 2: Expand informally and incrementally

As a team, your formal influence in the organization might be limited, but never underestimate how much you
can do informally. Work out an as-Agile-as-possible cooperation model with other teams in the organization—
ask a fresh person from finance if you can get creative with the ancient funding system or ask people from the
acquisition team if there are contracts in place to enable incremental delivery of systems. You’ll be surprised at
how many informal opportunities are available—and will serve as proof points for how Agile can deliver value faster.

Fix 3: Gradually expand your Agile team(s)

Take on larger and perhaps multiple products to include more people in your Agile team. If your span of control
gets too large, simply split into multiple teams and implement a lightweight Agile scaling framework. This approach
will give all team members a chance to practice Agile, and you will become a positive example for the rest of the
organization. Eventually, and only once the majority of your team has converted, build accountability into the
structure. This will help people follow the process, particularly those who may be resistant to change.
390075-20

Guide: Navigating between waterfall and Agile

 WAGILE SYMPTOM 2: OUR PROCESS IS STUCK

Every methodology that’s not nurtured and re-aligned every once in a while will suffer from entropy. The same is true for
your Agile practices. Here’s how you can tell if your Agile process is stuck.

Signs

• Your standups turned into progress meetings

• You and your team fail to improve on identified issues

• Retrospectives focus only on the product and not the team

These signs usually indicate that your team considers the Agile transformation “done”—that all techniques
and frameworks are implemented and it’s time to go to work. This is arguably the fastest way to put your Agile
transformation to sleep, as embracing continuous improvement will be vital to your success over-time.

This is also a signal that you’re slipping back to waterfall. This is normal and should be expected. People are
creatures of habit. Before the complete buy-in and/or when stress levels rise, people revert to what they know,
even when they know the old way wasn’t the best way. The waterfall-Agile hybrid is a trap.

Fix 1: Determine what level of Agile you actually need

Various factors, such as whether your product is physical or digital, the stage your company finds itself in and the
characteristics of your team, determine the level of Agile that is actually feasible. There are great frameworks that
help you tailor your Agile. For example, not all teams are comfortable being included in the evaluation process of
their peers. Find your appropriate level and don’t try to exceed it.

Fix 2: Make people, processes and product part of your retrospective

Even when an effective process like scrum is implemented, it needs to evolve and adapt over-time to stay
effective for the team(s). Teams often fall into the trap of only evaluating their product during retrospectives,
forgetting the process and personnel concerns. Make sure you include all three Ps (people, process, product) in
your retrospectives. Create improvement actions that can be executed in the next iteration and, in the following
retrospective, remember to verify that those actions were taken.

Fix 3: Create actionable metrics to assess changes

Next to coming up with changes to the process, you’ll also find it important to see if they have the desired effect.
Do these changes actually improve the wellbeing of the team? When setting action items to improve your Agile
processes, you can make the results tangible by tracking the right metrics.
390075-20

Guide: Navigating between waterfall and Agile

 WAGILE SYMPTOM 3: MANAGEMENT ISN’T ON BOARD

With customers, legislators, supply-chain partners and other stakeholders demanding attention, there’s a
possibility that Agile is not the top priority for management. Performing as an Agile team in an environment where
Agile is not actively supported by management can be difficult.

Signs

• Budget for structural improvements and/or training is minimal or doesn’t exist

• Decision-making power remains at the top instead of within the teams

• The iron triangle (good, fast and cheap) are still the only metrics used

Priorities exist for a reason; organizations need to focus on big-impact initiatives. That’s exactly why
Agile needs to climb the ranks. Your organization wants value delivered faster, and Agile can help. Here
are a few ways to champion the impact Agile can have.

Fix 1: Sell the concept to the business sponsors

IT supports the business. The business wants to provide requirements and walk away for six months
to a year, and then expects everything to be delivered perfectly. With waterfall, after numerous
delays, phase one is delivered and underwhelms the business. The promise of phase two never even
gets started. The business gets frustrated and loses faith in IT, which gives IT a bad reputation. If you
can convince the business to increase their participation in exchange for faster and more complete
deliveries, they can then convince IT leadership to take a chance on Agile.

Fix 2: Get outside help

Whether logical or not, for some reason, the promise of Agile just sticks better when it comes from an
outsider. When conveying the message, you might want to consider hiring an outside contractor to
run a seminar or just provide management consultancy to the C-level.

Fix 3: Raise awareness and educate management

Although management is becoming more and more aware that they need Agile in
their organization for the sake of competitive survival, you may find yourself in an
organization where Agile is not yet a top priority for management. Education is key
in this situation. Raise awareness on the benefits of Agile by offering to pilot a small
project using Agile. Set goals based on the value of early releases and early feedback.

The benefits of Agile don’t live in a wagile world. Now that you know how to spot the
top symptoms of wagile and have a few tools for how to address them, take action. It’s
a matter of organizational survival.

390075-20

Guide: Navigating between waterfall and Agile

 Section 3: Agile transformation: What to do, and what NOT to do

Change is hard. There is no denying that an Agile transition is a major change, and subsequently, hard. In fact, there has never
been an easy Agile transition. Every Agile transition that has ever taken place has led to a dip in performance, and every future
Agile transition will lead to a dip in performance. We know this because transitions have been studied for years. Transitions over
time can be visually represented, like this:

A common pitfall of inexperienced IT professionals is assuming everything will slowly improve over time, or that combining
Agile with the waterfall methodology to create a hybrid will give you the best of both worlds. This seductive illusion is known
as wagile.

To help you in your transition to Agile, we’ve put together a list of ten dos and don’ts. To succeed in any transition, you need to
let go of the old ways of doing things first, so let’s start with a “don’t.”

TIP #1: DON’T START WITH TRAINING

A common pitfall to many Agile transformations is when not unlimited, it’s important to get the most out of yours
leaders send development teams to Agile training prior by providing your team training only after you’ve received
to beginning their transition. While training on a new their buy-in to the transition.
methodology is intuitive and responsible, providing training
Once you’ve reached that point, invest in upskilling the
before they’re really ready causes multiple problems. You
entire team. Even if many of them are familiar with Agile,
risk the potential of a resistant team member derailing the
make formal training a team-wide priority. It will align
upskilling efforts and demotivating the entire team. It’s also
your team on terms and processes—which improves
likely that your team will retain very little of the training
communication and decreases weaponization—and serves
because they don’t have enough buy-in or context. In fact,
as the foundation for a successful transition.
we estimate that only 5-15% of the training will be retained,
at best, if provided too early. Because time and budgets are
390075-20

Guide: Navigating between waterfall and Agile

 TIP #2: DO START WITH WHY

The most critical step to any successful transition is understanding why

the change is needed. Each individual needs to understand the benefits
Agile offers and what’s personally in it for them. This broad communication
should come from leadership and set clear expectations and benefits. If you
apply Agile to the wrong situation, the result is confusion and resistance.
You may even have someone dig their heels into the ground on a future,
proper, transition. When applied correctly, Agile offers teams the ability
to deliver and obtain customer feedback faster, while providing those
customers partial value right away. Compare that to a waterfall project,
where customers wait months and years to receive value—and where the
delivery often doesn’t meet the customers’ ever-changing needs. Another
reason to consider transitioning to Agile is that many businesses can simply
no longer survive by doing things the old (slow) way.

TIP #3: DON’T IGNORE OR ALLOW

NEGATIVE BEHAVIOR

As with any large change, your Agile transition will be met with its fair
share of resistance. Some people resist for the right reason: they don’t
understand how the change will help and believe things should remain as
they are for the success of the organization. Others will resist because they
don’t want to make the effort of learning something new, don’t want to risk
failing, don’t want to lose their “expert” status, are afraid of the unknown or
a thousand other reasons. It’s your responsibility as the leader to manage
resistance to change. Be aware of defiant behavior and address it promptly.
It has the ability to spread quickly, especially when the individual curbing
your efforts is one of the “best” people on the team and a person others
look up to. If it comes down to it, you may even need to part ways with some
of your best people if they can’t commit to Agile.

TIP #4: DO HELP YOUR TEAM TRANSITION

Fortunately, most people want to succeed and only require guidance in

their journey to the new Agile reality. The important thing here is to actively
listen to their concerns. This cannot occur if leaders are always bouncing
between meetings; availability and approachability are key. As the Agile
transition leader, it’s up to you to create an environment with enough trust
and opportunity for people to open up about their concerns and difficulties.
You need to have a good understanding of the informal organization and
empathetic leaders alongside you to guide the transition. Address concerns
by looking for win-win scenarios, but…
390075-20

Guide: Navigating between waterfall and Agile

 TIP #5: DON’T GO BACKWARDS… EVER
There comes a time in every Agile transition where the
resolve of the organization to transition to Agile is tested.
Sure, it’s easy to delegate decision-making authority when
there is ample budget available and the products are doing
well. But what happens if things become less utopian?
When under pressure, people tend to revert to what they
are used to, which unfortunately is often still command and
control style management. When a project or program gets
into trouble, resist the urge to “take back control.” It can set
back the Agile transition multiple iterations and shatter the
perception of management’s commitment to making the
transition work, thus deflating the transition’s
biggest supporters.
TIP #6: DO SLOW DOWN
When programs and projects struggle, trust the process
and exploit the continuous improvement mechanisms of
Agile frameworks to learn about what isn’t working and
make things better for the next iteration. Instead of taking
control of the project, leaders in the organization should
stick to the process and make sure all of the prerequisites
like trust, rich communication, and actual time and budget
for continuous improvement are in place. This might cut
into the effective execution time, but it’s critical for the
long-term survival of your Agile transition.
TIP #7: DON’T THINK YOU’RE SPECIAL
We have yet to meet an organization that starts an
Agile transition on the basis that they are standard and
straightforward. Every company is different and has unique
people and processes, which is a good thing! When looking
at Agile transitions, you should consider that supporting
frameworks take this into account—even out of the box.
Instead of tailoring your frameworks before your transition
has even started, start out of the box and then use the
continuous improvement mechanisms of your framework
to start tailoring your Agile implementation to your unique
environment.
TIP #8: DO GO ALL-IN
During your Agile journey, you’ll likely face many situations
where you’ll need to make compromises. Perhaps your
vendors don’t have their processes aligned to an Agile
framework and you need to accommodate their waterfall
delivery methods. Or perhaps there are legal limits to the
amount of decision-making power you can distribute to the
teams. If the level of ambition of your Agile transition starts
off low, the end result will be even lower. Start as ambitious
as possible; subtleties and tradeoffs can be made later.
TIPS #9 AND #10: ENTER AND EXIT
WAGILE QUICKLY
In your Agile transition, you’re bound to experience a state
of wagile. Don’t be naïve and think you can avoid it, but
do try to escape it as quickly as possible. Being stuck in
a perpetual state of wagile, where a team never fully lets
go of the waterfall methodology, leads to the worst of
both worlds. While you’re in wagile, resistors will say Agile
is failing. Supporters will get frustrated and eventually
leave. However, the truth is that Agile hasn’t been fully
implemented. Follow the advice above to quickly exit the
dreaded state of wagile and you will find yourself being
Agile and providing value to your organization like
never before.

Leading an Agile transition may be one of the most difficult but necessary tasks you take on to help your organization thrive
in today’s environment. Now that you know the top dos and don’ts, the pitfalls of wagile and how to avoid them, and how to
choose the right methodology for your project, you’re ready to build your plan, put it into action and weather the wagile and
adoption phases.

Need help avoiding the wagile trap?

Give your team the Agile skills they need: pluralsight.com/skills
390075-20

Guide: Navigating between waterfall and Agile