Bookmark and Share
Email This Link

Sprinting to the Finish: 7 Tips for Software Localization with Agile Development

by Lydia Clarke

June 12, 2013

agile localization

Agile software development is the ticket for tech companies on the fast track to launching the next life-changing program or application. A flexible and fast development schedule makes it the bread-and-butter of innovators sprinting to global markets. But integrating agile development with software localization efforts is not for the faint of heart. Complexities and unforeseen hurdles can get in the way of a smooth global sim-ship. 

Follow these seven tips to avoid the common pitfalls and prepare your teams for multilingual agile success.

1. Think about ROI

If you decide to localize your software in agile, there’s a good chance you’ll spend more localization dollars than with waterfall methodology. When Cisco moved from waterfall to agile software development for one of their products, they found that localizing after an agile sprint was on average around four to five times less expensive than one waterfall release. However, with waterfall, they released three times a year, compared to 25 times with agile. In the end, agile cost more over the course of a full product launch.

The extra spend might be worth it, however, given the upside that agile affords you: quicker releases, swifter bug fixes and an early bird advantage to new markets, all of which influence revenues. A measured approach, such as localizing every other release or only every dot release, could strike the right balance between agility and cost-efficiency.

Considering all of your options beforehand and informing your localization company as to your course of action will enable you to maximize your ROI.

Efficient spending

2. Make internationalization planning mandatory for completing a sprint

During sprints, the dev team is hunkered down and focused on what they need to do — coding, coding and yes, more coding. But if their code is not internationalized, it will cause headaches and delays down the road when software localization begins. Classic internationalization issues include hard-coded strings, number and calendar formats and search problems, to name a few. These bugs come to light when the sprint goes into the localization phase. At this point, the dev team is typically immersed in another sprint, and fixing bugs from a previous sprint isn’t on the priority list. To avoid this issue, ensure that your dev teams own internationalization from the outset and deliver localization-ready code.  

No delays in localization due to internationalization issues 

3. Approve terminology after the translation cycle

Due to the swift nature of agile development, we recommend translating terminology in parallel with your content and submitting it for approval at the end of your software localization cycle. If you have changes from your reviewers, you can incorporate them before releasing to customers. This may sound counterintuitive to the standard best practice of approving all terminology before translation, but with agile, there’s no time to wait for reviewer comments. Luckily, sprints are usually small enough that terminology consistency within an update is not a major issue.

Terminology does not delay the localized sprint

4. Use the regular schedule to your advantage

Agile has a steady stream of localization versus fewer and bigger bursts with waterfall. The regularity of agile’s multiple rolling planned iterations can benefit you because your teams will grow accustomed to the translation process. Localization will become and remain top of mind for everyone from developers to reviewers. Another advantage is that your localization agency will get very familiar with your product and content.

Forecasting and product knowledge 

5. Evaluate whether each sprint is worth testing

Just as you question whether it’s worth it to localize every sprint, you should ask yourself in the planning phase if you need to linguistically test every localized sprint. We recommend testing releases that involve a new feature or that include at least 300 to 500 words. The exception to this rule of thumb is when words in the release are mission-critical.

Benefits: Minimize costs and reduce localization effort

6. Get localization in the scrum

If your goal with agile is to get to market quickly, then heed this advice: get someone to be your “localization rep” in the scrum. This agile team member does not have to be an expert in internationalization or localization, but he/she should be an advocate for localization. This person is thinking about localization at the planning phases and at the beginning of each sprint where localization is slated, and they ideally serve as the contact with your software localization partner. They also help to resolve any issues or questions that occur during the sprint. 

No surprises and smooth localization

7. Set up a framework for queries and review

Make sure at the beginning of the localization process that all of your subject matter experts are set up and trained in a framework in order to address linguistic queries and questions. This framework ideally should be the same platform you use to manage your bugs: Jira, Yammer, Asana, Google Docs, Facebook Groups, or another program, as long as it matches your company culture and the way you communicate. By using this central platform, each player will know what they need to review, where they need to go to accomplish their tasks and how they can route queries to the right person. The benefit of using a single platform for bugs and linguistic queries is easier management and more visibility, as well as one fewer password for your teams to remember. 

More accurate translation, quick answers for each sprint

Equipped with these seven tips, your dev teams should make it to the finishline in record time. Contact us for more software localization tips or request a free quote for your software localization project today.



Request a Call Back

First Name:
Last Name:
Job Title:
Valid business email required