No such thing as "Waterfall"
Back in 1970 a man named Winston W. Royce published a paper with IEEE entitled, "Managing the Development of Large Software Systems" [1]. He begins, "I'm going to describe my personal views about managing large software developments." and goes on to do exactly that. He shares his experience of what worked for him, and what did not.
Interestingly, it is this paper which is often cited as the source of the term "Waterfall", a term that has been used ever since to describe an approach to implement a software system—as if Royce himself endorsed it. He didn't. Indeed, Royce uses the term "waterfall" exactly zero times in his paper. He did however include this picture.
It is the second diagram in his paper, and the first to include all the phases of the process. It seems that most readers got as far as this diagram, maybe read the description, and decided there was no need to read further. These are the steps to develop a large computer program, they decided. It says so here. Let's get going.
Had they bothered to continue, the very next sentence would have given pause for thought: "I believe in this concept, but the implementation described above is risky and invites failure". It seems few did—either read, or think—and Waterfall as an implementation method was born. A paper that essentially advised "Don't do this" was understood as saying "Do this". Such is the power of sliver-bullet thinking.
Royce's paper is well worth reading to the end. We can see from the successive diagrams that indicate feedback and frequent iteration, that what Royce is describing is something akin to the agile approaches we recommend today. It becomes very clear in this final picture.
领英推荐
Those that advocate "Waterfall" for software development are actually not following these 1970 recommendations at all, but something much older, something like a manufacturing process that grew up during the industrial revolution (1760–1840). A more general term for the approach would be "defined process". A defined process works well when what we are making is a copy (or millions of copies) of a thing we made before.
No software system has ever been made before. Each one is new. Each one is unique and designed for a specific purpose. We cannot define an exact process to make a thing that has never been made; it is actually impossible, and it takes magical thinking to believe we can.
Developing new products require emergent processes, not defined ones. They require feedback, iteration, inspection and adaptation. This has always been the case. It has never not been the case. It isn't the case now.
—
[1] Royce, W.W. (1970) Managing the Development of Large Software Systems. Proceedings of IEEE WESCON, 26, 328-388. PDF version available here .
Head of Projects at Avanceon ME & SEA | LUMS EMBA '24 Gold Medalist | PMP?, TüV FS Engineer SIS | Program Management (Conventional/Agile), Business Strategy, Financial Management | Design Thinking & Customer Centricity
1 年Quick questions: 1. How would you justify the emphasis on thorough documentation, as indicated on Page 5/11 and in the screenshot below? 2. Why did Royce emphasize the Big Design Up Front approach, which is an inherent requirement of the Waterfall methodology, despite its limitations?
I agree with your position, mostly. But let's not forget his essay also, unfortunately, reinforced key elements of the Waterfall myth: · Royce argued “begin the design process with program designers, not analysts and programmers”. · And “ensure that a preliminary program design is complete before analysis begins”. To understand the context of those suggestions, and to understand why Royce had not yet abandoned the Waterfall myth entirely, it helps to remember that computers were the size of trucks and the cost of change was extremely high. A design flaw discovered late in development was expensive and time-consuming: much more than changing a few lines of code, imagine having to disassemble a truck-size computer, manufacture new components, and rewire entire electrical circuits. He argued it was necessary to spend the requisite time designing with chalkboard and paper before employing analysts and programmers (i.e., the people who assembled the hardware, operated the keypunch machines, catalogued the punch cards, and ran the programs). Many readers of his essay concluded that segregated sequential phases are necessary.
Professional People Geek | Author | CEO | Certified Scrum Trainer | Facilitator | Agility Guide & Mentor
1 年Thanks for posting. I point out this fact from 1970 all the time in #csm workshops. Reading comprehension goes a long way. Too many look at a picture and make assumptions.
Curating valuable patterns for customer-centric people driven Product cultures. Enabling flow from action to evolve out adaptive organizational ecosystems.
1 年Tobias Mayer if you look at the article he also says do all the steps at least twice. And the second time you’ll be closer to what the customers might want. Even with possible big batch it was recommended to have two full iterations. Something conveniently forgotten and assumed as first time get it right.
Certified Scrum Trainer. Agile & Lean Consultant.
1 年Yes, Tobias, Royce goes on to describe an approach that is both iterative and incremental, with early increments focused on critical areas (i.e. doing the risky bits first). He even advocates customer collaboration. Quite shocking really and I doubt it will ever catch on ;)