Maintaining project velocity while leveraging a remote-first working model can be a difficult challenge. All too often, firms imply that “this tool” will be the panacea, when in fact, it is not a tool issue at all. When done right, distance-based development is a careful orchestration of talent.
Remote working is not new to many organizations, but remote-first or 100% remote is a new world for many given recent events. All of a sudden, we are faced with managing across multiple timezones and multiple business/personal schedules as our home and work lives merge.
In the fast-paced agile manner in which most of our teams and clients work, we have had the luxury of being able to reduce structure and planning. Now, in the extremely distanced context that we find ourselves in, we need to adapt without sacrificing too much speed or productivity.
Here are a few simple and practical tips some of our teams have learned over the years.
1 Pull Requests
In the context of a software development team, a pull request is the process of notifying others that your work is ready to be merged into a project or solution. It can act as an approval process where others review and comment on your work before accepting it.
Where an approver and a submitter work in different time zones, there is huge potential for context-switching that disrupts the flow of work. For example, if a developer submits a pull request early in their day but then has to wait several hours for it to be reviewed, the developer is forced to pick up the next story before having completed the current story. Then, when the first pull request is reviewed, the developer has to stop work on the current story and return to the previous one. This creates context-switching or multitasking, which is known to reduce productivity, especially during complex tasks such as software development. It also can lead to “work-in-progress” problems when a single developer has multiple “in-play” tasks at any one time, which is ideal from neither a productivity nor a flow point of view.
We have found that the following help to maintain velocity:
- We prefer to delegate authority to allow engineering teams in the same time zone (or on the same schedule) to request and approve pull requests rather than having a centralized client team handle all approvals. This might initially feel risky to our clients, given that knowledge of their systems needs to be learned, and trust often needs to be earned or developed over time. In this scenario with our New York-based client, we moved slowly towards the goal of having our engineering team in Portugal approve all pull requests. We allowed time for everyone to get comfortable with the approach, starting with low-risk requests only and maintaining exceptions for the most complex tasks where the client still owned approval.
- In addition, we have also employed “Pull Request schedules” to ensure that all pull requests are reviewed daily at a regular time. For example, with our New York-based client, we agreed to a timeslot that was in the morning in New York and in the afternoon for our Portugal-based team. Having a regular mutual schedule helps improve the flow of work, allowing team members to get into a rhythm or cadence, which helps to increase flow and reduce inefficiencies, such as context switching. It also helps to act as a reminder, avoiding situations where a pull request is missed or other work is unintentionally prioritized.
- It is often possible and preferable to remove the need for pull requests entirely. Once a team has formed a good working knowledge of the domain or product, with a predictable velocity and a high-trust culture, approvals become unnecessary.
2 Think Ahead
Applicable to any delivery is the risk of reduced productivity due to lost time, such as waiting for access or information. In a collocated, physical world this is still a common issue, but the cost in a remote-first world is even higher as multiple unaligned schedules or timezones exacerbate delays.
As a standard, we find it helps to publish everyone’s timezone or schedule and find mutual working hours if possible so that everyone has a chance to collaborate with one another. The key is to prioritize work that requires collaboration during mutual working hours, leaving other work to other times of the day.
This form of prioritization is the responsibility of all team members and is something we mandate as part of our process and culture.
To help it become part of the mindset with our New York client, we use a team charter to showcase that navigating multiple timezones and schedules is the responsibility of all team members. For example, as a developer, it is crucial to be aware of where you are in your current task and think of what you might need to complete it. With the knowledge of any future impediments or dependencies, our developers make requests for information or input in advance and arrange their schedules so they are available to collaborate during mutual working hours.
Although this sounds very logical, it is very easy for team members to focus on their current tasks and to miss opportunities to collaborate during mutual working hours, especially when such opportunities are very limited in duration (which is often the case with more distant timezones).
3 Technical Alignment
To help replace some of the communication opportunities that happen naturally when we collocate, we create a daily team routine that includes technical alignment meetings during the start of each relevant timezone or schedule.
The meeting is a combination of a typical agile standup and a parking lot style meeting. It provides the opportunity to address important technical topics or problems without interfering with daily standups or the immediate flow of work. It creates a space where engineers and testers can share technical insights and make technical decisions together. This crucial sharing of knowledge and ideas can be easily lost when there are only structured or time-sensitive meetings arranged. With our New York-based client and Portugal-based engineering team, it really helped to increase productivity through more collaborative and better decision-making, which resulted in fewer mistakes and less rework and technical debt.
These are just a few of our tips to help improve productivity when working remotely, but for more ideas, check out our remote working playbook
If you want to learn more of the techniques we use to build high-performing remote-first teams watch this webinar.
At Equal Experts we’ve been running a series of remote-working webinars for our teams and clients where we share tips and practices to help teams make the shift from remote-friendly mindset to remote-first. The webinars were built around the remote working playbook that we shared last year and have subsequently been enhanced to include many additional hints and tips provided by the teams as we’ve been running the webinars.
Here are some of our favourite tips to help you as you get started.
Create a “remote-working” team charter
Remember when you were onboarded at your work and were taken around the physical office? Now you’re working in a virtual office, be intentional about onboarding your team into your new virtual office.
Discuss how your team plans to work together. Design your virtual office – from the tools you’ll use to how you’ll communicate and what core working hours you’ll all share.
What’s obvious to one person isn’t obvious to everyone else, so be explicit about how you want to work as a virtual team in a virtual office.
Check out our template to set up your team’s remote-working team charter.
Balancing work, social and home life
Do you want to have a strict start/end time for work, or integrate work and home life throughout the day?
Setting up anchors ⚓️ throughout your day 🗓 will help you balance the time spent on work vs socialising vs personal commitments.
As an example, you could set up calendar reminders at the start/end of the day to manage your work hours, add a break time to stretch your legs, book in virtual coffee sessions with colleagues, and block out time for helping the family. Do remember to tell your team when you are not available.
Don’t replicate all physical meetings with video calls
While regular video calls are important to connect with the team and discuss important topics, they can also be inefficient and draining.
Experiment with “asynchronous” meetings to reduce unnecessary video calls. As an example, you can set up a meeting agenda on a virtual whiteboard, get the team to do their preparation work by themselves, and then have a call to discuss the points everyone has added. This gives people more time to think and clarify upfront, which reduces circular conversations during the video call.
Some teams do a great job of treating meetings like “design sprints” which end up removing circular conversations, resulting in faster decisions and better focus in teams. But be prepared as this requires careful facilitation.
Setup the right (collaboration) tools
Just because you use Microsoft Word doesn’t mean this is the right collaboration tool for writing documents for remote working. Select the tools you use as a team based on how good they are at collaborative working rather than historical norms.
Where more than one person is adding information, your chosen tools should allow multiple people to participate by adding and editing simultaneously. These tools should be easy to access and may also have useful features like letting you comment, vote, share and export.
At a minimum, you need to consider the right tools for making video calls, messaging, writing on virtual whiteboards, managing tasks, sharing content and writing documents. We use zoom (video), slack (messaging), miro (whiteboard), Trello or Jira (task management), Google Drive or Confluence (content sharing), and Google Docs (documents).
Remove ambiguity when you communicate, be specific
Working remotely means we lose a lot of visibility around what colleagues are thinking, how they’re reacting, and whether we have clearly explained ourselves.
Here are some examples of how our teams follow online etiquette to over-communicate and create clarity:
- Say hi to the team on Slack with a 👋
- Change your status on Slack so people know you’re busy but will be back (⛔️I’m in the zone, back at 3pm)
- Leave the day with a 👋on Slack and a message about tomorrow (👋 See you tomorrow – I’ll be in at 10am – as I have childcare duties)
Given we would communicate these things to colleagues in the physical office, why shouldn’t we in our virtual office?
Another aspect of communicating is to “actively listen”. Ask clarifying questions and challenge colleagues to be more specific. Making assumptions in a virtual office creates even more confusion than when we’re sitting next to each other.
Instead of “it’ll take me longer to write this draft document”, try saying “this will take 4hrs longer, so I’ll finish by 2 pm. I’ll drop you a line when I’m done so you can check this and confirm it makes sense.”
Interested in more tips?
We are sharing our learning with a series of public webinars so if you are after some insights on how to build high-performing remote-first teams please contact email@example.com for details of the sessions or watch this video of a recent webinar