Similarities between Agile and Waterfall methodologies for Software Development

Author: Raashid Kiani, PMP, CSM

The Agile development is relatively new and, based on my experience, is the most misunderstood methodology. The objective of this article is to explain the similarities between Agile and other conventional methodologies in order to convey the message that Agile is not a very new way of developing software applications. The main difference is that you welcome change based on the customer’s feedback early on in the software application development and you deliver the products quickly rather than waiting to develop the entire software before engaging the customer.

This article mainly focuses on Waterfall and Scrum. However before I delve into detail let us rehash the definition of the Waterfall and Agile developments.

Waterfall

The Waterfall Model is a linear sequential development methodology where every next phase has finish to start dependency. This means that any phase under development begins only if the previous phase is complete. The methodology is based on three simple principles: strong documentation, low degree of customer involvement, and sequential structure of project realization.

The Waterfall approach does not define the process to go back to the previous phase to handle changes in the requirements. The diagram below shows the different phases in Waterfall SDLC (Systems Development Life Cycle).

waterfall 

 

 

Agile (Scrum)

Agile methodology is based on iterative and incremental development, where requirements and solutions evolve through collaboration between cross-functional teams with very extensive involvement of the client. Agile methodologies are open to changing requirements. The business stakeholders and developers work together to align the product with customer needs. 

scrum

 

Similarities

We need to understand that adapting Agile methodology does not mean that you are kicking into something very new. However, when it comes to the comparison on the two methodologies, people tend to forget that both methodologies have the similar goals i.e. to deliver a quality software application fulfilling the customer’s requirements. Both teams do the same activities – gather requirements, design, develop, test and deploy. Thus, the foundation stays the same, i.e. you still do the planning, execute the project and track the progress. I have listed down the similarities to provide more insight here, which may help to understand the concept and which may make you feel comfortable choosing either of the methodologies.

Aspects

Waterfall

Agile (Scrum)

 

Feasibility analysis

Cost benefit analysis is done to evaluate if the project/product development is financially, technically and operationally feasible. This may result in a business case. This phase normally takes long as effort is made upfront to capture as much detail as possible to avoid rework in the subsequent phases of the project.

Feasibility is also conducted, however unlike waterfall, this phase will not take long. Considerably less time is spent refining the requirements and working out details.
The customer/client are engaged very early in the phase to get buy-in and refine the requirements as we go.

Planning

Detailed planning is considered as a vital part of the conventional methodologies with the aim to deliver the project as per expectations and avoid changes to the requirements/scope. The plan formulated at the start of the project is monitored throughout the project. There are likely fewer chances to change the scope, add or exclude the requirements. And once the project plan is baselined, change is not welcomed.

Planning is also very important however, the detailed planning is not done upfront. The detailed level planning is done during a sprint planning when team is ready to take a certain chunk of the requirements and start planning to develop. This planning is ongoing, as the team is working on an active sprint, the product owner along with the scrum master or other SMEs continue to refine requirements and plan the next subset of requirements. The change is welcomed, however new requirements are not added during an active sprint.

Monitoring  & Tracking

The progress of the project is tracked against the project plan. Regular status reviews are held to evaluate the progress and then report the status to the management and sponsor(s). The weekly or monthly status reports are also built by the project managers and then shared with all the stakeholders.

Project tracking is also very critical in Agile. The progress is measured against each sprint. The team collectively reviews the results of the sprint and evaluates the progress on the project. The sprint report is created and shared with the stakeholders. The progress is also measured through the demo of the functionality built.   

Communication

The communication plan is normally part of the project plan. The project managers are mostly responsible to communicate on the project and conduct progress review meetings that can be on a weekly or a monthly basis.

The communication is very open, regular and face-to-face. Daily stand up, sprint planning, retrospective and sprint reviews are worth mentioning. The customer is actively involved throughout the project.

Roles

Typical roles. The team members deputed for particular roles perform only their assigned roles and that will not change (e.g. a developer will only do the development and will not work on testing or any other work stream).

Same roles like business analyst, solution architect, developers, testers etc. with the exception of scrum master, which is interchangeably switched with project manager.
However, teams in Agile are self-organizing and, unlike Waterfall, team members switch roles if they can or have cycles (e.g. a developer may help tester in testing).

 

Documentation

Involves extensive documentation.
Considerable time and effort is spent upfront to document the requirements.

Advocates working software delivery compared to spending time on comprehensive
documentation. However, one should not be carried away with the notion of having absolutely no documentation in Agile SDLC. You still need to document requirements, build design and write test plans.

In the end I would say there are pros and cons to both methodologies, however it is you who needs to evaluate which one to pick. Moreover, these methodologies are guidelines and you might need to tailor them when keeping the requirements of the organization in mind.