Are you learning about Agile software methods, but aren’t sure how to apply them to global software? This article explains how to do globalization in an organization using Scrum as a methodology.
The primary activities of software globalization are internationalization, localization, and testing. We will describe how each activity maps to the Scrum process.
Software Internationalization (I18n)
Software internationalization is the process of architecting and writing software so it will function properly in multiple countries. It involves designing software in a modular fashion so new countries can be easily supported by swapping out language packs and software libraries, rather than rewriting lots of code. This is a primary engineering task, and is well-suited to being done with Scrum. Requirements from international customers tend to change rapidly, so using Scrum to address these requirements in an agile fashion is a great idea.
Functional Testing
This is functional testing that is specific to the internationalization process. This verifies that generic features can be used by international customers, and also verifies features that are specific to certain international market segments.
Functional testing is done using international test data and localized systems. This type of testing may use “pseudotranslated content”. This is content that has been tagged to belong to a certain language and has strings that are of lengths typical to each locale. This allows engineers to verify that international content will be handled properly after translation and integration. Localized test data will use international character sets, and country-specific formats for numbering, currency, addresses, dates, phone numbers, names, etc. Also, functional testing will test using any third party libraries or modules required by target locales.
Functional testing can be done as part of a standard sprint. For global requirements, a Test Driven Development (TDD) methodology can be applied. In this approach, tests are written for each locale before any code is written for that functionality. Code is then developed against those tests. The code is complete when all international tests are passed. These tests are often automated to ensure that any future changes to the code will not break functionality for international users.
International English Version of Software
The result of software internationalization and functional testing is an international version of software. Often, the first target language for software is English. The international English version of software has been tested to work with all target locales, although the user interface and documentation is still in English. Some companies may decide to ship this version of software to international customers immediately to gain feedback on the product. It is important to note that unless the software has been tested for multiple locales using localized test data and systems, it cannot be considered an international version of software. Remember, if you don’t test, there are definitely defects.
Localization
Localization is the process of adapting content, including user interface and documentation, to target locales. This task is often done by outside firms staffed by native speakers in various languages. This work is usually billed on a per-word basis, with additional charges for document preparation, glossary creation, and desktop publishing. Costs can increase rapidly if many changes are made to the content during project. For this reason, it is best to wait until the definition of the software is fairly stable before proceeding with localization. You may decide to develop new functionality across several sprints, and then submit the content for localization after the features have stabilized somewhat. Of course, your international customers are just as eager to get new features as those in your base locale, so this can be a tough decision to make.
Localization may be done in-house or by an outside firm, so you may or may not have direct control of the process by which it is done. However, you can see that if your core engineering is managed with Scrum, it is best to submit content for localization after a sprint where the functions in question have reached some level of stability to minimize costs.
Localization Testing
There are several types of testing done during the localization process. These include linguistic, cultural, and cosmetic testing. These forms of testing are usually done by an outside firm, so the process by which they are done may not be under your direct control. However, many firms do in-house cultural and cosmetic testing using marketing personnel or country managers from each locale.
Integration and Deployment
Once the content comes back from localization, it must be integrated with the code and tested. This last stage is suitable for being done in an agile organization. However, you should avoid adding new requirements to the integrated software before release that impact the user interface or documentation because this will incur additional costs for localization.
Final integration and user acceptance testing can be done in the final sprint before release. This ensures that the product is ready for end users in each locale.
Balancing Agility and Cost
There are trade offs to be made between the flexibility provided by Scrum to change requirements with the costs of localization for each change. The ideal approach is to develop new features for all international customers simultaneously and verify this functionality with prudent testing prior to localization. Once the features have stabilized, they can be localized with minimal cost. Although final integration and testing may be done by the same team as initial development, care must be taken to protect the localized code from changes prior to launch. New feature requests should be submitted and queued for future localization and integration in the next sprint. This suggests an idea for two parallel pipelines: one for new functionality that welcomes new requirements, and another pipeline for integration of localized software that is more sensitive to changes. The number of sprints between localization rounds and the length of each sprint can be adjusted to balance these trade offs.