Software Development Dilemma #1: My Team Seems to Spend Too Much Time Arguing. What Can I Do?
This chapter is from the book
This chapter is from the book
This chapter is from the book
Some disagreement and even downright arguing is normal and healthy, particularly at certain times in the project's life.
When people first start to work together as a group, there is a certain amount of posturing and jostling for position. People come to the project with different preconceptions about how it should be tackled, and they bring different viewpoints to bear. They also have their own hidden agendas and their own personal priorities that they hope to pursue on the back of the project. These various differences come out fairly soon after the real work starts, and are manifested in arguments about work and in personal friction.
This is normal and natural behaviour for human beings. It does not mean that you have an unworkable or disruptive group of people. Quite the opposite, it shows that you have a group of people that is starting to gel into a team. Indeed, you should be far more worried if you find yourself in a group of people who sullenly avoid talking to each other, or who keep going off for furtive discussions in private cliques. A lack of open discussion and disagreement would indicate a serious problem.
I would go as far as to say that a team cannot work effectively unless it has been through the arguing stage. But that stage has to be handled properly by the team leader. The arguing stage should subside once the direction of the team is established and people have work that they can get on with, but it is necessary to go through that stage, to get issues out into the open and resolved. If you try to suppress arguments, they will rumble on for a long time, surfacing periodically to disrupt the project. Better to get them out in the open and settled at the beginning.
It is the leader's role to mediate in conflicts. You must be seen to be taking note of the opinions raised, and to be listening openly and fairly to them. You must balance the needs of the project (especially as seen from the customer's point of view), the needs and desires of the individuals making the argument, and the needs of the other people who have a stake in the outcome.
You must not give in to individuals who are jostling for more responsibility than they deserve. Nor must you allow the project to be pulled off course because of a desire by one (or even all) of the engineers to further their own priorities, such as building up their CVs. It is during this early argumentative stage that the guiding principles and priorities
of the project should emerge. Indeed, it is the emergence of a consensus about these principles and priorities that eventually causes the arguments to cease. So at the start of the project, you should be constantly ready to state, and sometimes to modify, the principles of the project. These principles may cover both technical and organizational issues.
It is for you as team leader to galvanize arguments into a decision, and more than that, it should be a decision about a clearly stated basic principle, not just about the specific issue. For instance, if some of the team are arguing that a new technology should be adopted for this project, while others are arguing for a more well-understood route to be taken, then you have the opportunity to state a principle, such as 'we will do it the old way because there are so many other new factors on this project to worry about that we shouldn't risk using that new technology as well' or alternately you might decide 'we should use the most productive tools available to us even if it takes time to learn them'. It is for you to reduce the specific arguments down to a choice of more general principles, and then use the project priorities to decide between the possible principles.
Far from suppressing arguments in the early stages of a project, it is your job to get them out in the open where they can be discussed maturely, and not to allow them to become personal or entrenched. Many people prefer to grumble, or to make snide remarks, rather than raise an issue directly. You should act as a catalyst, airing issues that you see to be contentious, listening to the opinions, and where necessary forcing a decision to be made that everyone on the team can live with.
It is worth remembering that the arguments may start all over again if a new person joins the team. After a little time you will notice friction building up between that person and the rest of the team. Whilst the team may be polite in the new person's presence, they may be scathing behind his or her back. Do not panic. The person is not being rejected, in fact they are starting the process of being accepted.
Another time when disagreement is to be allowed or to some extent encouraged is during reviews, especially design reviews. Engineers often have quite large egos concerning design issues and patterns and can find it hard to accept that other people may have a different approach that is as good as their own, or at least good enough. Very often a better design will emerge from a clash between opposing viewpoints, if a little creativity and humour are also thrown in. It's the team leader's job to mediate in these discussions, ensuring that everyone gets a fair hearing and that the discussion stays professional and doesn't become personal. Good design meetings are often full of banter and good-natured insults.
Arguments may be healthy in some circumstances but they should not be allowed to go on too long or to happen at inappropriate times. If the same argument has been repeated three times, there is no point in having it a fourth time. In this situation you should quickly review the decision that has been made, and then make it clear that the decision is made and the team must move on. If decisions turn out to be wrong then they will have to be reversed, but they must stand for the time being. If someone on your team absolutely refuses to accept the consensus of the team and continues to be disruptive, you have got a personnel problem to deal with, either with that person or with the make-up of the team as a whole – see SECTION 22: SOMEONE WHO'S A REAL PROBLEM.
Beware, however, that shy people can be inhibited by a 'robust macho' atmosphere and may be alienated if it goes on too long.
Sometimes there can be problems where a person suppresses their disagreements. This is quite common with contract staff, who often feel it
inappropriate to disagree with the consensus of the team or with its leader. This is an unhealthy situation, as someone will not work effectively if they don't believe in what they are doing. However, it is very hard to remedy. Demanding to hear a person's opinions is likely to be very counter-productive. The only solution is to encourage a relaxed and supportive atmosphere in the team, where opinions can be voiced safely, without fear, by all members. Always act against any tendency for people to put others down, score points, or take an 'us and them' attitude, either across a split within the team, or with regard to other teams or organizations that you work with.
As the team matures, the number of arguments should reduce. In a healthy situation this is because the project's principles have been defined and accepted by the team and there is no need for further discussion on them.
When a team works well together, everyone gets a reward in the form of a more relaxed, productive and sociable working day. For most people, this reward is worth sacrificing some of their own personal agendas and preferences, and so most people will soon commit themselves to the team's common approach if they think that a real team atmosphere and a successful project are going to result.