More about distributed Scrum – one example

Let’s talk about distributed Scrum using one example.

There are so many situations and variations for distributed Scrum.  And, hence, many different suggestions, depending on the situation.

One example

Imagine you are the head of technology, in the US.  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, according to the resume, just as good) within 3 time zones (eg, in Canada or Argentina).

Imagine that the cultural and language issues per se are not an obvious roadblock. And imagine 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, can be successful.  (Although to be fair, we have not done blind trials 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) to be successful.

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 other success factors to consider….)

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 very 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.

First, in your context, define success.  At least what you think the key criteria should 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.

1. Visit the ‘near-shore’ team.  Pick specific people. Ask yourself how those specific people compare to those you have.
2. 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 (a) 4 home people in a team room, and (b) 4 far people 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.)

Some things to consider:

• 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’ in a specific situation.

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 especially the 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.

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

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

« « 3 Drivers of productivity with Scrum || Scrum teams and living in packs » »