Tips & Tricks of Building a Remote Tech Team

As the pandemic made most of various companies change their work style, the establishment of a good remote team became a necessity. However, even if it wasn’t for the pandemic, the prosperity of a remote era wouldn't take too long. Bursting with the advantages compared to in-office work, managing a remote team will let you connect talents from all over the world, alongside making your workers’ experience unique and delightful.

What is a Scrum Methodology?

To put it simply, Scrum is a framework that allows teams to productively create value with the use of adaptive solutions for complex problems. According to it,you can combine mandatory structure with additional elements for the experience that exactly fits your team.

Scrum is a representative of agile values, thus follows 4 main rules of the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

As a project managing framework, Scrum supposes self-organised remote teams providing a finished product within the fixed terms. You may already know that the methodology itself consists of three key concepts: roles, events and artifacts.

Even though you may be already familiar with roles and rituals, we’ll take a fresh look at them and explain how you can adapt scrum tools to a remote work environment.

Scrum Roles

Regarding the number of members in a scrum team it is recommended to adopt Amazon's “two pizza” rule: “A Team should be no bigger than two pizzas can feed”. On average this means your team should be in range from 7 to 10 people. However for effective remote team management you may need to split it even in smaller sub-teams up to 4-6 people. Generally a scrum team, consists of three main roles:

Product Owner (PO)

Product owner is the one who presents all the requirements from stakeholders and customers to a development team. He must have a clear vision of the product to create a development roadmap as conflicting priorities and unclear directions are one of the common challenges. Also, his task is to organize user stories and prioritize them by story points.

When working remotely, a PO keeps all his responsibilities regarding prioritization and communication. However, since communication in distributed teams may be challenging, it’s important to implement tools and practices that streamline it:

• Agree on communication mechanisms for different purposes. For example, your team may record the demo video for the PO once in 1-2 weeks, hold weekly calls, and exchange information about specific backlog items in whatever tools you use (e.g. Trello or Jira) so all the information about this item stays in the same place.
• Delegate. In small companies, CEOs are usually the ones who act as POs. Yet, with all of the responsibilities that they have on the growth side, they often unintentionally become a bottleneck and slow down development. To avoid this, CEOs-POs should start delegating short-term decisions as soon as possible.
• Development Team

Development team is a group of specialists that fulfills every technical task that is required to finish the product. The “developer” role in scrum isn’t limited just to software engineers; UX/UI designers, QA specialists and DevOps engineers can also be a part of the Development Team.

Transparency and self-organisation are the two core things you should promote in your distributed development team. Later on, we’ll provide you with some tips and tools on how to build up these values in your company and keep your remote workers productive.

Scrum Master

Scrum master is a so-called work coordinator for the whole scrum team. He lets a product owner and a development team members work without any distractions and reduces the unnecessary communication for them to focus on their projects.

Every part of communication with stakeholders outside the scrum team itself lays on his shoulders. Also, he is responsible for coaching the team and creating an environment that supports scrum.

Scrum master in a remote environment is a “playmaker” that faces even more obstacles in scrum project management than regular team members. The top skill that a Scrum Master needs to master when working in a distributed environment is asynchronous communication. They may do this by adopting following practices:

Scrum Events

Sprint is a basic unit of work that stands in scrum as one iteration. Sprint is a time period for solving tasks and getting a predetermined part of a project done by a scrum team. As a rule of thumb, sprints last 2 weeks, even though some companies stick to one- or three-week-long sprints.

However, just like any other part of the scrum methodology, sprints and related activities need to be adjusted to the specifics of remote work:

Sprint Planning

Sprint planning is a scrum event that marks the start of a sprint. Planning the sprint determines the amount of work for the upcoming time period, its duration, the starting point and the ways to solve the tasks.

In a remote environment it gets harder to align everyone and to provide the right amount of airtime for all of the team members. To reach productivity and not to turn the meeting into a mess of thoughts, some liberating structures may come in handy. For example, a 1-2-4-All technique allows you to generate and filter a lot of ideas by making team members share their thoughts in separate video conferencing rooms constantly changing the formations.

Another common issue of online sprint planning sessions is that they may take up too much time.

A good way to address this issue is to have a predefined meeting agenda. Distribute it at least one day in advance, so the team can have a clear picture of what’s going on and offer their own amendments. This will reduce the number of unexpected questions and ensure a smooth meeting.

Also, you can opt for work in smaller groups. Sprint planning in groups of 4-6 people instead of 7+ can create an environment where people are not so easily distracted and can speak up without taking too much time.

Sprint Review

Sprint review is an event that is held at the end of a sprint before the retrospective part. During review, a scrum team demonstrates the results to stakeholders and gathers feedback. The purpose of this event is to celebrate success, develop a culture of how to deliver work as well as make sure the team is on the same page with other stakeholders..

To make sure your remote sprint review goes well, we’ve prepared a few tips:

• Have an agenda. Since you have access to planning environments, prepare a review agenda based on what’s been planned. For your convenience, you may organise it as a checklist or a survey to be used by stakeholders during a sprint review.
• Liberating structures. With the use of liberating structures you are able to create a great meeting experience and unleash local wisdom of your team. For sprint review, we recommend you UX Fishbowl as a liberating structure to create a comfort zone for discussions and ideas generation. According to this technique, you create two groups of meeting attendees (bowls): a small and a large one. The small bowl shares experience regarding the topic while the large one listens carefully and generates questions. The main point of a structure is to create a flow of experience, idea and opinion exchange by constantly changing the bowls’ line-ups.
• Collaborate with stakeholders. To get a better understanding of sprint results from another point of view — foster an active collaboration with stakeholders. First of all, ask them for proper feedback to understand their way of thinking regarding what was done by far. After receiving their verbal suggestions and requests — spend some meeting time updating a product backlog with the direct participation of stakeholders. Thus you are preventing any crucial project misunderstandings from happening in future.

