This post originated from an RSS feed registered with Agile Buzz
by Laurent Bossavit.
Original Post: Engineering Effective Teams
Feed Title: Incipient(thoughts)
Feed URL: http://bossavit.com/thoughts/index.rdf
Feed Description: You're in a maze of twisty little decisions, all alike. You're in a maze of twisty little decisions, all different.
If you manage software efforts, you are today facing a broader range of choices than ever before. Should you move work offshore, keep it all on one site, or distribute it across several offices? Current technology makes any of these possible but it doesn't provide the wisdom to choose effectively.
Recommendations about team composition tend to focus on an amorphous, aggregate model of the team -- "a team of five with a skill set including Java and UML" -- which served well enough in the past. Using this model, it may seem that offshore or distributed teams are a clear win, providing cost savings or more efficient use of personnel scattered across offices. But does such a model address the design considerations that matter in organizing knowledge work?
Extreme programming recommends having all team members in one room, customer included. This is a deliberate design choice, made in awareness of several factors and dynamics that apply in this situation. Consider, for instance, "overhearing," and what Alistair Cockburn calls information radiators. Consider as well how these methods trump more formal communication processes in a particular situation.
When a group of people pursuing the same overall goal are both colocated and shielded from interference from people not part of that overall purpose, they tend to be effective at acquiring information by overhearing. They are not disturbed by conversations taking place around them: the topic of these conversations is what occupies their own attention. But they will often pick up cues from these neighboring conversations and offer to help if someone is having trouble in an area with which they are familiar, even simply interjecting an observation that helps others make sense of the issue being discussed. Overhearing lets people share critical information in a timely and efficient manner, at practically zero cost or effort.
In the colocated situation, information radiators play a related role. These are conspicuous displays on the walls of the room of frequently updated information that reflects critical aspects of the software efforts. Good candidates for inclusion include number of defects, status of the most recent build, results of running test suites, risk of missing a deadline, and so on. Unlike information published on an intranet, these are constantly "in the team's face." Information radiators are hard to ignore, giving them a psychological impact out of proportion to the effort spent in publishing the information. A particularly notable result (failing many tests at once, for example) reported on an information radiator is likely instantly to elicit conversations among the team and mobilize the best of their skills toward a resolution.
These two effects and many more contribute to the effectiveness of information sharing and thus to the effectiveness of the project when the whole team sits in one room. In a distributed team situation, there is no single, easy, "standard" solution like putting everyone in one room, which at a single stroke achieves all these effects. We have to hunt around for bits and pieces. The structure of such teams is a complex design problem, with opportunities for mistakes that can easily wipe out the expected benefits suggested by the aggregate model.
Some team functions can be transposed relatively easily to distributed situations. The mailing list is a fairly good equivalent of the conversation dynamic; its nearly synchronous nature promoting intimacy, exploration, and so on. It even has something that face-to-face communication lacks: a memory. It does lack a number of aspects that are present in face-to-face communication, however, such as "meta" information about how people feel about the conversation, conveyed in facial gestures, intonations, and so on.
Other functions, among which I suspect are those provided by the overhearing and information radiator dynamics, may not transpose literally to distributed situations. For instance, consider the feature of some search engines that list keywords that people have recently submitted. That would be, for many software development contexts, a better transposition of "overhearing" than is the more literal transposition often attempted, at much greater cost, with speakers, microphones, and Webcams. What is important is not so much seeing and hearing colleagues as knowing what is on their minds and what has most recently grabbed their attention.
New technology is making the problem of designing effective teams more complex, not simpler. Don't be misled by oversimplified models into making choices that might turn out to be unprofitable. Do consider the design of your software team as one of the high-leverage choices for the project's success and plan to give it appropriate attention.
(Originally published in Cutter IT's "Email Advisor" newsletter, Sept. 15, 2004)
Previous Topic
