Building Strong Development Teams

Your browser does not support inline frames or is currently configured not to display inline frames.

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.

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.