When is Waterfall the right option?

Often when I’m training, I get the question “...but when is waterfall the right choice”, or “can’t I just do waterfall for this project”?

Generally, managers will suggest a waterfall approach when requirements for a project are implicitly and fully defined.  Examples include a refactor where the functionality should be identical to the un-refactored app, or where a team is charged with cloning a portion of an existing product.  The desire to use waterfall comes from someone who believes that since the requirements are implicitly set, they don’t need an iterative product management approach.  They know what they need to build and they want the engineers to JUST BUILD IT.  

However, just because there’s a clear product vision and all of the user stories (requirements) can be clearly articulated, doesn’t make waterfall the best answer.

To understand this better, let’s look at how this would work for a waterfall project:

First you’d start with a discovery phase and build out a requirements document that detailed EVERYTHING that needed to be built.  Depending on the size of the project, this could be very extensive and time consuming.  You’d also need to detail out the requirements for elements of the projects that may be weeks, months, or even more than a year away from being built.

Next you break the requirements down into bite sized tasks that can be scoped.  Generally these would be input into a Gantt chart with resources associated to each task.  After spending a day (or two) locked in a room with a project manager, you’d output a beautiful project plan with a very specific end date for the project.

Then, you and your team would begin work on the project.  However, even if the requirements of the project don’t change at all over the course of development (rarely the case, because there’s nearly always extra requirements discovered), something about the implementation team or implementation work would change.  Perhaps a member of the team would quit or perhaps some of the engineering work just turns out to be harder than expected.    In these cases, the project plan will have to change, requiring lots of time to update the plan, even though the requirements were in fact accurately described up front.

With a waterfall development methodology, the development team then continues to march through the requirements and project plan, regularly updating the project manager as they’re falling behind.  The project manager duly updates the stakeholders until eventually the project is launched (or canceled because it’s been delayed so many times leadership no longer sees the value).

But there’s a better way!  Even if you have a well understood product to build, it’s still helpful to incorporate scrum or kanban best practices for building.

The first thing you need to do is build the backlog.  You start with the highest priority components and build out a couple of sprints worth of user stories.  Since the work is well understood, it should be easy and quick to build the first part of the backlog.  Plus, compared to waterfall, you don’t have to build out the full backlog.  Instead, you can build out the highest priority elements and start your sprints.

For teams of three or more people, the team should follow the scrum model with backlog refinement, sprint planning, daily stand up, sprint demo and retros.  For teams of one or two developers, kanban is an appropriate choice and the team will work through the backlog in priority order.

Regardless of your chosen Agile methodology, sprint demos are very important as they help to build the confidence of stakeholders around the work being built.  From scrum teams, you’ll hold stakeholder demos every sprint and for kanban teams it usually makes sense to do monthly stakeholder demos.  These are crucial in building the confidence of the stakeholder team and having them witness the momentum of the project.

I find these are particularly impactful for large refactors, where the benefits of the work can seem intangible to stakeholders.  I suggest a demo where the engineer shows a faster output or the code generating the same result but with substantially less lines of code, thus making it easier to maintain, etc.  These demos serve to build momentum behind the project.  This helps if the project runs into trouble, as there’s already goodwill built with leadership.

The other advantage to demos is that it allows the team to uncover unnecessary work.  Often, a feature may seem absolutely necessary when a project is being described in the abstract.  But when a stakeholder sees the partially complete feature at a sprint demo, they realize that the feature isn’t as critical as it initially seemed and can be omitted, at least for the time being.  

It is also critical to have a regular cadence of retrospectives while the work is ongoing.  This allows the team to evaluate how they’re working together, identify areas of improvement, and make changes to their process that will allow for the project to be completed sooner.  This is one of the most powerful elements of Agile.Instead of waiting until a project is complete and then running a retrospective on how we can work better together next time, we can make changes today that will improve the current project we’re working on.  Agile’s rapid iterative improvement applies not just to the software project and its requirements, but instead to the team doing the work.

While waterfall gives the illusion of getting less distraction and meetings, Agile is still a better approach for projects with a well understood scope and requirements.  In these cases, the team may not need to spend a lot of time testing ideas. However, by incrementally working on user stories, doing stakeholder demos, and running retrospectives,the team will both produce a better product, and ship it faster.