Waterfall and Agile Methodology to Hybrid Model Case Study

Here is a detailed case study on how to eliminate Flaws of Waterfall and Agile Development Processes using a hybrid model. Let’s get started.

The Waterfall Model has always been the ideal choice for software development. Here, an idea transforms into a usable software in a sequential process through the stages of Initiation, Analysis, Implementation, Testing and Maintenance.

However, the Waterfall model does come with a few disadvantages.

Agile software development has evolved to eliminate the issues of the Waterfall model. It has a completely new framework. While the Waterfall model has a sequential design, the Agile model follows an incremental approach.

Eliminate Flaws in Waterfall and Agile Processes

When clients previously following the Waterfall model switched to Agile, the transition brought several issues with it. The reason was inadaptability to a different approach to software development. The end product eventually turned out to be a disaster.

There is now a newly evolved methodology known as “Hybrid” that combines the strengths of Agile and Waterfall models to ensure a strong final product.

Let’s first know about the Waterfall and Agile development models and then move on to the “Agile Waterfall Hybrid Model” with the pros and cons of each.

Waterfall Model

The Waterfall model is an approach for developing software that breaks a project into finite phases. One should move to the next phase only when its preceding phase is reviewed and verified.

In the waterfall model, phases do not overlap.

=> Click here to learn more about the Waterfall Model

The below figure shows the Waterfall model:

Advantages of the Waterfall model:

• Simple and easy to understand and use.
• It is a rigid model. Each phase has specific deliverables and review processes.
• Documentation and artefacts meticulously maintained.
• Suitable for projects where requirements are well understood.

Disadvantages of the Waterfall model:

• Not suitable for projects where requirements are at a risk of changing.
• Cost of fixing defects is very high when detected at a later stage.
• Not a good model for complex and long projects.
• The team does not produce any working software until late during the lifecycle.

Agile Model

Wikipedia defines the Agile Model as “a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.”

The model has its own principles that bring the processes to the backseat.

=> Click here to learn more about the Agile methodology

(Click on the image to get an enlarged view)

Advantages of the Agile model:

• Customer involvement in the process.
• High ROI is achieved by delivering working software frequently.
• We can easily accommodate even late changes in requirements.
• Continuous improvement to both product and process.

Disadvantages of the Agile model:

• Lack of emphasis on designing and documentation.
• The team should be stable and skilled.

Collaborative (Hybrid) Model

The Collaborative Model aims to combine both the Waterfall and Agile models effectively. Leveraging both the Waterfall and Agile approach ensures the success of the project. It removes the disadvantages of both the models, while bringing together the advantages of both.

The Collaborative Model can be implemented in a project by executing:

So, we can represent the Collaborative model diagrammatically as below.

Advantages of the Hybrid model:

• Combines the benefits of both Agile and Waterfall processes.
• High-level design is prepared to apply waterfall principles.
• Coding and testing are done using agile methodology.

Agile Waterfall Hybrid Model – Learn by Example – A Case Study

The software firm, ABC Software Services, provides services to a client, a University named XYZ University, to develop test and maintain their software (live production support).

The main features of the account are:

1. ABC Software Services has to upgrade the applications of XYZ University. The database needs to be upgraded and all applications need to be re-developed to the latest technology available in the market.
2. ABC Software used the Waterfall model to execute all the projects until now.
3. Two of the heavy traffic and high priority applications were now scheduled to be re-developed. The first one is ‘Online registrations’, the second one is ‘Online examinations’.
4. Client XYZ University now wanted these applications to be worked on using the Agile model of Software development.

The first project in an Agile model for ABC Software was online registrations. After executing this project, the team realized in a series of retrospectives that there were several flaws in the processes they were following.

These flaws were taken care of while execution the second project ‘online examinations’ and it was hence executed in Hybrid model.

Enhancing Development Processes Using a Hybrid Model

Let’s discuss these in detail one-by-one.

#1) No Documentation

One of the agile principles in the agile manifesto states: “Agile gives more value to working software over comprehensive documentation”. Agile methodology believes in having documentation that is ‘just barely good enough’ and places more emphasis on shipping out working software.

Not much effort is put into documentation, but for accounts like XYZ University, with a dedicated support team to work on defects found on live projects, this habit can be a hindrance if we analyze it on a long-term basis.

Over the years, when projects were executed in the Waterfall model, documents were maintained and updated for the support team to understand and work accordingly. Solution design, technical design, walkthrough documents, etc. were some documents prepared. After the project was over, the team transitioned the same to the support team.

But with the online registrations’ project, no such documents were prepared. When the project went live, multiple tickets were raised by the end-users and the support team had no clue how to work on them. The team did not have any documents to refer to.

This was a major lesson learned and for the next project, ‘online examinations’ documents were written and transitioned effectively.

=> Read more about why documentation is important.

#2) No UAT/End-to-End Testing

In Agile mode of software development, testers get the builds to test in increments. The builds keep integrating until we completely build the final build. Testers test the requirements covered in each sprint and continue the regression testing of the build that keeps on adding up.

