Improve Remote Development Workflow with Fewer Tools, Single Context

Remote work is the new norm

It's fair to say that working remotely is no longer "the future of work". It's the current standard for many tech companies with 75% of engineers now claiming they want the option to work remotely.

And while the benefits of remote work are clear, so are the challenges in making it really work for everyone involved. Development teams depend on consistent, clear communication to keep the development workflow moving, and so a distributed team will naturally face the critical challenge of maintaining the expected workflow velocity despite not being in the same physical location or even in the same time zone.

It's also the sort of thing that can get very overwhelming very quickly. It's easy for a developer or a manager to mistake a specific need or inefficiency in the workflow with an entire process that "just doesn't work". This kind of overgeneralization can lead to frustration, missed deadlines or worse.

A tactical framework for remote dev teams

To address this, many people focus on the soft skills that the team will need to work well remotely: good communication, a team player attitude, and a proactive approach to getting things done. A simple Google search will reveal lots of material covering these worthwhile topics.

But for a specialized use case such as a distributed, multidisciplinary development team working together, general soft-skill talk is not enough. A clear tactical framework is needed so that everyone on the team knows exactly how they'll be getting the job done.

And so we've outlined a step-by-step guide to how remote development teams can slow things down, improve their remote development workflows and increase the likelihood of success for everyone on the team.

Two quick notes before we begin:

• If some of these steps seem "obvious" to you, that's a good thing. The key objective here is to optimize the processes you already have, not create brand new ones that people aren't used to.
• We've used a typical FE-development workflow as an example below. This example is probably relevant to anyone out there who is developing some sort of frontend-centric product. But we've also tried to outline it generically enough that it can be applied to any other use case and workflow you might encounter.

Step 1 - Zoom out to find the "weak links" in your workflow

The first step to creating an effective tactical framework is to zoom out and define the team's development (pre-production) workflow. It's often helpful to actually map it out in writing and see what it looks like, step by step. For example, here's what a typical workflow looks like for a frontend team developing a new feature:

1. You write the code
2. You open a PR
3. Other developers perform a code review
4. You get feedback from other (non-technical stakeholders)
5. You resolve the open issues or comments
6. The team validates the changes/runs acceptance tests
7. You merge the PR

By looking at this from a birds-eye view, you can quickly identify the potentially weak links in the chain when this workflow is converted to a remote team.

Using our frontend development workflow example, items 1--3 are pretty straightforward. Coding, opening a PR and evening getting/giving a code review can be done from anywhere. Not only that, but code reviews are done in the familiar context of Github or other SCM tools, so it's usually no problem to continue this remotely.

Item 4 is where things start to get tricky. Getting pre-production feedback from other stakeholders is critical, and it's a lot more complicated when you're not all sitting in the same office. The designers can't just "show you something" on their screen.

With this exercise, we can preemptively identify the possible pain points in our remote development workflow. And this gives us the opportunity to come up with a solution that will allow the distributed team to move on to all the stages that follow - reviewing, addressing and approving the changes so the feature can get pushed to production.

Step 2 - Zoom in to better understand each of the "weak links"

Now that you've identified the weak link in your remote dev workflow ("getting feedback from other, non-technical stakeholders"), the next step is to zoom back in for a better understanding. Ask yourself - what are the specific actions that go into this "weak link" line item?

In our frontend development use case, the answer is that in order to get feedback from the team, 3 actions are required:

1. Sharing your pre-production work with other stakeholders
2. Collecting feedback from those stakeholders
3. Clearly reviewing this feedback together as needed

These 3 actions are the key ingredients to this part of the workflow. And by defining this so specifically, you now have a clear guide for how to help your remote team do its best work. Instead of sending vague motivational quotes about "teamwork", you can focus on finding solutions that check the boxes on the requirements you've defined.

Step 3 - Identify tools that check multiple boxes

Now that you have your requirements clearly laid out, it's time to find tools to address them. But since you're planning for remote work, you need to remember the golden rule of remote collaboration:

Remote teams always work better with fewer tools.

In a regular, in-office work environment, we might find 3 separate tools for getting this feedback from other stakeholders:

• A technical tool for creating preview environments
• Separate tools for collecting feedback
• Communication tools for scheduling and reviewing this feedback as needed

But a fragmented stack is a recipe for inefficiencies and confusion - exactly what we want to avoid in a remote work setting, especially when we have a multidisciplinary team. The more we can get everyone on the same page and using the same platforms, the smoother our remote collaboration will be.

To drive this point home, let's take the communication between developers and designers as an example.

Even when everyone is in the office together, designer-developer collaboration is incredibly inefficient - the two sides speak different languages entirely (visual vs code, Sketch/Figma vs IDEs), designers feel pushed out of projects early as budget/time constraints force devs to update designs without consulting them, and devs are often not brought on board from the very start, so they can't be involved in pre-production decision making.

So sticking to the same fragmented platform playbook when working remotely will just make these issues more pronounced. A much better approach is to get everyone working together in the same contexts and on the same platforms.

In the case of our frontend development workflow, applying this framework and finding solutions seems a lot easier said than done.

Sure, designers are getting into coding and learning GitHub 101, and design sensibility is becoming a more prominent skill required for developers, but at the end of the day each unit is used to working in a silo on the tools that suit their needs day to day.

So how can remote teams close these gaps between stakeholders to streamline their workflows?

A partial solution: preview environments for every PR

A common approach that many teams have taken is the use of preview environments for every pull request. The number of these solutions out there has been rapidly increasing as developers and dev teams have come to realize that it is to everyone's benefit to get other stakeholders involved in the pre-production review process.

More and more companies are adopting user-friendly solutions to generate preview environments for every pull request, and allow developers to easily share these links with others on the team for quick access and review. It's a good step in the right direction for many remote teams, but this alone is not enough.

Ephemeral environments themselves are like one-way mirrors. They help you share your latest code changes with others so they can review your work, but they do nothing for you in return.

They do not help you collect, review or address the subsequent feedback that others may have.

A complete solution: bring everyone to the "PRty" with collaborative pull requests

A more comprehensive approach is that taken by Livecycle. Livecycle's idea is exactly what our framework aims to achieve - create a single context for everyone on the team to review the latest changes, and limit the number of tools needed to make these iterations happen.  Livecycle makes this happen by leveraging your existing environments and adding a collaboration and annotation layer on top.

Here's how it works: after installing Livecycle on your frontend repository, Livecycle turns your passive preview environments into active, collaborative playgrounds. So anyone who opens the preview environment will not only see your latest work, but they can also comment on it, in context, on top of the product UI.

It works together with your existing pipeline to add a layer of built-in tools that keep all review comments for you in one place, per-environment. So the designers can leave you screenshots, QA can record a video of a problematic use case, and the folks in marketing can even edit the product copy and send it to you as a suggested change. And since everyone is working together in the same playground, the risk of workflow friction is dramatically reduced. Livecycle also syncs with those popular task management tools (like Jira, Linear and more) so all the important data ends up where it's needed without making anyone run between all those other apps and tools.

They basically created a product from the remote-work framework. By leveraging the PR and turning into an inclusive platform for EVERYONE on the team. Livecycle makes life easier for remote teams by allowing them to work together with fewer tools in a single context. Developers get better feedback. Other stakeholders give clearer comments in context, and everyone works better together even though they might be physically on opposite ends of the planet.

Conclusion

Livecycle is part of a new wave of devtools built to help teams effectively work remotely. It's a great illustration of the principles outlined above in our framework for helping remote teams achieve their goals.

Hopefully, more teams will follow this model to audit their own workflow practices and make the necessary changes to accommodate their remote teams in a more productive and effective way.