Lost in Translation
Photo by Dmytro Bayer @dmytrobayer on Unsplash
The tech industry is full of jargon, processes and ceremonies that should make the pesky process of creating software a joy.
I say should because there are times where it feels like the structures we put around ourselves create more confusion than clarity.
A case in point is my recent run-in with a ticket and the communication chaos it caused. It also left me feeling rather excluded, so let’s take a look at this.
The Little Ticket That Couldn’t
A task arrives in the sprint backlog. The ticket title is straightforward, but the acceptance criteria (AC) are…let’s call them “improvable.” Instead of clear, actionable requirements, the AC simply links to a reference document that’s subject to change (and this is a situation that has happened regularly so I’m concerned about it).
If I remember, acceptance criteria is supposed to be the guidance if a piece of functionality is finished. Developers, testers and the business need to know what is expected from a ticket to make sure the right work is completed (in the right way). So when I was set a moving target (in this case) the criteria needed to be called out as unacceptable. A link to a live document or design that updates over time isn’t an AC; it’s a recipe for chaos.
In our “backlog refinement” this request wasn’t met with a quick fix. What I think is simple clearly isn’t.
Lost in Translation
“I don’t understand what you mean”
That’s a fair response from our BA, and perhaps I could have been clearer. I explained again, emphasizing that using a dynamic reference doesn’t align with the purpose of acceptance criteria (I didn’t use that language, don’t worry). It still didn’t land.
So the BA turned to the rest of the team, asking them,
“Do you understand what they’re saying?”
Since we were all on video call it was the silence that permutated my soul. Eventually a colleague backed me up, and “translated” the comment for the BA, which they were able to do since they were both from the same country. This isn’t a one-off communication issue, and the same thing happened several times.
I felt totally excluded from the mainly culturally homogeneous team, and never made a comment about the quality of ACs in tickets again.
The Language of Work
Global teams are common in tech, and I’ve worked with plenty before. The surprise for me here is that the team is almost entirely homogeneous (excluding me!) rather than a meting point of different cultures.
It’s not just about language; it’s about cultural nuances, different ways of working, and, sometimes, power dynamics that leave you feeling sidelined when you’re a singular person from a culture.
Let me be blunt. My feedback wasn’t dismissed because it was unclear; it was dismissed because it wasn’t being echoed by someone the BA implicitly trusted. That’s a tough pill to swallow when your whole role revolves around solving problems and providing clarity.
Fixing the Signal Loss
So how do we address these kinds of breakdowns? Here are some ideas:
Define Acceptance Criteria Clearly
Teams should align on what constitutes acceptable AC. A link to something dynamic is not enough; AC should be specific, measurable, and static for the sprint.
Standardize Communication Protocols
Make it clear how feedback should be processed and resolved, ensuring every team member has a voice and that their concerns are treated seriously.
Empower Global Teams with Context
When working across cultures and languages, invest time in providing context for decisions and feedback. Don’t rely on “translation” by someone else in the team.
Foster Respectful Dynamics
Every team member’s input should be valued on its merits, not their role, native language, or perceived authority. Create an environment where everyone feels heard.
Conclusion
I’ve felt unheard, unacknowledged and sidelined in the Agile process for some time.
I’ve already pretty much come to the end of my current tenure where this bizarre realization happened to me. You can guess how well it ended: badly.