Better distributed Scrum
Suggestion 1. Make a fair comparison between distributed and collocated in your specific situation.
a. Cost per hour, usually lower for offshore people.
b. Hours of “distributed” members, usually more.
c. Hours for “local” members, usually more.
d. Net effect on delivery time, usually delayed.
Then, calculate and compare the net net effect.
Does it still make sense to be distributed? Often yes, and also often no. Depends on the situation. So, determine the net net effect for your situation. Both before you start, and then review after you finish.
Our opinion is that the main focus for the team should be on creating new knowledge. So, the old idea that we always find the people with the best existing knowledge is flawed. Creating knowledge is best done collocated.
So, here are some more ideas.
First, I find that collocated Scrum is always better. Xebia has an argument that the way they do distributed Scrum is even better than collocated Scrum. Maybe, but I do not think their hypothesis has been given a fair test. (This is a big subject; not the main topic here.)
Second, there are many types of distributed Scrum. Some examples.
a. Distributed in multiple places in the same city.
b. Distributed in only two team rooms, each in a different city, the cities not more than 2 time zones apart.
c. Dispersed across a continent (eg, the US), no two people in the same building, across 3 time zones.
d. Distributed in only two team rooms, each in a different city, the cities about 6 time zones apart.
e. Distributed in only two team rooms, both in the same city (thus: same time zone).
There are some similarities across these situations, but they each are pretty different. And might require different key components to the solution.
We have not mentioned yet cultural, language, and accent issues. We have not mentioned organizational issues (eg, different firms, departments or reporting lines).
1. Communication will be harder in many ways.
We know in our business (new product development) successful communication is very hard. And that’s when they are collocated. Any kind of distance makes this worse or harder. So, we do everything we can think of to make it better.
2. The team needs to Form, Storm, Norm and then Perform.
This is harder when they are not collocated.
Often they can get stuck in “high frustration.”
3. The team needs to share information.
This is related to communication, but different. Here we are talking about things like sharing documents, sharing diagrams, sharing code, etc, etc.
Suggestion 2: Get your team to compare your current situation to a collocated situation. What is the worst thing about it, as you all compare? Work on that one big impediment. One at a time.
There is ALWAYS something more that needs to be improved. And usually that something will be a weakness arising from being distributed.
Ok, now I get to a series of other suggestions, not all of which will apply to your specific situation.
Suggestion 3. In the beginning, get the Team collocated as much as possible. Ideally for release planning and the several initial sprints. Many reasons, but probably the main one is they get to really know each other. Very important.
Suggestion 4. Get them together more often than you currently can imagine. If in the same city, one day per week (or more). If in two continents, a week each month (or as often as you can get).
Suggestion 5. Minimize the dispersion. Two team rooms, each with 4 people is best. Try hard to get the 4 in one city to collocate in a team room.
Suggestion 6. Have frequent visits. Have one person from Bangalore visit the US. Then wait a week, and have a person from the US visit Bangalore. Do this more than you can currently imagine.
Suggestion 7. Spend money on really good tooling. This means: Scrum tool, great video conferencing, fancy Polycomm phones, leaving the Polycomm on during the day for impromptu conversations, high bandwidth between locations, fancy tools to emulate white-boarding or common editing of documents, common storage areas (eg, wiki or Sharepoint) that work really well. Plenty of throughput on the servers, plenty of server space.
Try ‘virtual presence’ tools. Try them. If they work for your team, use them.
Remember that tools always require more training than you anticipated. (If the tool is not used or not used well, it is remarkably less effective.)
Suggestion 8. One of the key issues is: do they all ‘feel’ as though they are one team? Or is there an us/them feeling?
We want the former attitude, of course. And it seems to be key, almost always. If not ‘one team’, make that issue visible, acknowledge it as a normal problem, and then work on it. See some of the other suggestions here, but there are also yet other solutions.
Suggestion 9. Culture. I find that cultural issues and misunderstanding decrease when people start to know each other personally. So, first, do that. (See Suggestion 3.) But, depending on the people, there can still be ‘cultural issues’. Even within the US, for example, but certainly between two countries or two languages or two cultures (eg, east Germans and west Germans). Get everyone some cultural education, courses, etc. Acknowledge that it is a common problem. And take the time to deal with it.
Now some more specific issues…
Issue 1. Where should the PO be? No strong opinion. Where the best PO is. Near the customers and near the team. With one of the two ‘pods’ of 4 people (half the team). It depends on many factors.
Issue 2. Where should the SM be? Again, no strong opinion. Where the best SM is. With one of the two pods. Ideally visiting both (or all) sites with some frequency. Again, it depends on many factors.
Issue 3. When should the Daily Standup be? Usually in the morning of one sub-team, typically then “later” for the other sub-team. If necessary, both sub-teams should compromise some on the timing.
Issue 4. Language, accent issues in the Daily Scrum. This is a fairly common problem. Often the “early” people (if they exist) can write their answers to the three questions and send that to the “late” sub-team. And the discussion is more about clarifying and fixing things, than about the answers per se. Of course, the better solution is to fix the problem at its source: improve the Polycomm or equivalent or send them to a language course or enunciation course. (“The rain in Spain falls mainly on the plain.”)
Many other issues and ideas, but those suggestions should keep you busy for awhile.
Note: We have not yet considered scaling with distributed teams. This can be done. With some success. It is hard, it is ugly, but it can still be successful. We can say that Scrum will enable you to see the ugliest thing today, which does help you fix it.