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.