Building Strong Development Teams

People and their interactions have ten times the potential impact on productivity compared to tools and processes. Fortunately, there is much you can do to improve the productivity of your teams, thus enabling them to become more flexible. To enhance flexibility, enable developers to gain experience in modifying processes. Alistair Cockburn has found three levels of process mastery. This is an essential skill for flexibility, so, in addition to developing it, place people with high mastery levels in key positions in the project, for instance, if the user interface of your product is subject to great change, make sure that someone fluent in the processes involved leads this activity.

Commitment

Flexibility requires in-depth involvement in the project and commitment to it. Someone who is only involved part time or peripherally in a turbulent project is constantly out of date, and others waste time keeping them current. You can judge the commitment of team members by using an analogy to the breakfast of bacon and eggs, plus a glass of milk. The pig is fully committed, having given its life to the project, the chicken the life of the next generation, and the cow is merely contributing some nourishment.

pic, cow and chicken
From Flexible Product Development by Preston G. Smith, Jossey-Bass, 2007. © 2007 by John Wiley & Sons. Used with permission. Illustrator: Lyn Doiron
.

These differing levels of commitment make a huge difference in the contribution made by various team members. Strive for pigs on your team and eliminate the cows (who sometimes turn out to be "helpful" managers).

Co-location

Opinion is strongly divided on co-location. Don Reinertsen has surveyed developers and found that those who have experienced co-location (defined by him as at least engineering, marketing, and manufacturing located within 20 m or 60 ft of each other) would do it again -- unanimously -- if they had to bring a new product to market rapidly. Those who haven't experienced it have countless reasons why it isn't a good idea or isn't practical. But notice that in no case is their opinion based on having actually tried it.

There is strong new evidence for co-location. It has become a standard practice in agile software development thorough pairing (see Williams and Kessler on the Resources page). Olson and Olson, in a survey paper, "Distance Matters" (see the Resources page) conclude that not only does it matter but that "distance will continue to matter." Teasley, et al. (see the Resources page) ran direct comparisons between co-located and non-co-located teams and found that the co-located ones were twice as productive.

Those who do not advocate co-location mostly observe that it is impractical in today's global workplace. Admittedly, it has become more difficult to do as teams have spread around the globe to take advantage of skills where they happen to be located.

Fortunately, this is not an either-or situation. Once you see the advantage of co-location, there are many things you can do to obtain much of its benefit by applying partial co-location. For instance, you can co-locate members of the team who are in the same city, rather than having them spread over your facility. If you can afford any travel, bring the team together at the beginning of the project, both to build relationships and decide on working approach but also because it is in the beginning of the project that everything is fuzzy and can really benefit from body language.