Report: It's Time To Include Localizers on the Agile Team

There was a time when enterprise application development teams simple threw their code over the wall to the people charged with the task of localizing it. Those days are fading, of course; software developers in medium to large companies have been generating ever greater percentages of their organizations' revenues outside the West for the past decade. And the pressure to "go global" faster is ever increasing.

Consequently, say the industry watchers at the Cambridge, Mass.-based research firm Common Sense Advisory, it's time for the team responsible for adapting U.S.-made software to other languages and cultures (a process called localization) to join the Agile team.

"Agile goes so fast that the other teams supporting it have had to get much closer together," said Director of the Global Leaders Service Rebecca Ray. "Testing, documentation, even the marketing people -- everyone needs to get together. And the localization team needs to work closer with the app dev team, too."

Ray recently co-authored a research report ("Localization at the Speed of Agile: Best Practices for Making the Transition") with her firm's founder and chief strategist, Donald A. De Palma. The report looked at the unique challenges associated with implementing Agile localization through interviews with 21 companies that develop software and faced this challenge.

"Agile is the gateway to integrating internationalization and localization as they were meant to be in the software development process," the authors wrote. "No localization team should pass up the chance to make it happen."

You'd think the spread of lightweight development methodologies among app dev teams would offer a nice solution to this "go global" challenge, but Agile is not a natural fit with traditional localization processes, Ray said.

"Agile is really a different way of developing software," she explained. "It's much more circular than linear, so it basically breaks the more linear processes that have been used for localization in the past. It's a huge change for localization teams."

Yet it's a change that must be made, Ray said. The localization team must become a part of the Agile team from the beginning of a project. If you don't want it to break your software, "localization" must become part of the "definition of done."

"Make sure that you talk to the localization people up front, during design," she said. "When you put together your users stories, the localization people should be in that group. The definition of done has to include localization."

During their research, Ray and De Palma found three common strategies among the companies interviewed for "syncing up" localization teams and developers: 1) "lag one sprint behind developers," which allows localizers to test features that may not be finished until the last minute in the previous sprint; 2) "stay current with each drop," which requires a high degree of automation, especially if sprints occur every two weeks or less; and 3) "sync up when most of the user interface (UI) work is complete," which allows the localization team to avoid the huge churn in features that usually happens within the first few weeks after development begins.

The report emphasizes the importance of automation to the success of an Agile localization effort. "Things have to be automated enough so that the translation management software can be connected directly into the source code repositories," Ray said. "That way, the software can just pick up whatever strings have changed and shoot them off to the translation/localization provider."

Also, the integration of localization with Agile doesn't have to be an all-or-nothing proposition, the researchers suggested. "There are certain things you must get right and places where you have to align or integrate localization with product development processes," they wrote. "However, you don't need to attend every single Scrum, translate every iteration of every string, or deliver 100% human translation for all sprints. If you spend too much time creating a perfectly Agile process, you will likely lose much of the adaptability and flexibility that comes with the model."

The reprioritization of localization from a last-minute consideration mirrors in some ways the status evolution of software testing from the ugly stepchild of the software development process. Proper localization can be a matter of life-and-death when it involves medical devices or automotive applications.

"I want to be sure that the doctor in Turkey can read my MRI output," Ray said. "And when my Toyota Prius arrives, it better speak English to me, and it better speak it well. There can't be any mistakes in that dashboard."

"People should keep in mind that this should not be painful," she added. "It should just be, this is another business process, and here's what we need to do."

An extract from the report is available on the Common Sense Advisory Web site.

Posted by John K. Waters on March 7, 2014