Ramblings about two software development models: Waterfall and Agile

Introduction

During my studies, in the subject "Analysis and Design of Information Systems," I learned about the Waterfall software development model. The name of this model evoked an image of a powerful waterfall cascading down from top to bottom, suggesting a sequential process that is not easily reversible.

However, in my professional career, I have yet to encounter any company that actually employs this model for software development. Instead, there is another name: Agile.

Agile - Scrum is a name I'm sure many people are familiar with or are currently implementing in their workplace. A cycle (sprint) takes only about 2 weeks to develop and complete a set of features, which are then released to the market and made available to users. The idea behind Agile is to deliver features to customers as quickly as possible, thus satisfying them and making them willing to pay for the product.

What could be more fantastic than Agile? We constantly cycle through new feature lists, "code" and "release"... occasionally taking a cycle to fix bugs and improve functionality. At the end of each sprint, we have a retrospective session where we look back on what we have done well or not so well, learning from it for the next time.

Honestly, as a fresh graduate, Agile seemed like the most amazing method to me. People often say that humans tend to develop strong emotions towards the first thing they encounter. This means that from the very beginning of my exposure to Agile, no matter what other models I came across, Agile always held a special place in my heart.

There was a time when I highly praised Agile, ready to crush other methods like Waterfall in debates. I believed that Waterfall was outdated and incapable of meeting the demands of modern software development.

But recently, I may have gathered enough "evidence" to support a certain truth: "Agile is not the best," or rather, it is often not ideal in most cases.

So, why is that?

Waterfall and Agile

First, let's briefly revisit the concept of the Waterfall model.

Waterfall is a software development model in which the development process resembles a flowing waterfall, with phases executed in a strict sequence without any backtracking or skipping of phases, including requirements analysis, design, implementation, testing, integration, and maintenance.

During my professional experience, I have found that requirements analysis is always the most time-consuming stage. It involves making decisions about what needs to be done, combining strategies with vision, plans, and even statistical figures to achieve the desired features.

Therefore, it must be meticulously and cautiously done before moving on to the next stage because once you proceed, it becomes difficult to backtrack. At that point, another department has taken over the requirements and started designing the system and application/software interfaces. What happens if an unexpected issue arises right from the first step?

If the mistake is small and within control, just a matter of rephrasing or adding a few cases that do not affect the main functionality, everything can be accepted. On the other hand, let's assume the Design department receives the requirements and discovers a significant number of issues that, if not addressed, prohibit progress. The waterfall process may collapse in such a situation. We cannot keep going in a loop from Requirements to Design because subsequent steps will never be able to continue.

I believe that many mistakes similar to the above have occurred in the past, which necessitated the emergence of a new approach: Agile.

Agile software development is a flexible method for executing software technology projects; it encourages change during project development and delivers the product to the end-users as quickly as possible.

We no longer have a waterfall, no longer a step-by-step cascade, and no longer fear going back. Now, everything focuses on "delivering the product to the end-users as quickly as possible."

Well, that sounds quite broad. How can we deliver the product to end-users as quickly as possible?

Scrum is a flexible collaborative framework often applied within Agile. According to Scrum, we have a time-limited iteration in which software development occurs continuously, typically lasting 2 weeks to a month. In each iteration, a feature must be completed and brought to the end-users. There are many more rules, but I won't go into detail within the scope of this article.

I believe that Agile is widely popular. If you ask 10 people in the same field, 9 of them will know Agile, and the companies they work for are likely implementing this method. Only one person might say, "I'm free," meaning they are not following any specific model.

In today's fierce competition in technology products, we cannot be certain that our ideas are unique because even a slight delay may result in numerous similar products appearing, even if they haven't been promoted anywhere.

Therefore, we need Agile to quickly release products to users, thereby capturing the market, and then we can leisurely add new features. Is this true? If you have applied Agile and observed a few limitations without openly expressing them, take a moment to think about those drawbacks and see if they align with my observations.

Below are the "evidence" mentioned at the beginning of this article to reinforce the viewpoint that "Agile is not the best" based on over 5 years of my working experience.

• Ambiguity and lack of information: In continuous and short-term cycles, everything must happen quickly. From creating documentation to grooming sessions to disseminate development goals, sometimes you don't even have enough time to review the documentation for the upcoming features.
• Too fast-paced and lacking time for reflection: You cannot fully anticipate the impact of what you are about to do on what already exists until you start working on it, when new issues arise.
• Tendency towards exhaustion and disillusionment: Continuously rotating through features, occasionally even having to accept entirely new requirements, can cause delays or even project failures. The lack of stability in product development can lead to doubts about the product itself.
• ET and OT: Once the feature list is received, the next step is detailed planning, task allocation, and estimation of completion time. This is not an easy task as it takes a lot of time to "predict" things that are still uncertain. If the deadline is approaching and work is not yet completed, overtime becomes the last resort, resulting in a week of non-stop work.
• Falling into the construction trap: Have you ever wondered where the feature list comes from? Is it from top management, customers, or the research department? A product brings value to users when it solves their problems. Therefore, the features must align with the customers' needs. We need more interaction with customers to truly understand what they want, and this often takes time and effort. There must be a faster way than trying to understand users' pain points by continuously releasing features and observing their usage. If the usage is high, it means success, and vice versa.
• Lack of product understanding: Most of the time, when starting a new job, I have a few weeks to get acquainted with new things, such as the culture, environment, product, and even the code... but rarely am I presented with an overall picture of the product I am going to work on. Mostly because the time to get acquainted is limited, and afterwards, you get swept up in the never-ending software development cycle.

At this point, it becomes apparent that Waterfall addresses most of the above disadvantages.

All requirements are clarified right from the beginning, and we have sufficient documentation to work on without the fear of changes. The issue at this stage is only the time plan for completing all the features.

Surveys and evaluations are integral to the initial stage. Surveys help us avoid the construction trap and provide a basis to believe that when a feature is released, it will bring satisfaction to many people.

When all departments have a clear understanding of the product, it creates motivation towards a future where the product is created and the value it brings to users.

Nevertheless, the strength of Waterfall is also its greatest weakness, as it lacks flexibility in software development stages. Most companies I have worked with are in the startup phase, and they have temporary strategies and plans to rapidly release products in order to capture the market.

I'm not here to criticize any particular method; rather, once we recognize the drawbacks, we need to find ways to mitigate them.

Agile encourages more interactions among team members to expedite the development process. Instead of blaming the product research team for unclear requirements or delayed documentation, because everyone is often caught up in the priority feature list for the product's survival, we can proactively ask questions to clarify issues, think critically or point out cases that the product team may have missed. Remember, once Agile is chosen, the most important thing is how to release the product to users as quickly as possible.

To avoid falling into the construction trap, ask more questions related to the product during the Grooming or Planning phase. Require numbers that speak and, if possible, ask why certain upcoming features are necessary. This helps everyone have a broader view of the value the product brings to end-users.

Lastly, always be prepared for continuous changes.

Conclusion

In conclusion, this article is a personal reflection on the advantages and disadvantages of the Waterfall and Agile software development methods. While Waterfall requires a solid foundation, Agile is more suitable for flexible changes. They are suitable for different work environments, and through this article, I hope readers will not fall into the same mistakes as I did by overrating one method over the other from the very beginning.