SAFe — Scaled Agile or Niagara Falls?
The term waterfall has been used since Winston Royce’s original 1970 paper. The paper Managing the Development of Large Software Systems describes the typical waterfall process as a risky and inviting failure.
The waterfall process relies heavily on initial requirements. However, if these requirements are not documented precisely, or there was a misunderstanding around the detail of what the customer wanted, it makes things very difficult. Unless the customer can really see and touch what is being built, the end result can be surprising.
The same problem happens between each transition of the phases. Very often different people are doing the work related to each of the boxes, so misunderstanding is easy. If the handovers are eliminated and the team is engaged since the beginning of the project, the risk is lower.
Testing is done last. At that time problems in any previous of previous phases can manifest — impossible or very expensive requirements, performance problems, or wrong design. The only chance to get everything right is to do the exact same project for the second time. If you are solving a novel problem or making an innovative solution, it is not possible to know many things up front, and an iterative and adaptive approach works much better.
