Offshore development, pitfalls and myths

When I was called to assist a major "offshore development" effort, my expectations and dreams were set on:

- a permanent operations room (with a nice view on the lake) where all the onshore "architects" could work together to design the solution, with blackboards, paper, high speed unrestricted internet connection, a powerful 17 inches laptop with 16 GB RAM, stationery etc


- pain-free, one click videoconferencing with the team offshore - the distance should be reduced to the minimum with the use of collaboration/communication tools such as Communicator, Skype, Desktop sharing etc

- wiki on the go - wikis are linkable to any section in it, word documents are not. Everything should be one-click-away and searchable

- automated-build environments were people can freely experiment without affecting others (nothing is more distressing than losing days of work because someone nuked the environment where you were working)

The stress should go on: coordination, communication, responsibility, agility, no red tape, trackability. Plan in advance, think in advance.

The idea that some giant throbbing brains onshore should do all the thinking, write down everything to the smallest detail in a gigantic omnicomprehensive Word document, throw it across the wall to a team of coders offshore and get the product delivered... this idea simply doesn't stand to reality.

First, because the architect can have the full picture, but a lot of small details can be perceived only by someone (developer) who fully dedicates himself to a single topic for a long time. The relationship between the architect and the developer can only be one of cooperation and mutual help... the architect takes care of the big picture, the developer of the tiny detail, and they both exchange ideas to accommondate the details into a coherent overall framework.



So, the design a little-code a little-test a little approach is even more winning in an offshore model: all these iterations and interactions help architect and developer to synchronize with each other - all should be tracked in wikis which can be edited by both sides of the ocean.

Word documents are a HUGE pain in the neck, you always end up with a local copy that is painful to synchronize with others. AVOID by all means.

Ideas and visions: things can be achieved only if people share a common vision.
Having educated resources is paramount - you need actively thinking brains, problem solvers, imaginative people, not people who sit waiting for instructions and complain if instructions are not perfect.

Micromanagement of resources is something really annoying - let people organize themselves, if they are old enough to brush their own teeth and buckle their shoes, they surely are able to coordinate with each other.

Visibility and trackabililty are everything, but this has to be streamlined. IMHO lenghty status calls where everyone is supposed to give a status report to the manager are the single biggest waste of time. Just ask each team member to update a wiki with the info, and aggregate all wikis with RSS.
Daily status calls should be max 15 minutes - they should be quick, snappy, and leave room for subsequent individual interactions. Everything else is just waste of neuron-cycles. If a person talks for more than 30 seconds, it's bad.

There are a number of web tools to manage people, tasks, who is doing what, product backlog... in offshore dev it's even more important to use such a tool. Everyone should have one-click access to all info. This way the remote management is not any more the single point of contact for all operations.