Train Hard Fight Easy
Train Hard Fight EasyProblem: 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:
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:
See also: LearningAndWeightLifting
EditText of this page
(last edited September 30, 2003)
or FindPage with title or text search