The Language as a Barrier in Agile Teams

February 24th, 2020 · 5 mins read

A practical report on how to overcome the barries of different mother tongues within an agile team.

Daniel Fonai

Agile teams have their everyday problems. User Stories being written and refined in the last moment, technical debt piling up for lack of time or developers making undocumented and not communicated changes to the code. However occasionally team problems are below the obvious surface. If you have ever worked in agile development teams, you were most likely working with other nationalities. Different nationalities mean - usually - different mother tongues and communication that you do not always understand. Highly functional teams overcome this barrier with time. But what can you do if your team still suffers from it?


Language Issue? Confrontation!

Let me tell you a problem I stumbled upon on a recent project. As an Agile Coach I was tasked with rooting out inefficiencies in a tribe of more than 20 people. The problem: agile immaturity, ignoring the team agreements, working on tasks no-one knows about and of course the end results of all problems: delivery speed far from expected. You could call it your textbook agile mess.

After several interviews and weeks spent with the team it became obvious, that the team’s understanding of the scrum processes was not where it should have been (bummer!!!). Based on the experiences collected, coupling it with the team’s input I have distilled down what the main problems are and how important they are. Then the team and me got to work. Missing Definition of Ready and Done? Let's create one! 2 feature teams working on the same micro service? Get the teams aligned and define areas of responsibility! User Stories are too technical? Ok, this is a big one, but using User Story Mapping we could tackle even this one; I can just recommend Jeff Paton’s book "User Story Mapping", it’s entirely worth its money!

Then one even bigger issue came into the picture. People kept complaining about others not using English in the office. It was a whole cacophony of complaints. It was like everyday politics or football, almost everyone had a crystal clear opinion what is going well and what should be done differently. Consensus? None whatsoever.

I kept long hours researching online who is having similar problems and how are these getting solved. What did I gain for the endless searches in endless blogs from the US and from Europe? In the US the topic is quite big and is considered from regulatory perspective, who is entitled to what. Human laws against what the employer is entitled to request from employees. In Europe the topic is rarely discussed, those who touch it mainly say, that yes, it exists, look at what it brings to your team! Solution recommendation? You guessed it, not really.

As any self-respecting agile coach, I went and invited all the members to an overarching retro including all teams to discuss what they want to do. Did I know where the discussion was going? God help no! We started with a warm up - Telephone Game - where you whisper a word or sentence to the guy who stands next to you. It was a good laugh but people were looking at me confusingly.

All right then, let's get to it! The meeting was then split into to 4 parts (on top of the warm up Telephone Game).

Meeting Agenda
Meeting Agenda

The four Parts

  1. List all the situation where you heard a colleague use non English! Group them! What disturbed you what did not?
    List the situations
    List the situations
  2. Take the ones you did not like and tell your peers why did it disturb you!
  3. Select the 2-3 most disturbing ones and select a measure how to control it in the future! (they were provided with some ideas what to use as measures and were encouraged to come up with new ones on their own.)
    Identify possible solutions
    Identify possible solutions
  4. Vote on what to apply in the team! At this point, the opposers slowly left the room, the supporters stayed to decide which measures to implement.
    “English speaking zone” posters were put on the wall, people started talking more English, then in 2 weeks people were back to “normal” (people using other languages again), like nothing happened.

    English speaking zone
    English speaking zone

Confrontation? Communication!

Only after the overarching team retro and the heated discussions during the upcoming weeks did I realise that the problem was not the language. It is just the obvious epidemic, the easiest way for people to formalise their dislike to their peers and to their behaviour. If it would have been an entirely German speaking team, they would have found something else, like cigarette breaks or smelly breath.

What did I miss then? In the past the team did not have the proper understanding how to work together and went to the way of least resistance, in this case to a soft anarchy. The members have “successfully” built walls and used them as separation lines between people who did not like work together. There was no-one really wanting to build an agile team. As one of the first converted teams in a traditional organisation they were new to agile and everyone followed their personal agenda. Cooperation and team efficiency were considered as utopian concept. The lack of belief in the scrum processes led them to keep doing the same thing as they did in the past, just without the old hierarchies and by using agile expressions.

In case they would have had the understanding of agile team work to tackle problems together, they could have done a retro around it. We are not programmed to be mean to each other, but uncertainty, missing understanding of the structures we work in brings stress out even from the best of us. Relieve this stress, talk it out and keep on enjoying your job. In the end, that's what we all want, right? Happy employees are effective employees and happy employees work at higher efficiency. But you need the baseline for that.

Communication? Start early!

That means that by being in charge for the building of a team, you have to be in charge for establishing the processes. To do it easily, you have to do it as the first thing once your team is set up. Later as we saw from the above example, it will be very hard to reestablish the way of working in the team. If you don’t know how to do it, invest in people who do. Have an experienced scrum master or agile coach and engage people as development team members with agile best practices under their belt. This investment will be your solid base of value delivery, without this any type of architecture or any world-renowned developer will have difficulties to provide you with the expected results. Do not forget, using agile practices is like using an electric screw driver instead of a manual one. If you know how to use it, it leads to great results. But if you start using it wrong, you will create much more damage.

Daniel Fonai
Daniel started his career working with monolithic ERP systems in waterfall project setups. With his first agile project he was not going back to the old world and enjoyed trying himself in every possible position in Scrum that did not require coding skills. While doing projects in Banking, Insurance and Automotive he decided to focus on enabling teams to deliver to their best abilities. After having done projects on 3 continents he found his new home in Vienna.

March 25 & 26, 2021 · Vienna

Wir sind stolzer Host einer Konferenz rund ums Thema Softwareentwicklung.