Agile development tackles large software projects in small pieces. This approach brings both challenges and benefits to the software localization process.
This paper examines the changes that Agile brings to the forefront for software localization. By working closely with your localization agency, you will find ways to take advantage of Agile’s frequent cycles of incremental releases to improve quality and reduce costs in localization.
Why Agile Is Important for Global Business
If your company is moving to Agile or already using it, you may be aware of the considerable benefits of Agile development in today’s global marketplace. Rapid time to market, responsiveness to customer demands and to changes in technology, and continual improvement in quality are among the reasons that Agile has become the methodology of choice for many software companies, and even in other industries.
1. Rapid time to market
Several software trends — Software-as-a-Service (SAAS), cloud, web-based apps, and smaller applications like mobile apps — have resulted in the need for shortening of time between the beginning and end of a project. To meet the demands of customers more effectively, smaller product increments that deliver specific features have become the norm. While some argue that there is still a place in software development for projects 18 months in length, Agile’s penchant for two- and four-week sprints is changing expectations for even large projects to go fast and small projects to go faster. Change happens so fast that in 18 months’ time you might already have lost your market share.
2. Responsiveness to changes
Agile is designed to meet changes in technology and business landscapes. When this year’s low selling on-premise software could be next year’s top web application, it pays to work in small chunks that could more easily be repurposed in the face of a technology change.
While geopolitical shifts and economic cycles do not change languages, they do change markets, and Agile lets companies capitalize on these opportunities.
3. Continual improvement in quality
From the perspective of service and support, fixing language-related bugs in the design, programming, or testing phase saves money by resolving them long before they reach the customers and begin accumulating at the help desk.
This is true for all software bugs, but it has been common for localization-related bugs to linger far too long. Agile localization lets you address translation issues sooner rather than later.
How Agile Impacts Localization
Instead of using the old Waterfall (or bursting dam, in many cases) approach of handing off hundreds of pages and resource files to the localization agency in one or two deliveries near the end of the project, software companies that employ Agile methodologies can hand off content for localization after each sprint. While this rapid cycle brings its own challenges, it can also bring the benefits of Agile to the localization process itself.
Quality of the translated content is continually improved because testing of the localized versions takes place much earlier in the project. Almost every sprint contains something new to test — user interface, functionality, global-readiness, documentation — so main product testing and localization testing can take place “in the same time zone” instead of several months apart as in traditional software projects.
Over time, cost savings typically result from integrating localization into the Agile process. It is easier for a developer to fix localization-related problems in last week’s code than in last year’s code. Agile increases the potential for resolving bugs early in the programming phase rather than in the operation phase after release. The considerable cost differences are depicted in Figure 1.
FIGURE 1: Increasing cost of defect correction
| Phase the defect is found | Cost per defect |
|---|---|
| Requirements phase | $80 |
| Design phase | $240 |
| QA/Testing phase | $960 |
| Once released as a product | $7,600 |
80% of development costs are spent identifying and correcting defects!
Agile can help spread the workload of localization testing for more effectiveness. In the Waterfall approach, most of this work falls to the localization agency and, if you have one, your company’s internal localization team. With Agile, since development and localization are occurring so closely in time, developers and QA teams can test the localized software along with the unit, functional, and integration testing they normally perform.
How to Optimize the Localization Process in an Agile Environment and Reap the Benefits
1. Planning
Because Agile brings localization into mainstream development, you and your localization agency need to work out new logistics, such as reconciling the sprint schedule to the translation schedule, working out the mechanics of file handoff and hand back, and assigning responsibility on each side for localization related tasks.
In the Waterfall approach, planning is often limited to the question of when your company will hand the project off and when the localization agency will deliver it. Under Agile, planning ensures that nothing goes missing in the continuous back-and-forth of small pieces.
Depending on your product, language needs, media, and cost considerations, you can choose the localization cycle that is right for you. If your product or customers demand release of all languages at once, known as simultaneous shipment or “SimShip,” you will need tight integration of the localization process into the sprint cycle.
To save costs and effort, it is common to arrange for “n-minus-1” localization, in which your developers begin work on, say, sprint 4, while translation begins on the content from sprint 3.
Some media such as video have a longer lead time for localization and production, so a release cycle for these media might be “n-minus-2” (or more). It might also be useful to collect enough material for each multimedia session to minimize cost, but these are all considerations that should be discussed during the planning phase.
With n-minus-1, content is handed off at the end of the sprint and localized in the next sprint. With SimShip, content is developed, localized, implemented, and tested in the same sprint.
Benefits: By planning ahead with your localization agency, you can develop a schedule to integrate the Agile localization process into your product release cycle.
2. Costs and budgeting
It is important for both you and your localization agency to analyze cost estimates closely and strike a workable balance with volume. Many companies develop a “hybrid” approach, localizing content in larger batches to achieve economies of scale, since certain costs such as project management apply to each batch.
To save money, you could change the schedule from localizing after every sprint to localizing after every other sprint, or your development team could change the duration of a sprint from two to four weeks to allow time for localization.
On the other hand, you could determine that simultaneous shipment is worth the additional cost and handoff at every sprint. The important point is that you need to sit down with your localization agency and complete a financial analysis of the new “Agile reality.”
This stream of small projects also affects how the localization agency works with your purchasing department. Internally, such as for the engineering group, the shift to Agile involves employees on a payroll, so the lack of a clearly defined start and finish makes little difference in cost; for external resources, however, the localization budget can look to a purchasing department like an indefinitely long series of one-off purchase orders. Constantly negotiating these would defeat the purpose of Agile and generate lots of extra work for both you and your localization agency.
Instead, the Agile model lends itself to arrangements like a quarterly/annual purchase order or a contract. A good point of departure is to assume that the localization costs in the first year of Agile will be on par with those from the previous year and build an agreement based on them.
Benefits: Agile’s steady stream of small handoffs generally results, over time, in lower development and localization costs.
3. Collaboration and automation
You will need to work with your development team on internationalization (i18n) of the software to accommodate localization. For starters, user interface text needs to be externalized from the software code and placed in locale files for easy localization. But as mentioned above, there is no time available for i18n bugs to appear in the process. The localization testing must be part of the regular testing for all of engineering.
To handle the increased number of files and the quick turnaround, you and your localization company will need to automate the workflow. The traditional tools of File Transfer Protocol, e-mail attachments, and spreadsheets for moving and tracking files are time-consuming, and not up to speed for the Agile process. Cloud-based translation environments incorporating workflow management and content management systems (CMS) are mature enough to support these projects and grant access to everyone involved.
More people need to talk to more people more frequently in an Agile project than in a traditional one, so you and your localization agency will both benefit from collaboration suites and forums that are easier to track than e-mail threads, and with an audit trail should problems occur.
In the past, the localization agency provided project managers to coordinate the translators, serving as a go-between. The need for coordination is still there, but communication needs to become more efficient for Agile to succeed.
The pace of an Agile project requires much tighter coordination, often putting your agency in direct contact with the translators.
A common starting point in the age of web-based defect tracking systems is for the localization agency and the translators to submit localization bugs directly to your database and for communication between subject matter experts, such as engineers and translators to be direct, not via a series of project managers.
Benefits: The rapid pace of Agile demands coordination both within your company and with your localization agency. This improvement in communication results in smoother processes for developing your product.
4. Subject matter expertise
Over time, a dedicated team of translators and localization professionals builds subject matter expertise through the continuous stream of small pieces of content on a short turnaround.
By working with your project in small pieces over a long time, the localization agency’s project managers understand the project’s pace, localization engineers can predict the file structure, and translators know the products and the industry vocabulary and nuances. The results are fewer questions, higher quality, and greater throughput in the localization process.
Consider the Waterfall project depicted in Figure 4, with three handoffs for localization and significant changes between draft and final content (shown in red):
FIGURE 4: Workload spike on Waterfall project
The only way to meet this workload peak is to engage many translators quickly for a short, furious burst of work, a large percentage of which consists of changes to draft content. As professionally competent (and available) as they may be, these translators do not have much time to develop or apply subject matter expertise.
In the Agile project depicted in Figure 5, conversely, there is a constant flow of roughly the same amount of content for handoff and only minor changes to draft content each time:
FIGURE 5: Workload balance throughout Agile project
As a result, there is no major peak in workload, so localization can proceed more smoothly with fewer translators commanding greater subject matter expertise over time.
The quality of work is improved and you may realize savings of 5-10 percent on the cost to localize the product.
Finally, this expertise results in an unsung benefit to your company. Translators are, in effect, the first and most probing audience for both user interface and documentation — since if the translators cannot understand content, they cannot translate it.
The more a team of translators reviews the product and documentation over time, the more valuable feedback they have to offer. If translators submit bugs, the writers have the opportunity to correct the text early in development, instead of after the product has shipped.
Conclusion
Localization in the Agile environment requires tight coordination, both within your development team and between you and your localization agency.
Your localization agency should have the tools and processes in place to handle the steady stream of smaller projects that corresponds to your company’s sprints. Traditional tools for moving and tracking files — email and spreadsheets — can break down under the traffic of Agile projects, and cloud-based translation tools with workflow and CMS are better suited to the volume and turnaround.
