Communication Challenges in Agile Project Management

Communication is a key element of the majority of actions undertaken in both private and professional life. If we know how to do it efficiently in business, we are able to build a strong brand and gain the attention of our co-workers and – what is more important – our customers.

Therefore it is highly recommended to identify the communication challenges likely to occur on our way. This is especially true for Agile environments, where cooperation is needed to succeed. Once identified and understood, it is easier to overcome the obstacles by finding a dedicated solution to a specific problem and improve the work quality significantly.

Their research, our survey

Since it is such a crucial element of each project, there have already been several studies checking which factors are most bothersome while working in Agile.

Software Advice published a great research on How Team Members Prefer to Communicate on Virtual Projects. Project Management Institute explained why communication has the essential role in their extensive report. Olga Kouzina discussed communication for Agile teams in this brief (but very interesting) blog post. We can go on and on, as there are countless great resources about the importance of communication!

Our idea was to confront them with our working environment in order to validate them in the real world. Thus, we conducted a survey, and this way we discovered which issues are the most important to address in our case. The results are presented below:

According to the Pareto rule (roughly 80% of the effects come from 20% of the causes), it would be sufficient to start with the top 3 and be able to see the results. That’s why we aimed for finding solutions to the three biggest problems.

Challenge #1: Miscommunication of requirements.

It is not really possible to eliminate this issue completely, we all know that.

However, it is crucial to minimize the risks of it’s occurrence by taking care of each detail from day one of cooperating with a customer. Therefore it is important to anticipate possible miscommunication and prepare a plan, which will be followed from the very moment a customer reaches out to the software house.

A company comes up with an app idea and presents vast requirements and features to be implemented. They give you the life-time plan for the project and the detailed plan of the game we will be playing for the next couple of months.

First of all, the concept for the application should be mature and entirely ready at the moment when the team writes the first line of code.

Even though it may seem crazy, your customer must be able to explain the business intentions behind every piece of functionality in his app. This way the team can help to define the milestones needed to achieve the global plan, realize the idea and start working on it straightaway without any further misunderstandings.

Having the global plan upfront reduces the risk of a miscommunication of requirements – the first phase of the project consists mostly of talking and understanding the project. Therefore both sides have their minds more open than later on, when they are more focused on particular tasks and get strictly technical. Understanding the business context at this moment is crucial, so if there are any questions that need to be asked, they concern the practical part of the work and not the concept itself. To track the requirements from the very beginning and not to miss any detail mentioned at any moment of the project, remember to assure the proper documentation, which is the subject of the next challenge.

Challenge #2: Lack of proper documentation

The documentation should be created the very moment that requirements are defined and then updated on a daily basis with all additional information.

When everything is defined and the aim is fully understood, the first result of the meeting should be a detailed step-by-step plan showing the order of feature development. If this is done properly, it embodies the great skeleton of the project. This document should be extended day-by-day with detailed specification of each feature. Remember not to multiply documents, but to have only one, which constitutes a Single Source of Truth (SSOT). It is understood as “one source [of data] that everyone in a company agrees is the real, trusted number for some operating data”. Following this concept, there should be only one document, but it should cover absolutely everything that is related to the project and represent a source of all answers if someone is in doubt.

If the document does not answer the question and the developer needs to clarify something with the customer, the outcome should be put directly in the specification for future reference.

Challenge #3: Different working hours.

The issue of the customer being located in a different time zone cannot be directly resolved – it would mean that the company would close for the international market outside of Europe. This would not make sense business-wise.

It must be accepted and the way to make it easier to accept would be to talk with the team and take care of their positive attitude, because in such a case, good posture is already half of the success.

Nowadays there are many different tools, such as Jira (which I personally like the most), to manage the priorities and have a clear overview of work progress at any time. With a bit of effort from both sides, the difference should be manageable and easier to handle.

However, the part of the problem that definitely has to be addressed is the working hours difference not related to the customer’s location, meaning the team members setting up their working hours on their own. In such cases, it is quite common not to have the entire team available at the same time. As a result, it might be frustrating while trying to debug an issue and not have the right people available. It is important to react before frustration reaches a dangerous level and people turn on reciprocal aggression. Scrum is all about teamwork and thus it is the role of Project Manager to anticipate the crisis.

The best approach to start with would be to set up core hours, however it should not be imposed but rather consulted with the team. The first step should consist of asking the team what their preferences are, as there rarely is one “fit them all” solution. Therefore it would be for the best to get feedback from each person separately. For example, by sending an on-line form with the above-mentioned values and a field for their input for each of them. It should be determined straight forward that the expected answer is a range in order to leave some space for manipulations and find the optimal solution.

Once all responses are in, the Project Manager should confront them and extrapolate the core hours that all team members are available. The next step is to optimize the core hours and possibly extend the quantity of shared hours. It should consist of negotiations and the genuine talk with the team - it is crucial not to impose anything – people need to feel their opinion matters.

If a consensus has been reached and the hours setup are the best possible, it is important to put the final table in a visible spot, so everyone can see it at any time – there is a big chance that such a public exposure of one’s timetable will make that person kind of obliged to stick to it.

In case the team is not entirely local or there are part-timers to consider, the approach should be similar – the difference would be in a medium of communication, so most suitably – the conferencing platform. For the part-timers it is necessary to communicate to the team when precisely this person will be available. It may happen that there would be days with no core hours, but it should not be such a big issue if everything is well communicated and it is compensated on the other days.

Another thing to possibly maximize the shared hours and take the best out of it, would be setting up daily meetings either at the beginning or at the end of the core period. It will not distract the team from the goal and yet will enable them to discuss everything that needs to be discussed and boost the productivity thanks to shared knowledge.

It will all fail anyway if…

To sum up, the things listed above are kind of unavoidable at some point during each project. Thus, we should now understand the problem and have a trick up our sleeve in case they occur. We also need to remember that they are all related - ignoring any of them and focusing on another may come back at us at the least favorable moment and ruin the entire plan.

However, there is one major thing that must be planted in people’s minds - we are a team, and we should act like one, no matter what the conditions are and no matter which factor is driving us crazy. Having that, we can overcome every obstacle.

One for all, all for one!

If there are any obstacles you encounter in your everyday work, please share them in the comments section! Your feedback and insights are invaluable for us.