Effective Communication in Agile

Chris Gungaloo 23rd June 2017

[vc_row][vc_column width=”1/1″][vc_column_text]One of the principles behind Agile work methods is that ‘business people and developers must work together daily throughout the project.’ Even with agile methods in place this is not always as straightforward as it seems. This article looks at some of the key areas for improvement when it comes to communication between highly technical people and stakeholders.

There is no doubt that technical people are the ones that turn ideas into reality. Whether you’re an artisan programmer, an innovative DevOps engineer or an automation testing genius, we all make it happen.

But we also have project managers to answer to. They’re the ones who keep us on track and are keenly interested in making sure we build the right thing on time and on budget. While you may be technically proficient, many applicants have been denied a job offer because they lack the ability to communicate effectively to their managers and other stakeholders.

The reality is that when you’re in a large-scale project, silo working is not only unlikely but undesirable as it can lead to ivory towers being built which later on incurs rework costs.

So how can we communicate effectively to stakeholders and instil confidence in them?

From my own experience here’s some things I’ve picked up.


One of the major benefits of Agile methodologies is to encourage synergy between team members which is impossible without good listening skills. This seems like a really obvious thing to do but you’d be surprised how little people work on this skill and how often a question is misinterpreted.

A manager can ask a question like “how many web pages have been completed so far?” The developer then responds by talking about content issues, javascript bugs, browser compatibility etc.

While those issues are important, it doesn’t answer the question. The purpose of the question was to ascertain how many web pages have been completed. That answer can either be a number or an honest “I don’t know”. Once the question has been answered, then you can provide your justification. This allows your manager to get a clear and concise update and leave open the opportunity for clarification.

Listening to the question can also save you time and expended effort. Typing up a well-worded email that doesn’t answer the question wastes everybody’s time. And delivering work that nobody wants can demoralise a team.

If you need clarification, don’t be afraid to ask. Seeking clarification first is much better than delivering unwanted work later.

In a job interview, listening to a question is vital. This is your opportunity to show that a company can confidently put you in front of a client. It frustrates interviewers to see someone who is technically proficient but a poor communicator.

When asked a technical question like “What is Polymorphism?”, I like to answer it by stating what it is and then providing an example.

“Polymorphism is the ability to process objects differently based on their data type or class. It is also the ability to re-implement the methods of a derived class….

An example of this is a Dog class that can have its ‘Bark’ method overridden by the Sub class “German Shepherd” to have a different kind of ‘Bark’ message.”

In this example, I have given a theoretical definition of polymorphism and then shown how it can be practically applied. This shows that not only do I understand the concept abstractly but I can also show how it is useful.

Listening to your team members is vital whether it be in a daily stand-up or scrum. More often than not there will be a cross over in workflows and people in your team may be working on a feature that affects your work. Listening to your team members can also give you the opportunity to help them if you can.

“We have two ears and one mouth so that we can listen twice as much as we speak.” Epictetus

Communicate Progress and Blockers

When on a project, you should never work in isolation, even if you are the only one working on a task. To give your team lead confidence that a project is on schedule, provide regular and concise progress reports.

‘Regular’ is relative to the scope and urgency of the project but it should be often enough to report significant progress. This will also give you the opportunity to communicate issues that you may be facing early on so that it can be dealt with as soon as possible.

The people you report to may be able to help you by pointing you to subject matter experts who can help you or tools that can solve your problem.

Regular reporting also can show your project leads if you are on the right track and if the right tasks have been prioritised. In so doing, leads can reprioritise your tasks or discuss your course of action if they feel it goes in the wrong direction.

The cost of rework can be unacceptably higher if a solution is developed in isolation.  It may be delivered on time but often fails to meets requirements.

The following example shows a status report that concisely defines subtasks, the ETA, status, duration and comments:[/vc_column_text][vc_single_image image=”2098″][vc_column_text]This table is easy to update as opposed to writing a paragraph every time status is required. The table can also be used by your leads to easily provide status to other stakeholders.

Copy the right people into your email so that everyone can be updated at once, avoiding the need to make duplicate communications.

If you’re working with agile planning and tracking tools like QABook and Jira then regularly updating your tickets is just as important as your team can get up to date information without having to come to you directly. Team leads can then rely on your updates to produce accurate burn down charts and other useful metrics.

Know Your Audience

There are some people who are technical and there are some that aren’t. There are some who are details orientated and some that are more headline orientated. In any case, know your audience. As you get to know your colleagues you’ll soon find out what information they are trying to get when asking you a question and what information they consider important when they are communicating with you. Try to tailor your communications accordingly so that they can better understand you and you can better understand them.

Talking to a non-technical manager about thread safety issues when all they are really interested in is an ETA on a feature is not going to get you very far.

Knowing your audience can lead to more efficient communications and allow you to tailor your conversations so that your concerns can be clearly communicated to the people you answer to and resolve issues quickly.

For example, if there is a bug in your code that is causing a problem, rather than explaining the details of the bug, it might be better to explain the impact the bug has on the deliverable.

Another instance might be when you feel prioritisation of tasks have been incorrectly set, then expressing your opinion on the impact of that with respect to the project timelines. This might better than talking about the technical impact.

When dealing with a more technical audience, it might be more appropriate to discuss design decisions when performing a task and why it is better to use one approach over another.

Be Concise

Nobody likes to read a page long email in order to get an answer to a simple question. As you are probably busy getting your own work done, I’m sure you want to spend as little time as possible writing emails or giving status reports.

Less is more. Answer the question, provide context if needed and provide any necessary references.

A picture says 1000 words. If you can show a screenshot to describe a situation, do so. Rather than pasting in the entire stack trace, copy in an extract and attach the entire stack trace as a file for reference. If you are talking about a list of things that need to be done it might be good to use a bullet pointed list rather than writing it all in one line.

When updating a kanban board, being concise is ideal as you can avoid having a bloated ticket that team leads find difficult to read.

Being concise is also important in a sprint retrospective. Feedback needs to be given accurately and specifically to make sure than the next sprint runs better than the previous. When in a retrospective, talk about things that can actually be acted upon and ideally be measured for future improvement monitoring.

Spelling, Grammar and Confidence

I’ve learned the hard way how embarrassing it can look to communicate to senior staff with spelling mistakes and bad grammar in an email. It can impact your own reputation regardless of your technical proficiency and it can even cause clarification emails to be sent back to you wasting further time.

Proofread your emails and don’t rely on spell checkers as the sole form of QA. Get your peers to read important emails if need be. Speak confidently and clearly with verbal communications and minimise slang when giving formal presentations. In a globalised economy, you are likely to talk to key influencers from around the world who may not understand your culturally specific colloquialisms.

In conclusion, your communications should be tools to get good quality work completed efficiently. They are a window for people to see how skilled you are and how valuable of an asset you are to their business. Communication should be a platform to success not a hinderance.

“The single biggest problem in communication is the illusion that it has taken place.”- George Bernard Shaw[/vc_column_text][/vc_column][/vc_row]

Found this interesting? Why not share it: