Over the last years, a few Agile direct clients have found their way into my life. None of them mentioned the Agile approach upfront. Each just started sending me work and left me to discover what was going on. This is what I found they have in common:

1. The translation team is small.

Before Agile, a project (think a new version of a database system or productivity suite) easily involved a few dozen translators and related professionals over a few months. Now, over an unlimited time, there are one or a few freelancers per language. On the client side, one or a few “translation coordinators” (with various job titles) manage all these languages.

All members of this tiny team are experienced, multi-talented people. They share some of the traditional roles between them, especially those of technical lead and terminology manager. Some clients also leave proofreading and/or localization testing to the translation team, others do them in-house. The coordinator is in charge of all management tasks traditionally offered by translation companies, and in fact many coordinators have started out as project managers in the localization industry.

2. Everyone is invited to say what they think.

The notion of “overstepping one’s authority” seems to be unheard of. As a translator, I’m delighted that my competence is recognized and that the coordinator is listening closely to my input. For the client, this approach clearlys pays off: translators are the first to see new pieces of user interface or text, and they are the most diligent readers imaginable, trained to find bugs and bumps in language and content.

3. Continuity is key.

Working in small installments – typically from a few words to a few thousand words – means that a permanent team is important. Permanent members get to know the product in depth as it is developed, while fluctuating members would have to learn about the entire product to translate a tiny part of it.

Moreover, we can no longer check the entire product for consistent terminology (or style) in one go, as we used to do at the end of traditional large projects. Therefore, great TM and terminology management and a log of style decisions are crucial. The coordinator uses a CAT tool that enables them to do this centrally, unlike traditional translation clients who often just send their files ‘as is’ and let their translation vendor do the rest.

4. The role and personality of the coordinator(s) are very important.

They do not need to know all languages, but they do need to know the product and the needs of translators. In each iteration, the coordinator makes the new features and their context visible for the translators, often through screenshots, explanations or navigation steps. Most Agile iterations require translation of several small disparate units. Without context, this would be error-prone, especially for very short strings („noun or verb? Button, heading or CTA?“), or inconsistent („adding one item to a bullet list on a webpage, what does the rest of the list say?“). This context information is the same for all languages, so carefully preparing it upfront saves time and redundant questions from several language translators. When translators do ask questions, the answers are shared with all languages through email or through a common “query doc” online.

Translators do not usually need to interact with each other directly. This means that the translation team itself is not a Scrum team or similar. Rather, it is a virtual member of an agile development team via the coordinator as its proxy. This enables translators to give feedback to developers, mostly on translatability obstacles such as split strings that do not work with language-specific word order, or local concepts such as ACH bank transfers that need to be adapted to target markets.

Ideally, the coordinator also liaises with other teams in the company that produce text, such as marketing teams in different countries, to gather and unify terminology and style. This does not yet seem feasible in most bigger companies, where workflows are still “siloed”. Ideally, the same pool of linguists would be involved in all (translated and original) linguistic output to unify the voice of the company, from UI and help text to customer communications and marketing material.

5. Agile “snippets” create more overhead than the old localization of entire releases.

In traditional workflows, the translation team methodically worked through the entire software (or website etc.). In Agile, the coordinator needs to visualize every new or updated feature for translators, and translators often have to read an entire screenshot or feature description to translate a few words.

This is not the only way Agile iterations mean a loss of economies at scale. For instance, I’m more likely to forget a word between iterations than during a large, compact project, so I’ll look it up in the TM or glossary far more often. Also, several short tasks from different clients in one workday cause psychological “context-switch costs”.

The overhead decreases with the duration of the cooperation and the increasing familiarity with the product, but it can never be avoided altogether. On the plus side, the excruciating monotony of long repetitive texts is no longer an issue.

6. The additional overhead is outweighed by the advantages.

Some of these advantages are manifestly economic ones. While the job of language coordinator needs to be created, and translators generally need to be top-notch and to spend more time per source word, all traditional “middle men” between the company and its freelancers are gone.

No time, information and budget are lost to a chain of command. A multi-level hierarchie made sense when huge wordcounts had to be distributed to large contractors, their subcontractors and in turn their freelancers, but it is dispensable in Agile.

Moreover, avoiding “middle men” also avoids anonymity, and I’m convinced that this again results in tangible advantages.

For one thing, anonymity seems to favour aggression. Every translator can tell tales of inexperienced (end) clients who make amateurish changes to a translation and go out of their way to add condescending remarks. Such reviewers do not feel that there is a human being on the other end, and certainly not one they could simply ask why a phrase has been translated the way it is.

Conversely, twenty years ago, an American client told the translation company that was then my employer to “cut down on the typical German snark in queries and bug reports”. I don’t think they realized how deep-seated this snark is – I know it is, because I’m still unlearning it by mirroring each translation coordinator’s tone.

Even without aggression, anonymity does not make for a good relationship. A few years ago, I built up a successful feedback loop with a client reviewer through an agency, but communication was still awkward: while I knew his name from metadata and found his online profile, I could not reveal my name or even my (grammatical) gender to him due to the agency’s NDA. I still wish I could tell him I stopped working with the agency because it kept trying to force increasingly inacceptable conditions on me. All he knows is that I disappeared from the face of the earth at the end of one of our friendly and slightly grotesque exchanges.

In direct contact with a translation coordinator, such things simply do not happen.

Of course, I have had pleasant and constructive business relationships before Agile, but Agile interaction and feedback have their own distinctive quality. It has taken me a while to open up to this much communication, because I was not expecting it. I knew that Agile is about changes in (business) culture, but I’m still surprised that the changes are so personal.

7. The quality of the collaboration is one of my core KPIs.

Of course, translator KPIs are word rates, word count per day, or (less measurable) text difficulty. Yet, what has motivated me to go from IT to translation and from employee to freelancer, was ultimately how comfortable I felt with it. I’m not selling commodities or other people’s time, I’m selling my own time and, even as a technical translator, a part of myself. I can see how quality of life translates into economic success.