It’s safe to say, most engineering teams have made the switch (whether temporary or permanent) to a remote work environment. And with that change have come some surprising wins and understandable challenges. One truth that has remained constant throughout our transition to this new normal is the importance of data. Building a data-driven engineering culture has empowered organizations pre-COVID to the present with the insights they need to work efficiently, advocate for their development teams and create a shared understanding that helps everyone do their best work. 

With the right data, you can spot bottlenecks before they become major problems. You can compare releases pre-pandemic to now. You can see that a team member’s work patterns have changed as a result of working from home, identify which teams are thriving and which are not, and coach those that need your help. These insights are necessary to lead through challenges and make your team a stronger, more effective unit.

Today’s challenges have understandably impacted many team’s output. By looking at release or sprint data today vs. pre-COVID, you can better define how the shift to remote work has impacted your teams and what you can do to help. 

If you’re seeing big changes in churn or engineers helping others, it could mean they’re either struggling with rework and requirements or that engineers are supporting each other and completing each other’s work in a way that’s different than before. You can see which engineers on which team are the largest contributors to each type of code, so you can understand your team’s work patterns and coach those that need it.

The project timeline report built into Pluralsight Flow enables you to dissect, even down to a daily level, the changes to workflow across a release. It shows you trends across your team’s sprint, including the total average output across the sprint, how much code delivery is new code versus updates to legacy code versus code churn and how much code is the product of one engineer helping another engineer.

Similarly, you can look at trends in collaboration patterns, which show you how quickly individuals are responding to each other. You can drill into the team level or even look at pairing between engineers. This will help you see how much collaboration is taking place—meaning how many pull requests someone is collaborating on, who they are collaborating with and what their response time is from person-to-person.

Productive throughput and impact are two core output metrics you can use to evaluate the health of your team’s workflow as you move to working remotely. Productive throughput is the amount of code after you remove recent rework and churn. Impact is a way to measure the ‘bigness’ of code changes that are happening in a way that goes beyond simplistic measurements like lines of code. It’s a measure of the severity of edits to the codebase, as compared to repository history.

You should expect some change in these metrics, but nothing major. If the total output of your team is dropping by less than 5% per release, you’re generally doing OK.

The retrospective report in Flow allows you to pick a defined period of time and compare it to a prior period, meaning you could compare the last four weeks you’ve worked remotely to four weeks when the team was together in the office. Not only is this useful in evaluating your team’s transition, but it’s also a great way to show leadership how your team has been affected by changes.

Spikes in rework can mean a few things. Your team might be hitting a technical roadblock or have a skills gap causing them to spend extra time on a problem they’re not sure how to solve. It can also mean there are changing requirements from business or product teams or poorly written user stories. 

You’re aiming to have 70-80% efficiency. A little work is a good thing—it means you’re improving code as you go. When it drops below 70%, or drops considerably below pre-COVID levels, that’s a sign that something is keeping your engineering team from moving through work as effectively as they could.

In Flow’s project timeline report, you can look at the code type delivered at the team level and understand at which points of time you have peaks in churn and who the largest contributors to churn are. 

By drilling down to the individual level, you can also see if someone is hitting issues that could be creating rework for them and others. You can see which project is driving that, giving you insight into where requirements are being changed or collaboration is not working. Knowing where these things are happening is important, so you can coach the team through it.

Some engineers are naturally moving to remote work and liking it. They have more time. They’re not bogged down with in-person meetings and they can optimize their time to code more. 

Others are not as good at time management, and you’ll see drop offs in their work patterns. More than anything, analyzing these changes gives you an opportunity to effectively coach team members on how to manage and structure their day.

In the workload report, you can see a daily summary of each engineer’s commit activity, the pull requests they’ve submitted and the comments they’re leaving on code reviews or pull requests. It gives you greater insight into your engineering team’s day and understand when they commit, when they do a pull request and when they do tickets, so you can see how things have changed since moving to a remote work environment.

How many hours is it taking to respond to feedback when someone submits a pull request? What percent of the time are they addressing the comments on their pull request and what percent of time are they making follow on commits based on the input on their pull requests? If your code review cycle time is going up by more than 10%, that’s a sign of possible issues you’ll want to drill into.

You can look at code review cycle times across your release cycles in Flow. Over the last month, has cycle time on pull requests changed notably? If you see that pull requests are taking longer than usual, dive in to understand why. You can look at distributions of response time in first to comment, number of reviewers and number of comments.

Code going through without being reviewed is always a red flag. Without a second set of eyes, mistakes can slip through causing major pain points for customers and headaches for your team later on. As a best practice, your code should always go through review before it gets deployed.

Simple. In Flow, you can look at the trend of unreviewed pull requests at the global, team and individual levels so you can identify exactly where your problems are and remedy them.

This is a problem that will get more pronounced as you move to remote work. In the office, you had the opportunity for people to talk to each other in person. As you move to distributed team communications, this can get a little harder, especially if everything is going through one or two people on your team. 

Look at your team’s knowledge sharing distribution pre-COVID-19 and now to understand how much collaboration was happening in person before versus formally in the system. As code reviews become more centralized, are more bottlenecks popping up causing code delays? Identifying those bottlenecks and removing them will significantly increase your efficiency. It’s an easy fix, but something that isn’t always so easy to spot without the right data.

Whether you find yourself suddenly leading a distributed team because of COVID-19 or you were making the change to remote work already, it’s important to get a clear understanding of how remote work impacts workflow efficiency, and what you can do to improve it. Flow’s reports and metrics makes this easier. 

Rather than guess what’s going wrong, pass judgement or feel frustrated, you can easily identify issues and coach your engineers to improve processes and work more efficiently. Remote doesn’t have to be a bad thing. In fact, with all this data at your disposal, your team could get into a great groove that helps you all feel empowered, productive and engaged in this new working world.