Bad Apples

One of the interesting pieces of work we get involved in are rescue projects. Rescue projects can be thought of projects that aren’t delivering or won’t deliver either to timescales, feature requirements or quality.

In a rescue project there are many areas that normally need addressing: Project Management, Documentation, Process and Quality. The one common theme in rescue projects is people; when we are brought in to help on a project people start to worry about losing their jobs, but more often than not are un-accepting of the situation they are in.

The reasons for projects failing are numerous but people are the main cause, Jim McCarthy in his 1995 book Dynamics of Software Development (ISBN 1-55615-823-8) discussed flipping the bozo bit where people fundamentally just lose the plot and need to be refocused.

A recent post on the problems of negative focused staff (Rotten Apples) by Jeff Atwood (Coding Horror) has sparked some thoughts, rather than copy sections out I urge you to read the posts and I have added some of my experiences on the same matters.

Dealing with Bad Apples (read this post)

Looking at projects where we have seen individual issues, the ones that strike home are refusal to have code reviewed, increasing amounts of secrecy (keeping lists on paper not electronic, discussions with third parties outside of the project or company), consistent grumbling but supplication when confronted. But I think the most common sign is complaints about others to divert attention away from the real problem. I can’t say how much is conscious, and malicious or not, it must be dealt with.

The striking mark is people on the high horses who stand absolute in their correctness, my advice, shoot the horse and then deal with the problem.

The Bad Apple the Group Poison (read this post)

I have run though nearly all the projects that have had problems and this post contains the key -

The worst team member is the best predictor of how any team performs

and for worst, it is more attitude than technical ability.  We have seen projects with what should have been a dream team fail but this fits the pattern, not technology but attitude.

It is strange that the people who are the problem are normally the ones who should have the most potential, but have flipped the bozo bit and refuse help. It is rare that the people I encounter don't have the ability (they may need training and advice) but they are missing the point and sometimes languishing in politics seems an easier ride, but they always fail. Only once do I think someone was out of their depth and in that case I feel they were making the best of a bad situation.

In any project, people do need to stand up if there is a problem, and fight their corner, rather than just sit and whinge.  They then need to work through getting it resolved in a short space of time, in a reasonable manner, and accept the outcome.

In summary whilst it is generally best to maintain all project staff, there is a point when management must make a hard decision for the good of the group rather than the individual.

I’m interested in others’ experiences on this topic.

b.