Case Study: How to Eliminate Flaws of Waterfall and Agile Development Processes Using a Hybrid Model

Size: px

Start display at page:

Download "Case Study: How to Eliminate Flaws of Waterfall and Agile Development Processes Using a Hybrid Model"

Cuthbert Boyd
6 years ago
Views:

1 Case Study: How to Eliminate Flaws of Waterfall and Agile Development Processes Using a Hybrid Model 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 endproduct 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. 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 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.

2 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. 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 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.

3 (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. 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.

4 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 applying waterfall principles. Coding and testing is 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).

5 The main features of the account are: 1. 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. 2. Until now, all the projects handled by ABC Software were executed in Waterfall model. 3. Two of the heavy traffic and high priority applications were now scheduled to be redeveloped. The first being Online registrations, the second being 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 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.

6 #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. 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 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 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 a 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 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.

7 #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. 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.

8 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:

9 Conclusion:

10 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 of leveraging the best of both worlds. The most important aspect before 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, 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 value less

Software Design COSC 4353/6353 D R. R A J S I N G H

Software Design COSC 4353/6353 D R. R A J S I N G H Outline Week 2 Software Development Process Software Development Methodologies SDLC Agile Software Development Process A structure imposed on the development