How to stop translation from delaying your software delivery

Your users in all countries are just dying to use your new feature that you just developed. Or this nasty bug that has been making the helpdesk overflow for the last few days and that you finally got your head around needs to get out there as soon as possible!?

Thank God you’ve optimized your development cycle so well that you can deploy every week, or even every day. This is going to be easy! Let’s get it out there!?

Oh, wait a minute. There’s still that translation that needs to be done. If we’re lucky, this is gonna take at least another two days. And if we’re unlucky, the batch has just been sent to the agency, and we have to wait for the next round to get our translations.?

In most companies, translation is delaying your release every single deployment cycle. In most cases this seems tolerable, although you sometimes wonder what would happen with your customer satisfaction, churn rate and sales if you could deploy sooner. And it is often hard to quantify the opportunity costs of the delay of actually bringing your feature to the market, in such a way that you can feel the urgency to reduce the cycle time of the translation phase.?

But in some cases it is very easy to see that this delay is costing your company a lot of money.?

Most companies think this is just the way it is. They believe that the fact that you are creating a product in multiple languages is inherently making everything slow and costly.?

I’m happy to tell you: it doesn’t have to be this way!?

Your challenge: How to embed translation in the development cycle?

Although more and more development teams are experiencing that translations are indeed in the critical path, they fail to embed translation in their process. In practice, translations are usually done in a waterfall way. And just like in development this leads to the problems described above.?

The big question companies have is: how do we do this? How do we embed translation in the development cycle? My content is usually not finalized until close to the end of a Sprint!

They are not aware of the solutions that Lean Localization provides that easily solves this problem. If they can adopt the Lean Localization mindset, the solution is obvious.?

Applying the Lean Localization Model

Applying the Lean Localization Model, you will experience the following benefits

1. Reduced cycle time of your deploys
2. Less rework to implement translations?
3. No more back and forths between translation department/translators and developers
4. More engaged translators and therefore optimal translations

So, how to get to this point?

The first step is to realize that your story is not done until all content is written and translated. This is not a separate process, your product is multilingual, and the Definition of Done should respect this. And the reported cycle time must also include the translation phase.

For most developers, this is a major mind shift - and an essential one. Once they are aware this is also their responsibility, they will be open to ways to make this work. As long as they feel this is someone else's problem (e.g. the translation department), the necessary adjustments will be hard to implement.

Once everyone embraces this fact of life, there are two key points to embedding translation in the development cycle:

1. Obey the structure: one piece flow
2. Minimize the cost of change

Obey the structure: one piece flow

Often, all content that is created in a sprint is sent to the translation department/vendor in one batch. Actually, it also happens quite often that all content of a sprint is only written and finalized at the end of a sprint - or even afterwards.

But this does not obey the way that your feature, that contains this content, is actually created. Usually, a sprint consists of a number of stories that are going through a number of steps before they’re considered “done”.?

The trick then, is to make sure that within a sprint, you are never batching content creation or translation. You want each story to be delivered in sequence, so there is no accumulation of work in any process step.?

This way, the developers, the UX writers and the translators are working in the same structure, and they are part of the same process. They will deliver translations during the sprint, for each story and they will understand what they’re writing/translating.?

This way, you can have all translations ready during code review, and make sure that developers have created something that works in all languages. Or even make that check earlier on in the process.?

You will be able to deliver all languages at the same time and not experience any delay in the process.?

Minimize the cost of change

Now, because people tend to make changes to content as long as it's not published, it is a good idea to make sure you can make changes quickly if the source content changes. This makes it a lot less scary to send out translations before your sprint is done, because any small change can be made at any time.?

For this you will need your processes and infrastructure to support this. Integration from your source of truth to translation tools and smart update processes are crucial to make this actually work. If you are working with files, this is great to begin with and to really understand the process, but before you start becoming too sophisticated when to send out translations, do yourself a favor and get rid of them as soon as you can.

Working this way will make you more flexible where translation comes your development process?

The proof is in the pudding

These principles work for all content/translation processes, whether it is marketing content or software development. You can read more about this approach in this case study, where I explain how this approach for a highly complex website has shown an improvement of the cycle time of about 50%, completely removed the developer from any interference in the translation stage and made us decide we needed no more review because the translations were perfect.?

Conclusion

Integrating translation in your development cycle does take some adjustments for everyone. The key to this is that everybody understands that they are building a multilingual product, and takes ownership over the entire process, including creating the language versions.?

Working in one piece flow is an amazing way to optimize your development process, and make it truly scalable. Of course, it’s not done overnight. But with the right approach and a strong belief that this is the way to go, you can improve your cycle time continuously.?

How to become a Lean Localization Company

Does this sound like what you need and do you need a helping hand in the implementation of Lean Localization? There are numerous ways that I can help you become a company where localization does not delay the delivery of your software product. I offer trainings, coaching and Build-Operate-Transfer programs. Feel free to reach out and book a call.

Check out my website for more info

Localization can be your competitive advantage!