I started my career in a service company by working on a project that followed a typical Waterfall model. Our team consisted of ten developers who were responsible for core development. The architect team was made up of a dot-net architect and a database architect. The core testing team had five testers who were involved in hardcore manual testing, and the automation team performed automation testing.
The development cycle
Our development cycle consists of the following phases:
- Requirements analysis phase. Architects and senior developers analyze the requirements, ask questions, and get clarification on any issues.
- Design phase. The team drafts a high-level design and secures approval.
- Coding phase. The ten-member development team starts coding and developing the application. Unit testing is completed and certified.
- Testing phase. The testing team begins testing and finding bugs:
- When the entire application is handed over to QA, and the five QA members test extensively, and many defects are raised in a day.
- Each bug requires analyses, impact analysis, design change, coding, testing, and QA. This process is costly.
- If there are functional bugs, the time to fix them, without impacting existing functionality, will be lengthy.
- UAT testing phase. User Acceptance Testing (UAT) is the phase during which the software is exposed to users for testing and approval on real-world scenarios. This is the time when the organization might want to change a few functionalities or change the look and feel of the product. The change phase is costly because the changes still need to be delivered on the same time schedule that that was originally committed.
This was a hectic phase for us, as our team needed to stretch, and it eventually burned itself out to achieve this level of testing. Many impacts were missed in last-minute bug fixes, resulting in costly defects that were found during production.
The catalyst for change
Both the team and customers were dissatisfied to the extent that customers even considered changing vendors. It was a difficult time, but then we heard suggestions to try the Agile method for our project. The suggestions generated many discussions and objections from the client as well as from the organization. They all thought it would not work because the team was unfamiliar with this method of development and the next project in pipeline was almost done with requirements.
We eventually secured a proposal for one three-month project. All stakeholders agreed to start Agile Scrum for this one small project. I was lucky to be part of that pilot project, which we tackled by following a series of steps.
Step 1: Build awareness.
A few team members, who had attended developer and ScrumMaster training, arranged an awareness session. This session set the expectations and established the processes. We even coached the clients on the Scrum principles.
Step 2: Set the process.
All the Scrum processes — grooming, stand-up, demo, and retrospection — were laid out.
Step 3: Form the Scrum team.
The Scrum team was formed with the right mix of developers and testers. The team was seven members strong.
Step 4: Implement the processes.
The pilot project for Scrum started with Sprint Zero during which the architecture discussions and spikes where done. Next, we presented the demo to customers, which was the highlight of the project. The customers were reviewing a workable product after two weeks. They had lot of suggestions for improvements. We used retrospection to analyze the improvements and determined which ones we could incorporate.
Step 5: Stabilize the team and processes.
The team became familiar with the processes and asked questions during the grooming, which resulted in fewer comments during the demo. The entire feedback mechanism was helpful.
Also, the QA team got to test the working software for all the stories completed, and they were able to find bugs earlier in the development cycle.
Step 6: Analyze the results.
The project was a great success, and we were able to release the product in three months with very few defects found in the UAT phase and no defects in production. The results gained the support of management, and slowly the entire account was moved to Scrum. The client awarded us with more projects.
After transitioning to Agile, we realized the following benefits:
- Team transparency and the empowerment to ask the right questions
- Satisfaction of delivering working software after each sprint
- Recognition of a member's value to the team and each team member's decision-making power
- Improvement in work-life balance
- Tangible improvement after each sprint