1. Simultaneous-sprint localization across 31 locales using ‘Localized’ Kanban methodology
Amrit Pal Singh
Senior Program Manager, Adobe Systems
ABSTRACT
In general, a product’s localization goal is to increase the reach of product in international markets.
While the benefits of using agile development practices for core product engineering and
development have been well known, the industry does not have a definite answer to how these
practices can be applied to product localization.
This paper, written from a perspective of Localization Manager, takes the readers through his journey
around localization management in a big product development organization. In particular, the paper
covers the following –
a. Challenges in managing simultaneous sprint releases (31 locales alongside English in the
same sprint)
b. Overview of different management approaches taken and challenges faced in their
implementation
c. Details of Locban methodology- Locban is localized adaptation of famous Kanban
methodology and supports visualization and transparency for all stakeholders
d. How does Locban tie to different project management process groups — planning, execution,
monitoring and control, closure
We conclude by talking about productivity gains that the team had with Locban.
KEYWORDS
Agile Localization; Kanban; Agile project management
TABLE OF CONTENTS
I. INTRODUCTION...............................................................................................................................2
II. MOVE FROM WATERFALL TO AGILE LOCALIZATION MODEL .........................................................2
III. CHALLENGES WITH SIMULATANEOUS SPRINT LOCALIZATION...................................................4
IV. OVERVIEW OF MANAGEMENT APPROACHES AND THEIR CHALLENGES....................................5
V. EVALUATING THE SCRUM METHODOLOGY SUITABILITY FOR LOCALIZATION ...............................6
VI. KANBAN TO LOCBAN (‘LOCALIZED KANBAN’).............................................................................7
VII. LOCBAN MAPPING TO PROJECT MANAGEMENT’ PROCESS GROUPS.........................................9
VIII. SUCCESS WITH LOCBAN............................................................................................................12
IX. CONCLUSION.............................................................................................................................13
X. REFERENCES..................................................................................................................................13
XI. ABOUT AUTHOR........................................................................................................................14

2. I. INTRODUCTION
From a product organization’ perspective, there are two high level objectives of localizing a product –
one, increasing the reach of the product and thus getting more business and two, providing same
level of user experience to an international customer as to a product’ native language customer. At
the same time, product companies also want to make sure that the product reaches its customers
sooner, with higher quality and more efficiently. That’s where Agile comes in. In particular, agile
development accelerates the delivery of business value through constant visibility, adaptability and
reduced risk.
They key challenges for a company is to marry agile development with localization successfully and
take the products to international markets on time with same business value as the native language
for which the product was built.
This paper shares the story of a large product which began to adopt an agile mind-set and approach
starting July 2010. Since that time-frame, the team has been doing a sprint over sprint release and
thus, benefiting from iterative planning and customer feedback. This product ships in 31 locales and
the localization is done by a specialized team, referred as localization team. The localization team [1]
helps to adapt the product to a specific locale, i.e., to the language, cultural context, conventions and
market requirements of a specific target market. With a properly localized product, a user can interact
with a product using his/her own language and cultural conventions. It also means that all user-visible
messages and all user documentation (printed and electronic) use the language and cultural
conventions of the user. Finally, the properly localized product meets all regulatory and other
requirements of the user’s country/region.
The localization team, structured as a centralized function serving all product teams, provides
localization services to multiple core product teams. The centralized structure makes sense because
localization is a specialized field and resources (people, tools) and processes can be leveraged
across the company.
The product localization is led by a Localization Manager who coordinates the entire localization
activities assisted by a team of quality engineers and developers specialized in localized testing and
development. The translations are done by vendors who are spread across the world. In addition, to
help with locale testing requirements, a functional vendor is also engaged.
The localization manager also ensures that the overall cost of localization is well under budget and
that the schedule is on track. Needless to mention, other project management areas such as quality
management, people management, communication management are also taken care of by him.
II. MOVE FROM WATERFALL TO AGILE LOCALIZATION MODEL
Since localization always follows core product development (for example, you cannot start testing
translated UI text unless native text is available or you cannot start loc (localization)-functional testing
unless the build with a feature is available), it is imperative that localization process methodology will
follow whatever development methodology the product engineering team follows.
Before we describe the move from waterfall model to agile, it is important to understand that the
localization process in general has broadly 3 set of tasks for localization –
a. Translating software UI strings/ text
b. Linguistic testing to ensure that the translated text fits correctly on the software UI and that
there are no truncations or overlaps and that the text is completely readable in that locale
c. Loc-functional testing to ensure that the software works correctly in a particular locale.

