The world has moved to agile. Everywhere I go, software practitioners, project managers and clients are terrified at the term "Waterfall". Scrum is the new buzzword and the whole huge industry of scrum and agile training and certification has taken the center-stage.
If you happen to be a proponent of waterfall approach, the "fanatics" of scrum and agile will possibly shoot you down.
But can waterfall and agile co-exist? Do they serve different types of requirements?
The premise behind waterfall was that discovering a missing requirement at the later of the project can be very costly, hence try to document all requirements in the beginning.
The pertinent question is "What types of requirements?" Functional requirements can be changed without much cost. What about non-functional requirements? Can they be changed easily once the application is developed?
Indeed, in my personal experiences, we had severe cost overruns in the projects because we missed non-functional requirements. In a large ERP implementation project, we had to move the roll-out plan for 6 months as the ERP could not handle required transaction loads. In another project, we spent close to 4 months to ensure application met information security requirements.
Unfortunately, Scrum and Agile approaches are very silent on non-functional requirements.
Next question is, will users change functional requirements or non-functional requirements?
Since users are keen on functional requirements, these requirements are likely to see more churn than non-functional requirements. Hence, agile and scrum approaches work better for functional requirements.
As long as we understand the differences between functional and non-functional requirements, we will be able to apply the right approach, waterfall and agile.