Waterfall vs Agile: Is It Still Worth Asking?

By Scott Harper

Previously we have talked about MVB (Minimum Viable Bureaucracy) — A practical approach to scaling agile project management.

We wanted to follow this great post up by revisiting the point-of-view of our founder and CEO, Scott Harper, on agile vs waterfall when it comes to creating software and hardware products with four scenarios our teams have experienced.

Scenario One: Creating the right hardware prototype

For a recent hardware project our team and the client shifted the goal / deliverables at least three times during a five week timeline, and having an agile workflow allowed for this. At each iteration of the prototype the hardware team discussed the outcome with the client and pivoted to build something slightly different based on their findings. This resulted in building the best hardware prototype that met both user/client needs and technology requirements.

Scenario Two: Shifting focus to a better audience

During a client engagement we identified a better growth opportunity if their business strategy, and the platform we were building, pivoted from a B2C to B2B focus.

By developing our software in an agile process this allowed us to regularly review our priorities and work, and adapt where appropriate. Initially our focus was on solving their immediate consumer needs — online acquisition. During the project the needs changed focus to administrative / point of sale requirements for location owners that would use this platform. This generated more customers faster, with higher traffic, and got our client to more locations quicker.

The complexity of the system being built made it critical that the Dialexa design practice also had an agile approach to be hands on throughout the development of the project — rather than a one and done approach at the start of the engagement

Scenario Three: Using an agile approach to manage Support needs

For one of our clients, where we have developed a new internal platform to drive operational efficiencies for a core activity, we are operating our support efforts using an agile methodology. This means that through an active communication and prioritization framework with the client, the team can be focused on building training, features, or addressing bugs — whatever is more important at the time to ensure the platform is operating and evolving as needed.

Scenario Four: Freedom to change the program with ease

The team started their work with a plan for an agile team where the focus was on the research & design at first and then there would be a shift to development after 25% of the time has passed. What ended up happening is that the team was required to work on design for almost 75% of the planned time to address all the client’s user research and changing priorities / requirements, and the remaining 25% of the timeline was development. This change in the program ensured both the client and our team were confident that what we were building in the remaining time accurately addresses the client and user needs.

After reviewing these real-world examples — we come back to our original question:

WATERFALL VS AGILE: IS IT STILL WORTH ASKING?

In less than 15 years, agile development has grown from a little-known alternative to traditional or “waterfall” project management, into the de facto framework for managing the process of delivering software products.

Despite its rise in popularity, discussions about whether agile, waterfall, or even a blended approach was the best way to manage a new project remained common until fairly recently.

According to surveys conducted by Forrester, among others, only about 10 percent of respondents are using pure traditional development methodologies. This confirms that waterfall is drying up as agile continues to expand.

Is the “waterfall vs agile” debate still worth having, or is agile clearly the best approach under every circumstance? We thought we would take a look.

WATERFALL METHODOLOGY

In use for over four decades, waterfall methodology is a sequential development process and generally relies on the following stages:

• Conception
• Initiation
• Analysis
• Design
• Construction
• Testing
• Implementation
• Maintenance

Once each stage is successfully completed, developers move on to the next stage. Since the process is sequential, a developer can’t go back to the previous stage without having to start the entire project from the beginning. Because there is no room for error in the waterfall approach, developers must start at the beginning and carry through until they finish all of the stages.

Advantages

Despite its lack of efficiency, waterfall’s focus on sequential planning and documentation has a few potential advantages:

• Meticulous records are created and updated at each stage of the development process, making it easier for subsequent stages to understand the whole application because there is no guesswork about what was done prior. At each stage, the project is “baked” complete before the next stage starts.
• Clients and stakeholders like to know upfront what they’re getting at the end of an engagement. Because detailed documentation of requirements, specifications and project planning form the underpinnings of waterfall, they start the project with a concrete idea of the cost, scope and timeline for the entire project (though many would argue that they’re getting a false sense of security, because everything goes out the window as soon as the product’s goals or anticipated outcomes are altered).

Disadvantages

While waterfall methodology has its benefits, its inherent lack of flexibility poses a number of substantial risks.

• Because the entire project is built on the initial requirements, mistakes in requirements gathering or documentation can throw the process into disarray and cause painful rework if not found until later stages like testing and implementation.
• Bugs aren’t discovered until very late in the process because quality assurance testing comes at the end of the project. Since everything is sequential, you might reach what appears to be the end only to start the process again.
• It doesn’t accommodate the client or stakeholder’s evolving needs, making new product development a challenge when needs are not fully know and change in requirements are inevitable.

Despite the challenges, there are instances in which waterfall is appropriate, such as in cases when there is a clear picture of the final product, when clients can’t change the scope once it starts, and when certainty is a higher priority than speed or flexibility. Examples where waterfall may still be appropriate are mission critical redundant systems such as space and military systems.

AGILE METHODOLOGY

As its name suggests, agile methodology is all about flexibility. What makes this so important is that software engineering isn’t a particularly predictable or repeatable process, like building physical objects such as houses or machinery, which is what traditional project management was designed for.

Advantages

Agile’s hallmarks are a high degree of collaboration between client/stakeholder and the project team, iterative design and dividing work into small units that are tested throughout the process. Because of these structures, bugs are discovered and corrected earlier, feedback is gathered and incorporated more frequently, and — perhaps most importantly — the product can evolve organically over the entire product development process. In addition:

• Changes can be made throughout the project without significantly disrupting the process.
• The client or stakeholder can change their mind based on changes in the marketplace or other situational factors.
• Developers can respond to changes or improvements in available technology.
• Project priorities are evaluated throughout, thus reducing the risk of ending up with an irrelevant product at the end.
• Working in iterative cycles conditions the team for continuing to improve the product after its initial release.

Disadvantages

• The high degree of structure inherent to waterfall project management provides a narrow set of “guard rails” for less experienced project managers to operate within, whereas agile process can quickly devolve into “no process” when managed by someone who is new to the methodology.
• Clients or stakeholders expecting a finished product that adheres precisely to a predetermined and highly detailed set of specifications may be disappointed.
• Agile isn’t well suited for projects that require a lot of detailed documentation up front.

CONCLUSION

There are a few important reasons that we don’t hear the “waterfall vs agile” debate as much as we used to:

• For reasons mentioned above, agile simply works better for the vast majority of software development projects.
• Because it works better, the number of experienced agile practitioners is constantly increasing.
• The pace and volume of innovation continues to increase, thus reinforcing the need for a methodology that is able to tolerate change while the process is running.

Does this mean that the question of “waterfall vs agile” isn’t worth asking? Not necessarily. While it’s increasingly a forgone conclusion, there will always be edge cases that require a more structured process, and project managers would do well not to ignore the possibility that waterfall, or even an approach that combines agile and traditional project management methodologies, is the right solution.

We love agile and use it almost exclusively with our customer and internal projects.

Learn more about how Dialexa improves the software development process, including our approach to new product development processes.

Originally published at https://by.dialexa.com/waterfall-vs-agile-is-it-still-worth-asking.

At Dialexa we start by asking “Do you know what your business will look like tomorrow?” Whether you have a plan, a problem or no idea, connect with us to explore the right answers for you.