Mike Cohn's Blog

Miscommunicating with the written word

What a wonderfully poor medium it is to communicate with written words. I’m sometimes amazed that we’re able to communicate meaning at all. Here are two good examples of how hard it is to communicate with written words.

A few weeks ago I was traveling and decided it was time to schedule another Certified ScrumMaster class. I emailed my assistant, Tonya, and said, “Please book the Hyatt in Denver for July 31-August 2.” A day or two later she emailed back saying, “The hotel is booked.” With that crossed off my mental to-do list I moved on to the next thing.

About two weeks later I’m again on the road and Tonya emails me saying, “Did you want me to find a different hotel in Denver or are you just not going to do that class?” I’m very confused because she’s told me the “hotel is booked.” Since that’s the case why is she asking me about booking a different hotel? We exchange a few more emails until I finally realize that her reply to me (“The hotel is booked”) did not mean “I’ve finished with that task; the hotel is booked.” It instead meant “The hotel is already booked by someone else; now what should I do?”

What’s interesting is to look back over the communication–nothing is wrong with what either of us typed into our emails except that we were each coming out the question from a completely different context.

Here’s a second example of how easy it is to miscommunicate: I’m in London this week teaching some classes for my good friends at Conchango. Since I can’t watch the basketball playoffs as I normally would this time of year I’ve been taking the opportunity to try to learn the rules to cricket. To someone with absolutely no prior exposure to the game it’s quite confusing especially as it seems to go on forever. I mentioned to my class today that I’m trying to figure the game out. One of the participants in the class shared with me the following instructions. These are apparently marketed as “Cricket Rules for Foreigners” throughout the UK:

You have two sides, one out in the field and one in. Each man that’s in the side that’s in goes out, and when he’s out he comes in and the next man goes in until he’s out. When they are all out, the side that’s out comes in and the side thats been in goes out and tries to get those coming in, out. Sometimes you get men still in and not out. When a man goes out to go in, the men who are out try to get him out, and when he is out he goes in and the next man in goes out and goes in. There are two men called umpires who stay all out all the time and they decide when the men who are in are out. When both sides have been in and all the men have been out, and both sides have been out twice after all the men have been in, including those who are not out, that is the end of the game!

These rules are obviously intentionally obtuse. Notice how they are (probably) perfectly correct yet they say nothing about how to really play cricket. What strikes me is how similar these rules are to many requirements documents I’ve seen in the past–they may be accurate and perhaps clear to someone who already knows what is being said but they sure don’t convey any true understanding to the reader.

About the Author

Mike Cohn is the founder of Mountain Goat Software, a process and project management consultancy that specializes in helping companies adopt and improve their use of Agile processes and techniques. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile. Mike is a co-founder of the Agile Alliance. He is also a co-founder and current board member of the Scrum Alliance. He can be reached at mike@mountaingoatsoftware.com

12 Comments:

Jay Conne said…

“What a wonderfully poor medium it is to communicate with written words.”

I’ve heard ideas like this from the Agile community for some years and have always had a problem with blaming the tool rather than the operator. 

Your example of ‘booked’ being misunderstood is funny and typical, but it begs another level of detail.  We all know that words in the dictionary have multiple meanings.  As speakers (or writers), if we are alert enough, we make clear which of multiple meanings we intend.  Of course there are slips that lead to humorous stories like yours.  That is a failure to understand the ambiguous context. 

The language has full capability to be precise in scope and detail.  It provides all the logical tools such as: and, or, not, except, etc.  We just need to know how to use them.  I think this is really an issue of thinking rather than communicating - one can’t communicate an idea that has not been clearly thought out. 

I hope we can come to focus on excellence in thinking and writing skills. 

This is not to say that I don’t appreciate the importance of discussion, review, editing and feedback.  But that’s all part of the process of getting to good ideas and communicating. 

Mike, you are such a good writer that I think of you as an excellent example of all these points - which has made your books such an important contribution to our discipline.  Give yourself all the credit you deserve for using your tools so well - and than encourage others to rise to a high standard of your example. 

So - thank you!

Edgardo Gonzalez said…

I use three basic rules for effective written communications - particularly through e-mail when everybody appears to suffer from ADD:

first sentence - state what you expect the receiver to do and when
second sentence - explain what prompted you to issue the request [why]
third sentence - impact of no action

Thereafter, one can provide any additional information/rationale

The example of “hotel booked” addressed the second sentence but failed to document the first one - the link between the sender and receiver was broken.  It also lacked the third one (to cancel the session if no hotel is booked)

I found it facinating why people spend so much time writing lengthly and convoluted e-mails when only three sentences will do to assist the receiver(s)

Also only place in the TO: section of the e-mail the name or names of those who you expect an action to be taken.  The BCC: is for information only and no action is expected from these people.

My ten cents worth

David McLean said…

During a recent job it appeared to a senior stakeholder that the teams were not communicating effectively. This he had surmised from being cc’d sporadically througout the conversations. To communicate his concern he used an email to suggest that everyone should be using the phone. Ironic eh? But a valid point.
However the written word is a useful record of what has been agreed. I’m an advocate of having a conversation either face to face or on the phone or a video conference; then follow up with the written work and make sure everyone agrees there is a fair representation of the agreement that can be used as a point of reference for future disputes. Easier said than done, oh to be so perfect!
And finally, avoid ironic interjections by not cc’ing anyone who is likely to be more interested in how your communicating than what your achieving with your communication.

