How do you deal with blame culture at work?
A bug is found in live production that costs the company loads of money.
The first thing they do is blame QA and mention what processes are in place.
But in a way QA did document the bug in an indirect way but the devs felt it was just luck or coincidence so it was left in the backlog.
The whole process gets reviewed by the higher ups and strictly monitored.
Did QA put the bug to the software? I think they’re looking in the wrong place and should be firmly but calmly informed of that.
I’ll let James and Michael explain the truth of the situation robustly, and quite humourously this recent podcast.
I feel I ought to add, what you’re describing is sadly quite common, and it needs tolbe approached with sensitivity and maturity. Whilst James and Michael are accurate in their assessment, approaching your management in a similar style may not ease the situation.
Take some time to think about your context, discuss it with colleagues and agree an approach.
@avenger12 Unfortunately, blame is not uncommon. Blame prevents the discovery of the real causes of problems because people feel unable to have a meaningful conversation. One of management’s obligations is to “drive out fear”. This is one of Deming’s 14 Points for Management. The 14 Points should be covered in management training. If management drives out fear, there should be no blame when there is a failure.
Instead of blaming QA, management should drive out fear so that you can use a method to discover the causes of the error. I have used both The Five Whys and Ishikawa Diagrams to uncover causes of errors. To uncover the causes of errors, you need management’s support because only they can create a blame-free environment necessary to find the real causes of errors.
When you(you as part of a team not personally speaking) have an escaping defect in prod, what is important to do it a root cause analysis(RCA).
About root cause analysis you can find online a lot of materials.(here is one example).
The thing is, it is not important who to blame, as scrum teams supposed to team work for delivery. It’s enough that it is being overseen by one of the parties in the design and development and it can slip into prod.
We do RCA in order to not repeat the same mistake twice, and it can also make us avoid other mistakes with same Root Cause in the future. At no point there is to blame anyone with the bug in production, because delivery is a team effort as putting bugs in production also a team blind-spot coincidence.
If the QA Manager does not see it that way it’s important that it’s reflected to him/her and the higher ups.
In the current company I’m in we don’t have a qa manager. The CEO is my direct manager. I’m the sole QA in the team.
Honestly that sounds rough, but I’ve been in those situations. It sounds like a small company if you report directly to the CEO, but if thats the case then they are your Line Manager.
So I would focus on regular communication that makes what you do more visible. Nothing too overwhelming or vast, just regular consistent updates on risk and progress. If not directly to the CEO then someone who has the CEO’s ear. Be seen as proactively providing information to the business on Quality and risk.
I like @yudit suggestion on doing an RCA. Imagine if you had those questions answered before the CEO gets notified of a bug. You’ll have a theory on why it was missed (in my experience it is never QA saying “Well we had the test planned but we decided not to execute it”), you’ve plugged the hole in your test approach if there was one, you spoke to the devs and product people if there are things they can do etc. Ideally, you want to be able to tell the CEO the issue was found, dealt with, a fix planned, corrective actions taken across the team etc. before they see a bug.
If there are other issues where the timescale to get good quality releases out is it odds with the resources you have, then get together with the wider engineering team to come up with a proposal on what needs to change to reduce the risks.
Those kind of actions should influence the CEO that “you and the engineering team have got this”. You’re all proactively trying to improve and take responsibility whenever anything goes wrong.
However, there are times where I couldn’t influence those above. The structure and people in those positions just aren’t going to listen. For those, I leave. Simple as that. No bitterness, I just feel that I can’t do the job in that organisation and its not an environment I can make a difference in. But before I leave, I have to say to myself that I tried to bridge the gap.
I have learned a lot from Bill Scherkenbach, and he has just made this great post on LinkedIn: “Stop the blame game”: https://www.linkedin.com/feed/update/urn:li:activity:7426807097130131456/?originTrackingId=FWdJj7QcTGZ3kFLOdhoBSw%3D%3D
That was a good watch thanks for the video 
I’ll re watch again from time to time