Problem:
Projects stumble, crumble, and bumble along as teams fail
to organize themselves under pressure.
Context:
Teams are thrown together and then presented with a project
without first establishing team mentality or shared skills, knowledge, or
vocabulary. Consequently, everyone learns "on the job" by trial and error,
often guided by some resident guru whose biases and narrowness of view may
prevent the team from examining a number of options, due both to the uneveness
of experience and relative political power. The team, under schedule pressure,
performs typically in one of two modes:
GuruDoesAll or
LetsPlayTeam.
Forces:
- Schedules determine everything.
- Good teams take time to form.
- It's not a perfect world, so make do with what you've got.
- Training flattens the knowledge distribution.
- Training sessions reduce formality and barriers.
- Common vocabularies are essential to teams.
- Training is expensive.
- Training costs stand out.
- Training is worthwhile.
- Good training is tough to get.
Solution:
Train the team as a unit in relevant technologies. Give
everyone the same tools and language.
Resulting Context:
The individual differences among members diminish
as learning is shared, particularly when relevant classes are given to the
entire team at the same time. Additionally, team members become more familiar
with one another's background, education, experience, and problem-solving
approaches, as well as personal styles. The team is not using the project as
the primary learning experience.
Rationale:
The fact is that whatever training is required will be
exacted, whether at the hidden expense of the project, or at the explicit
expense of training costs. There is no escaping training of one sort or the
other. In any project, without formal training, members tend to try to
self-educate, resulting in a lack of common culture or vocabulary.
Additionally, with schedule pressures, internal competition, egotism, and
fear, members may degenerate into one-upsmanship, hiding information from
team members that makes them look especially good to management. Therefore,
to give everyone an equal opportunity as well as iron out some of the initial
team issues, sending the entire team through formal training sessions relevant
to the project can consolidate expenditures and cut risks.
However, training is only part of the answer. For newly formed teams without any
experience working together, a
TrialProject may be required which is analogous to
applied use of the newly acquired knowledge in a timely manner. For example, units
in an army, though trained in the same basic skills, still perform mock battle exercises
together to consolidate their team skills, as do baseball teams, etc. Software teams
should be no different.
Experience:
What was a generally acknowledged dysfunctional team at
AGCS was permitted to stay together for the second phase of their project.
At their members' insistence, they were all put through Design Patterns
training, platform specific training and specific tools training as a group.
Consequently, in the very early days of the second phase it was apparent
that they had a common vocabulary, and had enough common shared knowledge
of their new tools such that they could then pool all the specialized
knowledge that each had developed on their own, rather than having
specialists for each tool. Additionally, the classroom situations allowed
members to relax and interact with one another as peers, since the material
was new to practically everyone. The performance of the team in design
activities was greatly improved, and morale improved to the point that all
members decided to remain together, despite the events of the previous phase.
Related Patterns and Anti-patterns:
Author:
DonOlson 1995/09/13
See also:
LearningAndWeightLifting