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.

Tips

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.

Learn More…

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.