Waterfall vs Agile. Which methodology should I choose for my project?
At the beginning of a software project, the technical team and the organization must make an important decision. Choose which methodology may be the most appropriate, that is, how to approach the development.
Today, we will learn about the two most used methodologies during the Software Development Life Cycle (SDLC). Choosing the most appropriate one may not be an easy decision since each one follows a very different process to achieve success.
Waterfall or cascade technique
It is the most traditional technique in software development. It has proven to be a widely beneficial technique. Based on the client’s interests, a sequential plan is designed to suit them. It is a sequential approach that divides the SDLC into five phases:
- Requirements: A list is made of the client’s needs (for example, the interface they need) to plan the following phases.
- Design
- Implementation: The programmers perform the actual workload.
- Verification: This phase is to check the quality of our work and appreciate the failures that we may have. Currently, Insights tools are used.
- Maintenance: Our team will be responsible for responding and updating the software to satisfy the customer.
We can only move to the next phase if the previous one has been successfully completed. Between the different phases, a deliverable or a signed document is expected.
Only once the different phases are passed. That is why all the requirements are gathered at the beginning. To have all the information necessary to create the necessary planning, budget, and resources.
Advantages and disadvantages of Waterfall
Advantages of Waterfall
- Gathering ideas early on makes planning and design easier.
- The scope of the project is well defined.
- The budget is easier to calculate.
- The client does not need to spend time on the project.
- Teams are more organized to work in parallel.
- Progress is measured with clear and marked goals.
Disadvantages of Waterfall
- Less flexible structure in the face of possible changes.
- There is no room for error. It can be a bad strategy in the face of changes in customer preferences.
- Large projects are not ideal: too much waiting time.
- There is no testing of the solution until the final stages.
Agile or agile method
Agile development follows an approach based on customer satisfaction. With it, we seek the rapid delivery of complete functionalities of an application.
In this methodology, a limited time phase called sprint is defined with a normally established duration of two weeks.
- At the beginning of each sprint, a list of functionalities to be delivered within the expected delivery time is drawn up based on the requests and priorities agreed with the client.
- At the end of the sprint, the developers and the client review and evaluate the work done and take notes to take into account for future sprints.
Advantages and disadvantages of Agile
Advantages of Agile
- Faster SDLC.
- Definition of a sprint calendar.
- A customer-centric approach results in greater satisfaction as you feel part of the team.
- Flexible in accepting changes: the client can see the work done, make decisions, and request changes.
- Empower teams to manage projects.
- Ideal for projects with non-fixed financing.
- Possibility of launching a basic version of the product that will be completed with later iterations.
Disadvantages of Agile
- It requires a high degree of customer involvement and not all customers are comfortable with this role.
- Customer involvement can lead to new requests made throughout the project, which will lengthen the time and increase the cost of development.
- It assumes that each team member is completely dedicated to the project.
- A time-constrained approach may not be enough to accommodate deliverables, and if delivery times do not match reality, they increase the cost of the project.
My personal experience
More than twenty years ago I realized that I liked documenting more than coding, and I went from being a programmer to a functional analyst.
The talks with the taking of requirements, the elaboration of functional documents with proposals in prototypes and their presentation to the client, etc. that is the stage of development that I could enjoy the most.
Waterfall Stage
The first fifteen of these twenty years were with 100% Waterfall methodology. In my sauce… generation of very detailed deliverables, schemes, diagrams, even data model proposals from the identification of entities and their relationships.
With this, exhibitions and discussions with the client, touch-ups, and, when everything is clear, development.
Agile Stage
Later and due to a change of employment, Agile arrived.
“No, no, there are no functional documents here, user stories are created in JIRA”
A user story is an informal explanation of a small piece of software functionality, documented independently of the rest. They are often documented as tasks in ticketing applications such as JIRA.
I had just run out of what I liked the most, preparing detailed documentation to have a preview of the product and discuss it with the client before starting development.
But what about the global vision? What documentation could I consult to learn about a project in development?
“You have to look for the tickets for the stories in JIRA and check each one there”
From my point of view, crazy. In other words, it could be said that there was nothing and to find out about the product in development, all that remained was to ask and play trial and error in test environments.
I believe that this fashion of not documenting anything leads to losing control when the system grows, to the fact that such a part was made by such a developer or an external company and it is not known how they did it or why they did it that way.
An intermediate step: the hybrid model
After a lot of development, the day came when I decided to get out of the script and start making functional documents about the product, documents that could cover several sprints and structured in such a way that they could be divided into sections, being able to limit the functionalities to be implemented in one iteration.
And then came the surprise. Customers were delighted to be able to see a document that was practically a preview of what could be a user manual, and developers too, since they could learn more about the product at the concept level and the business needs for which it was designed. thought development.
At that time, the tickets with the stories simply had a link to the specific section of a document, which delimited and detailed the functionality to be implemented, a document that in its entirety defined what the system or part of it as if it was a large project.
The hybrid model focused on prototyping
Using this new “hybrid” version of the methodology, I could incorporate the use of prototypes so that the client could see an idea of what the finished product would be like at the beginning of the development cycle. Many times, it is easier to detect an error of approach with an image of the “screens” than in a long text.
Once again, due to a change of employment, already in Itequia, I was lucky enough to come across a novelty in the methodology to be applied: giving importance to prototyping.
One of our ways to reduce the volume of initially generated documentation is to focus the requirements gathering phase on the generation of the prototype of what could be the final product.
It is about involving the UX/UI team almost from the beginning, that they are present at the requirements meetings in order to have the first proposals to validate with the client in the short term.
The presentation of a prototype with the final look that the product will have and interactive to simulate the functionalities makes it easier for the client to detect necessary changes with respect to what he had been able to initially propose and, in addition, gives him the feeling of progress in the project.
The prototype will also be used to introduce the development team so that they can see the theme, type, and scope of the implementation to be carried out during the project.
But… and my favorite part? What about the documentation?
Carrying out prior prototyping does not replace the necessary documentation to detail development, but it does help to have a prior vision, which helps us not to have to make many versions of the deliverables (and their respective readings) until the version is approved. final.
In short, both Waterfall and Agile have become the methodological standards because each covers a wide variety of projects and meets many of the industry requirements. That does not mean that they are the only existing ones or they need changes depending on the company. Explore each technique with your team, choose one as a base, and make any necessary changes while working on an application or program.
It is the best way to guarantee the success not only of you but of your client.