I don't disagree with the general take of the post, but I feel I can answer this particular point.

> What if you’re working with a major language barrier in the team, and misunderstandings can be mitigated with processes?

Process is communication. It's a way of doing mass communication. Instead of explicitly communicating everything to everyone, a process is way of saying "when X happens, you can assume Y".

For example, if a card is in the Done column, you can assume the code is in version control, deployed to production and checked to make sure it didn't explode on impact.

Then, instead of explicitly communicating every single deployment, you only need to communicate the exceptions. (ie; the things that don't fit neatly into an existing process)

If you're working in a team that has a major language barrier, I don't see how having a process can mitigate the need to explain that process, nor how the exceptions can be communicated effectively.