We need to support 5 languages for our product. This means that in order to have a potentially shippable product we need to translate all text new to the Sprint to all these languages. It doesn't make sense to me because the text might change after a few Sprints during which the users will use the application and give feedback. So paying the translating company for translating text that will most likely change doesn't seem to be a wise decision. So what do you do with localization in Scrum?
Put simply this, like many process questions, comes down to a cost-benefit decision.
Quite a few of the practices described in the agile processes are about reducing the time spent in the "last mile" - this is an example of one of them.
Unlike practices with other aims (quality, correctness, etc), the practices aimed at ensuring you can release the product at any time have a net cost associated with them.
Ensuring that the product you are developing remains ready to release at all times has a cost that is not directly turned into benefit in the same way as ensuring it is at production quality.
I split those two aspects up as they have important differences. For example:
Ensuring a product is well tested and bug free at all times has a cost, but the benefit is reduced time to fix bugs as they are found, produce new features, and decreased chance of large scale rework after bugs are found to be fundamental. Almost all the time the tangible benefit will be greater than the tangible cost.
Ensuring a product is quick and simple to release has a cost but will will save you when you come to release, and the benefit is multiplied when you release frequently. The more often you release the more likely that the cost will be realised in savings. Again, the tangible benefit will generally be greater than the cost.
Ensuring a product is properly localised at all time has a cost, but will rarely result in a tangible cost benefit. This is particularly true when a third party is involved as a long standing and ongoing relationship with a third party will generally cost more (in time and cost) than short bursts of piece-work.
The question is, are there other benefits that you gain that makes the cost worthwhile?
In this case the biggest benefit is likely to be the ability to reduce time taken from release candidate to actual release - it comes back to the 'last mile'.
One way to think about it is as stock in a warehouse. Developing software is a way of building up stock - until that stock is on the shelves (the software is released) it does not generate revenue. In some scenarios it even drops in value as it sits on the shelf.
So one question you can ask is "How long can we put up with our stock being on the shelf without generating value?". For internal efficiency based systems this may be weeks, for innovative first-to-market products this might be hours. The shorter the time is, the more "ready for production" you need your software to be at all times.
Another question may be "How likely is it that our customer will decide at an arbitrary point to release the software?". That is, in sprint 3 of 6 they decide that they like the software so much that they want it straight away. If the situation is likely, how long will they be comfortable waiting?
Also, will seeing the software in its entirely localised state throw light onto questions that would otherwise remain unanswered? Does seeing a translated version of the site generally make the customer change direction, or help validate the current direction? Is there therefore value in seeing it earlier in your process?
Do you have other processes in the "last mile" that will hold you up longer? If the only thing you're waiting for in the last 2 weeks are the translations then you will generate a bigger benefit than if would still have to wait 2 weeks for infrastructure to be upgraded, senior stakeholders to sign work off, etc.
Why do you find you need to do re-translations? Is it because the requirements of the text change as the system develops - an inevitable consequence of change in the system. Or is it more that people are unwilling to commit to a body of text early in the process when they probably should be able to. Could continual translation focus their minds on ensuring correctness at all times?
Finally, how much extra will this all cost? Have you looked at the amount of re-translation will be required? What is the incremental cost of doing the translation piecemeal? If this is a cost-benefit decision, you need not only to clarify the benefits, but work out the tangible cost.
So, my advice would be:
- Work out the benefits in your particular situation.
- Work out the costs.
- Make the decision based on facts.
Who are the real customers (as opposed to beta users)? Do they expect fully translated text?
If the idea is to let the product bake for a few sprints to get feedback, then you can defer translation so that it is scheduled to arrive in time for final delivery. Otherwise, translate for every sprint; that way the work is "done". If it needs to be changed later, accept that as a cost. The point is not to reduce every single expense at every step; it is to reduce it overall, and make the process more sane and agile.
Further, if your text "will mostly like change" after a few sprints, maybe some effort can be put into choosing better text in the first place, if possible.
Apply the "potentially shippable" rule as far as it makes sense. Use your common sense where it doesn't. (Common sense is sometimes called "rule 0" in agile)
A team should avoid to commit work that is beyond their own power. Translations typically rely on translators outside the team. So the team shouldn't commit to that.
In short: put in your definition of done "Ready for translation".
And reserve some time before the release to complete those little items that are left out of the D.o.D.
For the agile purists (those that interpret it all too literally), that is indeed a tiny little bit of "waterfall". But it works.
Localization should be finished for every release. If you release once per sprint, localize once per sprint. If you release every 4 sprints, localize once every 4 sprints. Have a string freeze period before release where you do not make changes to the strings in the codebase so that your translators have time to update things.