Skip to main content

Why waterfall development may still suit your organization

code
(Image credit: Image Credit: Christina Morillo / Pexels)

There are many efficient software development approaches around these days – why should you opt for waterfalling a project? There are several compelling reasons for that.

By choosing a software development methodology, you pick the easiest route to success. I’ve heard about numerous software projects that failed in their purpose, hampered by a wrong choice of a development approach. When you make a choice, focus on project specifics, not the popularity of one or another method, to ensure the desired outcome.

The methods of managing projects of different scales and across multiple industries differ as per the complexity, goal setting, time range, and initial requirements. Waterfall is in play today when it comes to small projects with accurately defined stages and development toolsets.

Without a strategy that relies on exact, predictable principles, success can be difficult or even impossible. In this article, I give the pros and cons of using Waterfall and explain why this methodology may still work best for you.

Linearity as the great feature of Waterfall  

Waterfall is quite straightforward and has been around since it was first applied to software development in 1970. It sees software creation more traditionally. You would take the same approach to build something: first, complete task A, then B, and on.

Being a linear model, Waterfall involves well-thought-out successive phases. A development team works over a specific SLDC activity per phase, such as gathering requirements, designing, coding, and other tasks. Developers need to deal with one activity before moving on to the next phase – overlaps are avoided.

I’d consider linearity an advantage of Waterfall. That has triggered a discussion between me and my coworker Martín Mateos, senior QA engineer and developer who has many projects behind him, 99 percent of which used Waterfall.

He was describing to me a new small project where they tried to implement Agile. As a result, their team faced the overhead of meetings and ceremonies that added up to the small budget of billable hours, leaving the team less time for actual work.

If they used the waterfall methodology instead, there would be fewer meetings and more time for diligent task completion. That is not the only reason for picking Waterfall out of the pull of widespread methodologies.

Discovering advantages of the Waterfall methodology 

The model fits well within the business goals of small and mid-size organizations and provides a range of benefits within product or solution development projects: 

  • Short-term activities that involve predefined stages  
  • Clear development requirements that face little to no changes 
  • A sustainable project environment 
  • A static set of technology and tools 
  • A well-trained team of software engineers  
  • Ready-to-use products or solutions delivered to clients 

I worked for a software development firm building IVR (Interactive Voice Response) programs where the projects were basically quite similar. Waterfall made it excellent since our project involved well-written documentation, and the scope was not bound to change much during the development process. Besides, it was easy to move employees around projects to start production as swiftly as possible. 

When Waterfall takes a wrong turn  

In a waterfall software development project, clients might have no hands-on experience up to the release of the first version, which happens as soon as the design, development, IST (integrated systems testing), and QA phases are completed. Clients receive progress reports on the work done but have to wait a couple of months to see an actual result.

While discussing popular project management approaches with Martín, I learned insights into waterfall drawbacks. The project he is on currently involves such stages as backend, database, chatbot, and webpage. Their team began with analysis and design, as any project needs that, and planned to move step-by-step, having the backend as the starting point.  

But the client preferred using the agile methodology, and besides, was not quite tech-savvy. For the first three Scrum meetings, the team demonstrated things the client didn't understand. They had to shift from explaining the backend to discussing the chatbot and webpage design, colors, and fonts choice, while what's under the hood was of the least importance for the client. 

For some projects, especially if you have to make demonstrations for a client, you can't use the waterfall model. It would be much better to prepare something to show at the end of each iteration and make the work more appealing to the client.

Taming ever-changing projects 

When everything is changing rapidly on a project, and clients demand an overview of the results at the earliest phases, using a lean or agile-driven approach might be your choice.

Agile software development

For me, Agile resembles a living entity. It requires a specific iterative approach that allows more autonomy in the development workflows and relies on efficient cooperation within a team. It may encompass Scrum, Kanban, or other ad hoc adaptations as per an organization’s philosophy.

Unlike Waterfall, an agile software development life cycle demands self-organization from each team member. Once formed, team members should remain the same throughout a project. Their learning curve is steep, and project documentation and scope are flexible and may change continuously. 

Agile-driven software development teams would focus on customers’ involvement and decision-making from the very first iteration that normally takes one or two weeks. After each iteration, a customer gets some functionality and can perform user acceptance testing.

Lean for software projects

The lean methodology originates from lean manufacturing, and it’s all about using resources wisely. My experience shows that the concept of resource-wise development focuses on more learning, less resource waste, postponed decision-making, and expedited delivery. 

Lean software development teams strive to cut out everything that doesn’t add value to a project, like unnecessary meetings, documentation, or inefficient multitasking. According to HBR, this approach might be game-changing for small and mid-size organizations seeking alternatives for growth. Lean management allows business owners to launch customer-centric products quickly and make the launch cheaper and less risky than traditional business development approaches.

Lean may be a perfect choice if you need to modernize or upgrade processes within your organization. On the other hand, Agile may help you efficiently manage teams of up to a dozen employees.

 Is Waterfall live or is it dead? 

Many projects still need Waterfall. Agile and other methodologies make no sense for small projects when the nuances of changes are minimal. 

Your project or organization may be less prone to changes and have well-developed documentation and strategy, or you may plan to move team members across project tasks or departments. If so, Waterfall may become the right option to help achieve reliable, predictable results.

Keep in mind that if you go Waterfall, changing the scope of a project is a bad idea, or you might lose work already done. For the same reason, you need to verify project requirements carefully before a project starts. 

It might be challenging to measure progress on a waterfall project. You may have no working software to show to a client until the end or close to the end of a project. You may have 70 percent of a project completed, but for your client, it would look like you haven't even started.

I would recommend involving professional QA engineers in your team from the beginning of a waterfall project. That would help drastically decrease the chances of having critical bugs. Using a linear methodology that excludes testing for each iteration, developers may catch bugs at very late stages when it might be hard to fix them.

Leo Prada, Technical Project Manager, Solvd

Leo Prada is a Technical Project Manager at Solvd, Inc., Argentine department. He is passionate about leading distributed teams and has vast team management experience across 10 different time zones. An avid traveler, he has spent many winters in the backwoods of Maine and some in Croatia, reclaiming his inspiration to work productively.