3. Before the agile process came in, the localization team was aligned to the core product team’s
waterfall model. In waterfall, the localization team had few defined set of times when they worked on
over a period of 12-18 months cycle. The planning was done at the start of the project and dates
arrived at by looking at product engineering’ schedule and aligning localization dates accordingly. The
localization team would not generally start unless a sizable number of strings/UI texts are ready for
translation. Similarly, loc-functional testing could not be started unless an internal milestone of the
core product team was completed and a minimum set of features were available. See Figure 1 which
illustrates the waterfall model.
Figure 1- Waterfall localization
This localization model had several drawbacks [2] - Localization partners got overwhelmed at end
game; localization issues were found too late and, when issues were classified as “show-stoppers,”
they could jeopardize the product release schedule; many critical defects ended up getting deferred
for the next product release. The model was costly and time consuming and it increased stress and
burnout.
With move to agile (specifically, scrum model), features were being delivered incrementally sprint over
sprint. The following changed in scrum localization versus waterfall localization.
Category Waterfall Localization Scrum Localization
Planning One-time, at the start of project Multiple times, at start of project for
release as well as at start of each sprint
Sending strings
for translation
Few times over the course of 1 release
cycle (12 months)
Multiple times during the course of 1
sprint (1 month)
Loc- functional
testing
Done as couple of testing rounds over
course of 1 release cycle (12 months)
Multiple times during the course of 1
sprint (1 month) as and when a
particular feature gets delivered
Localized build
release
At the end of release (12 months) At end of each 1 month sprint
Figure 2 illustrates the scrum based localization.

4. Figure 2- Agile localization
Normally, within agile localization, product teams can further have one of the following alternatives –
a. Releasing the localized product with ‘some’ delay. This delay could be of the magnitude of
couple of weeks or months for the entire set of locales other than native language or a
staggered release with some locales taking precedence over the others.
b. Releasing the localized product on exactly the same date as native product’s language
release.
Since the former option not only delays the business ‘benefits’ that the product can reap from
international markets but also creates a competitive opportunity for nearest contenders, the product
management team decided to go for the simultaneous alternative.
III. CHALLENGES WITH SIMULATANEOUS SPRINT LOCALIZATION
The biggest challenge with move to simultaneous sprint localization was that the localization team
now had to certify all features in a sprint for all 31 locales in a limited time frame of a month. Not to
mention, the locales had to be certified on various platforms (example, Windows 7, Windows XP, Mac
10.8, mac 10.7 etc.) as well. Obviously, the features were not available at the start of the sprint for
localization team to pick up and were instead being delivered incrementally during the course of the
sprint. This meant that the team and the vendors had to align for multiple short bursts of work during
the course of the sprint.
The second big challenge was drawing up a sprint schedule for the team. Due to incremental nature
of features getting delivered in the sprint from product engineering team, the localization manager had
to draw out a similar plan for his team considering the localization timelines, vendor availability and
internal resources bandwidth. He had to closely work with vendor project managers to address some
high resource asks during the course of sprint and in an eventuality that the core product
engineering’s plan for this sprint did not look reasonable, to get back and re-plan.
With multiple vendors, team members and other stakeholders (Figure 3), sharing the plan timely
became an important aspect. The vendors needed to align their team for assigned tasks and to see

5. how a product’ schedule fitted in demand from other similar products/companies for localization. With
multiple such stakeholders and ever changing dates, vendors often complained of not getting timely
information and being caught unawares of assigned tasks. This became the third big challenge.
Figure 3- Localization stakeholders
The fourth challenge was around monitoring and control during the sprint. As the sprint progressed,
the product team would more often than not call for changes in scope and timelines (Figure 4) for
certain features, which meant that the same had to be communicated back to vendors and the team
and re-planned. Timely planning and communication again was the key challenge here.
Figure 4- Sprint localization in action
IV. OVERVIEW OF MANAGEMENT APPROACHES AND THEIR CHALLENGES
Faced with multiple agile localization challenges around planning, communication and visibility, the
localization team started to look at various solutions for documenting the plan and updating it –
a. Scrum tool (Figure 5)- this was the obvious choice since the product engineering team was
following a scrum based model and was using this tool. However, the challenge in its usage
was that the tool was strictly based on scrum which didn’t allow for addition of start date for
any tasks which was what different vendors wanted. Plus there was no way the tool could
indicate if there was a change in specific task vis-à-vis scope or timelines.

