I run sprint retrospectives on a small, fully remote Japanese team, and if you dropped into one, the first thing you'd notice is what's missing: nobody points at anybody. Not the product owner, not the scrum master, not the engineers. Problems get raised β real ones β but they're always aimed at the process, never at a person. It isn't a rule written down anywhere. It's just how the room works.
I've spent about twenty years on Japanese dev teams, so this reads as normal to me. But I've watched engineers from other places sit through their first Japanese retro and come away unsure whether anything honest actually happened. It did. You just have to know where to look.
The shape of the hour
We run it on a shared board, in a fixed order.
First, before anyone writes anything, we go around and each person says a few words out loud β just a general impression of the sprint. It's a warm-up, but it also sets the temperature. Then everyone gets ten or fifteen minutes of quiet time to write cards on the board: Keep and Problem. Writing first, in silence, matters more than it looks. It means the quieter people put the same number of cards up as the loud ones, and nobody's opinion gets anchored by whoever would have spoken first.
Then we read through them, cluster them, and vote.
The "Keep" column is mostly thank-you notes
Our Keep column is usually the fullest one, and a lot of the cards are, plainly, thank-yous. "Thanks to X for helping me get unstuck on the deploy." "Grateful someone picked up the review while I was out." Gratitude, written down, to specific teammates.
It would be easy to read that as fluff β retro theater that pads the board while avoiding the hard stuff. I don't think it is. On a team where you're careful about pointing at people for problems, the Keep column is where naming a person is not only allowed but encouraged, as long as it's positive. It's the counterweight. You spend the sprint being indirect about what went wrong; the retro gives you a sanctioned place to be direct about what went right, and who made it go right. It keeps the ledger balanced.
Problems point at the process, not the person
When we get to Problem cards, the names come off.
The product owner, the scrum master, and the engineers all write the same way here: describe the problem, not the culprit. So a card doesn't say "the PO keeps changing his mind." It says something closer to "requirements shifted mid-sprint a few times, which made it hard to keep the scope stable." Same information. No target.
This isn't people being conflict-averse to the point of dishonesty. The problems are real and they land. A couple of examples, phrased the way they tend to go up:
- Acceptance criteria were unclear on some tickets, so work got built one way and then reworked.
- Reviews bunched up at the end of the sprint and turned into a bottleneck.
Everyone in the room usually knows which decisions and which people those cards are really about. But because the card is phrased as a process problem, the conversation stays about the process β how to tighten up acceptance criteria, how to spread reviews across the sprint β instead of turning into a defense of, or an attack on, one person. On a Japanese team, that framing is what makes it safe to raise the thing at all. Take the name off, and the hard problem can actually be discussed.
It helps that the cards are written in Japanese, because the language does half of this for you. Japanese lets you describe something going wrong without a grammatical subject at all β γγ«γͺγ£γ¦γγΎγ£γ (it ended up that way), γγηΊηγγ (an issue arose), or a plain passive where the actor just drops out of the sentence. In English you have to work to keep a person out of "the requirements kept changing." In Japanese, leaving them out is the path of least resistance. The grammar is already pointed at the process, so the writer doesn't have to make a diplomatic choice β the default phrasing is the diplomatic one.
Voting turns problems into Try
We don't write Try cards up front. We derive them.
Each person gets two or three votes to spend on the Problem cards, and we take the top two or three by vote into the next sprint as our Try items. It's a simple filter, but it does something useful: it means the problems the team feels, not just the ones the loudest person feels, are the ones we act on. The flip-flopping-direction card and the PO-review card both won votes, and both became Trys.
Where it falls apart
The retro works. Real problems get surfaced, voted on, turned into Trys. Then not much happens to them.
They get turned into backlog items β PBIs β with good intentions, and they sit there. The pile of process improvements we all voted for and none of us has had the capacity to pick up just keeps growing. We're good at diagnosing the sprint. We're worse, the next sprint, at remembering what we diagnosed. And I run these retros, so that pile is at least partly mine. That part probably isn't Japanese at all β I think that one's everywhere.
TL;DR
- On a Japanese retro, Problem cards describe the process, never the person β "acceptance criteria were unclear," not "so-and-so wrote vague tickets." Removing the name is what makes the hard problem safe to raise.
- Japanese grammar helps: you can describe something going wrong with no subject at all (γγ«γͺγ£γ¦γγΎγ£γ, γγηΊηγγ, or a plain passive), so the default phrasing already points at the process rather than a person.
- Writing cards silently first, on a shared board, levels the room so quiet members contribute as much as loud ones.
- The Keep column is full of thank-yous to specific teammates β the sanctioned place to be direct and positive about people, balancing the indirectness everywhere else.
- Try items are derived, not written up front: everyone gets 2β3 votes, the top Problems become next sprint's Try.
- Problems get raised fine; the weak spot is follow-through β Trys pile up as backlog items faster than they get closed.
