7 reasons why working with Agile methodologies will help our localization strategy

Today we live in a world where everything goes super fast.  We want everything faster, better and we want it now! We can order something in Amazon and we can receive it in a few hours.  Faster, better, cheaper are the words that come to mind when I think of our consumer behavior today.

And what does it mean for our industry? for Localization?

It means also faster, better and I guess cheaper. This concept brings me to the topic of my weekly post. Localization teams all over the world are adopting Agile methodologies to respond to a hyper connected fast world and the demands from it. 

At first we may think that continuous localization works against us because we have to have everything ready, and we have to have it with a quality that is good enough.

But what if we could turn the tables and see the positive side of this continuous trickle of requests? 

In my opinion Agile Localization and the introduction of localization sprints can become a good thing for Localization teams.

In the following paragraphs, I will summarise why sprints can be better for a Localization team than it seems at first sight.

Find below my 7 favourite reasons about why sprints are good for Localization teams.

1.   Scheduling. We know when we will receive Localization requests! Yay! Sometimes when I talk to other colleagues in the industry, there’s a misconception that Agile means chaos, that we might get a localization request at any minute. Occasionally that happens, but less than I personally expected. We can set up a framework to receive localization requests same day in the same time slot. The frequency is up to the stakeholders. They decide that, and we adapt to their decision. Some feel ok with a weekly handoff, while others need a higher frequency, which is ok ….. Having this framework and agreement with development teams allows us to book translators easily because we know when we’ll receive some content to localize. Agile, in this sense, has helped to deal with this uncertainty in an excellent way. We know when we’ll receive Localization requests, and we can allocate resources for these requests.

Of course, there will still be some situations with last-minute requests and last-minute changes (please check HERE my post about how to handle these requests) but what I found is that the number of requests is not as high as I might expect. This has helped me enormously to have fewer bottlenecks and a regular team of translators (which is crucial to be consistent in style)

2.   Know-how. When we know that we’ll be working on a new project for a few months and will get requests every week, we feel confident that we will learn how to use the tools needed; and understand the processes. And the reason why we feel so confident is that we are going to use them every week.

In Agile is not expected to be everything perfect in each sprint. The concept of MVP is quite popular, and this means that if I don’t know all the processes or all the steps this week is fine! Because I can keep polishing my skills and know-how this week, and the week after …and the week after. I’m in a continuous learning process, and this is great to improve my learning curve. In the past, following the traditional waterfall approach, I used to feel overwhelmed by the amount of info I needed to process at the beginning of the projects. And sometimes, that info was, in the end, not useful at all. It was related to requirements that were not finally implemented, but since it was in the initial planning, I had to deal with them anyway, and I had to learn about them as if they were real. In Agile, this does not happen. I just need to learn what it’ll be released.

3.   Continuous Localization Testing. When you work in Localization Sprints, if a bug is missed, if a typo is there, or a wrong term is used …. this is not the end of the world! We just fixed the mistake, and if it was a serious bug, we just submit a hotfix to the Appstore/PlayStore … and if it’s a bug but not that urgent …in that case, we can wait until the next build submission, and the bug will be solved. For me, this is priceless. In the past, I was always concerned about missing bugs or missing localization issues. I’m not exaggerating if I tell you that I had dreams of someone coming to me to ask me why we missed that bug …. It’s not that I’m not concerned anymore, but I know that if we miss a bug for whatever reason, there will be a new sprint soon that will give us the chance to fix it.

4.   We increase the feeling of being part of THE TEAM. This is quite important for me because working in sprint mode gives us plenty of opportunities to interact with other team members in dev teams or support functions.

This helps enormously to build trust and create a wider network. Having Localization present in the sprint planning meetings, it’s a great way to make feel localization team part of the company strategy.

 Agile provides multiple opportunities for stakeholder and team engagement. We can do it before (planning), during (execution), and after each sprint (retrospectives). Delivering localization pieces early and frequently increases stakeholders’ trust in the Localization team's ability to contribute to the project's success. It allows everyone to be more deeply connected in the project and during longer phases. In waterfall, there was a disconnection at some phases … but here, every new sprint is a new opportunity to keep increasing this feeling of being part of THE TEAM.

5.   We get localization feedback throughout the lifecycle. What happens if we have to translate the tutorial of a game and realize through our analytics and surveys that our players don’t understand the instructions? It might be that the English copy is not clear, it might be that the Localization in a specific language is not clear …. or it might be that the design of the game mode is not clear! Whatever the reason is ... no dramas here! In the next sprint, we can fix it!! We can write a clear English copy, or we can meet to brief our translators to ensure they understand the functionality they are translating in that tutorial … Sprints give us Localization teams many opportunities for continuous improvements

6.   Style guide and glossary creation. Sprints are great opportunities to build a termbase to collect key terms and recommend changes to source content. It also enables Localization team to define the style to be used during the translation phase. I’m so happy to use the first sprint cycles towards creating comprehensive and accurate glossary and style guide documents ….

7. Risk Management facilitation. What if we start working with a translator and the quality is not what we expected? Every sprint will allow us to work with localization partners to align expectations. We can give feedback about parts of the project that are not going as we expected. We can work together to sync expectations … and eventually, if this sync and alignment are not working, we can switch vendors. We can do this before all the content is translated … because we know that every sprint .... we will have new content to translate. Therefore, from a risk management perspective, sprints are very handy to ensure that we are getting the service we expect with our partners.

Summary

Working in Agile Localization mode with less volume and less time to deal with the content we have to translate at the beginning is a bit dizzying. Still, the model we operate today is more effective than the outdated waterfall style where the chances of Localization being an afterthought were higher.

Working surrounded by Agile teams allows our industry professionals to be involved from the ideation phase through to the release phase, where new content comes out every month.

Have a great day!

@yolocalizo