Language + localization
Agile localization involves incorporating internationalization, localization, and translation into an agile product development cycle. It requires adapting localization processes to be fast, flexible, and automated. Software development teams moving from a traditional waterfall approach to agile methodologies may feel daunted about approaching the “localization issue” while also undergoing such a critical paradigm shift in their internal processes.
Some companies attempt to maintain the waterfall approach to localization even after switching to agile methodologies. In these cases, they translate all release content in a rush at the very end of a sprint, potentially even releasing globally weeks after they go live domestically. Other companies end up avoiding localization altogether, ignoring international users and forgoing a great deal of global opportunity.
The benefit of agile localization to development teams is that it complements their agile methodologies – there are no clunky processes delaying time to market. Nevertheless, integrating localization into an agile development cycle is not easy since it requires buy-in and collaboration from numerous, typically siloed, stakeholders. In this post, we’ll outline seven best practices for integrating localization into your sprint cycles.
To be truly agile, localization must be integrated into an agile development cycle from the get-go because it needs to be running parallel to the development process in order to be successful. That said, there is no right or wrong way to approach agile localization – it will depend on your reality, your needs, and your global release goals. The list of best practices below is in no way exhaustive, but includes primary recommendations from experienced thought leadership in this arena:
1. Embed, integrate, and collaborate.
Localization must be deeply embedded into the agile process from the start. Internal localization managers and external localization partners must work closely with product owners, testers, and marketers. In-house managers should be involved in all scrum meetings and sprint demonstrations. Localization partners should be included as often as appropriate, at the very least via proxy. Localization should be integrated into user stories, product backlog, velocity calculations, and sprint planning and reviews. Milestones, successes, and failures should be shared with localization managers and partners to trigger conversations around process innovations and improvements.
2. Prepare to localize.
When planning for a sprint, consider internationalization and localization. Internationalization and localizability testing must occur early on in the development process. Internationalization testing will ensure the product is
locale-neutral, and localizability testing will identify and mitigate any potential localization issues (such as display issues due to text expansion). Machine Translation is an excellent tool to use for pseudolocalization during this testing phase.
3. Streamline your partnerships.
The number of localization partners you collaborate with should be limited so you can streamline your workflow. Require that your partner and the dedicated team of linguistic resources be trained on agile methodologies. Your localization partner should be able to speak “agile” to your scrum team.
4. Think language.
Work with your localization partner to develop key term lists, refine source content, and grow translation memory databases to better ensure language leverage and consistency throughout all content drops. While these strategies have always featured heavily in the traditional localization process, controlled, high-quality source content is critical to the success of agile localization because it will ensure short turnaround times and also reduce localization costs.
5. Automate.
The localization workflow should be (re-)engineered to allow for a continuous transfer of content between the systems involved. This will likely require an investment in technical infrastructure from all parties, but is a “make or break” factor in fully adopting an agile approach to localization. The only manual components of a truly agile localization workflow are when human translators, reviewers, and testers interact with the content for translation or QA. Some best practices for automation include:
- Automated transfer of localizable content between source repositories/development systems and localization partner systems (including dedicated, in-country linguists). These transfers will likely be triggered as part of an automated build or check-in, dependent on the development infrastructure.
- Release/update identification and parsing tools.
- Auto-generated screen captures for contextual reference, possibly with automated layout change testing.
- Auto-collated toolkits or packages for linguistic resources containing all content and reference materials (termbases, TMs, screen captures, etc.).
- Localization partner/in-country linguist access to issue-tracking systems.
6. Continuously translate.
As content becomes ready, even in small batches or in a preliminary form, it should trigger your localization workflow. While some of the subsequent translations may never be used – as user stories evolve, your software will alter to reflect those changes – they will be added to a translation memory database and be leveraged on future iterations. When implementing an agile localization process, the potential for “losing” initial translations should be viewed in the same light as the changes to the software itself: as a necessary byproduct of an agile process.
7. Define “done” globally.
You’ll know you’ve fully integrated localization into your agile development cycle when your team’s definition of “done” includes a ship-ready product for all locales.
The ability to achieve agile localization as part of your agile development cycle is ultimately a collaborative effort, with development teams and localization partners aligned to the end goal. Talk to your localization partner about tools, processes, and resourcing options that support your agile objectives.
If you’re attending LocWorld29 in Silicon Valley this year, be sure to check out Jenna’s presentation, “The Project Management Maturity Model,” at the Localization Processes Forum VI: Building Global Business Sustainability pre-conference session on October 14.
Sources:
http://www.smartling.com/translation-software/translation-process/agile-translation/
http://www.welocalize.com/global-software-companies-run-agile-localization-processes-alongside-agile-development-cycles/
http://www.oneskyapp.com/blog/agile-localization-myth-reality/
Webinar: Driving Localization in an Agile Environment, Saurav Gupta
Webinar: Building a Scalable Agile Localization Program, Darin Goble, PMP, CSM
