I will risk contributing to this controversial subject, especially after reading Victor's answer. I want to refute his argument, but at the same time fully agree with him. Come again?

Waterfall is everywhere

First, all developers use Waterfall. Always. What changes is the scale.

We cannot circumvent the string Requisito > Análise > Design > Implementação > Teste > Integração, simply because it is impossible. How can we do analysis without requirements, implementation without know what we have to do or test without code?

The difference is that some try to do everything in a sequence, write large blocks of code and try to run everything at once. Others, more like my case, test the code every two or three lines modified or added.

So I can reconcile my statements by making a difference between a full Waterfall and a micro waterfall . Agreeing with Victor, it is simply impossible make a complete Waterfall in a software project because it will always be necessary to review errors and changes that affect the previous steps. Even to fix a small bug you need to analyze the requirements, make design of a solution, implement it, test it. On the other hand, what Agile processes do is decrease as much as possible the time boxes to get feedback from the customer, thus creating Micro Waterfalls.

Designs with appearance of Waterfall

In practice, projects can be " interfaced* with the customer based on the full Waterfall model and micro managed in the development team using Scrum or any other Agile management methodology.

For some customers, not It is interesting to get a product very early. I thought about the case of a change of law with a date to take effect. What is the use of receiving the product before? A project with a schedule Waterfall would fit well in that case. However, nothing prevents the development from being done with Agile principles, where every one or two weeks the functionalities are integrated into an executable version, tested using mocks , presented to a customer (even if it is not the customer itself, but a business expert).

We can't have everything

Some time ago I wrote an article about the iron triangle. The idea of this representation is to pass the idea software projects deal with intrinsic constraints that we cannot simply ignore. The commonly cited are: time, resources, scope and quality.

More traditional software development and management methodologies, where the Waterfall fits in very well, usually tend to fix time and scope. What happens? It calculates the number of resources needed to deliver the system on a date, things do not go as planned and who suffers is the quality.

Modern processes, which usually take the term "incremental and iterative" to the limit, follow a reverse path. They generally vary the scope (by adding or removing User stories from sprint according to productivity) to maintain fixed time and quality at an acceptable level.

Final considerations

Anyway, my general advice would be:

• For software development, never use Waterfall in the full sense of the model, as it would be completely unfeasible.

• When, and only when, the client or the situation requires a strict schedule, encapsulate development into a project that looks like a Waterfall, but being very aware that when we set time and scope, we harm quality. we can't have everything.

For me, the dividing line is in the" degree of certainty " that one has of the project. Projects that you know exactly what to build, waterfall fits very well (ex.: buildings). Projects where there is a great degree of uncertainty about what to do and you learn a lot during the project, the Scrum fits better.

The post requirements survey and SCRUM talks a bit about how the topic "requirements survey" is approached in Agile methodologies.

Unlike Waterfall where changes are not welcome (because they generate "change requests" and require review of the entire project), agile encourages changes. Therefore, when the goal of the project is something easy to realize at the beginning of the project (it is easy to predict all activities, deadlines, etc.), waterfall fits much more. In the case of difficult, more experimental requirements, agile handles better, mainly because it encourages prioritizing what is known less, mitigating the risk of the project not being delivered sprint to sprint.

For this reason, scrum usually fits very well in software projects. At the beginning of the project, there is a lot of uncertainty that is reduced little by little. As iterative deliveries receive feedback from the user, feature improvements are estimated (in new stories), and re-enter the backlog to be prioritized.

The management of the deadline begins to be more efficient, because as the team generates history of "speed" (how many of how many points are made within a sprint), it is known by the size of the backlog x speed what the forecast of completion of the project.

On the other hand, in waterfall, the culture of setting dates in stone ends up reigning, because in order not to miss the deadlines, changes are discouraged. By complicating scope renegotiations (on each change, the entire activity thread, and the entire schedule should be revised), the result turns out to be products that are not of interest of the user, or the deadline for its construction is so great that upon completion of the project, the requirements given at the beginning of the project no longer reflect the user's need.

