Saturday, January 20, 2007

Separate teams by functionality not activity

Much of the traditional thinking on the onshore/offshore boundaries is based on the activity that people do. So analysis and design is done onshore, construction done offshore, and acceptance testing is done onshore. This obviously fits well with the waterfall model.

We've found that contrary to this, matters improve when we make the offshore team handle as many activities as possible. So we prefer to see them do as much analysis and design as possible, subject to the limitations that the requirements are coming from onshore. When we do split an effort with onshore and offshore development teams, we do this along functionality grounds rather than activities. We break the system into broad modules and let the offshore team tackle some of these modules. However unlike most groups that do this, we don't make a big effort to design and freeze the interfaces between these modules: continuous integration and weak code ownership allow the module interfaces to evolve as development goes on.

An important part of this is to grow the analyst part of the offshore team. The more someone local to the developers understands of the business, the more the development team can develop efficiently. Instead of having to wait overnight to answer a question, developers can get answers right away - which removes blocks to progress. All this means that you have to focus on growing the business knowledge of the offshore analyst. This takes time, but the local knowledge is a vital counterpart to the business knowledge onshore.

A corollary to this is to not divide teams by horizontally (having one team do presentation and another do database). In general I prefer a functional staff organization - and remote teams exacerbate the problems of dividing teams by layers.

The most important thing to remember here is the dominant power of Conway's Law - the structure of the system will mirror the structure of the team that built it. That means that it's important to separate distributed teams by modules that are as loosely couples as possible.