What does it take to introduce, then implement an entirely new localization strategy at the “number 1 IT company in the world”?

This was the challenge that Cisco’s Internationalisation Architect and “Chief Localization Evangelist” Gary Lefman faced early 2015. He realized that nearly all of the development teams he worked with at Cisco had “gone agile”—they were all using the agile development methodology that is fast becoming the industry standard.

So, faced with this daunting task, Gary got to work.

The result? His version of the much-hyped “agile localization” philosophy. This new system is known as “continuous localization.”   

In 2 years’ time, Gary has not only successfully aligned Cisco’s localization strategy with their agile development process, but he has also developed a robust internal team of “champions” and documentation to educate the 25,000+ engineers working in Cisco about this more flexible way of localizing—which Gary believes is most effective via continuous delivery throughout the development cycle, not just at the end.

This week, we got the chance to chat with Gary to learn more about continuous localization and how he implemented it at Cisco. Our conversation covered:

• What “continuous localization” is and why it’s different than “agile localization”
• How to successfully implement continuous delivery
• The challenges and benefits of this approach
• What a localization team of any size or budget can do today to become “more agile”

About Gary Lefman

Developing a whole new localization strategy for a multinational company with hundreds of product teams is intimidating for anyone, but Gary’s not one to shy away from challenges.

After starting his career in network engineering, he stumbled upon the localization industry in 2002. Since then, Gary has become one of the leading industry experts for localization and internationalization (the process of making your code adaptable to different languages, regions, and cultures.) To date, he has supported the localization process at Cisco for around 500 products.

About Cisco

Cisco Systems, Inc. is the worldwide leader in networking for the Internet. Cisco’s Internet Protocol-based (IP) networking solutions are the foundation of the Internet and most corporate, education, and government networks around the world.

Now, let’s get started.

Here are our top 9 key takeaways from Gary on how continuous localization works, and how you can integrate it into your own localization workflows.

1. Gary’s role at Cisco is unique and focused on internationalization education.

3 years after Gary made the jump at Cisco from networks engineering to working in localization full-time, he realized he was repeatedly facing the same problems.

“I’d tell the development teams over and over again, ‘there’s this internationalization dev program, and here’s how to adapt your code.”

As the number of products he was in charge of grew, so did the number of these identical meetings. He approached one of his senior directors and explained the need for a permanent internationalization solution—or a single internal system—that all the dev teams could follow in localization.

The director appointed Gary to be the new Internationalization Architect at Cisco. “You can move away from localization projects,” Gary was told, “and focus on getting the internationalization problems fixed from Day 1.

[bctt tweet=”At its core, Gary’s job is “to change people’s mindsets.” ” username=”oneskyapp”]

“This means educating software engineering teams. Product managers, project managers, designers—everyone I’d have to influence about internationalization to make sure they get everything right before they start localization.”

2. “Continuous localization” is necessary for today’s agile development environment.

Gary recalls how he first approached the concept of “agile localization” with skepticism.

“Until 2014, agile localization was the hot topic in the industry. But I was very dubious,” Gary says. “As a software engineer, I knew it was not going to work for localization.” Localization is too different from normal software engineering that the approach would be irrelevant.

But Gary was seeing more and more software teams transition to agile around him and knew that localization needed to “keep up.” He began looking at what developers were using to become agile—powerful tools that allowed them to automate building and integrating their code.

But it wasn’t until he attended a conference in the summer of 2016 that he first heard about continuous delivery of localization.

The conference discussed continuous delivery of static web content and documentation, but Gary pushed the idea further, to consider a continuous localization system for software, which is “a lot more complex and involved.”

To start, Gary looked at tools like Jenkins, one of the automation engines used in continuous delivery, and other tools that work closely with it more on the translation and text side.

“I started asking myself, how can we use development tools for localization, and how can we integrate our localization process into the lifecycle of products being developed today?”

3. Continuous localization is not just a system, but a new way of thinking about the localization process.

[bctt tweet=”Continuous localization is more than just a system of workflows—it’s a new way of localizing.” username=”oneskyapp”]

The waterfall method is, for better or worse, how most of the world still runs their localization: after engineers are done coding a project, the localization part begins in bulk, often causing codes to break. Developers would find errors in internationalization that could have been avoided if localization had been introduced earlier.

What Gary proposes with continuous localization is using continuous integration tools to connect “continuous delivery” processes on both development and localization side. In other words, testing smaller “bundles” of localized code in more frequent intervals in parallel to the agile development “sprints.”

Here’s what a high-level continuous localization workflow looks like:

Educating people about this new system requires 4 key components:

• Everyone needs to be onboard

Transitioning your team to any new system requires a lot of help—especially if your “team” is 25,000 engineers spread over 500 products around the globe.

We asked Gary which functions own this move into continuous localization at Cisco. He says it’s “really everyone’s responsibility,” but the 2 people key to an effective transition are the localization engineer and the product manager. “These are the 2 primary roles who focus on making sure continuous localization is implemented, or at least considered.”

• Identify and keep in touch with “champions” of your cause

“Because I can’t handle 500 products by myself,” explains Gary, “it’s part of our strategy at Cisco to build a community of ‘internationalization champions’ internally.”

To do this, he identifies anyone “who is deeply passionate about internationalization” or understands it—people Gary can count on to help him spread the word.

These can be various technical leaders and program managers in different business units at Cisco. He meets with them, gets them up to speed about internationalization best practices, then encourages them to pass that knowledge onto their teams.

“This system is working out quite well. It’s a case of getting around, meeting these people, getting them to understand the purpose behind internationalization and the benefits of doing it right from Day 1.”

Right now, there are 38 “champions” at Cisco.

“It’d be nice to have hundreds,” laughs Gary, “but 38 is good because it covers the majority of our software groups.”

• Allow your “champions” to collaborate on an internal library of resources

To empower these champions to own the internationalization process, Gary suggests leveraging an internal platform to collaborate, communicate, and share resources. Gary’s own champions are connected on an internal social media platform based on one of the company’s own products.

“We have a global software community that’s built on best practices, standards, and part of that is our internationalization strategy documents.”

[bctt tweet=”The small community of champions use the site for collaboration, sharing ideas and updates, etc.” username=”oneskyapp”]

Gary says it’s been “really helpful” to be able to share resources, and it runs like a helpdesk. He’ll write an article for anything he believes will be a repeated problem. He then refers anyone with the problem to that document.

4. Localizing well—whether waterfall or continuous—requires both expertise and experience in order to stay “agile.”

This means prioritizing:

• Flexible workflows

Agile methodology enables engineering teams to be adaptable and continue moving forward with results. Similarly, Gary says that “there’s a number of things that need to happen in localization, but how we get there is flexible.”

[bctt tweet=”“There is no set way that we do things,” Gary explains. ” username=”oneskyapp”]

“Our workflows are adapted to each development team’s style of doing things.” They’re equally flexible with any company Cisco acquires, gradually bringing those teams into the standard way of localizing—which is “not very rigid either.”

• Collaboration with localization experts

Internal documentation helps get teams up to speed, but sometimes, you need to bring in the experts—especially when it comes to something as specialized as localization.

For example, a common localization task is to ensure your code supports bidirectional locales (i.e. for languages like Arabic.) To do it well is “very much a gut feeling, a visual thing,” says Gary. “It’s not something that can be tested using tools that look at it in its static form, as a source code.”

For situations like these, Gary advises bringing someone in who has experience in bidirectional locales to look at the code in order to get it to run.

• Effective timing that benefits all teams

Ideally, this collaboration between a localization expert and the engineering team would take place after the user interface has already been designed—”before any code is written.”

That’s usually the point Gary jumps onto a project and guides the team through the requirements. “We can look at the design together,” he says, “and see how the team would need to adjust their programming style to meet the requirements for internationalization.”

From that point on, Gary will “hold the team’s hands for a while” and check up on them occasionally as the project moves ahead. The teams themselves still do the bulk of the work, but having Gary and other experts’ oversight ensures they don’t veer off course by accident.

5. Understand engineers’ pain points.

Gary received plenty of pushback about localization from development teams facing the internationalization process, even before he introduced continuous localization. He says the top pain points are 1) a bad preconception of localization from past experiences and 2) the time pressure in agile development itself.

Before dev teams switched to agile, the localization process would come at the end of a project, as per the traditional waterfall approach. “All these internationalization problems would be found, and all hell breaks lose” right before they wanted to go live.

“Everyone panics,” says Gary. “It’s chaos.”

This created negative feelings among software developers about localization, but this is less of the case now as localization education has improved.

