Lost in Translation

A colleague recently described the requirements process in his (non-Agile) organization to me. In their process, the business people talk to the business analysts who talk to the systems analysts who give requirements to the programmers.

As he was explaining all this, I couldn’t help but reflect on all the possible points of failure.

I’ve seen conversations around requirements go horribly astray with just two people: a business person specifying what they want, and a developer who is supposed to implement it. How much more likely must misunderstandings be when requirements are coming from people who are multiple levels of indirection removed from the originators of the requirements?

The first thing that came to my mind is the Telephone Game. In case you’ve never played it, in the Telephone Game, one person thinks up a story, then whispers it to the next person. That next person whispers it down the line to the next person. And so on. Eventually when the story reaches the end of the line, the last person tells the story as they heard it to the whole group, usually with much laughter as the group hears how the story evolved through many successive tellings.

But then it occurred to me that this is less like the Telephone Game and more like a succession of translations. The business person tells a story in BizSpeak to the Business Analyst who interprets it and retells it in BA-Speak (perhaps in terms of “Must,” “Should,” and “May” functional requirements) to the Systems Analyst who retells it in SysSpeak (perhaps UML Use Cases and/or Sequence Diagrams) to the Programmer who must translate it into TechSpeak (maybe State Models, Class Diagrams, and ERDs) and then code. The languages may have some commonalities, but they have a lot of differences too.

And that made me wonder what would happen if I played the game with the Google translator.

So I picked an innocuous sentence out of one of my blog posts, and translated it from English to German, then to French, then to Italian, then to Spanish, and then back to English. Here’s the result.

English: Agile means delivering business value frequently and consistently while adapting to changing business needs.

to German: Agile Business Wert bedeutet, liefern häufig und konsequent, während die Anpassung an sich wandelnde Bedürfnisse.

to French: Agile Business valeur signifie, et fournissent souvent de cohérence, tandis que l’adaptation à l’évolution des besoins.

to Italian: Agile Business valore significa, e spesso prevedono la coerenza, mentre l’adeguamento alle mutevoli esigenze.

to Spanish: Agilidad de negocios de valor medio y, a menudo, la coherencia, mientras que la adaptación a las necesidades cambiantes.

back to English: Agility and business value, often, the coherence, while adapting to changing needs.

Hmmm. Something got lost in translation.

Now, I wondered, what would happen if I chose more radically different languages?

English: Agile means delivering business value frequently and consistently while adapting to changing business needs.

to Indonesian: Tangkas berarti memberikan nilai bisnis yang sering dan konsisten sementara beradaptasi dengan perubahan kebutuhan bisnis.

to Hungarian: Fleet átlagos üzleti és következetes, alkalmazkodva a változó üzleti igényekhez.

to Dutch: Gemiddelde vloot en samenhangende activiteiten, aanpassing aan de veranderende zakelijke behoeften.

to Finnish: Keskimääräiset laivaston ja siihen liittyvää toimintaa, mukauttaa muuttuviin liiketoiminnan tarpeisiin.

back to English: Average fleet and related activities, to adapt to changing business needs.

(Hmmm. This makes me wonder whether “average fleet” is one example of a set of related activities, or whether one needs to average “fleet and related activities.”)

In any case, perhaps the lesson here is that the farther apart the languages are, the more gets lost in translation. And perhaps that points firmly toward the need for a ubiquitous language, as Eric Evans and the Domain-Driven Design community describe it, across the business stakeholders and the implementation team.

Or perhaps it’s just further evidence that it’s amazing that any software ever does anything useful. (Truly, given how many ways things can go wrong when developing software, I’m often astounded that anything ever works.)

But going back to the original story that prompted this post, where the business people talk to the business analysts who talk to the systems analysts who give requirements to the programmers: I think this simple example in natural language illustrates the risk of having multiple levels of indirection between the business stakeholders and the technical team.

This is why close collaboration between the Product Owner and the implementation team is so important in Agile. Otherwise, the real meaning and intent of the requirements will be lost in translation, and perhaps all the business value as well.

Subscribe

Subscribe to our e-mail newsletter to receive updates.

