Using Scrum in an offshore setup – with success
It is all about trust, respect, collaboration, feedback and understanding the small (or big…) difference between different cultures.
I had a very interesting experience years back when I started working together with people from the other side of the world. Initially we had started a larger CMMI multi site project to establish a common process foundation between the two organizations. We started the CMMI journey based on a lot of advice from people (experts?) working with offshore development, so called "best practice". After the initial startup, it was oblivious that we had to move away from the heavy specifications and focus more on collaboration, frequent feedback and start building more trust between the teams.
I introduced Scrum as the project framework and did some training of both the local and offshore teams on the process, how to work with user-stories, poker estimation, tasks boards etc. It was more a top-down approach, everyone jumping in the water at the same time. In the beginning it was a bit chaotic and many things had to be managed, discussed and changed in the beginning. After some time we established a rhythm and it worked better and better. The teams in both locations started to improve more and more doing retrospectives and trying many different new ways of working. More automation was stated with improved quality and focus on the development craftsmanship.
Some of the elements that worked well and improved the distributed work, was
- Proxy PO role on the offshore location for the offshore team to get faster feedback.
- Two weeks Sprints with a "Sneak preview" from the offshore team to the onshore PO.
- Daily Scrum of Scrum meetings with Scrum masters from local and offshore teams surfacing problems to me on a daily basis (very efficient and important).
- Global Retrospectives with teams from both destinations.
- Heavy use of Skype, webcams, Go-To meeting.
- Focus on automated builds and CI with unit tests.
- Establishing development standards for all teams.
- Working on same infrastructure (Team System – started on TFS2005, beta3 :-).
- People from both locations traveling to the other location and working together with the other teams.
- Focus on domain transfer to the offshore team with PO visits to the offshore location.
- Definition on "done-done", acceptance criteria, improved User Story concept.
A good development infrastructure is always one the important areas to establish and in a setup with distributed teams maybe working in different time zones it is even more important.
Establishing distributed software development must be a long term strategy, because it takes time to build the system with shared processes, rhythm, thrust and with focus on continuous improvement.
I was some years ago told an interesting story about difference in culture when working with Chinese people:
In Chinese there are more than 20 ways of saying "No" and more than five of them actually include the word for "Yes". So as a foreigner, you might hear a "Yes", but basically the reply might be: "No".
So look for the small details and understand the other culture, use more collaboration and establish a more frequent feedback rhythm. Use the different ways of visualizing what you are talking about so you have a common understanding and the same problem.