Better distributed Scrum

October 19, 2011
I was asked today for my main suggestions for getting better at 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.

 

 

« « One reason for “Business Value Engineering” – 2nd pass || 3 Drivers of productivity with Scrum » »

Posted in: Better Agile, Key problems
Tagged: Tags: , , , ,

10 thoughts on “Better distributed Scrum”

  1. Anonymous

    Change the name of the post to, "Don't Do distributed Scrum". Instead of offering real concrete suggestions, all you do is suggest ways to be less distributed. And worse, they are all obvious. This article get's a "duh" vote.

    ↓
  2. Joe Little

    Well, for a first article, one must cover the basics.

    Still, I find many teams and firms have not covered the basics.

    I don't agree that my main suggestion is 'don't do distributed scrum.' Although it is fair to say, other things equal, that I am skeptical that distributed can ever be better than collocated. But, other things are NOT always equal.

    For example: I find that when people try to do distributed, they don;t spend near enough money on 'virtual presence', by which I mean all the technology that makes it seem as though all the team is really together. Voice, face, body language, pictures, artifacts, etc, etc. Not nearly enough money. You are right to say that people then want an answer: well, exactly what do you mean and how do I implement it.

    Please tell us your ideas…

    Thanks,
    Joe

    ↓
  3. siddhi

    I think some companies have gotten 'true' distributed agile figured out.

    Thoughtworks, for example, does a fair bit of distributed projects, where teams are completely split by geography. You mentioned Xebia. All these companies are getting it to work.

    So I think the "make it less distributed", while a fair point in the early days of agile, is less relevant today.

    ↓
  4. Joe Little

    Hi siddhi,

    It seems you mis-understood what I was trying to say, at least partially.

    First, I think distributed teams can be very productive, perhaps even hyperproductive. But it is another thing to say that it is better than collocated. To prove that, one would have to do an experiment with multiple teams, essentially equal in all respects, and see if distributed or collocated were better. My hypothesis is that collocated would prove better.

    Still, I have done distributed Scrum and it was effective. But was it the most effective solution possible? Less clear.

    I am not sure what you mean by 'true' distributed. One of my points is that people mean many things by 'distributed.'

    I do think less distributed is better. For example, I would rather have a team that is 4 in one team room and 4 in another team room in another country (as Xebia does), than 8 people in each of 8 different time zones.

    But I grant that, so far as scientific research, so far we have mainly opinion and anecdotes. And I grant that, scientific studies of human teams are quite tough.

    Now, again, what I have said does not deal with all the possible individual situations. In a specific situation, any kind of distributed Scrum might be the best possible solution. IMO.

    More specifically, firms (eg, ThoughtWorks) that offer distributed Scrum of some flavor might be offering, at least to some clients, an excellent solution compared to other solutions available to those clients. As one example, I have not worked with ThoughtWorks in distributed Scrum, but I have worked with ThoughtWorks people, and I have a lot of respect for them.

    Thanks,
    Joe

    ↓
  5. siddhi

    Joe, it all depends on what you mean by colocated is 'better' than distributed. Do you mean better RoI? or lower cost? Or higher quality? or more value? faster time to market?

    For instance, suppose distributed scrum is 10x cheaper, then even if it 2x longer, you might still deliver 5x RoI compared to colocated.

    What if the quality people you need are easily available elsewhere? Then distributed might get an advantage over colocated in terms of quality.

    What if development happens in two non-overlapping time zones? Could you get faster time to market because development happens over 24hrs? (when its night at one place, its day at another)

    What I meant by 'true' distributed agile is these examples, where you harness distribution for improving business benefit.

    Contrasted with 'poor' distributed agile, where its like, "well we have to live with it, so lets see how to make it suck less".

    In the old days, the friction of distribution was so high that it would completely negate all the benefits you might get from.

    What companies like Thoughtworks & Xebia have shown is that you can turn around the equation where you provide a 'better' (based on cost, quality, or time to market) outcome to clients through distribution.

    These guys aren't distributed just for the heck of it. They could easily hire only in their home countries and remain colocated.

    What they have figured out is how to combine the advantages of distribution – cheaper developers, better quality of people, and 24hr development – with agile. And then provide an offering that their colocated competitors cant match.

    ↓
  6. Joe Little

    Siddhi,

    Exactly. I agree on many many points.

    Except that I come from the opposite assumption. Ceretis paribus. ("Other things equal") Meaning: salaries are the same, skill sets are equally distributed in all cities, creativity is equal, language and culture are all equal. In that case, I think collocated wins.

    I think your examples are good.

    In general, I think people talked about distributed mostly (but by no means always) because of a presumed cost advantage, eg, an "equal" person in India (or another country) costs less per hour than a person in the US (or another high cost country).

    I think as a generality, it is still true that the same "skill set" (to over-simplify) costs less per hour in India (or China or ….).

    What is less clear is whether the reduced CPH offsets the greater time (manhours and elapsed time). In a particular case. I think it can; I think it does not always.

    Anyway, to all your cases pro-distributed, I think that one can find as many cases where collocated, in the real world where other things are NOT equal, where collocated has an advantage.

    I have also seen many situations where "the managers" (or the firms involved) (IMO) have not figured how to manage distributed well. I do think that managing distributed is typically harder than managing collocated.

    Still, on any day a company can look at its real situation, and see a distributed team that will be better for them than any other (collocated) option.

    Perhaps by now you see my main point. I find some (senior) managers have a knee-jerk reaction in favor of distributed based solely on lower CPH. And insist on it. And I find middle managers will not have the guts to tell them that truth, which is often that forcing a distributed team in a particular case is (in that case) a stupid idea.

    Now, again, distributed teams can be very good. I can imagine many situations where I would do distributed.

    Let me reveal another key point (or bias on my part). People, IMO, are special. We are not abstracted boxes, that we should treat as abstract 'resources'. We should think of each team in a special way, as befits its unique and individual qualities and situation. The distributed "mania" that I have seen did not take into any account the specialness of any good team.

    Let me make one more comment, especially about your ThoughtWorks and Xebia examples. They are good firms, I know people there, and I respect them. But, as you probably know, their good examples do not prove that "everyone" should go distributed (eg, go distributed with them).

    There are many many situations. The cost ratios are always changing. Our understanding of the drivers of creativity is changing. The types of products, users, and intuitive knowledge of what the product should be, all are changing. The products are always different. Many many other things can be different in specific situations. So, assuming "well, we're professionals, and if we manage distributed professionally, it will be better" is not the place to start. The place to start is "how do we assemble a crack team to do this work?" Maximize whatever advantages we can find, and minimize any negatives we may have to deal with. And hit the key drivers for this specific project (eg, time to market is sometimes more important than in other cases).

    Thanks,
    Joe

    ↓
  7. siddhi

    Well, 'all this being equal' is an academic point isnt it? 🙂 In the real world all things aren't equal, and stakeholders want distribution exactly to harness the differences.

    Yes, in pure "development efficiency" terms, colocated is better. But thats irrelevant for biz.

    You mentioned cost as the primary driver.

    For most companies, the software division is a cost center, writing commodities – HR systems, billing, accounts, intranets and so on. Having an amazing accounts system at 1/2 time to market is not going to deliver a company any market advantage. They would rather pay 100K and get a passable accounts system in 12 months, instead of paying 1 million for an amazing account system in 6 months.

    As a developer, we can look at this and say, wow this process is so inefficient, we could do it 2x faster colocated and deliver better quality. Thats compromising the one factor you care about in exchange for two factors that you dont care about. From a biz standpoint its inferior.

    Cost is just one point of course. Thoughtworks and Xebia work on mostly non-commodity projects that are not cost driven. Their value proposition is based on better quality, faster time to market and better process.

    You mentioned that distributed agile is hard. Of course! Thats the whole competitive advantage for TW & Xebia. Its tough for their competitors to replicate. They have the know-how and are exploiting it.

    ↓
  8. Joe Little

    Hi Siddhi,

    Basically I agree with what you are saying.

    But if you want me to agree that distributed is always better "if we do it professionally", I am afraid we will never get there. First, the "if we do it professionally" will just never happen all the time in the real world. And, for a bunch of reasons, everyone is not going to use Xebia and/or ThoughtWorks. Nor should they all (although we can agree that more should).

    I think your numbers are, as a typical example, a bit exaggerated … I don't think the $ are typically THAT obvious. But I grant that sometimes the numbers can be quite obvious.

    A couple of minor comments.

    Ceretis Paribus allows us to think more clearly. That actually helps in the real world. Yes, I agree, the real world is more complex (of course), but that shouldn't lead to our logic getting sloppy (although I think it does).

    Most of the projects I see are not 'commodities', although I grant that my population may well be skewed.

    I think there is a magic in the Product Owner role. And in the joining of the PO and the implementers. And in the joining of of the full team to the customer. The closer we get to full collocation between these 3, I think it is a big advantage in many ways.

    I totally agree, as I have already said, that distributed can be the best solution. In many cases.

    Still, my bias, for reasons stated so far and reasons only hinted at, is to seek a collocated solution first. And then compare it to the best possible distributed solution. For each specific situation. And then decide.

    Thanks for your comments!

    Regards,
    Joe

    ↓
  9. siddhi

    Of course distributed is not *always* the answer.

    eg: If you already have the people in house, and cost is not an issue, and closeness to the customer is important, then distribution is not the way to go.

    You have to look at it on a case by case basis. That goes without saying.

    I think we give too little credit to stakeholders. Talk to them and ask them why they distribute. They have most likely thought about this before.

    What I'm saying is that the decision should be based on business reasons.

    A lot of people in the agile community are against distribution because they've feel its less "development effective" than colocated. Thats a narrow view. Goal is not development effectiveness, but business results.

    Thats one point. The other point is that companies are there who do distributed agile well. Like a waterfall company struggles with agile at first, similarly we struggle with distributed agile.

    Distributed agile is a different beast from regular agile. Its not simply a matter of bridging gaps in communication. You need a different mindset and different set of practices for it.

    For instance, I would prefer to *reduce* communication between distributed teams, not increase it, which is the opposite of what we would consider agile. This is a whole topic by itself.

    ↓
  10. Joe Little

    Hi siddhi,

    I think we agree.

    One thing I will add: My experience is that too often a company makes a blanket decision to go distributed.

    I would agree that some managers have 'thought about it' some. Just not necessarily well nor necessarily talked effectively with the boss. This could go BOTH ways.

    Like you, I am saying make a business decision. Case by case for each team, depending on the effort and the people available.

    I am thinking that the key differences in our thinking and expression arise from having had different experiences (and thus different assumptions).

    More later.

    Thanks,
    Joe

    ↓

Leave a Reply