Not so random thoughts #2 ||“Problem Child’s” are not really a problem

One of my most cherished learning from my business consulting experience is summarized so well by this old saying, “A problem well-defined is a problem half solved” and yet, not many people encourage talking about the problem. The general attitude towards problem statements around us is “Do not tell me what the problem is, just give me the solution”. Intentionally or unintentionally, you and me, have said this so many times to our teams and have discouraged people who like to talk about the problem in detail. The same follows to the ones who point out problems and generally is followed by tagging them as “Negative”, “Pessimists” or “Problem Child” team members.

Let’s take a very simple scenario of a regular product release delay. If this is a recurring issue with your product, I bet, the reasons for the same would differ completely depending on who you speak to. If you speak to the product team, they may point out to the large amount of time taken in aligning various stakeholders. If you speak to the Dev Team, they might point out to ambiguous user stories or bad prioritization or may be crappy epics. Speak to the Infra team and they may sing a different song around the code commit errors, wrong branch, code merge issues and finally if you speak with the sponsor, he may say that the whole team is clueless and lets change them or get them support from outside.

Overall, if one does not invest time in speaking to these different internal customers around problems, one possibly would never be able to find the pieces of truths in these different truths.

Fortunately, there are many a framework (my favorite being the Issue Tree) and working models to help you here but prior using them, one has to first infuse the culture in teams to talk openly about problems. Inclusion and involvement is the pre-requisite to this is my humble opinion.

A process that I follow sometimes, I can suggest here –

Speak about WHAT

Speak to different people across the team about their perception of the problem. You may get surprised that even the problem statement might differ from people to people. What is a release delay for a product owner might be over worked/over prioritization for Dev Team to a resource issue for a Scrum Master or technical debt for the Solution Architect resulting in more bandages. Talk, talk and talk and there is no short cut to this phase. The more the information, the more the pieces of truths you will have to work upon.

Ask WHERE

Try to identify what different sets of folks think where the problem lies and this would help you understand the inter team dynamics and could possibly also provide you a clue on “Where” segments, which is most commonly pointed out by everyone like legacy technical debt, resourcing issues, bad quality of user stories etc.

Investigate WHY

Now try and talk to people about why do they think this problem is there and trust me, the kind of insights you will get by encouraging people to talk about would astonish you to the core. For the example of a product release delay the answers could range from like legacy technical debt, resourcing issues, bad quality of user stories etc. and a single solution does not address these myriads of “Why’s”. Many a times, the leadership cabins define the problem statements and also prescribe a solution for the same without understanding the core customers POV and this just becomes a vicious circle since the core is never addressed.

Discuss HOW

Do not now push these people out of the solutioning phase. Once you’re done with the above 3 steps, enquire and encourage these participants to suggest solutions. Not surprisingly but for the same problem statement, you can get 3-4 solutions impacting the various elements of the problem statement depending upon how that problem impacts that user.

Once you’re done with the above 3 steps – finding a solution (at least on the paper) is never a time taking task; albeit implementing them could be if they require $$ or other subjective issues.. ??

In conclusion, do not undermine people who speak about problems and don’t tag them negative, for those are the ones who are really analyzing things and coming with several problem hypothesis. Talking about problems is really “Valuable”.

For sure ACTION has to follow the PROBLEM but there is not so much of benefit to jump to ACTION before talking about the PROBLEM.