Blog Article Detail

Lost in Translation

Written by Muneeb Zubair on May 21, 2018

One of the biggest hurdles that I have seen so far in the IT industry is that we have brilliant people working on projects but they lack the basic communication skills required to ensure that the requirement has been captured in accordance to the understanding and expectation of the client. Although this is true, for those projects, which have foreign or international project owners. According to the agile manifesto practicing professionals need to lean towards customer collaboration over contract negotiation. That is where the "Pandora's box" opens where both parties get lost in translation while communicating. This results in requirements not getting taken down properly or are simply misunderstood. Although collaboration is a two way street but, face it, if you are taking the requirements then it is your responsibility to make sure that the requirements are correct. 

Having said this, it is difficult to work according to the manifesto as you cannot rely on hearsay which ends up like a Chinese whisper where it starts one way and is completely distorted by the time it reaches the end point. Having said this, we need to rely on techniques and processes to help us make sure that the requirement taken is correct and the solution is as intended. Here are a few tips that can help in gathering requirements:

1. Know your audience/project owner - If the project/product owner is not technical you need to refrain from using lingo and jargon which is technical as this can create a gap. No one likes to say that that they don't know and product owners might not ask for clarification of what is said hence can cause risks and errors in the requirement.

2. Don't just ask questions about the requirement but also question the requirement. Sometimes POs tend to go deep into the solution causing them to lose focus on what is the objective. Question the requirement and get to know what the requirement objective is. You might have a more feasible solution. 

3. Paraphrase or confirm the requirement - Make sure that the requirement that has been taken is correct. That can be done by either repeating what was discussed (summarize) or paraphrase (in your own words) what is required. If you are incorrect the PO will correct you.

4. Don't jump to conclusions - make sure that you use effective listening skills (both listening and hearing) to make sure that you are taking the information that is required. 

5. Write down the requirements - Although agile leans towards working software over comprehensive documentation yet making sure that you are putting down the requirements on paper and getting a sign-off tends to help everyone to make sure that they are on the same page. 

 Finally, something that I like giving advise everyone is KISS (Keep it Simple Silly - Had to change the last words to obvious reasons) - We tend to over complicate our communication, documentation and implementation for the search for bigger, better, faster and end up with something which is quite the opposite. 

At the end of day, you need to work according to what works for you and keep on striving in making the entire process faster and better.