The Story of Waterfall Processes

In 1970, Winston W. Royce describes a model of a sequential design process. He presents this model as an example of flawed, non-working model in his paper Managing the Development of Large Software Systems.

I believe in this concept, but the implementation described above is risky and incites failure. In my experience, the [..] method has never worked on large software development efforts [..]

It became the model for a widely used process called Waterfall.


Winston was very aware that this easy approach of sequential analysis, design, implementation and test is very risky and he proposed five additional features to the model.

Nevertheless, most of the people at the time stopped to read on after the first page and obviously never came to the warnings that Winston expressed. 😉 The model became very popular even for complex software projects where it is not possible to gather all the requirements right from the start (the Cynefin model shows that – more in a later article).


Additional Features

So Winston proposed to add this features to the model (he never called it waterfall)

 1) A preliminary program design phase

Create an overview of the system that should be implemented and talk to everyone about it. In Winston’s time it was mostly about time and storage constrains.  “Each and every worker must have an elementary understanding of the system”.

In today’s agile processes, we create initial mock-ups or prototypes. We have kick-off sessions like story mapping or inception desk sessions to bring everyone on the same page.

2) Document the design

Winston proposes to document a software design quite heavily. 1000 pages for a 5 million dollar project seems to be about right. He fears that verbal communication is intangible to prove an adequate basis for interface or management decisions.

Well, even today, documentation is not excluded from any software projects at all. But documentation is not longer the first citizen for communication as it was for Winston. We can indeed learn from written text and documents to build up our tacit knowledge which allows us to work efficient. But there are better ways to learn. Collaboration with customer or cross-functional teams are just two agile principles.

3) Do it twice

From the preliminary design, a prototype should be created. Winston proposes to do the whole process in miniature at least two times. An initial walking skeleton, as we call it in the agile domain, is a first proof of concepts, deals with the highest risks and gives a minimal viable product for our customers to give feedback to.

4) Plan, control and monitor testing

Well testing was and is a very important aspect. This days, software engineers write their unit test even before they start to write code. Acceptance test frameworks are in place and run automated and regularly. Statical code analysis, trend analysis and various other ways try to reduce the amount of errors getting into a software project.

5) Involve the customer

Winston is aware that software designs are subject to wide interpretation even after previous agreement. So he suggested to involve customers regularly. For that, a dedicated person (we call her the product owner (PO)) is representing a wider audience of stakeholders. But other users are also invited to give feedback on a regular basis during so called sprint reviews or show & tells.


A waterfall process is probably the right thing to do if you have a simple problem at hand (like baking a cake or building a garage) but as soon as a project gets bigger and more complicated, waterfall would require all the features that Winston Royce proposed. All are covered in modern software development processes in a more natural way. So you might be better off with one of the agile approaches. 😉

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.