The Human Factor

1. Introduction

People are the most important asset in any type of project. The quality of the product is strongly dependent on the teamwork: “a good team builds a good product, a bad team builds a bad product” [1].

The main cause of a bad team is people themselves. It is usually enough for a single person to be bad to cause problems and reduce productivity. In this article I will discuss the concept of having a “bad apple” in your team and contrasting discussions and how to deal with them. I will also give examples from my experience I gained throughout my years of university.

 

2. Background

The “bad apple” concept refers to a bad fruit ruining all the other fruits next to it. In software engineering, this concept applies when the attitude of a team member affects the entire team such that the productivity decreases, problems arise and the quality of the product is jeopardised. In his article [2], Will Felps categorizes the types of human “bad apples” and suggests solutions of dealing with them.

He says there are three types of bad team members:

  • The withholder of effort: avoids doing work, does not complete tasks and does not take responsibilities
  • The affectively negative individual: always has a negative mood and attitude
  • The interpersonal deviant: proves disrespect towards his colleagues by having an inappropriate behaviour

Felps gives three ways to deal with these individuals:

  • Motivational interventions: upper management interventions or public criticism
  • Rejection: excluding from discussions and removing responsibilities
  • Defensiveness: revenge, good mood maintenance, distraction, denial and withdrawal from the group

It is possible that although the team doesn’t have a “bad apple”, diverse opinions can cause disruptive teamwork. In his article [3], Alistair Cockburn emphasizes how the difference and non-linearity between people have become an important factor when talking about application development. He presents fourteen concepts that summarize the human presence in a project. I believe that the most important facts that must be considered when assessing the success of a team are the following:

  • Trust in people to do what is necessary.
  • Adjust for people making mistakes.
  • People act according to their reward.
  • Recognise the presence of dominant personalities.
  • Let people work in unpredictable sequences
  • The communications load can soon dominate the project.
  • Software creation is limited by the ability of people to express their thoughts.

 

3. Experience

Throughout my university years I was part of a lot of group projects that aimed to teach us the importance of teamwork and organisational skills. However, no one actually instructed us how not to be the “bad apple” in our team. It is very likely that a lesson wouldn’t have helped us anyway since a lot of students would not have taken the advice. But in my opinion it would have at least made it easier for the good team members to confront and deal with the bad ones.

Every single team I was part of either had one or more bad apples in it or had people whose contrasting opinions lead to friction between colleagues. I have seen how the whole team has to suffer just because of one individual or how opposed attitudes put at risk the success of the project.

3.1 Slacker’s Effect

From experience I can say that in a university projects the bad apple usually comes in the flavour of “the withholder of effort”. Simply put, every team has a slacker. Such an individual can be observed as not attending the team meetings, bringing outsiders during the team discussions that distract everyone else or even find silly excuses for not being able to cope with pressure.

The worse thing about this situation is when you don’t see the bad apples from the beginning. Such an individual can be able to convince the team he is a hard worker and a good team player. The problem appears when you discover he is the exact opposite half way through the development time and adding more resources or removing people is impossible. In such cases disaster can be impossible to avoid.

The main effect of having such a person in my team caused “perceptions of inequity” between the other members. Everyone was comparing their contribution efforts with his and were considering the idea of being under-rewarded in the end. This can lead to the other team members to reduce their contributions and compromise the project themselves.

In a university environment, the motivational intervention by criticising the laziness to the supervisor would seem the most straightforward solution for such a situation. However, it doesn’t work very well since usually the supervisor does not take any action. I still don’t know if that’s because the whole point of doing a team project is learning how to deal with these situations (does this mean that the other solutions should be embraced?) or that the supervisor is too busy to get involved.

From experience, the best solution for such a situation is for the rest of the team to keep a strong relation. Having a good team leader can always help to eliminate interactions with the negative member and reassign responsibilities.

3.2 Diversity of People

I have also been in the unpleasant situation where the team had more bad members than good ones. Moreover, they were all good friends that didn’t take things seriously and were very reluctant in discussing each member’s responsibilities and taking advice from the others. I can’t put them in one of Felps “bad apple” categories since they were neither rude or with a negative attitude. With respect to their work, they finished in the end but the quality was very poor.

With only two of us left to do the rest of the work we realised immediately the seriousness of the situation we were in. Talking to the supervisor was not a solution since they were showing some progress on their work. We couldn’t possibly reject them either since they represented more than half of the team and the workload was too high.  We ended up fulfilling our tasks, keeping a positive attitude and hoping they will eventually finish the work they assigned to themselves. Disaster did strike us when our product failed to work during our presentation. Luckily we were given a second chance and my colleague was able to fix the bug caused by the bad members in time for our second demo.

This situation can be characterised by having team members with different attitudes and opinions with regards to work rather than having “bad apples”. Looking at Cockburn’s concepts, it was important for us to recognise the different personalities. We had to trust the others to do their necessary work and make sure that we can fix mistakes that might occur because of them. Moreover, if they wouldn’t have worked in unpredictable sequences or be able to express their thoughts in their own way the product might have not been finished at all.

 

4. Conclusion

In conclusion, every team will have a “bad apple” or occasionally more. Sometimes the “bad apple” might not be visible from the beginning and this could lead to problems later on in the development cycle. Other times, the “bad apple” effect is not very strong but differences between people’s personalities and attitudes can increase product creativity but also disrupt the teamwork.

Felper categorised the ”bad apples” and solutions against them in his article while Cockburn emphasises the importance of non-linearity between people. In both cases it is important to know how to deal with that particular situation. In a university environment it is very likely to encounter such situations while being part of group projects.

 

5. References

[1] Edwin Dando, “Behaviour Dynamics in Agile Teams”, July 2013

[2] Will Felps, “How, When and Why bad apples spoil the barrel: Negative Group Members and Dysfunctional Groups ”, 2006

[3] Alistair Cockburn, Growth of Human Factors in Application Development”, 1995