Failure is such a difficult word. When I hear failure, my hearth shrinks a little bit. Anxiety kicks in, suddenly, I don’t feel as if I achieved anything and even past achievements seem smaller now.
Does this feeling sound familiar?
We all know, at least at a certain level, that we learn when we fail. We adjust, we explore new options, we discover new options. Because we know for a fact the option we tried didn’t take us where we wanted to go. So, there is no other way than learning and expanding.
We also know that when we attempt new tasks, new ideas, new things, we might not getting right on the first try. More often than not, we fail first and later on we succeed. Some might take more failures than others but we still try more.
With this settled, I am all for learning from mistakes, from failure, from outcomes which didn’t go my way or in a general direction of my goal. But that comes at a later stage, after all the beliefs about failure start to quiet down.
I believe there is something to be done here in our domain.
When a developer delivers his code in testing, we assume there might be something not quite right. We validate the functionality she delivered behaves according to specifications. But when it doesn’t, we all feel frustrated. Developers need to rework and fix the errors, testers need to investigate the errors and retest when it is fixed, product leadership won’t receive the functionality in time, and the list of people and motives goes on.
We focus on solving the errors, we focus on the frustration and we are under pressure to deliver faster. The more times we try, the more stressed we all become. The less creative we all become.
Then we solve the problem, and try as hard as we can to forget the stress, the frustration, the entire problem. And then we try not to discuss it as not to point fingers.
What if we had a less formal discussion after such an issue and discuss:
- What issues we discovered when the errors happened?
- What were the areas impacted?
- What other services might benefit of what we learned while fixing the errors?
- How that failure benefits others in the team?
- What creative solutions and maybe workarounds we found?
- What did we try to fix the issues and still failed? So we can use new ways next time.
- What other areas of the code we explored in order to fix the issues? And what did we discover there?
Care to add more questions from your experience?
The whole point of asking the questions in this manner is to divert from being judgmental about failure. And to top that, we want to see failure as an opportunity to discover and to evolve.
I believe practicing this instead of the traditional what went wrong in the review meetings, might improve the way we look at failures in software development.
I believe this is a step in the direction of actually celebrating failures because of the opportunities they offer.
Photo by Mick Haupt on Unsplash
