Can we stop the ‘blame game’?

Can we stop the ‘blame game’?

Photo by Aarón Blanco Tejedor on Unsplash

I’m sure you have heard this before (directly or indirectly):

• „How developer/tester/he/she did not think about this?”
• “Why wasn’t it tested?”
• “Where was the QA?”
• “Why it is designed/implemented this way?”

I wonder whether these questions have ever solved any issues of the person who asked them.

The only thing that these questions can start is… drama (if this is your thing, grab a popcorn each time when you hear the words presented above). The drama obviously begins when there is something not working like it was promised (no one asks these questions when everything works fine). And after that, it’s just a blame-game.

Client/stakeholder blames Management. Management blames developers/testers. They would blame management or requirements. The requirements cannot defend themselves so management blames developers/tester again and so on, the vicious circle continues.

Maybe after the game, some solution is created, but drama, blame, and disgust stay with the development team.

The blame questions

First of all, let’s address the elephant in the room. I assume that the questioner asks these kinds of questions to find the bottleneck that leads to a bug.

Unfortunately asking these questions results in finding a scapegoat, rather than a solution and the blame game starts with “This cannot be my fault, it’s for sure someone else’s fault”.

“That’s so great for team building” – said no manager/leader ever.

The easiest solution to stop this drama and get the problem solved is simple.

Don’t ask these kinds of questions. It could bring only harm rather than a solution to your problem.

Let’s gather more information about the problem and ask your teammates:

“What can we do to fix the bug and prevent it from occurring again?”

Your team would be more motivated by addressing that issue and searching for the future prevention plan rather than with making excuses or blame searching.

Can we do it another way?

Like I said before, we know what has started this drama – the big bad bug in the code. What we want, and need is a quick solution to get rid of it.

Even the true explanation that in the product there is an infinite number of bugs is not an explanation that management would be keen on. This issue is a team problem, that we want to solve (without any drama).

Everyone is responsible for quality, right?

Chinese whisper

Have you ever played “Chinese whisper” or a “telephone game”? The game where one person comes up with a message and whispers it to the next person in the line. Then the last person says it at loud. The way the message changes through the game is fun and amusing.

In IT we have our own “Chinese whisper”, but it does not always end with fun and laugh.

It’s called “task hand over”. You know, when the task comes from client’s request and goes from one department/team to another.

Technically, in the task summary and its description, there should be all the info that you need, but we know how it looks in reality. The game begins, requirements say one thing, the designer another, development implements it differently, Test/QA tests are based on the other information. Management hears that there is no problem and Clients receive some solution from the development team.

Sometimes the core information stays the same, sometimes we get another message thanks to some interferences.

How can we maintain message integrity every time and deliver what everyone thinks was promised?

• Agile shows a wonderful thing, which is a cross-functional team. Reducing the number of players in the game is a good way to start (fewer players equals fewer interferences).
• Preparation of presentation and showcasing it to the whole team. Visualizing the problem or request that we want to solve brings more to the discussion than plain text. More ideas can be gathered this way.
• If you cannot create a cross-functional team – pair the existing ones. Remove the silos, let people work and cooperate. Finding new information before the “test” phase will save everyone’s money and time. The only downsides I can see are that people will learn from each other and find more useful information in this process, what a shame…
• The least you can do is to update your wiki/docs/requirements so everyone can have access to it. But is a long run that does not solve the issue.

Project and its process

People make mistakes, that’s how we are programmed, but we as the people can also mitigate those mistakes.

And there will be more mistakes when we work in short time frames and the deadline is around the corner.

Also, when the deadline is near – the idea of over hours emerges. Some believe that with more man-hour everything will be fine. But the mood of your team, their mental health and focus will be the first to suffer and along with it the way the people give and assimilate the information. Without the proper knowledge of what needs to be done and what the issues are in the design, implementation or development process, we will for sure encounter the bug in later phases of development. And the blame starts over again.

Another issue can result in the fact that not all team members are not fully aware of the goal and procedures in the project. Every person on the team has its own way to implement or test things.

Setting the goal and showing the procedures of how things should be done, or what the pitfalls could be, as well as giving them a way to measure their work could dispel the illusion of shallow understanding of what needs to be done.

Who is the one responsible for a new feature and its quality? Is it the last developer who makes the change? The code reviewer? Or maybe a tester? Everyone in your team should test and verify the quality of new code changes, but there should be only one person that is responsible for delivering the task. It’s not about looking for a scapegoat, but a leader that will take care of the whole task. What should be this leader’s responsibility? Mainly to drive the whole development process of the new feature and make decisions. In addition to being the one responsible for knowledge sharing and the overall quality of the feature that will be created. How it is achieved, it’s up to them.

Not a single person’s issue

The issue is never done by a single person in a team, there are always more factors to it. I have shown some of them (and briefly gave an idea of how to mitigate them) but there is a lot more of them like:

• Product complexity
• Business logic/needs understanding
• Team Motivation
• Technical skills
• Listening skills
• Poor team communication
• Development process
• Project management
• Consulting with stakeholders
• Tools used
• Measurement/metrics used
• Approach to testing and quality
• Work culture
• Meetings structure
• Organization
• Team synergy
• Boarding process
• Historical decisions
• Maturity level
• Dealing with trade-offs
• And many more

From time to time, let’s step outside of our loops and verify the existing problem before jumping to the conclusion of blaming someone.

Yes, bugs exist because of the action of your teammates (“there is no bug without u”) but the number of them can be managed by proper actions. And it’s never just one person’s fault there is always a system behind it. Knowing that the system will help you a lot in the future.