Waterfall or Agile? What are they? Which is better? We’ve seen a lot of questions and debates on this topic, and personally don’t believe there is a one size fits all answer.
First, let’s examine them. Waterfall and Agile are two software development methodologies. Each outlines a process for the software development lifecycle.
Waterfall is a traditional step based approach. Steps typically would look like this:
- Gather Requirements
- Write Code
- Address Issues
- Deliver Final Product
Waterfall’s strengths lie in having a clearly defined goal with a specified endpoint deliverable. It’s easy to manage as each stage is completed, the next stage picks right up. Having fully defined requirements and an agreed upon vision at the start can typically allow the project to move through each stage easily, allowing projects to stay on strict timelines and budgets to meet goals.
But what if priorities change during the middle of the process? What if after seeing the final project, it doesn’t meet expectations? These are the potential downsides of a Waterfall approach, and the reason a new approach – the Agile method, was developed. And yes, that is the new methodology on that very old looking website!
Agile is an iterative approach to development. Instead of building the project all at once, a project is broken into phases, and each phase would include steps similar to Waterfall: gathering requirements, development, testing and review. Agile allows for more flexibility with more frequent reviews, and re-prioritization at each stage. It embraces change and collaboration.
Because Agile relies on constant reviews and feedback, it’s imperative to have frequent communication throughout the process. Scrum is one of the most popular frameworks for implementing an Agile methodology. Scrum includes three roles:
- Product Owner: Business decision maker, communicates needs and wants
- Scrum Master: Facilitates team’s work, communicates between product owner and team
- Team Members: Build the product (around 3-10 people – designers, developers, etc)
Each phase is typically two weeks, and referred to as a “sprint”. The scrum master and team meet daily to review status, and address any obstacles. At the end of the “sprint”, the scrum master and product owner review the deliverable from that phase and plan the next phase.
While Agile solves for changing requirements and quick iterative deliverables, it’s flexibility can have downsides. With constant re-prioritization and shifting goals, projects can often run over budget or over time. It requires a business owner to have enough time and desire to be completely hands on, to review and approve of every stage. It’s also possible with constant iteration that pieces built in later stages may not fully align with pieces from previous stages in terms of look and functionality.
Which should I use?
To answer – which is better? Well, both are applicable depending on the situation. If you want to know – “which should I use” – then you first need to inspect the project timeline and pick which methodology makes sense in the situation.
If your project has a strict timeline and budget, if it is small to medium in size, if you don’t expect the goals to shift along the way – a Waterfall approach should work for you. If you have a very large project where goals will naturally shift during a longer timeframe, flexibility in budget and timelines, and want to be fully hands on, Agile may be better.
At Brunch, we typically follow a Waterfall approach for our client projects. We strive to deliver projects on time, within budget, and to exceed expectations. Understanding it’s potential drawbacks, we take care to alleviate any possible issues that can arise. We work closely to understand and gather requirements at the start. Instead of static design files, we build interactive prototypes to more clearly visualize the final product. We are a nimble team of designers and developers that work quickly and efficiently, but our internal collaborative strength allows us to respond to and handle changes with stride.
The most important factors with either methodology are clear communication and shared goals. This is exactly why we look to partner with folks we want to go to brunch with. I wish you best of luck with your next Waterfall or Agile project!