Are you wasting a lot of development efforts on the XY problem?

“Are you sure you need a hammer?”

A man wants to restructure his house and decides to tear down a wall to create a beautiful open space, so he goes to his neighbor and asks for the biggest hammer he could lend him, and after lots of sweat and hammering he’s done!

The neighbor visit the home, and he compliments the man for the work:

Neighbor:<<Hey nice work man!>>
Man:<<Lot’s of hammering, but worth it!>>
Neighbor:<<Really? You needed my hammer for this?>>
Man:<<Yes!>>
Neighbor:<<Gosh! It would be better if you had asked me for my concrete saw!>>

What can we learn from this story? That often instead of asking help on a particular problem, we ask for help on a solution that we think may solve our original issue. We have hit the infamous XY Problem!

What is it?

“The XY problem is asking about your attempted solution rather than your actual problem. This behavior leads to enormous amounts of wasted time and energy, both on the part of people asking for help, and on the part of those providing help.”

People get stuck on what they believe is the solution and are unable to step back and explain the issue in full.

By asking about our solution, we immediately limit the solution space and lose the opportunity to think about brilliant alternatives.
We also hide the real problem from our interlocutor effectively reducing his chances of helping us with different ideas and perspectives.
And finally our attempted solution may not be a working solution to the original problem, and so we waste a lot of time on something useless.

So what?

“Explore the surroundings”

What can we do to reduce the impact of this fallacy?
We can try to focus and nail down the real essence of the problem, and not thinking about the solution right away. And that’s hard as we are naturally inclined to jump immediately to a solution and because everyone wants to be the smart guy in the room!
So before immediately thinking about what to do, try instead to improve clarity on the problem and its context. To do that we may adopt different techniques to explore the original issue.
For example, we can start using the “Five Whys” or the “Ishikawa Fish Bone Diagram” to deepen the knowledge about our problem and try to identify the causes and other contextual pieces of information.
Equipped with this knowledge, we can then brainstorm different options and approaches (maybe with a diverge and merge strategy!) and work from there.

In the context of software development, designing and building a system or a set of features that does not address the real problem leads to massive waste of times and resources, and that’s the reason why cross-functional teams need to be engaged with the root issue by the stakeholders and not on attempted solutions. A resourceful team will generate many viable options and together with the stakeholders they can choose the best path to reach the desired goals.

At Byte-Code we’re working hard to create innovative practices and processes to deliver more value to our customers.
To stay updated and receive the latest articles you can subscribe to our newsletter!