The 2nd concern is that because agile teams are on tighter time pressures to quickly iterate, they don’t have much time to do any extra work.

The localization team will usually make a decision with each team whether or not to push for internationalization right away.

“We can’t force the internationalization onto them,” explains Gary, “because that will break our relationship with the developer teams. Instead, we’d plan to have it inserted at a later date.”

6. Focus on education-based solutions.

[bctt tweet=”Developers are rightfully protective of their code.” “username=”oneskyapp”]

“And they don’t want to break what they might have spent months, maybe years building,” says Gary.

“If we say, ‘this new project you’ve just started has to be internationalized fully at the same time as developing all your features,’ the PM might just say, ‘no, I won’t do it. You’re going to wait for internationalization after we’ve produced our first release. And we’ll see how it goes after that.’”

Education is a key part of providing solutions that match the teams’ particular issues, according to Gary.

For example, a lot of developers are “instinctively afraid” of coding support for bidirectional locales, the scenario we gave earlier. They’ve never seen everything being mirrored, so they panic. In this case, Gary tells them about how the basic code will do most of the work for them, and walks them through the technical details.

“The educational part upfront helps developers relax and realize it’s not such a big deal to support bidirectional locales.”

7. Continuous localization does cost more but contributes to customer success.

Yes, as you might have guessed already, continuous localization is going to be more expensive.

“Having to translate these tiny little packages, 10 words at a time, we definitely lose out on cost.” explains Gary. “We may end up paying 50% more overall.”

However, what this process allows them to do is get localized products out to customers every week instead of every quarter, which is what Cisco did in the past.

[bctt tweet=”“Our customers are happier buying our products.” ” username=”oneskyapp”]

“We think of it as the cost upfront to gain their trust,” says Gary.

The added bonus is that development teams can also test and prove their internationalization at a faster rate, finding defects in their code much faster than before.

8. Continuous localization can be implemented with limited budget and time.

We asked Gary for his advice to smaller teams interested in trying out continuous localization, and this is what he proposed: take out a piece of paper, draw a line down the middle of the page. On one side, write down all the tools and processes that the development team already has in place today—“just a simple flow chart from A to Z of what takes place.” On the other side, write the same list, but for localization.

Now, draw a line around the elements that are similar between development and localization, and try to see if you can integrate those processes.

[bctt tweet=”“Integrations are the key point to continuous localization,” emphasizes Gary.” username=”oneskyapp”]

“You need to have tools that talk to each other.” He suggests to start making small changes by looking into open source tools or adapters that can get you there.

Here’s Gary’s example of a localization workflow using integratable tools:

9. Continuous localization will only become more relevant and powerful in the future.

So far, people are responding positively to continuous localization.

“People are getting the message,” says Gary. “Dev teams are starting to think about how to accommodate localization from the beginning, and localization teams are thinking about how they can help developers localize right from the start. It’s like a symbiosis between the teams.”

These positive effects are far-reaching beyond the teams themselves.

As Gary explains, “continuous localization improves the quality of the source code and the locales, and ultimately, customers win. Everybody wins as a result from one simple action at the beginning.”

Gary is hopeful for the future of continuous localization. He wants to see technology being developed that products can be “churned out with localization at the blink of an eye” so that we can have “nearly-instantaneous localization.”

As for the end goal?

“Getting instant translations into the product and out to customers, almost as soon as it’s written. If we can achieve that, it would be the biggest win ever.”

Summary

Here are Gary Lefman’s 9 takeaways for successfully implementing continuous localization:

1. Gary’s role at Cisco is unique and focused on internationalization education.
2. Continuous localization is necessary for today’s agile dev environment.
3. Continuous localization is not just a system, but a new way of thinking about localization.
4. Localizing well—whether waterfall or continuous—requires both expertise and experience in order to stay “agile.”
5. Understand engineers’ pain points.
6. Focus on education-based solutions.
7. Continuous localization does cost more but contributes to customer success.
8. Continuous localization can be implemented with limited budget and time.
9. Continuous localization will only become more relevant and powerful in the future.

Over To You

Want to learn how to localize your app or website? Head over to our OneSky Localization Academy for a full walk-through and sample code to get you started.

Are you interested in improving your team’s translation quality? Check out our free ebook: The Project Manager’s Guide to Improving Localization Quality: