«Sketch Notes by Gary Barber Agile Communication – Why it Sucks! CONTRIBUTORS TO COMMUNICATION FAILURES IN THE TEAM SHARON ROBSON Abstract Agile is ...»
Sketch Notes by Gary Barber
Agile Communication –
Why it Sucks!
CONTRIBUTORS TO COMMUNICATION FAILURES IN THE TEAM
Agile is all about individuals and interactions over processes and tools, as well as customer negotiation
over contracts – yet time and again we fall into major pitfalls when it comes to communication in our
agile practices. There are three key contributors to communication failures in the team.
1. It’s hard to communicate! Communication is a transaction that requires 3 steps (send, receive, confirm). Language is a problem, there are barriers (wrong place, wrong time) and there are differing skill levels of communication.
2. What do we talk about? It is confusing to talk about the things we need to discuss in Agile, often we are talking at cross purposes. Understanding ‘big picture versus semantics’ and not even knowing the questions to ask are major problems.
3. So much to share, so little time! When we communicate we use the wrong tools in the wrong ways. We use the wrong processes that do not enhance communication in an effort to save time and money. We also fail to consider all the types of communication that are needed.
So how do we fix it? Let’s walk through these three clusters of communication issues and outline some feasible, quick and easy tools and techniques that can be used to enhance, enable and empower communication within the agile environment.
Introduction Agile communication sucks! It is really hard to communicate well, but we all think “we” do a great job, it’s just the other people who struggle. There are a myriad of communication issues we face but still we suffer through it. Why? Probably because the Agile Manifesto is all about communication, interaction and collaboration.
We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
We know it’s good, right and what we should do, we know to be agile we need to communicate. What we really need to do is understand the how and the why of communication, and also what the problems are. If we are going to move forward on our agile journeys, we also need to know what we can do about the communication issues. First we have to define the problem or problems and then we have to define potential solutions. So what are the problems?
Bottom line: it’s hard! There are two aspects that make it really hard – the physical and the “mental” or metaphysical. To enable communication, each of these needs to be considered.
Problem 2: Metaphysical Barriers There are more than physical barriers to communication – one of the challenges is identifying the mental or metaphysical barriers. These are harder to identify as they are harder to see and to trace.
Problem 3: We Talk About the Wrong Things In addition to the physical and mental communication barriers we need to overcome, there is a major barrier that comes from simply being agile – we talk about the wrong things. Working in an agile project is very different to how we normally work, so we often don’t understand what we are trying to say and when we need to say it. A classic example is the level of detail that we put into stories or design in the early stages of a project. Sometimes we need to drill into some detail early to drive out some good risks or questions, other times we need to refocus on the big picture to ensure we are not losing track of what we need to do. When to do each level depends very much on the needs of the team. However, we often structure our communication (ironically) to follow the process, not the needs of the team at each time.
It is very difficult to understand what to talk about at each stage of the project without • understanding why we are talking about it.
We talk about the wrong things at the wrong time with the wrong people because we don’t • understand the context of the conversation.
Problem 4: So Much to Share, So Little Time There is so much to discuss and share when we are building solutions. The best analogy I have heard is that is it like “drinking from a fire hose”. We need to know an awful lot from a lot of perspectives and this can be overwhelming. Often we resort to recording the information in written words – the worst possible way of recording information. We need to consider various ways of communication, from written word, discussions, whiteboard sessions, diagrams, brain storming, etc. We also need to allow ourselves to discuss a topic more than once. We need to learn from each discussion and then apply those learnings (either about how to discuss or the topic discussed) to each and every other topic we cover.
Using the wrong tools – the written word is not a great communication tool.
• We limit ourselves to a single session for communication.
• We use a single method of communication, no matter what we are considering.
• So How Can We Solve These Problems?
I have put together ten items for consideration on how to address these key problem areas. These are not a silver bullet, they will take time and energy to apply. Try some, all, or none, but at least try.
It is not impossible to do – there are some steps to be taken to help make communication much easier for everyone.
© Software Education 2013 3
1. Make it a Deliverable Within the team, focus on communication as a deliverable of the team. Highlight that communication does not just “happen” and it needs to be planned for and estimated. Treat communication as a key part of the output. Consider all the ways that communication can occur and estimate and plan the communication mechanisms. For each phase of the project, think about the mechanisms that are most suitable to that phase, plan the activities and then check that communication has occurred.
If we make it a deliverable of the project then we can also define acceptance criteria (given the team is attending an elaboration session, when the session is over everyone will have the notes needed to complete their work on the card). We can also define “done”. For communication done may mean: able to document my work, understanding of key terms, knowing who to talk to for any questions, able to replicate the thinking behind the decisions made.
Record the deliverable mechanisms in the agile ways:
Either as card on the wall or as a factor in velocity – make communication a deliverable.
• Measure and assess it – get the acceptance criteria clearly defined.
• Define “done” for each communication goal/activity.
2. Allow Time To have good communication people need time to prepare their thoughts, ideas, facts and figures, present them and then receive feedback on them. We often don’t allow time for the three steps, usually only the “present” ideas step. This can be very challenging for all involved; especially if they are unsure of the topic.
3. Understand Why The team needs to know why they are communicating together, as well as what’s in it for them, and what is expected from them. It’s very hard to understand what to do or how to do it, if you do not understand why you are doing it. This means all those involved know why they are going through this activity. The best way to do this is to have the team plan the communication process and techniques that will best drive out shared understanding.
5. Different Types of Communication are Required Change the methods, approaches and techniques for each of the types of communication required.
Maximise effectiveness by having some sessions as discussions, others using whiteboards or diagraming tools and other sessions using or building prototypes. Make some sessions about “creating” options and then other sessions about “editing” options.
6. Use Pictures, Not Words The old saying “a picture is worth a thousand words” is very true, particularly when talking about something complicated.
In our agile projects we need to consider both the specific and the general context of the work we are doing and often a diagram or drawing is the best way to understand those interactions. Words confuse the issue and make understanding an assumption, as we all assume that the same word means the same thing to everyone. Often it does not, or even worse, some people may not know what the word means and are too afraid to ask.
7. Use Specific Examples To make sure everyone understands, make anything
that you are discussing into reality, by using real world examples, facts and figures. Don’t leave things undefined or assume that everyone knows what it will look like. Most people struggle to contextualise or visualise unless they have a real world example to see, understand and then question.
Define the steps of communication – send, receive, confirm – and how to do it in the specific • meeting or forum. Clear rules mean clear engagement.
Check that each part of the process has occurred. Clear rules and process mean that confusion • can be eliminated.
9. Pick the Right Place and the Right Time Make sure you have the right environment and • tools for communication to occur: reduce interruptions, distractions and other physical barriers.
Have the right tools to hand. It is very difficult to do a design without a whiteboard or flipchart • paper. Brainstorming without preparation and post-its is hard!
Tell everyone what is going to happen and when it is going to happen so they are not surprised • or unprepared.
Don’t plan intensive long sessions for late in the day.
• © Software Education 2013 6
10. Aim to “Collaborate” Communication is only half of the game, collaboration is the ultimate goal. But collaboration is like “hyper-communication”! All the principles of communication need to be in place, then each member of the communication process needs to actively be involved in the session, contribute their knowledge and understanding and proactively change the way they are thinking, challenge any assumptions and contribute to the final knowledge solution.
To collaborate well teams need to:
Conclusion Communication is very hard. There are lots of factors involved in good communication and lots of assumptions we make about how and when and where we communicate. These assumptions can be wrong or misplaced.
Focusing clearly on the goals of communication and setting up good, solid communication mechanisms allows teams to grow their communication, and ultimately their collaboration skills.
As with all things agile, a few words in the manifesto actually have a lot of deep meaning and challenges to the team and individual. If nothing else, try some of these mechanisms to see if communication changes for you.
© Software Education 2013 7