Agile Waterfall Hybrid Model
The Waterfall Model has been the ideal choice for software development. In this model, an idea becomes usable software in a sequential process that cascades through the stages of Initiation, Analysis, Implementation, Testing and Maintenance.
But the Waterfall model has some disadvantages.
Agile software development evolved to eliminate the issues the Waterfall model has. It has a completely new framework. While the Waterfall model has a sequential design, the Agile model followed an incremental approach.
When clients who used to follow the Waterfall model switched to Agile, the transition brought many issues with it. The reason being inadaptability to a different approach to software development. The end product turned out to be a disaster.
A new methodology has thus evolved, that can be called a ‘Hybrid’, to ensure a robust end-product by picking the pros of both Agile and Waterfall models.
Let’s first know about the Waterfall and Agile development models and then move on to the “Agile Waterfall Hybrid Model” with pros and cons of each.
What You Will Learn:
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.
=> Read more about the Waterfall Model here.
Figure 1 demonstrates the Waterfall model:
Advantages of the Waterfall Model:
- Simple and easy to understand and use.
- 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.
- No working software is produced until late during the lifecycle.
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 tend to bring the processes to the backseat.
=> Read more articles on Agile methodology here.
(Click on image to view enlarged)
Advantages of the Agile model:
- Customer involvement in the process.
- High ROI as working software is delivered frequently.
- Even late changes in requirements can be easily accommodated.
- 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 models – Waterfall and Agile. 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 the Collaborative model can be represented 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
Software firm ‘ABC Software Service’s 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:
- ABC Software Services have 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.
- Until now, all the projects handled by ABC Software were executed in Waterfall model.
- Two of the heavy traffic and high priority applications were now scheduled to be re-developed. The first being ‘Online registrations’, the second being ‘Online examinations’.
- 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 the execution of this project, it was realized in a series of retrospectives that there were many flaws in the processes followed.
These flaws were taken care of while execution the second project ‘online examinations’ and it was hence executed in Hybrid model.
How to Eliminate Flaws of Waterfall and Agile 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 that: Agile gives more value to ‘Working Software over Comprehensive Documentation’. Agile methodology believes that documentation should be ‘just barely good enough’, and more emphasis is given to ship out a working software. Not much effort is done on documentation, but for accounts like XYZ University, with a dedicated support team to work on defects found on live projects, this habit can prove as a hindrance if we analyze it on 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 of the documents prepared. After the project was over, the same was transitioned to the support team.
But in the case of the ‘online registrations’ project, no such documents were prepared and that proved costly. When the project went live, many tickets were raised by end-users and the support team had no clue how to work on them. The team had no document to reference.
This was a major lesson learnt and for the next project ‘online examinations’ documents were written and transitioned effectively.
=> Read more here why documentation is important.
#2. No UAT/End-to-end testing:
In the Agile mode of software development, testers get the builds to test in increments. These builds keep on integrating until the final build is completely built. Testers test the requirements covered in each sprint and keep doing regression testing of the build that keeps on adding up.
But after 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. This should be done in a completely new environment.
=> End to end testing on a live project.
This has its own benefits:
- The complete system is deployed to a new environment and the tester tests the complete flow.
- It builds confidence because ultimately, the build needs to be deployed as a whole in a live environment.
When the Online Registrations project was tested, it was done in the testing environment. After system testing and re-testing all defects, it was declared for sign-off. Ideally, this was not promoted to another environment for another cycle of system testing. (Ideally, UAT happens after system testing, but in this case, UAT team members were involved in the first cycle of testing so no second cycle was scheduled)
When the online examinations project started, SIT (System 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 is responsible for making sure a team lives by the values and practices of Scrum. The Scrum Master is considered a coach for the team by helping the team do the best work it possibly can. The Scrum Master can also be thought of as a process owner for the team.
Online registrations team was formed without a Scrum Master. The importance of having a dedicated Scrum Master was not considered important. That resulted in a lot of issues not getting resolved on time and in turn, time to finish the project often crossed the deadline.
However, a dedicated Scrum Master was involved in the Online Examinations project. The project issues and challenges were taken care of by the Scrum Master. 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 were only concentrating on their work and completing their tasks assigned for that sprint. All additional housekeeping was handled by the Scrum Master.
#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 to 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 consists of features, bug fixes, non-functional requirements, etc. It is a growing document that gets bigger and better 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 waterfall model is traceability matrix. So in order to ensure that no requirements are missed out; a traceability matrix should also be designed and maintained. Usually, in agile no such matrix is designed.
This is a best practice in any project. A traceability matrix should be prepared in parallel to the product backlog. And it should be checked 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 Online registrations project went live, the application was accessed by the end users (students who wanted to register). They faced a lot of issues in the application. This resulted in a lot of tickets 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 the subsequent releases. These enhancements were meant to stabilize the application and improve the end-user experience.
So ultimately, the cost of the project shot up by many folds. Therefore, if a project is not properly transitioned to agile, it may cause the budget to overshoot. This is very necessary to plan a thorough transition of a 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 thought of and it was decided that the requirements analysis phase and high-level design phase were to be executed in waterfall model and rest of the stages in an agile model.
The hybrid model adopted can be pictorially represented as below:
It is evident that both the Waterfall model and Agile model have its own disadvantages. So, it is quite realistic to opt for a Hybrid model, which is an approach to leveraging the best of both worlds.
The most important aspect of the start of any project is to decide the model that the team is going to adopt. This requires extensive planning. Factors like budget, time, resource utilization, the complexity of requirements, etc. should be considered in adopting a software model.
The Hybrid model is still in a nascent stage. As more and more companies will adopt it, we will learn more about this concept.
The Agile manifesto asks us to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Whereas, the hybrid model does not adhere to this 100%. It suggests all aspects are of equal importance. It is up to the clients/project managers to decide which aspects to value more and which aspects to valueless.
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? Let’s discuss in comments.
23 thoughts on “Case Study: How to Eliminate Flaws of Waterfall and Agile Development Processes Using a Hybrid Model”
Good example to explain the use of hybrid model
Nice article and good example demonstrated.
Thank You for updating with the latest trends in QA.
Nice article. I like this idea a lot. I always found missing requirements in Agile to be a pain. Strict documentation from the Waterfall model would help to remediate this issue.
Nice artice and good example to explain use of Hybrid mode
Your approach for hybrid of both the worlds is really good with example.
can this be used for any type of project?
Its an amazing article. For all projects it would be really a good choice.
Nice article and very useful.
Good article…for those who are not aware of Hybrid Model
Thanks @Shilpa, @Vamsi, @Nikolay, @Urvashi, @Anand, @Monisha, @Hari, @Sandip for your comments.
Thanks @Amrita for appreciating the article. I believe yes, this approach can be applied to all projects as Hybrid model incorporates the best pratices of both waterfall and agile. As more and more projects will get executed by this model, it will evolve even furthur.
Excellent Article Harshpal.
Thanks for the information.
Requirements and design are gathered and finalized through Water fall and again from Coding starts with Agile.
is this not a re-work again while preparing user-stories in Agile.also if we observed change while iterations in Agile can we change the design in water fall
Very nice article..
Great Article! Really interesting points covered!
Your webpage is not loading.
I was hoping to read the article, but can’t.
I hope you can sort it out soon.
The issue appears to be with Internet Explorer 11 at the least.
I’ve just tried it in Chrome and the whole article loads. You might be wise to test in all the popular browsers
Thanks for the article, it’s looking to be a good read.
Nice article and makes so much sense. With agile model, we do throw many of the good things about the waterfall model out the window and that where i think, this “hybrid” model will be the best thing to adopt and try out.
Yes. This “hybrid” model is good and should be applied in long term project.
What should be the best test automation strategy for a hybrid SDLC cycle?
Hi all. Great article and the hybrid thought actually presents a current project I’m participating in – without no one really knowing it’s a hybrid model we have adopted:) I would really like to know any input as to how estimation is approached and handled in the hybrid set-up!!
Great article. This process is almost 100% as how we implemented our SW project development process at Lucas Systems and it is working well for us.
Though I appreciate the need for a hybrid model, there are two things I would like to point out.
1) While scrum states “Working software over comprehensive documentation”, it does not say that documentation is NOT needed. This is an important to understand. Documentation can be included in a sprint along anything else, as long as a sprint delivers one piece of working functionality.
2) In your section “Converting project documents to the Product backlog”, it seems to me that you are expecting that the Product Backlog can be finite before the agile part starts. The whole idea with the Product Backlog is, that it is a living backlog. As the project evolves, PO and stakeholders find new PBI’s that gives value to the project, and these need to be considers, as their Business Value may exceed previous PBI.
All in all, I see where you want to go (and so do I) but in my opinion, you are still more waterfall than agile. Nice thoughts though.
thank you for this article. it really help me in my project.