In IT projects, sometimes the biggest challenge is not in the code. With a lot of professionals of different specialties and authority levels involved, the pressure to meet the client’s expectations, and limited time and resources, communication can easily become an issue.
In this article, we want to share experiences working on a project with a client and the issues that we came across. See the improvements we made to make our communication more effective.
The project and the team
At CodiLime, we have experience in various projects. This article discusses one that started about 2 years ago. Our team worked with the client on an application - we supported them with frontend and UX/UI services. It involved close cooperation with the client. Based on this case, our team shares some tips and improvements that can help in communication, which sometimes can be even more challenging than coding.
How to achieve effective communication?
Good communication between you, your team, and the client requires a solid foundation of mutual understanding. That means that both sides need to know and understand the process that you will work with. When joining a new project, it’s good to ask yourself these few questions:
- Do I fully understand the communication process and the reason why it is like this?
- Who is responsible? Is there any part of communication that can become stale?
- Is this workflow simple? Can we decrease the amount of work needed for clearer communication between us?
- Can the workload be easily distributed among all team members regardless of their experience level?
- If I find any improvements, will those be used or implemented?
Once you answer these questions, you should have a clear understanding of the communication process of this project. However, even the most streamlined process may sometimes need some improvements.
In the next sections, we will explain the communication issues we've encountered on this project and how we took an iterative approach to solve them.
Real life example of a project
The structure of the project on which this example is based included the following:
- client’s representative with a technical background,
- backend developers,
- UX/UI designers,
- frontend developers,
- DevOps engineers.
The client and backend developers were based in the USA, while the rest of the team worked from Poland. The main channel of communication was Slack. We also used Jira boards synced with GitHub for progress tracking.
Here you can already suspect potential issues with cross-cultural communication, different time zones, and general difficulty with staying on the same page. Here’s how we tackled this issue.
Communication challenges and our solutions
The initial communication process was supposed to be simple. Twice a week, we held meetings at around 5-6 pm. Before each meeting, the Senior Frontend Developer would create a presentation to share on the Slack call and discuss during the meeting. This presentation consisted of approximately 15 slides with information about tasks in progress, priorities, and live requested features. The presentation also included a demo of merged functionalities. The meetings lasted around 1,5 hours.
We used the JIRA Board and sprints to manage our work, but we did not follow a strict Scrum flow. Instead, everything was added to the board. Furthermore, we made sure to keep track of stale tickets in the backlog so they wouldn't be forgotten.
The client wanted to keep a close eye on every change, so it was important for us to have clear and organized communication.
After around a month, we were able to find a few points of friction in this not-so-perfect process. Here are some of the issues we’ve encountered and how we dealt with them.
Issues with request tracking
Requests popped up everywhere - on the Slack channel, in private messages, and during meetings. Keeping track of them became an issue. As a result, the responsibility and pressure to keep track of everything fell on senior developers, who already had an assigned workload. It led to missed tickets or requests and lower confidence in communication.
Solution:
We created a separate slide for all new requests during the weekly presentation. That way, we could discuss them with the client and be on the same page. We were also able to create the next presentation right after the meeting and put all new tasks there instantly. This resulted in bigger trust and confidence on the customer's side and less stress on our side.
Disorganization in the JIRA board
The JIRA board was not managed properly, which led to, frankly, an overall mess. Every task was in the “current sprint” column, and the backlog was disorganized - there were no priorities or deadlines for individual tasks. At times, there were dozens of tickets on the JIRA board, which were unreadable and hard to track.
Solution:
We made it a priority to clean up the backlog. A special meeting was held where we updated all the tickets so that we were left with only actionable tasks. It made it easier to distribute the tickets among the team.
Uneven workload
Due to the weekly presentation, the senior frontend developer had to spend a significant amount of time preparing the slides and syncing them with the JIRA board after the meeting. It took even 2-3 hours per week to sync everything manually and to create and order slides in the presentation.
Solution:
We implemented a round-robin schedule using an Excel spreadsheet, where each developer takes turns performing tasks. This ensured an equal distribution of workload among the team.
Meetings not relevant to all the attendees
In order to keep the team involved, initially, the meetings involved the whole team - frontend and backend developers, UX/UI designers, DevOps engineers, and the client. Soon enough, we realized that there was no need for everyone to participate in the whole meeting, especially in the parts that had nothing to do with their responsibilities.
Solution:
We divided the meetings to facilitate more effective time management. The DevOps team started their own meetings, and there was no longer the dread for a long presentation and a feeling of wasted time.
Meetings were too long
The meetings took up to 3 hours per week, especially in later hours. This took away the time that the team could spend on feature development, especially taking into consideration the aforementioned problem - these meetings were not relevant to everyone.
Solution:
We agreed to divide the team during the meetings. Teams synced with each other during much shorter and more efficient meetings held the day after the weekly presentation.
Presentations were too long
It was an often occurrence that the whole presentation couldn't be covered in one meeting. Some slides were copied to the next meeting’s presentation, which elongated it even more. This created an overload on the next week’s presentation, outdated slides, and something that could be called slide debt. It was hard to find what you were looking for, and the meetings dragged on into infinity.
Solution:
We've removed unused slides, created a meeting agenda, and ordered slides. From then, each meeting had the same flow, and the presentations were nice and organized.
Communication challenges and our solutions - the second iteration
The initial changes brought some improvements. The frequency of meetings was decreased, work was distributed among team members, and the backlog was cleaned. Everything felt a bit better organized and easier to understand. But as you may guess, as time went on new issues came to be.
We still used the weekly presentation, but its necessity was questioned since we had the JIRA board. However, the presentation was a familiar flow for the client, and it was easy to understand and stay on the same page.
There was also a significant change in the team structure - some new, less experienced frontend developers joined the team. The original team members had to take on the responsibility of knowledge transfer and monitoring their work. Answering non-programming-related questions on the subject of the workflow and process itself became an added burden.
After some thought, we identified another set of challenges and introduced the following fixes.
Time-consuming presentations
Unlike we expected, using JIRA instead of slides didn’t cut down the time of presentations. Quite the opposite: moving everything to JIRA increased the workload and the likelihood of making mistakes, making it difficult to manage changes in priorities.
Solution:
A meeting agenda was established using the JIRA view. A backlog was created to prioritize tickets and add filters to the board to display statuses such as highest priority tickets and those related to epics.
Difficulties in tracking UX/UI progress
Tracking UX/UI designers' work was a challenge. The duplication of tickets between UX/UI and developers was difficult to manage and kept the two groups out of sync. It was a challenge to get the Designers to create their own tickets and keep track of them.
Solution:
To keep track of UX/UI designers' tickets, the assignment was established as the method of tracking. A ticket assigned to a UX/UI designer requires designs. Upon completion, the UX/UI designer had to unassign themselves and provide the link to the designs.
Missing information for the tickets
Creating tickets and gathering information to make them actionable was quite time-consuming. It wouldn’t have been an issue if all the necessary information was available, but it wasn’t. So there was a need to constantly request additional information, which was inefficient.
Solution:
I have established a set of guidelines for creating tickets to ensure that all necessary information is included. If someone submits a ticket that lacks the required information, it can easily be resubmitted by simply reposting it since it has already been pinned to the relevant channel.
Losing track of done tasks
We didn’t think of one important thing - keeping track of the job done. So the merged new features and bug fixes for the demo were difficult to track. It took recalling what one did last week, which is an unreliable tracking method. This resulted in omissions and mistakes during reporting.
Solution:
By adding an In Demo Review column to JIRA, we were able to effectively track and demonstrate all merged features and bug fixes during client demos. We proposed to adjust the meeting schedule. With two meetings a week - one to discuss new features and another to demonstrate the features - no progress was missed by the client.
Challenges with onboarding new team members
New developers were uncertain about what could be done and the process, which resulted in a vast amount of questions to more experienced team members. Each feature or bugfix was discussed in an off-the-process, inefficient manner.
Solution:
The solution to this issue was found by adding a new column called Ready to start in JIRA, which included designs and all necessary details.
Unclear review process
New developers had difficulty conducting proper reviews. There were many questions about how to perform testing and the location of components within the application.
Solution:
A GitHub template for Pull Requests ensured that we provided all information. We also made a commitment to include visual help, such as screenshots or videos, for greater clarity.
The review process was too long
Reviews were delayed for long periods. Due to the disproportion in new parts of code needing a review and the number of people authorized to review them, the process became a burden. There were days when the experienced developers were only reviewing new code.
Solution:
We added an Approvers field and made it visible on the board. This allowed us to designate a reviewer during daily meetings and schedule the time needed for reviews.
After implementing these changes, I realized there were additional benefits. The client trusted us more, experienced developers were relieved of the burden of remembering everything, and less experienced developers could learn faster and become more self-sufficient. It was really a win-win situation, and the stress levels dropped exponentially.
Conclusions
Maybe you noticed that the ‘Communication and improvements’ section was written twice. This highlights the importance of continuous improvement and how it should never end.
This process also improved my own confidence, reduced my workload, and helped me to communicate better with others. I encourage you to take a 10-minute break and reflect on what you can improve in your own work. Best of luck!
