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

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.

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.

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

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.

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 –

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.

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

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.

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.

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.

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

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.