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.
   88   89   90   91   92   93   94   95   96   97   98