The sticky note appears on the retrospective board again: “Communication problems.”
Someone suggests better documentation. Another proposes more standups. Everyone nods and moves on.
Next sprint, the same card appears.
Here’s what’s actually happening: Your team isn’t failing to communicate. They’re using the same words while meaning completely different things.
When Words Mean Different Things
Communication expert Dr. Caitlin Walker was 26, pregnant, and walking into her first corporate consulting job with an all-male IT team. One key team member didn’t want to participate.
Walker asked: “If this project was to go just the way you’d like it to, it would be like what?”
Walker’s version: “Whitewater rafting. We’d get in the boat. It would be scary at first. But we’d learn each other’s strengths and get better together.”
His response: “I would hate this project.”
Walker: “If it was just right for you, it would be like what?”
Him: “Beautiful blueprints. Crystal clear and carefully measured. At every stage, you know exactly where you are.”
Same question. Two opposite visions.
Walker asked: “What would have to be true about my whitewater rafting for you to be interested?”
“Could I be the cartographer? Could I keep track of where the river is?”
“And your blueprint – could it be done in pencil so we could alter it when new ideas came up?”
“Oh yeah, I don’t mind altering so long as it’s carefully done.”
He paused. “I see what you’re doing. Normally, I would just hate someone like you and spend my time bitching about you.”
He became their biggest advocate.
This can happen, for example, when considering stories in your sprint review using “done,” “ready,” “blocked,” and “critical.” Everyone nods in agreement, then discovers weeks later they meant different things.
What’s Actually Happening
When someone says “we have communication problems” in a retro, they’re describing a symptom, not the cause. The real issue: you’re using vague language that each person interprets differently.
Dr. Caitlin Walker’s work on Systemic Modelling refers to this as “drama” – “any behaviour when someone is not getting what they want.”
In retrospectives, drama shows up as:
- The same issues appearing every sprint
- Blaming other teams
- Insisting things can’t change
- Pushing back without offering alternatives
Walker’s approach: acknowledge the drama, then use specific questions to reveal what people actually mean.
The Pattern: Four Questions
When someone uses vague language in your retro, use this pattern:
- Repeat their exact words
“So there are communication problems…”
- Ask what they’ve seen or heard
“What have you seen or heard that means there are communication problems?”
Now they get specific:
- “I didn’t get the API documentation I needed”
- “The design changed but nobody told me”
- “Three people gave me different deadlines”
- Find out who else experiences this
“Who has the same experience? Who’s got something different?”
- Ask what they want to happen
“When that’s what you’ve experienced, what would you like to have happen?”
Let the group generate solutions instead of imposing yours.
Two boundaries:
- Stop at two questions per topic. More than that, you’re doing therapy, not facilitation.
- Only use this when you genuinely want to understand. If you’ve already decided the answer, don’t pretend to ask.
Source: Microaggressions webinar →
Try It Monday
In your next retrospective, when someone says “the story is done”:
You: “So the story is done. What have you seen or heard that means it’s done?”
Developer: “Code is merged, tests are passing.”
You: “Who has a similar understanding? Who’s got something different?”
QA: “For me, ‘done’ means tested in staging and passed all test cases.”
Product Owner: “Done means deployed to production and users can access it.”
You: “When those are the different things ‘done’ means, what would you like to have happen?”
The team might decide to:
- Use separate columns (Code Complete → QA Complete → Done)
- Create a shared definition
- Clarify expectations at each handoff
Document it where everyone can see it – your board, Confluence, Jira.
That’s it. Two clarifying questions revealed three different definitions. Without them, you would have spent the next sprint discovering the misalignment through rework.
What Actually Changes
Before you try this:
Your retro identifies “communication problems.” Someone suggests writing more detailed requirements. Next sprint, the same issue appears because nobody clarified what “ready” actually meant.
After you try this:
Your retro discovers “‘ready’ means different things to different people.” The developer needed acceptance criteria and API contracts. The PO thought “ready” just meant the story was written.
You create a shared definition. Before planning, PO and dev lead review stories against it. Stories entering the sprint are actually ready. Fewer surprises mid-sprint.
The bottleneck often isn’t capacity. It’s misalignment on what you’re solving.
If you’ve read our previous articles on what Clean Language is, how metaphors expose miscommunication, and how two questions stop conflicts, you’ll recognize this pattern. This is how you apply it in retrospectives.
Learn More
Clean in Toronto | February 24-25, 2026
Two days with Dr. Caitlin Walker:
- Day 1: Clean Language fundamentals, identifying misalignment
- Day 2: Team facilitation, running effective retrospectives
Investment: Day 1: $1,200 | Both days: $2,000 | Early bird: 20% off
Not ready? Free practice: “Metaphors at Work” | Dec 10, 12:00 PM EST Register →
Related Resources:
The Series:
- What Is Clean Language?
- How Business Metaphors Expose Miscommunication
- Two Clean Questions That Stop Meeting Meltdowns
- Why Your Retrospectives Keep Saying ‘Communication Problems’ ← You are here
About Dr. Caitlin Walker: Developed Systemic Modelling as “a way to raise group attention and intelligence.” Learn more at Clean Learning