TL;DR: Deciding on Agile vs Waterfall calls for an understanding of each methodology and their differences. While Agile focuses on customer satisfaction to distribute work in a flexible manner, Waterfall provides a sequence that always works in phases for a go-live. Deciding on either calls for an in-depth consideration of a particular project and a company’s culture and needs.

The excess information to which we are constantly exposed makes it common for people to read and repeat concepts without full clarity on where terms come from, or if their definition is entirely correct. To clear up any confusion between Agile vs Waterfall, we won’t just give a comparison and contrast. We’ll also go into examples and suggestions as to which priorities to focus on when deciding for either. Jump into this side-by-side comparison based on my experience as a full stack developer in the banking and fintech sectors. I hope doing so will help you make up your mind about the most suitable methodology for your needs. 

The actual comparison between Agile vs Waterfall

Straight off the bat, I need to clarify that neither Agile nor Waterfall is better than the other. Instead, each methodology carries out different types of projects. 

In a nutshell:

  • Agile’s always focused on customer satisfaction. It seeks to flexibly distribute work across different areas of a project. The idea is to work faster based on deliverables. 
  • Waterfall’s a traditional form of project development that follows a sequence and always works in phases for a go-live.

One of the most important differences between the two is the focus on quality control and testing. 

In Waterfall, the testing phase comes after the build phase; but in Agile, testing takes place at each iteration or deliverable.

Agile leverages different frameworks

Any institution can commonly take a specific framework and adapt it to their own needs. 

We know you may be wondering about Kanban, Scrum, DevOps and others. Those are all amongst the different frameworks Agile can leverage. There’s DevSecOps to think about, as well. The name stands for Development, Security, and Operations all into one. 

Each framework that Agile leverages provides diverse tools. And they should all be taken into account before setting project deliverables. Doing so can enhance deliveries of great value. 

Teams working with Scrum can work with aspects of the DevOps framework, for example. DevOps and Scrum can merge in cases of automated build implementation, test automation, continuous integration (CI), and continuous delivery (CD), to name a few. 

The reason for that is that these tools were often already used in systems management. They were also a part of configuration management, statistics, virtualization, and monitoring. 

Working for a large bank in Colombia, we once had to adapt to both Scrum as much as Agile. We were technologically already working under Scrum. Yet, the operations side, everyone in the bank’s core in terms of Customer Service and related departments, was more about processes. So, transporting Scrum over would have overcomplicated workflows. 

On top of that, there really wasn’t a need for improvement every sprint. We ended up working under a mix between Waterfall and Scrum. And that’s how the bank came up with its own specific framework.

Cases like the above happen because the choice of a given methodology or framework depends on the nature of a project, not so much the type of business. 

In this banking scenario, Waterfall might be easier to adapt to give support to clients in very specific timeframes. Yet, Agile is now of very common use. 

Agile vs Waterfall: Advantages and disadvantages

An advantage Waterfall offers is that it allows clients to know what to expect from the very beginning. Results will be concrete.

Among its disadvantages, however, is a lack of flexibility whereby a change cannot be applied until the product is live. It’s difficult to make changes in Waterfall once we’re ready to close the requirements phase. Those could have a high impact on the cost of the project and a lack of immediacy in the response. 

Agile’s a little more flexible. It adapts to clients’ needs by defining a goal on which customers give constant feedback. 

A disadvantage to Agile, though, is that the final result can be completely different from the initial plan. Ironically, some projects won’t be agile at all under this methodology. Agile can get tricky! Even though the name sounds and seems to point to an agile process, the nomenclature can fall short of its linguistic promise. 

We need to be careful. Sometimes, intending to be more agile, we end up being less so. 

So, which methodology should I use for a project?

To decide between Agile vs Waterfall, consider variables such as project size, duration, complexity, customers or stakeholders, and company culture. 

Deciding on the right methodology for each case is simply not an easy task, so this question always comes up. 

To choose, remember each project has its own characteristics and requires different ways to manage and execute it. 

