What’s in the news today?

In my experience there can often be, especially amongst testers, a desire to hear the bad news, the gossip or the failings. Get to any mainstream Testing conference to hear stories of Testers gleeful at delays, failings and horror stories of late releases; the stereotypes of negative Testers did start somewhere and is very much alive in some industries.

I don’t believe this is a good strategy at all, but I’ll save that rant for another post. A lot of the negativity, delays and grief can often come from the way we report our testing. Often innocent reporting of findings can result in a witch hunt, panic and stress. I’ve seen whole management teams mobilised because of lose comments about quality, especially when a product is nearing it’s release date.

When we report our test findings we need to be careful not to sensationalise the information, or underplay the importance of the findings.

So in a sense, just because some people crave tales of disaster, rework, bad designs, mistakes and trouble ahead it’s not always constructive to give them this news. Now, don’t get me wrong. I’m not advocating that we don’t give the truth. Not at all. What I am saying is be careful how you deliver this news.

Be careful to keep your information factual. Try not to add a personal or political balance to it (unless you have an agenda) – this is a lot harder than you think.

Becareful of the language used. Emotive words will flavour the meaning.

Think about the information you are providing. Sit and read it and then write down 5 questions you could realistically expect to be asked about this information. Then answer these questions. Add this further information to your reporting. Then try to find 5 more questions. Not only will you prepare yourself for inevitable questions about your reporting, but you will also fine tune your information in the process. It may seem over-kill but I have wasted countless hours in uneccessary meetings because someone over-sensationalised their findings.

Keep the data clean, minimalist, simple and to the point.

Think about what context you find your project in. Is it the last day? Is it the first day? Are you working overtime? Are you under lots of pressure? Is it going well? These factors may make a difference to how your information in interpreted.

Make your information gel nicely with the context. Or make it contradict for a reason.

But always be conscious of the effect your information *could* have. Even stopping to think about what you’re reporting is a very effective filter. And remember:

“What interests the project team, might not be in the interest of the project team”

Duplicate Conversations. Duplicate Conversations.

In almost all places of work, there exists a level of wasted time and effort when communicating a message multiple times.

In almost all places of work, there exists a level of wasted time and effort when communicating a message multiple times.


These “duplicate conversations” are wasteful and ultimately take people away from the work they are trying to complete.


Close up on the pic 79/365 playing the Whisper Game

Image courtesy of : http://www.flickr.com/photos/kalexanderson/

We need to communicate to our “communication stakeholders” (team members, project, sales, marketing etc) but this communication should not need to be repeated multiple times.


Duplicate conversations can occur for a vast number of reasons, but often it is as simple as key communication stakeholders dropping by for updates. Only to be shortly followed by another stakeholder. And then another. Soon you find the whole morning has gone and all you have done is update people. This is especially so when the management style is to “manage by wandering around“.

Meeting are a ripe source of duplicate conversations, typically arising due to a key stakeholder not being present in the meeting or people taking away a different set of actions or conclusions from the other attendees.

Different teams working on the same problems can often result in duplicate conversations, especially when they aren’t talking to each other during the development and are both updating the stakeholders individually.

No designated “Panic Manager” or “Point of Contact” can result in the whole team being involved in a bug investigation when it could easily be dealt with by just one person.


Repeating the communication once is bad enough, but to repeat it several times is very trying.

Even worse is the predictable amount of panic these multiple conversations can cause. This is especially so when it reaches a person of “power” after travelling through a series of Chinese Whispers (other people repeating the same conversation but missing out details or adding in details not included in the original message).

It can sound like a full scale project meltdown by the time the last person in the chain hears about it. Emergency planning meetings are called. People are furious. You’re wondering what went wrong. Panic and flapping over nothing. A storm in a tea cup. A miscommunication.


Communication failures I believe cause an unprecedented amount of wasted time, unneccessary panic and general grief for all involved.


So what’s the solution?


Each situation will be different and there is unlikely to be any one single answer to any communication problem but what follows are a few suggestions.

1. Hold a daily stand up meeting (where applicable with team size) and encourage all members to be clear and accurate in their description of what they are working on, what they are blocked by and what they have completed.

A standup (like any meeting) is only valuable if people are going to actively communicate. Too much information and people switch off. Too little and you’re losing the value. And no, they aren’t exclusive to agile projects.


2. Take “minutes” in meetings with clearly defined Actions. Read the actions out at the end of the meeting to ensure everyone understood them and took on board those actions they were tasked with. Communicate the minute notes immediately after the meeting in your preferred format of communication.


3. Use information radiators (low tech boards or areas or pages used to communicate information). Make sure the information is simple and easy to understand. Making your information radiators tricky to read is no good. They need to communicate the correct information, to the correct audience with the least chance of noise creeping in or misunderstanding of the message.


4. Dedicate someone (or more than one person) from your team to be the main point of contact for issues, questions and panics. Issue do happen so it’s prudent to make sure you are set up to handle them in the most appropriate fashion to avoid distraction and interuption and also to ensure the best possible response to any customer issues.

It’s also incredibly expensive to have a large team investigating an issue, especially when that issue turns out not to be an issue.


