[This post was inspired by a question in Quora – How can the waterfall method be incorporated into an agile software development environment? Is it possible to combine both methods or is it better to stick with one?]

Can I mix water with oil?

Sure, I can put them in the same container, but do they mix well?

The same with Agile and waterfall. When done properly, they have a “90° different perspective”.

As you can see, Waterfall is about staged delivery. The project execution is divided into phases, each of which focuses on one key activity (e.g. requirements, design, planning, coding, testing, deployment), seeking to fully complete one before moving to the next one. This approach commits the project very early to a specified scope, and it’s really hard to change that scope afterwards. The product is ready and usable by users only after all the phases have been completed. Each phase is usually done by a separate person; a specialist of that work.

Agile seeks to understand the whole, and then start working on the product in very narrow slices, completing one slice before moving to the next one. Each slice is specified, designed, coded, tested, integrated and deployed (as applicable). Ideally, at the end of each slice, the system (with all its implemented stories) is fully tested and integrated, and we have confidence that whatever we’ve done so far works. It is easy to change any future requirements, as we do not commit to any specific scope in the beginning; each slice is scope commitment only for that slice. And if we consider that set of requirements sufficient for business use, the product version could be used by users. The different specialties work together to deliver the slice.

So how would you combine that?

Well, people do try. For example, they treat Sprints as mini-waterfalls. They select a set of work for two weeks, and try to do waterfalls within that timeframe. I’ve never seen that work, really. I’ve even done it myself ages ago, and it didn’t work. Was it better than big waterfalls? Sure, but not by much. [This approach is pretty common in teams who claim they use “Scrum”]

Some people use cascading waterfalls, where each small feature is its own waterfall, but the items are not linked into packages. Each item follows the waterfall path – definition, design, coding, testing, integration, deployment – with separate people performing their stages. Again, this is not Agile, but it also can work better than big waterfalls. [This approach is pretty common in teams who claim they use “Kanban”]

And then there is the “Agile” delivery within a larger waterfall. The project has stages – requirements, planning, programming, testing, etc. – and each is completed in order, but programming is done using an “Agile approach”. There are often separate groups responsible for each stage. These projects are usually plagued by very long lead times, since majority of a given feature’s development time is spent in the requirements, planning and design phases. [This approach is very common in teams who claim they use “SAFe”]

As said, all these “combinations” are improvements over bigger waterfalls. But they are not Agile. As such, they can deliver some improvements in performance and quality (i.e. 10–50% improvement), but true and significant improvement (i.e. 5x-10x improvement) is not achievable.