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

Reading Time: 9 minutes

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 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.


These thoughts are maybe more abstract, but looking more from real life experience we can define twelve principles:

  1. Customer satisfaction by early and continuous delivery of valuable software
  2. Welcome changing requirements, even late in development
  3. Deliver working software frequently (weeks rather than months)
  4. Close, daily cooperation between business people and developers
  5. Projects are built around motivated individuals, who should be trusted
  6. Face-to-face conversation is the best form of communication (co-location)
  7. Working software is the primary measure of progress
  8. Sustainable development, able to maintain a constant pace
  9. Continuous attention to technical excellence and good design
  10. Simplicity—the art of maximizing the amount of work not done—is essential
  11. Best architectures, requirements, and designs emerge from self-organizing teams
  12. Regularly, the team reflects on how to become more effective and adjusts accordingly

This is a theory 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 which 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. Most common is 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 following stages:

  1. Software Requirements
  2. Analysis
  3. System Design
  4. Coding and Implementation
  5. Testing and Verification
  6. Operation and Maintenance

And we can see 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 analysing 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 analysing 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).

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 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 from 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. Don’t like to spend time on 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 which 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. At 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. In 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 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 on analyzing, defining and modelling of the main big crucial epic stories that we have to cover with our project. Which is more like DDD in the waterfall methodology.

Beyond the evolution of agility

Reading Time: 9 minutes

Hey you! In the following article, I try to dare a hypothetical outlook on future constellations of people in the context of entrepreneurial and individual interests.

Currently, especially in the IT sector, the concept of agility and associated methods and artefacts should be widely known, recognized and used. But the question arises for me, after the “naturally even better” solution from the point of view of all participants. Because do we not strive for a world in which we should at least not carry any organizationally open questions with us? Obviously, I do it. In short, you could also speak of a supposed cost reduction and efficiency increase in the entrepreneurial sense. Stop, that was maybe too fast.🤔
Before we venture into the world of free pluralism, it is worth describing the title of the blog to better understand the approach of the coming end of the mentioned agility.

Evolution describes in a biological sense the phylogenetic evolution from lower to higher forms of the living. No matter what exactly the living thing means for us today. However, you can use this progressive development of certain contexts insofar as they represent the nature of our social behaviour or cooperation.
If we now move into the realm of the world of work, here too we can see an evolution in the interaction between the employee and the entrepreneur. Historically, and also in terms of civilization, one can point out the following timeline: of a hunter making his spear in the sense of the struggle for survival for himself and his clan and passing on this skill to the next generation (as a transfer of knowledge or covert order to continue this); about the very first entrepreneurial forms in an ambivalent employment relationship, to actual profit-making production and proven profit-seeking.

Taking into account the number of people and the needs such as food, some can detect a strong delineation of the opportune sides over time. Looking at our modern development, we came from a partly dictatorial working world to a moderately structured hierarchy, into a flimsy open working culture of cooperation. The move, from the largely totalitarian work systems to a self-determining working method, was logical and not surprisingly the first to be found in areas that were difficult to understand and predictable and still are.
The IT 🙄 and development departments were among the first to use well-known industrial artefacts like Kanban in their favour. Over the past few years, this has become a discipline of its own, which in turn has created a responsibility or even a hierarchy. Someone could say, considering the commonly used agile model that necessarily, with control and control mechanisms (Scrum Master, Plannings, Charts, etc.), the claim of self-determination was forced back into a corset.
Everything now has flown over, you can perhaps consider a “return” of things. Somehow, the conflict between the nature of life and the artificial world seems to lead back to the origin. But humanity has and will resist it again and again in this age of the earth.

I do not want to talk about facts, but at least in the area of IT, a closed transition to this form of “things” is almost inevitable. Similarly, there is almost a certain social compulsion to join this. This change can be seen simply in the number of companies that already use agile methods in subareas or their organization. And there are more and more.