Sprint Retrospective

During the sprint retrospective a team discusses what went well during the sprint and what should be improved in the next sprints. The main point of this event is to make the upcoming sprint more productive than the previous one.

Let’s take a look at some tips for a productive remote sprint retrospective:

• Psychological safety. For a remote retrospective to be productive, first of all, you need to secure the psychological safety of the participants. Which means, that no punishments are coming for being sincere and team members can freely discuss the flaws and perfections of the previous sprint.
• Involve everyone. After creating a friendly atmosphere make sure everyone is involved and doesn’t feel out of their element. Showing that every opinion is appreciated is a key to a constructive resite of what you have already done.
• Successes should be discussed. Review successes as much as you review failures. This will let you understand better what lays behind the accomplishment in your projects and what is needed to repeat the accomplishment in your next sprints.

Daily Scrum

Daily scrum is a short event for every member of a scrum team. The main point of this everyday meeting is to track the progress of achieving sprint’s goals and applying any small changes to the plan or backlog if needed.

The structure of daily standups consists of 3 questions:

1. What did you work on yesterday?
2. What are you working on today?
3. What blockers do you have now?

As daily scrum is the most frequent event in the whole methodology — it requires a proper organisation.

We have some recommendations for you to make working with a time zone difference easier:

• Ensure you have a working hours overlap with your main time zone. Even as a distributed team, you’ll likely have a HQ or a decent part of your team located in one time zone. Make sure that all other team members have ~3-4 hours of their working time overlapping with your preferable time zone.

• Get to know the available working hours of every employee. It’s important to arrange a transparent schedule for the whole team, so everyone can set time when they are available for communication. After doing so, your team members can use any time zone conversion tool to find when their working hours cross for team gatherings. Some of the tools you can use are Timezone.io and World Time Buddy.

• Let the asynchronous communication in. Managing a remote team with different time zones will get you to a situation where your employees won't be online at the same time. In times like this — asynchronous communication will let you deliver the information to your colleague in the most suitable time for him. With the use of Slack, Trello, Google Drive you can create a digest of important information so that it reaches every worker without the need of being online simultaneously.

Feeling of social isolation

Although a remote job is much more flexible and time-saving for employees, it can also make them feel uncomfortable in a certain way. Constant working on a task alone may cause several scenarios:

• Workers may feel distant from the team because of the lack of social interactions, thus not feel themselves involved enough.
• When an employee faces a wall in their assignment they may feel like the only ones struggling with it. Due to the lack of physical presence of a team whatsoever, employees might not know who to ask for assistance.

Luckily, there are many solutions for these scenarios. For both cases it is great to include team building meetings to improve connection between the teammates such as:

Increased distractions

Distractions of your employees is something you can face in every working format. However, an office environment creates less opportunities to switch one’s attention to something else and helps to stay focused. A distant job also requires from an employee some self-organisation and focus skills, because not every person is able to resist the distractions that often occur while working at their homeplace.

There is no silver bullet for this problem, yet, there are some tips on how to help workers stay focused:

• Use time tracking software. It will help you to analyze how workers spend their time and where they might need your help to hit the goal faster. Software examples: ProofHub, DeskTime.

• Make regular call-ins and daily check-ins to see the constant progress of the task. Thus, along with maintaining a decent communication level in your team, you can determine if an employee is struggling to accomplish a task and needs some help.

• Learn the basics of asynchronous communication. The point of this communication is not to chase the need of your recipient being available at the time you send a message. Vice versa, you can take your time working on a task and reply to an email or a message when you are done or are not in “the zone”. This technique will let employees not be distracted by texts when they are non-urgent and can take a while to be responded to.

• Reduce the approval layers. Try to minimize the level of approvals your employees have to proceed before getting back to a task. Unnecessary approvals only interrupt the working flow of your team and waste the time that could have been spent on upgrading the product.

Lower motivation level

Always working remotely, employees have to deal with motivating themselves. As solving tasks from home creates a relaxing atmosphere, it is important for you as a manager to help your team to stay motivated. Let’s acquaint ourselves with some tricks to keep your team’s motivation at its highest:

• Constructive feedback over the destructive one. The reviewers must acknowledge one simple fact: “You are reviewing a code, not a coder”. Do not let your employees provide any kind of assumptions regarding the partner's personal qualities. Constructive feedback about the code is a priority, nothing else matters.

• Review no more than 400 lines of code at a time period. According to a SmartBear study of a Cisco Systems programming team the peak productivity is achieved when around 200-400 lines of code are reviewed at a time. It is not recommended to review more than 400 lines of code per session so that the productivity stays at its highest.

• Do not review more than 60 minutes per session. The best approach to this process is to conduct a review more often but for shorter periods of time. After 60 minutes of reviewing a person’s attention level for details drops significantly, making the further revision less efficient.

• _Decide how to split codes beforehand _ As we stated in a previous part, it is better to make reviews as short and effective as possible. However, to achieve that, you need to rationally split the code in a way that doesn't ruin the integrity of a part. We recommend you spend some time deciding how to divide the code into parts before giving out a task.

Code review tools

There is a variety of tools used for code reviews. The most notable examples are:

• Crucible
• GitHub
• Review Board

If none of those suit you for some reason, here are some alternative options — Gerrit, BitBucket, Code Climate.

How to Manage Technical Debt in a Remote Team

The first thing you need to know: technical debt isn’t something you need to be afraid of. Of course it’s better not to have any debts, but this is the price you pay for prioritizing product delivery speed over the quality control.

To have a better understanding of what a technical debt can be and how it is managed in different situations, we recommend you to check out the related article in our blog: