Agile Localization: The Moravia Q&A
Click here to close
Click here to close
Subscribe here

Agile Localization: The Moravia Q&A

Agile Localization: The Moravia Q&A

Agile Localization AMAPresenter Darin Goble, Moravia’s Director of Client Solutions, is a certified project management professional (PMP) certified project manager and a certified ScrumMaster (CSM). Yesterday, together with Renato Beninatto, Moravia’s Chief Marketing Officer, they answered questions from a live audience of the world’s top companies on the nature, impact, and best practices of Agile localization development.

Here’s our summary of the Q&A.

1. How does formal training in Agile (“Scrum master” for example) help a Localization Manager? Is it fundamental knowledge? Or is it just best to learn on the job?

Besides providing a great overview on how Agile framework should work, formal training provides greater detail on the best practices, case studies, and challenges for the model’s implementation. Nevertheless, nothing beats on-the-job training. Do you have the budget for training? Combine both.

2. How can you incorporate UI changes to localized documentation/software without freezing the UI?

Let’s admit that even under the older waterfall development model it was usually more “UI slush” than “UI freeze.” Agile localization fares favorably by comparison. One, it’s faster because it relies on modern tools that are designed to handle last-minute UI fixes among others. Two, it’s easier because handling these kind of updates at speed means we must first build end-to-end, well-designed localization ecosystems. That’s meant that the demands caused by, say, heavy DTP and other layout work have been displaced. There’s a new norm, thanks to Agile. Yes, it’s still a pain to have to update documentation and resource files with term and UI changes, but Agile processes have made it better.

3. How do you collect user stories which have impact on localization from multiple scrum teams in a timely fashion?

Remember: a user story is an independent, negotiable, valuable, estimizable, small, and testable requirement (INVEST). Too often, localization is treated as an afterthought. This is a relic behavior of the waterfall development model and simply doesn’t work for Agile. As you hear us talk about the expectations of well-built, end-to-end localization ecosystems, you’ll hear us repeat, too, that localization has to move upstream. Four new dialog boxes planned? Well, that has to flip a switch for someone in the sprint planning meeting that the localization team has to be informed. You have to train your teams so that if it looks like this, smells like this, and we’re going to do this, it triggers this process for the localization team. No big meetings necessary when this is the norm.

4. What’s an ideal cadence for localization in an Agile development environment?

There’s no ideal, because it depends upon volume, cadence, QA, review cycles, and what “done” means. Nevertheless, my personal preference is three weeks. It maintains the tight focus that a typical two-week sprint delivers for single markets while answering the demands of content localization for shippable products worldwide.

5. What is Moravia’s solution for fast (same day) turnaround of low volumes?

We developed Symfonie, a workflow management tool, to monitor and work with a variety of packages distributed from translation management systems. This works best for systemic and ongoing requirements — it manages the content, drips it out to translation teams that are trained for these daily- or twice-daily cycles, and tracks it back throughout the localization workflow. Again, this is best for systemic and on-going projects rather than the random one-offs that of course occur. Machine translation (MT) can also play a fantastic role in mature Agile environments. This is especially true in QA, where you can run structured resource files through MT and give the QA teams a chance to look at real to-be-post-edited content.

6. What is the fastest turnaround you propose?

Twelve- to 24-hour turnarounds are becoming increasingly common for well-established localization programs. This relies on solid technology, reframing translator expectations, and training in the Agile process. Shorter turnarounds than that are likely to affect quality.

7. How do you handle the occurrence of in-country holidays in a tight Agile schedule?

There’s a holiday happening all the time somewhere in the world. It’s a natural part of project- and human resource management. In-country teams that are committed and willing to meet the needs for clients in other time zones are important. So too are local translation resources. Above all, planning and expectation setting matched with sophisticated automation for reducing friction points can more than meet tight scheduling needs.

8. How does Agile accommodate linguistic edits & ICR?

This depends on the level of tool sophistication and training, but Agile localization definitely accommodates reviews and edits and on both the client and vendor sides. In the past, under waterfall development models, language errors were much harder to bear. They were pressed into CDs and shrink-wrapped for shelves, rather than website downloads. Things have changed. That also means that in-country reviewer roles have changed. They don’t come in at the end. Instead, they act as trainers and consultants who are shaping the content at the beginning. If you can live with some stylistic errors for the next hours or days of the cycle, the project is not a wash — opportunity flows into the next cycle.

9. What are the best translation memory tools for localizing in an Agile environment?

This is entirely subjective and, thankfully, there are a lot of well-functioning translation management systems that can be well-adapted to the Agile process. The real answer lies in what you need the system to do. That said, I believe these systems should have at least:

  • configurable workflow
  • robust editing capability of XML/XLIFF content
  • notification for next-in-line resources
  • built-in QA checks
  • status reporting
  • strong terminology and workflow management
  • review- and segment-level history

10. What kinds of tools are required for Agile localization, e.g. live TM?

Live TMs are certainly good. In general, any tool that creates or promotes automation and is an “always on” state is good for your Agile localization program. XML, XLIFF, and “all things structured” are equally good. By the same token, internationalization tools will help automate some of the handoffs to the localization team. They will also help core developers to incorporate multilingual release considerations into the development process upfront.

11. What best practices support iterative localization with DITA and CMS? Does an XML-based CMS lend itself best to Agile localization?

We’ve heard of Agile proficiency gains in the range of 30-50% with DITA and CMS rather than traditional DTP. The reasons are diverse but include DITA’s identical markup structure across languages, inline element and callout handling, and that delivers indexes and glossaries better.

12. How would you implement Agile in Life Sciences localization (for documentation, not SW)?

Documentation teams can be just as Agile-driven as software teams. Still, we recognize that Life Sciences bring distinct challenges, such as little tolerance for errors. Use topic-based authoring tools and workflow. Get in early in the sprint. Documentation needs to have a home on the core team, and a go-to person for localization. Organize your documentation workflow in sprints. Start with user stories and work closely to see how they are implemented.

13. How do you apply Agile localization to mobile app development?

Unsurprisingly, most mobile app development is already happening within an Agile environment. Not necessary for three guys in a garage cranking out an app, of course. It’s small in nature, its updates are released in drips and drops — it’s practically made for Agile.

14. Any recommendation to automate QA regression testing for mobile?

This is a tough one because QA is challenging within Agile time limits, in addition to the requirements of mobile. Typical mobile localization looks will be for truncations and missing translations – checks that need to be handled manually. Nevertheless, automation can support manual checks. There are tools that can automate screen tapping, mobile emulators, or run the app in browsers. I recommend taking a look at and for additional information on those tools.

Listen to a recording of the webinar yourself at Agile Localization AMA: “Ask Moravia Anything.”