Monday, October 27, 2008

Learning and Distributed teams

Andrés Taylor has some nice things to say about my book on his blog this week. Most of his blog is expressing concern about distributed teams and the discussion that follows is quite interesting too - Keith Briathwaite has continued on his blog. In my view distributed teams are generally a sub-optimal way of arranging your development process. However you may choose to organise in this way for several reasons. The main ones are:

1. You have no choice, for example: you need an expert in, say, database transaction processing on embedded systems and there are three guys in the world none of whom want to move to you Halifax Nova Scotia office.
2. You need your development team close to your customers and your customers are in different places.
3. Somebody somewhere has done a calculation that says the lost productivity is acceptable because the savings elsewhere. For example: having two developers in London and two in Bangalore is so much cheaper than having four in London that the 10% productivity loss is acceptable.

A few years ago we ran a focus group at EuroPLoP on Conways Law (What do we think of Conways Law now?) One of the insights I got from the focus group was:

• When ever you remove an informal communication channel create a formal one.

So.... Whatever the reason the important thing is to compensate for the distance. If you are saving so much money by spreading people out spend some of the money on flying people around to meet one another. Spend some of it on teleconferencing and video conference kit. Open the firewall to IM and Skype traffic.

Consequently companies that decide to spread their developers around should not then complain about travel budgets. If you are saving with the left hand you need to spend with the right so budget for it.

1 comment:

  1. "Optimal" and it's cognates are words I've come to be suspicious of—as with "important" a value judgement is being implied (and therefore hidden).

    When I see folks talking about optimal processes I'm reminded of Fred Taylor and the notion of a One Best Way. But which variable is to be optimised for? Total cost? Unit cost? Burn rate? Duration? Schedule flexibility? Throughput? One of a dozen other things? Any one of them could be a reasonable choice, and could lead to a very different "optimisation"

    The folks who decide to do distributed development aren't capricious or stupid, which they'd kind–of have to be to deliberately choose to do something badly. Their analysis of the costs is often incomplete and of the benefits wildly optimistic, but they are putting some thought into it.

    We as technologists, or coaches or team members or whatever else might not agree with their value judgements, but I think we need to do more than dismiss them with an objective–sounding but in fact deeply subjective term like "sub–optimal".

    In any case, I'm making a conscious effort these days to set aside striving for the optimum of anything—I'm much more interested in what is appropriate to a given situation at a given time for a given goal of a given group of people.


Note: only a member of this blog may post a comment.