Making Scrum Work in an On-Site/Offshore Model
25 April 2016
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.
Today's software development engagements are complex and span continental boundaries. Projects involve teams working from multiple locations around the world and in different time zones.
Imagine a situation in which you are asked to carry out a project using Scrum whereby part of the team is working in a time zone that is 12 hours different. The complexity is magnified when the project involves more than 20 or 30 team members, which mandates splitting the one team into multiple Scrum teams. How do we make such a project successful? What can we do to ensure that the Scrum roles are divided properly? That the Scrum ceremonies are practiced in an efficient manner and that the team collaboration is at an optimal level? Yes, it is a tough scenario. Here's how we made it happen.
First, the team made a conscious decision to have ScrumMasters and proxy product owners who were both on-site and offshore. The on-site ScrumMaster was responsible for managing client expectations in terms of delivery, ensuring that all impediments were removed and that a smooth flow of information was provided to the on-site and the offshore teams. The offshore ScrumMaster ensured smooth delivery of project activities from offshore.
Because the client was not willing to assume the role of the product owner, that meant an on-site business analyst (BA) was required to play the product owner's proxy. He was responsible for meeting stakeholders from different departments and eliciting the requirements and documenting them in the form of user stories in the product backlog. The offshore BA provided support to the on-site BA in analyzing and detailing the user stories in shared collaboration tool. He also communicated the requirements to the offshore development team.
At first the communication channels, meetings, and meeting frequencies were murky and not defined properly. There was a lot of finger-pointing in terms of requirements gaps and communication gaps. However, the team decided that it was necessary to conduct Scrum calls twice a day, in the morning and night, at each location so that an accurate update on the progress made during the day by each team could be obtained. Thus, Scrum calls were scheduled at 7:00 a.m. and 9:30 p.m. when the team logged in remotely from their homes. Sure, it was tough, but it was working.
In addition to the Scrum call, the team decided that all key stakeholders (BAs, development leads, and QA leads) needed to be on these two update calls so that each key stakeholder was aware of what was happening. The Scrum call was followed by individual calls between on-site and offshore counterparts to discuss and divide the work to be carried out during the day.
The on-site BA explained the requirements documented in the form of user stories to the offshore BA, who then carried out requirements walk-through sessions to the offshore development team. Similarly, the technical discussions focused on implementation, and any gaps identified in the requirements were immediately highlighted.
The drawbacks of the process stemmed from the lengthy sprint time duration. Each sprint was four weeks long, which was really long for a Scrum project. Another issue was that the on-site BA was not able to detail enough requirements adequately for the upcoming sprint, which meant that stories had to be taken on in mid-sprint. Other problems faced by the team included the on-site team holding backlog grooming sessions and sprint planning session because of the time difference. This control caused uneasiness among the team members.
Practicing Scrum within an on-site/offshore model is difficult. Have you faced these kinds of situations? How did you overcome the barriers? What did you do differently? I would definitely love to learn.
Current rating: 2.8 (4 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.