Agile, DevOps, Lean, Scrum: these are all applicable to software development frameworks we talk about these days. With a derisive sneer, we tend to refer to anything that’s pre-Agile as outmoded Waterfall. However, it is not accurate to label “Waterfall” to all that is pre-Agile. It is important to understand how we got from Waterfall to our more modern approaches, and how Waterfall originated. So let’s begin by harking back to 1970, then looking only at methodologies that precede Qualitest’s 1997 origin.
1970 began with the first moment of UNIX time (UTC) and would see the inventions of the floppy disk and the home VCR. It would be another year or two before laser printers, email, LCD’s, and Atari’s Pong would appear. So, in 1970, Dr. Winston W. Royce published an IEEE paper called “Managing the Development of Large Software Systems”. The Waterfall method we’ve all learned is based on this (or so we’ve been told). The Waterfall method depicts a non-iterative sequence of “Requirements => Design => Implementation => Verification => Maintenance” or “Plan => Build => Test => Review => Deploy” which resemble shortened versions of his Figure 2. Royce immediately follows this with, “I believe in this concept, but the implementation described is risky and invites failure” and never uses the word “waterfall” anywhere in his paper. He goes on to observe that “if these phenomena fail … then … a major redesign is required.” So, everything we think we know about Waterfall is wrong, as the paper proceeds to push for being iterative, incremental and showing multi-directional flow through the project management steps. In 1992, he’d write a paper on computer-aided prototyping! What I find exciting in his 1970 breakdown is his definition of testing (hey, I am a tester) in Figure 8, which includes inspecting code:
But enough about that. The Waterfall method is known today as a sequential non-iterative technique where each step must be finished before proceeding to the next, where you can’t go backward, and you can’t restart the whole process. The downfalls (non-iterative, can’t go backwards or restart) are rather apparent. But keep in mind, as said, that the method’s credited/blamed founder understood those flaws and knew better. Perhaps it is better to think of “iterative waterfalls” where the flow is less limiting, which includes the concept of work sprints/life cycles.
Daniel D. McCracken and Michael A. Jackson (not part of a famous singing family) wrote an ACM article called “Life Cycle Concept Considered Harmful” that bashes Waterfall for its “project management structure imposed on system development”, exclusion of user and customer experience involvement, and lack of agility. Helpful suggestions in this paper include prototyping as a basis and greater UX involvement at all project management steps.
Moving past Waterfall, the next popular methodology came along in 1986 and is called V-Model. Like Waterfall, the life cycle is a sequential path of processes. Time moves across the V (rightward is more complete) and vertically indicating the level of abstraction (uppermost is coarsest). The left side plus middle is Project Definition (lots of planning followed by Implementation, the finest-grained level of abstraction), while the right side is Project Test and Integration. You can think of the coarser abstraction as being more high-level, and that the V’s right side partner tests what was design/defined directly to its left on the V. It works worst for very large projects and those where the requirements may undergo drastic change.
(picture from Wikipedia’s definition of V-model (software development))
In 1991, something so radical happened to software development that it had to be called RAD (Rapid-application development). Structured approaches like Waterfall and V-Model were great for building physical structures, but software would often change direction more like a flock of birds or a swarm of bees, and sometimes you need to prototype before the design has been decided. It works well for when you know what the UI basically looks like and what it is supposed to do, but don’t care about the magic of how it is done inside the box. IBM’s James Martin (not the idea originator) constructed the approach we know today in his 1991 book (less expensive later editions are available) which stresses prototyping, reinvention and risk reduction from shift-left benefits as a “think outside the box” approach. RAD is good for quality, risk control, flexibility, good for smaller projects, and tends to come in on-time and on-budget. However, people need to adapt their skills to the format, it is harder for people to share their time with other projects, lacks scalability, and may favor minutiae over “big picture” design.
(Wikipedia’s diagram of RAD)
Gosh, now that we have solved the rigid structure problem, what could possibly come next? The answer is WinWin Spiral. Barry Boehm, who had a hand in early thought on what became RAD is credited with creating Spiral (papers published in 1986 and 1988) among many other accomplishments and publications. I’ve seen the year 1994 attributed to the “WinWin” version. Before RAD, Spiral emphasized repeated revisits to different development tasks. Like Waterfall, there are misconceptions about Spiral, which is in fact a) not a multi-sequence of waterfalls, b) not a single spiral sequence, and c) rigid in processes used or in process order. So what is it then? It is risk-driven and accommodates any mixture of spec-oriented, simulation-oriented, prototype-oriented, automatic-transformation oriented or other approach to software development, and both user and customer are included as stakeholders involved in the decision-making process. OK, not the most helpful definition. Here are the six ground rules (called “invariants”):
WinWin Spiral produces software incrementally, so problem discovery time is close to stakeholder definition time, catching problems early in the overall process. However, you must commit high-level people from different functions to move things along. This project type works best for large projects. “WinWin” involves the stakeholders getting what they want in exchange for cycle commitment. I feel like I’m writing about an ancestor of Scrum as I write this, and does that outer loop in the lower right below remind you of Waterfall?
(Wikipedia’s diagram of Spiral)
So we have Waterfall, credited as having been created by someone who knew its flaws. We have RAD which works well for small-scale projects, and WinWin Spiral which works well with big projects. We’ve seen concepts which we know advance to more modern theories on testing methodology. We’ve come to recognize that regimented procedures are not the final word on project management and that user experience is a worthwhile component. And then we have everything that came after Qualitest Group came into being, but that is a topic for another time.
