More about distributed Scrum - one example

There are so many situations and variations on distributed Scrum.  So that there then becomes so much to say about it.

So, as one example, imagine you have customers in the US, and your business people are in the US, and the best Product Owner is one of these business people.  He is pretty good as a Product Owner.

Imagine that you are doing a major add-on to an existing system.  The add-on can be considered a separate product.  So, knowledge of the existing system is important.  And a quick release of the new product is also important (within 4 months).  Assume that your current implementers are collocated in one city in the US (and could be collocated in one team room).  And assume that you can get people who are 50% cheaper in cost-per-hour (and by resume just as good) within 3 time zones (eg, in Canada or Argentina).  And that the cultural and language issues per se are not an obvious roadblock. And assume for now we are talking about only one Scrum team (about 8 people in total).  This is not a huge project.

What should you do?

Well, first, I can say from experience having worked with a couple of situations like this, that this kind of distributed can work.  Successfully (although to be fair, we did not do a blind trial to compare to an alternative course that might have been more successful).  And your firm does not have to be 'the best' at doing distributed Scrum (although it would of course help).

But nor would I assume, from what I have said so far, that distributed is necessarily the best course. Collocated might still be.

Let's go back a step.  How do you decide?

One question is: how do you define success?

Is it ROI?  Is it lower cost?  Is it productivity per unit of cost?  Is it faster time to market?  Is it less wear-and-tear on management?   Is it reduced risk?  Is it more accuracy in hitting just what the customer wants?  (And there are many others.)

Note: I find that faster time to market is often more important than many people realize.  In this example, I said 4 months.  This allows some time, but not too much, for knowledge transfer from the home people to the near-shore people. So, to me, in this example, it is a key issue, but not determinative by itself.

So, first, in your context, define success.  At least what you think it would be. (It may turn out to be something different later.  Live and learn.)  Look to optimize that success.

Then, do your best to look honestly at your situation (there is always the fog of war, or the fog of business or life).  What things should you do to make it (collocated or distributed) work better?  What specific questions should you ask (of each alternative)?

A couple of suggestions that might be helpful, depending on the situation.

• visit the 'near-shore' team.  Pick specific people.
• assuming you could pick 8 home people, when making the distributed comparison, decide who the 'top 4' would be. How would these people work with the 4 near-shore people?

Note: I have a strong bias that a distributed team should consist of 4 in team room and 4 in another team room.  This minimizes the typical us-them problem, and makes that problem more manageable. The us-them problem (or overcoming it) seems to be the key to real success with distributed.  From my experience and from what I hear from others.

• of course you will look at skill sets. I have already implied that both sets of people have essentially equal skill sets, but of course this may not be true in your specific situation.  In any case, you must look at how the skill sets of the 8 specific people mesh. Sometimes the resumes of the near-shore people are exaggerated. OTOH, sometimes we are surprised to find that the near-shore people are immediately better than our home people on our own systems. (Shocking, but it can be true.) 
• is your 'home' team diverse enough in a useful, knowledge creation way?  Will the near-shore people make the 'home' guys think more creatively?
• will the near-shore folks understand our business and the customers intuitively? (Do they have that tacit knowledge?)  If not, how much would it take for them to get it (more)?  Would that be a good challenge for the 'home' guys, to pass on that knowledge?
• will the Product Owner be able to motivate the near-shore people as effectively as the home people?  And communicate with them well, so that they quickly get the tacit knowledge of what is needed?  And therefore can build it better?
• is the PO willing to travel to the near-shore location? 
• how would the PO get the business value and requirements specifics to the near-shore people?
• how would the PO give the near-shore people daily feedback?
• to the degree there is a time zone difference (and in this example, we assumed that is relatively small), how will this work out practically?  Will one or both sides compromise?  eg, on the timing of the daily stand-up?

I hope these questions did not seem strongly in favor of collocated nor strongly in favor of distributed. One should approach the question, I find, with an open mind that is willing to find either answer as being 'right for this situation, as best we can tell now.'

There are lots and lots of other detailed questions to ask. 

Notice that I did not ask questions (yet) about how all the technical supports for distributed would work (although these are important questions, sometimes hugely important).  And notice that I asked a lot about how the business information, and specially tacit knowledge around the customers, gets into the heads of the near-shore people.  (Not that we can't also have a problem with that with our home people too.)

I also want to emphasize the knowledge creation dimension of the team.  Sometimes the near-shore people can add to that tremendously.  Sometimes they can seriously harm the knowledge creation.  It depends on the specific people, to a large degree.  As best I can figure out.

Enough for now.  Hope those ideas stimulated your thinking on the subject.

And hope you see (again) that 'distributed' is a very very big subject.