How software companies can make localization and Agile get along – Infobip’s story

Let me tell you a little bit about the approach to localization at Infobip. As a global communications platform for businesses and developers, we’re always looking to improve our localization process, especially when it comes to making it work within our agile framework.

For that reason, we recently decided to embark on another round of research and experimenting, which led to interesting and even surprising results.

But first, what’s localization and what does it have to do with software development? Localization is the adaptation of products and content to a specific location, which could be a region or a country, to make sure it works within that cultural and linguistic setting.

At Infobip, we’ve been focusing on continuous localization. This is the latest form of localization and is designed to solve the bottleneck issues that software companies typically encounter when incorporating localization into their software development cycles. It’s extremely helpful for companies with several engineering teams.

These days, software is equal to agile. This means short release cycles, i.e. developers making small additions and changes to software products little and often. These minor, repetitive releases need to be localized too, so everyone involved in the localization process – whether LSPs, translation companies, or in-house teams – should be agile too.

Unfortunately, the localization world is still very much in the traditional mindset – using the slow, linear waterfall method of completing finite steps one at a time, before moving on to the next one. This old-school method might still work in some industries (just about) but when applied to software companies, the bottleneck issues are inevitable – because everything needs to be done much faster.

Let’s look at our own case, as an example. Our products (UI) have around 95,000 words. We might have something as small as 120 words that we need to translate into 11 languages within 48 hours.

Any LSP we reached out to would have to:

• clarify the requirements and accept the project

• contact up to 11 vendors

• confirm their availability and find replacements for those who aren’t available or responsive at such short notice

• oversee the progress of the project

• answer questions and solve issues

• verify completion and deliver the translations

• invoice the client and pay vendors

Because of the requirements, we usually faced three problems: minimum fees from LSPs and their vendors, tight deadlines, and compromised quality. And it’s important to note here that LSP obviously does a lot of work, which makes it difficult to keep up with our continuous stream of small projects.

Continuous localization has always been our goal at Infobip but, with all the above constraints, it was “semi-continuous” at best. So we recently embarked on a low-risk, high-gain experiment to see if we could make our localization process truly continuous. In other words, we wanted to see if we could make our localization process fit seamlessly within our agile framework.

When we sat down to think about why real continuous localization was so challenging, we realized we needed to completely move away from the waterfall, sequential approach to localization projects. Was that even possible?

Well, we found that a group of software developers had faced the same challenge back in 2001. They countered the waterfall method by proposing their Agile Manifesto to do software differently. It revolutionized software development 20 years ago and is still valid today more than ever.

^{Agile approach VS waterfall approach}

So, with just a few tweaks to the original Manifesto, we came up with some principles on how to make localization agile too.

Here are our 12 guidelines for continuous localization:

1. Publish translations early and improve them later – don’t wait for perfectly reviewed translations.

2. Be ready for constant content updates – don’t request any development freezes as you're delaying your time-to-market.

3. Release translations as frequently as possible – don't wait for large batches and slow down the cycle (this is the hallmark of the old, waterfall method).

4. Establish collaboration across the whole company - don’t isolate the localization team.

5. Rely on people, trust, and teamwork – don't apply the command and control style in your localization department or program.

6. Prioritize direct communication methods with translators and other stakeholders – don’t rely on indirect communication through the LSP.

7. Collect feedback from end-users – they’ll show you what really matters and be the true measure of quality.

8. Set up a continuous, scalable process – the process must not get delayed if the localization team is unavailable.

9. Continuously improve your localization tools and system – don't expect that any generic, third-party software will over all your needs, some internal development is still needed.

10. Automate or minimize manual work – don't rely on human project management or human involvement if it can be automated.

11. Allow the localization team to choose how they work – don't insist on strictly defined procedures.

12. Reassess processes and plans regularly – don’t let years go by without making necessary adjustments.

We wanted to test these principles so we analyzed all the steps in our localization process, removed a few, and then looked into how to make the remaining more efficient. The agile principles fitted in well, without any exceptions.

One of the key changes in our experiment was the repositioning of the role of the LSP – we envisioned it as a third entity alongside the translators and the client (us), instead of as an intermediary between the client and the translators.

Once we found the right LSP to work with (Beluga Linguistics), we chose Swedish as the test language and set up our redefined triangle: client, LSP, and two freelance translators. We made sure to leave behind any waterfall practices by using technology and communicating with each other within the triangular circuit.

In addition to set-up and communication changes, we also took over contracts and payments to freelancers (handled it with a few clicks, using third-party technology), and asked the LSP primarily to lend us their experience in managing freelancer teams and the quality process. This removed any possibility of collision between our and LSP interests, and made us all completely aligned towards the end goal - faster and better localization.

We found that this new, triangular setup finally allowed for real continuous localization and benefited everyone involved.

Benefits for software companies:

• No need to delay product releases – when they were ready, from the code and the marketing perspective, they were instantly sent for translation and released.

• Any language issues could be fixed instantly – whether it was the source language or the translation.

Benefits for translators:

• They got paid accordingly, quickly, and in full – no deductions from banks or any accompanying fees.

• Direct communication with the client – no need to wait for answers or clarifications via the LSP.

Benefits for LSPs and translation companies:

• No deadlines or admin work to worry about.

• A guaranteed steady monthly income, like a retainer.

It’s worth noting that, given the non-life-threatening nature of Infobip products, we could live with occasional imperfect translations. That allowed us to speed up the time-to-market but also allowed the local Infobippers to do the in-country review on the UI, not in the abstract context of a TMS. In order to make this happen, we first had to decompose our localization process (from the technical perspective) - this allowed us to fix any translation errors and publish the changes to production in just 10 minutes, as many times as needed in a day.

All in all, our experiment was a successful one and demonstrated just how effective continuous localization can be, when done right.

^{Localization triangle solved}

There’s nothing like first-hand experience to learn the ropes and see how localization can be done in your company, but here are a few tips – based on our learnings from the experiment – that should help you along the way:

• Software businesses should really think about retaining ownership of the localization process. No outsider can do it better than you.

• Remember that translation is a human collaboration, not a faceless chain, so look after everyone involved and reap the benefits of efficient cooperation.

• Set expectations early and trust people to demonstrate their expertise.

• Give translators room and financial incentives to learn about your business.

• Run small checks and experiments often for everyone to improve.

This last point is one of the most important and, perhaps, the most overlooked. Agile is all about iterations, testing, and tweaking, so don’t be afraid to apply this experimental approach to your localization process too and you’ll soon be reaping the benefits of continuous localization in your software company.