Distributed Scrum: Breaking the geographical and cultural barriers

The software development company I was working implemented Scrum back in 2006. The setup was like, couple of Scrum teams were working in Europe and another couple of Scrum teams were working from offsite location at Dhaka. Four separate teams were following Scrum by textbook. Teams were conducting daily Scrum of Scrum (SOS) to synchronize them and to resolve inter-dependent issues.

After running for a year, it was evident separate teams working on the same project and for the same client (means same vision) were causing unnecessary issues and delays. Moreover the expectation gaps due to remote locations and cultural differences became a major pain that was creating lot of emotions at both sides. 

By that time, teams got familiar with Scrum framework, understood the basic principles and were convinced that Scrum improved the delivery and quality significantly. So we decided to continue with Scrum and stretch it beyond its limit. We formed distributed Scrum teams consisting members sitting thousands of kilometer away. Some of the objectives were:

• Reduce the inter team dependencies
• One team, same vision
• Transparency everywhere
• Reduce Onsite-offsite psychological & cultural gaps
• Quality-Quick delivery

Fantastic objectives but lot of implementation challenges. We had customers at various locations across the globe; we had Product owners, Developers, QAs, Infrastructure teams – all existed in multiple geographical sites. Infinite number of how-to questions were floating around us.

How to stay close
How to attend meetings
How to use Taskboard
How to code review
How to check-in
How to build frequently
How to demo
How to …

Fortunately we were using Microsoft’s Team Foundation System (TFS) as our only authentic development & management tool. We introduced “Scrum for TFS” to handle the Scrum related processes.

TFS solved our check-in and frequent build issues. Scrum for TFS gave us the opportunity to centrally create the product backlog, tasks and other relevant items. Based on the APIs provided by TFS, we built our custom virtual Taskboard. POs can create user stories, teams after breaking it down create tasks or bugs and all pop up in the virtual Taskboard. Members (does not matter where s/he is) can pick tasks from TFS and tasks status is updated on the board in real time. Team can always look at the Taskboard just like the whiteboard with stickies on the wall. Things were looking pretty cool towards our journey to distributed Scrum.

No wait, still lot more challenges ahead! Attending meetings. Fixing local issues. Transparent and continuous communication among members…We introduced Global and Proxy Scrum Master (SM) concept. Global SM is the natural SM of the team as stated in the textbook. But staying thousands of kilometer away, Global SM cannot facilitate and handle remote issues (some developer is sick or mentally upset, local interferences, booking a meeting room and so on). Proxy SM just fitted in our distributed picture nicely 🙂

What about open communication? We agreed to use Skype as our natural communication tool among members from different locations. We provided Webcams so that verbal communications look like almost real and people can see the facial expressions – it reduced the expectation and cultural gaps dramatically! On top of that we introduced GoToMeeting to share our desktops. We can talk all the time (PC to PC voice call is free in Skype), we can see each other (webcam) and we can show our codes, design diagrams or anything to others (GoToMeeting). Hey isn’t it the Scrum team as stated in the textbook sitting in the same room – talking, shouting, pair programming, code reviewing, planning, attending daily scrum?

After all the setup and moral boost, rest things fall in place quickly. We shifted our 15 minutes daily Scrum to a common working time so that all members from different time zones can participate. It is definitely not in the morning for everybody. Members of such locations introduced a short local morning scrum to address immediate issues to start their day and then they attend full Scrum meeting at the preset common-for-all schedule. The Sprint planning meeting, sneak preview, demo, retrospective, code review, design discussion – all such meetings were conducted always on the overlapping working time period.

After all such initiatives, I visualize my distributed Scrum team as a real Scrum team that follows all the basic Scrum principles, makes more business sense and handles real life situation where more and more software companies are outsourcing their work and dealing with distributed team members.

[Image taken from web, unknown source]

I consider myself lucky being a Scrum Master and Agile practitioner by working both at offsite and onsite locations with such great teams.