remote_team.svg

Management Practices

Wise insights

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.

![Remote team management tips task prioritization](https://wise-site.fra1.digitaloceanspaces.com/Management_Case_Study_3_9e822a2f61.svg)

### 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. 

![Remote team management](https://wise-site.fra1.digitaloceanspaces.com/meeting_nobackground_5da6af6dc0.svg)

### 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.

![Communication in remote team management](https://wise-site.fra1.digitaloceanspaces.com/chat_nobackground_c3a1b973d6.svg)

### 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.

![Delivering features while working remotely](https://wise-site.fra1.digitaloceanspaces.com/test_cases_nobackground_7aa173240a.svg)

## 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.








Sharing our experience of how to manage a team when requirements and prioritization for the project change almost every day.

How to Manage Remote Team in Dynamic Environment | Case Study

Check out how to manage a remote team when requirements and prioritization for the project change instantly.

How to manage remote team in increasingly dynamic environments

communication_model_main.svg

At Wise, we believe effective communication is the key factor that influences the outcome of any project. Be it collaboration with a client, teamwork on the in-house startup, or the company’s employer brand initiatives. Yet, usually effective communication is hard to measure and even harder to establish.

In this post, we’re reflecting on how communication has transformed in the outsourcing sphere over the last few years. We’ve been developing our clients’ [custom software](https://wise-engineering.com/case-studies/) and launching in-house products for over a decade now and observe some distinct transformations. Let’s discuss communication models in today’s software development outsourcing as well as reasons that forced the changes.

## Client-manager communication model

Usually, when browsing for an article on communication challenges while outsourcing you’ll read about time differences, cultural peculiarities, and poor language knowledge. These factors are, undoubtedly, important, yet, if you collaborate with an experienced and professional outsourcing team, rarely impact the project outcome that much. What then makes some of the projects succeed and others strive for existence? 

Over the last decade, the approaches to building and launching tech startups have evolved significantly. We no longer launch ideally implemented, bug-free products, plan all the functionality we’ll launch 3 years in advance. Instead, we test hypotheses right from the start, showcase clickable prototypes, get users’ feedback, and proceed with those products or features that get the highest evaluation. 

At the same time, the communication approaches in custom software development companies often remained the same as if we were still working in the fixed-projects-only reality. Historically, the outsourcing partner was hired for a set scope of work that had to be delivered in a specific time frame. The managers on the client's side used to communicate with a project or account manager from the outsourcing company who kept them up-to-date on the progress. We call it the client-manager communication model.

![Client-manager communication model](https://wise-site.fra1.digitaloceanspaces.com/communication_model_client_manager_e916e8da6f.svg)

## Client-team approach to software outsourcing

With new approaches to product launch, flexibility became the key success factor for most startups. By flexibility, we mean the ability to pivot the project on the go, adjust functionality based on the client’s expectations and feedback. For this, the old approaches to communication between the client and outsourcing team simply don’t work.

That’s why it is vital for the startups who [outsource MVP development](https://wise-engineering.com/expertise/mvp-development/) to be able to communicate with each member of the remote team individually. Because when an unexpected problem arises, people who are the closest to it can get the best solutions faster. That is what the client-manger model lacks – the ability to talk to the right specialist, the minute you need it. 

At Wise, we understood the problem of the communications via the manager long ago and rarely used it within our project. Today, what we advise our clients is to use client-team communication right from the start, no matter if it is a new product that we launch or scaling existing one with the new functionality. It does not mean the team operates without a project manager on our side (though sometimes it does), but that together with the PM the client can talk to the whole team or each specialist directly.

![Client-team communication model](https://wise-site.fra1.digitaloceanspaces.com/communication_model_client_team_cc0172362f.svg)

## Two models compared

The infographic below illustrates how the business logic behind the startup development has changed. The key difference lies in the project planning and scope. You no longer need to know how to fully realize the functionality you have in mind, or have the comprehensive list of features you need to implement. Instead, you can communicate your business goals and key problems your product addresses, and together with your outsourcing partner decide on the best solutions to make those goals achievable. One condition only – to be able to create a product you’ve envisioned, engineers need to discuss it with you directly.

![Two models compared](https://wise-site.fra1.digitaloceanspaces.com/communication_outdated_business_logic_ef347cf5e1.svg)

## Self-organized teams in outsourcing

Another phenomenon that was aroused by the change of the business development approaches, is the new paradigm for the outsourcing team organization and the rise of self-organized teams in the sphere. 

Usually, when this topic is discussed it is spoken of in the context of in-house teams. Though the covid pandemic has indisputably accelerated the remote-work trend and the way teams collaborate has been changed fundamentally. Self-organization became an even more critical aspect for all teams seeking efficiency. No matter if they work in-house or are part of the outsourcing project.

**What is a self-organized team?** It is a team whose members have the freedom to make decisions within their domain of expertise and not wait for their manager to assign tasks. A self-organized team has a clear vision or a product broader picture and does not expect detailed task descriptions in Jira. They communicate directly with the product creator and stakeholders and suggest solutions to the problem the management faces or users report. 

Simply put, this is a team that has the competence to accomplish the work without depending on people outside the team. Let’s discuss why this type of teamwork is beneficial both for the engineers and the business owners.

### From developers’ perspective

- In self-organized teams, people are mission-driven and understand the value of the product they build, as well as their own impact on its development. This also increases their level of involvement and promotes the ownership attitude.
- Engineers in self-organized teams tend to stay in the project longer as the process is dynamic and never becomes monotonous.
- When engineers take the responsibility for the decision they make, they are more eager to go the extra mile for their end-users. This helps them grow business thinking and changes the overall approach to product engineering. 
- Because each team member is involved in communication, the chances of spotting any miscommunication at the early stages are much higher. And it is always better to correct the concept of the feature implementation than to change the logic behind it entirely after it is almost ready.

### From the business owner’s perspective

- Working with a self-organized team you can finally minimize multi-tasking and micromanagement that eats up an enormous amount of time.
- With tech experts who handle the tech part, you can focus on the product strategy, hypothesis testing, and product growth that really deserve your rapt attention.
- To function effectively, self-organized teams should consist of experts in specific spheres. This also ensures all the tech-related decisions are made by people equipped with the best possible knowledge.
- With the clear communication loop established, all the people involved can take initiative and act faster. This helps to achieve frequent product delivery and fast product iterations.

## Wise approach to communication

Clearly, not every outsourcing team is ready to work within the self-organization paradigm, and the formation of such a team does not happen overnight. At Wise, we’ve been launching products for our clients for more than 15 years and noticed that to be able to effectively self-organize, a team should be working together for a significant amount of time. In our case, 60% of our teams work together for 3+ years and that’s the minimum time that is required. We also have teams that work together 5+ and 10+ years, and their achievements in self-organization are much more impressive.

Our project managers shared these handy tips on how to collaborate effectively with a self-organized team:

- **Minimize top-down management of tasks and activities.** Instead, you can build your cooperation model on partnership and strategic collaboration. For this, find a team that would consider your success their own achievement.
- **Do not confuse brief communication with clear communication.** Sometimes meetings last longer than usual. Sometimes an extra meeting is needed. The same as you now stay flexible with the project scope, adjust the communication schedule on the go. Our engineers usually request additional meetings if there are important topics to discuss.
- **Do systematic health checks to see if everyone from the team knows what to do and what is expected of them.** We usually do it with the *Roles & Responsibilities* exercise when each team member writes down what he/she expects of the teammates and sees what is expected of him/her. The points that do not coincide gets discussed.
- **Keep people in your outsourcing team informed.** The more the experts you’ve hired are up-to-date with the overall project situation, the more context they receive, the better solutions you’ll get on the outcome.
- **Clarity is the magic pill for effective communication.** Before you start moving forward with your outsourcing team, specify how you see the product development in the long perspective, how you measure success, what traction you expect, and what hypotheses you are trying to test. 

## Key takeaways

Software development outsourcing is a strategic initiative that allows startup companies to launch their product MVPs to market faster and validate ideas that will receive further investments. To succeed with the project you outsource, look for a custom software development company that’s open for dialogue, and would care about your product mission.

At Wise, we bring together engineers with deep expertise in [custom software development](https://wise-engineering.com/expertise/) and work in self-organizing teams. We’d be happy to discuss your business ideas and see how we can bring them in front of your end-users as fast as possible.

In this blog, we discuss communication models in today’s software development outsourcing as well as reasons that forced the changes.

New communication model in software development outsourcing

Learn how communication with the remote team has transformed and how it affects the outsourcing sphere.

Wise Engineering Blog

#management practices

How to manage remote team in increasingly dynamic environments

New communication model in software development outsourcing