Teams working in multiple locations set them self up for failure. The tax that they force on their projects is so big that it’s hard to come back from it.
I recently read a book about how important learning is to software development. It’s one of those rare books that make you say “of course! why didn’t I think of that!?”. The main argument Allan Kelly makes is that the constraining factor in software development is how fast everyone involved can learn. I definitely buy into this - it resonates with me.
Many types of learning are involved here - about the technical aspects of the work, how the IDE works, platforms used, coding standards, patterns used and so on. The team will learn about the domain they’re working in. They will also learn intangible things about how the group work, which will make them far more effective. All this learning is unavoidable - no matter what anyone does this learning will take place.
This is the constraint. No other single change can make as big impact as if the team gets really, really good at learning fast. Bigger screens, faster typing, or Ruby instead of Java means nothing compared to lifting this constraint. So an organisation that wants to make sure that their teams produce the right system as fast and with as high quality as possible better make sure that the teams are in a good position to learn.
And one way to make sure that learning is hard and slow is to force people to work far away from each other. Just having developers sit in different rooms will make the learning process much slower - imagine what sitting in different cities or even countries will do for you.
Alistair Cockburn talks in one of his books about how different types of communication have different bandwidths. Two persons talking face to face in front of a whiteboard can communicate many orders of magnitude better than two persons communicating through a Word-document. When you split teams up over geographical areas, you take away all the high-bandwidth ways they can communicate on, and this, of course, is very adverse to their learning capacity.
Manager realising distributed work is bad
When ever I hear of teams working across country lines, my gut reaction is to wonder if anyone has really thought this through. Have they made sure that the difference in labour costs really make up for the decrease in productivity and quality that it means to work like that? My experience is that it doesn’t make business sense most of the times. Thoughtworks had a couple of distributed projects that where running pretty smoothly, but they worked a lot on overcoming the problems introduced by distributed projects. If you think that email communication with a development team is a good way to produce software, I would wager that you are in for a surprise.
So, to recap, a teams learning capacity is what limits their effectiveness as a software system producer. Some times you can’t get away from dispersed teams. Enter these situations well aware of the extra cost this will have on your performance, and work on ways to get around these problems.
Let’s say that Allan is right (he used to work for me, so I’m happy to acknowledge that he’s got some good ideas). What then?
Some projects require a great deal of learning. For example, some of my reports are working on a tool to be used by mechanical engineers to design very large, very expensive, very sophisticated very energetic (and therefore dangerous) machines. They are learning a huge amount every day. Have been for years, will continue to for years yet.
Some don’t. Another team that I once managed built simulations of the user interfaces of mobile handsets. All the learning happened in one go over a couple of days when a new handset came in, and the rest of the six weeks (lets say) to build the simulator was “just work”.
There again, there are more reasons to distribute work that arbitrage of living costs. It’s true that many managers who have tried to do that have been caught out by the failure of their actuarial calculations goes awry. That developers in territory A at one third the cost of those in territory B doesn’t lead to a 66% reduction in cost by sending the work over there. CFOs seem to find this very puzzling indeed. Perhaps they should read Allan’s book.
But what if we believe in close collaboration between customers and developers and out customers are all over the world? Maybe the advantages of being close to the customer outweigh the penalties of having the developers far from one another. I’m pretty sure I’ve seen this.
And what if we simply can’t hire enough developers in A with the skills we need to do the job in time? Additional remote capacity might help us over the hump. Granted that the developers in B are not as effective as those here in A—what if there simply aren’t enough in A? B-land developers don’t need to be operating at peak efficiency to be more effective that the developers in A that we simply don’t have.
And so on. There are a lot of scenarios with a lot of free variables. Even if learning capacity is the single strongest constraint it’s big leap to say that it will therefore trump everything else.
I do agree with you though that whenever you see a distributed team there’s a good chance that the consequences of this have not been properly thought through. I just have a slightly more optimistic view of what can be expected to happen if that thinking does get done
Left by Keith Braithwaite on October 22nd, 2008
Let’s say that the price is very high to pay, but generally we offshore to 3rd worlds countries, so till those countries will keep their rates so cheap it still makes sense to pay that higher price ( waste on communication, travelling, information radiators).
Nobody never setted up (as fair as I know) a distribuited team across Europe.
The cost will be higher!
The day every country will have high rates (India and China will rule the world soon, so they’ll be more expensive too) we’ll stop to think that distributed development is the solution to every problem, and we’ll go back to the old good, nice, perfectyly effective wall, as a team, in one room.
Left by toni on October 22nd, 2008
themselves up for failure
Left by pat on October 22nd, 2008
You’re welcome to write an uninformed blog post and not cite any research of GSD (Global Software Development), but it doesn’t make anything you wrote correct or even verfiable or tested.
Conferences and workshops
http://icgse2008.di.uniba.it/
http://seal.ece.ubc.ca/gsd2006/
Or you could’ve just googled:
http://www.google.ca/search?hl=en&safe=off&q=global+software+development+&btnG=Search&meta=
You could’ve even searched for work on your topic:
http://scholar.google.ca/scholar?q=distributed+software+development&hl=en&lr=&btnG=Search
But you didn’t, you wrote this uninformed mess and you expect us to take it at face value.
Your opinion is meaningless, worthless and frankly pretty off-kilter. Go look at how IBM, Microsoft and other companies manage this and go look at the current results in research and business. A famous business consultant once said: Once your 50m away from someone you might as well be a continent away.
Left by Sarah Untire on October 23rd, 2008
I do buy into the fact that in-person communication is much more efficient than any other type. I also buy into the phenomenon that by the mere fact that you and your peers working on the same project are in the same room, you are very likely to be more aware of how the work of others is going to impact yours and put in your two cents in it.
I step back a little and read the blog again. Is it saying that you should not “Outsource” or is it saying that you should not “Distribute” your team. I think its the latter and so you can have your entire team offshore instead and put your subject matter expert into the team for them to work effectively and efficiently while deriving the benefits of lower cost. Right?
I am myself managing a project where we have team members who are distributed across cities and continents. To add to the complexity, even our customers are distributed.
While we are distributed we try to make up for it by over-collaborating. We make sure that a document is shared over a web conference so that everyone is on the same page and any edits are being observed real-time. We also highly encourage chatting within team members over IMs and over the phone. We record meetings during non-overlap periods to give an opportunity for team members to have a more rich experience of an update. I like it when a team-member says “I saw the video and the customer did not sound very convinced about our plan.” We also leverage audio cues that we observe over the telecons — a deep sigh, a laugh, an exclamation and not to mention silence. We actually thank the individual for that bit of extra dimension in the communication. Sometimes we call upon that individual’s non-verbal feedback — “Wow, you seem very happy to have had this in production, don’t you?”.
For my team, the web-conference is our team-room. We find ourselves having discussions on it several times a day. Developers sometimes do peer programming over it, customers do peer reviews.
This is not to say that we’ve achieved the efficiencies of a co-located team, but we do work very hard to compensate for our distribution.
Left by Nirmal Merchant on October 23rd, 2008
I’d agree with Nirmal Merchant’s comment; I am currently working on a distributed team, and our anecdotal evidence of having done this as a company for a decade is that our product gets developed and our customers are happy with it, and in my not-so-humble opinion we produce high-quality stuff.
I’ll also note that the open-source projects we contribute to such as GCC and GDB are also developed by very distributed teams, and their success in the relevant markets seems to be in direct counterpoint to this “doesn’t work” claim.
Sure, there are challenges. And being aware of them is useful. But the evidence shows that, when an organization or company fosters communication in ways other than face-to-face meetings, distributed development can in fact work very well.
Left by Brooks Moses on October 24th, 2008
Andres, I notice that you can reply to me in–line but not vice versa.
Anyway, see http://peripateticaxiom.blogspot.com/2008/10/just-work.html for some further thoughts on “just work”
Left by Keith Braithwaite on October 25th, 2008
I am part of the team that works in two cities 250km apart in the same timezone, with live sync-ups about monthly, and I don’t see how learning is impeded much by that remote arrangement with availability of IM, video calls, and roundtable camera meetings. Comment about “even developers working in separate rooms” is especially interesting - I was kind of assuming that it was common knowledge that developers working in separate offices are more productive.
Before that, I used to work with people collaboration via IRC and bug tracking systems plus whiteboard software; while it was harder, especially across timezones, it is still pretty viable.
My experience was that distributed development works, and works pretty well, especially with right tools in place; value of face to face communication for tech work is way, way, no - WAY overrated.
Marketing or PM team, or politically charged organization may have big problems from distributed arrangement, nut bot a good dev team.
I can also think of unmotivated, lazy developers having problems because of lack of managerial oversight - then, this could be solved, and ditto about good teams above.
Left by Sergey Shelukhin on October 25th, 2008
Nirmal, Brooks, Sergey:
My experience, and that’s all I’ve got to build on, is that people sitting close to each other are more productive than geographically dispersed team members. It’s hard to prove: http://www.martinfowler.com/bliki/CannotMeasureProductivity.html
My bias is that “high-bandwitdth” communication, like face to face meetings between devs in front of a whiteboard, easily outperforms IRC and bug tracking software. Maybe you’ve experienced something different.
Left by Andres on October 25th, 2008
Thanks for sharing this article I also like website with flash designing specially the intro part of the website is so attractive and I agree with your view that flash presentation
Increasing your web traffic and page views Add, add your website in http://www.directory.itsolusenz.com/
Left by nirenjan.raj on July 10th, 2009
Hey, you have a great blog here! I’m definitely going to bookmark you! Increasing your web traffic and page views Add, add your website in http://www.directory.itsolusenz.com/ site, it’s pretty awesome too!
Left by nirenjan.raj on July 10th, 2009
Gemini Info Way (GIW) Provide the Following Services,Web design, Flash Website Design, Banner Design, Flash Design , Flash Banner Design, web hosting, SEO, web development, online dating, e-commerce, graphic design, Vector based drawing, Brochure design, Banner Design, Flash Animation, Flash presentation, Flash Website, 3d Animation, 3d Landscape, 3dObject modeling, 3d Character modeling, 3d Story Animation, 2d Story board, 2d Story Animation, Gif Animation - http://www.geminiinfoway.com
Left by jennifer on October 30th, 2009