Ep 27: #FML

So, what happens when it all goes wrong?

As much as quality assurance is the job of everyone in a team, and getting QA involved at the planning phases means that QA is a process, not a step, work still goes through QA on the way to the client or user.

I still feel a level of ownership, which yeah, is my job, I’m supposed to own this, its what I signed up for. Its my job to work with the developers to make everything the best we can, and flag up issues. Its might job to find other people’s failure in a way. And sometimes its hard. Its hard to go ‘well, actually, there’s an issue here, we can’t go live with this’ but its the job.

But what happens when it goes wrong anyway? When the deadline isn’t hit, or the product isn’t up to scratch come the deadline?

I’m used to telling developers that I’ve found an issue with their work, that it doesn’t work quite right, or they’ve missed some part of the AC, but sometimes a bug is found after it’s gone through me – either the client picks it up, or a developer or someone else involved in the project does and I’ve missed it. And it sucks. But, you’ve got to use it as a way to learn.

A product hitting the client late, or with bugs that should have been found is always a blow to everyone, but how do you find out the cause and learn from that to move forward?

I think first of all you need the right atmosphere – looking for a reason and a process that maybe needs fixing is different from pointing the finger. You need that kind of atmosphere where people are – not comfortable being wrong, but comfortable admitting when something wasn’t right. I’ve been in retrospectives where developers have admitted they felt they missed too many issues before passing work to me, and that was noted but just accepted, and the developer moved on, knowing they wanted to approve. I’ve done the same. I’ve spoken to PMs about feeling like I can’t handle the workload, and I’ve been upfront where there have been issues.

I think this goes a long way to preventing failure by missing a deadline.

You also have to be able to look at the processes. Were they followed correctly? If so, is that the issue – is there a shortfall, or something in the project that needed a more custom process? If not, why not? If all of the above doesn’t yield any issues from the process, was it a communication issue, a client issue?

There needs to be a balance between assuming there is an issue with the process and assuming the failure in human error. And of course, allowing for the ‘shit happens’ defence.

The most important thing, I think, is to not immediately try to find who to blame. You want reasons, and responsibility maybe, if there’s an ownership gap maybe, but you don’t want to play the blame game, that makes people immediately defensive.

A couple of months ago, at the North West Tester Gathering, there was a meetup themed ‘Failure is Not a Dirty Word1’, and there were three talks about failure, and it was really interesting to hear people be so open about failing. And its useful, because hearing other people talk openly about failure and what they learned from it encourages other people to do the same, and admitting and learning from failure is more useful than being defensive about it.

My points of failure tend to be:

I rush a lot. And sometimes I do miss things I should catch because of this. Generally I’m good at catching myself and going back and looking over the task again, because I know this about myself, but my first reaction to pressure is to go faster – a legacy from working in pharmacy

Communication. Sometimes my anxiety means that I find it hard to communicate in a timely manner, especially if it’s bad news. And procrastinating on that can mean the bad news turns into worse news.

And talking about failure is important because we need to face it in order to learn and grow from it. So let’s share our fails today!

Footnote

[1]https://www.youtube.com/watch?v=_DWl4Wtf5_U&feature=youtu.be

Leave a Reply

Your email address will not be published. Required fields are marked *

Tags: , , ,