Another interesting reference on the subject is in Robert C. Martin's book "Agile principles, patterns and practices" (Appendix B). In this book he a comparison between the time of "documentation" (or design) x the time of construction. In this exercise, the author suggests that in civil construction, for example, the cost of the project is a fraction of the total cost of construction and once the project is ready, it is known exactly what to build. In software, the "model", would be the source code itself, while the construction only the" compilation " of the software, the construction. In this case, the project time is almost the entire time of the project. In these scenarios, agile fits better.

When to use Waterfall?

When the requirements are well defined and with no prospect of change, such as the construction of a building. That is, very rarely in the case of software.

With the caveat that good software development methodologies are often iterative and can define a waterfall-like model as the procedure for each iteration, although the process as a whole is not Waterfall.

When to use Scrum?

I will use the features of the Scrum to determine when it is appropriate to use it.

Tip: if you are getting married, you can use Scrum to arrange the wedding. :)

Scrum is above all Agile

Scrum is one of the ways to implement agile methodologies ; this defines most of what Scrum is and as such it adopts the preferences of the Agile manifest :

• individuals and interactions in preference a processes and tools
• running software in preference to extensive documentation
• Customer Collaboration in preference to Contract Negotiation
• react to changes in preference to follow a plan

This is not to say that the criteria on the right side will be ignored, but rather that the criteria on the left side are preferred over they.

The adoption of the Agile Manifesto suggests a project profile for which Scrum( and other Agile method implementations) are best suited:

• when requirements are expected to change over the course of development;
• when the client is available to provide feedback to the development process;
• when formally documenting the development process is not critical to the project;
• when not it is necessary that the methodology itself determines the type of documentation generated by it.

Scrum has its own characteristics

Some Scrum-specific features refine this project profile:

• relatively small teams, physically close and able to self-organize;
• minimum time of one sprint to develop the product.

Situations where Scrum shines (compared to methods non-agile):

• by being iterative, based on sprints and responding quickly to changes, Scrum ensures that changes will be met as quickly as possible, obeying a priority queue and delivering as many deliverables that the team(s) have the ability to deliver within that context. It shows its best when the customer, in addition to worrying about having this ability to respond quickly, is aware of the importance of its own willingness to provide feedback to the team(s), and want to have product iterations (partial deliveries) up and running as soon as possible;
• when deliveries cannot go beyond the deadline. This is because the sprints have predefined duration (although it is possible to cancel deliveries).

Note: scrum experts please supplement / correct what was quoted as my experience as a Scrum is less than one year and just as a developer (pig ).

When to use Waterfall

• The Waterfall life cycle is mainly used when the software to be built is defined mathematically and / or formally where all its requirements and logic are previously established and checked mathematically as the ABS brake. (Soon it is of extreme need for customer to commit to specification requirements).
• Note: life support software must be approved by a specialized institution, therefore your documentation should be well structured (which is a requirement for the use of Waterfall).

When to use Scrum

• when it is necessary to deliver features to the customer in a very short time (then the priorities of each function are staggered, the priority defines the delivery order).
• when the customer is not completely sure of their needs.
• when the domain of the application is constantly changing.
• when a team is small (+/- 10 Members) and has good interplay. (Determining requirement).

In Scrum and other Agile methods product owner participation is required all the time. In these methods, the more the customer can interact to give feedback to the developer the better will be the software produced, that is, the software produced will be more suitable to the customer's needs.

If, for some reason, the customer cannot be present at all times, the Scrum or other Agile method becomes unfeasible or at least impaired. There, you probably will fall into a model closer to the Cascade (requirements -- > development -- > validation).

More as a general rule, the more interaction and the more feedback the better.

I recommend leaning on Stacey's matrix, which helps visualize that when you have enough knowledge of what will be done and agreement with those involved, the cascade can serve well.

When you don't have that much clarity / agreement, agile can serve you better as it will help you test and validate small options throughout the project.

Dear Colleague, it is very difficult to answer your question without making any value judgments or entering into complex arguments. It is a decision that can depend on many factors.

However, so that it does not go without an objective answer and as a comparative basic guideline, I suggest you evaluate the table above that summarizes well some aspects (pros and cons) famous of both approaches.

Source: https://www.seguetech.com/waterfall-vs-agile-methodology /