6. Figure 5- Scrum tool for task planning and updates
b. Intra-company Wiki (Figure 6) – The challenge with this was that you had to explicitly provide
access to vendors for accessing the wiki and that wiki wasn’t a good tool for putting up plans
and dependencies and to track what changed during the course of sprint.
Figure 6- Wiki for task planning and updates
c. Microsoft Project Plan & MS Excel (Figure 7) – MPP was a good choice considering planning
and scheduling is its forte. The challenge with this one was that each update had to be
entered, a version saved and then emailed to the team/vendors. Even a small update meant
emails which itself became an overhead. It is important to note that MS Project Server license
was not available.
Figure 7- MS Excel for task planning and updates
V. EVALUATING THE SCRUM METHODOLOGY SUITABILITY FOR LOCALIZATION
While trying out different approaches, a question came up – “Is the Scrum methodology, as used by
product engineering team, the right methodology for the localization team?”
It appeared that what is one sprint for the core team, with a fixed team (a mix of developers and
quality engineers) and fixed work (aka story points) based on the team’ capacity is not one sprint for
the localization team –

7. a. Since the features are incrementally delivered, the localization team has an uneven time
distribution of the work unlike product engineering team which has an even distribution of
work across the sprint. There are days within a sprint when there is no work for localization
team and a lot of work on the other days.
b. Since the ask from localization is for translation and testing across multiple locales and
platforms for the same feature, the localization team has varying distribution of resources
across the sprint unlike product engineering team which has an even distribution of resources
across the sprint. So, for a translation task across 31 locales, 31 native translators would work
in parallel to translate the text and then they would be idle waiting for the next translations
ask. Similarly, the loc-functional testers would certify a feature for all locales and platforms for
couple of days and then they would be idle waiting for next features delivery.
See Figure 8 for sample illustration of differences in ‘sprint’ definition for product and localization
team. We thus learned that while we wanted to be agile, the Scrum model was not for localization.
Given this understanding, we started to research on alternate agile methods and landed upon
Kanban.
Figure 8- Differences in sprint for product engineering and localization team
VI. KANBAN TO LOCBAN (‘LOCALIZED KANBAN’)
The Kanban method [3], as formulated by David J. Anderson, uses a work-in-progress limited pull
system as the core mechanism to expose system operation (or process) problems and stimulate
collaboration to improve the system. The word 'Kanban' originates from Japanese language and
literally translates as "signboard“. This method is becoming a popular way to visualize and limit work-
in-progress in software development and information technology work. Kanban has a total of 8
principles, 3 foundational and 5 core principles.
We can see some direct correlation between some of its principles including the following ones –
a. Start with what you do now- The Kanban Method does not ask you to change your process
and there is no such thing as the Kanban Software Development Process or the Kanban
Project Management Method which worked well for us, the localization team.

