This article was originally featured in the Jan./Feb. 2011 issue of MultiLingual Computing Magazine, in Adam Asnes’ Business Side column. Read article “Agile Challenges” on MultiLingual’s Website.
A Hot Topic
Agile development is such a hot topic these days because it represents a change in how software is developed. More specifically, it has proven successful in producing highly productive results. It has a lot of developers very excited, and at this point, it’s hardly going away. That’s why back at Localization World Seattle in October, I was disappointed that a featured panel discussion about localization and agile development seemed to be more about the frustration of how three-week development sprints are incompatible with large localization efforts. I understand both sides of this argument, but I think the opportunity and consequently the impact on software localization practices here are potentially exciting.
Let’s step back a bit and look a little at the business and process drivers for agile. For those not following software development, agile is a management process with narrow and reduced scope that breaks down tasks into smaller efforts, where the object is to make product development advances in short cycles, typically three-week sprints. At the end of the three weeks, there can be a new release, or not, but agile cycles do result in more releases over far shorter periods of time than have been traditional in software production. This is exciting for development teams, even on an individual level for the very human reason that it’s really cool to build new stuff and see it come to fruition without getting caught in organizational planning and task bottlenecks. It’s even better for the customers, as they get new features faster, without having to wait for monumental releases that used to only happen perhaps once or twice a year.
There are all kinds of other benefits, and a quick search will teach you the basic concepts.
Internationalization and Agile
Internationalization is really just a part of the software development process. Hence, it can fit into agile quite nicely, at least in the case of ongoing internationalization as part of an already internationalized product. In the case of internationalizing legacy code, usually a separate code branching effort is required, and the cycle will be quite different than typical sprint-feature development.
For ongoing development, internationalization has to be understood as meaning more than just embedding strings. Every programming language and architecture have potential unique functional issues relating to internationalization. This is where measuring with static analysis tools gives you good assessment and ongoing metrics data rather than just relying on iterative, limited testing. There is a business and process value to knowing your product is internationalized, and that never gets finished, especially with agile, as there is so much new rapid development combined with less dependency on formal design.
Localization and Agile
The process of localization as it has been simply can’t comfortably keep up with agile release cycles. The challenge is that it’s very possible that new feature strings for translation might not be finalized until late in a sprint, and then they have to be compared for context with the rest of the application and perhaps translated into a multitude of languages, with new language packs and installers needing creation and testing. Localization likely just does not fit into that initial sprint. It follows that localization may have to be broken up into demonstrable sections. Some locales could possibly take precedence. In many cases, individual sprints will not result in large changes or word counts to the interface, but these sprints must be localization managed. It would be important to include developers in localization process awareness. Giving a localization manager advanced notice of what’s coming is a simple, low-cost place to start. Another solution is to aggregate releases for localization events, which will significantly lag behind development. Think of it as a waterfall process managed by agile methods. That is not exactly ideal for customers depending on those localizations, and they lose faster access to new features that agile enables. Plus it creates a competitive opportunity.
- Why should customers outside of the home market have to wait for three or four sprints? I’d recommend a clear plan to demonstrate that you aren’t falling behind too far. So what’s an agile, but globally-focused company to do?
- Educate the teams with the business, process and technical opportunities and ramifications of internationalization and localization. Start with the product owner (such as a product manager). This person leads features and release schedules. Confirm marketing and business impact of internationalization and localization. Confirm internationalization standards and requirements. Organize the localization backlog and release schedule, mapped to various sprints.
- Have a scrum master. This person manages the actual work produced by developers during sprint efforts. Make sure he or she is aware of global requirements and processes per the product owner. Bring localization manager(s) into scrum planning. Include internationalization criteria in development and testing. Measure internationalization with tools, not just by mucking about with a few screens. Get new strings to the localization manager as soon as possible.
- Have the localization manager work on creating internationalization and localization design patterns, which should be clear and reusable for sprint efforts. Track terminology and help developers with consistency of content creation in the interface and documentation. Perhaps a reach, but at least build in time for content review.
- In documentation, consider tools such as acrolinx to help make descriptions more localizable, rather than reinventing descriptions over and over.
- Consider new ways to see application translation in context, rather than the traditional list of strings. There are new tools coming to the market that emphasize product context views of translations. They are more applicable to browser based and multitiered applications than traditional tools that are limited to client applications. Some of the crowd-sharing site translation efforts are using early forms of this technology. Getting a contextual view drastically reduces the time and burden of linguistic context testing.
- Work with a localization company that understands and can move quickly with you. I’ve seen considerable differentiation among localization companies in regard to understanding development processes. The best partners are capable of enhancing your planning.
Conclusion
All of these efforts will take time, money and a focused initiative. That’s how it is with change. The move to agile took investment in training, new process thinking and tools. In many companies, localization has been an afterthought to development, but as global revenues command more of a company’s profits, the strategic and tactical efforts of internationalization and localization must catch up. Likewise, localization professionals will be charged with leading the effort, requiring them to contribute with ideas and improvements.
About the Author
Adam Asnes is President and CEO at Lingoport and enjoys investigating how globalization technology affects businesses expanding their worldwide reach. Adam is a sought after speaker at industry events and a columnist on globalization technology as it affects businesses expanding their worldwide reach. He often writes articles for localization, internationalization and globalization industry publications and enjoys cycling and Colorado’s Rocky Mountains; he can be reached by clicking here.
Lingoport’s Internationalization (i18n) and Localization (L10n) Tools and Consulting Solutions
Founded in 2001, Lingoport provides extensive software localization and internationalization consulting services. Lingoport’s Globalyzer software, a market leading software internationalization tool, helps entire enterprises and development teams to effectively internationalize existing and newly developed source code and to prepare their applications for localization.
For more information on how Lingoport can assist you with all of your internationalization and localization needs, please contact us at info@lingoport.com, call 303.444.8020, or contact us here.
