If you work in software development, I'm sure you have experienced this phenomenon where a bunch of people happily end the discussion of a new piece of work understanding everything, and weeks later, when the piece of work is "done" the happy faces are gone and the solution provided doesn't meet expectations or fully cover all necessary cases.
Day 1:
-Well, it's just supporting the same >>feature<< for a new country, it should be easy!
-Yeah, it'll be just adding a new entry in a registry and that's all...
Day 30:
-Why isn't >>this specific case<< working on this new country yet?
-Well, that was not in the requirements...
Classic, right? 😂
That's what we call a communication gap and there are many people trying stuff to prevent this issue from happening by implementing working practices (or rules) that they have heard of. And we already know that practices without understanding the principles and values behind them, won't get us very far. We'll be doing things we don't know why we do them for and get frustrated about this problem still happening as well as force others to participate in ceremonies that don't bring them any value.
How to prevent it
We can minimise the risk of getting something really wrong by going back to the basics. We assume we're already working using an Agile methodology, which won't prevent us from having communication issues - as shorter feedback loops also come with shorter deliverable timelines, however, precisely because it's very reduced, the industry has distorted the original purpose and reasoning behind the Agile manifesto, if we use examples and put it into other words it would get us to:
No Coding Monkeys
Don't prescribe a solution. Everyone in the process QA Engineers and Developers need to understand the business goal under a piece of work so that they can optimise in order to meet the target instead of just blindly implement a given solution which will come with miscommunication errors and not solve the original problem.
Build a shared language - Even if it feels very basic
When having a conversation, start by explaining or asking what people mean by each keyword of the explanation. It's fascinating how people from different companies and teams call different things with the same word or same thing with different words. Having an ubiquitous language is really important - One of the best product designers I've ever worked with, would start by asking and making sure we would all use the same word for different areas of the product before doing any work. That worked wonders! Don't feel afraid to ask too "basic" questions. Going form the basic will allow you identify inconsistencies that can get very expensive if they are ignored.
Communicate with examples
Examples leave less room for misinterpretation, they make us think harder and deeper are a avery effective communication technique. Way better than an imperative request. Imperative requests have hidden details behind the domain knowledge. As a domain expert (i.e: a nutrition team member at Tails.com) there are things that seem incredibly obvious to them but will hide details that can only be discovered by examples.
Run specification workshops
Having domain experts, QA and developers going through examples and identifying and analysing edge cases, ensures that decisions are made by the right people, developers won't make assumptions implementing wrong cases and QA engineers will less likely miss details when running their QA tests.
Convert examples into test cases
Once we have examples, developers and QA engineers can build tests to either test-drive the implementation or to automate the e2e tests.
Create easy to read diagrams
Workflow and state diagrams, if kept simple, will also allow getting the key scenarios and edge cases cleared out and tidy, explaining rules for each decision.
The pinnacle of leanfulness
Gojko Adzic in Bridging the communication gap, suggests some tools that allow product owners or domain experts writing acceptance tests in gherkin format that automatically run and validate or fail our release. I personally haven't got that far because it requires a lot of training and setup but I definitely see a lot of value on this.