Markus Strand said…

I think the word “written” had nothing to with your experience of bad comminication.
The same problems would have appeared also in spoken communication.

Good communication is IMHO:
  * short
  * exact
  * continuous
  * asynchronous
  * persistent
  * easy to understand


It is extremely difficult to listen in a different pace than the speaker speaks. Any disturbance or interference might cause the message to get lost forever.

Written communication is easy to come back to. You can read again anad again anything you don’t understand. And if you still don’t get it, you can make an axact pointer to the thing you didn’t understand.

Jakob said…

This is exactly what I expected to find out after reading the title Miscommunicating with the written word. Thanks for informative article

Quinn said…

Hi Mike ( long time no see…)

Great article…at FcSA we have many in house training courses and one of them is Effective Listening Skills and of course as eveyone knows…communication is mostly non-verbal in manner and form ( somewhere between 60-80% ).

Thus, the very nature of the human condition demands one-on-one direct communication for successful transfer or thoughts, feelings and ideas.

The only advantage I have when I write a long dialog in the context of working a user story is that it helps me clarify what I am trying to say with the business owner in a conversation that I fully expect to have when I work the story into some form of 1’s or 0’s ( programming ).

Keep up the momentum

Your Friend
Quinn  

PS Spell checkers are for WIMPs ( weakly interacting massive particles ).

Mike Cohn said…

Hi Quinn—
It’s good to hear from you. I love the written word (both reading and writing) so it’s a constant struggle for me always to remember what a weak medium it is for conveying information in a reliable manner.

By the way, congratulations on the continued success of agile at FCSA. I read an article on your success recently in CIO magazine: http://tinyurl.com/2ccduy

-Mike

Vikrama Dhiman said…

Great Article Mike.

In addition to miscommunication as explained in your post above, there are other problems - however these appear for both written as well as verbal communication. In our quest for becoming concise and short, we are unintentionally hurting people and leading to the work stress around.

Here is a small example:

A day past the sprint end and there is no Sprint Backlog or Communication with Product Owner. The CEO emails the SCRUM Master and the Team - “Why has the status not been updated?”. The SCRUM Master and the Team are already emotional as a team member had a severe medical problem yesterday and were all in hospital and are further enraged that CEO does not even know. SCRUM Master rather than explain the situation writes back emotionally “This is not my job to update you on progress. It is teams job, let them get back to you. I am out of it.” The team members all start “Why is status not asked when we were working so hard that we collapse on the work table itself. Anyways, it was not done because we were all out of office for a medical emergency.” CEO at this stage has been thoroughly confused and three emails have destroyed all the efforts made to get the team together - thereby destroying Agile itself.

And this is a true story. :)

Mike Cohn said…

That’s a horrible situation. The ScrumMaster should never have written an email like that. I suspect the situation was caused more by personality type (in response to stress) than by the use of an agile process. That is, the situation would have been mishandled whether the team was agile or waterfall.

Doug Miller said…

Mike,

I lead a marketing team at an organization using Scrum/XP for development of commercial software. One of the challenges is deriving the contents of a release from the stories/features that make up the original product backlog because of the flexibility of dynamic nature of what stories ultimately end up in the final release or release candidate. Because when the release is ready to go it is important to have marketing and selling materials updated to reflect the new business value added to the product, this often means that product marketing is the final release bottleneck. Using the words in the user stories are certainly a good start, but at some point those must get combined into feature sets and release themes for external consumption. Have you seen any good or best practices to help accomodate this challenge?

Mike Cohn said…

Hi Doug—
The developers should be providing you with an update each sprint of where they think they will be when they end. They should be able to estimate velocity as a range (let’s say from 15-20 points per sprint) and then multiply those by the number of sprints and then count off those numbers of points into the product backlog. They can they say to you something like “We have 5 sprints left and an average velocity of 15-20 so we will finish between 75 and 100 points.” I illustrate this by drawing lines through the product backlog so that everyone sees the likely range in which the team will finish.

Additionally, I like to start a project by thinking of its features as “epics”, which are simply larger user stories. An epic for a word processor might be “As a user I want to be able to add tables to my documents.” The epic later gets split into smaller user stories so that they are of a size the programmers can add them in a single sprint (e.g., “As a user I can add new rows to an existing table.”) The themes are helpful because they provide context for the overall project without being so lengthy we dose off reading it. The epics are also the items that are more suitable for marketing literature. Small, implementation-size user stories are generally too small to be the bullet points on the back of the box; epics fit there perfectly. Finally, if most of the marketing literature describes epics then that literature shouldn’t be too dependent on exactly which features make it in by the deadline. That is we’re still going to put “Now with tables!” on the box of our word processor’s box even if we didn’t have time for the user story about using custom border styles around the tables since much of the other table support presumably was added.

Doug Miller said…

Great help Mike—thanks! We will start doing the aggregating. I like your term “epic”, and this fits very nicely with what I meant when I described combining stories into related feature sets—nice metaphor to work with the dev theam with.

Leave a Comment: