Why is waterfall better than agile

Career & Salary

Agility is a catchphrase that has captured almost all companies. At the decision-making level, the topic of business agility, i.e. the agile way of working in a company, is becoming increasingly important. As a result, companies try to significantly increase their innovation and adaptation speed with the help of appropriate initiatives - especially in software development. Against developments in the quiet little room and far away from the commissioning specialist department, agility should also provide a remedy here. Before project managers blindly trust the promises of Scrum and Kanban, it is important to understand the ideas behind the methods and adapt them to the company.

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

• Waterfall, that means the development of software successively in stages with feedback.

• The V-model, which includes the integration of the aspects of quality assurance in the waterfall model.

• Evolutionary or incremental models, i.e. the gradual development of the software product and

• As a further development from this, today's common agile methods such as Scrum.

In the meantime, the trend is clearly 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 come onto the markets.

A look at the Fortune 500 companies reveals the impact of market changes on businesses and the need to adapt. And that in ever shorter cycles in order to survive in the market. In many cases, digital natives 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 German companies.

  1. Product & project manager
    In general, developers don't particularly appreciate it when someone tries to explain to them how to do their job. But because product and project managers often lead development teams, that's exactly what happens. That can lead to discrepancies.

    David Fox from devRant also has an opinion on this: "Ultimately, in most cases, product and project managers are in some way the 'owners' of projects and processes without being involved to know the daily challenges and problems faced by software developers. "
  2. Bosses
    Just like product and project managers, development or engineering managers are responsible for leading teams of developers and ensuring that projects are completed on time and under budget.

    "In some companies, situations can arise where the boss is also a member of the development team. Especially if the boss was a developer himself and becomes boss after a promotion, there is potential for conflict," notes Fox .
  3. Recruiters
    Software developers don't have to actively look for a job themselves in order to be harassed by recruiters and headhunters - thanks to the shortage of skilled workers. It would be very difficult to find a developer who has not yet fallen into the clutches of recruiters.

    David Fox especially sees the persistence of the recruiters as a problem: "They call, email and they just won't leave you alone - even if you're not looking for a job. And even if If you are looking for a job, many recruiters tend to make irrelevant job offers or recommend positions whose profile does not fit at all - for example a job on the other side of the country, even though you are not ready to move. "
  4. documentation
    If there is no documentation, the software developers complain. If it's too much, they complain, and if they have to do the documentation themselves, too. Even the developers are complaining about the way other people handle the documentation task.

    At this point, all developers finally agree, as Fox emphasizes: "Software developers want detailed, well-written and accurate documentation - but they don't want to do it themselves."
  5. Meetings
    Meetings are a problem not only for everyone else, but also for software developers. Especially when it comes to completely unnecessary, time-consuming and utterly boring get-togethers. As Fox explains, devotional objects with the inscription 'I survived another meeting that should have been an email' are now also available.
  6. Coworking spaces
    With the rise of agility, flat hierarchies, collaboration and teamwork have become part of everyday life in companies - especially for software development teams. But it is precisely these people who usually find it difficult or impossible to cope with their work in an open-plan office - at least that's what the devRant figures say.

    David Fox explains: "There are just too many distractions: colleagues are chatting, meetings are missed, phone calls are overheard. There are also a number of complaints about coffee in the office and other amenities - or that Opposite of that. "
  7. colleagues
    Self-explanatory: everyone has a colleague whom they particularly value. Not.

    In the case of software developers, the aversion to colleagues is usually based either on the poor quality of their work or an ego that is completely out of sync, reveals David Fox.
  8. Job interviews
    When a software developer is looking for a job and is invited to an interview, there is usually something to complain about afterwards:

    "The developers get just as angry as one with stupid questions or the solution of completely unpractical tasks in the job interview Interlocutor who doesn't even know what a developer is actually doing, "says Fox.
  9. Errors & bugs
    Software developers deal with errors and bugs day in and day out. That is why devRant founder Fox believes that developers think differently on this matter:

    "Most other problems are not resolved positively, but bugs and errors can be fixed and that feels good."
  10. Quality assurance
    Quality Assurance (QA) - or quality assurance - is a critical part of software development. Still, software developers often complain about the same things about QA experts as they do about product and project managers, according to Fox.

    "Quality assurance gets its hands on the product or project when the developers have completed it. This is why they often do not understand the hurdles and workarounds the developers had to overcome in the development process. Obviously, it also happens regularly that QA people are asking developers to revise areas that they could do themselves. "

Waterfall as a swear word

Against this background, "waterfall" is almost a swear word and a sign that companies that still use this method of software development have not yet arrived at the modern age. However, please note:

1. No software methodology is good or bad per se. Rather, it must always be about choosing the right methodology for the right product and the given framework. It has always been like this. Unfortunately, it is often the case that in-depth knowledge of the various methodologies and their implementation is not available. In addition, the hope for the "one methodology" that solves everything seems to lead to undesirable simplifications.

2. Waterfall is nowadays 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, so the criticism, the departments would be presented with the software much too late, changes would be very expensive and flexibility would not really exist. With this in mind, it is worth reading what the waterfall method really says. In 1970 Winston W. Royce published his paper "Managing the development of large software systems", making him one of the founders of the waterfall method. When reading it, it becomes apparent that for Royce, documentation is an absolute key factor in the development of software. This seems to be contrary to today's agile methodology. However, the following should be considered here:

• On the one hand, the well-known Agile Manifesto does not speak of not needing any documentation, but rather gives "working software" a higher weight than "comprehensive documentation".

• On the other hand, the level of documentation required always depends on the type of system to be developed.

Royce dealt in his work with 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 noteworthy that Royce recognized the risks of his waterfall methodology back then and also proposes in his paper how this risk can be minimized, namely through the

• Creation of a vision and an initial design of the target product to be achieved at the beginning of the project,

• Creation of an early prototype in terms of executable software that is constantly being further developed, and

• Involvement of the end customer in every phase of the development process.

Today, all of these things are more likely to be ascribed to the "agilists" camp.

It should also be noted that many of the concepts behind today's agile approaches are not necessarily new. At the heyday of the mainframe, the developers usually interacted directly with the specialist departments and new product versions were switched live in small cycles. Unfortunately, in the age of industrialization and CMMI, numerous hierarchical structures and processes have been introduced that have further and further removed the developer from the end user.

Agile principles

To be clear: The agile principles are indispensable for companies today. The age of industrialized software development has led to many excesses, which have been corrected by the agile movement. This is elementary, correct and a basic requirement in order to implement the actual topic - namely to make the company as a whole "more agile" - and to significantly increase one's own speed of innovation.

However, it is important not to fall into the trap here and blindly trust a methodology such as Scrum or SAFe. Much more crucial than the methodology are the principles behind it, understanding them and adapting the methodologies to your own situation with experienced people. And agile software development, on the other hand, is only a small component of a real agile company.