The Waterfall model has become a joke and is pointed to as an way of doing software development poorly. While the approach has a number of limitations, it is helpful in some situations. Understanding these situations can be useful when trying to use an agile development methodolgy to make sure that you do not make critical mistakes.

During a conversation last week, a team lead told me that he considered Agile and Watefall as being two different approaches with the same result. As a proponent of Agile approaches, I tried to understand his situation and convince him of the benefit of an agile approach. After some discussion, I came to the conclusion that his situation was unique in that it actually benefit from a more rigid approach.

The reality is that different development methodologies are appropriate for different situations. And while we all have our favorite approaches, we need to be careful about whether our current team/project benefits or gets hurt by our choice of development methodologies. Agile approaches breakdown without strong collaboration, and a waterfall approach cannot deal with changing requirements.

While the Waterfall model (even when first described) was used as an example of a flawed development model, it does have strengths. Many organizations need better software systems, but don’t really understand their requirement. Having a well-defined process for gathering requirements can help clarify the most important parts of a complex project. Agile teams work well when faced with changing requirements but they need to make sure that the first requirements that they are working on are the most important ones.

Agile development may not be as efficient when progressing towards a known goal (as indicated by the red line), but they do have useful functionality in every iteration.

Goals change over time - a team using the waterfall model will take much longer to reach an adjusted goal than an agile one.

The benefit of knowing all the requirements of a complex project can be a big strength of the Waterfall model. While having all the requirements does mean that the team needs to know both the problem and the solution, having this information allows optimizing how modules interact and therefore reduces the high communication overhead in projects. While Agile teams thrive in situations where only the problem is known, they do this at a cost – that of not having as clear module definitions, having code duplications, and thus having a higher communication overhead among development team members. Agile teams therefore need to make sure that they are consistently paying down techincal debt and improving the code based on an updated-architecture.

Additionally, knowing all the requirements in a project allows for teams following a waterfall model to optimize development efficiency by not worrying about short-term feature milestones that are not needed in the complete system. While this can add significant integration challenges for non agile teams when deploying an entire working system, the presence of the short-milestones in agile teams can add significant overhead for agile teams. Agile teams therefore need to realize that their lack of such development efficiency do comes with a benefit – one of having shorter milestones to provide their customers useful functionality frequently and therefore needing to focus on having working code with real users in each milestone.

Image credit: flickr

 

I am writing new articles once every 2-3 months. Interested in getting notified? Sign up here.