Agile vs. Waterfall Model

HOW WATERFALL PROJECT WORK

The waterfall model is the oldest and mostly widely used model in the field of software development. One of the biggest disadvantages being client is not very clear on what exactly they want from the software. Any changes that he mentions in between may cause a lot of confusion, which is also depicted in the slide. If that is the case and it arises baseline approach is followed, wherein output of one phase is carried forward to the next phase. For example even if SRS is not well divined and requirements cannot be freezed, still design starts. Now if any changes are made in SRS, then formal procedure is followed to put those changes in baseline document. Also until the final stage of the development cycle is complete a working model of the software does not lie in the hands of the client. Thus, he is hardly in a position to inform the developers if what has been designed exactly what he had asked for.

WATERFALL’S DEMISES

Let’s now understand and look in detail where did waterfall fail. Waterfall is a serialized process. There is strict sequential chain of the project phases. A previous phase has to be completed before starting the next phase. The waterfall PMP methodology and Agile Project management methodology are explained covered in the project management courses. Going back is in most cases difficult, costly and time consuming.

1. Planning far in advance:

Products no longer match reality by the time they are released.

2. Lack of Visibility:

Teams don’t realize they are behind schedule until it is too late. The working model can only be seen at the end.

3. Project Timeline:

Here timeline is planned at the start. If one phase is delayed all other phases are also delayed.

4. Static Requirements:

In the waterfall approach requirements cannot be changed or modified in the middle. Studies have shown that in the larger and more complex projects about 60% of the initial requirements are changed throughout the project.

AGILE’S RISE

Now as we know the problems with the waterfall model, let’s see how Agile provided solutions for those problems.

1. Serialized Process:

Agile has iterative approach with tasks broken into small increments.

2. Planning far in advance:

In Agile we plan for what we know and we have left sufficient allowance in our plans for what we don’t know.

3. Lack of Visibility:

Teams don’t realize they are behind schedule until it is too late. A working model can only be seen at the end.

4. Project Timeline:

It allows the development effort to get feedback from the customer throughout. Expectations are reset at the beginning of each new iteration based on the previous iteration.

5. Static Requirements:

When we work using Agile’s methodology, scope is never closed; continual reassessment of requirements and priorities by the business.

WHAT IS AGILE?

Agile framework has many misconceptions and myths associated with it like no process or plans followed if you are Agile. Agile lets the programming team do whatever they need to do. Improper implantation of an ill-defined concept of Agile can result in even graver problems arising. It has been my experience that the cure was worse than the disease in those cases.

CORE VALUES OF THE AGILE ALLIANCE

However Agile’s manifesto answers all the misconceptions, the Agile manifesto was written in February of 2001 at a summit of 17 independent minded practitioners of several programming methodologies. The participants did not agree about much but they did find consensus around four main values. We are uncovering better ways of development software by doing it and helping others do it. Students learn the Microsoft Project Software during our project management diploma program. Through this work we have come to value.

1. Working software over comprehensive documentation:

It states that working software is valued over comprehensive documentation. The obvious question is what is the difference? In traditional software projects with a lot of effort is used to produce documents like requirement specifications, technical specifications and test plans. In fact these documents are often required before the project can proceed to the next phase. Yet, the sad fact is that most of these documents are not updated or read after the project has been finished. Deliberate documentation might include a short architecture specification, installation instructions and documented source code.

2. Responding to change over a following plan:

The key here is that it is a guide and opens to change rather than a rigid plan.

3. Customer collaboration over contract negotiation:

Unlike in the waterfall model where the customer gets to see the working software only at the project, in Agile customers become part of the development process. Writing aspects down and throwing them over the fence does not work. Customers help the team in writing down the acceptance criteria.

4. Individuals and interactions over processes and tools:

The development team works together with other teams like PMO and Testers. What gets done and when is led from a designated role and agreed upon by the team as a whole.