![Ramblings about two software development models: Waterfall and Agile](tan-man-ve-hai-mo-hinh-phat-trien-phan-mem-la-waterfall-va-agile =1200x900)
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?
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.
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.
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.
Hello, my name is Hoai - a developer who tells stories through writing ✍️ and creating products 🚀. With many years of programming experience, I have contributed to various products that bring value to users at my workplace as well as to myself. My hobbies include reading, writing, and researching... I created this blog with the mission of delivering quality articles to the readers of 2coffee.dev.Follow me through these channels LinkedIn, Facebook, Instagram, Telegram.
Comments (8)