By Kirsty Taylor
Learning. Change. Newness. Our company was developing a number of new software products. We were just starting to localize content for the public release of products. (We had previously delivered either just the localized UI or localizations would be performed during the software implementation project or by the customer alone.) At the same time, we were also rolling out Agile development. A lot of change, a lot to learn, and a lot to get done for our international customers so that we could delight them with a localized product release where the international language was a core part of the product development process, rather than an afterthought. As a product development organization, we were already undergoing a lot of change, so why not bring all the changes together and start localizing the online help during Agile? This way we could all simultaneously ship for the first time.
Background
Our company uses the Scrum methodology of Agile, where a group of individual contributors with various strengths and specialties work together toward the common goal of releasing a software product. Developers, testers, product owners, architects, and technical communicators form the Scrum team. Our technical communicators are typically members of multiple Scrums. Content development tasks are sometimes included in-sprint as part of Done Done, and at other times these tasks are a sprint behind development and testing to reduce documentation rework efforts. We have not (yet!) attempted content localization in-sprint, as our localization testing and release schedule does not require such a rapid turnover rate.
Product managers define the overall themes or narratives for a product release. These themes come from the product roadmap that is designed to meet our customers’ future needs, and entice new customers to purchase our software. Product managers then work with product owners to develop epics, where we define the functionality that needs to be developed. We then divide those epics into multiple stories. Each story should be small enough to be completed in a sprint, which at our company lasts for two to three weeks. Product localization, which encompasses both UI and content, is included as its own epic.
Starting at the Very Beginning
Content localization planning needs to be included in release planning. In release planning, or prior to release planning, the product managers and product owners need to answer the following questions:
- Is it a goal to deliver localized content with the public, or general availability, release of a product?
- If so, what are the deliverables that will be localized?
- Into which locales/languages will the deliverables be localized?
- Will certain deliverables stay in the source language?
- Are there business reasons for localized product and content to be available after the source language release, rather than simultaneously shipping all locales?
As technical communicators and technical communication managers, we do not want to be surprised in the week before a product release by the expectation that we will have online help, eLearning, or user guides available on release day without prior warning. We also don’t want the additional surprise that those deliverables should be in French, German, Simplified Chinese, and Brazilian Portuguese! As much as technical communicators can feel that they are the last to know about product direction, development, and changes, the localization team is always a step behind them, and feel even more out of the loop. In a waterfall development model, typically the UI needs to be frozen, and the content reviewed and completed before you start localization. If those milestones are met only shortly before release, the localization team has a large amount of pressure to meet the deadlines at the very final stages of the process.
In an Agile environment, plan for the appropriate times in the development cycle when you can start product translations, turn them around and review them, and then start on the content translations. Then repeat that process of translating deltas (additions and changes), reviewing, and picking up the next round of delta changes. If there are technical product localization requirements as well (such as ensuring the software can work with different currencies, date formats, and zip code/post code lengths), build those requirements into epics or stories for the Scrum teams to work on.
Sprinting Through Agile Content Localization
Localizing product content (and product UI) is just like creating content deliverables—at some point, you need to stop waiting for the product to be completely perfect and ready for users, and write the content deliverables, or in this case, translate the UI and the content deliverables. Something might change in the next sprint—a UI label could be changed, which means both the content, the UI, and content translations need to be updated. But it’s not always possible to achieve a state of product perfection before spending effort and money on localization. There’s a delicate balance with Agile development and finding just the right time to start translating your content. Too early, and there could be lots of re-translations. Too late, and there’s a rush on the translations, which can result in reduced quality and overly stressed colleagues, in-house translators, or vendors. Finding that right balance is tricky.
For our first project, the technical communication manager involved and I, the localization manager, were in constant contact. We had many discussions about what she estimated the word count would be based on prior experience, how quickly I thought that the translation could be turned around, our gut feel of how the development was progressing, and “drop-dead” dates of when we would need translations returned so that the translated help could be incorporated with the product being released. We worked back from our drop-dead dates to establish a timeline that we hoped would be realistic, but also could work with the fast pace of Agile development.
Starting the Localization
To ensure the quality and consistency of the localization, it is important to translate as much of the user interface (UI) as possible before starting any content localization. It is possible to do UI and content localization at the same time, but the translators must have a high level of collaboration and consistency to ensure UI translations are correctly reflected in the content translations.
We were working on a six-month release cycle, with two-week sprints. The first iteration of UI translations was done three months into the development cycle (see timeline figure).
We gathered as much information for the external translators as possible—glossary terms, translations of other products that are in a similar domain, and the current draft version of the online help for them to search to help understand the UI. Translating a glossary of terms is a typical first step in a new product translation, and if the documentation team already has a draft glossary ready, the process is easier than having to start with terminology mining. Well-defined product terms are like nuggets of a precious metal!
In-country reviewers performed a linguistic quality assurance of the initial UI translations. The UI translations were updated, the translation vendor was informed of our company’s preferences for certain translations and terminology, and these preferences were added to the glossary to make it a bilingual glossary.
Approximately two months before product release, the technical communication team prepared a subset of the online help for translation. Since the technical communicator and manager were closely involved in the sprints, they were able to determine which content was relatively mature enough for translation. We all realized there might be re-work, but had included that re-work into budgetary and effort considerations.
Counting Down to the End
After that initial localization, we performed another round of content localization one month before product release. We caught up on recently-finished development and stories and added in-country review comments. Since the product had moved into hardening sprints pre-release, the product was quite mature, and unlikely to have lots of UI and content changes. We had planned for a final localization cycle at three weeks before product release, but we did not need it. There was a palpable sense of relief that the translations would not have to be included in the product just before the release date.
A new learning experience for our team was the time involved in preparing our content for translation. We had our tool and product experts involved in this project, due to its ground-breaking nature for our company. We used mature content development tools, but some of the intricacies of their localization functionality were new for all of us. We planned multiple iterations, just like in regular Agile code development, to ensure we would have the opportunity to find issues and correct them. We found that certain elements needed to be localized in the authoring tool, and were not exported with its localization module for translation. We discovered how we could update content translations, and whether the tool’s processes required more effort by the technical communication team or the translation team.
As a team, we delivered a fully localized product and online help to our customers with the product release.
Learning from the Experience
The overall process taught us several lessons. We learned to create a glossary of terms early in the development cycle. That glossary may not be ready for release to our users, but it was sufficient to help our translators learn more about the domain and terminology involved with the software. Much of our product terminology is quite similar to regular words, but has particular definitions within the businesses that use our software.
We learned about the processing time involved with producing localized help in our tools, and added this processing time into our future release planning.
Finally, we learned to embrace Agile, and work with Done rather than perfect. Complete, accurate, translated content was delivered to our users. Some processes were different than what we would have done in waterfall, but we embraced that difference to deliver the best possible outcomes without working 20-hour days.
Analyzing the Process
Since entering the world of localization, and discovering that localization teams feel even less involved and aware of product developments than technical communicators feel, I’ve realized that technical communicators have some great co-conspirators in their companies’ localization team. The localization team needs the expertise of the technical communicators—you will see the product first and be able to suggest and correct UI labels that will be hard to translate. You will work with the product and come across errors or confusing user experience issues that could be even more confusing to an international user. Your language and communication skills are front-line advocates for all users, including those who will not use your products in the source language.
During our first time through this type of process in Agile, we relied on information from our translation vendors, localization conferences, and researching technical communication and localization publications. We also learned by doing.
Considering Different Approaches
What could we have done differently? We might have considered not attempting to simultaneously ship source and localized language at the same time. This goal was a pretty gutsy effort for the first release of a new product. The primary customer of this product was from a non-English speaking country, so we wanted to show them that localization was an intrinsic part of product development from the very first release and not an afterthought they needed to wait for.
We might have considered running the localization process as a waterfall process rather than attempting to embed it into Agile. There are companies where the development process runs in Agile, but the localization process runs in a mini-waterfall process during hardening. This approach could have been an option for us, for both the UI and content localizations. But we decided to be bold, embrace Agile, and embrace the difficulties that we might encounter.
This six-month project was tough, scary, and new. It was definitely worthwhile to jump into a new process, just like the new Agile development process we were working in. Now, any new Agile localization processes we try are going to be tweaks and refinements on what we have already achieved—which is not as scary as what we have not yet attempted.
Kirsty Taylor is a manager of content and translations for Ventyx, an ABB company, in Brisbane, Australia. Her team of technical writers are based throughout Australia, documenting everything from the amount of explosives needed to get metals and minerals out of the ground through to asset maintenance processes. Kirsty is also responsible for product and content localizations globally for Ventyx. She is on twitter @kirstyt.
Reference:
Agile Alliance – Done Done – http://guide.agilealliance.org/guide/definition-of-done.html
