Was there something good in waterfall that lacks in agile – DDD

There is just one part, one-piece step/phase of both methodologies agile and waterfall in which the old fashion way, thinking of one aspect, has some advantage over the new one agile. This does not have to mean that agile (scrum) is bad and developing projects by this methodology are doomed to fail and all other projects managed by waterfall will have great success. The idea of this blog will be to motivate managers and others to think a little bit more out of the box, instead of blindly implementing and using everything from the books what is new. Before we start to talk about whether something is missing or not in agile let’s first introduce the basics of both methodologies.

Agile way
These days every software developer knows the basics of agile which are given in the agile manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more. https://agilemanifesto.org/
These thoughts are maybe more abstract, but looking more from real-life experience we can define twelve principles:
Customer satisfaction by early and continuous delivery of valuable software
Welcome changing requirements, even late in development
Deliver working software frequently (weeks rather than months)
Close, daily cooperation between business people and developers
Projects are built around motivated individuals, who should be trusted
A face-to-face conversation is the best form of communication (co-location)
Working software is the primary measure of progress
Sustainable development, able to maintain a constant pace
Continuous attention to technical excellence and good design
Simplicity—the art of maximizing the amount of work not done—is essential
Best architectures, requirements, and designs emerge from self-organizing teams
Regularly, the team reflects on how to become more effective and adjusts accordingly

This is a theory of what should some agile methodology have. And again there are no strict phases that one project has to go through during its lifecycle.
The most used methodology that is based on agile is scrum, so we are going to talk about it. It is a methodology that implements the principles of agile. Because it is a real practical process of developing some software it has strictly defined processes of how the software should be developed.

The project should be done in a series of iterative small steps which are called sprints. One sprint should have a maximum period of one month. The most common is for two weeks. Following pictures shows how scrum phases and sprints look like:
 

What can we focus on from all of this? The main goal in Scrum – Agile is to develop incrementally. Always split all requirements on smaller ones and work on a few of them every sprint. The idea is to make small requirements so that several can fit and can be done in one sprint. After every sprint, there will be a release and will be presented to the PO for review (features bugs, etc).

Waterfall way
Many of the older generations may have been working on some projects organized in this way and they know and are familiar with the main differences compared with agile. But for all others, we will try to explain it in few words.  

Basic model flow for the waterfall has the following stages:
Software Requirements
Analysis
System Design
Coding and Implementation
Testing and Verification
Operation and Maintenance
And we can see a few diagrams and models how waterfall looks like:


Here we can see that nothing is repeatable and everything is strictly defined. When the project starts, it has to go through every stage and every stage has to be confirmed that is correctly done. But what means no repeatable. It means that in all of these phases should be covered all scenarios that have to be implemented and are planned for the project.
Or more detailed explanation, when the analysis of the requirements starts, it will be for all requirements that should be in the project. It can take maybe one month or more. It can not be done with just a few meetings between the clients and business analysts, because in this phase all requirements should be defined in detail.

After both sides agree that requirements/business scenarios defined in these stages are good and are everything that will be done, the next stage, the design will start. In some ways, this is the stage when real implementation starts. Architects and designers are analyzing all the requirements, written in the first stage, and with that information and knowledge, they will start to design the model and set up the application (technologies and frameworks which will be used).
The next step will be implementing all requirements. The process with development and testing of every requirement after it is done. In the same phase, bugs will be fixed along with everything else.
After all, requirements are done and tested, the project goes in the final phase which will be the deadline when the project has to go live – production.

Right way of implementing Agile
Comparing these two ways of managing/doing one project we can agree that agile is much better and more reliable to be used instead of a waterfall. We don’t have to wait a long period to be sure that we are doing what is right and if it will be accepted by the clients. Acceptance of the project is with every iteration.
Why is this more and more adopted from companies that develop different applications, small and big? It is because they can be sure that everything that they are going to do this month will be accepted. If it is not they are going to lose the effort only for that month. Not the effort and work for one year like in waterfall.
Starting from this point companies are forcing to have something from the start. I don’t like to spend time analyzing and defining the whole data domain, taking in advance all requirements, and setting up the whole architecture by the real needs of the project. That will cost them time and money.

Everything will start great. All stories, epics will be defined after the projects start. Split them in small requirements that can be done during one sprint, they will be defined during the sprints or few sprints before they have to be done. There will be no useless work and effort.

The data model will be defined and created with every new requirement, with every new feature or maybe some bug. In the beginning that data model will serve very well. Requirements can be done fast because there will be no issue of creating a new entity and reference it to some existing one. DDD will be fulfilled while we solve every ticket. First, define the data then implement the code.
But this will be done only for the small parts of the data model and of the project. There will be no defining big data domain that will be useful for the features that will come next. For a week, month or year.

After some time and set up some data model, with every new ticket that will require model changing we will have more and more difficulties to adapt existing data model for the new requirements. At one moment we will have to do bigger changes in the model. The main reason for this is that when we implemented the requirements we cared only for the needs that we had in the sprint when we worked on the previous ticket, story, etc and we were not aware of the needs of the model for the featured requirements.

Then we will have let’s say two solutions:
To continue to try to work on the model that we made it by now. Which will make implementing our new changes harder, and with that more time-consuming.
Or at one moment stop with new features and spend time on a big refactor of the data model. Which will take a long time without doing anything productive on the project with new features, just refactoring.
In both scenarios we will have less productivity then we had before and less than we expected.

If we make a retrospective what we have done, we will see that we save time at the beginning on analyzing and defining the whole data model but after some time, year or more, we will spend the same or maybe more time on dealing with the bad data model or big data refactoring.

These possible issues that we can have in the future, with forcing fully agile from the very start, can be easily avoided if we add one more phase before implementing requirements. Just spend time analyzing, defining, and modeling of the main big crucial epic stories that we have to cover with our project. Which is more like DDD in the waterfall methodology.

Source: https://www.north-47.com/knowledge-base/was-there-something-good-in-waterfall-that-lacks-in-agile-ddd/