Nathan Jamin’s Weblog

The power of Scrum, as described in the Agile Manifesto, resides in the way team members interact on a daily basis. It’s about instant decisions and collaborative work rather than extensive documentation and cumbersome processes. One of the key elements of this collaboration is that _the entire project team_ sits ideally in the same room: the business owner, the frontend developers, the Scrum master, the database developer, the system administrator, the QA developer – everybody.

If your company has outsourced its development team and is thinking about using Scrum to develop software, you are probably trying to find out a process to overcome the distance factor. Here is a non-exhaustive list of what challenges I, as a Scrum Master, have experienced so far in the use of Scrum within distributed teams.

Challenges of working with distributed teams:

1. Different work culture
2. Language barrier
3. “Noisy” communication channels
4. Creating sustainable team dynamics

Considering Scrum principles focus on high collaboration, limited documentation and team interactions, there are addional challenges that you need to overcome. These are specific to the Scrum principles.

Challenges of using Scrum in a virtual environment:

1. Lack of informal interaction between team members (!!)
2. Hard to follow the Scrum ritual in a virtual environment

Now that you have an idea of what challenges you may be facing, you can start thinking of processes and tools that will allow you to overcome these and create an environment that comes close to having an entire team in 1 single room.

Some ideas to maximize communication:

I am merely focusing on tools here that may help you better follow the Scrum ritual.

1. Video-conferencing for milestone meetings: I have generally found out that video-conferencing is a great way to reduce the noise in communication. Estimation meeting, Sprint Planning and Sprint Review, if you do not always access to a video-conferencing system, are to me the most critical meetings where an lively interaction needs to happen in the team.

2. IM for your daily business: Conducting daily Scrums over IM has been successful so far, with some dangers however. It’s not easy to get everybody on time (including myself) and focused when there is no real break of the ordinary work environment. Set some rules to make sure everybody is on time, for example.

3. Google Spreadsheets for your Product Backlog: I have only used it for a few times but have enjoyed it a lot. The fact that it is extremely flexible and allows the entire team to access and edit it is a real productivity bonus. We used it mostly for Sprint Retrospectives where the team would enter “the good”, “the bad” and “the ugly” together. The Product Owner would also maintain the Product Backlog in this sheet.

4. A Wiki/Microsoft Sharepoint to document critical project information: this is _the_ place to get the latest information about the project, read daily Scrum logs, meeting minutes and so on. Always accessible for the team to consult and update.

5. IM Conference or Twitter for continuous update flows: I have never tried this before but I believe this would be extremely useful for distributed teams. I see multiple usage here. A developer could quickly inform the team about a block she is encountering: “Having some troubles with function xyz.” Another team member (most likely the one who developed this function) would come in and help get rid of the block. I would also see this tool as motivator: “Tests for story ABC all passed!“.

6. Email to document meeting minutes: I strongly believe in the efficiency of meeting minutes and write them after every meeting I moderate. If a member of the team is too busy to read her emails, upload the minutes in the Wiki and update the team with a Twit!

As you realize there are a lot of possibilities out there to help you use Scrum with distributed teams. I am sure there are more that I am not aware of. The bad point with the above is that you may end with many different tools to do the work. A little overhead is probably the best thing to face vs. costs of rework.

These are of course my personal ideas and would love to know how _you_ are using Scrum within virtual and distributed teams. What works for you? What doesn’t work so well?