Page 93 -
P. 93
64 PART TWO MANAGING SOFTWARE PROJECTS
4. Unclear definition of roles resulting in a lack of accountability and resultant
finger-pointing.
5. “Continuous and repeated exposure to failure” that leads to a loss of confi-
dence and a lowering of morale.
Jackman suggests a number of antitoxins that address these all-too-common
problems.
To avoid a frenzied work environment, the project manager should be certain that
? How do we the team has access to all information required to do the job and that major goals
avoid
“toxins” that and objectives, once defined, should not be modified unless absolutely necessary. In
often infect a addition, bad news should not be kept secret but rather, delivered to the team as early
software team?
as possible (while there is still time to react in a rational and controlled manner).
Although frustration has many causes, software people often feel it when they lack
the authority to control their situation. A software team can avoid frustration if it is
given as much responsibility for decision making as possible. The more control over
process and technical decisions given to the team, the less frustration the team mem-
bers will feel.
An inappropriately chosen software process (e.g., unnecessary or burdensome
work tasks or poorly chosen work products) can be avoided in two ways: (1) being
certain that the characteristics of the software to be built conform to the rigor of the
process that is chosen and (2) allowing the team to select the process (with full recog-
nition that, once chosen, the team has the responsibility to deliver a high-quality
product).
The software project manager, working together with the team, should clearly
refine roles and responsibilities before the project begins. The team itself should estab-
“Do or do not; there lish its own mechanisms for accountability (formal technical reviews are an excel-
3
is no try.”
lent way to accomplish this) and define a series of corrective approaches when a
Yoda
(Star Wars) member of the team fails to perform.
Every software team experiences small failures. The key to avoiding an atmo-
sphere of failure is to establish team-based techniques for feedback and problem
solving. In addition, failure by any member of the team must be viewed as a failure
by the team itself. This leads to a team-oriented approach to corrective action, rather
than the finger-pointing and mistrust that grows rapidly on toxic teams.
In addition to the five toxins described by Jackman, a software team often strug-
gles with the differing human traits of its members. Some team members are extro-
verts, others are introverted. Some people gather information intuitively, distilling
broad concepts from disparate facts. Others process information linearly, collecting
and organizing minute details from the data provided. Some team members are com-
fortable making decisions only when a logical, orderly argument is presented. Oth-
ers are intuitive, willing to make a decision based on “feel.” Some practitioners want
3 Formal technical reviews are discussed in detail in Chapter 8.