A project with a certain scope, time and a fixed budget can easily thrive using Waterfall. The same applies to a project with an absent customer.  

If, on the contrary, a project closely involves a customer and has the option of getting feedback and making constant changes to its requirements, Agile might be a more effective solution. 

More importantly, working according to a certain framework also calls for a shift in culture. Methodology choices aren’t just about their use; people’s mentalities also need to re-adapt. And those take time. 

When the time comes for implementation under any of these structures, it’s as if we needed to take in an entirely new chip in our brains. Certain elements just need to be handled a certain way. 

Woman facing whiteboard with tasks on Agile testing

Ideas on ways to migrate

So, here are a few ideas on how to go through migration processes, too. First, consider how hard sensible reactions are to foresee. It’s possible a company’s set of owners, founders or leaders, even clients, are new to these methods. And their ability to adapt can impact necessary transformations. Some people might not be capable of moving out of their comfort zones so easily. 

Set out about a year. This should be a good point of departure to reach the expected maturity of these processes. 

Another recommendation would be to create diverse teams to allow that maturity to happen. Grouping teams with less experience can give everyone time to adapt. More mature teams can work at their possible quick speed on very specific high-end tasks while also training and helping spread the new culture over to their newer peers. 

Establishing diverse value deliverables can help this adoption plan setup, too. Each iteration can then help measure the maturity of each team. This is where methodology guardians, such as scrum masters, can help with the best strategies that can strengthen that knowledge and workflow. 

The key question for everyone to be asking is: “What’s my role within the team?” “What do I have to offer?”

Beyond any applicable rules or whatever’s set in stone, making this decision can be more about the general culture that a certain methodology requires. Sometimes we focus on completing processes by the book and forget about something as simple as enjoying the work that comes along with that precise methodology. 

Recommendations on sprint prep

Whenever it’s time to plan a sprint, it’s also useful to ask ourselves whether we can truly use that precise methodology in servicing clients, for example. 

Projects with no deliverables (one where constant deliverables are unnecessary) can be more time-consuming if done under an unsuitable methodology. They can actually end up costing more time and effort. 

Take regulatory processes, those having to do with financial policies and rules, as an example. Institutions must report to regulating financial entities often. And they need a fast response to those demands. Projects of that sort commonly call for an unquestionable implementation of their main goal without a need for a full deliverable value to get there. These don’t need to run within Scrum.

One of the reasons we use Scrum, however, is to deal with digital information.  

Banking as much as government institutions are commonly married to a certain tech standard, however. At some point, these organizations need to become fully agile to give added value to users. That’s when agility normally steps in as a means to transform and create landmarks. In those cases, Scrum can help with deliverables that add constant value. 

Making sure choices tend to your actual needs

On other occasions, these methodologies might end up costing more time. We could almost say it’s a sort of fashionable approach today to build everything under Agile. But the common mistake is to not consider value deliverables. 

And please don’t get me wrong; I developed myself as a full-stack engineer precisely because our teams need to be cross-functional. We need to be versed from back to front in a way we can do wide testing. 

Yet, what’s crucial in migrating to Agile is to take an organization’s culture into account, too. And teams often fail to deeply consider an organization’s culture in planning transformations to Agile.

As a DevOps engineer, I’ve been part of processes where we’ve had to insert lots of agility into our working structure. And Agile can be seen as just a framework, but it’s really more of a change in paradigm to which people might not fully subscribe. That mindset shift can slow a process down.

Structure, organize, and cut back on learning curves

Before choosing, it would help to pause and contemplate which methodology or framework will give you a quick answer in response to your needs. Maybe a project simply doesn’t need to get too complicated. At times, despite how we’re used to working, other frameworks or methodologies can be easier to implement for a given need. 

Aside from this being a matter of embracing change, it also helps us to be passionate about how we need to handle work. That can easily help teams move away from getting stuck in a certain vision.

Learn more about full-stack app and software development.