Team-focussed approaches, like Scrum, Kanban and Extreme Coding, put a heavy emphasis on effective communication. Not only with the product owner or customer, but also within the team. Many practicioners fail to see why communication is so essential to the success of the mentioned approaches. In this post I want to focus on the importance of effective communication and how to facilitate it within teams by learning a few skills. There are many, many ways to improve communication, but I will focus on basic skills first. The other options are topics for future blogs. But let's start with an example of bad communication skills:
When communication goes sour ..
A team is working for company A. They've recently been introduced to Scrum through a formal training process that familiarized them with the basic concepts of Scrum. This all felt good, and the team feels confident about the approach. So the Scrum master and the team begin their first sprint and invite the product owner to join them for the first sprint planning meeting. The meeting is a complete failure. The team fails to ask relevant questions and keeps approaching the domain from a technical point of view, which alienates the product owner who doesn't understand the questions. In addition, the team feels that some functionality 'misses the mark' and voices this is an unfortante manner, which upsets the product owner who feels misunderstood. The product owner, in turn, is obviously quite unhappy with the proceedings and voices his dissatisfaction by critizing the team's approach. But the team handles the criticism badly, as they are not used to dealing with dissatisified product owners. This was never part of their Scrum training. The Scrum coach, in the meantime, is just sitting there not knowing how to best address the problematic situation. Dealing with this was never part of the training. The Sprint Planning Meeting sounded like a good idea on paper, but he was never prepared for this.
After the, admittedly, rough start, the team finally starts with the actual sprint. As the days go on, and Scrum stand up after Scrum stand up takes place, the Scrum master notices that the stand ups don't really work. Team members come to the meeting, but they lean back on their chairs and don't appear to be very interested. After a while, they start complaining that the meetings 'are just talk' and that they prefer to just get on with the programming. Also, members don't have anything useful to say other than 'I worked on some logic a bit, and fixed a bug that I can't remember'. No wonder the members feel that the Scrum stand up doesn't work. But to make matters worse, some team members start voicing their dissatisfaction with each other. One of the members, as it turns out, is lagging behind with his tasks and is constantly committing code that breaks the build. Some of the members feel that the sprint is endangered (a valid observation), and attack the member during the Scrum stand up. The meeting escalates and the lagging teammember walks away, his professional pride hurt badly.
Despite the struggling Scrum stand ups, the team continues working on the sprint. The Scrum coach does notice that the development room is quite silent. Members are working, but they have headphones on and don't really talk. When they talk, it's mostly about birds and bees. But there is no active lively debate about design issues, ways to deal with problems and more of those things promised by Scrum. 'Something must have gone wrong', the Scrum coach thinks. This is proven more pointedly during the Scrum Review Meeting. The product owner was persuaded to attend at least one more time and shows up on time, skeptical about the whole event. Although the team knew about the meeting, they did not adequatly prepare. After a lot of squabbling, one member finally steps forward and starts explain what he thinks the team has done with a soft and stuttering voice. The product owner was already skeptical, but this confirmed his suspicions: this is not a professional team. He strongly attacks the team on their lack of quality and leaves, leaving a demotivated and defeated team and Scrum coach behind.
An exaggerated example?
Of course the above was an exaggerated example. I'm sure most Scrum teams never run into all the mentioned pitfalls. But most teams will surely fall into at least some of them. The point I'm trying to make is that 'effective communcation' is often mentioned in Scrum courses and books, but it is very implicit. But effective communication is one of the hardest things to get right. It takes an awful lot of training and experience to become a good communicator. Hopefully, I can give you some pointers in this post to start working on you and your team's communication skills. The example above will always be difficult, even with the best communication skills, but a lot of problems may have been prevented in the first place.
What is effective communication?
From an academic point of view, 'effective communication' is when a sender sends a message to a receiver in such a manner that the receiver correctly receives and understands the message as it was intended by the sender. Communication is obviously a two-way process, so this definition demonstrates that effective communications reduces the amount of noise between communicating parties. The concept of 'noise' may a bit strange within the context of human communication. But a good example is trying to explain some difficult concept to another person. If you don't use the right words, the right examples, the other person might leave with a completely different idea than what you intended. In that case, the communication was not effective.
So, the key question of course is how to increase the effectiveness of communication. Let's get to it:
1. Active posture and active listening
I could probably write an entire post about this one because it's so vital to communication. An active posture means that you are sitting upright, that you are looking at the person who's talking and that you are (verbally and non-verbally) showing that you are actually listening to what they are saying. Verbal confirmations can consist of short 'Ok's or 'Mmm' remarks. Non-verbal confirmations can be nodding your head to show that you understand what is being said and to signal the sender to continue. It really helps if you write stuff down, as it gives you some structure and it shows that you are listening. An active posture is also an open one, which means that you are not leaning back in your chair, arms crossed, but sitting either upright or bent forward a bit. Leaning forward is actually a non-verbal cue that you are - so to speak - so involved that you actually want to get nearer to the other person. Not convinced? Just imagine someone who is doing the opposite of everything just mentioned and you'll see what that doesn't work well. Pay attention to people that you feel are 'active listeners' and you'll see that they do what I just wrote.
2. Learn how to paraphrase
The best way to reduce noise when communicating with someone is by repeating what the other person said, but in your own words. This is called 'paraphrasing' and it's a good way to check if you 'got' the message. It also shows that you are listening. Paraphrasing is not a difficult skill, but it is quite tricky to master. At first, it might feel a bit akward and forced (as do most communication skills). But most people won't even notice that you are doing it. Of course, i'm not saying you should repeat every single thing. But repeating the gist is important. The best way to do it is by actively listening to other party, then starting your response with 'So, what you are saying is ...' or 'If I understand correctly that ...' or 'So, you mean ...'. To practise, try repeating what other people are saying every once in a while (remember, in your own words!). You'll see that it does miracles.
3. Learn how to structure conversations with backward and forward references
Structuring a conversation means that you know where you are (in the conversation) and where you intend to go. If you structure the conversation, it means that you actively refer back to what has already been said (shows that you are listening) and expand on that. This could be done like 'Ok, but you just mentioned that ...' or 'Earlier, you told me about X but we didn't get to that. Can you explain X a bit more?'. You can also do this in a forward fashion, like 'I would like to get into that, but lets finish X first'. This is not a particularly hard skill, but most people don't do it so explicitly. The advantage of doing this is that is shows that you are listening and that you show control over the conversation.
4. Prepare and time-box
Structuring is also important in another sense. Effective communication is also time-effective. This means that you have to identify the primary purpose of a conversation before getting into it. You should make a point of making the purpose explicit before starting a conversation. This avoids confusion and shows control. In addition, time-boxing the conversation is a good idea if you have limited time or if you have to work fast. Most people will not take offense to an opening statement like 'For today, I would like to address X. I would like to take until [time] for this'. Within the time-boxed conversation, make sure to remind everyone to stay on-topic. This avoids the unlucky, but often occuring, scenario where a meeting is spent talking about other, less important, things. Especially for important business meetings, I like to write a few bullets on paper as to what I want to achieve. At the very least, I always think about this first. This also shows that you are prepared and not caught off-guard.
5. Learn to criticize construtively
This may seem like an strange one, but learning how to constructively critize other people is a very important and useful skill. Many people often begin with 'I don't mean to critize you, but...'. That doesn't work. This actually evokes a 'shields up' response from the recipient because you are technically lying: you are criticizing someone. Also, most criticism is phrased like an attack, like 'You did this wrong' or 'You wrote this down wrong'. There is absolutely nothing wrong with being critical and voicing this every once in a while. It shows that you are involved, otherwise you wouldn't even bother. And if you criticize someone's work, they might be able to learn something. So learning how to give criticism is important. The key is to make it not feel like an attack, but more like a factual observation and how you feel about that.
There are a few rules for effective and constructive criticism:
- Do it as soon as possible: Don't wait for weeks. If you want to criticize someone, do it during the event or as soon after as you can;
- Start with the facts: Don't start with your feelings, start with what you observed. For example, you could say 'I saw you taking my mug' rather than'You are a thief!'. The latter is easily perceived as an attack. The other person may not have had any bad intentions. If you criticize people like this, they will go into defense mode and try to strike back. The former is a factual observation and cannot be argued with;
- Describe how it made you feel: This may seem a bit touchy-feely, but it helps to describe a factual observation and expand on how that made you feel. The other person cannot possibly disagree with how you felt. They may disagree with how you perceived it, of course. So, you could say'I saw you take my mug, and it felt to me like you didn't consider that I wanted to use it' rather than'I saw you take my mug and I thus think that you are inconsiderate'. The former is phrased based on how it made you feel, while the latter makes a statement about the other person's personality. Obviously, the former will be easier to accept;
- Be constructive: Good criticism is followed by suggestions on how the other should change their behavior. After all, the only purpose of giving criticism is to evoke some degree of change in the other person's behavior. Again, keep it as concrete and objective as possible. You could say'I saw you take my mug, and it felt to me like you didn't consider that I want to use it. In the future, could you ask me first if I want to use it?'. By asking the other person to make a constructive change, you are signalling that you are willing to forgive them for it.
Now, this might all feel forced. Half the time, I don't follow these rules to the letter. But their basic tennets are important to keep in mind when criticizing. The only reason why we are criticizing someone is to evoke change. By formulating the criticism as an attack, it will most certainly fail. If you appear understanding and criticize the other's actions without attacking them personally, you can make a huge difference. Today, I had a nice example when a colleague told another colleague that 'Your notes don't make sense'. This way, you make the receiver feel incompetent. A much more effective approach is to say 'I find it hard to understand your notes'. Criticizing each other's work in a constructive manner will facilitate open and transparant communication within teams. As a Scrum coach, you'll probably have to help people criticize each other more often when you feel they need to, because most people tend to believe that criticism is bad.
6. Learn to ask open-ended questions
This is one of those pointers that most communication trainings will give you. There are basically two types of questions; open and closed oned. Closed questions are questions like'Do you like A' or'Is X' and can only be answered with yes, no or I don't know. They don't allow for debate or discussion. A more useful approach is to learn to phrase all questions in an open-ended manner. So, you can say 'Why do you like A and not B?' or 'Why is X?'. Most closed questions can be reformulated into open-ended ones by appending the question with a'why'. Open-ended questions are especially important when a team meets with a product owner. Make a rule of avoiding closed questions.
7. It's the 'Why' that matters
This skill is especially useful with product owners and they are the key reason why good consultants are good. Good consultants know that asking the 'Why?' question is very useful. In our company, product owners usually arrive with a solution they came up with. Often, this solution is based on the way the product owner framed their problem. A nice fictional example is a customer who walks into a DIY store and asks for a drill. A clerk could point the customer in the right direction. But it might be more beneficial to ask why the customer wants a drill. The answer might be that the customer wants to hang a painting on the wall. This opens dialogue options. The clerk could ask what kind of wall and perhaps recommend the customer to buy transparant plastic straps to hang the painting from the ceiling to the wall, instead of drilling holes in a soft wall that might cause damage. Another metaphor is a customer that wants a tunnel. Further inquiry might reveal that the customer wants to get to other side of a river. In that case, a tunnel might be a very expensive solution, especially if it's a one-time event. So, a helicopter might be more useful to the customer. The key is to ask the 'Why?' question to inquire about the reasoning that a product owner has behind their answers. You might recognize that writing user stories focusses on the 'Why' part of every functionality. This is why. Some product owners might even reconsider functionality after asking the 'Why?' question.
8. Learn how to resolve conflicts
All teams will deal with conflicts sooner or later. Most people frown on conflicts and consider them a bad thing. This is based on the incorrect assumption that all conflicts result in huge emotional stand-offs. This is not the case when a conflict is correctly handled. From an academic point of view, a conflict is nothing more than a difference of opinion or or a conflict of interest. There is no reason to allows this to escalate. To make the point, it might help to look at people that are hard to anger or lure them into conflicts. You'll see that these people follow a number of rules:
- They listen: Listening to the other party is the most important part. Often, parties that are in a conflict will stop listening to each other and just keep repeating the same thing over and over. This does not work. The best way to resolve conflict is to re-open communication;
- They change perspective: In a conflict, everyone feels they are right. It helps if parties try to understand each other's situation. This is very hard, especially with escalated conflicts. But if the parties don't understand or don't want to understand each other, it's hard to ever resolve it. Those who are good at resolving conflicts will usually say things like 'I understand how you feel, but'.They also make sure to keep the conflict from escalating to a personal conflict;
- Try to find middle ground: The best way to resolve a conflict is by doing something that is called 'log-rolling'. It means that you try to find a middle ground that is acceptable to all parties involved in the conflict. This sounds obvious, but it isn't easy in a conflict. Just keep in mind that if it's very unlikely to make everyone 100% happy with the outcome it's better for a team make everyone at least somewhat happy than some completely unhappy;
- If all else fails, ask for help: Let's be realistic; some conflicts can't be resolved if you're smack in the middle of them. It's often hard to clearly see what's happening. In that case, ask for help. That's why a Scrum coach should be trained in conflict resolution;
These are just a few pointers. Conflict resolution is a very interesting and difficult topic and it takes a lot of training to become very good at it. That's why mediators are often paid so well for what they do. But the rules mentioned above will give you a good start. I will write more about conflict resolution (in detail) in a future post.
9. Learn by doing
Communication skills can't be taught from a book or a blog. The best way to learn them, is to actually use them. A good way to do this with a team is to organize short workshops that focus on one skill. You can roleplay scenarios where one member plays the product owner and the other members have to determine the best solution or where members practice a skill on duos. Or you could ask members to take one skill every week and practice it on their colleagues. At the end of the week, ask how it went. A good communication training session with a professional coach is also a good option, but will require a larger budget.
Effective communication is important within teams, but also when communicating with product owners. This sounds like an open door, but effective communication is often not addressed in formal trainings. That's why many Scrum implementations fail to reach their potential. Even the best training might not prevent the horrible scenario we started with, but it will most likely prevent the majority of the problems. So, when you start with Scrum, make sure to also give your team at least some basic communication training. This will make communication more pleasurable to all and, above all, more effective. A nice benefit is that communication skills are useful everywhere, including your personal life. So get started!