You Have the Wrong Team

As a project manager, you have just staffed your project. Sorry to be the bearer of bad tidings, but you have the wrong team. If you an experienced project manager, you already know this. But you did the best you could from the resources you had available. It is the wrong team because:

• You are missing the experience you need in some key areas, and
• The team members don't necessarily work well together.

Agile practices help here, particularly the practices of collocation (and you do sit with your team, don't you?) and pair programming. If you are missing experience, collocation and pair programming lets you grow that experience by judicious pairing. Knowledge transfer is quite rapid and efficient in this environment. Collocation also dampens down the "finger pointing" that often plagues teams. ("He doesn't understand!", "She is so stubborn!", and the like.) It is much more difficult to talk behind someone's back when she is sitting in the room with you.

If team members still have difficulty working together, your being in the room provides insights to the solution. Is it a matter of tone (challenging, dismissive, personal rather than business)? Then coach on interaction style. Is it disagreement on technical matters? Ensure swift resolution before it becomes personal.In this area, Agile practices can be a disadvantage:collocation and pair programming will exacerbate negative relationships. Whereas you might be able to ignore or defer action when each team member sits in their own cubes, such deferrals are quite destructive in an Agile team with its close proximity.

Net-Negative Producing Programmers (NNPP)

Agile luminaries have coined the term NNPP to identify team members whose overall impact to the project is negative. That is, the work they do is less than the harm they do to their colleagues' productivity. An NNPP may be productive outside of an Agile environment. In a cube, their griping has no listeners. There challenging, terse tone goes unheard. But given their visibility in a collocated environment...

I recently saw on the Web a report purporting to show the impact of one bad apple on the rest of the team. A single individual typically can negatively impact other team members numbering in double digits! So indeed, one bad apple can spoil the whole bunch.

There are several ways to identify such individuals:

• Observe. Being in the room, you can see the behavior. Even more important, you can see the impact on overall team. The situation can be corrected by coaching, or ultimately, removal.
• Ask the team. The team knows who is acting incorrectly. Borrow a lesson from Survivor, and let the team vote someone off the island.
• Who gets picked last? If pairing is practiced, who is the person no one wants to pair with?

If you fail as a project manager to act quickly on identified NNPP, morale issues will quickly ensue. Your inaction, in particular, will be glaringly obvious to the team. Your leadership, dedication, and even competence will come under question.

Once more for emphasis: Failure to address an NNPP problem will rapidly destroy team productivity.

The Continuing Issue

The real fatal flaw in staffing projects, and Agile projects in particular, is not realizing that the project staffing needs change throughout the project. Projects that acquire their staff, and then stick with that staff throughout, will incur excessive costs if not fail outright. Staffing must be adjusted throughout the project.

A few years back on an eight-month Agile project, I made 10 staff changes in the first 6 weeks. The core development team had 16 different participants, but only 4 were on the project for the entire time. Rather than being a disaster for such team instability, the project set high water marks for productivity and quality that have yet to be touched.

Why does staffing need to be adjusted throughout a project? It is for several reasons beyond staff quitting and needing to be replaced:

• The needs of the project change throughout the project. DB tuning will be important at some stage, but not others. Knowledge of systems with which the project much integrate will be needed at some time. The general load of analysis, development, and testing will drift during the project.
• Team members will grow during the project, particularly on projects lasting more than six months. Exploiting this growth is part of good team management. Again from the above example, I reduced the number of developers to six toward the end of the project. They produced so much code, however, it took 17 testers to keep up. The developers skills had increased that much.
• An inbred team will cease innovating. Studies of innovation reveal a significant drop in innovation in a team that has been together for as little as six months. New blood is needed, even if only to challenge the patterns of current thinking.

As a project manager, you must constantly be alert to tweaking the team. You may raise eyebrows by constantly shifting your team composition; ignore them. When the need for an expert has passed, roll her off the project. Bring in a specialist when the need arises; exploit collocation and pair programming to harvest the knowledge and release the specialist. Perhaps that resource you really needed was not available at the start of the project. Bring them on board when they are available.

Successful team tuning requires building a strong relationship with two groups. First, be willing to share your experts with your colleagues. Hopefully, they will reward your good will with the loan of a needed expert of their own. Don't hoard resources when the need has passed; rather, release them to reduce your costs and maintain the morale of the resources. Second, build great relationships with your staffing or resource management team. Send them flowers or buy them a case of beer (or both); they will start to call you when a resource becomes available that you might use.

Application development is chaos; react or face corresponding chaos in your team.