Why do we fail when approaching Agile Localization

Last week we had a nice event from the Women Chapter GALA association in our King office. It was a nice gathering where we shared experiences about Agile Localization.We shared experiences in the hope that Localization, one day might have the status it deserves 

Is this a dream? Maybe 

Is this possible? Maybe 

Will I see it? I hope so! Although I’ve been over 20 years in the industry and I keep receiving same questions as in the ‘90s. i.e. How do you convince management teams than investing in Localization is worth it?

 

There were quite interesting questions in the WIL event (Women in Localization ), but as usual, when you are passionate about something, you don’t have time to communicate all that you want to express! Maybe that’s one of the reasons I have a blog :). I want to express my opinion, in a calmer manner, without the pressure of time to finish a presentation, or finishing a meeting. 

One of the most interesting questions I received was “Which are the best practices do you recommend for a successful agile localization strategy?

I was thinking about this topic over the last couple of days …. best practices for success …  and actually I started to think why agile localization is failing in some industries. If I analyse why Localization is failing I think I might be able to contribute in best practices. Totally back engineering thoughts, I think my early programmer brain is still there…

I see here at least 2 possible answers for the failing agile paradigm.

Possibility #1

Despite of the popularity of the agile movement, a lot of companies are still trapped in the waterfall model.

• Yes, you might have a product owner
• Yes, you might have a scrum master
• Probably, you do daily standups and you have post-it ™ everywhere with all different combination of colors and sizes (3M must be one of the companies happier($$$$$€€€€€) in the world with the Agile movement, they even give you some tips in their own web site about how to use them) 

And unfortunately

- maybe, Localization specialist are not invited to dev meetings, sprint planning and 

- maybe even worst, there’s not a post it with the word “Localization” written in the sprint planning. 

If you recognize yourself (or your team) in this scenario I’m sorry to be the bearer of bad news, you (and we) are working in the illusion of being agile, but, in fact, we are in a waterfall methodology. When there’s no a localization representative in the stand-up meetings or sprint planning or retros, the dev teams and Localization team are missing opportunities, better said, I would say we are missing a GREAT opportunity to receive feedback about:

·     the style/art of the game/app, 

·     about the colors used, 

·     about language characters coding issues, 

·     inappropriate cultural references, 

·     about grammar considerations, think about a string translation of “I’m so tired” in English vs let’s say German or Russian (m,f,n)

·     and much more ….

This can be solved; this must be solved. In Agile there’s more communication as in traditional waterfall model, therefore, we need to communicate more between dev teams and Localization. When Localization is treated as part of the dev team the magic starts. Feedback flows around and knowledge is shared. Once a Localization representative is invited to meetings it is crucial for the Loc person to show real interest and good feedback. Only when we, Localization people provide valuable feedback, the dev teams will really value the support we give. We need to build relationship with them and build trust. Build trust is a topic for itself , I’ll write a post about trust in the future , meanwhile I’ll share with you the best book I’ve ever read about building trust, the great Mr. Covey shared all his wisdom in the bestseller The Speed of Trust. It worth’s reading. You are welcome!

Possibility #2

Maybe, we are not using the right tool to communicate within the different stakeholders. You need to find the tool that it helps you and facilitate the conversations between different teams, including vendors! In an agile environment is a luxury to communicate via emails, do manual handoffs, copy/paste text strings and so on. 

You need continuous integration of your content with other tools (or at least with some standards of the industry such as Jenkins, GitHub, ZenDesk, Phyton), you need a tool to help you with collaboration and management between Devs, LPM’s and SLV/MLV, you need a tool to provide continuous monitoring.

When I think about my Localization projects during the first decade of my career I’m surprised we could localize projects with millions of words (I’m not exaggerating here, the localization of an online encyclopedia from Microsoft was a heavy project J) without really having anything that paired with a localization workflow for developers, product/localization managers, and translators. 

Nowadays there are different tools that it might be worth it to explore. These tools offer continuous localization integrated in an Agile framework. 

They offer:

·     cloud based repositories, 

·     TMs, 

·     many supported file formats,

·      tools for monitoring and getting real time overview of the status of the project, 

·     API for integration with other tools 

·     and so on

I have used different tools, and I cannot recommend “one size that fits all”, every localization team and company will have different needs for continuous localization and integration, I believe you should explore these tools by yourself and run a SWOT analysis to choose the best tool for you. If you still need some recommendations to start with, you might be interested in playing around with Transifex or Crowdin . 

Do you need more than a couple of tools to evaluate? Ok, then, there you go 22 TMS technology vendors/tools so you can explore even deeper :)

Have a wonderful day and watch out in the real world! There’s a huge crowd thinking Agile Localization is just doing translations quickly, ooops!

@yolocalizo