Distributed Team Patterns

We are some people trying to capture best practices for geographically distributed development teams. So far, we have been working inside a single company, but we have a hope there may be other people out there in the real world with similar experience who would be eager enough to start sharing these experiences. We have taken patterns to EuroPLoP and PLoP in 2004, and it looks like there is enough interest from others to have a discussion.

Our patterns and proto-patterns (yes, we are very interested in stories and discussions with anyone with experience and opinions on distributed teams!!) are set in a context of inter-company projects where team members are located in two or more product centers that are geographically far apart.

Here is a little story to introduce our thinking about geographically distributed teams.

"Company XYZ decided a few years back to build up a new engineering center in the far East. The decision was driven by a need for presence to build up business, as well as a desire to get access to highly qualified university graduates within some technical disciplines. Through the initial years of struggling to build up the center and enable it to develop products, several small projects were run in collaboration with other engineering centers within the company. There were may challenges to deal with. Not only were the centers located far apart and in different time zones (some had no overlapping work time), but also cultural differences and the variation in experience were pretty extreme. Over time, practices were established based on learning to work together. The company learned that it needed CommitmentFromAll? centers and all levels within the center. The development activity needed to be defined as OneProject?, with a DefinedOrganization? around it to support the team. On the team level, they needed an ExplisitCommunicationStrategy?. The work methods of the team developed over time, very much driven by the values from agile development. EarlyBonding? became an established practice, where the team would meet up at the start of a project to get a good start on their teamwork. Sometimes, team members had already done a TemporaryEngagement? at the other site as an introduction. Throughout the project, the teams would meet FaceToFaceRegularly. They found it very powerful to MeetAtIterationCompletion?, and they PreparedWorkspace? areas to accommodate their working style. Between their time together, the distributed team had FrequentShortMeetings? to keep the common pace and share progress and decisions. The team members had common time defined, and to reduce the negative impact of the irregular work hours they set up FlexibleHours?. Close to delivery time, the complete team would JoinForCompletion at a single site. On a practical level, access to modern communication tools were a necessity to keep the close daily communication. The standardization within the company on a CommonDevelopmentEnvironment? was key. The team members also worked on keeping to a CommonTerminology? and a ContinuallyAlignedProcess?. Realizing the need to support the distributed teams, the company make an effort to have PreparedTeam? and AssignedMentors? on distributed development. Each site had a LocalHero? to facilitate the collaboration, and they made sure they applied DistributedCredit? and had sufficient SocialFunds? for the teams. To further ensure the health of the teams over time, the team members on the distributed teams were CarefullySelected?, and a mechanism for ConflictManagement? set up. To try out implementations, PilotSolutions? were set up before growing the practice to several teams."

How about DistributedTeamAntiPatterns?

Surely being in the same location would be the best. There are many reasons why that can not always happen. In my previous position, I worked in an entity that resulted from merging/buying 22 different companies, over a long time period. Because of our history, not wanting to forcefully lay off or move people, and realizing our international presence, we have worked between a number of tech centers for many years. Recently, some of this experience has become more extreme because of bigger cultural differences, and time zones that are very far apart.

Do you mind if I hope for more constructive comments?

The comment was not intended to be destructive (or a snide way of "don't do DispersedDevelopment?"). It's a fair and useful question. A catalog of patterns is more useful when accompanied by a list of AntiPatterns.

I humbly disagree. Anyway, we have no plans to work on anti-patterns. Maybe a list of "we tried this and it did not work" short descriptions? But it is more than enough work for us on the patterns. Welcome to anyone who want to do some anti-patterns on this, though ;-)

Who is "we"? While the folks here at WardsWiki are more than happy to help you with this topic, and provide our experiences, keep in mind that these pages are "community" property, and may come to contain content over and beyond what you may find beneficial to your research. Though DistributedTeamAntiPatterns might be best left on its own page--many of us have lots of things we can contribute to both topics.

Sorry! We was referring to our little local team working on these patterns.

I am positively surprised on how quickly there are responses to this stuff. The whole point of entering it was to make it take a life of its own in the community, and see what happened. I asked Ward at PLoP if we could/should use Wiki, because we wanted to get in touch with people with other experiences and view points. Just did not expect it to change while I was still trying to get the initial stuff out. Anywhere I can go to get advice on how to lay out the pages for the patterns?