Can Agile be Combined with Offshore? 12 Lessons Learned
Lesson 1: Make sure you have an overlap of at least 2 hours for your onshore and offshore teams’ working day, if possible. Since India is nine and a half hours ahead of us during daylight savings time, we were able to construct a two hour overlap in our schedules in order to conduct the daily stand up meetings and resolve any outstanding issues. This greatly increased the communication flow and cohesiveness of the teams.
Lesson 2: Create a robust repository and collaboration site that will be the site of record for all specifications, test cases and discussions. We used SharePoint for this which became the repository of record for all communication, collaboration and storage of critical artifacts of the project.
Lesson 3: Do not use email as your primary method of communication (email is still a good mechanism for communication, but should not be used for discussing important topics such as requirements clarification or design decisions). Ensure that all communication is conducted through the repository so that it becomes a permanent record of events, artifacts and communication.
Lesson 4: You should implement web conferencing to create a sense of proximity of team members. We used this on a daily basis to conduct stand ups, review wireframes and specifications, walk through requirements and conduct Sprint reviews.
Lesson 5: Have one central point of entry for project status. All team members would record their progress via a central Scrum management tool. We used ScrumWorks as our tool of choice and were able to create accurate product backlogs, Sprint backlogs and burn-downs on a daily basis.
Lesson 6: Ensure that your offshore team has their own development and test environments, bug reporting tools (Bugzilla in our case) and source code repository. In our case, all of the development was being conducted offshore, so we found it better to have the offshore team in complete control of the development and test environments.
Lesson 7: Shorten your Sprints. We typically do 4 week Sprints when we conduct a project domestically. We discovered that we needed more frequent inspection and visibility into progress so we shortened the Sprints to 2 weeks. This made course corrections much easier and facilitated greater communication of requirements, more accurate status reporting and more meaningful reviews with the customer.
Lesson 8: The Scrum Master must be top notch. Our Scrum Master was located in the United States as well as the Product Owner. The Scrum Master is the key arbitrator in all Scrum projects but we discovered that it took a greater level of skill and experience to facilitate a Scrum when using offshore resources. This cannot be a training ground for aspiring Scrum Masters. You must assign your best to handle an offshore project.
Lesson 9: If possible, your Scrum Master should speak the languages of both your onshore and offshore team. The more they understand the language and culture of the dual teams, the greater the communication flow and understanding of the project requirements.
Lesson 10: The Product Owner must clearly define what “done” means for each of your user stories. In an offshore model we do not have the luxury of walking down the hall to refine and iterate. Well- defined acceptance criteria should be included in all of your user stories.
Lesson 11: There must be a strong technical leader on the offshore team. Your offshore team must possess all of the technical skills to be self sufficient.
Lesson 12: The offshore team must be properly trained in Scrum and specifically in your particular implementation of Scrum. It is worth the cost and time to travel to the offshore site, get to know the teams and properly train them for one or two Sprints to ensure that all expectations and processes are well understood by the offshore team.
