Project Management Techniques: Agile vs. Waterfall

When creating an approach to a new project, it can be difficult to decide what the best methodology might be. Both methodologies have proven track records, and work very well for different projects. What’s even more confusing is that what works for one project might not work for another...even with the same client.

As a Project Manager, one of the many hats you’ll wear is knowing enough about both your team AND your client’s needs to make an informed decision. Aside from the usual considerations on timing, budget, & scope...some of the other things you’ll need to consider include:

  • How many phases will your project have?
  • Have you worked with your team before?
  • How complicated is the overall MVP that you’re looking to deliver?
  • Does your client truly know what they want or are expecting?
  • How familiar is your client with the Software Development Life Cycle (SDLC)?
  • How urgent is it to get something tangible into the hands of stakeholders?

The answers to these questions can help you decide on the best method, but before making your choice, it’s important to understand the key characteristics of both methodologies.

Waterfall is a more traditional approach to a project, with a history of success in construction and manufacturing projects. In essence the “waterfall” refers to the cascading appearance of the project’s timeline, where one set of tasks flows into the next. Projects which require a sequential delivery for milestones tend to benefit the most from this method. For example, if each milestone has both a dependency on a previous task AND is required in order to proceed to the next milestone.

It starts with combing the backlog with both the team and the key stakeholders to determine which items are of the highest priority, and then further breaking these down into smaller chunks of work called “sprints”. Each sprint runs for a fixed amount of time (my preference being two weeks, but can be longer or shorter depending on your team and the work to be done). At the beginning of each sprint the tasks involved are assigned out to your resources and the expectations for what will be covered are clearly laid out for the team. At the conclusion of the two weeks, the work is shared both internally and with key stakeholders in order to determine that the requirements were met.

While this methodology is very widely accepted and easy to implement, it’s not without its drawbacks. In my personal & professional experience, the cliche that “seeing is believing” rings especially true with client projects. Waterfall might work well for a smaller project with a fast turnaround time between deliverables… but what about more complex projects with timelines measured in months or years rather than days or weeks? Clients may become uneasy about the progress of a deliverable over several weeks. This problem typically gets worse when they’re only seeing invoices before actually laying eyes on something that resembles a deliverable.



It starts with combing the backlog with both the team and the key stakeholders to determine which items are of the highest priority, and then further breaking these down into smaller chunks of work called “sprints”. Each sprint runs for a fixed amount of time (my preference being two weeks, but can be longer or shorter depending on your team and the work to be done). At the beginning of each sprint the tasks involved are assigned out to your resources and the expectations for what will be covered are clearly laid out for the team. At the conclusion of the two weeks, the work is shared both internally and with key stakeholders in order to determine that the requirements were met.

Once it’s been determined that the criteria and deliverables for the sprint were met, the team can then confirm what’s the be included in the coming sprint as the cycle begins again.