Peter DeYoe's Blog

Hello All,

One of the readers of my blog recently asked a very good question.

“Can Agile be combined with offshore?”

Although my initial response is “Yes” it comes with some conditions.  One of our projects recently utilized a partner in India.  We had used this partner successfully in the past for some non-Agile development work, but we quickly discovered that Agile, and in particular Scrum, was a game changer. Our first few Sprints did not go very smoothly.  We found out that blending offshore with an Agile project being run domestically took a greater degree of management and communication than we would normally apply.  Once we realized that there was a higher level of overhead required to make this work we were able to get the project back on track.

I sat down with the development manager responsible for this project and asked him what the critical success factors were in managing a project that had some component of offshore.  He provided a set of 12 “key lessons learned” that might be of some help if you are embarking on using an offshore team for your Agile/Scrum development efforts.

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.

Additional thoughts on running an Agile project using offshore resources can be found in an article written by Martin Fowler.  The article can be accessed at:

http://martinfowler.com/articles/agileOffshore.html

I welcome the thoughts and experiences of others that have utilized offshore resources in an Agile development framework.

Have a great day!

Pete

————————————————————————–

Special thanks for Mr. Jim Dempsey for his contribution to this article.  Jim is an Account Manager and Practice Manager for Application Development and Quality Assurance at CAI.  See his profile on LinkedIn.