Agile started out as a novel way to build new products: widely adopted in the software industry and being seriously tried by others. Agile’s use impacts all of us who’s products have even a small software component to them. If Agile is new to you, troll a few of the Agile 101 videos on YouTube.
I’m not going to wax on about the team, roles, process, ceremonies, and such. Rather, I hope this helps you understand how the Agile process impacts translation and internationalization. I’ll start comparing the historical way translation has been done versus what the opportunities and challenges are if your organization is, has, or plans to embrace Agile translation.
The Traditional “Waterfall” Method vs the “Agile” Method
Traditionally, products emerged through the “waterfall” method. The product is envisioned and designed, specs written, team assembled, stuff built, an intense round of testing, then repairing, and finally documentation and translation. Initial releases are usually monolingual – developed in the principal language of the company – and internationalization, localization, and multi-language character set support were considerations for future releases.
About 20 years ago, Agile was hatched. Agile is based on embracing continuous change – product versions are released rapidly, with small incremental changes. Remember the early versions of Windows? Updates were few and far between, deeply tested, and slowly rolled out – sometimes a year elapsed between minor releases. Now we get Windows updates, silently, weekly – rapid release. Printed documentation has also gone the way of the dodo bird. In part, documentation had to shift from print to accommodate Agile’s rapid release – being impractical to print and ship documentation to users monthly.
Agile vs Waterfall Method
The Waterfall Methodology (traditional) vs. Agile Methodology (continuous).
What translators are experiencing is, instead of getting a final draft of content (user, service, or marketing documentation), they get a latest draft, possibly as often as every three weeks. Translated work is expected in days as opposed to what often would have been weeks, months if you include in-country review of translations.
The good news is, even though Agile doesn’t come close to specifically addressing rapid, iterative translation, there are core tenants of Agile that will help – ceremonies, specifically End of Sprint demonstrations.
What is a Sprint?
The development team sets a cadence for their work, called a “sprint”. It is a window of time to get some work done. Sprints are typically three weeks long, possibly two or four. At the beginning of a sprint, the team themselves choose the work they feel they can complete within the Sprint. At the end of each Sprint, the team formally demonstrates what they’ve accomplished (working features), ideally including a few customers. The Sprint demo is a useful (repeating) moment for the technical writers (and by extension the translators): they can use the demo to get started on their work for what was completed.
Modern Day Translation is Leaning Towards the Agile Method
Does translation effort really need to adjust? In my opinion, yes, you need to embrace this is going to be an ongoing collaborative effort, not a single undertaking. Translators need to connect with the people writing the documentation as it is being done and get invited to the Sprint demos. The goal is to be part of the team. To “see” what is coming and to translate in as quickly as possible without impacting quality.
To review, engineering has (or is) making a transition from a historical, waterfall way to something called Agile. Agile revolves around these small rapid releases, which, as I’ve noted, has had a big impact on translators, technical writers, localization, and even database schemas. – the people at the backend just before release. The shift is not an easy one.
What is a translator or Language Service Provider (LSP) to do? My experiences tell me, kind of in the following order…
- Use Translation Memory (TM) technology to your strategic advantage. Find services that use it, or deploy it yourself. TM, amongst other things, is a tool that a human translator uses during the translation process to conduct the localization. The TM ensures translations are consistent across projects.
- Your people need to be personalities that thrive on interaction. They are going to be involved, over a period, working directly (or nearly) with the development team. A closet recluse who was great at pure translation is going to find this difficult. Get people who are good multi-taskers and can juggle a few projects at a time.
- Scheduling will be odd at first. However, as time goes on, a rhythm will emerge. Your first thought on scheduling needs to be: “How soon can I get started?” rather than “When is the final draft available?”
- Have your translation team interact with your team members, even if only a little bit: they now are part of the team. Facilitate direct communications, not through a lead or handler, or a manager.
- Pricing is important to all, and with Agile, it is all about delivering value through service. Track, measure, and bill:
- Time the translation partner spends interacting and gathering content and time attending the team demos and the occasional standup. This is likely in 15-minute increments once or twice a week.
- Then there is the usual calculation for the cost per unique and leveraged words. This is where the Translation Memory comes in big.
- Lastly is status reporting. With Agile, progress is measured in a variety of ways, none of which includes percentage of work done – because the work won’t ever be done. Reporting needs to be open, less formal, and very transparent. The key is to report daily – whenever translation is blocked by something, anything, big or small, internal or external.
Consider your situation. The desired release schedule. Ask questions. How does your translation get done today? Is it done rapidly enough for the release schedule – could it be? How does the initial documentation get tested – which leads to how does the translation get tested? How connected are your translators to the development team – what tools do you use? Are you leveraging Translation Memory? How are versions of content and translation stored?
About the Author
Gordon Varney has been an Agile practitioner for 20+ years, is a certified Senior Scrum Master and Product Owner, has led Agile teams and transitions at seven software shops, and coached a number of other organizations. All of those organizations faced Agile-based translation challenges required for rapid releases.