How to manage remote team in increasingly dynamic environments

Working with teams scattered across countries and time zones is challenging enough. Moreover, the pressure doubles if the project requirements and priorities are unstable and new tasks arrive instantly.

In this blog post, we are sharing our experience of replacing traditional approaches to project management with more flexible alternatives. Here’s how we organized work for design, development, and QA teams from the USA, Ukraine, and India and what lessons in remote team management we learned along the way.

Challenges we met

It all started as a small project where the development team located in Ukraine and QA engineers from India worked together. Stakeholders from the USA had a basic vision for the project scope and tended to change requirements when the features were already in development. Within the small team, we managed to resolve all routine questions quickly via chat, adapted processes on the go, and the lack of long-time planning seemed like a challenge we could overcome.

Yet as the project scaled and more people joined, what seemed like a working solution turned into an organizational nightmare. New requests and tasks arrived every day. Most of them were handled by the Ukrainian team, which started work 3.5 hours later than the Indian Quality Assurance team. This meant the QA team needed to redefine their working day scope in the mid-day. No need to emphasize how stressful and frustrating it was for everyone involved.

Approaches we adopted

Stuck in the communication gap, we started to adjust project management approaches to the situation and looked for solutions that would allow us to work despite the time difference and our conflicting schedules. We implemented traditional scrum methodology and created a document with the list of all tasks the Indian QA team had to do during their working day.

1. Updates prioritization

Very soon, the idea with the document containing QA tasks failed. The client expected us to be more agile and flexible than we thought. For example, the tasks that were of the highest priority in the evening got substituted by the other more urgent ones in the morning. There were also changes throughout the day. Finally, it was clear – we need an approach that would allow us to work effectively in this dynamic environment.

This is how we started dividing all new tasks into three groups:

• Big features
• Urgent small changes
• Not urgent small changes

Urgent small changes were implemented right away. Big features were discussed, estimated, and scheduled for further development. And not urgent small changes went into the backlog.

Prioritizing updates helped us start planning our work in the long run. We also were able to provide the QA team with ETA for features in development and the amount of work they would get. As for the urgent tasks, every sprint had a buffer time reserved for their implementation.

2. Daily meetings

Our initiative of holding daily scrum (stand-up) meetings failed as well. We received unsatisfying feedback literally from everyone. People complained about connection issues, unclear accents, communicative skills, and sometimes even about feelings of being unrelated to the topics (read: they were bored).

It was obvious that our daily syncs were just a waste of time for 10 to 15 people and this is why they got canceled. We initiated meetings only for the Ukrainian development team instead. This turned out to be very productive for us.

To address the open question with the updates for the Quality Assurance team from India, we experimented with organizing meetings for the QA team, Team Lead, and Project Manager. After some time, we analyzed the effectiveness of such daily synchronizations and decided to hold them twice per week.

This is how the daily syncs transformed into the QA/PM meetings held twice a week and weekly QA/TL meetings. PM kept the QA team informed on the priorities for the current week, feature delivery dates, and plans for the functionality changes. TL, in his turn, talked in-depth about tech details and project improvements.

3. Slack channels

As the project started, there were two separate Slack channels: one for the development-related questions and one for QA issues. When a Project Manager joined the team, she was the only person following both channels and unintentionally became a single point of failure.

Meanwhile, to clarify details, project members used direct messages that caused the lack of transparency. What’s interesting, we didn’t notice the problem until the new member who joined the team pointed it out to everyone.

Funny as it is, with the chats we did exactly the opposite of what we did with the meetings – we merged them. Now the QA team and developers discussed all the tasks-related questions in one Slack channel. This brought transparency and allowed the whole team to be on the same page.

4. QA planning

When developing new functionality, the chances are high that new features will affect the parts not directly related to the ongoing project. With the agile development flow and instant feature updates, we were always at risk of bugs appearing in the most unexpected places. To prevent such situations, the QA team conducted systematic regression testing.

Having an intuitive QA flow was enough for quite a long time. However, as the project grew and more features appeared, the quality of regression testing decreased. So we started a regression test plan – a document with an extensive list and descriptions of what and how should be tested, including the responses received. So, the QA team started to mark the tested functionality in the document and comment on the task.

This way, when developing a new feature, we also started to add a new test case for regression. Even though creating such a document was rather time-consuming, after it was ready, the teamwork improved significantly. And again, a person who initiated the idea of the QA plan was a new developer who joined the team a short time before.

Lessons learned

Today, you’re just as likely to work with someone from a different part of the world as you are with someone in a different part of your office. That is why understanding how to manage remote teams is this vital. Our Project Managers have vast experience in setting up processes for teams scattered across countries and continents, and this story is just the tip of the iceberg of all the things we’ve tried.

What is the key takeaway here? The truth is, there is no magic one-fits-everyone approach. Sometimes even the most popular practices don't benefit your team. So, start small and analyze the effectiveness of every step you implement. Adopt methods one by one, see how they impact your team, and customize them to your needs.

Here are also some handy remote team management tips for the start.

• Be attentive to feedback. This is not necessarily should be an official form or meetings. People tend to talk about things that look wrong even if they are not asked. Your task is to gather this feedback and use it wisely.
• Ask newcomers. If the processes are arranged in the same way for months or years, you and your team do not notice things that can be optimized. This is when the newcomers’ option becomes precious.
• Encourage everyone’s initiative. Even if you’re a very experienced manager, sometimes your team knows better. Let them implement ideas. This will help them work better together and will lift the team’s spirit.
• Ask questions. Even if everything works well, always leave some room for doubts. There are always things you can improve. If there are a lot of problems, when looking for the weak points, try to collect as many opinions as you can.
• Do not stick to one methodology. Rules and guidelines are important. Especially when you only start. Though as you move forward, if the approach is ineffective, don’t stick to it. Adopt other practices, miх approaches, let them evolve, and select what works best for your team.
• Be aware that routine affects culture, and vice versa. Though it may look like they are not connected, very often the best traditions, as well as the worst, grow out from the daily routine.