This Month’s Pattern *

14 Face Time

The distributed project team relies on lots of face-to-face contact among the sites, to build the familiarity and credibility that enables long-distance teamwork.

“At computer society meetings one continually hears young programming managers assert that they favor a small, sharp team of first-class people, rather than a project with hundreds of programmers, and those by implication mediocre. So do we all.”

Some of you will recognize this excerpt; others may be surprised to learn that it was first published more than thirty years ago.[1] You still hear this today, though “programmers” have become “developers,” and today’s managers also specify a preference for a small, co-located team of rock stars. It was true thirty, forty, and fifty years ago, and it remains true today–this is the best way to build software.

And yet, large and geographically distributed development teams seem to be more common than ever. You may encounter project teams spread across half a dozen or more development sites, though two or three sites form the more common configuration. Granted, a large distributed team may be composed of smaller co-located teams, but it must be managed as a distributed team if the sub-teams are working on elements of an integrated system or product.

Regardless of the motivation, distributed development may be proliferating simply because the availability of collaboration technology makes it less daunting. Teams cope with the challenges of distributed development by using instant messaging, wikis, video-conferencing, and Web-based meetings, in addition to good-old conference calls and e-mail.

Those who make distributed teams work best are careful to introduce opportunities for members of the group to get together at least occasionally. Why is face-to-face contact so essential to the success of distributed teams? In the absence of adequate face-to-face contact, teams at one site tend to regard those at the other sites with disdain. “Other sites” often comes to mean “bozos.” Face-to-face contact that is regular, reasonably frequent, and cross-functional builds up the reserves of goodwill and benefit-of-the-doubt that we spend down on all those conference calls and Web meetings.

So, how much face-to-face contact is enough? This varies from team to team, but these general guidelines may help you to decide for your project:

  • Those most responsible for coordinating work among the sites need the most frequent contact. These people usually carry titles like program manager, project manager, or release manager. They need to meet multiple times per release cycle. Meeting quarterly is not enough.
  • Among developers, QA engineers, and technical writers, the more-senior people need to meet their counterparts at other sites at least once per release cycle. Establishing mutual credibility and respect at this level enables opinion leaders to influence more-junior team members back home.
  • Occasionally allowing junior team members to travel to other sites helps them see how their work fits into the team’s overall mission, and it exposes them to mentorship and career development with senior people at other sites. It also helps when you are arguing for a raise for your wunderkind to have a peer at another site support your high opinion of him.

Consider the following fool-proof recipe for guaranteeing the failure of a distributed development effort: Following the acquisition of a team at a distant site, the organization responds to the inevitable pressure to cut costs by restricting business travel “temporarily, until things improve.” To succeed at distributed development, you almost certainly will have to increase, not decrease, your travel budget.

Distributed development is an inherently difficult, high-risk practice. Sometimes, the potential to access or retain desirable talent justifies the risk. To borrow Tom Wolfe’s phrase, “I don’t advise it, you understand, but it can be done.”[2] Face time is one essential element.

1. Frederick P. Brooks, Jr., The Mythical Man-Month: Essays on Software Engineering (Reading, Mass.: Addison-Wesley, 1975), p. 30.

2. Tom Wolfe, The Right Stuff (New York: Farrar, Straus & Giroux, 1979).

* Each month we plan to publish here one of the patterns from our Jolt Award book, Adrenaline Junkies and Template Zombies — Understanding Patterns of Project Behavior. (Watch this space for a mere 86 months and you'll have read the whole thing.) The book is published by Dorset House Publishing, in the US and Hanser Verlag in Germany. It is available at Amazon and also as a Kindle book.


Hilversum, Mastering the Requirements Process
5-Nov-2018 to 7-Nov-2018

James Archer teaches Mastering the Requirements Process. For details please contact Adept Events. Dutch description, or in English.

Oslo, Mastering the Requirements Process
13-Nov-2018 to 15-Nov-2018

Mastering the Requirements Process with Suzanne Robertson. Contact Den Norske Dataforeignen for details. 

London, Mastering the Requirements Process
14-Nov-2018 to 16-Nov-2018

James Archer teaches Mastering the Requirements Process. For details and registration, please contact IRM UK.

in depth

Business analysis is often seen as a technical skill. But the business analyst has another set of responsibilities -- to dig into what the stakeholder's mind and uncover what is really needed, and not just what they say they want. 

A Ruby Beam of Light, Book I of Tom DeMarco's Andronescu's Paradox saga is now available in English in paperback and ebook, from Double Dragon Publishing.

"This war isn't going to blow anything up, only turn everything off."

Suzanne and James Robertson's "Requirements: The Masterclass LiveLessons-Traditional, Agile, Outsourcing". 15+ Hours of Video Instruction. 

Als auf der Welt das Licht Ausging, the German edition of Tom DeMarco's science fiction epic, Andronescu's Paradox, has now been published by Hanser Verlag in Munich.  Translation by Andreas Brandhorst.

James Robertson’s webinar for Software Education explains how agile stories are best used to ensure the right solution. Writing the Right Agile Stories on YouTube. Download the webinar slides.