A quick overview on Waterfall and Agile project management approaches. What makes them different and what will work best for you.

A duotoned dark purple and beige version of the Apple question mark emoji, in front of a green circle background

To save you a Google search on project management approaches, here’s a summary that you may find helpful. There’s more than just Agile and Waterfall, but I’m highlighting these as they’re the most common in digital project management (and the ones that I can attest to).

Waterfall aka traditional 🏞

  • Pre-defined scope at the beginning of the project
  • Each stage happens in sequential order
  • Structured and well documented

Pros and cons

Well documented and structured approachInflexible and less adaptable to change
Easy to understand timings, and determining a project schedule (who/when people need to be assigned)Less client involvement throughout
Useful approach for a fixed price or scoped projectScoping and design often done when we know the least about the project
Client knows exactly what they’re getting for their moneyHarder to justify the request for more money. As you may often find that once more features have been built, decisions made earlier on in the project will need to be reworked. Which leads to a murky discussion of who wears that cost
Good approach if you’ve solved the same technology decisions before, and therefore don’t need to spend time experimenting and/or upskilling

The waterfall model is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to a specialisation of tasks. 


Useful reading

Agile 🔀

  • Iterative and collaborative approach
  • Multiple releases, releasing early and often
  • Each stage is designed, developed and tested before moving on to the next

Pros and cons

Allows for greater client engagement throughout each phase of the projectHard to budget and scope at the beginning of a project
You don’t waste time/money at the start of the project documenting or designing something that can’t be realised in developmentHard for clients to see value for money and understand what sort of end cost they’re looking at
Allows for continuous and iterative developmentTechnical debt can more easily accumulate
Flexible and adaptable to change in scope and requirementsDecreased quality in the end product when priorities misalign
Features a more accurately costed and monetary risk is shared

One thing that separates Agile from other approaches to software development is the focus on the people doing the work and how they work together. Solutions evolve through collaboration between self-organizing cross-functional teams utilizing the appropriate practices for their context.

Agile Alliance

Useful reading


As I’d mentioned in this post, no matter the approach you take you need to remain flexible and adaptable in order for it to work for you. A rigid approach may work in one setting, but another it might completely fail. My tip is to always ask yourself these questions along the way:

  • Is this approach working for this particular project?
  • Am I getting the most out of my team with this approach?
  • Are we making things easier or harder for ourselves and/or the client?
  • Is this approach costing us time and therefore money?

What approach do you prefer? I’m keen to hear from others, in the digital space but also in other industries. Leave a comment below, I’d love to hear from you! 💞