The Scrum Framework — Second Edition

This chapter retains the second edition’s historical and practical teaching context. The third-edition curriculum is also available in the contents below.

---

Why Can the Waterfall Software Development Model Fail? - International Scrum Institute

Studies have shown that in over 80% of the investigated and failed software projects, the use of the Waterfall methodology was one of the key factors of failure. But why?

Phases in the Classical Waterfall Software Development Model

As shown above, when deploying the waterfall methodology there is a strict sequential chain of the different project phases. A previous phase has to be completed before starting the next phase. Going back is in most cases difficult, costly, frustrating to the team and time-consuming.

The project timeline is planned at the start. A releasable product is delivered only at the end of the project timeline. If one phase is delayed all other phases are also delayed.

To avoid this users of the waterfall methodology normally try to anticipate all possibilities beforehand. This means that in one of the earliest phases of the project they try to define all requirements in as much detail and as completely as possible. However, requirement definition in such an early phase of the project is often very difficult and therefore many requirements change (or should change) throughout the project. Studies have shown that in larger, complex projects about 60% of the initial requirements are changed throughout the project. Other requirements are implemented as defined but are not really needed by the customer and consume valuable time that could have been better used to implement functionality with a higher added value for the customer.

The separation into different project phases forces users to estimate each phase separately. The problem is that most of these phases are normally not separate. In practice, the activities often overlap and influence one another.

The waterfall approach for developing software can be used for implementing small and simple projects. But for bigger and more complex projects it can be said that this approach is highly risky, often more costly and generally less efficient than the Scrum framework.