Once all the sprints are complete and the final build is ready and all integrated, the tester should test the complete system and should perform end-to-end testing. The tester should perform end-to-end testing in a completely new environment.

Recommended Reading => End to end testing on a live project

It has its own benefits, such as:

• After deploying the complete system to a new environment, the tester tests the complete flow.
• It builds confidence because ultimately; the build needs to be deployed as a whole in a live environment.

The team tested the Online Registrations project in the testing environment. After system testing and re-testing all defects, it was declared for sign-off.

Ideally, this would not be promoted to another environment for another cycle of system testing. (UAT happens after system testing, but in this case, the UAT team members were involved in the first cycle of testing so no second cycle was scheduled)

When the online examinations project started, SIT (Systems Integration Testing) was done, and the code was promoted to a UAT environment where the second cycle of testing was done. Result: All high priority defects were captured and resolved. The build was stable before the go-live release.

#3) No Scrum Master

The Scrum Master makes sure a team lives by the values and practices of Scrum. The Scrum Master fulfills the role of a coach for the team, ensuring they do the best work they possibly can. Scrum Master can also be thought of as a process owner for the team.

Online registrations team was formed without a Scrum Master. The lack of recognition for the importance of having a dedicated Scrum Master was a significant oversight. That resulted in a lot of issues not getting resolved on time and in turn, the time to finish the project often crossed the deadline.

However, a dedicated Scrum Master was involved in the Online Examinations project. The Scrum Master effectively handled and resolved the project’s issues and challenges. The project/sprint reports were prepared and the team could see their progress.

Also, proper sprint planning meetings and sprint retrospective meetings took place for each sprint, that improved the performance of the team. The team was only concentrating on their work and completing the tasks assigned for that sprint. The Scrum Master handles all additional housekeeping.

#4) Converting project documents to the Product backlog

The initial project documents that are prepared in a waterfall model are Business Requirements Specification (BRS), High-level design, Functional design, etc. These documents need to be transformed into a product backlog in order to execute the coding, testing and implementation stages in agile mode. This is a very important step.

The product backlog is the starting point of an agile project. The product backlog is a prioritized list of requirements that is maintained for a product. It comprises features, bug fixes, non-functional requirements, etc. It is a growing document that gets improved based on customer feedback, changing requirements, etc.

Being the first artifact of any project, it is most important to list down the requirements and assign them priorities. The conversion of waterfall project documents to product backlog is a big task in itself and requires brainstorming of the entire team, along with the customer/stakeholder.

Once all the requirements are listed and agreed by the customer, the next task is to prioritize them in order to pick them up in sprints.

#5) Traceability matrix

Another important artifact that is usually maintained in the waterfall model is the traceability matrix. In order to ensure that no requirements are missed out; a traceability matrix should also be designed and maintained. Usually, no such matrix is designed in Agile.

This is a best practice for any project. The traceability matrix should be prepared in parallel to the product backlog. It is important to check it against the test cases executed during user acceptance testing/end-to-end testing (this stage is explained in my next point).

Even if any requirement is missed out, it can be easily incorporated even in the late stages of development, as agile provides that extra flexibility and adaptability.

After the online registration project went live, the end user (students who wanted to register) accessed the application. They faced a lot of issues in the application. This results in a lot of tickets being raised to the production support team. Tickets raised can be classified as incidents, problems, or changes.

A lot of issues were resolved, anticipating the application will become stable. But even then, more than a dozen change requests/enhancements were planned in subsequent releases. These enhancements stabilized the application and improve the end-user experience.

So ultimately, the cost of the project shot up by many folds. Therefore, if a project does not undergo a proper transition to agile, it may cause the budget to overshoot. It is necessary to plan a thorough transition of the project to Agile.

Also, planning should be done to the extent the project needs in order to be executed in agile mode. Proper hybrid models should be designed for a particular project.

Before the start of the Exam Entry project, this aspect was well looked after. A hybrid model was considered and it was decided that the requirements analysis phase and high-level design phase were to be executed in the waterfall model and rest of the stages in an agile model.

The hybrid model adopted can be pictorially represented as below:

Conclusion

Both the Waterfall model and Agile model come with their own set of disadvantages. So, it is quite realistic to opt for a Hybrid model, which is an approach to leveraging the best of both worlds.

When beginning any project, the most crucial step is to carefully determine and select the model that the team will adopt. Planning for this requires a significant amount of time and effort. When adopting a software model, it is important to consider factors such as budget, time constraints, resource utilization, and the complexity of requirements.

Hybrid models are still in a nascent stage. As more and more companies adopt it, we can learn more about this concept.

The Agile manifesto asks us to value the following:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

However, the hybrid model does not adhere to this 100%. It suggests that all aspects are of equal importance. It is up to the clients/project managers to decide which aspects to value more and which aspects require less focus.

About the author: This is a guest article by Harshpal Singh. He is having 7+ years of manual, database, automation and performance testing experience and currently working as a Team lead in a leading MNC. He has worked on many QA projects following the Waterfall, Agile and hybrid development models.

Do you have any experience working on this hybrid development and testing model? Please post your feedback in the comments section below. We would love to hear from you.