Five Clues That Your “Agile” Localization Program Is Really Agile
Click here to close
Click here to close
Subscribe here

Five Clues That Your “Agile” Localization Program Is Really Agile

Five Clues That Your “Agile” Localization Program Is Really Agile

Agile Localization

If you hear “agile” one more time you might be caught rolling your eyes in a meeting (good thing you work remotely). And for a good reason. Agile is one of those words that people throw around without really thinking about what it means.

“Agile” in its broad sense implies flexible, adaptable, fast, and efficient. (Simone Biles is “agile”.) In software development, agile allows you to release updated versions of products multiple times per week, in multiple languages, making it imperative for localization to keep improving its “agility”. Companies have no chance of maintaining such a fast and furious release cycle if they keep those linear, waterfall processes.

But how does agile manifest itself in the localization industry? I’ve come to believe that these five pillars show what successful agile localization looks like.

1. Localization, product, and marketing groups are one team

The best solutions come about when there is a partnership between the client’s product groups, the marketing department, and the vendor’s localization teams. The most agile teams treat the localization folks as if they were part of their own team. (Otherwise you are just throwing things over the fence at each other.)

Invite the localization project manager to meetings where they can hear about project goals, important milestones, issues, and challenges they may be able to help with. Their involvement during planning activities also gives the product team visibility into and understanding of the localization tasks.

2. The localization team helps in the development process

Development teams may not want to worry about localization until “necessary” (which is always too late), so that they can focus on their core work. Product teams don’t always anticipate the impact of a particular task/feature on localization because they aren’t localization specialists. As a consequence, localizability issues are often discovered too late and aren’t fixable without delaying the product release.

When localization engineers are involved early, they can influence design before the product or feature is released — finding and fixing potential localization issues proactively, avoiding bugs before they occur, and saving you time and money.

3. Reduce and recycle

There are several ways to get more bang out of your buck by reducing the amount of work to be done:

  • Make the best use of past content by recycling previous translations with a Translation Memory.
  • Ditto for legacy English content by using an authoring tool that searches for and plugs in appropriate chunks.
  • Reduce the scope. Are you localizing too much content? Adobe provides a good example in which they were localizing content for the Russian market, but the user groups actually preferred English. Time and money spent on localization was a waste. Do comprehensive market research before you localize all content.

4. Automation

Agile programs automate. You can only go as fast as your slowest component. When your program needs agility, you can’t afford to send translation requests through email, or cut and paste strings from a spreadsheet to a source file. All translation handoffs should be automated and managed through a centralized system.

Even better if the system can connect with various source repositories, provide workflow, automate file preparation and quoting, leverage existing translations across projects and content types, and link to machine translation engines.

5. Centralization

Localization is increasingly becoming a centralized function serving all product and functional teams. Because enterprise localization programs work best when everyone does things the same way, it makes sense to place all people, tools, and processes in one place. You’ll have improved consistency and efficiency — redundancy and duplication are no longer allowed to reign. This allows a localization program to be nimbler and more responsive.

There are other advantages:

  • You might be able to reduce your headcount across the organization — one localization team can be the central point for all project requests.
  • You will achieve better data visibility. A central department will have insight into all projects at once and can track, manage, and report quality, cost, and turnaround time data at the program level. And lastly…
  • You will have power in negotiation. You’re going to get a better deal from LSPs when your company buys services in bulk, rather than in little projects from all over.

Adopting practices from these five areas will take you a long way down the path to agile. Your localization vendor can help you identify barriers to agile localization and put remedies in place. The bottom line is that we are in an era when localization needs to happen at the speed of light, because your product isn’t final until it goes out the door in multiple language at once. To accelerate revenue and fuel growth, achieving agile is mission critical. (See why some enterprises fail.)

For further reading, see here where Moravia discusses why Agile matters to localization and how your company can get lean.

Project and program managers — what other characteristics do you see in a program that’s agile? Enterprises — what else have you done to enable agile?