8. b. Agree to pursue incremental, evolutionary change- The localization team felt that their current
circumstances did not warrant a gentle, evolutionary approach for improvement. Any drastic
change would have neither worked nor would have found management support.
c. Respect the current process, roles, responsibilities and job titles- Kanban recognizes that
there is a value in existing organizational roles and titles and therefore it is worth preserving.
This augurs well for localization team which already has specialized set of folks doing
respective jobs.
d. Visualize the workflow – It is about understanding what it takes to take a task from request to
completion expressed visually as a card on a card wall or electronic board. So typically, we
are looking for state changes in the work which get reflected as a change in the activity. It is
very useful for localization team since its stakeholders can now have a visual access to the
upcoming, current and completed work for a sprint.
e. Manage Flow- Track and report flow of work items across various states. Flow here means
movement - speed of movement and the smoothness of that movement which is very relevant
for localization because that’s exactly what we want to measure and improve upon.
f. Make Process Policies Explicit- The purpose of this is to get an understanding of how things
work and how work is actually done and thus get to a state where the team can analyse and
empirically discuss any issues. This is more likely to facilitate consensus around
‘improvement’ suggestions.
g. Improve Collaboratively (using models/scientific method) - It is about suggesting
improvements, taking and implementing the feedback from the team members. For
localization, this would have meant analysing the process workflow and suggesting
improvements.
Then, there were some for which we didn’t see a direct correlation between how agile localization
works and how it is described by Anderson –
a. Limit WIP – It is about setting up agreed upon limits to how many work items are in progress
at any time. The new upcoming task is ‘pulled’ in only when there is available capacity within
the local WIP limit. Given the nature of localization tasks where we align ourselves with the
product engineering and that our vendors help with quick resource ramp-ups, this did not
seem to be a requirement from the team.
Given this knowledge about Kanban and its suitability for localization process, we started to define a
process and build an online tool for capturing tasks and creating a visual system around it. We first
defined what a task (Figure 9, 10) meant for the team.
a. In simplest terms, a localization task has the following attributes – Task’s short description,
Start date, Due date, Assignee, State
b. The state could be one of the - TODO (Upcoming), WIP (Work In Progress), DONE
(Completed) and represents the state of the assigned task.
c. Additional attributes were then added to the task to make it more specific to project – Project
name, Sprint name
d. And a field to add running updates, if any – Comments

9. Figure 9- Basic task ‘card’ Figure 10- Complete task details
All tasks were then mapped to a Locban board akin to Kanban board. This board had all tasks
bucketed by state and organized as project and then sprint.
VII. LOCBAN MAPPING TO PROJECT MANAGEMENT’ PROCESS GROUPS
Lets look at how Locban maps to various project management’ process groups –
a. Planning – During the sprint planning, the product engineering team picks up stories to be
implemented from the release backlog. Once the stories are finalized, the product team
publishes a build plan. This plan indicates the dates on which a particular feature would be
completed. The localization team takes a look at sprint backlog and the build plan and based
on their own judgment and consultation with product team defines which stories have a
localization impact. The team then breaks that story into multiple executable tasks, puts in
assignees, estimates for task duration and adds the start and end dates. These tasks are
then added to Locban board.
As soon as the task is created and assignments added, the assignee (vendor or internal
resource) gets notified of the upcoming task. Figure 11 shows a snapshot of how Locban
board looks at end of planning phase. All tasks for a project’ sprint would be in TODO bucket
at the end of planning phase. Also, for some of the tasks, the team might not have complete
clarity. In which case, whatever best information is available is put in. The tasks undergo
progressive elaboration as the sprint progresses.

11. Figure 11: Locban board after sprint planning
b. Executing- During the sprint execution, the localization manager attends the daily scrum
meeting with the product engineering team to update the core team of the localization
progress, clear any impediments and get exact delivery dates as the due dates for feature
deliveries gets closer. Based on the inputs from the scrum meeting, the localization manager
updates the Locban board. He might adjust the dates for existing tasks, add new tasks as
they get discovered, remove some of them as they might not be required and then moves the
tasks from TODO to WIP state.
The assignees, internal team members and vendors, get notified of every change that
happens at a task level apart from a daily reminder email that goes out at the start of the day
giving them a summary of upcoming and current tasks. The assignees can always login to
Locban web based tool and view the status of the tasks assigned to them.
The assignees pull up their task from Locban board on designated start dates and once a
task is completed, change the status to DONE. If there are some comments, like daily status
updates to a task spread over couple of days, the same is added as a comment to the task.
Figure 12 shows a snapshot of Locban board during sprint execution.
Figure 12: Locban board during sprint execution
c. Monitoring and Closing- Using the information available from Locban board, the localization
manager monitors how many tasks have been completed and how many are still left. A visual
indicator (Figure 13) on each card comes up if the task is beyond its start date (in case state
is TODO) or beyond its due date (in case state is WIP) and provides visual alert to the
localization manager to take appropriate action.