But the question of whether it is the absolutely definitive way is only discussed obscure. To publicly confront oneself with a potentially critical attitude is now considered unfashionable and unattractive. It is now a domain of the younger culture to want to deliver themselves to a self-reflective surface. Sometimes one tries to get rid of the already mentioned corset again. Interdisciplinary is the keyword here. But is not that also an escape forward or even back to the past? There has always been a claim to position employees self-sufficiently in the right place in the company. Incidentally, here is a small digression to the “Peter Principle” quite amusing. But I want to concentrate more on the group dynamic aspect.

The dilemma.
As with any innovation, its manifestation and burgeoning acceptance, so to speak creates a generational conflict. If the current protagonists of this culture are, almost without exception, supporters and optimizers of this agile system, there will be a radical discourse for a new kind of corporate structure in the future as well. When? Soon! Relative to our desire to make our participation in the entrepreneurial activity completely uniform and decisive. Because that’s where single individuals try to take the majority to lived self-determination. Then at least e.g. almost every meeting would have a really measurable result. 🤭

Does that automatically include a forced change? I think you have to use the needs and their changing meaning for humans. After all, it was all about survival at first, but in the future, it’s all about not drowning in the mush of the growing mass of potential workers. Prince Lev Nikolayevich Myshkin could certainly be used as a paradigm for a playful and beneficial naivety and, so to speak, a relaxed attitude to life, but so much smart serenity is generally unlikely to be expected. And you and I are full of aspiring ambitions!

Accordingly, the need for a seamless lifestyle that unites both the private and the business. This now applies tangible and more manageable for us. In order to achieve this, thinking and acting must be equated strategically and tactically with an entrepreneur. The modulation of these two life parallels requires a revolutionary act. The employee of today already carries the seed in itself. Not only the claim to shape his working environment according to his needs becomes clearer, no, also the desire for the determinability of his own work, at every convenient time. Hierarchies of today will disappear (the so-called flat hierarchies seem to serve me rather as bread and circuses instrument).
The top and the bottom will remain at a logical level. It is about the personal benefit and the equal distribution of personal claim (profit) in its existing phase of life. Certainly, the fight of transition to such a new system will not be easy, because man is often a little narcissist and the envy in the way preventing. The “New” need reliable friends!

It will again lead to the formation of a new social order, which, however, does not, as it once did, take its impetus from individuals, but represents participation in a global cultural process. Of course, this is more than worrying, but you probably will not even notice, because you’ve always been involved in a change process: Evolution.

So far, all of it has been pretty daring theory and you can also give up irony or cynicism 🤫 here if you have a sense of humour. However, it would be totally overstated to see a reissue of a “labour power” or a dissolution of any democratic aspect. It will simply be the next evolutionary step. There are branches that will eventually cease to exist. But in best case, a new one could emerge before this end.

How could this be in the distant future?
Any demand-driven venture will be reduced to a few but stable organizations. There will only be more or fewer entrepreneurs. Ensuring production and service will be the driving force for all. Each participant joins according to his abilities but is paid in equal parts. There will be no more reward in its monetary form. The remuneration is rather the assurance and availability of other services. Here, not the weakest link determines the beat, as it is e.g. for some scrum teams today, but the sole urgency and benefit to the common good. It automatically uses the right and necessary resources. The self-determined freedom seems to be more than tempting, but now everyone can suffer an entrepreneurial defeat. The motives to succeed are a true basic need. No safety-net but many new opportunities and potentials to enrich his life through his contribution to the community.

In the end, I want to sprinkle a lot of positive energy over the whole thing.
After all, so-called agility has actually given us more courage and freedom in thinking. It is the key to opening the door that will lead us into a new era. The question of whether this article will now have a direct benefit, I would deny. It is also unlikely that a current entrepreneur will engage in radical new concepts in the short term. The dangers for the company and also the social responsibility are simply too big. Also, I can imagine a momentary separation of powers and equal distribution of the consideration, very difficult. Too many dependencies, even in a small artificial trial environment, determine our actions. 🙋‍♂️ But …

It is important for me to offer both the employee and the entrepreneur a world full of new perspectives and exciting opportunities. It may be that I have dealt with this topic too superficially, but I would be happy to receive more opinions and ideas from you. Only those who do not completely ignore the suggestive future will most likely remain successful. In this sense…

stay agile!