Agile versus Waterfall in Real Life

In software development, the waterfall model is now considered to be frowned upon and antiquated. But waterfall has connections to the agile methodologies. Agility is a catchphrase that has affected almost all companies. At the decision-maker level, the topic of business agility, i.e. the agile way a company works, is becoming increasingly important. As a result, companies are trying to significantly increase their speed of innovation and adaptation with the help of appropriate initiatives -, especially in software development. Against developments in the quiet closet and far away from the ordering department, the agility should also help here. Before project managers blindly trust the promises of Scrum and Kanban, it is important to understand the ideas behind the methods and to adapt them to the company.

Since the beginning of modern software development, there have been various approaches to creating software. The best known and most widespread methods in the past ten years are:

• Waterfall is the development of software successively in stages with feedback.
• The V-Model, which includes the integration of quality assurance aspects into the waterfall model.
• Evolutionary or incremental models, ie the gradual development of the software product and
• As further development of today’s common agile methods such as Scrum.

In the meantime, the trend is moving towards agile as the de facto standard for building modern software, with Scrum and Kanban dominating as the methods used. One reason for this development can be seen in the speed with which new business models, as well as products and services, are entering the markets. A look at the Fortune 500 companies shows the impact of market changes on companies and the need to adapt. And in ever shorter cycles to survive on the market. Digital natives often dominate the market and have conquered it with modern working models. These companies bring innovations to the market at much faster intervals than many of the established companies.

Waterfall as an offensive phrase

Against this background, “waterfall” is almost a dirty word and a sign that companies that still use this method of software development have not yet arrived in modern times. However, please note that:

1. No software methodology is good or bad per se. Rather, it always has to be about choosing the right methodology for the right product and the given framework. It’s been like that forever. Unfortunately, it is often the case that in-depth knowledge of the various methodologies and their implementation is not available. Also, hope for the “one methodology” that solves everything seems to lead to undesirable simplifications.
2. Waterfalls are often described verbally as follows: “Requirements are recorded for months, then the software is built for months and only then does the specialist department see the software as part of the test.” In this scenario, the criticism, the specialist departments would be presented with the software much too late, changes would be very expensive and flexibility would not exist. Against this background, it is worth reading what the waterfall methodology says. Documentation is a key factor in the development of software. This seems to be contrary to today’s agile methodology. Here is what to consider:

• On the one hand, the well-known Agile Manifesto does not speak of not needing any documentation, but simply weights “Working Software” higher than “Comprehensive Documentation”.
• On the other hand, the required level of the documentation always depends on the type of system to be developed.

Royce was involved in the creation of software for the planning, implementation and analysis of space missions. One can imagine that such systems require a very high level of documentation. It is also remarkable that Royce already recognized the risks of his waterfall methodology at the time and also proposed in his paper how this risk can be minimized, namely through the

• Creation of a vision and initial design of the target product to be achieved at the start of the project,
• Creation of an early prototype in the sense of executable software that is constantly being developed, and
• Involvement of the end customer in every phase of the development process.

All of these things would be ascribed to the “agilists” camp today. It should also be borne in mind that many of the concepts behind today’s agile approaches are not necessarily new. At the wedding of the mainframe, the developers generally interacted directly with the specialist departments and new product versions were launched live in small cycles. Unfortunately, however, numerous hierarchical structures and processes were introduced in the age of industrialization, which has removed the developer from the end-user.

Agile principles

To put it bluntly, today’s agile principles are essential for companies. The age of industrial software development has led to many excesses, which have been corrected by the agile movement. This is elementary, correct and a basic requirement to implement the actual topic – namely to make the company as a whole “more agile” – and to significantly increase your speed of innovation.

However, it is important not to fall into the trap here and to blindly trust a methodology such as Scrum or SAFe. The principles behind understanding these and adapting the methodology to your situation with experienced people are much more important than the methodology. And agile software development, in turn, is just a small building block towards a real agile company.