Back to School: Acing the Localization of Agile Software Development

Category: Software Translation

Summer is over, and for many students, it’s back to the classroom for a brand new year full of things to learn. For the freshmen who are new to localizing in Agile, we’ve got some tips to help you stay at the top of the class.

Lesson #1: Integrate localization with ROI in mind

Localizing after an Agile sprint can be four to five times less expensive than one waterfall release. But a waterfall may release three times a year compared to 25 times with Agile. In the end, Agile may cost more over the course of a full product launch. To help stay budget-friendly, you might want to opt to localize international versions every other sprint. Finding the sweet spot is the key.

Lesson #2: Internationalize code during the sprint

Hard-coded strings, number and calendar formats, and search problems often pop up when code goes to the localization phase. Require your teams to own internationalization from the outset.

Lesson #3: After the translation cycle, approve terminology

It sounds backwards, but it works. Translate terminology in parallel with your content and submit it for approval at the end of your software localization cycle. As there’s precious little time to wait for reviewer feedback, and the total amount of terminology to review for consistency is usually small in a sprint update, the development time-savings is worth the counterintuitive move.

Lesson #4: View frequent localization as improved knowledge management

With Agile’s planned iterations your teams grow accustomed to the translation process. Localization fast becomes top of mind for everyone, and as a side benefit, your localization agency will get very familiar with your product and content.

Lesson #5: Optimize your test cycle

Just as you might choose to localize every other update, decide if each release needs full linguistic testing. A good rule of thumb: If you have a new feature, the changes are mission critical, or a release includes at least 300 to 500 words, test.

Lesson #6: Get a localization advocate in the scrum

They don’t have to be an expert in localization, but your advocate should be thinking about localization at the planning phases and at the beginning of each sprint. Ideally they’ll also serve as the contact with your translating services partner.

Lesson #7: Establish a common communication framework

All of your subject matter experts should be trained in a framework in order to address linguistic queries and questions. Typically this will be the same platform you use for bug tracking. This way, each stakeholder will know what they need to review, where they need to go to do so, and how to correctly route queries. It may also serve as a reference for any associated translation documents from previous sprints.

The dunce cap may be a thing of the past, but those who fail to study these seven lessons may find themselves stuck in summer school to make up for lost market share.

Still lost on Agile? That’s OK. You can borrow our notes on our Agile Software Localization Services or Tips for Agile Software Development.

Now do your homework. Class dismissed!