Agile software development is one of the most challenging environments for localization, and it just happens to be a specialty of ours. These seven tips will give you a foolproof strategy, smooth process, and high-quality software localization for ongoing updates in new language markets.
The ham and eggs restaurant
Unlike traditional “waterfall” methods, agile software development has continual releases, self-organizing teams, and fluid assignments during a sprint. Professionals involved with agile development also see their role in the process a little differently than with waterfall.
This is illustrated by the commonly referenced “Chicken and Pig” story: a chicken and pig meet and decide to open a ham and eggs restaurant. The pig is completely accountable and deeply committed by supplying the ham right off his back. The chicken, by simply supplying the eggs, is an interested party to the project and can continue on with day-to-day life without too much sacrifice. With agile, all players involved fall into a variation of these two roles. Pigs tend to be scrum masters and facilitators, development team members and product owners. Chickens tend to be vendors, customers, and managers.
Now, imagine that the chicken and pig want to open a restaurant in Mexico (jamón y huevos anyone?). How does localization fit into the agile development mix of roles, fluid responsibility, and constant releases?
Determine goals for your international launch. How often will you release your software and for how many markets? Do you want to launch in all markets at the same time? What are the drivers behind the releases? Scope your strategy from a development and localization perspective.
Before starting, work with your localization vendor to answer the following questions:
Do we want localized releases at the end of each sprint or at the end of every three or four sprints? How much will that cost? How does this play into our international release strategy?
What are the localization requirements of everything on our burndown lists (outstanding tasks and the time estimated to accomplish them)? And how do we build this into our sprint planning?
When should we start handing off files to our translation vendor?
How often should we handoff?
When should we test?
What type of process should we have in place for creating localized builds?
How does our development team deal with bugs that are found during localization testing?
Work closely with your localization vendor. While vendors traditionally take on the role of a chicken, they can become a pig for sprints where localization is a major element. This makes your localization vendor more visibly involved and accountable. Whether they are designated a chicken or pig, inform your vendor upfront about your agile development methods and project release schedule — they should conform their methods to yours. You may even want to include them in sprint meetings that include localization builds. A good vendor is committed and flexible, working closely with you on each relevant milestone.
Your development team should own internationalization. Any internationalization bugs that arise should go to your development team and ideally, not anyone else. In addition, all internationalization testing for a particular sprint should be completed before going onto the localization component of that sprint; if not, internationalization bugs will ultimately hamper localization and may cause delays in the release.
Establish a minimum amount of linguistic test passes with the most amount of features to test. The more test iterations you have, the more the cost. Your motto should be: Hoard your tests! In other words: translate, translate, translate, then linguistic testing.
It’s not efficient to linguistically test half a feature. Communicate to your vendor which features are completed versus not. You may not want to test until you’re completely sure that a feature has been 100% completed.
As with “waterfall” development, create a process for bug fixes during linguistic testing. Agile speeds up the bug fix process as they are found continuously during testing. When bugs are fixed, your localization vendor needs to verify them. In addition, you may want multiple small verification passes to remove all bugs by the time of release.
Each company adopts agile software development differently and there is not a universal solution. This means that localization must adapt to each company’s agile process — and Acclaro has extensive experience doing just that. Contact us today to learn how Acclaro can help you achieve high-quality software localization, whether developed via waterfall or agile methods.