12. Figure 13: Alert on a task past its due date
A backend script monitors each change to a task and tracks exactly when a task gets
completed. This information is extracted out to get a report of cycle time from initiation till
completion. The localization manager uses the cycle time information to monitor the
performance of different stakeholders against pre-defined SLAs, identify bottlenecks and work
on strategy to resolve them for the next sprint.
The spread out tasks across projects and sprints on Locban board also provide information of
work accomplished during each sprint without the need of going back into other sources to
get this information.
d. Closure- During the sprint closure, a sprint retrospective is held with all localization
stakeholders. With the empirical data from Locban board, the results are analysed and ways
to overcome current sprint’s impediments and improve upon the existing parameters for the
next sprint are discussed.
VIII.SUCCESS WITH LOCBAN
Although there is no publicly available metrics around measuring success with agile localization, we
have done statistical analysis of certain metrics pre and post Locban implementation and seen
considerable improvement in numbers. The comparison is not around waterfall and agile localization
but around agile localization with and without Locban. Some of them are listed below –
Metrics How was it measured?
Before
Locban
With
Locban
On time delivery Expressed as an average number of stories per
project per sprint that could not be completed for
all locales by localization team within that sprint.
0.8 0.2
Resource
utilization
Expressed as percentage of actual hours spent by
a resource against the hours that were planned
for him at start of sprint
62% 87%
Turnaround time Expressed as number of hours from receiving a
set of strings for translation (word count ~ 250) to
completing it in 31 locales
30 hours 12 hours
Customer
Satisfaction
Score
Expressed as an average of responses to 4
parameters (satisfaction with quality, satisfaction
with timely delivery, overall performance, ease of
working with) answered by product engineering
managers and product manager
7.5 8.5
Team
Satisfaction
Expressed as an average of responses to survey
questions answered by internal and external team
members
8 9.5
Most of these improvements have been as a result of following benefits that Locban brought to the
table –
a. Higher Transparency- resulting in increased collaboration amongst all stakeholders including
vendors.

13. b. Vendor empowerment- resulting in vendors having enough information to plan ahead and
take informed decisions.
c. Automatic tracking with a quick and easy snapshot of project tasks and statuses.
d. Auto- reminders and backend notifications saving the hassles of typing in emails every time
for a change.
e. Responsiveness to change because of easy adaption to changes in scope and schedule.
f. Performance tracking (tracking the time taken for each task) not only for localization manager
but also for each member of the team
IX. CONCLUSION
Locban adoption has helped the product’s localization team embrace agility. The benefits from an
online tool and process around it have immensely helped the localization team improve the value it
delivers.
The approaches observed with Locban’ adoption may be interesting patterns for other companies and
teams in similar situations to try out, and are shared below –
a. After Locban’ success with this product’s localization team, other teams in Adobe are trying to
adopt Locban for their localization processes. This pattern of starting with one team, fine-
tuning the processes and then raising the awareness, looks to be a reasonable approach for
other companies trying to adopt new agile localization practices.
b. Locban is one way of putting a visual cue for tasks assigned to stakeholders. Companies can
choose to use other similar tools; a large number of them are available publicly for free or with
paid subscription or create a custom one per their need. The idea is to represent your
localization tasks visually so that you can get benefits of transparency and collaboration.
c. No tool can be successful without a process around it. Locban is turning out to be helpful only
because it is integrated to how the scrum is used by core product engineering team.
d. Simplicity with any visual tool is important. You and your team members would slowly lose
interest if there is lot of information to be entered before a task can be created.
e. Giving access to team including external vendors would be a good idea. That ways, not only
localization manager avoids being a bottleneck for creation of tasks but this also reflects trust
and maturity in the team.
f. Although Locban has been tried and tested for localization, the concepts behind it can be
applied to any industry and practice.
X. REFERENCES
[1] http://www.localizationinstitute.com/switchboard.cfm?page=terminology
[2] https://blogs.adobe.com/globalization/globalization-myth-series-myth-4-it-takes-6-weeks-to-
localize-a-product/
[3] Anderson, David J., Kanban- Successful Evolutionary Change for Your Technology Business

14. XI. ABOUT AUTHOR
Amrit Pal Singh is Senior International Program Manager with Adobe Systems, Noida, and managing
localization of its key platform Adobe® Creative Cloud™. He holds a computer sciences engineering
degree from NIT, Kurukshetra and MBA degree from XLRI, Jamshedpur. He has about 10 years of IT
experience in various roles including program management, product management, technical
architecture and presales. Amrit's expertise lies in bringing innovative processes to manage projects,
especially those on agile methodology. He has spoken in international conferences including the
recently concluded Localization World in Singapore.