Last weekend I attended a training for essential consulting skills. One obvious idea presented there really impressed me: Listen to your conversational partner! Sounds trivial, right? Well, there are some simple techniques about that worth to be mentioned.

The workshop leader asked one consultant to talk about his hobbies. When the conversation started, the workshop leader was not attending the conversation and just saying “Hm, yeah, interesting…” while sorting some papers on the table. Of course, the consultant felt very uncomfortable in this situation. He was unsure about himself and just nervous. Then the workshop leader used some simple tricks to keep the conversation running. Attend: Just be present, concentrate on your partner and do not do any other things. Clarify: Ask, if any detail is unclear, show your interest. Restate: Repeat with your own words to show you got the point. Empathize: Be a mirror for your partners feelings. Summarize: Give a résumé about the dialog to be sure you got the key points and to derive the next steps from this conversation.

Use these techniques to give the attention your counterpart deserves and see how much more information you can get and how much more comfortable your conversational partner feels. Not everybody likes to talk to unknown persons. People are not sure about themselves, they don’t know that the other person wants to hear and what will be done with the given information. As consultant you have to deal with such situations every day. So use these simple techniques to get what you want, to make others feel comfortable and to build up a trustful relationship with your customer.

Are you a good listener? Which techniques do you use to keep a conversation running?

Some things can’t be said too often: The key skill in todays business is the provision of concise »on the point« information. Of course this doesn’t only work with coffee.

The following scribble shows an example how to display business processes along with their underlying technical counterparts (services and databases).

The diagram was used in one of my last engagements and provided a lot of information in one view:

• The business process
• The (external) services called
• Necessary middleware/adapters
• Underlying datasources

The boxes pointing to the right symbolize »callbacks« i. e. calls in an asynchronous scenario with arbitrary time between the calls. The boxes with an open left side stand for the counterpart waiting for such calls. If services couldn’t be called directly e. g. because protocol conversion had to be considered (RMI2SOAP, …) the adapter swimlane was used to show the middleware in use.

Of course the boxes were labeled with even more information but for now the general blueprint is interesting enough. Techies and Business Folks were discussing the same diagrams. Questions of data origin and synchronisatin problem could be simultaneously discussed in terms of processes and technical constraints.

Of course there are countless variations of this swimlane-like type of diagram. Any ideas? What are possible improvements? What do you use in similar contexts?

Presenting information in a clear and time saving way is the skill for us IT-folks to develop and nurture. Today Lokesh Dhakar shows us what condensing and visualizing to the point can look like.

We proudly present his blueprints for what I would call CAL (Coffee Layer Architecture) (click to enlarge):

Isn’t this great? You get a lot of important information in one view:

• What sorts of coffe are there?
• What is the difference?
• How can I make one myself?
• What is the correct pronunciation?
• …

What would it take to accomplish this with pure text? Would you (want to) read it?

You can find the whole set and sizes on flickr.

I stumbled upon a blog entry from Jeff Langr today in which he challenges the concept of »chickens and pigs« in agile development.

His line of reasoning: Having a rule which forbids communication is not agile at all. He suggests to sustitute an other agile value instead: courage. Simply ask people who are not helping in the daily to stop. And talk about it.

You can read his full view here.

I like his suggestion for dealing with chicken-rule-fetishists:

The next time someone calls you a chicken, let them know that there is a new animal in agile. It’s the ass. The ass is the person who dictates how things must be. They are stubborn, controlling animals. Perhaps the best thing to do with an ass is to give it a good swift kick.

I think Jeff has a valid point there. Nothing is more tedious than being constantly remembered by a Scrummaster(tm) that something »isn’t following the Scrum rule book«. On the other hand these rules are necessary scaffolding for beginning project managers without a lot of experience under their belt. Maybe the truth is somewherein  between again. If you need this rule, use it. But get rid of it as soon as possible.

What do you think of this rule? Do you use it?