Many development organizations are in various stages of embracing agile methodology for the development of software products. Agile is a methodology used by software development teams as an alternative to the more traditional “waterfall” style of project management.
Scrum, for example, is a popular agile process and requires a team with three roles. These roles are scrum master, product owner and team member. Scrum teams are meant to be self-managed. Scrum requires close team collaboration and a number of specific meetings, including story backlog grooming — stories detail in one or two sentences what a system must provide — sprint planning, a scrum stand-up meeting and a sprint retrospective.
However, infusing globalization to the process is still a challenge. Various localization service providers (LSPs) and others are designing and implementing solutions. That is good news. If your success is based on doing business globally, you will want to take the plunge and begin to incorporate globalization best practices.
Still, based on my experience to date, it is not clear that all solutions under consideration are fully addressing some very real facts of life for in-house localization managers. First of all, corporations almost always look to spend less money on localization and translation. Second of all, localization budget cuts in hard times or perceived hard times can be very dramatic. Third, corporations and teams tend to create their own customized versions of agile, whereas agile teams tend to think about globalization as translations for which the localization team is responsible. Lastly, agile does not accommodate well to globalization, internationalization, localization and translation (GILT). Scrum teams, for example, are likely to be small groups of people working at the same physical location. In the world of GILT, same-site location is a highly unlikely prospect.
There are many localization managers whose reality is that budgets are falling, throughput is increasing, and goals for high quality and on-time delivery are as stringent as ever. This article discusses ways to approach agile globalization, and focuses primarily on development and delivery of software user interfaces in multiple target languages. Any summary of agile here is highly simplified — you can find many books, articles and consultants who are well-versed on the subject.
Acme Earthworks Inc.
To help illustrate some points, imagine a software company named Acme Earthworks Inc. that develops and distributes online calendars, among other products. For the sake of discussion, let’s assume that the natural language of the original development team, and of the software user interface (UI) is US English. The agile teams include people from product management, testing and technical writing. They do not include direct representation from the area of localization. Let’s further assume that the company is already receiving orders for French language products from France, where it was able to make a market entry several years ago due to the purchase of calendars by a US-based international customer. Now, Acme Earthworks Inc. identifies some major revenue-producing opportunities in France, Germany, Canada, Brazil and the People’s Republic of China if the UI is made available in their native languages. And finally, let’s assume that the worldwide sales team is lobbying hard for Russian products to sell next year.
Just because agile may be light on delivering the thorough requirements and planning documents we are used to with the waterfall approach to software development projects, it does not mean that requirements are absent from the process. They are covered through stories, standards and guidelines. Business goals still establish the reason for the existence of the project, and influence the scope and timeline of the agile project.
Product owners who are part of the agile team may be assigned to write and manage stories, including prioritization. Through the product owner, agile teams should have a clear understanding of what is needed from them to develop products that support the global business plans of the corporation. For Acme Earthworks Inc., we might write a story like this one: “As a French user of the calendar in France, my calendar looks and feels like a native French application.” However, that approach (as seen in Figure 1) could prove cumbersome if we are targeting more than one or a few country markets. So instead, as part of the agile process, we may wish to issue a set of internationalization guidelines that are specifically created for our agile teams and prioritized for our business needs. Creating the internationalization guidelines does not preclude us from writing functional stories that are relevant to global markets. For example, next year, the Acme Earthworks Inc. product owner for the calendar may write a story that demonstrates the needs of users in Asia for support of any input method editor they prefer for passing correct Asian characters to the application.
In any and all cases, the product owners should themselves be clear about target markets and timelines for entering new global markets as articulated by the company’s executive team. Product owners should be aware of the benefits to users and to the company’s bottom line of product globalization.
Internationalization guidelines
The internationalization guidelines you write for the agile teams are likely to contain a mix of basic, “must have” guidelines and ones that are very particular to your product, its code and architecture, including supported browser platforms and so on. Internationalization guidelines can be initiated by the localization team, and should always be reviewed by at least one senior member from the product, development, quality assurance (QA) and technical writing organizations. If you do not have an in-house localization manger, engineer or consultant, product owners and other team members may collaborate to originate the guidelines.
Identifying the supported languages is a good place to start. However, it is recommended that you do not specifically exclude the support of any natural language character set unless you are absolutely sure you will never take your product to markets where that language is used. Even if you are not going to sell into a market in the short term, it is best to ensure that all new code can handle character sets and local information (date and time stamps, for example).
If you maintain a thorough set of guidelines for internationalization, you should also create short, one-page summaries of the top priorities so that all team members can see at a glance what is expected of them. At a minimum, include guidelines for developers, QA engineers, designers and technical writers. It is good practice to expand upon the guidelines over time, as you learn more about your users, markets, talent pool and the code, including legacy issues. However, remember that if you do not apply basic internationalization actions now, you may need to recode your product later. Such reengineering work is expensive in terms of both time and money. It can be a real show stopper, keeping you out of what would otherwise be lucrative markets and paving the way for your competition to enter ahead of you.
Internationalization guidelines include statements of best practices. They can also include examples that show well-executed UIs and screens, or illustrate existing issues to address. An internationalization guideline for Acme Earthworks Inc., for example, might suggest that locals control, among other things, how the names of the days appear on a calendar, and with which day to begin the week. If the team follows the guidelines, no localization or translation is required, saving money and potential delays to time-to-market.
This guideline may include an example of a previous calendar in which all calendars start on Sunday and all days of the week appear in English, or in which manually translated words do not fit or align properly for the space provided.
Internationalization guidelines may set standards for future sprint stories. They do not, however, tell agile teams how to implement solutions.
A product, as developed in increments by agile teams sprint by sprint, should always be developed as internationalized. Implementation may be staged over several projects, starting with the basics of internationalization. For example, the most basic internationalization guidelines for Acme Earthworks Inc. include the following:
Use Unicode for end-to-end coding.
Use fonts that support all character sets.
Put all UI strings in a resource file; do not embed strings in the code.
Allow the text of the UI and messages to expand by up to 50% or indefinitely.
Do not “box in” words that require translation.
Do not use concatenation techniques in the UI
Use pseudo-language testing techniques on new UI developed during each sprint.
In subsequent projects, more advanced guidelines may be made into stories that are implemented during sprints. For example, a guideline that suggests the ability of system administrators or users to select, add or modify locales (French-France, French-Canada, French-Switzerland and so on) may be addressed in the guidelines.
Because the source product is developed with internationalized UI, the UI is known to support all necessary languages (characters). Unless you wish to and can afford to fund multiple, in-house, simultaneous UI writers (in our case, for US English, French, Canadian French, German, Brazilian Portuguese and Simplified Chinese), you probably plan to translate the source English UI to your target languages.
Fully-integrated approach
By definition, translations can occur only after the source words are written. If you are defining agile to mean that at the end of each sprint you must be able to demonstrate the new UI as 100% done in the source language and in all target languages, then each sprint must be planned to accommodate translation time. You may need to hire your professional translators by the hour rather than pay for their work by the word. In this scenario, Acme Earthworks Inc. might have all translators on board for a set number of hours throughout the sprint and over the life of the entire project. The final day or days of each sprint may be reserved for debugging and for UI translations only. In essence, the translators are writing the UI in multiple languages simultaneously. If the English source string is drafted on Day 2 of the sprint, then it is drafted in the target languages. If it is edited on Day 5, it is edited in the target languages, and so on, until all source and target strings are 100% done. Each team should strive to emphasize the completion of the source English string early in the sprint. Ensuring that translations are fully completed in all languages at the end of each sprint is extremely challenging. A modified approach is to deliver the source English UI strings as 100% done while delivering the translations in draft form only for the current sprint, either by human translators or by machine translation. The translations are completed as 100% done by human translators in a subsequent sprint. The final sprint or sprints may require a moratorium on new and change source English strings.
Proof-of-concept approach
Other approaches exist. For example, Acme Earthworks Inc., relative to the UI, might define agile to mean that English strings must be 100% done at the end of each current sprint and that translated strings must be 100% done by the next sprint or some other subsequent sprint. In other words, the functionality is fully coded, the English UI is 100% completed, and the translations are due at a later sprint. In this case, the translators can await the finalized English strings before they start the translations. As soon as the finalized English strings are received, depending on the number of strings and words they contain, translators work on the UI translations in a dedicated manner to create and deliver finalized strings in the target languages. A modified version of this approach is more in the line of proof of concept. It takes into account the top-producing global markets. It calls for the rapid translation of the source strings to just one or several target languages. For Acme Earthworks Inc., this leading target language would be French for France. In this scenario, only the English and French UI strings would be developed and delivered as agile.
Ongoing/rolling approach
Another way to work translations into the agile process is to use an ongoing translation process while not requiring 100% completed translations until the end of the final sprint in the project. The final sprint or sprints will not include development of new source English UI strings. Rather, the final sprint or sprints are reserved for product testing, code debugging and finalizing the translations. For example, in this scenario, Acme Earthworks Inc. might first collect all finalized source English UI strings at the end of each sprint or every other sprint. Next, they would translate the strings according to a sprint-centered schedule, allowing an adequate amount of time for all key aspects of translations to occur, including translation, editing, proofreading, and even possibly, linguistic validation testing. They would then conduct pseudo-language testing continuously; conduct touch testing on translated UI regularly; and conduct final linguistic or subject matter expert testing of the UI during the final sprints or periodically throughout the project.
Figure 2 shows a four-sprint project in which source English UI strings are 100% completed (developed, tested and accepted) by the end of sprint 3 (S3). French, German, Brazilian Portuguese and Simplified Chinese UI strings are 100% completed by the end of sprint 4 (S4).
This rolling approach to agile translations is possibly the most cost-effective one. However, the globalization of the agile process is still evolving. You may find that onboarding translators by the hour to produce sprint-based drafts or even some approach you will design and customize for your own teams to produce the most efficient and effective results for your teams, your company and your customers.
In summary, go global while you are going agile: the two are not mutually exclusive.
