The world has become agile. In every organization and at every interaction I have, software practitioners, project managers, and clients are terrified of the term "Waterfall".

Agile and Scrum are the new buzzwords of being in tune with the new development methodology. A whole new huge industry of scrum and agile training and certifications has taken the center stage.

If you happen to say anything good about the Waterfall approach, the "fanatics" of scrum and agile will probably shoot you down.

Agile fanaticism has actually made us lose many things that were good in the Waterfall approach.

How does Agile address software architecture? Very little is discussed in most of the agile and Scrum training. I have personally sat through multiple Scrum and Agile training sessions conducted by reputed institutes and have not found a satisfactory answer to the question.

Do I not agree with Agile principles? I do completely agree. We as an organization are following Scrum principles for more than 2 years now.

We find the approach to be beneficial to us for upgrading our core product, SuXeed.

But can waterfall and agile co-exist?

Do they serve different types of requirements?

The premise behind the Waterfall approach was that discovering a missing requirement at the later of the project can be very costly, hence the need to document all requirements at the beginning.

The pertinent question is "What type 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 the required transaction loads. In another project, we spent close to 4 months to ensure the 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.

Do share your thoughts on the topic.

Suggestions for improvements are always welcome.

You can reach me at LN@Adaptiveus.com.