Success Story: Transition from Agile-cum-Waterfall to Scrum
3 January 2014
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
I was not a Certified ScrumMaster when this story began. I had about 13 years of experience in software services. I joined the Global Products team as a ScrumMaster, however. I attended the ScrumMaster training conducted by Pete Deemer at Bangalore and carried back a lot of enthusiasm for implementing Scrum at Global Products.
Global Products was the team that developed Internet products for our customer. There were about 50 people on the team in Chennai, and they were working as a single team. The customer manager managed the project in a time-and-materials contract and had been leading the team for the past three years toward developing the products via Waterfall but within Agile methods. The customer's senior management had been sold on the idea of implementing Scrum at Global Products as a pilot to extend the Agile philosophy across the account.
I was the second of 5 ScrumMasters for the team. Upon my return to Chennai, I briefed my bosses about the training I had attended and shared with them the principles of Scrum, which I had learned from Pete. Eventually, on my insistence, the 50-member team was split into 5 smaller teams of about 9 to 10 members each, and I was identified as the Scrum Master for two teams named Bugatti and Mercedes.
I worked with the project management office (PMO) team, which conducted the Scrum of Scrums to do the release planning and assignment of features to the Scrum teams. The sprint schedule was arrived at for all the teams.
During the first sprint, I introduced my teams to sprint planning, estimation using planning poker, the Daily Scrum call, sprint burn-down, sprint retrospectives, etc. The teams started showing a keen interest in all these things, which had not been practiced previously. Initially, I had the backing of my bosses as well.
The customer manager was not convinced that the new model would work and expressed his worries to his management and to my bosses as well. I had invited the customer manager to attend the daily Scrum meetings, although as an optional attendee. I thought this would dispel some concerns about the new way of working that the teams had adopted.
Two sprints had passed; my team members were showing great enthusiasm and active participation in all the Scrum ceremonies. During the retrospective meetings, certain things became clear: that they were working more continuously than before, that they did not have to wait for the requirements after the sprint had begun, that they could actually collaborate more effectively among themselves, and that they could find ways to improve their work in a friendly setting.
The challenges that remained included winning the customer's confidence; ensuring that defects were reduced on the sprint deliverables; and ensuring that the teams were able to interact more frequently with the business analysts, who were proxy product owners working in a different continent and time zone.
During the third sprint, I had made sure the requirements discussion happened during the overlap hours. This had two benefits. One was the closer interaction between the teams that developed the Internet products and the business analysts who documented the proposed products. The second benefit was a reduction in the number of defects.
The challenge that remained for the fourth sprint was winning the customer's confidence. I set up a discussion between the customer manager and my teams and asked the question, "What should we do differently to be able to satisfy the customer?" Different opinions were voiced. Finally, after due discussion, the teams agreed that in order to win customer confidence, they would have to complete the full feature by the end of this sprint and demonstrate it to the customer. This was not going to be an easy task. I checked the project plan and confirmed that this feature had been planned for completion by the end of the fifth sprint. This meant that the teams had set themselves the goal of completing this feature a whole sprint in advance.
We started the requirements discussion for the fourth sprint early, three days ahead of the start of that sprint. The teams signed off on the requirements on the scheduled sprint start date and decided that they would forgo afternoon coffee breaks for the sprint. They also decided to work weekends. On the penultimate day of the sprint, the teams announced that they had completed all the deliverables for the sprint, called the testers to validate the feature, and the whole feature was accepted by the business analysts -- at the end of the fourth sprint.
The customers lauded the teams for making this huge contribution, and with such good quality. This was a huge morale booster for the teams. The members had not only embraced Scrum themselves but had also convinced avowed Waterfall champions that Agile using the Scrum framework was the way forward for development of Internet products.
Team members were feeling motivated and the customers were feeling more satisfied with the products. Managers breathed more easily. And that's how a cultural transformation took place at Global Products.
Current rating: 4.3 (4 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.