How to resolve 6 common conflict situations with colleagues

Programmers program. Testers test. In an ideal world, everyone would do what they were good at (or at least what they were employed for) and the result would be a stable reliable fit-for-purpose product that helped the customer stay happy, the shareholders become rich and you survive to work another day.

The world of software development, though, is far from ideal. Tight deadlines, unclear requirements, limited budgets, and human errors make the office a volatile place with constant fire-fighting. Tempers run high. Patience runs low. Programmers and testers are at each others’ throats. And may always be.

Here’s how to keep your cool and deal with some common stressful situations at work, when the tester says:

1. “It’s a bug, not a feature. It’s not supposed to work that way!”

Programmers, ignore the implied “stupid”. Get the business analyst or project manager to spell out exactly what the “feature” is meant to do, by updating the documentation.

If there isn’t any documentation to clarify the situation, it probably means the Business Analyst (BA) has not thought about the possibility of something working in a different way than expected. Ask the tester directly if it really is such a big issue. Does an exception need to be made? Does it need to be raised now? How often will it be encountered? Is it stopping any critical function from being completed? Testers may not always be in the best position to discern what is urgent and what isn’t. However, for most busy project managers, it helps to know at least roughly how critical a bug is so that they know which order to deal with a list of them in. It saves time. The programmer and tester can try to put their heads together to find if there is a work-around available to continue the business functionality and if the bug can wait.

2. “It doesn’t work on my machine.”

It works on yours, and you can’t replicate the problem, so how are you meant to fix it? Use the tester’s machine. Or ask the tester to demonstrate the exact bug reproduction steps on yours. Testers may not always be articulate, clear and accurate about bug reporting. Employ screen shots freely. Seek clarification quickly if the bug is reported in ambiguous language. “Tick the XYZ checkbox” means tick the XYZ checkbox. On the other hand, “Check the XYZ checkbox” can mean take a look at the checkbox to see if it is ticked or unticked.

Your customers are not all going to have the same system configurations, so the defect may crop up eventually. Yes we would all like to avoid confrontation. But we would also like to avoid embarrassment if there is a risk something may go wrong in live production.

3. “It was working yesterday, John’s broken it.”

It is possible something has regressed. Especially if more than one programmer works on a system or if the code is branched. Perhaps multiple updates happened on shared files. Perhaps a reference library has been modified. Get the configuration/release manager to check what has changed since the previous day or version and fix it. Don’t blame or accuse your fellow programmers for something that is inevitable. Software is unstable. The sooner everyone accepts this, the quicker they move on.

If manual regression testing is taking up too much time and resource, find out if it can be automated. If patch fixes keep breaking the system repeatedly, the deeper root cause needs to be found.

4. “This is not a requirement, just a nice-to-have suggestion.”

A tester’s role is not just to find and log bugs. It is also to see what happens when the unexpected happens. To act as a reference for the project’s overall progress. To ask questions no one else has thought of. To provide a different perspective. To anticipate future problems. To highlight gaps in requirements, understanding and implementation. To suggest improvements that will make the user’s life easier.

From your point of view, time may be short. Or testing may be wandering all over the place and not have a clear focus or direction. Ask the tester to log the item and mark the status “On Hold” with a remark about why the item takes lower priority. Make sure you don’t neglect the item out of miscommunication or personal prejudice. Nice-to-haves can turn into change requests and money-earners later.

5. “This is within scope and needs to be fixed now.” or “This is an implicit requirement.”

A programmer’s job is compartmentalised. He is given a requirement, asked to code the solution and barely has thought to spare for the surrounding system. A tester’s role is the antithesis. She looks at the bigger picture and observes, detects, analyses, cross-checks and reports several things happening simultaneously. She doesn’t go looking for unrelated bugs or unsatisfied requirements, but when she finds one, she cannot ignore it. As a user representative, she doesn’t care if it is something that is currently being developed or has existed from an earlier release. So the “scope” of testing is never the same as the “scope” of programming. To resolve this issue, get the management to step in and make a decision. It gets the pressure off both of you, and puts the responsibility firmly on the shoulders of those who can handle the repercussions.

6. “Why have you rejected this bug?”

The tester is the company tester. She is not the business customer. Nor is she the end user. But she is acting on behalf of both those people. A competent tester can imagine a lot of scenarios that an ordinary user can’t. A rejected bug hurts her, but not as much as one rejected for the wrong reasons or for no reason at all. Give your rationality behind the rejection with a short note, so that the tester knows better next time, then leave it alone. Further arguments or involved discussions will not serve any use. Only time will tell who was right.

Mike Myatt is a leadership advisor to Fortune 500 CEOs and their Boards of Directors. Widely regarded as America’s Top CEO Coach, he is recognized by Thinkers50 as a global authority on leadership. He is the bestselling author of Hacking Leadership and Leadership Matters, a Forbes leadership columnist, and is the Founder and Chairman at N2Growth. “Conflict in the workplace is unavoidable,” says Myatt. “The ability to recognize conflict, understand its nature, and bring swift and fair resolution serves everyone well.” He believes conflict rarely resolves itself. “Conflict normally escalates if not dealt with proactively and properly.”

Withdrawal, Confrontation, Consensus and Avoidance are some conflict management styles and one size doesn’t fit all. A high Emotional Quotient, Clear Thinking, Reflective Listening and Keen Observation are important skills to possess.

Jonathan Kohl is an internationally recognized consultant and technical leader. He is the founder and principal software consultant of Kohl Concepts, Inc. Jonathan helps companies define and implement their ideas into products, coaches practitioners as they develop software on teams, and works with leaders helping them define and implement their strategic vision. He is also a popular author and speaker. When asked how he avoids conflict, he says, “I don’t. It is a natural part of human interaction. If you try to avoid it, you just drive the energy and emotion underground and it gets expressed in unhealthy ways.”

Testers need to be tactful and diplomatic when raising defects. Their job is essentially to find faults in other people’s work, and they need to realise that for the programmers this can be unpleasant and difficult to accept.

On the other hand, programmers need to be aware that bugs are not personal. While more bugs found can mean more rework, longer hours and late sitting in the office, project delays, estimations getting messed up, more pressure and being labelled incompetent, programmers can also do a lot to minimise conflicts in the office:

• Empathise – others may have a valid point you haven’t thought of.

  Kohl says, “People I’ve worked with tend to feel more comfortable if they feel they are being heard and their ideas are considered seriously, even if they don’t always get their way.”

  “Understanding the other person’s position and motivations is critical. Help those around you achieve their objectives,” says Myatt.

• Attack the issue, not the person – never introduce a personal motif into any argument. “You always do this!” “It’s just like you to say that!” “He is so <unflattering adjective>!” Always keep things on a professional and courteous level.

  Myatt advises, “Don’t play favourites, don’t get involved in drama, and certainly don’t tolerate manipulative, self-serving behaviour.”

  Kohl adds, “I don’t tolerate personal attacks, and I don’t tolerate gossip.”

• Anticipate and come prepared – like any good battlefield strategist, pre-empt your opponents by being forearmed with knowledge.

  Myatt says, “Most conflict results from information-poor information, no information, or misinformation. Clear, concise, accurate, and timely communication of information will help to ease both the number and severity of conflicts.”

  So how does he handle conflict when it happens? Kohl believes conflict helps encourage a diversity of opinions and ideas. “I facilitate healthy conflict by having some ground rules: any idea is worth bringing forward. I don’t judge anything no matter how silly it might sound. I encourage people to be self-critical, to speak from the heart and to go with their gut instinct. From there, I encourage people to investigate those feelings and see if they can gather some data to see if their idea is defensible or not.”

• Take it slowly – introduce ideas gradually so that people get time to let them sink in.

  Myatt believes having clearly defined job descriptions so people know what’s expected of them and a well articulated chain of command to allow for effective communication will help avoid conflicts. “Creating a framework for decisioning, using a published delegation of authority statement, encouraging sound business practices in collaboration, team building, leadership development, and talent management will all help.” This creates awareness and sets guidelines are more easily acceptable to others.

• Get assistance – seek out the key players and bring them over to your side. They will, in turn, be able to influence others.

  What does he do to facilitate conflict resolution? Kohl encourages team members to resolve problems by getting together to talk about them. “If people won’t get past arguing over ideas, I ask them to prove out their ideas. Reality, measurable data and criteria tend to prove which idea is better, and we all learn and move forward much more effectively.”

  Myatt advises seeking out areas of potential conflict and proactively intervening in a fair and decisive fashion is likely to prevent certain conflicts from ever arising. “Minimize the severity of the conflict by dealing with it quickly.”

Co-operation, collaboration, team spirit, and frequent communication are crucial. The relationship between programmers and testers keeps rebounding as forcefully as a stone and a catapult. Neither can achieve anything significant without the other. You could throw the stone by hand, and you could use a grape on a catapult, but it wouldn’t make the same impact. Conflict can be a time for discussion, reflection and action. If viewed positively, it can be a great building block of vibrant team dynamics that can reap huge benefits.

We are all developers in that we all help develop a piece of software that provides a solution to a business problem, that satisfies a business need or requirement, that creates an actual product out of virtual ideas. Where possible, we need to change the system that sparked the conflict in the first place. Remove the trigger and the fuse won’t blow. Where this is not possible, we still need to work together, so we might as well get along well and make the best of it. Celebrate our differences. Highlight our individuality. Adopt the necessary social skills. Learn from conflict and use it to grow. After all, how dull and boring the world would be if everyone always agreed with everyone else!