5. Organise cross team meetings or standups or chat channels. Use whatever communication medium floats your boat to ensure different teams are talking to each other when working on the same area, or problem or feature set. It’s crucial to start the communication process and try to keep the channels open.

Otherwisey you could find you end up with a situation Melvin Conway was describing in Conways Law.


6. Fine tune your process. If you find yourself repeating the same message to multiple stakeholders then stop doing it and work on the cheapest and lowest tech solution to the problem.

In my experience, the more expensive, integrated and purpose built a software communication tool is (like Test Management Tool), the least likely it is to solve your problem.

You cannot beat face to face communication for gathering the non-verbal subtleties and clues, but if that’s not possible then what about a good information radiator like a status written on a white board?

Or a Chat Group where the discussions and outcomes are already audited and exportable for future reference?

Or a free wiki? Or a blog?

Look for the most cost effective way to solve the problem and keep iterating around the problem until it goes away.


However, none of the above will solve your communication problem if the right people aren’t kept in the loop and the people involved aren’t communicating the right messages.

This is a much harder problem to solve.





Communication. Signs. Symbols.

I’ve studied communications for years now but today was the first time I encountered the video from Archive.org that I’ve included in this post. Which is a shame because it’s fantastic. At the same time I’m glad I’ve stumbled across this video now so that I can share it with those who are interested.

Communication underpins everything we do. In a sense, we cannot do anything without communicating something, so it’s important we understand the implications of this.

For those that follow this blog you’ll know I’m interested in simplifying the discussions around communication by elevating the deeper rooted theory in to a simple three thought process. Purpose. Audience. Context. It’s a starting point to think about communication and how well we communicate but is no means complete.

This video does an excellent job of explaining the deeper rooted theory, particularly focussing on Shannon’s model of communication but also touching on signs, symbols, culture and noise. It’s a great video and carries that typical 1950’s haunting aspect of informational videos. I love the images, editing techniques and footage and the soundtrack just tops it all off. But despite all of this retro greatness there’s nothing more important in this video than the content.

It’s a long video at 20 mins but well worth sticking through. Some highlighted phrases stood out from a testing point of view.


English language is one half redundant


Computers are often referred to as brains….The greatest fallacy in the comparison is one of degree.




Lost in translation – a lesson learned at a hot dog stand – #agiletd

Image from : http://www.flickr.com/photos/bunchofpants/2946843497/sizes/z/in/photostream/

It seems there is inspiration for learning all around us. I’ve just got back to my room after a walk around the local area here at Agile Testing Days in Berlin. The location is excellent, despite being a distance from the airport, and the local area is just lovely. Lots of fabulous buildings and shops and tree lined streets. I’d left my memory card back in the laptop otherwise I’d have included some photos.

I’m one of these tourists that loves to sample the local food. I don’t see the point in being abroad and eating English food. It’s not like we’re known for our culinary delights anyway. So I decided to stop off at a wiener stand by the side of the road.

What followed can only be described as a “Lost in Translation” moment.

Me: Hallo

Vendor : Hallo. (Something else which I suspect was “what can I get you”, but cannot be sure as my German is very very bad)

Me: I’d like what the locals eat please.

Vendor: Ok.

He then proceeded to create the most creative looking “hot-dog” I’ve ever seen. His face told a thousand horrors as he randomly put bits of various stuff from the fridge in a tiny bread roll. He looked like a scientist trying different flavour combinations, each one accompanied by a frown and a suggestion that this might not taste so good.

With a look of sheer panic he placed the largest weiner I’ve ever seen in the tiny roll. Then added Ketchup and Mustard. Some more stuff from the fridge. He rolled his eyes, raised his eye brows and gave off more non-verbal clues that he really wasn’t sure about this thing.


It seems my request for something authentic and local had been Lost in Translation and since my German was so embarassingly bad neither of us had really got a good deal out of this.

He leaned over the counter and said:

“hmmm. I guess this is a German Hotdog” His eyes told a chilling truth though. Here was a man who’d created something he’d no doubtedly have nightmares about. I could see in his eyes that he was gutted. I too was apprehensive of this “German hot-dog”.


As it happens it was delicious but I suspect, not very authentic. The locals in the cafe were all incredibly amused by my lunch too. I think one or two took pity on me as they offered me kitchen roll and laughed heartily with (at?) me. They’d seen this epic failure on my behalf to communicate my requirements clearly and seen the resulting meal. I’d done everything I preach against doing. I’d failed to communicate my intentions clearly.

If only I had have brought a German Phrase book with me things could have been very different.


And so I learned a valuable lesson here today. Even with the best intentions in the world, communication breakdown is a reality and both parties can be dissatisfied with the final product. I should have learned some German for my trip or at least given the vendor something more substantial to go on.


This happens in the work place too, even when there is a common cultural language in use. Ideas and concepts get lost in a fog of misunderstanding and assumptions.


I think next time I venture out to taste the local cuisine I shall take a phrase book with me and try to clearly articulate my intentions in more detail. I can still see the vendors face now (who I learned was called Alios….I think). But I also tried to let him know how delicious it was, because it truly was amazing. And despite the fact his non-verbal communication suggested otherwise, I can’t help wonder whether he’ll add it to his menu as “The German Hotdog”.