When to use Waterfall and when to use Scrum?

Question

There is a clear way to determine when a software development project should be conducted using a methodology Waterfall or use Scrum? What criteria should be observed to choose one or the other?

Answer 1

Well, I didn’t intend to answer, but here’s a comment that Francisco Junior made:

If by chance any user comes only opining subjectively on the answer (as in the first comment saying to "never use Waterfall"), he should receive negative votes.

So come on, you can put your finger on the negative here on the left!

According to the page about the Waterfall model in Wikipédia:

The first formal Description of the Waterfall model is often cited as a 1970 article by Winston W. Royce, Although Royce Did not use the term "Waterfall" in this article. Royce presented this model as an example of a flawed, non-working model.

What translating into Portuguese is:

The first formal definition of the Waterfall model is often referred to as Winston W. Royce’s 1970 paper, although Royce did not use the term "Waterfall" in this article. Royce presented this model as an example of a flawed and non-functional model.

How interesting! The Waterfall model was born with the perception of being flawed and non-functional! And this more than 40 years ago, so imagine today!

Well, let’s take a look further into the article by Royce:

Figure 3 portrays the iterative Relationship between successive Development phases for this Scheme. The Ordering of Steps is based on the following Concept: that as each step progresses and the design is further Detailed, there is an iteration with the preceding and succeeding Steps but rarely with the more remote Steps in the Sequence.

[...]

I Believe in this Concept, but the implementation described above is Risky and invites Failure. The problem is Illustrated in Figure 4. The testing Phase which occurs at the end of the Development Cycle is the first Event for which timing, Storage, input/output transfers, etc., are Experienced as Distinguished from analyzed. [...], then invariably a major redesign is required. [...] The required design changes are likely to be so disruptive that the software Quirements upon which the design is based and which provides the rationale for Everything are violated. Either the Requirements must be modified, or a substantial change in the design is required. In Effect the Development process has returned to the origin and one can expect up to a 100-Percent overrun in Schedule and/or costs.

[...]

Hopefully, the iterative Interaction between the Various phases is confined to successive Steps.

[...]

Unfortunately, for the process Illustrated, the design iterations are Never confined to the successive Steps.

Translating into Portuguese:

Figure 3 demonstrates the iterative relationship between successive phases of development in this scheme. The ordering of the steps is based on the following concept: that each step is a progress and the design is better detailed, there is an iteration between preceding and succeeding steps, but rarely between remote steps in the sequence.

[...]

I believe in this concept, but the implementation described above is risky and is an invitation to fail. The problem is illustrated in Figure 4. The test phase that occurs at the end of the development cycle is the first event for which time, storage, input and output transfer, etc., are different than the one analyzed. [...], and then invariably a heavy redesign is needed. [...] The necessary changes in the design will probably be so disturbing that the requirements in which the design was made and that prove the reason for everything were violated. Either the requirements must be modified or a substantial design change is required. The effect is that the development process has returned to its origin and then one can expect a 100% over time and/or costs.

[...]

Interaction between the various phases is expected to be confined to successive steps.

[...]

Unfortunately, for the illustrated process, the demonstrated iterations are never confined to successive steps.

I recommend reading the entire article, and again I emphasize that it is from the distant year 1970. However, this continues to this day, Waterfall starts from the precept that development is composed of rigid and sequential steps, but this never works and everyone who has ever been in any project knows why:

• The customer changes his mind all the time.
• The client doesn’t know what he wants.
• A bug appeared in the test and we found that there is an error there at the beginning of the project.
• In the middle of the project something happens and then we have to go back and change a lot of things.
• User did not like the product.
• The competitor solved the problem in a different and better way.
• Customer requested changes in a certain part, changing an important requirement.
• There are two or more conflicting requirements.
• The customer says one thing at a time and then says otherwise.
• There was a difficult problem to solve in the development and the deadline has gone to bag.
• Etc..

If you want something more recent, it’s very, very easy to find on the internet, you could easily quote Martin Fowler, TDD practices, or even the Head First book on agile development, which inside explains why Waterfall doesn’t work.

And now, to ensure my downvote, I’m going to give you my personal remark on what we see today: In fact, it’s hard to find any material that defends Waterfall today that comes from anyone who has any idea what you’re talking about, and not just parroting old concepts that never took the trouble to question.