10 Responses to Lost in Translation

  1. Chris Morris March 30, 2009 at 11:34 am #

    Some thoughts I’d already been sketching out that play off your post here: http://www.clabs.org/blogki/blogki.cgi?page=/ComputersAndTechnology/ComputersAreNotPeople

  2. Tyson March 30, 2009 at 12:00 pm #

    Good article. There’s a site that automates your translation experiment called “Lost in Translation”:
    http://tashian.com/multibabel/

    This is a problem in a lot of environments, not just software: sheet music never perfectly captures how the music should be played, books on martial arts can never replace learning from a master, etc. But that doesn’t mean that sheet music, martial arts books, or software requirements documentation have no value. It just means that they have limitations, and can be very useful if those limitations are taken into account.

  3. Paul King March 30, 2009 at 1:02 pm #

    There is an old story about translation machines during the cold war era. “Out of sight, out of mind” was converted to Russia and back to yield “Blind idiot!”. Don’t know if it is part urban myth or real.

  4. Eric Pugh March 30, 2009 at 2:36 pm #

    I’ve often thought the process of converting requirements to code, to verifying with tests is similar to the process of drawing called “cadavre exquis” (http://en.wikipedia.org/wiki/Exquisite_corpse). Translation, whether from person to person or language to language is hard!

  5. Lisa Crispin March 30, 2009 at 3:26 pm #

    My team has found that it’s not enough to collaborate closely with the product owner. Yes, his job is to get consensus from the different customers about the value each story should provide. However, just like your example, things get lost in the translation. We have learned that we must:
    1. Learn all aspects of the business ourselves, inside and out. This is hard, but it allows us to understand what the customers need.
    2. Talk directly to the people who will be using the functionality, not only the PO, while always keeping the PO in the loop.

    Here’s a recent example. Our accountant needed a .csv file with information to cut a check. The PO talked to her and gave us the columns to include in the file. The pgmr and I went and talked to her directly, and she said, “Oh no, I don’t need columns C and J, but I need these other columns X and Y.” The PO was surprised, but for whatever reason, he did not provide us the correct information.

    Accounting is the area of the business where we’re all weak. We’ve learned the hard way – everyone involved in delivering an accounting story needs to talk directly to the accountant, and ask good questions.

    (And even after we released the new .csv file, she thought of one more column she needed!)

  6. Matthew Farwell March 31, 2009 at 12:52 am #

    Good article. It basically comes down to:

    You lose some information when you communicate. The more steps you go through, the more information you lose.

  7. Antony Marcano March 31, 2009 at 11:27 pm #

    Nice post Elisabeth. I especially like your translator illustration… nice.

    I also drew a similar comparison to the telephone game a while ago…

    “So on projects that derive tests (or examples of anticipated usage in the real world) from a generalizing specification (or model) that was itself derived from examples of anticipated real-world usage… is at best verification against the abstraction and at worst the software development equivalent of the ‘Telephone Game’.”
    -http://www.testingreflections.com/node/view/7232

    I think it’s more than just things getting lost in the translation… because the translations aren’t literal. It’s that different people will take away different understandings and then approximate that understanding in a different language – compounding the problem.

    I’ve also found that any collaboration is a good start, but it’s the nature of the collaboration that is important. Active involvement of the customer, evolution of a ubiquitous language and using examples (represented as automated tests) as a focal point of discussion makes a huge difference. These combine to increase the detail that we get from the business and the accuracy of what we deliver to the customer in comparison to what they thought they’d asked for.

  8. Sergey April 3, 2009 at 12:33 am #

    “I’ve seen conversations around requirements go horribly astray with just two people: a business person specifying what they want, and a developer who is supposed to implement it. How much more likely must misunderstandings be when requirements are coming from people who are multiple levels of indirection removed from the originators of the requirements?”

    Elisabeth, developer should not only implement something, but prepare documents. Not just for himself, but for other business peoples who will use implemented, for QAs, for other developers, etc, etc. And this is really another story. Developers just can’t write documents.


    Elisabeth responds:

    Hi Sergey – I don’t think documents solve the problem. In many cases, trusting documents to convey critical information exacerbates the problem because the written word is such a narrow communication channel. There’s just no substitute for direct face-to-face communication.

  9. Hillary Johnson April 3, 2009 at 10:56 am #

    Brilliant. Between two individuals, active listening is one solution to the communication problem–to be thought of as unit testing for humans, maybe?–but it will always be true that the longer the pathway, the greater the signal degradation. In the end, no amount of error correction matters if you’re simply talking to the wrong person.

  10. Amber Shah April 3, 2009 at 3:37 pm #

    Great post. I definitely appreciate your move from the telephone game to language translations, because it’s definitely more appropriate and has a bigger effect. This reminds of this picture that I found awhile ago: http://onproductmanagement.files.wordpress.com/2007/07/treecomicbig.jpg