A Balanced Approach: Incorporating Both Agile and Waterfall into Your UX and Product Team's Workflow

You’ve probably seen this endless debate countless times on LinkedIn or other social media websites: Is Agile better than Waterfall? Do Agile and UX fit together? Does Waterfall allow more time for research? The truth is - It’s an endless, pointless debate. It’s the equivalent of talking about wanting to work hard but only sticking with the part where you talk about it.

I won’t dive too deeply into each methodology in this post but I will briefly explain them and give you my take on this argument.

When it comes to software development, there are two primary methodologies: Agile and Waterfall. These methodologies differ in their approach to project management and can significantly impact the outcomes of UX and product teams. Both have their strengths and weaknesses. In my experience, product teams that combine both tend to perform best.

Waterfall

Waterfall methodology is a linear, sequential approach that moves through the project phases in steps. In this approach, the product team completes each stage before the next one can begin. The advantage of this approach is that it is suitable for long-term projects, and it gives the design and research team a head start before committing more resources. You can think of it as the design and research team playing the role of vanguards or scouts, outlining a path forward. The bad news is design teams can end up so far ahead of the development team that both teams end up disconnected.

Agile

Agile methodology, on the other hand, is a flexible, iterative approach that focuses on delivering small, working increments of the product in short cycles, typically two to four weeks. This approach is best for projects or features that are cheaper to pour resources on or already have a clear path forward. Agile is particularly useful if you want to develop a feature but are uncertain if it’s worth going all-in. It allows you to get your feet wet before diving in. It also allows the design team to iterate on designs that they previously delivered via the Waterfall methodology. The idea behind Agile is to work in small/incremental cycles. The design and research team should be able to validate and test assumptions and make necessary changes. In reality? Product and development teams end up duct-taping their product together at the seams while BSing the board of directors that they have a clear plan and roadmap as they leave user research on the sidelines.

Both approaches have strengths and weaknesses. A product team using both methodologies can benefit from their strengths and mitigate their weaknesses. The Waterfall methodology provides a solid foundation for the project by setting up a long-term path, while the Agile methodology allows the team to iterate and make adjustments as needed. The product team works on setting up a long-term path while also iterating on the stepping stones along the way to make the flow easier to navigate for both the users and the development team.

A pet peeve I want to address is that research should always play a vital role regardless of long work/sprint cycles are. If you fail to allocate resources towards user research, neither Agile, Lean, nor Waterfall methodologies can help you. Skipping the research phase is the equivalent of taking a shot in the dark and hoping you hit the target. The design team needs to conduct research and testing at all stages to ensure they’re moving in the right direction and meeting their users’ needs.

It’s essential to ensure that both approaches don’t lead to silos. Both methodologies should involve collaboration and working together across teams. Design and research team members should be involved in every stage of the project to ensure that they’re contributing their expertise, and developers should be involved in the early stages of the project to ensure that their feedback plays a role in informing the design process.

Final Thoughts

In short, I believe Agile and Waterfall aren’t at odds but are two methods that synergize and complement one another. They’re also not novel ideas or divine words you cannot deviate from. Agile and Waterfall both work, but you need to understand why and when to choose one over another.

In either work methodology, you’re asking: How full of a picture do I need to create solution X?

I’d argue that it’s not about choosing either Agile or Waterfall.

The Waterfall and Agile methodologies have their respective strengths and weaknesses, and the choice between the two depends on the nature of the project. Both approaches can work together effectively if product teams utilize both to their advantage.

The most critical factor in project success is a continuous research and testing process to ensure that the design and product meet the user’s needs. Collaboration and working together across teams should be key components of any approach. Collaboration helps break silos and keeps the information about progress, status, and findings accessible.

As a side note: Breaking silos doesn’t mean a product manager can assume the role of a UX specialist, or that a UX specialist that knows how to develop can assume the role of a developer.

The method you choose to adhere to doesn’t matter. What matters is that your teams are working collaboratively and testing and validating designs while considering both long and short-term impacts. If you can confidently say your research indicates you are creating a solution to a real problem, then you know you aren’t wasting your resources.