In the list above I have cited some reasons why Waterfall fails. Basically it comes down to the fact that things change over time. What yesterday was a requirement, today may not be anymore. What yesterday was not important, today is fundamental. Today we have an important restriction, but tomorrow we don’t. That’s where agile methodologies come in: they were thought to tackle these problems, assuming that these things change over time and devising strategies so that changes can be implemented quickly.

Well, I confess that so far I’ve only given half the answer and I haven’t said anything about Rawm. I won’t go into too much detail on Raw and I’ll just make a quick list to recommend when to use agile methodologies (more generally, whether Raw or not) or when to use Waterfall, and I’m sure that after you read this and have already given the downvote, will still call your friends to vote against:

• If your scope and requirements are undeniably closed, immutable and written in stone, and your code is absolutely perfect and bug-free, you can get along well with Waterfall. Otherwise, I recommend the agile.
• If your role or your company’s function is to generate millions of pages of requirements documents, business rules, architectural decisions, flowcharts, etc, and these documents will not be read or criticized by anyone (or at least by anyone who has the power to be heard), and it is not you who will make the code, so Waterfall is also for you. Otherwise I recommend the agile.
• If you plant bugs and ill-defined requirements on purpose in your project to then charge the client for any requested changes, then Waterfall will also serve for you. Otherwise I recommend the agile.
• If your religion, your philosophy, your sense of living, or your favorite deity tells you that you must follow bureaucratic and rigidly defined plans simply because things have always been so, are so and always will be so and you have an obligation to be happy with it without ever thinking of questioning, so I recommend Waterfall. Otherwise I recommend the agile.

To close, in reply to this comment:

By the way, aeronautical certifications require formal development models. It is much more likely that software running on Boeing aircraft, for example, will be developed with a process closer to Waterfall than a purely agile and informal methodology like Scrum. And I ask you one thing: you prefer to fly in an airplane that has FAA software certification or in an airplane that has been developed without any formality with Scrum?

In response to this, I say that on 10/11/2013, I attended a lecture at the IME/USP in São Paulo demonstrating the opposite. The title of the lecture was "Combining Scrum, AOP, DDD and Metadata - A Success Case at Embraer." and speakers Roberto Perillo, Tiaslei Vasni and Daniel Feichas. Here is the summary of the lecture:

This talk consists of the presentation of the approach of creating an application called AHEAD (Aircraft Health Analisys and Diagnosis), currently under way in the Executive Aviation area at Embraer. The application architecture combines Domain-Driven Design, aspects and metadata, whose development is being managed with SCRUM. Initially, a short history of projects will be shown at Embraer and because it was decided to use SCRUM. Next, you will see some mistakes made by the software industry (according to the experience of the team members) and important concepts for understanding the approach used in application design. The functional and non-functional requirements that motivated the use of the approach and how the elements were implemented will be presented below. It will also be shown how the ALM environment manages the application lifecycle and how the tests were organized (unit, integration and system). As an example, issues related to application security implementation, reverse AJAX through domain events, cross-cutting interests and integration with other systems will be presented. In conclusion, the benefits obtained with the approach will be presented, such as the gain of flexibility in the application and the acceleration of the team’s speed with regard to productivity.

Answer 2

I’m going to risk contributing to this controversial issue, especially after reading Victor’s response. I want to refute his argument, but at the same time fully agree with it. How?

Waterfall is everywhere

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

We can’t beat the sequence Requisito > Análise > Design > Implementação > Teste > Integração, simply because it is impossible. How can we do analysis without requirements, implementation without knowing 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 modified or added lines.

So I can reconcile my claims by making a difference between a Waterfall Completo and a Micro Waterfall. Agreeing with Victor, it’s simply impossible to make a Waterfall Completo 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, design a solution, implement it, test it. On the other hand, what agile processes do is reduce as much as possible the time boxes to obtain feedback customer, thus creating Micro Waterfalls.

Projects with the appearance of Waterfall

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

For some customers, nay It is interesting to get a product very early. I thought about the case of a law change with date to take effect. What is the use of receiving the product before? A project with a schedule Waterfall I could do with that. However, nothing prevents development from being done with agile principles, where every week or two the features are integrated into an executable version, tested using mocks, presented to a client (even if not the client itself, but a business expert).

We can’t have it all

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

More traditional software development and management methodologies, where the Waterfall fits very well, generally tend to fix time and scope. What happens? Calculate the number of resources needed to deliver the system on a date, things don’t 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 usually vary the scope (adding or drawing user Stories of 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 complete sense of the model, as it would be completely unviable.

• When, and only when, the customer or situation requires a rigid schedule, encapsulate the development in a project with the appearance of Waterfall, but being very aware that when we set the time and scope, we harm the quality. We can’t have it all.

Answer 3

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

The post Requirements Survey and SCRUM talks a little about how the theme "requirements survey" is addressed in agile methodologies.

Unlike Waterfall, where changes are not welcome (because they generate "change requests" and require revision of the entire project), agile encourages change. So when the goal of the project is something easy to tangibilize 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, primarily 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 term management begins to be more efficient, because as the team generates history of "speed" (how many stories, of how many points are performed within a sprint), it is known by the size of the backlog x speed which the forecast of completion of the project.

On the other hand, at Waterfall, the culture of setting dates in stone comes under way, as changes are discouraged in order not to miss deadlines. By complicating the scope renegotiations (in each change, the entire chain of activities, and the entire schedule should be reviewed), the result ends up being products that are not of interest to the user, or the deadline for its construction is so great that when finishing 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 the book "Agile Principles, Patterns and Practices", by Robert C. Martin (appendix B). In this book he compared the time of "documentation" (or design) to 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 finished, we know exactly what to build. In software, the "model" would be the source code itself, while building only the "compilation" of the software, the construction. In this case, the design time is almost all the time of the project. In these scenarios, the agile fits best.

Answer 4

When to use Waterfall?

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

With the exception that good software development methodologies are often iterative and can define a model similar to Waterfall as the procedure of each iteration, although the process as a whole is not Waterfall.

---

When to use Scrum?

I will use Scrum’s characteristics to determine when it is appropriate to use it.

Tip: If you’re 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 Agile Manifesto:

• Individuals and interactions in preference to Processes and tools
• Software running in preference to Extensive documentation
• Customer collaboration in preference to Contract negotiation
• React to changes in preference to Stick to a plan

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

The adoption of Agile Manifesto suggests a design profile for which Scrum (and other agile method implementations) is best suited:

• When the requirements are expected to change throughout development;
• When the customer is available to provide feedback to the development process;
• When formally documenting the development process is not critical for the project;
• When it is not necessary for the methodology itself to determine the type of documentation generated by it.

Scrum has its own characteristics

Some Scrum-specific features refine this design profile:

• Relatively small teams, physically close and able to self-organize;
• Minimum period of one sprint to develop the product.

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

• For being iterative, based on sprints and respond quickly to changes, Scrum ensures that changes will be met as quickly as possible, obeying a priority queue and delivering as many as possible Deliverables that the team(s) (s) have the ability to deliver within that context. It shows its best when the customer, in addition to worrying about having this rapid response capability, is aware of the importance of its own availability to provide feedback à(s) team(s), and wishes to have product iterations (partial deliveries) running as soon as possible;
• When deliveries cannot exceed the deadline. That’s because the sprints have predefined duration (although it is possible to cancel deliveries).

---

Note: Scrum experts please supplement/correct what has been cited, as my experience as Scrum is less than a year and as a developer only (pig).

Answer 5

I recommend relying on Stacey’s matrix, which helps visualize that when you have enough knowledge of what will be done and according to those involved, the cascade can serve well.

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

Answer 6

In Scrum and other agile methods customer participation (Product Owner) is required all the time. In these methods, the more the customer can interact to give feedback to the developer the better the software produced, ie the software produced will be better suited to the customer’s needs.

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

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

Answer 7

When to use Waterfall

• The Waterfall lifecycle is mainly used when the software to be built is mathematically and/or formally defined where all its requirements and logic are previously established and mathematically checked as the ABS brake. (It is therefore extremely necessary for the customer to commit to the specification of requirements).
• Note: Life support software must be approved by a specialized institution, so its documentation must be well structured (which is a requirement for the use of Waterfall).

When to use Scrum

• When a delivery of features to the customer is required in a very short time (soon the priority of each function is staggered, the priority defines the delivery order).
• When the customer is not completely sure of their needs.
• When the field of application is constantly changing.
• When the team goes small (+/- 10 members) and has good chemistry. (Determining requirement).

Answer 8

Dear colleague, it is very difficult to answer your question without making any judgement or entering into complex arguments. It is a decision that may depend on many factors.

However, so that it does not remain without objective response and as a basic comparative orientation, 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/