Waterfall or Agile – Reflections on Winston Royce’s original paper

If you are like me, at some stage you learned about the Waterfall methodology. Often the source of the waterfall methodology is attributed to Winston Royce and his paper: “Managing the Development of Large Software Systems”. Recently I have heard many people speak about this paper and imply that it has been misunderstood by the general audience. Rather than prescribing Waterfall it was actually recommending an iterative (or shall we call it Agile?) approach. I just had to read it myself to see what is behind these speculations.

I think there is some truth to both interpretations. I will highlight four points of interest and provide a summary afterwards:

  • Fundamentals of Software Development
    I like the way he starts by saying that fundamentally all value in softwareroyce 2
    delivery comes from a) analysis and b) coding. Everything else (documentation,
    testing, etc.) is required to manage the process and customers would ideally
    not pay for those activities and most developers would prefer not to do them.
    This is such a nice and simple way to describe the problem. It speaks to the
    developer in me.
  • Problems with Waterfall Delivery – He then goes on to describe how the Waterfall model isroyce waterfall fundamentally flawed and how in reality the stage containment is never successful. This pictures and the caption is what most Agile folks use as evidence: “Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps.” So I think he again identifies the problem correctly based on his experience with delivery at NASA.
  • Importance of Documentation – Now he starts to describe his solution to the waterfall problem in five steps. I will spare you the details, but one important point he raises is documentation. To quote his paper “How much documentation? My own view is quite a lot, certainly more than most programmers, analysts or program designers are willing to do…” He basically uses documentation to drive the software delivery process and has some elaborate ideas on how to use documentation correctly. A lot of which makes complete sense in a waterfall delivery method.
  • Overall solution – At the end of the paper he provides his updated model and I have to sayroyce 3 it looks quite complicated. To be honest many of the other delivery frameworks like DAD or SAFe look similarly complicated and we should not discount it just for that reason. I did not try to fully understand the model, but it is basically a waterfall delivery with a few Agile ideas sprinkled in: Early customer involvement, having two iterations of the software to get it right and a focus on good testing.

Summary – Overall I think Winston identifies the problems and starts to think in an Agile direction (okay Agile didn’t exist then, but you know what I mean). I think his
approach is still closer to the Waterfall methodology we all know but he is going in the right direction of iterations and customer involvement. As such, I think his paper is neither the starting point of the Waterfall model nor the starting point of an Agile methodology. I think a software archaeologist would see this as an inbetween model that came before its time.

7 thoughts on “Waterfall or Agile – Reflections on Winston Royce’s original paper

  1. Mark McLaughlin

    Mirco you also have to keep in mind some of the constraints that were in place from a hardware perspective at the time and the type of systems they were building.

    Often they were building software that you would not be able to modify. For example embedded control systems. Nowadays even these are upgradable in most cases so if you do make a mistake you can fix it. In those days it was often not possible to do that.

    Also these were often man-rated systems. Peoples’ lives depend on the software working correctly. So the whole system has to work perfectly with release 1.0. This still applies to a lot of software projects today.

    Yes in this both cases you could use Agile practices during development but you do only get one shot at the release.

    (Also – the images in your article don’t show unless you are logged on to Accenture)


    1. Mirco Hering Post author

      Thanks Mark for your comments. And yes it was written in a different time, but I think it is helpful to sometimes go back to the roots to understand the history. And yes I have fixed the pictures, thanks for pointing this out. Need to change my process so that it doesn’t happen again.


  2. Tina M. Kister


    I’m writing an article, and trying to obtain permission to use the same images you have used here from Royce’s 1970 article). Can you please tell me how you obtained permission to use them? I can’t find the article on the IEEE website.

    Thank you!


  3. Pingback: What, if anything, is new about DevSecOps? – Acquisition Talk

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

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