The archetypal diagram of waterfall model was attributed to Royce 1970s work[1] which in contrary addressed the risk of uncovering problems late in testing phase of the development when you obediently wait for each previous phase to close. He expressed it in another diagram, nevertheless a least famous one, emphasizing “do it twice” instead.
Imagine hearing testing-early followed by more testing. That’s twice. Waterfall is incredibly intuitive for us, that “twice” considerably means ineffective doubling of execution and cost. Henrik Kniberg moreover offers looking at shorter total time vs seeing it as wasting two times[2]. Shortening cycle time for value to reach the customer is thus being effective here.
Let’s also be honest that when trying to move to iterative mode, what usually happens is that testing gets squeezed to the late-end (a.k.a. mini-waterfall), dragged to supposedly next iteration, and finally release is further “behind”[3].
To leave the argument, time travel to 1980s brings GM and Honda stories where one of the differences was on having tester involved even early in design[4].
Next read [[tester in planning]]
References
[1] W. W. Royce, “Managing the development of large software systems,” Proceedings of IEEE WESCON, pp. 1–9, Aug. 1970.
[2] H. Kniberg, Lean from the Trenches: Managing Large-Scale Projects with Kanban. Pragmatic Bookshelf, 2011.
[3] L. Crispin and J. Gregory, Agile testing: A Practical Guide for Testers and Agile Teams. Pearson Education, 2008.
[4] M. Poppendieck, T. D. Poppendieck, and T. Poppendieck, Lean Software development: An Agile Toolkit. Addison-Wesley Professional, 2003.
