Waterfall Project Management: Don’t Go Chasing Waterfalls in an Agile World

April 4, 2018

Waterfall Product Management is as old as the hills, and as the old adage goes, “if you fail to plan, you plan to fail.” A phrase that is becoming exceedingly relevant in the IT world. There are various methodologies to approach planning and execution, each with their own rewards and challenges.

The question becomes, which methodology is the best one? Many are familiar with the the Waterfall methodology, and a large number of organizations still use it as their primary project management approach.

In essence, this methodology completes all phases from requirement gathering and analysis, implementation, system design, testing, deployment to maintenance in a sequential manner. While this seems like a very practical approach to tackling the issues at hand, this method can result in more issues that it initially sought to address.

For instance:

#1 The Waterfall Product Management approach is seen as obsolete nowadays

With the exception of exceedingly simple projects, Waterfall often fails in practice because it is impossible for the entirety of small, less important features of a software product to be tested and perfected before moving on to the next phase while learning from those mistakes. This creates a reliance on each phase being 100% perfect before moving on, a process that is a difficult to achieve consistently, slowing the time to market.

#2 It’s difficult to to make changes once the Waterfall process stops

The Waterfall methodology is effective with little to no client interaction or feedback. In this case, the client has to state precisely what his or her requirements are prior to the launch of the Waterfall, because it is virtually impossible to stop once the process has begun.

However, if the client decides to change an aspect of the deliverable during the course of the project, significant delays can occur, reducing overall client satisfaction and taking time away from other important projects.

#3 The Waterfall Methodology creates the illusion that the design can easily turn into the final product

Leaving the design phase and moving into the production phase of the product lifecycle typically involves unveiling an initial prototype of the product itself. In many cases, the design of the product looks very feasible and cost effective on paper.

It is not until the developer moves into the implementation phase that inherent and inevitable issues begin to spring up. As issues begin to arise and compound, re-designs are needed, completely destroying the distinction between traditional Waterfall phases.

In reaction to these inherent failings of Waterfall project management, there have been several modifications to the underlying methodology. While these modifications have not entirely addressed all prominent issues, updates have introduced overlapping phases (meaning that you do not need to entirely complete one phase before entering into another phase).

In the event that the client has clear and concrete requirements and your team is confident that they can deliver the project to those exact specifications, Waterfall can be a convenient methodology. If not, Waterfall project management will almost certainly do more harm than good.

Solution

As a direct response to the intrinsic failings of Waterfall, Agile methodologies have become the new favorite for software developers. In this model, an idea is translated into usable software by a process that develops through the stages of initiation, analysis, implementation, testing and maintenance.

When compared to Waterfall, Agile is a much more iterative and incremental style of project management. The only challenge in implementing an Agile approach is that it is requires fundamental changes to traditional project management strategies.

Making the switch from Waterfall to Agile can be a difficult proposition for many organizations, as project teams have gotten used to the status quo and are often resistant to changing their tried and true methodologies.

As a direct response to this challenge, a new approach has surfaced called “hybrid,” which ensures a robust end-product by picking the pros of both Agile and Waterfall models, without completely overturning either method.

Before going into the hybrid approach let’s breakdown both the Waterfall and agile methodology.

Waterfall Product Management

The Waterfall model is an approach for developing software that breaks a project into definite phases. Requirements are analyzed and understood, leading to a defined design stage, after which coding and production begins, before finally commencing the testing and implementation phases.

Advantages include:

1. Simplicity and structure
2. Each phase has defined deliverables
3. It’s perfect for projects in which requirements are well understood

Disadvantages include:

1. Not suitable for projects where requirements are at a risk of changing
2. No working software is created until much later in the phase
3. It falls short on projects that are highly complex

Agile

The agile model is best described as a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

Advantages include:

1. Client involvement is maximized
2. Continuous improvement through each cycle
3. Late changes can be accommodated without compromising the project

Disadvantages include:

1. The team needs to leverage all of its skillsets
2. Lack of emphasis on design and documentation

Now that pros and cons of both methodologies are understood, we can talk about the hybrid model:

Hybrid (Water-Agile-Fall)

The entire purpose of the hybrid model is to leverage both Waterfall and Agile advantages and approaches to ensure the success of the project.

Advantages include:

1. The combination of both methodologies
2. High level design is done using Waterfall principles
3. Coding and testing are both done using agile principles

The Hybrid model is essentially seen as the ‘best of both worlds,’ as this model uses the advantages of both Waterfall and Agile. Prior to deciding on the hybrid model, it is important to conduct extensive planning and ensure that your team is prepared to implement the necessary changes.

Factors like: budgeting, time, resources, project type, and complexity of requirements must be taken into consideration.

The Hybrid model is still in the fledgling stage and its progress will continue to be refined as more companies adopt this methodology.