This Month’s Pattern *

73 Babel

The project fails to develop a consistent language that’s understood by all members of the development team and stakeholder community.

We expect to be understood—and most of the time, that’s a pretty safe assumption. When the people we are talking to share our contextual and cultural space, our meaning is usually communicated without distortion. In an English pub, when you ask for a pint, you get a pint of ale. Ask the driver of an electric dairy car in London for the same thing, and you’ll get a bottle of milk. Similarly, when you are talking to a co-located fellow team member about the network status or the customer discount rate or any other term you use in your project, you expect to have a shared understanding of the meaning.

It is this optimistic expectation of being understood that prevents you from asking, “Does he really mean the same thing I do? Are we simultaneously nodding yet speaking different languages?”

Babel is encouraged by the fiction that organizations have a common language and that as long as every project uses this language, all will be well. But organizations are large, dynamic, inconsistent creatures, and terms like service, order, asset, policy, customer, employee, and discount have very different meanings, depending on their context of use within a project. Rather than rely on the wishy-washy generalities of org-speak, every project needs to define its own common language. The degree of formality and rigor required depends on the likelihood and seriousness of the risk of being misunderstood, with loss of human life at one end of the scale and minor financial loss or irritation at the other.

The risk is increased by any of the factors relating to differences between individuals, such as domain knowledge, life experience, linguistic background, or personality traits. The list becomes longer when you consider other influences, such as geographical separation, assignment to parallel projects, and outsourcing to other organizations. Many organizations grow through acquisitions, and each acquired company has its own idiosyncratic language that may have to be decoded and normalized by the new parent company.

The language you need for your project is a living language that truly reflects what all the team members are learning about the problem space. Cultivating the language means progressively defining your terminology in writing, to reflect your growing understanding. This also means making those terms easily accessible and extendable by everyone on the team.

When a team does develop a consistent language, the effort may be almost invisible from the outside. But inside the project, the participants are willing to focus attentively and repeatedly—almost obsessively—on definitions. The successful team is the one that does not accept the fiction that there is already an organizational common language. It is willing to refine and refine again in order to build its language, the one that will protect the project from Babel.

* Each month we plan to publish here one of the patterns from our Jolt Award book, Adrenaline Junkies and Template Zombies — Understanding Patterns of Project Behavior. (Watch this space for a mere 86 months and you'll have read the whole thing.) The book is published by Dorset House Publishing, in the US and Hanser Verlag in Germany. It is available at Amazon and also as a Kindle book.


Hilversum, Mastering the Requirements Process
8-Nov-2016 to 10-Nov-2016

James Archer teaches Mastering the Requirements Process. For details please contact Adept Events. Dutch description, or in English.

London, Mastering the Requirements Process
15-Nov-2016 to 17-Nov-2016

James Archer teaches Mastering the Requirements Process. For details and registration, please contact IRM UK.

Wellington, Mastering the Requirements Process
22-Nov-2016 to 24-Nov-2016

The ever popular Mastering the Requirements Process. For details please contact Software Education.  

Canberra, Mastering the Requirements Process
28-Nov-2016 to 30-Nov-2016

Mastering the Requirements Process. Please contact Software Education  for details and registration. 

Melbourne, Mastering the Requirements Process
28-Nov-2016 to 30-Nov-2016

Suzanne Robertson presents Mastering the Requirements Process. Please contact Software Education  for details and registration. 

Sydney, Mastering the Requirements Process
5-Dec-2016 to 7-Dec-2016

Suzanne Robertson teaches the popular Mastering the Requirements Process sponsored by Software Education.

in depth

A Ruby Beam of Light, Book I of Tom DeMarco's Andronescu's Paradox saga is now available in English in paperback and ebook, from Double Dragon Publishing.

"This war isn't going to blow anything up, only turn everything off."

Suzanne and James Robertson's "Requirements: The Masterclass LiveLessons-Traditional, Agile, Outsourcing". 15+ Hours of Video Instruction. 

Take a look at Tom DeMarco's Risk Management for Dummies article, published in CrossTalk.

Als auf der Welt das Licht Ausging, the German edition of Tom DeMarco's science fiction epic, Andronescu's Paradox, has now been published by Hanser Verlag in Munich.  Translation by Andreas Brandhorst.

James Robertson’s webinar for Software Education explains how agile stories are best used to ensure the right solution. Writing the Right Agile Stories on YouTube. Download the webinar slides.