Pitfalls of Waterfall
By far, Waterfall is the most dominant method of building software. In Waterfall model, software development happens sequentially. Each step of the process is executed one after the other in a sequential manner. The results of each step of the process is input to the next step. If this process is depicted pictorially, it would look like waterfall. Hence, the name, Waterfall model of Software Development as shown in the figure below.
This scheme of things is very logical and elegant. Many projects even to this day, still follow this method to build the software. The results are not what we expect them to be. According to various surveys (including Standish Chaos report and Ambysoft) the success rates of Software Projects are not too high. Waterfall is not delivering the success rates of projects that we expect. There are many reasons why this happens with Waterfall model.
Changes in Requirements
Requirements that have been finalized during the requirements analysis phase are expected to remain unchanged throughout the later phases or project execution in Waterfall model. But in reality, requirements change all the time and even during the last phases of the project. There are many reasons for this.
As stakeholders get involved in analyzing the project over a period of time, they get new ideas for improvements and new features. Other changes in the external environment also can contribute to change in requirements. For example, competitive landscape may change. New regulations may be imposed by governments. In such circumstances, requirements change out of necessity. Waterfall model encourages what is known as Big Design Up Front approach. Here, the design is done only when requirements are frozen. If any ideas come later, it means a huge rework of the design and price of changes in requirements keeps on escalating as project progresses further into later phases.
Working software is ready, late in the life cycle
One other big problem with Waterfall model is that working software is ready only at a very late stage. Any sort of working software is demonstrable only after integration phase is done. This is the time at which end user or customer can get to see working software for which the requirements were agreed upon. In many cases, the way software works may not be what was expected by the end user despite the fact that the software was built based on the requirements agreed upon previously (it is extremely difficult to accurately represent requirements by writing them in requirement documents and far too easy to misunderstand these requirements).
Surprises occur late in the cycle
Sometimes, surprises can crop once the software is built. Many times, architects and designers miss out on the implicit and non-functional requirements such as performance etc. Once the system is integrated and tested, these issues come to light and it is very expensive at this stage to engineer solutions to these problems. Quite often, there are issues in integration process as well, as modules are developed independently by different teams and these modules are put together for the first time only during integration. If there were any misunderstandings of interface design by different teams, then modules do not interwork and changes will have to be carried out to make them work.
Another kind of surprise that is often encountered during software development, is in the implementation phase. While design may be ready to be implemented, the team runs into problems during implementation according to the design. This can happen because of invalid assumptions about tools and technologies that will be used.
Common result of these unexpected events occurring such as the ones described above late in the cycle, is that the schedule is overrun and cause a cascade of problems. In most of the projects, the later phases happen to be the most stressful period for the team as well as management due to unabated flow of bugs being reported and heroic efforts of developers to fix those bugs within the release deadline (assuming the release deadline is not past yet). Problems in each phase is depicted in the figure below.
Problems with waterfall
Benefits of Scrum
Scrum is one of the most popular and widely utilized of the Agile methodologies available. Scrum is a framework which if utilized properly, can overcome the challenges associated with Waterfall model. Scrum requires that software be developed in iterative and incremental manner as opposed to Waterfall model of software development. Using Scrum, small increments of software are delivered periodically which are in deliverable state. This minimizes many of the problems that occur during software development while using traditional approach. Working software becomes available for demonstration quite early. If software is demonstrated to customer, lot of ambiguities regarding requirements can be cleared away. Iterative development helps in the cutting down of risks associated with surprises that normally occur during later phases in a traditional model of software development.
Scrum also stresses a set of values which encourage the team to become empowered to take responsibility and deliver working software iteration after iteration regularly. Scrum also requires constant improvement by following the idea of “inspect and adapt”. It means that every iteration, team inspects both the product it has produced as well as the process it has followed and changes things so that team can adapt as required so as to improve performance in the next iteration. Consequently, Scrum, if followed in a committed manner can prove to be of immense value in delivering value to the customer. For the team, Scrum will provide a very satisfying work environment in which the team can perform highly effectively and work productively and at a sustainable pace.
Various stakeholders benefit:
- Team members have a conducive and supportive environment to work, which in turn keeps them motivated, and hence benefits the customer.
- There is the effect of heightened visibility of the progress made and the quality of work done, due to a well conducted reviews at regular intervals. This is the most important benefit from a customer perspective, as the true progress of the project is known and hence a much better stab at controlling the project can be taken.
- Due to visible progress and people working for well recognised goals, usually Scrum teams attain a significant improvement in productivity.
- Scrum executed well means that customers have much better control and with correct reporting (not reporting which accounts for the wishful thinking of management) can have realistic information. Based upon this remedial action can be taken earlier than otherwise possible.
In the next chapter, we examine the practice of Scrum in much greater detail and how Scrum delivers for both customers as well as the team.