Tuesday, February 19, 2013

Scrum & Distributed Teams

Target audience: Beginner
Estimated reading time: 20'


The power of Scrum is about instant decisions and collaborative work within the team and with the product owner.  Most of the books and articles on the subject assume, indirectly, that the entire team sits in the same building or vicinity. Unfortunately, an increasing number of software companies have either engineering teams spread around the world, or allow telecommuting or both. Such organizations create challenge for management and more specifically for the Scrum master.

  • Different culture or ethics. Some culture have different rules about accessibility outside normal business hours and privacy. Most of western Europe has very strict labor regulations that may have an impact of the quality of the collaboration between teams.
  • Language barrier. Beside the obvious challenges of accommodating different regional accents, people are sometimes hesitant to ask the speaker to repeat himself or herself, leaving the listener guessing and making inaccurate assumptions. 
  • Confusing communication.  Companies with distributed teams offer multiple channels of communication in order to improve collaboration. However this strategy is not without risk as the same message, report or request may differ between channels of communication.  
  • Difficulty to build team Considering Scrum principles focus on high collaboration, it is quite a challenge to build the team dynamic and motivation. 
  • Interaction too formal. Team spirit and commitment is built through informal interaction. Such tactic is certainly more difficult to implement within a distributed team than a group of engineers sharing the same office.

The last few years have seen a significant increase of the number of options available to facilitate collaboration across continents. 

1. Video-conferencing: This approach is more suited for weekly status meeting, spring planning and retrospective. Skype is a low cost solution to create a bond between the team members and reduce noise in communication. Managers can observe the mood of the teams through non-verbal communication.

2. Instant Messaging
I have found Instant Messaging is perfectly suited for quick one-on-one exchange between engineers.  It is foremost a very effective tool because it allows non-formal, abbreviated, short messages with link to document, source code,  test cases or meeting minutes to be reviewed by a peer. Some IM solutions such as Meebo include extra features that are make the archiving and search through messages easier.

3. Sharing Documents
Although Scrum is not conducive to large amount of documentation, there is always a need for functional specifications, design documents or test plan to be drafted and shared. DropBox or Google Drive provide a simple and effective platform for engineers to share and update documents, especially when used in conjunction with a micro blog. Once a document has been updated, reviewed and approved, it can be converted into a Wiki page

4. Micro blogs
As long at the are used judiciously, Micro blogs such as Twitter are a great way to  notify a group of engineers or the entire team of changes in procedures, summary of daily sprint stand-up, update status or announce meetings or corporate events. However management needs to monitor the content, tone and frequency of those posts.  Employees because insensitive and unresponsive because they are constantly bombarded with large numbers of messages.

5. Wiki
 Wiki are still the best medium for well-defined and complete documents such as coding standard, list of user stories for an incoming sprint, minutes of a retrospective Scrum meeting.

6. Email
From my personal experience, email is an overused and abused communication medium. It should be reserved for formal and/or confidential information

7. Meetings
Because of time zone differences, we cannot expect everyone from any part of the world to attend every meetings. Meeting should be run effectively with a clearly defined agenda, time limit and detailed minutes so engineers do not feel compelled to drop more critical tasks to attend a meeting because of the fear to miss on important information. Meetings should be restricted to evaluate proposal, make recommendation, bring different point of view, and eventually make decisions.

1. Managing communication
As I mentioned earlier, some of the communication tools can be easily abused or misused. It is the responsibility of the manager to monitor any team or company wide communication for sake of legal, ethical implication as well as the overall productivity of the engineering group.

2. Managing collaboration
Some tasks such as peer programming require to have  two or more engineers collaborate on a specific problem. I believe manager are responsible to organize schedule and set business hours of different teams to overlap to facilitate technical collaboration and brainstorming.