Get certified - Transform your world of work today


Success Story: Transition from Agile-cum-Waterfall to Scrum

3 January 2014

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.

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.

Article Rating

Current rating: 4.3 (4 ratings)


Sanjay Nipane, CSM, 1/21/2014 4:03:14 AM
Good transformation.
Sweta Paul, CSM, 2/25/2014 5:01:43 AM
I would like to know what happened after the 4th Sprint?
1. Did the stakeholders expect the teams to continue completing work 1 sprint in advance (increased velocity)?
2. Did the teams go back to working at their previous velocity, without stretching on weekends or late into the night?

This was obviously not sustainable for the team and thereby against one of the main tenets of Agile.
Also, it raises the bar when it comes to expectations from the stakeholders, and thereby skews the release planning since the team will not be able to work at the same pace to match the expectation.

Comments would be welcome....
Bharath Malaivaiyavur, CSM, 8/26/2014 2:19:03 AM
Hi Sweta,

Well, what happened after the 4th sprint is that, more features have come the team's way and they have been well advised to take up in a sprint only, what they can deliver.

Thanks for sharing your feedback. Yes, avowed Scrum champ you're :-)
Raju Joshi, CSM, 1/6/2015 2:41:39 AM
This is only possible if you have a committed and dedicated team who understand the need of time which is really hard to find in real life. My experience so far is that you as a scrum master had a hard time conviencing the team and that become very challanging when it comes to your Role as you are not suppose to put any pressure or influnce on the team.
Bharath Malaivaiyavur, CSM, 1/7/2015 12:21:14 AM
A Scrum Master is as much an influencer as a servant leader.
Zhe Yu, CSM, 1/28/2015 7:10:38 AM
Support from boss and customers is so important for scrum. That is a hard way.
Fred Hong, CSM, 3/26/2015 8:54:14 PM
That's really a nice sharing! And I am glad to see the team succeeded at the end.
What I was wondering is for the fourth sprint. I noticed the team was really working hard for delivery and I do feel it might be not good as a long term solution. It can happen for once and could be twice.... That might bring the wrong feeling to the team that they just have to work harder in last few sprints for delivery.I still think we should keep the work loading balance in each sprint. Meanwhile, I don't feel much exists of the product owner, who should have deeper understanding on customer requirements.
Yatin Choubal, CSM, 5/2/2015 5:57:20 PM
Bharat, great success story. Although little late to read, please help me with following.

At the start you mention that most of your projects were time and material based. How did you carry out your estimations.
1) Was it story points. If story points, how did you convert story points to hours?
2) if hours for tasks, how did you write an SOW upfront. Please let me know how did you work around these parameters.
Yatin Choubal, CSM, 5/2/2015 6:24:43 PM
Bharat, great success story. Although little late to read, please help me with following.

At the start you mention that most of your projects were time and material based. How did you carry out your estimations.
1) Was it story points. If story points, how did you convert story points to hours?
2) if hours for tasks, how did you write an SOW upfront. Please let me know how did you work around these parameters.
Bivendra Narangoda, CSM, 6/13/2015 8:54:01 AM
Yatin, above mentioned that planning porker was used, which is a relative measure of estimate. Yes with planing poker you will get the estimates in story points. One of the biggest mistake done by most scrum masters and agile teams is converting story points to hours. If you look at it, hours are more absolute, not relative, so there is no co-relation on that. If you understand the concept behind the sprint velocity, (which is the average story points which could be delivered by the team for a given sprint), you could divide the total size of product backlog by velocity to get the number of sprints needed for the project. If you like, you could multiply the number of sprints by the number of weeks taken for each sprint to get the total number of weeks for the project. Hope this explains

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up